ERD; Categorisatie -> Database

[Verwijderd]

Ik heb 't volgende voorbeeld ERD gemaakt:


Een zijn dus personen, en deze persoon kan óf een docent óf een student zijn. Personen hebben altijd een naam, en afhankelijk van de categorie waartoe ze behoren hebben ze een DatumIndienst, of een Studierichting.

Nu moet dit resulteren in een database. Ik zou graag jullie visie willen hierop. Ik heb op dit moment 2 ideeën:

Alles in 1 tabel:
tblPersoon
--------------
Nummer
Naam
DatumIndienst
Studierichting

Het voordeel is dat ik met 1 select statement alle info kan ophalen uit de tabel. Het nadeel is dat er Null-waarden ontstaan in records.


3 tabellen:
tblPersoon
--------------
Nummer
Naam
(eventueel de kolom 'Categorie' erbij)

tblDocent
-------------
Nummer
DatumIndienst

tblStudent
-------------
Nummer
Studierichting

Het voordeel is dat naam van de tabellen precies aangeeft wat hun inhoud is, dat je geen overbodige records of kolommen hebt (als iemand een student is, is er geen docent record, en dus geen null-waarden)
Het nadeel is dat je bij het ophalen van gegevens eerst data uit de persoon-tabel ophaalt, dan kijkt aan de hand van de categorie-kolom bekijkt of het een docent of student is, en dan de relevante tabel gaat querieën.

Ik zou gaan voor optie 2.

Zijn er nog meer opties, of zie ik dingen over het hoofd?

[Goodielover]

Ik zou voor optie 1 gaan, maar wel een extra typeringsveld opnemen (dus docent/student)
Met behulp van dit veld kan je dan database rules definieren die op de verplichting controleren van de andere velden.

[ Voor 1% gewijzigd door Goodielover op 18-04-2003 23:57 . Reden: type ]

[TheRebell]

Officieel zou je je ERD moeten volgen, dus 3 tables....
Maarja als jij denk/vindt/voelt dat het in bv 1 moet, dan moet je dat doen. Maar qua opbouw en consistentie zou je 3 tables moeten hebben

Je zult er dan wel ff een veldje bij moeten gooien om te zeggen of het een docent of student is of natuurlijk via je primary...

[ Voor 11% gewijzigd door TheRebell op 19-04-2003 00:15 ]

[gorgi_19]

Ik zou ook voor optie 3 gaan; zeker ivm de netheid en de ordelijkheid. Echter, je gaat de mist in met het volgende:

1 student volgt 1 of meer studies. Eveneens geeft een docent les op 1 of meer studies.

De categorie persoonsidee hoeft er niet bij. Immers, deze filter je er al uit met een query op de laatste 2 tabellen.

[Goodielover]

Dit heeft niets te maken met netheid en ordelijkheid.
Performance technisch is het vele malen hadiger om mijn oplosing te kiezen.
Dit (optie 2) is een te ver doorgevoerde normalisatie. Het is niet gebruikelijk om potentiele NULL-velden weg te normaliseren.
Ervaring heeft bewezen dat 1-1 relaties het beste technisch in 1 tabel kunnen komen.
Wel (ik zeg het nogmaals) een type veld opnemen.

[TheRebell]

mjah oke, zeg ook niet dat het fout is. Maar je zou het eigenlijk wel zo moeten doen (optie 2). Of hetgebruik van 1 table sneller is als 3 zal wel meevallen, zeker niet als de db een 'beetje' gevuld wordt...
Het leuke komt idd nog en dat is, zoals gorgi_19 al zegt als een student meerdere richtingen/studies heeft en een docent meerdere vakken geeft

oh en normaliseren doe ie feitelijk als je het nog verder kunt opdelen en als er dubbele gegevens ik voor kunnen komen. Natuurlijk hang het wel een beetje af van de verschillende gegevens die evt bij elkaar horen.. (dwz: dit gaat dus niet altijd op..)

[ Voor 28% gewijzigd door TheRebell op 19-04-2003 00:54 ]

[gorgi_19]

Goodielover schreef op 19 April 2003 @ 00:48:
Dit heeft niets te maken met netheid en ordelijkheid.
Performance technisch is het vele malen hadiger om mijn oplosing te kiezen.
Dit (optie 2) is een te ver doorgevoerde normalisatie. Het is niet gebruikelijk om potentiele NULL-velden weg te normaliseren.
Ervaring heeft bewezen dat 1-1 relaties het beste technisch in 1 tabel kunnen komen.
Wel (ik zeg het nogmaals) een type veld opnemen.

* gorgi_19 is het er niet mee eens.. Er is immers geen enkele relatie tussen een student en een docent, met als uitzondering dat ze beiden een persoon zijn. Hoe wil je dan verder gaan uitbreiden? Nog meer Null velden opnemen? Studentnummer toevoegen, etc? Al deze zaken verwaarloos je. Performance is 1 ding, onderhoudbaarheid van zaken en een hoop onnodige velden is een andere zaak. Het performanceverlies, met goed indexen, vind ik iig verwaarloosbaar t.o.v. de onderhoudbaarheid van code.

Een te ver doorgevoerde vorm van normalisatie zal ik dit zeker niet vinden.

Daarnaast ben ik nog steeds heel benieuwd hoe je in jouw systeem meerdere studies aan een student en meerdere studierichtingen, natuurlijk gekoppeld aan meerdere in diensttredingsdata (ja, dat is logisch, 1/1 begonnen op AA, 1/3 begonnen op CE) gaat behandelen.

Als je jouw systeem wilt doen, dan moet je toch imho nog minimaal 2 tabellen maken; eentje voor docenten, en eentje voor studenten, waarbij je toch een groot aantal velden, waaronder de NAW-gegevens, dubbel zal hebben. De kenmerken van docenten c.q. student verschillen te zeer om ze in 1 tabel op te nemen,a fgezien van de algemene persoonsgegevens. Aangezien naar verwachting de eigenschappen voor beiden erg op elkaar lijken, kan je het net zo goed in 1 tabel stoppen en alleen de 'verschillen' aangeven in de gedetailleerdere tabellen.

[ Voor 38% gewijzigd door gorgi_19 op 19-04-2003 00:59 ]

[IndoBoy]

Geld het niet bij ERD's dat als het een "is een" relatie, dat de eerste tabel, in dit geval dus Persoon, alles over erft?

[.GoO]

IndoBoy schreef op 19 April 2003 @ 00:57:
Geld het niet bij ERD's dat als het een "is een" relatie, dat de eerste tabel, in dit geval dus Persoon, alles over erft?

Ja klopt.

[Verwijderd]

nee, student en docent erven alles van persoon, en hebben zelf nog specifieke attributen die persoon niet heeft

Als de verschillen te groot zijn, of je krijgt te maken met veel n:m relaties zoals gorgi_19 aangeeft, dan ontkomt je er trouwens haast niet aan om het in losse tabellen te zetten. Met het oog op uitbreidbaarheid zou ik zeker in dit geval dan ook kiezen voor meerdere tabellen.

[ Voor 56% gewijzigd door Verwijderd op 19-04-2003 01:03 ]

[Goodielover]

Een RDBMS kent geen overerving.

reactie op gorgi_19:

Als in je model de verschillen vele malen groter zijn dan de overeenkomsten en het feit dat ze allebei een persoon zijn is voor het systeem niet relevant, dan worden het gewoon twee tabellen.
Je kan natuurlijk ook altijd één of meerdere views definieren in welke situatie dan ook om de tabel persoon, docent en student te simuleren.

Motto: er is niet een eenduidig antwoord te geven. Je kan voor beide oplossingen argumenten vinden om ze te staven of onderuit te halen.

Succes ermee.

[gorgi_19]

Goodielover schreef op 19 April 2003 @ 01:04:
Als in je model de verschillen vele malen groter zijn dan de overeenkomsten en het feit dat ze allebei een persoon zijn is voor het systeem niet relevant, dan worden het gewoon twee tabellen.
Je kan natuurlijk ook altijd één of meerdere views definieren in welke situatie dan ook om de tabel persoon, docent en student te simuleren.

Mijn punt van kritiek, en dat neem je ook niet weg met bovenstaande post, is dat je je op voorhand al helemaal vast legt. In jouw geval kan ik dus moeilijk de structuur uitbreiden, zonder een complete redesign te doen (je hebt het hier zelf over 2 tabellen, als dat nodig is, in plaats van 1 uit een eerdere post. Per definitie verminderd dit je flexibiliteit).

Views zijn, zoals door jou voorgesteld ranzig; je werkt om het probleem heen. Je ontwerpt een database en je wilt niet een goede structuur er uit halen door middel van een view; een goede structuur moet er zijn. Een view kan je idd creeeren als bijvoorbeeld DocentView of StudentView, waarin je al een join tussen de tabellen hebt gelegd.

Puur strict gezien zijn beiden een persoon, met beiden hun eigen kenmerken welke beide hebben.. Iedere docent en student heeft NAW gegevens. Iedere docent of student heeft een geb. datum. En beiden moeten opgeslagen worden; deze kan dan in een aparte tabel gestopt worden, want zijn uniek voor een docent of student (in de zin van: een student heeft ze wel en een docent niet)

Aangezien dit laatste betwistbaar kan zijn, is het verdedigbaar om geen tabel persoon te maken, maar deze gelijk op te delen in docent en student. 1 tabel is echter naar mijn idee niet verdedigbaar.

[ Voor 13% gewijzigd door gorgi_19 op 19-04-2003 01:15 ]

[bille]

zoals al eerder werd gezegd: in princiepe moet je gewoon de standaard regels volgen.. dat betekent dat je een van alle drie de objecten een tabel maakt. Tussen de tabel "student" en "persoon" zit uiteraard een 1 op 1 relatie (ik neem aan dat je beide uniek identificeert? persoon met? sofi? en student met studentnr o.i.d.). Je zal dus in de tabel "student" de PK van persoon op moeten nemen.. en dat geldt ook voor "docent" .. die zal dus ook een kolom met de PK van "persoon" moeten hebben. dus:

tbl_persoon
----------
Prsn_Nummer [PK]
Prsn_Naam

tbl_student
-----------------
nummer [PK]
Prsn_Nummer[FK]
Studierichting

tbl_docent
-----------------
nummer [PK]
Prsn_Nummer[FK]
DatumIndienst

zoiets dus.. helpt je dat iets? Je zult in de businesslogica van je applicatie moeten gaan afdwingen dat de PK van tbl_persoon niet in zowel tbl_docent én tbl_student staat.

[gorgi_19]

Waarom kan een student niet student EN docent zijn? Het is in praktijk mogelijk. Als je deze zaken (personeel en studenten) koppelt in 1 database, moet je dit ook mogelijk maken, aangezien het in praktijk ook voor kan komen.

Verder ben ik het niet eens met studierichting; een student volgt 1 of meer studierichtingen. Hierdoor zou er eik ook een 1:n relatie tussen student en studierichting moeten bestaan.

[RobIII]

bille schreef op 19 April 2003 @ 01:22:
<knip>
zoiets dus.. helpt je dat iets? Je zult in de businesslogica van je applicatie moeten gaan afdwingen dat de PK van tbl_persoon niet in zowel tbl_docent én tbl_student staat.

Kleine noot: Ik kan me voorstellen dat iemand Docent en leerling is. Ik zou dat niet TE hard afdwingen (eerder waarschuwen ofzo).

edit:

Damn you gorgi_19

[ Voor 7% gewijzigd door RobIII op 19-04-2003 01:29 ]

[whoami]

Als je zeker weet dat een student slechts 1 studierichting tegelijk kan doen, zou ik gaan voor optie 1.
Als je echter wilt weten welke studierichtingen een bepaalde student allemaal gevolgd heeft, dan zul je voor optie 2 moeten gaan.

Als je gaat voor optie1, dan zou ik zeker nog een extra veld in de DB zetten die aangeeft of die persoon een student of een docent is.

Goodielover schreef op 19 April 2003 @ 01:04:
Een RDBMS kent geen overerving.

Inderdaad, maar er zijn wel verschillende mogelijkheden om inheritance voor te stellen in een RDBMS.
Optie 2 van de topicstarter is er een van.
Wat je ook kunt doen om inheritance voor te stellen is; in dit geval; je beperken tot 2 tabellen. Een tabel student en een tabel docent.
Dan heb je:

code:

tblDocent : nummer, naam, datumindienst
tblStudent: nummer, naam, studierichting

De opmerkingen van gorgi_19 en RobIII over het en student, en docent zijn, zal je ook in overweging moeten nemen.

[Verwijderd]

Thanks voor alle reacties.

Ok, wat mij betreft wordt er gekozen voor aparte 3 aparte tabellen. En ik heb dat in het plaatje hieronder verder uitgewerkt:



De opmerking dat een Persoon zowel Docent als Student kan zijn klopt inderdaad. En daar wil ik even op doorgaan.
Het is namelijk zo dat er moet worden bijgehouden wanneer een Docent of Student wordt ingevoerd en door wie dit gebeurt (velden InvoerDatum en InvoerUserID). En ook moet de datum van de laatste wijziging en door wie dit gebeurt worden bijgehouden (velden WijzigDatum en WijzigUserID).

Ik kan dit ook best in de persoon-tabel gaan bijhouden, alleen dan moet je dus voor iedere categorie velden gaan aanmaken, zoals te zien in dit figuur:




Verder zou je natuurlijk ook nog een extra tabel kunnen aanmaken waarin invoerdatums en wijzigdatums worden bijgehouden, alleen dan loop je weer tegen de moeilijkheid aan dat je in die Logging-tabel één veld hebt voor de FK (DocentNr of StudentNr) en dat die eigenlijk best een heel ander datatype kunnen hebben (???). Zie dit figuur:

Dit is aan de andere kant ook wel een interessante optie volgens mij, omdat je hier een veel uitgebreidere logging mee kunt bijhouden dan alleen de laatste wijziging aan een record.


(Ik snap trouwens niet waarom dit soort vraagstukken niet in mijn databaseboek staat "Database systemen voor de praktijk", J.A.Vandenbulcke wat ik moest aanschaffen tijdens mijn informatica opleiding)

Ik zou zelf voor de eerste optie (plaatje1) kiezen. (Trouwens, dit is geen opdracht waar ik nu mee bezig ben, alleen een soort brainstorm van mezelf, waar ik jullie ook graag in wil betrekken. Ik vind het namelijk wel leuk om dit uit te zoeken.)

[whoami]

Ik zou ook voor de eerste of derde optie gaan met dit verschil dat ik de tabel Persoon zou weglaten.
Ik vind het een beetje overhead om een extra tabel bij te houden, aangezien student en docent blijkbaar toch maar 1 gemeenschappelijk veld hebben, nl. naam. (Afgezien van de primary key dan).

[Verwijderd]

Ik ben het met je eens dat het nogal overkill is om voor 1 veld een extra Persoon-tabel aan te maken. In een real-life situatie zal de Persoon-tabel waarschijnlijk nog meer informatie bevatten. De kolom 'Naam' wordt bijvoorbeeld opgesplitst in Voornaam, Achternaam, Tussenvoegsels, verder komen er Adresgegevens in te staan. En misschien nog wel een hoop meer.

Er zal in zo'n situatie goed gekeken moeten worden of het zinvol is om daarvoor een Persoon-tabel te maken, of dat die informatie toch beter opgeslagen kan worden in de Docent- en Student-tabel.

[bille]

lol toch leuk als je suggestie wordt opgevolgd .. egotripppppp

[Goodielover]

Het maken van een model is nooit goed of fout, maar erg afhankelijk van wat je er mee wilt.
Bedenk maar eens op hoeveel manieren je partner (als in huwelijk) kan modelleren?
Als het voor jouw essentieel is dat je personen onderkent, dan is dus een extra tabel niet overkill. Als je bij een vrouw ook de meisjesnaam wilt opnemen ga je dan kiezen voor twee tabellen, één voor mannen en één voor vrouwen. Zeg het maar!

Nogmaals dus: Het goede antwoord bestaat alleen als je al een complete redenering erbij geeft wat je met dit model van de werkelijkheid wilt.

Sorry het is niet anders.