Datamodellering noen temaer

Transkript

1 Datamodellering noen temaer Disse notatene er kun en oversikt over en del prinsipielt stoff innen datamodellering. Disse må kompletteres med mer om aktuell(e) notasjon(er) som brukes (her finnes bare en grov oversikt). mer om vanlige struktur (noen eksempler, uten forklaring finnes i de siste sidene) mer om dette kommer på forelesningene. Litt om datamodellering Edgar Bostrøm. Versjon 1.4, vår

2 Datamodellering prinsippielt Hva er en datamodell? Noen fokuserer på Beskrivelse av en informasjonsstruktur Andre på Tegning av en databasestruktur Mest vanlig bruk i praksis: Ideer, behov m.m. for strukturering av informasjon Diskusjon, retting, mer diskusjon, forbedring, etc. Sted Omfattende løsning, men noen detaljer er kuttet ut. Postnr Poststed snavn hører til Bilmerke Datamodellering: Det av systemanalyse / planlegging / systemering Selskap Rabattype Selskap Rabattprosent Rabattypetekst SendesTil Sendetekst Egenandel *Selskap *Rabattypetekst Egenandelbeløp Årsakstype Årssakteller Årsaknavn Bil Kunde Kundenr Kundenavn Adresse *Postnr bileier fører Assistanse Assistansenr *Selskap *Rabattypetekst *Registreringsnr KmStand UtførtAssistanse Anmerkning *Sendetekst Starttid Sluttid *Kundenr Bergingsbil Bilmerkenavn Biltypenavn Registreringsnr *snavn *Bilmerkenavn Forventet_inn_kl AssistanseBil Tjenestetype *Registreringsnr *Assistansenr Tjenestenavn Dekningsområde Lengdetype Tidkategori rekvireres fra Lengdekategori Tidkode Tidtekst Biltype Biltypekode Biltypenavn Tjeneste_i_kategori Tjenestenr *Lengdekategori CREATE TABLE Gruppe ( Gruppenr Integer NOT NULL, Gruppenavn Varchar(30), PRIMARY KEY ( Gruppenr ) ); CREATE TABLE Student ( Gruppenr Int NOT NULL, NrInnenGruppe Int NOT NULL, Databasedefinisjon Fornavn Varchar(20), Etternavn Varchar(20), Telefonnr Varchar(20), DBkunnskap Varchar(100), Postnr Varchar(4), PRIMARY KEY ( Gruppenr, NrInnenGruppe ) ); CREATE TABLE Sted ( Postnr Varchar(4), Utvikling av grafisk brukergrensesnitt Litt om datamodellering Edgar Bostrøm. Versjon 1.4, vår

3 Fra enkeltforekomster til typer / klasser av ting "Ting" "Data om ting" Klassifikasjonsretning K l a s s e F o r e k o m s t e r Ansatt Ansatt Ansattnr Ansattnav n 6723 Per 2134 Hans 3154 Ole 3265 Per Generali sering Beskrivelse Symbol Formelt begrep Type/klasse av tingen (hele boksen) Navn på denne klassifikasjonen Ansatt Interessante data for denne typen/klassen Ansattnr Ansattnav n entitetstype attributter entitetstypenavn Litt om datamodellering Edgar Bostrøm. Versjon 1.4, vår

4 Fra enkeltsammenhenger til typer / klasser av sammenhenger Per 2134 Hans 3154 Ole 3265 Per jobber i jobber i jobber i jobber i 1 Klær 2 Jernvare 3 Sko Hver av strekene er en relasjon mellom to "ting". Siden disse er mellom de samme ting av samme type, er det naturlig å gjøre en tilsvarende klassifikasjon som vi gjorde for entitetstyper. Hvis vi forutsetter at hver ansatt jobber i en og bare en avdeling, og at avdelinger i alle fall av og til kan være uten ansette, ser vi at denne relasjonstypen blir min. 0 max. mange på venstre side, min. 1, max. 1 på høyre side, altså: Ansatt jobber i (i kråkefot-dialekt ) Litt om datamodellering Edgar Bostrøm. Versjon 1.4, vår

5 Litt om maksima og minima, 1 Vi ønsker altså å kartlegge hvor mange av noe som er knyttet til noe annet : er det noen begrensninger i hvor mange av noe som kan knyttes til noe annet - dvs. maksimalt antall. Vanligvis er det snakk om o maksimum 1 o maksimum mange, dvs. ingen begrensninger på hvor mange. er det noen begrensninger i hvor få av noe som kan knyttes til noe annet dvs. minimalt antall. Vanligvis er det snakk om o minimum 0, dvs. ingen begrensninger på hvor få KAN o minimum 1, m.a.o. at noe må være knyttet til minst en annen MÅ I noen tilfelle er det interessant å oppgi et bestemt antall, f.eks. at en bil kan ha minimum 3, maksimum 4 hjul. Slikt må imidlertid spesialbehandles i databasen (via såkalte triggere), i applikasjonen som bruker databasen eller i program mellom databasen og applikasjonen. Videreføring av eksempelet over: hvor mange minimalt? hvor mange maksimalt? Ansatt jobber i har Fra til Ansatt: Hvis der er slik at hver avdeling kan ha fra 0 til uendelig mange ansatte, kan dette mer formelt skrives som: har minimum 0, maksimum mange Ansatt o bør vi anta at alle avdelinger har minst en ansatt? P.d.a.s. kan det kanskje finnes nyopprettede avdelinger uten ansatte? Fra Ansatt til : Hvis hver ansatt må jobbe i en gitt avdeling, og at den ansatte også maksimalt kan jobbe i en avdeling, blir det mer formelt: Ansatt jobber i minimum 1, maksimum 1 Men: er dette eneste mulighet? eppe! Litt om datamodellering Edgar Bostrøm. Versjon 1.4, vår

6 Ansatt jobber i minimum 1, maksimum 1 o (som over) Ansatt jobber i minimum 0, maksimum 1 o (det er en eller flere som ikke er koblet til noen avdeling) Ansatt jobber i minimum 1, maksimum mange o (fordeler arbeidstiden mellom 1 eller flere avdelinger) Ansatt jobber i minimum 0, maksimum m o (fordeler arbeidstiden mellom 0 eller flere avdelinger) Hva som er riktig vil selvsagt avhenge av hva som er situasjonen i det firmaet vi skal lage databasen for, dvs. for oppdragiveren. Dette må vi finne ut ved samtale med oppdragsgiveren, eller fra en skriftlig beskrivelse av det påtenkte systemet. B: oen er svært nøye med alltid å spesifisere både maksimum og minimum, andre spesifiserer stort sett bare maksimum. Oppsummert: vanlige minima og maksima Minimalt antall: vanligvis 0 (ingen begrensning) eller 1. Maximalt antall: vanligvis 1 eller mange (ingen begrensning) mange. Hvor få minimalt (Min) 0 1 [ Hvor mange maksimalt (Max) 1 mange == > Min 0, max mange er egentlig ikke noen begrensning i det hele tatt. Minimum og maksimum vises på ulik måte i ulike datamodelleringsdialekter. Litt om datamodellering Edgar Bostrøm. Versjon 1.4, vår

7 Grunnleggende notasjon, som kråkefot hhv. UML-basert. Kråkefot UML-basert jobber i Ansatt Entitetstype/klasse Relasjonstype max 1 min. 1 min 0 max mange verb/rolle som beskriver hva rel. gjelder (en eller begge veier) Minimum kan sløyfes, men gir mindre nøyaktig modell. Verb eller rolle kan sløyfes, men er ofte nyttig for å forstå hva relasjonstypen gjelder. Merk parallelliteten med vanlig språk, f.eks: Ansatt jobber i min. 1, max. 1 og har min 0, max mange Ansatt. Entitet (-stype/-sklasse) (evt: bruker begrepet objektklasse også her) 1 (betyr min 1, max betyr min 0, max 1) jobber i * (betyr min 0, max m 1..* betyr min 1 max m) Ansatt Assosiasjon relasjonsnavn (en eller begge veier, viser retningen) Hvis minimum sløyfes, blir kan det være usikkert om 1 betyr min. 0 eller min. 1. Relasjonsnavn kan sløyfes, men er ofte nyttig for å forstå hva relasjonstypen gjelder. Notasjonen er en delmengde av klassediagram. o Fordel: samme notasjon. o Ulempe: man kan lett forledes til å tro at tankemåten ved modelleringen er lik. Litt om datamodellering Edgar Bostrøm. Versjon 1.4, vår

8 Med primærnøkkel (identifikator) og fremmednøkkel: Med primærnøkkel (identifikator) og fremmednøkkel: Ansatt Primærnøkkel (understreket) Primærnøkkel Ansattnr Fornavn Etternavn *snr Fremmednøkkel (markeres med * eller stiplet linje snr) Ansatt Ansattnr {PK} Fornavn Etternavn snr {FK} Fremmednøkkel Brukes ikke (og tas derfor ofte heller ikke med), er for operasjonener i en OO modell. Opplysningene (tilsvarende kolonner i databasen) kalles vanligvis attributter. Legg merke til forskjellen Entitetstyper er tingene i seg selv, f.eks. en Ansatt. Attributtene er opplysninger/egenskaper om tingene, f.eks. Ansattnr, fornavn, alder, sivilstatus o.l. Dette kan på en eller annen måte gis en verdi. Primær- og fremmednøkler i modellen? Det er ulike meninger om man bør ha med primær- og fremmednøkler i datamodellen hele tiden (betyr at man tenker relasjonsdatabase hele tiden) etter hvert bare når (hvis) man skal overføre modellen til en database. Litt om datamodellering Edgar Bostrøm. Versjon 1.4, vår

9 Flere relasjoner mellom de samme entitetene (og dermed også typene/klassene) Det kan godt finnes flere relasjoner mellom de samme entitetene, og til og med relasjoner mellom to entiteter av samme type. Det siste kalles gjerne egenrelasjoner. 1 Klær 2 Jernvare jobber i Ansatt er leder for (i kråkefotdialekt ) jobber i er leder for er sjef til er sjef til På type-nivå har vi dermed Ansatt jobber i, Ansatt er leder for Ansatt er sjef til Ansatt. Relasjonstypene kan altså være av flere former: en-til-mange mange-til-mange en-til-en (må splittes før overføring til database) (relativt sjelden i praksis) Dessuten: alle-til-alle (beskrives sjelden i modeller, men etter min mening viktig!) Litt om datamodellering Edgar Bostrøm. Versjon 1.4, vår

10 Betegnelser er sjelden entydige! Med andre ord: Om forholdet mellom ting og navn på ting. Vi tror gjerne at begrep er temmelig entydige, og at man mener det samme eller samme ting med samme begrep. Dette er ofte ikke tilfelle. Vi bør derfor være nøye med begrepsbruk. Noen trivielle eksempler: Nederland Holland The Netherlands Norsk Rikskringkasting NRK Nårsk Rihkskringkrastring (feilstavet, men vi tenker på ) Norsk Riks Kringkasting Norges Røde Kors Røde Kors Raudekrossen Tegningene på venstre side brukes som bilde på selve tingene, mens navnene, eller betegnelsene står til høyre. Forholdet mellom "ting" og "navn på ting"/begreper er altså, sagt med en "kvasi"-datamodell: "Ting" "Begrep" Litt om datamodellering Edgar Bostrøm. Versjon 1.4, vår

11 Det finnes flere ulike dialekter, bl.a. Chen s opprinnelige notasjon: Kunde 1 1 Kunde -Ordre Kundenr Kundenavn m m Kundekontakt Ordre m Vare m Kontaktnavn Kunde- Kundekontakt Ordrelinje Antall Har bl.a. super / subtyper, sterke og svake entitetstyper m.m. Kan tegne på eller utelate attributter i modellen Se f.eks. Jeffrey A. Hoffer, Mary B. Prescott, Fred R. McFadden: Modern Database Management, 6/e Litt om datamodellering Edgar Bostrøm. Versjon 1.4, vår

12 Kråkefot: (er nærmest relasjonsdatabasetenkning, dermed enkel, men kan ikke beskrive alle avanserte deler.) Sted Gruppe Postnr Varchar(4) Poststed Varchar(30) Gruppenr Int Gruppenavn Varchar(30) Student *Gruppenr Int *NrInnenGruppe Int Fornavn Varchar(20) Etternavn Varchar(20) Telefonnr Varchar(20) DBkunnskap Varchar(100) *Postnr Varchar(4) Større modell: Sted Postnr Poststed Mulig gruppering:måleverdigenerator, Måleinstrument, syntese/ utviklingsverktøy Bruksområde Bruksområdenavn brukes i Utstyr Utstyrnr Utstyrnavn klassifiseres under Utstyrstype UtstyrstypeID Utstyrstypenavn NB! Har ikke splittet opp rene mange-til-mange-forhold. Disse er trivielle å ta siden, og tilfører ikke noe ekstra nytt til modellen. ISOtype OsoNr er gitt sertifisering til gjelder IsoFirma *Firmanr *IsoNr Fra_dato er poststed for arbeider innenfor Firma jobber i Firmanr Firmanavn Adresse *Postnr Akkrediteringnr Webadresse Firmaperson har kompetanse på PersonID *Firmanr Personnavn Epostadresse Kommentar Bransje Bransjenavn jobber innen tilbyr har har kompetanse for Firma_utstyr *Firmanr *Utstyrnr Firma_tjeneste finnes som *Firmanr *TjenesteID Akkreditert LeveranseAvtaleMåte LeveranseKrav Pris Tid_til_svar Tilbyr_veiledning Webadresse? Måleområde *Metodekode trengs til er aktuelt for bruker Testobjekt TestObjektID TestObjektNavn *OverTestObjektID brukes som Objekt_for_tjeneste *TestObjektID *TjenesteID Kommentar gjelder leveres av Kan tegne på eller utelate attributter i modellen. er aktuell for Hva_måles Hva_måles_ID Hva_kortnavn Hva_navn *Over_Hva_måles_ID Tjeneste klassifises under TjenesteID *TjenestetypeID *Hva_måles_ID i er aktuell for Tjenestetype Metode TjenestetypeID Typenavn Metodekode Kommentar MetodeNR IsoNr f.eks. prøving, salg/ utleie, kurs, utredning gjøres med Databasediagrammer som finnes i noen databasesystemer er i virkeligheten på kråkefot-form (selv om mange kanskje tegnes som el.l.). Se f.eks. Edgar Bostrøm: Datamodellering, praksis og teori. Litt om datamodellering Edgar Bostrøm. Versjon 1.4, vår

13 Forenkling av klassediagram fra UML, I: (Klassediagram er en sentral del av UML, Unified Modeling Language. Disse beskriver bl.a. objektklasser, med klassenavn attributter (data) operasjoner (metoder) Faktura Fakturanr Fakturadato. LagNy SkrivUt UtsettSending (antalldager) Hvis vi dropper operasjoner, kan dette ses på som et datamodelldiagram). Nesten kun med standard datamodellering : Litt om datamodellering Edgar Bostrøm. Versjon 1.4, vår

14 Forenkling av klassediagram fra UML, II: Mer omfattende eksempel, bl.a. med arv: Teknikken er mer omfattene (f.eks. arv, komposisjoner m.m.). I tillegg til det som er vist over, kan høyere ordens assosiasjoner (relasjoner) markeres med en rombe (som i Chens s notasjon) Se f.eks. Connolly & Begg: Database Systems (bruker egentlig en kombinasjon begreper fra UML og Chen). I tillegg finnes naturligvis en rekke bøker om UML, men disse er (i alle fall som regel) ikke fokusert på data/databaseaspelktet. Litt om datamodellering Edgar Bostrøm. Versjon 1.4, vår

15 IAM ( ijsen s InformasjonsAnalyse Metode) / ORM (Object Role Model) (svært presis, på attributtnivå, men kan bli på litt for detaljert nivå) Ansatt (ansattnr) jobber i har (avdelingsnr) Større modell: Kalles nødvendigskranken eller påkrevd rolle Avdnavn (avdnr) Prosjektnavn Ansatt (ansattn r) Prosjektdeltagelse Prosjekt (prosjektnr) Ansattna vn Uke (ukenr) Timer (timetall ) Beskrivel se avtalt timetall faktisk timetall denne uken Ressursnavn Ressurstype (ressurskat) Beløp Dato forbrukt beløp Se f.eks. Gerhard Skagestein: Systemutvikling. Cappelen forlag. 1. utgave. 2. utgave bruker UML-basert notasjon. Litt om datamodellering Edgar Bostrøm. Versjon 1.4, vår

16 Klassifikasjon av datamodelleringsdialekter (litt forenklet): Primært: attributtnivå The binary NIAM/ORM model (ikke tatt opp her. Enkelt sagt: tegn opp alle attributtene + sammenhenger) entitets- kråkefot Chen forenklet UML typenivå databasenært relasjoner kan ha kan beskrive mange egne attributter typer strukturer, bl.a. fra obj.orient. enkel å forstå vanskeligere å forstå Samtidig: den reelle utfordringen er å kunne bruke språket i komplekse sammenhenger, ikke å kunne symbolene. Litt om datamodellering Edgar Bostrøm. Versjon 1.4, vår

17 I tillegg er det naturligvis mange varianter, bl.a. Skal det gjøres et skille mellom ulike stadier av utviklingen (jf. tidligere). o konseptuell o logisk o fysisk design (databasetypeuavhengig) (databasetypeavhengig) (da er vi egentlig dypt nede i databasedesign) Symbolbruk og mekanismer. hvilke symboler skal i tilfelle brukes? hvorledes markeres en og mange? skal minima markeres, i tilfelle hvorledes? hvilke avanserte mekanismer bør finnes? hvilke skranker bør kunne modelleres? begrepsbruk: entiteter eller typer, -klasser? Relasjoner, sammenhenger eller assosiasjoner? Og: det finnes verktøy for tegning av datamodeller generelle tegneverktøy (du kan tegne alt mulig) verktøy for mange teknikker (f.eks. innen UML) spesialverktøy for datamodellering større eller mindre grad av automatikk, designhjelp osv. Litt om datamodellering Edgar Bostrøm. Versjon 1.4, vår

18 Ansatt tilbudsansvarlig Kategori Delprosjekt Konkurrent Produktområde prosjektleder Prosjekt Partner har laget Konsulent Kunde utføres ved Stasjon Hovedenhet Hovedenhetkarakteristikum Kundekode Kontaktperson Sted Stasjonen inneholder også opplysninger om alle kunder Enhetstype Lovlig_nasjon Gruppe Gruppestasjon ANSATTE Redundansen mellom ANSATTE og Ansatt bør ordnes med senere Kunde_plukkliste Sentralbordelementer Fabrikat FabrikatModell Prosjektår Fakturering Prismetod Prosjekt_kontakt Generell metodikk (kort) Det er kunden som vet hvilken informasjon som trengs i systemet Vi er metodespesialister, men må passe på at vi ikke overkjører kundene. (Stikkord: modellmakt) Legg mye vekt på diskusjon av begreper (blir evt. tabellnavn siden) Jobb på overordnet nivå lengst mulig (normalt entitetstyper/objektklasser og relasjonstyper/assosiasjoner) Etter hvert vil da attributter falle på plass av seg selv. Vær forberedt på mange iterasjoner. o diskuter med kunden, diskuter med kollegaer, få tak i en hovedkritiker. o idealet er at du får full oversikt med en gang, men det er sjelden realistisk o mer realistisk: Oppdragsgiver Vurder, tenk, diskuter, krangl, beskriv, test ut oppdragsgiver eier Litt om datamodellering Edgar Bostrøm. Versjon 1.4, vår

19 Tenk gjerne prototypeorientert! I forbindelse med databaser må du kanskje lage en eller flere databaseprototyper, for dermed å vinne erfaringer. Noen ganger kan det lønne seg å bruke plan to throw away - tenkning. M.a.o. (revidert fra 1. side): Prototypeorientert databaseutvikling Erfaring, metodekunnskaper, strukturer Ideer, behov m.m. for strukturering av informasjon Diskusjon, retting, mer diskusjon, forbedring, etc. Sted Omfattende løsning, men noen detaljer er kuttet ut. Postnr Poststed snavn hører til Bilmerke Selskap Selskap Rabattprosent Egenandel Rabattype Rabattypetekst SendesTil Sendetekst Kunde Kundenr Kundenavn Adresse *Postnr bileier fører Bilmerkenavn Biltypenavn AssistanseBil *Registreringsnr *Assistansenr Bergingsbil Registreringsnr *snavn *Bilmerkenavn Forventet_inn_kl Tjenestetype Tjenestenavn Dekningsområde CREATE TABLE Gruppe ( Gruppenr Integer NOT NULL, Gruppenavn Varchar(30), PRIMARY KEY ( *Selskap *Rabattypetekst Egenandelbeløp Årsakstype Årssakteller Årsaknavn Bil Assistanse Assistansenr *Selskap *Rabattypetekst *Registreringsnr KmStand UtførtAssistanse Anmerkning *Sendetekst Starttid Sluttid *Kundenr rekvireres fra Biltype Biltypekode Biltypenavn Lengdetype Tidkategori Lengdekategori Tidkode Tidtekst Tjeneste_i_kategori Tjenestenr *Lengdekategori Gruppenr ) ); CREATE TABLE Litt om datamodellering Edgar Bostrøm. Versjon 1.4, vår

20 Praktisk datamodellering, I: (kun på stikkordsnivå, mer følger i forelesningene) Ikke alt kan beskrives i en datamodell ulike notasjoner har ulike muligheter (og kompleksitet) behov for skriftlig beskrivelse ved siden av ting som ikke lar seg beskrive i den grafiske modellen designbeslutninger som er tatt og vurdering av alternativer Datamodeller og nøkler bør primær- og evt. også fremmednøkler være med (bl.a. i forhold til detaljeringsgrad, konseptuell-logisk-fysisk osv). NB! PK & FK er en del av relasjonsmodelen, ikke modellering generelt. regler hvis fremmednøkler skal være med Hode/linje (hoved-del) -strukturer og graden av binding mellom disse (UML: komposision evt. aggregering). BOM (Bill-of-materials) Mange-til-mange og eventuell entitetisering mange-til-mange (beholdes eller entitetiseres) mange-til-mange og attributter (attributter på relasjonene eller ikke) selve teknikken 2. ordens entitetisering (viser seg at en allerede entietisert inneholder en mange-til-mange, slik at man må splitte på nytt). Litt om datamodellering Edgar Bostrøm. Versjon 1.4, vår

21 Praktisk datamodellering, II: Flere relasjonstyper mellom de samme entitetstypene problemstillingen bruk i forbindelse med historikk modellering i forbindelse med en hoved- og flere tilleggs- Kontroll av lovlige verdier i ett nivå i flere nivåer, inkl. alle-til-alle eller mange-til-mange standardverdier og unntak Relasjonstyper mellom 3 eller flere inkl. ulike muligheter for dette. viktig: ulike skranker ut fra fremmednøkkelegenskaper Flere-rolle-problematikk og hvorledes legge struktur til data Hierarki fast antall nivåer og variabelt antall nivåer ettverk nettverk generelt nettverk med symmetri (ikke-rettede grafer), og problem med disse sammenheng mellom representasjoner: datamodeller, grafer og matriser Vanlige feil og hvorledes løse disse vifte-bommerten (= mist ikke tråden ) - engelsk: fan trap kløft-bommerten (= mist ikke mellomnivå ) - engelsk: chasm trap Kort om arv og muligheter i ulike modelleringsdialekter Kort om ener-stier og ekvivalente stier Litt om datamodellering Edgar Bostrøm. Versjon 1.4, vår

22 Plassering av entitetstyper i modellen. Det kan være lurt å plassere entitetstyper som danner en naturlig helhet nær hverandre, slik at det blir færre streker på kryss og tvers. Også lettere å lese en helhet og se en totalstruktur. Oftest er det nødvendig med flere runder med tegning. Kan lønne seg å farge de ulike delene av en modell med ulike farger, mye lettere å lese. Hvis det er en liten modell kan det være en fordel å sette på alle attributtene. For en større modell blir det for detaljert. NB! Hvis modellen fremdeles endres en god del, kan det lønne seg å vente med attributter til du er nesten ferdig. Noen velger å modellere først og fremst med 1-ere øverst, mange nederst hvis mulig. Det kan gjøre modellen lettere å lese og mer entydig, men spiller ingen rolle for innholdet. Litt om datamodellering Edgar Bostrøm. Versjon 1.4, vår

23 otasjon og variasjoner i 3 av dialektene: Chen, kråkefot og nedskalert UML. En del detaljer og variasjoner mangler. Grunnleggende. For alle dialekter: attributter kan tas med eller utelates (avh. av hvor langt i prosessen og hvor stor modellen blir) ditto for domener/datatyper det finnes varianter for å vise min./max. Chens ER Kråkefot nedskalert UML arbeids sted Person 1 m Rollenavn / relasjonsnavn Personnr Personnavn min. 0, dvs. Avd. kan ha person Begrep: Entitet(styper), relasjon(styper), attributter. jobber i Begrep: Entitet(styper), relasjon(styper), attributter. 1 jobber i er arbeidssted for * Begrep: Entitet(styper) eller objektklasser, (multiplisitets)assosiasjoner, attributter. Er repetisjoner tillatt? Ja, på konseptuelt nivå Nei splittes ut i egne entitetstyper Ja, på konseptuelt nivå Person PersID ::::::::: Verbal beskrivelse. Kan evt. settes på begge sider. Alternativt brukes en rolle som relasjonsnavn Max. nærmest entitetstypen, evt. min. lenger unna Eksempel med attributter Person PersID ::::::::: 1 er (og kan skrives) skrives 0..1 Verbal beskrivelse. På en eller begge sider. Pil viser retning * er (og kan skrives) 0..* 1..* betegner 1..m. Eventuelle primær- og fremmednøkler Tas gjerne ikke med Hvis det tas med: Markeres f.eks. med primærnøkkel: understreking fremmednøkkel: prikket linje, *, el.l. Entitetisering Kan gjøres, men vanligvis settes det bare på attributter på relasjonen. Bare nødvendig ved 2. ordens entitetisering. Gjøres dersom relasjonen skal inneholde attributter. Person Kurs Hvis det tas med: markeres gjerne med {PK} hhv. {FK} bak attributtnavnet. Hvis (del av) begge deler: {PK,FK} Kan gjøres, men bare nødvendig ved det som ellers ville vært 2. ordens entitetisering. Assosiative entitetstyper m/ attributter kan legges på: * * Person Kurs Person Deltagelse Kurs Person PersID :::::::::: Litt om datamodellering Edgar Bostrøm. Versjon 1.4, vår

24 n-ære relasjonstype / assosiasjoner (n >2) Avhengighet av andre entitetstyper (en entitet er avhengig av eksistensen av en annen entitet) Innebygdt i notasjonen, ingen forskjell på binære og n-ære. Ordre Ordrelinje kalles svak entitet / weak entity Arv Finnes ikke, må i tilfelle beskrives som 1:1, men gir ikke egentlig arv. Evt. entitetisering gjøres først, deretter henges nye entitetstyper på denne. Markeres ved at fremmednøkkelen er en del av primærnøkkelen (på mange-siden) Finnes ikke, må i tilfelle beskrives som 1: 1, men gir ikke egentlig arv. Bruk for å knytte dem sammen. Assosiative entitetstyper kan brukes Ordre Ordrelinje Kunde kalles komposisjon. Finnes også en mindre sterk kobling som kalles aggregering (markeres med i stedet for ). {Mandatory, Or} Forhold til normalisering Overføring til relasjonsdatabaser I tillegg: kan beskrive kombinasjoner av mandatory/optional og om en overordnet kan kobles til max. 1 eller til flere underordnede (or eller and), se over. Kan også være arv med ett barn, f.eks. bare Kunde og Utenlandskunde. Må evt. gjøre utsplittinger Er normalisert Må gjøre evt. utsplittinger Overføres til kråkefot el.l. først (fra konseptuelt til logisk nivå) Alternativt: Legg på primær- og fremmednøkler Evt. repetisjoner må tas bort. Entitetstyper blir til tabeller. Relasjoner som gjelder 1:m tas bort, relasjoner som gjelder m:m blir egne tabeller. Evt. mange-til-mange må entitetiseres. Ellers: entitetstyper blir til tabeller Utenlands kunde Innenlands kunde Evt. repetisjoner må tas bort. Entitetstyper/objektklasser blir til tabeller. Assosiasjonsattributter i m:m blir egne tabeller, andre m:m entitetiseres. Høyere ordens relasjonstyper blir til tabeller. Arv må omformuleres (flere alternativer finnes, ingen er helt gode). Dersom man bruker ORDB-utvidelser i systemer som har dette, kan arv implementeres. Litt om datamodellering Edgar Bostrøm. Versjon 1.4, vår