Datamodellering FINF400 28. august 2003. amanuensis Gerhard Skagestein Institutt for informatikk, UiO gerhard@ifi.uio.no To formål en modell? Diskusjonspunkter Realiseringsplattformens innvirkning på modellen Grafiske dialekter ER, UML klassediagrammer, ORM Attributter eller assosiasjoner? Behovet for datatyper Valg av identifikator { key } Hva er en weak entity? Undertyper når skal vi bruke dem? Generalisering/spesialisering Hva er egentlig et individ? Tesselering i rom og tid Grensetrekking mellom skjema og forekomster Noen mønstre FINF400DM - FINF400DM -2 Figur -. Informasjonssystemet gjenspeiler «virkeligheten» Figur -2. Data krever tolkning Virkeligheten (interesseområdet) Referanseramme registrering påvirkning Oppfatningen av virkeligheten Annen relevant kunnskap Oppfatningen av virkeligheten Brukere Informasjonssystem Informasjonssystem Data Brukere! Informasjon Virksomheten FINF400DM -3 FINF400DM -4
Modellenes to formål Interesseområdet Beskrivelse Figur 5-2. Ogdens trekant Thoughts of Reference Begreper Person Bil Døgn Oppfatningen av interesseområdet Foreskrivelse 8076543873 DF 2345 9. febr. 2003 2003-02-9 Informasjonssystem Brukere Symbol Lingvistiske elementer representasjoner Referent Fenomener i interesseområdet FINF400DM -5 FINF400DM -6 En enkel datamodell Figur 5-3. Datamodell attributter erstattet med assosiasjoner fylkenavn {unique} omfatter : ligger-i 0: kommunenr{id} avfallsmengde {null} innbyggertall omfatter : stilhørighet Multiplisitet ligger-i 0: Klasse, stereotypet som begrep 0: avfallsmengde navn fylkenavn {id} navn {id} # tonn {id} Mengde Assosiasjon Rolle innbyggertall # {id} Antall FINF400DM -7 FINF400DM -8
Figur 5-6. Bruk av identifiserende assosiasjon Figur 5-3. Datamodell med identifiserende assosiasjon omfatter ligger-i omfatter : ligger-i 0: stilhørighet Klasse, stereotypet som begrep Multiplisitet navn fylkenavn {id} tosifret kommunenr kommunenr2s {id} kommunenr2s {id} navn {id} 0: avfallsmengde # tonn {id} Mengde Assosiasjon Rolle innbyggertall # {id} Antall FINF400DM -9 FINF400DM -0 Figur 5-3b. Modell med fremmednøkler Figur 5-5. Relasjonsdatabasen fylkenavn {fk} {unique} navn fylkenavn {id} fylkenavn navn fylkenavn omfatter : navn ligger-i 0: {fk} {id} kommunenr2s {id} {fk} avfallsmengde {fk} {null} innbyggertall {fk} 0: avfallsmengde navn {id} Mengde # tonn {id} Antall kommunenr2s Mengde Antall antall_tonn antall avfallsmengde innbyggertall innbyggertall # {id} FINF400DM - FINF400DM -2
Figur 5-8. Relasjonsdatabase uten unyttige tabeller Figur 5-9. Modell uten unyttige klasser fylkenavn fylkenavn {unique} omfatter : kommunenr2s avfallsmengde innbyggertall ligger-i 0: {fk} {id} kommunenr2s {id} avfallsmengde {null} innbyggertall FINF400DM -3 FINF400DM -4 Figur 5-6. Relasjonsdatabasestruktur uten nil Figur 5-7. Modell med mange-til-mange-assosiasjon kommunenr2s avfallsmengde innbyggertall gjenvunnet_materiale Materiale materialnavn {id} kommunenr2s innbyggertall 2 kommunenr2s innbyggertall FINF400DM -5 FINF400DM -6
Figur 5-8. Modell med assosiasjonsklasse Figur 5-9. Assosiasjonsklassen erstattes med en vanlig klasse Materialgjenvinning 0: gjenvunnet mengde gjenvunnet_materiale # tonn {id} Mengde Materiale materialnavn {id} Materialgjenvinning gjenvunnet_ materiale Materiale materialnavn {id} 0: gjenvunnet mengde # tonn {id} Mengde FINF400DM -7 FINF400DM -8 Figur 5-. Spesialisering og generalisering Underbegreper Figur 5-2. Modell med underbegreper Mann fødselsnr {id} a) far mor Generalisering Kvinne fødselsnr {id} Spesialisering Person fødselsnr {id} far mor b) omfatter Navn navn {id} {disjoint, complete} Person ligger-i navn navn c) fødselsnr {id} {disjoint, complete} Mann far mor Kvinne FINF400DM -9 FINF400DM -20
Figur 5-5. Modell med generalisering Figur 5-7. Håndtering av underbegreper omfatter ligger-i fylkenavn navn {id} Navn Kjønn kjønnskode {id} diskriminerende assosiasjon Person fødselsnr {id} 0: {disjoint, complete} Fornavn navn {id} Mann Kvinne antall fødsler Antall # {id} FINF400DM -2 FINF400DM -22 a) Separasjon Figur 5-7. Håndtering av underbegreper Person fødselsnr kjønn fornavn Figur 2-22. Samme fenomen uten og med tidsdimensjon Mann fødselsnr Kvinne fødselsnr b) Absorpsjon Person fødselsnr kjønn fornavn c) Partisjonering antall_fødsler antall_fødsler nil hvis kjønn = m Én forekomst for hvert tidspunkt! t t Person ansattnr{id} Kjønn kjønnskode{id} Person fødselsnr Kan sløyfes, ingen forekomster Mann fødselsnr kjønn fornavn Kvinne fødselsnr kjønn fornavn antall_fødsler År årstall{id} Personår 0: #kg{id} Vekt FINF400DM -23 FINF400DM -24
ansattnr{id} kjønn Figur 2-23. UML klassediagram og tilsvarende relasjonsdatabase, uten og med tidsdimensjon Person Person ansattnr kjønn Intensjon og ekstensjon Husholdningsavfall Relasjonsskjema nr nr navn Databasens intensjon Avfallsmengde Personår Databasens ekstensjon ansattnr {id} {fk} årstall {id} vekt Personår ansattnr årstall vekt Tupler/ Linjer/ Forekomster 0 0 0 00 004 005 Halden Moss Sarpsborg 0228 0423 2600 FINF400DM -25 FINF400DM -26 Diskusjonspunkter Når bør vi normalisere? Databaser Fra modell til relasjonsdatabase Fra modell til OO-database FINF400 4. september 2003 Hvordan oppnå permanens Brukerklienter og databasetjenere. amanuensis Gerhard Skagestein Institutt for informatikk, UiO gerhard@ifi.uio.no Statisk vs dynamisk SQL prekompilering vs. rutinekall Tilgangskontroll Sikringsmekanismer Distribuerte databaser: To-fase-commit vs. replikering FINF400DM -27 FINF400DM -28
Høyere ordens assosiasjoner en vederstyggelighet Høyere ordens assosiasjon vist som tabell År År omfatter : årstall {id} omfatter : årstall {id} Ikke i henhold til UML-standarden! ligger-i 0: ligger-i 0: Materialgjenvinning gjenvunnet_ materiale Materiale materialnavn {id} Materialgjenvinning gjenvunnet_ materiale Materiale materialnavn {id} navn navn Er entydighetsskranken korrekt? Er tabellen normalisert? {id} {id} FINF400DM -29 FINF400DM -30 Høyere ordens assosiasjon vist som tabell Høyere ordens assosiasjon løst opp med nytt begrep År År jf. figur 5-0 i Skagestein: Systemutvikling årstall {id} årstall {id} omfatter : ligger-i 0: navn {id} Materialgjenvinning gjenvunnet_ materiale Materiale materialnavn {id} navn {id} Materialgjenvinning omfatter : ligger-i 0: gjenvunnet_ materiale 0: gjenvunnet mengde Materiale materialnavn {id} # tonn {id} Mengde FINF400DM -3 FINF400DM -32
Statiske og dynamiske virkelighetsmodeller Dataorientert (statisk) virkelighetsmodell Interesseområdet t Virkelighetsmodellen omfatter o virkelighetens tilstander og deres representasjoner registrering påvirkning o regler for lovlige/ulovlige tilstander og tilstandsoverganger Informasjonssystem Oppfatningen av interesseområdet t Brukere t Virkelighetsmodellen omfatter ikke transformasjoner fra en tilstand til den neste Informasjonssystemet får istedenfor en melding om at virkeligheten har endret seg, og virkelighetsmodellen oppdateres ved hjelp av funksjoner i applikasjonslaget. Virkelighetsmodellen deles av alle funksjoner FINF400DM -33 FINF400DM -34 Objektorientert (dynamisk) virkelighetsmodell Virkelighetsmodellen gjenspeiler konkrete og/eller tenkte (mentale) objekter, med hver sin tilstand og hver sin oppførsel Virkelighetsmodellens objekter kan selv sørge for transformasjoner fra en tilstand til den neste Informasjonssystemet må i tillegg ha funksjoner (ofte implementert ved hjelp av objekter) for o (resten av) forretningslogikken o brukergrensesnittet Fra det dataorienterte til det objektorienterte perspektiv I det dataorienterte perspektivet interesserer vi oss for faktaopplysninger av statisk natur om interesseområdet, og skranker som forhindrer registrering av åpenbart uriktige fakta I det objektorienterte perspektivet interesserer vi oss for virkelige og tenkte objekter i interesseområdet, og hvordan disse objektene gjennom samarbeide kan gi en hensiktsmessig modell Javel, men har ikke da disse perspektivene svært lite til felles? FINF400DM -35 FINF400DM -36
Andre relevante forskjeller I OO har vi som collection ikke bare mengde, men også bag, list og array > krav om entydighetsskranke faller bort > forekomstene kan ordnes I OO kan strukturer som set, bag, list og array, samt generelle objekter, brukes som verdier > uendelige mange muligheter for hvordan data struktureres I OO er dataene innkapslet i objektene > dataenes struktur er ukjent for omverdenen - de kan bare fås tak i gjennom spørremeldinger (jf. neste lysark) i OO har objekter sin egen innebygde identifikator (OID) > begreper behøver ikke alltid ha en representasjon Ah, hvilken frihet - men vi betaler vel noe for dette? Klasser eller objekter først? Dataorientert utforming: Begreper og klasser, deretter forekomster Men: Homogenitetsregelen Objektorientert utforming: Objekter, deretter klasser Hvorfor forskjellen i praktisk fremgangsmåte? FINF400DM -37 FINF400DM -38 Forholdet mellom det generelle og det spesielle (klasser og objekter) Det generelle, eksisterer det egentlig, eller er det noe vi har funnet på for å beskrive/snakke om verden på en enklere måte? o Eks: kråker, mennesker o Eksisterer slike fellesbegreper, eller er det bare vår egen begrepsdannelse? o Hvis de eksisterer, er de av fysisk eller åndelig natur? o Eksisterer det generelle evt. fritt fra de enkelte individene, eller bare som del av disse? Debatt fra 00- tallet, interessant for systemutviklere Nominalist Nominalist eller Realist o Det som eksisterer er bare enkeltindividene. Generelle fellesbegreper er skapt av menneskene, bl.a. for bedre å forstå/beskrive verden (eks. Wilhelm av Occam og Charles Darwin) Realist o Generelle fellesbegreper som kråke, menneske har en egen eksistens, og enkeltindividene er dannet etter disse (eks: Platon og Thomas av Aquinas) FINF400DM -39 FINF400DM -40
Datadrevet vs. ansvarsdrevet modellering Datamodellering: Hvilke ting må systemet vite om, og hva må det vite om disse tingene? Datadrevet OO: Hvilke objekter har vi? Hva må et objekt vite om seg selv, og hvilke andre objekter må det kjenne til? Hva må hvert objekt kunne gjøre for å kunne løse oppgaven? Hvilke objektbeskrivelser (=klasser) trengs? Ansvarsdrevet OO: Hvilke objekter må til for å løse oppgaven, og hvilket ansvar må hvert objekt ivareta? Hva må hvert objekt kunne gjøre for å oppfylle ansvaret? Hva må et objekt vite om seg selv, og hvilke andre objekter må det kjenne til? Gir disse ulike tankemåtene samme svar? Objektorientert vs. dataorientert utforming Både dataorienterte og objektorienterte informasjonssystemer inneholder data. Forskjellen er at i dataorienterte systemer er alle data samlet i en sentral ressurs databasen, mens i objektorienterte systemer er dataene fordelt på objektene ut fra det generelle prinsipp at det objektet som har bruk for data selv tar vare på dem. I objektorienterte systemer får dataene evig liv ved å gjøre objektene persistente. Dette kan realiseres på flere måter for eksempel ved hjelp av en OO-database. Ugrupperte modeller bygd med elementære utsagn er i utgangpunktet nøytrale overfor hvilket perspektiv som velges. Perspektivet kommer inn når de elementære utsagnene skal grupperes til relasjonsdatabase eller inn i objekter. Gruppering til relasjonsdatabase kan gjøres utelukkende ut fra skrankene i den ugrupperte dataorienterte modellen (i UML eller ORM). For gruppering til objekter må vi i tillegg se på ansvarsfordelingen. FINF400DM -4 FINF400DM -42 Objektorientert vs. dataorientert utforming Informasjonssystem new new klasse Objektorientert Realisering av klassediagrammet fylkenavn relasjonsdatabase {fk} komnr2s {id} objekter Program Informasjonssystem CREATE INSERT INSERT Dataorientert klasse (entitet) 0 0 fylkenavn 0 Østfold komnr2s 0 04 Halden Moss Østfold: 0 Østfold evt. metoder realiseres ved hjelp av OIDs eller relationships : 00 Halden evt. metoder : 004 Moss evt. metoder FINF400DM -43 FINF400DM -44
Til relasjonsdatabase: Generering av fremmednøkler Stryk unyttige klasser År År navn {id} årstall {id} omfatter : ligger-i 0: «identi- fying» {fk}{id} kommunenr2s {id} {fk} Materialgjenvinning kommunenr{fk}{id} gjenvunnet_mat{fk}{id} år{fk}{id} gjenvunnet_mengde{fk} gjenvunnet_ materiale 0: gjenvunnet mengde Materiale materialnavn {id} Mengde # tonn {id} FINF400DM -45 omfatter : ligger-i 0:? «identi- fying» Materiale materialnavn {id} {fk}{id} kommunenr2s {id} {fk} navn {id} årstall {id} Materialgjenvinning {fk}{id} kommunenr2s{fk}{id} gjenvunnet_mat{fk}{id} årstall{id} gjenvunnet_mengde gjenvunnet_ materiale 0: gjenvunnet mengde # tonn {id} Mengde FINF400DM -46 Relasjonsdatabasen Figur 0-0. Sekvensdiagram for avfallsstatistikk-system Kontrollobjekt Forretningsobjekter Delmengdeskranke/ referanseintegritet Materiale materialnavn :Brukergrensesnitt :Statistikkinteressert person Be om statistikk :Statistikkprodusent new( ) :HeleLandet Halden: Moss: Halden998: Gjenvinning Halden200: Gjenvinning Moss998: Gjenvinning kommunenr2s lagstatistikk(args) hentdata(args) mengde:=gjenvunnetmengde (periode,materiale) mengde :=gjenvunnetmengde(materiale) mengde := gjenvunnetmengde(materiale) mengde :=gjenvunnetmengde (periode,materiale) mengde := gjenvunnetmengde(materiale) gjenta for alle kommuner gjenta for alle aktuelle år Materialgjenvinning kommunenr2s gjenvunnet_mat år gjenvunnet_mengde Fjern objektet det trengs ikke lenger FINF400DM -47 FINF400DM -48
Figur 0-. Klassediagram for avfallsstatistikk-system Flytting av grense skjema/forekomster HeleLandet struct hentdata(args) int gjenvunnetmengde (periode, materiale) Materialgjenvinning årstall {id} papirmengde glassmengde plastmengde kommune 00 00 00 materiale papp glass plast gjenvunnet 344 446 0 Opprinnelig struktur Objektorientert klassediagram int gjenvunnetmengde (materiale) 005 005 005 papp glass plast 252 237 0 Mer metadata, mindre data Dataorientert klassediagram Materialgjenvinning årstall {id} materialnavn {id} mengde kommune 00 005 papp 344 252 glass 446 237 plast 0 0 FINF400DM -49 FINF400DM -50 Skranker Hvorfor er skranker så viktige i dataorientert utforming, og lite omtalt i objektorientert utforming? En relasjonsdatabase har ingen egen bevissthet, og trenger et regelverk og en vaktbikkje til å beskytte seg Objekter har oppførsel, og vi antar at de følger Kardemommeloven: Du skal ikke plage andre, du skal være grei og snill og for øvrig kan du gjøre hva du vil Antagelsen holder ikke nødvendigvis alltid stikk (programmeringsfeil!) derfor er skranker på vei inn også i objektorienterte systemer jfr OCL (Object Constraint Language) Integritetsskranker i relasjonsdatabaser Brukergrensesnitt Integritetsregler Metadata Kunde Ordre Database Primærnøkler og entitetsintegritet Fremmednøkler og referanseintegritet Andre skranker Brukerdata Databasehåndteringssystem (DBMS) FINF400DM -5 FINF400DM -52
Klient-tjener-filosofi klient Spørreklienter mot databasetjenere - et eksempel på klient/tjener-arkitektur tjener klient klient tjener klient kan du være så snill å... Spørreklienter mot databasetjenere - en typisk anvendelse av klient/tjener-arkitektur o Felles, ytelsesoptimalisert, sikret database o Personlig brukergrensesnitt og datamassasje med fornøyelse! Det er alt gjort! Hver enkelt klient og tjener er et selvstendig (autonomt) system! Klienten er proaktiv, tjeneren reaktiv klient Database tjener FINF400DM -53 FINF400DM -54 PC -databasehåndterere Ekte klient-tjener-løsninger SQL Frittstående maskin hent filer SQL prosedyrekall Filtjener Databasetjener Databasetjener I begge tilfeller gjøres databaseoperasjonene på brukerens maskin! lagret prosedyre PC i nett Klient-tjener-løsning med SQL-grensesnitt Klient-tjener-løsning med lagrede prosedyrer FINF400DM -55 FINF400DM -56
Mellomvare ( Middleware ) Open Database Connectivity ODBC Komponenter o Applikasjon Applikasjon Mellomvare Standardiserte grenseflater o Driver Manager o Drivere o Datakilder ( = DBMS med data ) Driver Manager Driver Driver Driver ODBC interface Mellomvaren skjuler ulikheter i databasegrensesnitt eventuelt datanett En Microsoft standard! Datakilde Datakilde Datakilde FINF400DM -57 FINF400DM -58 ODBC med eksempel på drivere Java Database Connectivity JDBC Komponenter Application Application Application Driver to Oracle SQLNet ODBC API ODBC Driver Manager Service Provider API Driver to SQL Server Net Lib Driver to DB2/6000 ESQL/DRDA Driver to NonStop SQL NS SQL o Applikasjon (skrevet i Java) o Driver Manager (objekter med metoder) o Drivere o Datakilder ( = DBMS med data ) Applikasjon Driver Manager Driver Driver Driver Datakilde Datakilde Datakilde JDBC interface FINF400DM -59 FINF400DM -60
Hvordan oppnå persistens Eksplisitt overføre objekter til og fra et permanent lager med read/write - kommandoer o Databasen er skilt fra programmet Deklarere objekter persistente ved fødselen eller senere (enten som egenskap ved klassen, ved persistent new, eller referert fra persistent rotobjekt) o Databasen er integrert med programmet (Illusjonen om Det Ene Datalager) read/write Usynlige fra programmet virtuelt permanent lager Databasen integrert med programmet Programmeringsspråket er også datamanipuleringsspråk (Java, C++, Smalltalk?) Transiente og persistente objekter behandles likt - enkel programmering Persistens bør kunne gjelde alle typer objekter Persistent Transient Type Persistent = evigvarende! Transient = midlertidig (så lenge programmet går) FINF400DM -6 FINF400DM -62 Databasen skilt fra programmet Ett standard datamanipuleringsspråk (SQL, OQL?) Sentral databaseadministrasjon Basen først - så programmene Databasespråk DDL/ODL Datadefinisjonsspråk (for skjemamanipulering) DCL - Data-kontrollspråk (for tilgangskontroll) Mye semantikk i basen - integritetsregler osv. Kan brukes fra programmer i mange ulike programmeringsspråk DML/OQL Datamanipuleringsspråk Programmeringsspråk datamanipuleringsspråk o Forskjellige datatyper? o Impedance mismatch? FINF400DM -63 FINF400DM -64
Bruk av SQL Som selvstendig språk som regel interaktivt Som databasespråk i et vertsspråk o Embedded SQL (SQL-kommandoer som må prekompileres er lagt inn i programteksten) o Call Level Interface (SQL-subrutiner kalles fra programteksten) Embedded SQL er lettere å programmere, men databasens struktur må være fastlagt ved prekompileringen! Prekompilator er bundet til DBMS-produktet. Derfor er Call Level Interface mer i vinden! import java.sql.; import oracle.sql.; import javax.swing.; import oracle.jdbc.driver.; Figur 4-0 a. Bruk av SQL i et Java-program Oppkobling mot databasen class OracleInf02 { public static void main(string args[ ]) throws SQLException { // Last ned Oracle JDBC driveren DriverManager.registerDriver(new oracle.jdbc.driver.oracledriver( )); // Be bruker om brukernavn og passord String brukernavn = JOptionPane.showInputDialog("Brukernavn: "); String passord = JOptionPane.showInputDialog("Passord: "); // Oppkobling mot databasen Connection conn = DriverManager.getConnection ("jdbc:oracle:thin:@volund.ifi.uio.no:52:stubas",brukernavn, passord); FINF400DM -65 FINF400DM -66 Figur 4-0 b. Bruk av SQL i et Java-program Spørring og utskrift // Lag et SQL-setningsobjekt Statement stmt = conn.createstatement(); // Utfør en spørring ResultSet rset = stmt.executequery("select from Husholdningsavfall"); // Iterer gjennom resultatet og skriv ut noen av attributtene while ( rset.next( ) ) { System.out.print (rset.getstring()); // attributt nr System.out.print (" " + rset.getstring("navn")); System.out.println (" " + rset.getstring("avfallsmengde")); } System.exit(0); // fordi JOptionPain brukes uten foreldrevindu } } //OracleInf02 Persistent JAVA, ortogonal persistens import org.opj.store.pjstore; import org.opj.store.pjstoreimpl; import org.opj.store.pjsexception; class Test { } public static void main(string args[]) { try { PJStore ps = new PJStoreImpl("/home/user/pjs/stores/TestStore.pjs");... Object[] objectarray = new Object[00]; ps.newproot("object Array", objectarray);... } } catch (PJSException e) { System.err.println(e); } Trikset er å gjøre objektene nåbare fra et permanent rotobjekt FINF400DM -67 FINF400DM -68
Eksempel på en ODL-spesifikasjon interface Person { extent people; key SSN; attribute Integer SSN; attribute string name; attribute struct <Integer number, string street, Ref<City> city> address; relationship Set<Person> children inverse Person::parents {order_by birth_date}; relationship Person[2] parents inverse Person::children; ancestors (out Set<Person>) raises (no_such_person); move (in Address); } Jack.dateOfBirth select c.crse_title, c.credit_hrs from courses c where c.crse_code = MBA 664 select s.age from students s where s.name = John Marsh select s from students s where s.gpa >= 3.0 Eksempler OQL Select x.enrollment from courseofferings x x.belongs_to y where y.crse_code = MBA 664 and x.section = select c.crse_code, c.crse_title from students s s.takes x x.belongs_to c where s.name = Mary Jones FINF400DM -69 FINF400DM -70 Database-transaksjoner Datasikkerhet Transaksjon: Et udelelig stykke arbeid mot databasen Sikring av tilgang til data for de berettigede Forhindring av tilgang for de uberettigede Skal ideelt sett tilfredsstille ACID -kravene: ACID Atomiticy Consistency preservation (serializability) Durability Isolation Hva du gjør, gjør fullt og helt, og ikke stykkevis og delt! Beskyttelse av data mot hendelig eller villet tap, ødeleggelse eller misbruk. FINF400DM -7 FINF400DM -72
Tilgangskontroll Autentiseringsmekanismer o (ved hjelp av noe du vet, noe du har, noe du er) Autorisasjonsregler o Autorisasjonsmatriser o Eksterne skjema ( Views ) Tilgangskontroll Autorisere brukere, gi adgang til data GRANT. Trekke tilbake autorisasjoner REVOKE... Krypteringsmekanismer En autorisasjonsmatrise! FINF400DM -73 FINF400DM -74 Sikringskopiering og gjenoppretting Sikringskopierings-mekanismer Logging o Transaksjonslogg o Endringslogg - før- og etterbilder Sjekkpunkt-etablering o Restart-punkt etter feil Gjenopprettings-mekanismer Fremover- og tilbakerulling sikringskopiering sjekkpunkt fremoverrulling ønsket tilstand tilbakerulling Ved sjekkpunkt er ingen transaksjoner aktive, og databasen i en konsistent tilstand Fremoverrulling er aktuelt etter nedlasting fra sikkerhetskopi Fremoverrulling gjøres for bekreftede transaksjoner problem Databasens utvikling Tilbakerulling er aktuelt etter avbrutte transaksjoner: Brukeravbrudd, brudd på integritetsregler, samtidighetskontroll Tilbakerulling (UNDO) gjøres for ubekreftede transaksjoner samt for bekreftede transaksjoner som har lest data skrevet av ubekreftede transaksjoner (kaskaderende tilbakerulling) Fremover- og tilbakerulling forutsetter en logg (etterbilder og førbilder) FINF400DM -75 FINF400DM -76
Fremoverrulling (b) Rollforward Tilbakerulling FINF400DM -77 FINF400DM -78 Distribuerte databaser Mellomvare Interessante spørsmål: o Replikering? o Hvem er master? o To-fase-commit eller asynkron forplantning av oppdateringer? FINF400DM -79