Automatiserad hantering av användardefinierade aggregattabeller

(1)

Automatiserad hantering av användardefinierade aggregattabeller

(HS-IDA-EA-00-103)

Johan Carstam (a97johca@student.his.se)

Institutionen för datavetenskap Högskolan i Skövde, Box 408

(2)

Automatiserad hantering av användardefinierade aggregattabeller

Examensrapport inlämnad av Johan Carstam till Högskolan i Skövde, för Kandidatexamen (B.Sc.) vid Institutionen för Datavetenskap.

2000-05-18

Härmed intygas att allt material i denna rapport, vilket inte är mitt eget, har blivit tydligt identifierat och att inget material är inkluderat som tidigare använts för erhållande av annan examen.

(3)

Automatiserad hantering av användardefinierade aggregattabeller Johan Carstam (a97johca@student.his.se)

Sammanfattning

Denna rapport behandlar hur aggregattabeller kan administreras av lagrade procedurer i en databasserver. Målet är att skapa en parser som kan hantera aggregattabeller transparent för de applikationer som använder databasen. För att kunna uppfylla transparens måste denna parsern kunna dra slutsatser om databasstrukturen. Genom att identifiera nödvändig metadata och sedan placera den i ett repository, kan parsern dra sådana slutsatser. Identifiering redovisas i rapporten genom en metadatastudie, vilken ligger till grund för metodens genomförande. I rapporten diskuteras olika metoder för att uppnå en transparent lösning. Den metod som sedan implementeras, är en lagrad procedur. I rapporten dras slutsatsen att det är möjligt att skapa en lagrad procedur i databasservern, som kan utföra de uppgifter som krävs för att hantera aggregattabeller på ett transparent sett.

(4)

1 Inledning

Innehållsförteckning

1 Inledning... 3

2 Databaser ... 4

2.1 Datamodeller ...5 2.1.1 Relationsdatamodellen...6

2.1.2 Metadata i Data Dictionary och Repository ...8

2.2 DBMS...8 2.2.1 Treschemaarkitektur ...9 2.2.2 Dataoberoende ...10 2.2.3 DBMS-språk ...10 2.3 SQL...10 2.3.1 Inbyggd SQL...11 2.3.2 Dynamisk SQL ...11 2.4 Prestanda...12

2.4.1 Prestanda och optimering i databaser ...13

2.4.2 Frågeoptimering...13 2.4.3 Datalager...13 2.4.4 Denormalisering...14 2.5 Vyer ...15 2.5.1 Materialiserade vyer ...16 2.6 Aggregattabeller ...16

3 Problemprecisering ... 19

3.1 Motivering ...19 3.2 Problemfokusering ...19 3.3 Problemformulering ...19

4 Metoder och val av metod ... 21

4.1 Olika typer av projekt ...21

4.1.1 Val av projekt...21 4.2 Hypotes...22 4.4 Metod...22 4.4.1 Litteraturstudie...23 4.4.3 Implementation ...23 4.5 Val av metod...24

(5)

1 Inledning

5 Lösningsmetod ... 25

5.1 Lagrad procedur i servern...25

5.2 Preprocessor ...26 5.3 Mellanlager...28 5.4 Val av lösningsmetod ...28

6 Genomförande ... 29

6.1 Skapa aggregattabeller...29 6.2 Navigering i aggregattabeller ...30 6.3 Design...31 6.3.1 Design av repository ...33 6.3.2 Uppdelning av SQL-satser...36

6.3.3 Sökning i repository och omskrivning av SQL-satser ...38

6.3.4 Sökning i repository och omskrivning för beräkningar i select-satser ...38

6.3.6 Exekvering av SQL-satser ...39

7 Implementation... 41

7.1 Uppdelning av select-satser ...41

7.2 Sökning i repository och omskrivning för summeringar i select-satser ...43

7.3 Exekvering av SQL-frågor ...48

8 Slutsatser ... 49

8.1 Transparens...49 8.2 Portabilitet ...49 8.3 Identifiering av metadata ...49 8.4 Funktionalitet...50

9 Diskussion... 51

10 Fortsatt arbete ... 53

10.1 Mätningar ...53 10.2 Metod...53 10.3 Implementation...53

Referenser ... 75

(6)

1 Inledning

Dagens databaser tenderar ofta till att bli väldigt stora, med tabeller som innehåller flera miljoner rader av information. Det skapas ett behov av att både optimera frågor och själva databasarkitekturen, eftersom storleken på sökområdet i databasen har betydelse för frågors responstid mot databasen.

Att optimera databaser för frågor är ett viktigt moment vid utvecklingen av större databaser. Vid sökning i databaser kan frågornas responstid vara en avgörande faktor för om en databas är en lämplig och applicerbar lösning på ett problem. En teknik som används för att minska responstiden vid frågeaccess till en eller flera tabeller i databasen, är att skapa aggregattabeller associerade till dessa tabeller.

I Oracle 8i finns en funktion som kan hantera aggregattabeller i materialiserade vyer. Den bygger på att aggregattabeller ska kunna utnyttjas till frågor som inte direkt är ställda mot dem, utan mot motsvarande bastabeller. I de fall där en fråga är ställd på ett sådant sätt att det ger en prestandaökning om frågan istället ställs mot en aggregattabell skriver denna hanterare om frågan. Detta gör den transparent, d.v.s. exekveringen utförs mot aggregattabellen utan att applikationen är medveten om att frågan inte ställs mot de tabeller som är specificerat. Detta görs för att undvika att beräkningar utförs varje gång som frågor vilka innehåller beräkningar ställs mot mycket stora tabeller som t.ex. i datalager.

Det här projektet syftar till att undersöka möjligheten att konstruera en parser med en algoritm, vars mål är att öka prestanda när en SQL-server utför sökningar i databastabeller. I ett framtida projekt kan en jämförelse göras mellan den framtagna parsern och den i Oracle 8i inbyggda funktionen för aggregattabeller i materialiserade vyer. De områden som är aktuella att behandla i en jämförelse är funktionalitet och prestanda. Detta kan utföras med hjälp av mätningar. Portabilitet är intressant att undersöka med avseende på hur oberoende av databasserver en parser kan göras.

(7)

2 Databaser

Databaser och databasteknologin ligger till stor del till grund för den allt större användningen av datorer. Databaser kommer i framtiden att spela en stor roll inom nästan alla områden, som t.ex. handel, forskning, medicin, utveckling, utbildning med flera (Elmasri och Navathe, 1994). Elmasri och Navathe (1994) definierar en databas som en samling av relaterad data. Med data menas känd fakta som kan lagras och har en underförstådd (eng. implicit) betydelse. Det kan illustreras med följande exempel: Ta personer som du känner, vilkas adress och telefonnummer du skrivit in i en adressbok eller i något program i en PC. Den data som du lagrat om personerna är relaterad data och har en implicit betydelse. Inom den övergripande databasdefinitionen definierar Elmasri och Navathe (1994) följande egenskaper för en databas:

• En databas representerar i något avseende verkligheten. Ibland kallas den representerade verkligheten för minivärlden. Förändringar i minivärlden reflekteras i databasen.

• En databas är en logisk sammankoppling av data som har egenskaper av arv. En slumpartad samling data kan således inte korrekt kallas för en databas.

• En databas är designad och byggd, och data är inlagd i databasen för ett specifikt ändamål. Databaser har en utvald grupp användare och någon slags applikation som användarna utnyttjar för att komma åt informationen i databasen.

En databas har således en källa som data ursprungligen kommer ifrån, och den har någon form av interaktion med händelser i verkligheten och med de intressenter, som är aktivt intresserade av innehållet. Databaser kan vara olika stora och vara olika komplexa beroende på vilket användningsområde och syfte de är applicerade på. Databaserna kan genereras och underhållas både manuellt eller maskinellt. För att manuellt skapa och underhålla en databas kan ett så kallat databashanteringssystem, även kallat DBMS (eng. Database management

system) användas. Ett DBMS består enligt Elmasri och Navathe (2000) av en samling

program, som möjliggör processen att definiera, skapa och manipulera databaser för olika applikationer. Att definiera en databas innebär specificering av datatyper, strukturer och regler för data som ska lagras i databasen. Att skapa en databas är en lagringsprocess, där data lagras på ett beständigt medium. Detta medium underhålls av DBMS. Att manipulera databasen innefattar att ställa frågor mot den, dvs. hämta information från databasen, eller att uppdatera den, dvs. lägga till eller ta bort information i databasen. Databasen är lagringsstället för data, medan DBMS hanterar informationen i databasen och tillsammans benämns databasen och DBMS för databassystem. En grundläggande egenskap för en databaslösning är att den stöder någon form av dataabstraktion, d.v.s. den döljer detaljer om lagrad data som flertalet databasanvändare inte har någon nytta av (Elmasri och Navathe, 2000). Att införa en datamodell är huvudtekniken för att uppnå dataabstraktion. En datamodell beskriver databasstrukturen. I relationsdatabaser lagras data i form av tabeller. För att definiera och hantera data används olika databasspråk som t.ex. SQL.

(8)

2 Databaser

Figur 1 Databashanteringssystem.

2.1 Datamodeller

En datamodell eller databasmodell är en samling definitioner som beskriver hur verkliga data (eng. real-world data) ska representeras begreppsmässigt som elektronisk information. Datamodellen beskriver också vilka typer av operationer som är tillgängliga för att få access till data och för att uppdatera denna information (O’Neil, 1994). Elmasri och Navathe (2000) definierar en datamodell som en mängd begrepp, som kan användas för att beskriva strukturen i en databas. Med strukturen i en databas menas datatyper, relationer och begränsningar som är specificerade för data i databasen. Det finns ett flertal tillvägagångssätt för att på ett strukturerat sätt få åtkomst till informationen i en databas. En datamodell som används idag är relationsdatamodellen (O’Neil, 1994). En DBMS som använder sig av relationsdatamodellen är en relationsdatabas och kallas ofta för RDBMS och ibland endast för DBMS.

Databassystem

DBMS

Mjukvara för att hantera Frågor/Program

Mjukvara för att hantera access till lagrad data

Lagrad Databasdefinition (Metadata) Lagrad databas Applikation Användare

(9)

2 Databaser

I alla datamodeller är det viktigt att skilja mellan beskrivningen av databasen och själva databasen. Beskrivningen av databasen kallas för databasschema eller metadata (Elmasri och Navathe, 2000).

2.1.1 Relationsdatamodellen

Codd (1982) definierar relationsdatamodellen som en datamodell för data som medför ett antal viktiga egenskaper. Relationsdatamodellen gör databashanteringen relativt enkel, eftersom den försöker förebygga så att databasen ska bli resistent mot fel samt att den ska vara förutsägbar. Codd (1982) beskriver det viktigaste i relationsdatamodellen som;

• Relationsdatamodellen beskriver data i dess naturliga strukturer utan att införa ytterliggare strukturer i maskinrepresentationen.

• Den stöder en matematisk bas för härledning, redundans och konsistens för relationer.

• Den stöder oberoende för den fysiska datarepresentationen, för relationer mellan data samt för implementationsaspekter som t ex. hör till effektivitet.

Relationsdatamodellen representerar databasen som en samling av relationer (Elmasri och Navathe, 2000). Reglerna för relationsdatamodellen bestämmer vilka variationer av tabellstrukturer som är tillåtna. De bestämmer även begränsningar i möjliga hämtningsoperationer. I relationsdatamodellen representeras databasens samlade relaterande information som en samling tabeller.

I relationsdatabasvärlden återkommer ofta begreppen relation, tuppel, attribut, som definieras nedan, enligt Date (1994). I en relationsdatabas är all information representerad i form av namngivna tabeller, vilka innehåller namngivna kolumner (O’Neil, 1994). I relationsdatabasen benämns en rad tuppel, ett kolumnnamn attribut och tabellen benämns relation (Elmasri och Navathe, 2000). Den datatyp som beskriver de olika värden, som ett attribut kan anta, benämns domän. En domän är en form av begränsning för vilken typ av data som kan lagras i en kolumn. Kardinaliteten kallas antalet tuppler och antalet kolumner kan anges som graden på en tabell. En primärnyckel är en unik identifierare, som pekar ut en rad i en tabell, primärnyckeln består av ett eller flera attribut i tabellen, vilkas kombination gör nyckeln unik inom tabellen. En domän är en begränsning för ett attribut, domänen begränsar inom vilket område ett attribut kan anta ett värde. En tabell kallas även för relation. Ett schema är en samling av tabeller, som relaterar till varandra i en databas. En databas kan bestå av mer än ett schema.

För att illustrera hur en relationsdatabas är uppbyggd tillsammans med dess begreppsvärld ges ett exempel nedan som beskriver hur en enkel databas skulle kunna se ut för ett universitet. I universitetets databas vill universitetet lagra vilka studenter som går på skolan, vilka program de läser, vilka kurser som hör till ett program, vilka kurser som ges i en sal och när kursen går. Det kan ge en struktur där informationen delas in i tabeller på följande sätt. Studentinformation lagras i studenttabellen, kursinformation i kurstabellen och information om vilka kurser som ingår i ett visst program i programkurstabellen.

Figur 2 exemplifierar tabeller i RDBMS, där tabellen Student innehåller ett unikt Student_ID för varje student, alla studenters namn, vilket program studenten går på, och studentens telefonnummer. Dessa värden lagras i respektive kolumn. Information om en enskild student lagras i tabellens rader, t ex. så återfinns studenten Fredrik i den första raden med student ID 1, han läser programmet syp och har telefonnummer 415307. Informationen om Fredrik kan t ex. läsas på följande sätt: ur tabellen student får vi fram att Fredrik läser programmet syp och i tabellen programkurser kan det utläsas att i syp ingår kurserna 101, 109 och 110. För att ta reda på var och när Fredrik ska befinna sig för att ta del av kurserna, kontrollerar man kurskoderna 101, 109 och 110 mot kurstabellen och utläser att 101 är programmering i sal

(10)

2 Databaser

Tabell

E212 på måndagsförmiddagar och 109 är programutveckling i sal A205 på onsdagseftermiddagar, osv.

STUDENT Tabellnamn

Student_ID Namn Program Telefonnr Attribut

1 Fredrik Syp 415307

2 Johan Syp 485112 Tuppel

3 Marcus Sep 485170 4 Pernilla dvp 853214 Poster 5 Pia svp 836012 6 Mikael sep 431578 Kolumn PROGRAMKURSER KURSER

Kurskod Program Kurskod Kursnamn Sal Tid

101 syp 101 Programmering E212 Måndag FM

101 sep 102 Databaskunskap E104 Tisdag EM

102 dvp 104 Modellering E118 Måndag FM

104 sep 109 Programutveckling A205 Onsdag EM

104 svp 110 Gränsnittsutveckling E214 Torsdag FM

109 syp 110 syp 110 sep 110 svp Figur 2 Tabeller i RDBMS. Primärnyckelkolumn Domän Program sep dvp syp kvp

(11)

2 Databaser 2.1.2 Metadata i Data Dictionary och Repository

En grundläggande egenskap för en databaslösning är att databassystemet inte bara består av databasen utan också av en komplett beskrivning eller definition av databasen. Denna definition lagras i data dictionary, på svenska kan den benämnas för systemkatalog (Elmasri och Navathe, 2000). Informationen som lagras i data dictionary kallas för metadata eller databasschema och beskriver strukturen för databasen. Metadata specificeras under databasdesignen och är inte avsedd att förändras. Visualiseringen av databasens metadata kallas för schemadiagram. Ett schemadiagram beskriver strukturen för varje tabell. Objekt i exempelschemadiagrammet är student, kurs och programkurs.

STUDENT

Student_ID Namn Program Telefonnr

KURS

Kursnr Kursnamn Sal Tid

PROGRAMKURS

Kursnr Program

Figur 3 Exempel på schemadiagram över metadata i data dictionary

Ett schemadiagram visar endast vissa delar av metadata, som tabellnamn, attribut och vissa databegränsningar. Schemadiagrammet visar inte all information i data dictionary t.ex. inte datatyper för varje attribut och inte heller relationer mellan olika tabeller. Data dictionary används av DBMS och ibland av databasanvändare för att ta reda på information om databasstrukturen. Eftersom DBMS oftast är generella system, eftersom de är inte utvecklade för specifika databasapplikationer, måste de kontrollera data dictionary för att få reda på information om databasens struktur. Det kan vara information om formatet och datatypen på data som DBMS ska göra access på.

En databasutvecklare kan skapa en egendefinierad metadata struktur, ett så kallat repository. Ett repository används ofta som ett stöd för applikationsprogram. Ett repository fyller samma uppgift som data dictionary, men till skillnad från data dictionary som endast är avsett att läsa information ifrån, får databasutvecklaren ändra i ett repository. Den information som inte kan utläsas ur data dictionary kan läggas till i ett repository. Databasutvecklaren kan skapa ett repository där information kan läggas till och tas bort på så sätt att repositoryt beskriver databasen på ett tillfredställande sätt för de applikationer som använder den.

2.2 DBMS

Det finns tre viktiga egenskaper i en databaslösning (Elmasri och Navathe, 1994):

• Isolering mellan data och de program som hanterar data.

• Stöd för flera möjliga vyer av informationen för olika användare i systemet.

• Användning av en data dictionary för att spara information om databasens beskrivning (metadata).

Treschemaarkitekturen är framtagen som hjälp att uppnå dessa egenskaper (Elmasri och Navathe, 1994).

(12)

2 Databaser 2.2.1 Treschemaarkitektur

Figur 4 Treschemaarkitektur

Målet med en treschemaarkitektur är att separera användarapplikationer och data. Den består av en intern, en extern och en konceptuell nivå. Treschemaarkitekturen är endast en beskrivning av data, se figur 4. Den enda data, som verkligen existerar, är data på den fysiska nivån (Elmasri och Navathe, 1994).

Den interna nivån har ett internt schema som beskriver den fysiska lagringsstrukturen i databasen. Det interna schemat använder en fysisk datamodell och beskriver alla detaljer inom datalagring och accessvägar till databasen.

Den konceptuella nivån har ett konceptuellt schema, som beskriver strukturen av hela databasen för en allmän samling användare. Det konceptuella schemat döljer detaljer i den fysiska lagringsstrukturen och fokuserar i stället på att beskriva entiteter, datatyper, relationer, användaroperationer och begränsningar.

Den externa nivån innehåller ett antal externa scheman eller användarvyer. Alla externa scheman inriktar sig på att beskriva den del av databasen, som en specifik användargrupp har intresse av, och döljer då övriga delar av databasen för den användargruppen.

Slutanvändare Extern Nivå Konceptuell Nivå Intern Nivå Lagrad databas Externt synsätt Externt synsätt Konceptuellt schema Internt schema

(13)

2 Databaser 2.2.2 Dataoberoende

Treschemaarkitekturen kan användas för att förklara begreppet dataoberoende, vilket Elmasri och Navathe (2000) definierar som möjligheten att ändra schemat på en nivå i databassystemet, utan att behöva göra ändringar i schemat på en nivå upp i arkitekturen. Han definierar sedan två typer av dataoberoende, ett logiskt och ett fysiskt dataoberoende.

• Logiskt datoberoende är möjligheten att förändra det konceptuella schemat utan att behöva förändra det externa schemat eller applikationsprogram. Det konceptuella schemat kan förändras för att utöka eller förminska databasen (genom att lägga till och ta bort tabeller eller bara attribut i tabeller). Förändringar i databegränsningar kan också införas i det konceptuella schemat utan att påverka externa scheman.

• Fysiskt dataoberoende är möjligheten att förändra det interna schemat utan att behöva förändra varken det konceptuella schemat eller de externa schemana. Förändringar i det fysiska schemat kan vara nödvändiga på grund av att fysiska filer omorganiserats. Till exempel om en ny accesstruktur införts för att öka prestanda vid hämtning eller uppdatering av data. Förändras det interna schemat så att samma data, som tidigare bibehålls i databasen, så ska inte det konceptuella schemat behöva förändras. Till exempel att lägga till en ny accessväg för att förbättra hämtningen av delar av data från en viss tabell, säg från student och program i student tabellen. Det medför inte att en fråga, som att lista alla studenter på syp programmet ska behöva ändras, trots att den kan exekveras snabbare om den nya accessvägen används. Fysiskt dataoberoende handlar endast om att isolera applikationen från de fysiska datastrukturerna, vilket gör det enklare att uppnå fysiskt dataoberoende än logiskt dataoberoende.

2.2.3 DBMS-språk

När designen av databasen är klar och en DBMS är utvald för implementationen av databasen ska databasens konceptuella och interna schema specificeras liksom överföring mellan dessa. Dessa båda scheman kan specificeras med ett datadefinitionsspråk, DDL (eng. data definition

language), i de DBMS som gör en klar separering mellan det interna och det konceptuella

schemat. DBMS använder sig av DDL för det konceptuella schemat och SDL (eng. storage

definition language), för det interna schemat. Överföringen mellan dessa kan göras i något av

dessa språk (Elmasri och Navathe, 2000). För en riktig treschemaarkitektur krävs ytterligare ett språk, VDL (eng. view definition language). När scheman är sammanställda och data är införd i databasen, behöver användarna något att manipulera databasen med. För detta ändamål tillhandahåller DBMS ett datamanipuleringsspråk (DML).

Det är vanligt att det i dagens DBMS används ett integrerat språk när scheman tas fram, dvs. ett språk som inte är bundet till ett specifikt schema. Ett typexempel på ett sådant språk är SQL, som är ett relationsdatabasspråk vilket representeras av språktyperna DDL, VDL och DML (Elmasri och Navathe, 2000).

2.3 SQL

SQL är ett frågespråk som används för access till relationsdatabaser som hanteras av RDBMS (Melton och Simon,1993). I dagsläget stöds SQL av de flesta databasprodukter och SQL är nu det officiella standardspråket för hantering av relationssystem (Date, 1994). Många, t ex Elmasri och Navathe (1994) och O’Neil (1994), säger att SQL står för Structured Query Language men Melton och Simon (1993) och Date (1994) anser att det inte stämmer in på dagens SQL-standard utan enbart på tidiga prototyper av SQL. Detta eftersom språket har utvecklats och inte längre kan anses vara strukturerat och således finns den ursprungliga

(14)

2 Databaser

betydelsen i inte kvar i benämningen SQL. SQL-språket stöder satser för datadefinition och manipulering dvs. DDL (eng. Data definition language), och DML (eng. data manipulation

language). DML innefattar satserna select, insert, update och delete. SQL kan användas i

kombination med andra programmeringsspråk som C, ada, pascal, cobol, m.fl. Då kallas det ofta för inbyggd SQL (eng. embedded SQL)

2.3.1 Inbyggd SQL

Den fundamentala principen för inbyggd SQL är att alla SQL-satser som kan användas interaktivt också ska kunna användas i ett applikationsprogram (Date, 1994). Det blir en markant skillnad mellan en interaktiv SQL-sats och dess motstycke i inbyggd SQL, särskilt vad gäller hämtning av svar, vilket kräver en utökad handling hos det värdspråket som behandlar inbyggd SQL.

Ett exempel på inbyggd SQL är PL/SQL, som är en procedurell utökning av SQL. Med hjälp av PL/SQL kombineras enkelheten och flexibiliteten hos SQL med procedurell funktionalitet hos ett strukturerat programmeringsspråk. I PL/SQL är det möjligt att deklarera variabler, konstanter, pekare och undantag. PL/SQL-kod kan lagras centralt i databasen, vilket gör att nätverkstrafiken kan minskas mellan databasen och applikationen. Det i sin tur ökar applikationens och systemets prestanda. Även om PL/SQL-kod är lagrad i databasen är det möjligt för applikationen att skicka block av PL/SQL till databasen istället för separata SQL-satser. Med hjälp av PL/SQL- procedurer placerade i databasen kan dataaccess kontrolleras. 2.3.2 Dynamisk SQL

Dynamisk SQL består av en mängd inbyggda SQL-resurser som specifikt stöds för att möjliggöra generella konstruktioner. Konstruktionen kan ha en direktansluten (eng. online) access till databasen via en terminal eller vara en interaktiv applikation (Date, 1994). En direktansluten applikation behöver gå igenom följande steg:

1. Acceptera kommandot från terminalen. 2. Analysera kommandot.

3. Ställa den korrekta SQL-satsen mot databasen.

4. Returnera ett meddelande och/eller resultat till terminalen.

Om antalet kommandon, som applikationen/programmet kan hantera, är relativt litet och antalet möjliga SQL-satser som kan ställas är litet, kan det ”hårdkodas” i programmet. Är det däremot stora variationer i input data till programmet, är det inte alltid praktiskt lämpligt att ha fördefinierade och ”hårdkodade” SQL-satser för varje möjligt kommando. I de fallen är det mer lämpat att först konstruera SQL-satsen dynamiskt och sedan kompilera och exekvera den dynamiska satsen.

2.3.3 SQL-processen för olika satser

Frågor skiljer sig från övriga SQL-satser i det avseendet att de returnerar ett resultat. Andra satser returnerar endast att satsen lyckats eller misslyckats. En fråga kan returnera allt från en upp till flera tusentals resultatrader. En frågas resultat lämnas alltid i form av en tabell. En fråga som är skriven i ett högnivåfråge-språk som SQL måste först skannas och sedan valideras innan den kan ställas mot en databas. Skannern identifierar språkkomponenter i frågans text. Parsern kontrollerar frågans syntax för att undersöka om den är korrekt formulerad, enligt de syntaktiska reglerna i frågespråket. DBMS valideras sedan för att kontrollera att alla attribut och tabellnamn är giltiga och semantiskt meningsfulla. Frågeoptimeraren måste sedan välja en exekveringsstrategi för att hämta frågeresultatet från

(15)

2 Databaser

de interna databasfilerna. En fråga har oftast flera möjliga exekveringsstrategier. Den process som väljer en lämplig exekveringsstrategi kallas för frågeoptimering. Efter att frågeoptimeraren valt en exekveringsstrategi, generar frågekod-generatorn koden för att exekvera strategin. Databasprocessorn exekverar sedan frågekoden för att skapa frågans resultat. Frågekoden kan antingen vara kompilerad eller interpreterad (Elmasri och Navathe, 2000).

Figur 5 Frågeprocessen

2.4 Prestanda

Prestanda kan ha två betydelser (McDaniel, 1993):

1. Hastigheten som en dator arbetar i, antingen teoretiskt (till exempel, genom att använda en formel för att beräkna Mtops (eng. millions of theoretical instructions per second)) eller genom att räkna utförda instruktioner eller operationer under ett benchmarktest (till exempel MIPS (eng. millions of instructions per second)). Ett benchmarktest utför vanligtvis någon form av arbete som ska efterlikna arbetet en dator skulle göra i en verklig situation.

2. Den totala effektiviteten i ett datorsystem, vilket inkluderar systemkapacitet (eng.

throughput), enskilda responstider och tillgänglighet.

Enligt IBM Dictionary of Computing (vilken citerar ISO:s Information Technology

Vocabulary), är responstid: Den tid som förflyter mellan slutet på en förfrågan eller begäran

till ett datorsystem och början på svaret; till exempel den tid som går mellan en slutindikering på en förfrågan tills att det första tecknet i svaret visas på en skärm. Eftersom input från användaren och systemets svar kan anta flera former än enbart text kan exemplet i ISO:s definition utökas. Det finns även ett begrepp för det som användaren kan uppfatta som responstid (eng. perceived response time) d.v.s. den tid som användaren känner av, som början

av input tills slutet på svaret. I datateknologin är systemkapacitet den mängd arbete som en dator kan utföra under en given tidsperiod.

Ny övergående form av frågan

Exekveringsstrategi

Frågans exekveringskod Frågeoptimeraren

Parser, översättare och validerare

Frågekodgeneratorn

Databasprocessorn

Frågans resultat Fråga i ett högnivåspråk

(16)

2 Databaser 2.4.1 Prestanda och optimering i databaser

Databasers användningsområde är mycket vid, därför har denna teknik kommit att växa allt mer. Under tiden lagras allt mer information i de befintliga databaserna. Detta ställer krav på att databaser ska kunna hantera all inkommande information samtidigt som de ska stödja service i form av att ge information till de som arbetar mot databasen. Samtidigt ökas antalet användare som är uppkopplade mot databassystemen. När antalet användare och informationsmängderna växer gäller det att databasen är konstruerad på ett sådant sätt att den klarar av att utföra servisen utan att prestanda försämras.

Det finns flera prestandahöjande tekniker för databaser, som att optimera frågor mot databasen och att optimera lagringsstrukturen i databasen. Vilken teknik som kan och bör väljas beror på vad databasens huvudsakliga ända mål är. Det kan t ex vara att till största del föra in data i databasen, så kallade uppdateringsintensiva databaser, eller databaser för informationssystem, som har sitt huvudsakliga syfte i att ge en service för presentation av data i databasen, frågeintensiva databaser.

Optimering av lagringsstrukturen kan göras med hänsyn till så kallade datalager. Datalager inriktar sig på att öka prestanda för frågeintensiva databaser.

2.4.2 Frågeoptimering

Frågeoptimering är den process som utförs för att välja den mest effektiva lösningen för att exekvera en SQL-sats. Optimering är ett viktigt steg i alla satser som: select, insert, update och delete, i ett datamanipuleringsspråk (eng. data manipulation language), benämnt (DML). Det finns ofta många olika sätt att exekvera en SQL-sats på, t.ex. kan man variera accessordningen av tabeller och index som ingår i sats. Genom optimering av SQL-satser kan stor vinning uppnås vad gäller hur snabbt en sats exekveras.

En frågeoptimerares mål är att minimera användningen av en särskild resurs genom att välja den bästa av flera accessvägar för en fråga. Resurserna som är intressanta är användningen av CPU-tid och antalet I/O-operationer som är nödvändiga. Datorns minne är även en viktig resurs men minneskapaciteten är olika för olika ändamål och bestäms oftast vid systeminitieringen (O’Neil, 1994).

En optimerare är ett program som evaluerar flera faktorer för att kunna välja en av flera alternativa accessvägar för en SQL-sats, som t.ex. ett kostnadsbaserat eller regelbaserat tillvägagångssätt.

2.4.3 Datalager

Datalager (eng. data warehouse) är en logisk integrerad datakälla för beslutsstödsystem och administrativa informationssystem. Enligt Simon (1995) är ett datalager ingen databas. Även om datalager kan implementeras med hjälp av DBMS, så behöver det inte nödvändigtvis vara ett krav. Syftet med ett datalager är enligt Simon (1995) att stödja informationshanterings-system och inte en organisations funktion eller dess transaktioner. Det gör att många principiella delar som en databas eller DBMS stöder inte är nödvändiga.

(17)

2 Databaser

I ett datalager lagras information från en eller flera databaser för att applikationer och användare ska kunna ställa frågor på dess data, på ett effektivare sätt, än vad som skulle vara fallet om frågorna ställdes mot en databas. Den interna strukturen för lagring av data i ett datalager skiljer sig från en databas interna strukturer i det avseendet att datalagrets struktur är optimerad för frågor. I ett datalager införs ofta redundant data, för att frågor ska kunna exekveras snabbare.

Figur 6 Arkitektur för datalager.

Den snabbt växande användningen av datalager har medfört att mycket stora databaser innehållande mycket detaljerad (eng. fine-grained) information har skapats. En ökande trend är idag att lagra daglig utförd information i datalager eller till och med information på transaktionsnivå (Kimball, 1998). Det är oftast nödvändigt att ha en detaljerad nivå på informationen i ett datalager eftersom analyser ofta går in på detaljnivå. T ex om en analytiker vill ta reda på hur många kunder det är som förnyar sitt kabel TV abonnemang varje dag, eller som följer efter en speciell mediahändelse, så behövs mycket detaljerad information.

Det mest effektiva sättet att öka prestanda i ett datalager är att stödja aggregattabeller som lagras tillsammans med bastabellerna i databasen, (Kimball, 1998). Att använda aggregattabeller kan ge mycket stor effekt på prestanda, i vissa fall kan det minska responstiden för frågor med en faktor 100 ibland 1000, mot att inte använd aggregattabeller. Ingen annan teknik finns idag som ger en sådan effektfull prestandaökning (Kimball, 1998). Fördelarna med aggregat är att de kan realiseras med nästan alla datalager- hård och mjukvaror, vilket inkluderar alla RDBMS som Oracle, Informix, DB2, Sysbase med flera. 2.4.4 Denormalisering

Denormalisering av den fysiska databasstrukturen kan göras för att öka prestanda för frågor. Denormalisering görs genom replikering av attribut vilka ofta är förekommande i specifika frågor. Detta görs genom att attribut från en tabell också lagras i en annan tabell (Elmasri och Navathe, 1994). Ett exempel på en delnormaliserad struktur visas i figur 7. Denna figur innehåller en faktatabell som är skapad utifrån dimensionstabellerna (kund, tid, leverantör, order och produkt). I faktatabellen lagras nycklarna från dimensionstabellerna samt de attribut som anses vara relevanta för t ex frågeoptimering. Den informationen som lagras i faktatabellen är redundant information, eftersom den också lagras i dimensionstabellerna.

Applikation 1 Applikation N

Datalager Databas

operationer (läsa/skriva)

Periodiska uppdateringar och överföringar av data till datalagret

Informationssystem

Frågor mot informationen

Operativ Databas

(18)

2 Databaser

Figur 7 Exempel på denormalisering.

2.5 Vyer

När en applikation är byggd, väljs en underliggande datamodell för att göra applikationen effektiv. Ofta använder flera applikationer samma data, fast den modelleras olika beroende på applikationen. Vymekanismen är en teknik för att modellera data olika för olika applikationer, utan att påverka det underliggande dataformatet och datastrukturen. Tekniken möjliggör applikationer att anpassa dataobjekt som är delade mellan flera applikationer utan att det påverkar de applikationer som använder samma objekt. Det växande behovet av datamanipulering från företagens sida kan inte hanteras av existerande ärvda system (eng.

existing legacy systems) som innehåller värdefull data. Således har vytekniken blivit ett

alltmer viktigt sätt att modellera och använda data i nya applikationer, (Gupta, Mumick, 1999).

Enligt Elmasri och Navathe (2000) är en vy i SQL-termologin en specifik tabell som är framställd ifrån en eller flera tabeller, dessa tabeller kallas för bastabeller. Vyer kan i sin tur användas som bas för en ny vy. En vy behöver nödvändigtvis inte existera fysiskt, utan den kan ses som en virtuell tabell. Detta skiljer sig från bastabeller vilkas tuppler/rader är fysiskt lagrad i databasen. En vy har begränsade uppdateringsegenskaper på grund av att den är virtuell, däremot finns inga begränsningar när det gäller att ställa frågor till den. Frågor till en vy kan specificeras på samma sätt som en fråga till vanliga tabeller. En vy är alltid aktuellt uppdaterad, dvs. att om en rad ändras eller läggs till i en bastabell vilken en vy är definierad på, så uppdateras vyn med förändringen automatiskt. En vy skapas inte då den definieras utan först då en fråga är ställs på den.

Som ett exempel på användbarheten hos en vy är ta ett fleranvändarsystem där olika användare har olika rättigheter i systemet. Ett enkelt sätt att administrera rättigheterna är att skapa vyer för de olika användargrupperna. Eftersom en vy kan specificeras över flera tabeller kan vyer anpassas så att inte all information som finns i tabellen representeras i vyn, vilket underlättar rättighetshanteringen i tabeller, som t.ex. om en användare inte har rättighet till hela tabellen.

Att implementera en vy för att på ett effektivt sätt kunna ställa frågor på den är komplext, Elmasri och Navathe (2000) ger två möjliga lösningar:

1. Den icke materialiserade vyn som inte är lagrad i databasen, vilket innebär att frågor som ställs mot vyn modifieras om så att den istället ställs på vyns underliggande bastabeller. Nackdelen med det här tillvägagångssättet är att det inte är effektivt för vyer som är definierade utav komplexa frågor.

2. Materialiserade vyer innebär att en fysisk vytabell skapas temporärt då en fråga ställs till den första gången. Vytabellen lagras sedan i databasen, med förhoppningen att samma typ av fråga kommer att ställs igen och då ska frågeprocessen inte behöva ta lika lång tid eftersom vyn redan är skapad.

FAKTA TABELL

KUND LEVERANTÖR

ORDER PRODUKT

(19)

2 Databaser 2.5.1 Materialiserade vyer

Materialiserade vyer är vyer som har exekverats och sedan lagrats i databasen. Eftersom de reducerar behovet av att återskapa en vy eller data som blivit frågad på, ger de möjlighet att minska den tid som frågan kräver för att exekveras. En annan fördel är att de stöder ett systematiskt sätt att beskriva och återexekvera data, det medför att underhåll och utveckling kan automatiseras. Materialiserade vyer är särskilt användbara i datalager för frågeoptimering, underhåll av integritetsregler, analytiska direktanslutna processer samt applikationer för fakturering, banker och försäljning, (Gupta och Mumick, 1999).

Materialiserade vyer används i databaser och datalager för att beräkna och lagra aggregerad data, som summor, medelvärden etc. Materialiserade vyer används även för att beräkna joinoperationer, med eller utan aggregat. Materialiserade vyer tar upp lagringsutrymme på disken, de måste uppdateras då data i dess bastabeller ändras. När materialiserade vyer används tillsammans med frågeomskrivning (eng. query rewrite) kan de öka prestanda för exekveringen av frågor. Dess existens är då transparent för SQL applikationer och användare, vilket ger den fördelen att användaren eller applikationen inte behöver ha information om dess existens för att kunna utnyttja den.

Materialiserade vyer kan öka frågeprestanda genom att frågeoptimeraren kalkylerar kostnaden för join- och aggregationsoperationer, med avseende på exekveringstid för de tabeller och vyer som kan utnyttjas för frågan. Frågeoptimeraren upptäcker här automatiskt när det finns en existerande materialiserad vy som matchar en fråga. Frågeoptimeraren skriver om frågan transparent för att kunna använda den materialiserade vyn. Frågeoptimeraren använder sedan den materialiserade vyn, om kostnadskalkylens beräkning resulterar i att det kan vara mer optimalt med avseende på prestanda. Därefter ställs den omskrivna frågan mot den materialiserade vyn i stället för till de underliggande bastabellerna eller vyerna. Tekniken att skriva om frågor för att använda materialiserade vyer istället för bastabeller kan resultera i en kraftig prestandaökning (Kimball, 1998).

2.6 Aggregattabeller

Figur 8 Aggregattabell.

Tidnyckel Ringt telenr Samtalstid kostnad Månad Samtalstid Kostnad

2000-01-31 781238 6,23 2,49 nov-99 55,12 22,05 2000-02-02 481212 1,25 0,50 dec-99 208,53 83,41 2000-02-02 145358 5,53 2,21 jan-00 118,48 47,39 2000-02-04 158724 6,67 2,67 feb-00 109,23 43,69 2000-02-06 456523 8,94 3,58 2000-02-07 785612 0,41 0,16 2000-02-25 856545 56,21 22,48 2000-02-25 811227 4,33 1,73 2000-02-25 899878 6,54 2,62 2000-02-27 856421 7,32 2,93 2000-02-29 651282 3,48 1,39 2000-03-02 544634 5,37 2,15 Kund Kund/månad

Bastabell

Aggregattabell

Den månadsbaserade

samtalstabellen grupperar

bastabellens samtal i en

kompakt tabell.

(20)

2 Databaser

Inmon (1996) definierar en aggregattabell som en tabell, som grupperar många olika

förekomster av detaljerade data från operativ data in i en tabell som lagras fysiskt i databasen. En aggregattabell skapas genom att gruppera data från en eller flera bastabeller. Som exempel på detta kan ett telefonbolag gruppera alla telefonsamtal från en kund vid, varje månadsslut och föra över den samlade informationen i en ny tabell, en aggregattabell, som lagrar en summering. Genom att göra så skapas en aggregattabell vid sidan av den befintliga tabellen, som lagrar en kunds alla månatliga samtalsaktiviteter.

När en fråga, som t.ex. ska returnera total samtalstid och kostnad för en specifik månad, ställs mot bastabellen måste alla poster under denna månad summeras ihop. När samma typ av fråga ställs mot aggregattabellen behöver endast en post returneras, nämligen en redan beräknad månadspost. Tekniken att göra beräkningar i förväg och lagra dem i databasen kan öka prestanda när frågor ställs mot databasen.

Figur 9 visar en fråga mot bastabellen, som behöver hämta in alla poster för den specifika månaden och summera dem.

Figur 9 Select mot bastabell.

Figur 10 visar en fråga mot aggregattabellen, som endast behöver hämta in en förberäknad post.

Figur 10 Select mot aggregattabell.

Enligt Kimball (1998) har aggregattabeller fördelen med aggregattabeller är att de kan ge en enorm effekt på prestanda. Höga aggregatnivåer som t ex total årliga nationella försäljningen, kan ofta ge en 1000-faldig förbättring i exekveringstid, jämfört mot att gå igenom den dagliga försäljningen eller de dagliga transaktionerna. Kimball (1998) nämner även att aggregattabeller har två stora nackdelar. Det ena är att de tar upp plats i databasen. Det andra är navigeringen, d.v.s. slutanvändarens frågeverktyg måste specificera i SQL-satsen att det just är en aggregattabell som ska användas i frågan, annars kommer den inte till nytta. Databasadministratören måste även manuellt uppdatera varje aggregattabell och associerade index efter det att uppdateringar skett i tillhörande bastabeller. Detta måste göras för att hålla data koncistent mellan aggregattabeller och bastabeller (Kimball, 1998). Inkonsistent data kan medföra inkorrekta frågeresultat.

Frågor som gör summeringar är kritiska i det avseendet att de sätter samman delar av individuella transaktioner till systematiserad information vilket framhäver trender i data vilken i sin tur hjälper användare att ta beslut beroende på informationen. Nackdelarna med frågor som gör summeringar eller andra beräkningar är att de kan generera stora mängder overhead, när de söker igenom stora tabeller, vilket t ex är vanligt i datalager. Resultatet kan

SELECT SUM(samtalstid), SUM(Kostnad) FROM KUND

WHERE tidnyckel>20000131 AND tidnyckel<20000301;

SELECT samtalstid, kostnad FROM KUND_MANAD

(21)

2 Databaser

bli oacceptabla responstidsfördröjningar, från flera minuter upp till timmar. Ett följdproblem är att detta kan påverka prestanda negativt för frågor som exekveras samtidigt.

Aggregattabeller används ofta för att beräkna data innan frågor ställs mot databaser eller datalager. Aggregattabeller lagrar summerad data eller beräkningar fysiskt i databasen. Aggregattabeller undviker problem vid summerings- och beräkningsfrågor genom att den är fysiskt lagrad i databasen och en sådan fråga behöver således inte söka i all relevant data utan endast data i aggregattabellen.

(22)

3 Problemprecisering

3.1 Motivering

Databaser kan vara optimerade för olika syften beroende på vilka ändamål de ska användas till, t.ex. används datalager för att öka prestanda vid sökning i väldigt stora informationsmängder. En teknik som används för att just minska söktiden i databaser och datalager, är att skapa aggregattabeller som ett komplement till de redan existerande tabellerna. Prestandaökningen kan i vissa fall uppnå en faktor på 100 ibland 1000 mot att frågor ställs direkt mot databasens bastabeller (Kimball, 1998). Aggregattabeller kan i princip skapas i alla DBMS, men det är endast en eller ett fåtal DBMS som stöder hanteringen av aggregattabellerna, däribland Oracle. För de databasutvecklare som inte använder sig av ett DBMS som stöder hantering av aggregattabeller är det intressant att utveckla en produkt som är oberoende av DBMS och kan appliceras på just deras databassystem.

3.2 Problemfokusering

Den här rapporten fokuserar på aggregattabellernas användningsområde. Det diskuteras mer i detalj kring hur aggregattabeller kan utnyttjas på ett transparent sätt, för att kunna ta tillvara på de prestandavinster som aggregattabeller kan ge upphov till.

Ett problem med aggregattabeller som lagras direkt i databasen är att det inte finns tillräcklig information (metadata) lagrad om deras existens i data dictionary, för att aggregattabellerna ska kunna användas på ett enkelt sätt. En databasutvecklare måste känna till och hålla reda på alla aggregattabeller som finns i en databas och förstå när en specifik fråga ska använda en specifik aggregattabell, t ex genom att i slutanvändarens frågeverktyg specificera att en SQL-sats ska använda en viss aggregattabell i en bestämd fråga. Rapporten ger en inblick i hur sådana problem kan lösas.

I dag finns det DBMS-utvecklare som kan hantera dessa problem i sina system, t.ex. erbjuder Oracles DBMS stöd för aggregattabeller i materialiserade vyer. Rapporten behandlar de stöd som kan uppnås för att på egen hand administrera aggregattabeller.

3.3 Problemformulering

Målet med projektet är att på ett transparent sätt kunna utnyttja aggregattabeller när frågor ställs mot tillhörande bastabeller, dvs. på ett transparent sätt, utan att det är specificerat i frågan. En applikation (parser) ska skapas för att utföra en service, på så sätt att frågeverktyget inte måste ha vetskap om aggregattabellers existens för att kunna utnyttja dem. Med transparent menas i den här rapporten att en parser utför en service åt en applikation för att förenkla en process. Parsern utför automatiskt olika operationer åt applikationen, på sådant sätt att applikationen inte behöver vara medveten om dessa operationer.

En parser är enligt IEEE standarden 610.12-1990 ett program, vanligtvis en del av en kompilator, som tar emot input i form av sekventiella källprograms instruktioner, interaktiva direktanslutna kommandon (eng. online commands), taggar, eller något annat definierat gränssnitt. Den delar isär inputinformationen för att andra programkomponenter sedan ska kunna använda dem. Att uppnå transparens för frågor är ett huvudmål, eftersom problemet med aggregattabeller i flertalet av dagens DBMS är att det måste specificeras specifikt i en fråga att en aggregattabell ska användas. För att frågor ska kunna ställas transparent till aggregattabellerna krävs att tillräckligt med metadata om aggregattabellernas existens lagras i ett repository. Den metadata som är nödvändig för att lösa problemet ska identifieras. Metadata kan variera beroende på val av lösningsmetod.

(23)

3 Problemprecisering

En parser ska konstrueras på så sätt att en SQL-frågesats ska kunna tas emot och parsern ska lokalisera om det finns någon aggregattabell som kan utnyttjas till frågan. Om så är fallet ska frågan skrivas om av parsern, på så sätt att den nya frågan utnyttjar aggregattabellen och att den nya frågan genererar samma resultat som den ursprungliga frågan. Parsern är den mekanism som utför tjänsten så att frågor kan ställas transparent mot databasen.

Figur 11 Parserns funktion.

Lösningens mål är att minska exekveringstiden för select-frågor mot databasen. Lösningen uppfyller sitt mål om tiden för att exekvera en fråga med hjälp av parsern och aggregattabeller understiger tiden att exekvera en fråga direkt mot databasens bastabeller. Parsern kommer att ta en viss mängd tid att exekvera. Tidsvinsten ligger i att antalet I/O-operationer för att inhämta data från databasfilerna (på disk) till databasens cacheminne reduceras om aggregattabeller utnyttjas.

Portabilitet är intressant att undersöka med avseende på hur oberoende av en databasserver parsern är. Pressman (1997) beskriver portabilitet som den möda som behövs läggas ner för att flytta ett program från ett hårdvaru- eller mjukvarusystem till ett annat. I den här rapporten menas portabilitet hur oberoende parsern är från den server den arbetar mot. Ett exempel på en portabel konstruktion av en parser, är en parser som kan användas på flera databasservrar utan att några modifieringar behövs göras.

Ur problemformuleringen kan en hypotes lyftas fram, ”Är det möjligt att skapa en parser som

på ett transparent sätt kan hantera aggregattabeller?”

7) Presentation 1) Fråga Databas 2) Sök i Data Dictionary efter aggregattabeller Parser 4) skriv om frågan Repository (metadata) 3) svar 5) Ny fråga 6) Resultat Användare Data

(24)

4 Metoder och val av metod

4.1 Olika typer av projekt

Det finns flera typer av undersökningar, de flesta klassificeras utifrån hur mycket kunskap som finns inom ett visst problemområde, innan undersökningen startar. När det finns hål och luckor i kunskapen kommer undersökningen att vara utforskande, explorativ (Patel och Davidson, 1998). En explorativ undersökning syftar till att inhämta så mycket information som möjligt för att kunna belysa ett bestämt problemområde allsidigt. Vid explorativa undersökningar används ofta flera olika tekniker för att ta fram information. Eftersom dessa undersökningar syftar till att uppnå kunskap, är idérikedom och kreativitet viktigt.

När det finns mycket kunskap inom ett problemområde kommer undersökningen att vara beskrivande, deskriptiv (Patel och Davidson, 1998). Vid deskriptiva undersökningar begränsas oftast undersökningen till att undersöka några aspekter av problemområdet. De beskrivningar som görs är detaljerade och grundliga. Det kan vara beskrivningar av aspekterna var för sig eller av samband mellan olika aspekter.

Inom problemområden där kunskapsmängden är ännu mer omfattande och teorier har utvecklats, kommer undersökningen att vara hypotesprövande (Patel och Davidson, 1998). Hypotesprövande undersökningar förutsätter att det finns tillräckligt med information om problemområdet för att från teorin kunna härleda antaganden om verkligheten. Antaganden som görs kallas för hypoteser och uttrycker samband. För att hypoteser ska kunna prövas krävs att undersökningen läggs upp på så sätt att den undanröjer risken för att resultatet påverkas av annat än vad som uttrycks i hypotesen.

4.1.1 Val av projekt

Problemområdet i det här projektet är känt och dokumenterat, vilket gör att ingen undersökande rapport för att komma fram med ny kunskap inom problemområdet behöver göras. Rapporten beaktar möjligheten att skapa en viss typ av parser. Problemet är formulerat som en fråga, vilket gör det möjliga att lyfta fram en. Utifrån resultatet kan hypotesen falsifieras genom olika tester och mätningar. Problemområdet undersöks med hjälp av en hypotesprövande undersökningsmetod.

(25)

4.2 Hypotes

Forskningsarbeten ska vara teoretiskt förankrade vilket innebär att de har sin utgångspunkt i etablerade teorier och modeller. Underlaget för teoribildandet är data, d.v.s. information om den del av verkligheten som studeras. Detta underlag kallas ofta för empiri. Ur observationer av empirin tas hypoteser fram som i sin tur kan forma teorier. En forskares arbete är att relatera teori och verklighet till varandra.

En hypotes är ett antagande om hur två eller fler begrepp är relaterade och kan definieras som ”en språklig sats i vilken olika begrepp sätts i relation till varandra”, (Patel och Davidson, 1998). Grundtanken med hypoteser är att göra en empirisk prövning för att se om en hypotes ger en sann eller falsk bild av verkligheten. Det kan göras genom att verifiera eller falsifiera hypotesen. Ett motexempel räcker som grund för att falsifiera en hypotes. Antalet exempel som testas med ett icke falsifierande resultat kan inte ge grund till att verifiera en hypotes, eftersom det alltid kan finnas ett hittills oprövat motexempel. Om hypotesen håller i ett fall stödjer det hypotesen, men det bevisar inte att den är sann. Det vanliga vad gäller forskning är att försöka falsifiera hypoteser. Så länge ingen lyckats falsifiera hypotesen kan den antas vara sann.

När tester utförs för att falsifiera en hypotes är det viktigt att iaktta de olika situationer som kan uppstå som:

• För vilka situationer höll hypotesen?

• För vilka situationer höll inte hypotesen?

• Vilka tänkbara fel finns i testet, när hypotesen höll?

• Hur vanlig är denna situation, när hypotesen höll?

• När hypotesen inte höll, finns det då en bättre hypotes som kan gälla?

En teori är traditionellt sett ett system av hypoteser, antaganden och satser som beskriver en avgränsad del av verkligheten. Patel och Davidson (1998) definierar en teori som: ”Ett system av inbördes relaterade begrepp som tillsammans ger en bild av en företeelse. Den uttalar sig om hur begreppen relaterar till varandra så att det går att förklara och förutsäga företeelsen eller innebörden av den.” En forskare åskådliggör vanligen en teori med hjälp av en modell.

4.4 Metod

I det här kapitlet behandlas valet av den eller de metoder, utifrån problemområdet i fortsättningen ska diskuteras. Det finns olika forskningsmässiga metoder, och vilken eller vilka som väljs beror på problemet som behandlas. Att forska inom ett område görs för att öka kunskapen och förståelsen inom området. Metoden eller ”metodologin ger principen för kunskapssökandet, dvs. den anger förhållandet mellan teori och empiri, föreskrifter för problemformulering och analys, antaganden om giltighet i frågeställningar samt kriterier för verkligheten” (Patel och Davidson, 1998). En metod används för att understödja forskningsarbetet genom att den hjälper forskaren att utföra ett strukturerat arbete, att säkerställa vetenskapligheten i arbetet, att göra resultat i arbetet jämförbara och att dra nytta av tidigare erfarenheter från andra arbeten.

(26)

Det finns olika metoder att undersöka ett projekt med, bland annat litteraturstudie, intervju, fallstudie, experiment, implementation, simulering och teoretisk analys. De metoder som kan vara aktuella för detta projekt är:

• Litteraturstudie är lämplig för explorativa och deskriptiva projekt, men den kan användas som inslag i en hypotesprövande studie. Litteraturstudier används för att samla ihop och presentera information.

• Implementation kan ingå för att undersöka hypotesens giltighet. 4.4.1 Litteraturstudie

En litteraturstudie ska understödja att ett forskningsprojekt sätts i ett bredare sammanhang och att bekräfta dess närvaro inom det specifika studeringsområde. En litteraturstudie består av två huvudsakliga delar (Dawson, 2000):

1. Söka efter litteratur och hantera det insamlade materialet.

2. Redovisning av litteratur, vilket kräver en kritisk förståelse av det insamlade materialet. Litteraturstudier fortgår under hela projektets gång och genom att förfina och konsolidera den insamlade informationen försäkras att projektet bibehåller sin aktualitet. Med tanke på materialet som används i projektet bör dess akademiska värde beaktas. I det här projektet används böcker för att ge en grundläggande förståelse inom ämnet. Böcker som används måste vara aktuella eftersom området är under ständig utveckling. I djupare diskussioner inom vissa ämnesområden används ibland artiklar, då inte böcker ger tillräckligt stöd.

En litteraturstudie görs i detta projekt för att undersöka olika möjligheter att implementera en parser som på ett transparent sätt kan hantera aggregattabellerna. Det är viktigt att bedöma materialet kritiskt för att ta reda på vilket budskap en författare försöker uttrycka. I ett hypotesprövande projekt kan en litteraturstudie formas på ett sådant sätt att den stödjer hypotesen, vilket inte är bra för ett objektivt forskningsprojekt som detta. En litteraturstudie i detta projekt är flexibel i den bemärkelse att det finns olika typer av litteratur som behandlar området. En litteraturstudie är i regel ett måste när det gäller hypotesprövande projekt (Patel och Davidson, 1994). I det här projektet används litteraturstudier för att ta reda på teorin som ligger till grund för problemet. En litteraturstudie är inte lämplig för att konkret testa hypotesen i projektet, vilket i stället görs med hjälp av experiment innehållandes verkliga scenarion.

4.4.3 Implementation

Det är inte nödvändigtvis så att ett projekt inom datorvärlden behöver innehålla en implementationsdel, men om projektets mål är att testa och demonstrera en viss funktion, som t.ex. att testa en idé, demonstrera en teknik eller algoritm, eller att utvärdera ett koncept, kan en implementation vara nödvändig (Dawson, 2000). Oavsätt anledningen för en implementation så ställer det krav på att koden uppfyller en ”acceptabel kvalitet” (Dawson, 2000). Även om ett projekt inte antas producera komplett dokumentation om mjukvaran från designfasen till testningsfasen och vidare utveckling, ska den producerade koden tillfredställa projektets mål. Ett problem med att göra en implementation för att undersöka om ett projekts mål är uppnått, är att det är svårt att garantera att resultatet inte beror på buggar som smugit sig in i koden. En implementation är trots detta problem lämplig för att undersöka möjligheten att skapa en parser för ändamålet. En implementation är aktuell i projektet, för att med ett verkligt experiment undersöka hypotesens giltighet. Hypotesen i det här projektet: ”Är det

(27)

4.5 Val av metod

I det här projektet krävs en litteraturstudie för att ta fram fundamentala delar som bygger upp problemställningen. Genom att belysa detta med en litteraturstudie kan begrepp och resonemang kopplas till den underliggande informationen. Material för att genomföra en litteraturstudie finns dokumenterade i form av böcker, artiklar och manualer, vilket ger stöd åt att genomföra en litteraturstudie. Problemformuleringen innehåller en hypotes. Att undersöka om problemet är genomförbart är en central del, detta görs lämpligen med litteraturstudier och implementation.

I en förstudie till projektets genomförandedel behövs en litteraturstudie som behandlar parsern och aggregattabeller. Anledningen till att en litteraturstudie behövs är att utreda vilka möjliga lösningsvarianter som finns på problemet. I förstudien väljs den mest lämpliga varianten för att lösa problemet.

I projektets genomförandedel dvs. efter det att en lösningsmetod valts implementeras den valda lösningsmetoden. Detta för att kunna verifiera hypotesen.

Figur 12 Hypotesprövande projekt

Det är viktigt att implementationen har ett tydligt syfte. Syftet med implementationen av en parser är att visa att det är genomförbart utifrån de givna kriterierna. En implementation har nackdelar som att det kan iföras buggar i den, vilka kan påverka resultatet. Det är en svårt att garantera att resultatet inte beror på buggar, eftersom det är människan bakom implementationen och tester av implementationen som ska garantera korrektheten.

Literaturstudie Lösningsmetod

Implementation Genomförande Hypotesprövande projekt

(28)

5 Lösningsmetod

För att på ett transparent sätt kunna utnyttja aggregattabeller krävs någon form av applikation (Parser) som kan sköta hanteringen av manipulering och sökning i dessa tabeller. Innehållet i aggregattabellerna är oftast hämtat från data ur databasens befintliga tabeller, med hjälp av någon form av logik. Det gör det möjligt att för dessa fall skapa en parser som kan utöka hanteringen, från att göra manipuleringar i databasens ”vanliga” tabeller, till att också gälla att manipulera de aggregattabeller som är associerade till dessa tabeller. Även för att på ett transparent sätt kunna utnyttja aggregattabellerna vid sökning av information i databasen behövs en parser. Denna ska kunna dirigera om frågor mot bastabeller till aggregattabeller, när detta är möjligt.

En parser som kan hantera aggregattabeller kan konstrueras på olika sätt. Parsern kan placeras i databasen som en lagrad procedur, där den är fristående från andra applikationer. Den kan skapas i klienten, fristående från DBMS, eller som en preprocessor, fristående från databasen och klienten. Eller som ett mellanlager med logik i både klienten och DBMS. De olika lösningsmetoderna beskrivs i kapitel 5.1 till 5.4 med sina för och nackdelar.

5.1 Lagrad procedur i servern

Parsern kan implementeras som en lagrad procedur (eng. stored procedure) i databasservern. En lagrad procedur är enligt Date (1994) ett förkompilerat program som lagras på serversidan i ett klientserversystem. En lagrad procedur anropas av klienten med ett så kallat ”remote procedure call” (RPC).

Figur 13 Stored procedure

Genom att proceduren utför arbetet på servern kan de prestandaförluster minskas, som normalt uppstår när stora databasmängder hanteras av klienten. Förutom prestandavinster anger Date (1994) följande fördelar med en lagrad procedur:

• En lagrad procedur kan användas av flera klienter.

• Optimering kan göras när proceduren skapas, istället för under exekveringstiden. (Detta gäller för interpreterande system)

• En lagrad procedur kan öka säkerheten. T ex. genom att en användare kan ha rättighet att exekvera en viss procedur, men inte att göra operationer direkt på data som proceduren gör operationer på.

• En lagrad procedur kan användas för att dölja detaljerad information för användarna i ett system och därigenom det öka graden av dataoberoende.

En stor fördel med att implementera parsern som en lagrad procedur är att den kan hantera dynamisk SQL. Hantering av dynamisk SQL är en förutsättning för att lösningen ska vara genomförbar. Nackdelen med att denna lösning är att inte alla DBMS kan hantera dynamisk

Applikation

Lagrad Procedur DB-server

(29)

5 Lösningsmetod

C kod

exec sql select count (*) into :värd_variabel from lager;

C kod

SQL. Nätverkstrafiken kan minskas genom att exekveringen av proceduren utförs på databasservern. Däremot tar proceduren CPU-tid ifrån servern när den exekverar.

5.2 Preprocessor

Parsern kan implementeras som en preprocessor. En preprocessor är ett verktyg som utför en förbehandling av programmet innan kompilatorn analyserar det. En preprocessor kan ses som en förkompilator. Rent tekniskt kan preprocessorn och kompilatorn vara integrerade men logiskt sätt är de två skilda steg i kompileringen (Eriksson, 1996). Preprocessorns uppgift kan vara att inkludera filer, utföra villkorlig kompilering samt expansion av makron (Eriksson, 1996).

En preprocessor kan används för att kunna hantera inbyggd SQL, där SQL-satser byggs in i ett värdspråk, som t ex C. I C börjar SQL-satsen med kommandot exec sql. En sådan sats kan innehålla flera rader SQL-kod. I exemplet nedan visas en inbyggd SQL-sats i C-kod.

Exempel:

Preprocessorn skiljer ut DML kommandon från ett applikationsprogram som är skrivet i ett värdspråk, som t.ex. C. DML kommandona skickas till DML kompilatorn, där de kompileras till objektkod för databasaccessen. Resten av programmet skickas till en kompilator för värdspråket, t.ex. en C-kompilator. Objektkoden för DML kommandona och resten av programmet länkas samman i en transaktion. Dess körbara kod innehåller anrop till ”run-time” databasprocessorn (Elmasri och Navathe, 2000). DBMS interagerar med operativsystemet för att kunna få access till disken, som när den behöver access till databasen eller data dictionary.

Till exempel i Oracle är en preprocessor ett programmeringsverktyg som tillåter inbyggda SQL-satser i källprogrammets källkod (Elmasri och Navathe, 2000). Preprocessorn kan ta emot källprogrammet och översätta de inbyggda SQL-satserna till programanrop för Oracle, och sedan generera ett modifierat källprogram som kan kompileras, länkas och exekveras (Elmasri och Navathe, 2000). Genom att t ex använda PRO*C kan ett automatiskt stöd för konvertering mellan Oracle och C’s dataspråk användas. Både SQL- och PL/SQL-satser kan byggas in i ett värdspråk som C. Genom detta kombineras styrkan i C och fördelarna med att använda SQL för access till databasen.

Genom att implementera parsern som en preprocessor behövs inte klientapplikationens kod förändras, men det kräver att all SQL-kod, som ska utnyttja aggregattabeller, ligger i klientapplikationen. Detta eftersom preprocessorn måste placeras mellan klientapplikationen och dess kompilator. För att lagrade procedurer och triggers ska kunna använda aggregattabellerna på samma generella sätt krävs att det ligger en motsvarande parser i databasen.

(30)

5 Lösningsmetod

Figur 14 Del av DBMS med preprocessorn

Det största problemet med att implementera en parser som en preprocessor är att en preprocessor inte kan hantera dynamiska SQLfrågor, dvs. frågor som inte är kända vid kompileringstillfället, t ex frågor som användaren formulerat själv. Detta beror på att preprocessorn måste veta exakt vilka frågor som ska utnyttja aggregattabellerna, eftersom preprocessorn enbart kan göra en substitution av den ursprungliga frågan till en redan fördefinierad fråga. Substitutionen sker 1-1 dvs. för varje klientfråga som ska utnyttja aggregattabeller så finns en motsvarande fråga i preprocessorn. Detta gäller under de omständigheter då preprocessorn inte har kommunikation med databasens data dictionary. Problemet med att upprätthålla kommunikation med data dictionary ligger i ökad nätverkstrafik, vilket ger minskad prestanda. Vid replikering av data dictionary till varje klient måste varje klient försäkra sig om att informationen i kopiorna är konsistent.

När nya aggregattabeller skapas eller gamla modifieras måste preprocessorn modifieras och kompileras om. Målet med parsern är att den här typen av problem ska kunna hanteras, vilket gör lösningen med en preprocessor utan kommunikation med data dictionary mindre bra.

Preprocessor Applikation Data Dictionary Lagrad Databas DMLkompilator Rune-time databas processor DMLsatser Kompilerade transaktioner Värdspråkets kompilator

(31)

5 Lösningsmetod

5.3 Mellanlager

I datorvärlden är mellanlager den generella termen för någon form av programmering som syftar till att ”sammanfoga”, agera mellan, eller förbättra två redan existerande program. En vanlig mellanlagerapplikation göra det möjligt för ett program som är skrivet för access till en specifik databas, att även kunna få access till andra databaser.

I ett klientserversystem finns ofta mellanlager (eng. middleware), det är en mjukvarukomponent som placeras mellan klienten och servern. Ett mellanlager kan bestå av olika delar, såsom nätverksoperativsystem, liksom även specialiserade applikationsdelar som ger stöd åt databasspecifika applikationer, ORB standard (eng. object-request broker), fleranvändareteknologier, kommunikationshantering, och andra klientserverkomponenter.

Figur 15 Mellanlager

ODBC (Open Database Connectivity) drivrutiner kan ses som ett exempel på mellanlager. ODBC drivrutiner kan skrivas om för specifika ändamål, som detta.

Fördelen med ett mellanlager är att de är enkla att byta ut, de är inte beroende av vare sig klienten eller servern, i den bemärkelse att ingen logik ska behövas läggas till i dessa komponenter. Däremot är ofta mellanlagerkonstruktioner av den här typen stora och komplexa.

5.4 Val av lösningsmetod

I den här rapporten väljs som lösningsmetod, att implementera parsern som en lagrad procedur. Skillnaderna mellan de olika lösningsmetoderna är framför allt var parsern placeras, i klienten, servern, eller mellan dessa två. Alla lösningsmetoder har fördelar och nackdelar. Det främsta kriteriet för valet är att parsern ska kunna hantera frågor som inte är bestämda på förhand. För att den valda lösningsmetoden ska vara flexibel krävs att lösningsmetoden kan hantera dynamisk SQL. En preprocessor kan inte hantera detta. Att skapa ett mellanlager som lösning kan ge en mycket komplex implementation av parsern.

(32)

6 Genomförande

6.1 Skapa aggregattabeller

Det enda absolut nödvändiga kravet för att skapa en aggregattabell är att den skapas utifrån underliggande atomär data (Kimball, 1998). Det finns flera olika tillvägagångssätt för att skapa aggregattabeller:

1. Att bygga aggregattabeller utanför DBMS genom att sortera den detaljerade inkommande data och beräkna brytrader. Där en brytrad är ett aggregat. Aggregattabellerna existerar utanför DBMS före laddningssteget och de kan lagras separat tillsammans med basdata. 2. Att skapa aggregattabeller under en tidsperiod i DBMS, vilket görs genom att

ackumulativt addera inkommande data till en lagringsplats i DBMS.

3. Aggregattabeller byggs automatiska som en del av laddningsprocessen i ett datalager. Det kan ses som en kombination av de två tidigare teknikerna, fast att fysiska aggregattabeller inte existerar utanför DBMS.

4. Att skapa aggregattabeller i DBMS och att använda SQL efter laddningen av detaljerad data till databasen.

Att bygga aggregattabeller inom DBMS kan vara ineffektivt av två anledningar. För det första, det är nödvändigt att utföra en sorteringsoperation. Att sortera med hjälp av en sorteringsalgoritm kan vara mycket snabbt utanför databasen, jämfört med att sortera data i DBMS med hjälp av ”order by” operationen i SQL. För det andra, är det kritiskt att låsa upp en ersättningsnyckel när aggregatet skapas. Logiken för att utföra denna operation är relativt enkel men det är inte en relationsprocess utan en sekventiell process. För att undvika de här problemen anser Kimball (1998) att de flesta typer av aggregat ska lagras utanför DBMS, med en sorterings algoritm och procedurell programmering.

För att exemplifiera skapandet av aggregattabeller ges ett exempel för ett företag med flera försäljnings butiker lokaliserade i olika regioner. Företaget säljer ett antal produkter vilka är indelade i olika kategorier. Företaget vill skapa aggregattabeller för den totala försäljningen för varje produkt kategori. I dagsläget lagras data kategoriserad på försäljningen för en produkt per dag. Aggregat som kan skapas är:

• Kategori för butik och dag.

• Kategori för region och dag.

• Kategori för butik och månad.

• Kategori för region och månad.

• Osv.

De två första aggregattabellerna kan skapas för varje dag utifrån den dagliga produkt försäljningen. De senare två kan skapas utifrån de två tidigare aggregaten. Varje gång ett nytt aggregat skapas, t ex en ny total för en butik under en dag, måste en nyckel skapas till aggregatet.

Som en tumregel anser Kimball (1998) att i ett datalager bör det vara lika stor del aggregat som lagrad basdata. Anledningen är att för lite och för mycket aggregat ger försämrad prestanda för användaren, där för lite är under 25 % av basdata och för mycket är flera gånger så mycket som basdata. Det är av vikt att tänka på vilken nivå som aggregat ska existera på, t.ex. produktnivå, delkategorinivå eller kategorinivå. Vilken nivå som är lämplig beror på hur