Normaliseren Datamodellering 2006

Wat is normaliseren? - 1 Data organiseren in tabelvorm, zó dat: er minimale redundantie is update-operaties (toevoegen, wijzigen, verwijderen) eenvoudig zijn uit te voeren records in een tabel te identificeren zijn m.b.v. een unieke sleutel

Redundantie: voorbeeld Suppliers-and-Parts: wat als een leverancier verhuist?

Wat is normaliseren? - 2 Normaliseren: bottom-up datamodelleringstechniek vgl. ER-methode: top-down Omvat een aantal stappen (= normaalvormen): 1NF 2NF 3NF BCNF 4NF 5NF 6NF 1NF 2NF 3NF BCNF 4NF 5NF 6NF 2NF veronderstelt, dat de dataset al in 1NF is, etc.

Normaliseren & DBMS-model Normaliseren in de praktijk gekoppeld aan het relationele database model: tabellen Normaliseren vereist enige basiskennis van het relationele model

Enkele principes RDBMS Relationele database: verzameling tabellen Relationele tabel rechthoekig (dus  spreadsheet tabel!) rijen (records = tuples) en kolommen (velden, attributen) cardinaliteit: aantal rijen graad (degree): aantal kolommen geen vaste ordening rijen en kolommen cel: atomaire waarde Relationele operaties  tabel Tabellen gekoppeld via sleutels primary key (pk) – foreign key (fk)

Functionele afhankelijkheid - 1 S# City P# Qty S# is de determinant van City City is functioneel afhankelijk van S#

Functionele afhankelijkheid - 2 Given a relation R: attribute Y of R is functionally dependent on attribute X in symbols, R.X  R.Y (read: “R.X functionally determines R.Y”) if and only if each X-value in R has associated with it precisely one Y-value in R (at any one time). Attributes X and Y may be composite.

Sleutels Candidate key: unique niet-reduceerbare combinatie van attributen (indien composite) fungeert als determinant voor andere attributen in de tuple Primary key: een candidate key gekozen als identifier Foreign key: kruisverwijzing naar primary key

Normaliseren: document

Normaliseren: NFNF NFNF (of: NF²) = Not in First Normal Form NOTA (Naam, Adres, Plaats, Postcode, ClientNr, NotaNr, NotaDatum, {DierId, DierNaam, Verrichting, Bedrag})

Normaliseren: 1NF Geen repeating groups: NOTA (Naam, Adres, Plaats, Postcode, ClientNr, NotaNr, NotaDatum) NOTA_DIER (NotaNr*, DierID, DierNaam, Verrichting, Bedrag)

Normaliseren: 2NF Elk niet-sleutel attribuut is volledig afhankelijk van de hele primary key: NOTA (Naam, Adres, Plaats, Postcode, ClientNr, NotaNr, NotaDatum) NOTA_DIER (NotaNr*, DierID*, Verrichting, Bedrag) DIER (DierID, DierNaam)

Normaliseren: 3NF Er is geen transitieve afhankelijkheid: als A  B en B  C, dan A  C (transitief) NOTA (ClientNr*, NotaNr, NotaDatum) CLIENT (ClientNr, Naam, Adres, Plaats, Postcode) NOTA_DIER (NotaNr*, DierID*, Verrichting, Bedrag) DIER (DierID, DierNaam)

Maar... zó niet goed Verrichting repeteert! - NFNF had moeten zijn: NOTA (Naam, Adres, Plaats, Postcode, ClientNr, NotaNr, NotaDatum, {DierId, DierNaam, {VerID, Verrichting, Bedrag}}) Vraag: zijn bedragen voor elke verrichting standaard? Of uurtarief? Bovendien is het in dit ontwerp bewerkelijk om alle dieren van een client te achterhalen

Boyce/Codd Normal Form Verschuift aandacht van primaire sleutels naar kandidaat-sleutels: BCNF: elke determinant is een kandidaat-sleutel In de praktijk zijn de meeste relaties in 3NF ook in BCNF

Meer… Rules of Data Normalization [DataModel.org] http://www.datamodel.org/NormalizationRules.html Database eLearning, ch. 4: http://db.grussell.org/ch4.html Normalization [University of Texas]: http://www.utexas.edu/its/windows/database/datamodeling/rm/rm7.html