Ett databashanteringssystem (DBHS) skiljer sig från andra programmeringssystem bl.a.

1 Kap. 1 INTRODUKTION Ett databashanteringssystem (DBHS) skiljer sig från andra programmeringssystem bl.a. 1. Möjligheten att hantera persistenta data 2. Möjligheten att accessera stora mängder av data bekvämt och effektivt. Punkt 1 säger bara att det finns en databas som existerar permanent. Innehållet av denna databas är de data ett DBHS accesserar och hanterar. Punkt 2 skiljer åt ett DBHS från ett filsystem, som också hanterar persistenta data, men i allmänhet inte ger snabb access till godtyckliga delar av data. Dessa två egenskaper är fundamentala. Andra som nästan alltid finns i kommersiella DBHS: a. Understöd för åtminstone en datamodell (matematisk abstraktion genom vilken användaren ser data). b. Understöd för vissa högnivåspråk som tillåter användaren att definiera strukturen hos data, accessera data, och manipulera data. c. Transaktionshantering, dvs. att kunna ge korrekt access till databasen åt många användare samtidigt. d. Accesskontroll, dvs. att kunna begränsa access till data av icke-auktoriserade användare. e. Resiliency (stryktålighet): icke förlora data vid systemfel. 1.1 Syften med databassystem Betrakta ett bankbolag som håller information om alla kunder och konton i permanenta filer vid banken. Dessutom har systemet ett antal applikationsprogram som tillåter anv. att manipulera filerna, t.ex. - ett program för att debitera eller kreditera ett konto - ett program för att lägga till ett konto - ett program för att bestämma balansen av ett konto - ett program för att generera månatliga rapporter Dessa applikationsprogram har skrivits av systemprogrammeraren Nya applikationsprogram läggs till systemet efter behov. Typiskt läggs nya permanenta filer och nya appl.program till systemet. Allt detta understöds av ett konventionellt operativsystem

2 NACKDELAR: - Dataredundans och inkonsistens - Svårighet att accessera data - Dataisolering - Samtidig access anomalier - Säkerhetsproblem - Integritetsproblem 1.2 En syn på data Ett viktigt mål för ett DBHS är att ge använandaren en abstrakt syn på data, dvs. systemet döljer vissa detaljer hur data lagras och upprätthålls. 1.2.1 Dataabstraktion För att systemet skall vara användbart måste det skaffa fram data effektivt. Detta har lett till skapandet av komplicerade datastrukturer för att representera data i databasen. Denna komplexitet döljes för användare via flera abstraktionsnivåer: Fysiska nivån. Den lägsta nivån beskriver hur data verkligen lagras. Komplicerade låg-nivå datastruktuer beskrivs härvid i detalj. Logiska nivån. Den nästa nivån beskriver vilka data lagras i databasen, och vilka relationskaper som finns mellan dessa data. Vy nivån. Den högsta abstraktionsnivån beskriver bara en del av hela databasen. Typiskt för att ge användare av databasen en bekväm syn på den del av databasen de är intresserade av.

3 Vy nivå vy 1 vy 2... vy n logisk nivå fysisk nivå Analogi med progr.språk: Vi kunde dekl. en post som: type customer = record customer-name : string; social-security : string; customer-street : string; customer-city : string; end; En bank kunde ha flera dylika post typer, såsom - account, med fälten account-number och balance - employee, med fälten empoyee-name och salary På den fysiska nivån kan en customer, account eller employee post beskrivas som ett block av konsekutiva lagringspositioner (t.ex. ord eller bytes). Kompilatorn döljer denna detaljnivå för programmerare. Likaså döljer databassystemet många lågnivådetaljer för databasprogrammerare. Databasadministratörer kan känna till vissa detaljer om den fysiska organisationen av data. På den logiska nivån beskrivs varje dylik post av en typ definition. På vy nivån definieras flera vyer av databasen och användare ser dessa vyer. 1.2.2 Instanser och Schemor Overall design: schema (<-> typ). Ändras mycket sällan. Information lagrad vid ett visst ögonblick: instans (svarar mot värde av en variabel (av en given typ) vid ett visst ögonblick).

4 Vid deklaration av post typen har vi ännu inte deklarerat några. I progr. var customer1 : customer; Ett fysiskt schema Ett begr. schema Flera subscheman 1.2.3 Data Oberoende I avsnitt 1.2 tre abstraktionsnivåer på vilka databasen kan betraktas Möjligheten att modifiera en schema def. på en nivå utan att påver-ka en schema def på nästa högre nivå kallas kallas data oberoende. Fysiskt data oberoende är möjligheten att modifiera det fysiska schemat (göres ibland för att förbättra effektivitet) utan att till. program behöver skrivas om. Logiskt data oberoende är möjligheten att modifiera det begr. schemat utan att till. program behöver skrivas om. Behövs när den logiska strukturen av databasen förändras (t.ex. tillägg av ett nytts slags konto i ett banksystem). (Svårare) Begr. d.o. svarar mot begr. abstrakta datatyper i progr.språk. Vardera gömmer impl. detaljer för användarna och gör det möjligt att koncentrera på den allmänna strukturen (i st.f. lågnivå impl. detaljer). 1.3 Data Modeller = samling begr. redskap som beskriver - data - datarelationskaper - datasemantik - konsistensbegränsningar Tre grupper: objekt-baserade logiska modeller, post-baserade logiska modeller, (fysiska modeller).

5 1.3.1 Objekt-baserade logiska modeller Används för att beskriva data på logisk och vy nivå. Entitets-relationskaps modellen (E-R) Objekt-orienterade modellen (O-O) 1.3.1.1 E-R modellen Samling grundläggande objekt, entiteter och relationskaper mellan dessa. Entitet särskiljbar (från andra objekt) genom attribut. T.ex. konto-nr och balans beskriver ett visst konto i en bank. En relationskap är en associering mellan flera entiteter. T.ex. deponent (eller cust-acct) associerar en kund med varje konto som kunden har. Mängden av alla entiteter av samma typ: entitetsmängd Mängden av alla relationskaper av samma typ: relationskapsmängd Den logiska strukturen i stora drag av en databas kan uttryckas grafiskt med ett E-R diagram rektanglar, repr. entitetsmängder ellipser, repr. attribut ruter (diamonds), repr. relationskper mellan ent.mgder linjer, länkar attribut till ent.mgder och ent.mgder till relationskaper. cust-id cust-str cust-city acct-nr balance cust-name customer deponent account 1.3.1.2 Objekt-Orienterade Modellen Liksom E-R: baserad på en samling objekt. Ett objekt innehåller värden lagrade i instansvariabler inom objektet. Ett objekt innehåller även kod som opererar på objektet. Dessa kodmängder kallas metoder. Objekt som innehåller samma typer av värden och samma metoder grupperas ihop till klasser.

6 Enda sättet ett objekt kan accessera data av ett annat objekt är genom att till. en metod av det andra objektet. Detta kallas att sända ett budskap (message) till objektet. Till skillnad från entiteter i E-R modllen har varje objekt sin egen entydiga identitet oberoende av de värden det innehåller. Två objekt innehållande samma värden är olika. 1.3.2 Post-baserade logiska modeller Anv. för att beskriva data på begr. (logiska) och vy nivåer. Även högnivå beskrivning av implementeringen (i motsats till objekt-baserade). Databasen är strukturerad i fix-formats poster (därav namnet) av flera typer (förenklar fysiska-nivå impl.). Tre vanligaste (post-baserade): relations (denna kurs handlar mest om detta) nätverks hierarkiska 1.3.2.1 Relationsmodellen Data och relationskaper mellan data repr. av en samling tabeller, som var och en har ett antal kolonner med entydiga namn. Ex. på tabelldata i relationsmodellen customer-name customer-id customer-street customer-city accountnumber Johnson 192-83-7465 Alma Palo Alto A-101 Smith 019-28-3746 North Rye A-215 Johnson 192-83-7465 Alma Palo Alto A-201 Jones 321-28-3123 Main Harrison A-217 Smith 019-28-3746 North Rye A-201 account-number balance A-101 500 A-201 900 A-215 700 A-217 750

7 1.3.2.2 Nätverksmodellen Data repr. av en samling poster och relationskaper bland data representeras av länkar (kan betr. som pekare). Pointer chasing Posterna i databasen är organiserade som samlingar av godtyckliga grafer. 1.3.2.4 Hierarkiska modellen Skiljer sig från nätverksmodellen på så sätt att posterna är organiserade som samlingar av träd i st.f. godtyckliga grafer.

8 1.4 Databas språk Ett databassystem tillhandahåller två typer av språk: ett för att specificera databasschemat, och ett för att uttrycka förfrågningar (queries) och uppdateringar, 1.4.1 Data Definitions Språk (DDL) Spec. ett data schema med en mängd av definitioner i ett DDL. Resultatet av kompileringen av DDL kommandon är en mängd av tabeller som lagras i en speciell fil kallad data lexikon (denna konsulteras förrän verkliga data läses in eller modifieras). Lagringsstrukturen och access metoder spec. med en mängd definitioner i ett speciellt DDL, kallat ett data lagrings och definitionsspråk. 1.4.2 Data Manipuleringsspråk Abstraktionsnivåerna (i 1.2) gäller inte bara strukturering av data utan även manipulering av data. Med data manipulering menar vi sökning av information lagrad i databasen insättning av ny information i databasen strykning av information från databasen modifikation av information lagrad i databasen På den fysiska nivån måste vi definiera algoritmer som tillåter effektiv access till data. På högre abstraktionsnivåer är det i stället effektiv mänsklig interaktion, dvs. bekväm användning som är viktigt. Ett data manipuleringsspråk (DML) är ett språk som tillåter användare att accessera och manipulera data. Två typer: Procedurala DML, kräver att användare anger vilka data efterfrågas och hur de erhålles. Icke-procedura DML, kräver att användare anger vilka data efterfrågas men ej hur de erhålles. Icke-procedurala DML är vanligen lättare att använda, men koden kanske inte lika effektiv. Detta kan förbättras genom inbyggda optimeringstekniker (i själva verket förbättringstekniker), vilka diskuteras i Kap. 12 i kurs-boken. En förfrågan (query) är ett kommando för att söka efter information. Det har blivit praxis att använda frågespråk och data manipuleringsspråk synonymt.

9 1.5 Transaktionshantering Ofta bildar flera operationer av databasen en enda logisk arbetsenhet. Betr. ett exempel med en penningsöverföring där ett konto (A) debiteras och ett annat (B) krediteras. Antingen bör både debiteringen och krediteringen ske eller så ingendera (dvs. överföringen måste ske helt och hållet eller inte alls). Detta allt-eller-ingenting krav kallas atomicitet. Dessutom krävs det att överföringen bevarar databasens konsistens, dvs. värdet av A + B måste bevaras. Slutligen måste de nya värdena av A och B bevaras, trots möjligheten av systemfel, kallas durability. En transaktion är en samling operationer som utför en enda logisk funktion i en databastillämpning. Varje transaktion är både en atomisk och konsistent enhet. Vi kräver alltså att transaktioner inte motstrider några konsistentsvillkor. Om databasen var konsistent när en transaktion startade, så måste databasen vara konsistent när transaktionen terminerar framgångsrikt. Men under transaktionens exekvering kan det behövas att tillfälligt tillåta inkonsistent. Detta kan leda till problem om fel inträffar. Det är programmerarens sak att ordentligt definiera de olika transaktionerna, så att de bevarar databasens konsistens. Att försäkra atomicitet och durability skötes av databassystemet självt - nämligen transaktionshanterings-komponenten. När flera transaktioner uppdaterar databasen samtidigt behöver inte längre konsistensen hos data bevaras trots att varje individuell transaktion är korrekt. Det är på concurrencycontrol managerns ansvar att kontrollera interaktionen bland de samtidiga transaktionerna för att försäkra konsistens hos databasen. Databassystem för små persondatorer har inte dylika finesser, men de är ett krav i större sammanhang. 1.6 Lagringshantering Firmors databaser gigabytes (1000 Megabytes) eller terabytes. Lagras på skivor. Dataflyttningar mellan skivminne och primärminne behövs. Dessa år långsamma jämfört med CPU:s hastighet. Därför: minimera behovet av dylika dataflyttningar. En lagringshanterare (databasmanager) är en programmodul som ger interfacet mellan lågnivåsdata lagrade i databasen och till.program och förfr. givna till systemet. Ansvarig för: Interaktion med filmanagern. DMM översätter de olika DML satserna till lågnivå filsystemskommandon. Integritetskrav. Säkerhetskrav. Backup och återställande. Concurrency control.

10 1.7 Databasadministratör (DBA) Person som har central kontroll över systemet (både data och programmen som accesserar data). Schema definition Lagringsstruktur Schema modifikation och modifikation av fysiska org. Givande av accessrättigheter Specificering av integritetsbegränsningar. 1.8 Databasanvändare - Applikationsprogrammerare - Sofistikerade användare - Naiva användare 1.9 Systemstruktur i stort 1) Query processor komponenter 2) Storage manager komponenter 1): - DML kompilator - Inbyggd DML prekompilator - DDL tolk - Frågeevalueringsmaskin 2): - Auktoriserings- och integritetshanterare - Transaktionshanterare - Filhanterare - Bufferhanterare Dessutom krävs flera datastrukturer för fysiska implementeringen: - Data filer - Datalexikon - Index - Statistiska data

11 1.10 Sammanfattning Ett databashanteringssystem (DBHS) består av en samling data och program som accesserar data. Data beskriver en speciell firma (t.ex.). Det primära syftet är att ge en omgivning som är både bekväm och effektiv för sökning och lagring av information (och typiskt stora informations-mängder). Ett BHS ger användare en abstrakt syn på data: systemet gömmer detaljer om hur data lagras. Det gör detta genom att definiera tre abstraktionsnivåer: den fysiska nivån, den logiska nivån och vy nivån. Databasens struktur anges av datamodellen: en samling begreppsmässiga redskap för att beskriva data, data relationskaper, och data begränsningar. Databaser förändras med tiden när information insätts och stryks.samlingen information lagrad vid ett visst ögonblick kallas databasens instans.designen i stort kallas databasens schema. Möjligheten att modifiera en schemadefinition på en nivå utan att påverka en schemadefinition på nästa högre nivå kallas dataoberoende. Det finns två nivåer av data oberoende: fysiskt d.o. och logiskt d.o. Ett databasschema anges m.h.a. ett data-definitionsspråk (DDL). DDL kommandon kompileras till en mängd av tabeller som lagras i en speciell fil som kallas ett data lexikon. Ett datamanipuleringsspråk (DML) är ett språk som gör det möjligt för användare att accessera och manipulera data. Det finns väsentligen två typer: procedurala och ickeprocedurala. Transaktionshanteraren ansvarar för att försäkra att databasen förblir i ett konsistent tillstånd trots systemfel. Den ser också till att samtidiga transaktioner fortskrider utan konflikter. Lagringshanteraren är en programmodul som ger interfacet mellan låg-nivå data lagrade i databasen och tillämpningsprogram och frågor givna till systemet.

12 Övningsuppgifter 1.1 Vilka är de fyra största skillnaderna mellan ett DBHS och ett filhanteringssystem? 1.2 I detta kapitel har vi listat några av de främsta fördelarna med ett DBHS. Finns det några nackdelar? (W-m 1.2) 1.3 Förklara skillnaden mellan fysiskt och logiskt dataoberoende. 1.4 Lista databasmanagerns uppgifter. För varje fall, förklara de problem som skulle uppstå om ansvaret inte uppfylldes. 1.5 Vad är de viktigaste funktionerna hos en databasadministratör? 1.6 Lista sju olika programmeringsspråk som är a) procedurala och två som är b) icke-procedurala. Vilken grupp är lättare att lära sig och använda? (W-m 1.6) 1.7 Lista de viktigaste stegen då en databas sättes upp för en speciell firma. (W-m 1.7)