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-7 Komposisjon side 8 Aggregering side 9 Se ellers læreboka, side 99-22 Forelesning 6, Uke 38 Oppsummering: Å oversette fra ER-modell til relasjonsmodell. 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. Sett på UNIQUE-krav i CREATE TABLE-setningen for å sikre entydigheten. Se side 93 i læreboka. 3. Oversett en-til-mange-sammenhengstyper ved å legge inn fremmednøkkel på mange-siden i forholdet. Se side 95. 4. Mange-til-mange-sammenhengstyper gir alltid opphav til en egen relasjon ("koplingstabell"). Se side 97-99. Fremmednøkler fra begge sidene kommer inn og danner til sammen primærnøkkelen i en slik relasjon. Det er mulig med ekstra attributter i tillegg, da vises det i ER-modellen ved en entitetstype med stiplet linje fram til den aktuelle sammenhengstypen. (Alternativt kan man ha løpenummer som primærnøkkel. Fremmednøklene må likevel være med. Sett da på UNIQUE-krav i CREATE TABLE-setningen, eksempel: CONSTRAINT unique_constr UNIQUE(lev_nr, prod_nr))) 5. I dag kommer flere regler: Hvordan overføre objektorientering fra UML-diagrammet til relasjonsmodellen? side 2
Spesialisering og generalisering 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. Oversetter til relasjonsmodellen: person(person_id, etternavn, fornavn, adresse) forelder(person_id*, telefon_jobb, telefon_hjemme, stilling) elev(person_id*, fodselsdato, morsmaal) insert into person values(00, Olsen, Arne, xxx ) insert into elev values(00, 0092002, bokmål ) select * from person, elev where person.person_id = elev.person_id; Skisser SQL-setninger for innlegging av ny forelder/laerer/elev uthenting av all info om en forelder/laerer/elev side 3 Overlappende / disjunkte delmengder {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. Kan kravet om disjunkte mengder framkomme i relasjonsmodellen, eventuelt ved generering av databasen med SQL? Nei. Vi skal senere se hvordan slike krav kan programmeres som person(person_id, etternavn, fornavn, adresse) del av database-skjemaet. forelder(person_id*, telefon_jobb, telefon_hjemme, stilling) elev(person_id*, fodselsdato, morsmaal) side 4 2
Total/delvis deltakelse {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. Kan disse kravene framkomme i relasjonsmodellen, eventuelt ved generering av databasen med SQL? Nei. Vi skal senere se hvordan slike krav kan programmeres som person(person_id, etternavn, fornavn, adresse) del av database-skjemaet. forelder(person_id*, telefon_jobb, telefon_hjemme, stilling, status) elev(person_id*, fodselsdato, maalform) side 5 Restriksjoner på spesialiseringen kan kombineres Disjunkt (OR) Overlappende (AND) Delvis En superentitet deltar i 0 eller subentitetstype (0..) En superentitet kan, men behøver ikke, delta i eller flere subentitetstyper () Total En superentitet deltar i eksakt subentitetstype () En superentitet deltar i minst subentitetstyper (..*) side 6 3
Et større eksempel 3..7..* Deltaker +delt_id {PK} +deltart i +epost +leder Sesjon +sesjons_id {PK} +tittel +start_tid +varighet {total, OR} deltaker(delt_id, fornavn, etternavn, epost) sesjon(sesjons_id, tittel, start_tid, varighet, ledes_av_delt_id*) paneldebatt(sesjons_id*) foredrag(sesjons_id*, sammendrag) fellesforedrag(sesjons_id*, aapent) spesialforedrag(sesjons_id*, maalgruppe) deltaker_spesialforedrag(delt_id*, sesjons_id*) deltaker_paneldebatt(delt_id*, sesjons_id*) (alternativt: paneldebatt(sesjons_id*, delt*, delt2*,, delt7*)) +deltar i - Paneldebatt Foredrag -sammendrag {total, OR} (Deltakere på fellesforedrag trenger ikke registreres) Fellesforedrag -aapent Spesialforedrag -maalgruppe 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,...) annonse(annonse_nr,..., avisnavn*) NOT NULL Identitetsavhengighet Forskjell mellom de to - - modellene? Støtte i relasjonsmodellen og SQL for komposisjon? For eksistensavhengighet? For identitetsavhengighet? prosjekt(prosjnr, prosjektnavn, budsjett, forbruk) prosjektrapport(prosjnr*, dato, tittel, forfattere, sammendrag, innhold) side 8 4
avis(avisnavn,...) annonse(annonse_nr,..., avisnavn*) Forskjell mellom de to -- modellene? Figuren til høyre: kan inngå i andre sammenhenger, det er (vanligvis) ikke tilfelle for figuren til venstre. Støtte i relasjonsmodellen og SQL for komposisjon? ON CASCADE DELETE. Ikke mulig å hindre at annonse_nr blir fremmednøkkel. For eksistensavhengighet? Sett NOT NULL på fremmednøkkelen. For identitetsavhengighet? La fremmednøkkelen være en 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? Ingenting / svært lite. Husstand +husstand_id {PK} +boareal 0.. +består_av kan være NULL +epost husstand(husstand_id, adresse, boareal) person(person_id, etternavn, fornavn, epost, husstand_id*) side 0 5