LC238D Datamodellering og databaser http://www.aitel.hist.no/fag/_dmdb/ Objektorientering i ER-modeller EER-modeller Enhanced Entity Relationship Models Oppsummering: Å oversette fra ER- til relasjonsmodell side 2 Spesialisering og generalisering side 3-6 Komposisjon side 7 Aggregering side 8 Se ellers læreboka, side 199-212 Forelesning 6, Uke 39
Oppsummering: Å oversette fra ER-modell til relasjonsmodell 1. Lag en relasjon pr. entitetstype. 2. Oversett en-til-en-sammenhengstyper ved å legge inn fremmednøkkel på den ene av sidene. Hvis det er eksistensavhengighet (NOT NULL) på en av sidene, skal denne brukes. UNIQUE på fremmednøkkelen sikrer 1-multiplisiteten på motsatt side. Se side 193 i læreboka. Andelseier +and_eier_nr {PK} +telefon +ansiennitet +bebos_av 1..1 +kan_ha Leilighet +leil_nr {PK} +ant_rom +ant_kvm +etasje andelseier(and_eier_nr, fornavn, etternavn, telefon, ansiennitet) leilighet(leil_nr, ant_rom, ant_kvm, etasje, and_eier_nr*) 0..1 3. Oversett en-til-mange-sammenhengstyper ved å legge inn fremmednøkkel på mange-siden i forholdet. Se side 195. Student +studnr {PK} +adresse +bor på 1..1 Poststed +postnr {PK} +sted 4. Mange-til-mange-sammenhengstyper gir alltid opphav til en egen relasjon ("koplingstabell"). Se side 197-199. Fremmednøkler fra begge sidene kommer inn og danner til sammen primærnøkkelen i en slik relasjon. (Alternativt kan man ha løpenummer som primærnøkkel. Fremmednøklene må likevel være med.) Det er mulig med ekstra attributter i tillegg, da vises det i ERmodellen ved en entitetstype med stiplet linje fram til den aktuelle sammenhengstypen. Eksempler på sammenhenger mellom tre entitetstyper (trinær sammenheng) samt entiteter av samme type (rekursjon og nettverk), samt identitetsavhengighet, se forelesning 4. I dag kommer flere regler: Hvordan overføre objektorientering fra UML-diagrammet til relasjonsmodellen? Enhanced Entity Relationship (EER) student(studnr, fornavn, etternavn, adresse, postnr*) poststed(postnr, sted) student(studnr, etternavn, fornavn, adresse, telefon, fdato, epost) fag(fagkode, fagnavn, eks_dato, vekttall, brukernavn, passord) fagvalg(studnr*, fagkode*) side 2
Spesialisering er prosessen for å finne forskjellene mellom entitetstyper ved å identifisere karakteristiske trekk ved dem. Generalisering er prosessen som går ut på å redusere forskjellene mellom entitetstyper ved å identifisere deres fellestrekk. Spesialisering viser roller. Spesialisering og generalisering Forelder +telefon_jobb +telefon_hjemme +stilling Person +person_id {PK} +adresse Laerer +telefon_kontor +utdanning +ansiennitet Elev +foedselsdato +morsmaal Oversetter til relasjonsmodellen: erson(person_id, etternavn, fornavn, adresse) orelder(person_id*, telefon_jobb, telefon_hjemme, stilling) aerer(person_id*, telefon_kontor, utdanning, ansiennitet) lev(person_id*, fodselsdato, morsmaal) Skisser SQL-setninger for innlegging av ny forelder/laerer/elev uthenting av all info om en forelder/ insert into person values(1, Ås, Ole, xxx); insert into forelder(1, 99, 88, xxx ); insert into laerer(1, 77, yyy, 10); select * from person, forelder where person.persnr = forelder.persnr and fornavn = Ole and etternavn = Ås ; side 3
Overlappende / disjunkte delmengder Person +person_id {PK} +adresse {AND} {AND} betyr overlappende spesialisering, dvs at en person kan være f. eks. både forelder og lærer. {OR} betyr disjunkt spesialisering, dvs at hver person enten er forelder, lærer eller elev. Forelder +telefon_jobb +telefon_hjemme +stilling Laerer +telefon_kontor +utdanning +ansiennitet Elev +foedselsdato +morsmaal Kan kravet om disjunkte mengder framkomme i relasjonsmodellen (NEI), eventuelt ved generering av databasen med SQL (NEI)? Men vi skal i siste del av kurset se erson(person_id, etternavn, fornavn, adresse) hvordan vi kan programmere dette orelder(person_id*, telefon_jobb, telefon_hjemme, stilling) som et krav i databasen. aerer(person_id*, telefon_kontor, utdanning, ansiennitet) lev(person_id*, fodselsdato, morsmaal) side 4
Total/delvis deltakelse Person +person_id {PK} +adresse {delvis} Delvis deltakelse betyr at det kan finnes entiteter i superentitetstypen som ikke er med i noen av subentitetstypene. Total deltakelse betyr at alle entitetene i superentitetstypen må være med i minst en av subentitetstypene. Forelder +telefon_jobb +telefon_hjemme +stilling Laerer +telefon_kontor +utdanning +ansiennitet Elev +foedselsdato +morsmaal Kan kravet om total deltakelse framkomme i relasjonsmodellen (NEI), eventuelt ved generering av databasen med SQL (NEI)? Men vi skal i siste del av kurset se hvordan vi kan programmere dette som et krav i databasen. person(person_id, etternavn, fornavn, adresse) forelder(person_id*, telefon_jobb, telefon_hjemme, stilling, status) laerer(person_id*, telefon_kontor, utdanning, ansiennitet) elev(person_id*, fodselsdato, maalform) side 5
Restriksjoner på spesialiseringen kan kombineres Disjunkt (OR) Overlappende (AND) Delvis En superentitet deltar i 0 eller 1 subentitetstype (0..1) En superentitet kan, men behøver ikke, delta i 1 eller flere subentitetstyper () Total En superentitet deltar i eksakt 1 subentitetstype (1..1) En superentitet deltar i minst 1 subentitetstyper (1..*) side 6
Et større eksempel Deltaker 1..* 3..7 +delt_id {PK} +epost 1..1 +deltart i deltaker(delt_id, fornavn, etternavn, epost sesjon(sesjons_id, tittel, start_tid, varighet, ledes_av_delt_id* Sesjon +leder +sesjons_id {PK} +tittel +start_tid +varighet {total, OR} paneldebatt(sesjons_id*, foredrag(sesjons_id*, sammendrag fellesforedrag(sesjons_id*, aapent spesialforedrag(sesjons_id*, maalgruppe +deltar i - Paneldebatt Foredrag -sammendrag {total, OR} delt_spes_foredrag(sesjons_id*, delt_id*) Fellesforedrag -aapent Spesialforedrag -maalgruppe delt_paneldeb(sesjonsid*, delt_id*) side 7
Komposisjon En komposisjon er en meget sterk en-del-av-binding. Delene kan ikke leve uten at den delen de inngår i eksisterer. Delene kan kun inngå i én kompositt. Komposisjon innebærer eksistensavhengighet. Avis +avisnavn {PK} +fins_i 1 +har Annonse +annonse_nr {PK} +tekst +tlf_kunde +pris +dato avis(avisnavn,...) annonse(annonse_nr,..., avisnavn*) NOT NULL Avis +avisnavn {PK} +fins_i 1..1 +har Annonse +annonse_nr {PK} +tekst +tlf_kunde +pris +dato Forskjell mellom de to Avis- Annonse- modellene? I det nederste tilfellet kan Annonse inngå i andre sammenhenger. I en komposisjon er dette (vanligvis) ikke tilfelle. Støtte i relasjonsmodellen og SQL for komposisjon? Nei, ikke hvis vi holder oss til det strenge kravet at Annonse ikke skal kunne delta i andre sammenhenger. For eksistensavhengighet? Ja, ved å sette NOT NULL på fremmednøkkelen. Konklusjon. Unngå å bruke komposisjon i ER-modeller. side 8
Identitetsavhengighet prosjekt(prosjnr, prosjektnavn, budsjett, forbruk) prosjektrapport(prosjnr*, dato, tittel, forfattere, sammendrag, innhold) Videreføres i relasjonsmodell opg SQL ved å la fremmednøkkelen være del av primærnøkkelen.
Aggregering Aggregering er en løsere sammenheng enn komposisjon. De enkelte delene kan leve videre selv om den entiteten de er en del av, forsvinner. Hva skiller dette fra en vanlig sammenheng, dvs en strek uten aggregerings-rombe? I praksis ingenting. Husstand +husstand_id {PK} +adresse +boareal 0..1 +består_av kan være NULL Person +person_id {PK} +epost husstand(husstand_id, adresse, boareal) person(person_id, etternavn, fornavn, epost, husstand_id*) side 10