Uppsala Universitet Instutitionen för Informatik och Media Databasdesign: Nulägesanalys av normalisering Johannes Wesslén Weiler Emelie Öhrn Kurs: Examensarbete Nivå: C Termin: VT-16 Datum: 160617
Sammanfattning År 1970 introducerades normalisering med syfte att organisera data i relationsdatabaser för att undvika redundant data och reducera risker för anomalier. Idag finns indikationer på att en mer nyanserad bild av normalisering behövs då dagens databaser ställs inför nya utmaningar och krav. Det här arbetet utförs i form av en fallstudie där en analys av tre databaser inom olika verksamheter genomförs. Med utgångspunkt i normalformerna genomförs en explorativ analys för att identifiera vilka aspekter som påverkar normalisering i industrin. Slutsatsen av arbetet är att det är svårt för en oberoende part till databasen att avgöra och tolka normalformernas uppfyllnad. Faktorer som påverkar normalisering av databaser är: utvecklarens intuition, användarens påverkan av datakvalitet samt den tekniska skuld som quickfixes orsakar. Nyckelord: databasdesign, normalisering, normalform, denormalisering
Abstract Normalization was first introduced in 1970 with the purpose to organize data within relational databases in a way to avoid data redundancy and reduce the number of anomalies. As databases are facing new challenges and requirements, indications have been identified which points to a need for a more detailed view of normalization. This work is the outcome of a case study where three databases are analyzed. With the normal forms as starting point, an explorative analysis is made with the goal to identify different aspects that affects the way normalization is conducted within the industry. The conclusion is that it is difficult for an outsider to the database to interpret and determine whether the normal forms are fulfilled or not. Aspects affecting normalization are: the developer s intuition, users impact on data quality and the technical debt that quickfixes creates. Keywords: database design, normalization, normal form, denormalization
Begreppslista Attribut En egenskap som entiteten kan ha. Egenskap och attribut kommer i uppsatsen att användas som synonymer. BI (Business Intelligence) En samling olika färdigheter, tekniker, applikationer, processer och metoder som används av en organisation för att bättre förstå sin verksamhet och dess omvärld. Används för att kunna göra mer välavvägda affärsbeslut. Constraints Restriktioner som används för att skapa kontroll över hur data interagerar med annan data och hur relationer kopplas mellan entiteter. Dashboard En visuell och lättbegriplig display som visar information om nyckeltal som är viktiga för dess användare. DBMS (Database Management System) Mjukvara som tillåter användare interagera med databaser. MySQL & Microsoft SQL Server är exempel på denna typ av program. Entitet Något som verksamheten vill upprätthålla data om. Kan t.ex. vara en person, produkt, objekt eller koncept. ERD (Entity Relationship Diagram) En datamodell för att beskriva entiteter samt attribut och de relationer som finns mellan dem. GUI (Graphical User Interface) Ett grafiskt användargränssnitt som används för att förenkla interaktion mellan användare och dator. Join En query som kombinerar data från mer än en tabell för att forma en ny tabell med information från originaltabellerna. Kandidatnyckel Attribut som skulle kunna användas för att bli primär- eller främmande nyckel. OLAP (Online Analytical Processing) Ett tillvägagångssätt för att på en större mängd data på ett effektivt sätt genomföra queries snabbt. Exempelvis går det i en OLAP-kub att göra exekveringar snabbt på flerdimensionella databassökningar.
OLTP (Online Transaction Processing) Ett tillvägagångssätt för att i en databas utföra update-queries på ett bra och pålitligt sätt. OLTP stödjer även spårbarhet i större utsträckning än OLAP. Query En exakt begäran som extraherar viss information från en databas eller utför något i databasen. Sammansatt nyckel En kombination av attribut som tillsammans skapar en nyckel. SLA (Service Level of Agreement) En del av ett tjänstekontrakt som formuleras mellan olika parter. Överenskommelsen berör den kvalitet och omfattning en leverans ska ha och vilka skyldigheter som finns mellan de olika parterna för kontraktet. SSAS (SQL Server Analysis Services) Ett verktyg utvecklat av Microsoft som används för att granska och analysera data. Verktyget kan användas över flera olika databaser för att sammankoppla data och hitta mönster mellan den information som finns. Kan appliceras på data warehouses och är bland annat använt i BI-syfte.
Innehållsförteckning 1 Inledning 1 1.1 Problemformulering................................ 2 1.2 Syfte........................................ 2 1.3 Avgränsning.................................... 3 1.4 Disposition..................................... 3 2 Teori 4 2.1 Traditionell modellering.............................. 4 2.1.1 Konceptuell modellering............................ 4 2.1.2 Logisk modellering.............................. 5 2.1.3 Fysisk modellering............................... 5 2.2 Normalisering................................... 5 2.2.1 Normalformer................................. 6 2.2.2 Teknisk skuld.................................. 8 2.3 Anomalier..................................... 9 2.4 Denormalisering.................................. 9 2.5 Data warehouse................................... 10 2.5.1 Modellering.................................. 10 2.6 Tidigare forskning................................. 12 3 Metod 13 3.1 Forskningsstrategi och paradigm.......................... 13 3.2 Val av respondenter................................. 13 3.3 Metodik för datainsamling............................. 14 3.3.1 Insamling av dokument............................ 14 3.3.2 Intervju..................................... 15 3.4 Metodik för dokumentanalys............................ 16 3.4.1 Dokumentanalysmall.............................. 16 4 Resultat 17 4.1 Databas för bilder till kataloger.......................... 17 4.1.1 Bakgrund.................................... 17 4.1.2 Uppbyggnad och designval.......................... 18 4.2 Databas för rapportering över ärendehantering.................. 20 4.2.1 Bakgrund.................................... 22 4.2.2 Uppbyggnad och designval.......................... 22 4.3 Databas för filmförsäljning............................. 24 4.3.1 Bakgrund.................................... 24 4.3.2 Uppbyggnad och designval.......................... 26 5 Analys 27 5.1 Tolkning av normalformer............................. 27 5.1.1 Semantik.................................... 27 5.1.2 Kontext..................................... 27
5.1.3 Censurerad data................................ 28 5.2 Intuition....................................... 28 5.3 Användarens påverkan på datakvalitet....................... 29 5.4 Teknisk skuld och quickfixes............................ 30 6 Slutsats 32 6.1 Förslag till vidare forskning............................ 33 7 Diskussion 34 Referenser 35
1 Inledning Att hålla en god databasdesign är grunden till att snabbt, pålitligt och konsekvent kunna hämta data ur databaser (Badia och Lemire, 2011). Ett verktyg för att på ett strukturerat sätt organisera sin data är att normalisera den i flera steg. År 1970 introducerade E.F Codd normalisering och den första normalformen (Codd, 1970). Normalformerna kan beskrivas som riktlinjer för organisering av data i en databas (Kent, 1983), och en närmare redogörelse för normalisering och normalformerna görs i avsnitt 2.2. Normalisering av relationsdatabaser görs för att undvika redundant data och anomalier vid queries i form av insert (insättning), modification (modifiering) och delete (borttagning) (Codd, 1970). Genom en bra design av databasen kan exempelvis backup-funktioner tillhandahållas vilket gör att återhämtningen efter eventuell datakorruption kan gå snabbare och mer smärtfritt (Stephens, 2010, s.8-9). Vid normalisering av databaser blir anpassningar till förändringar som insättning och borttagning av data enklare (Stephens, 2010, s.136-137). Enligt Stephens (2010, s.154) stannar många databasdesigner vid tredje normalformen, detta för att det anses vara den nivå av normalisering som förhindrar de flesta anomalier. Här menar Stephens att de högre normalformerna leder till onödigt komplicerade datamodeller som är svåra att implementera, underhålla och använda. En annan svårighet som Jagadish m.fl. (2007) lyfter är att högre normalformer skapar svårigheter för användare som inte kan interagera direkt med databasen på grund av att dess design är för komplex. Målet är att normalisera relationer tills den normalform som är den mest kostnadseffektiva uppnås, med hänsyn till ökad prestanda och reducerat antal anomalier (Lee, 1995). Hur långt och hur mycket en databas ska normaliseras är en avvägning mellan å ena sidan minskade risker för anomalier och å andra sidan försämrad systemprestanda i form av längre svarstider. På senare tid har en debatt förts av ett antal större verksamhetsaktiva bloggare, t.ex. Pat Helland (Microsoft, 2007) om huruvida det kan vara mer lönsamt att denormalisera data snarare än att normalisera den. Denormalisering innebär att sänka graden av normalisering av databasen för att uppnå bättre systemprestanda (Hoffer, Prescott och McFadden, 2006, s.249). System som behöver vara skalbara och leverera data i varierande storlek tjänar på att denormaliseras (Obasanjo, 3.8.2007). Åtskilliga större aktörer inom IT-industrin såsom Google, ebay och Amazon väljer idag att använda sig av denormaliserade tabeller i större utsträckning för att snabbare leverera resultat och för att bättre skala sina databaser (Obasanjo, 3.8.2007; Rotem-Gal-Oz, 13.8.2007). Ett exempel på fördelaktig denormalisering tar Flickr s då ledande webbutvecklare Cal Henderson upp. Flickr har valt att denormalisera data då deras teknik kräver att 13 joins av tabeller måste göras för varje insert-, delete- och modification-query (Henderson, 2004). Debatten om normalisering och denormalisering är fortfarande aktuell då det inte finns tydliga riktlinjer om när och hur det är lämpligt att använda de olika verktygen vilket tyder på att det fortfarande finns problematik inom ämnet (Green, 16.3.2014). 1
1.1 Problemformulering Normalisering är idag ett vida känt koncept och som trots sin ålder fortfarande är aktuellt. Teorin lärs ut som ett av de främsta verktygen inom introduktionskurser till databaser (Badia och Lemire, 2011). Detta är något som även författarna av denna uppsats har erfarenhet av genom sin utbildning. Badia & Lemire (2011) belyser vidare att medan viss litteratur faktiskt beskriver svårigheterna med normalisering, ger andra bilden av normaliseringsteorin som ett closed case eftersom ämnet är så pass vedertaget och etablerat att ytterligare forskning anses onödig. Badia & Lemire menar att tillräcklig forskning inte bedrivs inom ämnet databasdesign. Flertalet forskare lyfter att normalisering inte enbart är en uppsättning regler att förhålla sig till, utan är beroende av utvecklarens intuition och erfarenheter (Badia och Lemire, 2011; Sanders och Shin, 2001). Vidare diskuterar Shin & Sanders (2006) att denormalisering (som trots namnet ej bör ses som motsats till normalisering, se avsnitt 2.4) av databaser är frekvent använt inom industrin, men kommer i skymundan inom akademia. Forskarna belyser också att inom den akademiska världen behandlas avvägningen mellan normalisering och denormalisering av databaser bristfälligt (Shin och Sanders, 2006). Tillvägagångssättet att organisera data genom normalisering uppfyller inte alltid de krav användare och verksamheter har på moderna databaser. Exempel på en anledning till att inte normalisera data kan vara att bättre svarstid är mer önskvärt än uppfyllda normalformer (Badia och Lemire, 2011). Värt att beakta är dessutom aspekten att idag är lagringsutrymme för data mycket billigare än för 35 år sedan (Ahl, 1981; WD US Online Store, 2016). Således fanns tidigare en större motivation för lagringsbesparande teknik. Därför kan en diskussion föras kring huruvida förhållningssättet till normalisering borde förändras för att bättre spegla dagens klimat. Avsikten med denna uppsats är att i form av en fallstudie genom dokumentanalys och intervjuer undersöka hur normalisering används i empiriska fall. De tankegångar som beskrivs i ovanstående stycken tyder på att det finns anledning att undersöka hur normalisering används inom industrin idag. Genom att utgå från normalformerna, tillsammans med arbetets explorativa karaktär, identifieras och undersöks vilka aspekter som påverkar normalisering och således kan en mer nyanserad bild av normalisering erhållas. 1.2 Syfte Uppsatsen genomförs i form av en explorativ flerfallsstudie. Genom dokumentanalys av tre databaser samt intervjuer undersöks i vilken utsträckning en oberoende part till databasen kan avgöra huruvida normalformerna uppfylls. Uppsatsens syfte är att med normalformerna som utgångspunkt skapa en nyanserad bild för vilka aspekter som påverkar hur normalisering inom industrin används. Detta är intressant på grund av att dagens databaser ställs inför nya utmaningar och krav. En sådan indikation är exempelvis fallet med Flickr i inledningen, där det är tveksamt om endast normaliseringsteorin, med fokus på dataredundans och minskat antal anomalier, är tillräcklig. 2
Uppsatsens område och det som diskuteras är intressant för bland annat IT-industrin och IT-konsulter. I händelsen av att externa IT-konsulter anlitas med uppdraget att för en organisation vidareutveckla system finns en stor sannolikhet att stöta på databaser och datastrukturer som funnits i bruk över en längre tidsperiod. Därav är det intressant att analysera hur normaliseringsteorin fungerar just när databaser och kringliggande system granskas. I uppsatsen används oberoende part som synonym till dessa IT-företag och konsulter. 1.3 Avgränsning Det finns olika typer av databaser med skilda syften och funktionalitet. Analysen i denna uppsats avgränsas till att undersöka relationsdatabaser då det är den vanligaste typen av databas (Stephens, 2010) och normaliseringsreglerna vanligen tillämpas på dessa. Normalformerna kan även i viss mån appliceras på data warehouse om det synsätt som Inmon (2000) förespråkar används. Andra typer av databaser än relationsorienterade berörs ej. Analysen av databasernas design utgår från normalisering. Som nämnts tidigare i inledningen förhindrar den tredje normalformen de flesta anomalier, och implementation av högre normalformer kan ge onödigt svåra datamodeller. Med detta i åtanke görs en avgränsning där brott mot eller användandet av normalformer över tredje normalformen inte tas i beaktning och ej heller behandlas. Uppsatsen redovisar eller producerar inte någon metod eller norm för hur framtagandet av designen för databaser bör gå till, utan ämnar endast undersöka och analysera hur situationen ser ut idag. 1.4 Disposition Inledningsvis i kapitel 2 redogörs den teoretiska grunden för arbetet. Normalisering och denormalisering behandlas grundligt tillsammans med de tre första normalformerna. Här berörs även den tidigare forskning som finns i ämnet. Kapitel 3 utgör uppsatsens metoddel där forskningsstrategi och paradigm presenteras, samt datainsamlingsmetodik och den dokumentanalysmall som använts. I kapitel 4 sammanställs resultatet av dokumentanalysen samt intervjuerna. Även databasernas strukturer presenteras genom ERD. Kapitel 5 är analysavsnittet där resultatet från kapitel 4 analyseras efter ett antal olika teman som påverkar normalisering. I kapitel 6 presenteras slutsatser och förslag till framtida forskning och i kapitel 7 presenteras en diskussion utifrån materialet. 3
2 Teori I avsnittet berörs de centrala begreppen normalisering och denormalisering samt kriterierna för de tre första normalformerna. Vidare ges förklaringar till de anomalier som kan uppstå när databaser inte är tillräckligt normaliserade. Avsnittet presenterar också den modellering som genomförs av både traditionella databaser samt data warehouses. Sist behandlas den tidigare forskning som existerar inom ämnet. 2.1 Traditionell modellering Det finns ett flertal metoder för utformning och modellering av databaser. Ett sätt att modellera en databas är genom följande tre steg: konceptuell, logisk och fysisk modellering (Teorey, Lightstone och Nadeau, 2010). 2.1.1 Konceptuell modellering I detta steg analyseras vilka krav som ställs och utifrån kraven genereras sedan en konceptuell modell av databasen, vanligen ett ERD (se Figur 1) (Badia och Lemire, 2011). Detta steg kan vara problematiskt för verksamheter då mappningen mellan entitet och verkligheten inte enbart är av teknisk karaktär (Eriksson och Ågerfalk, 2010). Att använda rätt identifierare är också en kritisk del i designprocessen. En identifierare är något som används för att identifiera enskilda objekt, och utgör en viktig del av informationsinfrastrukturen för organisation och samhälle. Vidare diskuterar Eriksson & Ågerfalk tre problem gällande identifierare och visar att svårigheterna vid utformning, val, förvaltning och kontroll av identifierare. Dåligt utformade identifierade skapar låsningar, ineffektivitet och kvalitetsproblem. (Eriksson och Ågerfalk, 2010) Figur 1: ERD - exempel 4
2.1.2 Logisk modellering För att skapa en logisk modell krävs den konceptuella modellen av databasen tillsammans med de funktionella beroenden som finns mellan de olika entiteterna som identifierats. När entiteternas funktionella beroenden utstakats skapas en modell för hur dessa ser ut tillsammans med primära och främmande nycklar som symboliserar relationerna mellan entiteterna (se Figur 2). Efter detta skapas ett databasschema där varje entitet listas tillsammans med dess attribut och de primärnycklar som finns kopplade till respektive entitet. Normalformerna bör finnas i åtanke från starten av modelleringen. Dock blir det tydligare i den logiska fasen vilka entiteter som bör få egna tabeller då attributs kopplingar och beroenden blottas på ett begripligare sätt. Därav bör den slutgiltiga normaliseringen ske i den logiska modelleringsfasen. (Teorey m. fl., 2010, s.141-145) Tabell Primärnyckel Troliga icke-nycklar Författare Personnummer Förnamn, Efternamn, isbn_id (FK) Bok isbn_id Titel, Förlag_ID (FK) Förlag Förlag_ID Namn, Telefonnummer Figur 2: Exempel på logisk modell 2.1.3 Fysisk modellering Den fysiska modelleringen använder sig av databasschemat från den logiska modelleringen för att skapa lagringsutrymmen (Badia och Lemire, 2011). I denna fas fattas beslut angående den fysiska organisationen för datan och program för databasbearbetning designas (Hoffer m. fl., 2006, s.47). I den fysiska modelleringen ingår bland annat indexering, partitionering och klustring av data. Fokus ligger på hur datan lagras och hur åtkomst till informationen behandlas. Målet med fysisk modellering är att maximera effektiviteten för databasen och de applikationer som körs mot den. I åtanke finns bland annat processorkraft, in-/outputkapacitet och nätverksbandbredd (Lightstone, Teorey och Nadeau, 2010, s.7). 2.2 Normalisering Genom att implementera de olika normalformerna ges en struktur på databasen för att undvika oönskade anomalier vid insert-, modification- och delete-queries. Genom att undvika att lagra samma information på flera olika ställen i databasen (s.k. redundant data) kan modifiering och insättning av data göras på ett snabbt och smidigt sätt då lagringen sker på ett enda ställe i databasen. Uppbyggnaden genom normalformerna ger också upphov till ökad datatillgänglighet. En fördel med strukturen är att den producerar naturligt normaliserade relationsscheman. Normalformerna genererar också en ökad kontroll av stabiliteten och integriteten av ERD:s genom att uppkomsten av anomalier förebyggs. (Sanders och Shin, 2001) 5
En ytterligare fördel med normalisering är att det sparar lagringsutrymme (Jagadish m. fl., 2007). Enligt Figur 3, som är onormaliserad, behöver ett fält med all information per bok läggas till vid varje insert-query. Detta skapar redundant information där Nordstedts Förlag upprepas vid varje insert. Istället för att lista Nordstedts Förlag på alla rader i tabellen skapas en referens till en annan entitet genom en främmande nyckel som sedan länkas i originaltabellen. I tabellen Författare (Figur 6) hittas isbn_id som är främmande nyckel till entiteten Bok. Denna entitet har i sin tur en främmande nyckel som refererar till det förlag boken hör till. Genom denna teknik minimeras lagringsmändgen då varje informationen för varje entitet endast behöver lagras på ett ställe, en gång. Personnummer Författarnamn isbn Titel Förlag Förl. telefonnummer 920305-0000 Astrid Lindgren 937462739-1 Mio, min Mio Rabén & Sjögren 018-14 76 88 920315-1111 Herman Lindqvist 837627483-5 Gustavs dagar Wahlströms 018-13 87 77 920408-2222 Jan Guillou 472838764-2 Tempelriddaren Nordstedts Förlag 018-35 67 77 910824-3333 Tess Ward 8911307151-0 Ät naturligt Nordstedts Förlag 018-35 67 77 Figur 3: Ingen normalform Trots många fördelar med normalisering av databaser finns det ett flertal nackdelar. Först och främst leder det till minskad systemprestanda i form av längre svarstider på grund av de join-queries som behöver utföras. I en relativt liten databas behöver detta inte ses som ett problem, men till följd av större datamängder blir svarstiderna onödigt långa när joins måste utföras på data utifrån många olika tabeller (Shin och Sanders, 2006). Generalisering och fragmentering av databaser leder också till mer komplicerade databasmodeller (Sanders och Shin, 2001). Jagadish m.fl. (2007) argumenterar för att användbarheten av en databas är minst lika viktig som dess operativa kapacitet. De betonar att fragmentering av tabeller minskar användbarheten av databaser när det gäller schemaförståelse, och till följd av detta måste experter med erfarenhet och kunskap hjälpa användarna att tillhandahålla den data som efterfrågas (Jagadish m. fl., 2007). Ytterligare en nackdel är att normalisering är ineffektiv på databaser där data sällan behöver modifieras och där hämtning av data är primärt (Lee, 1995). 2.2.1 Normalformer En normalform kan ses som en riktlinje för design och organisation av data i en databas (Kent, 1983). Normalformerna implicerar hur olika attribut kan grupperas (Lee, 1995). De normalformer som finns är: onormaliserad form, första normalformen, andra normalformen, tredje normalformen, Boyce-Codd normalform, fjärde normalformen, femte normalformen samt domain/key normalform (Stephens, 2010, s.138; Kent, 1983). När databasen uppfyller första normalformen sägs den vara i första normalformen. Om de tre första normalformerna uppfylls anses databasen vara i tredje normalformen. Detta innebär att om en databas är på en viss nivå av normalisering utnyttjar den även fördelarna med de tidigare normalformerna. (Stephens, 2010, s.137-138) 6
Personnummer (PK) Förnamn Efternamn isbn Titel Förlag Förl. telefonnummer 920305-0000 Astrid Lindgren 937462739-1 Mio, min Mio Rabén & Sjögren 018-14 76 88 920315-1111 Herman Lindqvist 837627483-5 Gustavs dagar Wahlströms 018-13 87 77 920408-2222 Jan Guillou 472838764-2 Tempelriddaren Nordstedts Förlag 018-35 67 77 910924-3333 Tess Ward 8911307151-0 Ät naturligt Nordstedts Förlag 018-35 67 77 Figur 4: Första normalformen Den första normalformen (1NF) innebär att de egenskaper en entitet kräver blir naturliga för att skapa entiteten (se Figur 4). Varje kolumn måste ha ett unikt namn och varje kolumn måste ha en och endast en datatyp. Varje kolumn får bara innehålla ett enda värde och är då s.k. atomär/atomisk. Kolumner kan inte heller innehålla upprepade grupper. (Stephens, 2010, s.100, s.138-140, Kent, 1983) Personnummer (PK) Förnamn Efternamn isbn_id (FK) 920305-0000 Astrid Lindgren 937462739-1 920315-1111 Herman Lindqvist 837627483-5 920408-2222 Jan Guillou 472838764-2 910924-3333 Tess Ward 8911307151-0 (a) Författare isbn_id (PK) Titel Förlag Förl. telefonnummer 937462739-1 Mio, min Mio Rabén & Sjögren 018-14 76 88 837627483-5 Gustavs dagar Wahlströms 018-13 87 77 472838764-2 Tempelriddaren Nordstedts Förlag 018-35 67 77 8911307151-0 Ät naturligt Nordstedts Förlag 018-35 67 77 (b) Förlag Figur 5: Andra normalformen Den andra normalformen (2NF) kräver att tabellen är i första normalformen, samt att alla attribut som inte är en nyckel är beroende av hela nyckeln. Detta kallas för funktionella beroenden (Stephens, 2010, s.146-147). Konceptet är endast väsentligt när det finns en sammansatt nyckel, alltså när en nyckel består av flera kolumner (Kent, 1983). Exempelvis är Titel i Figur 4 beroende av både isbn, som kan ses som kandidatnyckel, och Personnummer vilket gör att informationen behöver delas upp för att uppfylla andra normalformen (se Figur 5). 7
Personnummer (PK) Förnamn Efternamn isbn_id (FK) 920305-0000 Astrid Lindgren 937462739-1 920315-1111 Herman Lindqvist 837627483-5 920408-2222 Jan Guillou 472838764-2 910924-3333 Tess Ward 8911307151-0 (a) Författare isbn_id (PK) Titel Förlag_ID (FK) 937462739-1 Mio, min Mio 1 837627483-5 Gustavs dagar 2 472838764-2 Tempelriddaren 3 8911307151-0 Ät naturligt 3 (b) Bok Förlag_ID (PK) Namn Förl. telefonnummer 1 Rabén & Sjögren 018-14 76 88 2 Wahlströms 018-13 87 77 3 Nordstedts Förlag 018-35 67 77 (c) Förlag Figur 6: Tredje normalformen Den tredje normalformen (3NF) kräver att tabellen är i andra normalformen och att det inte finns några transitiva beroenden (se Figur 6). Det betyder att det inte finns något attribut, som ej är en nyckel, som är beroende av något annat attribut, som ej heller är någon nyckel. (Stephens, 2010, s.150) 2.2.2 Teknisk skuld Vid för låg grad av normalisering finns det risk för att s.k. teknisk skuld kan uppstå. Teknisk skuld kan användas som metafor till ej optimal kod. Om det intialt i ett projekt utvecklas något som inte är optimalt blir det svårare att bygga vidare på det över tid. Detta innebär att det blir dyrare och tar längre tid att utveckla funktioner ovanpå den kodbas som redan existerar. Wolff beskriver att ju mer tid som läggs på att utveckla ett system kring kod som inte är optimal desto mer ökar den tekniska skulden. Försök att kringgå problemet gör att kostnaden ökar med tiden. (Wolff och Johann, 2015) Sundvall kopplar metaforen teknisk skuld till databasstrukturen och hur det finns risk för att manuellt behöva uppdatera och mappa information när data ska förändras eller matas in i databasen (Sundvall, 2013). 8
2.3 Anomalier Begreppet anomali har sitt ursprung i grekiskan och betyder avvikelse från det normala, från en regel eller en lag (Anomali, 2016). En anomali i en databas är ett fel eller inkonsekvent data som kan uppkomma när det görs försök att uppdatera en tabell som innehåller redundant data (Hoffer m. fl., 2006 s.197). Anomalier i databaser innebär att datan inte sätts in korrekt eller saknar vissa delar och på så sätt är ofullständig. De förekommer i samband med för låg nivå av normalisering (Makowsky och Ravve, 1998). De tre typer av update-anomalier som förekommer är: insert, modification och delete. Onormaliserade databaser kan vara en bidragande orsak till att anomalier uppkommer (Westland, 1992). Anomalier åsamkar även inkonsekvent data och förlorad affärsdata (Lee, 1995). En insert-anomali uppstår när användare försöker lagra en viss typ av information som kräver att även information om en annan entitet anges (Makowsky och Ravve, 1998). Exempelvis så kräver en insert-query all information om författaren, boken samt förlaget för att den ska fungera (se Figur 3). En modification-anomali uppstår när användaren behöver modifiera data på flera olika ställen i databasen på grund av duplicering av data (Lee, 1995). För att modifiera kolumnen Förlag (se Figur 4) som finns i en tabell som är i första normalformen, kommer även förlagets telefonnummer att behöva modifieras för att inte skapa inkonsekvent data. Om Förlag existerat oberoende av Bok eller Författare hade förändringen inte skapat denna typ av anomali. En delete-anomali uppstår när information som finns i databasen tas bort av misstag vid en delete-query. Om en delete-query körs med syftet att ta bort författaren Herman Lindqvist (Figur 4) kommer även förlaget Wahlströms samt boken Gustavs dagar försvinna från databasen vilket skapar en delete-anomali. Tabellen behöver normaliseras för att inte skapa inkonsekvens i informationen då författare, bok och förlag behöver kunna existera utan att vara beroende av varandra. 2.4 Denormalisering Denormalisering är processen att minska normaliseringsgraden av databasen för att uppnå bättre systemprestanda (Hoffer m. fl., 2006 s.249). Många kommersiella databaser använder denormalisering för att reducera antalet joins, optimera evalueringen av queries samt underlätta interaktionen med användarna. Utmaningarna kan inte lösas genom ett förbättrat query interface utan utvecklare måste börja tänka om gällande själva arkitekturen på databasen (Jagadish m. fl., 2007). Genom denormalisering minskar antalet tabeller vilket gör att färre joins mellan tabellerna måste genomföras (Sanders och Shin, 2001). Ett användningsområde som är relativt stort för denormaliseringsstrategin är data warehousing. Ett syfte med data warehousing är att hämta en organisations data för att blotta den för beslutsfattare inom organisationen. Att hämta, konvertera och migrera data från databasen till de system som finns hos den organisation som är målet för informationen är ett av de områden 9
där data warehousing förekommer. Genom att användare oftast utför hämtning av data, och modifieringar av individuella attribut sällan förekommer, kan det vara fördelaktigt att denormalisera data warehouses. (Shin och Sanders, 2006) En av de negativa sidorna med alltför denormaliserade tabeller är ökad risk för de anomalier som kan uppstå i samband med insert-, delete- och modification-queries (se avsnitt 2.3). Ytterligare nackdelar med denormaliseringen är att valet att denormalisera vanligtvis resulterar i kompromisser mellan flexibilitet och prestanda. För att fatta beslut med god grund behöver kunskap finnas om hur frekvent datan uppdateras, hur serverns DBMS fungerar och hur övriga system samverkar för att leverera bästa möjliga resultat. (Shin och Sanders, 2006) Trots begreppen normalisering och denormalisering, är dessa två inte motsatser till varandra. Om en tabell inte är normaliserad innebär inte detta att den är denormaliserad. Den är då endast onormaliserad, alltså ej i den första eller någon av de högre normalformerna. (Shin och Sanders, 2006) 2.5 Data warehouse Data warehouses används för att lagra stora mängder data. Datan lagras som en multidimensionell datastruktur, och en mer denormaliserad sådan för att på ett effektivt sätt bistå med information som sträcker sig över ett stort spann. Informationen i data warehouset presenteras ofta i kuber vilket den multidimensionella strukturen är väl anpassad för. Målet med informationen i data warehouset är att på ett enkelt sätt filtrera, dela upp och lyfta ut information som är värdefull för en given verksamhet. Informationen ska vara enkel att förstå och endast det som är relevant ska visas. För att förstå hur datastrukturen ska modelleras behövs kunskap för att förstå verksamhetens behov. Även kännedom om den underliggande datakällan behövs. (Kimball och Ross, 2013) Ett data warehouse byggs genom en iterativ process, eftersom kraven på det inte på förhand är kända (Inmon, 2000). Ett data warehouse tillsammans med dess BI-verktyg måste kunna anpassa sig till förändringar. Användares behov, data och teknologin som används tenderar alla att förändras över tid. Existerande data och applikationer kopplade till datan ska inte behöva modifieras eller störas när organisationen behöver lägga till ny typ av data. (Kimball och Ross, 2013) 2.5.1 Modellering De två vanligast förekommande tillvägagångssätten för datalagring i data warehouses är dimensionell och normaliserad modellering (Breslin, 2004). Dimensionell modellering är enligt Kimball en bottom-up -strategi (Breslin, 2004). Det är en logisk designteknik med målet att presentera data på ett standardiserat sätt som är ämnat att ha hög prestanda, d.v.s. kort svarstid, när det gäller åtkomst (Connolly och Begg, 2005, s.1183). Inom denna typ av modellering används Entity-Relationshipkonceptet tillsammans med 10
ytterligare strategier. Varje dimensionsmodell består av en tabell med sammansatt nyckel som kallas för faktatabell, samt några mindre tabeller som kallas dimensionstabeller. Varje dimensionstabell har en enkel primärnyckel som är kopplad till en matchande främmande nyckel i faktatabellen. (Connolly och Begg, 2005, s.1183) Ytterligare en viktig metod inom dimensionell modellering är att alla dimensionstabellers naturliga primärnycklar byts ut till en ersättningsnyckel (en teknisk nyckel) som baseras på en simpel integerstruktur. Detta innebär att varje join som sker inom databasen baseras på de ersättande nycklarna istället för en primärnyckel. Anledningen till att primärnyckel byts ut mot en annan är för att skapa ett oberoende från själva datan i data warehouset för att få struktur i mappningen mellan datan. Den dimensionella modellen är denormaliserad för att snabbt kunna svara med relevant information. (Connolly och Begg, 2005, s.1183-1185) Den logiska strukturen, när det finns en faktatabell omgiven av dimensionstabeller med refererande data, kallas starschema (se Figur 7). Den refererande datan kan i sin tur denormaliseras (Connolly och Begg, 2005, s.1183). En alternativ form till starschema är snowflakeschema. Ett snowflakeschema tillåter dimensioner att ha dimensioner, dvs. en dimensionstabell kan ha ytterligare tabeller under sig vilket främjar en normaliserad struktur. Anledningen till att ha normaliserad data i data warehouset är att enklare kunna filtrera den data som används i det. Inom denna struktur innehåller inte dimensionstabellerna någon denormaliserad data. (Connolly och Begg, 2005, s. 1184-1185) Figur 7: Starschema Inmons normaliserade modellering är till skillnad från Kimballs en top-down -strategi. Inmon beskriver en datamodell med tre lager, där kuben designas med hjälp av ERD (Breslin, 2004). Data warehouse bygger på samma standard som traditionella relationella databaser. Tabeller grupperas enligt subject areas och följer till en viss grad normalformerna (Inmon, 2000). 11
2.6 Tidigare forskning Lee (1995) belyser i sin artikel svårigheterna med att bestämma vilken normalform som är lämplig för databasstrukturen ur ett ekonomiskt perspektiv. Han presenterar därefter en metodologi för att definiera normalformer genom en cost/benefit-modell. Lee hävdar att riktlinjerna sannolikt leder till en bättre databasdesign (Lee, 1995). Badia & Lemire (2011) beskriver hur traditionell databasdesign inte efterlevs i praktiken. En svårighet som existerar är att den teori och metodologi som finns inte ger de redskap och verktyg som krävs. Problemet försvårar metodens tillämpning i den moderna miljö som utvecklarna arbetar i idag. Forskarna belyser att traditionella metoder, dit normaliseringsteorin kvalificeras, väljs bort vid design av databaser trots att det existerar en bred teoretisk bas. De hävdar att traditionella metoder inte ger tillräckligt med vägledning hur de ska tillämpas i olika situationer, särskilt när informationen inte passar med den konceptuella modellen (se avsnitt 2.1.1). Vidare menar Badia & Lemire att denna situation medverkar till att vidmakthålla problemet och försvåra vidare utveckling av metoder för databasdesign. (Badia och Lemire, 2011) Jagadish m.fl. (2007) kontrasterar Badia & Lemires uttalande om att utvecklingen inte går framåt. De förstnämnda menar istället att de databastekniker som finns har förbättrats de senaste årtiondena. Dock är det tveksamt om det kan ses som tillräckligt då verksamheter har höga kostnader för teknisk support av databaser (Jagadish m. fl., 2007). De högre normalformerna är också problematiska då de bidrar till ytterligare underhållskostnader (Lee, 1995). Som nämnts i avsnitt 1 har bland andra Pat Helland (2007) fört en diskussion kring normaliseringen av databaser. Helland påstår att Normalization is for sissies och att normalisering av data som är oföränderlig ses som onödig. Ett exempel på data som är oföränderlig är information i databaser som loggar händelser, såsom banktransaktioner och olika typer av ordrar. De innehåller till största del beständig data eller information som endast bygger på den redan befintliga datan. Helland menar att data som är oföränderlig endast bör normaliseras om det finns en betydande anledning, exempelvis begränsningar i lagringskapaciteten. (Helland, 23.7.2007) 12
3 Metod I detta avsnitt redogörs det för vilken forskningsstrategi samt paradigm som har använts i arbetet. Här beskrivs hur insamlingen av data skett samt hur analysen av dokumenten genomförts. All exempeldata som finns med i denna uppsats är fingerad p.g.a. konfidentialitet. Vissa entiteters attribut är sekretessbelagda och därför censurerade. De kommer således inte att behandlas djupare i analysen. Företagen och kontaktpersonerna som medverkat i arbetet till uppsatsen önskar vara anonyma. 3.1 Forskningsstrategi och paradigm En fallstudie karaktäriseras av fokus på mer djupgående än bred kunskap, att fallet undersöks i sitt naturliga sammanhang och att ett holistiskt synsätt används (Oates, 2006, s.141-142). Forskningsstrategin som använts i detta arbete var av typen fallstudie, på grund av att arbetet syftade till att undersöka hur normalisering används i industrin. Att analysera databaser som används i olika verksamheter medför krav för förståelse av databasens kontext. För att förstå kontexten behövs ytterligare undersökningar i form av dialog med någon som är bekant med databasens utformning. Vidare var arbetet dels en beskrivande fallstudie, dels en explorativ sådan. Detta p.g.a. att det är ett speciellt fenomen, normalisering, som utforskas i sin kontext samt att det är verkliga fall som tolkas. Eftersom de olika databaserna analyserades på samma sätt, men i olika kontext, leder detta till att fallstudien är en flerfallsstudie. Vid flerfallsstudier analyseras först de olika fallen (d.v.s. databaserna i form av de tillhandahållna dokumenten) separat för att sedan jämföras i syfte att hitta skillnader och likheter (Oates, 2006, s.144). Arbetet har utgått från det interpretivistiska paradigm som enligt Oates (2006, s.292-293) syftar till att förstå det sociala sammanhanget av ett informationssystem och att det inte finns en sanning utan flera olika sätt att tolka verkligheten. Den kvalitativa dataanalysen och intervjuer, tillsammans med att databaserna studerades i deras naturliga kontext implicerar att interpretivism är det underliggande paradigmet för arbetet. 3.2 Val av respondenter För att försöka säkerställa spridning i insamlingen av data kontaktades flera olika typer av verksamheter. Målet var att få tillgång till databaser i olika storlek och som existerar i olika kontexter. Önskvärt hade varit att kunna genomföra analysen på ytterligare databaser. På grund av begränsad tid för utförandet av arbetet fanns inte möjligheten att genomföra analysen på ett tillräckligt stort antal databaser för att generalisering skulle vara möjlig. De databaser som kom att granskas valdes utifrån ett bekvämlighetsurval (Oates, 2006, s.144-145), där de respondenter som svarade och ansåg sig kunna ställa upp bidrog med undersökningsmaterial. De tre databaser som slutgiltligen användes tillhandahölls genom kontakter på författarnas tidigare arbetsplatser. Andra verksamheter som kontaktades ansåg sig 13
inte kunna bidra med material med hänvisning till sekretessbestämmelser. Några återkom aldrig med svar. Genom att respondensen resulterade i att de databaser som ställdes till förfogande var genom kontakter på företag där författarna av denna uppsats tidigare har varit anställda finns eventuell svarsbias som måste tas hänsyn till. Ett krav för att försöka förebygga svarsbias var att författarna av denna uppsats i sitt tidigare arbete aldrig kommit i kontakt med applikationerna och de tillhörande databaserna. Genom detta ansågs en nyanserad analys kunna genomföras. 3.3 Metodik för datainsamling Dokumentanalys och semistrukturerade intervjuer har nyttjats som datainsamlingsmetoder för uppsatsen. Eftersom det är två olika metoder som har använts tillämpas metodtriangulering (Oates, 2006, s.37). Genom detta kan rikare data erhållas, då de tolkningar som gjordes under dokumentanalysen kontrollerades genom intervju, vilket höjer kvaliteten på resultatet (Bryman och Nilsson, 2011, s.354). På så sätt säkerställdes att de antaganden som gjorts om databaserna var rättfärdigade. 3.3.1 Insamling av dokument För att samla in underlag till arbetet gjordes en förfrågan om material genom mailutskick. Mailet sändes till sex olika verksamheter inom olika branscher, inklusive en kommun. Det som efterfrågades var databasens struktur i form av t.ex. ERD, där entiteter och relationer blottas. För att kunna avgöra om tabeller var i 1NF, 2NF och 3NF behövdes även tillgång till entiteternas attribut och exempeldata. Tillsammans med förfrågan om dokument ombads mottagaren att motivera och beskriva kopplingen mellan databasen och organisationens verksamhet för att förstå kontexten. I och med att dokumenten tillhandahållits av personer inom verksamheten, som är insatta i de olika systemen och bedömts ha god insikt i databasens kontext, ses de dokument som analyserats som pålitliga och korrekta (kontaktpersonernas roller deklareras i respektive databas resultatdel, se avsnitt 4). En aspekt som behövde tas hänsyn till vid datainsamlingen var sekretessen kring databaser. I mailutskicket påpekades att sekretessbelagd information ej behövde inkluderas, och att tvättat material var av mindre betydelse. Ett företag ställde sig tveksamma att lämna ut information om databaserna och systemens struktur då de innehöll hemlig affärsinformation. Andra argumenterade för att databasstrukturen i sig inte är hemlig utan det problematiska var att lämna ut innehållet i den. Med databaserna för reservdelskataloger (avsnitt 4.1) och ärendehantering (avsnitt 4.2) erhölls både struktur med entiteter och attribut samt tabeller med exempeldata. Avsaknad av dokumentation nämner Stephens (2010, s.210) som ett problem gällande databasdesign vilket också upplevdes under arbetets gång. En av databaserna som mottogs bestod av över 200 entiteter. Tillsammans med ett ERD bifogades tabeller med primär- och främmande nycklar för varje entitet. Detta ERD var omfattande vilket medförde svårigheter för vidare analys. Därför togs ett beslut att exkludera databasen från arbetet. 14
3.3.2 Intervju Baserad på den dokumentanalys som genomfördes (se avsnitt 3.4), hölls även intervjuer för att erhålla djupare förståelse och en bredare bild av företagens tillämpningar av databasdesign. Intervjuer hölls via Skype och genom mail. Intervjuerna var semistrukturerade för att få möjlighet att öppna upp för diskussion (Oates, 2006, s.188), men innehöll även specifika frågor om den aktuella databasens design. Den struktur intervjuerna fått och de teman som diskuterats har grundats i de tolkningar som framkommit från dokumentanalysen, så som uppfyllnad av normalformer. Utifrån detta ställdes frågor och funderingar kring kontexten av databasen för att ytterligare förtydliga och bygga vidare på analysen. För att analysera intervjuerna gjordes en tematisk kodning baserad på den process som Robson (2013, s.475-476) föreslår. Det första steget var att efter genomförd intervju transkriberades den och lästes igenom. Efter att ha blivit bekant med datan påbörjades en kodning av intervjun där de segment som ansågs intressanta för arbetet markerades. Innan kodningen hade inga fördefinierade teman tagits fram för att undvika bias och inlåsningar (Robson, 2013, s.275). Intressanta teman identifierades utifrån dokumentanalysen av databasens bakgrund, strategi och design för att finna relevanta resultat inom intervjumaterialet. Två av databaserna som granskades tillhandahölls av samma IT-arkitekt (se avsnitt 4.1 och 4.2). Därför har en viss iteration funnits i intervjuerna med denna person, då karaktären av kodningen från intervjun innan påverkade vilka frågor som ställdes i den efterföljande. Sist sammanställdes resultaten från den initiala dokumentanalysen med den information som framkommit under intervjuerna. Resultatet av detta återfinns i avsnitt 4. Fördelen med att tolka data genom denna process är att den är flexibel och att resultatet utan svårigheter kan presenteras för läsaren (Robson, 2013, s.477). Den tematiska kodningen har också varit användbar då de personer som intervjuades fungerade som bidragsgivare i researchen och analysen genom att medverka med sin expertis. Nackdelen med den flexibla processen är att mycket data genereras och det kan då bli problematiskt att veta vilken data som ska fokuseras på (Robson, 2013, s.477). Detta förebyggdes genom att ha koncentration på frågor som rörde normalformerna och mest frekvent återkommande teman. En annan nackdel var att detta tillvägagångssätt inte anses ha lika god renommé som vissa andra analysmetoder (Robson, 2013, s.477). Något som i största möjliga mån försökte åstadkommas var att få kontakt med någon person väl insatt i databasens uppbyggnad och struktur. De personer som intervjuades hade roller som IT-arkitekt samt integrationskonsult. IT-arkitektens intervjuer genomfördes bl.a. via Skype och på det sättet fanns det möjlighet för korrespondenten att visa databasens kontext genom skärmdelning. Därför valdes också transkriberingen att ej göras verbatim. Intervjun med integrationskonsulten genomfördes skriftligen. Genom att intervjua en anställd på ett företag finns risk för, återigen, att det tillhandahålls en subjektiv bild. Varje individ tolkar verksamheten på sitt sätt. Databasdesign kan också möjligen inte alltid ses som något som är rätt eller fel utan är ett mer subjektivt område där bedömningar och avvägningar spelar in. Önskvärt vore att intervjua flera personer med kunskap om samma databas för att kunna redogöra för skillnader i tolkningar. På grund av begränsad tid för arbetet har detta inte kunnat genomföras. 15
3.4 Metodik för dokumentanalys En kvalitativ dataanalysmetod inkluderar all icke-numerisk data såsom ord, bilder och ljud, som är resultatet av intervjumaterial, företagsdokument, hemsidor och utvecklares modeller. Inom interpretitativa studier används till största del den kvalitativa data som genereras utifrån fallstudier. (Oates, 2006, s.266) Dokumenten har setts som behållare av information vilket innebär att de går att analysera både kvalitativt och kvantitativt (Oates, 2006, s.239). Med den kvalitativa teknik som använts i studien har olika teman i dokumenten undersökts för att sammanfatta datans sammanhang. Den metod som användes vid analysen av dokumenten var enligt Oates beskrivning (2006, s.269) av deduktiv karaktär då existerande teorier användes. Den dokumentanalysmall som upprättades kan ses som ett ramverk då den inkluderade kriterier för uppfyllnad av normalformerna (se avsnitt 3.4.1). De dokument som har använts i analysen har för varje databas varit (med undantag för databasen för filmförsäljning (avsnitt 4.3) där ingen exempeldata fanns att tillgå): ERD, beskrivning av entiteter och dess relation till varandra samt tabeller med exempeldata. En risk som finns vid kvalitativ dataanalys är hur författarnas bakgrund, antaganden och övertygelser påverkar analysen. Detta har minimerats genom att bygga analysen på en redan etablerad teori, normalisering. För att en databas ska implementera en grad av normalform måste vissa kriterier vara uppfyllda. Med teorin som bakgrund har en högre grad av objektivitet kunnat upprätthållas vilket medförde bättre kvalitet i studien. 3.4.1 Dokumentanalysmall En dokumentanalysmall upprättades för att tillvägagångssättet av analysen skulle bli likvärdigt för alla databaser. Processen började med att sammanfatta den kontext som databasen verkar i, eftersom detta kom att påverka resultatet av analysen i form av förbättrad förståelse för databasens helhet. Sedan sammanställdes ERD, tabeller med exempeldata och en beskrivning av entiteter och deras förhållande till varandra. Därefter kontrollerades, för varje relation, om kriterierna för första, andra respektive tredje normalformen uppfylldes. Detta var en iterativ process med syfte att stämma av att de antaganden som gjordes var korrekta. De dokument som erhållits har granskats utförligt och den kontext som databasens information förhåller sig till har först tolkats av respondenten i verksamheten och sedan av uppsatsens författare. Kontextbeskrivningen är något som varit kritiskt för att fastställa huruvida motiveringar och strategier är rimliga för respektive databas. Genom denna process finns det risk för att tolkningen av databasens kontext blivit något subjektiv, däremot bör de ERD:s som tillhandahållits ses som en objektiv bild av databasens uppbyggnad. 16
4 Resultat I detta avsnitt presenteras de resultat som tillhandahölls genom att tillämpa metoden som beskrivs i kapitel 3 på det insamlade materialet. Varje databas presenteras var för sig och resultatet grundar sig i den dokumentanalys som genomfördes av databasen samt de intervjuer som utförts. Först ges en kort presentation av företaget följt av kontexten där databasen verkar. De delar av databaserna som närmare presenteras är bitar som har en central roll i databasens uppbyggnad, där det anses har funnits problem eller ämnen som de intervjuade personerna själva har lyft fram. Figur 8 visar en överblick av de databaser som presenteras i avsnittet. Allt material som presenteras är sådant som respektive företag gett samtycke till att publicera i uppsatsen. Databas Databastyp Typ av verksamhet Intervjuperson Miljö Bilder till kataloger OLTP Fordonstilverkare IT-arkitekt Rapportering över ärendehantering OLAP En kommun* IT-arkitekt Statistik över filmförsäljning** OLAP IT-tjänsteföretag Integrationschef Applikation för att skapa kataloger för reservdelar, produkter, servicemanualer etc. Kubmiljö för att skapa rapporter över incidenter inom en organisation för att sedan kunna följa upp om SLA uppfylls. Data warehouse för lagring av tillgängliga filmer och försäljningsstatistik över dessa. * = driftas av samma företag som databasen för bilder till kataloger. ** = fingerat för att anonymisera. Figur 8: Översikt av material 4.1 Databas för bilder till kataloger Databasen tillhandahölls av ett företag verksamt inom fordonsindustrin. Företaget har ett brett utbud av fordon och tillhandahåller även service och reservdelar. Deras produktionsanläggningar finns i ett flertal länder runt om i världen. Fordonen distribueras främst via fristående försäljare. 4.1.1 Bakgrund Applikationen skapades runt 1995 och används som ett internt system för reservdelskataloger, servicemanualer och liknande. Databasen innehåller bilder på fordon och reservdelar och den används som en bildmapp som organiserar bildernas kopplingar till olika kataloger. Den finns integrerad med andra system (som bl.a. översättare och artikelbeskrivningar) som gör att slutresultatet kan bli både digitala och tryckta kataloger. Katalogerna i PDF-format har funktionen att när användaren klickar på en reservdel länkas den till delens detaljlista och artikelnummer (s.k. hotspot) för att underlätta beställningar. 17
Figur 9: ERD - bilder till kataloger 4.1.2 Uppbyggnad och designval Nedan presenteras de delar av databasens uppbyggnad (entiteter) som är centrala för vidare diskussion genom att det exempelvis har funnits brott mot normalformer. Det ERD som granskats presenteras i Figur 9. Intervjuer genomfördes både genom mailkontakt och i mötesform via Skype. Personen som intervjuades arbetar som IT-arkitekt på företaget sedan tio år tillbaka och har drygt 30 års erfarenhet inom branschen. 18
IMAGE IMAGE är en tabell för bildentiteter med egenskaper som format, vem som skapat bilden, kostnad och fritext. IMAGE är den mest centrala entiteten med relationer till ett flertal andra entiteter. Det finns kopplingar som har att göra med vilka giltiga format som bildentiteten kan ha. Det finns även tabeller för att spara kopplingar till reservdelskataloger och giltiga produktlinor. Figur 10 visar ett exempel på hur en katalogsbild ser ut. IMAGE har en rekursiv relation till sig själv. Denna relation innebär att varje bild kan ha en förälder-till-barnrelation. IMAGE kan skapas från en redan existerande entitet och får då förälderns IMAGEID som PARENT_IMAGEID som koppling till originalentiteten. Anledningen till att funktionen som tillåter skapandet av nya bilder från en redan existerande är företagets behov av att kunna skapa nya versioner av redan existerande produkter. Det finns möjlighet att göra små förändringar från originalet till en ny entitet och sedan länka till dess förälder för att kunna spåra bildernas relation. Om entiteten uppfyller 1NF kan diskuteras. Kolumnen I_NAME innehåller både för- och efternamn. Dock bör detta endast ses som ett och samma värde då företagsnamn ibland används i denna kolumn. Figur 10: Exempel på katalogbild ILLUSTRATOR ILLUSTRATOR är en tabell för illustratörer som skapat bilderna som används i katalogerna. De egenskaper ILLUSTRATOR har är olika kontaktuppgifter så som adress, telefonnummer och företagsnamn. ILLUSTRATOR är direkt kopplad till IMAGE, en IMAGE kan ha en ILLUSTRATOR och en ILLUSTRATOR kan ha flera IMAGE. I_NAME är primärnyckel i entiteten och består av en illustratörs namn. Vid frågan om varför namn används som identifierare berättar IT-arkitekten att ha ett namn som primärnyckel är en osäker identifierare och ställer till problem om det existerar två illustratörer med samma namn. Nyckeln är alltså inte optimal men detta är något som inte vidare diskuteras i denna uppsats. Adressen, som består av I_ADRESS, I_POSTALCODE och I_PADRESS, är här beroende av företagets (I_COMPANY) ort, som inte är en nyckel och med den anledningen anses inte entiteten uppfylla 3NF. I och med att I_COMPANY inte är en egen entitet och genom att det inte finns någon relationskoppling till ILLUSTRATOR kan inte I_COMPANY existera oberoende, utan all data finns i samma tabell. Under intervjun motiveras denna design genom att applikationen först var tänkt endast som ett internt system inom verksamheten. De 19
illustratörer som användes i början var anställda på företaget och därav skulle inte attributet I_COMPANY användas. Det fanns även personer som slutade och startade egen verksamhet, vilket gjorde att det konstruerades en ny post åt personen och I_COMPANY började användas. Vidare ändrades kraven på systemet och företaget ville börja använda databasen för att skapa offerter. USER USER är en tabell för användare av applikationen. USER har i sin tur en relation till USERPERMISSION samt en tabell över tillgängliga språk, LANGUAGE. USER har ett attribut, U_PERMISSIONLEVEL som anger vilken typ av grupp användaren tillhör där USER kan ha rollen som administratör, user eller viewer. Detta anger hur mycket som kan manipuleras i de bilder som finns i databasen. IT-arkitekten anser att U_PERMISSIONLEVEL rimligtvis borde ha ett mer distinkt namn, exempelvis U_ROLE, för att förtydliga vilken typ av toll som anges. Detta återspeglas i USERs relation till tabellen USERPERMISSION som är mer övergripande och anger den behörighet som finns per CATEGORY, där CATEGORY är ett attribut för varje typ av katalog som finns. PERMISSIONLEVEL anger här om tillåtelse finns för att uppdatera eller bara visa inom respektive kategori. IT-arkitekten påpekar att andra namn borde valts för respektive attribut, U_PERMISSIONLEVEL för USER och PERMISSIONLEVEL för USERPERMISSION, för att skapa mer tydlighet. 4.2 Databas för rapportering över ärendehantering Denna databas finns i en svensk kommuns verksamhet där den används inom bl.a. skolor och förvaltningar. Fordonsföretaget sköter drift och underhåll av denna kub och genom detta kan de båda parterna följa upp att SLA uppfylls (de villkor som finns mellan kommunen och aktörerna). Materialet tillhandahölls av samma IT-arkitekt som den för reservdelskataloger och det är också denna person som har intervjuats. 20
Figur 11: ERD - SLA 21