Transformering från objektmodell till tabeller i databasen

De klasser som identifierats i analysen överförs till datamodellen för transformering till

tabeller i databasen, är de som visas i objektmodellen, Figur 11. Överföringen sker i

detta exempel manuellt till Erwin. De främmande nycklarna förs på automatiskt i den

logiska modellen när relationerna sätts mellan klasserna, Figur 13.

Efterhand som sekvensdiagrammen förfinas under designfasen, kommer operationer att

tillföras i objektmodellen. Att detta sker i ett senare skede påverkar inte

transformeringen till tabeller i databasen, eftersom det är klassernas struktur

innehållande attribut och relationer som överförs och inte operationerna.

Figur 13 Datamodellen beskriven i Erwin (logisk modell)

Då datamodellen skapas tas hänsyn till ifall varje klass ska lagras i en eller flera

tabeller. Uppdelningen kan ske horisontalt eller vertikalt (Raumbaugh 1991). Det som

skulle kunna motivera en uppdelning av en klass horisontalt är ifall en klass har många

instanser varav några få kommer att refereras till ofta. De som refereras ofta till skulle

då lagras i en tabell och de övriga i en annan, för att på så sätt öka effektiviteten vid

sökning. Det som skulle kunna motivera en vertikal uppdelning av en klass är ifall en

klass har attribut med olika åtkomstmönster, dvs vissa attribut används ofta vid

sökningar medan andra sällan behövs. I bokhandelsexemplet kommer ingen uppdelning

av klasserna att göras utan varje klass mappas mot en tabell. Den historik över

beställda varor som lagras i separata tabeller, kan ur en synvinkel ses som en horisontal

uppdelning av BestOrder och OrderRad, men alla operationer från BestOrder- och

Orderradtabellerna kan inte användas på historiktabellerna. Detta eftersom inget ska

kunna ändras i efterhand, dvs de tabellerna blir bara möjliga att läsa inte att förändra.

Generalisering kan transformeras på olika sätt (Rumbaugh 1991):

Superklassen och subklasserna lagras som egna tabeller och kopplas samman genom

att lagra superklassens primärnyckel som främmande nyckel i subklasserna. Ett

problem som kan uppstå här är ifall primärnyckeln från superklassen inte ska få finnas i

båda subklasserna, dvs uteslutande generalisering. Exempelvis en anställd kan inte vara

både expedit och kontorspersonal. Det behöver skrivas speciell kod för att ta hand om

denna integritetsföreskrift då SQL inte har kapacitet att övervaka efterföljandet av en

regel för uteslutande delning, som indikeras av generalisering. Det är inte alltid som

uteslutande generalisering krävs och då behövs ingen sådan föreskrift.

Superklassen och subklasserna skapas som en tabell. Detta är en lösning som endast är

användbar om det finns två eller tre subklasser med få attribut. Detta eftersom det

annars blir många fält som inget lagras i. Exempelvis registreras inget bonusunderlag

för kontorspersonal och inget specificerat ansvarsområde för butikspersonal, figur 13.

Det går också att dela upp tabellerna efter de subklasser som finns. Attributen från

superklassen lagras då en gång i varje subklasstabell. Det blir alltså redundant lagring

av superklassens attribut i de olika subklasserna.

Vid multipla generaliseringar bör generaliseringen mappas på så sätt att en tabell för

superklassen och en för varje subklass används. Vill man optimera mappningen för att

undvika mycket överlappning av information vid multipel generalisering, skapas även

en tabell för att lagra generaliseringsrelationen. Detta är dock oftast inte värd mödan

då multipel generalisering är sällan förekommande. Med multipel generalisering avses

generalisering i flera nivåer.

I bokexemplet har varianten med en tabell för superklassen och en tabell för varje

subklass valts, Figur 13. I bokhandelsexemplet finns det inte många attribut i varje

subklass, men attributet idanställd används ofta och därför är det i detta fall att föredra

separata tabeller framför en enda tabell med både super och subklasser.

Varje attribut tilldelas en domän, dvs en datatyp, Figur 14. Primärnycklar identifieras

och förs på tabellerna. Som primärnyckel kan ett genererat id användas. Antingen kan

detta genereras från databasen eller också kan det t ex skapas ett speciellt objekt som

endast har till uppgift att generera id till de olika tabellerna. En fördel med genererade

id gentemot att använda namn eller dylikt som primärnyckel, är att id som består av

genererade nummer inte kan kollidera, som exempelvis ifall namn används och det

finns två Stina Svensson anställda.

Ett annat vanligt sätt att få fram primärnyckel när det gäller personer, t ex anställda, är

att använda personnummer som primärnyckel. Eftersom anställningsid kan komma att

användas som identifiering gentemot kund, t ex på kundens kvitto respektive

beställningsorder, kan det dock anses som integritetskränkande att behöva lämna ut

personnumret så allmänt. Ifall ett separat anställningsid ändå måste finnas, kan det

alltså likaväl genereras automatiskt och användas som primärnyckel.

Det finns ytterligare en fördel av att använda inte informationsbärande primärnycklar,

dvs genererade id. Vid uppdatering av information i en rad, dvs tuppel, behöver inte

primärnyckeln ändras. Ifall en informationsbärande primärnyckel används och behöver

uppdateras måste alla främmande nycklar, som eventuellt finns och pekar på denna,

Genomförande

också uppdateras. Detta görs inte automatiskt utan måste tas omhand med t ex en

trigger med dominoeffekt på uppdateringen (eng. cascading update).

Ordernummer och orderrader är naturligt att generera automatiskt, då inget annat

identifieringssätt är bättre. I samtliga klasser som tagits fram i bokhandelsexemplet

används genererade id, med stöd av det resonemang som förts ovan.

Figur 14 Datamodell beskriven i Erwin (Fysisk modell som kan användas för att

automatgenerera tabeller till databasen

Det anges ifall ett värde får anta Null, dvs om det får anta Null behöver inte något

värde anges för attributet. Det anges också ifall värdet måste vara unikt i tabellen, t ex

primärnyckeln måst alltid vara unik. I de flesta relationsdatabaser behöver det inte

ytterlikare specificeras att primärnyckeln ska vara unik och inte får anta Null, men det

kan finnas andra attribut i ett system som man önskar ska vara unika och inte ska få

anta värdet Null. Det kan ofta specificeras vid skapandet av databasens tabeller.

Då vissa attribut i tabellen oftare än andra används vid sökning är det bra att skapa

sökindex på de attributen. Genom att skapa sökindex uppnås en snabbare åtkomst av

dessa ofta använda attribut. I system som till stor del vänder sig till slutanvändare är

det särskilt viktigt att tänka på att unikt identifiera för kunden lättidentifierade attribut,

som t ex namn och andra ofta använda attribut, och skapa separata index för dessa.

De olika relationerna association, aggregat och generalisering ska också transformeras

på lämpligt sätt (Rumbaugh 1991). Om en många till många relation finns blir detta en

egen länktabell där primärnycklarna från de båda tabellerna finns som en sammansatt

primärnyckel för länktabellen. I bokhandelsexemplet finns en sådan relation mellan

klassen Boklager och klassen Författare. Det resulterar i en länkklass BokFörfattare

vilket kan ses i figur 14.

nyckel i den tabell som har många relationen. Det går också att implementera denna

typ av relation som en egen tabell. De fördelar som det innebär att representera

relationen med främmande nyckel är att det blir få tabeller och snabbare åtkomst av

data tack vare färre tabeller att söka i. Det finns även nackdelar med att beskriva

relation mellan tabeller med främmande nyckel, då en asymmetrisk representation av en

association kan medföra mer komplex sökning och uppdatering. Mindre inkapsling och

reducerad utökningsmöjlighet vad gäller kardinaliteten i relationen är också på

minussidan. Det är alltså en avvägning som görs med hänsyn till applikationen. I

bokexemplet beskrivs ett till många associationer konsekvent med främmande nyckel, i

den tabellen med många relationen. Fördelarna med snabbare sökning och färre tabeller

överväger här och flexibilitet i systemet är inte ett överordnat kriterium.

Vid en ett-till-ett association förs samma resonemang som för ett till många, med den

skillnaden att det inte finns någon fördel som indikerar i vilken av tabellerna som den

främmande nyckeln bör placeras.

Aggregat är en starkare form av association och representeras i datamodellen av

ett-till-många relation samt följer samma regler som för associationer. Detta kan ses i

datamodellen figur 13, där i bokhandelsexemplet klassen OrderRad är ett aggregat till

klassen BestOrder och representeras som en ett-till-många relation.