Chapter 9 (continued)

Normalization

-A few definitions:
 Normalization is a formal process o ensure that every attribute is attached to
the entty that ir truly describes
 Technique for structuring your data in order to minimize data redendancy and
inconsistency
 A technique used to make complex databases more efficient by removing all
undesirable redundancy
 Normalization breaks ...
...

-Problems caused by redundancy:

 Storage inefficiencies:
 Wasted storage space
 Processing inefficiencies
 Multiple updates
 Errors
 Requiring multiple updates -> inconsistencies likely

-Normalization is not a mechanic process

-Normalization is basically common sense: each entity/object should record one fact.
Problems arise when independent facts are stored together
...

Example: list of books

-> Voorbeeldrapport

1
 Uitgever

Boek Auteursteam

Auteur
Streepjes aan auteur moeten bij auteursteam

-> ERD dat we al spontaan kunnen ontwikkelen voordat we met de normalisatie

starten

Un-Normalized Entity

Bij een boek met meerdere auteurs, moeten we bij elke auteur alles terug noteren

Remove repeating groups

-> ongenormaliseerd
=> herhalende groep: we moeten meerdere auteurs kunnen opnemen, dus de
herhalende groep zijn dan de auteurs
-> 2 soorten gegevens: persoonsgegevens en gegevens van het boek

Many-to-many = een schrijver kan meerdere boeken schrijven of een boek kan
meerdere schrijvers hebben

2
Alle gegevens van de auteurs gaan we overbrengen in een aparte tabel
-> moet een link kunnen leggen naar de tabel met de boekgegevens => dmv het
BoekID ook op te nemen in de tabel met de persoonsgegevens (moet weten wie
welk boek heeft geschreven)
=> in elke tabel mag elk gegeven maar 1 keer worden opgeslagen

Sleutelvelden:
-Boekgegevens: BoekID
-Persoonsgegevens: gecombineerde sleutel -> BoekID en AuteurID

Velden die niet tot de sleutel behoren -> kijken of die afhankelijk zijn van een
sleutelveld (geheel of deels)

Remove partial dependency

Afhankelijkheid van een sleutelveld afsplitsen

3
Een auteur kan maar 1 keer dat bewuste boek beschrijven
Nieuwe koppeling tussen de 2 tabellen, vorige tabel heeft nu nog enkel sleutelvelden

Remove transitive dependency

Kijken of er nog een afhankelijkheid is tussen niet sleutelvelden

Code (UitgeverID) en Uitgever zijn afhankelijk van elkaar -> splitsen

4
Elke uitgever komt nu nog maar 1 keer voor, maar de UitgeverID komt meerdere
keren voor (aangezien een uitgever meerdere boeken uitgeeft)

The normalized database

Bij een normalisatie mag je geen waarden opnemen, maar abstracte beschrijvingen
We gaan niet normaliseren zoals hierboven, maar op een andere manier

The normalization steps

-The normalisation process is performed on a set of abstract data

-4 normal forms

5
0NF → 1NF → 2NF → 3NF

Step 1: 0NF

= nulde Normal Form

-Collect all data

-Delete all data that are a result of a calculation
-Choose a primary key
-Indicate the repeating groups of data: {...}

Boek = (BoekID, Titel, {AuteurID, AuteurVoornaam, AuteurFamilienaam},

JaarUitgave, UitgeverID, Uitgever)
-> herhalende groep op de gegevens van de auteur

Step 2: 1NF

= de eerste normaal vorm

...
-Determine the primary key in both sets
 The primary key of the first set will be the same as in the 0NF
 The primary key of the second set will usually be a combination of the primary
key from the 0NF together with one or more other fields

Boek = (BoekID, Titel, JaarUitgave, UitgeverID, Uitgever)

Auteursteam = (BoekID, AuteurID, AuteurVoornaam, AuteurFamilienaam)

-> Databank bevindt zich in de eerste normaal vorm, en heeft geen herhalende
groepen meer

Step 3: 2NF

-Search for the non-key

...

!!!No partial dependancy!!!

Boek = (BoekID, Titel, JaarUitgave, UitgeverID, Uitgever)

Auteursteam = (BoekID, AuteurID)
Auteur = (AuteurID, AuteurVoornaam, AuteurFamilienaam)

De niet sleutelvelden (zoals titel, jaaruitgave, ...) zijn nu afhankelijk van hun volledige
sleutel

6
Step 4: 3NF

Each attribute must directly depend on the key!!

Boek = (BoekID, Titel, JaarUitgave, UitgeverID)

Uitgever = (UitgeverID, Uitgever)
Auteursteam = (BoekID, AuteurID)
Auteur = (AuteurID, AuteurVoornaam, AuteurFamilienaam)

Elk rapport apart normaliseren, anders zie je niet welk de herhalende groepen zijn
Van verschillende normalisaties moet je de niet sleutelvelden verdelen over de
sleutelvelden -> na een aantal normalisaties weet je wat bij wat hoort

Example

Reeks deelnemers voor cursussen:

Als je gaat normaliseren, duid dan eerst aan welke gegevens je gaat opnemen (in
rood aangeduid)

Aantal: ... -> mag je niet opnemen in de normalisatie (mogen geen berekeningen in)

Deelnemer Deelname

Module

7
-> In normalisatie moeten we deze 3 terugvinden

Un-Normalized Entity

-> flat-table

Remove repeating groups

8
Link kunnen leggen met de oorspronkelijke tabel (CursusID)
Een persoon kan maar 1 keer inschrijven voor een welbepaalde cursus

Remove partial dependency

Gedeelde afhankelijkheid (Voornaam en Familienaam) afsplitsen in een nieuwe tabel

(Deelnemers)

9
Remove transitive dependency

What if …

Niet sleutelvelden van elkaar afhankelijk? Indien wel -> splitsen

Als je de naam van de gemeente kent wil dat niet zeggen dat je de postcode kent
(Antwerpen heeft verschillende postcodes), als je de postcode kent dan ken je de
naam van de gemeente

1
ERD is fout
-> Entiteiten vinden we terug in de normalisatie maar er is nog 1 sleutelveld meer

Normalization

0NF:
Cursus = (CursusID, Cursus, Datum, {DeelnemerID, Voornaam, Familienaam,
Adres, Postcode, Woonplaats})

1NF:
Cursus = (CursusID, Cursus, Datum)

1
Deelname = (CursusID, DeelnemerID, Voornaam, Familienaam, Adres, Postcode,
Woonplaats)
-> Elke deelnemer een unieke ID geven
-> Combinatie CursusID en DeelnemerID is uniek

2NF:
Cursus = (CursusID, Cursus, Datum)
Deelname = (CursusID, DeelnemerID)
Deelnemer = (DeelnemerID, Voornaam, Familienaam, Adres, Postcode, Woonplaats)

3NF:
Cursus = (CursusID, Cursus, Datum)
Deelname = (CursusID, DeelnemerID)
Deelnemer = (DeelnemerID, Voornaam, Familienaam, Adres, Postcode)
Gemeenten = (Postcode, Woonplaats)

Example: The invoice

1
De gegevens die je gaat opnemen in je normalisatie (in het rood)
Alles wat je kan berekenen moet je schrappen uit de normalisatie (zoals Extended
Price)

Een klant gaat meerdere orders bestellen

Veel-op-veel relatie: meerdere producten maken deel uit van een order, meerdere
orders bestaan uit eenzelfde product

1
Step 1: 0NF

-Collect all data

-Delete all data that are a result of a calculation
-Choose a primary key
-Indicate the repeating groups of data

Invoice = (OrderID, OrderDate, CustomerID, Customer, Address, PostalCode,

City, Country, {ProductID, ProductName, Quantity, UnitPrice})

OR

Customer = (CustomerID, Customer, Address, PostalCode, City, Country, {OrderID,

OrderDate, {ProductID, ProductName, Quantity, UnitPrice}})
-> Herhalende groep op de producten
(De vorm van een rapport kan ook al aangeven welk een herhalende groep kan zijn)

Step 2: 1NF

-Determine the primary key in both sets

 The primary key of the first set will be the same as in the 0NF
 The primary key ...

Invoice = (OrderID, OrderDate, CustomerID, Customer, Address, PostalCode,

City, Country)
InvoiceDetails = (OrderID, ProductID, ProductName, Quantity, UnitPrice)

Step 3: 2NF

!!!No partial dependancy!!!

Invoice = (OrderID, OrderDate, CustomerID, Customer, Address, PostalCode,

City, Country)

1
InvoiceDetails = (OrderID, ProductID, Quantity)
Products = (ProductID, ProductName, UnitPrice)

Step 4: 3NF

!!!Each attribute must directly depend on the key!!!

Invoice = (OrderID, OrderDate, CustomerID)

Customers = (CustomerID, Customer, Address, PostalCode, City, Country)
InvoiceDetails = (OrderID, ProductID, Quantity)
Products = (ProductID, ProductName, UnitPrice)

Database optimalization

UnitPrice hoort bij het product, je hebt die UnitPrice wel degelijk nodig want elk
product heeft een eenheidsprijs
Bij normalisatie: geen UnitPrice op de OrderDetails -> wel bij ERD want het kan zijn
dat een product op een bepaald tijdstip in het jaar goedkoper of duurder is

Example

1
The normalization process is preformed on a set of abstract data

Example: Customer Card

-> Het kan zijn dat je bij de normaisatie teveel tabellen krijgt (zie step 4)

Step 1: 0NF

Purchases = (CustomerID, LastName, FirstName, Address, PostalCode, City,

Phone, {Date, {ArticleID, Description, Price}})
-> Een klant per dag meerdere artikels kopen

Step 2: 1NF

1
Customer = (CustomerID, LastName, FirstName, Address, PostalCode, City,
Phone)
Purchases = (CustomerID, Date)
-> Klant koopt iets op een bepaalde dag, maar de klant meerdere aankopen doen op
1 dag
PurchaserDetails = (CustomerID, Date, ArticleID, Description, Price)

Step 3: 2NF

Customer = (CustomerID, LastName, FirstName, Address, PostalCode, City,

Phone)
Purchases = (CustomerID, Date)
-> Deze tabel schrappen omdat je met PurchaserDetails nog altijd aan alle informatie
kunt komen
PurchaserDetails = (CustomerID, Date, ArticleID)
Articles = (ArticleID, Description, Price)

Step 4: 3NF

Customer = (CustomerID, LastName, FirstName, Address, PostalCode,

Phone)
Purchases = (CustomerID, Date)
PurchaserDetails = (CustomerID, Date, ArticleID)
Articles = (ArticleID, Description, Price)
Cities = (PostalCode, City)

… and in Access

Keys and relationships

...

1
Example

Restrictions:
Each Academic Year, a student can subscribe in only ONE Year of Study

0NF
Student = (StudentID, LastName, FirstName, {AcademicYear, YearOfStudy,
{CourseID, CourseName, Quotation, MaxQuotation}})

1NF
Student = (StudentID, LastName, FirstName)
Contract = (StudentID, AcademicYear, YearOfStudy)
ContractCourses = (StudentID, AcademicYear, CourseID, CourseName, Quotation,
MaxQuotation)

2NF
Student = (StudentID, LastName, FirstName)
Contract = (StudentID, AcademicYear, YearOfStudy)
ContractCourses = (StudentID, AcademicYear, CourseID, Quotation)
Courses = (CourseID, CourseName, MaxQuotation)

3NF
Student = (StudentID, LastName, FirstName)
Contract = (StudentID, AcademicYear, YearOfStudy)
ContractCourses = (StudentID, AcademicYear, CourseID, Quotation)
Courses = (CourseID, CourseName, MaxQuotation)

The Elements of the Analysis Model

1
Data dictionary : gaat elk element beschrijven

State Transition Diagram

-Modelling the dependent model

Data Dictionary

1
Organized listing of all data elements that are
pertinent to the system, with precise, rigorous
definitions so that both user and system analyst
will have a common understanding of inputs,
outputs, components of stores and [even]
intermediate calculations.
(Yourdon, E.N., Modern Structured Analysis, Prentice Hall, 1990)
_ Contains following information
– Name
– Alias
– Where-used/how-used
– Content description
– Supplementary information

Example: a telephone number

– Name: telephone number
– Aliases: none
– Where-used/how-used: assess against set-up (output)
dial phone (input)
– Description:
telephone number = prefix + access number
prefix = [*a four digit number that starts with 0* |
*a five digit number that starts with 0*]
access number = *any size number string*

2
2