[ALG]vraag over relaties tussen tabellen

[ErikRo]

Ik wil even iets checken want hoe meer ik erover lees, hoe meer ik er juist van in de war raak

Een 1:1 relatie bestaat als het goed is, niet of nauwelijks in een goed datamodel, las ik hier op GOT.
Euh, ik gebruik ze anders regelmatig bv als er in een record een gebruiker geselecteerd wordt. Die gebruiker staat in een andere tabel en zijn ID sla je op en zo zijn er nog meer keuzes te maken in een record. Dit is volgens mij een 1:1 relatie toch? Eén record in tabel A is gekoppeld aan max één record in table B (gebruikers). De 100 records in tabel A kunnen allemaal aan hetzelfde ID in table B zijn gekoppeld, maar ook dat kan volgens mij met een 1:1 relatie


1:N relatie is geen probleem, 1 record in tabel A (bedrijven) is gekoppeld aan meerdere records in tabel C (ontvangen declaraties)


M:N of N:N, op zich ook geen probleem. Tussentabel benodigd.


N:1 kwam ik een tijdje geleden tegen in een boek over access en hier breek ik al een tijdje mijn hoofd over, al helemaal omdat ik er geen voorbeeld bij kan bedenken. Volgens mij is dit namelijk gelijk aan een N:N relatie en heb je dus hier ook een tussen tabel nodig.

Mijn collega zegt, nee dit is het omgekeerde van een 1:n relatie dus geen tussentabel nodig. Vorige week heb ik nog vol overtuiging mijn betoog de hele dag verdedigd, maar nu twijfel ik weer

Kunnen jullie met jullie ervaring uitsluitsel geven? Want ik heb al een paar websites bezocht, maar het is er helaas niet duidelijker op geworden.
Alvast bedankt!

[ Voor 3% gewijzigd door ErikRo op 07-11-2004 22:56 ]

[Creepy]

ErikRo schreef op 07 november 2004 @ 22:56:
Een 1:1 relatie bestaat als het goed is, niet of nauwelijks in een goed datamodel, las ik hier op GOT.
Euh, ik gebruik ze anders regelmatig bv als er in een record een gebruiker geselecteerd wordt. Die gebruiker staat in een andere tabel en zijn ID sla je op en zo zijn er nog meer keuzes te maken in een record. Dit is volgens mij een 1:1 relatie toch? Eén record in tabel A is gekoppeld aan max één record in table B (gebruikers). De 100 records in tabel A kunnen allemaal aan hetzelfde ID in table B zijn gekoppeld, maar ook dat kan volgens mij met een 1:1 relatie

Als je dit omdraait dan heeft 1 record in table B dus 100 records in table A. Dit is dus geen 1:1 maar een 1:n relatie net als je dat hieronder aangeeft

1:N relatie is geen probleem, 1 record in tabel A (bedrijven) is gekoppeld aan meerdere records in tabel C (ontvangen declaraties)


M:N of N:N, op zich ook geen probleem. Tussentabel benodigd.

N:1 kwam ik een tijdje geleden tegen in een boek over access en hier breek ik al een tijdje mijn hoofd over, al helemaal omdat ik er geen voorbeeld bij kan bedenken. Volgens mij is dit namelijk gelijk aan een N:N relatie en heb je dus hier ook een tussen tabel nodig.

Mijn collega zegt, nee dit is het omgekeerde van een 1:n relatie dus geen tussentabel nodig. Vorige week heb ik nog vol overtuiging mijn betoog de hele dag verdedigd, maar nu twijfel ik weer

Kunnen jullie met jullie ervaring uitsluitsel geven? Want ik heb al een paar websites bezocht, maar het is er helaas niet duidelijker op geworden.
Alvast bedankt!

een 1:n is dus hetzelfde als een n:1. Een 1:1 relatie wil zeggen dat bij 1 record in tabel A maar 1 record in tabel B is, en andersom! Dit komt in de praktijk inderdaad weinig voor.

[NMe]

Natuurlijk is N:1 gewoon het tegenovergestelde van 1:N; immers, je leest het in het Nederlands zo:
Tabel1 verhoudt zich met tabel2 als meer staat tot één. Draai het om en je krijgt: Tabel2 verhoudt zich met tabel1 als één staat tot meer. Duidelijk toch?

Een 1:1 relatie bestaat als het goed is, niet of nauwelijks in een goed datamodel, las ik hier op GOT.
Euh, ik gebruik ze anders regelmatig bv als er in een record een gebruiker geselecteerd wordt. Die gebruiker staat in een andere tabel en zijn ID sla je op en zo zijn er nog meer keuzes te maken in een record. Dit is volgens mij een 1:1 relatie toch?

Nee. 1:1 wil zeggen dat er voor ieder record in de ene tabel maar één record in de andere tabel is. Bijvoorbeeld als je één tabel hebt met alle gebruikers erin, en één tabel met profielgegevens. Bij elke gebruiker hoort één profiel, bij elk profiel hoort één gebruiker. Dit soort dingen kun je beter in één tabel doen, volgens de normalisatieregels. In verband met performance kun je het soms beter niet doen.

[Verwijderd]

Een 1:1 relatie bestaat als het goed is, niet of nauwelijks in een goed datamodel, las ik hier op GOT.
Euh, ik gebruik ze anders regelmatig bv als er in een record een gebruiker geselecteerd wordt. Die gebruiker staat in een andere tabel en zijn ID sla je op en zo zijn er nog meer keuzes te maken in een record. Dit is volgens mij een 1:1 relatie toch? Eén record in tabel A is gekoppeld aan max één record in table B (gebruikers). De 100 records in tabel A kunnen allemaal aan hetzelfde ID in table B zijn gekoppeld, maar ook dat kan volgens mij met een 1:1 relatie

Dit is een N:M Relatie (of N:1) N records in tabel A kunnen verbonden zijn met M records in tabel B

Een 1:1 relatie wordt voornamelijk gebruikt om zaken die functioneel niet echt met elkaar te maken hebben maar wel 1:1 aan elkaar te koppelen zijn te scheiden.
Denk bijvoorbeeld aan een inlog tabel met een UserID en UserName (en groep info en...) waarbij je van elke user ook de NAW gegevens registreert.
Als dit een 1:1 relatie is kun je het allemaal in 1 grote tabel stoppen maar het is neter de data te scheiden in een aparte NAW en User tabel.

En om gelijk maar een misverstand uit de weg te ruimen

Dit soort dingen kun je beter in één tabel doen, volgens de normalisatieregels. In verband met performance kun je het soms beter niet doen.

Niet volgens de Normalisatieregels die ik ooit geleerd heb. Was het niet de vierde normal form die deze scheiding voorschreef? Er is genoeg theorie te vinden die aangeeft waarom de 4e en 5e normal form handig zijn om toch te gebruiken.

[ Voor 17% gewijzigd door Verwijderd op 08-11-2004 00:22 ]

[NMe]

Verwijderd schreef op 08 november 2004 @ 00:18:
Niet volgens de Normalisatieregels die ik ooit geleerd heb. Was het niet de vierde normal form die deze scheiding voorschreef? Er is genoeg theorie te vinden die aangeeft waarom de 4e en 5e normal form handig zijn om toch te gebruiken.

Ik heb zelf nooit gehoord van een nomaalvorm hoger dan de derde (alleen 0-3), dus daar kan ik niet veel over zeggen. Ik zeg ook dat volgens normalisatieregels alles juist in een tabel gezet wordt bij een 1:1 relatie, maar dat ervoor gekozen kan worden vanwege performance om dit niet te doen. Dit bijvoorbeeld omdat je, in jouw voorbeeld, NAW gegevens misschien bijna nooit nodig hebt, en je toch snel wil kunnen zoeken in de gebruikerstabel.

[pjotrk]

1:1 relaties zouden alleen in geval van specialicaties voor kunnen/mogen komen, voornamelijk om null waarden in tabellen te voorkomen. Relationele databases bieden voor specialicaties maar weinig ondersteuning, 2 mogelijke oplossingen hiervoor zijn zoiets:

Oplossing 1 met 1:1 relaties:

code:

table persoon {
  persoon_id (primary key)
  naam
  geboorte_datum
  adres
}

table vaste_werknemer {
  persoon_id (primary key)
  maandloon
  reknr
}
foreign key persoon_id in vaste_werknemer verwijst naar tabel persoon 

table tijdelijke_werknemer {
  persoon_id (primary key)
  uurloon
}
foreign key persoon_id in tijdelijke_werknemer verwijst naar tabel persoon

Voordeel hiervan: geen niet gebruikte velden
Nadeel hiervan: joins nodig om gegevens over vaste/tijdelijkemedewerkers op te halen.

Oplossing 2 in 1 tabel:

code:

table persoon {
  persoon_id (primary key)
  naam
  geboorte_datum
  type_werknemer
  adres
  maandloon
  reknr
  uurloon
}

Voordeel hiervan: is sneller, want geen joins nodig. (uitzonderingen hierop zijn tabellen met ernorm grote tupels, terwijl je meestal alleen maar 1 veld van een tupel wilt hebben)
Nadeel hiervan: veel niet gebruikte velden, dus ruimte verspilling. en betekenis hiervan onduidelijk (wat is de betekenis van een null waarde)

Nadeel bij beide gevallen: constraints nodig om integriteit te waarborgen.


Maar wat meer de vraag:
1:1 relaties kan je makkelijk herkennen door aan elkaar refererende tabellen met exact dezelfde primaire sleutel, welke in 1 tabel dan dus ook de vreemde sleutel is.

"De 100 records in tabel A kunnen allemaal aan hetzelfde ID in table B zijn gekoppeld, maar ook dat kan volgens mij met een 1:1 relatie"
Misschien lijkt de constructie hetzelfde, doordat bij zowel 1:1 als 1:N geen tussentabel nodig is. Maar het verschil zit hem qua implementatie dus in het verschil tussen het soort verwijzende velden (bij 1:1 primaire ->primaire, bij 1:N vreemdesleuten->primaire)

En doordat een primaire sleutel niet meerdere keren in een tabel mag voorkomen is "De 100 records in tabel A kunnen allemaal aan hetzelfde ID in table B zijn gekoppeld" dus bij een 1-1 relatie onmogelijk .


4e en 5e normaalvorm bestaan iig wel, maar vaak ga je niet verder dan BCNF ivm performance: http://www.google.nl/sear...oc+normalisatie+5NV&hl=nl

bij 3NV zou je dus idd voor de 1 tabel vorm gaan.
bij 4NV zou je dus idd voor de opsplitsing gaan.

[ErikRo]

Eén record in tabel A is gekoppeld aan max één record in table B (gebruikers). De 100 records in tabel A kunnen allemaal aan hetzelfde ID in table B zijn gekoppeld

OK heb ik het dan goed begrepen, als ik zeg, dat tabel A een N:1 relatie met B
Tabel B heeft dan weer een 1:N relatie met tabel A.

Ik houd me normaal bezig met hoe een programma eruit moet gaan zien en wat het moet gaan doen. Vandaar mijn gebrekkige DB kennis. Leek me leuk om nu ook eens meteen een datamodel te ontwerpen.

[ Voor 56% gewijzigd door ErikRo op 08-11-2004 08:12 ]

[bille]

oplossing 2 van pjotrk is nog niet volledig genormaliseerd. Namelijk type_werknemer zou een foreign key moeten zijn uit een tabel met werknemer types . Even als Adres eigelijk, want je zou ook nog meerdere personen op 1 adres kunnen hebben..

[ Voor 24% gewijzigd door bille op 08-11-2004 08:23 ]

[Verwijderd]

Hoewel ik het niet anders dan met het verhaal van pjotrk eens kan zijn is dit wel opmerkelijk.

Nadeel hiervan: joins nodig om gegevens over vaste/tijdelijkemedewerkers op te halen.

Elke normalisatiestap zorgt namelijk voor joins. Een ongenormaliseerde platte tabel (met bv NAW gegevens en 10 telefoonnummers) die gesplitst wordt in een tabel met NAW gegevens en een tabel met de telefoonnummers moet ook weer gejoind worden om de data compleet te krijgen.

[pjotrk]

bille schreef op 08 november 2004 @ 08:16:
oplossing 2 van pjotrk is nog niet volledig genormaliseerd. Namelijk type_werknemer zou een foreign key moeten zijn uit een tabel met werknemer types

Zou inprincipe netter zijn, maar meestal dient zo'n typenr ervoor (zoals ik het verteld heb gekregen dan ) dat de dbms kan afleiden op welke manier de dbms de constraints moet leggen. Dit veld is dan vaak een char(1)/bit (ligt eraan of vaste en tijdelijkewerknemer totaal disjunct zijn aan werknemen of niet) met daarin:
- een 'w' indien alleen werknemer, zodat je dmv een constrain dan aan de dbms kan vertellen dat maandloon, reknr, uurloon allemaal null moeten blijven.
- een 't' voor tijdelijk, (maandloon, reknr moeten null blijven)
- een 'v' (uurloon moet null blijven)
Helaas biedt een rdbms eigenlijk geen functionaliteit voor overerving, waardoor je dit soort constraints niet in het datamodel zelf kan vastleggen, en je dus met constraints zelf nog het een en ander zou moeten vastleggen.

Aangezien het aantal mogelijke betekenissen al bij de bouw van het datamodel vast ligt, maak ik hiervan zelf nooit meer dan alleen een char(1) (met een constraint erop) of een bitwaarde. (ligt er dus denk ik aan hoever je wilt doorgaan met normaliseren )

[ErikRo]

Als ik nog een vraag mag stellen, doordat ik nu het 1 op 1 deel begrijp, twijfel ik even over iets anders namelijk "veel op veel"

Dit klopt toch?
Als er onder één record uit tabel A meerdere records uit tabel B kunnen hangen en onder één record uit tabel B meerdere records uit tabel A. Dan heb je een tussentabel nodig “T”. Vanuit A komt er dan een 1 op N relatie naar T en vanuit T een N:1 relatie naar B.


En het viel me op als een soort ezelsbruggetje dat als er een join op de prim key zit dat dat dan automatisch de "1" wordt bij een 1 op V relatie.
En als de join ergens in het middden zit dan is dat automatisch het "veel" deel.

Sorry als deze vragen wat dom overkomen.

[Creepy]

ErikRo schreef op 08 november 2004 @ 09:23:
Als ik nog een vraag mag stellen, doordat ik nu het 1 op 1 deel begrijp, twijfel ik even over iets anders namelijk "veel op veel"

Dit klopt toch?
Als er onder één record uit tabel A meerdere records uit tabel B kunnen hangen en onder één record uit tabel B meerdere records uit tabel A. Dan heb je een tussentabel nodig “T”. Vanuit A komt er dan een 1 op N relatie naar T en vanuit T een N:1 relatie naar B.

Klopt

En het viel me op als een soort ezelsbruggetje dat als er een join op de prim key zit dat dat dan automatisch de "1" wordt bij een 1 op V relatie.
En als de join ergens in het middden zit dan is dat automatisch het "veel" deel.

Klopt ook, want een prim. key komt maar 1 keer voor in de tabel, als het goed is

Sorry als deze vragen wat dom overkomen.

Maakt niet uit, maar een boekje over Databases en normaliseren zou denk ik geen overbodige luxe zijn.

[ Voor 3% gewijzigd door Creepy op 08-11-2004 09:42 ]