Ontwerp tabellen en relationele theorie.

Tabellen zijn het hart van een database. Wanneer het ontwerp van de mank is dan gans de database.

De relationele theorie (gesteld door Dr. E.F.Codd) definieert dat er in een relatie, meestal tabel genoemd, er geen identieke rijen voorkomen.
De primaire sleutel (enkelvoudig of samengesteld) in een tabel moet uniek zijn zodanig dat ook alle rijen van de tabel uniek zijn.

Een belangrijk principe van de relationel theorie is dat rangschikking, de plaats, van een rij in de tabel irrelevant is. .
De enige relatie tussen de rijen is dat deze behoren tot dezelfde tabel en verder mag er tussen de rijen geen enkel ander verband zijn. Met relationele bedoelt men dat de kolommen tot een identieke relatie (familie) behoren.

Het proces strevend naar een ideaal concept van de tabel(len) in een database noemt men normaliseren. Zeer algemeen gesteld is normaliseren het proces waarbij overtollige data, soms herhalende, verwijderd wordt maar zonder verlies informatie.

Dr. E.F.Codd stelde een aantal normalisatie vormen op, waarbij de volgende steeds sterker is dan de voorgaande..
Wanneer een database voldoet aan de derde normalisatie vorm mag men aannemen dat in de meeste gevallen de database probleemloos zal werken .

Het is van het aller grootste belang om ruime aandacht te besteden aan het ontwerpen van de tabellen..
Pas als men zeker is dat alle tabellen voldoen aan de derde normalisatie vorm kan men verder met het ontwerpen van andere objecten zoals, formulieren, queries, modules..enz.

Eerste Normalisatie vorm

Een tabel voldoet aan de eerste normalisatie vorm wanneer :

1. De volgorde van de rijen (records) of kolommen (velden) is irrelevant.
2. Iedere rij (record) van de tabel moet uniek zijn.
3. Een veld mag slechts een waarde bevatten, moet zogenaamd atomisch zijn of mag niet splitsbaar zijn
4. Herhalende kolommen zijn niet toegelaten.

Stel volgende tabel :

De tabel bevat personeelsgegevens, de afdeling waar het personeelslid werkt, in welk beroep, en de kinderen van het personeels lid.
Het is duidelijk dat Kind1, Kind2, Kind3...(en indien één personeelslid 5 kinderen zo hebben moeten er nog bijkomende kolommen Kind4 en Kind5 voorzien worden), herhalende kolommen zijn.
Er moet dus een tabel tblKind voorzien worden. Daar een veld slecht één waarde mag bevaten, moet er een afzonderlijke kolom komen voor KindVNaam, Kind Naam en KindGebDatum :

Van de tabel van de personeels gegevens blijft er over :

Gezien iedere rij uniek moet zijn en dit moet verwezenlijkt moet worden door een primaire sleutel gaan wij na welke kolom(men) kandidaat is (zijn) voor primaire sleutel.
Hier moet men een samengestelde primaire sleutel nemen en wel RR-nr en Afdeling.
Gezien de primaire sleutel geen Null waarde mag bevatten moeten de lege velden RR-nr en Afdeling een waarde hebben. Bovendien moet de kolom Adres op gesplits worden in 4 kolommen, en de kolom Naam in 2 kolommen

Hier valt het op dat er veel overtollige data voorkomt, de naam en adres gegevens worden iedere rij herhaald, het is duidelijk dat er zodoende type(schrijf)-fouten kunnen voorkomen, bovendien wanneer er adres gegevens moeten gewijzigd worden moet dit in verschillende rijen aangepast worden ( stel u een tabel met 1000 rijen voor).
Bovendien behoren de kolommen niet tot dezelfde familie (personeelsgegevens versus afdelingen en jobs. Er moet dus een tabel personeel en een tabel werk komen.

Tabel tblPersoneel:

Tabel tblWerk

De tabellen voldoen nu aan de eerste normalisatie regel.

Begin

---

Tweede Normalisatie vorm.

Het is niet omdat een tabel voldoet aan de eerste normalisatie regel dat de tabel perfect is. De gebruiker kan gemakkelijk foutieve gegevens invoeren wat er toe kan leiden, dat zelf bij een gering aantal anamolieën, de ganse tabel onbetrouwbaar wordt.
Zie gele velden.

De oorzaak van deze data anamoliën zijn de overbodige data , te wijten aan data die herhaald wordt in verschillende rijen. Overbodige data moet geminimaliseerd worden.

Een tabel voldoet aan de tweede normalisatie regel als :

1. Indien de tabel voldoet aan de eerste normalisatie regel en
2. Elk veld in de tabel functioneel afhankelijk is van de Primaire sleutel, en enkel aan de primaire sleutel.
   Bij een enkelvoudige primaire sleutel moeten alle velden functioneel afhankelijk zijn.
   Bij een samengestelde primaire sleutel is het mogelijk dat bepaalde velden afhankelijk zijn van één deel van de primaire sleutel terwijl andere van het andere deel van de primaire sleutel. .
   In dit geval voldoet de tabel niet aan de tweede normalisatie regel. Ook bij een samengestelde primaire sleutel moeten alle velden afhankelijke zijn van de totale primaire sleutel.

De tabel tblpersoneel voldoet aan de tweede normalisatie regel. Als primaire sleutel heeft men het RR-nr en de overige velden zijn functioneel afhankelijk van de primaire sleutel.

Nemen wij de tabel tblKind , deze tabel heeft geen primaire sleutel, Naam komt daar zeker niet voor in aanmerking, zelf een combinatie van Naam en Voornaam niet gezien zelfs dan dubbels niet uitgesloten zijn.
Het RR-nr van het kind daarentegen is wel uniek en komt in aanmerking als Primaire sleutel. Gezien de tabel moet gekoppeld worden aan de tabel personeel moet er een veld zijn die verwijst naar deze tabel, het veld RR-nr van de tabel personeel komt daarvoor in aanmerking.

De tabel kinderen wordt dan :

Beschouwen we de tabel werk :

In principe kunnen wij hier voor een samengestelde primaire sleutel kiezen, namelijk RR-nr en Job (voor zover de bedrijfsregels dit toelaten......), maar zelfs dan is het veld Afdeling niet afhankelijk van de volledige primaire sleutel.

Er is een afhankelijkheid tussen de kolommen Afdeling en Job.
Bovendien kan het theoterisch dat een personeelslid een zelfde job heeft in verschillende afdelingen.

Oplossing met derde normalisatie vorm

Begin

---

Derde Normalisatie vorm.

Een tabel voldoet aan de derde normalisatie vorm indien :

1. De tabel voldoet aan de tweede normalisatie vorm
2. Alle sleutelvelden zijn onafhankelijk van elkaar en zijn enkel en alleen afhankelijk van de primaire sleutel

Een rechtstreeks gevolg van deze regel is dat berekende velden (op basis van andere velden van de tabel), niet voldoen aan deze vorm.

Wij herwerken de tabel tblwerk :

Wij maken een tabel tblAfdeling :

Wij maken een tabel tblJob :

Wij kiezen voor deze tabellen een numerieke Primaire Sleutel, IDAfdeling en IDJob

Vervolgens maken een tabel tblJobAfdeling met de mogelijke combinaties van jobs per afdeling.

En tenslotte de tblWerk die voldoet aan de derde normalisatieregel :

En ziehier het eindresultaat van het normalisatieproces :

Begin

---

Tabellen en Verbanden

Uit het resultaat van bovenstaand normalistie proces onderscheiden wij verschillende mogelijke verbanden tussen tabellen. Belangrijk is dat men bij het leggen van verbanden via de interface van Access kan opteren voor referentiële integriteit. Bij de tabel tblPersoneel en de tabel tblKind betekent dit dat er in de tabel enkel kinderen kunnen voorkomen van een personeelslid van de tblPersoneel.

Eén op veel verband : komt het meest voor, tblPersoneel naar tblKind is daar een voorbeeld van. Het verband wordt gelegd via de primaire sleutel in tblPersoneel RR-nr en wordt gelegd naar de ‘vreemde sleutel’ RR-Nr_Pers .

Eén op één verband : In beide tabellen moet men een primaire sleutel hebben van dezelfde data. Bij tblPersoneel zou dit RR-nr moeten zijn in beide tabellen. Deze techniek wordt toegepast om in de tweede tabel bijvoorbeeld vertrouwelijke informatie te stockeren.

Veel op veel verband. Zoals bijvoorbeeld bij tblAfdeling en tblJob. Men maakt gebruik van een derde tabel waar de primaire sleutels van de andere tabellen ‘vreemde sleutel zijn in de derde tabel.

Begin