E/R-diagram

Webprogrammering –Netteknologi A.
Note vedr. E/R diagrammer til Databaser
Datamodeller
DTU 9. oktober 2007
I forlængelse af noten om normalisering, følges der her op med redskabet
E/R-diagrammer til opstilling af en datamodel, opfat således dette som en alternativ
metode mere end endnu et redskab til datamodellering.
1. Elementerne
Vi betragter E/R-diagrammet, som et diagram over entiteter og relationer
Tegneregler:
Entitet
En rektangulær kasse – symboliserer en entitet
(entiteter bliver til tabeller)
Relation
En diamant (eller en rude) symboliserer en relation mellem to eller flere entiteter.
(kan nogle gange blive til en tabel)
Et E/R-diagram er en logisk eller begrebsmæssig tegning af lagrede data. Dette kaldes
også en datamodel. Senere kan datamodellen gøres ”fysisk” eller implementeres i
form af en database, efter nogle retningslinjer, som beskrives herunder i
Ordredatamodellen:
KUNDE
N
1
Har
afgivet
ORDRE
N
Side: 1 af 7
omfatter
M
VARE

Webprogrammering –Netteknologi A.
Note vedr. E/R diagrammer til Databaser
DTU 9. oktober 2007
Fordelen ved at starte med en model eller en arkitekttegning er velkendte fra andre
sammenhænge:
Det er en nem og billig måde at udføre eksperimenter med løsningsalternativer
Det giver overblik og mulighed for at tale sammen om det endelige produkt på
en konstruktiv måde
Det bidrager med en ”arbejdstegning” , der kan bruges ved fremstilling af det
endelige produkt – dét, der også kaldes at implementere.
Det gør at man efter implementeringen har en udmærket dokumentation til
produktet.
2. Relationer
En relation er en forbindelse eller en sammenhæng mellem entiteter. I
ordredatamodellen ovenfor er der to relationer ”Kunde har afgivet ordre” og ”Ordre
omfatter vare”. Relationerne kan også læses den anden vej, så skulle de have heddet
”ordre er afgivet af kunde” og ”Vare er omfattet af ordre”.
Relationstyper
Relationstypen angiver hvor mange entiteter relationen forbinder; man skelner
mellem rekursive (1 entitet), binære (2 entiteter) og tertiære (3 entiteter) relationer.
Rekursive relationer forbinder således en entitet med sig selv:
Hund er
hvalp af
Binære relationer forbinder to entiteter. Det er klart den mest almindelige
relationstype:
Mand
Tertiære relationer forbinder 3 entiteter:
medikament
m1
er gift
med
Side: 2 af 7
land
m har licens
til at sælge
m1 i land
Kvinde
medicinalfirma
m

Webprogrammering –Netteknologi A.
Note vedr. E/R diagrammer til Databaser
Relationsgrader
DTU 9. oktober 2007
Relationsgraden (også kaldet kardinaliteten) er en beskrivelse af antalsforholdet
mellem entitetsforekomsterne ved en relation:
11 1
hundefører
Relationsgraden 1:1
fører en
1
hund
Relationsgraden er 1:1 (læses: ”en til en”). Én hundefører fører højest 1 hund. Og én
hund føres højest af én hundefører. Læg mærke til at kardinaliteten først er tolket fuldt
ud når man har prøvet fra begge sider (eksemplet dækker bedst på 1 blind med 1 førerhund eller
en tolder med en narkohund – glem alt om slædehunde på/i Grønland) .
hund
N
Relationsgraden 1:N
kommer
fra
1
kennel
Her ved relationsgraden 1:N (læses: ”én til N” eller ”1 til mange”) er det lettere at se
noget om læseretningen. Man hiver først fat i én hund for at finde ud af hvor mange
kennelerm den kan stamme fra – så skriver man 1 ovre ved kennel. Så tager man fat i
kennel og finder ud af hvor mange hunde, der kan stamme fra den - så skriver man
N for mange ovre ved hund – det var jo et antal hunde, man havde fundet frem til.
hund
Relationsgraden N:M
N har
behandlet
M
dyrlæge
Dette diagram skal mht. til relationsgraden tolkes således: Relationsgraden er N:M
(læses ”N til M” eller ”mange til mange”). En hund kan have været til konsultation
hos mange forskellige dyrlæger og en dyrlæge kan have haft mange forskellige hunde
i behandling. Grunden til, at man ikke bruger N begge steder, er for at tydeliggøre at
der ikke nødvendigvis er tale om det samme antal hunde og dyrlæger i relationen.
Side: 3 af 7

Webprogrammering –Netteknologi A.
Note vedr. E/R diagrammer til Databaser
Medlemstyper
DTU 9. oktober 2007
Medlemstypen angiver, om entitetsforekomsterne i en entitet skal deltage i en bestemt
relation. Er medlemstypen obligatorisk, skal alle entitetsforekomster deltage i
relationen. Er medlemstypen frivillig, kan der godt findes en entitetsforekomst der
ikke deltager i relationen.
dyrlæge
N
har
behandlet
M
Obligatorisk
Medlem
Fed streg
hund
Vi kan godt forestille os en hund, der aldrig har været til dyrlæge. Men det er svært at
være dyrlæge uden at have behandlet flere hunde………
kunde
har
afgivet
ordre
En ordre kan ikke eksistere uden en kunde, (hvordan skal ordren ellers kunne
ekspederes) - men en kunde kan godt oprettes uden afgivelse af en ordre.
Eksempel: Vi reflekterer på en henvendelse – hvorefter vi fremsender reklamer –
tilbud – kataloger. Dette sker inden ordren afgives og måske fører det aldrig til en
ordre – men vi opretter den potentielle kunde i vores database.
Hvorfor skal relationstyper, relationsgrader og medlemstyper bestemmes?
Det kan virke besværligt – så der skulle gerne være en god grund til, at vi gør det.
For det første får man beskrevet integritetsreglerne for området meget præcist. Det er
eksempelvis rart at vide, om kunder først oprettes, når de har afgivet en ordre, eller
allerede på dét tidspunkt, hvor de rekvirerer et katalog. Sådan noget vil blive afklaret
ved fastsættelsen af medlemstyper.
For det andet skal man på et tidspunkt tage stilling til om nogle af entiteterne og
relationstyperne kan reduceres. At en entitet eller en relation reduceres vil sige at den
ikke bliver til en tabel i den endelige database – attributterne flyttes i stedet ud i en af
Side: 4 af 7

Webprogrammering –Netteknologi A.
Note vedr. E/R diagrammer til Databaser
DTU 9. oktober 2007
de andre tabeller. Ganske bestemte regler skal være overholdt for at man kan tillade
sig at reducere:
En relation kan reduceres, hvis relationstypen er rekursiv eller binær, medlemstypen
er obligatorisk i mindst en af siderne, og der på den anden side står ”1” i
relationsgraden (kardinaliteten).
En entitet kan reduceres, hvis relationstypen er rekursiv eller binær, relationsgraden
er 1:1 og medlemstypen på begge sider er obligatorisk.
Hvis de nævnte regler ikke overholdes vil der opstå redundans (data, der forekommer
overflødigt mange gange) eller andre dårligdomme (anomalier).
3. Attributter.
Attributterne er de egenskaber ved entiteterne og relationerne, der skal gemmes dat
om i tabellerne. Attributterne er med andre ord tabellernes kolonneoverskrifter. De
skal bruges til at identificere og beskrive og listes i tabellerne.
Tabelskitsernes form ses af figuren: Først entitetens eller relationens navn og så i
parentes bagefter en liste med alle attributterne adskilt med komma.
KUNDE
1
Har
afgivet
N
ORDRE
Ordredatamodellen:
KUNDE (kundenr, fornavn, efternavn, tlfnr, …)
ORDRE (ordrenr, kundenr, ordredato,….)
VARE (varenr, varenavn, enhedspris, ….)
ORDRE_OMFATTER_VARE (ordrenr, varenr, antal)
N
Side: 5 af 7
omfatter
M
VARE

Webprogrammering –Netteknologi A.
Note vedr. E/R diagrammer til Databaser
DTU 9. oktober 2007
Attributterne bruges som sagt bl.a. til at identificere de enkelte rækker/forekomster i
tabellen. I dén forbindelse taler man om ”nøgleattributter” eller blot ”nøgler”. Man
taler om flere forskellige slags nøgler:
En kandidatnøgle er en eller flere attributter, som entydigt kan udpege
rækkeforekomster i deres tabel. Der må ikke være flere attributter med end
nødvendigt (Eksempel: kundenr, fornavn+efternavn og tlfnr i KUNDE).
En primærnøgle er den kandidatnøgle, der er blevet valgt som den vigtigste
identifikation af tabellens rækker. Den markeres med en understregning i
tabelskitsen (eksempel: kundenr. i KUNDE).
Set lidt i bakspejlet er kandidatnøglerne altså attributter eller attributkombinationer,
som kan bruges som primærnøgle – deraf navnet.
En alternativ nøgle er en kandidatnøgle der ikke er blevet valgt som
primærnøgle (eksempel: fornavn + efternavn og tlfnr i KUNDE).
En sammensat nøgle er en nøgle, der er sat sammen af flere attributter
(eksempel: fornavn + efternavn i KUNDE).
En fremmednøgle er en eller flere attributter, der indeholder en værdi, der står
som primærnøgle i en anden tabel eller i en anden række i samme tabel.
Fremmednøgler markeres med kursiv i tabelskitserne (evt. ved stiplet
understregning i håndskrevne tabelskitser). Eksempel: kundenr i ORDRE,
ordrenr og varenr i VARE.
Kandidatnøgler
Primærnøgle
Alternative nøgler
x x x x
x x
Læg mærke til at relationerne ofte implementeres med en sammensat primærnøgle,
der består af fremmednøgler, som peger på de entiteter, der indgår i relationen.
Attributter kaldes i daglig tale også for felter. (I Java bliver attributter implementeret
som variable ).
Side: 6 af 7

Webprogrammering –Netteknologi A.
Note vedr. E/R diagrammer til Databaser
Find entiteter, relationer og attributter
DTU 9. oktober 2007
I visse tilfælde kan det være vanskeligt at vide om man står med en entitet, en relation
eller en attribut. Så kan man gribe til følgende beskrivelser af de sproglige
sammenhænge:
Entiteter:
Navneord, der beskriver noget, der kan identificeres, som der er behov for at
gemme information om, som overholder et fast regelsæt, og som har et fast
sæt af egenskaber.
Relationer:
Udsagnsord i sætninger, hvor navnet på to eller flere entiteter indgår
(Studerende låner bøger).
Attributter:
Navneord, der kan udtrykke en egenskab ved en entitet – herunder:
-navneord, som kan antage en værdi (vægt, pris, antal …)
-sammensatte navneord, hvor første led er en entitet ( Varepris o.l.)
-sammensatte navneord, hvor sidste led er ”id”, nr”, ”kode” el.lign.
-ofte kandidatnøgler
RESUMÉ
Vi skal opfatte E/R-diagrammerne som en alternativ datamodelleringsmetode eller
værktøj. Det meget anvendeligt til kommunikation med kunden, som vi vil lave
databasen til. Det kræver at vi sætter kunden/brugen ind i tegnereglerne.
Vi kan så afstemme virksomhedens måde at opfatte virkeligheden på med vores
model.
Når vi har det færdige E/R-diagram (godkendt af kunden) – går vi i gang med
implementeringen kombineret med de reduceringer, der er beskrevet på side 4 og 5.
(konkret ser vi i ordredatamodellen, hvordan relationen afgivet bliver reduceret bort
ved, at primærnøglen på 1’er-siden bliver fremmednøgle på n-siden, sagt på en
anden måde kundenr bliver fremmednøgle i ORDRE – dette opretholder relationen
mellem de 2 entiteter KUNDE og ORDRE.
(Dette kunne kun lade sig gøre fordi ???? obligatorisk medlemskab af ORDRE til …)
Når vi implementerer og reducerer efter de givne regler, får vi som hovedregel
”foræret” en database på 3 normalform. Dette kan man dog ikke være helt sikker på.
Derfor er det en god idé, at løbe normaliserings betingelserne igennem på den model
man ender op med.
Side: 7 af 7
DTU – 9/10 2007
Finn Gustafsson