1

ER-modellen

Diagram for å representere design Entitet, ”ting” Attributt = eigenskap til entitet Entitet kan ha ein eller fleire attributtar Entitets-sett, samling av liknande entitetar Ein nøkkel er eit sett av attributtar der verdiane

kan tilhøyre kun ein entitet Relasjonar mellom entitets-sett

(Entity-Relationship)

2

Roller i relasjonsforhold

Mogleg for eit entitetssett å førekome to eller fleire gongar i eit enkelt relasjonsforhold.

Kvar linje til entitetsett representerer forskjellig rolle. Navngjev desse.

Eks: – Film-entitets-sett. – Relasjon oppfølgjar. – Film kan ha mange

oppfølgjarar. – Ein oppfølgjar har kun ein

original.

Original Oppfølgjar

Rambo Rambo 2

Rambo Rambo 3

Die Hard Die Hard 2Film

oppfølgjar_til

oppfølgjar original

(Ein original, men fleire oppfølgjarar)

3

Subklasser

Ofte har eit entitetsett entitetar som har eigenskapar som ikkje alle dei andre entitetane har

Kan då definere spesial-tilfelle entitetssett, eller subklasser Spesialtilfelle av relasjonar. Spesialsymbol, triangel Subklasse = spesialtilfelle = færre entitetar = fleire eigenskapar Kan ha eigne spesialattributtar og/eller relasjonar Eksempe 1:

– Lastebil er ein type bil– Alle bilar er ikkje lastebilar, men nokre er...– Kan gå ut frå at lastebil har attributtar i tillegg til dei som bil har, t.d.

lastekapasitet Eksempel 2:

– IDI-tilsett subklassa til Forelesar/Ingeniør/Adm

Bil

Lastebil

4

Nokre designprinsipp

Unngå redundans– Oppstår når vi seier det same på to (eller fleire) måtar

– Sløser med plass

– Viktigare: ”oppmuntrar” til inkonsistens:

To instansar av same fakta kan verte inkonsistent om vi

endrer ein, men gløymer å endre den andre relaterte versjonen

Ikkje bruk entitetssett når ein attributt gjer nytta Ikkje over-bruk svake entitetstypar Ikkje over-bruk subklassing

5

Eksempel:

Fag PersonForelestAv

fagnavn navn email

Dette designet gjev navn til forelesar eksakt ein stad

Godt design!

(1,1) (0,N)

6

Eksempel:

Problem: Forekomst av forelesarnavn to stadar Dårleg design!

Fag PersonForelestAv

fagnavn navn

forelesar

email

(1,N) (0,N)

7

Eksempel:

Repeterer faglærarnavn ein gong for kvart fag, personen si emailadresse forsvinn frå databasen om han/ho midlertidig ikkje foreleser

Dårleg design!

Fag

fagnavn

forelesar email

8

Entitetssett vs. attributtar

Eit entitetssett skal tilfredsstille minst eit av følgjande vilkår:– Det er meir enn berre ”navnet på noko”, det skal ha

minst ein attributt i tillegg til nøkkel

eller

– det er det ”mange” i ein mange-til-ein eller mange-til-mange relasjon

9

Eksempel:

Person fortener å vere entitetssett pga. ikkje-nøkkel-attributten email

Fag fortener¨å vere entitetssett pga. at det er ”mange” i ein mange-til-ein-relasjon ForelestAv (unngår dermed kopi av personopplysningar for kvart fag)

Godt design!

Fag PersonForelestAv

fagnavn navn email

(1,1) (0,N)

10

Eksempel:

I dette tilfellet har vi ingen ekstra informasjon om forelesarIkkje nødvendig å gjere forelesar til eige entitetssett, pga. vi kun lagrer navnet hans/hennar.

OK design.

Fag

fagnavnforelesarnavn

11

Ikkje over-bruk svake entitetstypar

I praksis kan vert det laga nøklar for dei fleste entitetstypar:– Personnummer

– Registreringsnummer

– ... Når treng vi svake entitetstypar?

– Når det ikkje finnast global autoritet som kan generere unike ID’ar

– Eksempel: Nummer på fotballspelarar

12

Ikkje over-bruk subklassing

Utgangspunkt: – Må gje meining, subklassene må ha noko til felles– Vil vanlegvis vere relatert også i den verkelege

verden Ikkje alltid fornuftig med subklassing sjølv om

klassene er relatert i den verkelege verden– Typisk eksempel: La alle entitetsklasser som

representerer personar arve frå Personar Kan også vere direkte feil, t.d. Bildekk

subklasse av Bil

13

Eksempel: Internettleverandøren GentleNet

Kundehandsamingsdatabase To typar kundar, private og firma. Skal ein kunne lagre adresse og telefonnummer for

privatkundar, medan ein for firma også kontaktperson. GentleNet tilbyr epost-kontoar til privatkundar (opptil

5 pr. kunde), informasjon om desse kontoane skal også lagrast. Vert ikkje gjort for firmakundar.

Både eksisterande og tidlegare kundar skal kunne lagrast i databasen

Ein kunde kan ha eitt eller fleire abonnement

14

GentleNet (forts.) Fleire abonnementstypar/produkt, der kvar type har eit

namn, internett-hastigheit, og pris. GentleNet har ei mengde tilsette, som tilhøyrer

salsavdeling, kundestøtte, eller administrasjon. For å betre kunde-oppfølgjing lagrar ein kva seljar som har

selt eit abonnement til ein kunde. Eit av dei store problema for GentleNet har vore

handsaming av klager. For å betre på dette vil ein no for kvar klage som kjem inn tilordne ein tilsett i kundestøtte-avdelinga til klagen.

Av og til vil ein klageførespurnad vere relatert til ein tidlegare klage. For å avdekke slike tilfeller skal databasen også kunne lagre samanhengen mellom klager.