Andrejs STEPANOVS

DATU BĀZES DATORIZĒTĀS PROJEKTĒŠANAS PROBLĒMU ANALĪZE

Maģistra darbs

Zinātniskais vadītājsDr.sc.ing., prof.

J.EIDUKS

Rīga 2007

ANOTĀCIJA

DATU BĀZE, DATORIZĒTA PROJEKTĒŠANA, CASE RĪKI, DATU MODELIS,

TRANSFORMĀCIJAS LIKUMI

Maģistra darbā ir apskatīta datu bāzes datorizētas projektēšanas tehnoloģija. Ir izanalizēts

konceptuālais un loģiskais datu modelis, ka arī datu bāzu fiziskais modelis. Ir izpētīti

datorizētas projektēšanas CASE rīki, kas ļauj automatizēt datu bāzes veidošanas procesu un ar

transformācijas likumu palīdzību no datu bāzes konceptuāla un loģiskā modeļa iegūt fiziskās

struktūras. Darbā ir piedāvāti varianti kā šādus transformācijas procesus var uzlabot.

Maģistra darba apjoms ir 80 lappuses, kas sevī iekļauj 45 attēlus, 5 tabulas. Darbā ir

ievietotas atsauces uz 33 literatūras avotiem.

2

SATURA RĀDĪTĀJS

IEVADS.....................................................................................................................................81. DATU BĀZES DATU MODEĻU ATTĪSTĪBA...............................................................10

1.1. Datu glabāšana izplātās datnēs......................................................................................101.2. Datu bāzes vadības sistēma un datu modelis................................................................101.3. Pirmsrelāciju datu bāzu modeli.....................................................................................11

1.3.1. Hierarhiskais datu bāzu modelis.........................................................................121.3.2. Tīkla datu bāzu modelis......................................................................................13

1.4. Relāciju datu bāzu modelis...........................................................................................131.4.1. Relāciju datu bāzu modeļa apraksts....................................................................141.4.2. Relāciju datu bāzu modeļa realizācija................................................................151.4.3. Relāciju datu bāzu modeļa fiziskās struktūras....................................................17

1.5. Objektu modelis............................................................................................................191.5.1. Objektorientētas pieejas jēdzieni........................................................................191.5.2. Objektu datu bāzu modelis.................................................................................201.5.3. Objektu datu bāzu fiziskās struktūras.................................................................21

1.6. Relāciju-objektu modelis..............................................................................................211.6.1. Relāciju-objektu modeļa apraksts.......................................................................211.6.2. Relāciju-objektu datu bāzu fiziskās struktūras...................................................22

1.7. Citi modeli.....................................................................................................................241.7.1. XML modelis......................................................................................................241.7.2. Asociatīvais datu modelis...................................................................................251.7.3. Modelis Realitāte-Atribūts-Vērtība....................................................................28

2. DATU BĀZU PROJEKTĒŠANA......................................................................................302.1. Realitāšu-saišu diagramma............................................................................................32

2.1.1. Realitāte un realitātes atribūts.............................................................................332.1.2. Saites un kardinalitāte.........................................................................................35

2.2. UML klašu diagramma.................................................................................................372.2.1. Klase un klases atribūti.......................................................................................372.2.2. Klases operācijas (metodes)...............................................................................382.2.3. Asociācijas saite (attiecības starp klasēm)..........................................................382.2.4. Vispārinājuma saite............................................................................................402.2.5. Agregācijas saite.................................................................................................402.2.6. Kompozīcijas saite..............................................................................................40

2.3. Paplašināta realitāšu-saišu diagramma..........................................................................412.4. Citi modeļi.....................................................................................................................43

3. CASE RĪKI..........................................................................................................................444. TRANSFORMĀCIJAS LIKUMI......................................................................................46

4.1. Relāciju datu bāzes transformācijas likumi...................................................................474.1.1. Vienkāršas struktūras..........................................................................................474.1.2. Unārā saite..........................................................................................................474.1.3. Binārā saite.........................................................................................................474.1.4. Ternārā un n-ārās saite........................................................................................484.1.5. Vispārinājuma un agregācijas saite....................................................................48

4.2. UML un realitāšu-saišu diagrammu atbilstība..............................................................694.3. Objektu datu bāzu transformācijas likumi....................................................................694.4. Relāciju-objektu datu bāzes transformācijas likumi.....................................................72

3

4.4.1. Saliktais atribūts.................................................................................................734.4.2. Metode................................................................................................................734.4.3. Binārā saite viens pret daudziem........................................................................744.4.4. Vispārinājuma saite............................................................................................74

SECINĀJUMI.........................................................................................................................80LITERATŪRAS SARAKSTS................................................................................................83

4

IEVADS

Datu bāzu sistēma ir datorizētā sistēma, kuras pamatuzdevums ir glābāt informāciju,

sniedzot lietotājiem rīkus šīs informācijas izgūšanai un modificēšanai. Par informāciju tiek

uzskatīts viss nepieciešamais lietotāja vai organizācijas darbam [6]. Datu bāzu pētījumu

panākumi ir cieši saistīti ar lietojumprogrammatūras attīstību, kura sasniedza milzīgu

ražotspēju un būtiski ietekmēja ekonomiku. Pasaulē datu bāzu tehnoloģijas pētniecībā tiek

ieguldīts vairāk nekā 10 miljardi eiro gadā. Datu bāzu pētījumu panākumu rezultāti kļuva par

komunikācijas sistēmu, transporta un loģistikas, finanšu pārvaldības, zināšanu bāzu sistēmu,

kā arī civilo un militāro lietojumprogrammu pamatu [5].

Datu bāzes ir informācijas sistēmu pamats. Lai sekmīgi realizētu sistēmu, kuras pamatā

ir datu bāze, pirmkārt, ir jādomā par datiem, tad par lietojumiem. Slikti izprojektēta

sistēma radīs kļūdas, kā rezultātā lietotāji pieņems nepareizus lēmumus, kuru sekas negatīvi

ietekmēs organizācijas darbību [5].

Datu bāzes izveidošana ir grūts un atbildīgs uzdevums. Galvenās problēmas ir saistītas,

nevis ar tehnisko realizāciju, bet gan ar datu bāzes satura definēšanu. Lai datu bāze būtu

kvalitatīva:

1) jāpārliecinās par datu bāzes satura atbilstību dotas problēmvides informācijas

struktūrai;

2) jānodrošina datu bāzes satura vienkāršošana, tādējādi atvieglojot tālāko darbu

izstrādātājiem un lietotājiem;

3) jānodrošina satura izteiksmība, tam jāspēj attēlot atšķirības un saites starp datiem;

4) jānovērš datu dublēšanās, jāizslēdz nevajadzīga informācija [5].

Informācija par apskatāmās problēmvides datiem tiek iegūta aptaujājot potenciālos

lietotājus un analizējot eksistējošos dokumentus, pētot organizācijas kultūru, pielietojot citas

sistēmu analīzes un zināšanu iegūšanas metodes. Lai veiksmīgi un kvalitatīvi varētu iegūt

informāciju no lietotājiem, labi jāizprot loģiskās datu struktūras, kurās viņi veido savu

izpratni:

1) informācijas sistēmu veidošanās sākumposmā tika uzskatīts, ka lietotāji informācijas

sistēmu iedomājas kā “melno kasti” un operē ar ieejas un izejas datiem;

2) vēlāk dominēja uzskats, ka lietotāji datus grupē un analizē kā tabulveida struktūras;

3) attīstoties objektorientētai programmēšanai, tika izvirzīta tēze, ka nedrīkst datus

apskatīt atsevišķi no to izmantojuma. Dati tika grupēti objektos atkarībā no to

5

izmantojuma. Veidojās objektu hierarhijas, vienāda tipa objektiem piekārtojot

nepieciešamo funkcionalitāti (metodes).

Izmantojot šos priekšstatus, tika izveidoti vairāki datu konceptuālie modeļi, kuri tika un tiek

izmantoti datu bāzes projektēšanā. Populārākais no šiem modeļiem ir realitāšu-saišu

diagramma (Entity-Relationship diagram), kas dažādās izpildes modifikācijās ir visplašāk

lietotais datu bāzu datu konceptuālais modelis. Otrs populārākais modelis datu bāzu datu

modelēšanai ir UML valodas klašu modelis. Šis modelis ir orientēts uz datu objektu un

metožu priekšstatu.

Arī datu bāzu datu glabāšanas struktūras ir veikušas garu attīstības ceļu. Pirmās datu bāzes

izmantoja datu hierarhiskās, tīklveida struktūras. Plaša datu bāzes tehnoloģijas izmantošana

iesākās līdz ar relāciju struktūru izmantošanu datu glabāšanai. Turpinājumā tika ieviestas datu

objektu struktūras (objektu datu bāzes un relāciju-objektu datu bāzes).

Datu bāzes datorizētai projektēšanai tika izveidoti speciālas interaktīvas programmu

paketes, kuras ļauj grafiski definēt datu bāzes konceptuālo modeli un veikt tā transformāciju

uz norādītās datu bāzes vadības sistēmas datu glabāšanas struktūrām. Tehnoloģija, kad

informācijas sistēmas projektētājs savas vēlmes un priekšstatus definē grafisku diagrammu

veidā, un pēc tam sistēma automātiski veic datu bāzu datu, glabājamo struktūru un

lietojumprogrammu ģenerēšanu, tika nosaukta par CASE (Computer-Aided Software

Engineering) tehnoloģiju. Mūsdienās tiek piedāvātas vairāk kā 100 programmu pakešu, kas

realizē šo tehnoloģiju. Parasti šīs programmu paketes sauc par CASE rīkiem. Projektētājiem ir

iespējams izvēlēties savām vēlmēm vislabāk atbilstošo rīku.

Diemžēl, lai kvalitatīvi un efektīvi lietotu CASE tehnoloģiju un CASE rīkus, ir daudz

neatrisinātu problēmu:

1) esošo datu bāzu datu konceptuālo modeļu grafisko elementu klāsts ir nepilnīgs,

dažādos CASE rīkos tas ir atšķirīgs un bieži vien nepietiekams;

2) datu bāzu konceptuālā modeļa elementi parasti tiek transformēti uz vienkāršākām datu

glabāšanas struktūrām, kas nedod vēlamo efektivitāti. Bieži vien tas rada arī

nevajadzīgi sarežģītu datu glabāšanas interpretējumu;

3) neeksistē pilnvērtīgās un automātiskās datu bāzes konceptuālo modeļu elementu

transformācijas uz efektīvākajām relāciju, relāciju-objektu un objektu datu bāzes datu

glabāšanas struktūrām. Jo īpaši varētu atzīmēt, ka ļoti vājš transformāciju

nodrošinājums ir relāciju-objektu datu bāzēm.

Tāpēc ir ļoti svarīgi izvērtēt konceptuālo modeļu elementu esošo transformāciju klāstu un

nepieciešamos transformāciju papildinājumus.6

1. DATU BĀZES DATU MODEĻU ATTĪSTĪBA

Gandrīz visas netriviālas lietojumprogrammas strādā ar lielu datu apjomu, vairums no

lietojumprogrammām ir veidotās tieši datu apstrādei. Pirms tika ieviestas datu bāzes vadības

sistēmas, lietojumprogrammas strādāja ar datiem, kas glabājas izplātās datnēs (flat files).

1.1. Datu glabāšana izplātās datnēs

Izplātā datne ir „datne, kas nav fizikāli saistīta ar citām datnēm un nesatur norādes uz tām.

Izplātajai datnei nepiemīt hierarhiska struktūra [8].

Šādai pieejai ir vairāki trūkumi:

glabājot datus izplātās datnēs nav iespējams attēlot loģiskās saites starp datiem;

šādas sistēmas ir grūti programmēt, īpaši, ja datu struktūra ir sarežģīta, tad arī visas

lietojumprogrammas ātrdarbība ir zema – lai atrastu kādu konkrētu informāciju, ir

jāapstrādā visa datne;

datu dublēšanās [15, 20].

1.2. Datu bāzes vadības sistēma un datu modelis

Vajadzība ērti un ātri strādāt ar lieliem datu apjomiem kalpoja par datu bāzes vadības sistēmu

rašanas iemeslu.

Datu bāzes vadības sistēma ir „lietojumprogrammatūra, kas organizē datus datu bāzē,

nodrošinot to uzglabāšanu, izguvi, drošību un integritāti” [8]. Datu bāzes vadības sistēmas

sniedz iespējas atjaunot datus, meklēt tos, kā arī ļauj lietojumprogrammu izstrādātājiem

mazāk domāt par datu glabāšanas fiziskām detaļām, vairāk pievēršoties loģiskiem

jautājumiem (1. att.).

7

1. att. Informācijas sistēmas arhitektūra

Veidojot datu bāzi izstrādātājs sastapās ar problēmu kopu. Datu modeli piedāvā atšķirīgus

šādu problēmu risinājumus. E.Kods definē datu modeli kā trīs komponentu kombināciju:

1) datu struktūru tipu kopums (celtniecības bloki jebkurai datu bāzei, kas atbilst

modelim);

2) operatoru vai izvedumkārtulu kopums, kas ierobežo datu struktūru tipus, to

kombinācijas;

3) operāciju kopums, kas tiek pielietots datu struktūru tipiem (datu ievietošanai,

rediģēšanai, izgūšanai, u.t.t) [4].

1.3. Pirmsrelāciju datu bāzu modeli

Tā kā relāciju modelim ir svarīgāka loma datu bāzu tehnoloģijā un tas attīstībā, bieži datu

bāzu modeļus klasificē kā pirmsrelāciju un pēcrelāciju. Pirmsrelāciju modeļi sakarā ar relāciju

modeļa paradīšanās un tā pārākumu zaudēja savu popularitāti, bet to izpēte palīdz saprast kā

evolucionēja datu bāzu tehnoloģija un kādas prasības bija izvirzītas relāciju modeļim, kurā ir

novērsti vairāki no pirmsrelāciju modeļa trūkumiem. Pazīstamākie no pirmajiem datu bāzu

modeļiem ir hierarhiskais un tīkla datu bāzu modelis.

8

1.3.1. Hierarhiskais datu bāzu modelis

Hierarhiskajā datu bāzu modelī dati tiek organizēti koka struktūrā: katram vecākam var būt

vairāki bērni, bet katram bērnam ir tikai viens vecāks (2. att.).

2. att. Hierarhiskais modelis

Hierarhiska datu bāzu modeļa pazīstamāka realizācija ir IBM sistēma IMS.

XML datubāzēm arī piemīt hierarhiskā struktūra (XML modelis ir apskatīts zemāk).

Hierarhiskā modeļa priekšrocības:

modelis nodrošina divu veidu saites starp realitātēm – “viens pret vienu” un “viens

pret daudziem”;

ātra piekļuve datiem, ja tiek izmantotas iepriekšdefinētas saites [10].

Modeļa trūkumi:

nav iespējams izveidot realitāti, kurai būtu vairāki vecāki (vienīgais, piesaistīt

jaunu vecāku var realitātes kopijai, kas noved pie datu dublēšanās);

nav izmantojama, ja ir bieži jāpielieto vaicājumi, kas nebija ieplānoti iepriekš –

modelis “nav elastīgs” [10].

9

1.3.2. Tīkla datu bāzu modelis

Tīkla datu bāzu modelī dati tiek organizēti koka struktūrā, bet atšķirībā no hierarhiska modeļa

vienam bērnam var būt vairāki vecāki (3. att.).

3. att. Tīkla modelis

Līdzīgi kā hierarhiskam modelim, ja piekļuve datiem notiek izmantojot iepriekšdefinētas

saites, tad tā ir ātra [10].

Modeļa trūkumi:

neieplānoto vaicājumu izpilde var būt ļoti sarežģīta [10];

datu modelis nav pilnībā neatkarīgs no lietojumprogrammas (jā tiek mainītas datu

struktūras, tad arī jārediģē lietojumi).

1.4. Relāciju datu bāzu modelis

Relāciju modelis ir mūsdienu datu bāzu tehnoloģijas pamats [6]. Relāciju datu bāzu modeļi

piedāvāja E.Kods (Edgar F. Codd) 1970. gadā. Vēlāk vairākos darbos E.Kods raksta, kādus

mērķus viņš centās sasniegt ar šo modeli:

1) augsts datu neatkarības līmenis;

2) vienkāršāka iespējama struktūra, kas atbilst semantiskām prasībām (jānodrošina

iespēja neprogrammētājiem strādā ar datiem gadījumos, kuros agrāk bija nepieciešams

programmētāju darbs, ka arī jāpaaugstina programmētāju darba efektivitāte);

3) relatīvi vienkārša datu nepretrunīguma analīze;

4) failu integrēšana datu bāzēs;

10

5) attālināto datu bāzu tīklu atbalsts;

6) datu bāzes administratora darba vienkāršošana [3, 7].

1.4.1. Relāciju datu bāzu modeļa apraksts

Būdams pēc izglītības matemātiķis, E.Kods piedāvāja datu apstrādei izmantot kopu teorijas

aparātu, kas iekļauj sevī tādas kopu operācijas kā apvienojums, šķēlums, starpība un Dekarta

reizinājums. E.Kods paradīja, ka jebkurus datus var attēlot kā īpaša veida divdimensiju tabulu

kopumu, kas matemātikā ir zināma kā attiecība, relācija (relation).

Mazāka datu vienība relāciju modelī ir atsevišķa, atomāra (nedalāma) datu vērtība, kas ir

atkarīga no konkrēta datu modeļa. Tā, vienā priekšmetiska jomā vārds un uzvārds var tikt

apskatīti kā viena vērtība, bet citā – kā divas atšķirīgas vērtības.

Par domēnu sauc viena tipa atomāru vērtību kopu. Piemēram, starppilsētu satiksmē,

sākuma vai gala staciju domēns ir apdzīvotu vietu kopa, bet reisa numuru domēns ir veselu

pozitīvu skaitļu kopa.

Domēnu nozīme ir sekojoša. Ja divu atribūtu vērtības tiek ņemtas no viena un tā paša

domēna, tad, iespējams, šos atribūtus ir jēga salīdzināt (piemēram, var veikt vaicājumu, lai

uzzinātu, vai ar trīs latiem pietiek, lai aizceļotu no Rīgas līdz Liepājai). Ja atribūtu vērtības

tiek ņemtas no dažādiem domēniem, tad to salīdzināšanai, visticamāk, nav nekādas nozīmes

(nav vērts salīdzināt reisa numuru ar biļetes cenu).

Attiecības sastāv no virsraksta un ķermeņa. Piemēram, autobusa satiksme (4. att.) [30].

4. att. Attiecības struktūra

11

Tāpēc kā attiecība ir kopa, bet kopas pēc definējuma nesatur vienādus elementus,

noteiktajā laikā momentā nevar būt situācija, kad viens kortežs ir cita korteža dublikāts.

Augstākminētie un vēl citi matemātiskie jēdzieni tiek izmantoti kā relāciju modeļa

teorētiska bāze, bet praktiskajā realizācija tiek izmantoti sekojoši šo jēdzienu ekvivalenti:

Attiecība – Tabula (retāk Fails),

Kortežs – Rinda (retāk Ieraksts),

Atribūts – Lauks, Aile, Šūna.

Relāciju modeļi raksturo zema ātrdarbība, kas ir cena par iespēju veikt neieplānotus

vaicājumus [10]. Relāciju modelim ir vairākas priekšrocības. Modelis, atšķirībā no

hierarhiska un tīkla datu bāzu modeļiem, atbalsta neieplānoto vaicājumu izpildi. Saites vairs

nav datubāzes sastāvdaļā, tas tiek izmantotas nepieciešamības gadījumā. Relāciju datu bāzi

var modificēt, neapstādinot darbu ar to. Salīdzinot ar iepriekšējiem modeļiem, relāciju datu

bāzes sniedz sekojošas priekšrocības:

iebūvēta daudzlīmeņu integritāte: datu integritāte ir iebūvēta modelī lauku

līmenī, lai nodrošinātu datu pareizību; tabulas līmeņi, lai nodrošinātu ierakstu

nedublēšanos un, lai atklātu trūkstošas primāro atslēgu vērtības; saišu līmenī, lai

nodrošinātu to, ka saites starp tabulu pāriem ir spēkā esošas; un biznesa līmenī, lai

nodrošinātu datu atbilstības biznesa videi;

loģiskā un fiziskā datu neatkarība no datu bāzes lietojumprogrammām:

lietotāja izmaiņas datu bāzes loģiskajā projektējumā, vai lietojumprogrammatūras

izstrādāja izmaiņas datu bāzes fiziskajā realizācijā neietekmē lietojumprogrammas,

kas izmanto šo datu bāzi;

garantēts datu nepretrunīgums un precizitāte: dati ir nepretrunīgi un pareizi

pateicoties vairākiem datu integritātes līmeņiem;

ērta datu izguve: pēc lietotāja komandas, dati var būt izgūti kā no atsevišķas

tabulas, tā arī no vairākām saistītām tabulām datu bāzes robežās. Tas ļauj

lietotājam apskatīt informāciju gandrīz neierobežoto variantu skaitā [11].

1.4.2. Relāciju datu bāzu modeļa realizācija

Relāciju datu bāze ir attiecību kopa, kas satur visu informāciju, kurai jāglabājas datu bāzē. Bet

lietotāji var uztvert šādu datu bāzi kā tabulu kopu (5. att.) [30]:

12

1) katrai tabulai ir unikāls vārds un tā sastāv no vienāda tipa rindām;

2) rindām ir fiksēts lauku un vērtību skaits (jebkurā laukā ne vairāk par vienu vērtību);

3) rindas obligāti atšķiras viena no otras minimāli ar vienu vērtību, kas ļauj viennozīmīgi

identificēt jebkuru tabulas rindu;

4) tabulas robežās stabiņiem ir unikāli vardi, katrā no tiem tiek izvietotas viendabīgas

datu vērtības (datumi, uzvārdi, veseli skaitļi vai naudas summas);

5) strādājot ar tabulu, tas rindas un stabiņus var apstrādāt jebkurā kārtība, neskatoties uz

to informacionālu saturu, ko veicina tabulu un stabiņu vārdu esamība. Iespēja izdalīt

jebkuru rindu vai jebkuru rindu kopu, kas atbilst noteiktam nosacījumam (piemēram,

reisi ar gala staciju Ventspils un pienākšanas laiku līdz 12:30).

5. att. Relāciju datu bāzi lietotājs var uztvert kā tabulu kopu

Eksistē vairākas relāciju modeļa realizācijas (TutorialD, TQL, Quel u.c), bet izplatītāka ir

IBM kompānijas izstrādāta strukturēto vaicājumu valoda SQL, kas ir arī standartizēta. SQL

valoda ir daudz kritizēta no teorētiķu puses, kuri uzskata, ka SQL valoda nekorekti atbalsta

relāciju modeli vai atbalsta to nepilnā mērā [6]. Neskatoties uz šiem pārmetumiem, SQL

valoda attīstās un uz to balstās gandrīz jebkura mūsdienu relāciju datu bāzu vadības sistēma,

piemēram, SQL2003 standarta realizācijas piedāvā tādi datu bāzu vadības sistēmu ražotāji kā

IBM, MySQL, Oracle, PostgreSQL, Microsoft, Sybase, kā arī citi [13].

13

1.4.3. Relāciju datu bāzu modeļa fiziskās struktūras

SQL valodas struktūras nav ierobežotas ar tabulām un tabulu kolonnām. Nodaļā ir aprakstītas

tikai plašāk izmantotās struktūras. Ārpus aprakstītam eksistē arī fiziskās struktūras, kas ir

specifiskas noteiktām datu bāzu vadības sistēmām.

Tabulas ir realitāšu fiziskais ekvivalents, datu konteineris, kas sastāv organizēts rindu un

kolonnu veidā. Tabulas var būt saistītas sava starpā ar ārējo atsauču (foreign key) palīdzību.

Skats (view) ir struktūra, kuras pamatā ir vaicājuma rezultāts, bet kura var būt izmantotā

tādā pašā veidā (ar dažiem ierobežojumiem) kā tabula. Ja kādā instrukcijā ir norāde uz skatu,

tad vaicājuma rezultāta dati kļūst par skata saturu šis instrukcijas darbības laikā. Dažas datu

bāzu vadības sistēmas atbalsta materializētus skatus, kuri atšķirībā no skatiem tiek fiziski

veidoti uz skata vaicājuma pamata, tāpēc materializētie skati ir līdzīgi tabulām. Skata kolonnu

nosaukumi var neatbilst tabulu kolonnu nosaukumiem, bieži skatu kolonnām ir nosaukumi,

kuri ir vieglāk saprotami lietotājiem. Skatu izmantošanas iemesli:

datu grupu iepriekšēja sagatavošana labākai ātrdarbībai (lietojot materializētus skatus);

piekļuves ierobežošana tabulām, tabulu kolonnām vai noteiktām datu vērtībām;

tabulu iespējamo izmaiņu novēršana;

tabulu un kolonnu pārdēvēšana ērtākai saskarnei [1].

Skati parasti ir tik efektīvi, cik efektīvi ir vaicājumi, uz kuru pamatā skati tiek veidoti. Tāpēc

ir svarīgi veidot ātrdarbīgus, labi uzrakstītus vaicājumus.

Visi biznesa vides datu elementi tiek apskatīti kā kolonnu kandidāti.

Ierobežojumi (constraints) – noteikumi, kas nosaka, kuri dati ir pieļaujami veicot insert,

update un delete operācijas, t.i. veicot datu ievadi, rediģēšanu vai dzēšanu. Ierobežojumi

palīdz automātiski nodrošināt datu integritāti un filtrēt datus, kas tiek ievietoti datu bāzē.

SQL standartā eksistē četri ierobežojumu veidi (konkrētās datu bāzu vadības sistēmās

šādu ierobežojumu var būt vairāk):

1) unikalitātes ierobežojums (unique), jeb potenciālas atslēgas ierobežojums, nosaka,

ka vienas kolonnas vērtībām, vai vairāku kolonnu vērtību kombinācijai jābūt unikālai;

2) primāras atslēgas ierobežojums (primary key) tiek definēts vienai vai vairākām

kolonnām, kuru vērtība viennozīmīgi identificē katru tabulas ierakstu, primāras

atslēgas ierobežojums ir unikalitātes ierobežojuma īpašais gadījums. Tabulā

vienlaicīgi var eksistēt tikai viens primāras atslēgas ierobežojums, primāras atslēgas

vērtība nevar būt nedefinēta (vienāda ar NULL);

14

3) ārējas atsauces ierobežojums (foreign key) tiek definēts vienai vai vairākām tabulas

kolonnām, kuras atsaucās uz citas (retāk tas pašas) tabulas kolonnu ar unikalitātes vai

primāras atslēgas ierobežojumu. Ārējas atsauces ierobežojums var novērst datu ievadi

tabulā, kurai nav atbilstošu vērtību saistītājā tabulā. Ārējas atsauces ir galvenais veids

kā sasaistīt relāciju datu bāzes tabulas savā starpā. Vienā tabulā var eksistēt vairākas

ārējas atsauces;

4) pārbaudes ierobežojumi (check) ļauj veikt salīdzināšanas operācijas, lai noteiktu, vai

vērtība atbilst dotajiem nosacījumiem [13].

Indeksi ir speciāli objekti, kas tiek noskaņoti virs tabulām un paātrina vairākas datu

manipulēšanas operācijas, piemēram, instrukciju select, update un delete izpildi. Indeksi var

paātrināt arī citas operācijas:

min() un max() vērtību noteikšana indeksēta kolonnā,

tabulas kolonnu šķirošana un grupēšana,

lauku tipa is null vai is not null meklēšana u.c.

Trigeris ir īpaša tipa procedūra, kura automātiski nostrādā, kad tabulā tiek izpildīta

noteikta, ar datu modificēšanu saistīta instrukcija. Trigeris ir tieši saistīts ar tabulu un tiek

uzskatīts par atkarīgo objektu. Piemēram, var rasties nepieciešamība atjaunot detaļu numurus

tabulā Realizācija, ja tika mainītas detaļu numuru vērtības tabulā Produkti, šādējādi

nodrošinot sinhronizāciju. Trigeris ir piesaistīts konkrētai tabulas modificēšanas komandai

(insert, update, un delete), tam ir arī noteiktais palaišanas laiks. Trigeri var būt palaisti pirms

modificēšanas komandas izpildes (before), pēc (after) vai modificēšanas komandas izpildes

vietā (instead of). Trigeri, kas tiek palaisti pirms modificēšanas komandas, vai modificēšanas

komandas vietā neredz izmaiņas, ko veic šī komanda, savukārt trigeri, kas tiek palaisti pēc

modificēšanas, var redzēt šis izmaiņas un ietekmēt tās [13].

SQL valoda nav procedūrorientēta (procedūrorientēta programma sastāv no instrukcijām,

kurās izpildās soli pa solim), arī pirmām relāciju datu bāzu vadības sistēmām nebija

procedūrorientēto iespēju. Procedūrorientētām valodām, kas bija populāras tolaik (C,

COBOL, Pascal u.c.) eksistēja paplašinājumi, kas ļāva iekļaut SQL vaicājumus

programmēšanas kodā. Ar laiku relāciju datu bāzes palika sarežģītākas un attīstījās ideja

glabāt procedūrorientētas programmēšanas moduļus kompilēta formā iekš relāciju datu bāzes

vadības sistēmas. SQL99 standartā parādījās glabājamas procedūras (persistent stored

routines) un trigeri, bet tolaik vadošajiem datu bāzu vadības sistēmu ražotajiem jau bija

izstrādāti savi procedūrorientēti moduļi. Glabājamas procedūras (stored procedures) ir

lineāras un secīgas programmas. Glabājamo procedūru sintakse ir atkarīga no realizācijas 15

(datu bāzu vadības sistēmas), bet ir kopējas iezīmes. Glabājamas procedūras var atbalstīt

parametrus un atļauj lokālo mainīgo lietošanu; tas ir strukturētas un atļauj lietot apakšmoduļus

[14].

1.5. Objektu modelis

Objektu modelis ir cieši saistīta ar objektorientēto programmēšanu. Objektorientētas pieejas

idejas parādījās jau 1960-tājos gados, un šodien šī pieeja ir ļoti attīstīta, iekļaujot sevī daudz

koncepciju un jēdzienu.

1.5.1. Objektorientētas pieejas jēdzieni

Tradicionāli objektorientēta pieeja tiek balstīta uz sekojošam koncepcijām:

objekts un objekta identifikators,

atribūti un metodes,

klases,

hierarhijas un klašu mantošana, u.c. [32].

Jebkura pasaules realitāte objektorientētās sistēmās tiek modelēts objekta veidā.

Radīšanas laikā objektam tiek piešķirts sistēmas ģenerētais unikālais identifikators (object

identificator, OID), kas ir saistīts ar objektu tā pastāvēšanas laikā un netiek mainīts, ja mainās

objekta stāvoklis.

Katram objektam ir stāvoklis un uzvedība. Objekta stāvoklis ir objekta atribūtu vērtību

kopums. Objekta uzvedība – metožu kopums (programmas kods), kas operē ar objekta

stāvokli. Objekta atribūta vērtība tas ir arī objekts vai objektu kopa. Objekta stāvoklis un

uzvedība ir iekapsulēti objektā; objektu mijiedarbība notiek ar ziņojumu palīdzību un ar

attiecīgo metožu izpildi.

Objektu kopa ar identiskiem atribūtiem un metodēm veido objektu klasi. Objektam

jāpieder tikai vienai klasei (neskaitot mantošanas iespēju, kas tiek apskatīta zemāk). Ir

iespējama primitīvu iepriekšdefinētu klašu esamība, kuru objektiem-eksemplāriem nav

atribūtu: veselie skaitļi, simbolu virknes u.t.t. Klase, kuras objekti var kalpot par atribūtu

vērtībām citai klasei, tiek saukts par šī atribūta domēni.

16

Ir iespējams veidot jauno klasi, par pamati ņemot jau eksistējošo – mantošana. Šajā

gadījumā jauna klase, ko sauc par eksistējošas klases (superklases) apakšklasi, manto visus

superklases atribūtus un metodes. Izšķir divus mantošanas veidus:

katrai klasei ir ne vairāk par vienu superklasi,

klase var mantot no vairākām klasēm (šādā gadījumā apakšklases objekts pieder

jebkurai superklasei),

Jāpiebilst, ka ar augstākminētajiem jēdzieniem objektorientēta pieeja nav ierobežota.

1.5.2. Objektu datu bāzu modelis

Objektu datu modelis tika izstrādāts, lai nodrošinātu pastāvīgu glabāšanu (persistence)

objektorientētām programmēšanas valodām. Palaižot objektorientēto programmu, visi tās

mainīgie tiek glabāti pamatatmiņā objektu veidā. Kad programmas izpilde ir pabeigta, atmiņā

tiek atbrīvota, bet objekti zaudēti. Objektu datu bāzes ļauj pārvietot objektus starp

pamatatmiņu un disku [28].

Visticamāk, svarīgākais raksturojums, kas atšķir objektorientētas datu bāzes, ir objektu

uzvedība. Datorsistēmās, kas balstījās uz tradicionālam datu bāzēm, eksistēja principiāla

robeža starp struktūras un uzvedības daļu. Tradicionāli informācija un procedūras tika

glabātas atsevišķi, dati un saites tika glabāti datu bāzē, bet procedūras – lietojumprogrammā.

Objektorientēta pieeja ļauj glabāt realitāšu apstrādes procedūras kopā ar datiem. Pielietojot šo

pieeju, realitātes uzvedība nav atkarīga no lietojumprogrammas. Objektorientētais modelis arī

tieši atbalsta saiti “daudzi pret daudziem”.

Objektorientētam modelim ir līdzība ar pirmsrelāciju modeļiem, jo šajā modelī pieeja

datiem notiek izmantojot iepriekšdefinētas saites, kas palielina ieplānoto vaicājumu

ātrdarbību, bet padara neieplānoto vaicājumu veidošanu grūtāku (vaicājumā nav iespējams

izveidot jaunas saites, kas bija iespējams relāciju modelī) [10]. Par objektu modeļa trūkumu

var nosaukt faktu, ka šim modelim nav tik attīstīta matemātiska aparāta, kāds tas ir relāciju

modelim.

Kaut arī objektu datu modelis sākumā nebija plānots kā relāciju modeļa konkurents,

vairāki eksperti bija tik sajūsmināti ar objektorientētas tehnoloģijas idejām, ka prognozēja šim

datu modelim lielus komerciālos panākumus. Reāla situācija ir tāda, ka datu bāzu izstrādātāji

17

neredz objektu datu modeļa priekšrocības tik skaidri, lai varētu atteikties no relāciju modeļa

un segt uzdevumus, kas ir saistīti ar jauna modeļa ieviešanas izmaksām [28].

1.5.3. Objektu datu bāzu fiziskās struktūras

Objektu datu modelim nav tik attīstītas standartizētas datu apstrādes valodas, kāda ir SQL.

Tāpēc objektu datu bāzu fiziskās struktūras vēl vairāk nekā relāciju datu bāzu struktūras ir

atkarīgas no konkrētas realizācijas.

Objektorientētajā programmā realitāte ir pārstāvēta kā objekts. Atšķirība no relāciju

tabulām, objekts var iekļaut sevī arī uzvedību (objektorientēta pieejā īpaša uzmanība ir

pievērsta objektu mijiedarbībai) Pastāv nepieciešamība lietot vairākus līdzīga tipa objektus ar

līdzīgiem raksturojumiem. Klase ir šablons, no kura var veidot šādus līdzīgus objektus [19].

Objektu datu bāzu fiziskas struktūras realizē objektorientētas pieejas koncepcijas, tātad

iekļauj sevī objektu identifikatorus, objektu metodes, mantošanas mehānismus, abstraktās

klases un citas konstrukcijas.

1.6. Relāciju-objektu modelis

Relāciju-objektu datu bāzēm ir jāatbalsta gan relāciju, gan objektu iespējas. Šāda „tehnoloģiju

tuvošanās” notiek par pamatu ņemot relāciju datu bāzes un papildinot tās ar labākam objektu

tehnoloģijas īpašībām [6].

1.6.1. Relāciju-objektu modeļa apraksts

Relāciju-objektu modeli 1990. gadā piedāvāja Maikls Stounbreikers (Michael

Stonebraker) un šis modelis ir realizēts vairākas datu bāzu vadības sistēmās, arī standarts

SQL99 tika papildināts ar iespējam, kas saistīti ar objektorientēto datu tipu ieviešanu [13].

18

6. att. Relāciju-objektu datu bāzēs objekti tiek pārveidoti relāciju struktūrās

Galvenā relāciju-objektu modeļa kritika ir saistīta ar to, ka objektu glabāšanai tiek

izmantotās relāciju struktūrās – tabulas un kolonnas, kas neļauj pilnvērtīgi izmantot objektu

pieejas priekšrocības (6. att.) [19].

1.6.2. Relāciju-objektu datu bāzu fiziskās struktūras

Relāciju-objektu datu bāzes iekļauj sevī visās relāciju datu bāzu fiziskās struktūras, ka arī

specifiskas struktūras, kas ļauj izmantot objektorientētas pieejas iespējas.

Lietotāju datu tipi (user-defined type), jeb objektu tipi papildina SQL ar mantošanas un

citām objektorientētas funkcionalitātes iespējām. Objektorientētas programmēšanas

terminoloģijā objektu tipi atbilst klasēm. Var veidot arī apakštipus – tipus, kuru pamatā ir

cits tips – supertips (7. att.) [13].

7. att. Objektu tips ar apakštipu (šeit un turpmākos attēlos relāciju struktūras ir apzīmētas ar

taisnstūriem, objektu – ar elipsēm)

Apakštipi manto atbilstoša supertipa raksturojumus, bet tiem ir arī savi raksturojumi.

Piemēram, var definēt objektu tipu telefonaNr, tad uz šī tipa pamata var izveidot jaunus

apakštipus – mājasTelefons, darbaTelefons, mobilaisTelefons u.t.t. Vai arī izveidot tipus datu

bāzes elementiem, kas tiek īpaši bieži izmantoti, piemēram, objektu tipu adrese, kura sastāvēs

no valsts nosaukuma, pilsētas un ielas nosaukuma, mājas un dzīvokļa numura.

Izmantojot iepriekšizveidoto objektu tipu var veidot objektu tabulu, kas ir ekvivalenta

objektorientētas programmēšanas klases eksemplāram (8. att.).

19

8. att. Objektu tabula

Vai objektu kolonnu, kad atribūta datu tips ir kāds lietotāja izveidots objektu tips (9. att.).

9. att. Tabula ar objektu kolonnu

Objektu metodes ir funkcijas vai procedūras, kas var būt deklarēti kopā ar objektu tipu,

lai realizētu šī tipa objektu uzvedību [17].

Relāciju-objekta modeļa realizācija var atšķirties un ir atkarīga no konkrētas datu bāzu

vadības sistēmas. Tālāk tiek aprakstītas dažas fiziskas struktūras, kuras pastāv PostgreSQL,

citā DBVS tie var būt realizēti citā veidā.

Relāciju modelī tabulas lauku vērtībai jābūt atomārām datu objektam. PostgreSQL var tikt

lietoti arī saliktas vērtības, ko sauc par masīviem. Masīvs ir elementu kopa ar vienu kopējo

identifikatoru. Masīva elementiem var būt iebūvēts vai lietotāja definēts datu tips, bet tiem

obligāti jābūt vienā tipā. Ir pieļaujami daudzdimensiju masīvi, kuru katrs elements var būt ne

atomāra vērtība, bet cits masīvs. Relāciju-objektu modeļi no relāciju modeļa atšķir objektu

identifikatori. PostgreSQL ir atļauti vairāki ieraksti ar vienādu lauku saturu, jo šādā gadījumā

tiem būs dažādi objektu identifikatori (relāciju datu bāzēs vienās tabulas robežās ierakstu

viennozīmīgi identificē primāra atslēga) [29].

Mantošanas mehānisms PostgreSQL tiek realizēts ar atvasināto tabulu palīdzību. No

bāzes tabulas atvasinātai bērna tabulai ir tie paši lauki un ierobežojumi, kas papildus tiek

papildināti ar savējiem laukiem. Ievietojot datus atvasinātājā tabulā tie automātiski tiek

ievietoti arī bāzes tabulas atbilstošos laukos [29].

Relāciju-objektu modelis ir realizēts arī Oracle datu bāzu vadības sistēmā. Objektu skati

ļauj piekļūt relāciju datiem, izmantojot relāciju-objektu iespējas. Objektu skati ļauj izstrādāt

relāciju-objektu lietojumus nemainot relāciju struktūras. Cita Oracle relāciju-objektu fiziskā

struktūra ir atsauce (reference) – loģiskais rādītājs uz rindas objektu, kas ir veidots no objekta

identifikatora. Ar atsaucēm var modelēt asociācijas saites starp objektiem īpaši saiti daudzi

20

pret vienu, kas samazina vajadzību izmantot ārējas atsauces. Salikto atribūtu un saites daudzi

pret daudziem modelēšanai Oracle atbalsta divus kolekciju tipus – masīvi (varrays) un

iekļautās tabulas, kad tabula tiek glabāta citas tabulas kolonnā (10. att.).

10. att. Iekļauta tabula

Kolekciju tipi var būt izmantoti jebkur, kur tiek izmantoti citi datu tipi [17]

1.7. Citi modeli

Datu bāzu projektēšanai un realizācijai parasti izmanto relāciju, objektu vai relāciju-objektu

modeļus. Bet eksistē arī citi modeļi, kuri šobrīd vēl nav tik populāri, vai arī tie tiek izmantoti

specifiskiem mērķiem.

1.7.1. XML modelis

XML valoda, jeb paplašināmās iezīmēšanas valoda ir programmēšanas valodas SGML

apakškopa, kas speciāli izstrādāta darbam ar tīmekļa dokumentiem [8]. Valoda galvenokārt

tiek izmantota automātiskai datu apmaiņai starp tīmekļa lapām un uzņēmumiem.

XML dokuments ir datu bāze, kas satur gan datus, gan meta datus:

1) XML elementi un atribūti apraksta datus, tie atbilst relāciju datu bāzu tabulām un

laukiem;

2) strukturēts hierarhiskais XML dokuments apraksta attiecības starp dažādam datu

tipiem un ir daudzmaz līdzvērtīgs saitēm starp tabulām relāciju datu bāzēs, bet labāk

atbilst saišu struktūrai starp klasēm objektu modelī [21].

21

XML dokuments tiek organizēts teksta veidā, kas sniedz nozīmīgu priekšrocību – tas ir

universāli saprotams, bet arī trūkumus – šie dokumenti mēdz būt liela izmēra, var saturēt

dublējošus datus, lai šādu XML datni apstrādātu ir jāpārskata viss dokuments.

XML datu bāzes piemērs, meta dati ir iezīmēti ar treknrakstu:<planeta nosaukums="zeme"> <ieraksts regions="Afrika" valsts="Mauritānija" valoda="Bhojpuri" gads="1983" sievietes="99467" viriesi="97609"></ieraksts> <ieraksts regions="Afrika" valsts="Mauritānija" valoda="Franču" gads="1983" sievietes="19330" viriesi="16888"></ieraksts> <ieraksts regions="Eiropa" valsts="Somija" valoda="Čehu" gads="1985" sievietes="42" viriesi="36"></ieraksts>...</planeta>Šo XML datu bāzi var pārveidot relāciju tabulā (11. att.).

11. att. XML dokumenta pārveidošana relāciju tabulā

XML datu bāzes nekonkurē ar relāciju, objektu vai ar relāciju-objektu datu bāzēm. XML datu

bāzu uzdevums ir strādāt kopā ar tradicionālam datu bāzēm [28]. Kā jau bija minēts, galvenais

XML datu modeļa mērķis ir datu apmaiņa starp datu bāzēm, lietojumprogrammām.

1.7.2. Asociatīvais datu modelis

Asociatīvajā modelī datu bāze tiek veidota no divu tipu datu struktūrām:

datu vienumi (items), katram no kuriem ir unikālais identifikators, vārds un tips;

saites (links), katrai no kurām ir unikālais identifikators, kopā ar unikālajiem

identifikatoriem, kas attēlo fakta avotu, darbības vārdu un mērķi. Katrs no

objektiem – avots, darbības vārds un mērķis var būt saite vai datu vienums [28].

Piemēram, ir informācija „Flight BA1234 arrived at Riga Airport on 12-Aug-2006 at

10:25am” („Reiss BA1234 ir ielidojis Rīgas Lidostā 2006. gada 12. augustā, plkst. 10:25”,

asociatīva modeļa piemēros tiks lietota angļu valoda, jo pārtulkojot tos latviešu valodā

sastapās ar grūtībām, kas ir saistītas ar valodu īpatnībām. Lai modeļi varētu lietot neangļu

problēmvidei, tas ir jāadaptē). Piemērā ir septiņi datu vienumi: četri lietvārdi Flight BA1234, 22

Riga Airport, 12-Aug-2006 un 10:25am, un trīs darbības vārdi arrived at, on un at. Lai

uzglabātu šos datus ir vajadzīgas trīs saites:

Flight BA1234 arrived at Riga Airport

... on 12-Aug-2006

... at 10:25am

Ja apskata asociatīvo modeļi no relāciju modeļa viedokļa, tad asociatīvo datu bāzi var

uzglabāt divās tabulās – viena datu vienumiem un otra saitēm (1., 2. tabula).

1. tabula

Datu vienumi

Identifikators Vērtība77 Flight BA123408 Riga Airport32 12-Aug-200648 10:25am12 arrived at67 on09 at

2. tabula

Saites

Identifikators Avots Darbības vārds

Mērķis

74 77 12 0803 74 67 3264 03 09 48

Cits piemērs no grāmatu tirdzniecības sfēras [28]. Interneta grāmatu (book) veikals strādā

izmantojot tirdzniecības punktus (legal entity) dažādās valstīs (country). Lai klients (person)

varētu veikt pirkumu, tam ir jāreģistrējas sistēmā. Katram tirdzniecības punktam ir sava

grāmatu cena (price) vietējā valūtā. Pērkot grāmatas klients krāj punktus (points), kurus pēc

tam klients varēs izmantot atlaižu saņemšanai veikalā.

Fragments shēmai, kas apraksta pasūtījumu struktūru (datu vienumi treknrakstā):

Legal entity sells Books

... worth Points

... in Country

... from Date

... at Price23

Person lives in Country (12. att.)

12. att. Grāmatu tirdzniecības piemēra metadati

Grāmatu tirdzniecības piemēra dati (fragments, 13. att.):

13. att. Daļa no grāmatu tirdzniecības piemēra datiem

Relāciju modelī dati tiek glabāti, izmantojot atsevišķas tabulas atšķirīgo datu glabāšanai.

Katra tabula ir unikāli strukturēta, un programmas, kas ļauj lietotājam strādāt ar datu bāzi ir

atkarīgas no datu bāzes struktūras. Rezultātā, katru reizi izstrādājot datu bāzi ir jāizstrādā arī

24

lietojums, bet mainot esošas datu bāzes struktūru, jāmaina arī no šis datu bāzes ir atkarīgas

programmas.

Salīdzinājumā, datu bāzes, kas izmanto asociatīvo datu modeļi (associative model of data)

glāba atšķirīgus datus kopā vienā struktūrā, kura nekad nemainās, neatkarīgi no uzglabāto

datu tipu daudzuma [28]. Šādu datu bāzu lietojumprogrammas modeļa autori sauc par „patiesi

atkārtoti lietojamiem”.

1.7.3. Modelis Realitāte-Atribūts-Vērtība

Modelis Realitāte-Atribūts-Vērtība (Entity-Attribute-Value), RAV tiek lietots gadījumos, kad

atribūtu (īpašību, parametru) skaits, kas var tikt izmantots realitātes vai objekta aprakstam,

potenciāli ir ļoti liels, bet skaits, kas faktiski tiek attiecināts uz doto objektu ir relatīvi neliels

[27].

Populārākais RAV modelēšanas piemērs produkciju (production) datu bāzēs ir piemērs ar

klīniskiem datiem (slimības vēsture, pašreizējas sūdzības, fiziskā izmeklēšana, speciālie

pētījumi, diagnozes), kurus var attiecināt uz pacientu. Šādu datu var būt ļoti daudz, bet

lielākai daļai no pacientiem ir tikai maza daļa no iespējamiem datiem. Ja šādas sistēmas datu

bāzi veidot ar standarta līdzekļiem, būs vajadzīgas tabulas ar tūkstošiem kolonnām, kuru

lielāka daļa nebūs neaizpildīta, bet šādas lietojumprogrammas saskarne būs nelietojama.

Situāciju arī pasliktinās tas, ka vienam un tam pašam atribūtam būs iespējamas vairākas

vērtības, piemēram, bērna augums un svars mainās bērnam augot, arī medicīna attīstās un

sistēmai būs bieži jāpievieno jaunas tabulas un kolonnas ar jauniem iespējamiem testiem.

RAV modelis spēj risināt šis problēmas, lielākas klīnisko datu krātuves lieto tieši RAV

modeļi.

RAV tabulā dati tiek ierakstīti trīs kolonnās:

1) Realitāte. Klīniskajiem pētījumiem, tā ir ārēja atsauce uz tabulu, kas satur pacienta

identifikatoru un laiku (vai laika intervālu), kad ir noticis aprakstāmais gadījums

Piemēram, „Pacients Aldis Zariņš, p.k. 230977-11201, 2006. gada 15. februārī plkst.

12:15”

2) Atribūts vai parametrs. Ārēja atsauce uz tabulu ar atribūtu aprakstiem (piemēram,

laboratorijas izmeklējumu apraksti – atribūta identifikators, nosaukums, apraksts, datu

tips, mērvienības, iespējamas vērtības, maksimālais ieraksta garums u.c.)

25

Piemēram, „Ķermeņa temperatūra Celsija grādos”

3) Vērtība atribūtam. Ir atkarīga no datu tipa, citiem atribūta ierobežojumiem

Piemēram, „37,5”

RAV klīnisko izmeklējumu datu piemērs (3. tabula).

3. tabula

Klīniskie izmeklējumi

Realitāte Atribūts VērtībaPacients Aldis Zariņš, p.k. 230977-11201, 12:15 15.02.2006

Ķermeņa temperatūra Celsija grādos

37,5

Pacients Aldis Zariņš, p.k. 230977-11201, 12:15 15.02.2006

Klepus Jā

Pacients Aldis Zariņš, p.k. 230977-11201, 12:15 15.02.2006

Klepus veids Ar krēpām, asins piejaukums

Pacients Aldis Zariņš, p.k. 230977-11201, 12:15 15.02.2006

Sirds ritms, sitienu skaits minūtē

98

Modeļi realitāte-atribūts-vērtība var izmantot arī citās priekšmetiskās jomās, piemēram,

veikala čeku datu glabāšanai. Līdzīgi kā piemērā ar klīniskajiem datiem, čekā ir informācija

par mazu daļu no veikalā pieejamām precēm [27].

26

2. DATU BĀZU PROJEKTĒŠANA

Tiek lietotas dažādas datu bāzes projektēšanas tehnoloģijas. Tās cita no citas atšķiras ar

dažādiem gala lietotāju priekšstatu veidiem par projektējamo informācijas sistēmu. Tiek

meklēts priekšstata variants, kurš ir vislabāk saprotams, lai lietotājs varētu sniegt visvairāk

informācijas par savām vēlmēm viņam vispiemērotākā formā.

Sākotnēji izstrādājamo informācijas sistēmu apskatīja kā “melno kasti”, kurai ir zināmi

tikai ieejas un izejas dati (tātad tos bija jāuzzina no lietotāja). Izmantojot šo informāciju,

Džeksons izstrādāja vienu no pirmajām formalizētajām datu bāzes projektēšanas metodēm.

Turpinājumā datu bāzes projektēšanas speciālistu domas dalījās:

1) vieni uzskatīja, ka lietderīgi noskaidrot projektējamās sistēmas darbības

pamatfunkcijas un tajās figurējošos datus (šiem mērķiem tika izveidota, piemēram,

datu plūsmas diagramma);

2) otri, lietderīgi veidot visu izmantojamo datu savstarpējās saistības modeli (šim

mērķim tika izstrādāta, piemēram, realitāšu-saišu diagramma).

Attīstoties objektorientētai programmēšanai, tika radītas arī objektu datu bāzes. Līdz ar to

veidojās uzskats, ka datus lietderīgi analizēt objektu formā, papildus apskatot ar objektiem

veicamās darbības (metodes). Tika izstrādātas tādas informācijas sistēmas modelēšanas

metode kā UML valoda (Unified Modeling Language). UML valodas modelēšanas tehnika

ietvēra sevī vairākas diagrammas, bet datu bāzes projektēšanai nozīmīgākā bija klašu

diagramma.

Datu bāzes sistēmas projektēšanas pamatdarbību secība var atšķirties, bet tai jāiekļauj sevī

tādus punktus kā problēmvides analīze un modelēšana, prasību iegūšana, datu diagrammu

izveidošana, sākotnējo datu struktūru veidošana un to kvalitātes pārbaude, datu bāzes

struktūrās definēšana (14. att.).

27

14. att. Datu bāzes sistēmas projektēšanas pamatdarbību secība

Veidojot datu bāzi, dati tiek apskatīti un analizēti trīs līmeņos:

1) konceptuālais līmenis – lietotājs un datu bāzes izstrādātājs apskata problēmvides

datus, atlasa nepieciešamos un nosaka datu savstarpējas saites. Līmeņa rezultāts ir

pilnīgi neatkarīgs no datu bāzes realizācijas un tā var būt realitāšu-saišu diagramma,

UML klašu diagramma, arī kāds cits modelis (varianti tiek apskatīti šajā nodaļā);

2) loģiskais līmenis – datu bāzes projektētājs veido datu loģisko modeli noteiktām datu

bāzes sistēmas tipam, piemēram, relāciju, objektu vai relāciju-objektu (iespējamie

varianti tika apskatīti iepriekšējā nodaļā);

3) fiziskais līmenis – datu bāzes projektētājs realizē datu loģisko modeli konkrētai datu

bāzes vadības sistēmai, iegūstot datu glabāšanas fizisko struktūru definējumus,

piemēram, SQL kodu. Datu bāzes iegūšanas (transformācijas) varianti tiks apskatīti

nākamajā darba nodaļā (15. att.) [5].

28

15. att. Datu bāzes veidošana (trīs līmeņi)

Iespējams apskatīt datu bāzes veidošanas procesu divos līmeņos, apvienojot datu loģisko

un fizisko modeļi kopā (piemēram, no realitāšu-saišu diagrammas tiek iegūtas Oracle datu

bāzes struktūras), ka arī citi varianti.

Ka jau bija minēts, veidojot datu konceptuālo modeli nav svarīgi vai turpmāk tiks

izmantota relāciju datu bāze, objektu datu bāze vai relāciju-objektu datu bāze, šis modelis tiek

veidots neatkarīgi no datu bāzes realizēšanai izmantotā tehnoloģiskā varianta.

2.1. Realitāšu-saišu diagramma

Vispārēja realitāšu-saišu diagrammas notācijas standarta nav – dažādās grāmatās un

programmatūrā tiek lietotās atšķirīgas notācijas [9, 24].

29

2.1.1. Realitāte un realitātes atribūts

Realitāte (entity) ir “priekšmets” vai “objekts” reālajā pasaulē, kas ir skaidri atšķirams no

citiem objektiem [6, 24].

Modernajā literatūrā bieži ar terminu “realitāte” (entity) apzīmē nevis realitāti klasiskajā

nozīmē, bet gan realitātes eksemplāru. Šādos gadījumos realitātes (entity) termina vietā

izmanto terminus realitāšu kopa (entity set), realitāšu tips [6] vai pat realitāšu klase (entity

class). Šāda terminoloģijas attīstība, iespējams, ir saistīta ar objektu tehnoloģijas ietekmi –

entity atbilst objektam, bet entity set vai entity class atbilst klasei.

Realitātes atribūts – realitāti veidojošās datu kopas elements. Tas var identificēt

realitātes eksemplāru vai norādīt tā īpašību (16. att.). Var būt vienkāršie un saliktie atribūti

(apvieno vairākas datu vienības)

16. att. Realitāte ar atribūtiem

Bieži realitātes atribūti grafiski netiek apzīmēti elipšu veidā, bet tiek izvietoti iekš realitātes

taisnstūra (17. att.).

17. att. Realitāte ar atribūtiem (cits grafisks apzīmējums)

Ir izmantojami arī citi realitātes apzīmējumi (piemēram, taisnstūris ar noapaļotiem stūriem

Barkera notācijā), kā arī ir iespējams veidot realitāšu-saišu diagrammas zemākajā detalizācijas

līmenī, nenorādot atribūtus [31].

Atribūtu, kurš satur pats savus atribūtus sauc par salikto atribūtu (composite, complex

attribute ) [26]. Salikta atribūta piemērs ir atribūts adrese, kurš var sastāvēt no atribūtiem iela,

mājas numurs, pasta indekss (18. att.).

30

18. att. Saliktais atribūts

Primāras atslēgas atribūti, jeb identifikatori tiek izmantoti, lai varētu atšķirt vienu

realitātes eksemplāru no cita. Diagrammā atslēgas atribūti tiek pasvītroti, iespējami arī citi

apzīmējumi (19. att.).

19. att. Atslēgas atribūts (Kods)

Realitātei var nebūt pietiekami daudz atribūtu lai izveidotu primāro atslēgu. Šādu realitāti

sauc par vājo realitāti (weak entity) (20. att.) [24]. Vājas realitātes eksistence ir atkarīga no

citas realitātes eksistences, piemēram, ja Darbiniekam ir piesaistīta vāja realitāte Automašīna

(realitāšu saišu jēdziens tiks apskatītas zemāk) un informācija par darbinieku vairāk netiek

uzglabāta, tad nav nepieciešama arī informācijas par viņa automašīnām [2].

20. att. Vāja realitāte

Eksistē realitāšu-saišu diagrammas notācijas, kur tiek arī norādīts atribūta obligātums. Ja

atribūts ir obligāts (mandatory), tas nozīme, ka realitātes eksemplārs nevar pastāvēt bez šī

atribūta vērtības. Piemēram, Darbiniekam obligāts atribūts ir darbinieka numurs un darbinieka

vārds, bet atribūts faksa numurs ir neobligāts (21. att.) [9].

31

21. att. Atribūta obligātuma un atslēgas atribūta apzīmējums realitāšu-saišu diagrammas

Barkera notācija

Barkera realitāšu-saišu diagrammas notācijā neobligātie atribūti tiek apzīmēti ar neiekrāsota

punkta “°” simbolu, bet obligātie – ar zvaigznītes “*” simbolu (obligātiem atribūtiem ir

iespējams arī iekrāsota punkta apzīmējums “•”). Atslēgas atribūti Barkera notācijā tiek

apzīmēti ar “#” simbolu.

2.1.2. Saites un kardinalitāte

Saite (relationship) ir attieksme starp realitātēm [24]. Saitēm realitāšu-saišu diagrammās

parasti tiek piekārtota kardinalitāte (jeb attieksmes apjoms), kura ir attēlota ar ciparu, kurš

attēlo realitātei atbilstošo realitātes eksemplāru skaitu [12].

Izšķir sekojošus bināru saišu tipus:

viens pret vienu (one-to-one) – 1:1 attiecība;

viens pret daudziem (one-to-many) – 1:N attiecība (22. att.);

22. att. Saite viens pret daudziem

daudzi pret daudziem (many-to-many) – N:M attiecība (23. att.).

32

23. att. Saite daudzi pret daudziem

Atribūtu piesaiste saitēm ir iespējama ne visās realitāšu-saišu notācijas (šādu iespēju

sniedz, piemēram, Cena notācija). Visbiežāk saišu atribūtus izmanto saitēm daudzi pret

daudziem (23. att.) [26].

Kaut arī modelējot visbiežāk tiek izmantotas binārās saites (saites starp divām realitātēm),

ir iespējamas unārās saites (vienas realitātes robežās), arī augstākas kārtas attieksmes (n-ārās,

piemēram, ternārās saites) (24., 25. att.) [26].

24. att. Unārā saite

25. att. Ternārā saite

Ar kardinalitātes palīdzību tiek noteiks maksimālais realitātes eksemplāru skaits. Daudzās

realitāšu-saišu diagrammu notācijās tiek izmantoti apzīmējumi minimālam realitātes

eksemplāru skaitam – saite var būt obligāta (mandatory), ja jāpastāv kaut vienam realitātes

eksemplāram, vai neobligāta (optional), kad šāds eksemplārs var arī nebūt [25]. Piemēram,

var uzskatīt, ka raksts nav iespējams bez autora (obligāta saite), bet ir iespējama situācija, kad

33

autoram nav rakstu (neobligāta saite). Dažādās realitāšu-saišu notācijās ir iespējami atšķirīgi

saites obligātuma apzīmējumi (26. att.).

26. att. Saites obligātums

Piemēram, firmai var nebūt darbinieku, var būt vairāki darbinieki, bet darbiniekam jābūt

obligāti piesaistītam kādai firmai.

2.2. UML klašu diagramma

Vienota modelēšanas valoda (Unified Modeling Language, UML) ir standartizēta

specifikācijas valoda objektorientētai modelēšanai. UML iekļauj sevī grafisko notāciju, kuru

izmanto sistēmas abstrakta modeļa, jeb UML modeļa radīšanai [27].

Valoda tika izstrādāta ar mērķi rādīt universālo valodu priekšmetiskas jomas, kā arī

konkrēta programmēšanas uzdevuma aprakstam. Jebkurš no uzdevumiem tiek projektēts

veidojot noteiktu diagrammu kopumu.

Kaut UML tika izstrādāts objektorientētai programmatūras izstrādei, to var izmantot arī

neobjektorientēto datu bāzu projektēšanai [16]. Pirms modelēt datu bāzi ir jāveic biznesa

modelēšana, jānosaka prasības sistēmai, šiem mērķiem var izmantot virkni UML diagrammu,

bet pašu datu bāzes modeļi parasti veido ar klašu diagrammas palīdzību (darbā nav apskatīts

kāds noteikts UML standarts, bet UML klašu diagrammu pamatidejas, kuras izmanto datu

bāzu projektēšanā).

2.2.1. Klase un klases atribūti

Klase grafiski tiek attēlota taisnstūra veidā, kas papildus var būt sadalīts sekcijās. Šādās

sekcijās var būt norādīti klases vārds, atribūti un operācijas [22, 33].

34

Darbinieks----

vardsuzvardsalgaamats

: String: String: Number: String

+++

getVards ()getUzvards ()atlaist ()

: char: char: void

27. att. Klases grafisks attēlojums

Datu bāzu modelēšanā UML klase atbilst realitātei (ja modelēšanai izvēlas realitāšu-saišu

diagrammu) vai tabulai (realizācijā).

Klases atribūti parasti tiek norādīti zem klases vārda (vārds un uzvārds, 27. att.).

Realizācijā klases atribūti atbilst tabulas kolonnām.

2.2.2. Klases operācijas (metodes)

Viena no galvenajām objektu pieejas īpašībām ir tā, ka objekti tiek apskatīti kopā ar to

uzvedību. Realitāšu-saišu modelī nav elementu, kas atbilst klases operācijām, bet realizācijā

metodes varētu atbilst iekļautām procedūrām.

Klases grafiskajā apzīmējumā metožu saraksts parasti ir attēlots zem atribūta saraksta.

2.2.3. Asociācijas saite (attiecības starp klasēm)

Asociācijas (associaton) saite var pastāvēt vienas klases robežās (28. att.). Šādā gadījumā tā

atbilst unārai saitei realitāšu-saišu diagrammā, bet realizācijā tabulai tiek pievienots papildus

lauks.

0..1

0..*Firma---

numursnosaukumsadrese

: int: String: String

28. att. Asociācijas saite vienas klases ietvaros (meitas firma)

35

Visbiežāk asociācijas saite tiek izmantota divu klašu sasaistei (binārā saite). Šāda saite var

atbilst realitāšu-saišu diagrammas saitei viens pret vienu, viens pret daudziem vai daudzi pret

daudziem (29., 30. att.).

0..10..*

Darbinieks----

vardsuzvardsalgaamats

: String: String: Number: String

Firma---

numursnosaukumsadrese

: int: String: String

29. att. Asociācijas saite starp divām klasēm (0..1 un 0..*) – vienai firmai ir vairāki darbinieki

0..*0..*

Darbinieks----

vardsuzvardsalgaamats

: String: String: Number: String

Firma---

numursnosaukumsadrese

: int: String: String

30. att. Asociācijas saite starp divām klasēm (0..* un 0..*) – vienai firmai ir vairāki darbinieki,

darbinieks var strādāt vairākās firmās

Klašu diagrammā asociācijas saitei var būt piesaistīta asociācijas klase (31. att.).

0..*

0..*

Darbinieks----

vardsuzvardsalgaamats

: String: String: Number: String

Firma---

numursnosaukumsadrese

: int: String: String

Algo- datums : Date

31. att. Asociācijas saitei ir piesaistīta klase (0..* un 0..*)

Realitāšu-saišu diagrammā atbilstības šādai attiecībai nav (tikai paplašinātājā realitāšu-saišu

diagrammā, ir šādas diagrammas varianti arī ar citiem UML klašu diagrammas elementiem),

bet realizācijā šādas trešās klases atribūti var tikt piesaistīti vienai no pārējam klasēm, bet

gadījumā ar daudzi pret daudziem tiek izveidota trešā tabula, kas arī satur šai saitei piesaistītas

klases atribūtus.

36

2.2.4. Vispārinājuma saite

Vispārinājuma (generalization) saite apraksta attiecības starp vispārīgāko elementu (vecāku)

un specifiskāko (bērnu). Bērns pilnībā atbilst vecākam, bet satur papildus informāciju (32.

att.).

Organizacija---

numursnosaukumsadrese

: int: String: String

Bezpelnas- finansetajs : String

AkcijuSabiedriba--

kapitalsapgrozijums

: Number: Number

32. att. Vispārinājuma saite starp klasēm

Viens no vispārinājuma saites izmantošanas mērķiem ir mantošana [22].

2.2.5. Agregācijas saite

Agregācijas (aggregation) saite ir asociācijas saites forma, kas apraksta attiecību vesels-daļa

(piemēram, automašīnai ir riteņi un dzinējs, 33. att.)

0..10..*

Automasina- izlaidums : Date

Ritenis--

gaisaSpiediensriepa

: Number: String

33. att. Agregācijas saite – automašīna „satur” riteņus

2.2.6. Kompozīcijas saite

Kompozīcija (composition) saite ir asociācijas saites forma, kurā bērns nevar pastāvēt bez

vecāka (piemēram, darbiniekam noteikti jābūt piesaistītai firmai, bet firma, savukārt, var būt

bez darbiniekiem, 34. att.).

37

0..1

0..*Darbinieks

----

vardsuzvardsalgaamats

: String: String: Number: String

Firma---

numursnosaukumsadrese

: int: String: String

34. att. Kompozīcijas saite

2.3. Paplašināta realitāšu-saišu diagramma

Mūsdienās datu bāzi projektē ar realitāšu-saišu diagrammu, kurai ir pievienoti citi, papildus

elementi. Šādi elementi arī ir iekļauti modernajos CASE rīkos (piemēram, Oracle Designer

papildināja savu realitāšu-saišu diagrammu ar „vai” saiti, bet PowerDesinger piedāvā

ER+Merise notāciju), bet diagrammu sauc par paplašināto realitāšu-saišu diagrammu

(extended, advanced entity-relationship diagramm). Sakarā ar objektorientētas koncepcijas

attīstību, visbiežāk realitāšu-saišu diagrammai pievieno UML diagrammas elementus.

Runājot par paplašināto realitāšu-saišu diagrammu, pirmkārt piemin vispārinājumu,

(generalization). Vispārinājuma saite nosaka to, ka atsevišķas realitātes ar kādiem kopīgiem

atribūtiem var būt vispārināti uz augstāka līmeņa realitāti, ko sauc par vispārējo (generic),

superklases vai supertipa realitāti. Apakšēja līmeņa realitātes – apakštipu realitātes,

vispārinājuma hierarhijā var pārklāties (overlapping) vai nepārklāties (disjoint) (35. att.) [26]

[25, 31].

35. att. Vispārinājums ar apakštipiem, kas nepārklājas

Diagramma apraksta situāciju, kurā Darbinieks var būt Vadītājs, vai Operators, vai

Apkopējs, vai Sekretāre (36. att.). Nepārklāšanas (apzīmēta ar „d” burtu) nozīme, ka viens

Darbinieks nevar būt Operators un, piemēram, Apkopējs vienlaicīgi.

38

36. att. Vispārinājums ar apakštipiem, kas pārklājas, ar pilnīguma ierobežojumu

Šajā situācijā apakštipi pārklājas („o” burts diagrammā) – Cilvēks var būt apskatīts gan kā

Darbinieks, gan kā Pircējs vienlaicīgi (36. att.). Pilnīguma ierobežojums tiek apzīmēts ar

dubulto līniju, un tas nozīme, ka apakštipu kopa ir pilna – vienīgi iespējamie Cilvēka tipi datu

bāzē ir Darbinieki un Pircēji.

Eksistē realitāšu-saišu diagrammas notācijas (piemēram, Barker notācija), kur apakštipi

grafiski tiek izvietoti iekš supertipiem (37. att.) [25].

37. att. Vispārinājuma saite

Vispārinājuma saiti sauc arī par „ir” saiti („is-a” relationship) starp apakštipiem un

supertipu (Darbinieks ir Cilvēks, Operators ir Darbinieks, Vīrietis ir Cilvēks u.t.t.).

Līdzīgi kā vispārinājuma saite, agregācijas saite, ir saites forma starp supertipu un

apakštipu, bet pretēji „ir” saitei, agregācijas saite apraksta attiecību vesels-daļa, tāpēc šo saiti

sauc arī par „daļa no” saiti („part of” relationship) [26] . Piemēram, Lietotāja rokasgrāmata

ir daļa no Programmatūras produkta (38. att.).

39

38. att. Agregācijas saite (saite „daļa no”)

Oracle veidotājā projektēšanas rīkā Designer eksistē loģiskā „vai” saite (39. att.).

Att. 39. „Vai” saite

„Vai” saite (arc) ir ierobežojums divām vai vairākām realitātes saitēm. No visām „vai” saitēm

vienlaicīgi spēkā var būt tikai viena (cilvēks ir vai vīrietis, vai sieviete, ne abi vienlaicīgi).

Eksistē arī citi realitāšu-saišu diagrammas paplašinājumu elementi. Šādu elementu

izmantošana ļauj projektētam precīzāk aprakstīt problēmvidi.

2.4. Citi modeļi

Datu bāzes konceptuāla līmeņa izveidošanai var pielietot ne tikai realitāšu-saišu diagrammu

vai UML klašu diagrammu. Eksistē arī daudzi citi modeļi, bet vairākums no tiem vai nu vēl

nav guvis popularitāti, vai tiek lietots šaurās nozarēs. Piemēram, objektu-lomu modelēšanas

(Object-Role Modeling) īpatnība ir tā, ka diagrammas sintakse ir sarežģīta [9]. MADS pieeja

tiek pielietota pārsvarā telpiski-temporālo datu bāzu konceptuālai projektēšanai [18].

Salīdzinoši populārā ir dimensiju un datu noliktavu modelēšana [1].

40

3. CASE RĪKI

CASE tehnoloģija (Computer-Aided Software Engineering, CASE) ir „datoru un specializētas

programmatūras izmantošana programmu sastādīšanai” [8]. Šāda specializēta programmatūra

var ievērojami atvieglot datu bāzu izstrādi, jo ļauj no projektējuma (diagrammām) iegūt datu

bāzes fiziskās struktūras. Lai varētu spriest par tehnoloģijas stāvokli, tika apskatīti vairāki

CASE rīki, kuru specializācija ir datu bāzu modelēšana. Apskatītos rīkus var klasificēt

sekojošā veidā:

Rīki datu bāzu un lietojumu izstrādei

Silverrun,

PowerDesigner,

Visible Analyst un Visible Developer,

Telelogic System Architect un Telelogic TAU (vāja datu bāzu modelēšanas daļa –

uzsvars uz biznesa procesiem),

Embarcadero ER/Studio un Describe.

Rīki datu bāzu izstrādei (neatbalsta lietojumu ģenerēšanu):

Altova DatabaseSpy (rīks ar zemo funkcionalitāti);

Erwin;

Toad Data Modeler;

Xcase.

Rīki diagrammu zīmēšanai (specializējas diagrammu veidošanā, bet var iekļaut

ierobežotas iespējas datu bāzu ģenerēšanai):

Dia (bezmaksas rīks);

Concept Draw (datu bāzu diagrammas var pārveidot kodā);

Microsoft Visio.

Vēl viens izplatīts rīks DB Visual Architect ir veidots Mac OS operētājsistēmai, tāpēc šis rīks

netika apskatīts.

Visiem rīkiem ir pieejamas demonstrācijas versijas (var lejupielādēt mājas lapā vai pasūtīt

pa pastu) ar lietošanas laika ierobežojumu (15 vai 30 dienas) vai ierobežotu funkcionalitāti

(piemēram, ierobežots modeļa elementu skaits).

Apskatot CASE rīku funkcionalitāti, radās vairāki secinājumi par stāvokļi šajā sfērā.

Pirmkārt, rīku modelēšanas iespējas ir ierobežotas. Piemēram, ar tiem nevar veidot ternārās

41

saites vai „vai” tipa saites. Attiecībā par struktūrām, ko var iegūt, lietojot CASE projektēšanas

rīkus:

1) relāciju datu bāzes (SQL) – relāciju struktūras var iegūt izmantojot gandrīz visus

CASE rīkos;

2) objektu datu bāzes (piemēram, Java vai C#) – tikai dažos CASE rīkos no projektējuma

var iegūt objektu struktūras, piemēram, PowerDesigner;

3) relāciju-objektu datu bāzu struktūras (SQL ar objektu iespējam) – neviens no

apskatītājiem CASE rīkiem šādas iespējas nesniedz, kaut arī relāciju-objektu

tehnoloģija ir vairāk nekā 10 gadu veca un to atbalsta tādi vadošie datu bāzu vadības

sistēmu ražotāji kā Oracle, IBM un PostgreSQL.

Kaut arī eksistē daudzi automatizētas projektēšanas rīki, kas ļauj veidot relāciju datu

bāzes, parasti šis izveidotas struktūras ir pārāk vienkāršas, t.i. netiek izmantotas visas iespējas,

ko var sniegt relāciju modelis un SQL. Piemēram, CASE rīki pārsvarā ģenerē tabulas un

saites (ārējas atsauces), tiek aizmirsts par vairākām pārējam fiziskām struktūrām, kas var

ievērojami uzlabot datu bāzes kvalitāti – skatiem, indeksiem, pārbaudes ierobežojumiem.

Bieži vienam un tam pašam projektējumam var atbilst vairākas realizācijas. Piemēram,

viens pret vienu saiti starp divām realitātēm parasti realizē, veidojot divas tabulas ar ārējam

atsaucēm, bet kādā konkrēta gadījumā šādu saiti varētu realizēt arī ar vienas tabulas palīdzību.

Īpaši daudz tādu izvēles variantu varētu būt objektu-relāciju datu bāzē, kur var izmantot

relāciju un objektu tehnoloģiju iespējas kopā, vienai tabulai veidot objektu struktūru, bet citai

relāciju. CASE rīki piedāvā šādus variantus ļoti ierobežotā apjomā, rezultātā atkal ir ietekmēta

datu bāzes kvalitāte.

Kopumā jāsecina, ka CASE rīkiem ir daudz attīstības iespēju un kaut tie var ievērojami

palīdzēt datu bāzu projektēšanā to funkcionalitāte ir nepietiekama – lai izejā saņemtu labāku

produktu, kvalitatīvāko datu bāzi, CASE rīku ģenerētas struktūras ir jāuzlabo manuāli.

42

4. TRANSFORMĀCIJAS LIKUMI

Transformācijas likumi ļauj no projektējuma iegūt datu bāzi (no konceptuāla līmeņa iegūt

loģisko, no loģiskā fizisko, pašu datu bāzi, piemēram, SQL kodu). Apskatot literatūru un

modernus CASE rīkus, tika secināts, ka pastāv trīs populārākie datu bāzes projektēšanas

paņēmieni – realitāšu-saišu diagramma, UML klašu diagramma un paplašināta realitāšu saišu

diagramma (realitāšu-saišu diagramma ar papildus iespējam, arī tām, ko sniedz UML). Tāpat,

eksistē trīs populārākie datu bāzu realizācijas veidi – relāciju, objektu un relāciju-objektu

(apvieno relāciju un objektu datu bāzu funkcionalitāti) (40. att.).

40. att. Datu bāzes datorizētā projektēšana

Nodaļā tiek apskatīta objektu (UML klašu diagramma) un relāciju (realitāšu-saišu un

paplašināta realitāšu saišu diagramma) projektēšanas elementu transformācija relāciju (SQL)

un relāciju-objektu struktūrās (SQL standarts, datu bāzu ražotāju realizācija) arī šo

projektēšanas elementu savstarpēja atbilstība.

43

4.1. Relāciju datu bāzes transformācijas likumi

Relāciju datu bāzes ir visplašāk atbalstītas ar CASE rīkiem. Lielākoties CASE rīki veic tikai

vienkāršas transformācijas ar unārām saitēm, binārām saitēm (viens pret vienu, viens pret

daudziem, daudzi pret daudziem). CASE rīkos parasti nav iekļautas ternāro saišu

transformācijas, arī vispārinājumu un agregācijas saites CASE rīku diagrammās ir pārstāvēti

ierobežoti, tāpēc šis transformācijas apskatīt darbā bija īpaši svarīgi.

CASE rīku veidotas struktūrās parasti ir ierobežotas ar tabulām, unikalitātes

ierobežojumiem, primāras atslēgas ierobežojumiem, ārējas atsauces ierobežojumiem. Netiek

lietotas tādas struktūrās kā indeksi, pārbaudes ierobežojumi, trigeri, skati. Darbā tiek

piedāvāts lietot skatus vispārinājuma saites realizēšanai, bet pārbaudes ierobežojumus „vai”

saites realizēšanai.

4.1.1. Vienkāršas struktūras

Realitāšu-saišu diagrammas realitāte atbilst UML klašu diagrammas klasei, galvenā atšķirība

ir metodes, kurus realitāšu-saišu diagrammā attēlot nav iespējams. Gan klase, gan realitāte,

veicot transformācijas likumus tiek pārveidota tabulā.

4.1.2. Unārā saite

Unārai saitei viens pret vienu un viens pret daudziem atbilst viena tabula. Tabula ir

jāpapildina ar ārējas atsauces atribūtu, kuras domēns sakrīt ar primāras atslēgas atribūtu.

Daudzi pret daudziem saitei ir jāveido otrā tabula ar divām ārējam atslēgām.

4.1.3. Binārā saite

Viens pret vienu saites gadījumā, ja abas realitātes ir obligātas, tad katra no realitātēm kļūst

par tabulu un vienas tabulas obligātais un unikālais (not null, unique) atribūts kalpo par ārējo

44

atsauci. Gadījumā ar vienu obligātu realitāti, transformācijas likumi ir tie paši. Ja ir divas

neobligātas realitātes, tad ārējas atsauces atribūts nav unikāls un obligāts.

Viens pret daudziem saite var būt obligāta vai neobligāta „daudzi” pusē, neietekmējot

transformāciju. Ārējas atsauces atribūtam ir jāparādās pusē „daudzi”, un šī atribūta vērtībai

jābūt obligātai (not null) tikai gadījumā ja „viens” realitāte ir obligāta (piemēram, UML

gadījumā 1..1, nevis 0..1).

Binārai saitei daudzi pret daudziem ir jāizveido jaunā, trešā tabula, kas saturēs abu

realitāšu primāras atslēgas. Saišu obligātums transformāciju neietekmē.

4.1.4. Ternārā un n-ārās saite

Ir (n+1) n-ārās saites iespējamie veidi: visas n puses ar kardinalitāti „viens”, (n -1) puses ar

kardinalitāti „viens” un viena puse ar kardinalitāti „daudzi”, (n -2) puses ar kardinalitāti

„viens” un divas puses ar „daudzi”, līdz visbeidzot visas puses ir „daudzi”. Šādas saites

realizācijai jāveido jaunā tabula (kopējais tabulu skaits n+1). Šī tabula satur ārējas atslēgas uz

visām realitāšu tabulām.

4.1.5. Vispārinājuma un agregācijas saite

Katrai no realitātēm tiek veidota atsevišķa tabula, apakštipa realitāšu tabulas satur ārējas saites

uz supertipa realitāšu tabulām.

Šo pašu saiti var realizēt citādi, izveidojot vienu tabulu ar visu supertipu un apakštipu

realitāšu atribūtiem, bet apakštipu realitāšu tabulu vietā izveidojot skatus.

Agregācijas saites gadījumā atribūti netiek mantoti – katra no realitātēm satur savu

atribūtu kopu. Šādu saiti var realizēt kā viens pret daudziem saiti, vai saiti viens pret vienu,

atkarībā no loģikas.

Plašāk ar transformācijas likumiem var iepazīties ar piemēru palīdzību (4. tabula) [26].

Tabulā lietotie apzīmējumi:

1) <pa> - primāras atslēgas ierobežojums,2) <O> - obligāts (mandatory, not null),3) <āa> - ārējas atsauces ierobežojums (foreign key).

45

4. tabula

Relāciju datu bāzes transformācijas likumi

KONCEPTUĀLAIS LĪMENIS LOĢISKAIS UN FIZISKAIS LĪMENIS

Objektorientēta pieeja (UML klašu diagramma)

Relāciju pieeja (realitāšu-saišu diagramma)

Relāciju pieeja, SQL valoda

Klase Realitāte Tabula

create table Darbinieks ( ...);

Klases atribūts Realitātes atribūts Tabulas kolonna

create table Darbinieks ( numurs INTEGER, vards VARCHAR2(30), uzvards VARCHAR2(30), alga NUMBER, amats VARCHAR2(150), constraint PK_DARBINIEKS primary key (numurs));

46

Atslēgas atribūts Atslēgas atribūts Primāras atslēgas kolonna

create table Darbinieks ( numurs INTEGER, ... constraint PK_DARB primary key (numurs));

– Atribūta obligātums Kolonnas vērtības obligātums

create table Darbinieks ( ... vards VARCHAR2(30) not null, ...);

Klases metode – Iekļautas procedūras

47

Unārā saiteUnārā asociācijas saite (0..1 : 0..1)

Ir iespējama situācija, kad darbinieks ir laulāts ar citu kompānijas darbinieku.

Unārā saite viens pret vienu (abas puses neobligātas)

Tabula ar ārējo atsauci

create table Darbinieks ( numurs CHAR(6), vards VARCHAR(20), lau_numurs CHAR(6), constraint PK_DARBINIEKS primary key (numurs), constraint FK_DAR_DAR foreign key (lau_numurs) references Darbinieks (numurs));

Unārā asociācijas saite (1 : 0..*) Unārā saite viens pret daudziem (puse „daudziem” neobligāta, puse „viens” obligāta)

Viena tabula ar ārējo atsauci

48

create table Inzenieris ( numurs CHAR(6), vards VARCHAR(20), vad_numurs CHAR(6) not null, constraint PK_INZENIERIS primary key (numurs), constraint FK_INZ_INZ foreign key (vad_numurs) references Inzenieris (numurs));

Unārā asociācijas saite (0..* : 0..*)

Katram darbiniekam ir iespēja būt par atskaites līdzautoru kopā ar citiem darbiniekiem, vai arī uzrakstīt atskaiti vienam.

Unārā saite daudzi pret daudziem (abas puses neobligātas)

Divas tabulas (viena ar divām ārējām atsaucēm)

create table Darbinieks ( numurs CHAR(6), vards VARCHAR(20), constraint PK_DARBINIEKS primary key (numurs));

create table Lidzautors ( autora_numurs CHAR(6), lidzaut_numurs CHAR(6), constraint PK_LIDZAUTORS primary key (autora_numurs, lidzaut_numurs), constraint FK_LID_DAR1 foreign key (autora_numurs) references Darbinieks (numurs), constraint FK_LID_DAR2 foreign key (lidzaut_numurs)

49

references Darbinieks (numurs));

Binārā saite viens pret vienuAsociācijas saite (1 : 1)

Katrai atskaitei ir viena abreviatūra un katra abreviatūra reprezentē tieši vienu atskaiti.

Saite viens pret vienu (abas realitātes obligātas)

Divas tabulas (viena ar ārējo atsauci)

create table Atskaite ( numurs INTEGER, nosaukums VARCHAR2(150), constraint PK_ATSKAITE primary key (numurs));create table Abreviatura ( abr_numurs CHAR(6), atsk_numurs INTEGER not null unique, constraint PK_ABREVIATURA primary key (abr_numurs), constraint FK_ABR_ATS foreign key (atsk_numurs) references Atskaite (numurs));

Asociācijas saite (0..1 : 1)

Jābūt vadītājam priekš katra departamenta, bet darbinieks var vadīt ne vairāk par vienu departamentu.

Saite viens pret vienu (viena no realitātēm ir obligāta)

Divas tabulas (viena ar ārējo atsauci)

Transformācija sakrīt ar iepriekšējo gadījumu

50

Asociācijas saite (0..1 : 0..1)

Daži no datoriem ir piesaistīti inženieriem, bet ne obligāti visiem inženieriem ir dators.

Saite viens pret vienu (abas realitātes ir neobligātas)

Divas tabulas (viena ar ārējo atsauci)

create table Inzenieris ( inz_numurs INTEGER, dat_numurs INTEGER, constraint PK_INZENIERIS primary key (inz_numurs));create table Dators ( dat_numurs INTEGER, inz_numurs INTEGER, constraint PK_DATORS primary key (dat_numurs), constraint FK_DAT_INZ foreign key (inz_numurs) references Inzenieris (inz_numurs));

Binārā saite viens pret daudziemAsociācijas saite (1..1 : 1..*)

Katra prece ir piesaistīta tieši vienai partijai, partijā var būt viena vai vairākas preces.

Saite viens pret daudziem (abas realitātes obligātas)

Divas tabulas (viena ar ārējo atsauci)

Jāizveido ārējas atsauces lauks (partijas numurs), šī lauka vērtība nevar būt nedefinēta („null”).

create table Prece ( ...

51

par_numurs INTEGER not null, ... constraint FK_PRE_PAR foreign key (par_numurs) references Partija (numurs));

Asociācijas saite (0..1 : 0..*)

Darbinieks var strādāt maksimāli vienā firmā (vai būt nepiesaistīts nevienai no firmām). Firma var būt neviens darbinieks vai daudzi darbinieki.

Saite viens pret daudziem (abas realitātes neobligātas)

Divas tabulas (viena ar ārējo atsauci)

Jāizveido ārējas atslēgas lauks (numurs firmai, kurā strādā darbinieks)

create table Darbinieks ( ... fir_numurs INTEGER, ... constraint FK_DAR_FIR foreign key (fir_numurs) references Firma (numurs));

Asociācijas saite (0..1 : 1..*)

Katrs departaments publicē vienu vai vairākas atskaites. Nav obligāti, ka kāda konkrēta atskaite ir departamenta publicēta.

Saite viens pret daudziem (realitāte „daudzi” obligāta, realitāte „viens” neobligāta)

Divas tabulas (viena ar ārējo atsauci )

Transformācija sakrīt ar iepriekšējo gadījumu

52

Binārā saite daudzi pret daudziemAsociācijas saite (0..* : 0..*)

Katrs darbinieks var strādāt nevienā, vienā vai vairākās firmās, bet katrā firmā ir neviens, viens, vai vairāki darbinieki.

Saite daudzi pret daudziem (abas realitātes neobligātas)

Trīs tabulas

Jāizveido trešā tabula ar divām ārējam atsaucēm.

create table FirmasDarbinieki ( fir_dar_numurs INTEGER not null, fir_numurs INTEGER, dar_numurs INTEGER, constraint PK_FIRDARB primary key (fir_dar_numurs), constraint FK_FIRDAR_FIR foreign key (fir_numurs) references Firma (numurs), constraint FK_FIRDAR_DAR foreign key (dar_numurs) references Darbinieks (numurs));

Ternārā un n-ārā saiteTernārā asociācijas saite 1 : 1 : 1 Ternārā saite 1:1:1 Četras tabulas (viena ar trim ārējam atsaucēm)

53

Darbinieks izmanto tieši vienu datoru priekš katra no projektiem. Katrs dators projektā tiek piesaistīts darbiniekam. Darbinieks var strādāt vairākos projektos, katrā no tām izmantojot citu datoru.

create table Darbinieks ( dar_numurs CHAR(6), constraint PK_DARBINIEKS primary key (dar_numurs));

create table Projekts ( proj_nosaukums CHAR(100), constraint PK_PROJEKTS primary key (proj_nosaukums));

create table Dators ( dat_numurs INTEGER, constraint PK_DATORS primary key (dat_numurs));

create table Lieto_datoru ( dar_numurs CHAR(6), proj_nosaukums CHAR(100), dat_numurs INTEGER not null, constraint PK_LIETO_DATORU primary key (dar_numurs, proj_nosaukums), constraint FK_LIE_DAR foreign key (dar_numurs) references Darbinieks (dar_numurs), constraint FK_LIE_PRO foreign key (proj_nosaukums)

54

references Projekts (proj_nosaukums), constraint FK_LIE_DAT foreign key (dat_numurs) references Dators (dat_numurs), unique (dar_numurs, dat_numurs), unique (proj_nosaukums, dat_numurs));

Ternārā asociācijas saite 1 : 1 : 1..*

Katrs projektam piesaistītais darbinieks strādā šīm projektam paredzētājā vietā (izvietojums), bet var strādāt arī kādā citā projektā, atbilstoši citā vietā. Jebkurā no izvietojumiem var strādāt vairāki darbinieki.

Ternārā saite 1:1:N Četras tabulas (viena ar trim ārējam atsaucēm)

No iepriekšēja gadījuma atšķiras unique() sekcija SQL izteiksmē.

create table Darbinieks ( dar_numurs CHAR(6), constraint PK_DARBINIEKS primary key (dar_numurs));

create table Projekts ( proj_nosaukums CHAR(100), constraint PK_PROJEKTS primary key (proj_nosaukums));

create table Izvietojums(

55

izv_nosaukums CHAR(100), constraint PK_DATORS primary key (dat_numurs));

create table Piesaistits ( dar_numurs CHAR(6), proj_nosaukums CHAR(100), izv_nosaukums CHAR(100) not null, constraint PK_PIESAISTITS primary key (dar_numurs, proj_nosaukums), constraint FK_PIE_DAR foreign key (dar_numurs) references Darbinieks (dar_numurs), constraint FK_PIE_PRO foreign key (proj_nosaukums) references Projekts (proj_nosaukums), constraint FK_PIE_IZV foreign key (dat_numurs) references Izvietojums (izv_nosaukums), unique (dar_numurs, izv_nosaukums));

Ternārā asociācijas saite 1 : 1..* : 1..*

Katram no inženieriem, strādājot noteiktajā projektā, ir tieši viens vadītājs, bet projektam var būt vairāki vadītāji, bet inženieriem var būt vairāki vadītāji un vairāki projekti. Vadītājs var pārvaldīt vairākus projektus.

Ternārā saite 1:N:N Četras tabulas (viena ar trim ārējam atsaucēm)

No iepriekšēja gadījuma atšķiras unique() sekcija SQL izteiksmē (šajā gadījumā šī ierobežojuma nav)

56

create table Projekts ( proj_nosaukums CHAR(100), constraint PK_PROJEKTS primary key (proj_nosaukums));

create table Vaditajs ( vad_numurs CHAR(6), constraint PK_VADITAJS primary key (vad_numurs));

create table Inzenieris( inz_numurs CHAR(6), constraint PK_INZENIERIS primary key (inz_numurs));

create table Parvalda ( proj_nosaukums CHAR(100), vad_numurs CHAR(6) not null, inz_numurs CHAR(6), constraint PK_PARVALDA primary key (proj_nosaukums, inz_numurs), constraint FK_PAR_PRO foreign key (proj_nosaukums) references Projekts (proj_nosaukums), constraint FK_PIE_VAD foreign key (vad_numurs) references Vaditajs (vad_numurs),

57

constraint FK_PIE_INZ foreign key (inz_numurs) references Inzenieris (inz_numurs));

Ternārā asociācijas saite 1..* : 1..* : 1..*

Darbinieki var izmantot atšķirīgas iemaņas jebkurā no vairākiem projektiem, un katram projektam ir vairāki darbinieki ar daudzām iemaņām.

Ternārā saite N:N:N Četras tabulas (viena ar trim ārējam atsaucēm)

No iepriekšēja gadījuma atšķiras ceturtās tabulas primāra atslēga.

create table Darbinieks ( dar_numurs CHAR(6), constraint PK_DARBINIEKS primary key (dar_numurs));

create table Iemana ( iem_nosaukums CHAR(150), constraint PK_IEMANA primary key (iem_nosaukums));

create table Projekts( proj_nosaukums CHAR(150), constraint PK_PROJEKTS primary key (proj_nosaukums));

58

create table Izmantota_iemana ( dar_numurs CHAR(6), iem_nosaukums CHAR(150), proj_nosaukums CHAR(150), constraint PK_PARVALDA primary key (dar_numurs, iem_nosaukums, proj_nosaukums), constraint FK_PAR_DAR foreign key (dar_numurs) references Darbinieks (dar_numurs), constraint FK_PAR_IEM foreign key (iem_nosaukums) references Iemana (iem_nosaukums), constraint FK_PAR_PRO foreign key (proj_nosaukums) references Projekts (proj_nosaukums));

Vispārinājuma un agregācijas saiteVispārinājuma saite

Cilvēks var būt pircējs, vai darbinieks, vai abi kopā, vai neviens no tiem.

Vispārinājuma saite Trīs saistītas tabulas

create table Cilveks ( cilv_pers_kods CHAR(11), cilv_vards CHAR(30), cilv_adrese CHAR(100), constraint PK_CILVEKS primary key (cilv_pers_kods));

create table Darbinieks ( dar_pers_kods CHAR(11), dar_amats CHAR(15),

59

constraint PK_DARBINIEKS primary key (dar_pers_kods), constraint FK_DAR_CILV foreign key (dar_pers_kods) references Cilveks (cilv_pers_kods));

create table Pircejs ( pir_pers_kods CHAR(11), pir_kredits CHAR(12), constraint PK_PIRCEJS primary key (pir_pers_kods), constraint FK_PIR_CILV foreign key (pir_pers_kods) references Cilveks (cilv_pers_kods));

Tā pati situācija, cita realizācija Viena tabula un divi skati

create table Cilveks ( cilv_pers_kods CHAR(11), cilv_vards CHAR(30), cilv_adrese CHAR(100), dar_amats CHAR(15), pir_kredits CHAR(12),

60

constraint PK_CILVEKS primary key (cilv_pers_kods));

Create view Darbinieks ASSELECT cilv_pers_kods, cilv_vards, cilv_adrese, dar_amatsFROM Cilveks;

Create view Pircejs ASSELECT cilv_pers_kods, cilv_vards, cilv_adrese, pir_kreditsFROM Cilveks;

Agregācijas saite

Programma un lietotāja rokasgrāmata ir daļa no programmatūras produkta.

Agregācijas saite Trīs tabulas

Realizācija kā saitei viens pret vienu

create table Programmaturas_produkts ( numurs INTEGER, nosaukums VARCHAR2(150), cena NUMBER(5,2) constraint PK_PROGPRODUKTS primary key (numurs));create table Programma ( numurs CHAR(6), versija VARCHAR2(150), prod_numurs INTEGER not null unique, constraint PK_PROGRAMMA primary key (numurs), constraint FK_PRO_PROD foreign key

61

(prod_numurs) references Programmaturas_produks (numurs));

create table Lietotaja_rokasgramata ( numurs CHAR(6), versija VARCHAR2(150), lpp_skaits NUMBER, izdevējs VARCHAR2(150), prod_numurs INTEGER not null unique, constraint PK_LIETROKASGRAMATA primary key (numurs), constraint FK_LIET_PROD foreign key (prod_numurs) references Programmaturas_produks (numurs));

Saites ar asociācijas klasiAsociācijas klase (asociācijas saite 0..1 : 0..*)

Darbinieks var strādāt nevienā vai vienā firmā, vienā firmā strādā neviens vai vairāki darbinieki.

Saitei viens pret daudziem ir piesaistīti atribūti (asociācija)

Divas tabulas (asociācijas atribūti tika piesaistīti bērna tabulai)

create table Firma ( numurs CHAR(6), nosaukums CHAR(30), adrese CHAR(100) constraint PK_FIRMA primary key (numurs));

create table Darbinieks ( numurs CHAR(6), fir_numurs CHAR(6), vards CHAR(30), datums DATE, amats CHAR(30), constraint PK_DARBINIEKS primary key (numurs), constraint FK_DAR_FIR foreign key (fir_numurs)

62

references Firma (numurs));

Asociācijas klase (asociācijas saite 0..* : 0..*)

Darbinieks var strādāt vairākās firmās.

Saitei daudzi pret daudziem ir piesaistīti atribūti (asociācija)

Trīs tabulas (asociācijas atribūtiem tika izveidota trešā tabula)

create table Firma ( numurs CHAR(6), nosaukums CHAR(30), adrese CHAR(100) constraint PK_FIRMA primary key (numurs));

create table Darbinieks ( numurs CHAR(6), vards CHAR(30), constraint PK_DARBINIEKS primary key (numurs), ); create table Algo ( numurs INTEGER, fir_numurs CHAR(6), dar_numurs CHAR(6), datums DATE, amats CHAR(30), constraint PK_ALGO primary key (numurs), constraint FK_ALG_FIR foreign key (fir_numurs) references Firma (numurs), constraint FK_ALG_DAR foreign key (dar_numurs)

63

references Darbinieks (numurs));

Citas saites„Vai” saite

Cilvēks var būt vai nu vīrietis, vai nu sieviete, bet ir arī iespējams uzglābāt no dzimuma neatkarīgo informāciju (Cilvēks realitātes atribūti)

Trīs tabulas un pārbaudes ierobežojums

create table Virietis ( vir_numurs CHAR(11), ... constraint PK_VIRIETIS primary key (vir_numurs)); create table Sieviete ( siev_numurs CHAR(11), ... constraint PK_SIEVIETE primary key (siev_numurs));

create table Cilveks ( cilv_numurs CHAR(11), numurs_vir CHAR(11), numurs_siev CHAR(11), ... constraint PK_CILVEKS primary key (cilv_numurs), constraint FK_CILV_VIR foreign key (numurs_vir) references Virietis (vir_numurs), constraint FK_CILV_SIEV foreign key (numurs_siev) references Sieviete (siev_numurs));

64

Pārbaude tabulai Cilveks: CHECK ( numurs_vir IS NOT NULL AND numurs_siev IS NULL) OR ( numurs_vir IS NULL AND numurs_siev IS NOT NULL) OR ( numurs_vir IS NULL AND numurs_siev IS NULL)

Obligāta „vai” saite Atšķirībā no iepriekšēja gadījuma, cits ir tikai pārbaudes ierobežojums:

Pārbaude tabulai Cilveks: CHECK ( numurs_vir IS NOT NULL AND numurs_siev IS NULL) OR ( numurs_vir IS NULL AND numurs_siev IS NOT NULL)

65

4.2. UML un realitāšu-saišu diagrammu atbilstība

Kā ir redzams (4. tabula), UML klašu diagrammas un realitāšu-saišu diagrammas notācijas ir

ļoti līdzīgas un veikt transformācijas starp tām ir iespējams gandrīz jebkurā gadījumā. Pat ja

klasiskajā realitāšu-saišu diagrammā var nebūt konkrēto UML elementu (piemēram,

vispārinājuma saites), šādi elementi tiek izmantoti paplašinātajā realitāšu-saišu diagrammā.

Tāpēc bieži CASE datu bāzu projektēšanas rīkos tiek izmantota papaplašinātais realitāšu-

modelis (piemēram, ER+Merise notācija rīkā Sybase PowerDesigner), jo tajā izstrādātāji

papildus realitāšu-saišu diagrammas elementiem var iekļaut arī UML klašu diagrammas

funkcionalitāti, ka arī citas papildus idejas.

4.3. Objektu datu bāzu transformācijas likumi

Objektu definēšanas valoda ODL (Object Definition Language) ir standarts objektu datu

bāzes struktūras un satura aprakstam [23].

41. att. Klase Pircējs

Klases ODL valodā tiek definētas sekojoši (41. att.):class Pircejs { attribute string kontaNum attribute string vards attribute string piegadesAdrese attribute string majasTelefonaNum attribute string darbaTelefonaNum}

66

42. att. Saite viens pret daudziem

Saites viens pret daudziem realizācija (42. att.):class Pircejs { attribute string kontaNum attribute string vards attribute string piegadesAdrese attribute string majasTelefonaNum attribute string darbaTelefonaNum relationship set<Pasutijums> Veic inverse Pasutijums::Veikts}

class Pasutijums { attribute string pasutijumaNum attribute string pasutijumaDatums attribute string pasutijumaPrioritate attribute string pasutijumaSumma relationship Pasutijums Veikts inverse Pircejs::Veic}

43. att. Saite daudzi pret daudziem

Saites daudzi pret daudziem realizācija (43. att.):class Darbinieks { attribute string vards attribute string alga relationship set<Projekts> Strada inverse Projekts::Piesaistits}

class Projekts { attribute string projektaNum attribute string apraksts attribute string sakumaDatums attribute string beiguDatums relationship set<Darbinieks> Piesaistits inverse Darbinieks::Strada}

67

Pircējs

kontaNumvārdspiegādesAdresemājasTelefonaNumdarbaTelefonaNum

Pasūtījums

pasūtījumaNumpasūtījumaDatumspasūtījumaPrioritātepasūtījumaSumma

1 0..*

44. att. Saite daudzi pret daudziem ar asociācijas klasi

Saite daudzi pret daudziem ar asociācijas klasi tiek realizēta kā divas saites viens pret

daudziem (44. att.):class Katalogs { attribute string sezona attribute integer gads attribute string apraksts attribute string derigumaDatums relationship set<KatalogaProdukts> Satur1 inverse KatalogaProdukts::Ieklauts1}

class Produkts { attribute string produktaNum attribute string razotajs attribute string dzimums attribute string apraksts relationship set<KatalogaProdukts> Ieklauts2 inverse KatalogaProdukts::Satur2}

class KatalogaProdukts { attribute real cena attribute real akcijasCena relationship Katalogs Satur1 inverse Katalogs::Ieklauts1 relationship Produkts Satur2 inverse Produkts::Ieklauts2}

68

45. att. Vispārinājuma saite

Vispārinājuma saites realizācijai tiek pielietots atslēgvārds extends (45. att.):class Pasutijums { attribute string pasutijumaNum attribute string pasutijumaDatums attribute real piegadesCena attribute real cena}

class InternetaPasutijums extends Pasutijums { attribute string epastaAdrese attribute string atbildesVeids}

class TelefonaPasutijums extends Pasutijums { attribute string telefonaOperators attribute string zvanaSakumaLaiks attribute integer zvanaGarums}

class PastaPasutijums extends Pasutijums { attribute string sanemsanasDatums attribute string uznemumaOperators}

Eksistē arī citi objektu datu bāzu transformāciju likumi, bet bieži šos transformēšanas

jautājumus var pieskaitīt objektorientētas programmēšanas tehnoloģijai.

4.4. Relāciju-objektu datu bāzes transformācijas likumi

Relāciju-objektu transformācijas likumi ir grūtāk izpētāmi, jo tie nav realizēti CASE

rīkos, arī nav apskatīti literatūrā. Šajā gadījumā var palīdzēt zināšanas par fiziskajām

struktūrām, gan tam, kas ir aprakstītas SQL standartā, gan tām, ko piedāvā datu bāzu vadības 69

Pasūtījums

pasūtījumaNumpasūtījumaDatumspiegādesCenacena

InternetaPasūtījums

epastaAdreseatbildesVeids

TelefonaPasūtījums

telefonaOperatorszvanaSākumaLaikszvanaGarums

pastaPasūtījums

saņemšanasDatumsuzņēmumaOperators

sistēmu ražotāji. Piemēram, PostgreSQL ir atvasināto tabulu struktūra, kad viena tabula manto

citas tabulas atribūtus. Šis struktūras loģika atbilst vispārinājuma saites loģikai.

Relāciju-objektu transformācijas ir tieši tas gadījums, kad ir iespējami vairāki

transformāciju varianti, jo šajā modelī ir pieejamas divu veidu struktūras, un bieži kādas

diagrammas struktūras realizēšanai var izmantot gan objektu, gan relāciju struktūras. Tāpēc

relāciju-objektu modelī ir spēkā visas relāciju transformācijas, kas tika aprakstītas iepriekšējā

apakšnodaļa, gan modelim specifiskās transformācijas. Piemēram, pieminēto vispārinājuma

saiti relāciju-objektu modelī var realizēt ar atvasinātam tabulām, bet arī ar trīs tabulām un

ārējas atsauces ierobežojumiem.

Relāciju-modelis ļauj realizēt tādas konceptuāla līmeņa struktūras, kuras ar relāciju modeļi

realizēt ir pietiekami grūti. Galvenais relāciju modeļa ierobežojums ir saistīts ar to, ka tabulas

lauka datu vērtībai jābūt atomāram datu objektam, piemēram, tekstam vai skaitlim – relāciju

modelis neparedz situāciju, kad lauka ir ierakstīti teksts kopa ar skaitli, vai vairāki skaitļi un

līdzīgas. Šāda pieeja ierobežo izstrādātāja iespējas konceptuālajā līmeņi. Turpretī relāciju-

objektu modelis ļauj konceptuālajā līmenī veidot saliktus atribūtus, šajā modelī ir pieejama

tāda struktūra kā masīvs, kas ļauj viena laukā glabāt vairākas vērtības.

4.4.1. Saliktais atribūts

Saliktais atribūts relāciju pieejā tiek realizēts ar objektu kolonnu palīdzību. Pirmkārt, ir

jāizveido objektu tips. Objektu tipam līdzīgi, ka tabulai var būt vairākas kolonnas, ka kolonnu

vērtību domēns tiek ņemts kāds no standarta datu tipiem, vai iepriekšizveidotais objektu tips

(šādi var realizēt atribūtus ar sarežģītāko hierarhiju). Izveidotais objektu tips tālāk tiek

pielietots kā datu tips tabulas kolonnai, bet šādu kolonnu sauc par objektu kolonnu.

70

4.4.2. Metode

UML klašu diagrammā ir iespēja definēt klases metodes. Relāciju-objektu modelī šīs metodes

var realizēt. Piemēram, lai to izdarītu Oracle datu bāzes vadības sistēma, ir jāizveido objektu

tips. Tipa definīcijas beigās ir jāieraksta atslēgvārds member procedure un metodes

nosaukumu. Tad, lai šo metodi realizētu ir jāveido objektu tipa ķermenis, kurā var aprakstīt

visas iepriekšdefinētas metodes. Izveidoto objektu tipu ar metodēm var pielietot tālāk veidojot

tabulas vai objektu tabulas.

4.4.3. Binārā saite viens pret daudziem

Saiti viens pret daudziem objektu-relāciju modeļi var realizēt dažādos ceļos, neskaitot relāciju

pieejas ārējas atsauces ierobežojumu. Oracle datu bāzu vadības sistēmā var izveidot tabulu ar

iekļautu tabulu, otrais veids ir atsauču (REF) izmantošana. Abu variantu realizācijai sākumā ir

jāizveido objektu tips, tad šis objektu tips īpašā veidā tiek piesaistīts tabulai iekļautas tabulas

gadījumā, vai to piesaista kolonnai ar REF atslēgvārda palīdzību.

PostgreSQL datu bāzu vadības sistēmā eksistē konstrukcija masīvs ar kuras palīdzību var

realizēt saiti viens pret daudziem gadījumā, ja „daudzi” pusē ir tikai viens atribūts.

4.4.4. Vispārinājuma saite

Īpaši ērti relāciju-objektu modeļi var realizēt vispārinājuma saiti, jo mantošana ir viena no

objektorientētas programmēšanas pamatkoncepcijām. Relāciju modeli vispārinājuma saites

realizēšanai bija nepieciešami vairāki ārējo atsauču ierobežojumi, vai skati. Relāciju-objektu

modelī PostgreSQL gadījumā bērnu tabulām tiek pievienots atslēgvārds inherits (manto), kas

nodrošina to, ka bērnu tabulas satur vecāka tabulas atribūtus, un mainot informāciju bērnu

tabulā tā tiek mainīta arī vecāku tabulas atbilstošos atribūtos.

Plašāk ar transformācijas likumiem var iepazīties ar piemēru palīdzību (5. tabula) [13, 17, 29].

71

72

5. tabula

Relāciju-objektu datu bāzes transformācijas likumi

KONCEPTUĀLAIS LĪMENIS LOĢISKAIS UN FIZISKAIS LĪMENIS

Objektorientēta pieeja (UML klašu diagramma)

Relāciju pieeja (realitāšu-saišu diagramma)

Relāciju-objektu pieeja, SQL valoda

Saliktais atribūts Tabula ar objektu kolonnu (Oracle sintakse)

Atribūta tipam nav izmantots kāds no standarta datu tipiem (CHAR, NUMBER, DATE u.t.t.), bet gan izveidots jaunais objektu tips T_Kontakti

create type T_Kontakti as object ( telefons NUMBER, fakss NUMBER, adrese VARCHAR(70));

create table Darbinieks ( numurs CHAR(6), vards CHAR(40), amats CHAR(100), kontaktinfo T_KONTAKTI, constraint PK_DARBINIEKS primary key (numurs));

73

Metode Realitāšu-saišu notācijā metodes attēlot nav iespējams

Objektu tabula ar metodi (Oracle sintakse)

create type O_Darbinieks as object ( numurs CHAR(6), vards CHAR(30), uzvards CHAR(30), telefons NUMBER, MEMBER PROCEDURE DarbinieksIzvade);

create type body O_Darbinieks AS MEMBER PROCEDURE DarbinieksIzvade IS BEGIN DBMS_OUTPUT.PUT(‘Darbinieka numurs’||numurs); DBMS_OUTPUT.PUT(‘ Darbinieka vārds’||vards); DBMS_OUTPUT.PUT(‘ uzvārds:’||uzvards); DBMS_OUTPUT.PUT(‘ Darbinieka tel.’||telefons); DBMS_OUTPUT.NEW_LINE; END DarbinieksIzvade;END;

create table Darbinieks OF O_Darbinieks;

Asociācijas saite (0..1 : 0..*) Saite viens pret daudziem (abas realitātes neobligātas)

Tabula ar iekļauto tabulu (Oracle sinakse)

Iekļautai tabulai ir jāizveido objektu tips (piemērā T_Darbinieks)

74

Darbinieks var strādāt maksimāli vienā firmā (vai būt nepiesaistīts nevienai no firmām). Firma var būt neviens darbinieks vai daudzi darbinieki.

create type T_Darbinieks as object ( vards CHAR(30), telefons NUMBER);

create type Tabula_Darbinieks as table of T_Darbinieks;

create table Firma ( numurs CHAR(6), nosaukums CHAR(100), darbinieks TABULA_DARBINIEKS, constraint PK_Firma primary key (numurs))nested table darbinieks store as darb_tabula;

Tā pati situācija, cita realizācija Atsauce (Oraclesintakse)

Jāizveido ārējas atslēgas lauks (numurs firmai, kurā strādā darbinieks)

create type TipsDarbinieks as object( ...);

create type TipsFirma as object (

75

... darbinieks REF TipsDarbinieks ...);

Asociācijas saite (0..1 : 0..*)

Papildus nosacījums: „daudzi” klasei ir tikai viens atribūts

Saite viens pret daudziem (abas realitātes neobligātas)

Papildus nosacījums: realitātei „daudzi” ir tikai viens atribūts

Viena tabula ar lauku-masīvu (PostgreSQL sintakse)

Šis variants ir alternatīvs standarta transformācijai, kad saite viens pret daudziem tiek pārveidota divās tabulās (viena ar ārējo atsauci) un var būt pielietots ne jebkurā situācijā.Pārveidojums ir iespējams tikai ja „daudzi’ realitātei ir viens atribūts.

create table Darbinieks ( numurs ... atskaites_nosaukums text[], constraint PK_FIRMA primary key (numurs));

Vispārinājuma saite Vispārinājuma saite Trīs tabulas, divas no tām atvasinātas (PostgreSQL sintakse)

76

Cilvēks var būt pircējs, vai darbinieks, vai abi kopā, vai neviens no tiem.

create table Cilveks ( cilv_pers_kods char(11), cilv_vards char(30), cilv_adrese char(100), constraint PK_Cilveks primary key (cilv_pers_kods));

create table Darbinieks ( dar_amats char(15))INHERITS (cilveks);

create table Pircejs ( pir_kredits CHAR(12))INHERITS (cilveks);

77

SECINĀJUMI

Tiek projektētas datu bāzes dažādām problēmvidēm, eksistē temporālās, telpiskās datu bāzes,

datu noliktavas un citi datu bāzu veidi. Visiem datu bāzu tipiem ir nepieciešama projektēšanas

tehnika, kas diemžēl neeksistē vai ir vāji attīstīta. Šādas projektēšanas tehnikas izstrādi jāsāk ar

universālām pieejam – tādām datu bāzu tehnoloģijām, kas ir mazāk piesaistītas konkrētiem

uzdevumiem.

Projektējot datu bāzi, ir lietderīgi izmantot diagrammas datu konceptuālajam, loģiskajām un

fiziskajām modelim. Izplatītākie konceptuālo modeļu veidi ir:

1) realitāšu-saišu diagramma,

2) UML klašu diagramma,

3) realitāšu-saišu diagramma ar dažiem paplašinājumiem, ieskaitot UML elementus.

Jāpiebilst, ka, izstrādājot konceptuālo modeļi, nav svarīgi kurā DBVS datu bāze tiks realizēta.

Tātad, izvēloties kādu no projektēšanas pieejām ir jādomā, vai šīs projektēšanas veids ir labi

saprotams klientiem un pašiem izstrādātājiem, vai ar tā palīdzību var aprakstīt pietiekami

sarežģītas problēmvides struktūras. Attīstības gaitā UML klašu diagramma un realitāšu saišu

diagrammas ir tik uzlabojušās, ka tagad tas spēj sniegt līdzīgu funkcionalitāti un daži

automatizētas projektēšanas rīki ļauj brīvi pārveidot UML klašu diagrammu realitāšu-saišu

diagrammā un otrādi. Ārpus minētājiem, eksistē vairākas citas modelēšanas pieejas, bet tās ir vai

nu pārāk sarežģītas (piemēram, objektu-lomu modelēšana), vai arī domāti specifiskiem mērķiem,

piemēram, MADS konceptuālas modelēšanas pieeja, kas ir domāta temporālo un telpisko datu

bāzu projektēšanai, tāpēc dotajā brīdī šis pieejas nav kļuvušās populāras izstrādātāju vidū.

Eksistē vairāki datu bāzu loģiskie modeļi, uz kuriem balstās datu bāzu vadības sistēmas.

Neapšaubāmais līderis ir relāciju modelis. Vairāki zinātnieki un izstrādātāji apgalvo, ka liels

potenciāls ir objektorientētām datu bāzēm, kuru galvenā atšķirība ir tā, ka objekti netiek atdalīti

no uzvedības. Eksistē minēto tehnoloģiju hibrīds – relāciju-objektu datu bāze. Katrai no

tehnoloģijām ir sava pieeja datu glabāšanai, savas fiziskās struktūras. Relāciju modelī dati tiek

glabāti tabulās, objektorientēta modelī – objektos, bet tas nav visas fiziskās struktūras, eksistē

indeksi, kas palielina ātrdarbību, ierobežojumi, kas rūpējas par datu integritāti, metodes, kas

nodrošina objektu uzvedību u.c. Nevar viennozīmīgi pateikt, kura no tehnoloģijām ir labāka.

Eksistē uzdevumi, problēmvides, kuros labāk ir izmantot kādu noteiktu tehnoloģiju, bieži vien

tehnoloģijas izvēle ir atkarīga no izstrādātāju pieredzes, dokumentācijas esamības un citiem

iemesliem. Ar relāciju, objektu un relāciju-objektu modeļi datu bāzu vadības sistēmas nav

ierobežotas. Līdzīgi kā ar projektēšanas metodēm eksistē ne tik izplātītie modeļi, arī modeļi,

kurus izmanto specifiskos uzdevumus.

Praksē konceptuāla un loģiskā līmeņa pārveidojumus fiziskajās struktūrās CASE rīki neveic

tik labi:

1) CASE rīku diagrammas ir ierobežotas, piemēram, nevar izveidot ternāro saiti, vai nav

realizēta mantošana. Šādā gadījumā izstrādātājam ir jāizdomā, kā apiet šos

ierobežojumus, kā rezultātā diagramma nav tik kvalitatīva – tā ir sliktāk pārskatāma, tajā

ir lieki elementi u.t.t.;

2) veiktas transformācijas ir nekvalitatīvas, jo netiek izmantotas visas iespējas, ko sniedz

modelis. CASE rīks veido vienkāršākas struktūras, tiek aizmirsts par iespējām, ko var

dot, piemēram, skati, indeksi un citas fiziskās struktūras;

3) ar izplatītāko CASE rīki palīdzību nevar izveidot relāciju-objektu datu bāzi;

4) CASE rīki reti piedāvā transformācijas variantus. Bieži vienu to pašu uzdevumu var

atrisināt dažādos ceļos, bet rīks izvēlās kādu vienu, iespējams šajā gadījumā ne pašu

labāko.

Sakarā ar minētājiem CASE rīku nepilnībām, bet lielu nepieciešamību pēc atbalsta, ko tie

varētu sniegt datu bāzu izstrādātājiem, tika izpētīts, kā CASE rīkus var uzlabot, bet konkrēti, tika

apskatīti diagrammu elementi, kas sniedz vairākas papildus iespējas datu bāzu projektētājiem,

fiziskās struktūras, kuras pareizi pielietojot, var izveidot kvalitatīvāko datu bāzi (ātrāko,

vienkāršāko, labāk atbilstošu uzdevumam u.t.t), bet galvenais, tika piedāvāti transformācijas

likumi, gan tie likumi, kuri ir iekļauti labākajos rīkos, gan arī tie, kuru tur nav, kā arī tika

piedāvāti projektēšanas uzdevumu risināšanas varianti – kā diagrammas elementu kopu var

pārvērst fiziskajās struktūrās dažādos veidos.

CASE tehnoloģiju var uzlabot, pirmkārt, papildinot konceptuālo modeli, ieviešot tajā

papildus konstrukcijas – „vai” saiti, vispārinājuma un agregācijas saiti, ternāro un augstākas

kārtas saiti, arī konstrukcijas, kuras var realizēt ar relāciju-objektu tehnoloģijas palīdzību

(objektus, saliktus atribūtus). Otrkārt, jāizmanto visas datu bāzu sniegtas iespējas jeb fiziskās

struktūras. CASE rīkiem transformācijas rezultātā jāveido skati, kurus var izmantot

vispārinājuma saites, „vai” saites realizācijai. Transformāciju rezultātā jāveido relāciju-objektu

fiziskas struktūras – masīvus; mantošanu, ar kuras palīdzību var realizēt vispārinājuma saiti;

iekļautas tabulas; atsauces, ar kurām var realizēt saiti viens pret daudziem; masīvus, kas ļauj

realizēt neatomārus atribūtus. Pieredzējušām lietotājam jāpiedāvā iespējas izvēlēties no

iespējamiem transformāciju variantiem. Darbā ir apskatīti četri varianti, kā var realizēt saiti viens

pret daudziem (ar ārējas atsauces, masīva, iekļautas tabulas, atsauču palīdzību), tāpēc lietotājam

būtu jāpiedāvā visi iespējamie varianti, nevis katru reizi realizēt šo saiti ar ārējam atsaucēm, kā

79

tas tiek praktizēts CASE rīkos. Līdzīgi jābūt iespējai izvēlēties, vai konkrēta struktūra tiek

pārveidota tabulās vai tabulās un skatos, šādas iespējas pastāv realizējot vispārinājuma saiti, bet

ja pielieto relāciju-objektu struktūrās, tad variantu skaits ir vēl lielāks.

Pamatojoties uz veikto analīzi tiks veidots jauns CASE rīks, kas novērsīs augstākminētas

nepilnības. Par šī CASE rīka loģisko pamatojumu kalpos šis maģistra darbs, kā arī katedras

ietvaros veiktie pētījumi par šāda CASE rīka fiziskās realizācijas variantiem.

80

LITERATŪRAS SARAKSTS

1) Allen S., Terry E. Beginning Relational Data Modeling, 2nd edition. – Apress, 2005. – 632 p.

Grāmata ir interesanta ne tikai ar to, ka tajā ir izklāstīti datu modelēšanas principi, bet arī

ar to, ka tajā ir informācija par datiem kā tādiem, datu apstrādes vēsturi, ir sniegts šāda

modelējuma pamatojums – kāpēc tas ir vajadzīgs biznesam.

2) Bagui S., Earp R. Database Design Using Entity-Relationship Diagrams. – Auerbach

Publications, 2003. – 242 p.

Grāmata apskata relāciju datu bāzu lomu programmatūras izstrāde, realitāšu-saišu

diagrammas teoriju, ir aprakstītās paplašinātas realitāšu-saišu diagrammas koncepcijas,

Barkera realitāšu-saišu diagrammas notācija, ka arī citi jautājumi, kas ir veltīti datu bāzu

izstrādei, lietojot realitāšu-saišu diagrammu.

3) Codd E. A Relational Model of Data for Large Shared Data Banks// Communications of the

ACM. – June 1970. – Vol. 13, No. 6. – pp. 377-287.

Viens no pirmajiem (ja ne pirmais) Koda rakstiem par relāciju modeli.

4) Codd E. Data Models in Database Management// Proc. Workshop in Data Abstraction,

Databases and Conceptual Modelling, Pingee Park, Colo. – June 1980. – No.74.

Relāciju modeļa autora rakstā ir teorētiskā informācija par datu modeļi, uzdevumiemi,

ko tam ir jāveic.

5) Connolly T., Begg C. Database Systems: A Practical Approach to Design, Implementation,

and Management, 3rd editon. – Adisson Wesley, 2001. – 1236 p.

Grāmata, kas apskata visas datu bāzu tehnoloģijas pamattēmas, ieskaitot datu bāzu

tehnoloģijas ietekmi uz ekonomiku; relācijas modeli, analīzes un projektēšanas metodes,

arī jaunos virzienus datu bāzu pētījumos.

6) Date C. An Introduction To Database Systems, 7th edition. – Addison Wesley Longman,

1999. – 938 p.

Grāmatā tiek apskatīti gan datu bāzu pamati, gan arī autora redzējums par datu bāzu

iespējamo attīstību. Īpaša uzmanība tiek veltīta relāciju modelim.

7) Date C. The relational model will stand the test of time // Intelligent Enterprise. – 1999. –

June 1, Volume 2, Number 8.

Raksts, kas ir veltīts relāciju modeļa autora Koda (Codd) darbiem. Rakstā pamatdaļas

ietver relāciju modeļa mērķu un attīstības ceļa analīzi.

8) Datortermini. Lielā terminu vārdnīca. / Internets. – http://www.termini.lv/

81

9) Halpin T. Information Modeling and Relational Databases: from conceptual analysis to

logical design. – Morgan Kaufmann, 2001. – 792 p.

Grāmatā pārsvarā iet runa par objektu-lomu modelēšanu. Autors apgalvo, ka salīdzinot

ar realitāšu-saišu diagrammām un UML modelēšanu, objektu-lomu modelēšanai pieejai

ir vairākas priekšrocības. Lai lasītājs par to pārliecinātos, grāmatā daudz uzmanības ir

veltīts arī ER un UML projektēšanai. Grāmata arī ir vērtīga apskatot relāciju datu bāzu

modelēšanas tehnoloģiju vispār.

10) Harrington J. Object-Oriented Database Design Clearly Explained. – Morgan Kaufmann,

1999. – 328 p.

Grāmatā par objektu datu bāzu projektēšanu ir apskatīti tādi jautājumi kā datu bāzu

vēsture, objektorientēta paradigma, objektorientēto datu bāzu standartizācija,

objektorientētas pieejas priekšrocības. Grāmatas otrajā daļā ir apskatīti konkrēti

projektēšanas piemēri.

11) Hernandez M. Database Design for Mere Mortals. A Hands On Guide For Relational DBMS

Design, 2nd edition. – Addison-Wesley Professional, 2003. – 672 p.

Grāmata ir plaši apskatītas relāciju struktūras, sniegtas autora izstrādātas vadlīnijas

relāciju datu bāzu projektēšanai.

12) Ievīte I, Kirikova M. Diagrammas sistēmu analīzē un projektēšanā. Lekciju palīgmateriāls

RTU ASTF jaunāko kursu studentiem. – Rīga: RTU, 1997. – 33 lpp.

Lekciju palīgmateriālā apskatītas realitāšu-saišu, datu-plūsmu, stāvokļu pārejas ka arī

citu diagrammu konstruēšanas pamati.

13) Kline K., Kline D., Hunt B. SQL In A Nutshell, 2nd edition. – O'Reilly Media, Inc., 2004. –

700 p.

Grāmata ir veidota rokasgrāmatas formātā un tajā ir apskatīts standarts SQL2003, ka arī

šī standarta realizācijas īpatnības Microsoft, Oracle, IBM, PostgreSQL, MySQL datu

bāzu vadības sistēmās.

14) Kriegel A, Trukhnov B. SQL Bible. – John Wiley & Sons, 2003. – 831 p.

Apskatīti dažādi jautājumi, kas ir saistīti ar SQL valodu: objektorientētas iespējas, SQL

standarts SQL:1999, šī standarta realizācijas, SQL saistība ar XML, OLAP.

15) Matthew N., Stones R. Beginning Databases with PostgreSQL: From Novice to Professional,

2nd edition. – Apress, 2005. – 664 p.

Grāmata ir veltīta PostgreSQL datu bāzes vadības sistēmai, bet tajā ir arī aprakstīta datu

bāzes tehnoloģijas attīstības vēsture.

16) Naiburg E., Maksimchuk R. UML for Database Design. – Addison-Wesley Professional,

2001. – 320 p.

82

Liela grāmatas daļa ir veltīta UML klašu diagrammai, ir apskatītas arī citas datu bāzu

projektēšanas iespējas, izmantojot UML.

17) Oracle Database. Application Developer’s Guide. Object-Relational Features. 10g Release 1

(10.1). – Oracle Corporation, 2003. – 252 p.

Dokuments apraksta Oracle datu bāzes relāciju-objektu iespējas. Dokumentā ir apskatīti

arī projektēšanas jautājumi.

18) Parent C., Spaccapietra S., Zimanyi E. Conceptual Modeling for Traditional and Spatio-

Temporal Applications. The MADS Approach. – Berlin: Springer, 2006. – 470 p.

MADS pieeja tiek izmantota galvenokārt telpiski-temporālo lietojumu datu bāzu

konceptuālai projektēšanai. Grāmatā plaši apskatīta telpisko un temporālo datu bāzu

teorija un datu bāzu projektēšanas teorija.

19) Paterson J., Edlich S., Horning H. The Definitive Guide to db4o. – Apress, 2006. – 510 p.

Grāmata ir par objektu datu bāzi db4o (database for object, jeb datu bāze objektiem) un

ir domāta programmētājiem. Darbā ir arī teorētiska informācija par objektu pieeju un par

objektu datu bāzu sniegtajām priekšrocībām.

20) Powell G. Beginning Database Design. – Wiley Publishing, 2006. – 496 p.

Grāmata ir domāta datu bāzes tehnoloģijas pašu pamatu apguvei. Šajā darbā labi ir

aprakstīta datu bāzu evolūcija no failu sistēmām līdz relāciju-objektu modelim.

21) Powell G. Beginning XML Databases. – Indianapolis:Wiley Publishing, 2007. – 470 p.

Autors apskata gan XML tehnoloģiju, šis tehnoloģijas uzdevumus, tas saistību ar datu

bāzēm. Grāmatā ir piemēri, kā XML tehnoloģija tiek izmantota relāciju datu bāzēs, dau

bāzu vadības sistēmās Oracle un SQL Server.

22) Rumbaugh J., Jacobson I., Booch G. The Unified Modeling Language Reference Manual. –

Adisson Wesley Longman Inc., 1999. – 568 p.

UML veidotāju grāmatas, iepazīstina ar UML valodas koncepcijām.

23) Satzinger J., Jackson R., Burd S. System Analysis and Design in a Changing World, 4th

edition. – Thomson Course Technology, 2006. – 712 p.

Grāmatā ir apskatīti vairāki programmatūras izstrādes jautājumi, bet tā arī iekļauj

nodaļas par datu bāzu projektēšanu, iekļaujot informāciju par objektorientētām un

relāciju-objektu datu bāzēm.

24) Silberschatz A., Korth H., Sudarshan S. Database System Concepts, 5th edition. – McGraw-

Hill, 2006. – 1142 p.

Grāmatā ir apskatīti visi galvenie jautājumi, kas ir saistīti ar datu bāzu tehnoloģiju. Ir

apskatītas arī tādas tēmas kā objektu datu bāzes un XML, paplašināta realitāšu-saišu

diagramma, relāciju valodas (ne tikai SQL).

83

25) Simsion G., Witt G. Data Modeling Essentials, 3rd edition. – Morgan Kaufmann, 2005. –

560 p.

Apskata datu bāzu projektēšanas jautājumus: supertipu un apakštipu projektēšanu,

realitāšu-saišu diagrammas paplašinājumus, datu noliktavu projektēšanu kā arī daudzus

citus.

26) Teorey T., Lightstone S., Nadeau T. Database Modelig & Design: Logical Design, 4th

edition. – Morgan Kaufmann, 2006. – 296 p.

Grāmata ir interesanta ar to, ka tajā nav plaši aprakstīta datu bāzu teorija (informācija, ko

var atrast desmitos citu grāmatu), bet gan kodolīgi ir apskatīta datu bāzu modelēšana, arī

transformācijas likumi no realitāšu-saišu un UML konstrukcijām uz SQL. Grāmatā ir arī

nodaļa par moderniem CASE rīkiem.

27) Wikipedia: Entity-Attribute-Value model / Internet. – http://en.wikipedia.org/wiki/Entity-

Attribute-Value_model

Brīvās enciklopēdijas raksts par modeli Realitāte-Atribūts-Vērtība.

28) Williams S. The Associative Model of Data, 2nd edition. – Lazy Software, 2002. – 272 p.

Autors piedāvā jauno datu modeli – asociatīvu datu modeļi, aprakstot tā būtību un

sniegtas priekšrocības. Grāmatā ir plaši aprakstīta datu bāzu attīstības vēsture,

argumentēti objektu un relāciju modeļu trūkumi.

29) Worsley J., Drake J. Practical PostgreSQL. – O’Reilly Media, Inc., 2002. – 636 p.

Grāmatā ir aprakstīti praktiskie jautājumi darbam ar relāciju-objektu datu bāzu vadības

sistēmu PostgreSQL. Grāmatā ir interesanta ar to, ka tajā ir informācija par struktūrām,

kas ir specifiskās PostgreSQL kā relāciju-objektu sistēmai. Jāpiezīmē, ka tieši

PostgreSQL (tolaik Postgres) sistēmas izstrādi pārvaldīja relāciju-objektu modeļa autors

Maikls Stounbreikeris (Michael Stonebraker).

30) Кириллов В. Основы проектирования реляционных баз данных / Интернет. –

http://www.citforum.ru/database/dbguide/index.shtml

Internetā publicētais mācību līdzeklis apskata dažādas relāciju datu bāzes problēmas:

sākot ar datu bāzu definīciju, realitāšu saišu diagrammu, datu bāzu projektēšanu un

beidzot ar bibliotēkas datu bāzes projektēšanas piemēru.

31) Крёнке Д. Теория и практика построения баз данных, 8-е издание. - Санкт-Петербург:

Питер, 2003. – 800 стр.

Darbs, kas aptver visas datu bāzu tehnoloģijas pamattēmas, ieskaitot relāciju un objektu

datu bāzes, datu bāzu projektēšanu un citas.

84

32) Кузнецов С. Объектно-ориентированные базы данных - основные концепции,

организация и управление: краткий обзор / Интернет. –

http://www.citforum.ru/database/articles/art_24.shtml

Rakstā minētas objektorientēto datu bāzu pamatkoncepcijas.

33) Леоненков А. Объектно-ориентированный анализ и проектирование с использованием

UML и IBM Rational Rose. – Москва: Бином. Лаборатория знаний, 2006. – 320 стр.

Grāmāta par UML valodu un tas pielietošanu.

85