INF130: Datahåndtering og analyse

INF130: Datahåndtering og analyse Modellering 1.1 Temaer Kapittel 7 Modellering 2 Datamodellering med E/R Fasene i systemutvikling og databasedesign E/R (Entity/Relationship) Entitet Attributt Identifikator Forhold og roller Kardinaliteter: 1:1, 1:M, M:N Oppløsing av mange-til-mange (M:N) forhold Svake entiteter Egenforhold Subtyper Pensum: Kapittel 7 og 8 3 INF130: Modellering 1

Hvorfor datamodellering? Det er ikke opplagt hvilke tabeller en database bør inneholde og hvilke kolonner disse tabellene bør inneholde. Vi må prøve oss litt fram for å finne en hensiktsmessig struktur. Det har vist seg nyttig å bruke «visuelle modeller» i denne prosessen. E/R (Entity/Relationship) er et slikt visuelt modellspråk. Et E/R-diagram viser strukturen til en database. 4 Eksempel på E/R-diagram Bok BokNr ISBN Tittel Forfatter UtgittÅr AntallEks I A15 A40 A30 I I Utlån UtlånsDato Levert D BL Navn Kontakt Telefon Forlag A30 A40 A8 Låner LNr I Fornavn A20 Etternavn A30 Gateadr A40 5 Først Vi har sett en del eksempler på hvordan data lar seg representere i tabeller: 6 INF130: Modellering 2

Kjøretøy RegNr Merke Modell År Km LY 12345 Toyota Corolla 1998 225501 NV 54321 Toyota Avensis 2012 15238 DA 98765 Ford Focus 2009 47624 NV 67890 Nissan Micra 2007 31092 q Noen fysiske objekter som bøker, personer og kjøretøy har en etablert primærnøkkel (ISBN, personnr, registreringsnr). q For andre fysiske objekter er det naturlig å etablere et «løpenr» VNr for Vare, SNr for Student osv. 7 Mer abstrakte objekter: Lån LNr KNr Beløp Start År Rente Type 27630364643 50401 1550000 02.09.2009 20 5.5 Serie 27630382732 50104 65000 01.01.2011 8 7.6 Annuitet 27630393982 20932 1050000 20.07.1999 20 5.0 Annuitet 27630338829 90237 300000 10.12.2007 10 6.5 Annuitet 27630391882 70238 1250000 05.08.2008 15 5.5 Serie q Lån er ikke et fysisk objekt, men likevel relativt «håndfast». q Er det noen fremmednøkler her? q Lagrer ikke mer enn vi må: Fra opplysningene i tabellen kan vi generere en nedbetalingsplan (hva skal betales hver måned, hvor mye er avdrag og hvor mye er renter). 8 Sammensatte objekter: Ordre og Ordrelinje OrdreNr Ordredato KNr 20505 20.8.2011 5022 20506 20.8.2011 5009 20507 20.9.2011 5188 q Ordreskjemaet består av et «hode», der man skriver inn dato og kundenr, q og et antall «linjer», der man på hver linje skriver inn varenummer og antall eksemplarer. q Det er et en-til-mange forhold mellom en ordre og en linje på denne ordren. OrdreNr VNr Pris Antall 20505 10830 29.90 1 20505 77033 109.50 5 20506 10830 29.90 1 20506 44939 57.60 3 20506 65081 109.50 5 20507 12088 109.50 2 9 INF130: Modellering 3

Hendelser: Temperaturmåling StedNr Dato Temp 53 30.04.2011 7 53 12.05.2011 8 53 20.05.2011 6 54 20.05.2011 11 54 20.07.2011 4 q En hendelse er noe som skjer på et bestemt sted på et bestemt tidspunkt. q Hva er en hensiktsmessig primærnøkkel i tabellen? q Hva om vi vil gjøre flere målinger pr. dag? 10 Tabeller og hierarkier: Slektstrær Id Fornavn Mor Far 1 Ola 2 Lise 3 Per 1 4 Kari 2 5 Arne 3 6 Johanne 4 5 7 Gunnar 4 5 Ola Per Arne Gunnar Kari Johanne Lise q Far-forholdet er et hierarki; et en-til-mange forhold fra far til barn. Det samme er mor-forholdet. q Lar seg representere i en tabell ved at alle «peker på» sine foreldre. q Er det fremmednøkler her? 11 Tabeller og grafer (nettverk): Fottur TurNr StartHytte Gradering 56 Glefsebu Lett 77 Høgåshytta Middels Glefsebu Storvassbui Høgåshytta Mimrebu Mimrebu Breheimen Krikut TurNr Dag TilHytte 56 1 Mimrebu 56 2 Storvassbui 77 1 Breheimen 77 2 Mimrebu 77 3 Krikut 12 INF130: Modellering 4

Så Hva går datamodellering ut på? 13 Modeller og perspektiver Når man skal konstruere noe som er komplisert er det nyttig å lage en modell først. Hus-eksempel: Arkitekttegning, 3D-modell En modell er en representasjon av noe, der visse egenskaper, som er viktige for det formål representasjonen skal brukes til, er fremhevet, mens øvrige egenskaper utelates. Perspektiver: Prosessorientert: Hva skal systemet gjøre? Informasjonsorientert: Hva må systemet vite? Objektorientert: Et system består av kommuniserende objekter. 14 Livsløpet til et databasesystem Et databasesystem inngår som regel i et større (edb-basert) informasjonssystem. Systemutvikling kan gjøres i faser. Forstudie: Skal vi starte utvikling? Analyse: Hva skal systemet gjøre? Design: Hvordan skal systemet bygges opp? Implementasjon: Lag (programmer) systemet! Test Drift Videreutvikling / avvikling 15 INF130: Modellering 5

Fossefallsmodellen / Smidige metoder Den «klassiske» fossefallsmodellen er kritisert for å være for «stivbeint». Smidige metoder (agile) er en mer fleksibel løsning. Mindre omfattende planlegging i starten Mange, små leveranser og hyppige tilbakemeldinger underveis 16 Databasedesign HVA? Begrepsmessig databasedesign E/R diagram Logisk databasedesign HVORDAN? Fysisk databasedesign 17 Databasedesign fra abstrakt til konkret Begrepsmessig databasedesign Teknologiuavhengig beskrivelse av hva databasen skal inneholde. E/R (Entity/Relationship) mye brukt som «språk». Logisk databasedesign Logisk tabellstruktur uavhengig av konkret DBHS. Fysisk databasedesign Fysisk tabellstruktur tilpasset et konkret DBHS med beskrivelse av lagringsstrukturer og aksessteknikker. E/R-diagrammer kan oversettes til tabellstruktur delvis automatisk av modelleringsverktøyet. Generate database 18 INF130: Modellering 6

Introduksjon til E/R-diagrammer E/R-diagrammer er en visuell beskrivelse av strukturen til en database. Hver entitet (boksene) svarer til en tabell. Attributter (i nederste del av boksene) svarer til kolonner. Identifikatorer er understreket og svarer til primærnøkler. Forhold (linjene) svarer til fremmednøkler. Ø E/R-diagrammer brukes når vi planlegger hva databasen skal inneholde. Ø Gir god oversikt. Ø Lesbare også for de som ikke er IT-eksperter. 19 Grunnleggende begreper i E/R Person PersonNr Fornavn Etternavn Adresse eier eiet-av Bil RegNr Merke Modell Årsmodell q Person og Bil er entiteter. q Fornavn er et attributt til Person. q RegNr er identifikator i Bil. q En person kan spille rollen som eier i forholdet mellom Person og Bil. 20 Type og forekomst Tabellen Ansatt inneholder mange rader. Hver rad beskriver én ansatt. En entitetsforekomst svarer til en rad i en tabell. Eksempel: (AnsattNr=1, Fornavn='Hans', Etternavn='Hansen', Adresse='Hansegata 3') Entitetstypen representerer mengden av forekomster (og svarer dermed til hele tabellen). Tilsvarende skiller vi mellom type og forekomst av forhold. Forekomst: Eierforholdet mellom Ola og hans Ascona. Type: Samlingen av alle eierforhold. 21 INF130: Modellering 7

Forholdstype og forholdsforekomster Kunde 1 Kunde 2 Kunde 3 Ordre 1 Ordre 2 Ordre 3 Ordre 4 22 Kardinalitet 1:N (en-tilmange) Person PersonNr Fornavn Etternavn Adresse eier eiet-av Bil RegNr Merke Modell Årsmodell 1:1 (en-til-en) Ansatt AnsNr Fornavn Etternavn leder er-ledet-av Avdeling AvdKode AvdTlf Leder M:N (mange-tilmange) Selger AnsNr Fornavn Etternavn selger blir-solgt-av Produkt ProduktNr Betegnelse PrisPrEnhet 23 Minimums- og maksimumskardinalitet En gitt person kan eie minimum 0 og maksimum mange biler. Symbol nærmest entitetene angir maksimumskardinalitet. Kråkefot betyr «mange», mens betyr 1. Innerste symbol angir minimumskardinalitet. Sirkel betyr 0 og betyr 1. Forenklet notasjon (brukes i PowerDesigner): En sirkel alene betyr maksimum=minimum=0. En alene betyr maksimum=minimum=1. 24 Generelt er det mulig å bruke andre «tall» enn 0, 1 og «mange». Eksempel: 3..7 Forskjellen på 0, 1 og «mange» avgjør tabellstruktur. INF130: Modellering 8

Svake entiteter Båt Navn MaxAntPersoner MaxAntBiler har-avgang avgang-for Avgang Dato Klokkeslett GrønnAvgang q En svak entitet arver deler av sin identifikator fra en annen og kan ikke eksistere uten denne. Ø En Avgang kan ikke eksistere uten en tilhørende Båt. Ø Identifikatoren for Avgang er (delvis) avledet fra identifikatoren for Båt. 25 Oppløsing av mange-til-mange forhold Selger AnsNr Fornavn Etternavn selger blir-solgt-av Produkt ProduktNr Betegnelse PrisPrEnhet Er det interessante egenskaper ved forholdet? Selger AnsNr Fornavn Etternavn SelgerProduktTilknytning Budsjett Produkt ProduktNr Betegnelse PrisPrEnhet 26 Modelleringsklisjeer Mange datamodelleringsproblemer er eksempler på noen få «klassiske problemer». Skagestein kaller dette for modelleringsklisjeer. Eksempler: «Er-en»-hierarkier ( en katt er et pattedyr ) «Har-en» hierarkier ( del er bygget opp fra ) Et papirskjema er bygget opp fra et hode og et antall linjer. Skal man kun lagre nå-situasjonen, eller også historikken? 27 INF130: Modellering 9

Hode/linje-mønsteret (master/detail) Kunde Vare Kunde Ordre Obs! Vare Kunde Ordre Ordrelinje Vare 28 Entitet eller attributt? En egenskap ved et attributt kan lagres som et attributt, for eksempel hvilken avdeling en ansatt jobber i: Hva om vi vil lagre flere opplysninger om avdelingen? 29 Avdeling AvdNavn Telefon Egenforhold Underavdeling UnderNavn Telefon underordnet Enhet Navn Telefon overordnet Kontor KontorNavn Telefon q Kan antall nivåer variere? Er det en øvre grense? q Egenforhold kan modellere vilkårlig dype hierarkier. Eksempler: Slektstrær, kataloger/ mapper på en PC, diskusjonsforum. q Hvilken modell gir de enkleste spørringene? 30 INF130: Modellering 10

Tid og rom Vare VareNr Pris q Kun lagre nå-pris? Hva kostet varen tidligere? Ø Lagre prisendringer, eller pris for hver dag? Ø Håndtering av tidsperioder. q Tidspunkt/sted som (del)identifikator i entiteter som representerer «hendelser» (vielse). Vare VareNr Pris Prisendring Dato Listepris 31 INF130 Introduksjon til databaser ER modellen og grafisk fremstiling av modeller Knut Kvaal, UMB 1.32 Innhold Entitetsmodellen Eksempel på ER modell med kart MYSQL workbench 33 INF130: Modellering 11

Litteratur Pensum Kapittel 8 34 Hvordan lære modellering? Vi skal lære modellering ved hjelp av et enkelt eksempel Vi vil benytte modellverktøy i denne prosessen MYSQL workbench er installert på Comet Du kan installere dette verktøyet på din lokale maskin 35 Entiteter og koblinger En grafisk framstilling av koblinger mellom entiteter gir en god oversikt. Alt dette får du ved å benytte Workbench! 36 INF130: Modellering 12

Innledning Definisjon av databasestrukturen Analyse og diskusjon Dårlig utformet database gir en dårlig applikasjon Systematisk utarbeiding av en datamodell større sjanse for å lykkes 37 Problembeskrivelse En samtale med oppdragsgiveren De ansatte i et firma er forelt på forskjellige avdelinger. Det er viktig å ha oversikt over hvem som jobber hvor og hvilken stillingstype de har. De ansatte skoleres ved å gå på ulike kurs. 38 Entitetstyper Ansatt Avdeling Stillingstype Kurs Opplysninger om entitetstypene utvikles i de enkelte attributtene 39 INF130: Modellering 13

Datamodellens entiteter Stillingstype Avdeling Kurs Ansatt 40 Koblinger Hvordan er de ulike entitetene koblet til hverandre? Ansatt-Kurs Ansatt-Avdeling Ansatt-Stillingstype 41 Ansatt-Kurs Hver ansatt kan ha vært med på flere Kurs Hvilke kurs har den enkelte ansatt vært med på? Hvert Kurs kan bli tatt av flere Ansatte Dette er opplagt for oss men ikke for database systemet! Det må beskrives 42 INF130: Modellering 14

Ansatt-Avdeling En Avdeling kan ha mange ansatt Hver Ansatt kan bare jobbe i en avdeling Det er ikke interessant med jobber som en ansatt kan ha hatt i andre avdelinger 43 Ansatt-Stillingstype En Ansatt kan kun ha en stillingstype Det kan være mange ansatte som har samme stillingstype Sekretær, direktør, konsulenter 44 Tillatte sammenhenger En eller mange Avdeling Avdeling En Mange 45 INF130: Modellering 15

Vår datamodell Stillingstype Avdeling Gjelder Jobber i Har ansatt Har tatt Har Ansatt Er tatt av Kurs 46 Relevante attributter Datamodellen i figuren gir en enkel oversikt av en presisert problembeskrivelse Vi må beskrive de relevante attributtene for de forskjellige entitetene 47 Attributtene Stillingstype Avdeling Stillingskode Stillingsbetegnelse Avdelingsnr Avdelingsnavn Adresse Telefonnr Ansatt Kurs Ansattnr Ansattnavn Kurskode Kursnavn 48 INF130: Modellering 16

Identifikator Identifikatoren nøkkelfeltet Identifiserer en enkelt forekomst av en entitetstype Avdeling Avdelingsnr Avdelingsnavn Adresse Telefonnr 49 Minimum og maksimums kardinalitet En presis modell bør ha angitt en maksimum og minimums kardinalitet Eksempel minimumsbeskrivelse Kan jobbe i avdeling betyr minimum 0 Må jobbe i avdeling betyr minimum 1 Maksimumsbeskrivelsen er gjerne en eller mange 50 Maksimum/minimum modell Stillingstype Avdeling Gjelder Jobber i Har ansatt Har tatt Har Ansatt Minimum 0,1 = kan, må Er tatt av Kurs 51 INF130: Modellering 17

Fremmednøkler Vi har satt opp en liste over viktige opplysninger for hver entitet Attributter Attributtene blir felter i tabellene En database med koblinger mellom entitetene krever Fremmednøkler (fremmede attributter) 52 Koblingene i praksis Ansatt-Avdeling For å få til koblingen legger vi inn et nytt attributt (avdelingsnr) i entitetstypen Ansatt For hver Ansatt kan vi da finne ut hvilken Avdeling vedkommende arbeider i Mulig fordi en ansatt ikke kan arbeide i mer enn en avdeling og fordi vi antok at Avdelingsnr er unik (nøkkel) Det er altså ikke nødvendig med Avdelingsnavn som fremmed attributt i Ansatt. Hvorfor? 53 Integritetsskranker i relasjonsdatabaser Integritets- Metadata regler Kunde Ordre Brukerdata Database Databasehåndteringssystem (DBMS) Brukergrensesnitt Primærnøkler og entitetsintegritet Fremmednøkler og referanseintegritet Vi kan altså ikke starte å registrere alle data i Ansatt tabellen uten å ha verdier tabellen er avhengig av! @Gerhard Skagestein 54 INF130: Modellering 18

Entitetsintegritet Enhver tabell skal ha en primærnøkkel som er ( not null ) Alle verdier av valgt kolonne/kombinasjon må være forskjellige Ingen del av felt/kombinasjonen kan være NULL Alle forekomster (entiteter= ting ) skal kunne identifiseres og ha mening. 55 Referanseintegritet Dersom to tabeller er sammensatt i et Primærnøkkel/ Fremmednøkkel forhold, må alle verdier av fremmednøkkelen være ENTEN: Matche med en verdi i primærnøkkelen ELLER: Helt ut være NULL (udefinert, finnes ikke) 56 Eksempel på Referanseintegritet A) Avdeling B) Avdeling Avdkode Avdkode har har jobber i Ansatt jobber i Ansatt Ansattnr *Avdkode Ansattnr *Avdkode 57 INF130: Modellering 19

Strategi ved referanseintegritet Ved innsetting av en post med fremmednøkler Sjekk at fremmednøkkelen matcher dens eier eventuelt er NULL Ikke tillatt å sette inn Avdnr i ansatt som ikke matcher dem et Avdnr i Avdeling For eks B forrige bilde: Tillatt å sette inn Ansatt uten avdelingsnr 58 Eksempledatabase Stillingstype Avdeling Jobber i Har ansatt Har tatt Har Ansatt Er tatt av Kurs Ref: Metodedata as 59 Modelleringen Konstruer Entitetstypene Koblingstypene Attributtene Fremmednøklene Test modellen i MySQL 60 INF130: Modellering 20

Modellen i første versjon 61 Sterke og svake entitetstyper Sterk Eksisterer uavhengig av andre entitetstypre Svak Avhengig av en annen entitetstype for sin egen identitet. Den er identitetsavhengig av en annen entitetstype Slå opp på side 156 i læreboka. 62 Mange til Mange koblinger Et mange-mange forhold må kobles via en fiktiv entitetstype Kobling Den fiktive entiteten vil inneha mange til en relasjon og fremmednøkler fra entitetene den kobler sammen 63 INF130: Modellering 21

Kursdeltagelse Vi kan ikke legge attributtet kurskode i Ansatt Vi kan ikke legge attributtet Ansattnr i Kurs Vi må lage en ny entitet: Kursdeltagelse 64 Entitetisering (splitting) 65 Den endelige modellen Ref: Modellator manual 66 INF130: Modellering 22

Modellverktøy MYSQL Workbench Vi skal demonstrere denne prosessen på fredag 67 MySQL Workbench 68 Modellen overføres til et DBMS Modellen som vi har konstruert i Modellator kan eksporteres til et DBMS Vi viser et eksempel der MySQL er mottager Skjema er beskrevet i SQL/DDL Man må ofte påregne noe redigering av SQL generert kode kjøres som skript 69 INF130: Modellering 23

Bruke databasen Etter at databasen er eksportert til et DBMS må den sannsynligvis etterarbeides En test på dette Lage formularer (om det er mulig) Hva skjer når man starter med å registrere data kun i Ansatt-tabellen? Referential integrity constraint 70 INF130: Modellering 24