Databaser og SQL Introduktion til SQL Kap 1-5 1 Dagens gang Databaser Database begreber Mapning af klasser til relationel model Normalisering Opgaver til næste gang 2 Databasebegreber A database is a: Logically coherent collection of related data with inherent meaning, built for a certain application, and representing a "miniworld". A database management system (DBMS) is software that allows databases to be defined,constructed, and manipulated Based on set theory (relational Algebra) 3 Side 1
Database begreber En relationel database består af en samling tabeller 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 Domæne Atributter 4 Nøgler Bog Udlån Låner En nøgle er en entydig identifikation af en enkelt rækkes data (en instans) Nøgler skaber sammenhænge mellem tabellers data 5 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 6 Side 2
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) 7 Implementering Principper, teknikker og vurdering 8 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 9 Side 3
Mapning af klasser i relationel database 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 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. 10 Mapning til relationel database: Generalisering Checkkonto Rentesats SidsteHæfte Nr SidsteUdtog Lån Hovedstol Afdrag Afdragsdato 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 11 Generalisering (1) Nr SidsteUdtog 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 Checkkonto Lån konto-id rentesats sidste-hæfte 1 0,1 100395 konto-id hovedstol afdrag afdragsdato 2 25000 2500 30 Rentesats SidsteHæfte Hovedstol Afdrag Afdragsdato 256 0,5 221294 Begrebsmæssig klar. Enkel og overskuelig. Let at ændre. Besværligt at tilgå objekter. 12 Side 4
Generalisering (2) Nr 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. 13 Generalisering (3) 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. 14 Aggregering og associering CPR-nr Navn Adresse Kunde Saldo SidsteUdtog type 0:m 1:m Kunde 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 konto-id konto-nr sidste-udtog kontotype 1 615-6789 280295 checkkonto 2 931-1453 311294 lån 256 112-7290 120395 checkkonto Kunde- kunde-id konto-id 1 2 1 4 2 1 2 2 2 4 3 3 4 2 4 1251 5 1251 256 25 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? 15 Side 5
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. 16 Normalisering 17 Normalisering Sidste aktivitet i databasedesign-processen. Teknik der anvendes til at sikre at den relationelle model ikke indeholder unødig redundans. 18 Side 6
Normalformer En normalform er defineret ved en række regler, som en tabel skal opfylde for at være på den givne normalform. 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. 19 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. 20 Eksempel Klasse fra et dårligt klassediagram for et ordrebehandlingssystem Ordrelinie -ordrenr -ordredato -sælgernr -sælgernavn -varenr -varenavn -antal 21 Side 7
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. Ordrelinie ordrenr ordredato sælgernr sælgernavn varenr varenavn antal 22 1NF med data Ordrenr Ordredato Sælgernr Sælgernavn Varenr Varenavn Antal O17 10-4-2001 S104 Jens Olsen V10 Plade 10 O17 10-4-2001 S104 Jens Olsen V32 Håndtag 3 O17 10-4-2001 S104 Jens Olsen V3 Dør 4 O18 12-4-2001 S101 Per Phil V3 Dør 2 O18 12-4-2001 S101 Per Phil V22 Side 2 O19 12-4-2001 S104 Jens Olsen V32 Håndtag 7 O19 12-4-2001 S104 Jens Olsen V3 Dør 4 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) Der må ikke være felter i tabellen, der kun står i relation til dele af tabellen 24 Side 8
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). 25 Funktionelle afhængigheder Ordrelinie Sammensat nøgle ordrenr ordredato sælgernr sælgernavn varenr varenavn antal Afhænger kun af ordrenr Afhænger kun af varenr 26 Den relationelle model på 2NF Ordre Ordre Ordre linie vare ordrenr ordredato sælgernr sælgernavn Ordrelinie Ordrelinie ID ordrenr varenr antal Vare varenr varenavn 27 Side 9
2NF med data Ordrenr Ordredato Sælgernr Sælgernavn O17 10-4-97 S104 Jens Olsen O18 12-4-97 S101 Per Pihl O19 12-4-97 S104 Jens Olsen varenr v3 v10 v22 v32 varenavn Dør Plade Side Håndtag OdrelinieID 1 2 3 4 5 6 7 Ordrenr Varenr Antal O17 V10 10 O17 V32 5 O17 V3 4 O18 V3 2 O18 V22 2 O19 V32 7 O19 V3 4 28 2. NF er opfyldt Hver tabel har en entydig nøgle Hvert felt indeholder kun én værdi Ingen kolonner gentages Ingen attributter, der ikke selv tilhører nøglen er afhængig af en del af nøglen 29 3. normalform En tabel er på 3. normalform hvis: Den er på 2NF Ingen attribut afhænger af andre attributter, der ikke selv er nøgler Det betyder: Alle egenskaber i en række skal være direkte afhængige af primærnøglen 30 Side 10
Funktionelle afhængigheder Ordre ordrenr ordredato sælgernr sælgernavn Afhængig af sælgernr 31 Den relationelle model på 3NF Ny Tabel Sælger sælgernr sælgernavn Ordre ordrenr ordredato sælgernr Ordrelinie ordrenr varenr antal Vare varenr varenavn 32 3NF med data varenr varenavn v3 Dør v10 Plade v22 Side v32 Håndtag Ordrenr Ordredato Sælgernr Ordrenr Varenr Antal O17 V10 10 O17 V32 5 O17 V3 4 O18 V3 2 O18 V22 2 O19 V32 7 O19 V3 4 O17 10-4-97 S104 O18 12-4-97 S101 Sælgernr S101 Sælgernavn Per Pihl O19 12-4-97 S104 S104 Jens Olsen 33 Side 11
RDB modelleres med E/R diagrammer Entitet relation 34 Side 12