Hoe normaliseer ik deze database

[Johnsel]

Hallo vriendjes

Ik heb momenteel een discussie over hoe een bepaalde database genormaliseerd zou moeten worden:

Het gaat om zakken die gekoppelt worden aan een laadbon. Elke bigbag is per definitie uniek. Het enige wat dubbel opgeslagen wordt is het gewicht, puur omdat als je het verder zou afsplitsen je van 1 kolom naar 2 zou gaan.

Elke zak hoort bij 1 laadbon, maar een laadbon heeft meerdere zakken. Een een-op-veel relatie dus.(toch?)
De laadbon is dan weer aan 1 klant gekoppelt, maar een klant heeft ook weer meerdere laadbonnen. Ook weer een-op-veel. (toch?)

Nu is de stelling van mij dat de juiste manier om dit te verwerken in een database is door middel van een extra kolom in de tabel zak en een extra kolom in de tabel laadbon waarin resp. het laadbon nr cq het klantnr komt.

De ander stelt dat hier een aparte koppeltabel voor zou moeten komen, ivm snelheid bij het ophalen van gegevens en het flexibel kunnen aanpassen van de tabellen.

Ik heb hier uiteraard het nodige al over opgezocht. Sommigen beweren dat het wel zou moeten, anderen weer niet.

Moet er dus een koppeltabel bij een een-op-veel relatie komen? Volgens mij maakt het select's allemaal lastiger ivm 3 inner joins ipv 2. Ook wordt het zaknr 2 x opgeslagen. dat je er aan de "1 kant" niet onderuit komt om dit te doen is logisch, maar aan de veel kant kun je het beperken tot een enkele keer.

Wat is hier de juiste manier?

[ Voor 12% gewijzigd door Johnsel op 29-01-2010 12:53 ]

[MueR]

Ik zou niet weten waarom je dit moet normaliseren? Het lijkt mij al een prima database structuur. Het gaat vrij weinig extra moeite kosten voor een database om bij een bon alle bags te zoeken (iets met IN() enzo). Dit verder "optimaliseren" is, voor zover ik uit je verhaal kan halen, overkill.

[Johnsel]

Dus de bovenste structuur is juist?

[Thasquealer]

Normaliseren gaat toch juist vanuit een opdracht?
Dit lijkt meer een resultaat, dus wordt het van de verkeerde kant bekeken.

Edit:
Ik zou denk wat minor aanpassingen doen aan de Laadbon-tabel
Ik weet niet wat er met LaadbonNR wordt bedoelt, maar is dit niet overbodig met een laadbonid?
Tevens zou ik op de tabel Laadbon, een FK BigBagID neerzetten. Dan staat er iig per laadbon welke bigbag er aanwezig is.

Dan kan ook de LaadbonID van de tabel Bigbags af.

[ Voor 58% gewijzigd door Thasquealer op 29-01-2010 13:08 ]

[Woy]

Aangezien je een een-op-veel relatie hebt zie ik de meerwaarde van de extra koppeltabel niet. Immers heeft je BigBagRelations nu een een-op-een relatie met je BigBags, en dus ik zou hem weg laten, behalve als je verwacht dat een big-bag in de toekomst ook bij meerdere laad-bonnen kan gaan horen, zodat je een veel-op-veel relatie krijgt.

[Johnsel]

Dat is precies wat ik dacht.
Rekening houden met toekomstige dingen, prima, maar aangezien het fysiek onmogelijk is om 1 zak op 2 wagens te laden....

edit:

Thasquealer schreef op vrijdag 29 januari 2010 @ 13:02:
Ik zou denk wat minor aanpassingen doen aan de Laadbon-tabel
Ik weet niet wat er met LaadbonNR wordt bedoelt, maar is dit niet overbodig met een laadbonid?
Tevens zou ik op de tabel Laadbon, een FK BigBagID neerzetten. Dan staat er iig per laadbon welke bigbag er aanwezig is.

Dan kan ook de LaadbonID van de tabel Bigbags af.

LaadbonNR is een "custom" nummering en is dus niet gelijk aan het ID

Een laadbon moet een willekeurige hoeveelheid zakken kunnen bevatten, dus het ID (de id's) in de laadbon aangeven mag ook niet.

[ Voor 68% gewijzigd door Johnsel op 29-01-2010 13:18 ]

[VyperX]

Zelfs dan zou het alleen nuttig zijn als je het op korte termijn verwacht. Die BigBagRelations tabel kan je later altijd nog construeren uit de informatie die je op dat moment hebt.

Ook snap ik het argument van extra snelheid bij de tweede optie niet echt... Je moet een extra tabel raadplegen die eigenlijk een 1-op-1 relatie heeft met de BigBags tabel. Of zie ik iets over het hoofd?

[leuk_he]

De bovenste,

De onderste impliceert dat 1 bigbag meer laadbonnen kan hebben, iets wat niet het geval is en je dus in de applicatie(/triggers) weer zou moeten begrenzen.

ivm snelheid bij het ophalen van gegevens

Dat heeft niet heel veel met normaliseren te maken. Dat is naderhand optimaliseren.

het flexibel kunnen aanpassen van de tabellen.

Waarom niet 3 tabbellen:

#tabelid
tabelnaam

#kolumid
@tabelid
kolomnaam
kolomtype

#rijid
@kolomid
waarde.


Heel flexibel, helemaal uitgenormaliseerd

spoiler:

Ik hoop dat je snapt dat je dit laatste dus niet letterlijk moet nemen, het enkel om aan te geven dat een te flexibel database ontwerp niet helpt uiteindelijk.

[Xiphalon]

leuk_he schreef op vrijdag 29 januari 2010 @ 13:13:
Heel flexibel, helemaal uitgenormaliseerd

Alleen als je alle semantiek eruit haalt

[Herr Flicker]

Ik heb met Johnsel hier over ook al gediscussieerd.

Ik denk juist dat een koppel tabel wel de juiste manier is.
Er kunnen immers "meerdere" bigbags in 1 laadbon, hoe wil je anders opgeven dat er meerdere zijn ?
Zonder koppel tabel betekend dus voor elke bigbag in 1 laadbon/reservering dat er een nieuwe rij komt.

Dat lijkt mij juist onlogisch.

Ik zou de bigbags in een aparte tabel zetten, daar de bags toevoegen (als er nieuwe komen).
In de koppeltabel geef je aan wat de keuze is geworden van de bags, en dat wordt weer gekoppeld aan de laadbon/reservering.

[acemoo]

Herr Flicker schreef op vrijdag 29 januari 2010 @ 13:31:
Ik heb met Johnsel hier over ook al gediscussieerd.

Ik denk juist dat een koppel tabel wel de juiste manier is.
Er kunnen immers "meerdere" bigbags in 1 laadbon, hoe wil je anders opgeven dat er meerdere zijn ?
Zonder koppel tabel betekend dus voor elke bigbag in 1 laadbon/reservering dat er een nieuwe rij komt.

Dat lijkt mij juist onlogisch.

Ik zou de bigbags in een aparte tabel zetten, daar de bags toevoegen (als er nieuwe komen).
In de koppeltabel geef je aan wat de keuze is geworden van de bags, en dat wordt weer gekoppeld aan de laadbon/reservering.

Of je hebt de rijen in een koppel tabel, of je hebt ze in de normale tabel, je zullt ze toch krijgen.

[Johnsel]

De laadbon waar de bigbag bij hoort is een eigenschap (attribute) van die ene unieke bigbag, kan niet meerdere waarden bevatten, en hoort daarom volgens de regels van normalisatie dus bij de tabel bigbags.

Citaat wikipedia:
Een relatie is in 2NF als alle attributen die niet in de sleutel zijn opgenomen, afhankelijk zijn van de gehele sleutel (geen gedeeltelijke afhankelijkheid) . Een relatie met één attribuut als sleutel is automatisch in 2NF.

* voldoet aan de eerste normaalvorm
* alle niet-sleutelattributen zijn functioneel totaal afhankelijk van de primaire sleutel.

edit op edit: toch niet, rij != kolom

[ Voor 40% gewijzigd door Johnsel op 29-01-2010 13:43 ]

[MueR]

Herr Flicker schreef op vrijdag 29 januari 2010 @ 13:31:
Ik denk juist dat een koppel tabel wel de juiste manier is.

Wij niet. Per bag heb je maar 1 mogelijkheid, maar 1 laadbon. Het boeit verder totaal niet hoeveel bags er onder een laadbon hangen, die haal je toch snel genoeg op met een simpele query als

SQL:

SELECT bag.BigBagId, bag.Weight, bag.DateTime
FROM BigBag bag
WHERE bag.LaadbonId = 684

Met je koppeltabel ben je nodeloos extra tabellen aan het joinen. Doe dat dus maar niet.

[ppx17]

Herr Flicker schreef op vrijdag 29 januari 2010 @ 13:31:
Ik heb met Johnsel hier over ook al gediscussieerd.

Ik denk juist dat een koppel tabel wel de juiste manier is.
Er kunnen immers "meerdere" bigbags in 1 laadbon, hoe wil je anders opgeven dat er meerdere zijn ?
Zonder koppel tabel betekend dus voor elke bigbag in 1 laadbon/reservering dat er een nieuwe rij komt.

Dat lijkt mij juist onlogisch.

Ik zou de bigbags in een aparte tabel zetten, daar de bags toevoegen (als er nieuwe komen).
In de koppeltabel geef je aan wat de keuze is geworden van de bags, en dat wordt weer gekoppeld aan de laadbon/reservering.

Er stond dat de bigbags uniek zijn (dus per bigbag heb je al een rij) en er staat ook dat elke bigbag op 1 laadbon komt te staan, op welk punt krijg je op deze manier dan dubbele rijen?

Meerdere laadbonnen om aan te koppelen komen er niet en van elke bigbag is al een rij dus daar komt ook niks extra bij.

[NMe]

Herr Flicker schreef op vrijdag 29 januari 2010 @ 13:31:
Ik heb met Johnsel hier over ook al gediscussieerd.

Ik denk juist dat een koppel tabel wel de juiste manier is.
Er kunnen immers "meerdere" bigbags in 1 laadbon, hoe wil je anders opgeven dat er meerdere zijn ?
Zonder koppel tabel betekend dus voor elke bigbag in 1 laadbon/reservering dat er een nieuwe rij komt.

Dat lijkt mij juist onlogisch.

1:N-relaties hebben geen koppeltabel nodig, N:M-relaties wel. Als een bigbag meerdere laadbonnen kan hebben én een laadbon meerdere bigbags dan heb je gelijk, en anders zit je gewoon fout. Ik ben dus bang dat je je beginnersboek over normaliseren er weer even bij mag pakken.

[Herr Flicker]

MueR schreef op vrijdag 29 januari 2010 @ 13:57:
[...]

Wij niet. Per bag heb je maar 1 mogelijkheid, maar 1 laadbon. Het boeit verder totaal niet hoeveel bags er onder een laadbon hangen, die haal je toch snel genoeg op met een simpele query als

SQL:

SELECT bag.BigBagId, bag.Weight, bag.DateTime
FROM BigBag bag
WHERE bag.LaadbonId = 684

Met je koppeltabel ben je nodeloos extra tabellen aan het joinen. Doe dat dus maar niet.

Ik begrijp hem nu..
Ik geef mijn fout toe.