Den relationelle model

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

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

3. Den relationelle model NOEA/IT - Databaser/arkitektur

4. 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) NOEA/IT - Databaser/arkitektur

5. 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. NOEA/IT - Databaser/arkitektur

6. 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) NOEA/IT - Databaser/arkitektur

7. 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 NOEA/IT - Databaser/arkitektur

8. 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. NOEA/IT - Databaser/arkitektur

9. 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. NOEA/IT - Databaser/arkitektur

10. 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.) NOEA/IT - Databaser/arkitektur

11. Eksempel…-2 ER-Datamodel (en domænemodel kunne bruges) ktonr cprnr status 1 n Konto ejer Kunde saldo navn adr rf gade postnr by NOEA/IT - Databaser/arkitektur

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

13. 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 NOEA/IT - Databaser/arkitektur

14. Eksempel …-4 Vi får følgende relationelle skemaer: • Kunde: • cprnr: cprNrType PK • navn varChar • gade varChar • postnr char[4] FK REF PNrBy(pnr) • status statusType NOT NULL • PNrBy: • pnr char[4] PK • by varChar NOT NULL NOEA/IT - Databaser/arkitektur

15. Eksempel…-5 • Konto: • kto ktoNrType PK • saldo decimal[>=0] NOT NULL • rentefod interval[0:100] NOT NULL • kCprnr cprNrType NOT NULL FK REF Kunde(cprnr) NOEA/IT - Databaser/arkitektur

16. 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) NOEA/IT - Databaser/arkitektur

17. 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 NOEA/IT - Databaser/arkitektur

18. 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) NOEA/IT - Databaser/arkitektur

19. Relationsalgebraen - oversigt NOEA/IT - Databaser/arkitektur

20. 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 NOEA/IT - Databaser/arkitektur