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

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 1 010155-2321 Jens Andersen Søndergade 6 2 101289-7566 Oda Nielsen Algade 99 • 1251 060967-2390 Pia Schrøder Bispensgade 27 kunde-ID konto-ID 1 2 1 4 2 1 2 2 2 4 3 3 4 2 4 1251 5 1251 • 256 25 konto-ID konto-nr sidste-udtog kontotype 1 615-6789 280295 checkkonto 2 931-1453 311294 lån • 256 112-7290 120395 checkkonto

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

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)

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

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

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 1 010155-2321 Jens Andersen Søndergade 6 2 101289-7566 Oda Nielsen Algade 99 • 1251 060967-2390 Pia Schrøder Bispensgade 27

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

Generalisering (1) Konto Konto Checkkonto Lån Checkkonto Lån KontoNr SidsteUdtog Konto konto-ID konto-nr sidste-udtog kontotype 1 615-6789 280295 checkkonto 2 931-1453 311294 lån • 256 112-7290 120395 checkkonto Checkkonto Lån konto-ID rentesats sidste-hæfte 1 0,1 100395 • 256 0,5 221294 konto-ID hovedstol afdrag afdragsdato 2 25000 2500 30 • Checkkonto Rentesats SidsteHæfte Lån Hovedstol Afdrag Afdragsdato Begrebsmæssig klar. Enkel og overskuelig. Let at ændre. Besværligt at tilgå objekter.

Generalisering (2) Konto Checkkonto Checkkonto Lån KontoNr SidsteUdtog Checkkonto konto-ID konto-nr sidste-udtog rentesats sidste-hæfte 1 615-6789 280295 0,1 100395 • 256 112-7290 120395 0,5 221294 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.

Generalisering (3) Konto Ingen tabeller for specialiseringsklasserne. konto-ID konto-nr sidste-udtog kontotype rentesats sidste-hæfte hovedstol afdrag afdragsdato 1 615-6789 280295 checkkonto 0,1 100395 2 931-1453 311294 lån 25000 2500 30 • 256 112-7290 120395 checkkonto 0,5 221294 Ingen tabeller for specialiseringsklasserne. Enkel tilgang. Bedst når generaliseringsklassen har mange attributter.

Aggregering og associering Kunde Kunde-Konto Kunde CPR-nr Navn Adresse kunde-ID CPR-nr navn adresse 1 010155-2321 Jens Andersen Søndergade 6 2 101289-7566 Oda Nielsen Algade 99 • 1251 060967-2390 Pia Schrøder Bispensgade 27 kunde-ID konto-ID 1 2 1 4 2 1 2 2 2 4 3 3 4 2 4 1251 5 1251 • 256 25 Konto 0:m konto-ID konto-nr sidste-udtog kontotype 1 615-6789 280295 checkkonto 2 931-1453 311294 lån • 256 112-7290 120395 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?

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.

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.

Normalisering

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

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.

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.

Eksempel Klasse fra et dårligt klassediagram for et ordrebehandlingssystem

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.

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

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).

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)

Funktionelle afhængigheder

Den relationelle model på 2NF

2NF med data Ordrenr Ordredato Sælgernr Sælgernavn O17 10-4-97 S104 Jens Olsen O18 12-4-97 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

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.

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)

Funktionelle afhængigheder

Den relationelle model på 3NF

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 10-4-97 S104 O18 12-4-97 S101 O19 Sælgernr Sælgernavn S101 Per Pihl S104 Jens Olsen

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