Relationsdatabasdesign nikos dimitrakas nikos@dsv.su.se 08-162099 rum 6626 Database Systems, Connolly & Begg third edition: kapitel 14.1, 14.2 & 15 fourth edition: kapitel 15.1, 15.2 & 16

Vad är Relationsdatabasdesign? Logisk relationsdatabasdesign Omvandla en konceptuell modell till en logisk relationsdatabasmodell (i 3NF) Kallas ofta för översättning av konceptuell modell till relationsdatabasmodell eller till logisk modell Fysisk relationsdatabasdesign Omvandla en logisk relationsdatabasmodell till en fysisk relationsdatabasmodell

Metod Utgå från den konceptuella modellen Översätt klasser, attribut och relationer till tabeller, kolumner, och nycklar Validera den framtagna modellen med normalisering Validera att modellerna stämmer överens (tänk på multipliciteter och andra regler) Modifiera vid behov (gå tillbaka till den konceptuella modellen vid behov)

Begrepp Tabeller (relationer) Kolumner, attribut Nycklar Primärnycklar Främmande nycklar Surrogatnycklar Kandidatnycklar Alternativa nycklar Sammansatta nycklar Datatyper (domäner) Andra regler UNIQUE, NOT NULL Regler för främmande nycklar

Notation Tabellnamn Kolumnnamn Primärnyckel Relationens multiplicitet: minimum maximum 1 många *Främmande nyckel

Notation (mer komplett) Datatyp Andra regler för kolumner

Översättning Klasser Attribut Relationer Envärda Flervärda Partiella Sammansatta Relationer Ett-till-ett (1:1) Ett-till-många (1:M) Många-till-många (M:M) Arv

Exempel

Klasser Klass  Tabell Klassens namn blir tabellens namn

Envärda attribut Från klassen till motsvarande tabell Attributets namn i tabellen kan vara samma som i klassen

Flervärda attribut Egen tabell för varje flervärt attribut Attributets namn kan bli den nya tabellens namn Men det är inte klart. Vi behöver koppla tabellerna med en främmande nyckel. Men då måste man ha en primärnyckel i tabellen Person:

Flervärda attribut Man kan också omvandla den konceptuella modellen för att få bort det flervärda attributet Sedan kan man hantera denna ett-till-många relation.

Sammansatta attribut En kolumn för varje del av det sammansatta attributet

Partiella attribut Hantera som vanliga attribut men låt kolumnerna acceptera NULL, eller Skapa en ny tabell (en subklass) för att lägga det partiella attributet. Det här borde eventuellt göras redan vid den konceptuella modellen.

Relationer För att översätta relationer behöver vi främmande nycklar. För att skapa främmande nycklar måste man först ha primärnycklar. Då vissa primärnycklar är beroende av andra främmande nycklar, gör man dessa parallellt. Dock är det lämpligt att börja med de oberoende tabellerna/klasserna (strong entities).

Ett-till-ett relationer En främmande nyckel på den ena sidan Välj den sidan som är bäst för att undvika NULL, dvs främmande nyckeln på noll-sidan

Ett-till-många relationer En främmande nyckel på många-sidan

Ett-till-många relationer Även om relationen är rekursiv gäller samma regel: En främmande nyckel på många-sidan

Många-till-många relationer En ny tabell med två främmande nycklar: en till varje sida Den nya tabellens primärnyckel blir oftast en sammansatt nyckel som består av de två främmande nycklarna

Arv Subklassens tabell får samma primärnyckel som superklassens tabell. Primärnyckeln i subklassens tabell är en främmande nyckel till superklassens tabell.

Arv Alla andra arvsregler (mandatory OR, optional OR, etc) blir verksamhetsregler. Relationen mellan superklassens tabell och subklassens tabell blir en vanlig ett-till-ett relation. En relationsdatabas förstår inte att det finns arv.

Tips Om en refererad primärnyckel är sammansatt, måste främmande nyckeln också vara sammansatt. Om en relation är 0..1-till-0..1 kan man placera främmande nyckeln på vilken sida som helst, (eller kan man ändra den konceptuella modellen). Om flera relationer går mellan samma tabeller, skall man namnge främmande nycklarna så att kunna skilja på relationerna. Välj namn för tabeller och kolumner som visar vad ett värde i kolumnen / en rad i tabellen är. Undvik pluralform. För tabeller som refereras av flera andra, kan det vara lämpligt att skapa surrogatnycklar om de naturliga nycklarna är för stora.

Resultat

Validera resultatet Kontrollera att modellen stämmer överens med den konceptuella modellen. Om något inte kunde översättas, kan det t ex bli en verksamhetsregel. Kontrollera att modellen är i 3NF. Ofta blir modellen direkt i 3NF om man har en bra konceptuell modell.

Konceptuell modell vs. Relationsmodell Inga relationsdatabasspecifika grejer Inga surrogatnycklar Inga primärnycklar (dock OK med identifierare) Inga främmande nycklar Endast attribut från den modellerade verksamheten Relationsdatabasmodell Inga flervärda attribut Inga många-till-många relationer Inget arv Nycklar (primärnycklar & främmande nycklar)