[DB] Indeling patiëntendatabase*

[StanTheMan]

Momenteel ben ik bezig met mijn onderzoeksstage voor geneeskunde, daarbij ben ik bezig een database in Access te maken, ik stuit nu alleen op een probleempje dat voor jullie programmeurs een appeltje-eitje moet zijn:

Ik heb de relaties als volgt (constructieve feedback is ook daarbij welkom, hoewel jullie moeten begrijpen dat ik natuurlijk geen opleiding op dit gebied volg):



Nu wil ik in het formulier tblBeh_aneurysma bij "Datum opname azM" een keuzelijst laten zien die de opnamedata laat zien van de geselecteerde patient-ID. Wat ik ook doe met query's: ik krijg alle opnamedata van alle patienten, terwijl ik alleen die van de geselecteerde patient wil laten zien.
Dit moet mogelijk zijn maar hoe...?

De dbase heb ik ook even hier staan (aangepast tot en met 12 juni naar aanleiding van de posts!)
http://www.stanleyoei.nl/dbasesableeg.zip

[ Voor 40% gewijzigd door StanTheMan op 12-06-2006 22:41 ]

[Rigi]

Misschien is het handig om ook even het probleem uit te leggen?

EDIT: intussen even naar je relaties gekeken, waarom heb je een opnamedatum en een patient id? Is het niet beter om gewoon een opnameID te maken waar je beide koppelt? scheelt een berg redundante data volgens mij

[ Voor 63% gewijzigd door Rigi op 09-06-2006 17:28 ]

[Invisible_man]

Een goede database ontwikkelen kan best wel lastig zijn en begint (bij mij iig) gewoon op papier. In hoe verre heb jij je in deze stof verdiept (dus niet hoe je het in Access moet kloppen, maar meer databases in het algemeen)? Aan de hand van die informatie kunnen we je wat "gerichter" adviseren. Iig veel suc6 met je project

[ Voor 20% gewijzigd door Invisible_man op 09-06-2006 17:29 ]

[NMe]

Om te beginnen is dit geen programmeerprobleem maar een ontwerpprobleem, en dat soort problemen horen in Software Engineering & Architecture, zoals je in Waar hoort mijn topic? had kunnen lezen.

Daarnaast zul je inderdaad veel meer informatie moeten geven voordat we je op weg kunnen helpen. Lees Programming Beleid - De "quickstart" even door en pas je topicstart aan. Hier kunnen we niet veel mee.

PRG>>SEA

[StanTheMan]

hey hey ik was even bezig met mn post editen....! Keek even hoe de thumbnail en t plaatje eruit kwamen, en toen bedacht ik dat t toch maar handiger is om de db online te zetten.

Jullie zijn verdomd snel met reageren..
Het lijkt er alleen op dat er in dit forum minder mensen kijken...?

[ Voor 72% gewijzigd door StanTheMan op 09-06-2006 17:34 ]

[Varienaja]

Ik sluit me bij -NME- aan. Ga eerst ontwerpen. Schrijf op wat er gebouwd moet worden. Probeer objecten te onderscheiden, en als je dat rond hebt mag je beginnen met tabellen (al kan je die ook laten genereren als je je objectenmodel af hebt).

Ik zie in jouw database bijvoorbeeld al een object Complicatie dat in twee verschillende tabellen staat. Dat kan niet goed zijn. Dus daarom: eerst ontwerpen!

[Invisible_man]

Ik sluit me bij -NME- aan. Ga eerst ontwerpen.

Euh... Volgens mij zij ik dat. foutje kan gebeuren

[Invisible_man]

Eén opmerking die ik over je huidige ontwerp kan maken is dat bijvoorbeeld de compilcaties voor en na de behandeling in apparte tabellen komen te staan. Handiger is om één tabel ta maken met daarin de behandelingen (hierin kan één patient vaker voorkomen met dezelfde en/of verschillende behandelingen). In deze tabel zijn er vervolgens optionele kollomen voor complicaties er voor en er na.

Blijft dat het ontwerpen van een database van dit formaat van een heel ander caliber is dan een adressenbestand oid.

[Rigi]

Ja, een goed ontwerp kan veel problemen voorkomen. Maar als je toch koste wat kost door wilt met dit ontwerp kan je toch gewoon iets doen in de trand van:


SELECT Datum_opname_azM from tblOpn where tblOpn.Patient-ID = ..
Of zie ik nu iets over het hoofd?

[ Voor 4% gewijzigd door Rigi op 09-06-2006 17:43 . Reden: typo ]

[StanTheMan]

Ik heb me uiteraard wel een tijd verdiept in databases, maar heb natuurlijk ook een hoop tijd moeten steken in het vergaren van de patiëntinformatie zelf.
Dit zal nooit een database worden die voldoet aan alle regels, daar heb ik simpelweg de kennis, tijd en opleiding niet voor.
Desondanks had ik toch gehoopt op wat goede tips (dus bv wat ABSOLUUT problemen gaat geven), en natuurlijk de vraag die ik in mijn opening stel....

In ieder geval alvast bedankt voor het meedenken wat jullie al duidelijk doen. Ik zal daar zeker iets mee kunnen.

Invisible_man schreef op vrijdag 09 juni 2006 @ 17:40:
Eén opmerking die ik over je huidige ontwerp kan maken is dat bijvoorbeeld de compilcaties voor en na de behandeling in apparte tabellen komen te staan. Handiger is om één tabel ta maken met daarin de behandelingen (hierin kan één patient vaker voorkomen met dezelfde en/of verschillende behandelingen). In deze tabel zijn er vervolgens optionele kollomen voor complicaties er voor en er na.

Ik had die complicaties ook in de "Opnametabel" staan, alleen geeft dat problemen als iemand 2 of 3 complicaties heeft toch?

[ Voor 38% gewijzigd door StanTheMan op 09-06-2006 17:56 ]

[whoami]

Nou, als je direct tips wilt:
- ik zou zowiezo geen gebruik maken van natural primary keys; dwz dat ik m'n primary key op een extra veld zou leggen (een auto-number bv) die verder geen enkele informatie toevoegt. Gewoon een 'administratief' gegeven voor de DB dus (zoek eens op surrogate primary keys).
- gebruik betere veldnamen, zet bv geen spaties in je veldnamen
- ik vraag me af of die velden die beginnen met 1ste / eerste / laatste / enz... te hebben. Meestal duidt dit op een repeterende groep, en dus normaliseer je dat best verder uit.

Verder is het nogal moeilijk (zeg maar onmogeljk) om zinnige tips te geven, aangezien we niets weten over het probleem domein.

[ Voor 23% gewijzigd door whoami op 09-06-2006 18:05 ]

[Invisible_man]

Ik had die complicaties ook in de "Opnametabel" staan, alleen geeft dat problemen als iemand 2 of 3 complicaties heeft toch?

Of dit problemen geeft of niet hangt er helemaal vanaf hoe de sleutel is. Als de patient (patientID bij jou) de sleutel is krijg je dit probleem ja, dan kan een bepaalde patient maar één keer in een tabel voorkomen. Als je echter de combinatie van patientID en behandelingsdatum de sleutel maakt, kan in één tabel een bepaalde patient meerdere behandelingen ondergaan, en zelfs meerdere de zelfde behandelingen op verschillende datums.

Met deze sleutel combinatie ben je echter wel beperkt tot één behandeling per datum. Wil je dit probleem oplossen, dan moet je de combinatie uitbreiden met het behandelingstype (geeft dan weer het probleem dat een patient een bepaald type behandeling maar één keer op een dag kan krijgen, maar ik zou niet weten of dit een probleem is of niet aangezien die namen mij niets zeggen ). Het toewijzen van sleutels en het bepalen welke informatie in welke tabel moet komen staan is iets wat ik zelf op papier doe. Hiervoor gebruik ik een methode die "normaliseren" heet volgens het boek "Databases en Access 2003" uitgegeven door Academic service, ISBN:90 395 2363 0.

Dit zelfde princiepe geld natuurlijk ook weer voor het complicaties probleem.

[ Voor 10% gewijzigd door Invisible_man op 09-06-2006 18:27 ]

[GambitRS]

Ik vraag me alleen af, waarom wordt het bouwen van een database aan iemand die geneeskunde studeert uitbesteed? Dat lijkt me meer een stage voor een Informatica student.... of eigenlijk een korte opdracht

Wat is het doel van je onderzoek? Hoe je databases moet bouwen? Of moet je soms onderzoeken of het nuttig zou kunnen zijn om iemand anders een database te laten bouwen om de processen te stroomlijnen? Voor het eerste volg je idd de verkeerde studie (namelijk niet nuttig als arts om dat te weten), voor het tweede kan je wellicht het probleem op een andere manier onderzoeken.

[StanTheMan]

het doel van mijn onderzoek/stage:
een goed overzicht hebben van alle patienten die vanaf 1998 in het academisch ziekenhuis maastricht een hersenbloeding hebben gehad en eventueel een behandeling, zo ja, welke behandeling en met welke outcome (na 3 maanden, na 2 jaar enz)

Daarnaast hebben deze patiënten natuurlijk een hele reeks aan variabelen (risicofactoren zoals roken, hun geslacht, leeftijd etc), en kunnen ze in goede of slechte toestand binnenkomen.

Uit deze gegevens kan vervolgens een beschrijvend verslag/artikel gemaakt worden. Om de gegevens van 500 patiënten (zoveel zijn het) in een overzicht te zetten heb ik gekozen voor een access database.
Deze database is namelijk ook handig om bij een bepaalde vraagstelling de juiste patiënten eruit te filteren, waarna gericht verder gekeken kan worden naar deze patiënten (dan moeten er ook andere gegevens zoals een opnamestatus bijgehaald worden). Bijvoorbeeld: hoe is het klinisch beloop bij patiënten ouder dan 75 jaar? Of bij patiënten die op een bepaalde locatie de afwijking hebben?

Al met al ben ik als student (over 2 maanden afgestudeerd), dus bezig met deze vraagstellingen. Onderdeel van de studie geneeskunde is een paar maanden onderzoek doen (waar ik ook iets uit haal, maar het is de bedoeling dat ik hier later naast mijn werk ook mee verder ga)
Een goed middel hierbij vonden wij zo'n database. Aangezien ik zelf op zich wat meer computer/software kennis heb dan mijn mede-studenten, heb ik wel de keuze gemaakt mij op access te storten, en het niet met excel te doen zoals de meesten doen.

Hoe dan ook: ik denk dat deze database zoals hij nu is (uiteraard moeten de formulieren nog wat aangepast worden) redelijk goed voldoet.

Tweede doel voor mij zelf is dat ik wat ervaring opbouw met Access, natuurlijk niet zoals iemand die informatica doet, maar ik vind het op zich best leuk, en het kan me in de toekomst uiteraard wel helpen bij onderzoek, al dan niet met hulp van een professional. Ik word hier natuurlijk niet voor betaald, ik doe het voor mezelf, maar ook het ziekenhuis (radiologie, neurologie), en uiteindelijk de patiënt, heeft hier veel aan.

Ik hoop dat dit wat meer duidelijkheid schept... In eerste instantie is deze database dus voornamelijk voor mijn eigen onderzoek, en ik kan later altijd nog de database (met hulp) perfectioneren tot iets wat door anderen bijgehouden kan worden. Tot zover vind ik het wel erg prettig om wat op- en aanmerkingen te horen.

[Invisible_man]

Ok dat is dan duidelijk . Deze database doet op dit moment ongeveer het zelfde als één of meerdere excelsheets (zo keek ik vroeger ook tegen databases op, totdat ik er echt les in kreeg), welliswaar uitgebreidt met wat zoekfuncties en dergelijke die access biedt.

Een voordeel van een goed ontworpen database is bijvoorbeeld dat deze automatisch verkeerde invoeren tegenhoudt (bijvoorbeeld een patient die twee keer dood gegaan is volgens je database). Aangezien je aangeeft dat deze voor persoonlijk gebruik is maakt dit weer minder uit.

Blijft wel het probleem waar je zelf al tegen aanliep: sleutels van meer dan één kolom.

De keus die je IMHO nu hebt is: a) of op de excel manier verder of: b) je daadwerkelijk in database ontwerp verdiepen.

[whoami]

Ik ken het, medische mensen die databasejes ontwikkelen.... Ik heb er ervaring mee op m'n werk, en meestal is zo'n DB echt niet onderhoudbaar.
Waarom zet je de risicofactoren bv in de patienten tabel ? Waarom niet in een aparte tabel de verschillende risico-factoren bijhouden (als er bv eentje bijkomt, hoef je enkel een record toe te voegen), en met een koppeltabel kan je aangeven welke patient er welke risico-factoren heeft.

Ik zou gewoon zeggen: schoenmaker blijf bij je leest, en laat iemand met voldoende kennis die DB ontwerpen.
Wil (of moet) je het toch persé zelf doen, dan is het misschien aan te raden om eerst eens even een en ander te lezen over normalisatie, een paar goed genormaliseerde DB's te bekijken (AdventureWorks, Norhtwind, ... ) en misschien eerst eens even wat eenvoudige oefeningkjes te doen; dat zal je misschien in een eerste fase als verloren tijd beschouwen, maar het zal je veel frustratie achteraf besparen.
Indien je later bv opmerkt dat er iets aan je DB model moet veranderd worden, dan zal je vloeken als het een ingrijpende verandering blijkt te zijn.

[Rigi]

Kijk naar what whoami hier ergens boven zegt, dat zal je imho zoiezo moeten doen. Verder kan het waarschijnlijk geen kwaad om even op zoek te gaan naar informatie rond database ontwerp. Wat dat betreft kijk ik graag bij universiteiten, die hebben daar vaak leuke slides/ docjes voor.
bv
http://www.utexas.edu/its...tamodeling/dm/design.html
http://www.cs.uu.nl/docs/vakken/db

EDIT: Dit bedoelde ik,niet wat hier recht boven staat:

- ik zou zowiezo geen gebruik maken van natural primary keys; dwz dat ik m'n primary key op een extra veld zou leggen (een auto-number bv) die verder geen enkele informatie toevoegt. Gewoon een 'administratief' gegeven voor de DB dus (zoek eens op surrogate primary keys).
- gebruik betere veldnamen, zet bv geen spaties in je veldnamen
- ik vraag me af of die velden die beginnen met 1ste / eerste / laatste / enz... te hebben. Meestal duidt dit op een repeterende groep, en dus normaliseer je dat best verder uit.

[ Voor 43% gewijzigd door Rigi op 09-06-2006 20:07 ]

[EfBe]

Was er een tijdje geleden ook niet iemand die hier zn ziekenhuis database liet bespreken? Staat me zoiets van bij.

In ieder geval: ziekenhuis databases zijn normaliter inmens groot. (1500 tables zijn geen uitzondering). Wees dus op je hoede dat je je probleemgebied goed afbakend en dat je dus niet verzand in het definieren van inmense hoeveelheid tabellen.

Ook zou ik beginnen met het gebruiken van fatsoenlijke namen: niet prefixen met tbl, geen afkortingen gebruiken en enkelvoudige tabelnamen. Dus geen
tblBeh_Patienten
maar: patient

[StanTheMan]

Hij zal niet inmens groot worden.. Er hangen (vooralsnog) ook geen belangrijke processen van af, om die reden zijn er ook geen middelen om een professional ervoor aan te trekken. Wellicht is dat iets voor later, iets waar ik later door deze minimale kennis van databases en access ook wat beter kan sturen. Dat is dan weer iets wat mooi meegenomen is.

Hoe dan ook: verder gaan op de dezez excel-achtige manier zoals invisible man zegt is waarschijnlijk ook hoe het verder zal gaan.

Toch heb ik nog op mijn oorspronkelijke vraag geen echt antwoord gekregen..... No offense, maar het is een beetje alsof iemand een medische vraag aan mij zou stellen, en ik dan antwoord dat het je vakgebied toch niet is....

[Invisible_man]

Toch heb ik nog op mijn oorspronkelijke vraag geen echt antwoord gekregen..... No offense, maar het is een beetje alsof iemand een medische vraag aan mij zou stellen, en ik dan antwoord dat het je vakgebied toch niet is....

Ha, heb je helemaal gelijk in . Ik zal weer eens wat in Access rondneuzen om die query's op patient te laten selecteren. Kan even duren overigens...

[Invisible_man]

Nu wil ik in het formulier tblBeh_aneurysma bij "Datum opname azM" een keuzelijst laten zien die de opnamedata laat zien van de geselecteerde patient-ID. Wat ik ook doe met query's: ik krijg alle opnamedata van alle patienten, terwijl ik alleen die van de geselecteerde patient wil laten zien.
Dit moet mogelijk zijn maar hoe...?

Waar wil je dit hebben, met een formulier is dit te doen (eerst een patiënt selecteren, waarna je het desbetrefende lijstje krijgt). Wil je dit echter ergens in de tabellen, wordt dit idd lastiger (de tabellen zijn eigenlijks niet bedoeld als user-interface, dit zou echter via de formulieren en raporten moeten gaan).

[StanTheMan]

Allereerst dank voor je behulpzaamheid.

Ik wil het uiteraard wel in het formulier hebben..
Via main menu kun je naar aneurysma (Beh. + FU) gaan, bij het subformulier rechts wil ik dan dat onder "Datum opname azM" een keuzelijst komt van de beschikbare opnamedata die in eerste instantie in het formulier "Opname" is ingevuld (dus tabel "tblOpn"), dat zal bijna altijd 1 datum zijn, maar soms meer. Ik snap niet hoe je ervoor kan zorgen dat dat lijstje alleen maar de Opnamedata query'd voor het ingevulde Patient-ID..

Natuurlijk zou dit makkelijker voor je zijn als er gegevens in de database zouden staan, maar de reden voor een lege dBase zal duidelijk zijn, hoewel ik misschien beter even wat 'dummy's' erin had kunnen zetten...

[ Voor 24% gewijzigd door StanTheMan op 10-06-2006 01:20 ]

[JochemK]

Het eerste wat ik dacht toen ik dit topic zag was "DoCmd.Open(eyes)" (ooit te lang VBA geprogrammeerd voor een Access db, en toen werd ik op die manier wakker)

Die Access db die ik toen moest maken was, toevalligerwijs, ook voor een ziekenhuis. Alleen bij mij was het een schoolproject, op de universiteit, waar we met 5 man een heel trimester lang hard aan gewerkt hebben.

Wat ik hiermee wil zeggen is, verkijk je niet op de hoeveelheid en de complexiteit van het werk die je keuze met zich meebrengt.

Ik krijg ook de indruk dat het niet een systeem wordt dat erg "levendig" zal zijn, m.a.w. waar 1 keer de data in gaat, je vervolgens een zootje query's op uitvoert, en wat dan onder een laag stof verdwijnt. Is het die moeite allemaal waard?

[StanTheMan]

Als ik daar één of meer mooie artikelen uit kan halen vind ik dat wel de moeite.. Zoals ik ook al zei: je moet ergens beginnen, ik vind dat ik op deze manier toch wel een hoop te zien krijg van databases, access en de complexiteit ervan. Iets wat in de toekomst bij het doen van onderzoek toch wel van pas kan komen.
Verder hoop ik verder te kunnen op die afdeling, als ik straks klaar ben, waarna ik dit natuurlijk weer zal oppakken.

[Verwijderd]

Bouw een nieuwe query en geef aan de criteria -1 of >-1

zo worden niet alle patienten getoont.
Gewoon wat stoeien met bepaalde opties en dan moet het lukken

[ Voor 27% gewijzigd door Verwijderd op 10-06-2006 10:59 ]

[StanTheMan]

Verwijderd schreef op zaterdag 10 juni 2006 @ 10:58:
Gewoon wat stoeien met bepaalde opties en dan moet het lukken

Toptip!

[NMe]

StanTheMan schreef op vrijdag 09 juni 2006 @ 22:22:
Toch heb ik nog op mijn oorspronkelijke vraag geen echt antwoord gekregen..... No offense, maar het is een beetje alsof iemand een medische vraag aan mij zou stellen, en ik dan antwoord dat het je vakgebied toch niet is....

Er worden toch heel wat bruikbare tips gegeven? whoami had in zijn eerste post wat algemene opmerkingen, en er wordt later, als je meer info gegeven hebt ook inhoudelijk op je model ingegaan, onder andere door whoami en EfBe. Toch zie ik je nergens ingaan op die antwoorden en eigenlijk alleen algemene opmerkingen maken. Niet zo gek dat je dan weinig ervan opsteekt.

Kort samengevat:

1. Je benamingen zijn niet geweldig (geen spaties gebruiken, geen speciale tekens, hoofdletters zijn ook niet nodig).
2. Je keys zijn opgebouwd uit velden die door de gebruiker worden ingevuld en zelfs gewijzigd kunnen worden. Dat is niet praktisch: als iemand een veld wijzigt moet je alle foreign keys die ernaar verwijzen ook wijzigen. Neem dus nietsbetekenende autonummeringvelden als PK. Uitzondering: de patiëntentabel, want een patiënt-ID kan (lijkt me) toch niet veranderd worden.
3. Beter normaliseren! Je stopt teveel info in één tabel, info die je beter uit elkaar kan trekken en in losse tabellen zetten. Dat proces heet normalisatie en maakt je database een stuk onderhoudbaarder.
4. Andere tabellen zijn juist weer overbodig. Complicaties voldoen bijvoorbeeld voor en na een behandeling aan dezelfde datastructuur. Beetje zinloos om ze dan in aparte tabellen te zetten. Splits de tabellen op zodat je één record per complicatie krijgt, sla daarbij op of het voor of na een bepaalde ingreep was en sla bovendien op bij welke ingreep die info hoort. Ook dat is weer onderdeel van het normalisatieproces.
5. Je zegt dat je database niet immens groot gaat worden. 1500 tabellen worden het waarschijnlijk inderdaad niet nee, maar het worden er bij een fatsoenlijk ontwerp zeker meer dan de 10 die je nu hebt. Schrik daar dan ook niet van, als je goed normaliseert en indexeert betekent dat geen performanceverlies voor je applicatie.

Dat zijn de belangrijkste punten die hierboven al genoemd zijn. Afgezien van dat kunnen we je weinig info meer geven voordat je met een nieuwe, verbeterde draft van je ontwerp komt. Zoek wat info op over normalisatie, pas die toe in een nieuw ontwerp, en post dat ontwerp hier daarna nog een keer.

[Verwijderd]

Het prbleem wat je wilt oplossen lijkt me meer iets voor spss? of zit ik hier nu helemaal naast?

[StanTheMan]

Bedankt -NMe-, natuurlijk bedoel ik het niet ondankbaar. Ik ga ook zeker met de tips aan de slag, maar pas morgen of vanaf maandag weer.. (daar moet ik echt voor gaan zitten). Morgen jarig en vanavond feestje, dus een hoop voor te bereiden...

[ Voor 7% gewijzigd door StanTheMan op 10-06-2006 15:49 ]

[Verwijderd]

Bij de one-to-many relaties gebruik ik altijd PK ('Primary Key') en FK ('Foreign Key') achtervoegsels in plaats van overal het ID achtervoegsel. Hiermee kan ik dus heel simpel zien of ik een veld heb wat aan de 'one' of aan de 'many' kant van mijn one-to-many relatie zit.

Ik wil ook nergens een dubbele veldnaam; als je de namen van je tabellen extreem kort houdt, kun je overwegen om ieder veld met de naam van je tabel te laten beginnen.

Denk goed na of een relatie one-to-one, one-to-many of many-to-many is. In het geval van many-to-many heb je een tussenliggende tabel nodig die de many-to-many relatie opsplitst in one-(many-many)-one.

"Everything needs to be built top-down, except the first time"

Cheers,

[NMe]

Verwijderd schreef op zaterdag 10 juni 2006 @ 16:02:
Bij de one-to-many relaties gebruik ik altijd PK ('Primary Key') en FK ('Foreign Key') achtervoegsels in plaats van overal het ID achtervoegsel. Hiermee kan ik dus heel simpel zien of ik een veld heb wat aan de 'one' of aan de 'many' kant van mijn one-to-many relatie zit.

Kwestie van smaak, maar een beetje zinloos IMO. In je resultset bij het ophalen middels een query is de tabel waar het veld uit komt irrelevant, dus de toevoeging _FK is dat ook. Dan kun je beter in de ene tabel een id hebben, en in de andere een tabelnaam_id, aangezien je dan tenminste nog duidelijk hebt waar het id vandaan komt.

Ik wil ook nergens een dubbele veldnaam; als je de namen van je tabellen extreem kort houdt, kun je overwegen om ieder veld met de naam van je tabel te laten beginnen.

Dat vind ik juist altijd erg irritant. Het voegt niets toe, en in de gevallen dat er verwarring kan zijn kun je altijd nog aliassen gebruiken. Queries worden op jouw manier al gauw erg log en vervelend leesbaar omdat je dingen krijgt als "SELECT patient.patient_naam". Het nut van het dubbel neerzetten van de entiteitnaam ontgaat me niet helemaal, maar IMO weegt het niet op tegen de minpunten.

[StanTheMan]

Ok, ben nu weer volop ermee bezig.

Moet wel zeggen dat ik bij wijze van trial al een kleine 25 patiënten erin heb gestopt, en gezien een deadline kan en wil ik niet veel langer met de database zelf bezig zijn. Natuurlijk moet ik dan niet verwachten dat de dbase optimaal is, maar ik zie het als een leerproces en zoals ik al zei, met wat ik nu heb kan ik in principe al voldoende vraagstellingen beantwoorden.

- Nu wil ik wel de risicofactoren apart zetten, als een waarde "Onbekend" is hoef ik die niet erin te zetten (anders zou die tabel ellelang worden), maar is dat later dan nog goed terug te halen (dus stel dat ik een lijst wil van alle patienten waarbij het rookgedrag onbekend is)?
Dan kan ik dus volstaan met een Ja/Nee waarde (als dit wel bekend is). En bijvoorbeeld bij roken een keuzemenu maken met (Nu/Nee/Gestopt).. Of zien jullie hier problemen mee?

- Als ik het goed begrijp moet ik dus in alle tabellen de veldnamen aanpassen zodat er geen spaties in voorkomen (dus bijvoorbeeld underscores gebruiken). Hoofdletters misschien niet nodig, maar zal geen kwaad kunnen lijkt me.

- Ik ga kijken of ik ergens surrogate keys kan maken (hopend dat t aanpassen van de reeds toegevoegde patiënten niet al te veel werk zal zijn)

Dan toch nog de vraag hoe ik in een formulier een keuzelijst kan maken van beschikbare opties passend bij een patient ID die wel gekoppeld is vanuit het hoofdformulier in het subformulier waar je die keuzelijst wil hebben...

[NMe]

StanTheMan schreef op maandag 12 juni 2006 @ 11:28:
- Nu wil ik wel de risicofactoren apart zetten, als een waarde "Onbekend" is hoef ik die niet erin te zetten (anders zou die tabel ellelang worden), maar is dat later dan nog goed terug te halen (dus stel dat ik een lijst wil van alle patienten waarbij het rookgedrag onbekend is)?
Dan kan ik dus volstaan met een Ja/Nee waarde (als dit wel bekend is). En bijvoorbeeld bij roken een keuzemenu maken met (Nu/Nee/Gestopt).. Of zien jullie hier problemen mee?

Gewoon in een losse tabel zetten, kan geen kwaad. Vervolgens is het prima op te halen met joins in een relatief simpele query.

- Als ik het goed begrijp moet ik dus in alle tabellen de veldnamen aanpassen zodat er geen spaties in voorkomen (dus bijvoorbeeld underscores gebruiken). Hoofdletters misschien niet nodig, maar zal geen kwaad kunnen lijkt me.

Het mòet niet, maar het is niet gangbaar (en niet handig) om spaties in je tabelnamen te gebruiken.

- Ik ga kijken of ik ergens surrogate keys kan maken (hopend dat t aanpassen van de reeds toegevoegde patiënten niet al te veel werk zal zijn)

Zit je op een live database te werken dan?

Dan toch nog de vraag hoe ik in een formulier een keuzelijst kan maken van beschikbare opties passend bij een patient ID die wel gekoppeld is vanuit het hoofdformulier in het subformulier waar je die keuzelijst wil hebben...

Zie eerst maar dat je ontwerp goed is, implementatie is voor later zorg. Je zou je nog helemaal niet bezig moeten houden met dat niveau van denken.

[StanTheMan]

Je bent er wel snel bij altijd.. Ik zie dat je uit Reuver komt, heb daar 2 jaar geleden 10 weken huisartsstage gedaan... (Huisarts Van Megen)

[NMe]

StanTheMan schreef op maandag 12 juni 2006 @ 11:39:
Je bent er wel snel bij altijd..

Service van de zaak.

[StanTheMan]

Zo even bezig geweest:
Relaties nu

Nu heb ik een probleem, of denk ik een probleem te hebben, bij het verbinden van tblOpn --> tblBeh_aneurysma en tblComplicatiesProc:

naast hoe het nu is, wil ik ook gegevens uit tblOpn relateren aan bijvoorbeeld de procedurele complicaties.
Die procedurele complicaties moeten wel rechtstreeks gerelateerd worden aan tblBeh_aneurysma omdat de complicaties zelf ook te herleiden moeten zijn naar een bepaald aneurysma.

De complexiteit zit 'm eigenlijk hierin:
- een patient kan meerdere aneurysma's hebben
- een aneurysma kan meerdere behandelingen hebben
- die behandelingen hoeven natuurlijk niet allemaal tijdens één opname plaats te vinden
- tijdens een behandeling kunnen meerdere aneurysma's behandeld worden, maar procedurele complicaties moeten bijvoorbeeld wel te herleiden zijn tot een bepaald aneurysma

Hoe kan ik het beste de opname koppelen aan de procedurele complicaties (ik wil bijvoorbeeld zoeken bij een bepaalde uitkomstmaat in tblOpn hoeveel mensen een bepaalde procedurele complicatie had, of ik wil van alle opnames zien hoeveel (bepaalde) procedurele complicaties waren)

[ Voor 4% gewijzigd door StanTheMan op 12-06-2006 14:30 ]

[StanTheMan]

On topic:

Ik kan natuurlijk bij tblBeh_aneurysma het Opname_Nr toevoegen, maar dan zou ik die handmatig moeten toevoegen, alleen weet ik dat nummer bij het invullen natuurlijk niet (de opnamedatum zoals ik het eerst had moest ik ook handmatig invullen)

[ Voor 14% gewijzigd door StanTheMan op 12-06-2006 15:56 ]

[NMe]

Ik heb even wat offtopic posts verwijderd.

[StanTheMan]

Nu heb ik het zo:

Graag jullie meningen, is dit werkbaar? Verbeterpunten?

[NMe]

1. Waarom verwijst tbl_FU naar re-bleeds maar heeft die geen enkele verwijzing naar de re-bleed tabel? Een verwijzing zou meteen die datum overbodig maken in tbl_FU.
2. Vanwaar ineens die compleet onduidelijke tabelnamen? Afkortingen zijn nergens voor nodig lijkt me? Schrijf de entiteiten gewoon voluit, zonder spaties of speciale tekens, in enkelvoud. Dus niet "tblBeh" maar "Behandeling" (al dan niet met hoofdletter) en niet "tblOpn" maar "Opname". Dat maakt je queries straks een stuk duidelijker.
3. Verschillende voorkomens van hetzelfde veld kun je beter dezelfde naam geven. Ik zie zowel Patient-ID als Patiënt-ID. Sowieso is een streepje in een veldnaam IMO niet erg handig, omdat je daar zonder brackets om aan te geven dat het om een veldnaam gaat eigenlijk een rekensom mee aanduidt.
4. Ik zie tabellen met een PatientID die verder geen verwijzing hebben naar de Patiëntentabel.
5. Kun je voor de resultatenvelden in de twee tabellen rechtsonder niet beter een aparte resultatentabel maken waar je naar verwijst?

Dit is wat ik nu zo snel even zie, ik heb nou even de puf niet om er dieper op in te gaan. Bovendien mis ik natuurlijk jouw vakkennis om te zien wat alles voorstelt.

[StanTheMan]

He bedankt!

-NMe- schreef op maandag 12 juni 2006 @ 22:35:
[list=1]
• Waarom verwijst tbl_FU naar re-bleeds maar heeft die geen enkele verwijzing naar de re-bleed tabel? Een verwijzing zou meteen die datum overbodig maken in tbl_FU.

Begrijpelijke opmerking, maar re-bleeds na behandeling heeft een wat andere betekenis dan een re-bleed tijdens de opname. Daarom denk ik dat niet geïntegreerd hoeft te worden, maar ik zal er nog eens even over denken.

• Vanwaar ineens die compleet onduidelijke tabelnamen? Afkortingen zijn nergens voor nodig lijkt me? Schrijf de entiteiten gewoon voluit, zonder spaties of speciale tekens, in enkelvoud. Dus niet "tblBeh" maar "Behandeling" (al dan niet met hoofdletter) en niet "tblOpn" maar "Opname". Dat maakt je queries straks een stuk duidelijker.

Ga ik veranderen, ik kan je ook niet vertellen waarom ik het zo cryptisch heb gedaan...

• Verschillende voorkomens van hetzelfde veld kun je beter dezelfde naam geven. Ik zie zowel Patient-ID als Patiënt-ID. Sowieso is een streepje in een veldnaam IMO niet erg handig, omdat je daar zonder brackets om aan te geven dat het om een veldnaam gaat eigenlijk een rekensom mee aanduidt.

Mooi dat je dat zo vlotjes ziet, ga ik mee aan de slag. Is een underscore ook een potentieel "onhandig" teken?

• Ik zie tabellen met een PatientID die verder geen verwijzing hebben naar de Patiëntentabel.

Het betreffende veld (ik zag er zo maar één) heb ik verwijderd.

• Kun je voor de resultatenvelden in de twee tabellen rechtsonder niet beter een aparte resultatentabel maken waar je naar verwijst?

Stomme fout dat ik het zo op het net gezet heb, de resultatenvelden moesten alleen in één tabel staan.

[/list]
Dit is wat ik nu zo snel even zie, ik heb nou even de puf niet om er dieper op in te gaan. Bovendien mis ik natuurlijk jouw vakkennis om te zien wat alles voorstelt.

Ik heb overigens nu de gezipte lege database geupload voor de mensen met puf, of die morgen weer puf hebben (ook ik moet maar eens gaan stoppen!)

[ Voor 88% gewijzigd door StanTheMan op 12-06-2006 22:53 ]

[StanTheMan]

Na verbetering:

[NMe]

StanTheMan schreef op maandag 12 juni 2006 @ 22:42:
Begrijpelijke opmerking, maar re-bleeds na behandeling heeft een wat andere betekenis dan een re-bleed tijdens de opname. Daarom denk ik dat niet geïntegreerd hoeft te worden, maar ik zal er nog eens even over denken.

Ik denk dat je dan beter een flag op kan nemen in die re-bleedtabel waarmee je dat aangeeft. Op die manier kun je die re-bleedtabel toch ook gebruiken voor dat andere type, en heb je alle bij elkaar horende data ook echt bij elkaar staan.

Ga ik veranderen, ik kan je ook niet vertellen waarom ik het zo cryptisch heb gedaan...

Mooi dat je dat zo vlotjes ziet, ga ik mee aan de slag. Is een underscore ook een potentieel "onhandig" teken?

Underscores zijn op zich geen probleem nee. Ik zou het persoonlijk houden bij letters, cijfers en eventueel inderdaad underscores.

Het betreffende veld (ik zag er zo maar één) heb ik verwijderd.

Het was er inderdaad maar eentje.

Stomme fout dat ik het zo op het net gezet heb, de resultatenvelden moesten alleen in één tabel staan.

Dan nog heb je twee resultaatvelden per record. Als resultaten altijd relatief beknopt in een tekstveldje staan dan kun je het zo laten; wil je het iets specifieker maken, dan is een aparte tabel misschien toch handiger. Wat als er meerdere resultaten bij één record horen? Of kan dat niet voorkomen?

[NetForce1]

Ik heb nog wel wat kleine dingetjes:
[list=1]
• Er zijn verschillende kolommen die een dubbele punt aan het einde van de naam hebben (bijv. in de tabel ClippingSpecifiek
• De tabel Opname heeft een kolom 'Re-bleed', maar vanuit de tabel Rebleeds wordt ook al naar Opname verwezen. Dit lijkt me dubbelop.
• In de tabel Opname heb je een kolom GEEN_Angio, het is handiger om deze Angio te noemen. Het is namelijk (dat is tenminste mijn ervaring) een beetje verwarrend omdat je de boolean die daar waarschijnlijk inzit continue moet inverteren in je hoofd
• De naamgeving van je kolommen is inconsequent. Denk bijv. aan underscores vs streepjes (underscores hebben de voorkeur, want dat is geen operator), woorden scheiden via hoofdletters of underscores/streepjes of allebei, nr versus id versus nummer (in de pk's)
• In de tabel Opname heb je bijv. de kolommen 1e_CT, 1e_CTA ed. betekend dat dat er ook een 2e_CT kan komen en een 3e_CT? Dan is het beter om daar ook een extra tabel voor te maken.
• De kolom Aantal_aneurysmas in de tabel Opname lijkt me overbodig (is te berekenen)
• De kolom Behandeling in de tabel Opname, staat daarin of er wel of geen behandeling is geweest tijdens de opname? Dat lijkt me ook te berekenen door de records uit de tabel Behandeling op te vragen die het juiste OpnameNr hebben
• In de tabel Patient heb je de kolom Overleden, en Datum_overlijden. Dat is dubbelop lijkt me, zolang Datum_overlijden null is is iemand nog niet overleden
• De kolommen Ja_Onbekend in de tabellen Voorgesch(iedenis?) en Medicatieg(egevens?) voelen wat dirty aan. Volgens mij kun je dat oplossen door alle records uit die tabellen op te vragen voor een PatientID, als er dan niets gevonden wordt is het onbekend.

Dit zijn wat dingen die ik zo 1, 2, 3 even uit je screenshot haal. Er zijn vast nog meer dingen te verzinnen, maar dan moet je er iig langer naar kijken en meer kennis hebben van het domein.

[NMe]

Met de meeste puntjes van NetForce1 ben ik het ook eens, maar op eentje reageer ik even.

NetForce1 schreef op dinsdag 13 juni 2006 @ 00:21:
Ik heb nog wel wat kleine dingetjes:

• In de tabel Opname heb je een kolom GEEN_Angio, het is handiger om deze Angio te noemen. Het is namelijk (dat is tenminste mijn ervaring) een beetje verwarrend omdat je de boolean die daar waarschijnlijk inzit continue moet inverteren in je hoofd.

Het feit dat GEEN met hoofdletters geschreven is en opgenomen is tussen allerlei andere afgekorte veldnamen doet me vermoeden dat het een afkorting is voor het een of het ander.

[NetForce1]

-NMe- schreef op dinsdag 13 juni 2006 @ 00:25:
Met de meeste puntjes van NetForce1 ben ik het ook eens, maar op eentje reageer ik even.

[...]

Het feit dat GEEN met hoofdletters geschreven is en opgenomen is tussen allerlei andere afgekorte veldnamen doet me vermoeden dat het een afkorting is voor het een of het ander.

Dat zou idd kunnen, daar had ik nog niet aan gedacht. Wij hebben in ons systeem eens een kolom gehad waarvan de naam eindigde op _not, dit omdat de checkbox in de interface standaard uit stond. Gelukkig is dat er al weer een tijdje uit, maar hij wordt nog regelmatig aangehaald als voorbeeld van hoe het ook alweer niet moet.

[StanTheMan]

-NMe- schreef op maandag 12 juni 2006 @ 23:50:
[...]
Ik denk dat je dan beter een flag op kan nemen in die re-bleedtabel waarmee je dat aangeeft. Op die manier kun je die re-bleedtabel toch ook gebruiken voor dat andere type, en heb je alle bij elkaar horende data ook echt bij elkaar staan.
[...]

Ik heb het aangepast, dat lijkt me ook beter.

Dan nog heb je twee resultaatvelden per record. Als resultaten altijd relatief beknopt in een tekstveldje staan dan kun je het zo laten; wil je het iets specifieker maken, dan is een aparte tabel misschien toch handiger. Wat als er meerdere resultaten bij één record horen? Of kan dat niet voorkomen?

Er kunnen bij een flowmeting wel meer resultaten zijn, maar dan gaat het ook om verschillende vaten, dus dan komen er in die tabel 2 FlowID's te staan met een verschillende vat, er is altijd wel maar 1 waarde vooraf en achteraf (er wordt een klemmetje om een aneurysma/bloedvatuitstulping gezet, vooraf en erna wordt de doorstroming in het moedervat gemeten om te weten of die niet veel lager uitvalt. Dan zou het zo goed moeten zijn toch (pre- en post staat dan ook direct naast elkaar)

[StanTheMan]

Allereerst ook bedankt dat je de moeite neemt om 's nachts ernaar te kijken...

NetForce1 schreef op dinsdag 13 juni 2006 @ 00:21:
[list=1]
• Er zijn verschillende kolommen die een dubbele punt aan het einde van de naam hebben (bijv. in de tabel ClippingSpecifiek

Verwijderd.

• De tabel Opname heeft een kolom 'Re-bleed', maar vanuit de tabel Rebleeds wordt ook al naar Opname verwezen. Dit lijkt me dubbelop.

Als ik straks puur wil kijken naar het aantal opnames/mensen die een Re-bleed kregen tijdens hun opname (het maakt niet uit hoeveel), is het dan niet handiger op deze manier? Dan hoef ik alleen de opnames met een vinkje bij de rebleed te bekijken. Met een query zou je dan moeten vergelijken of er een record bekend is in de tabel rebleeds voor die patiënt (als het kan ook nog tussen opnamedatum en ontslagdatum), dit lijkt me best complex. Of heb ik het mis?

• In de tabel Opname heb je een kolom GEEN_Angio, het is handiger om deze Angio te noemen. Het is namelijk (dat is tenminste mijn ervaring) een beetje verwarrend omdat je de boolean die daar waarschijnlijk inzit continue moet inverteren in je hoofd

Overigens is dit voor de verandering GEEN afkorting , ik heb dit zo gedaan omdat ik heb gemerkt dat van de 500 patiënten dit misschien max 5-10 keer voorkomt. Dus meer uit efficiëncy overwegingen, of zeggen jullie ondanks dat gegeven dat ik het bevestigend moet maken?

• De naamgeving van je kolommen is inconsequent. Denk bijv. aan underscores vs streepjes (underscores hebben de voorkeur, want dat is geen operator), woorden scheiden via hoofdletters of underscores/streepjes of allebei, nr versus id versus nummer (in de pk's)

Had ik ook gemerkt, ben dat ook aan 't aanpassen.

• In de tabel Opname heb je bijv. de kolommen 1e_CT, 1e_CTA ed. betekend dat dat er ook een 2e_CT kan komen en een 3e_CT? Dan is het beter om daar ook een extra tabel voor te maken.

Die zijn er wel, maar zijn niet relevant voor de database, het gaat er hier om om de delay tussen opname, hersenbloeding, en de 1e CT te zien. "Hoe snel krijgt iemand de eerste scan?"

• De kolom Aantal_aneurysmas in de tabel Opname lijkt me overbodig (is te berekenen)

Daar zat ik gisteren ook al naar te kijken. Ik heb een "Datum gevonden" in de tabel aneurysma staan, ik kan dus het aantal records voor een bepaalde patiënt relateren aan die datum uit de tabel aneurysma's en bijvoorbeeld de datum van ontslag?
Bij een eerste opname kan iemand er 1 hebben, maar na 2 jaar misschien wel 2. Dat moet wel terug te vinden zijn per opname.

• De kolom Behandeling in de tabel Opname, staat daarin of er wel of geen behandeling is geweest tijdens de opname? Dat lijkt me ook te berekenen door de records uit de tabel Behandeling op te vragen die het juiste OpnameNr hebben

Correct, dat kan dus ook weg.

• In de tabel Patient heb je de kolom Overleden, en Datum_overlijden. Dat is dubbelop lijkt me, zolang Datum_overlijden null is is iemand nog niet overleden

True... Hm, tenzij de datum van overlijden onbekend is...

• De kolommen Ja_Onbekend in de tabellen Voorgesch(iedenis?) en Medicatieg(egevens?) voelen wat dirty aan. Volgens mij kun je dat oplossen door alle records uit die tabellen op te vragen voor een PatientID, als er dan niets gevonden wordt is het onbekend.

Was ik ook bang voor, maar ik heb gezien dat het vaakst "Nee" voorkomt (logisch). Ik wilde daarom diezelfde logica toepassen daarop. Alle records opvragen, indien niets gevonden hebben ze het niet, anders is het positief of onbekend.
Reden hiervoor is uiteraard het korter/kleiner houden van de tabel, en het invoeren te versnellen.
Is het nog steeds not done in dit geval?

[ Voor 7% gewijzigd door StanTheMan op 13-06-2006 12:31 ]

[NMe]

StanTheMan schreef op dinsdag 13 juni 2006 @ 12:26:
Overigens is dit voor de verandering GEEN afkorting , ik heb dit zo gedaan omdat ik heb gemerkt dat van de 500 patiënten dit misschien max 5-10 keer voorkomt. Dus meer uit efficiëncy overwegingen, of zeggen jullie ondanks dat gegeven dat ik het bevestigend moet maken?

Dat zou ik inderdaad wel doen. Of je nu true of false opslaat maakt verder niet uit, en het zou je model wat overzichtelijker maken. NetForce1 heeft het al redelijk mooi verwoord hierboven.

True... Hm, tenzij de datum van overlijden onbekend is...

Mja, om die reden kun je ofwel twee velden nemen zoals je nu hebt, ofwel je neemt één speciale datum ver in het verleden (of in de toekomst) die je laat staan voor "nog niet overleden" danwel "sterfdatum onbekend", waardoor je NULL overhoudt voor de andere optie. Welke van de twee je daarbij kiest maakt performancetechnisch niet zo gek veel uit.

Reden hiervoor is uiteraard het korter/kleiner houden van de tabel, en het invoeren te versnellen.
Is het nog steeds not done in dit geval?

De tabel klein houden moet niet een direct doel zijn. Wat je wil is op een overzichtelijke manier je data opslaan, en op een snelle manier deze data eruit krijgen. Schijfruimte is goedkoper dan processorkracht. Wat overigens niet betekent dat je alle berekenbare data maar dubbel op moet nemen; dat is weer een ander uiterste.

[StanTheMan]

Even dat laatse duidelijk krijgen, want dat is wel een belangrijk punt in dit geheel. Als de tabel klein houden niet belangrijk is, is het wel de tijd die het extra kost om 15 keer een record met nee toe te voegen (arbeid is weer nog duurder dan schijfruimte en processorkracht...)
Is het verder wel goed werkbaar met de "indien geen record nee", ja of onbekend als er wel een record is? (ik vermoed dat dat moet lukken, maar NetForce1 noemt het ook niet voor niets "dirty"

Edit:
Over de ANGIO, wel of niet.. Ook dit is weer te berekenen. Indien CTA en MRA en DSA null dan geen angio... dus kan weg...

[ Voor 17% gewijzigd door StanTheMan op 13-06-2006 12:47 ]

[NMe]

StanTheMan schreef op dinsdag 13 juni 2006 @ 12:45:
Even dat laatse duidelijk krijgen, want dat is wel een belangrijk punt in dit geheel. Als de tabel klein houden niet belangrijk is, is het wel de tijd die het extra kost om 15 keer een record met nee toe te voegen (arbeid is weer nog duurder dan schijfruimte en processorkracht...)

Hoezo een record met nee toevoegen? Ik geloof dat ik je niet helemaal begrijp.

[StanTheMan]

Voor het gemak laat ik nu alles wat negatief is gewoon weg, omdat dat ook het vaakst voorkomt.
Wat dan overblijft is dan ja of onbekend.

Stel dat ik in die tabellen voor True/False zou kiezen, en geen record zou "Onbekend" zijn, wat logischer klinkt, dan moet ik wel bij elke patiënt een record voor alle beschikbare factoren toevoegen.

Ben ik zo wat duidelijker?

-NMe- schreef op dinsdag 13 juni 2006 @ 12:38:
[...]
Mja, om die reden kun je ofwel twee velden nemen zoals je nu hebt, ofwel je neemt één speciale datum ver in het verleden (of in de toekomst) die je laat staan voor "nog niet overleden" danwel "sterfdatum onbekend", waardoor je NULL overhoudt voor de andere optie. Welke van de twee je daarbij kiest maakt performancetechnisch niet zo gek veel uit.
[...]

Dat is wel een goed idee ja, bv gewoon 1-1-1901 voor sterfdatum onbekend, maar wel overleden.

[ Voor 45% gewijzigd door StanTheMan op 13-06-2006 12:59 ]

[TheRookie]

Dat zou ik niet zo snel doen, ik kan me nog herinneren dat er toendertijd een 'soort' van "Y2K" probleem verwacht werdt met 9-9-99 omdat programmeurs dat ook een mooie datum ver in de (toen nog) toekomst vonden;).

Ik zou 2 velden houden: Een boolean met Overleden en een apart datumveld indien datum overlijden bekend is

@-NMe-: ik denk dat TS bedoeld dat de default waarde van dat veld 'Ja' is en dus in 90% v/d gevallen handmatig aangepast zou moeten worden aangezien het maar op een beperkt aantal records van toepassing is; dit is op te lossen door de default waarde op Nee te zetten

[ Voor 37% gewijzigd door TheRookie op 13-06-2006 13:16 ]

[StanTheMan]

In dat geval moet ik dus een nieuwe tabel maken waar al die factoren naast elkaar staan (eigenlijk zoals het eerst ook in de patiëntentabel stond).
Ik had het net veranderd in deze vorm:

VGRFID	PatientID	VG_RF	Ja_Onbekend	Jaartal	Specificatie_bij_anders
1	1111111	Hypertensie	Ja	1995

En dan uiteindelijk in het formulier gewoon in een keuzelijstje een kenmerk selecteren, ja of onbekend en dat is dan een nieuw record

[ Voor 131% gewijzigd door StanTheMan op 13-06-2006 13:59 ]

[NetForce1]

StanTheMan schreef op dinsdag 13 juni 2006 @ 12:26:

[...]

Als ik straks puur wil kijken naar het aantal opnames/mensen die een Re-bleed kregen tijdens hun opname (het maakt niet uit hoeveel), is het dan niet handiger op deze manier? Dan hoef ik alleen de opnames met een vinkje bij de rebleed te bekijken. Met een query zou je dan moeten vergelijken of er een record bekend is in de tabel rebleeds voor die patiënt (als het kan ook nog tussen opnamedatum en ontslagdatum), dit lijkt me best complex. Of heb ik het mis?

Dat valt wel mee hoor, die twee data heb je hier niet nodig, omdat rebleeds al gekoppeld zijn aan een specifieke Opname. Ik heb voor de grap even een query voor je gemaakt die per patient het totaal aantal rebleeds telt.

SQL:

SELECT Patient.PatientID AS PatientID, COUNT(*) AS AantalRebleeds
FROM Patient, Opname, Rebleeds
WHERE Patient.PatientID = Opname.PatientID AND Opname.OpnameNr = Rebleeds.OpnameNr
GROUP BY Patient.PatientID

[...]
Was ik ook bang voor, maar ik heb gezien dat het vaakst "Nee" voorkomt (logisch). Ik wilde daarom diezelfde logica toepassen daarop. Alle records opvragen, indien niets gevonden hebben ze het niet, anders is het positief of onbekend.
Reden hiervoor is uiteraard het korter/kleiner houden van de tabel, en het invoeren te versnellen.
Is het nog steeds not done in dit geval?

Hmm, dit is een leuke. Misschien is het een idee om in de tabel Patient een veld Voorgeschiedenis_bekend of heeft_Voorgeschiedenis te hebben. Bij de eerste optie is er geen voorgeschiedenis als er geen gerelateerde records in de tabel Voorgeschiedenis zijn. Bij de tweede optie is de voorgeschiedenis onbekend als er geen gerelateerde records in de tabel Voorgeschiedenis zijn.

[StanTheMan]

Ja, maar dan scheer je wel de hele voorgeschiedenis over één kam. Het komt af en toe voor dat je van een aantal zaken wel weet, of mag aannemen dat ze negatief zijn, maar voor bijvoorbeeld roken en alcoholgebruik is dit weer niet duidelijk. Dit geldt ook voor de medicatie, van sommige middelen kan ik wel verwachten dat ze niet gebruikt worden, als ik naar het verhaal kijk, maar van andere middelen kan ik daar niet vanuit gaan...
Lastig....
Toch maar gewoon een tabel bouwen waarin alle factoren als velden genoemd zijn, waarbij alles standaard op nee staat en ik dan alleen maar ja of onbekend hoef te kiezen uit een invoerlijstje?

(En relaxed dat je ook zo actief meedenkt)
Ik heb nu het volgende:

[ Voor 15% gewijzigd door StanTheMan op 13-06-2006 15:31 ]

[NMe]

NetForce1 schreef op dinsdag 13 juni 2006 @ 14:42:
Hmm, dit is een leuke. Misschien is het een idee om in de tabel Patient een veld Voorgeschiedenis_bekend of heeft_Voorgeschiedenis te hebben. Bij de eerste optie is er geen voorgeschiedenis als er geen gerelateerde records in de tabel Voorgeschiedenis zijn. Bij de tweede optie is de voorgeschiedenis onbekend als er geen gerelateerde records in de tabel Voorgeschiedenis zijn.

Waarom dat extra veld? Je kan toch gewoon een outer join toepassen? Wanneer er geen voorgeschiedenis is, is gewoon automatisch een aantal velden NULL.

[NetForce1]

-NMe- schreef op dinsdag 13 juni 2006 @ 16:46:
[...]

Waarom dat extra veld? Je kan toch gewoon een outer join toepassen? Wanneer er geen voorgeschiedenis is, is gewoon automatisch een aantal velden NULL.

Agreed, ik interpreteerde voorgeschiedenis iets anders.

[StanTheMan]

ik houd het voor vandaag maar weer voor gezien, gezien de tijd ben ik ook al aan de slag geweest met nieuwe formulieren, en heb ik even de oude ingevoerde gegevens langsgelopen, ondanks alle aanpassingen klopte het nog allemaal goed, gelukkig.

Ik heb het idee dat het met de tabelindeling redelijk ok is, de problemen die ik nu tegenkom, zijn volgens mij formulierproblemen, daarover mogelijk later meer.... Uiteraard blijven suggesties altijd welkom! Tot zover bedankt, ik kom er echt veel verder mee.

[ Voor 6% gewijzigd door StanTheMan op 13-06-2006 18:34 ]

[StanTheMan]

Ok, we gaan weer naar de volgende problemen, nu met betrekking tot formulieren.
Zo heb ik de relaties:


Ik heb eigenlijk 2 kwesties:
het eerste gaat over dit aneurysmaformulier
Via mijn hoofdmenu kan ik een patientnr/naam selecteren, en via een knop kom ik in dit scherm.
Bovenaan komen de PatientID en Naam te staan, en in het subformulier worden netjes de bij die persoon behorende aneurysma's getoond.
Wat ik nu wil is, dat ik ook in het SubSubformulier erboven een aneurysma kan selecteren, waarna het record wordt gekozen in het Subformulier. Er moet dus weer een terugkoppeling zijn vanuit het subsubformulier naar het subformulier.
Enige tips hoe ik dat moet doen?

Tweede kwestie gaat over het behandelingsformulier.
Vanuit de opname wil ik de behandelingen invullen. Ik wil hier in plaats van het vakje AneurysmaID een lijstje hebben van de aneurysma's die bekend zijn bij deze patiënt (het AneurysmaID en de bijbehorende locatie).
Met een query kan ik wel de juiste lijst krijgen, maar ik weet niet hoe je in dit geval de query vanuit een formulier kan aanroepen zodat hij alleen maar de waarden voor een bepaald BehandelingID weergeeft (en een BehandelingID is via de OpnameID, via de PatientID naar de aneurysmaID's gekoppeld).
Dit laatste kan ik dan ook weer toepassen op het Follow-Up gebeuren wat ik eigenlijk op dezelfde manier als de behandelingen aangepast heb.

Ik hoop dat jullie me snel op weg kunnen helpen hiermee, want ik zit alweer enkele uren te stoeien hiermee.

[ Voor 3% gewijzigd door StanTheMan op 15-06-2006 15:49 ]

[NMe]

Je bent nu bezig met implementatiespecifieke dingen binnen Access. Je bent sneller geholpen als je die vragen stelt in Officesuites en -software, waar je terecht kan voor alle Office-gerelateerde zaken. Het is beter als je daar even een nieuw topic opent met in je startpost een linkje naar dit topic en de tekst uit je laatste post.

[StanTheMan]

Thanks!