Anoniem: 25556 schreef op dinsdag 18 januari 2005 @ 16:40:
Nofi hoor, maar sinds wanneer moet de PK een betekenis hebben? Dat kan ik nergens in mijn boeken over normaliseren terugvinden?
In 'koppetabellen' (tabellen ontstaan door n:m relaties) is geen ID veld nodig, maar in alle andere tabellen is het domweg het verstandigst om een van de data onafhankelijk (autogenummerd) ID veld te gebruiken, en die ook als PK te zetten, temeer daar je 'm in andere tabellen als FK zult gebruiken. Niets in alle regels van normalisatie zegt dat dit niet mag, of onverstandig is.
Verder zie ik hierboven ergens gezegd worden dat autonummering redundantie in de hand werkt, die mag mij uitgelegd worden, want dat verband zie ik echt niet.
Als laatste.. een mierenneukpuntje, maar waarom zou je de tabelnaam nog weer laten terugkomen in alle veldnamen?
het MOET geen betekenis hebben, maar wanneer het KAN is het mooi meegenomen en aangeraden om dit te doen.
dat je een ID nodig hebt in koppeltabellen zeg ik niet.
zomaar een ID als PK 'OMDAT JE HEM VANUIT ANDERE TABELLEN ALS FK WIL GEBRUIKEN' is volgens mij nog altijd ronduit idioot. ID is en blijft een candidate key en kan daardoor evengoed, zelfs zonder dat ie PK is voor dat doel gebruikt worden.
ik laat helemaal niet de tabelnaam in veldnamen terug komen. enkel bij een foreign key kan dit handig zijn: klantID is foreign key in tabel aankopen bvb.
ik typ even rechtstreeks over uit m'n cursus:
- superkey: een verzameling van 1 of meer attributen die uniek is voor elke rij
- candidate key: een minimale/irreducible superkey
- primary key: de kandidaatsleutel gekozen om rijen uniek te identificeren. hoewel er meerdere candidta sleutels kunnen zijn is er maar 1 de primaire.
- verwijssleutel: verzameling van 1 of meer attributen verwijzend naar een kandidaatsleutel van een tabel. is zelf GEEN sleutel maar verwijst naar een sleutel
Keuze van primaire sleutels:
- kies een sleutel die een werkelijke betekenis heeft (dit zal als een vloek klinken bij nogal wat DBA's)
- voer dus niet zomaar een nummering in om een primaire sleutel te hebben (tenzij deze nummering ook in de werkelijkheid wordt doorgedrukt)
- je kunt altijd een sleutel vooropstellen, desnoods alle attributen samen.
- een artificiele sleutel vermijd het gebruik van samengestelde verwijssleutels en maakt sleutellengte data-anofhankelijk
- een artificiele sleutel alleen lost het uniciteitsprobleem niet op maar verlegt het (een artificiele kandidaatsleutel kan echter nuttig zijn)
- het legendarische veld ID en types zoals autonummering zijn nuttig maar gevaarlijk voor de onwetende
- neem de meest waarschijnlijke sleutel
1ste normaalvorm (slechts gedeeltelijk)
- attributen zijn atomair
2de normaalvorm (slechts gedeeltelijk)
- een relatie staat in 2NF als 1NF voldaan is en niet-sleutel attributen volledige afhankelijk zijn van de primaire sleutel. of maw elk niet-sleutel attribuut is Volledige FA van een kandidaatsleutel)
- Het is duidelijk dat 2NF automatisch voldaan is wanneer de primaire sleutel enkelvoudig is (singleton). helaas is dit vaak een verdediging van de mensen die artificiele primaire sleutels maken. noem het eerder een slecht excuus. of nog, meestal/vaak zijn primaire sleutels niet enkelvoudig.
--- tot daar de theorie.
Jij wou normaliseren. volgens mijn cursus staat jouw DB nog niet eens in de eerste normaalvorm. Daarvoor moet je zoals ik zei het veld "naam" splitsen in "voornaam" en "familienaam".
om in 2de normaalvorm te geraken, zet je ID als candidate key op autonummering en kies je een goeie primary key.
Anoniem: 127584 schreef op woensdag 19 januari 2005 @ 00:39:
Langzaam begint het wat duidelijker te worden. Zelfs Highway wil dus
wel graag een ID veld erbij gooien om te koppelen, maar dat veld niet als PK gebruiken. Hij vindt dat de PK een betekenis moet hebben.
Dat zo'n ontwerp uiteindelijk niet veel anders is dan een PK op het autoinc veld en een business rule op de combi van Voornaam, Achternaam of Chassisnummer of Kenteken lijkt nog niet helemaal doorgedrongen te zijn. Persoonlijk vind ik dat je Business rules (Uniekheid van het kenteken) moet controleren je door unique constraints of indexen aan te maken en dus niet via de PK. Business rules kunnen namelijk in de loop der tijd veranderen. Iets wat in een bepaalde situatie uniek is hoeft dat later niet meer te zijn.
Ook blijf ik zijn voorbeeld met namen niet snappen. De tabel
code:
1
2
3
4
| ID Voornaam Achternaam Adres Tel
1 Jan Klaasen Klaasenlaan 1 +311234567890
2 Jan Klaasen Klaasenlaan 1 +311234567890
3 Jan Klaasen Pietenlaan 2 +311234567891 |
hoeft namelijk geen fouten te bevatten. Het kan toevallig zo zijn dat de familie klaasen nogal honkvast is en niet echt creatief met de naamgeving. Highway noemt dat "extreme gevallen" maar mijn ervaring is dat in een grote database er altijd een paar "extreme gevallen" zullen zijn. Een PK met Voornaam, Achernaam, Tel hoeft dus geen uniek record op te leveren terwijl je dat op het eerste gezicht wel zou verwachten. Een goed database ontwerp is daar op voorbereid. Een slecht ontwerp niet.
Maar goed het enige voordeel van zijn manier van werken kan zijn dat bepaalde databases de tabel standaard in de volgorde van de PK opslaan zodat het zoeken op de PK sneller is dan op een secundaire key. De meeste goede databases laten je echter kiezen welke key je daarvoor wilt gebruiken. Vaak wil je daar dus de key voor gebruiken die koppelt naar child tabellen. Die link zul je waarschijnlijk het meest gebruiken en daar haal je dus de meeste performance winst.
Dit is echter eigenlijk helemaal niet relevant in deze discussie want het aanpassen van het ontwerp aan de gebruikte database valt bij mij onder optimalisatie niet onder normaliseren. Als PK wil ik dus iets zien wat op basis van het DB design uniek
moet zijn. Niet iets dat enkel bij correcte invoer uniek is en waarvan de uniekheid door een externe partij bepaald wordt.
check aub nog eens mijn nick...
er is wel een wezenlijk verschil.
business rules kunnnen idd veranderen, maar als je die business rule kan veranderen, kun je evengoed je PK veranderen. Want als je met problemen komt te zitten in je data door de gewijzigde business rule, dan heb je die toch in beide gevallen. Het is niet zo dat een PK door de tijd constant is. Morgen kan idd mijn PK anders zijn.
wat jij geeft is een uitvlucht en pure luiheid.
daarenboven heb jij minstens 1 constraint/rule meer als ik wat (in beperkte mate) de performantie niet ten goede komt.
dat de data in de tabel die jij geeft niet per se fout moet zijn is juist, maar het geval wat ik gaf was bedoeld om aan te tonen dat bij slecht ontwerp 1 persoon meerdere malen in dezelfde database kan zitten, terwijl dit helemaal niet zou mogen. Daarom is normalisatie nodig.
En die extreme gevallen: als de kans 1/100000 is dat je zo'n extreem geval tegenkomt, dan is het de vraag of het echt nodig is om er rekening mee te houden. In sommige situaties is het nodig, en kun je dit oplossen door de PK uit te breiden.
ik praat over PK's, niet over indexen. In gelijk welk ontwerp kun je toch indexen toevoegen 'zoveel je wilt'. performantie voordeel daardoor is dus uitgesloten.
ik quote dit nog even extra:
Als PK wil ik dus iets zien wat op basis van het DB design uniek moet zijn. Niet iets dat enkel bij correcte invoer uniek is en waarvan de uniekheid door een externe partij bepaald wordt.
een ID met autonummering is idd ALTIJD uniek. Maar dit is enkel en alleen de easy-way om "fuck you" te zeggen tegen de personen die later iets met jouw DB moeten aanvangen.
En dat het deels steunt op correcte invoer is net een surplus.
als we even terug het geval nemen van 1 persoon die meerdere keren voorkomt in een DB
dan heb jij meer problemen als ik:
code:
1
2
3
4
5
6
7
8
9
10
11
12
| ID Naam
123 Jan met de Pet
253 met de Pet Jan
346 met de Pet, Jan
546 met de Pet, Jean
567 Jean met de Pet
874 met de Pet Jean
tegenover
ID familienaam voornaam
123 met de Pet Jan
546 met de Pet Jean |
/u/26260/icon.png?f=community){kind=icon}
:
/u/661/crop5cca8f904dc18_cropped.png?f=community)
:strip_exif()/u/72391/Pinky_and_the_Brain_-_Brain.gif?f=community)
/u/126369/Daos2.png?f=community)
/u/44276/got_icon5.png?f=community)
:strip_exif()/u/26373/anim4.gif?f=community)
:strip_icc():strip_exif()/u/69009/eend.jpg?f=community)
/u/24411/img.png?f=community)