UNIVERSITETET I OSLO INF1300 Introduksjon til databaser Dagens tema: Informasjonssystemer 100%-prinsippet: Fra virkelighet til informasjonsmodell Forretningsregler, skranker og integritetsregler: Fra modell til databaseskjema 3-skjemaarkitekturen ORM som analysemetode Kvalitetssikring av ORM-modeller Eksamensråd Resten av grupperingsalgoritmen Fra skranker til integritetsregler Klassifisering av integritetsregler: Forekomstrestriksjoner Realisering av integritetsregler i SQL Sterk gruppering Gruppering vs modellering INF1300-9.11.2011 - Ellen Munthe-Kaas 1
Beskrivelse (deskripsjon) av virkeligheten/interesseområdet (Universe of Discourse = UoD) Interesseområdet (UoD) Begrepsdannelse og idealisert representasjon Beskrivelse av interesseområdet INF1300-9.11.2011 - Ellen Munthe-Kaas 2
100%-prinsippet En fullstendig beskrivelse av interesseområdet kalles en informasjonsmodell 100%-prinsippet sier at det er mulig å lage en informasjonsmodell på norsk (eller et annet naturlig språk som engelsk eller japansk) Hvorvidt dette er riktig, er et filosofisk spørsmål I ORM tas 100%-prinsippet som et aksiom (Det vi ikke kan beskrive med ord, kan vi heller ikke lage et informasjonssystem for). Derfor bygger ORM på naturlig språk og lingvistiske prinsipper (elementære setninger). INF1300-9.11.2011 - Ellen Munthe-Kaas 3
Det begrepsmessige skjema Informasjonsmodellen brukt som regelverk (preskripsjon) for hvordan informasjonssystemet skal oppføre seg, kalles det begrepsmessige skjema Det begrepsmessige skjema uttrykkes i et språk som passer for den databaseteknologien vi skal bruke For relasjonsdatabaser bruker vi SQL INF1300-9.11.2011 - Ellen Munthe-Kaas 4
Informasjonssystemer Modelleringsspråk (ORM) Databasespråk (SQL) (kan stanse her) Interesseområdet Forretningsregler (lover) Analyse Informasjonsmodellen Skranker (statiske/dynamiske) Realisering Informasjonssystemet Data Prosesser Integritetsregler INF1300-9.11.2011 - Ellen Munthe-Kaas 5
Forretningregler, skranker og integritetsregler Reglene som gjelder i UoD, kaller vi forretningsregler Beskrivelsen av forretningsreglene i informasjonsmodellen (ORM-modellen) kaller vi skranker I det begrepsmessige skjemaet kaller vi skrankene for integritetsregler Integritetsreglene bestemmer hva som er lovlig å lagre i informasjonssystemet, dvs. hva som er lovlige tilstander i databasen hva som er lovlige forandringer dvs. hva som er lovlige transisjoner/transaksjoner Det er umulig for en bruker av informasjonssystemet å gjøre noe som strider mot integritetsreglene INF1300-9.11.2011 - Ellen Munthe-Kaas 6
Skranker Statiske skranker beskriver begrensninger på mulige tilstander i interesseområdet Dynamiske skranker beskriver begrensninger på mulige forandringer i interesseområdet Den ferdige ORM-modellen er en beskrivelse av de statiske skrankene i vårt UoD For å beskrive de dynamiske skrankene i UoD må vi bruke en annen modelleringsteknikk, f.eks. UMLs sekvensdiagrammer INF1300-9.11.2011 - Ellen Munthe-Kaas 7
3-skjemaarkitekturen for databaser Presentasjonslaget beskrives med eksterne skjemaer ( views ) hvordan informasjon skal presenteres for ulike brukere Det konseptuelle (eller logiske) laget beskrives i det begrepsmessige skjemaet hva som kan lagres, og hva som er lovlige forandringer Det fysiske laget beskrives i det interne skjemaet hvordan informasjon lagres, forandres og behandles INF1300-9.11.2011 - Ellen Munthe-Kaas 8
3-skjemaarkitektur Internt skjema Begrepsmessig skjema Eksternt skjema Intern/fysisk informasjonsbehandler Intern database med fysiske data Begrepsmessig informasjonsbehandler Begrepsmessig database Ekstern informasjonsbehandler (presentasjon) Ekstern database Berit bruker INF1300-9.11.2011 - Ellen Munthe-Kaas 9
Realisering (Grupperingsalgoritmen) Forberedelser: 1. Alle lange piler gjøres om til nye begreper (med ekstern entydighet) 2. Alle begreper må ha (minst) en referansemåte 3. Alle broer må ha en entydig begrepsrolle Grupperingsalgoritmen: 1. For hvert begrep, lag en relasjon 2. For hvert begrep, velg én referansemåte 3. Grupper gjenstående broer til sine respektive begreper 4. Grupper gjenstående faktatyper 5. Overfør skrankene 6. Bestem hvilke referanserelasjoner som skal fjernes (undertrykkes) INF1300-9.11.2011 - Ellen Munthe-Kaas 10
Fra skranker til integritetsregler Ved gruppering fra en ORM-modell til et relasjonsdatabaseskjema blir skrankene i modellen omformet til integritetsregler i skjemaet De aller fleste skrankene overføres direkte til skjemaet Noen få ganger kan det være fornuftig å la være å håndheve en skranke i databasen, men dette er unntak Vi skal aldri ha en integritetsregel i skjemaet som ikke kommer fra en skranke i modellen Det betyr at skjemaet aldri kan være strengere enn modellen INF1300-9.11.2011 - Ellen Munthe-Kaas 11
Gruppererroller og referanseroller I grupperingen vil en mange-til-én-faktatype fra A til B bli til en fremmednøkkel fra A-relasjonen til B-relasjonen En én-til-én faktatype mellom B og C hvor bare B-rollen er total, blir til en entydig fremmednøkkel fra B-relasjonen til C-relasjonen Rollen til det begrepet som får fremmednøkkelen, kalles gruppererrollen i faktatypen (rolle 1 og 3 i eksempelet) Rollen som blir til en fremmednøkkel, kalles referanserollen i faktatypen (rolle 2 og 4 i eksempelet) INF1300-9.11.2011 - Ellen Munthe-Kaas 12
Håndtering av én-til-én- faktatyper uten totale roller Her har vi et valg: Vi kan velge å peke ut en av rollene som gruppererrolle, dvs. hvilken relasjon som skal få fremmednøkkelen Vi kan velge å danne et begrep av faktatypen Det grupperte resultatet blir i såfall en relasjon som består av to kandidatnøkler som er fremmednøkler til de to relasjonene som stammer fra de to begrepene som inngår i faktatypen. (En av kandidatnøklene velges som primærnøkkel.) Merk: I storm må vi i såfall selv foreta denne begrepsdannelsen INF1300-9.11.2011 - Ellen Munthe-Kaas 13
Håndtering av én-til-én- faktatyper med to totale roller Slike faktatyper forekommer sjelden Ett eksempel er en faktatype som kobler sammen hovedsteder med sine land Vi må da velge en av rollene som gruppererrolle Dersom ett av de involverte begrepene bruker denne faktatypen som sin prefererte referanse, har vi gjort en analysefeil. De to begrepene skal da slås sammen til ett begrep, og faktatypen skal fjernes fra ORM-modellen INF1300-9.11.2011 - Ellen Munthe-Kaas 14
Håndtering av eksterne entydigheter Eksterne entydigheter blir til kandidatnøkler En ekstern entydighet kan derfor brukes som referansemåte for et begrep INF1300-9.11.2011 - Ellen Munthe-Kaas 15
Navn på attributter 1 I eksempelet over vil A-relasjonen få en fremmednøkkel til B- relasjonen bestående av to attributter: ett C-attributt og ett D-attributt Ved maskinell gruppering i storm vil navnene på disse attributtene bli C_rolle2 og D_rolle2 (evt c_rolle2 og d_rolle2 hvor c og d er representasjonene til hhv C og D) I storm kan man gi alternative relasjons- og attributtnavn hvis man ikke synes de automatisk genererte navnene egner seg INF1300-9.11.2011 - Ellen Munthe-Kaas 16
Navn på attributter 2 Ved manuell gruppering kan dere velge navnene på de to attributtene i fremmednøkkelen fritt Det kan dere forøvrig gjøre for alle andre attributter også INF1300-9.11.2011 - Ellen Munthe-Kaas 17
Håndtering av underbegreper Underbegreper arver alltid representasjonen til sitt superbegrep Anta: Alle superbegrep har minst én underbegrepsforklaring Alle underbegrep har minst én gruppererrolle Til hvert underbegrep opprettes en relasjon med samme primærnøkkel som superbegrepet, og med fremmednøkkel fra underbegrepets primærnøkkel til superbegrepets. To alternativer: 1. Attributter fordeles mellom superbegrepets og underbegrepets relasjoner 2. Alle attributtene fra superbegrepets relasjon (unntatt underbegrepsforklaringen) gjentas i underbegrepets relasjon INF1300 17.11.2010 Ellen Munthe-Kaas 18
Håndtering av verdiskranker En verdiskranke begrenser domenet for et attributt Eksempelet over gir følgende definisjon av Medaljeutbytte: CREATE TABLE Medaljeutbytte ( land_navn CHAR(20) NOT NULL REFERENCES Land(navn), med_kode CHAR(1) NOT NULL CHECK(med_kode IN ( G, S, B )), antall INTEGER CHECK( (0 < antall) AND (antall < 70) ), CONSTRAINT med_utb_pk PRIMARY KEY(land_navn,med_kode) ); INF1300-9.11.2011 - Ellen Munthe-Kaas 19
Forekomstrestriksjoner En integritetsregel som kan håndheves lokalt i en enkelt forekomst i en tabell, kalles en forekomstrestriksjon På engelsk kalles den en «intra-record constraint» En integritetsregel som ikke er en forekomstrestriksjon, har ikke noen egen betegnelse på norsk På engelsk kalles den en «inter-record constraint» Forekomstrestriksjoner er billige å håndheve fordi vi ikke trenger å lese noen andre forekomster enn den vi holder på med Forekomstrestriksjoner kan bare brytes ved innlegging og endring, aldri ved sletting INF1300-9.11.2011 - Ellen Munthe-Kaas 20
Ulikhet i gruppereroller Gruppert skjema: Person(personnavn, gren_blir_saget, gren_blir_sittet_på) Her sammenligner vi to gruppererroller for Person, og disse skal ikke ha noen felles forekomst Det betyr at ingen forekomst av Person skal finnes både i rollen sitter_på og i rollen sager Når vi legger inn en ny forekomst av Person, må vi altså kontrollere at minst ett av attributtene gren_blir_sittet_på og gren_blir_saget er NULL INF1300-9.11.2011 - Ellen Munthe-Kaas 21
Ulikhet i referanseroller Gruppert skjema: Person(personnavn, gren_blir_saget, gren_blir_sittet_på) Her sammenligner vi to referanseroller til Gren, og disse skal ikke ha noen felles forekomst Når vi legger inn en ny forekomst av Person, må vi kontrollere at 1) verdien i gren_blir_saget ikke må finnes som verdi i gren_blir_sittet_på i noen tidligere forekomster 2) verdien i gren_blir_sittet_på ikke må finnes som verdi i gren_blir_saget i noen tidligere forekomster INF1300-9.11.2011 - Ellen Munthe-Kaas 22
Dobbeltrolleulikhet Gruppert skjema: Person(personnavn, gren_blir_saget, gren_blir_sittet_på) I dette tilfellet har vi en dobbeltrolleskranke hvor vi sammenligner de to gruppererrollene Den sier at ingen forekomstpar av Person og Gren skal ha samme verdi i rolleparene (sager, blir saget) og (sitter på, blir sittet på) Når vi legger inn en ny forekomst av Person, må vi altså kontrollere at minst ett av attributtene gren_blir_saget og gren_blir_sittet_på er NULL eller at de har forskjellig verdi INF1300-9.11.2011 - Ellen Munthe-Kaas 23
Mengdeskranker som blir til forekomstrestriksjoner Enkeltrolleskranker som bare går mellom gruppererroller, blir til forekomstrestriksjoner som bare ser på NULL. Dette gjelder også kombinerte totale roller mellom gruppererroller Dobbeltrolleskranker hvor gruppererrollene sammenlignes, blir til forekomstrestriksjoner hvor verdiene i attributtene sammenlignes Ingen andre mengdeskranker blir til forekomstrestriksjoner En generell kombinert total rolle som involverer flere referanseroller, er svært dyr å håndheve, og den er derfor kandidat til en skranke vi velger å neglisjere INF1300-9.11.2011 - Ellen Munthe-Kaas 24
Håndtering av andre skranker I Håndtering av delmengde- og likhetsskranker blir helt tilsvarende håndteringen av ulikhetsskranker 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 INF1300-9.11.2011 - Ellen Munthe-Kaas 25
Håndtering av andre skranker II Fremmednøkler er spesialtilfeller av delmengdeskranker At A har en fremmednøkkel til B håndheves som to integritetsregler: Ved INSERT på A må vi sjekke at fremmednøkkelen har en lovlig verdi (peker på en forekomst av B) Ved DELETE av en B må vi sjekke at ingen A har en fremmednøkkel til denne forekomsten av B INF1300-9.11.2011 - Ellen Munthe-Kaas 26
Forekomstrestriksjoner i SQL Gruppert skjema: Person(personnavn, gren_blir_saget, gren_blir_sittet_på) Alle forekomstrestriksjoner kan i SQL uttrykkes ved hjelp av CHECK() Eksempel: Når vi legger inn en ny forekomst i Person, må minst ett av attributtene gren_blir_saget og gren_blir_sittet_på være NULL, eller de må ha forskjellig verdi I SQL uttrykkes dette slik (i table Person): CHECK( (gren_blir_saget IS NULL) OR (gren_blir_sittet_på IS NULL) OR (gren_blir_saget <> gren_blir_sittet_på) ) INF1300-9.11.2011 - Ellen Munthe-Kaas 27
Andre integritetsregler i SQL Av andre integritetsregler (de som ikke er forekomstrestriksjoner) har vi tidligere sett hvordan vi definerer Primærnøkler Andre entydighetsrestriksjoner (dvs. kandidatnøkler) Fremmednøkler De øvrige må vi programmere selv i form av databasefunksjoner som kalles fra triggere INF1300-9.11.2011 - Ellen Munthe-Kaas 28
Sterk gruppering 1 Ved vanlig gruppering vil ikke-totale gruppererroller gi attributter hvor NULL er tillatt Det å gruppere sterkt betyr at nullverdier aldri er tillatt Resultatet blir at relasjonene må splittes: Vi får én relasjon med de attributtene som kommer fra faktatyper med total gruppererrolle Faktatyper hvor gruppererrollen ikke er total, blir til en egen relasjon bestående av primærnøkkelen og attributtet fra denne faktatypen Ved likhetsskranke mellom gruppererroller kan attributtene fra disse faktatypene legges i samme relasjon INF1300-9.11.2011 - Ellen Munthe-Kaas 29
Sterk gruppering 2 Sterk gruppering gir samme resultat som det å opprette et underbegrep hver gang vi får en ikketotal gruppererrolle Det gjør at alle gruppererroller blir totale ved sterk gruppering Resultatet blir en relasjonsdatabase hvor ingen attributter kan være NULL INF1300-9.11.2011 - Ellen Munthe-Kaas 30
Referansebegreper og undertrykking av relasjoner (repetisjon) Et begrep som ikke spiller noen andre gruppererroller enn de som inngår i den utvalgte referansemåten, og som spiller minst én referanserolle, kalles et referansebegrep Tabeller som kommer fra referansebegreper, kan fjernes (undertrykkes) fra relasjonsdatabaseskjemaet INF1300-9.11.2011 - Ellen Munthe-Kaas 31
Gruppering vs modellering Følgende er en del av grupperingsprosessen og ikke av modelleringsprosessen: 1. Valg av referansemåter og hvilke datatyper som skal knyttes til representasjonene 2. Valg av gruppererroller 3. Valg av om det skal brukes sterk gruppering 4. Valg av hvordan underbegreper skal realiseres 5. Valg av hvilke referanserelasjoner som skal undertrykkes og hvilke som skal beholdes Grupperingsprosessen er automatiserbar og kan gjøres av en datamaskin Man kan lage generelle regler for hvordan 1-5 skal håndteres og få en helautomatisert grupperingsprosess, men databaseskjemaet blir bedre hvis det gjøres bevisste valg der hvor det er mer enn én mulighet INF1300-9.11.2011 - Ellen Munthe-Kaas 32
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 (storm), som et ORM2-diagram (Visio/NORMA), eller med en annen passende tegneteknikk INF1300-9.11.2011 - Ellen Munthe-Kaas 33
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) INF1300-9.11.2011 - Ellen Munthe-Kaas 34
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). INF1300-9.11.2011 - Ellen Munthe-Kaas 35
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-9.11.2011 - Ellen Munthe-Kaas 36
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 (for der gjør dere vel ikke feil?) INF1300-9.11.2011 - Ellen Munthe-Kaas 37
Eksamen Eksamen er delt i to likeverdige deleksamener som begge må være bestått for å bestå kurset: Design av relasjonsdatabaser (ORM, gruppering,...): Tirsdag 29. november kl. 9.00 13.00 Bruk av relasjonsdatabaser (SQL, normaliseringsteori,...): Fredag 9. desember kl. 14:30 18.30 På den første av de to eksamenene får dere lov til å bruke blyant og viskelær på besvarelsen. De gule gjennomslagsarkene blir ikke brukt i sensuren av akkurat denne eksamenen. Læreboken er eneste tillatte hjelpemiddel på eksamen (For fremmedspråklige er ordbok tillatt) INF1300-9.11.2011 - Ellen Munthe-Kaas 38
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 INF1300-9.11.2011 - Ellen Munthe-Kaas 39
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 INF1300-9.11.2011 - Ellen Munthe-Kaas 40
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) INF1300-9.11.2011 - Ellen Munthe-Kaas 41