Datamodellering med E/R-diagram

En presentation över ämnet: "Datamodellering med E/R-diagram"— Presentationens avskrift:

1 Datamodellering med E/R-diagram

2 Databasdesign Givet att vi har en kravspecifikation över den information som ska finnas i databasen, hur kan vi logiskt strukturera innehållet på ett bra sätt? En av de vanligaste modellerna för databasdesign är entitet/relations (E/R) - modellen. ER-modellen beskriver data med hjälp av: entiteter attribut relationer subtyper

3 Entiteter ” Någonting som klart kan identifieras ”
existerar fysiskt, ex bil, student existerar konceptuellt, ex univ.kurs, jobb Delas ibland upp i starka entiteter och svaga entiteter. Tips: leta efter substantiv i kravspecen

4 Entiteter och attribut
Varje entitet har attribut, dvs. egenskaper som beskriver entiteten. Dessa kan vara: Enkla eller sammansatta Nyckelattribut Bestående av ett eller flera värden Basegenskaper eller härledda egenskaper

5 Sammansatta attribut Kan delas ned i mindre delar som har oberoende betydelse

6 Nyckelattribut Varje entitetstyp skall ha ett (eller flera) attribut vars värde skall vara unikt för varje enskild entitet i entitetsmängden Student: Personnummer, namn, ålder

7 Mångvärdesattribut Vanligtvis har ett attribut bara ett värde, men...
Vad händer om ex. en bil har tre olika färger?

8 Härledda attribut Exempelvis kan man härleda en persons ålder från personnummer och nuvarande år

9 Relationer mellan entiteter
Definieras som "en association mellan entiteter". Tips: leta efter verb i kravspecen Entiteter som ingår i en relation sägs vara deltagare i den relationen. Antalet deltagare i en relation kallas relationens grad. Det finns tre sorters relationer (kardinalitet): En-till-en ( 1-1 ) En-till-många ( 1-n ) Många-till-många ( n-m ) En entitet kan antingen ha ett partiellt eller ett totalt deltagande i en relation En relation kan också ha attribut!

10 Subtyper En entitet kan vara av flera typer samtidigt.
Om t ex vissa anställda är programmerare kan vi säga att entiteten PROGRAMMERARE är en subtyp av entiteten ANSTÄLLD. PROGRAMMERARE ärver alla egenskaper och relationer som ANSTÄLLD har (men inte tvärtom).

11 Mappning ER-diagram / relationsmodellen
Varje stark entitetet blir en basrelation där primärnyckeln i relationen motsvarar nyckelattributet(en) i entiteten Varje svag entitet blir en basrelation som bildar sin primärnyckel genom att ta primärnyckeln från ”ägande” relationen (som främmandenyckel) och egen partiell nyckel tillsammans Reglerna för främmandenycklar i en relation mellan en svag och en stark entitet måste vara DELETE CASCADES UPDATE CASCADES Visar på beroendeförhållandet mellan entiteterna

12 Relationer En-till-många relationer Många-till-många relationer
En främmandenyckel introduceras i relationen på "många"-sidan som refererar till relationen på "en"-sidan. Regler för update och delete måste specificeras för varje främmandenyckel. En-till-en relationer behandlas precis som en-till-många relationer. Många-till-många relationer Varje många-till-många relation blir en basrelation. Varje sådan basrelation måste innehålla en främmandenyckel för varje deltagare i relationen. Primärnyckeln kan vara kombinationen av främmandenycklarna (om den är unik) eller så kan ett nytt attribut introduceras.

13 Attribut Varje attribut för en entitet blir ett attribut i den relation den tillhör. Undantaget är om attributet för entiteten är ett mångvärdes-attribut, i så fall skapas en ny relation Härledda attribut läggs oftast inte heller in i databasen. Istället skapas vyer för dessa Domäner skapas för alla attributens värdemängder

14 Subtyper Varje subtyp blir en basrelation med samma primärnyckel som relationen den ärver ifrån (supertypen). Primärnyckeln blir också en främmandenyckel som refererar till supertypen.

15 Normalisering och funktionella beroenden
DAV B04 - Databasteknik Normalisering och funktionella beroenden

16 Riktlinjer när man vill skapa en databas
Designa så att det är lätt att förstå innebörden. Kombinera inte attribut från olika entitetstyper i samma tabell Designa så att inte problem uppstår vid insättning, borttagning eller modifiering Undvik värden i basrelationer som ofta blir NULL. Skapa istället en ny relation

17 Vad är fel med denna design?

18 Normalisering Felet med designen är att relationen innehåller redundans Kan leda till inkonsistens och problem vid uppdateringar Syftet med normalisering är att minska redundansen i den lagrade informationen. "one fact in one place” Normalisering innebär att man kollar om en relation uppfyller ett antal sk normalformer Om ej, delas relationen upp i flera mindre Denna uppdelning måste vara reversibel, dvs ingen information får förloras vid normaliseringen Normalisering används oftast bara för att verifiera designen

19 Normalformer (formellt)
1NF: Omm relationens underliggande domäner endast innehåller atomära värden 2NF: Omm relationen är i 1NF och varje attribut som inte ingår i primärnyckeln är till fullo funktionellt beroende av den. 3NF: Omm relationen är i 2NF och varje attribut som inte ingår i primärnyckeln är ömsesidigt funktionellt oberoende BCNF: Omm varje determinant är en kandidatnyckel

20 Funktionellt beroende (FB)
Givet en relation R, så är attributet Y i R funktionellt beroende av attributet X i R omm varje X-värde i R är associerat med precis ett Y-värde i R (vid varje tillfälle). Attributen X och Y kan vara sammansatta R.X  R.Y (R.X determinerar R.Y funktionellt) Den vänstra sidan kallas determinant och den högra sidan dependent

21 Exempel på funktionellt beroende
Relationen Suppliers har följande FB: S#  SNAME S#  STATUS S#  CITY Dvs för varje värde på S# finns det exakt ett värde på SNAME, STATUS och CITY Vet vi värdet på S# vet vi också värdena på de andra attributen

22 Exempel på funktionellt beroende
Determinanten kan bestå av fler än ett attribut, t ex i relationen SHIPMENTS: (S#, P#)  QTY Alla attribut är funktionellt beroende av primärnyckeln (per definition) Finns det andra beroenden har vi redundans!

23 Till fullo funktionellt beroende
Vi har också följande FB: (S#, SNAME)  CITY Det här är dock inte ett till fullo FB eftersom determinanten är reducerbar CITY är funktionellt beroende på S# ensamt (determinanten är icke-reducerbar)

24 Vilka FB har relationen?

25 FB-diagram

26 Exempel normalisering
Vi utgår från en relation som bara uppfyller 1NF. FIRST( S#, STATUS, CITY, P#, QTY ) anta också att CITY ---> STATUS PN är ( S#, P# )

27 Problem vid uppdateringar (S#  CITY)
INSERT: att en viss leverantör finns i en viss stad kräver att den leverantören kan leverera minst en del DELETE: om den enda tupeln tas bort förloras all information om den leverantören UPDATE: city förekommer i FIRST många gånger flera uppdateringar för att ändra stad möjliga inkonsistenser i databasen

28 Lösning…

29 Lösning (forts) Vi delar upp relationen FIRST så att alla icke-till-fullo FB försvinner OBS! se till att inga FB förloras vid uppdelningen  ingen information förloras Relationerna är nu i 2NF: Omm relationen är i 1NF och varje attribut som inte ingår i primärnyckeln är till fullo beroende av den

30 Från 2NF till 3NF Vi har fortfarande problem eftersom CITY  STATUS
Två attribut som inte ingår i PN är beroende av varandra (också kallat ett transitivt beroende)

31 Lösning

32 Lösning (forts) Vi delar upp relationen så att alla ömsesidiga beroenden försvinner Uppdelning sker med project och den ursprungliga relationen kan återskapas med en naturlig join Relationerna är nu i 3NF: omm relationen är i 2NF och varje attribut som inte ingår i primärnyckeln är ömsesidigt oberoende

33 Boyce/Codd Normalform (BCNF)
En variant av 3:e normalformen Hänvisar inte till 1NF och 2NF utan står för sig själv BCNF: omm varje determinant är en kandidatnyckel Dvs de enda tillåtna pilarna i FB-diagrammet är de som utgår från kandidatnycklar