2009NOEA/IT - Databaser/arkitektur1 Den relationelle model En teoretisk model for databaser Hviler på et sundt teoretisk grundlag Omfatter: Datastruktur.

Præsentationer af emnet: "2009NOEA/IT - Databaser/arkitektur1 Den relationelle model En teoretisk model for databaser Hviler på et sundt teoretisk grundlag Omfatter: Datastruktur."— Præsentationens transcript:

1 2009NOEA/IT - Databaser/arkitektur1 Den relationelle model En teoretisk model for databaser Hviler på et sundt teoretisk grundlag Omfatter: Datastruktur Integritetsregler Manipulationssprog

2 2009NOEA/IT - Databaser/arkitektur2 ” Den verdensberømte supplier-part database” (Date)

3 2009NOEA/IT - Databaser/arkitektur3 Den relationelle model

4 2009NOEA/IT - Databaser/arkitektur4 Den relationelle model Data struktureres i et antal tabeller (relationer), som har forskellige navne. Hver tabel består af et antal (>=1) søjler (attributter). Attributter er atomiske og defineret over et domæne. I en tabel er der et antal (evt. ingen) rækker (forekomster, tupler), som ikke har nogen indbyrdes orden De enkelte forekomster kan identificeres ved hjælp af værdien af nøglen, der findes ikke to ens forekomster En relation (tabel) er en mængde af tupler Graden af en tabel angiver antal attributter (søjler)

5 2009NOEA/IT - Databaser/arkitektur5 Attributter Et domæne beskriver de lovlige værdier for en attribut. Domæner baseres på standard datatyper som int, char osv., som DBMS'et tilbyder. Flere attributter kan godt have samme domæne. At en attribut har værdien "tom” (ikke oplyst/ikke defineret) beskrives med værdien NULL.

6 2009NOEA/IT - Databaser/arkitektur6 Egenskaber ved relationer Følger af, at en relation er en mængde i matematisk forstand: ingen tuple optræder mere end een gang ( => der eksisterer altid en primærnøgle) tuplerne er uordnede (veritikalt) attributterne er uordnede (horisontalt) attributværdier er atomiske, dvs. en relation er altid på 1NF (Følger af, at domæner kun indeholder atomiske værdier)

7 2009NOEA/IT - Databaser/arkitektur7 Nøglebegrebet En nøgle er en attributkombination, som entydigt identificerer en forekomst i en tabel. En nøgle er minimal, dvs.. fjernes een attribut, er den ikke længere entydig. Alle attributter fra tabellen vil tilsammen altid være en (evt.. ikke-minimal) nøgle, kaldet en supernøgle. Der kan være flere forskellige kandidatnøgler i en tabel Der vælges altid en primærnøgle fra mængden af kandidatnøgler

8 2009NOEA/IT - Databaser/arkitektur8 Tabelsammenhænge repræsenteres ved fremmednøgler en fremmednøgle er een eller flere attributter i en tabel, som svarer til primærnøglen i en anden tabel en fremmednøgle peger på en forekomst i en anden tabel og fortæller, at her ligger resten af oplysningerne fremmednøglen og primærnøgleattributterne i den tabel, der refereres til, skal have samme domæne.

9 2009NOEA/IT - Databaser/arkitektur9 Integritetsregler Integritet: at være sammenhængende –Entitetsintegritet: En primærnøgle må ikke indeholde NULL-værdier –Referenceintegritet: En fremmednøgle skal enten være NULL eller referere til en forekomst med en tilsvarende primærnøgleværdi –Semantisk (domæne-) integritet: Forskellige regler, der i modsætning til de andre former for integritet, afhænger af den bestemte database.

10 2009NOEA/IT - Databaser/arkitektur10 Eksempel I firmaet Minibank registreres der oplysninger om kunder og konti. Om kunder registreres navn, adresse, cprnr og status (A= særlig gode kunder, B= almindelige kunder eller C= problemkunder). Om konti registreres kontonr, saldo og rentefod. En konto hører altid til en og kun en kunde, en kunde kan have 0 eller flere konti. (Primærnøglen (PK) er understreget.)

11 2009NOEA/IT - Databaser/arkitektur11 Eksempel…-2 ER-Datamodel (en domænemodel kunne bruges) Kunde Konto ejer cprnrstatus navn n1 adr gadepostnrby ktonr saldo rf

12 2009NOEA/IT - Databaser/arkitektur12 Eksempel…-2a Domænemodel (en Er-model kunne bruges)

13 2009NOEA/IT - Databaser/arkitektur13 Eksempel...-3 Der defineres tre tabeller –Kunde –Konto –PNrBy (for at undgå redundans) For at repræsentere ejerforholdet mellem konto og kunde tilføjes cprnr til konto som fremmednøgle

14 2009NOEA/IT - Databaser/arkitektur14 Eksempel …-4 Vi får følgende relationelle skemaer: Kunde: –cprnr:cprNrTypePK –navnvarChar –gadevarChar –postnrchar[4]FKREF PNrBy(pnr) –statusstatusTypeNOT NULL PNrBy: –pnrchar[4]PK –byvarCharNOT NULL

15 2009NOEA/IT - Databaser/arkitektur15 Eksempel…-5 Konto: –ktoktoNrTypePK –saldodecimal[>=0]NOT NULL –rentefodinterval[0:100]NOT NULL –kCprnrcprNrTypeNOT NULL FK REF Kunde(cprnr)

16 2009NOEA/IT - Databaser/arkitektur16 Eksempel…-6 Entitet: –primærnøgler må ikke være NULL Reference: –hvad skal der ske med Kunde.postnr, hvis en by får nyt postnr? Domæne: –cprNrType: det skal være muligt at definere gyldige cpr- numre –tilsvarende for kontonumre og statusværdier –saldo skal være ikke-negativ (problemspecifikt)

17 2009NOEA/IT - Databaser/arkitektur17 Problemspecifikke integritetsregler (forretningsregler) Mulighed for at definere fornuftige reaktioner på forsøg på opdateringer, som vil bryde integritetsregler fx. at hæve et beløb, så saldo vil blive negativ

18 2009NOEA/IT - Databaser/arkitektur18 Datamanipulation i den relationelle model - relationsalgebraen Arbejder på hele tabeller dvs. alle operationer tager tabeller som input og returnerer nye tabeller Operationer: –rækkeudvælgelse (RESTRICT/SELECT) –søjleudvælgelse (PROJECT) –sammensætning af tabeller (JOIN) –mængdeoperationer (UNION, INTERSECTION, MINUS, PRODUCT) –avancerede operationer (OUTER (LEFT/RIGTH) JOIN)

19 2009NOEA/IT - Databaser/arkitektur19 Relationsalgebraen - oversigt

20 2009NOEA/IT - Databaser/arkitektur20 Eksempel - MiniBank find kunden med cprnr=’250298-1234’ –rækkeudvælgelse: i Kunde(cprnr=’250298-1234’) find navne og adresser på alle kunder i postnr=’9220’ –rækkeudvælgelse i Kunde(postnr=’9220’) –rækkeudvælgelse i PNrBy(postnr=’9220’) –JOIN disse to temporære tabeller –søjleudvælgelse(navn, gade, postnr, by) i den lige dannede tabel