INF1300 Introduksjon til databaser

Transkript

1 UNIVERSITETET I OSLO INF1300 Introduksjon til databaser Dagens tema: Ringskranker Klisjéer Tommelfingerregler ORM og normalisering Denormalisering og splitting ORM som metode INF Ellen Munthe-Kaas 1

2 Ringskranker Utgangspunkt: En binær faktatype der et begrep spiller begge rollene i faktatypen INF Ellen Munthe-Kaas 2

3 Refleksiv skranke x pop(r1) pop(r2) (x,x) pop(r1,r2) Hvis (a,b) er med, så må (a,a) og (b,b) også være med INF Ellen Munthe-Kaas 3

4 Irrefleksiv skranke (x,x) pop(r1,r2) Forekomster på formen (a,a) og (b,b) skal aldri være med INF Ellen Munthe-Kaas 4

5 Symmetriskranke (x,y) pop(r1,r2) (y,x) pop(r1,r2) Hvis (a,b) er med, så skal (b,a) også være med INF Ellen Munthe-Kaas 5

6 Antisymmetriskranke (x,y) pop(r1,r2) x y (y,x) pop(r1,r2) Hvis (a,b) er med, der a b, så skal ikke (b,a) være med INF Ellen Munthe-Kaas 6

7 Asymmetriskranke = antisymmetri + irrefleksivitet INF Ellen Munthe-Kaas 7

8 Transitiv skranke (x,y) pop(r1,r2) (y,z) pop(r1,r2) (x,z) pop(r1,r2) Hvis (a,b) og (b,c) er med, så skal (a,c) også være med INF Ellen Munthe-Kaas 8

9 Intransitiv skranke (x,y) pop(r1,r2) (y,z) pop(r1,r2) (x,z) pop(r1,r2) Hvis (a,b) og (b,c) er med, så skal ikke (a,c) være med INF Ellen Munthe-Kaas 9

10 Asyklisk skranke (x 1,x 2 ) pop(r1,r2)... (x n-1, x n ) pop(r1,r2) (x n, x 1 ) pop(r1,r2) Hvis a, b, c, d,.. tolkes som noder i en graf, og forekomsttabellen tolkes som rettede kanter i grafen, så skal grafen være uten sykler. INF Ellen Munthe-Kaas 10

11 Kombinerte ringskranker asyklisk og intransitiv asymmetrisk og intransitiv symmetrisk og intransitiv symmetrisk og irrefleksiv INF Ellen Munthe-Kaas 11

12 Klisjéer Med en klisjé mener vi en standardkonstruksjon som går igjen i modeller, uavhengig av interesseområde Eksempler: Hode/linje-klisjéen Standard-med-unntakklisjéen Plasseringsklisjéen Hierarkiklisjéen Hierarkisk representasjon Erstatningsklisjéen Stykklisteklisjéen Tidsakseklisjéen INF Ellen Munthe-Kaas 12

13 Hode-linje-klisjéen Ekstern entydighet på bestilt/ordrehode dersom en vare ikke får gjentas på flere ordrelinjer innen en ordre INF Ellen Munthe-Kaas 13

14 Standard-med-unntak-klisjéen For å finne hvilken avdeling som har ansvar for en vare, sjekker man først om varen har en unntaksrelasjon INF Ellen Munthe-Kaas 14

15 Plasseringsklisjéen ekvivalente stier/ joinskranke? INF Ellen Munthe-Kaas 15

16 Hierarkiklisjéen enkel variant INF Ellen Munthe-Kaas 16

17 Hierarkiklisjéen spesielle varianter INF Ellen Munthe-Kaas 17

18 Hierarkisk representasjon INF Ellen Munthe-Kaas 18

19 Erstatningsklisjéen familieløsningen INF Ellen Munthe-Kaas 19

20 Stykklisteklisjéen realiseres ikke INF Ellen Munthe-Kaas 20

21 Tidsakseklisjéen INF Ellen Munthe-Kaas 21

22 Tommelfingerregler I Vær skeptisk overfor «mange-til-mange» (lange entydigheter) og «en-til-en» (to korte entydigheter på en binær faktatype) Påkrevd rolle står vanligvis på samme side som entydighetsskranken Entydighetsskranken omfatter sjelden mål, vekt, antall o.l. Entydighetsskranken omfatter (nesten) aldri to tidspunkter Manglende påkrevd rolle kan skjule et underbegrep 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 Ikke formaliser fritekst det ikke skal søkes i Vær skeptisk overfor begrepsdannelser og underbegreper uten grupperende roller INF Ellen Munthe-Kaas 22

23 Tommelfingerregler II Roller som spilles av begrepsdannelser, har som oftest en entydighetsskranke (intern eller ekstern) Bruk standardiserte referansemåter hvis de finnes Dersom to begreper har samme referansemåte, bør de sannsynligvis tilhøre samme underbegrepsfamilie Ikke baser informasjonsbærende referansemåter på ustabile fakta Gjør informasjonsmodellen robust mot forretningsmessige og politiske endringer (av forretningsreglene i interesseområdet) Et begrep som blir til en tabell som kan undertrykkes, men som man ønsker å beholde, mangler trolig en faktatype (f.eks. til en kodeforklaring) INF Ellen Munthe-Kaas 23

24 ORM og normalisering Realisering av korrekte ORM-diagrammer gir alltid 3NF. Realisering av korrekte ORM-diagrammer gir som regel BCNF. Unntakene skyldes alltid problemer knyttet til ekvivalente stier. INF Ellen Munthe-Kaas 24

25 ORM og FDer Entydighetsskranker svarer til funksjonelle avhengigheter. Faktatypen over gir en relasjon A(a,b) med den ikketrivielle FDen a b. Dette ORM-diagrammet gir en relasjon E(a,b,c) med den ikketrivielle FDen ab c. INF Ellen Munthe-Kaas 25

26 ORM og brudd på BCNF - 1 UoD: I hvert prosjekt skal det dokumenteres at krav til sertifiseringer er oppfylt. Det skal være ett dokument pr. krav, og et dokument kan ikke dekke mer enn ett sertifiseringskrav, men det kan gjenbrukes i andre prosjekter. Legg merke til EOPen. Den er nødvendig for å få en korrekt modell. Relasjon Dokument(doknr, skode) Dokumentasjon(prosjnr, skode, doknr) Ikketrivielle FDer doknr skode prosjnr, skode doknr INF Ellen Munthe-Kaas 26

27 ORM og brudd på BCNF - 2 EOPen betyr at oppslag på en skode i Dokumentasjon skal gi et doknr som ved oppslag i Dokument gir samme skode. Integritetsregelen kan sjekkes ved å joine Dokumentasjon og Dokument på likt doknr og kontrollere at det ikke finnes tupler hvor verdiene i de to skode-attributtene er forskjellige. SQL-spørring som finner brudd på regelen: select k.doknr, k.skode, d.skode from Dokumentasjon k, Dokument d where k.doknr = d.doknr and k.skode <> d.skode; INF Ellen Munthe-Kaas 27

28 ORM og brudd på BCNF - 3 På grunn av EOPen vil FDen doknr skode gjelde i Dokumentasjon også: Relasjon Dokument(doknr, skode) Dokumentasjon(prosjnr, skode, doknr) Ikketrivielle FDer doknr skode prosjnr, skode doknr doknr skode Dermed bryter Dokumentasjon BCNF (men oppfyller 3NF). INF Ellen Munthe-Kaas 28

29 Avvik fra optimal normalform Av hensyn til blant annet effektiviseringer kan det enkelte ganger være hensiktsmessig å avvike fra den optimale normalformen som realiseringen av ORM-modellen gir Det er to måter å gjøre slike avvik på: Denormalisering Splitting av relasjoner INF Ellen Munthe-Kaas 29

30 Denormalisering 1 Å denormalisere etter realiseringen betyr å ta en join av to eller flere basisrelasjoner og la resultatet erstatte disse basisrelasjonene Denormalisering gir alltid oppdateringsanomalier Kontroll av oppdateringsanomaliene fører til prosedyrerestriksjoner, enten i applikasjonsprogrammene eller i triggerprogrammer Hensikten er å spare tid ved at svært hyppige joiner er utført på forhånd INF Ellen Munthe-Kaas 30

31 Denormalisering 2 Et vanlig eksempel er lagring av adresser, der en adresse består av gatenavn, gatenummer, postnummer og poststed, og der det til hvert postnummer er ett poststed ORM-diagrammet gir følgende tabeller (som begge er BCNF): Relasjon Adresse(gatenavn, gatenr, postnr) Postnummer(postnr, poststed) Ikketrivielle FDer postnr poststed INF Ellen Munthe-Kaas 31

32 Denormalisering 3 En denormalisering erstatter disse med én tabell: Relasjon Adr(gatenavn, gatenr, postnr, poststed) Ikketrivielle FDer gatenavn, gatenr, postnr poststed postnr poststed Dette gir mulighet for (feilaktig) å lagre samme postnummer med forskjellige poststeder Vi kan få DBMSet til å overholde regelen om at det til hvert postnummer er ett poststed, ved at vi benytter triggere og triggerprogrammer INF Ellen Munthe-Kaas 32

33 Splitting 1 Splitting vil si at vi etter realiseringen velger å fordele attributtene i én basisrelasjon på flere relasjoner (nedenfor kalt delrelasjoner) Det stilles vanligvis tre krav til en splitting, hvorav de to første er absolutte: 1. Alle attributter er med i minst én delrelasjon 2. Primærnøkkelen er med i alle delrelasjonene 3. Ingen attributter som ikke er med i primærnøkkelen, er med i mer enn én delrelasjon INF Ellen Munthe-Kaas 33

34 Splitting 2 Hvis det tredje kravet på forrige side er oppfylt, gir ikke splitting noen oppdateringsanomalier Splitting medfører alltid en økning i antall lese- og skriveoperasjoner Det er to hovedgrunner til splitting: Sikkerhetshensyn Økt effektivitet fordi det er mindre behov for bufferplass (Splitting sparer ikke nevneverdig diskplass) INF Ellen Munthe-Kaas 34

35 Splitting pga. sikkerhetshensyn Splitting kan være nyttig i behandlingen av sensitive data Ta som eksempel pasientdata i helsevesenet: Navn, fødselsdato mm. kan ligge i én relasjon som er allment tilgjengelig Diagnose og prøveresultater kan ligge i en annen relasjon med begrenset tilgjengelighet DBMSer har vanligvis adgangskontroll på tabeller, men ikke på enkeltattributter INF Ellen Munthe-Kaas 35

36 Splitting pga. effektivitet Splitting kan være formålstjenlig hvis den opprinnelige relasjonen har et stort antall attributter der mange forekomster inneholder NULL Dette kan bety mye for behovet for bufferplass, og dermed for mengden av disk-i/o Databaseadministratoren kan på en måte innføre «falske» underbegreper ved hjelp av slik splitting. Ekte underbegreper oppstår når noen forekomster ikke kan ha verdi i et attributt; underbegrepene inneholder de forekomstene som har verdier i dette attributtet. I motsetning til disse skiller splitting ut de forekomstene som akkurat nå tilfeldigvis har en verdi. INF Ellen Munthe-Kaas 36

37 Håndtering av BLOBer Den vanligste bruken av Binary large objects (BLOBer) er lagring av multimediadata (lyd, bilder og video) Selv om SQL tillater å ha BLOB som domene for et attributt, er det dumt å lagre et BLOB som del av en forekomst (det krever for mye bufferplass) I stedet lar vi attributtverdien være en peker inn i et separat diskområde hvor BLOBene lagres Dette kan minne om splitting, men regnes ikke som det INF Ellen Munthe-Kaas 37

38 ORM som metode 1 Object-Role Modelling er en analysemetode for å lage et begrepsmessig skjema for et gitt UoD 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å ORM-diagrammene 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) INF Ellen Munthe-Kaas 38

39 ORM som metode 2 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). INF Ellen Munthe-Kaas 39

40 Modellmakt Begrepet modellmakt ble introdusert av professor i sosiologi Stein Bråten i 1973 Det at dere behersker modelleringsmetoden ORM og har trening i å lese ORM-diagrammer, gjør at dere har et «overtak» på UoD-ekspertene Denne modellmakten gjør det farlig å bruke ORMdiagrammer som argumentasjon i diskusjoner med brukere og UoD-eksperter Faren ligger i at UoD-ekspertene bekrefter at modellen er riktig uten egentlig å ha forstått den INF Ellen Munthe-Kaas 40

41 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 og hoppe over ORM-klisjeene INF Ellen Munthe-Kaas 41

42 Oversettelse til elementære setninger Eksempel: Leirskole Hver elev har nøyaktig ett kjønn Hver elev er tildelt maksimalt én seng Hver seng er for maksimalt én elev Hver seng er i nøyaktig ett rom Hver kombinasjon av ett sengnr og ett rom svarer til maksimalt én seng INF Ellen Munthe-Kaas 42