Dagens tema: Ekvivalente stier og joinskranker Ringskranker Informasjonsbærende representasjoner Behandling av tid

Transkript

1 UNIVERSITETET I OSLO INF1300 Introduksjon til databaser Dagens tema: Ekvivalente stier og joinskranker Ringskranker Informasjonsbærende representasjoner Behandling av tid Tommelfingerregler ORM som analysemetode Noen eksamensråd for ORM Institutt for informatikk Dumitru Roman 1

2 Stier Dette er en sti fra A til C 2

3 Ekvivalente stier Dersom vi har to stier fra A til B som er slik at hvis vi starter med én forekomst i A, så skal vi komme til samme forekomst i B uavhengig av hvilken av de to stiene vi følger, så kaller vi de to stiene ekvivalente. 3

4 Avledbare data - 1 Unødvendig (avledbar) informasjon Merk de ekvivalente stiene! 4

5 Avledbare data - 2 Unødvendig (avledbar) informasjon? Det kan være mange grunner til å lagre avledbar informasjon 5

6 Eksempel på ekvivalente stier 6

7 Håndtering av EOP i realisering Ekvivalente stier (EOP) blir en slags likhetsskranke Noen ganger havner de to attributtene som skal ha lik verdi i samme tabell, da er det enklest å slå sammen de to attributtene til ett I mer kompliserte tilfeller havner de i forskjellige tabeller; da må alle tabeller langs de to stiene joines for deretter å sjekke at de to attributtene har lik verdi 7

8 Joinskranker Ekvivalente stier er et viktig eksempel på det vi kaller joinskranker For å håndheve disse skrankene kan det være nødvendig å foreta en join mellom tabeller Alle mengdeskranker kan opptre som joinskranker Ekvivalente stier er et spesialtilfelle av en joinlikhetsskranke 8

9 Avanserte skranker Alle skranker vi ikke har grafiske symboler for, kalles avanserte skranker Disse skrives på ORM-diagrammet som tekst Lovlig språk er førsteordens logikk og vanlig aritmetikk (regneformler) Lovlige variable er konstanter, roller, stier og inverse stier Se f.eks. lysarket Avledbare data 2 ORM 2 har et eget språk for avanserte skranker 9

10 Ringskranker 10

11 Refleksiv skranke x pop(r1) pop(r2) (x,x) pop(r1,r2) 11

12 Symmetriskranke (x,y) pop(r1,r2) (y,x) pop(r1,r2) 12

13 Transitiv skranke (x,y) pop(r1,r2) (y,z) pop(r1,r2) (x,z) pop(r1,r2) 13

14 Irrefleksiv skranke (x,x) pop(r1,r2) 14

15 Antisymmetriskranke (x,y) pop(r1,r2) x y (y,x) pop(r1,r2) 15

16 Asymmetriskranke = antisymmetri + irrefleksivitet 16

17 Intransitiv skranke (x,y) pop(r1,r2) (y,z) pop(r1,r2) (x,z) pop(r1,r2) 17

18 Asyklisk skranke (x 1,x 2 ) pop(r1,r2)... (x n-1, x n ) pop(r1,r2) (x n, x 1 ) pop(r1,r2) 18

19 Kombinerte ringskranker asyklisk og intransitiv asymmetrisk og intransitiv symmetrisk og intransitiv symmetrisk og irrefleksiv 19

20 Representasjoner Alle begreper må kunne representeres Begrepsforekomster kan ikke lagres; det vi lagrer, er representasjonsforekomster Skal vi kunne realisere modellen som en relasjonsdatabase, må vi representere alle begrepene entydig 20

21 Valg av representasjon Valg av representasjon: entydig bro mellom en forekomst av en representasjon og forekomsten av det tilhørende begrepet helst uforanderlig støtte utveksling av informasjon mellom systemer Identifikator = representasjon hvor det er en uforanderlig en-til-en-bro mellom begrep og representasjon 21

22 Representasjonstyper navn, koder, forkortelser boolske verdier tellbare størrelser tids- og romlige verdier fritekst representasjoner av bilde og lyd 22

23 Ikke-informasjonsbærende representasjoner Representasjonen til begrepet identifiserer en forekomst av begrepet Det fins ingen innkodet informasjon i representasjonen 23

24 Delvis informasjonsbærende representasjoner Deler av representasjonen til et begrep identifiserer en forekomst av et annet begrep Dette kan, men behøver ikke, være synlig i modellen 24

25 Totalt informasjonsbærende representasjoner Representasjonen til begrepet består av en samling elementer der hvert element identifiserer en forekomst av et annet begrep 25

26 Synliggjøring eller ikke av informasjonsbærende representasjon i modellen? Hvis det er en mulighet for at brukeren etterspør denne informasjonen, bør den vises i modellen 26

27 Representasjon via superbegrep Underbegreper arver alltid representasjonen til sitt superbegrep 27

28 Representasjon via en-til-en-faktatype Et begrep med en påkrevd rolle i en en-til-enfaktatype til et annet begrep kan identifiseres indirekte gjennom det andre begrepet Eksempel: En hovedstad kan identifiseres med det landet den er hovedstad i 28

29 Behandling av tid Versjonering Hva er et tidspunkt Hva skal et tidsstempel reflektere Praktisk versjonsmodellering 29

30 Versjonering Hvis vi ønsker at databasen skal vise historiske opplysninger, lagrer vi tidsstemplede versjoner av informasjonen Med en versjon mener vi her et øyeblikksbilde av all informasjon De tidsstemplede versjonene kan ordnes langs en tidsakse 30

31 Versjoner med tidsstempel ansatt avdeling 120 salg 110 salg 081 produksjon 230 økonomi prosjekt ansatt prosj.timer Alfa Beta Alfa Alfa Beta ansatt avdeling 120 salg 110 salg 081 produksjon økonomi prosjekt ansatt prosj.timer Alfa Beta Alfa Alfa Beta ansatt avdeling 120 salg 110 salg 081 produksjon salg prosjekt ansatt prosj.timer Alfa Beta Alfa Alfa Beta t 31

32 Hva er et tidspunkt Tidsaksen består i praksis alltid av tidsintervaller i informasjonsmodellen Granulariteten til intervallene avhenger av behovet for nøyaktighet. Granularitet avgjør hvordan tidsintervallene skal representeres Hvert tidsintervall identifiseres ved et tidsstempel, f.eks. år+måned, år+ukenummer, år+mnd+dag, år+mnd+dag+time+minutt hva som er «samtidig» Hendelser innen samme tidsintervall kan ikke skilles i tid En informasjonsmodell kan ha flere tidsakser med ulik oppdeling og granularitet det er ikke alltid mulig å bestemme samtidighet på tvers av ulike tidsakser 32

33 Forskjellige tidsakser, eksempel september 2009 Uke ma ti on to fr lø sø : 12: 18: 26: dag uke måned

34 Tidsmessig isomorfi Utviklingen av versjonene må gjenspeile virkeligheten på en hensiktsmessig måte Hvilken type tidspunkter tidsstempelet skal inneholde, må velges etter hva modellen skal reflektere Versjonene må registreres i databasen slik at forsinkelsen fra hendelse til registrering er akseptabel 34

35 Hva skal tidsstempelet reflektere? 1. Når en hendelse faktisk inntraff? 2. Når versjonen ble lagt inn? 3. Når versjonen skal tre i kraft? 4. Når versjonen ble ugyldig? Maks én av disse! (men neppe nr. 4) Merk: De fleste modeller ligger etter virkeligheten, f.eks. nr.1 (og nr. 2): Det tar tid før en hendelse i virkeligheten kan gjenfinnes som en versjon i databasen (mikrosekunder til dager, avhengig av registreringsprosess) Noen modeller må ligge «foran» virkeligheten, f.eks. nr.3 35

36 Tidsmessig kontinuitet Det er maksimalt én versjon pr. mulig tidsstempel Dersom det legges inn færre enn en versjon pr. mulig tidsstempel, så må det være mulig å avlede ikke-materialiserte versjoner for de tidsstemplene som ikke har en tilhørende versjon 36

37 Tidsmessig kontinuitet ansatt avdeling 120 salg 110 salg 081 produksjon 230 økonomi prosjekt ansatt prosj.timer Alfa Beta Alfa Alfa Beta ansatt avdeling 120 salg 110 salg 081 produksjon økonomi prosjekt ansatt prosj.timer Alfa Beta Alfa Alfa Beta ikke-materialisert versjon ansatt avdeling 120 salg 110 salg 081 produksjon salg prosjekt ansatt prosj.timer Alfa Beta Alfa Alfa Beta t 37

38 Film- eller lysbildeprinsippet? lysbildeprinsippet filmprinsippet 38

39 Film- og lysbildeprinsippet Filmprinsippet: Én ny versjon for hvert nytt mulig tidsstempel Trenger mye lagerplass ved fin granularitet Lysbildeprinsippet: Observerer og registrerer virkeligheten bare av og til Bygg inn nok kunnskap til at de ikkematerialiserte versjonene kan utledes 39

40 Elementære setninger og tid Tre typer elementære setninger: De som ikke har noen tidsdimensjon De hvor vi bare ønsker å ta vare på siste aktuelle verdi De hvor vi ønsker å modellere en tidsdimensjon Virkeligheten har to typer endringer: Kontinuerlige Sprangvise Virkelighet kontra modell: Versjonene endrer seg alltid i rykk og napp Versjonene kan være tidsmessig forskjøvet i forhold til virkeligheten 40

41 Begrepsdannelse med tidsaksen 41

42 Eksempel 42

43 Eksempel: Hvor lenge varer det? 43

44 Angivelse av opphør 44

45 Angivelse av varighet 45

46 Tommelfingerregler 1. Vær skeptisk overfor «mange-til-mange» (lange piler) og «en-tilen» (to korte piler) 2. Total rolle står vanligvis på samme side som entydighetsskranken 3. Entydighetsskranken omfatter sjelden mål, vekt, antall o.l. 4. Entydighetsskranken omfatter (nesten) aldri to tidspunkter 5. Manglende total rolle kan skjule et underbegrep 6. Dersom flere stier fører fra et begrep til et annet, sjekk om det finnes overflødige faktatyper eller om vi har ekvivalente stier/ joinskranker 7. Ikke formaliser fritekst det ikke skal søkes i 8. Vær skeptisk overfor begrepsdannelser og underbegreper uten grupperende roller 46

47 Tommelfingerregler (forts.) 9. Roller som spilles av begrepsdannelser har som oftest en entydighetsskranke (intern eller ekstern) 10. Bruk standardiserte referansemåter hvis de finnes 11. Dersom to begreper har samme referansemåte, bør de sannsynligvis tilhøre samme underbegrepsfamilie 12. Ikke baser informasjonsbærende referansemåter på ustabile fakta 13. Gjør informasjonsmodellen robust mot forretningsmessige og politiske endringer (av forretningsreglene i interesseområdet) 47

48 ORM som metode 1 ORM (Object-Role Modelling) er en analysemetode for å lage et begrepsmessig skjema for et gitt UoD Resultatet kan tegnes som et klassisk ORMdiagram, som et ORM2-diagram (Visio/NORMA), eller med en annen passende tegneteknikk 48

49 ORM som metode 2 Når dere bruker metoden i jobbsammenheng, så husk: Det er ikke dere som er eksperter på UoD Ekspertene på UoD kan normalt ikke forventes å forstå deres diagrammer Kommunikasjonen med ekspertene skal foregå på vanlig norsk (eller et annet naturlig språk) og med forekomstdiagrammer for elementære setninger Hensikten med analysen er å gi dere tilstrekkelig kunnskap om UoD slik at dere kan lage en korrekt informasjonsmodell Ansvaret for at dere har forstått ekspertene riktig, er fullt og helt deres (det er dere som er informatikere) 49

50 ORM som metode 3 Det kan være vanskelig å få UoD-ekspertene til å forstå at det er de som skal forklare deg hva UoD er. («Her betaler vi for en datakonsulent, og så må vi lære ham/henne jobben sin» er en ikke ukjent reaksjon) Det å innføre et nytt informasjonssystem må være godt forankret i organisasjonen (både i ledelsen og hos brukerne). 50

51 Kvalitetssikring Kvalitetssikringen av modellen gjøres ved å oversette modellen tilbake til de elementære setningene den uttrykker For en stor analyse kan dette være en tidkrevende (og derfor dyr) prosess Så i praksis bør dere konsentrere dere om de UoD-spesifikke delene av modellen 51

52 Noen eksamensråd for ORM - 1 Tegn og skriv tydelig sensor er ikke tankeleser! Velg begrepsnavn med omhu feil begrepsnavn gjør at modellen blir feil et uheldig begrepsnavn kan villede sensor Alle faktatyper skal ha minst én entydighetspil Hvis entydighetspilene mangler eller plasseres feil, blir modellen feil Alle faktaroller skal ha navn som beskriver rollen 52

53 Noen eksamensråd for ORM - 2 Alle begreper må ha referansemåter I dette emnet bruker vi ORM-diagrammer til å lage relasjonsdatabaser Hvis ikke alle begreper har referansemåter, kan ikke ORM-diagrammet grupperes Nesten alle ekte modeller inneholder begrepsdannelser/eksterne entydigheter Hvis modellen din ikke har noen begrepsdannelser, er det sannsynligvis alvorlige mangler ved modellen 53

54 Noen eksamensråd for ORM - 3 Det er både lurt og lov å spre ORM-modellen over flere ark Skriv hvilke deler av besvarelsen hvert ark gjelder Skriv gjerne kommentarer til Lillebjørn Nilsen er alltid optimist og løser kryssord med kulepenn Men han tegner ikke ORM-modeller med kulepenn Så det viktigste dere tar med dere på ORMeksamenen er blyant og viskelær (og kanskje en blyantspisser) 54