UNIVERSITETET I OSLO INF1300 Introduksjon til databaser Dagens tema: Ringskranker Klisjéer Tommelfingerregler ORM og normalisering Denormalisering og splitting ORM som metode INF1300 7.11.2016 Ellen Munthe-Kaas 1
Ringskranker Utgangspunkt: En binær faktatype der et begrep spiller begge rollene i faktatypen INF1300 7.11.2016 Ellen Munthe-Kaas 2
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 INF1300 7.11.2016 Ellen Munthe-Kaas 3
Irrefleksiv skranke (x,x) pop(r1,r2) Forekomster på formen (a,a) og (b,b) skal aldri være med INF1300 7.11.2016 Ellen Munthe-Kaas 4
Symmetriskranke (x,y) pop(r1,r2) (y,x) pop(r1,r2) Hvis (a,b) er med, så skal (b,a) også være med INF1300 7.11.2016 Ellen Munthe-Kaas 5
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 INF1300 7.11.2016 Ellen Munthe-Kaas 6
Asymmetriskranke = antisymmetri + irrefleksivitet INF1300 7.11.2016 Ellen Munthe-Kaas 7
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 INF1300 7.11.2016 Ellen Munthe-Kaas 8
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 INF1300 7.11.2016 Ellen Munthe-Kaas 9
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. INF1300 7.11.2016 Ellen Munthe-Kaas 10
Kombinerte ringskranker asyklisk og intransitiv asymmetrisk og intransitiv symmetrisk og intransitiv symmetrisk og irrefleksiv INF1300 7.11.2016 Ellen Munthe-Kaas 11
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 INF1300 7.11.2016 Ellen Munthe-Kaas 12
Hode-linje-klisjéen Ekstern entydighet på bestilt/ordrehode dersom en vare ikke får gjentas på flere ordrelinjer innen en ordre INF1300 7.11.2016 Ellen Munthe-Kaas 13
Standard-med-unntak-klisjéen For å finne hvilken avdeling som har ansvar for en vare, sjekker man først om varen har en unntaksrelasjon INF1300 7.11.2016 Ellen Munthe-Kaas 14
Plasseringsklisjéen ekvivalente stier/ joinskranke? INF1300 7.11.2016 Ellen Munthe-Kaas 15
Hierarkiklisjéen enkel variant INF1300 7.11.2016 Ellen Munthe-Kaas 16
Hierarkiklisjéen spesielle varianter INF1300 7.11.2016 Ellen Munthe-Kaas 17
Hierarkisk representasjon INF1300 7.11.2016 Ellen Munthe-Kaas 18
Erstatningsklisjéen familieløsningen INF1300 7.11.2016 Ellen Munthe-Kaas 19
Stykklisteklisjéen realiseres ikke INF1300 7.11.2016 Ellen Munthe-Kaas 20
Tidsakseklisjéen INF1300 7.11.2016 Ellen Munthe-Kaas 21
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 INF1300 7.11.2016 Ellen Munthe-Kaas 22
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) INF1300 7.11.2016 Ellen Munthe-Kaas 23
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. INF1300 7.11.2016 Ellen Munthe-Kaas 24
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. INF1300 7.11.2016 Ellen Munthe-Kaas 25
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 INF1300 7.11.2016 Ellen Munthe-Kaas 26
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; INF1300 7.11.2016 Ellen Munthe-Kaas 27
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). INF1300 7.11.2016 Ellen Munthe-Kaas 28
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 INF1300 7.11.2016 Ellen Munthe-Kaas 29
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 INF1300 7.11.2016 Ellen Munthe-Kaas 30
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 INF1300 7.11.2016 Ellen Munthe-Kaas 31
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 INF1300 7.11.2016 Ellen Munthe-Kaas 32
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 INF1300 7.11.2016 Ellen Munthe-Kaas 33
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) INF1300 7.11.2016 Ellen Munthe-Kaas 34
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 INF1300 7.11.2016 Ellen Munthe-Kaas 35
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. INF1300 7.11.2016 Ellen Munthe-Kaas 36
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 INF1300 7.11.2016 Ellen Munthe-Kaas 37
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) INF1300 7.11.2016 Ellen Munthe-Kaas 38
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). INF1300 7.11.2016 Ellen Munthe-Kaas 39
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 INF1300 7.11.2016 Ellen Munthe-Kaas 40
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 INF1300 7.11.2016 Ellen Munthe-Kaas 41
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 INF1300 7.11.2016 Ellen Munthe-Kaas 42