Ladda ner presentationen
1
Relationsdatabasdesign
nikos dimitrakas rum 6626 Database Systems, Connolly & Begg third edition: kapitel 14.1, 14.2 & 15 fourth edition: kapitel 15.1, 15.2 & 16
2
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
3
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)
4
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
5
Notation Tabellnamn Kolumnnamn Primärnyckel Relationens multiplicitet:
minimum maximum 1 många *Främmande nyckel
6
Notation (mer komplett)
Datatyp Andra regler för kolumner
7
Ö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
8
Exempel
9
Klasser Klass Tabell Klassens namn blir tabellens namn
10
Envärda attribut Från klassen till motsvarande tabell
Attributets namn i tabellen kan vara samma som i klassen
11
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:
12
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.
13
Sammansatta attribut En kolumn för varje del av det sammansatta attributet
14
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.
15
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).
16
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
17
Ett-till-många relationer
En främmande nyckel på många-sidan
18
Ett-till-många relationer
Även om relationen är rekursiv gäller samma regel: En främmande nyckel på många-sidan
19
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
20
Arv Subklassens tabell får samma primärnyckel som superklassens tabell. Primärnyckeln i subklassens tabell är en främmande nyckel till superklassens tabell.
21
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.
22
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.
23
Resultat
24
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.
25
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)
Liknande presentationer
© 2024 SlidePlayer.se Inc.
All rights reserved.