ER-modellen

1. (Entity-Relationship) 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

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. Film oppfølgjar original oppfølgjar_til (Ein original, men fleire oppfølgjarar)

3. Lastebil Bil 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

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: fagnavn navn email ForelestAv Fag Person (1,1) (0,N) Dette designet gjev navn til forelesar eksakt ein stad Godt design!

6. Eksempel: fagnavn navn email • Problem: Forekomst av forelesarnavn to stadar • Dårleg design! ForelestAv Fag Person (0,N) (1,N) forelesar

7. fagnavn Fag forelesar email Eksempel: • Repeterer faglærarnavn ein gong for kvart fag, personen si emailadresse forsvinn frå databasen om han/ho midlertidig ikkje foreleser • Dårleg design!

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. fagnavn navn email ForelestAv Fag Person (0,N) (1,1) 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!

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. fagnavn forelesarnavn Fag

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.