Dagens gang Sidste uges opgaver Databaser Opgaver til næste gang

Præsentationer af emnet: "Dagens gang Sidste uges opgaver Databaser Opgaver til næste gang"— Præsentationens transcript:

1 Dagens gang Sidste uges opgaver Databaser Opgaver til næste gang
Database begreber Mapning af klasser til relationel model Normalisering Opgaver til næste gang

2 Database begreber En relationel database består af en samling tabeller
Tabeller er relateret til hinanden gennem nøgler En tabel beskriver en entitetstype (klasse) En tabel består af - Kolonner, felter, attributter som repræsenterer et domæne - Rækker, poster, tuples, instanser kunde-ID CPR-nr navn adresse Jens Andersen Søndergade 6 Oda Nielsen Algade 99 • Pia Schrøder Bispensgade 27 kunde-ID konto-ID • konto-ID konto-nr sidste-udtog kontotype checkkonto lån • checkkonto

3 Nøgler Primær nøgle Fremmed nøgle
Entydig identifikation af en rækkes data Unik og ikke NULL (skal have en værdi) Der kan kun være en primær nøgle i en tabel En primærnøgle kan være sammensat af flere felter Fremmed nøgle Repræsenterer relationen til en anden tabel Der kan være flere fremmed nøgler i en tabel

4 Dataintegritet Entitetsintegritet Referentiel integritet
I en given tabel må der ikke være identiske rækker Sikres af unik primærnøgle Referentiel integritet Fremmednøgle skal pege på en gyldig række i den tabel der relateres til. Ellers skal den sættes lig NULL Domæne integritet Mængde af gyldige værdier der eksisterer for en kolonne (type, længde, indhold)

5 Principper, teknikker og vurdering
Implementering Principper, teknikker og vurdering Kapitel 17

6 Implementering i objektorienteret miljø
Overvej Objekters identitet Attributters type og opdeling Skal associeringer repræsenteres enkelt- eller dobbeltrettet? Er aggregeringer statiske eller dynamiske? Skal aggregeringer repræsenteres indlejret eller tilknyttet? Håndtering af multipel nedarvning

7 Mapning af klasser i relationel database
Hver klasse afbildes over i en tabel. Klassens navn bruges som navn på tabellen. Hver af klassens attributter afbildes over i en søjle i tabellen. Tabellen udbygges med en søjle, som indeholder en entydig reference til ethvert objekt.(nøgle) For hver attribut overvejes endvidere domæne (type) muligheden for tomme værdier relevante nøgler hyppighed i anvendelsen Overvej mulige opdelinger af tabellen. Kunde CPR-nr Navn Adresse kunde-ID CPR-nr navn adresse Jens Andersen Søndergade 6 Oda Nielsen Algade 99 • Pia Schrøder Bispensgade 27

8 Mapning til relationel database: Generalisering
Konto KontoNr SidsteUdtog Generalisering: tre alternativer 1. Hver klasse afbildes i en tabel. De generelle og specielle dele af et objekt bindes sammen med nøgler. 2. Hver specialiseringsklasse afbildes i en tabel, som også indeholder generaliseringsklassens attributter. 3. Generaliseringsklassen afbildes i en tabel, som også indeholder alle specialiseringsklassernes attributter. Multipel nedarvning: Tilgang 1 anvendes Checkkonto Rentesats SidsteHæfte Lån Hovedstol Afdrag Afdragsdato

9 Generalisering (1) Konto Konto Checkkonto Lån Checkkonto Lån
KontoNr SidsteUdtog Konto konto-ID konto-nr sidste-udtog kontotype checkkonto lån • checkkonto Checkkonto Lån konto-ID rentesats sidste-hæfte 1 0, • 256 0, konto-ID hovedstol afdrag afdragsdato • Checkkonto Rentesats SidsteHæfte Lån Hovedstol Afdrag Afdragsdato Begrebsmæssig klar. Enkel og overskuelig. Let at ændre. Besværligt at tilgå objekter.

10 Generalisering (2) Konto Checkkonto Checkkonto Lån
KontoNr SidsteUdtog Checkkonto konto-ID konto-nr sidste-udtog rentesats sidste-hæfte , • , Checkkonto Rentesats SidsteHæfte Lån Hovedstol Afdrag Afdragsdato Ingen tabel for generaliseringsklassen. Enkel tilgang, når kontotypen kendes. Ændringer i generaliseringsklassen kræver rettelse i alle specialiseringsklasser. Bedst når generaliseringsklassen har få attributter.

11 Generalisering (3) Konto Ingen tabeller for specialiseringsklasserne.
konto-ID konto-nr sidste-udtog kontotype rentesats sidste-hæfte hovedstol afdrag afdragsdato checkkonto 0, lån • checkkonto 0, Ingen tabeller for specialiseringsklasserne. Enkel tilgang. Bedst når generaliseringsklassen har mange attributter.

12 Aggregering og associering
Kunde Kunde-Konto Kunde CPR-nr Navn Adresse kunde-ID CPR-nr navn adresse Jens Andersen Søndergade 6 Oda Nielsen Algade 99 • Pia Schrøder Bispensgade 27 kunde-ID konto-ID • Konto 0:m konto-ID konto-nr sidste-udtog kontotype checkkonto lån • checkkonto 1:m Konto Saldo SidsteUdtog Kontotype De indgående klasser bliver til tabeller. Tabellerne udbygges med nøgle-attributter. Strukturen kan repræsenteres i en selvstændig tabel. Overvej: Skal delobjekter i en aggregering oprettes og nedlægges sammen med helhedsobjektet?

13 Vurdering af relationel database
Modellen bidrager konstruktivt til definition, afgrænsning og implementering af databasens indhold og anvendelse. Der er en enkel, men ikke altid triviel vej fra klasser, strukturer og attributter til implementeringen. Der er ingen indkapsling i det implementerede system. Alle data i databasen kan principielt manipuleres fra alle dele af systemet ved hjælp af SQL. Et relationelt databaseværktøj kan anvendes til hurtig udvikling af prototyper under analyse og design også selv om det endelige system ikke implementeres i et fjerdegenerationsværktøj.

14 Oversigt Formål Principper Resultat
At realisere et design på en teknisk platform. Principper Respekter designbeslutningerne. Resultat En samling af programdele, som realiserer et objektorienteret design.

15 Normalisering

16 Normalisering Sidste aktivitet i databasedesign-processen.
Teknik der anvendes til at sikre at den relationelle model ikke indeholder unødig redundans.

17 Normalformer Under normaliseringsprocessen sikrer man sig at tabellerne er på en stadig højere normal-form - ofte stoppes ved tredie normalform (3NF) eller Boyce-Codd normalform (BCNF), men man kan i teorien komme helt op på femte normalform selv om det ikke er særlig interessant i praksis. En normalform er defineret ved en række regler, som en tabel skal opfylde for at være på den givne normalform.

18 Normalformerne udgør et hieraki
1NF er den laveste og 5NF den højeste. Dvs. de krav der stilles til en tabel, for at den skal være på 1NF er mindre end dem, der stilles for at den skal være på 2NF osv. Alle tabeller, der er på 2NF er automatisk på 1NF, og alle der er på 3NF er automatisk på 2NF og 1NF osv. Da ideen med normalformerne er at undgå redundans vil en tabel der kun er på 1NF indeholde mere redundans end en tabel på 2NF osv.

19 Eksempel Klasse fra et dårligt klassediagram for et ordrebehandlingssystem

20 1. normalform En tabel er på 1. normalform hvis:
Den kun indeholder simple attributter (atomare attributter), dvs. ingen flerværdi-attributter og ingen sammensatte attributter. Atomare attributter er attributter som vi ikke kan/vil opdele yderligere.

21 1NF med data Ordrenr Ordredato Sælgernr Sælgernavn Varenr Varenavn
Antal O17 S104 Jens Olsen V10 Plade 10 V32 Håndtag 3 V3 Dør 4 O18 S101 Per Phil 2 V22 Side O19 7

22 Funktionel afhængighed
En funktionel afhængighed (FD) bestemmer et forhold mellem attributter. FD: X Y læses som: X bestemmer Y funktionelt eller:Y er funktionelt afhængig af X X kaldes for determinanten, da det er den der entydigt bestemmer Y's værdi. Eks: Varenr  varenavn, da der til et givet varenr svarer et og kun et varenavn (i det valgte problemområde).

23 2. normalform En tabel er på 2. normalform hvis:
Den er på 1NF. Alle ikke-nøgle attributter er fuldt funktionelt afhængige (FFD) af hele primærnøglen. (Dette er kun et problem i tabeller med sammensat nøgle)

24 Funktionelle afhængigheder

25 Den relationelle model på 2NF

26 2NF med data Ordrenr Ordredato Sælgernr Sælgernavn O17 10-4-97 S104
Jens Olsen O18 S101 Per Pihl O19 Ordrenr Varenr Antal O17 V10 10 V32 5 V3 4 O18 2 V22 O19 7 varenr varenavn v3 Dør v10 Plade v22 Side v32 Håndtag

27 Transitive funktionelle afhængigheder:
X Z er en transitiv funktionel afhængighed hvis der findes en FD X Y og en FD Y Z. Dvs. at X Y og Y Z  X Z Et eksempel: Medarbejdernr Postnr og Postnr Postdistrikt  Medarbejdernr Postdistrikt. Her er der en transitiv funktionel afhængighed mellem medarbejdernr og postdistrikt.

28 3. normalform En tabel er på 3. normalform hvis:
Den er på 2NF og der ikke findes nogen transitive funktionelle afhængigheder mellem ikke-nøgle attributter (dette er kun et problem i relationer med mere end een ikke-nøgle attribut)

29 Funktionelle afhængigheder

30 Den relationelle model på 3NF

31 3NF med data varenr varenavn v3 Dør v10 Plade v22 Side v32 Håndtag
Ordrenr Varenr Antal O17 V10 10 V32 5 V3 4 O18 2 V22 O19 7 Ordrenr Ordredato Sælgernr O17 S104 O18 S101 O19 Sælgernr Sælgernavn S101 Per Pihl S104 Jens Olsen

32 Opgaver til næste gang Lilleby kommunebibliotek
Map klassediagram til relationelle skemaer Normaliser