med relationsdatabas (HS-IDA-EA-99-104)
Yvonne Brohede (a94yvobr@ida.his.se) Institutionen för datavetenskap
Högskolan i Skövde, Box 408 S-54128 Skövde, SWEDEN
Examensarbete på programmet för systemprogrammering under vårterminen 1999.
Handledare: Henrik Gustavsson
Designstruktur för komponentbaserad applikation med relationsdatabas Examensrapport inlämnad av Yvonne Brohede till Högskolan i Skövde, för Kandidatexamen (B.Sc.) vid Institutionen för Datavetenskap.
1999-06-07
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.
Signerat: _______________________________________________
Yvonne Brohede (a94yvobr@ida.his.se)
Nyckelord: Designstruktur, Komponentbaserad utveckling, Objektorientering, Återanvändning, Traditionell relationsdatabas, UML
Sammanfattning
Det blir allt mer vanligt förekommande att utvecklingen av applikationer sker enligt
objektorienterade metoder, ofta som komponentbaserade applikationer. Samtidigt är
användandet av traditionella relationsdatabaser fortfarande mycket utbrett. En
kombination av komponentbaserad applikation och traditionell relationsdatabas har
idag blivit vanlig. Här beskrivs en designstruktur som visar hur beteendet, vilket inte
kan lagras i relationsdatabasen, bör tas om hand för att möjliggöra delad åtkomst samt
återanvändning av programkoden. Beteendet implementeras som applikationens
programkod i form av regler, beräkningar och operationer. Det har tagits i beaktning
både hur uppdelningen av olika typer av beteende kan göras och var i systemet det bör
implementeras, för att uppnå en generell lösning. För att underlätta framtagandet av
applikationer med den framtagna designstrukturen, beskrivs de olika arbetsmoment
som ingår. I lösningen används ett mellanlager med transaktionshanterare samt
resurshanterare. Resultatet visar att designstrukturen fungerar för alla möjliga
grundläggande konstruktioner som används i den beskrivna tekniken.
Innehållsförteckning
1 Introduktion... 1
2 Bakgrund ... 2
2.1 Delning av programkod...2
2.1.1 Komponentbaserad utveckling (KBU) ...3
2.1.2 Analys och design för utveckling av uppdelade applikationer ...4
2.2 Klient-server ...4
2.3 Databassystem ...5
2.3.1 Databas ...6
2.3.2 Relationsdatabas...7
2.3.3 Affärsregler ...8
2.3.4 Skillnader mellan traditionell och utökad relationsdatabas ...9
2.4 Databassystemets logiska arkitektur ...10
2.5 Databashanteringssystem...10
2.5.1 Lagrade procedurer ...11
2.5.2 Triggers...12
2.6 Standardiserade gränssnitt ...12
2.6.1 ODBC ...12
2.6.2 CORBA ...13
2.6.3 COM/DCOM ...13
2.7 Verktygsstöd...13
2.8 Relaterat arbete...14
3 Problembeskrivning ... 15
3.1 Motivering och definition av problemet ...16
3.2 Förväntat resultat ...16
3.3 Avgränsning...17
4 Metod ... 18
4.1 Lösningsalternativ ...18
4.1.1 Processervice direkt på klienten ...18
4.1.2 Processervice i databasen...20
4.1.3 Ett mellanlager för processervice ...21
4.1.4 Uppdelning av processervice på mellanlager och databas...23
4.2 Kriterier vid utvärdering av lösningsalternativ...24
4.2.1 Komplexitet...25
4.2.3 Flexibilitet ...25
4.2.4 Tillgänglighet...25
4.2.5 Återanvändning ...26
4.2.6 Skalbarhet ...26
4.3 Utvärdering av lösningsalternativ...26
4.3.1 Processervice direkt på klienten ...26
4.3.2 Processervice i databasen...27
4.3.3 Ett mellanlager för processervice ...27
4.3.4 Uppdelning av processervice på klient, mellanlager och databas ...27
Val av lösningsalternativ...28
5 Genomförande ... 29
5.1 Exempelsystem ...29
5.2 Verktygsval...29
5.2.1 Kort beskrivning av funktionalitet i MTS som används i exemplet ...30
5.3 Översiktlig beskrivning av analysfasen...31
5.4 Övergripande designstruktur ...33
5.4.1 Transformering från objektmodell till tabeller i databasen...35
5.4.2 Ta hand om beteendet som arbetar direkt mot tabellerna i databasen ...38
5.4.3 Ta hand om övrigt beteende...40
5.5 Implementationsfasen...44
5.6 Designstruktur med beskrivning av arbetsmoment ...46
5.7 Implementation och test ...48
6 Slutsats ... 49
6.1 Resultat...49
6.2 Diskussion ...50
6.3 Fortsatt arbete...51
6.4 Sammanfattning vetenskaplig metod...52
Referenser ... 54
Introduktion
1 Introduktion
Människan har alltid samlat på data av olika slag. I dagens samhälle har möjligheten och behovet att lagra allt större mängder av data på liten yta ökat. Detta ställer också ökade krav på tekniken. Det är dessutom angeläget att lagra data på ett strukturerat sätt, dels för att effektivt kunna komma åt att nyttja den data som behövs, dels för att lagringsutrymmet inte ska bli onödigt stort. Vid lagring av data är databaser en vanlig lagringsform. En databas kännetecknas allmänt av att den är en samling av relaterad data. Med data avses känt fakta som kan registreras och har implicit mening (Elmasri 1994). För att undvika onödig dubbellagring av data är det viktigt att möjliggöra för olika applikationer att få access till samma databas. På samma sätt är det viktigt att programkod som kan användas av olika applikationer inom ett system kan delas. Det är också viktigt att möjliggöra för en applikation att få access till flera olika databaser.
Det har utvecklats olika metoder för att överföra modeller av verkligheten (hos t ex verksamheter) till databassystem för att lagras på ett förståbart och verklighetsnära sätt. Två av dessa sätt är relationsdatamodellen och objektdatamodellen.
Objektdatamodellen ger en verklighetsnära och lättförståelig bild av verkligheten, genom att bland annat beskriva de händelser som sker, som så kallade Use Case diagram. Den ger också stöd för återanvändning av redan skriven kod. De objektorienterade databaserna har dock inte kunnat uppfylla de effektivitets- och stabilitetskrav som marknaden ställt på dem (Rumbaugh 1991). De har också varit mycket resurskrävande. Relationsdatamodellen ger en något sämre möjlighet att beskriva verkligheten på ett lättförståeligt sätt. Återanvändning dvs, delad åtkomst av kod befrämjas inte heller, förutom i själva tabellerna. Relationsdatabasen är däremot mycket stabil och användandet av relationsdatabaser är mycket utbrett.
En kombination mellan objektorienterad applikation samt lagring i relationsdatabas skulle därmed kunna vara en lösning. Problemet uppstår vid “skarven” mellan de båda tänkesätten. Att ta tillvara objekttänkandet med återanvändning och kopplingen till de handlingar som utförs i systemet, kräver att affärslogiken, dvs de operationer samt olika regler som beskrivs i systemet, tas om hand och paketeras på ett bra sätt. Det enda som kan lagras i en traditionell relationsdatabas och som också är det enda som kan erbjuda delad åtkomst och återanvändning i relationsorienterade system är datan och de implicita regler som lagrats för tabellerna i databasen.
Att finna en designstruktur för lagring av affärslogiken (beteendet), vid en kombination
mellan objektorienterad applikation och relationsorienterad databas är huvudsyftet med
detta arbete. Avsikten är att därmed stödja delad åtkomst och återanvändning även av
affärslogiken. Även en arbetsmetod som visar de olika stegen för att uppnå denna
designstruktur är önskvärd. Detta arbete kommer härmed att resultera i en metod
innehållande både en designstruktur och de arbetsmoment som behövs för att uppnå
denna.
2 Bakgrund
För många år sedan var alla applikationer specialanpassade och de personer som utvecklade dem var de som hade den övergripande kontrollen över t ex kostnad och kvalité. Idag har detta ändrats och mjukvarubranchen är ett extremt konkurrensutsatt område. Kostnad och kvalité är den huvudsakliga drivkraften för den intensiva konkurrensen (Pressman 1997). Ett sätt att uppnå dessa konkurrensfördelar är att använda sig av komponentbaserad mjukvaruutveckling.
2.1 Delning av programkod
Några av de grundläggande anledningar som gör det angeläget att överväga att dela upp applikationer i moduler eller komponenter är underhåll och delning (Pressman 1997):
• Underhåll. Applikationer som ska fungera i ett system under många år kommer under denna tid att behöva revideras, anpassas och korrigeras många gånger. Detta kan ge oväntade och allvarliga sideoffekter varje gång en förändring sker. Om applikationen då är modul- eller komponentuppdelad på ett bra sätt, förenklar det uppdateringen genom att endast den modul/komponent som förändringen berör modifieras. Övrig kod påverkas då inte. Kvalitén på applikationen blir därmed högre och tiden som går åt för modifieringen blir avsevärt kortare.
• Delning. Applikationer inom ett system använder sig ofta till en viss del av samma kod, till exempel vissa affärsregler. För att inte ”uppfinna hjulet igen” bör därför den kod som redan utvecklats kunna återanvändas. Detta föranleder att det görs en uppdelning av programkoden och en lagring av densamma på ett sådant sätt, att återanvändning möjliggörs. En schematisk bild över programdelning visas i figur 1.
Applikat ion 1 Applikat ion 2 Applikat ion n
Den grå skuggade delen av applikationen består av kod som är lika i alla applikationerna
Applikat ion 1 Applikat ion 2 Applikat ion n
Den grå delen är den gemensamma koden som skrivs en gång. Alla applikationer kan nyttja koden gemensamt.
Figur 1 Delning av programkod
Bakgrund
Modularitet är således en viktig aspekt när ett komplext system ska utvecklas och förenklar utvecklingsarbetet om den används på ett korrekt sätt. Det är mot bakgrund av detta som komponentbaserad utveckling (KBU) numera har blivit den allt mer dominerande modellen för mjukvaruutveckling (Spitser 1997).
Begreppen modul och komponent används båda i den litteratur som berör uppdelning av applikationer och mjukvarans arkitektur. Det föranleder en viss begreppsförvirring varför en definition av begreppen behövs, med klargörande av hur de fortsättningsvis används i detta arbete.
En komponent är en del av en enhet och en modul är benämning på vissa standardiserade (måttbestämda) enheter (Bonniers Svenska Ordbok 1991). Pressman (1997) definierar begreppen på liknande sätt. Moduler beskrivs som komponenter av en mjukvara vilka är separata, namngivna och adresserbara. En något annorlunda preciserad definition, men likafullt med samma innebörd, ges i Dictionary of computing (1990). Där definieras en modul som en komponent av hanterbar storlek med ett väl definierat gränssnitt mot resten av världen.
Modul är således ett mer specialiserat begrepp, även om en modul och en komponent båda är väl avgränsade delar av ett större sammanhang. Fortsättningsvis kommer begreppet komponent genomgående att användas som uttryck för både modul och komponent.
2.1.1 Komponentbaserad utveckling (KBU)
Avsikten med KBU är att leverera lösningar som består av köpta eller egentillverkade komponenter som interagerar. Lösningen kan liknas vid självständiga delar (komponenter) som lagrats i samma lagringsutrymme. Ett objekt är inte samma sak som en komponent, även om många komponenter implementeras som objekt. En komponent paketerar programfunktionaliteten på ett sådant sätt att komponentens tjänster kan upptäckas i det gemensamma lagringsutrymmet under den sammansättande fasen och exekverings fasen. Ett objekt däremot måste kompilera den lagrade källkoden och länkas till en specifik applikation för att dess allmänt tillgängliga tjänster ska kunna utnyttjas av applikationen (Spitzer 1997).
En komponents förmåga att interagera är ett resultat av dess samstämmighet och anpassningsförmåga till en gemensam infrastruktur för mjukvara. Denna infrastruktur definierar en mekanism för speciella paket av funktioner, för samarbetet inuti ett gemensam lagringsutrymme. Uttrycket gemensam infrastruktur refererar till en vida accepterad komponentarkitektur som många utvecklare har accepterat som bas för KBU. Som exempel kan nämnas Microsofts arkitektur AktivX/COM och Java Softs JavaBeans. Det finns dock ingen vida accepterad standardbaserad komponentarkitektur. CORBA är den enda standardbaserade arkitekturen för objektinteraktion, men dess tillgänglighet har ännu inte lett till storskalig utveckling av CORBA-kompatibla komponenter (Spitzer 1997).
Några av KBUs föregångare är utvecklingsbibliotek och objektorienterad
programmering. KBU kommer troligen att bli ett mer accepterat och bestående
paradigm än de genom att nackdelen med kompilering och länkning till specifik
applikation undvikits. De två faktorer som tillsammans fört fram KBU till dess vida
spridda acceptans är Internet och mognaden i utvecklingen av AktivX/COMs
infrastruktur. En omfattande acceptans av AktivX/COM, som länge har förespråkat
KBU, har startat en omfattande tredjehands komponentindustri. Detta förstärker
ytterligare utvecklingen av KBU (Spitzer 1997).
2.1.2 Analys och design för utveckling av uppdelade applikationer
Vid utveckling av komponentuppdelade applikationer kan de metodsteg som finns beskrivna i litteraturen för objektorienterad analys och design följas. Den notation som idag framstår som standard vid denna modellering är Unified Modeling Language (UML) vilken är en kompromiss mellan Jacobssons, Rumbaughs och Boochs notationer (Gottesdiener 1997).
Det finns generella metodbeskrivningar för både analys och design. UMLs Use Case diagram är ett sätt att konkret kunna återge verkligheten i modellen i analysfasen (Gottesdiener 1997). Ett annat sätt är enligt Object Modeling technique (OMT) där objekt analyseras fram direkt från kravspecifikationen. Designfasen beskrivs enligt OMT i åtta generella metodsteg (Rumbaugh 1991):
1. De olika modeller som framtagits i analysen kombineras till en. Objektmodellen med sin datastruktur och relationer, Dynamiska modellen med beskrivning av tillstånd och transaktioner samt Funktionella modellen där operationer, dataflöde och beroenden beskrivs.
2. Algoritmer designas. Detta görs med hänsyn till bland annat implementationskostnad, datastruktur, nya interna klasser och operationer. Varje operation tilldelas en klass.
3. Optimering genomförs. detta genomförs på ett sådant sätt att balansen mellan effektivitet och läsbarhet upprätthålls. Exempel på optimering är att ändra beräkningsordning eller lägga till redundanta associationer.
4. Kontrollflöde implementeras. Detta flöde kan vara procedurellt, händelsestyrt eller parallellt.
5. Generaliseringar och arv justeras. Här ses klasshierarkin över och det kontrolleras att de arv som tillåts är semantiskt korrekta.
6. Associationer designas. Här avgörs det hur varje association ska implementeras.
Exempelvis kan en association implementeras som en pekare om den traverseras i en riktning och har kardinalitet ett.
7. Representation definieras. Detta innebär exempelvis att designern avgör när primitiva datatyper ska användas i ett objekt eller om en grupp av relaterade objekt ska kombineras.
8. Fysisk paketering av implementationen utförs. Detta inbegriper döljande av information från utsidan sett, begränsning av omfånget för en metod och definition av väl avgränsade komponenter.
2.2 Klient-server
Termen klient-server har en mängd olika betydelser. Den traditionella klient- serverdefinitionen beskriver hur en klient utför en förfrågan och hur en eller flera servrar försöker besvara dess förfrågan. Meddelandehanteringen som är bunden till denna aktivitet kräver nätverksresurser. Klient-server är alltså en variant av distribuerat system (Cashin 1997).
Idén med klient-servertekniken består i att urskilja specifika servrar med specifik
funktionalitet, t ex filserver som hanterar filerna åt klientens användare eller i
Bakgrund
databassystem, databasserver där data lagras och behandlas. Även specialiserad mjukvara kan på liknande sätt placeras på en specifik server. Genom att på detta sätt dela upp systemet i två nivåer minskas komplexiteten och de resurser som tillhandahålls från de specialiserade servrarna kan användas av många klienter (Elmasri 1994).
Klient
Klienten har initiativet och skickar en begäran om tjänst till servern
servern utför tjänsten och returnerar resultatet presentationslogi
k
Server
funktionslogik data
Figur 2 Förenklad schematisk bild på klient-server och dess inbördes funktion (efter Cashin, 1997, sid 66)
Den vanligaste arkitekturen i ett klient-serversystem är att många klienter delar på en eller ett fåtal servrar. Det förekommer dock även andra arkitekturer. En maskin kan till exempel vara både klient och server, eller en klient behöver tillgång till många servrar.
2.3 Databassystem
En vanlig typ av klient-serversystem är ett databassystem, där enligt den traditionella uppdelningen, DBHS finns på servern och applikationerna på klienten. Generellt sett är databassystem ett datoriserat system vars främsta syfte består i att bevara dokumenterad information (data) och göra den tillgänglig vid behov. Databassystem består av fyra huvudkomponenter (Date 1995): hårdvara, användare, mjukvara samt data.
Hårdvararudelarna av systemet består av:
• Sekundärminne, till exempel hårddisk som innehåller den lagrade datan, samt anslutna I/O enheter.
• En eller flera processorer och anslutna huvudminnen som används för att ge stöd vid mjukvarans exekvering i systemet.
Det finns tre större grupper av användare:
• Applikationsprogrammerare, vilka ansvarar för att skriva de program som använder sig av databasen. Här avses både bakgrundsapplikationer och användargränssnitt, de så kallade klientapplikationerna, som avser att ge slutanvändaren stöd vid åtkomst av databasen.
• Slutanvändare, som är den som interagerar med systemet från arbetsstation (PC) eller terminal.
• Databasadministratör (DBA), är den som skapar aktuell databas och är även den som skapar de tekniska kontroller som ger den dess förväntade policy. Underhåll av systemet samt tillhandahållande av relaterad teknisk service ingår också.
Mellan den fysiska databasen och de som använder systemet finns ett lager av mjukvara, ett databashanteringssystem (DBHS), vars generella funktion är att kapsla in hårdvarudetaljer så att slutanvändaren får en bild av databasen från en så kallad högnivåvy (Date 1995). Mjukvaran spelar idag dubbla roller. Den är en produkt samtidigt som den är ett verktyg för att leverera en produkt (Pressman 1997).
Data är fakta som kan dokumenteras och som har en inneboende mening. I databassammanhang är det vanligt att tala om varaktig (eng. persistent) data, även om den inte existerar särskilt länge. Det som är avsikten med detta är att skilja den från mer flyktig data som indata och utdata, kontrollvillkor, delresultat mm. Det är den varaktiga datan som lagras i databasen.
2.3.1 Databas
En databas är ett stort lager med data, vilket definieras en gång och kan användas samtidigt av många olika användare (Connolly 1996). Enligt Date (1995), består en databas av en samling varaktiga data som används av applikationer i ett givet system.
Elmasri (1994, sid 2), ger en lite mer specifik beskrivning av vad som avses med en databas och det är denna definition som kommer att ligga till grund för begreppet databas i detta arbete:
• Databasen representerar en aspekt av den reella världen, en minivärld. Förändringar i denna minivärld reflekteras i databasen.
• Den är en samling logiskt sammanhållen data, vilkens betydelse är inbördes relaterad.
• Databasen är skapad utifrån ett speciellt syfte och innehåller specifik data för detta syfte. Den har användare som är aktivt intresserade av dess innehåll. Det finns i förväg skapade applikationer som användare kan nyttja för att hämta data.
Uttrycket logiskt sammanhållen data förutsätter att det skett en analys av informationsbehovet och att identifiering av entitet, attribut och samband gjorts. En entitet är ett distinkt objekt, t ex en person, en plats, ett koncept eller en händelse som ska representeras i databasen. Attribut är egenskaper som beskriver aspekter av det distinkta objektet vi önskar dokumentera. Sambandet beskriver den logiska samhörigheten mellan olika entiteter (Connolly 1996).
Databaser kan vara av mycket varierande storlek och komplexitet. En grundläggande orsak för att använda databassystem för lagring av data är dataoberoende.
Dataoberoende kan definieras som en applikations immunitet vid förändring i
lagringsstruktur och åtkomstteknik (Date 1995).
Bakgrund
Andra fördelar med att lagra data i databaser härrör sig utifrån idén med centralt kontrollerad data (Date 1995):
• Onödig dubbellagring av data kan minskas
• Inkonsistens kan till viss del undvikas
• Data kan delas
• Det kan övervakas att standard följs
• Säkerhetsrestriktioner kan tillämpas
• Integriteten kan upprätthållas
• Krav som står i konflikt till varandra kan balanseras
Då en databas ska definieras specificeras datatyper, struktur och constraints, dvs regler för data som ska lagras. Konstruerandet av databasen sker när den definierade metadatan lagras i ett lagringsutrymme som kan kontrolleras av DBHS. Metadata kallas också för databasschema och är data om data. Manipulering av en databas görs med hjälp av funktioner som t ex ställer frågor till databasen för att få specifik data eller uppdatering för att reflektera förändringar i minivärlden (Elmasri 1994).
2.3.2 Relationsdatabas
Relationsdatabasen (RDB) bygger på relationsmodellen som ursprungligen utformades av E. F. Codd, 1969-70 (Codd 1970). Den är ett specifikt sätt att representera data och har specificerat hur manipulation av denna data ska utföras.
Relationsmodellen berörs av tre aspekter av data (Date 1995):
• Datastruktur
• Dataintegritet
• Datamanipulation
Den första aspekten, datastruktur, visar att innehållet i en traditionell relationsdatabas presenteras på endast ett sätt, nämligen som explicita datavärden. Den är vid presentationen till användaren strukturerad i tabellform. Tabellen består av rader, sk tuppler samt kolumner. Alla datavärden är atomära, dvs varje unik kombination av rad och kolumn, innehåller endast ett datavärde och inte en grupp med flera värden. Detta innebär att den sk första normalformen (1NF) följs. Tabellen är den logiska strukturen men inte den fysiska. På den fysiska nivån kan den lagringsstruktur som förefaller lämpligast användas, t ex indexering, hashing, länkade listor eller sekventiella filer. Det som krävs är att det går att översätta dessa strukturer till tabeller på den logiska nivån (Date 1995).
Dataintegritet kopplas till ett flertal integritetsregler, vilka måste följas för att uppfylla reglerna för relationsmodellen. Avsikten är att bland annat förhindra onödig dubbellagring samt hålla data i databasen konsistent. Integritetsregler för relationsdatabas är domain constraints, key constraints, entity integrity constraints och referential integrity constraints. Andra typer av constraints kallas databeroende och används främst för databasens design genom normalisering (Elmasri 1994).
• Domain constraints specificerar att värdet för varje attribut måste vara atomiskt.
• Key constraints innebär att två tuppler i en tabell inte kan ha identisk kombination
av attribut. Ett nyckelvärde kan användas för att unikt identifiera en tuppel i en tabell. Det kan finnas flera olika attribut som var för sig pekar ut en specifik tuppel, så kallade kandidatnycklar. Då väljs en av kandidatnycklarna godtyckligt ut till primärnyckel, dvs den som används för att identifiera tupplerna i tabellen.
• Entity integrity constraints specificeras för individuella tabeller och föreskriver att inget primärnyckelvärde kan vara null. Om en primärnyckel skulle tillåtas ha ett nullvärde skulle det innebära att det värde saknas som används för att identifiera unika tuppler i en tabell.
• Referential integrity constraints uppstår utifrån de relationer mellan entiteter som representeras i metadata. För att kunna specificera regler måste det finnas en klar bild av hur mängden av attribut i de olika tabellerna förhåller sig till varandra.
Referensregler specificeras mellan två tabeller och avser att se till att data är konsistent mellan tupplerna i de två tabellerna. Den föreskriver att en tuppel endast kan referera till en existerande tuppel.
För att relatera ett samband mellan attribut i olika tuppler och tabeller används en främmande nyckel. En främmande nyckel kan även visa ett samband mellan attribut i den egna tabellen.
Det finns två regler som gäller för en främmande nyckel (Elmasri 1994):
1. Attributen i den främmande nyckeln ska ha samma domän som de attribut i primärnyckeln hos den tabell som relateras till.
2. Värdet på den främmande nyckeln i en tuppel i tabellen har antingen samma värde som primärnyckeln har i den tabell den refererar till, eller också värdet null.
Ursprungligen ingår inte en allmän klass med så kallade semantiska integritetsregler i en relationsdatabas. Ett exempel på en semantisk integritetsregel är: maximalt antal timmar en arbetare får arbeta på samtliga projekt, sammantaget under en vecka, är 56 timmar. Det utvecklas dock mekanismer för att specificera och övervaka även denna typ av restriktioner.
Den manipulativa aspekten består av olika operatorer vilka i relationsmodellen kan kategoriseras som hämtande eller uppdaterande (Elmasri 1994). Det finns tre basoperatorer för uppdatering: Insert, Delete och Modify. Insert för att lägga till en ny tuppel, Delete för att ta bort tuppler och Modify för att förändra värdet på något av attributen.
Den hämtande kategorin av operatorer använder sig av relationsalgebra, och kan i sin tur delas upp i två grupper. Den ena gruppen innehåller operatorer specifikt framtagna för relationsdatabas: Selektion, Projektion och Join. Den andra gruppen är mängdoperatorer från matematisk mängdlära: Union, Snitt, Differens och Kartesisk produkt (Elmasri 1994).
2.3.3 Affärsregler
Integritetsregler styr databasens minivärld och kallas även för affärsregler. Det finns tre huvudsakliga tekniker, genom vilka affärsregler kan bli specificerade i ett databassystem. Dessa tre tekniker är fördefinierade, implicita och explicita regler (Elmasri 1994).
Varje datamodell har en mängd av inbyggda regler associerade med konstruktionen av
datamodellen. Dessa kallas för fördefinierade regler (eng. inherent) för datamodellen.
Bakgrund
De fördefinierade egenskaperna behöver inte specificeras av data definition language (DDL) när metadata definieras. Fördefinierade regler är således regler som definierar datamodellens uppbyggnad.
Implicita regler är de regler som definieras och lagras av DDL i metadata för att kunna övervakas av DBHS. Dessa indirekta eller underförstådda regler uppstår genom de olika specifikationer som beskriver de olika entitetstyperna attributen och relationerna.
Som exempel på en indirekt regel kan nämnas att då det definieras att ett attribut är en primärnyckel, skapas den underförstådda regeln att det attributet inte får anta nullvärde.
Eftersom ingen datamodell kan specificera alla typer av regler som kan behövas i en minivärld är det nödvändigt att kunna specificera kompletterande explicita regler. De semantiska integritetsreglerna är ett exempel på explicita regler.
2.3.4 Skillnader mellan traditionell och utökad relationsdatabas
De applikationer som var aktuella när relationsdatabaser (RDB) började användas, använde sig enbart av enkla datastrukturer som t ex heltal, reella tal och bokstavssträngar. Till dessa applikationer var traditionell RDB tillräcklig. De nya typer av applikationer som utvecklas idag, t ex komponentuppdelade applikationer, kräver möjligheter till ett mer expressivt uttryckssätt. Detta ges i varierande grad av så kallade utökade RDB (Delobel, 1995). Exempel på uttryckssätt som kan behövas är hierarkiska strukturer och andra komplexa egendefinierade datatyper (EDT), egendefinierade funktioner (EDF), indexstrukturer samt optimerare (Davis 1997).
Stöd för EDT kan ges på både kolumnnivå och radnivå. På kolumnnivå är EDT antingen distinkta eller abstrakta datatyper. Distinkta datatyper är en utökning av en existerande grundläggande datatyp, medan abstrakt datatyp är en mer komplex datatyp med speciell intern struktur t ex text eller bild. På radnivå beskriver EDT en hel rad eller en mängd bestående av nästlade kolumner i en tabell. Detta möjliggör ett sätt att representera hierarkiska entiteter i databasen. Referenstyper kan sedan ersätta komplexa joindefinitioner med en enklare ”vägbeskrivning” för hur data från olika relationer skall kombineras.
EDF vilka definierar metoder för att manipulera data, är ett viktigt komplement till EDT. Ett utökat RDBHS bör tillåta komplexa värden som returvärden vilka sedan kan ytterligare manipuleras, t ex tabeller. Överlagring av funktionsnamn bör stödjas för att förenkla applikationsutvecklingen.
Traditionella RDB använder sig av binärträdsindex (eng. B-trees) för att snabba upp åtkomst till skalär data. Med möjlighet att definiera mer komplexa datatyper krävs specialindex för en effektiv åtkomst, t ex regionsträd (R-trees) för åtkomst av två- och tredimensionell data. En mekanism för att kunna ”plugga in” vilken egendefinierad indexstruktur som helst ger högsta nivå av flexibilitet.
Frågeoptimerare är själva knutpunkten vad det gäller RDBHSs prestanda. Systemet måste alltså utökas med kunskap om hur exekvering av EDT effektivast utförs. Detta kan åstadkommas genom att dra fördel av de nya indexstrukturerna, transformera frågor på nytt sätt samt navigera mellan data med hjälp av referenser.
Andra utökningar är stöd för lagring av stora objekt i databasen eller i externa filer,
möjlighet att tillämpa affärsregler och integritetsregler på nya datatyper, rekursiva
frågor för att stödja komplexa datarelationer samt utökat språkstöd i servern (Davis
1997).
2.4 Databassystemets logiska arkitektur
Arkitekturen delas upp i tre logiska nivåer, presentationslager, processlager (även kallat applikationslager eller affärsservice) och datalager. DBHS tillhandahåller tjänster på alla nivåer (delvis på presentationslagret) och vid mappning mellan lagren.
Presentationslager
Processlager
Datalager
DBHS Slutanvändare
Databas
Figur 3 Schematisk bild över logisk treskikts arkitektur
Den nivå som är närmast användaren är presentationslagret vilket tillhandahåller användargränssnittet till systemet. All användaraccess till data sker genom detta lager.
Presentationslagret kommunicerar också med processlagret, som tillhandahåller tjänster som generell sökning, uppdatering av produkt, arkivering, komplex affärsregelkontroll mm. Processlagret tillhandahåller också tjänster vilka inte är knutna till presentationslagret som t ex bakgrunds-schedulering eller automatiserad händelsehantering. Datalagret tillhandahåller den data som processlagret behöver för att utföra sina processer. Kommunikation sker naturligtvis också mellan processlagret och datalagret (Thompson 1997).
Uppdelningen i tre skikt är logisk men kan också vara fysisk. Det är dock inte helt entydigt hur en fysisk uppdelning av applikationen bör göras. I en traditionell klient- serverteknologi utgörs presentationslagret av klienten och datalagret av servern.
Beroende på tillämpning finns processlagret på klient eller server eller uppdelad på båda.
2.5 Databashanteringssystem
Ett DBHS är ett komplext mjukvarusystem som hanterar all åtkomst till databasen. Det tillhandahåller ett visst antal minimifunktioner: datadefinition, datamanipulation, datasäkerhet och dataintegritet, återhämtning och parallell åtkomst av data samt data dictionary (Date 1995).
DBHS måste kunna ta emot datadefinitioner i källkodsform och konvertera dem till
lämplig objektform. Detta medför att DBHS måste inkludera komponenter som stöder
bearbetningen av frågespråket. En komponent för vart och ett av de olika
datadefinitionsspråken (eng Data definitions language, DDL). DBHS måste också
förstå DDL definitionerna i den meningen att det ska kunna tolka och svara på
användares förfrågningar.
Bakgrund
DBHS måste kunna hantera förfrågningar från användaren vad gäller hämta, uppdatera eller ta bort existerande data från databasen eller lägga till ny data i databasen. Det måste alltså inkluderas en komponent som ger stöd för bearbetningen av frågespråket (eng data manipulation language, DML).
DML-förfrågningar kan vara både planerade och oplanerade:
• Planerade förfrågningar är sådana vars behov kan förutses i förväg och DBA kan därför anpassa den fysiska databasdesignen på så sätt att god prestanda kan garanteras vid dessa förfrågningar.
• Oplanerade förfrågningar är däremot ad hoc frågor, dvs i förväg ej förutsedda frågor som uppstår i ett spontant ögonblick. Att uppnå bästa möjliga prestanda för dessa förfrågningar är en signifikant utmaning för DBHS och berörs till stor del av optimering.
Planerade förfrågningar kommer att härröra ifrån i förväg skrivna applikationsprogram medan de oplanerade förfrågningarna per definition härrör sig från interaktivitet. För att garantera datasäkerhet och dataintegritet måste DBHS inkludera funktionalitet för övervakning av användarförfrågningar. Varje försök till att bryta mot de säkerhetsregler och integritetsregler som definierats och lagrats måste avvärjas. När det gäller parallell åtkomst av data och återhämtning av data används en komponent som kallas transaktionsövervakare (eng. transaction manager, TM). Denna komponent kan vara antingen direkt inkluderad i DBHS eller en komponent i direkt anslutning till DBHS.
DBHS måste tillhandahålla en funktion för data dictionary. Data dictionary kan ses som en databas i sig själv, dock mer en systemdatabas än en databas med rådata. Den innehåller metadata. Datainformation om alla olika schema och mappningar i alla nivåer av databassystemet lagras både som källkodsdata och i objektkodsform. En omfattande data dictionary inkluderar även information om korsreferenser, t ex vilka program som använder vilka delar av databasen, vilka användare som efterfrågar vilka rapporter osv. DBHS ska naturligtvis utföra all denna funktionalitet så effektivt som möjligt, dvs med så hög prestanda som möjligt.
Datakommunikationshanterare (eng. Data communication manager, DC) är en fristående mjukvarukomponent som är ett autonomt system i sig självt. Den transporterar användarförfrågningar i form av kommunikationsmeddelande. Dessa meddelanden skickas från slutanvändarens PC eller arbetsstation, (egentligen från den applikation som nyttjas av användaren) som kan befinna sig på fysiskt avstånd från systemet, till DBHS och även från DBHS tillbaka till slutanvändaren (Date 1995). DC och DBHS kan ofta ses som likvärdiga partners i ett system där DBHS sköter databasen och DC hanterar meddelanden till och från applikationer som använder DBHS.
De olika distinkta språk som används i ett DBHS sammanfattas numera ofta i ett omfattande, integrerat språk. Det vanligaste språket för relationsdatabaser är SQL, vilket sålunda representerar en kombination av komponenterna DDL, view definition language (VDL) och DML. VDL har inte berörts tidigare, men är det språk som används för att specificera användarens vy samt dess mappning mot DBHS.
2.5.1 Lagrade procedurer
En lagrad procedur är i grunden ett förkompilerat program som lagrats i
databasservern och är känt av densamma. Beteendet i en applikation kan implementeras som procedurer. En procedur är jämförbar med en metod och opererar på tabeller. I modernare databasservrar finns möjlighet att exekvera procedurer i servern och dessa anropas från klienten. De fördelar som detta innebär är: ökad prestanda, procedurer kan delas av många klienter vilka har tillgång till samma databas, optimering kan utföras då procedurer skapas istället för vid körning, procedurer kan användas för att dölja systemspecifika detaljer för användaren samt en högre säkerhet kan erbjudas. Exempel på en typ av säkerhet som kan uppnås genom lagrade procedurer är att genom auktorisering tillåta en viss användare att endast få anropa en procedur men inte operera direkt på data som proceduren ges åtkomst till (Date 1995).
2.5.2 Triggers
En trigger specificerar ett villkor och en åtgärd, dvs en procedur, som ska utföras i de fall då det specificerade villkoret uppfylls. Villkoret är oftast specificerat som ett påstående vilket anropar eller startar upp åtgärden när påståendet blir sant (Elmasri 1994). Affärsregler i form av semantiska integritetsregler kan implementeras som triggers och kan bland annat användas för att upprätthålla vissa typer av konsistens i databasen.
2.6 Standardiserade gränssnitt
Ett problem som är vanligt, särskilt i större databassystem, är att åtkomst kan behövas till olika servrar i heterogen miljö, dvs servrar från olika utvecklare ska fungera i samma system. Det behövs mjukvara som översätter koden mellan de delar i systemet som använder sig av olika språk.
Det traditionella sättet att sammanfoga heterogena plattformar till ett ur användarperspektiv skarvlöst och interaktivt homogent system har varit att bygga eller köpa mjukvara som samordnar gränssnitten mellan de specificerade miljöerna.
Det som länge efterfrågats är en universell mjukvara som möjliggör för vem som helst att bygga system som består av specialiserade, återanvändbara komponenter med standardiserade gränssnitt. Nyckeln till en sådan lösning ligger i att tillhandahålla ett gemensamt språk för att definiera gränssnitt mellan komponenter och en mekanism för att förmedla förfrågningar mellan komponenter.
Det finns idag inte någon universellt accepterad mjukvarulösning för standardiserade gränssnitt mellan komponenter men de två ledande lösningarna som finns på marknaden är CORBA och DCOM (Keuffel 1997). För gränssnitt mellan applikation och relationsdatabas finns däremot en standardlösning genom Open Database Connection (ODBC) som tillhandahåller heterogen access till relationsdata (Rue 1997).
2.6.1 ODBC
Utvecklingen av mjukvara för koppling mellan olika mjukvaror har utvecklats från
leverantörsspecifika gränssnitt till mer standardiserade. Det fanns ursprungligen ingen
standard för koppling av applikationer mot relationsdatabas. Det var nödvändigt att
använda specialanpassade gränssnitt från den specifika leverantören för åtkomst av
data från relationsdatabasen. Att konvertera existerande applikationer till nya miljöer
kunde bli mycket tidsödande och dyrt. ODBC kom att bli den odiskutabla standarden
för koppling till traditionell relationsdatabas. I och med acceptansen av ODBC som
standard, räckte det med att utvecklaren lärde sig en programmeringsmodell för
Bakgrund
åtkomst av relationsdata. Denna kunskap kunde sedan användas för åtkomst av data från praktiskt taget alla relationsdatabaser (Rue 1997).
2.6.2 CORBA
Common object request broker architekture (CORBA) skapades av Object management group (OMG), som är en sammanslutning av leverantörer och användare.
CORBA är en specifikation för ett universellt mellanlager vilket ska tillåta programmerare att skriva objekt som kan interagera med andra objekt utan att veta hur eller var dessa andra objekt är implementerade. Det gemensamma språk som togs fram är Interface Definition Language (IDL) och den mjukvara som förmedlar förfrågningar mellan objekt kallas Object Request Broker (ORB). CORBA är den minsta gemensamma nämnaren till vilken alla ORBs måste ansluta sig för att vara kompatibla.
Exempel på en ORB som skrivits utifrån CORBAs specifikation är ORBIX från Iona Technologies Inc (Keuffel 1997).
Från databasperspektiv sett är en underspecifikation av CORBA kallad Object Transaction Service (OTS) intressant. Vid migration från transaktionsorienterad miljö till objektorienterad tillhandahåller OTS en säker och pålitlig väg mellan miljöerna.
OTS består av fyra viktiga gränssnitt: Concurrent, Coordinator, Recource och SubtransaktionAwareResource (Keuffel 1997).
2.6.3 COM/DCOM
Component Object Model (COM) är en objektbaserad programmeringsmodell från Microsoft Corp, vars syfte är att tillåta utveckling av mjukvarukomponenter vid olika tillfällen och från olika leverantörer. Dessa leverantörer kan använda sig av varierande språk, verktyg och plattformar. Ett COM-gränssnitt definierar beteende och förmåga hos en mjukvarukomponent som en samling av metoder och egenskaper.
Komponentdesigners använder sig av Microsoft Interface Definition Language (MIDL) vid implementation och en MIDL-kompilator genererar ställföreträdande (eng proxy) och kontramärkt (eng stub) kod i C eller C++. Den genererade ställföreträdande koden ger klientsidans API. Den kontramärkta koden avkodar inkommande klient- förfrågningar och levererar dem till lämpligt objekt i servern. Internt interagerar sedan kontramärkt och ställföreträdande kod med lämpliga runtime libraries för att utväxla förfrågningar och svar. Varje COM-objekt får en universell unik identifierare, för att eliminera risken för osäkerhet i samband med namnkollisioner. Enbart gränssnittet är inte tillräckligt för att bygga en komplett COM-applikation. En COM-klass är en kropp med källkod, vilken bland mycket annat består av ett eller flera COM-gränssnitt. En eller flera COM-klasser paketeras på en server. En COM-server kan paketeras som ett dynamiskt länkbibliotek (DLL) vilken laddas in i klientprocessen. Distribuerad COM (DCOM) utökar COM till att fungera i nätverk genom remote methods call, samt genom att tillhandahålla stöd för säkerhet, skalbarhet och transparent lokalisering (Ewald, Roy 1997).
2.7 Verktygsstöd
Det har de senaste 20 åren, generellt sett, varit med mjukvaruutvecklare som med
skomakarens barn. Talesättet som syftas på är: skomakaren är för upptagen med att
göra skor åt andra så hans egna barn blir utan. Detta stämmer bra på
mjukvarubranchen. Medan komplexa hjälpmedel som automatiserar arbete åt andra har
utvecklats har dock inga automatiseringsverktyg utvecklats för mjukvaruutveckling.
Detta har nu förändrats genom att hjälpmedel som allmänt kallas computer-aided software engineering (CASE) tagits fram och finns inom olika kategorier. De ger inte alltid det sofistikerade resultat som önskas, men CASE-verktygen har förfinats efter hand (Pressman 1997).
Nuvarande objektorienterade CASE-verktyg har en begränsad möjlighet att på ett bra sätt föra över en objektmodell till det fysiska relationsschemat. Denna begränsning ställer stora krav på designen. Gottesdiener (1997) hävdar att det är svårt att finna en bra överföring i synnerhet för arvsstrukturen i objektmodellen. Det finns olika sätt att angripa detta på men ingen är ensidigt bäst, utan det finns flera olika kriterier att ta hänsyn till. Några av kriterierna är djupet och vidden av arvsstrukturen, kapacitet hos miljön applikationen ska köra i, storlek och flyktighet av data samt hur enkelt det är att utöka den fysiska designen när den väl är implementerad. Ett problem är hur samordningen mellan transaktioner från de olika applikationernas komponenter ska ske ifall flera applikationer samtidigt behöver tillgång till data i samma databas (Gottesdiener 1997).
2.8 Relaterat arbete
Det finns beskrivet hur objektmodellering kan direktöverföras i objektorienterade
databaser samt hur datastrukturen och dess relationer överförs från objektmodell till
relationstabeller (Rumbaugh 1991). Här lämnas dock inget stöd för hur beteendet som
är relaterat till datan ska tas omhand, då relationsdatabas används istället för
objektorienterad databas. I litteraturen finns också beskrivet hur olika hybrider (så
kallade utökade RDB) kan användas för att lagra metoder och annan objektorienterad
funktionalitet, t ex komplexa datastrukturer i form av hierarkiska strukturer
(Rennhackkamp 1997, Davis 1997). Exempel på utökade RDB är Oracle 8i (Oracle
1999) och DB2 V5 (IBM 1999). I detta arbete hanteras situationen som uppstår då
inte beteendet kan lagras tillsammans med datan i databasen, dvs traditionell
relationsdatabas används tillsammans med en applikation framtagen med
objektorienterad analys och design (komponentbaserad applikation).
Problembeskrivning
3 Problembeskrivning
Det innebär en del svårigheter att använda sig av komponentbaserade utvecklingsmetoder vid framtagande av nya applikationer ifall en traditionell relationsdatabas ska användas för lagring av datan. Övergången mellan objektorienterat tänkande och relationsorienterat tänkande blir svårt. Datan kan fortfarande relativt enkelt lagras i databasen, men affärslogiken, dvs beteendet, måste tas om hand på annat sätt. Med beteende avses i detta arbete de regler, beräkningar och operationer som finns definierade för applikationen.
Det är viktigt att kommunikationen mellan de olika komponenterna i systemet fungerar bra även om de inte är uppbyggda med samma språk, t ex då data skall hämtas ur olika heterogena databaser. Detta underlättas av att det skapas ett generellt gränssnitt för access av data som kan utnyttjas av alla typer av datakällor.
Den data som lagras i själva databasen är redan uppdelad på ett sätt som medger delad tillgång av kod och återanvändning. I en relationsdatabas sker denna uppdelning i form av tabeller. Data från samma tabell kan gång på gång hämtas och processas av flera olika användare. Det som i detta fall blir aktuellt att fysiskt dela upp i komponenter är det logiska processlagret, dvs beteendet. De fysiska komponenter, som innehåller beteendet, bör lagras fysiskt på ett sådant sätt att delad åtkomst och återanvändning understöds. Beteendet är lagrat på klienten, i ett traditionellt databassystem med klient- serverarkitektur.
Klient
Presentationslager Processlager
Processlagret, dvs beteendet, vilket lagras direkt på en klient kan inte nyttjas av någon annan klient. Det måste distribueras ut till varje klient och lagras där
Databas
Datalager
Tabellerna är lagrade så att delad åtkomst är möjlig
Figur 4 Schematisk bild över hur det logiska processlagret lagras fysiskt i ett
traditionellt klient-serversystem.
Implementation som lagras direkt på en klient är inte tillgänglig för någon annan klient.
Koden är alltså inte möjlig att dela utan varje klient lagrar den kod som den behöver tillgång till. Den kod som däremot lagras i databasen, dvs tabeller på databasservern, kan alla klienterna få delad åtkomst till. Se figur 4
När det gäller databassystem, så är det den traditionella relationsdatabasen, och inte den objektorienterade databasen, som fortfarande är den mest använda. Detta gäller trots att en övergång till komponentuppdelade applikationer blir allt vanligare (Thompson 1997). Samtidigt som det är viktigt att ta tillvara de fördelar som en komponentuppdelad applikation ger, blir lagring av data från applikationens olika komponenter i en relationsdatabas mer komplicerad. Detta eftersom traditionella relationsdatabaser i allmänhet saknar stöd för komponenttänkande. En relationsdatabas lagrar rena tabeller med rader och kolumner och har ingen möjlighet att direkt lagra det beteende, som finns i olika komponenter eller objekt. Ett annat exempel på svårighet vid lagring av komponenter i relationsdatabas är den hierarkiska arvsstrukturen. Detta medför att det finns ett antal improviserade lösningar på detta problem.
3.1 Motivering och definition av problemet
Det finns i litteraturen beskrivet hur datastrukturen och dess relationer överförs från objektmodell till relationstabeller t ex i Rumbaugh (1991), kap 17. Det saknas däremot beskrivning av en designstruktur som beskriver komponentuppdelning av beteendet i databasapplikationen, dvs en struktur för hur och var beteendet från de olika komponenterna i objektmodellen ska implementeras. Även stöd i form av anpassade arbetsmetoder vid implementering av denna designstruktur saknas.
Problemet består i att finna en designstruktur, inklusive arbetsmetoder, möjligen baserade på Case-teknologi, vilka ger ökat stöd för komponenttänkande i applikationen med fortsatt användande av en ej utökad relationsdatabas. Problemet uppstår genom att beteendet som finns i objektmodellens klasser, inte kan lagras i tabeller som datastrukturen och dess relationer, utan måste tas om hand på annat sätt.
Detta då en kombination av objektorienterad applikationsdesign och traditionell relationsdatabas används. Vid komponentbaserad utveckling används vanligtvis objektorienterad analys och design.
3.2 Förväntat resultat
Det förväntade resultatet är att finna en metod som innehåller en generell designstruktur för det logiska processlagrets fysiska uppdelning och lagring i databasapplikationen, samt arbetsmetoder för framtagande av denna designstruktur.
Denna designstruktur bör understödja ökad möjlighet till delad åtkomst av komponenter som innehåller beteendet. Med delad åtkomst, menas att flera användare kan använda samma kod utan att den behöver skapas mer än en gång och lagras på mer än ett ställe.
Designstrukturen avser att klargöra var i databassystemet, dvs i vilket eller vilka
fysiska lager som lagringen av beteendet bör ske, för att få en så generell lösning som
möjligt. De olika fysiska lager som avses är klienten, databasen och eventuellt ett
mellanlager. Beteendet måste fysiskt sett komponentuppdelas och det som fokuseras
på är hur beteendet grupperas i komponenter och var beteendet ska lagras, för att en så
fördelaktig lösning som möjligt ska uppnås. Uppdelning och lagring av processlagret
kan exempelvis ske på klienten, som komponenter med embedded SQL. Den kan ske i
Problembeskrivning
ett separat mellanlager, som tar hand om allt beteende och den kan ske i databasservern som lagrade procedurer och triggers. En blandning av de olika typer som berörts kan visa sig vara fördelaktigast.
De arbetsmetoder som tas fram syftar till att definiera vilket tillvägagångssätt som bör användas, för att underlätta utveckling av system med den designstruktur som valts.
De generella metodsteg som beskrivs för objektdesign i litteraturen (bl a Rumbaugh 1991) behöver specialanpassas för databasapplikation vid framtagandet av vald designstruktur.
3.3 Avgränsning
Studien begränsas till att gälla system där en eller flera applikationer delar på en enda
relationsdatabas, då en mer omfattande studie inte ryms inom tidsramarna. Aspekter
som rör datakommunikation i nätverket faller också utanför denna rapports ramar.
4 Metod
Den vetenskapliga metod som används vid genomförandet av detta arbete är en vanlig forskningsmetodik inom datalogi (utförlig beskrivning relaterad till detta arbete ges i kap 6.4). De olika stegen kan sammanfattas här:
• Problemet definieras. I detta arbete är det grundat i litteraturen
• Lösningsmetod tas fram. Flera olika lösningsmetoder tas fram och analyseras för att bästa alternativ ska kunna hittas. Dessa grundar sig också från fakta från litteraturen.
• Testfall genomförs. Detta görs för att resultatet ska kunna evalueras och valideras.
I vissa fall kan det falsifieras. Detta arbete är möjligt att falsifiera genom att det genomförs ett så kallat existensbevis, dvs antingen lyckas testfallet eller också inte.
• Resultat erhålls. Här erhålls ny kunskap oavsett om problemet lösts eller ej.
Det används en så kallad kvantitativ metod, dock med kvaltitativa inslag (Patel &
Davidson 1994). De kvalitativa inslagen innebär att bedömning och analys sker, av hur de framtagna lösningsalternativen uppfyller avsedda kriterier (kriterierna är hämtade från fakta i litteraturen). Detta görs vid val av lösningsalternativ. En i huvudsak kvantitativ metod som arbetssätt, har valts för att arbetet ska kunna genomföras så objektivt som möjligt. Problemet är också av en sådan karaktär, dvs ett mycket praktiskt problem, att denna metod bedömts som den mest lämpliga.
4.1 Lösningsalternativ
Det är inte entydigt var det logiska processlagret ska placeras rent fysiskt och inte heller hur det ska komponentuppdelas. Den logiska treskiktsuppdelningen av applikationen behöver inte betyda att den fysiskt delas upp på separata enheter. Här tas fyra olika förslag på lösningsalternativ fram. Det är tänkt att spegla hela bredden av lösningsalternativ, dvs de olika ytterligheterna samt det som finns imellan. Det första lösningsalternativet speglar det traditionella sättet att ta hand om beteendet, dvs i klienten. Här ges då samtidigt en möjlighet att utvärdera detta alternativ gentemot de övriga alternativen. Det andra lösningsalternativet speglar den andra ytterligheten med att ta hand om allt beteende i databasen. De två sista lösningsalternativen är olika former av middlewarelösningar, vilket innebär att det används mjukvara, i ett mellanlager, för att på ett smidigt sätt binda ihop klient och databasserver och därmed de olika logiska lagren i applikationen.
4.1.1 Processervice direkt på klienten
I detta lösningsalternativ implementeras beteendet på klienten, Figur 5. Denna lagring av beteendet sker i ett dynamiskt länkbibliotek, dvs DLL-filer. DLL-filerna är förkompilerade och behöver bara anropas för att kunna användas i olika applikationer.
Varje DLL-fil betraktas som en komponent.
Varje komponent bör av återanvändningsskäl inte innehålla mer än ett fåtal externa
metoder, vilket gör att det i ett stort system blir komplext med oerhört många
komponenter i biblioteket. Varje komponent kan återanvändas i de olika applikationer
som klienten använder.
Metod
Delad åtkomst av beteendet mellan klienter kan inte ske utan ett omfattande nätverkssystem, där en klient då måste vara både klient och server. Det måste därför på varje klient finnas tillgång till det beteende som är definierat och används i systemet.
Det innebär också att vid uppdatering i processlagret, t ex förändring i eller tillägg av komponenter, måste förändringen distribueras ut till varje klient. Felsökning, när det gäller beteende, kan ta tid då varje klient har sin version av processervice lagrad och det följaktligen kan vara, antingen ett lokalt fel på en klient, eller ett systemfel.
Länkbiblioteken kan efterhand utökas dock med risk för att bli ohanterligt stora.
Förändringar av beteendet tar mycket tid då dessa varje gång måste distribueras ut till samtliga klienter. Detta medför prestandaförlust, särskilt ifall det skulle vara fråga om att förändra metoder eller affärsregler ofta.
All data som ska bearbetas hämtas upp från databasen till klienten för att bearbetas där.
Att data transfereras till klienten för bearbetning ger upphov till hög nätverkstrafik, exempelvis måste varje explicita regler kontrolleras via klienten varje gång något ska lagras i databasen. Åtkomst av data för olika klienter och applikationer kan vid ojämn eller konstant hög belastning, t ex många behöver samtidigt tillgång till samma data i databasen, ge upphov till stor prestandaförlust. Det är viktigt att se till att varje förfrågan som kräver åtkomst till databasen inte tar för lång tid att utföra eftersom det kan innebära att stora mängder data behöver lagras på klienten under bearbetningstiden.
Klient
Databas
Presentationslager Processlager
Datalager
Klienten sköter all
processervice, dvs beteendet måste distribueras ut till varje klient och lagras där
Figur 5 Schematisk bild av systemet vid implementering av processervice på klienten
Utökning av fler relationsdatabaser från olika leverantörer medför inga större problem
då alla explicita regler lagrats utanför databasen. Detta förutsatt att mjukvara med
standardiserade gränssnitt används, exempelvis ODBC. Byte till annan datamodell,
exempelvis en objektorienterad, medför en helt annan struktur i databasen vilket gör
att mycket av det som tidigare implementerats i klienten då naturligt skulle lagras i den nya databasen. Applikationen på klienten skulle antagligen behöva revideras.
Det kan inte vara för många användare anslutna till ett system där mycket bearbetning av data förekommer, då det hela tiden krävs mycket nätverkstrafik för överföring av data mellan klienten och databasen.
4.1.2 Processervice i databasen
Applikationens beteende, implementeras och lagras direkt i databasen, Figur 6. Det beteende som däremot definierar hur användargränssnittet presenteras och fungerar, lagras fortfarande direkt på klienten då det beteendet bara berör själva presentationen av informationen till användaren. De olika typerna av beteenden lagras i databasen i form av triggers och lagrade procedurer, vilka kan jämföras med metoder.
Beteenden behöver endast implementeras en gång och de olika klienterna kan få gemensam tillgång till dem i databasen. Förändringar av beteende och andra affärsregler är också enklare att genomföra då dessa bara behöver ske i databasen.
Även ifall det finns flera databaser kopplade till applikationen, blir det inte mer än en gång i varje databas, som implementationen behöver ske. Vid felsökning finns bara en version med data att genomsöka (förutsatt att det bara är en databas). Databasserverns processor kan dock belastas hårt då både bearbetning av beteendet, och övrig service för åtkomst av data sker på samma processor.
Klient
Presentationslager
All processervice sköts i databasen. Detta minskar nätverkstrafiken, eftersom beteendet bearbetas direkt i databasen. Tillgången till beteendet blir därmed gemensam för alla klienter Databas
Datalager processlager
Figur 6 Schematisk bild av systemet vid implementering av processervice i databasen
Det sker mindre transport av data över nätverket då den nätverkstrafik som sker i detta
lösningsalternativ sker vid förfrågan från applikationen på klienten och vid retur av
Metod
resultat tillbaka från databasen till klienten. Applikationen anropar databasen vid varje transaktion. Triggers, dvs semantiska integritetsregler, har den fördelen att de hjälper till att hålla data konsistent i databasen, förutom att det inte behövs någon nätverkstrafik för att applicera reglerna på data i tabellerna. Nätverkstrafik sker inte heller vid övrig bearbetning av beteendet, vilket implementeras som lagrade procedurer, och vid förfrågning från klient bearbetas de direkt i databasen.
Backuppsystemet behöver inte bli komplicerat då data finns lagrat på ett ställe, men vid backupp kan prestandan sjunka, då detta medför att databasserverns processor belastas extra.
Då databasen innehåller många implementerade procedurer och triggers kan det göra databasen något långsammare. Detta eftersom exekveringstiden för procedurer och hantering av triggers blir omfattande, samt all bearbetning sker på samma processor.
Att utöka med nya komponenter i systemet är inte särskilt tidsödande men även här belastas databasen extra vid den uppdatering av systemet som sker. Det är inte en enkel sak att byta databas ifall hela det logiska processlagret fysiskt implementerats i databasen. Även om det är byte mellan relationsdatabaser från olika leverantörer, så skiljer sig ofta sättet att implementera en del. Ifall åtkomst av data ska ske från flera olika databaser, måste koden skrivas en gång i varje databas. Byte av användargränssnitt med bibehållen relationsdatabas blir däremot enkelt såvida ODBC eller annat standardiserad mjukvara för gränssnitt används för kopplingen mot relationsdatabasen.
Förutsatt att varje komponent som innehåller procedurer är väl designade och implementerade, utgör lagringssättet inget hinder för en bra återanvändning av de olika komponenterna. Det är dock inte lämpligt med riktigt många användare i ett sådant här system, då all bearbetning sker i databasen och parallell åtkomst av identisk data för samtidig bearbetning inte kan tillgodoses. Processorns kapacitet har en avgörande betydelse för prestandan.
4.1.3 Ett mellanlager för processervice
Applikationens beteende implementeras och lagras i ett mellanlager, Figur 7. Även i detta lösningsalternativ sker undantag för det beteende och de affärsregler som endast gäller presentation av information i användargränssnittet.
Implementation av beteendet behöver bara ske på ett ställe, oavsett ifall det behövs en eller flera databaser i systemet och oavsett hur många klienter som behöver tillgång till koden. Felsökning när det gäller fel i regler och beteende sker på ett enda ställe.
Uppdatering och backupp av processervice sker också på ett och samma ställe. Det blir förhållandevis lätt att byta ut och förändra komponenter ifall de är bra designade och implementerade, dvs väl avgränsade och generella, då varken databasen eller klienten direkt påverkas av detta.
Applikationen anropar lämplig processerver, en så kallad applikationsserver, då data
ska hämtas för bearbetning och/eller presentation till användare. Applikationsservern
anropar sedan i sin tur databasen för att få tillgång till den data som behövs. Data
hämtas och lagras på applikationsserver medan bearbetning sker. All bearbetning sköts
på applikationsservern. Detta medför att det blir lite nätverkstrafik från klienten till
applikationsservern för att överföra de olika förfrågningarna. Från applikationsservern
sker nätverkstrafik för att hämta data från databasen för bearbetning. Det blir även
nätverkstrafik mellan databasen och applikationsservern för att kontrollera de olika
semantiska integritetsreglerna som är definierade för lagring av data i tabellerna i databasen. Efter bearbetningen sker nätverkstrafik från applikationsservern för att leverera resultatet av förfrågningen till klienten som är den som presenterar resultatet till användaren. Hur detta påverkar prestanda i systemet beror till stor del på vilken kapacitet nätverket har.
Genom att lagra alla affärsregler och metoder på en applikationsserver i ett separat mellanlager kan många olika klienter få parallell åtkomst till data och samtidig bearbetning av densamma. Detta sköts av en särskild transaktionshanterare på applikationsservern vilken sköter all transaktionshantering från klient mot databasen.
Det finns en del olika transaktionshanterare från olika leverantörer på marknaden.
Att byta databasleverantör eller ansluta fler databaser från olika leverantörer blir inte speciellt problematiskt, ifall mjukvara med standardiserade gränssnitt används. Även andra användargränssnitt kan anslutas om standardiserade gränssnitt används.
Återanvändningen av komponenterna som innehåller beteendet blir effektiv med användande av transaktionshanterare för åtkomst av de lagrade komponenterna.
Klient
Presentationslager
Databas
Datalager
All processervice sköts på mellanlagret, dvs
applikationsservern, vilket medför nätverkstrafik då data distribueras mellan lagren.
Tillgången till processervice är gemensam för alla klienter
Processlager
