Föreläsningsmaterial

Föreläsningsmaterial
DAV B04 - Databasteknik Föreläsningsmaterial KaU - Datavetenskap - DAV B04 - MGö

KaU - Datavetenskap - DAV B04 - MGö
DAV B04 - Databasteknik Introduktion (kap 1, 2) KaU - Datavetenskap - DAV B04 - MGö

Databaser och databashanteringssystem
Databaser och databashanteringssystem En databas (DB) är en samling av relaterad data representerar någon aspekt av verkligheten; minivärlden eller University of Discourse (UoD) Databashanteringssystem (DBHS) programvarusystem som används för att skapa och underhålla databaser ”Ett filhanteringssystem som kan hantera komplexa relationer mellan data och hämta och uppdatera data enkelt och effektivt” KaU - Datavetenskap - DAV B04 - MGö Karlstads Universitet, Datavetenskap

Databas-system Ett databas-system (DBS) består av DBHS-mjukvaran tillsammans med själva databasen (applikationer, användare) KaU - Datavetenskap - DAV B04 - MGö

Egenskaper hos databas-system
Data är integrerad och delad I DBHS lagras en beskrivning av databasen struktur, integritetsregler mm Visst mått av dataoberoende KaU - Datavetenskap - DAV B04 - MGö

Datamodell Används för att gömma implementationsdetaljer ge användarna en konceptuell vy av databasen Stödjer många olika vyer av databasen KaU - Datavetenskap - DAV B04 - MGö

(Andra) fördelar med databas-system
Redundansen kan minskas Säkerheten kan förbättras Flera olika användargränssnitt Integriteten kan upprätthållas Stöd för återhämtning av data Tiden för applikationsutveckling kan minskas KaU - Datavetenskap - DAV B04 - MGö

Nackdelar med databas-system
Ofta höga kostnader för hårdvara, mjukvara och utbildning Komplexiteten hos ett DBHS kan ibland vara onödig eller ge för låg prestanda KaU - Datavetenskap - DAV B04 - MGö

Användare av databas-system
Databasadministratörer (DBA) Applikationsprogrammerare Slutanvändare KaU - Datavetenskap - DAV B04 - MGö

Olika typer av databas-system
främst hierarkiska databaser och nätverksdatabaser Från ca 1980 de flesta nya databas-system varit relationsdatabaser Från ca 1990 objektorienterade och objektrelationella databaser KaU - Datavetenskap - DAV B04 - MGö

Datamodeller En samling koncept för att beskriva databasens struktur De integritetsregler den måste följa Oftast också de operationer som går att göra på databasen KaU - Datavetenskap - DAV B04 - MGö

Högnivå-modeller Använder koncept som ligger nära hur användare förstår data. Används ofta vid databasdesign. Exempel E/R-modellen KaU - Datavetenskap - DAV B04 - MGö

Logiska modeller Använder koncept som kan förstås av användare Ligger inte alltför långt ifrån hur data organiseras i databasen KaU - Datavetenskap - DAV B04 - MGö

Lågnivå-modeller Använder koncept som beskriver i detalj hur data är lagrad rent fysiskt KaU - Datavetenskap - DAV B04 - MGö

Databasens schema Beskrivningen av databasen Kan visas i ett schemadiagram KaU - Datavetenskap - DAV B04 - MGö

Exempel på schemadiagram
KaU - Datavetenskap - DAV B04 - MGö

Databasens gränssnitt
Varje användare kommunicerar med databasen m h a ett språk Programmerare: konventionellt programspråk (C eller Pascal) Slutanvändare: något frågespråk (SQL), eller kommunicerar med databasen genom något specialdesignat menysystem KaU - Datavetenskap - DAV B04 - MGö

Språk Varje språk inkluderar ett underspråk (data sublanguage eller DSL) som sägs vara inbäddat i värdspråket (host language) KaU - Datavetenskap - DAV B04 - MGö

Dataoberoende Logiskt dataoberoende Det går att göra ändringar i det konceptuella schemat utan att det påverkar de externa schemana eller applikationsprogrammen Fysiskt dataoberoende Det går att göra ändringar i det interna schemat utan att det påverkar det konceptuella schemat KaU - Datavetenskap - DAV B04 - MGö

Beståndsdelar DSL Data Definition Language (DDL) den del av språket som används för att definiera de olika objekten som databasen består av Data Manipulation Language (DML) den del av språket som används för att manipulera eller utföra operationer på sådana objekt KaU - Datavetenskap - DAV B04 - MGö

Applikationer skrivna av användaren
Skrivna i något programspråk (t ex C) med inbäddad SQL eller applikationer skrivna i SQL KaU - Datavetenskap - DAV B04 - MGö

Applikationer skrivna av någon leverantör (tools)
Kompilatorer för något frågespråk, rapportgeneratorer, grafiska användargränssnitt, kalkylprogram, statistikprogram, 4GL-kompilatorer, CASE-verktyg KaU - Datavetenskap - DAV B04 - MGö

Program som används för att administrera databasen
Laddningsprogram, backup-program, reorganisationsprogram, statistik- och analysprogram KaU - Datavetenskap - DAV B04 - MGö

Katalogen (Data Dictionary)
Ett DBHS måste innehålla en katalog eller ett data dictionary, där detaljerad information om systemets olika delar lagras information om tabeller, index, användare, integritets- och säkerhetsregler lagras också som tabeller, så att det går att ställa frågor till katalogen på samma sätt som till databasen KaU - Datavetenskap - DAV B04 - MGö

Översikt av kursen Genomgång av relationsmodellen Genomgång av SQL + praktiska övningar Konceptuell databasdesign Fysisk databasdesign Transaktionshantering Databassäkerhet Web-databaser och distribuerade databaser Laborationer: teori, design, implementation och användargränssnitt KaU - Datavetenskap - DAV B04 - MGö

Relationsmodellen (kap 7)
DAV B04 - Databasteknik Relationsmodellen (kap 7) KaU - Datavetenskap - DAV B04 - MGö

Relationsmodellen En formell teori som baserar sig på (främst) mängdlära predikatlogik Föreslogs av E.F Codd 1970 i artikeln ”A relational model for large shared data banks” i Communications of the ACM, juni 1970 KaU - Datavetenskap - DAV B04 - MGö

Relationsmodellen Relation är den matematiska termen för tabell En databas ses som en mängd relationer DB = {R1, R2,…Rn} KaU - Datavetenskap - DAV B04 - MGö

Relationsmodellen Beskriver ett sätt att se på data från en logisk synvinkel Tre aspekter av data datastrukturer (eller objekt) huvudsakligen tabeller datamanipulation (eller operationer) operationer är bl. a SELECT, PROJECT och JOIN dataintegritet de viktigaste reglerna är de om entitetsintegritet och referensintegritet KaU - Datavetenskap - DAV B04 - MGö

Domäner En domän är en namngiven mängd av skalära värden, alla av samma typ Varje attributs värden måste tas från exakt en underliggande domän En domän är vad man i moderna programspråk kallar en datatyp De flesta av dagens relationsdatabaser stödjer dock bara primitiva datatyper som CHARACTER, INTEGER och FLOAT KaU - Datavetenskap - DAV B04 - MGö

Exempel på domäner typedef enum{London, Paris, Athens, New York, Stockholm, Rome} City; Detta skapar en datatyp City i ett C-program. Alla variabler av typen City måste ha som värde en av de uppräknade städerna KaU - Datavetenskap - DAV B04 - MGö

Exempel på domäner CREATE DOMAIN City Char(9) DEFAULT ’???’ CHECK (VALUE IN (’London’, ’Paris’, ’Athens’, ’New York’, ’Stockholm’, ’Rome’, ’???’ ) ) KaU - Datavetenskap - DAV B04 - MGö

Relationer En relations schema består av en mängd attribut R = {A1, A2, …An} Varje attribut är definierat på exakt en underliggande domän Attributnamnen i en relation måste vara unika Flera attribut kan dock vara definierade på samma domän KaU - Datavetenskap - DAV B04 - MGö

Relationer En relations tillstånd eller värde vid en viss tidpunkt benämns r och består av en mängd tupler t (0 eller flera) r = {t1,t2,…tn} Varje tuple t består av en mängd värden v där varje värde är hämtat från motsvarande domän t = {v1,v2,…vn} KaU - Datavetenskap - DAV B04 - MGö

Relationer Antalet tupler i en relation kallas relationens kardinalitet Antalet attribut i en relation kallas relationens grad En eller flera attribut som unikt identifierar en tuple kallas för relationens primärnyckel KaU - Datavetenskap - DAV B04 - MGö

Egenskaper hos en relation
Det finns inga duplicerade tupler Tuplerna är oordnade det finns ingen ”första” eller ”sista ”tuple” Attributen är oordnaded det finns inget ”första” eller ”sista” attribut Alla värden är atomära (skalära) (detta betyder att en relation alltid är i första normalformen) KaU - Datavetenskap - DAV B04 - MGö

Olika sorters relationer
En namngiven relation är en relation som har definierats i databasen En basrelation är en relation som inte är en härledd relation, utan existerar ”på riktigt” En härledd relation är en relation som är definierad i termer av andra relationer KaU - Datavetenskap - DAV B04 - MGö

Olika sorters relationer
En vy är en namngiven härledd relation som är virtuell – den existerar bara som ett uttryck Ett frågeresultat är en icke namngiven härledd relation som är resultatet av att en specifik fråga exekveras KaU - Datavetenskap - DAV B04 - MGö

Vyer (virtuella relationer)
En vy är en härledd relation som är namngiven relationen finns bara som ett uttryck och brukar därför kallas en virtuell relation Vyer har flera användningsområden, men det viktigaste är att de kan användas för att skapa logiskt dataoberoende KaU - Datavetenskap - DAV B04 - MGö

Logiskt dataoberoende
Ett system har logiskt dataoberoende om användare och applikationer inte påverkas av ändringar i databasens logiska struktur Logiskt dataoberoende kan bara uppnås om systemet stödjer operationer på vyer på ett korrekt sätt! KaU - Datavetenskap - DAV B04 - MGö

Logiskt dataoberoende
Två aspekter Om databasen växer, d v s om t ex ett attribut läggs till en relation eller en relation läggs till databasen, kan dessa ändringar gömmas med hjälp av vyer Om databasen omstruktureras, t ex om en relation bryts ner i två stycken, kan vyer användas för skapa illusionen om att det fortfarande är en enda relation KaU - Datavetenskap - DAV B04 - MGö

Andra fördelar med vyer
Vyer tillåter att samma data kan ses av olika användare på olika sätt samtidigt Vyer kan användas som "macron” Vyer kan användas för att gömma data (av säkerhetsskäl) KaU - Datavetenskap - DAV B04 - MGö

Integritet Integritet handlar om att se till att data i databasen är korrekt Vid varje tillfälle innehåller en databas en mängd datavärden som skall representera en viss del av "verkligheten” Vissa värden kan inte tillåtas eftersom de inte representerar något som finns i verkligheten (t ex negativa löner) När databasen definieras måste därför också vissa integritetsregler läggas till. Dessa gör det möjligt för DBHS att hindra att inkorrekta värden läggs in i databasen KaU - Datavetenskap - DAV B04 - MGö

Exempel på integritetsregler
Integritetsregler i COMPANY-databasen SALARY i relationen EMPLOYEE måste vara större än noll SEX i relationen EMPLOYEE måste ha värdet M eller F SSN i relationen EMPLOYEE måste bestå av nio siffror KaU - Datavetenskap - DAV B04 - MGö

Integritetsregler Reglerna i exemplet är databas-specifika (eller semantiska), dvs. de gäller bara för en specifik databas Relationsmodellen innehåller också två generella integritetsregler, dvs. regler som gäller för alla databaser kandidatnycklar (och primärnycklar) främmandenycklar KaU - Datavetenskap - DAV B04 - MGö

Definition av en kandidatnyckel
Låt R vara en relation. Då är en kandidatnyckel för R en delmängd av Rs mängd av attribut, säg K, så att vid varje givet tillfälle, så har två olika tupler i R inte samma värde på K (K är unik) om K är sammansatt, så kan ingen del av K tas bort och K fortfarande vara unik (K är ej reducerbar) KaU - Datavetenskap - DAV B04 - MGö

Enkla och sammansatta kandidatnycklar
En kandidatnyckel som består av mer en ett attribut sägs vara sammansatt En kandidatnyckel som består av exakt ett attribut sägs vara enkel KaU - Datavetenskap - DAV B04 - MGö

Kandidatnycklar Kandidatnycklar definieras som mängder av attribut Skälet till att kandidatnycklar är så viktiga är att det enda sättet att adressera en speciell tuple är genom att använda ett värde på en kandidatnyckel KaU - Datavetenskap - DAV B04 - MGö

Exempel kandidatnycklar
Ex i COMPANY: Employee: K = {SSN} Project: K = {PNUMBER} Works_on: K = {ESSN,PNO} KaU - Datavetenskap - DAV B04 - MGö

Primärnycklar och alternativa nycklar
Primärnyckel en nyckel som väljs från mängden kandidatnycklar Alternativ nyckel den återstående mängden kandidatnycklar när primärnyckeln har tagits bort KaU - Datavetenskap - DAV B04 - MGö

Sekundärnyckel En sekundärnyckel är en nyckel som när den används för sökning kan returnera en relation med fler än en tuple Ex. SELECT SSN from EMPLOYEE WHERE DNO = 5; DNO är här en sekundärnyckel KaU - Datavetenskap - DAV B04 - MGö

Nycklar och saknad information (nulls)
Nulls är något som används i databaser för att handskas med saknad information För varje attribut i en relation kan man specificera NULLS ALLOWED eller NULLS NOT ALLOWED KaU - Datavetenskap - DAV B04 - MGö

Tolkningar av NULL Vissa logiska svårigheter värde okänt egenskapen ej relevant värde finns inte värde odefinierat KaU - Datavetenskap - DAV B04 - MGö

Regeln om entitetsintegritet
Ingen del av primärnyckeln i en basrelation får vara null I en relationsdatabas lagrar vi inte information om någonting vi inte kan identifiera! KaU - Datavetenskap - DAV B04 - MGö

Definition av främmandenyckel (FK)
Låt R2 vara en basrelation. Då är en främmandenyckel i R2 en delmängd av mängden attribut i R2, säg FK, så att det finns en basrelation R1 (R1 och R2 behöver ej vara olika) med en kandidatnyckel CK, och för varje tillfälle, så är varje värde på FK i relationen R2 antingen helt och hållet null eller identiskt med värdet på CK i någon tuple i R1 KaU - Datavetenskap - DAV B04 - MGö

Främmandenycklar Varje attribut i en främmandenyckel måste definieras på samma domän som det motsvarande attributet i den matchande kandidatnyckeln KaU - Datavetenskap - DAV B04 - MGö

Främmandenycklar Främmande-till-kandidatnyckel referenser sägs ibland vara det "lim" som håller ihop databasen. Dessa sägs representera relationer mellan olika tupler KaU - Datavetenskap - DAV B04 - MGö

Regeln om referensintegritet
Databasen får inte innehålla några icke matchande värden på främmandenycklar dvs. om B refererar till A, så måste A existera KaU - Datavetenskap - DAV B04 - MGö

Regler för främmandenycklar
Vad ska då systemet göra om en operation försöker utföras som skulle bryta mot regeln om referensintegritet ? För varje främmandenyckel i databasen skall databasdesignern specificera vad som skall hända vid delete eller update av den matchande kandidatnyckeln KaU - Datavetenskap - DAV B04 - MGö

Exempel på regler för främmandenycklar
Vad skall t ex hända om någon försöker ta bort eller uppdatera ’ ’ i relationen EMPLOYEE? Två möjligheter (åtminstone) finns för båda operationerna: RESTRICTED - operationerna är förbjudna om ’ ’ också finns i WORKS_ON CASCADES - operationerna utförs också på de tupler som innehåller ’ ’ i SHIPMENT KaU - Datavetenskap - DAV B04 - MGö

Semantiska integritetsregler
Även kallade business rules Gäller för en specifik databas KaU - Datavetenskap - DAV B04 - MGö

Exempel på semantiska integritetsregler
Regler av typen ”Ingen kan ha en lön som är mindre än 10000” kan specificeras med domänregler Regler av typen ”Varje anställd måste tillhöra en avdelning” specificeras genom att ange NOT NULL för attributet DNO i EMPLOYEE Regler av typen ”Ingen anställd får ha högre lön än sin chef” kan specificeras genom triggers eller assertions KaU - Datavetenskap - DAV B04 - MGö

Relationsalgebra (kap 7)
DAV B04 - Databasteknik Relationsalgebra (kap 7) KaU - Datavetenskap - DAV B04 - MGö

Relationsalgebra Operationer som görs på relationer för att hämta data från en databas Utdata från alla operationer är en ny relation (algebran är sluten). Detta gör det möjligt att skriva nästlade operationer KaU - Datavetenskap - DAV B04 - MGö

Operationer De speciella relationsoperationerna select, project, join och division De traditionella mängdoperationerna union, intersection, difference och cartesian product KaU - Datavetenskap - DAV B04 - MGö

SELECT  SELECT returnerar en relation som består av alla tupler från en relation som uppfyller ett visst villkor SELECT-operationen benämns <selection condition> (R) KaU - Datavetenskap - DAV B04 - MGö

<selection condition> (R)
Den resulterande relationen har samma attribut som R Villkoret är av formen X <jämförelseoperator> Y, där X är ett attributnamn och Y är ett attributnamn eller en konstant. Flera villkor kan sättas samman med hjälp av AND, OR och NOT SELECT är unär, dvs indata är en relation KaU - Datavetenskap - DAV B04 - MGö

PROJECT  PROJECT returnerar en relation som består av alla tupler i en relation sedan vissa attribut har utelämnats PROJECT-operationen benämns <attribute list> (R) KaU - Datavetenskap - DAV B04 - MGö

<attribute list> (R)
Den resulterande relationen har bara de attribut som specificeras i attributlistan Duplicerade tupler tas bort av PROJECT PROJECT är unär, dvs. indata är en relation KaU - Datavetenskap - DAV B04 - MGö

Sekvenser av operationer
Flera operationer kan kombineras för att bilda ett algebraiskt uttryck (en fråga) Exempel: Hämta namn och löner för anställda som arbetar på avdelning 4: P FNAME,LNAME,SALARY (s DNO=4(EMPLOYEE) ) KaU - Datavetenskap - DAV B04 - MGö

RENAME Alternativt så kan man specificera temporära relationer för varje steg: DEPT4_EMPS s DNO=4(EMPLOYEE) R  P FNAME,LNAME,SALARY(DEPT4_EMPS) KaU - Datavetenskap - DAV B04 - MGö

RENAME Attribut i den resulterande relationen kan ges andra namn om man så vill: DEPT4_EMPS  s DNO=4(EMPLOYEE) R(FIRSTNAME,LASTNAME,SALARY)  P FNAME,LNAME,SALARY(DEPT4_EMPS) KaU - Datavetenskap - DAV B04 - MGö

Traditionella mängdoperationer
Dessa binära operationer fungerar som motsvarande operationer i matematiken En viktig skillnad operanderna måste vara typkompatibla, dvs. bestå av samma slags tupler (gäller ej produkt) KaU - Datavetenskap - DAV B04 - MGö

UNION: R1  R2 Unionen av två typkompatibla relationer R1 och R2 är en relation med samma huvud som både R1 och R2 med en kropp som består av mängden av alla tupler t som finns i R1 eller i R2 eller i båda KaU - Datavetenskap - DAV B04 - MGö

INTERSECTION: R1  R2 Snittet av två typkompatibla relationer R1 och R2 är en relation med samma huvud som både R1 och R2 med en kropp som består av mängden av alla tupler t som finns i både R1 och R2 KaU - Datavetenskap - DAV B04 - MGö

DIFFERENCE: R1 – R2 Differensen mellan två typkompatibla relationer R1 och R2, i den ordningen, är en relation med samma huvud som både R1 och R2 och med en kropp som består av mängden av alla tupler t som finns i R1 men inte i R2 KaU - Datavetenskap - DAV B04 - MGö

CARTESIAN PRODUCT: R1 X R2
Den kartesiska produkten av två relationer R1 och R2 ger en relation med alla möjliga kombinationer av tupler från R1 och R2 är meningslös i sig själv KaU - Datavetenskap - DAV B04 - MGö

THETA JOIN Är det samma som en kartesisk produkt följt av en SELECT-operation THETA JOIN benämns R1<join condition>R2 Oftast jämförs ett attribut i R1 med ett i R2 i villkoret KaU - Datavetenskap - DAV B04 - MGö

EQUIJOIN Kallas operationen om villkoret är ”=” KaU - Datavetenskap - DAV B04 - MGö

NATURAL JOIN är det samma som EQUIJOIN, men där join-attributet i R2 är borttaget i resultatrelationen NATURAL JOIN benämns R1 * R2 R1 * <join attribute1>, <join attribute2> R2 KaU - Datavetenskap - DAV B04 - MGö

DIVISION tar två relationer, en binär och en unär, och returnerar en relation som består av alla värden som ett av den binära relationens attribut har och där det andra attributet matchar alla värden i den unära relationen DIVISION benämns R1  R2 KaU - Datavetenskap - DAV B04 - MGö

DAV B04 - Databasteknik SQL (kap 8) KaU - Datavetenskap - DAV B04 - MGö

SQL - frågespråk för relationsdatabaser
4GL, mycket kraftfullt jämfört med t ex C/C++ och FORTRAN SEQUEL SQL (Structured Query Language) SQL-86 SQL1 (ANSI-standard) SQL-92 SQL2 SQL3 kommer bl.a. att vara objektorienterat KaU - Datavetenskap - DAV B04 - MGö

SQL i kursen Olika dialekter, vi använder Microsoft Jet SQL (separat kompendium) MySQL KaU - Datavetenskap - DAV B04 - MGö

Beståndsdelar SQL Data Definition Language (DDL) med hjälp av kommandon i DDL skapar man och kan modifiera scheman, tabeller, villkor och vyer Manipulation Language (DML) kommandona i DML möjliggör läsning, skrivning, insättning, radering och förändring av tabellinnehåll KaU - Datavetenskap - DAV B04 - MGö

SQL uttryck Tabell = relation Rad = tuple Kolumn = attribut KaU - Datavetenskap - DAV B04 - MGö

DDL-operationer CREATE Skapa tabell, schema, vy, domän… DROP Radera tabell eller… ALTER Lägg till eller ta bort i tabell KaU - Datavetenskap - DAV B04 - MGö

DML-operationer SELECT Välj ut data ur tabell(er) INSERT Skriv in rad(er) DELETE Radera rad(er) UPDATE Modifiera kolumner i rad(er) KaU - Datavetenskap - DAV B04 - MGö

DAV B04 - Databasteknik ER-diagram (kap 3) KaU - Datavetenskap - DAV B04 - MGö

Datamodellering KaU - Datavetenskap - DAV B04 - MGö

ER (Entity Relationship) - diagram
Konceptuell datamodellering ER modellen beskriver data utifrån entiteter attribut relationer KaU - Datavetenskap - DAV B04 - MGö

Entiteter ”Sak” i verkliga världen existerar fysiskt, ex bil, student existerar konceptuellt, ex univ.kurs, jobb KaU - Datavetenskap - DAV B04 - MGö

Entiteter och attribut
Varje entitet har attribut, dvs. egenskaper som beskriver entiteten Student: namn, ålder, adress... KaU - Datavetenskap - DAV B04 - MGö

Attributens värde En existerande entitet har värden på sina attribut student s1: ”Kalle”, 47, ”Karlstad” Denna typ av data utgör majoriteten av information sparad i en databas! KaU - Datavetenskap - DAV B04 - MGö

Sammansatta attribut Kan delas ned i mindre delar som har oberoende betydelse KaU - Datavetenskap - DAV B04 - MGö

Mångvärdes attribut Vanligtvis har ett attribut bara ett värde, men... Vad händer om ex. en bil har tre olika färger? KaU - Datavetenskap - DAV B04 - MGö

Härledda attribut Exempelvis kan man härleda en persons ålder från personnummer och nuvarande år KaU - Datavetenskap - DAV B04 - MGö

Entitetstyper Definierar en mängd av entiteter som har samma attribut (varje entitet i mängden har dock egna värden på attributen) En entitetstyp beskrivs därmed med hjälp av entitetens namn och dess attribut STUDENT: Namn, ålder, adress KaU - Datavetenskap - DAV B04 - MGö

Entitetsmängder Samlingen/mängden av alla entiteter av en viss entitetstyp i databasen vid någon given tid KaU - Datavetenskap - DAV B04 - MGö

Nyckelattribut Varje entitetstyp skall ha ett attribut vars värde skall vara unikt för varje enskild entitet i entitetsmängden Student: Personnummer, namn, ålder KaU - Datavetenskap - DAV B04 - MGö

Relationer mellan entiteter
Som i: samband mellan entiteter KaU - Datavetenskap - DAV B04 - MGö

Relationer och attribut
En relation kan också ha attribut Exempelvis: en student på en kurs har ett betyg... KaU - Datavetenskap - DAV B04 - MGö

Kardinalitet på relationer 1:1 förhållande

Kardinalitet på relationer 1:N förhållande

Kardinalitet på relationer N:M förhållande

Mappning mellan ER-diagram och relationsmodellen (kap 9)
DAV B04 - Databasteknik Mappning mellan ER-diagram och relationsmodellen (kap 9) KaU - Datavetenskap - DAV B04 - MGö

Mappning ER-diagram / relationsmodellen
Används för att skapa den logiska databasdesignen som baseras på den konceptuella designen KaU - Datavetenskap - DAV B04 - MGö

Algoritm Finns en algoritm för att stegvis utföra mappningen denna finns mer detaljerat beskriven i kapitel 9.1 KaU - Datavetenskap - DAV B04 - MGö

Starka entiteter Steg 1 ~ varje stark entitetet blir en basrelation där primärnyckeln i relationen motsvarar nyckelattributet(en) i entiteten KaU - Datavetenskap - DAV B04 - MGö

Svaga entiteter Steg 2 ~ bildar sin primärnyckel genom att ta primärnyckeln från ”ägande” relationen (som främmandenyckel) och egen partiell nyckel tillsammans Reglerna för främmandenycklar i en relation mellan en svag och en stark entitet måste vara DELETE CASCADES UPDATE CASCADES Visar på beroendeförhållandet mellan entiteterna KaU - Datavetenskap - DAV B04 - MGö

1:1 förhållanden Steg 3 ~ välj en av entiterna och lägg in primärnyckeln i den ena som främmandenyckel i den andra eventuella attribut till relationen mellan dessa bör hamna på samma sida KaU - Datavetenskap - DAV B04 - MGö

1:N förhållanden Steg 4 ~ introducera primärnyckeln från ”en” relationen som främmandenyckel i relationen på ”många” sidan eventuella attribut till relationen (sambandet) mellan dessa två entiteter migreras till ”många” sidan KaU - Datavetenskap - DAV B04 - MGö

N:M förhållanden Steg 5 ~ varje många-till-många relation (samband) blir en basrelation varje sådan basrelation måste innehålla minst en främmandenyckel från varje deltagare i relationen primärnyckeln kan skapas genom kombinationen av främmandenycklarna eller genom att introducera ett nytt attribut KaU - Datavetenskap - DAV B04 - MGö

Attribut Steg 6 ~ Varje egenskap i för en entitet blir ett attribut i den relation den tillhör. Undantaget är om attributet för entiteten är ett ”mångvärdes” attribut, i så fall skapas en ny relation KaU - Datavetenskap - DAV B04 - MGö

Värdedomäner Skapas för alla attributens värdemängder KaU - Datavetenskap - DAV B04 - MGö

Praktisk databasdesign (kap 16)
DAV B04 - Databasteknik Praktisk databasdesign (kap 16) KaU - Datavetenskap - DAV B04 - MGö

Sammanhang Informationssystem (IS) Livscykel: Makro Databassystem (DBS) Livscykel: Mikro KaU - Datavetenskap - DAV B04 - MGö

Informationssystems livscykel (Makro livscykel)
Analys av möjliga krav (Feasibility analysis) Kravanalys och insamling av krav Design Implementation Testing/kontroll och acceptanstest Utplacering, drift och underhåll KaU - Datavetenskap - DAV B04 - MGö

Databassystems livscykel (Mikro livscykel)
Definition av systemet Databasdesign Databas implementation Inladdning av data eller konvertering Konvertering av applikationer Testing och kontroll Drift Övervakning och underhåll KaU - Datavetenskap - DAV B04 - MGö

Steg 2 – databasdesign Mål: klara av användarnas och applikationernas krav på informationsinnehåll naturlig och lättförstådd struktur på informationen klara av ställda krav på prestanda, ex svarstid Består av sex olika faser... KaU - Datavetenskap - DAV B04 - MGö

Faser i databasdesignen

Faser i databasdesignen
Insamling och analys av krav Konceptuell databasdesign Exempel ER-modellen Val av DBHS Mappning av datamodeller (logisk databasdesign) exempel, mappning från ER modellen till relationsmodellen Fysisk databasdesign lagringsstrukturer, index Implementering av databassystemet impl. av databas och applikationer, trimning (tuning) KaU - Datavetenskap - DAV B04 - MGö

Fas 1 – Insamling och analys av krav
Identifikation av applikationsområden och användargrupper Studier av existerande dokumentation Studier av nuvarande operativsystem och planerad användning av informationen Skriftliga svar på frågor från databasens potentiella användare KaU - Datavetenskap - DAV B04 - MGö

Fas 2 – Konceptuell databasdesign
2 parallella aktiviteter datamodellering transaktionsdesign Datamodellering centraliserad vs. vy integration Transaktionsdesign Specar funktionella krav på applikationerna Hämtnings-/uppdaterings/blandade transaktioner KaU - Datavetenskap - DAV B04 - MGö

Fas 3: Val av DBHS Exempel på faktorer som spelar in relationsdatabas, objektdatabas? utvecklingsverktyg? vad kostar det att: införskaffa all mjukvara? underhålla mjukvaran? införskaffa eventuell ny hårdvara? skapa databasen alt. konvertera från gammal? skaffa eventuell ny personal? träna personalen så att de kan använda DBHS? ha databassystemet i drift? KaU - Datavetenskap - DAV B04 - MGö

Fas 4 – Mappning mellan datamodeller
Kan ske i två steg system-o-beroende mappning ER-modell -> relationsmodellen systemberoende mappning DBHS har olika kännetecken och restriktioner som man behöver anpassa sig till Resultatet blir DDL uttryck i det språk som utvald DBHS hanterar KaU - Datavetenskap - DAV B04 - MGö

Fas 5 – Fysisk databasdesign
Utifrån vad DBHS kan erbjuda väljs lämpliga lagringsstrukturer, åtkomstvägar, organisation av filer, indexering Kriterier som påverkar svarstid utrymme transaktionsgenomströmming (medelvärde transaktioner/minut) KaU - Datavetenskap - DAV B04 - MGö

Fas 6 – implementation och trimning
DDL och SDL uttrycken kompileras och används för att skapa databasens scheman och (tomma) databasfiler. Eventuellt sker laddning/konvertering av data görs av DBA + databasdesigner Transaktioner implementeras genom att utgå från de konceptuella beskrivningarna av transaktionerna görs av applikationsprogrammerare KaU - Datavetenskap - DAV B04 - MGö

Fysisk databasdesign i relationsdatabaser
Brukar börja med att man tar fram de viktigaste faktorerna och den information man har om dem och analyserar dessa... Frågor, transaktioner, applikationer KaU - Datavetenskap - DAV B04 - MGö

Fysisk databasdesign i relationsdatabaser
Analys av frågor och transaktioner frekvens på anrop av frågor och transaktioner tidskrav på frågor och transaktioner frekvens på uppdateringsoperationer indexering (accessvägar) KaU - Datavetenskap - DAV B04 - MGö

Databastrimning i relationsdatabaser
Görs för att applikationer ska köra snabbare, få ned svarstider, förbättra genomströmning av transaktioner Fixas genom att trimma index databasdesignen frågor KaU - Datavetenskap - DAV B04 - MGö

Normalisering och funktionella beroenden (kap 14)
DAV B04 - Databasteknik Normalisering och funktionella beroenden (kap 14) KaU - Datavetenskap - DAV B04 - MGö

Riktlinjer när man vill skapa en databas
Designa så att det är lätt att förstå innebörden. Kombinera inte attribut från olika entitetstyper i samma tabell Designa så att inte problem uppstår vid insättning, borttagning eller modifiering Undvik värden i basrelationer som ofta blir NULL. Skapa istället en ny relation KaU - Datavetenskap - DAV B04 - MGö

Normalisering Uppdelning i flera relationer Innebär att redundansen i databasen är minskad (eliminerad?) Ingen information försvinner vid normaliseringen Inga falska samband skapas om man gör NATURAL JOIN på tabellerna KaU - Datavetenskap - DAV B04 - MGö

Funktionellt beroende (FD)
Functional Dependency Är en många-till-en relation från en mängd attribut till en annan i en given relation KaU - Datavetenskap - DAV B04 - MGö

Definition av FD Givet en relation R, så är attributet Y i R funktionellt beroende av attributet X i R omm varje X-värde i R är associerat med precis ett Y-värde i R (vid varje tillfälle). Attributen X och Y kan vara sammansatta R.X  R.Y KaU - Datavetenskap - DAV B04 - MGö

Exempel på funktionellt beroende
Relationen EMP_PROJ (i Fig. 14.3b, sida 470) har följande FD: SSN  ENAME PNUMBER  {PNAME, PLOCATION} {SSN, PNUMBER}  HOURS KaU - Datavetenskap - DAV B04 - MGö

Exempel på funktionellt beroende
Andra raden skulle också kunna delas upp i Även den triviala relationen finns PNUMBER  PNAME PNUMBER  PLOCATION PNUMBER -> PNUMBER osv. KaU - Datavetenskap - DAV B04 - MGö

Determinant Vänstra sidan av FD Determinanten kan vara primärnyckel och därmed också kandidatnyckel men måste inte vara det (BCNF – 3NF) KaU - Datavetenskap - DAV B04 - MGö

Dependent Den högra sidan av ett FD Alla attribut i en relation är funktionellt beroende av primärnyckeln KaU - Datavetenskap - DAV B04 - MGö

Definition av fullständigt funktionellt beroende
Attributet Y i relationen R är fullständigt funktionellt beroende av attributet X i R om det är funktionellt beroende av X och det inte finns någon äkta delmängd Z av X sådan att Y är funktionellt beroende av Z KaU - Datavetenskap - DAV B04 - MGö

Exempel på fullständigt funktionellt beroende
Relationen EMP_PROJ (i fig. 14.3b, sida 470) Här är {SSN, PNUMBER} primärnyckel (PK), vilket gör att alla attribut kan bestämmas när man vet PK:s värde. Attributen ENAME, PNAME och PLOCATION är alltså funktionellt beroende av PK men inte fullständigt funktionellt beroende eftersom följande gäller: SSN  ENAME PNUMBER  PNAME PNUMBER  PLOCATION KaU - Datavetenskap - DAV B04 - MGö

1:a normalformen (1NF) En relation är i första normalformen (1NF) omm de underliggande enkla domänerna innehåller endast skalära värden figur 14.8 och 14.9 KaU - Datavetenskap - DAV B04 - MGö

2:a normalformen (2NF) En relation är i andra normalformen (2NF) omm relationen är i 1NF och varje attribut som inte ingår i primärnyckeln är fullständigt funktionellt beroende av den figur (a) KaU - Datavetenskap - DAV B04 - MGö

3:e normalformen (3NF) En relation är i tredje normalformen (3NF) omm relationen är i 2NF och varje attribut som inte ingår i primärnyckeln är icke-transitivt beroende av primärnyckeln figur (b) KaU - Datavetenskap - DAV B04 - MGö

Boyce-Codd normalform (BCNF)
En relation är i Boyce-Codd normalform (BCNF) omm varje determinant är en kandidatnyckel (dvs. skulle kunna vara primärnyckel) figur 14.13 KaU - Datavetenskap - DAV B04 - MGö

Transitivt beroende I EMP_DEPT (i fig b) är SSN primärnyckel och det innebär att alla attribut inklusive DNAME och DMGRSSN är funktionellt beroende (FD) av SSN Det finns ytterligare beroenden i tabellen: Om man vet DNUMBER vet man också DNAME och DMGRSSN KaU - Datavetenskap - DAV B04 - MGö

Transitivt beroende Vi har ett transitivt beroende från SSN via DNUMBER till DNAME och DMGRSSN Transitiva beroenden elimineras genom att splittra tabellen (PROJECT). fig SSN  DNUMBER  {DNAME, DMGRSSN} KaU - Datavetenskap - DAV B04 - MGö

Vandra mellan normalformerna
Allmänt gäller att varje steg till högre normalform görs med PROJECT (splittring av tabell) och tabellen kan återskapas via NATURAL JOIN. Inga informationsförluster uppstår vid dessa operationer ex. finns i figur 14.2 och 14.4 KaU - Datavetenskap - DAV B04 - MGö

Varning! Vid olämplig design kan falska tupler uppstå vid NATURAL JOIN ex. figur 14.3, 14.5 och 14.6 KaU - Datavetenskap - DAV B04 - MGö

DAV B04 - Databasteknik Indexering (kap 6) KaU - Datavetenskap - DAV B04 - MGö

Lagring av databaser på sekundärminne
Att läsa/skriva på sekundärminne (hårddisk) är en långsam process jämfört med operationer i primärminnet Antalet diskaccesser (I/O) bör därför minimeras KaU - Datavetenskap - DAV B04 - MGö

Skrivning och läsning från sekundärminne
Skrivning och läsning sker i form av sidor (= page/block) med standardstorlek, t ex 1024 bytes Databasposterna är ofta mindre än sidorna, t ex 100 bytes, vilket gör att man läser/skriver flera poster (i detta fall 10) på samma gång Önskvärt är att relaterade poster lagras nära varandra för att minska antalet accesser KaU - Datavetenskap - DAV B04 - MGö

Hämta en post från databasen
DBHS bestämmer vilken lagrad post som behöver hämtas och ber filhanteraren att hämta posten Filhanteraren bestämmer vilken sida (block) som posten finns på och ber diskhanteraren att hämta den sidan Diskhanteraren bestämmer fysisk adress och ber om data från denna adress Data läses av diskhanteraren Den lagrade sidan returneras till filhanteraren Den lagrade posten returneras till DBHS KaU - Datavetenskap - DAV B04 - MGö

Exempel på lagringsstrukturer
Sekventiell lagring, osorterad/sorterad Indexering Hashing B-träd, B+-träd KaU - Datavetenskap - DAV B04 - MGö

Sekventiell lagring Osorterat plus: insättning av nya poster enkelt, sist eller första lediga minus: leta upp en post är besvärligt, sekventiell sökning Sorterat plus: binärsökning ger mycket snabbare access minus: insättning av nya poster medför att poster måste flyttas KaU - Datavetenskap - DAV B04 - MGö

Hashing Hashing innebär att adressen till en post bestämmes med hjälp av en hash-funktion vars indata är något av fälten i posten plus: direktaccess plus: minskat adressintervall minus: kan ge kollisioner som måste specialbehandlas KaU - Datavetenskap - DAV B04 - MGö

Indexering Indexering innebär att man bestämmer en viss ordningsföljd på posterna i datafilen. Index kan knytas till vilket fält som helst eller en kombination av fält Primary indexes Clustering indexes Secondary indexes Multilevel indexes Dynamic multilevel indexes, B-trees, B+-trees KaU - Datavetenskap - DAV B04 - MGö

Primary indexes Index knutet till primärnyckel dense index (= index till varje post) nondense (= ej index till varje post). Indexfil och datafil fig. 6.1 och exampel 1, sida 159 KaU - Datavetenskap - DAV B04 - MGö

Clustering indexes Index knutet till ett icke-nyckelfält som har dubbletter En pekare från indexfilen för varje distinkt värde (första blocket) på clustering-fältet fig. 6.2 och 6.3 KaU - Datavetenskap - DAV B04 - MGö

Secondary indexes Indexfil med två värden, indexfält och pekare till post/block En datafil kan ha många sekundärindex, ett för varje attribut Fig. 6.4 och exempel 2, sida 162. Index till osorterad fil men på ett fält med unika värden Fig. 6.5 visar indexfil till fält med ej unika värden KaU - Datavetenskap - DAV B04 - MGö

Multilevel indexes Index med flera nivåer fig. 6.6 och exempel 3, sida 167 Mycket snabb access men i likhet med alla ovanstående varianter är det problem med insättning av nya poster och borttagning av befintliga poster KaU - Datavetenskap - DAV B04 - MGö

Dynamic Multilevel Indexes using B-trees and B+-trees
B-träd som finns i olika varianter möjliggör att dynamiskt lägga till och ta bort poster utan att ”slösa med minnesutrymme” Träden är balanserade, dvs. alla löv ligger på samma nivå Nyckelvärdena är ”upphängda” i sorteringsordning i trädet KaU - Datavetenskap - DAV B04 - MGö

Skillnaden mellan B-träd och B+-träd
I ett B-träd kan datapekare finnas i alla inre noder och i löven medan B+-träd endast har datapekare i löven Dessutom finns pekare mellan löven i B+-träd vilket möjliggör sekventiell sökning KaU - Datavetenskap - DAV B04 - MGö

B-träd av ordningen p Varje inre nod i trädet (fig. 6.10a) är på formen <P1, <K1, Pr1>, P2, , <K2, Pr2>, …, , <Kq-1, Prq-1>, Pq> där q <= p Varje Pi är en trädpekare och varje Pri är en datapekare till den post (eller block som innehåller) vars nyckelvärde är Ki KaU - Datavetenskap - DAV B04 - MGö

B-träd av ordningen p Inom varje nod gäller K1 < K2 < … < Kq-1 För alla sökvärden X i det subträd som utpekas av Pi gäller Ki-1 < X < Ki, för 1 < i < q X < Ki, för i = 1 Ki-1 < X för i = q KaU - Datavetenskap - DAV B04 - MGö

B-träd av ordningen p Varje nod har högst p trädpekare Varje nod, förutom roten och löven, har åtminstone [(p/2)] trädpekare. Roten har minst 2 trädpekare såvida den inte är ensam nod i trädet KaU - Datavetenskap - DAV B04 - MGö

B-träd av ordningen p En nod med q trädpekare, q <= p, har q-1 söknyckelvärden och därmed också q-1 datapekare Alla löv ligger på samma nivå. Löven har samma struktur som inre noder men deras trädpekare är NULL KaU - Datavetenskap - DAV B04 - MGö

B+-träd av ordningen p Inre noder definieras enligt varje inre nod i trädet är på formen <P1, K1, P2, K2, …, Pq-1, Kq-1 , Pq> där q <= p varje Pi är en trädpekare Inom varje nod gäller K1 < K2 < … < Kq-1 KaU - Datavetenskap - DAV B04 - MGö

B+-träd av ordningen p För alla sökvärden X i det subträd som utpekas av Pi gäller Ki-1 < X <= Ki, för 1 < i < q X <= Ki, för i = 1 Ki-1 < X för i = q Varje inre nod har högst p trädpekare KaU - Datavetenskap - DAV B04 - MGö

B+-träd av ordningen p Varje inre nod, förutom roten, har åtminstone [(p/2)] trädpekare. Roten har minst 2 trädpekare såvida den inte är ensam nod i trädet En nod med q trädpekare, q <= p, har q-1 söknyckelvärden KaU - Datavetenskap - DAV B04 - MGö

B+-träd av ordningen p Lövnoder definieras enligt Varje löv har utseendet <<K1, Pr1>, <K2, Pr2>, …, , <Kq-1, Prq-1>, Pnext> där q <= p Pri är en datapekare och Pnext pekar på nästa lövnod i trädet KaU - Datavetenskap - DAV B04 - MGö

B+-träd av ordningen p Inom varje nod gäller K1 < K2 < … < Kq-1, q <= p Varje Pri är en datapekare som pekar på den post (eller block) vars söknyckelvärde är Ki Varje lövnod har åtminstone [(p/2)] trädpekare Alla lövnoder är på samma nivå KaU - Datavetenskap - DAV B04 - MGö

Transaktionshantering (kap 19)
DAV B04 - Databasteknik Transaktionshantering (kap 19) KaU - Datavetenskap - DAV B04 - MGö

Transaktion Logisk enhet i databasbearbetning Har en början och ett slut Kan innehålla flera delar, t ex read(x), modify(x) och write(x) KaU - Datavetenskap - DAV B04 - MGö

read(x) Kan ses som 3 steg hitta (beräkna) adress till den sida (block) där x finns kopiera sidan till buffert i PM kopiera x från buffert till programvariabel x KaU - Datavetenskap - DAV B04 - MGö

write(x) Kan ses som 4 steg hitta adress till den sida (block) där x finns kopiera sidan till buffert i PM kopiera programvariabel x till buffert lagra den uppdaterade sidan på sekundärminne KaU - Datavetenskap - DAV B04 - MGö

Concurrency Innebär samtidig/jämlöpande körning av flera transaktioner kan ställa till problem om de jobbar mot samma datamängd KaU - Datavetenskap - DAV B04 - MGö

Förlorade uppdateringar / Lost Update Problem
X är initialt lika med 80 Transaktion T1 vill flytta 5 (= N) bokningar från X till Y Transaktion T2 vill öka X med 4 (= M) bokningar X borde bli 79 men värdet blir 84 KaU - Datavetenskap - DAV B04 - MGö

Tillfälliga uppdateringar / Temporary Update Problem
X minskas av T1 T2 läser x och uppdaterar X Men sedan misslyckas T1 och minskningen görs ogjord Därmed har T2 använt ett felaktigt värde (dirty read) KaU - Datavetenskap - DAV B04 - MGö

Felaktiga summeringar / Incorrect Summary Problem
T3 summerar variablerna A, B, …,Y Samtidigt ska T1 föra över N enheter från X till Y T3 summerar förändrat X-värde men oförändrat Y-värde Summan är ej korrekt KaU - Datavetenskap - DAV B04 - MGö

Fel som kan inträffa under transaktioner
Datorfel - hårdvaru-, mjukvaru-, nätverksfel Transaktionsfel t ex division med noll Exceptions t ex data för transaktion saknas, underskott Concurrency control visar att transaktionen ej kan utföras på ett korrekt sätt eller deadlock inträffar Diskfel read/write, headcrash Katastrof brand, fel tape KaU - Datavetenskap - DAV B04 - MGö

Tillståndsdiagram 5 olika tillstånd ACTIVE PARTIALLY COMMITTED COMMITTED FAILED TERMINATED KaU - Datavetenskap - DAV B04 - MGö

Loggning Allt som händer lagras på en loggfil som skrivs till disk Varje transaktion har ett transaktions-ID, T KaU - Datavetenskap - DAV B04 - MGö

Operationer Hur mycket behöver lagras för varje typ? [start_transaction, T] [write_item, T, X, old_value, new_value] [read_item, T, X] [commit, T] [abort, T] KaU - Datavetenskap - DAV B04 - MGö

Varför logga systemet? Eftersom alla permanenta operationer loggats kan ett korrekt tillstånd erhållas med hjälp av loggen om man vet läget vid en tidigare tidpunkt (check-point) Vi kan göra undo på de transaktioner som inte fullföljdes genom att backa i loggen Vi kan göra redo på transaktioner som inte gjorts commit på genom att gå framåt i loggen KaU - Datavetenskap - DAV B04 - MGö

Önskvärda egenskaper hos transaktioner
ACID-egenskaper: Atomicity en transaktion skall utföras helt eller inte alls Consistency preservation transaktionen gör att databaser växlar mellan konsistenta tillstånd Isolation transaktionen skall inte påverkas av andra transaktioner Durability or permanency ändringar är permanenta KaU - Datavetenskap - DAV B04 - MGö

Transaktionsscheman Med schema (schedule eller history) avses en beskrivning av ordningsföljden mellan de operationer (read/write) som görs för att antal transaktioner som använder gemensamma data KaU - Datavetenskap - DAV B04 - MGö

Seriella och icke-seriella scheman
Seriellt schema (serial) en transaktion i taget aktiv och först när den avslutats (commit/abort) kan nästa börja Icke-seriellt (nonserial) dvs. inte en transaktion i taget Automatiskt seriellt om transaktionerna är oberoende av varandra KaU - Datavetenskap - DAV B04 - MGö

Hur kan man avgöra om ett schema är seriellt eller inte?
För varje transaktion Ti som ingår i schemat S Skapa en nod som heter Ti i en precedensgraf För varje fall i S där Tj utför en read_item(X) efter att Ti utfört en write_item(X) skapa en kant (Ti  Tj ) i precedensgrafen KaU - Datavetenskap - DAV B04 - MGö

För varje fall i S, där Tj utför en write_item(X) efter att Ti utfört en read_item(X) skapa en kant (Ti  Tj ) i precedensgrafen utför en write_item(X) efter att Ti utfört en write_item(X) skapa en kant (Ti  Tj) i precedensgrafen KaU - Datavetenskap - DAV B04 - MGö

Schemat S är serialliserbart omm precedensgrafen saknar cykler KaU - Datavetenskap - DAV B04 - MGö

Concurrency Control (kap 20)
DAV B04 - Databasteknik Concurrency Control (kap 20) KaU - Datavetenskap - DAV B04 - MGö

Tekniker för concurrency control
Olika slags lås (locks) Tidsstämpling (timestamps) KaU - Datavetenskap - DAV B04 - MGö

Binära lås 2 tillstånd, låst (locked) och olåst (unlocked) Ett lås till varje databasvariabel (post, item) X Växlar tillstånd med lock_item(X) och unlock_item(X) Viktigt att det är atomära (odelbara) operationer Om låset redan är låst läggs man i väntekö KaU - Datavetenskap - DAV B04 - MGö

Regler för lås En transaktion T måste utföra operationen lock_item(X) innan någon read_item(X) eller write_item(X) utförs i T En transaktion T måste utföra operationen unlock_item(X) efter att alla read_item(X) eller write_item(X) utförts i T KaU - Datavetenskap - DAV B04 - MGö

Regler för lås En transaktion T får inte utföra operationen lock_item(X) om den redan har ett lås på X En transaktion T får inte utföra operationen unlock_item(X) om den inte har ett lås på X KaU - Datavetenskap - DAV B04 - MGö

Regler för lås Reglerna garanterar att högst en transaktion i taget kan låsa en variabel! I databashanteraren finns en tabell där man för varje lås anger < data item, LOCK, transaktion som håller låset > KaU - Datavetenskap - DAV B04 - MGö

Delade/exklusiva lås Shared/Exclusive (or Read/Write) Locks Läsning av samma datapost kan tillåtas för flera transaktioner, låset kan delas, en räknare vet hur många transaktioner som låst (läser) samma post 3 tillstånd, read-locked, write-locked och unlocked KaU - Datavetenskap - DAV B04 - MGö

Regler för delade/exklusiva lås
En transaktion T måste utföra operationen read_lock(X) eller write_lock(X) innan någon read_item(X) utförs i T En transaktion T måste utföra operationen write_lock(X) innan någon write_item(X) utförs i T En transaktion T måste utföra operationen unlock(X) efter att alla read_item(X) och write_item(X) är utförda KaU - Datavetenskap - DAV B04 - MGö

Regler för delade/exklusiva lås
En transaktion T får inte utföra operationen read_lock(X) om den redan har ett lås på X En transaktion T får inte utföra operationen write_lock(X) om den redan har ett lås på X En transaktion T får inte utföra operationen unlock(X) om den inte har ett lås på X KaU - Datavetenskap - DAV B04 - MGö

Two-phase locking protocol
Alla låsningar (read_lock och write_lock) föregår första unlock i transaktionen Garanterar serialiserbarhet Dock kan deadlock inträffa KaU - Datavetenskap - DAV B04 - MGö

Deadlock Prevention Protocols
Varje transaktion förses med tidstämpel TS(T) Antag att Ti försöker låsa X som redan är låst av Tj Nu finns två varianter, i båda dessa varianter undviks deadlock wait-die wound-wait KaU - Datavetenskap - DAV B04 - MGö

wait-die Om TS(Ti) < TS(Tj), (dvs. Ti är äldre än Tj) så får Ti vänta annars (dvs. Ti är yngre än Tj) avbryts Ti (abort) och återstartas senare med samma tidstämpel KaU - Datavetenskap - DAV B04 - MGö

wound-wait Om TS(Ti) < TS(Tj), (dvs. Ti är äldre än Tj) så avbryt Tj (Ti wounds Tj ) och återstarta senare med samma tidstämpel annars (dvs. Ti är yngre än Tj) låt Ti vänta KaU - Datavetenskap - DAV B04 - MGö

Utan tidstämpel No waiting Om transactionen inte kan få ett lås avbryts den omedelbart och återstartas efter viss fördröjning utan att kontrollera om deadlock kommer att uppstå Cautious waiting Antag att Ti försöker låsa X men att X redan är låst av Tj Om Tj inte är blockerad (inte väntar på någon annan låst variabel) så blockeras Ti och får vänta annars avbryts Ti KaU - Datavetenskap - DAV B04 - MGö

Deadlock Detection and Timeouts
Upptäck deadlock genom att konstruera wait-for graph Deadlock omm det finns cykler i grafen Lösningar victim selection timeouts KaU - Datavetenskap - DAV B04 - MGö

Victim selection ”Någon måste offras” Undvik transaktionen som gått länge och gjort många uppdateringar KaU - Datavetenskap - DAV B04 - MGö

Timeouts Avbryt transaktionen om den väntat för länge KaU - Datavetenskap - DAV B04 - MGö

Starvation En transaktion får vänta orimligt länge på grund av låg prioritet eller annat Lösningar FCFS : first-come-first-serve i väntekö Prioritet : ge högre prioritet åt den som väntat länge KaU - Datavetenskap - DAV B04 - MGö

DAV B04 - Databasteknik MySQL (-) KaU - Datavetenskap - DAV B04 - MGö

Vad behöver du? Ett SSH-program som ex.Tera Term Pro (Programs-> Misc->Tera Term-> Tera Term Pro (SSH) ) Ett program för att kopiera över filer från ditt vanliga konto till kontot på enterprise, ex WinSCP (Programs-> Net-> WinSCP) Följande data enterprise.cse.kau.se användarkonto (ex. picard, data) lösenord KaU - Datavetenskap - DAV B04 - MGö

Logga in på enterprise Från SSH-programmet med hjälp av användarkonto lösenord KaU - Datavetenskap - DAV B04 - MGö

Logga in på databaskontot
Därifrån loggar du in på MySQL mysql –h <hostname> -u <user> -p (-h <hostname> kan du bortse från) Ex. mysql –u picard -p KaU - Datavetenskap - DAV B04 - MGö

Välj databas Tala om vilken databas du kommer att använda (lab3_XX) mysql> use lab3_XX; KaU - Datavetenskap - DAV B04 - MGö

Andra nyttiga kommandon
Visa alla tabeller i databasen mysql> show tables; Beskriv en specifik tabell mysql> describe <tabellens namn>; KaU - Datavetenskap - DAV B04 - MGö

MySQL vs. Access Inga sub-selects (går inte att nästla) Information om främmandenycklar sparas inte (kommer i senare version...), så referensintegritet kontrolleras inte (upp till er) Inga vyer (senare version...) KaU - Datavetenskap - DAV B04 - MGö

MySQL vs. Access I MySQL är det möjligt att göra COUNT(DISTINCT <kolumn-namn>) Wildcards Access * (substräng), ? (ett tecken) MySQL % (substräng), _ (ett tecken) Kommentarer skrivs efter ett #-tecken eller inom /* */ enligt C-stil KaU - Datavetenskap - DAV B04 - MGö

Exempel: skapa tabeller
CREATE TABLE suppliers (s_num varchar(5) NOT NULL PRIMARY KEY name varchar(50) NOT NULL ); CREATE TABLE shipments (s_num varchar(5) NOT NULL, p_nu, varchar(5) NOT NULL, PRIMARY KEY (s_num, p_num), FOREIGN KEY (s_num) REFERENCES suppliers (s_num) FOREIGN KEY (s_num) REFERENCES parts (p_num) KaU - Datavetenskap - DAV B04 - MGö

Information om att skapa tabeller
Alla alternativ för CREATE TABLE finns på Ytterligare exempel finns på De viktigaste typerna TINYINT, SMALLINT, MEDIUMINT, INT, BIGINT, REAL, DOUBLE, FLOAT, DECIMAL(length,decimals), NUMERIC(length,decimals), CHAR(length), VARCHAR(length), DATE, TIME, TIMESTAMP, DATETIME, TINYTEXT, TEXT, MEDIUMTEXT, LONGTEXT, ENUM(value1,value2,value3,...) KaU - Datavetenskap - DAV B04 - MGö

Ta bort tabeller (Efter allt arbete man lagt ned för att skapa tabellen...;)) drop table <tabell-namn>; Tar bort både definitionen av tabellen och alla data så var försiktig!!! KaU - Datavetenskap - DAV B04 - MGö

Ändra i tabeller Ex. ALTER TABLE shipments ADD COLUMN qty INT NOT NULL AFTER p_num; DROP COLUMN qty; Alla alternativ finns på: KaU - Datavetenskap - DAV B04 - MGö

Importera data till tabell
Skapa en text-fil och se till att den har något slags avgränsare I Excel finns alternativet att spara som tab-delimited .txt-file, vilket är lämpligt eftersom det är default för MySQL vid importering av data Kopiera över filen till ert användarkonto (med ex. WinSCP) KaU - Datavetenskap - DAV B04 - MGö

Importera data till tabeller
Vid prompten är syntaxen sedan mysql> LOAD DATA LOCAL INFILE ”/home/<användarnamn>/<filnamn.txt>” INTO TABLE lab3_XX.<tabell-namn>; KaU - Datavetenskap - DAV B04 - MGö

Testa tabellerna All data i en tabell SELECT * FROM <tabellnamn>; SELECT fungerar till stort precis som förut (förutom att du inte kan nästla SELECT-satserna) KaU - Datavetenskap - DAV B04 - MGö

Ta bort data från tabeller
DELETE FROM <tabellnamn>; Tar bort ALL data i tabellen!!! DELETE FROM <tabellnamn> WHERE <villkor> Tar bort alla rader i tabellen där villkoret matchats KaU - Datavetenskap - DAV B04 - MGö

Logga ut Logga ut från MySQL quit Logga ut ifrån SSH-programmet exit KaU - Datavetenskap - DAV B04 - MGö

Mer information om MySQL
Officiell sajt Dokumentation/tutorial Tutorial MySQL/PHP KaU - Datavetenskap - DAV B04 - MGö

DAV B04 - Databasteknik PHP (-) KaU - Datavetenskap - DAV B04 - MGö

PHP Hypertext Preprocessor
Scriptspråk på serversidan Innebär att webbservern översätter php-scripten innan sidan skickas till webbläsaren, dvs. webbläsaren ser bara vanlig html-kod KaU - Datavetenskap - DAV B04 - MGö

PHP Grunderna Exempel php-script på webbservern //test.php <HTML> <HEAD> <TITLE> Simple PHP Example</TITLE> </HEAD> <BODY> <P> <?php print(“<B>Hello World!</B>"); ?> </P> </BODY> </HTML> KaU - Datavetenskap - DAV B04 - MGö

PHP Grunderna Samma sida i webbläsaren //test.php <HTML> <HEAD> <TITLE> Simple PHP Example</TITLE> </HEAD> <BODY> <P> <B>Hello World!</B> </P> </BODY> </HTML> KaU - Datavetenskap - DAV B04 - MGö

PHP Grunderna Resultat i webbläsaren KaU - Datavetenskap - DAV B04 - MGö

Positiva aspekter Oberoende av webbläsarens typ/version etc. Tillgång till resurser på webbservern Ex. MySQL-databaser Saktar inte ned webbläsaren som exempelvis JavaScript kan göra (prestandakraven ligger istället på servern) KaU - Datavetenskap - DAV B04 - MGö

PHP Syntax Ett php-script börjar alltid med <?php (eller <?) Och slutar alltid med ?> Kallas för scriptets avgränsare (delimiters) KaU - Datavetenskap - DAV B04 - MGö

Skalära (primitiva) typer
boolean, bool: {true, false} integer, int: {…-1, 0, 1, 2…} float, double, real: {..1.1, 1.2..} string: tecken inom ’ ’ eller ” ” KaU - Datavetenskap - DAV B04 - MGö

Komplexa (sammansatta) typer
arrayer (lista, haschtabell, samling…) där nyckeln är antingen är av typen integer eller string objekt (ej i denna kurs om ni inte absolut känner för det…) KaU - Datavetenskap - DAV B04 - MGö

Variabler Börjar alltid med ett dollartecken ( $) $name, $i, $test Är typlösa 8! $name = ”Joppe”; $i = 1; $test = 4.7; $test = ”Kalle”; KaU - Datavetenskap - DAV B04 - MGö

Operatorer =, ==, !=, !, +, -, *, /, ++, --, &&, || etc.... $i = 1; $i = $i + 2; //$i = 3 $i++; //$i = 4 Dvs. precis som i C/C++ KaU - Datavetenskap - DAV B04 - MGö

”Utökningar” som kan vara bra att känna till
AND, OR Punktoperatorn (.) som används för att slå ihop strängar $fname = ”Joppe”; $sname = ”Karlsson”; $name = $fname . ” ” . $sname; //Joppe Karlsson $name = ”$fname $sname”; //samma resultat $name = ’$fname $sname’; //samma resultat KaU - Datavetenskap - DAV B04 - MGö

Utskrift print() eller echo() print(”Hello World”); echo(”Hello World”); print($fname . ” ” . $sname); Egentligen inte funktioner, utan språkkonstruktioner... print ”Hello World”; echo $fname . ” ” . $sname; KaU - Datavetenskap - DAV B04 - MGö

Reserverade ord KaU - Datavetenskap - DAV B04 - MGö

Selektioner if-else if ($var1 == true) { //... } else if($var2 == true) { //... else KaU - Datavetenskap - DAV B04 - MGö

Iterationer while for while ($expr) { //... } for($i = 0; i < $size; $i++) { //... } KaU - Datavetenskap - DAV B04 - MGö

Iterationer do-while foreach $i = 0; do { //... }while ($i>0); foreach($array_expr as $value) //... foreach($array_expr as $key => $value) //... KaU - Datavetenskap - DAV B04 - MGö

Funktioner function add ($arg, $arg_2) { echo "Example function.\n"; $retval = $arg1 + $arg2; return $retval; } … $sum = add(1, 2); KaU - Datavetenskap - DAV B04 - MGö

Koppla upp mot MySQL mysql_connect(<address>, <username>, <password>); Exempel $dbcnx ”picard", ”password"); if (!$dbcnx){ print("<P>Unable to connect to the " "database server at this time.</P>" ); exit(); } KaU - Datavetenskap - DAV B04 - MGö

Välj databas bool mysql_select_db (string databas [, uppkoppling]) Exempel if ) { print( "<P>Unable to locate the " "database at this time.</P>" ); exit(); } KaU - Datavetenskap - DAV B04 - MGö

Kör en SQL-fråga mysql_query(string sql_question [, uppkoppling] ) Vad funktionen returnerar varierar: vid CREATE/INSERT/UPDATE/DROP etc. returneras true/false vid SELECT returneras en resultatmängd KaU - Datavetenskap - DAV B04 - MGö

Kör en SQL-fråga Exempel $result = mysql_query(”SELECT * FROM Supplier ”); if ( !$result ) { print("<P>Error performing query: " . mysql_error() . "</P>"); exit(); } KaU - Datavetenskap - DAV B04 - MGö

Hantera resultatmängden
Hämta resultatet rad efter rad… while ( $row = mysql_fetch_array($result) ) { print( ”<P>” . $row[”snum”] . ” ” . $row[”sname”] . ”</P>”); } KaU - Datavetenskap - DAV B04 - MGö

Formulär <FORM ACTION=”vad som skall hända" METHOD = POST> … </FORM> där ”vad som skall hända” exempelvis kan vara att ladda in en ny sida, eller maila till någon person... KaU - Datavetenskap - DAV B04 - MGö

Formulär Exempel <FORM ACTION="<?php echo($PHP_SELF); ?>" METHOD = POST> … </FORM> KaU - Datavetenskap - DAV B04 - MGö

Textboxen <INPUT TYPE="text" NAME="name" SIZE="30"> KaU - Datavetenskap - DAV B04 - MGö

Pop-up boxen <SELECT NAME=”color" SIZE="1"> <OPTION SELECTED>Blue <OPTION>Red </SELECT> KaU - Datavetenskap - DAV B04 - MGö

Sänd eller återställ informationen i formuläret
<INPUT TYPE="submit” NAME=”submit”> <INPUT TYPE="reset” NAME=”reset”> KaU - Datavetenskap - DAV B04 - MGö

Viktigt att veta om PHP och formulär
Namnet på textboxen, pop-up boxen, knapparna osv. blir automatiskt variabler i PHP! <?php if($submit){ //Ok, arbeta mot databasen } ?> <FORM ACTION="<?php echo($PHP_SELF); ?>" METHOD=POST> <INPUT TYPE="submit” NAME=”submit”> </FORM> KaU - Datavetenskap - DAV B04 - MGö

Exempel på PHP och formulär

PHP och reguljära uttryck
Reguljära uttryck kan användas för att kontrollera att det användaren matar in är i rätt form för en given kolumn exempelvis att ett Bach-nummer måste vara på formen BWV XXX(X) där X är en siffra mellan 0-9 KaU - Datavetenskap - DAV B04 - MGö

Exempel på reguljära uttryck
Sök efter strängen ”Now” i meningen ”Now is the time!” if(ereg(”Now”, ”Now is the time!”) == true) print(”Found”); if(ereg(”^Now”, ”Now is the time!”) == true) if(ereg(”Now$”, ”Now is the time!”) == true) print(”Found”); //Hittas ej KaU - Datavetenskap - DAV B04 - MGö

Bara bokstäver/siffror i ex. en variabel * står för 0 eller flera gånger + står för 1 eller flera gånger {n,m} står för att det finns mellan minst n till som mest m gånger if(ereg(”[A-Za-z0-9]*”, $test) == true) print(”Correct”); else print(”Error”); KaU - Datavetenskap - DAV B04 - MGö

Sant eller falskt? ereg(”^Now [a-z ]+$”, ”Now is the time!”) ereg(”^Now [a-z ]+!$”, ”Now is the time!”) Vill man sedan inte bry sig om stora eller små bokstäver så använder man istället eregi() KaU - Datavetenskap - DAV B04 - MGö

Mer information Manualer/tutorials/sökning eller Tutorial om PHP och MySQL Tutorial om html, formulär osv.. Information om laborationen KaU - Datavetenskap - DAV B04 - MGö

DAV B04 - Databasteknik Återhämtning (kap 21) KaU - Datavetenskap - DAV B04 - MGö

Återhämtning (Recovery)
Innebär att man: återhämtar/återställer databasen till dess senast konsistenta tillstånd efter det att en transaktion misslyckats Disk-krasch, datorfel, transaktionsfel, katastrof osv. Använder vanligtvis systemloggar för att återställa databasen KaU - Datavetenskap - DAV B04 - MGö

Repetition transaktioner
En transaktion är en mängd operationer, utförda i sekvens, som tillsammans bildar en logisk enhet. BEGIN TRANSACTION ; INSERT ( { S#: 'S5', P#: 'P1', QTY:1000 } ) INTO SP ; IF any error occurred THEN GO TO UNDO ; UPDATE P WHERE P# = 'P1' TOTQTY := TOTQTY ; COMMIT TRANSACTION ; GO TO FINISH ; UNDO : ROLLBACK TRANSACTION ; FINISH : RETURN ; En transaktion förflyttar databasen från ett konsistent tillstånd till ett annat konsistent tillstånd, men garanterar inte konsistens under tiden transaktionen utförs. KaU - Datavetenskap - DAV B04 - MGö

Strategier vid återhämtning
Vid allvarligare fel backup av databasen används för att säkerställa ett konsistent tillstånd hos databasen alla operationer sedan backupen togs tills det att feltillståndet inföll görs sedan om KaU - Datavetenskap - DAV B04 - MGö

Strategier vid återhämtning
Mindre allvarliga fel vrid tillbaka ändringar som orsakat inkonsistens genom att göra operationerna ogjorda det kan också vara nödvändigt att göra om vissa operationer för att återställa databasen jobbar efter avstämningar i systemets logg KaU - Datavetenskap - DAV B04 - MGö

Mindre allvarliga fel Två olika tekniker uppskjuten uppdatering (deferred update) omedelbar uppdatering (immediate update) KaU - Datavetenskap - DAV B04 - MGö

Caching Caching av disk-block data som skall uppdateras cachas i primärminnet datan uppdateras i primärminnet. datan skrivs tillbaka till disken. Speciellt cachningsminne för DB DBHS cache KaU - Datavetenskap - DAV B04 - MGö

Strategier för återskrivning
In-place updating Skriver över ursprungsvärdet Shadowing Skriver en uppdaterad buffer till ett annat diskutrymme, vilket innebär att flera versioner av datan existerar. KaU - Datavetenskap - DAV B04 - MGö

Loggningsinformation
Två typer av loggningsinformation Information som behövs för UNDO Nya värdet (AFIM) Information som behövs för REDO Gamla värdet (BFIM) KaU - Datavetenskap - DAV B04 - MGö

Write-Ahead loggning De loggblock som innehåller information om datan som skall uppdateras måste skrivas till disk innan själva datablocket skrivs till disken KaU - Datavetenskap - DAV B04 - MGö

Ansatser till återhämtning
Terminologi för när information kan skrivas från cachen till disken... no-steal cache-info som blivit uppdaterad av en transaktion kan inte skrivas till disken innan transaktionen kommit till sin commit-punkt. steal uppdaterad information i buffern (cache-minnet) kan skrivas innan transaktionen nått commit-punkten. KaU - Datavetenskap - DAV B04 - MGö

Ansatser till återhämtning
force approach all information som blivit uppdaterad av en transaktion skrivs omedelbart till disken så fort en transaktion nått sin commit-punkt. no-force approch uppdaterad information behöver inte skrivas till disk direkt efter att en transaktion nått sin commit-punkt. KaU - Datavetenskap - DAV B04 - MGö

Ytterligare loggningsinformation
Checkpoints sådan information skrivs till loggen när systemet uppdaterar databasen med alla DBHS [cache] buffrar som har blivit modifierade alla transaktioner som har sina commit-punkter i loggen innan en checkpoint behöver inte få sina WRITE-operationer omgjorda ifall det blir en krasch av något slag KaU - Datavetenskap - DAV B04 - MGö

Strategi för checkpoints
Frys temporärt exekveringen av alla transaktioner Gör en force-write av alla buffrar i primärminnet som har blivit uppdaterade (till disk) Skriv in en checkpoint till loggen och gör en force-write även på loggen (till disk) Påbörja exekvering av transaktionerna igen KaU - Datavetenskap - DAV B04 - MGö

Rollback Om en transaktion misslyckas kan det vara nödvändigt att återställa uppdaterade värden till de gamla värdena (BFIM). Kallas för att man gör en rollback. KaU - Datavetenskap - DAV B04 - MGö

Cascading rollback Vid beroendeförhållanden Om en transaktion T misslyckas och det måste utföras en rollback på T så måste det även utföras en rollback på alla transaktioner som läst värden som uppdaterats av T... KaU - Datavetenskap - DAV B04 - MGö

Illustration av cascading rollback
Fig. 21.1 KaU - Datavetenskap - DAV B04 - MGö

Illustration av cascading rollback

Uppskjuten uppdatering
Skjuter upp eventuella uppdateringar till databasen tills dess att transaktionen avslutat sin exekvering och nått sin commit-punkt KaU - Datavetenskap - DAV B04 - MGö

Strategi för uppskjuten uppdatering
En transaktion kan inte ändra databasens innehåll förrän den nått sin commit-punkt En transaktion når inte sin commit-punkt förrän alla dess uppdateringsoperationer har blivit inskrivna i loggen och loggen har blivit force-written till disken NO-UNDO/REDO recovery algorithm KaU - Datavetenskap - DAV B04 - MGö

Uppskjuten uppdatering i enanvändarmiljö
Fig. 21.2 KaU - Datavetenskap - DAV B04 - MGö

Uppskjuten uppdatering i ett fleranvändarsystem
För att hantera concurrency och återhämtning en transaktion skriver ingen information till databasen förrän efter dess commit-punkt (lyckad exekvering) => en transaktion behöver aldrig göra roll back pga. en misslyckad transaktion en transaktion läser aldrig ett värde som blivit uppdaterat av en transaktion som inte nått sin commit-punkt, eftersom värdet förblir låst tills dess att commit-punkten nåtts (ingen cascading rollback) KaU - Datavetenskap - DAV B04 - MGö

Återhämtning Uppskjuten uppdatering i ett fleranvändarsystem (fig. 21.3) KaU - Datavetenskap - DAV B04 - MGö

Omedelbar uppdatering
När en transaktion gör en uppdateringsoperation uppdateras databasen omedelbart. uppdateringsoperationen måste dock skrivas till loggen innan uppdateringen så att återhämtning kan ske UNDO/NO-REDO Algorithm alla uppdateringar skrivs till DB innan transaktionen gjort commit UNDO/REDO Algorithm transaktioner får göra commit innan alla dess uppdateringar skrivits till DB KaU - Datavetenskap - DAV B04 - MGö

Shadowing pages NO-UNDO/NO-REDO recovery algorithm alla uppdateringar görs hela tiden i en ny katalog och den gamla versionen sparas i en s.k. skuggkatalog vid fel byter man helt enkelt tillbaka till den gamla katalogen KaU - Datavetenskap - DAV B04 - MGö

Illustrering av Shadowing pages

Återhämtning i ett system med flera databaser
Two-phase commit används om en given transaktion involverar flera "resurshanterare" t ex i ett distribuerat databassystem Om en transaktion uppdaterar två olika databaser, får det inte hända att uppdateringar görs i den ena databasen men inte i den andra KaU - Datavetenskap - DAV B04 - MGö

En komponent i systemet, koordinatorn, har som uppgift att garantera att båda databaserna utför samma operation (båda gör COMMIT eller båda gör ROLLBACK), även om systemet kraschar mitt i processen. Om koordinatorn bestämmer att operationen skall vara COMMIT gås två faser igenom... KaU - Datavetenskap - DAV B04 - MGö

Strategi för återhämtning i ett system med flera databaser
Fas 1 koordinatorn instruerar alla resurshanterare att göra sig klara för att avsluta transaktionen det betyder att alla deltagare i processen måste skriva all information de har om transaktionen till loggen om detta gick bra, svarar resurshanteraren "OK", annars "not OK" till koordinatorn. KaU - Datavetenskap - DAV B04 - MGö

Strategi för återhämtning i ett system med flera databaser
Fas 2 när koordinatorn har fått svar från alla deltagare, skriver den sitt beslut till sin egen logg om alla svar var "OK" blir beslutet "commit”, annars blir det "rollback” koordinatorn informerar sedan alla deltagare om sitt beslut, vilket de alla måste rätta sig efter KaU - Datavetenskap - DAV B04 - MGö

Om systemet kraschar mitt i processen, letar omstartproceduren efter koordinatorns beslut i loggen. Om den hittar det, kan processen fortsätta där den slutade. Om inte, så antas beslutet ha varit "rollback". KaU - Datavetenskap - DAV B04 - MGö

DAV B04 - Databasteknik Säkerhet (kap 22) KaU - Datavetenskap - DAV B04 - MGö

Olika säkerhetsaspekter
Lagliga och etiska aspekter Policyfrågor Säkerhet på hårdvarunivå Säkerhet i operativsystemet Säkerhet i nätverket Säkerhet i databassystemet KaU - Datavetenskap - DAV B04 - MGö

Säkerhetsmål (allmänt)
Sekretess (Confidentiality) förhindrande av att information görs tillgänglig för obehöriga Integritet (Integrity) förhindrande av obehörig påverkan av information Tillgänglighet (Availability) information skall finnas tillgänglig för den behörige användaren KaU - Datavetenskap - DAV B04 - MGö

Säkerhetsmekanismer i databaser
Två typer av mekanismer används: discretionary control användare beviljas accessrättigheter till objekt (tabeller, kolumner, rader mm) i databasen på individuell basis mandatory control Användare och objekt delas in i olika säkerhetsklasser För att dessa mekanismer skall fungera krävs autentisering av användarna KaU - Datavetenskap - DAV B04 - MGö

Discretionary Control
Är den vanligaste mekanismen Bygger på att man beviljar (grant) eller drar undan (revoke) olika privilegier Privilegier på kontonivå specificeras av DBA Privilegier på relationsnivå kan specificeras av den som skapat relationen (och som själv äger alla rättigheter) KaU - Datavetenskap - DAV B04 - MGö

Privilegier på relationsnivå
SELECT för att kunna hämta data INSERT, UPDATE, DELETE för att kunna modifiera data REFERENCES för att kunna referera en relation t ex i en integritetsregel WITH GRANT OPTION för att en användare ska kunna ge privilegier vidare KaU - Datavetenskap - DAV B04 - MGö

SQL-syntax GRANT ALL [ PRIVILEGES ] | [ SELECT ] [ INSERT ] [ DELETE ] [ UPDATE [ (kolumnlista) ] ON tabellnamn TO namnlista | PUBLIC [ WITH GRANT OPTION ] KaU - Datavetenskap - DAV B04 - MGö

Exempel på säkerhetsregler med GRANT
GRANT ALL PRIVILEGES ON cust_table TO lewis, agganis WITH GRANT OPTION. GRANT SELECT, UPDATE (credit_limit) TO garcia. KaU - Datavetenskap - DAV B04 - MGö

Exempel på säkerhetsregler med REVOKE
Det går också att dra tillbaka rättigheter med REVOKE REVOKE DELETE, UPDATE ON cust_table FROM jones, brown. KaU - Datavetenskap - DAV B04 - MGö

exempel på en värdeoberoende säkerhetsregel
GRANT SELECT ( S#, SNAME, CITY ) ON S TO Jacques, Anne, Charley. KaU - Datavetenskap - DAV B04 - MGö

Exempel på en värdeberoende säkerhetsregel
GRANT SELECT, INSERT, UPDATE ( SNAME, STATUS ), DELETE ON S WHERE S.CITY = 'Paris’ TO Dan, Misha. Dessa användare kan se en horisontell delmängd av S KaU - Datavetenskap - DAV B04 - MGö

Exempel på osynliga villkor
GRANT SELECT ( S#, SNAME ) ON S WHERE S.STATUS > 50 TO Judy, Paul. Attributet STATUS används här som villkor även fast det inte är synligt för användarna. KaU - Datavetenskap - DAV B04 - MGö

Exempel på en kontextberoende säkerhetsregel
GRANT SELECT, UPDATE ( STATUS ) ON S WHERE DAY ( ) IN ( 'mon', 'tue', 'wed', 'thu', 'fri' ) AND TIME ( ) >= '9:00 AM' AND TIME ( ) <= '5:00 PM' TO Purchasing. KaU - Datavetenskap - DAV B04 - MGö

Säkerhetsregler på vyer
Anta att vi har definierat en vy SSQ enligt följande: CREATE VIEW SSQ AS SELECT S#, SUM(QTY) FROM SP GROUP BY S# KaU - Datavetenskap - DAV B04 - MGö

Säkerhetsregler på vyer
Då kan vi skriva följande säkerhetsregel: Fidel har bara rättigheter att se viss statistik från basrelationen SP, inte några detaljer Detta är ett exempel på hur man kan använda vyer för att gömma information GRANT SELECT ON SSQ TO Fidel. KaU - Datavetenskap - DAV B04 - MGö

Audit Trails En audit trail är en speciell logg där detaljer om alla operationer som har utförts registreras Information som en audit trail kan innehålla: hur operationen såg ut från vilken terminal operationen utfördes vilken användare som utförde operationen datum och tid för operationen berörda relationer, tupler och attribut de gamla värdena de nya värdena KaU - Datavetenskap - DAV B04 - MGö

Mandatory control Används i databaser som har höga krav på säkerhet Ett antal säkerhetsklasser definieras, tex top secret(TS), secret(S), confidential(C) och unclassified(UC) där TS >= S >= C >= UC Den vanligaste klassificeringsmodellen är den sk Bell-LaPadula-modellen KaU - Datavetenskap - DAV B04 - MGö

Bell-LaPadula-modellen
Varje subjekt (användare, konto, program) och objekt (relation, tuple, attribut, vy, operation) tilldelas en av säkerhetsklasserna TS, S, C eller UC klassificering av ett subjekt: class(S) klassificering av ett objekt: class(O) KaU - Datavetenskap - DAV B04 - MGö

Bell-LaPadula-modellen
Två regler: Ett subjekt S får bara läsrättigheter till ett objekt O om class(S) >= class(O) (simple security property) Ett subjekt S får bara skrivrättigheter till ett objekt O om class(S) <= class(O) (*-property eller star property) KaU - Datavetenskap - DAV B04 - MGö

Statistiska databaser
Användare får bara ställa frågor m h a count, sum, min, max osv. Problemet med sådana databaser är att det ofta går att få svar på en otillåten fråga genom att ställa ett antal tillåtna frågor…. KaU - Datavetenskap - DAV B04 - MGö

Relationen Stat KaU - Datavetenskap - DAV B04 - MGö

Föreläsningsmaterial

Liknande presentationer

En presentation över ämnet: "Föreläsningsmaterial"— Presentationens avskrift:

Liknande presentationer

Om projektet

Kontakta oss

Logga in

Logga in via sociala nätverk:

Föreläsningsmaterial

Liknande presentationer

En presentation över ämnet: "Föreläsningsmaterial"— Presentationens avskrift:

Liknande presentationer

Om projektet

Kontakta oss