Topdown normaliseren v.e. Database vraag

[Frenkpie]

Hoi ik volg een BI opleiding (1e jaar) in Eindhoven en ben nu bezig met een Database te normaliseren om later in MS-Access te implementeren en wat formuliertjes te maken.

Dat klinkt allemaal niet zo spannend. Maar we moeten nu aan de hand van een tekst een IBS (informatie behoefte structuur) en een ERD (entity relationship Diagram) maken.

Normaliter komt er een één op één relatie weinig voor in een ERD. maar ik heb het idee dat ik nu twee situaties ben tegengekomen waar dit van toepassing is.

Mijn vraag was of iemand dat kon bevestigen of dat klopt, of dat ik de plank finaal missla?

Het stukje tekst:

U wordt als informatieanalist gevraagd om een informatiesysteem te ontwerpen voor het opname- en operatiegebeuren in een ziekenhuis. Gemakshalve zien we af van spoedgevallen (patiënten die niet het normale opnamegebeuren doorlopen). De volgende beknopte omschrijving is relevant: een patiënt die moet worden geopereerd, krijgt van de behandelend specialist een indicatie- kaart, waarop allerlei persoonlijke gegevens en een opnamediagnose zijn ingevuld. Met die kaart gaat de patiënt naar de afdeling Opname, waar hij de kaart afgeeft en een wachtlijstformulier meekrijgt. Dit formulier wordt in de regel door de patiënt thuis ingevuld (o.a. met gegevens over de gewenste opnameperiode, godsdienst, huisarts, etc.) en aan de afdeling Opname toegestuurd. Deze completeert het formulier met o.a. de gegevens van de indicatie- kaart en het dagstempel, waarna het formulier wordt opgenomen in een bestand (kaartenbak), aan te duiden met wachtbestand. De indicatiekaarten zijn nu afgewerkt en gaan naar de afdeling Patiëntenadministratie. Ze zijn verder voor dit verhaal irrelevant.
Het zojuist genoemde wachtbestand is o.a. nodig voor het dagelijks bepalen van een opnameprogramma. Daarvoor zijn ook nodig gegevens over beschik- bare vrije bedden c.q. beschikbare operatietijd. Laatstgenoemde gegevens komen van de verpleegafdelingen en van het hoofd van de operatiekamers (hoofd OK). Indien besloten wordt een patiënt op te nemen, stuurt de afdeling Opname een bericht aan de betreffende patiënt (meestal telefonisch) met uiteraard vermelding van de dag van opname. Alle verzonden berichten worden genoteerd in een zogenoemd bestelboek.

Mijn IBS (gedeelte):
Patiënt
PatiëntNr
PatVoorletters
PatRoepNaam
PatTussenvoegsel
PatAchternaam
PatGebDatum
PatHuisnr
PatGeslacht
PatPolisnr
PatHuisarts
PatApotheek
Postcode
MedicusNr
VerzekeringNr

Opname
PatiëntNr
GewenstOpname
OpnameDatum
Godsdienst
PersoneelNr
BerichtVerzonden
Opnamediagnose

MedischDossier
PatiëntNr
PatNoodTelNr
PatOntslagDatum
PatNoodTelNr
PatAllergie
PatDieet
PatBloedgroep

Ik dénk dus dat de Entiteiten "MedischDossier"en "Opname" een één op één relatie hebben met de patiënt.

Want:
- een patiënt heeft één medisch dossier. en een medisch dossier heeft gegevens over één patiënt.
- een patiënt heeft één opnamedag en een opname heeft één patiënt.

(de 2e twijfel ik het meeste over...)

someone? thnx alvast

[Frenkpie]

Zou ik misschien niet beter "Godsdienst" bij de entiteit "patiënt" kunnen zetten? Ondanks dat deze gegeven op een ander formulier wordt ingevuld kan het toch in een zelfde entiteit worden gezet??

Je zou dan bijna zeggen dat je een één op meer relatie kan leggen.. alleen "GewenstOpname" "BerichtVerzonden" en "Opnamediagnose" is per patiënt verschillend.. alhoewel het wel KAN dat er patiënten zijn met én dezelfde gewenste opname datum én dat het bericht is verzonden én dat ze dezelfde opname diagnose hebben.. alleen dat is denk ik niet echt goed denk ik ???

[ Voor 51% gewijzigd door Frenkpie op 16-12-2005 16:46 ]

[pasta]

Ik zou zelf idd Godsdienst onder Patiënt zetten.

Hoe dan ook, dit lijkt me meer iets voor Programming & Webscripting, dus ik verplaats je topic even.

[Frenkpie]

Ok foutje... ik wist niet precies waar ik het neer moest zetten omdat dit niet echt programmeren is

ik heb wat geprobeerd.. en ik dénk dat het een Many to Many relatie is tussen de Opname en Patiënt.

Je moet dus gebruik maken van een Koppelregel. Dit heb ik er nu van gemaakt:

Koppel_PatOpn
OpnameNr
PatiëntNr
GewenstOpname
BerichtVerzonden
Opnamediagnose
BedNr

Patiënt
PatiëntNr
PatVoorletters
PatRoepNaam
PatTussenvoegsel
PatAchternaam
PatGebDatum
PatHuisnr
PatGeslacht
PatPolisnr
PatHuisarts
PatApotheek
Postcode
MedicusNr
Godsdienst
VerzekeringNr

Opname
OpnameNr
OpnameDatum
PersNr

[Eärendil]

Many to many zou inhouden dat bij elke patienten meerdere opnames kunnen horen (lijkt me aannemelijk) en dat bij elke opname meerdere patienten kunnen horen, dat tweede lijkt me niet nodig.

[Verwijderd]

Volgens mij heb je te maken met een 1 op veel relatie. Een patient kan immers meerdere malen worden opgenomen. Bij het dossier is het een beetje twijfelachtig, maar omdat ik er bijvoorbeel ook dieet in zie staan (iets wat kan veranderen naar verloop van tijd) is het misschien slim om dit ook als 1 op veel relatie in te delen zodat je een historie van dossiers en dus dieten? opbouwt.

[edit]
Zoals hierboven al staat is de omgekeerde situatie niet echt aannemelijk: een opname hoort bij 1 patient immers & hetzelfde geldt voor dossier.

[ Voor 18% gewijzigd door Verwijderd op 16-12-2005 17:31 ]

[Frenkpie]

Eärendil schreef op vrijdag 16 december 2005 @ 17:19:
Many to many zou inhouden dat bij elke patienten meerdere opnames kunnen horen (lijkt me aannemelijk) en dat bij elke opname meerdere patienten kunnen horen, dat tweede lijkt me niet nodig.

als je kijkt naar de attributen zit in de opname tabel de opname datum.. dus op één opname dag en voor één personeelslid kunnen meerdere patiënten worden opgenomen...

logisch toch?

[ Voor 3% gewijzigd door Frenkpie op 16-12-2005 17:47 ]

[Verwijderd]

Ja, je hebt wel gelijk dat 1 medewerker meerder personen kan opnemen, maar daardoor wordt het nog geen meer op meer relatie. Er komen bijvoorbeeld op 16-12-2005 4 patienten binnen, die hebben allemaal hun eigen entry in de opname tabel. Dan kan het zo zijn dat bij 3 van de 4 hetzelfde Personeelnr staat. Dat valt er met een query weer uit te halen:
SELECT COUNT(Patientnr) AS Aantal from PATIENT WHERE Personeelnr = x

[EfBe]

Frenkpie schreef op vrijdag 16 december 2005 @ 16:39:
Hoi ik volg een BI opleiding (1e jaar) in Eindhoven en ben nu bezig met een Database te normaliseren om later in MS-Access te implementeren en wat formuliertjes te maken.

Dit is een huiswerk-opdracht?

Dat klinkt allemaal niet zo spannend. Maar we moeten nu aan de hand van een tekst een IBS (informatie behoefte structuur) en een ERD (entity relationship Diagram) maken.

Hebben ze bij BI nooit van NIAM/ORM gehoord? ERD is een abstractieniveau lager, waardoor je al in tabellen gaat denken en dat is juist bij normaliseren niet wat je wilt.

Normaliter komt er een één op één relatie weinig voor in een ERD. maar ik heb het idee dat ik nu twee situaties ben tegengekomen waar dit van toepassing is.

Waar baseer jij het op dat normaliter 1:1 relaties weinig voor komen?

Mijn vraag was of iemand dat kon bevestigen of dat klopt, of dat ik de plank finaal missla?
Het stukje tekst:
[...]

Met zo'n beschrijving kun je erg weinig, behalve concluderen dat er erg veel informatiestromen zijn en bitter weinig optimalisatie in deze stromen. (en erg veel foutgevoeligheden).

Ok, here we go.

Mijn IBS (gedeelte):
Patiënt
PatiëntNr
PatVoorletters
PatRoepNaam
PatTussenvoegsel
PatAchternaam
PatGebDatum
PatHuisnr
PatGeslacht
PatPolisnr
PatHuisarts
PatApotheek
Postcode
MedicusNr
VerzekeringNr

NOOIT fieldnames prefixen, voegt niets toe. Tabellen en views ook nooit prefixen overigens.

Opname
PatiëntNr

Dit gaat niet werken, want dan kan er maar 1 keer een opname volgen voor een patient. voor de entity 'Opname' is patientnr dus niet een identifying attribute. Patient+OpnameDatum wel, maar je zou ook kunnen kiezen voor OpnameNr, een attribute dat je nu niet hebt gedefinieerd in Opname, maar wat nuttig kan zijn bij het oplossen van de andere fouten, zie beneden. Dus, voeg OpnameNr toe en maak dat PK.

GewenstOpname

Is dit een flag, 'gewenst/ongewenst' ? Indien ja, niet suffixen, we weten al dat het een attribute van Opname is.

OpnameDatum
Godsdienst

Godsdienst is een attribute van patient, en dus moet deze bij patient geplaatst worden. Ik zou je echt aanraden op http://www.orm.net te kijken en je de kennis die daar staat tot je te nemen, zodat je meer begrijpt wat attributes en entities zijn en hoe ze zich tot elkaar verhouden.

PersoneelNr
BerichtVerzonden
Opnamediagnose

Wat is personeelnr? Ik neem aan de ID van een personeelslid betrokken bij de opname? Dat kunnen er wellicht meerdere zijn. Een personeelslid kan bij meerdere opnamen betrokken zijn, een opname kan meerdere personeelsleden hebben, dit betekent een m:n relatie. Je moet dus een nieuwe entity creeeren, die die m:n relatie realiseert: OpnamePersoneel. Let overigens op de 2 zinnen die ik hierboven neerzette. Via die zinnen kun je heel makkelijk de relaties herleiden tussen entities. En bv ook 'Patient heeft godsdienst' etc. Zodoende kun je makkelijk relaties leggen tussen attributes en entities en entities onderling.

OpnamePersoneel
OpnameNr
PersoneelNr

Ok, verder.

MedischDossier
PatiëntNr
PatNoodTelNr

Niet afkorten, volledige namen ingeven van velden. We zitten niet op een DB2 database uit 1874 met 8 chars per fieldname.

PatOntslagDatum
PatNoodTelNr
PatAllergie
PatDieet
PatBloedgroep

Ik heb een beetje moeite met deze entity. Alle attributes hebben een 1:1 relatie met patient. Dit betekent automatisch dat ze in de patient entity terecht komen, tenminste als ze verplicht zijn. Je plaatst 1:1 related attributes in een aparte entity indien ze niet verplicht zijn. Echter, elke patient heeft een medisch dossier (kenmerk van patient), en dus zijn alle attributes verplicht en als je ze dan TOCH in een aparte entity plaatst krijg je ALTIJD 2 entity instances: patient en medischdossier. Dit is dus overbodig, en je moet dus de attributes in de patient entity plaatsen.

Ik dénk dus dat de Entiteiten "MedischDossier"en "Opname" een één op één relatie hebben met de patiënt.

Want:
- een patiënt heeft één medisch dossier. en een medisch dossier heeft gegevens over één patiënt.
- een patiënt heeft één opnamedag en een opname heeft één patiënt.

Medisch dossier's attributes horen allemaal bij patient, en dus horen de gegevens bij patient en niet bij opname en hebben de attributes van wat jij nu medisch dossier noemt NOOIT een relatie met opname. Patient heeft een relatie met Opname, en via DIE relatie kun je vanaf opname bij de medische gegevens van de patient komen, maar ze hebben zelf geen relatie met opname.

Ik zag verder nog iemand met SQL aankomen: een relationeel model is iets dat je gewoon kunt ontwerpen zonder te denken aan SQL, sterker: je MAG niet aan SQL denken, eerst het relationele model, dan je queries, niet andersom. SQL is bedoeld om te werken MET een relationeel model, niet om het te definieren. Je dus laten beinvloeden door 'dit is vast sneller in SQL' is een van de grootste fouten die men maakt bij het definieren van een relationeel model. De andere is overigens 'in tables denken'. Een relationeel model is gerealiseerd in tables, maar niet gedefinieerd in tables.

[Frenkpie]

EfBe schreef op zaterdag 17 december 2005 @ 12:12:
[...]

Dit is een huiswerk-opdracht?

Een eind opdracht, ik moet dit ontwerpen in Access en dan "verdedigen" in de tentamen week.

[...]

Hebben ze bij BI nooit van NIAM/ORM gehoord? ERD is een abstractieniveau lager, waardoor je al in tabellen gaat denken en dat is juist bij normaliseren niet wat je wilt.

Ja dat hebben ze me wel verteld, maar ik heb het niet goed opgenomen / toegepast toen ik hieraan was begonnen..

[...]

Waar baseer jij het op dat normaliter 1:1 relaties weinig voor komen?

vertelde me leraar dat er weinig 1op1 relaties voorkomen.. maar hij bedoelde in een bep. situatie denk ik.. want aan jouw vraagstelling te zien is dat denk ik niet zo?

[quote]
[...]

Met zo'n beschrijving kun je erg weinig, behalve concluderen dat er erg veel informatiestromen zijn en bitter weinig optimalisatie in deze stromen. (en erg veel foutgevoeligheden).
[quote]

Ik zal de hele tekst even laten zien:

U wordt als informatieanalist gevraagd om een informatiesysteem te ontwerpen voor het opname- en operatiegebeuren in een ziekenhuis. Gemakshalve zien we af van spoedgevallen (patiënten die niet het normale opnamegebeuren doorlopen). De volgende beknopte omschrijving is relevant: een patiënt die moet worden geopereerd, krijgt van de behandelend specialist een indicatie- kaart, waarop allerlei persoonlijke gegevens en een opnamediagnose zijn ingevuld. Met die kaart gaat de patiënt naar de afdeling Opname, waar hij de kaart afgeeft en een wachtlijstformulier meekrijgt. Dit formulier wordt in de regel door de patiënt thuis ingevuld (o.a. met gegevens over de gewenste opnameperiode, godsdienst, huisarts, etc.) en aan de afdeling Opname toegestuurd. Deze completeert het formulier met o.a. de gegevens van de indicatie- kaart en het dagstempel, waarna het formulier wordt opgenomen in een bestand (kaartenbak), aan te duiden met wachtbestand. De indicatiekaarten zijn nu afgewerkt en gaan naar de afdeling Patiëntenadministratie. Ze zijn verder voor dit verhaal irrelevant.
Het zojuist genoemde wachtbestand is o.a. nodig voor het dagelijks bepalen van een opnameprogramma. Daarvoor zijn ook nodig gegevens over beschik- bare vrije bedden c.q. beschikbare operatietijd. Laatstgenoemde gegevens komen van de verpleegafdelingen en van het hoofd van de operatiekamers (hoofd OK). Indien besloten wordt een patiënt op te nemen, stuurt de afdeling Opname een bericht aan de betreffende patiënt (meestal telefonisch) met uiteraard vermelding van de dag van opname. Alle verzonden berichten worden genoteerd in een zogenoemd bestelboek.
Op de dag van opname vervoegt de patiënt zich bij de afdeling Opname, die o.a. gegevens op het wachtlijstformulier controleert en in het bestelboek aantekent dat opname is geschied. De patiënt wordt vervolgens naar zijn verpleegafdeling gebracht, die over de patiënt een medisch dossier aanlegt (nodig voor de vastlegging van allerlei medische gegevens).
Opgenomen patiënten zijn bepalend voor het operatieprogramma (we hebben immers afgezien van spoedgevallen). Dit programma wordt gemaakt door de afdeling Opname en het hoofd OK op grond van het wachtlijstformulier, gegevens uit het medische dossier (verstrekt door de verpleegafdeling) en op grond van gegevens over beschikbare bokcapaciteit (operatiekamer, medisch personeel). Is een operatieprogramma gemaakt, dan wordt dit doorgegeven aan een afdeling binnen het OK-Complex, aan te duiden met OK-POST. Deze OK-POST informeert alle betrokkenen over het programma (verpleegafdelingen van de te opereren patiënten, chirurgen, anesthesisten etc.).
Op de dag van de operatie geeft de OK-POst aan de verpleegafdeling door wanneer een patiënt naar de operatiekamer gebracht kan worden. Bij aankomst in deze kamer controleert de OK-post aan de hand van het mee vervoerde medische dossier en aan de hand van het operatieprogramma of de juiste patiënt is gebracht. Na die controle begint de anesthesist met de verdoving, waarna de operatie plaatsvindt. Na de operatie moet de anesthesist de verdoving 'uitleiden' (beëindigen) en gaat de patiënt voor korte tijd naar een zogenoemde 'recovery-afdeling'. Is hij enigermate hersteld van de operatie, dan wordt hij vervoerd naar zijn verpleegafdeling. Na iedere operatie wordt een operatieformulier ingevuld door een van de verpleegkundigen die bij de operatie betrokken was. Op dit formulier worden o.a. gegevens vermeld zoals: geopereerde patiënt (naam, patiëntnummer), verrichte operatie (een of meer verrichtingen), personeelsnummer van de betrokken personen bij de operatie (chirurg, assistent, anesthesist, diverse verpleegkundigen), operatiebegin- en eindtijd, begin- en eindtijd van de anesthesie, etc. Dit formulier is nodig voor twee doeleinden, te weten:
1. de financiële afwikkeling van de operatie (factuur e.d.);
2. het maken van allerlei overzichten (statistieken) over het operatiegebeuren.

Ok, here we go.

[...]

NOOIT fieldnames prefixen, voegt niets toe. Tabellen en views ook nooit prefixen overigens.

Maar als ik in de klant tabel de attributen: naam, achternaam etc. in zet én in de personeelstabel: naam, achternaam.... dan weet je niet meer welke attributen nu precies bij welke entiteit hoort...

[...]

Dit gaat niet werken, want dan kan er maar 1 keer een opname volgen voor een patient. voor de entity 'Opname' is patientnr dus niet een identifying attribute. Patient+OpnameDatum wel, maar je zou ook kunnen kiezen voor OpnameNr, een attribute dat je nu niet hebt gedefinieerd in Opname, maar wat nuttig kan zijn bij het oplossen van de andere fouten, zie beneden. Dus, voeg OpnameNr toe en maak dat PK.

Dat heb ik al gedaan "Opname" ziet er nu zo uit:

Opname
OpnameNr
OpnamePeriode
BerichtVerzonden
Opnamediagnose
PatiëntNr
BedNr
PersNr

BedNr is dus het gereserveerde bed voor de desbetreffende patiënt. Dan kunnen de zusters wanneer ze een opname programma maken voor een andere patiënt zien welke bedden nog beschikbaar zijn.

Per patiënt kan één personeelslid worden toegekend die hem begeleid. Dus bijv. een zuster.

[...]

Is dit een flag, 'gewenst/ongewenst' ? Indien ja, niet suffixen, we weten al dat het een attribute van Opname is.

"Opnamegewenst" dat is de gewenste opname datum. Dat heb ik hernoemd naar "GewOpnamePer" (gewenste opname periode)

Omdat ik een Wachtlijstformulier moet maken heb ik de entiten "wachtbestand" toegevoegd:

Wachtbestand
WachtbestandNr
WachtbestandDatum
GewOpnamePer
PatNoodTelNr
Huisarts
PatiëntNr

[...]

Godsdienst is een attribute van patient, en dus moet deze bij patient geplaatst worden. Ik zou je echt aanraden op http://www.orm.net te kijken en je de kennis die daar staat tot je te nemen, zodat je meer begrijpt wat attributes en entities zijn en hoe ze zich tot elkaar verhouden.

Hmm mja oke maar godsdienst moet worden ingevuld op het wachtlijstformulier.. en dit wordt niet gegeven wanneer een patiënt zich inschrijft in het ziekenhuis (via de verzekering bijv.) .... daarom dácht ik dat het dan niet direct bij de patiënt hoort.. maar nu je het zegt klopt dat wel ja.. één patiënt heeft een godsdienst.

[...]

Niet afkorten, volledige namen ingeven van velden. We zitten niet op een DB2 database uit 1874 met 8 chars per fieldname.

[...]

Wordt het niet een beetje slordig door alles volledig uit te schrijven?

Ik heb een beetje moeite met deze entity. Alle attributes hebben een 1:1 relatie met patient. Dit betekent automatisch dat ze in de patient entity terecht komen, tenminste als ze verplicht zijn. Je plaatst 1:1 related attributes in een aparte entity indien ze niet verplicht zijn. Echter, elke patient heeft een medisch dossier (kenmerk van patient), en dus zijn alle attributes verplicht en als je ze dan TOCH in een aparte entity plaatst krijg je ALTIJD 2 entity instances: patient en medischdossier. Dit is dus overbodig, en je moet dus de attributes in de patient entity plaatsen.

Ik heb het "medischdossier" gemaakt omdat de bloedgroep enz alleen maar in het medisch dossier wordt vermeld van een patiënt, en het is niet de bedoeling dat iedereen het bloedgroep en het dieet van een bep. patiënt mag zien.

De entiteit is gemaakt vanwege de rechten. Niet ieder personeelslid mag in het medisch dossier van een patiënt kijken.. daarom is dat apart gemaakt.

Of kan ik dat nog toepassen in access zonder een aparte entiteit aan te maken?

Verder: bedankt voor je uitgebreiden post!

Mijn IBS en ERD:

[EfBe]

Frenkpie schreef op zaterdag 17 december 2005 @ 15:18:
[...]
vertelde me leraar dat er weinig 1op1 relaties voorkomen.. maar hij bedoelde in een bep. situatie denk ik.. want aan jouw vraagstelling te zien is dat denk ik niet zo?

Je kunt er niet zomaar vanuit gaan dat ze minder voor komen.

[...]
Maar als ik in de klant tabel de attributen: naam, achternaam etc. in zet én in de personeelstabel: naam, achternaam.... dan weet je niet meer welke attributen nu precies bij welke entiteit hoort...

Ik heb zo'n vermoeden dat je er niet veel van begrijpt nog (is ook niet erg, je zit pas in je 1e jaar!) Een attribute hoort bij een entity, en benader je altijd via de entity, dus weet je bij welke entity een attribute hoort. Klant.Naam, en Personeel.Naam, waarom kun jij ze niet uit elkaar houden?

"Opnamegewenst" dat is de gewenste opname datum. Dat heb ik hernoemd naar "GewOpnamePer" (gewenste opname periode)

Waarom heet dat veld niet GewensteOpnamePeriode? GewOpnamePer, kan ook betekenen gewicht opname personeelslid of weet ik wat. Duidelijkheid voor alles.

[...]
Hmm mja oke maar godsdienst moet worden ingevuld op het wachtlijstformulier.. en dit wordt niet gegeven wanneer een patiënt zich inschrijft in het ziekenhuis (via de verzekering bijv.) .... daarom dácht ik dat het dan niet direct bij de patiënt hoort.. maar nu je het zegt klopt dat wel ja.. één patiënt heeft een godsdienst.

Les 1 van relationeel model ontwerp: de gui komt later, niet eerder. Een formulier is ook een gui. En die is nooit en te nimmer leidend! De grootste fout die je kunt maken is je model modelleren aan de hand van je schermen of formulieren.

Een relationeel model is logisch en je moet je louter focussen op de attributes die je herkent in de realiteit, de relaties tussen de attributes, de groepen die je kunt herkennen over die relaties (die je entities noemt) en de relaties tussen entities.

[...]
Wordt het niet een beetje slordig door alles volledig uit te schrijven?

Geloof me maar, afkortingen gebruiken is niet goed. Duidelijkheid voor alles. Dat beetje extra typewerk is niet iets waar je nadeel van ondervindt, het op een gegeven moment niet meer begrijpen van wat C102BF betekent wel degelijk.

[...]
Ik heb het "medischdossier" gemaakt omdat de bloedgroep enz alleen maar in het medisch dossier wordt vermeld van een patiënt, en het is niet de bedoeling dat iedereen het bloedgroep en het dieet van een bep. patiënt mag zien.

Dat is toch volledig niet relevant voor je model? Je model staat los van de applicatie daarbovenop. Jij gaat dan een applicatie bouwen bovenop dit model en daarin bouw je security voor bepaalde onderdelen in. Niet andersom. Er is geen logische reden om medisch dossier in een aparte tabel te plaatsen. Je kunt bv middels een view in de db ook security creeeren voor fields in je db. Dat is een implementatie aspect en dus volledig niet van belang voor je model, maar wel een voorbeeld dat je model niet beinvloed wordt door een implementatieaspect, sterker nog, niet MAG worden beinvloed door een implementatieaspect.

De entiteit is gemaakt vanwege de rechten. Niet ieder personeelslid mag in het medisch dossier van een patiënt kijken.. daarom is dat apart gemaakt.

is dus onzin.

Of kan ik dat nog toepassen in access zonder een aparte entiteit aan te maken?

In access kun je een query aanmaken die alleen de medischdossier attributes teruggeeft

[Dido]

Je hebt nog steeds de mogelijkheid van meerdere patienten per operatie (ok, je kan rekening houden met siames tweelingen, maar moet dat ) en meerdere patienten per opname... hetgeen ook raar klinkt.

[ripexx]

Als ik zo kijk naar je diagram zie ik al direct een aantal zaken waar ik mijn twijfels over heb.

Wat is het verschil tussen een medicus en personeel? Oftewel moet dat niet in een tabel? Verder bestaat een operaties uit een aantal verrichtingen en zijn aan die verrichtingen een of meerdere personen gekoppeld. Daarnaast is een medicus vaak een vrijgevestigde werknemer in een maatschap? Waar zijn de maatschappen?

Dan het punt van verzekering. Volgens jouw diagram heeft een patient een verzekering en een verzekering een of meerdere patienten. Volgens mij is het zo dat een patient een actieve verzekering heeft en een of meerdere historsiche verzekeringen. Die verzekering heeft een verzekeraar en een verzekeraar heeft duseen of meer verzekeringen. Dus in een bepaalde periode kunnen er dus meerdere patient van een verzekeraar "actief" zijn.

Verzer vraag ik mij af waarom je operatie gebruik? Ik zou kiezen voor behandeling en dat kan zijn, dag behandeling, operatie of iets anders. Een opname is een onderdeel van de behandeling (activiteit/verrichting).

Maar zoals gezegd, schrijf je verbanden eens goed uit:
een patient heeft een of meerdere behandelingen en een behandeling heeft een patient
een patient heeft een medische dossier en een medisch dossier heeft een patient
etc.

en defineer je entiteiten dus:
personeel VS medicus?
opname VS operatie VS behandeling?
etc.

[Frenkpie]

Medicus is geen personeelslid van het ziekenhuis maar bijv. een huisarts oid. die hem naar het ziekenhuis kan doorsturen.

Ik merk gewoon dat ik de verkeerde "techniek" heb aangeleerd.. ik haal het topdown en bottom up normaliseren door elkaar en ik probeer constant de entiteiten aan te maken aan de hand van de formulieren die er gemaakt worden.... dus dat loopt de soep in.

Dit is mijn nieuwe IBS:

Postcode
Postcode
Straatnaam
Plaatsnaam

Patiënt
PatiëntNr
Voorletters
RoepNaam
Achternaam
GebDatum
Huisnr
TelNr
ExtraTelNr
Geslacht
Polisnr
Postcode
MedicusNr
Godsdienst
VerzekeringNr
Bloedgroep
Allergie
Dieet

Personeel
PersNr
Voorletters
RoepNaam
Achternaam
GebDatum
TelNr
Pieper
Email
DatumInDienst
Geslacht
Salaris
FunctieNr
AfdelingNr

Functie
FunctieNr
FunctieNaam
Omschrijving

Medicus
MedicusNr
Voorletters
Achternaam
Huisnr
Telnr
Faxnr
Email
Postcode

Verzekering
VerzekeringNr
BedrijfsNaam
HuisNr
TelNr
FaxNr
Email
Postcode

Afdeling
AfdelingNr
AfdelingNaam
FaxNr
TelNr

Opname
OpnameNr
OpnamePeriode
BerichtVerzonden
Opnamediagnose
OntslagDatum
PatiëntNr
BedNr
PersNr

Operatie
OprNr
OperatieKamerNr
Datum
StartTijd
EindTijd
PatiëntNr

Koppel_PersOpr
PersNr
OprNr
FunctieNr
PersoneelStartTijd
PersoneelEindTijd

Koppel_PatOpr
PatiëntNr
OprNr

Verrichting
VerrichtingNr
Naam
StartTijd
EindTijd
OprNr
PersNr

Wachtbestand
WachtbestandNr
WachtbestandDatum
GewensteOpnamePeriode
PatiëntNr

Ik twijfel alleen nog over de entiteit "wachtbestand" ... want ik moet een wachtlijstformulier maken, waar het datum van de wachtlijstformulier ook wordt vermeld... maar dat kan ik dus niet zomaar onder een andere entiteit zetten (bijv. "Opname") ofwel?


één patiënt kan meerdere operaties ondergaan: 1:m
één patiënt kan meerdere keren worden opgenomen: 1:m
één patiënt heeft één postcode, er kunnen meerdere patiënten zijn met dezelfde postcode: 1:m
Personeelslid kan aanwezig zijn op één operatie, bij een operatie kunnen meerdere personeelsleden aanwezig zijn. :1:m

een operatie kunnen meerdere verrichtingen worden gedaan...

patiént heeft één verzekering en één medicus.


volgensmij klopt ie zo wel aardig...

ik ben nog erg nieuw hierin.. ben pas een week of 12 hiermee in de weer..

[ Voor 68% gewijzigd door Frenkpie op 17-12-2005 18:23 ]

[Max|Burn]

Ben ik de enige die het erg vreemd vind dat

- een patient maar 1 medisch dossier heeft? (er zit een ontslagdatum in..kan je maar 1 maal ontslagen worden?!) Wat als ik weer ziek word!??!? Help!
- medicusnummer bij patient opgenomen zit ipv medisch dossier. De doorverwijzende arts kan verschillen per medisch voorval dus is deze echt niet altijd hetzelfde.

DossierNR?
Koppeltabel DossierNR/PatientNR ?
Bloedgroep hoort bij patient, niet bij het dossier. De bloedgroep zal echt niet veranderen per medisch dossier.. Sterker nog, het zorgt voor onnodige redundantie en inconsistentie. Als men elke keer weer de bloedgroep moet opgeven heb je sneller kans op fouten en krijg je dat iemand ineens een liter van het verkeerde spul erin pompt

Zou ik misschien niet beter "Godsdienst" bij de entiteit "patiënt" kunnen zetten? Ondanks dat deze gegeven op een ander formulier wordt ingevuld kan het toch in een zelfde entiteit worden gezet??

Ja..

Er valt nog echt veel op aan te merken dus ik raad je toch aan om nog dieper in het ontwerp te duiken en nog meer met medestudenten te babbelen Denk a.u.b. niet in forms/schermpjes want de weergave daarin staat wel zo ver af van de database

[ Voor 138% gewijzigd door Max|Burn op 17-12-2005 19:10 ]

[Frenkpie]

ik heb de aanpassingen doorgevoerd... zie m'n voorgaande laatste post..

(ik kan geen nieuwe screenshot maken van het excel bestand en hier posten want ik kan nu niet op m'n homepage inloggen)

Klopt het dat er een Koppeltabel is tussen de entiteit "Operatie" en "Personeel" ?

Meerdere personeelsleden zijn aanwezig bij een operatie en een personeelslid kan meerdere operaties uitvoeren.. niet tegelijk maar KAN wel op één dag bijvoorbeeld... ik weet niet hoe ik dit moet zien...

is dit nu meer op meer? of 1 op meer?

Duidelijk is dat er meer personeelsleden zijn op een operatie.. maar het is niet zo dat één personeelslid meerdere operaties tegelijk kan uitvoeren maar wel meerdere operaties kan uitvoeren op één dag??

En het kan toch ook zijn dat er meerdere patiënten aanwezig zijn bij één operatie (siameese tweeling)?

Dus dan is het tussen operatie en patiënt toch ook meer op meer?

[ Voor 66% gewijzigd door Frenkpie op 17-12-2005 20:10 ]

[ripexx]

Frenkpie schreef op zaterdag 17 december 2005 @ 18:16:
Medicus is geen personeelslid van het ziekenhuis maar bijv. een huisarts oid. die hem naar het ziekenhuis kan doorsturen.

Maar wat als de internist iemand doorstuurt naar de afdeling cardiologie?

Ik merk gewoon dat ik de verkeerde "techniek" heb aangeleerd.. ik haal het topdown en bottom up normaliseren door elkaar en ik probeer constant de entiteiten aan te maken aan de hand van de formulieren die er gemaakt worden.... dus dat loopt de soep in.

Volgens mij kijk je teveel naar formulieren. Dit kan een basis zijn maar het ontwikkelen van een ERP achtig datamodel is niet iets wat je zomaar kan of doet. Daarvoor moet je veel meer van de afzonderlike processen weten om er goed mee om te gaan.

[...]

Het is niet nodig om je hele ontwerp zo neer te zetten, een plaatje met uitleg zeg meer dan een complete lijst van entiteiten. Verder kan ik je een tool als Visio oid aanraden, dat werkt een stuk eenvoudiger dan Excel.

Ik twijfel alleen nog over de entiteit "wachtbestand" ... want ik moet een wachtlijstformulier maken, waar het datum van de wachtlijstformulier ook wordt vermeld... maar dat kan ik dus niet zomaar onder een andere entiteit zetten (bijv. "Opname") ofwel?

Ik snap nog steeds niet waarom je een entiteit opname hebt? Want volgens mij bestaat een behandeling uit een aantal activiteiten/acties/verrichtingen. Want een opname is een mogelijk onderdeel van de behandeling.

één patiënt kan meerdere operaties ondergaan: 1:m
één patiënt kan meerdere keren worden opgenomen: 1:m
één patiënt heeft één postcode, er kunnen meerdere patiënten zijn met dezelfde postcode: 1:m

Let op een patient heeft geen postcode maar een adres, een adres is weer opgebouwd uit een aantal onderdelen. Kan je iemand nu helpen verwerken als deze in Belgie/Duitsland/UK woont?

Personeelslid kan aanwezig zijn op één operatie, bij een operatie kunnen meerdere personeelsleden aanwezig zijn. :1:m

een operatie kunnen meerdere verrichtingen worden gedaan...

Maar wat is de opname dan? Toch ook een verrichting.

patiént heeft één verzekering en één medicus.

Dat is dus niet waar, je hebt een verzekering, maar wat doe je als de opname loopt van 15 dec 2005 tot 15 jan 2006? Danheb je dus te maken met twee verschillende verzekeringen.

volgensmij klopt ie zo wel aardig...

ik ben nog erg nieuw hierin.. ben pas een week of 12 hiermee in de weer..

De vraag die je je moet stellen is hoe ingewikkeld wil ik het maken? Als ik het goed begrijp gaat het om een huiswerkopdracht, want als je hiermee aankomt bij een van onze programmeurs of analysten wordt je echt terug gestuurd. Verder heb ik het vermoeden dat je geen idee hebt wat er allemaal speelt in de zorg sector en wat daarin wel of niet belangrijk is. Opzich niet erg als je uitgaat van een huiswerk opdracht, het ontwikkelen van een logisch relationeel database model kost enige tijd, moeite en ervaring. Want hoe langer ik er over nadenk des te meer opties, mogelijkheden ik zie. Want hoe zit het met operatie kamers? Dit is een hulpmiddel, net zoals instrumenten en apparaten zoals een hart-long-machine of monitor?

[Max|Burn]

En het kan toch ook zijn dat er meerdere patiënten aanwezig zijn bij één operatie (siameese tweeling)?

Beetje flauw maarehm...ik heb zo het idee dat dat 1 patient is Vraag me af hoe ze dat doorgaans plannen in een ziekenhuis.

Nogmaals, let er op dat je je erg bewust moet zijn van hoe je de data op wilt slaan. Hoe het op het scherm komt heeft er echt niets mee te maken. Soms kan het verhelderend werken om alles weer bij mekaar te gooien en dan opnieuw normaliseren...

code:

Koppel_PersOpr
PersNr
OprNr
FunctieNr
PersoneelStartTijd
PersoneelEindTijd

Wat doet FunctieNR daar nu ineens?! Dat is al een foreign key van Personeel...
Zo valt het me ook weer op dat je functienr wel weer apart hebt in een tabel functie (functienr, naam, osmchrijving) wat goed is (net als afdeling)..maar vervolgens doe je dat niet bij bv. OperatiekamerNR ? Je hebt geen tabel operatiekamer dus dit is dus een veldje die mensen met het handje invoeren?..foutgevoelig denk je ook niet.. Een tabel operatiekamerNR / Naam is al genoeg..eventueel kan je bijhouden welke attributen de operatiekamer nog meer heeft. (misschien is de een geschikt voor operatie soort X en de ander voor Y?)

Valt salaris niet buiten de scope van dit systeem? Ik neem aan dat het puur bedoeld is voor de registratie van patienten, operaties, e.d? Het gaat de mensen die er mee gaan werken sowieso geen bal aan wat ik verdien, dus wat doet dat daar?

Zo zijn er nog heel wat dingetjes uit te werken

[ Voor 108% gewijzigd door Max|Burn op 18-12-2005 10:46 ]

[EfBe]

MaxBurn schreef op zaterdag 17 december 2005 @ 18:21:
Ben ik de enige die het erg vreemd vind dat
- een patient maar 1 medisch dossier heeft? (er zit een ontslagdatum in..kan je maar 1 maal ontslagen worden?!) Wat als ik weer ziek word!??!? Help!

Dat is historie, en je kunt dat onderbrengen in ziektehistorie of iets dergelijks. Het punt is dat een medisch dossier een verzamelnaam is van gegevens die bij 1 enkele patient horen en veelal slechts 1 keer aanwezig zijn en niet in entiteit-vorm, maar in attribuutvorm (wat dus tot gevolg heeft dat je ze in de patient entity plaatst). De gegevens die voorgesteld werden in 'medischdossier' hadden allemaal een 1:1 relatie als attribute met patient. Echter, ik ben het met je eens dat wanneer je bv ziektes of 'onderzoeken' gaat opnemen, dan moet je dus daar een entiteit voor definieren en dus volgt daar dan een 1:n relatie uit.

- medicusnummer bij patient opgenomen zit ipv medisch dossier. De doorverwijzende arts kan verschillen per medisch voorval dus is deze echt niet altijd hetzelfde.

Niet gezien, maar moet natuurlijk bij opname. Overigens is 'opname' nu een losstaand iets zo lijkt het, terwijl het eigenlijk bij een onderzoekstraject hoort. Patient komt bij arts en begint een sequence van onderzoeken wat eventueel kan resulteren tot een opname, wat dan onderdeel uitmaakt van een 'behandeling', die een relatie heeft met onderzoek voor een patient etc.

Denk niet te licht over ziekenhuis systemen. verschillende klanten van mij bouwen er een (in verschillende landen) en ik heb nog niet een gezien onder de 800 tabellen. (de grootste had meer dan 1500 tabellen). Aangezien dit een 1e jaars opdracht is, verwacht ik niet dat alles uitgenormaliseerd hoeft te worden tot in de kleinste details

[Frenkpie]

ripexx schreef op zondag 18 december 2005 @ 02:32:

De vraag die je je moet stellen is hoe ingewikkeld wil ik het maken? Als ik het goed begrijp gaat het om een huiswerkopdracht, want als je hiermee aankomt bij een van onze programmeurs of analysten wordt je echt terug gestuurd. Verder heb ik het vermoeden dat je geen idee hebt wat er allemaal speelt in de zorg sector en wat daarin wel of niet belangrijk is. Opzich niet erg als je uitgaat van een huiswerk opdracht, het ontwikkelen van een logisch relationeel database model kost enige tijd, moeite en ervaring. Want hoe langer ik er over nadenk des te meer opties, mogelijkheden ik zie. Want hoe zit het met operatie kamers? Dit is een hulpmiddel, net zoals instrumenten en apparaten zoals een hart-long-machine of monitor?

Het is niet de bedoeling dat we een complete IBS en ERD ontwikkelen voor een ziekenhuis.. het is de bedoeling dat we de punten die in de tekst voorkomen verwerken en hier en daar wat extra dingen bijverzinnen.. maar we hoeven nog niet zo superdiep op in te gaan.. alleen het moet dus wel werkenn in Access zodat ik een operatieformuilier en een wachtlijstformulier kan maken.

we moeten het principe onder de knie krijgen..

[ripexx]

Frenkpie schreef op zondag 18 december 2005 @ 13:02:
[...]
Het is niet de bedoeling dat we een complete IBS en ERD ontwikkelen voor een ziekenhuis.. het is de bedoeling dat we de punten die in de tekst voorkomen verwerken en hier en daar wat extra dingen bijverzinnen.. maar we hoeven nog niet zo superdiep op in te gaan.. alleen het moet dus wel werkenn in Access zodat ik een operatieformuilier en een wachtlijstformulier kan maken.

Dat lijkt me duidelijk Maar vergeet even de zaken zoals Access en formulieren. Want bij een goed opgezet relationeel model kanje ook in Access alle informatie tonen. Daarnaast is er een verschil tussen bij verzinnen en ergens logisch over nadenken. Kijken welke overeenkomsten er tussen entiteiten zijn en etc. Het gaat om een denk proces waarbij er van je wordt verwacht dat je het gedachten proces naar een hoger nivo moet tillen en eigenlijk boven de materie (Access en output) gaat staan.

we moeten het principe onder de knie krijgen..

Klopt, maar dan wil ik nog steeds weten waarom een medicus een andere entiteit is dan personeel. Want beide zijn eigenlijk niet goed Verder vind ik het raar dat een adres bestaat uit postcode, plaats en straatnaam. Terwijl een Nederlands adres uniek te indetificeren is door postcode-huisnummer combinatie. Daarnaast ken het best dat twee patienten op exact hetzelfde adres werken en dat ze ook medicus zijn en werkzaam zijn als personeels lid.

Het gaat zoals EfBe zegt net om een volledig ERD voor een ziekenhuis met alle mogelijk subprocessen. Maar het gaat om de keuzes die je maakt, en dan met name waarom je deze keuzes maakt. Zomaar wat neer zetten schiet niet op. Want zodra jij onderbouwd je keuzes kan verantwoorden en argumenten hebt zonder daar eerst over moet nadenken wil zeggen dat je verschillende opties bekeken hebt, op dat moment zal geen enkele docent jouw een onvoldoende geven, omdat het niet gaat om het resultaat maar het proces. En kan je docent dat niet, dan weet je ook waarom hij les geeft en niet meer in het bedrijfsleven werkt

[Max|Burn]

Dat is historie, en je kunt dat onderbrengen in ziektehistorie of iets dergelijks.

Waar, maar dat lijkt me toch wel gewenst. Ik kan me nog goed herinneren dat dit soort ontwerpkeuzes ook in het eerste jaar wel van je verwacht worden. JUIST bij een ziekenhuis lijkt historie me gewenst

Overigens, mits juist onderbouwd maakt het tijdens je studie niet uit hoever je het allemaal uitwerk/uitdenk. Als je maar goed kan uitleggen waarom je voor keuze A of B bent gegaan. Ik weet nog vrij goed dat de ERD's die ik in me studie moest bouwen juist redelijk ver uitgedacht moesten worden. (voor een eerste jaar dan he ) Geen historie in een ziekenhuissysteem (qua dossiers in dit geval) zou al een flinke deuk in me cijfer gegeven hebben, onderbouwt of niet.

Dat is historie, en je kunt dat onderbrengen in ziektehistorie of iets dergelijks. Het punt is dat een medisch dossier een verzamelnaam is van gegevens die bij 1 enkele patient horen en veelal slechts 1 keer aanwezig zijn en niet in entiteit-vorm, maar in attribuutvorm (wat dus tot gevolg heeft dat je ze in de patient entity plaatst).

Omdat ontslagdatum in het medisch dossier zit opgenomen (in dit geval) denk ik dat de context anders is dan in het voorbeeld dat je zelf aangeeft?

En kan je docent dat niet, dan weet je ook waarom hij les geeft en niet meer in het bedrijfsleven werkt

Ik heb ooit een 4 gekregen voor een database ontwerp + uitwerking in Oracle door zo'n docent. Deze verklaarde dan ook regelmatig dat het bedrijfsleven niets voor hem is. Zelf vond ik het ontwerp juist behoorlijk strak, echter door 1 fout in me ERD ging het van een 10 naar een 4, want het moest perfect ( ? ) Vervolgens een second opinion aangevraagd bij DE database guru van de studie. (nota bene degene waar de eerder genoemde docent in de leer heeft gezeten..)
Deze heeft lang in het bedrijfsleven gezeten en superveel regels code geschreven o.a. voor IBM's database systemen .. <insert kettingprinter debugging verhalen hier> Deze gaf een 8, samen met een giga sneer naar de andere docent met daarin iets van "Een studie is een leertraject, je kan niet verwachten dat iets perfect moet zijn, dat is in het bedrijfsleven ook bijna nooit zo."

[ Voor 142% gewijzigd door Max|Burn op 18-12-2005 17:34 ]

[Frenkpie]

ripexx schreef op zondag 18 december 2005 @ 14:07:

Klopt, maar dan wil ik nog steeds weten waarom een medicus een andere entiteit is dan personeel. Want beide zijn eigenlijk niet goed Verder vind ik het raar dat een adres bestaat uit postcode, plaats en straatnaam. Terwijl een Nederlands adres uniek te indetificeren is door postcode-huisnummer combinatie. Daarnaast ken het best dat twee patienten op exact hetzelfde adres werken en dat ze ook medicus zijn en werkzaam zijn als personeels lid.

Medicus is een extern persoon, die niet werkt in het ziekenhuis is, dus ook geen personeelslid is. Daarom heb ik die apart genomen.


En ik heb postcode apart genomen omdat de straatnaam + woonplaats af te leiden zijn van de postcode..

[ripexx]

Frenkpie schreef op zondag 18 december 2005 @ 19:38:
[...]
Medicus is een extern persoon, die niet werkt in het ziekenhuis is, dus ook geen personeelslid is. Daarom heb ik die apart genomen.

Maar beide zijn toch een persoon? Of iemand personeelslid is, is een kenmerk van de persoon, eigenlijk is het de functie van een persoon bij een organisatie. En wat is patient nu? Toch ook een persoon? Wat maakt een persoon een patient?

En ik heb postcode apart genomen omdat de straatnaam + woonplaats af te leiden zijn van de postcode..

Gezien je IBS snap ik het niet? Jouw IBS voor postcode is als volgt:
Postcode
Postcode
Straatnaam
Plaatsnaam

En dan staat in de tabel patient een FK naar postcode en het huisnummer. Ik zou een adressen tabel maken:
Adres
Straatnaam
Huisnummer
HuisnummerToevoeging
Postcode
Plaats
Provincie
etc.
LandID (FK - > Landen tabel)

Zo heb je een adres maar eenmaal in de database staan. En als je het heel mooi wil doen, wil je namelijk ook een apart postadres kunnen opgeven en verhuzingen kunnen registreren. Als ik nog tijd heb zal ik wel even een ERD neer zetten.

Voorbeeld ERD

Zoals je ziet is er maar een tabel persoon waarin patienten en personeelsleden (Zorgaanbieders) zitten. Ook is een opname in mijn beleving een onderdeel van de behandeling. Wat hierin niet opgenomen is, hoe je omgaat met beschibaarheid van bijvoorbeeld de hulpmiddelen en het personeel. Want voor het personeel moet je werken met planning van ploegendiensten en vakanties. En een OK is maar beperkt beschikbaar etc etc.

[ Voor 21% gewijzigd door ripexx op 18-12-2005 21:47 ]

[Frenkpie]

pfoe dat is een TOTAAL andere uitwerking idd... maarja ik kan met zoiets niet komen aanzetten bij de leraar...

Ik heb m'n IBS en ERD nu laten zien en hij zei dat het zo wel aardig klopte (voor iemand van het 1e jaar athans denk ik ..).

De postcode tabel heb ik afgesplitst op advies van de leraar.. ik kan wel een aparte adres Entity maken.. maar dat is niet zo het punt. dat zit wel goed voorlopig.

Ik zit nu meer te twijfelen over het wachtbestand...
[Het ERD]
[Het IBS]


Kijk het is dus zo dat wanneer een patiënt het ziekenhuis binnenkomt met een verwijzing van de huisarts (medicus). Deze krijgt dan een indicatiekaart en vult thuis daar de persoonlijke gegevens in: godsdienst, gewenste opname etc.

De afdeling opname completeert het formulier met o.a. de gegevens van de indicatie- kaart en het dagstempel, waarna het formulier wordt opgenomen in een bestand (kaartenbak), aan te duiden met wachtbestand.

Dus er is een entiteit wachtbestand zou je dus zeggen...

Maar nu is het dus zo.. met het wachtbestand wordt een opname programma gemaakt.. HOE moet ik dit in het ERD zetten? Het is dus zo dat er voor een patiënt een wachtbestand is, op basis van die ene wacht bestand wordt er één opnameprogramma gemaakt.

dus het is een één op één relatie tussen Opname en wachtbestand?

En een op meer tussen patiënt en wachtbestand?

[ Voor 80% gewijzigd door Frenkpie op 19-12-2005 19:17 ]

[ripexx]

Frenkpie schreef op maandag 19 december 2005 @ 18:43:
pfoe dat is een TOTAAL andere uitwerking idd... maarja ik kan met zoiets niet komen aanzetten bij de leraar...

Klopt, maar dat heeft met de ervaring te maken. Ik zie redelijk veel verschillende modellen van ERP, CRM en mid office systemen en zorg dan dat deze ook te koppelen zijn. Dus dan kom je nog wel eens wat andere structuren tegen. Maar ik hoop dat je begrijpt waarom bepaalde keuzes zijn gemaakt en welke voor maar ook nadelen deze hebben.

Ik heb m'n IBS en ERD nu laten zien en hij zei dat het zo wel aardig klopte (voor iemand van het 1e jaar athans denk ik ..).

Er heeft niemand gezegd dat het fout is maar wat men je wil laten zien is dat er meer is als je wat langer er over nadenkt en niet zomaar een formulier een op een gaat vertalen naar tabellen.

De postcode tabel heb ik afgesplitst op advies van de leraar.. ik kan wel een aparte adres Entity maken.. maar dat is niet zo het punt. dat zit wel goed voorlopig.

Kan maar dat is niet hoe ik het zou implementeren maar dat heeft er mee te maken dat ik ook altijd buitenlandse adressen wil kunnen gebruiken. Als het requirement alleen Nederlandse adressen is leg ik een manager wel uit dat het onzin is.

Ik zit nu meer te twijfelen over het wachtbestand...
[Het ERD]
[Het IBS]


Kijk het is dus zo dat wanneer een patiënt het ziekenhuis binnenkomt met een verwijzing van de huisarts (medicus). Deze krijgt dan een indicatiekaart en vult thuis daar de persoonlijke gegevens in: godsdienst, gewenste opname etc.

De afdeling opname completeert het formulier met o.a. de gegevens van de indicatie- kaart en het dagstempel, waarna het formulier wordt opgenomen in een bestand (kaartenbak), aan te duiden met wachtbestand.

Dus er is een entiteit wachtbestand zou je dus zeggen...

Maar nu is het dus zo.. met het wachtbestand wordt een opname programma gemaakt.. HOE moet ik dit in het ERD zetten? Het is dus zo dat er voor een patiënt een wachtbestand is, op basis van die ene wacht bestand wordt er één opnameprogramma gemaakt.

dus het is een één op één relatie tussen Opname en wachtbestand?

En een op meer tussen patiënt en wachtbestand?

De basis van het wachtbestand is voorraadbeheersysteem. Bij de invoer van een volledig indicatie kaart is het een item voor gebruik. Dus eigenlijk heb je voldoende aan drie verschillende situaties. Kaart verstuurd, ingevulde retour en in opgenomen. Je kan dan heel snel zien hoeveel er in de wachtrij staat door te tellen hoeveel er niet ingevuld retour zijn.

[Frenkpie]

ripexx schreef op maandag 19 december 2005 @ 20:26:
[...]
Klopt, maar dat heeft met de ervaring te maken. Ik zie redelijk veel verschillende modellen van ERP, CRM en mid office systemen en zorg dan dat deze ook te koppelen zijn. Dus dan kom je nog wel eens wat andere structuren tegen. Maar ik hoop dat je begrijpt waarom bepaalde keuzes zijn gemaakt en welke voor maar ook nadelen deze hebben.

ja ik heb (ondanks het vrij complexe structuur) toch enigzins kunnen begrijpen. Maar ik zie zelf ook dat ik nog heel erg veel moet leren, maar dat komt wel met de tijd. Het vak vind ik iig raar genoeg erg leuk

[...]
Er heeft niemand gezegd dat het fout is maar wat men je wil laten zien is dat er meer is als je wat langer er over nadenkt en niet zomaar een formulier een op een gaat vertalen naar tabellen.

Idd, ik dacht (denk?) teveel in de vorm van Formulieren..ik moet volgende keer proberen mezelf van dat af te zetten en volledig te richten op het ontwikkelen van het datamodel. Het kijken naar formulieren heeft me alleen maar in verwarring gebracht.


Bedankt voor je hulp !

[Verwijderd]

EfBe schreef op zaterdag 17 december 2005 @ 12:12:
[...]
Ik zag verder nog iemand met SQL aankomen: een relationeel model is iets dat je gewoon kunt ontwerpen zonder te denken aan SQL, sterker: je MAG niet aan SQL denken, eerst het relationele model, dan je queries, niet andersom. SQL is bedoeld om te werken MET een relationeel model, niet om het te definieren. Je dus laten beinvloeden door 'dit is vast sneller in SQL' is een van de grootste fouten die men maakt bij het definieren van een relationeel model. De andere is overigens 'in tables denken'. Een relationeel model is gerealiseerd in tables, maar niet gedefinieerd in tables.

Het ging mij er niet om of iets sneller is of niet: het was mijn bedoeling om aan te geven dat dat soort informatie achteraf uit de database te halen is & en een meer op meer relatie dus niet per definitie gewenst / noodzakelijk is.