Datamodellering med E/R-diagram

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 • 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. • Regler för update och delete måste specificeras för varje främmandenyckel. • 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. DAV B04 - Databasteknik Normalisering och funktionella beroenden

16. Riktlinjernä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