Datamodellering med E/R-diagram

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

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

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

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

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

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

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

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!

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

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

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.

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

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.

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

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

Vad är fel med denna design?

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

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

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

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

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!

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)

Vilka FB har relationen?

FB-diagram

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# )

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

Lösning…

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

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)

Lösning

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

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