Side 1. Databaser og SQL. Dagens gang. Databasebegreber. Introduktion til SQL Kap 1-5

Transkript

1 Databaser og SQL Introduktion til SQL Kap 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

2 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

3 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

4 Mapning af klasser i relationel database Kunde CPR-nr Navn Adresse kunde-id CPR-nr navn adresse Jens Andersen Søndergade Oda Nielsen Algade 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 checkkonto lån checkkonto Checkkonto Lån Checkkonto Lån konto-id rentesats sidste-hæfte 1 0, konto-id hovedstol afdrag afdragsdato Rentesats SidsteHæfte Hovedstol Afdrag Afdragsdato 256 0, Begrebsmæssig klar. Enkel og overskuelig. Let at ændre. Besværligt at tilgå objekter. 12 Side 4

5 Generalisering (2) Nr 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. 13 Generalisering (3) 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. 14 Aggregering og associering CPR-nr Navn Adresse Kunde Saldo SidsteUdtog type 0:m 1:m Kunde kunde-id CPR-nr navn adresse Jens Andersen Søndergade Oda Nielsen Algade Pia Schrøder Bispensgade 27 konto-id konto-nr sidste-udtog kontotype checkkonto lån checkkonto Kunde- kunde-id konto-id 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

6 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

7 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

8 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 O S104 Jens Olsen V10 Plade 10 O S104 Jens Olsen V32 Håndtag 3 O S104 Jens Olsen V3 Dør 4 O S101 Per Phil V3 Dør 2 O S101 Per Phil V22 Side 2 O S104 Jens Olsen V32 Håndtag 7 O S104 Jens Olsen V3 Dør 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

9 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

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

11 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 O S104 O S101 Sælgernr S101 Sælgernavn Per Pihl O S104 S104 Jens Olsen 33 Side 11

12 RDB modelleres med E/R diagrammer Entitet relation 34 Side 12