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 sammansattaNyckelattributBestående av ett eller flera värdenBasegenskaper 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 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.

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.

DAV B04 - Databasteknik

Normalisering och funktionella beroenden

Riktlinjer när man vill skapa en databas1) Designa så att det är lätt att förstå innebörden.

Kombinera inte attribut från olika entitetstyper i samma tabell

2) Designa så att inte problem uppstår vid insättning, borttagning eller modifiering

3) Undvik värden i basrelationer som ofta blir NULL. Skapa istället en ny relation

Vad är fel med denna design?

S# CITY P# QTY

S1 LONDON P1 300 S1 LONDON P2 200 S1 LONDON P3 400 S1 LONDON P4 200 S1 LONDON P5 100 S1 LONDON P6 100 S2 PARIS P1 300 S2 PARIS P2 400 : : : :

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# SNAMES# STATUSS# 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?

S# CITY P# QTY

S1 LONDON P1 300 S1 LONDON P2 200 S1 LONDON P3 400 S1 LONDON P4 200 S1 LONDON P5 100 S1 LONDON P6 100 S2 PARIS P1 300 S2 PARIS P2 400 : : : :

FB-diagram

S#

SNAME

STATUS

CITY

P#

PNAME

COLOR

WEIGHT

CITY

S#

P#

QTY

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

QTYS#

P#

STATUS

CITY

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

S# STATUS CITY P# QTY

S1 20 LONDON P1 300 S1 20 LONDON P2 200 S1 20 LONDON P3 400 S1 20 LONDON P4 200 S1 20 LONDON P5 100 S1 20 LONDON P6 100 S2 10 PARIS P1 300 S2 10 PARIS P2 400 S3 10 PARIS P2 200 S4 20 LONDON P2 200 S4 20 LONDON P4 300 S4 20 LONDON P5 400 : : : :

QTY

S#

P#

STATUS

CITY

S#

S# STATUS CITY

S1 20 LONDON S2 10 PARIS S3 10 PARIS S4 20 LONDON S5 30 ATHENS

S# P# QTY

S1 P1 300 S1 P2 200 S1 P3 400 S1 P4 200 S1 P5 100 S1 P6 100 S2 P1 300 S2 P2 400 S3 P2 200 S4 P2 200 S4 P4 300 S4 P5 400

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)

QTY

S#

P#

STATUS

CITY

S#

S# STATUS CITY

S1 20 LONDON S2 10 PARIS S3 10 PARIS S4 20 LONDON S5 30 ATHENS

S# P# QTY

S1 P1 300 S1 P2 200 S1 P3 400 S1 P4 200 S1 P5 100 S1 P6 100 S2 P1 300 S2 P2 400 S3 P2 200 S4 P2 200 S4 P4 300 S4 P5 400

Lösning

QTY

S#

P#

STATUS

CITY

S#

STATUSCITY CITYS#

S# CITY CITY STATUS

S1 LONDON S2 PARIS S3 PARIS S4 LONDON S5 ATHENS

ATHENS 30 LONDON 20 PARIS 10 ROME 50

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

kandidatnyckelDvs de enda tillåtna pilarna i FB-diagrammet

är de som utgår från kandidatnycklar