1. Datamodellering Kommentarer til læreboka

Transkript

1 Tore Mallaug Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for fagene LN323D Databaser 1. Datamodellering Resymé: Denne leksjonen viser et par eksempler på ER-modellering inkludert sammenhengen mellom diagram og tabeller. UML brukes som notasjon (diagrammene er tegnet i MS Visio). I tillegg kommenteres lærebokas kap. 6. Innhold 1.1. KOMMENTARER TIL LÆREBOKA EKSEMPEL: TIMEAVTALER Problemstilling Løsningsforslag (trinær sammenhengstype) EKSEMPEL: GAMMEL EKSAMENSOPPGAVE Problemstilling: Salg av nye biler i Norge Løsningsforslag: Kommentarer: Kommentarer til læreboka Les igjennom alt i kap Det er viktig at du forstår forskjellen på en entitetstype og en entitet (eller forekomst). F.eks. LÆRER er entitetstypen, mens Tore Mallaug er en entitet (forekomst) av typen LÆRER. Oversatt til relasjonsmodellen blir LÆRER tabelldefinisjonen (CREATE TABLE i SQL), mens Tore Mallaug blir et tupell i tabellen. Riktignok er det ingen fasit som sier at oversettingen fra ER til tabeller trenger å være slik. Det viktige er at minst mulig av den semantiske informasjonen i ER-diagrammet forsvinner ved oversetting til tabeller. Noe informasjon vil typisk forsvinne rett og slett fordi ER-modellen semantisk sett er rikere (gir større rom til å uttrykke semantikk) enn relasjonsmodellen. Når du skal tegne et ER-diagram må du prøve å finne mulige entitetstyper. Disse er ofte substantiv, f.eks. en lærer, en person, en bil, en kontrakt, en transaksjon... Sammenhengstypene (eng. relationships) er ofte verb, f.eks. arbeide, tilhøre, inneholde, består av, tar, er... Attributt beskriver egenskaper til entiteter og sammenhenger av en gitt type. Prøv og ikke heng deg for mye opp i nøkler når du designer ER-diagram. Personlig mener jeg nøkler er unødvendig å spesifisere i diagrammet (selv om bokas UML-notasjon gjør dette), fornuftige nøkler er noe man må finne når en oversetter til tabeller senere. Om en entitet er sterk eller svak (kap ), synes jeg heller ikke er så interessant. Avhengighetene en

2 entitetstype har til andre entitetstyper kommer uansett fram ved å se på sammenhengstypene i diagrammet. Det viktige blir altså å finne fornuftige entitetstyper og sammenhengstyper. Videre må du lære deg forskjellen på en-til-en (1:1), en-til-mange (1:*,ofte også kallt1:n) og mange-til-mange (*:* (M:N)). Merk deg alle de ulike sammenhengstypene som er omtalt i kap dette er viktig stoff. Når du skal finne mulige sammenhengstyper når du tegner ERdiagram, må du tenke entall og på entiteter. F.eks. hvis du har entitetstypen STUDENT, still deg spørsmålet: Hvilke sammenhenger kan én student ha? Hvis du tenker flertall blir det rot (mange studenter har mange sammenhenger, alt blir mange-til-mange). Merk deg at en-til-mange er mest vanlig, deretter mange-til-mange. En-til-en er i praksis ganske sjelden, så hvis du ender opp med mange 1:1 i et diagram, er sikkert de fleste av dem egentlig en-til-mange. Videre følger et par eksempler på ER-diagram og oversatte tabeller Eksempel: timeavtaler Problemstilling Tabellene fra leksjon 6 er som følger: TIMEBESTILLING (ansattnr*, pasientnr*, dag*, tid) LEGE (ansattnr, legenavn) PASIENT (pasientnr, pasientnavn) LEGE_ROM (ansattnr*, dag, rom*) ROM_BEHANDLING (rom, behandling) Understekne attributter er primærnøkkel. Attributter merket * er fremmednøkler. Dette blir å gå litt i feil retning (ER-diagrammet er ment å komme før tabellene), men her er uansett et forslag til ER. side 2 av 5

3 Løsningsforslag (trinær sammenhengstype) Denne løsningen representerer en timebestilling som en trinær sammenheng mellom en pasient, lege og lege_rom. Den trinære sammenhengen har også et eget attributt, tid (tilsvarer attributtet i tabellen TIMEBESTILLING). Kardinalitene viser at både pasient, lege og lege_rom kan være involvert i null, en eller mange timebestillinger. Alternativt kunne Timebestilling vært en egen entitetstype med -sammenhengstyper til PASIENT, LEGE og LEGE_ROM. Fordelen med den trinære løsningen her er at vi får vist at en Timebestilling alltid består av en sammenheng mellom pasient, en lege og et lege_rom (denne semantikken kommer ikke fram med tre binære sammenhenger). I tillegg inneholder ER-diagrammet en en-til-mange-sammenheng mellom lege og lege_rom (et lege_rom har alltid en lege, en lege kan være på 0,1 eller flere lege_rom (riktignok ikke på samme tidspunkt, men det får vi ikke vist i diagrammet)). Og en en-til-mange mellom lege_rom og rom_behandling (et lege_rom er alltid på et rom, mens et rom kan brukes av 0, 1 eller flere lege_rom) Eksempel: gammel eksamensoppgave Oppgave fra høsten 2002: Problemstilling: Salg av nye biler i Norge Vi tenker oss at bilbransjen skal etablere en sentral database over alt salg av nye personbiler i Norge og at det er laget følgende situasjonsbeskrivelse/kravspesifikasjon for databasen: Hver bil som blir solgt har et registreringsnummer som entydig identifiserer bilen. For hver bil registreres i tillegg en salgsdato, farge og kjøpesum. side 3 av 5

4 En bil blir solgt av en bilforhandler i en bestemt uke i et bestemt år. For bilsalget registrerer man hvilken ukedag (mandag, tirsdag, ) salget skjer. En bilforhandler selger ett eller flere bilmerker (SAAB, Volvo, ). Hvert bilmerke tilbyr en mengde bilmodeller (V40, V70, S80, ) som leveres i en del modelltyper (sedan, stasjonsvogn, ulike motorer, osv.). Innen hvert bilmerke er bilmodellnavn entydige. Innen hver bilmodell er biltypebetegnelsene entydige. Hver bilforhandler hører til ett handelsdistrikt som har et entydig navn (Trondheim, Inntrøndelag, Namdalen, ). Hvert handelsdistrikt er på sin side del av en landsdel (Midt-Norge, Nord-Norge, ). Til både handelsdistrikt og landsdeler skal det kunne registreres en beskrivende tekst. For en bilmodell skal man kunne registrere året bilmodellen ble lansert og en kort beskrivelse. For en bilmodelltype skal man kunne registrere type bil (sedan, stasjonsvogn, kombi, flerbruksbil, ), drivstofftypen (bensin, diesel, ), motorvolum, motoreffekt, antall sitteplasser, bagasjeromsvolum, egenvekt og maksimal nyttelast. Alle biler som blir solgt er en av bestemt bilmodelltype. Databasen skal blant annet brukes til å analysere hvordan bilsalget fordeler seg i løpet av året i ulike deler av landet. For det inneværende året er det viktig at brukerne enkelt kan finne ut hvilke uker det er registrert data for. Dersom det er ekstraordinære forhold som påvirker salget i en uke, skal det være mulig å legge inn en forklarende kommentar til denne uken (uke 13 og 14 var for eksempel påskeuker i 1999). a) Lag en konseptuell datamodell (ER-modell) for denne databasen. Du velger selv om du vil bruke kråkefotnotasjonen (Modelator) eller UML-notasjonen (lærebokas notasjon). Gjør kort rede for de forutsetninger og antagelser som du finner det nødvendig å gjøre. b) Du skal oversette den konseptuelle datamodellen (ER-modellen), som du kom fram til i a), til relasjonell form (relasjonsmodellen) uansett hvilken notasjon du brukte til å tegne modellen. Husk å merk primær- og fremmednøkkel. side 4 av 5

5 Løsningsforslag: a) BIL +reg_nr {PK} +salgs_dato +farge +kjøpesum +selger BILSALG ukedag +selges av BILFORHANDLER +forhandler_navn {PK} HANDELSDISTRIKT +distrikt_navn {PK} +omfatter +blir gjort i +del av UKE +uke_nr {PK} +år +kommentarer LANDSDEL +landsdel_navn {PK} BILMODELLTYPE +type_navn {PK} +drivstoff_type +motor_volum +motor_effekt +ant_sitte_plasser +bagasjeroms_volum +egenvekt +maks_nyttelast BILMODELL +modell_navn {PK} +lanserings_år BILMERKE +merke_navn {PK} b) BILMERKE(merke_navn) BILMODELL(modell_navn, lanserings_år, beskrivelse, merke_navn*) BILMODELLTYPE(type_navn, drivstoff_type, motor_volum, motor_effekt, ant_sitte_plasser, bagasjeroms_volum, egenvekt, maks_nyttelast, modell_navn*) BIL(reg_nr, salgs_dato, farge, kjøpesum, type_navn*) BILFORHANDLER(forhandler_navn, distrikt_navn*) BILSALG(regn_nr*, forhandler_navn*, uke_dag, uke_nr*) UKE(uke_nr, år, kommentarer) HANDELSDISTRIKT(distrikt_navn, beskrivelse, landsdel_navn*) LANDSDEL(landsdel_navn, beskrivelse) Kommentarer: Legg merke til at BILSALG i ER-diagrammet er representert som en mange-til-mange sammenheng mellom BIL og BILFORHANDLER. Dette er logisk fordi et salg her er noe som skjer mellom en bil og en bilforhandler, og derfor et dårlig eksempel på en selvstendig entitet. Men siden BILSALG har en egen sammenhengstype til UKE kunne den like godt ha vært tegnet inn som en entitetstype (i UML godtas det at en tegner sammenhenger til BILSALG her). Ellers er det bare vanlige en-til-mange i dette diagrammet. side 5 av 5