1 / 25

Relationsdatabasdesign

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

avery
Download Presentation

Relationsdatabasdesign

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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 Vad är Relationsdatabasdesign?

  3. 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) Metod

  4. 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 Begrepp

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

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

  7. Klasser Attribut 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 Översättning

  8. Exempel

  9. Klass  Tabell Klassens namn blir tabellens namn Klasser

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

  11. Egen tabell för varje flervärt attribut Attributets namn kan bli den nya tabellens namn Flervärda attribut 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. Man kan också omvandla den konceptuella modellen för att få bort det flervärda attributet Flervärda attribut Sedan kan man hantera denna ett-till-många relation.

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

  14. 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. Partiella attribut

  15. 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). Relationer

  16. 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-ett relationer

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

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

  19. 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 Många-till-många relationer

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

  21. 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. Arv

  22. 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. Tips

  23. Resultat

  24. 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. Validera resultatet

  25. Konceptuell modell 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) Konceptuell modell vs. Relationsmodell

More Related