DTA - PowerPoint-presentatie

Principes van databases
Relationele databases:
logisch databaseontwerp
Hoofdstuk 5
1
Overzicht
• Omzetting van een EER-diagram
• Normalisatie
• Denormalisatie
2
Overzicht
• Omzetting van een EER-diagram
• Normalisatie
• Denormalisatie
3
Omzetting van een EER-diagram
• Overzicht
informatievergaring
conceptueel
ontwerp
databasemodelonafhankelijk
logisch
ontwerp
dbmsonafhankelijk
fysieke
ontwerp
• domeinanalyse
• functionele analyse
• behoefteanalyse
• conceptueel model
(bijvoorbeeld EER-diagram)
• functionele beschrijving
• logisch databaseschema
(bijvoorbeeld relationeel)
• gedragspecificaties
• DDL-scripts
• implementatie van gedrag
4
Omzetting van een EER-diagram
conceptueel relationeel
databaseontwerp
EER-diagram
functionele
beschrijvingen
reverse
engineering
logisch relationeel
databaseontwerp
relationeel
databaseschema
gedragspecificaties
Vb. Functionele beschrijving: Controleren bij invoer leeftijd
5
Omzetting van een EER-diagram
• Het omzettingsalgoritme voor relationele
databases
9 stappen:
1) Omzetting van reguliere entiteittypes
2) Omzetting van zwakke entiteittypes
3) Omzetting van specialisaties en generalisaties
4) Omzetting van categorieën
5) Omzetting van binaire 1:1 relatietypes
6) Omzetting van binaire 1:N relatietypes
7) Omzetting van binaire M:N relatietypes
8) Omzetting van meerwaardige attributen
9) Omzetting van n-aire relatietypes waarbij n>2
6
Omzetting van een EER-diagram
• Het omzettingsalgoritme voor relationele
databases
Automatiseren m.b.v. CASE-tools
• ER-Studio (Embarcado Technologies)
• Designer (Oracle)
• Enterprise Application Suite (Sybase)
7
Omzetting van een EER-diagram
• Aanmaken van gedragspecificatie
• CASE-tools bieden ondersteuning
• Omzetten van functionele beschrijvingen:
gebruik database faciliteiten!
• Alternatieve sleutels
Afdwingen van uniciteit
• Integriteitsrestricties
Afdwingen van beperkingen (vb. Sterftejaar >= Geboortejaar)
• Stored procedures
•Triggers
8
Afdwingen van ‘Businessregels’ = voorwaarden
waar de data aan moet voldoen
(vb. Heeft de docent alle cijfers ingevoerd?)
Overzicht
• Omzetting van een EER-diagram
• Normalisatie
• Denormalisatie
9
Normalisatie
• Wat is normaliseren?
– Normaalvormen zijn ingevoerd voor diagnose van
dB’s = Kwaliteitsnorm
– Kwaliteitsnorm van de basisrelatie
Hoe hoger de normaalvorm, hoe minder problemen
– Verhogen normaalvorm m.b.v. normalisatieproces
Basisrelatie opsplitsen en omzetten
– Database ontwerp d.m.v. normalisatieproces
• Eenvoudige dB: alle attributen samennemen in één basisrelatie
• Geen EER-diagram nodig
10
Normalisatie
• Probleemstelling bij slecht opgebouwde
relaties
– Overtollige dataopslag
– Update-afwijkingen
– Dataverlies
11
Normalisatie
Tabel Schilderij
S_ID:
Titel:
char(3) varchar
primaire sleutel = {S_ID}
Periode: Naam:
integer
varchar
Geboren:
integer
Gestorven:
integer
1840
1926
1834
1917
S01
Vissershuis
1882
S02
De balletles
1872
Monet
Degas
S03
Mona Lisa
1499
Da Vinci
1452
1519
S05
Na het bad
1883
Degas
1832
1917
Relatie geeft informatie over zowel schilderij als schilder
• Overtollige data bv. twee schilderijen van dezelfde schilder
• Afwijkingen (anomaliën) bv. update van het geboortejaar
• Dataverlies bv. enige schilderij weg, dan ook details schilder weg
12
Normalisatie
• Het normalisatieproces
Basisrelatie
1NF  2NF  3NF  BCNF  4NF  5NF  6NF
13
Voorbeeld
Opdracht: Facturatie
Tabel Factuur
Primary key: {Factuur nr.}
|
|
|
|
|Factuur nr.|Klant nr.|Naam
|Adres
|Artikelen
|Aantal
|Kosten
|
+-----------+---------+--------+--------+------------------------+------------------+---------------+
|
1000|
10|Arie K |Bosweg 3|Schroef;Bout;Spijker
|100/200/300
|5,00/2,00/3,00 |
|
1001|
20|Donald D|Bosweg 5|Zaag;Boor
|1/1
|30,00/40,00
|
|
1002|
30|Joop S |Bosweg 7|Badkuip
|20
|2000,00
|
+-----------+---------+--------+--------+------------------------+------------------+---------------+
Waarom staat deze relatie niet in 1NF?
Zet deze relatie in 1NF, vervolgens in 2NF en tot slot in 3NF.
Leg uit wat je doet en waarom!
14
Voorbeeld
1NF
Geen atomaire datatypes -> opslitsen
Tabel Factuur
Primary key:
{Factuur nr.}
Tabel Items
Primary key
{Factuur nr.; Item nr.}
|
|
|Factuur nr.|
+-----------+
|
1000|
|
1001|
|
1002|
+-----------+
|
|
|
|
|Factuur nr.|Item nr.|Klant nr.|Naam
|Adres
|Artikelen |Aantal |Kosten |
+-----------+--------+---------+--------+--------+----------+-------+--------+
|
1000|
1|
10|Arie K |Bosweg 3|Schroef
|100
|5,00
|
|
1000|
2|
10|Arie K |Bosweg 3|Bout
|200
|2,00
|
|
1000|
3|
10|Arie K |Bosweg 3|Spijker
|300
|3,00
|
|
1001|
1|
20|Donald D|Bosweg 5|Zaag
|1
|30,00
|
|
1001|
2|
20|Donald D|Bosweg 5|Boor
|1
|40,00
|
|
1002|
1|
30|Joop S |Bosweg 7|Badkuip
|20
|2000,00 |
+-----------+--------+---------+--------+--------+----------+-------+--------+
15
Foreign key
{Factuur nr.}
Voorbeeld
2NF
Ieder attribuut moet afhankelijk zijn van de gehele kandidaatsleutel
(klantgegevens zijn niet afhankelijk van een item (=primary key) maar van Factuur nr., gevolg: er ontstaat redundante
data)
oplossing: plaats klantinformatie bij factuur nr.
Tabel Factuur
Primary key:
{Factuur nr.}
Tabel Items
Primary key
{Factuur nr.; Item nr.}
|
|
|
|Factuur nr.|Klant nr.|Naam
|Adres
|
+-----------+---------+--------+--------+
|
1000|
10|Arie K |Bosweg 3|
|
1001|
20|Donald D|Bosweg 5|
|
1002|
30|Joop S |Bosweg 7|
+-----------+---------+--------+--------+
|
|
|
|
|Factuur nr.|Item nr.|Artikelen |Aantal |Kosten |
+-----------+--------+----------+-------+--------+
|
1000|
1|Schroef
|100
|5,00
|
|
1000|
2|Bout
|200
|2,00
|
|
1000|
3|Spijker
|300
|3,00
|
|
1001|
1|Zaag
|1
|30,00
|
|
1001|
2|Boor
|1
|40,00
|
|
1002|
1|Badkuip
|20
|2000,00 |
+-----------+--------+----------+-------+--------+
16
Foreign key
{Factuur nr.}
Voorbeeld
3NF
Ieder attribuut is alléén direct afhankelijk van een kandidaatsleutel
(klant naam en adres zijn afhankelijk van factuur (kandidaatsleutel) nr. èn klant nr. (géén kandidaatsleutel))
oplossing: opsplitsen
Tabel Factuur
Primary key:
Foreign key
{Factuur nr.} {Klant nr.}
|
|
|
|Factuur nr.|Klant nr.|
+-----------+---------+
|
1000|
10|
|
1001|
20|
|
1002|
30|
+-----------+---------+
Tabel Klant
Primary key:
{Klant nr.}
|
|
|Klant nr.|Naam
|Adres
|
+---------+--------+--------+
|
10|Arie K |Bosweg 3|
|
20|Donald D|Bosweg 5|
|
30|Joop S |Bosweg 7|
+---------+--------+--------+
17
Tabel Items
Primary key
Foreign key
{Factuur nr.; Item nr.} {Factuur nr.}
|
|
|
|
|Factuur nr.|Item nr.|Artikelen |Aantal |Kosten |
+-----------+--------+----------+-------+--------+
|
1000|
1|Schroef
|100
|5,00
|
|
1000|
2|Bout
|200
|2,00
|
|
1000|
3|Spijker
|300
|3,00
|
|
1001|
1|Zaag
|1
|30,00
|
|
1001|
2|Boor
|1
|40,00
|
|
1002|
1|Badkuip
|20
|2000,00 |
+-----------+--------+----------+-------+--------+
Overzicht
• Omzetting van een EER-diagram
• Normalisatie
• Denormalisatie
18
Denormalisatie
• Denormaliseren
– Bewust afstappen van een hogere normaalvorm
• Voordelen
– Minder relaties, dus minder operaties nodig
(systeemperformance gaat omhoog)
• Nadelen
– Kans op redundante data
– Hogere ontwikkelingskosten, omdat meer integriteitsrestricties,
stored procedures en triggers nodig zijn
– Slecht uit te breiden
19