INF1300 Introduksjon til databaser

Transkript

1 UNIVERSITETET I OSLO INF1300 Introduksjon til databaser Dagens tema: Fra skranker til integritetsregler (restriksjoner) Klassifisering av integritetsregler Forekomstrestriksjoner Realisering av integritetsregler i SQL ORM som analysemetode Kvalitessikring av ORM-UML-modeller INF Ragnar Normann 1

2 Fra skranker til integritetsregler Ved gruppering fra en ORM-UML 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 kan 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 INF Ragnar Normann 2

3 Håndtering av verdiskranker En verdiskranke begrenser domenet for et attributt Eksemplet ovenfor 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) ); INF Ragnar Normann 3

4 Gruppererroller og referanseroller I grupperingen vil en mange-til-én assosiasjon fra A til B bli til en fremmednøkkel til B-relasjonen i A-relasjonen En én-til-én assosiasjon mellom B og C hvor bare B-rollen er total, blir til en entydig fremmednøkkel til C-relasjonen i B-relasjonen Rollen til det begrepet som får fremmednøkkelen, kalles gruppererrollen i assosiasjonen (rolle1 og rolle3 i eksemplet) Rollen som blir til en fremmednøkkel, kalles referanserollen i assosiasjonen (rolle2 og rolle4 i eksemplet) INF Ragnar Normann 4

5 Valg av gruppererroller I de to gjenværende tilfellene, én-til-én assosiasjoner med ingen eller to totale roller, både kan og må vi velge hvilken av rollene som skal være gruppererrolle, dvs. hvilken relasjon som skal få fremmednøkkelen Valg av gruppererroller er en del av grupperingsprosessen, og ikke av modelleringsprosessen Det samme gjelder valg av hvilke referanserelasjoner som skal undertrykkes, og hvilke som skal beholdes Resten av grupperingsprosessen er automatiserbar og kan gjøres av en datamaskin INF Ragnar Normann 5

6 Navn på attributter I eksemplet ovenfor vil A-relasjonen få en fremmednøkkel til B-relasjonen bestående av to attributter: ett b-attributt og ett c-attributt Ved maskinell gruppering vil navnene på disse attributtene bli b_rolle2 og C_rolle2 (evt. c_rolle2) Ved manuell gruppering står dere fritt til å avvike fra dette når dere mener dere har bedre attributtnavn INF Ragnar Normann 6

7 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 INF Ragnar Normann 7

8 Ulikhet i referanseroller Gruppert skjema: Person navn {pk} 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 INF Ragnar Normann 8

9 Ulikhet i gruppererroller Gruppert skjema: Person navn {pk} 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 Dette er en forekomstrestriksjon hvor vi bare ser på NULLverdier INF Ragnar Normann 9

10 Dobbeltrolleulikhet Gruppert skjema: Person navn {pk} gren_blir_saget gren_blir_sittet_på Dette er 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 I denne forekomstrestriksjonen sammenligner vi verdier INF Ragnar Normann 10

11 Mengdekranker som blir forekomstrestriksjoner Enkeltrolleskranker som bare går mellom gruppererroller, blir til forekomstrestriksjoner som bare ser på NULL (Dette gjelder også påkrevde rollekombinasjoner) Dobbeltrolleskranker hvor gruppererrollene sammenlignes, blir til forekomstrestriksjoner hvor verdiene i attributtene sammenlignes Ingen andre mengdeskranker blir til forekomstrestriksjoner En generell påkrevd rollekombinasjon som involverer flere referanseroller, er svært dyr å håndheve, og den er derfor kandidat til en skranke vi velger å neglisjere INF Ragnar Normann 11

12 Håndtering av andre skranker Håndtering av delmengde- og likhetsskranker blir helt tilsvarende håndteringen av ulikhetsskranker Ekvivalente stier blir en slags likhetsskranke I tilfellet fra Oblig2 der Billett arver én båt fra Avreise og én båt fra Køye, og verdien av de to båtene må være like i hver Billett-forekomst, ordner vi det enklest ved å slå de to båt-attributtene sammen til ett Fremmednøkler er spesialtilfeller av delmengdeskranker At A har en fremmednøkkel til B er egentlig to skranker: 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 INF Ragnar Normann 12

13 Forekomstrestriksjoner i SQL Gruppert skjema: Person navn {pk} 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: CHECK( (gren_blir_saget IS NULL) OR (gren_blir_sittet_på IS NULL) OR (gren_blir_saget <> gren_blir_sittet_på) ) INF Ragnar Normann 13

14 Andre integritetsregler i SQL Av andre integritetsregler (de som ikke er forekomstrestriksjoner) har vi tidligere sett hvordan vi definerer Primærnøkler Andre entydighetsrestriksjoner Fremmednøkler De øvrige må vi programmere selv Måten dette gjøres på er svært DBMS-avhengig I PostgreSQL gjøres det med databasefunksjoner som kalles fra triggere Dette er behandlet i kapittel 10 i Matthew and Stones INF Ragnar Normann 14

15 PostgreSQL-funksjoner I Postgres 8.0 eller høyere lages funksjoner slik: CREATE FUNCTION fnavn ( [par1 type1 [, par2 type2]... ] ) RETURNS returtype AS $$ programtekst $$ LANGUAGE programmeringsspråk Blant de lovlige programmeringsspråkene er plpgsql (Postgres eget PL/pgSQL) sql (PostgreSQL) perl (PL/Perl) python (PL/Python) Med unntak av sql må språkene lastes inn av superbruker, vanligvis som del av installasjonen INF Ragnar Normann 15

16 Eksempel på PL/pgSQL CREATE FUNCTION fakturasum ( fakturanr integer ) RETURNS trigger AS $$ DECLARE faktsum NUMERIC(9,2); BEGIN SELECT SUM(belop) INTO faktsum FROM Fakturalinje fl WHERE fl.faktura = fakturanr ; UPDATE Faktura SET belop = faktsum WHERE Faktura.faktnr = fakturanr ; RETURN NULL; END; $$ LANGUAGE plpgsql ; INF Ragnar Normann 16

17 Triggere En trigger er en beskjed om at noe ekstra skal skje ved visse hendelser i databasen De mulige hendelsene som utløser en trigger er INSERT, DELETE og UPDATE Også når det gjelder triggere, er det store forskjeller mellom de ulike DBMSene INF Ragnar Normann 17

18 Triggere i PostgreSQL Syntaks for triggerdefinisjoner: CREATE TRIGGER navn { BEFORE AFTER } hendelse1 [ OR hendelse2 [ OR hendelse3 ] ] ON tabell FOR EACH { ROW STATEMENT } EXECUTE PROCEDURE funksjon ( parameterliste ) Hendelsene kan være INSERT, DELETE og UPDATE FOR EACH ROW betyr at funksjon kalles en gang for hver forekomst FOR EACH STATEMENT betyr at funksjon kalles bare en gang INF Ragnar Normann 18

19 Eksempel på trigger CREATE TRIGGER sett_fakturabelop AFTER INSERT OR UPDATE OR DELETE ON Fakturalinje FOR EACH ROW EXECUTE PROCEDURE fakturasum ( Fakturalinje.faktura ) ; INF Ragnar Normann 19

20 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 ORM-diagram eller som et ORM-UML-diagram 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 INF Ragnar Normann 20

21 ORM som metode 2 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) 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 Ragnar Normann 21

22 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-UML-diagrammer, gjør at dere har et «overtak» på UoD-ekspertene Denne modellmakten gjør det farlig å bruke ORM-UMLdiagrammer som argumentasjon i diskusjoner med brukere og UoD-ekspertene Faren ligger i at UoD-ekspertene bekrefter at modellen er riktig uten egentlig å ha forstått den INF Ragnar Normann 22

23 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?) INF Ragnar Normann 23

24 Noen eksamensråd Lillebjørn Nilsen er alltid optimist og løser kryssord med kulepenn Men han tegner ikke ORM-UML-modeller med kulepenn Så det viktigste dere tar med dere på eksamen er blyant og viskelær (og kanskje en blyantspisser) Tegn og skriv tydelig Sensor er ikke tankeleser! Det er lov å spre modellen over flere ark Lykke til neste fredag! INF Ragnar Normann 24