paarden database

[B2]

'k verveel me een beetje in de vakantie.
En omdat we bij ons thuis nogal in de paardenfokkerij zitten, leek het me wel leuk om een soort van afstammelingsdatabase te maken. Een soort genealogie maar dan voor paarden dus.

Op zich is het code hiervan geen probleem voor me, alleen ik zat nog even na te denken over de opzet van de database met de verschillende tabellen.
Ik ga de volgende dingen op slaan per record :

• ID-nummer van paard
• Naam
• Vader
• Moeder
• Geb.datum

en eventueel:
• Fokker
• Eigenaar

en op een later tijdstip misschien nog eventuele premies en behaalde certificaten.

M'n bedoeling is dus dat wanneer ik een record selecteer dat automatisch ook de afstammelingen van zo'n paard kan zien, dus ook moeders-vader etc etc.
Is het nodig om dit te normaliseren?

[Delphi32]

Ik neem aan dat je wilt weten hoe je met de relatie paard-vader en paard-moeder moet omgaan.

Dan heb je volgens mij 2 opties:
1. tabel paard(id, vader(=fk naar paard.id), moeder(=fk naar paard.id)
2. tabel paard(id), tabel paardouders(paardid, vaderid, moederid)

Optie 1 heeft het voordeel van simpliciteit qua datamodel, maar het nadeel is dat je opgescheept zit met een self-referencing table. Dat kan je queries wel eens heel ingewikkeld maken.

Optie 2 is complexer (een tabel extra, dus queries worden veel joins enzo), maar heeft als voordeel dat de relatie tussen een paard en zijn ouders duidelijker gedefinieerd is.

Omdat je te maken hebt met een 1:1 relatie tussen paard en zijn ouders, hangt volgens mij de vraag of je voor optie 1 of 2 moet kiezen af van de vraag hoe belangrijk de genealogie is voor het zo volledig mogelijk omschrijven van de entiteit paard. Je geeft aan dat je juist de genealogie wilt beschrijven, dus zou ik voor optie 1 gaan.

Maar ik laat me graag corrigeren door de databasemodelleerfanatici die hier rondlopen

[MrCyber]

Op zaterdag 27 juli 2002 23:03 schreef supergrover het volgende:
'k verveel me een beetje in de vakantie.
En omdat we bij ons thuis nogal in de paardenfokkerij.........

Ik zou het inderdaad normaliseren tot NF3 of 4. Zie [url="http://gathering.tweakers.net/forum/list_messages/556270/1?limit=50"]dit[/url] topic voor een tutorial die redelijk goed en begrijpbaar beschrijft hoe dit te doen.

Iets in de trand van :

code:

Tabel Paard
- ID
- Naam
- Geboortedatum
- Kleur
- Wat je verder exact van dit ene paard wil weten

Tabel Fokker
- ID
- Naam
- Adres
- Wat je nog meer wil weten

Tabel Eigenaar
- ID
- Naam
- Adres
- etc.

Tabel Relaties
- ID
- Paard-ID (uit tabel Paard)
- Fokker-ID (uit tabel Fokker)
- Eigenaar-ID (uit tabel Eigenaar)
- Vader-ID (uit tabel Paard)
- Moeder-ID (uit tabel Paard)

etc.

Uiteraard kun je dit nog veeeeeeeeel verder uitbreiden zoals een tabel voor kleuren, adressen in aparte tabel gooien (waarbij de plaatsnaam weer in een andere tabel zit, etc), etc etc etc.

[dusty]

Op zaterdag 27 juli 2002 23:03 schreef supergrover het volgende:
[..]
Is het nodig om dit te normaliseren?

Ja.

Op zondag 28 juli 2002 01:33 schreef MrCyber het volgende:
[..]

code:

[..]
Tabel Relaties
- ID
- Paard-ID (uit tabel Paard)
- Fokker-ID (uit tabel Fokker)
- Eigenaar-ID (uit tabel Eigenaar)
- Vader-ID (uit tabel Paard)
- Moeder-ID (uit tabel Paard)

Ah, een laten we maar een ID toevoegen in elk tabel. Mag jij mij uitleggen wat die ID daar doet. Integriteit is meteen aangetast, aangezien je nu weer een nieuwe regel moet toevoegen die zorgt dat de combinatie paard-ID en fokker-ID uniek is. Althans, zover ik weet heeft een paard altijd maar een fokker.

Een paar jaar geleden had ik iemand onder me werken als stagiere, die mocht een programma maken voor manege's om deze dingen dus bij te houden, maar ook bij te houden wanneer er inentingen waren, wie de vee-arts voor het paard was, waar hij stond in de stal etc. Eigenlijk dus om gewoon alles bij te houden.

OM dit programma te maken is echter redelijk veel geduld nodig, heb je niet veel tijd ervoor over kan je beter stoppen, heb je wel veel tijd, dan kan je leuke tijden tegemoet zien

[zneek]

Kleine opmerking: Let er op dat je misschien niet altijd de vader en moeder van paard kent. De oplossing die ik tot nu toe zie staan gaan er van uit dat de moeder en vader ook in de database staan. Dat zal misschien niet altijd het geval zijn.

Ik kom later nog wel eff met een ER/D voorstelletje.

[Alarmnummer]

Op zondag 28 juli 2002 16:30 schreef zneek het volgende:
Kleine opmerking: Let er op dat je misschien niet altijd de vader en moeder van paard kent. De oplossing die ik tot nu toe zie staan gaan er van uit dat de moeder en vader ook in de database staan. Dat zal misschien niet altijd het geval zijn.

Ik kom later nog wel eff met een ER/D voorstelletje.

Als je een waarde niet kent, dan kan je er NIL inzetten. Ik kwam er ineens achter dat een database ook meerwaardige logica bezit

[MrCyber]

Ah, een laten we maar een ID toevoegen in elk tabel. Mag jij mij uitleggen wat die ID daar doet. Integriteit is meteen aangetast, aangezien je nu weer een nieuwe regel moet toevoegen die zorgt dat de combinatie paard-ID en fokker-ID uniek is. Althans, zover ik weet heeft een paard altijd maar een fokker.

Mij is altijd verteld om voor elk record in een tabel altijd een uniek ID te hebben. Ik geef ook onmiddelijk toe dat ik nooit een cursus o.i.d. in SQL heb gevolgd, dus kan er helemaal naast zitten. Maar waarom zou je geen uniek ID voor deze tabel doen dan ? (leer graag dingen bij)

[Alarmnummer]

Op zondag 28 juli 2002 17:32 schreef MrCyber het volgende:

[..]

Mij is altijd verteld om voor elk record in een tabel altijd een uniek ID te hebben. Ik geef ook onmiddelijk toe dat ik nooit een cursus o.i.d. in SQL heb gevolgd, dus kan er helemaal naast zitten. Maar waarom zou je geen uniek ID voor deze tabel doen dan ? (leer graag dingen bij)

Je moet zorgen dat je ieder record uniek kan identificeren. Soms doe je dit dus door een id aan te maken, zoals paardId, sofirnr, autonr etc etc. Maar soms doe je dit ook door meerdere velden met elkaar te combineren tot een unieke sleutel.

Verder snap ik niet wat die relatie tabel daar doet. Is relatie ook een bepaalde entiteit? Zo ja (bv een liefdesrelatie tussen 2 personen is een entiteit) dan zou je daar een tabel voor kunnen maken. Zo nee en het zijn relaties tussen tabellen, dan ga je geen tabel aanmaken met daarin alle relaties.

Ik maak verder niet veel databases en er zijn hier genoeg mensen die hier veel meer ervaring in hebben dan ik. Maar het eerst wat ik begin te doen is een ERD maken: het uitzoeken welke entiteiten(paard,eigenaar) er allemaal zijn, welke atributen(naam,leeftijd) ze allemaal hebben, welke relaties die entiteiten met elkaar hebben (is paard van, is vader van), dan bepaal je de cardinaliteiten van die relaties (ieder paard heeft 1 vader, iedere vader heeft 0 of meerdere kinderen, dus een 1 op N relatie) en dan ga je pas beginnen met het maken van tabellen.

[Verwijderd]

M'n vriendin doet dat ook (afstammelingen) voor d'r eigen paard (een Engelse Volbloed). We gebruiken daarvoor nu het programma Brothers Keepers (is eigenlijk voor mensen) maar het werkt goed (na wat gepuzzel).
Daarnaast zijn er tooltjes om de database van BK om te zetten naar HTML, heb daar zelf ook nog wat voor gemaakt.

[zneek]

Eff het verschil tussen tabellen en relaties uitleggen:

Een entiteit is iets wat je in de eerste fase van je systeemontwerp tegenkomt. In die fase dien je absoluut nog niet over tabellen/sleutels enz. na te denken. Niet elke entiteit wordt een tabel en niet elke tabel hoort bij een entiteit. Je kijkt in deze fase puur logisch naar je systeem en denkt voornamelijk vanuit opdrachtgever/gebruiker en de bedrijfsprocessen waarvoor je het systeem ontwerpt. In deze fase praat je ook nog over veel-op-veel relaties. Bijvoorbeeld (entiteiten zijn in CAPS): een KLANT koopt een ARTIKEL, een ARTIKEL kan door meerdere KLANTEN gekocht worden. Dit is dus een veel-op-veel relatie tussen 2 entiteiten.

Ga je nu een stap verder in je ontwerp, en heb je dus alle business logica in je ontwerp verwerkt, dan ga je vanuit de techniek denken. Dat betekent dat je een functie model ontwerpt wat zich vertaalt naar schermen en een database model waarin je entiteiten omzet naar tabellen. In bovenstaand voorbeeld betekent dat dat we 3 tabellen creeeren: KLANT, ARTIKEL en AANSCHAF. De tabel AANSCHAF is een tabel die een relatie uit het entiteit model weergeeft, een zogeheten koppeltabel.

Dit is niet als flame bedoeld, maar ik merk dat de 2 zaken hier door elkaar lopen. Eerst nadenken over de gegevens die je systeem moet bevatten, en hoe de logische samenhang tussen de gegevens is. Dan pas een database model maken.

[edit] Wat Alarmnummer dus eigenlijk al zei, maar dan iets langdradiger uitgelegd

[zneek]

Ow ja, over ID kolommen in tabellen. Op school leer je allerlei technieken en regels over de innerlijke structuur van tabellen. Veldafhankelijkheden enzo. Of zoals ik het noem: BLA BLA BLA.

Zo gauw je bij een automatiseringsbedrijf met een echt systeem bezig gaat is dat het eerste wat je kunt vergeten. Zo gauw de sleutel van een tabel niet duidelijk is introduceren we een uniek ID veld. Pure tijdverspilling om daar over na te gaan denken. Grote automatiseringstools als cool:GEN doen er ook niet moeilijk over, sterker nog, die doen het standaard dacht ik.

Dus, als je zo makkelijk en duidelijk mogelijk wil DB designen zou ik gewoon ID kolommen introduceren als het uitkomt.

[edit] Alarmnummer, ik probeer je niet te flamen, ik spreek puur uit ervaring.

[Alarmnummer]

Op zondag 28 juli 2002 18:54 schreef zneek het volgende:
Alarmnummer, ik probeer je niet te flamen, ik spreek puur uit ervaring.

hehe

Ik heb weinig praktische ervaring met databases nouja.. weinig.. ik ben in ieder geval daar minder dan 10% vd tijd mee bezig, maar theoretisch kan ik me er mee redden

Ik vind het alleen een beetje vreemd om altijd een nieuwe ID als primaire sleutel te gaan introduceren omdat het in sommige gevallen veiliger is om een primaire sleutel uit meerdere velden samen te stellen.

Als je bv een generator tabel hebt, dan krijg je ook 2 velden die samen een primaire sleutel zijn. Een bijkomend voordeel is dat je dan alleen kan garanderen dat bepaalde veld combinaties uniek zijn, en anders kan je die garantie niet geven.

[edit] toch een beetje flamen dus

ps: eigelijk vind ik dat je helemaal niets te maken moet hebben met het relationele database model. Ik ben op dit moment me ook wat aan het verdiepen in or mappings, en het relationele model is leuk voor databases, maar niet voor mensen.

[zneek]

Op zondag 28 juli 2002 19:07 schreef Alarmnummer het volgende:

ps: eigelijk vind ik dat je helemaal niets te maken moet hebben met het relationele database model. Ik ben op dit moment me ook wat aan het verdiepen in or mappings, en het relationele model is leuk voor databases, maar niet voor mensen.

Ik snap niet helemaal wat je daar mee bedoelt, maar je bedoelt het vast goed

Ik kan je wel een voorbeeld geven waarom zo'n samengestelde sleutel onhandig kan zijn (Ik zeg niet onmogelijk, want alles is mogelijk). Neem die tabel die hierboven werd genoemd, die RELATIES tabel. Als je die ID kolom weghaalt en een samengestelde sleutel maakt werkt alles nog prima, sterker nog, zoals jij zegt dwing je dan automatisch af dat bepaalde combinaties uniek zijn. Maar denk je nu eens in dat er een tabel is die gerelateerd is aan RELAITES volgens een 1-op-veel. Dat betekent dat die tabel de volledige PK (samengesteld dus) van RELATIES overneemt als FK. Zie je het probleem? Teken het maar eens uit als niet een 1-op-veel, maar een veel-op-veel aanhangt, die ook weer gerelateerd is aan een tabel.

Wat ik maar probeer te zeggen is dat samengestelde sleutels in tabellen die in de kern van het ontwerp zitten heel veel overhead in de database kunnen veroorzaken omdat de FK in een gerelateerde tabel ook samengesteld word.

[edit] en dan bedoel ik overhead in termen van duidelijkheid, leesbaarheid en gemak van gebruik. 1 ID kolom is simpelere Queries schrijven dan 4 ID kolommen.

[Alarmnummer]

Op zondag 28 juli 2002 19:15 schreef zneek het volgende:

[..]

Ik snap niet helemaal wat je daar mee bedoelt, maar je bedoelt het vast goed

Was een half offtopic praatje waarin een oo programmeur zijn frustraties tov rdbms`en even uitte

Wat ik maar probeer te zeggen is dat samengestelde sleutels in tabellen die in de kern van het ontwerp zitten heel veel overhead in de database kunnen veroorzaken omdat de FK in een gerelateerde tabel ook samengesteld word.

En dat is denk ik het verschil tussen ervaring en theorie Ik kan wel in jouw verhaal komen alhoewel ik nog wel bang ben omdat de db in een inconsistente toestand kan komen (je hebt tenslotte nu minder constraints).

[zneek]

Op zondag 28 juli 2002 19:22 schreef Alarmnummer het volgende:

En dat is denk ik het verschil tussen ervaring en theorie Ik kan wel in jouw verhaal komen alhoewel ik nog wel bang ben omdat de db in een inconsistente toestand kan komen (je hebt tenslotte nu minder constraints).

Dat is waar. Maar los van de PK kun je altijd nog extra constaints definieren. Tis een beetje een kwestie van smaak, en hangt af van de context van de tabel in kwestie. 9 van 10 gevallen maak ik gebruik van een samengestelde sleutel. Alleen als de tabel "in het hart" het systeem zit kies ik voor een aparte ID kolom (maar ook niet altijd). Met alle tabellen die niet ontstaan uit relaties doe ik niet moeilijk, dan pak ik zonder pardon een ID veld. Je zult mij nooit een klant tabel zien bouwen met als PK achternaam/postcode oid. Ook al is het een geldige unieke key volgens de normalisering regels.

[dusty]

Op zondag 28 juli 2002 18:54 schreef zneek het volgende:
Ow ja, over ID kolommen in tabellen. Op school leer je allerlei technieken en regels over de innerlijke structuur van tabellen. Veldafhankelijkheden enzo. Of zoals ik het noem: BLA BLA BLA.
[..]

En daar zit het verschil tussen een goeie database designer en een slechte, omdat het "Werkt" betekent nog niet dat je het niet meer hoeft te doen, omdat bepaalde tools het standaard doen, betekent het nog niet dat het beter is. Hetzelfde geldt voor programmeurs, omdat iets "werkt" betekent nog niet dat het goed geprogrammeerd is.
Gooi je er altijd een extra ID bij kan je extra regels op gaan stellen die de database weer moet controleren, dat kost OOK meer werk, uiteindelijk wordt je database onstabieler, en de kans op vuile data ook groter, ik spreek OOK uit ervaring, alleen dan nog op een extra manier aangezien ik aan een groot data migratie project bezig ben geweest.

Zodra men bij een goede automatiserings bedrijf werkt, weet men ook dat bedrijven vaak toch liever een goed degelijk systeem wilt hebben die op de toekomst is voorbereid dan een database die gewoon werkt.

Uiteraard spreek ik hier compleet uit eigen ervaring en probeer ik ook niet te flamen.

[edit: automatIsering dusty... ]

[zneek]

Op zondag 28 juli 2002 19:29 schreef dusty het volgende:

[..]

En daar zit het verschil tussen een goeie database designer en een slechte, omdat het "Werkt" betekent nog niet dat je het niet meer hoeft te doen, omdat bepaalde tools het standaard doen, betekent het nog niet dat het beter is. Hetzelfde geldt voor programmeurs, omdat iets "werkt" betekent nog niet dat het goed geprogrammeerd is.
Gooi je er altijd een extra ID bij kan je extra regels op gaan stellen die de database weer moet controleren, dat kost OOK meer werk, uiteindelijk wordt je database onstabieler, en de kans op vuile data ook groter, ik spreek OOK uit ervaring, alleen dan nog op een extra manier aangezien ik aan een groot data migratie project bezig ben geweest.

Zodra men bij een goede automateserings bedrijf werkt, weet men ook dat bedrijven vaak toch liever een goed degelijk systeem wilt hebben die op de toekomst is voorbereid dan een database die gewoon werkt.

Uiteraard spreek ik hier compleet uit eigen ervaring en probeer ik ook niet te flamen.

Ik doelde voornamelijk op tabellen waarin je volgense de normalisering regels een bestaande veld combo als sleutel aan zou moeten wijzen. Als je de vorige 3 posts lees zie je dat ik het op gebied van relatie implementerende tabellen niet zomaar iets erin gooi. Duidelijkheid, stabiliteit en ease-of-maintenance zijn ALTIJD een doel bij mij.

[edit] Trouwens de "goede" automatiseringsbedrijven waar ik het over heb zijn o.a. Cap-Gemini/Ernst and Young. Ik zuig deze onzin niet uit mijn duim ofzo

[edit2] Of bedrijven dat willen hangt ook weer van een aantal zaken af. Soms willen bedrijven het wel, maar hebben ze het budget er niet voor. Of .... verzin het maar. Over het algemeen zal het een bedrijf aan zijn reet roesten hoe de je de boel uitvoert, als het maar werkt, en voldoet aan hun randvoorwaarden.

[SuperRembo]

Op zondag 28 juli 2002 16:30 schreef zneek het volgende:
Kleine opmerking: Let er op dat je misschien niet altijd de vader en moeder van paard kent.

Sterker nog, het is zeker dat je nooit van elk paard de vader en moeder kent. Vader en moeder hebben ook weer een vader en moeder die weer....

[zneek]

Op zondag 28 juli 2002 19:59 schreef SuperRembo het volgende:

[..]

Sterker nog, het is zeker dat je nooit van elk paard de vader en moeder kent. Vader en moeder hebben ook weer een vader en moeder die weer....

Daar hebben we iemand die verder nadenkt dan zijn neus lang is.