Dmitrijs Pozdņakovs

UML MODEĻA TRANSFORMĀCIJA OBJEKTU-RELĀCIJU SHĒMĀ

Studiju darbs

Vadītājs: Dr. sc. ing. prof. Eiduks

2005. gads

ANOTĀCIJA

Objektu – relāciju datu bāzes (ORDB) paplašina relāciju datu bāžu iespējas strādāt ar

objektiem. Referāta ir apskatīta objektorientēta UML modeļa transformācijas iespējas OR

shēmā.

No sākuma ir pievērsta uzmanība OR produktu īpatnībām un trūkumiem. Tālāk ir

apskatīti OR produktu pamatjēdzieni (objektu tipi, objektu atribūti, atsauces un tml.) un ir

piedāvātas dažas UML modeļa (precīzāk UML statiskās struktūras diagrammas) elementu

transformācijas, kuriem par pamatu ir ņemti šie pamatjēdzieni. Beigās, ir piedāvāts sakārtots

transformācijas procesa apraksts ar vairākiem transformāciju piemēriem.

Tā kā pagaidām nav izveidots vienots RODB sistēmu standarts, diezgan bieži aprakstos

tiek ņemta terminoloģija no konkrētiem RODB produktiem (no Oracle8, Informix Dynamic

Server vai no DB2 Universal Data Base (UDB) ORDB vadības sistēmas) vai no topoša SQL3

standarta. Transformācijas piemēri ir realizēti izmantojot Oracle8 datubāzes vadības sistēmas

iespējas.

Referāts satur 18 lappuses izklāstā tekstā, 10 attēlus, 2 nodaļas un izmantojamas

literatūras sarakstu.

2

SATURS

1. OBJEKTU-RELĀCIJU DATU BĀZES..............................................................................4

1.1. ORDBVS īpatnības......................................................................................................4

1.2. ORDBVS trūkumi.......................................................................................................5

2. UML MODEĻA TRANSFORMĀCIJA OBJEKTU-RELĀCIJU SHĒMĀ........................6

2.1. RODB datu tipi............................................................................................................9

2.2. UML datu tipu pārveidošana RODB objektu tipos...................................................10

2.3. UML asociāciju pārveidošana...................................................................................10

2.3.1. Objektu atribūti........................................................................................................11

2.3.2. Atsauces...................................................................................................................12

2.3.3. Kolekcijas................................................................................................................13

2.4. Uzvedība....................................................................................................................14

2.5. Transformācijas shēma..............................................................................................14

3. LITERATŪRAS SARAKSTS...........................................................................................18

3

1. OBJEKTU-RELĀCIJU DATU BĀZES

Objektu relāciju datu bāzes vadības sistēmas (ORDBVS) papildina relāciju datu bāžu

iespējas un ļauj strādāt ar objektiem.. ORDBVS bieži tiek sauktas par universāliem serveriem,

galvenokārt tāpēc, ka tie var darboties ar jebkurā tipa datiem (vismaz pēc DBVS izstrādātāju

vārdiem). Tālāk apskatīsim galvenās ORDB sistēmu īpatnības.

1.1.ORDBVS īpatnības

ORDBVS papildina relāciju datu bāzes vadības sistēmas (RDBVS) ar šādam iespējam:

1. Lielo (sarežģīto) objektu datu tipu (Large Objects. LOB) atbalsts:

ORDBVS atbalsta datu tipus, kas ļauj atspoguļot un glabāt sarežģītus objektus (LOB).

Faktiski ORDBVS nodrošina iespēju glabāt un izgūt patvaļīgu bitu kopu, kā arī nodrošina

funkcijas, kas ļauj strādāt ar šiem datiem. Standarts ANSI SQL3 izšķir trīs LOB veidus:

BLOB – BYNARY LARGE OBJECT

CLOB – CHARACTER LARGE OBJECT

NCLOB – NATIONAL CHARACTER LARGE OBJECT

Diemžēl LOB ir vismazāk standartizēta sadaļa starp ORDBVS sistēmām.

2. Paplašināto datu tipu (Extended Data Type, EDB) atbalsts:

ORDBVS produkti paplašina savas tipizēšanas sistēmas, ieviešot lietotāju-definēta tipa

(User Defined Type, EDF), abstraktu datu tipa (Abstract Data Type, ADP) un objektu tipa

atbalstu.

3. Vairāku vērtību datu tipu (ieliktas tabulas, masīvi) atbalsts:

Daudzie, bet ne visi ORDBVS produkti atvieglina pirmās normālformas ierobežojumus,

atļaujot izmantot ieliktas tabulas un masīvus kā atsevišķas kolonas vērtību.

4. Objektu identitātes jēdziena ieviešana:

Tāpat , daudzie (bet atkal ne visi) ORDBVS produkti ievieš objektu identitātes (OID)

jēdzienu. OID ļauj unikāli identificēt noteikta tipa objektu, kā arī savienot tabulas, kuri glabā

šos objektus, izmantojot atsauces uz OID vērtībām.

5. Speciālo valodas paplašinājumu ieviešana, kas ļauj izmantot iepriekšminētas

iespējas:

ORDBVS produkti ievieš nozīmīgas izmaiņas sistēmu struktūrā, lai nodrošinātu

iepriekšminēto iespēju izmantošanu. Piemēram, tiek ieviestas tipu pārveidošanas (Cast)

4

operatori, kurus ir iespējams izmantot, lai konstruētu lietotāju objektus. Oracle8 ORDBVS

ievieš metodes, kuras ir iespējams pievienot lietotāja definētam tipam.

1.2.ORDBVS trūkumi

Neskatoties uz RODB tehnoloģijas priekšrocībām, ir vērts atzīmēt dažus punktus, kuri

acīmredzami apgrūtina ORDB tehnoloģiju izmantošanu:

1. RODB ievieš jauninājumus tipizēšanas sistēmā, līdz ar to prasa ieviest izmaiņas

arī SQL valodā. Taču eksistējošais SQL standarts (respektīvi, tehnoloģiskās

iespējas) neatļauj to izdarīt vienkārši. Katrs izstrādātājs ievieš savu, atšķirīgu no

citiem risinājumu. Līdz ar to pagaidām nav piekrišanas starp RODBVS

izstrādātiem par vairākiem būtiskiem jautājumiem.

2. RODB produkti ievieš daudz jaunu, nestandartizētu pieeju darbam ar RO datu

bāzēm. Daudzie no jauninājumiem neatbilst topošam SQL3 standartam. Līdz ar

to tiek ievērojamo apgrūtināta līdzekļu izvēle RODB realizācijai.

3. Funkcionālo iespēju daudzveidībā padara grūtu vienotas pieejas izvēli, kas ļautu

transformēt UNL datus ORDB shēmā.

5

2. UML MODEĻA TRANSFORMĀCIJA OBJEKTU-RELĀCIJU

SHĒMĀ

Tālāk ir pievērsta uzmanība jautājumiem, kuri ir saistīti ar UML modeļa transformāciju

RODB shēmā. Ir apskatīti atsevišķie RODB shēmas elementi un to iespējami pielietojumi

UML diagrammas pārveidošanai. Beigās ir dots transformācijas shēmas apkopojums.

Lai ilustrētu transformācijas procesu, referātā ir piedāvāts informācijas sistēmas UML

modelis (sk. 2.2. un 2.3. attēlus) [1].

2.2. attēlā ir paradīta personu apakšsistēmas klašu diagramma. Personu apakšsistēma

satur klasi Person un Identification klašu hierarhiju, kas pieder dotai persona. Cilvēki (no

klases Person) spēle noteiktu lomu vienā vai vairākās organizācijās. Minēta saite tiek

atspoguļotas ar trīspusējas asociatīvas saites palīdzību starp klasēm Person, Role un

Organization. Klašu redzesloks „Organization::” norāda uz to, ka minētas klases pieder

apakšsistēmai Organization.

Organizāciju apakšsistēma (sk. 2.3. attēlu) ietver organizāciju hierarhiju, kura iekļauj

CriminalOrganization klasi. Organizāciju apakšsistēma ietver arī klasi Role un trīspusējo

saistību starp organizācijām, personām un lomām.

Apakšsistēma Entity apvieno iepriekšminētas apakšsistēmas un apakšklasi Entity, no

kuras tiek mantotas klases Person un Organization kopā ar atbilstošiem pakotnēm (sk. 2.1.

attēlu).

2.1. att. Apakšsistēma Entity UML diagramma

6

2.2. att. Personu apakšsistēmas UML diagramma

7

2.3. att. Organizācijas apakšsistēmas UML diagramma

8

2.1.RODB datu tipi

Galvenā ORDBVS priekšrocība ir spēja strādāt (respektīvi, glabāt, reprezentēt un

apstrādāt) ar viss dažādākiem datu veidiem. Izstrādātajām ir nepieciešams pareizi izlemt, kuru

no iespējamām datu struktūrām izvēlēties, konkrētas problēmas risināšanai.

RDB sistēmās izstrādātāji operē ar iebūvētiem datu tipiem, kuri tiek asociēti ar

atsevišķiem tabulas laukiem (piemēram, NUMERIC, FLOAT, VARCHAR, TIMESTAMP

u.c.).

RODB sistēmās situācija ir citāda. Piemēram, SQL3 standarts definē šādus jaunus datu

tipus:

Lietotāja definēts tips (User Defined Type, UDT) – tips, kurš tiek definēts ar

CREATE TYPE izteiksmi. Tipu ir iespējams izmantot atsaucēs, mantošanās

attiecībās, atgriežot vērtību no lietotāja funkcijas, tipu pārveidošanas izteiksmēs

un galvenais, definējot tabulas. Izšķir atsevišķu un strukturētus lietotāju tipus.

Atsevišķs tips (Distinct UDT) atsaucas uz iepriekšdefinētu, iebūvētu datu tipu,

turpretī strukturēts lietotāja (Structured UDT)tips ir datu struktūra, kas apvieno

vairākus datu atribūtus.

Rindas tips (Row type) – tips, kurš reprezentē datu rindas struktūru.

Atsauces tips (Reference Type) – atsauce uz lietotāja definēto tipu, tiek

izmantota atsaucoties uz datu struktūru no tabulas lauka.

Datu kolekcijas tips – daudzvērtību tips, piemēram, masīvs – vienveidīga,

sakārtota datu kopa.

CLOB – liels datu masīvs simbolu datu glabāšanai.

NCLOB – CLOB, kurš glabā vairāku baitu simbolus, kurus definē vienā no

SQL3 simbolu tabulām.

BLOB – liels datu masīvs bināro datu glabāšanai.

SQL3 iekļauj objektu orientētas funkcijas, kas ļauj realizēt datu aizsardzību

(inkapsulāciju) un mantošanu.

Daudzi ORDB produkti piedāvā dažādu SQL3 standarta daļu realizāciju, taču neviens

nerealizē pilno standarta prasību klāstu. Tālāk ies runa par visbiežāk sastopamiem RO

jēdzieniem: objektu tips, lielais objektu tips, kolekcija, atsauce un uzvedība.

9

2.2.UML datu tipu pārveidošana RODB objektu tipos

OR sistēmās objekta jēdziens ir atdalīts no tabulas jēdziena. Respektīvi, OR sistēmas

nemēģina pārdefinēt tabulu ar objektu tipa palīdzību. Termins objektu tips ir Oracle produktu

lietotāju definēta tipa nosaukums. Vēl viens, taču vairāk teorētisks, sinonīms terminam objektu

tips ir abstrakts datu tips (ADT). Nav nekādas vajadzības piešķirt dotajiem terminiem atšķirīgo

teorētisko nozīmi, jo faktiski iet runa par vienu un to pašu būtību, kurai tiek piešķirti dažādo

izstrādātāju izdomāti nosaukumi.

Datu tips definē datu semantiku, operācijas, kuras ir iespējams veikt ar dotā tipa datiem,

kā arī nosāka, kādas vērtības var pieņemt dota tipa mainīgie. Objektu tipiem semantiku uzdot

lietotājs.

UML valoda definē vienkāršus datu tipus , datu tipus, kuru mainīgiem nav identitātes,

bet tikai vērtība. Vienkāršie datu tipi iekļauj primitīvus iebūvētus datu tipus (tādus, kā integer

vai string), struktūras un sarakstus. Līdz ar to UML vienkārša datu tipa klasifikatoram

„DataType” ir trīs apakštipi: „Primitive”, „Structure” un „Enumeration”. UML diagrammas

datu struktūras ar „DataType” klasifikatoriem pārveido primitīvos ORDB datu tipos.

Klašu un interfeisu UML klasifikatori „Class” un „Interface” atbilst OR strukturētiem

objektu tipiem. Relāciju datubāzēs klases tiek pārveidotas tabulās, bet interfeisi glabājamās

procedūrās. OR sistēmās klases un interfeisi var tikt pārveidoti gan relāciju tabulās, gan

strukturētos objektu tipos, kurus definē ar CREATE TYPE palīdzību.

2.3.UML asociāciju pārveidošana

Šeit apskatīsim, kā realizēt UML statiskas struktūras asociācijas. Ir pievērsta uzmanība

šādiem asociāciju veidiem:

Ģeneralizācija (mantošana):

Semantiskā asociācija

10

Daudzie pret daudziem asociācija:

Viens pret daudziem asociācija:

Agregācija

Veidot UML asociācijas OR sistēmās ir grūti, tāpēc, ka ir pārāk daudz iespēju, kā tos

realizēt:

Ar ārējo atslēgu palīdzību, veidojot parastas saites 1:1 un 1:M starp relāciju

tabulām.

Izmantojot objektu atsauces un objektu atribūtus.

Izmantojot objektu kolekcijas

Lai izvēlēties vienu no pieejām ir jāiepazīstas ar objektu atribūta, atsauces, kolekciju

koncepcijām.

2.3.1. Objektu atribūtiObjektu atribūts ir objektu tipa atribūts, kurš glabā strukturēta objektu nevis iebūvēto

datu tipu. Relāciju tabulas glabā savās kolonnas tikai primitīvas vērtības. Vērtībām nav

atsevišķas identitātes ārpus dotas tabulas rindas robežām. Objektiem vienmēr ir ārēja, unikāla

identitāte. OR datu bāzē tabula (objektu tabula) sastāv no objektiem, kur katrai tabulas rindai

atbilst unikālais objekts, kurš savukārt var iekļaut arī citus unikālus objektus.

Kopēja agragācija (shared agragation):

Class7 nepieder Class6

Kompozīcija(Composition):

Class7 pieder Class6

11

Faktiski objektu atribūti veido UML kompozīcijas asociāciju, ar kardinalitāti 1..1 vai 1..0

tajā klases pusē, kura atspoguļo ielikto (jeb pakļauto) objektu. Nedaudz modificējot 2.2.

piemēra attiecības starp klasēm Person un Identification, mēs dabūjam šādu kompozīciju, kuru

var realizēt ar objekta atribūta palīdzību:

2.4. att. Kompozīcijas piemērs, kuru var realizēt ar objekta atribūta palīdzību

2.3.2. AtsaucesAtsauce ir loģiskai radītais uz objektu, kurš glabājas RODB tabulā. Atsauce ir realizēta,

kā objekta identifikators, jeb OID. RODBVS ģenerē OID katram strukturēta tipa objektam. Ar

OID palīdzību var atsaukties uz objektu, ieliekot OID vērtību tabulas kolonnā. Ar atsauces

palīdzību ir iespējams izgūt nepieciešamo objektu SQL vaicājumā, neizmantojot tabulu

savienošanu ar ārējo atslēgu palīdzību.

Ar OID palīdzību ir iespējams realizēt vienkāršas asociācijas starp objektiem, un šīs

asociācijas vairs nav ierobežotas ar stingriem kompozīcijas nosacījumiem. OID ļauj vienkārši

realizēt viens pret daudziem semantisko asociatīvu attiecību, piemēram (no 2.2. attēla):

2.5. att. Semantisko asociāciju piemēri, kurus var realizēt ar atsauces palīdzību

Galvenais objekts ar objekta atribūtu Identifikācijas numurs

Atribūtā ieliktais objekts

Adreses tipa objekti atsaucas uz objektiem Persona

Var arī otrādi: Persona objekti atsaucas uz Adreses tipa objektiem

12

Taču ir jāņem vēra šādu nosacījumu: ORDBVS neiekļauj mehānismus atsauces

pareizības pārbaudei, līdz ar to izstrādātājam ir jārēķinās ar papildus izdevumiem aizsardzības

mehānisma realizēšanai.

Pie tam ar OID palīdzību var realizēt tikai vienā pusē virzītas semantiskās asociācijas, jo

objektam, uz kuru atsaucas, nav nekādas informācijas par šo asociāciju.

2.3.3. KolekcijasKolekcija ir atribūts, kurš satur vairākas vienā tipa vērtības (masīvs, kopa vai tabula) .

SQL3 standarts paredz tikai vienu kolekcijas tipu masīvu ARRAY. Oracle8 realizē masīvu

VARYING ARRAY un ieliktās tabulas. Informix piedāvā kolekcijas – sarakstus:

SET,MULTISET un LIST. Kolekcijas mērķis ir apvienot objektu kopu vienā kolonnā.

Ar kolekcijas palīdzību ir iespējams realizēt viens pret daudziem vai daudzi pret

daudziem semantiskās asociācijas, viens pret daudziem kopējas agregācijas vai kompozīcijas.

Piemēram, apskatīsim asociāciju starp klasēm Person un Identification (sk. 2.2. attēlu).

Katrai personai ir virkne identifikācijas dokumentu. Šī ir kompozīcijas asociācija, līdz ar to

informāciju par identifikācijas dokumentiem ir jāglabā, kā personas objekta sastāvdaļu.

Realizēsim šo asociācijas ar Oracle8 VARYING ARRAY palīdzību. Ierobežosim identifikācijas

dokumentu skaitu ar 20 gabaliem, jo Oracle masīvam ir jābūt ar iepriekšdefinētu garumu. Līdz

ar to mēs saņemam 1 pret 20 kompozīciju starp klasēm Person un Identification:

2.6. att. 1 pret daudziem kompozīcijas realizācija, izmantojot Oracle8 masīvu

Lai realizētu kopējo agregāciju (agregācija, kura nav kompozīcija), ir ieteicams izmantot

masīvu no atsaucēm. Piemēram, apskatīsim klases Person un Address 2.2. attēlā. Katra

personas var būt pierakstīta vairākās adresēs. Mēs varam realizēt šo saiti, pievienojot objektam

Person kolekciju no atsaucēm uz Address objektiem. Taču ir jāņem vērā faktu, ka Address

objektiem nav nekādas informācijas par šo saiti.

CREATE TYPE IdentificationDocuments_tAS VARYING ARRAY (20) OF Identification;

CREATE TYPE Person_t AS OBJECT (PersonID INTEGER,. . . ,IDs IdentificationDocuments);

13

Līdz ar to kolekciju no atsaucēm ir ieteicams izmantot tikai kad ir nepieciešams realizēt

vienā pusē virzīto asociāciju un tikai optimizācijas nolūkos, jo minēta shēma ar atsaucēm

neļauj automātiski (ar ORDBVS līdzekļiem) uzturēt datubāzes integritāti.

2.4.Uzvedība

Relāciju datu bāzēs UML objektu metodes tiek transformētas glabājamās procedūrās un

trigeros. OR datubāzes tikai nedaudz maina šo shēmu, ieviešot dažus jaunus veidus, kā

pievienot uzvedību objektiem. Piemēram, Oracle8 ORDBVS realizē metožu pievienošanu

objektu tipam. SQL3 standarts to nedara, tajā vietā ieviešot virkni standartoperāciju ar objektu

atribūtiem (get set metodes), konstruktorus un tipu pārveidošanas funkcijas.

Ir vērts transformēt tikai tās metodes, kuras pilda servera operācijas. Operācijas, kuras

tiks pildītas tikai operatīvā atmiņā nekandidē uz transformācijām uz servera pusi.

2.5.Transformācijas shēma

Tagad, kad tika apskatīti OR pamatobjekti var apskatīt UML modeļa transformācijas

procesu OR shēmā. OR shēmas izveidošanas process ietver divus pamat soļus: pirmkārt ir

jāizveido objektu tipus un tabulas visiem UML klasēm, otrkārt ir jāizveido tabulas „daudzie

pret daudziem” un trīspusējām asociācijām. Sīkāk šīs process izskatās šādi:

1. Pirmkārt ir nepieciešams identificēt klases, kuras jau ir realizētās un atbilst

izmantotas ORDBVS paplašinājumiem. Šī pieeja der specifiskām sistēmām, kas

darbojas ar lieliem objektiem, piemērām attēlu apstrādes sistēma vai ģeogrāfiskā

sistēma. Šajā gadījumā ir jāsameklē un jāpielieto atbilstošu bāzes tipu. Piemēram,

attēlu apstrādei Oracle8 sistēmā var pielietot ORDSYS.ORDVIRB tipa objektu.

Ir jāizveido jauno attēla tipu un šim tipam jāpievieno ORDSYS.ORDVIRB tipa

atribūtu:

CREATE TYPE Image_t AS OBJECT (ImageData ORDSYS.ORDVIRB;

);

2.7. att. Eksistējošo tipu izmantošanas piemērs

2. Uzsākot transformācijas UML klases jāpārveido objektu tipos . Parasti katram

objektu tipam atbilst objektu tabula, kas glabā objektu rindas. Ir iespējams, ka

vienam objektam atbilst vairākas objektu tabulas. Piemēram, personu

14

apakšsistēmai 2.2. attēlā var izveidot šādus objektu tipus: Person_t, Address_t,

Expiring_ID_t, Driver_License_t, Passport_t, National_ID_t,

Law_Enforcement_ID_t, Social_Security_Card_t un Birth_Certificate_t.

Veidojot objektu tabulu ir jāpieņem arī lēmumu par to, kā tabulas objekti tiks

identificēti: ar OID palīdzību, vai izmantojot tabulas primāro atslēgu. OID objektam tiek

veidots vienmēr. Primāra atslēga papildus ļauj saistīt tabulas un specificēt saišu integritātes

nosacījumus (CACADE DELETE nosacījums un tml.). Primāras atslēgas izveidošanai ir

jāpievieno objektam papildus atribūtu un pēc tam objektu tabulas atbilstošai kolonnai ir

jāpievieno PRIMARY KEY nosacījumu.

3. Jāpārveido visus pārējus UML datu tipus. Par objektu tipu UML tips kļūst tikai,

ja šim tipam ir atribūti, citādi tips pārtop par kādu no iebūvētiem primitīviem

datu tipiem. Šajā posmā izstrādātajam ir jābūt uz rokām transformācijas tabulai,

kura definētu, kā pārveidot UML primitīvus datu tipus ORDBVS iebūvētos tipos.

4. Objektu tipam ir jāpievieno atribūtus :

a. UML atribūts UML klasē pārtop par atribūtu objektu tipā.

b. UML atribūta tips kļūst vai nu par atribūta objektu tipu vai iebūvēto

primitīvo tipu, atbilstoši iepriekšminētiem noteikumiem.

c. Ja UML atribūtam ir piekārtots marķieris {nullable}, tad, definējot

objektu tabulu, atbilstošajam atribūtam (kolonnai) ir jāpiekārto NULL

ierobežojumu, citādi jāpiekārto NOT NULL ierobežojumu.

d. Ja UML atribūts ir inicializēts, definējot objektu tabulu, atbilstošam

atribūtam (kolonnai) ir jāpiekārto vērtību pēc noklusēšanas, izmantojot

DEFAULT izteiksmi.

e. Ja ir nepieciešams, jāpievieno CHECK ierobežojumus.

Piemēram, UML klasei Address no personu apakšsistēmas (sk. 2.2. attēlu) pēc

pārveidošanas Oracle8 OR shēmā var izveidot šādu objektu tipu un tabulu:

15

CREATE TYPE Address_t AS OBJECT (

AddressID INTEGER,StreetNumber NUMBER,StreetFraction VARCHAR(5),StreetName VARCHAR(100),StreetSuffix VARCHAR(25),City VARCHAR(100),State CHAR(2),PostalCode CHAR(20),Country VARCHAR(100),Comment VARCHAR(250)

);

CREATE TABLE Address OF Address_t (AddressID PRIMARY KEY,-OID typeStreetNumber NOT NULL,StreetName NOT NULL,StreetSuffix NOT NULLCity NOT NULL,State NOT NULL,PostalCode NOT NULL,Country NOT NULL

);

2.8. att. UML klases Addrees transformācijas piemērs (objektu identifikācijai tiks

pielietots gan OID, gan primārā atslēga)

Tur kur ir nepieciešams jārealizē mantošanu starp klasēm:

5. UML klasēm, kurām nav ģeneralizācijas (saknes vai neatkarīgā klase), ir

jāizveido primāro atslēgu (jāpievieno jauno atribūtu un jānorada atbilstošai

tabulas kolonnai PRIMARY KEY nosacījumu). Ja klase satur atribūtus ar

marķieri {oid}, jāpievieno šos atribūtus kopējam tabulas PRIMARU KEY

nosacījumam. Ja dotajai klasei ir apakšklase, tad atbilstošajam objektu tipam ir

jādefinē papildus atribūtu, kurš palīdzēs atšķirt konkrētu klasi. Objektu tabulas

kolonnai (kolonnām, ja tiks veidotas vairākas tabulas), kas atbilst izveidotajam

atribūtam ir jāpievieno CHECK nosacījumu ar dotas klases apakšklašu

nosaukumu kopu.

16

6. Apakšklasē pievienot katrā priekšteča primāro atslēgu PRIMARY KEY un

FOREIGN KEY nosacījumu kopām. Protams, ja dotā ORDBVS atbalsta

mantošanu, var izmantot DBVS piedāvāto sintaksi mantošanas realizācijai.

7. Ja UML klasē ir marķieris {alternate oid = <atribūta numurs>}, kas specificē

alternatīvus identifikatorus dotajai klasei, tad objektu tabulas atbilstošajai

kolonnai ir jāpievieno UNIQUE ierobežojumu. Piemēram, klasei

LawEnforcementID (sk. 2.2. attēlu) ar {alternate OID = 1} ir jāpievieno

UNIQUE nosacījumu attiecīgai objektu tabulas kolonnai:

CREATE TABLE LawEnforcementID OF LawEnforcementID_t (BadgeNumber NOT NULL UNIQUE);

2.9. att. {alternate oid = <atribūta numurs> } marķiera transformācijas piemērs

Tālāk, kad ir definēti visi objektu tipi un objektu tabulas ar nepieciešamajiem

ierobežojumiem un primārām atslēgām, ir jāveic asociāciju transformāciju:

8. Transformējot bināras „viens pret daudziem” asociācijas (sk. 2.5. attēlu), klasei

ar kardinalitāti „daudzie” ir: 1) vai nu jāpievieno atribūtu, kas veidos ārējo

atslēgu; 2) vai nu jāpievieno atsauci uz objektu ar kardinalitāti 1.

9. Transformējot kompozīcijas arī jāizšķiras starp dieviem variantiem: 1) jāizveido

primāro atslēgu galvenā objekta tabulai un ārējo atslēgu iekļauta objekta tabulai

(FOREIGN KEY ar CASCADE nosacījumu); 2) Jāizmanto objektu tipu, lai

glabāt iekļautus objektus, vai nu izmantojot objektu atribūtu, vai nu izmantojot

kolekcijas (iekļautas tabulas, masīvi).

10. Transformējot pārējas agregācijas, ir jāizveido primāro atslēgu galvenā objektā

un ārējo atslēgu iekļautos objektos. Šajā gadījumā nav jādefinē stingrus

(CASCADE) sasaistes nosacījumus. Var izmantot arī atsauces uz objektiem un

kolekcijas no atsaucēm (sk. 2.3.2. nodaļu), taču šīs variants prasa papildus

aizsardzības mehānismu realizāciju.

11. „Daudzie pret daudziem” un trīspusējo asociāciju realizācijai nav iespējams

izmantot OR shēmas līdzekļus (objektu atribūtus, kolekcijas). Šo asociāciju

transformācijai ir jāizveido atsevišķas tabulas, kas satur visu saistītu klašu

primāras atslēgas. Protams, var izveidot arī objektu tipu kas satur saistīto tabulu

primāras atslēgas un nepieciešamus asociācijas atribūtus, un pēc tam objektu

tipam veidot objektu tabulu.

17

Piemēram, trīspusējas asociācijas Plays (sk. 2.2. attēlu) realizācija Oracle8 OR shēmā

izskatās šādi:

CREATE TYPE Plays_t AS OBJECT (PersonID INTEGER,OrganizationID INTEGER,RoleID INTEGER,Tenure INTEGERStartDate DATE,EndDate DATE,TerminationMethod CHAR(1));

CREATE TABLE Plays OF Plays_t (PRIMARY KEY (PersonID,

OrganizationID, RoleID),PersonID REFERENCES Person,OrganizationID REFERENCES Organization,RoleID REFERENCES Role,Tenure NOT NULL,StartDate NOT NULL);

2.10. att. Trīspusējas UML asociācijas transformācijas piemērs

12. Jātransformē klašu metodes , iegūstot vai nu objektu tipu metodes vai iebūvētas

procedūras (atkarībā no ORDBVS).

18

3. LITERATŪRAS SARAKSTS

1. Robert J. Muller. Database Design for Smarties. Morgan Kauffman Publishers,

1999, 212. – 236. lpp.

19