1 / 32

Dagens gang

Dagens gang. Sidste uges opgaver Databaser Database begreber Mapning af klasser til relationel model Normalisering Opgaver til næste gang. kunde-ID CPR-nr navn adresse 1 010155-2321 Jens Andersen Søndergade 6 2 101289-7566 Oda Nielsen Algade 99 • • •

tarmon
Download Presentation

Dagens gang

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. Nøgler • Primær 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 • 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. 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. 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 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

  8. Mapning til relationel database: Generalisering 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 Konto KontoNr SidsteUdtog Checkkonto Rentesats SidsteHæfte Lån Hovedstol Afdrag Afdragsdato

  9. konto-ID konto-nr sidste-udtog kontotype • 1 615-6789 280295 checkkonto • 2 931-1453 311294 lån • • • • • • • 256 112-7290 120395 checkkonto • konto-ID rentesats sidste-hæfte • 1 0,1 100395 • • • • • • • 256 0,5 221294 • konto-ID hovedstol afdrag afdragsdato • 2 25000 2500 30 • • • • • • Generalisering (1) Konto Konto KontoNr SidsteUdtog Checkkonto Lån 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) Checkkonto Konto KontoNr SidsteUdtog • 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.

  11. Generalisering (3) Konto • 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.

  12. 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 Aggregering og associering Kunde Kunde-Konto Kunde CPR-nr Navn Adresse • 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? Konto 0:m 1:m Konto Saldo SidsteUdtog Kontotype

  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 • 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

  22. Funktionel afhængighed • Enfunktionel 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

  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

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

More Related