Normalisering Hensikten med normalisering: En informasjonsenhet ett sted. Forhindrer anomalier Anomalier: Innsettingsanomalier. F.eks være avhengig av å sette inn flere verdi, selv om det er det er bare en verdi du egentlig vil legge til Slettingsanomalier. Sletting av en record kan gjerne fjerne mer enn du ønsker Oppdateringsanomalier. Kan bli dobbellagring (Redundans) Funksjonell avhengighet (X Y): Y er funksjonelt avhengig av X hvis alle tuppler som har samme verdier for en mengde attributter X alltid vil ha samme verdier for en mengde attributter Y Sjekke for normalform: BCNF, hvis en kandidatnøkkel og alle har avhengighet til den kandidatnøkkelen, og ingen andre avhengigheter uten nøkkel. Altså alle determinanter er nøkler 3. NF, hvis en kandidatnøkkel, og ingen andre avhengigheter uten nøkkel 2. NF, hvis kandidatnøkler og uten delvis avhengigheter Ellers antar man 1. NF (Kan ikke ha like verdier,ex. 2 like navn) Bevaring av funksjonell avhengighet og tapsløs join egenskap: Splitter opp og bevarer en funksjonell avhengighet Ex. R(a,b,c) med a b => R1(a,b) og R2(a c) Bevarer siden R1 bevarer ab I eksemplet over har den også tapsløs join siden felles attributtet (første i R2 som er a) også er nøkkel ER-modell 4 klasser av spesialisering med eksempel: Delvis og overlappende. Biler kan ha både automatgir og firehjulstrekk, eller bare en av delene. Og det kan finnes biler uten noen av delene Bil ---- o < gir / 4WD Delvis og disjunkt. Sykler er enten racer- eller terrengsykler, eller ingen av delene. Man kan ikke være begge deler Sykkel ---- d < racer / terreng Total og overlappende. En pasient kan stå på venteliste og komme inn som akuttpasient. Men finnes ikke pasienter som ikke er noen av delene. Pasient == o < akutt / venteliste Total og disjunkt. Alle personer er enten kvinner eller menn, finnes ingen som er begge deler Person == d < kvinne / mann
Lagring og indekser SQL-dictionary: Beskriver hvilke tabeller og indekser vi har og hvordan poster ser ut B-trær: Består av mange vlokker på forskjellige nivåer Datadevice: Hvor blokkene ligger lagret Blokker: Inneholder poster Poster: Er hver record SQL-Query ved hjelp av indeks: Direkte aksess av søkenøkkel, f. eks ved hashindeks. Aksesserer stort sett kun en blokk. Tabell som er clustered hash. Rangequery, f. eks B-tre. Hvis queriet er selektivt, vil indeksen gi god ytelse fordi kun få poster i tabellen vil aksesseres. Indeks sannsynligvis sekundærindeks. Hvordan en randomisert fil (hashed file) er bygget opp: En fil med et fast antall blokker som er adresseområdet. Enten er overløp i egne blokker eller overløpsposter flyter bakover til naboblokker. Begrep: Hjemmeadresse, den blokken som adresseformelen beregner for en post Synonymer, alle poster med samme adresse tilhører en synonymgruppe eller to poster med samme adresse er synonymer Fyllinggrad, det gjennomsnittlige antall poster i hver blokk delt på antall poster per blokk som det er kapasitet til Overløpspost, plass for poster som ikke får plass på hjemmeadressen Hvordan en indeks-sekvensiell fil er bygget opp: En sortert sekvensiell fil med datablokker. Disse kan ligge i fysisk sekvens eller være lenket sammen i en logisk sekvens. For hver datablokk er det en indekspost som inneholder siste nøkkelverdi i datablokken. Indekspostene ligger ligger sortert i en kjede av indeksblokker. For hver indeksblokk er det en indekspost med siste nøkkelverdi i blokken. Disse lagres i en kjede av indeksblokker på nivå 2. Dette mønsteret gjentar seg inntil alle indekser får plass i en blokk (rotblokken). Begrep: Indeksblokk, blokk med indeksposter, når datablokkene er kjedet sammen inneholder indeksposten også en peker til blokken Datablokk, den sekvensielle filen med bare dataposter Rotblokk, blokk med alle indekser fan out,antall indeksposter det er plass til i en indeksblokk Reorganisering, omskriving av hele eller deler av filen for å bedre plassutnyttelsen. B-tre er en indekssekvensiell lagrinsstruktur. Indekssekvensiell aksessmetode versus randomisert aksessmetode: Randomisert lagring ved eksakt nøkkelmatch Indeks-sekvensiell under alle andre forhold
Forskjellige måter å utføre join: Nested loop. For hver post/blokk i den tabellen, gå gjennom alle poster i den andre tabellen og se etter match Index nesten loop. For hver post i den ene tabellen, slå opp i en indeks for den andre tabellen Sort-merge join. Sorter begge tabellene på join-kolonnen og så bruk fletting av tabellene Lagring av poster for å utnytte plass: Postformat, kan lagres med variabellengdeposter. Enten med feltpekere eller med feltseparasjonstegn Blokkformat. Blokker med variabellengdeposter kan ha postene lagret unpacked fra starten av blokken, mens slutten har et slot directory med pekere til postene og antall pekere Antall blokker etter lagringsmetode: Heapfil => poster / gjennomsnittlig antall poster i blokk = blokker Clustered B-tre-indeks => antallet man fikk med heapfil / fyllegrad for B-tre-indeks Clustered hash-indeks => antallet man fikk med heapfil / fyllegrad i hash-indeks Unclustered B-tre med heapfil => antallet man fikk med heapfil + poster*poststørrelse/blokkstørrelse*fyllegradb-tre + B-tre nivå 1 Egenskaper til lagrinsmetoder: Heapfil => innsetting er billig Clustered B-tre-indeks => Slipper sortering Clustered hash-indeks =>Suveren på direkteaksess pga hashnøkkel Unclustered B-tre => Best på enkle lesinger Implementere heapfil: - To sammenlenkede lister av blokker. Den ene listen er full med blokker, andre med ledig plass - Directory of pages, separat sett av indeksblokker som er lenked sammen. Hver indeksblokk inneholder en rekke pekere til vanlige datablokker. Systemkatalogen (SQL-dictionary): Består av informasjon om systemet, som blokkstørrelser, antall blokker i buffer, etc.. I tillegg er det informasjon for hver tabell, view, indeks, restriksjoner og prosedyrer, etc.. Den lagrer også statistikk om antall poster og blokker for hver tabell og indeks. Transaksjoner
Konfliktserialiserbarhet: Hvis transaksjonsavhengigheter ikke går i sykel, altså presedensgrafer ikke har sykel. Ikke sykel => konfliktserialiserbar Konfliktekvivalente serielle historien: Skriv historien i den logiske rekkefølgen slik at man er innom alle tilstandene Ex. T 1 T 2, T 3 T 1, T 3 T 2 Da blir den konfliktekvivalente serielle historien: T 3 T 1 T 2 Klasser til transaksjon-historier: Ikke gjenopprettbar, hvis en starter å skrive til X (w 1 X) og får lest (r 2 X) og commited (c2) før man får commited skrivingen (c 1 ) Gjenopprettbar, hvis den kan bruke cascadingabort. Commiting mellom skriving og lesing overlapper o ex: starter å skrive til X (w 1 X) og får lest (r 2 X). Commiter så skrivingen (c 1 ) før man commiter lesingen (c 2 ) Strict, ACA(AvoidCascadingAbort) og gjenopprettbar, hvis den unngår de to over Fordelene med no-force/steal-strategien for logging/recovery: No-force, at transaksjonenen slipper å skrive data ved commit, det holder med å skrive loggen, som kan gå temmelig raskt Steal, at det er mulig å stjele et skittent buffer. Dette gjør buffermanager mer fleksibel og man slipper at en transaksjon har reservert hele bufferet med sine skitne blokker Hvordan ARIES minimaliserer blokker leses under REDO-recovery: ARIES bruker Dirty Page Table (DPT) og reclsn som sier hvilke datablokker som var skitne (dirty) ved et sjekkpunkt og den første loggposten (reclsn) som gjorde datablokken skitten siden den siste var skrevet til disk. Dette er informasjon som er skrevet i sjekkpunktloggposten. Dette gjør at ARIES slipper å lese inn en del datablokker ved REDO recovery. Når redo ser på en loggpost (med referanse til en datablokk): Hvis datablokken er er DPT, trenger REDO ikke å lese den inn Hvis datablokken er i DPT, men har en reclsn som er større enn LSNen til loggposten, da trenger ikke REDO lese datablokken inn Queryevaluering
I/O operasjoner: Altså hvor mange sjekker man må innom for å finne resultat - Tabellskan, siden den ikke er sortert må man gjennom alle blokkene - Clustered B-tre-indeks, siden den er sortert kan må bruke det. F.eks du skal finne finne de 10% laveste tallene blir det bare 10% av alle blokker. - Unclustered B-tre-indeks, sortert altså f. eks 10% av alle blokker, men må gjennom alle postene => 10%alleBlokker*posterPerBlokk Grunn for at en queryoptimalisator jobber med left-deep plans : For å minske antall planer som vurderes For å kunne utnytte fullt pipelinet utføring Logging og recovery Hensikten med felt i en update-loggpost: prevlsn, peker til forrige loggpost i samme transaksjon transid, transaksjonsidentifikator type, beskriver om det er update, insert, delete, etc.. pageid, identifikatoren til posten for endringen length, lengden av endringen offset, peker inn i posten for endringen before-image, gammelt bilde av posten after-image, nytt bilde av posten Formål med CLR(Compensating Log Record): En CLR kompenserer for en vanlig loggpost, dvs den representerer undo av en loggpost. For å gjøre undo må man da redo e CLRen. Det at vi har CLRer gjør også at vi kan støtte fingranulære låser, dvs låser på postnivå. Dette er fordi en undo ikke setter tilbake PageLSNen, men installerer CLRens LSN inn i PageLSN. Alt: En spesiell redologgpost som er brukt til undo av en annen loggpost. Kan være nyttig for å få til recordnivå låsing. Faser av recovery etter systemkrasj: Analyse, starter fra siste sjekkpunktloggpost i loggen og går framover for å finne taper- og vinnertransaksjoner Redo, sørger for at alle vinnertransaksjoner får gjort ferdig sine operasjoner Undo, ruller tilbake tapertransaksjoner ved å kompensere for de aksjonene den har gjort