Transcript svag entitet

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

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 databas
1)
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
3 00
S2
PARIS
P2
4 00
:
:
:
:
Normalisering

Felet med designen är att relationen innehåller redundans


Syftet med normalisering är att minska redundansen i den lagrade
informationen.


Kan leda till inkonsistens och problem vid uppdateringar
"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 Yvärde i R (vid varje tillfälle). Attributen X och Y
kan vara sammansatta
 R.Y (R.X determinerar R.Y funktionellt)
 Den vänstra sidan kallas determinant och den högra
sidan dependent
 R.X
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 ickereducerbar)

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
3 00
S2
PARIS
P2
4 00
:
:
:
:
FB-diagram
PNAME
SNAME
COLOR
S#
ST AT US
P#
WEIGHT
CIT Y
CIT Y
S#
QT Y
P#
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# )
S#
STATUS
P#
CITY
QTY
Problem vid uppdateringar
(S#  CITY)

S#
ST AT US
CIT Y
P#
QT Y
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
:
:
:
:


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…
STATUS
S#
QTY
S#
CITY
S#
ST AT US
P#
CIT Y
S#
P#
QT Y
S1
20
LONDON
S1
P1
300
S2
10
PARIS
S1
P2
200
S3
10
PARIS
S1
P3
400
S4
20
LONDON
S1
P4
200
S5
30
AT HENS
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 (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

STATUS
S#
QTY
S#
CITY
P#

S#
ST AT US
CIT Y
S#
P#
QT Y
S1
20
LONDON
S1
P1
300
S2
10
PARIS
S1
P2
200
S3
10
PARIS
S1
P3
400
S4
20
LONDON
S1
P4
200
S5
30
AT HENS
S1
P5
100
S1
P6
100
S2
P1
300
S2
P2
400
S3
P2
200
S4
P2
200
S4
P4
300
S4
P5
400
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
ST AT US
S#
QT Y
S#
P#
CIT Y
S#
CITY
S#
CITY
S1
LONDON
S2
PARIS
S3
PARIS
S4
LONDON
S5
ATHENS
CITY
CITY
STATUS
STATUS
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
kandidatnyckel

 Dvs
de enda tillåtna pilarna i FB-diagrammet
är de som utgår från kandidatnycklar