1

2

Relāciju – objektu DB projektēšanaTiek 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 (1. att.).

3

1 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(2 att):

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 vai arī kāds

cits modelis;

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;

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.

4

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

5

Pamata transformācijas

1. Klases transformācijaKlase no konceptuālā līmeņa tiek transformēta uz saliktu objektu. Tālāk šo objektu var izmantot lai

definētu objektu tabulu vai izmantot kā kolonnu tabulā. Piemērā (attēls 3) tiek transformēta klase

darbinieks ar relāciju objektu pieeju uz salikto tipu ar nosaukumu Darbinieks.

3. att Klases transformācija

Klases atribūta transformācija

Klases atribūts transformējot tiek transformēts kā saliktā tipa atribūts. Definējot salikto tipu, pie tipa

definīcijas tiek noteikti atribūti, un to tipi. Piemērā(attēls 4) klasei Darbinieks tiek definēts atribūts

Uzvards ar tipu CHAR(40).

4 att Klases atribūta transformācija

6

Atslēgas atribūta transformācija

Definējot objekta tipu, tā atribūtiem nevar noteikt ierobežojumus. Lai kādam no saliktā tipa atribūtiem

noteiktu ierobežojumus, šie ierobežojumi ir jānodefinē veidojot tabulu. Piemērā (attēls 5), klases

Darbinieks atslēgas atribūts ir numurs. Atribūts tiek definēts veidojot salikto tipu darbinieks, bet

ierobežojums, kas nosaka, ka šis atribūts būs atslēgas atribūts tiek noteikts veidojot tabulu darbinieki.

5 att Atslēgas atribūta transformācija

Atribūta obligātuma transformācija

Līdzīgi kā transformējot atslēgas atribūtu, arī atribūta obligātumu nevar noteikt definējot salikto tipu,

tas jānodefinē veidojot tabulu. Piemērā(attēls 6), klasei Darbinieks ir obligāts atribūts vards. Atribūts

un tā tips tiek nodefinēts veidojot objektu, bet ierobežojums, kurš nosaka, ka šis atribūts būs obligāts

tiek noteikts veidojot tabulu.

7

6 att. Atribūta obligātuma transformācija

Klases metodes transformācija

Lai transformētu klases metodi, veidojot salikto tipu tiek ierakstīts tikai šīs metodes nosaukums. Pati

metode tiek veidota, veidojot tipa ķermeni. Piemērā (attēls 7), klasei Darbinieks ir metode getUzvards.

Veidojot salikto tipu tiek nosaukta metode ar komandu MEMBER PROCEDURE getUzvards. Tālāk

veidojot tipa ķermeni tiek veidota pati metode.

7. att. Klases metodes transformācija

8

Saites viens pret daudziem transformācija.

Saiti viens pret daudziem var transformēt uz tabulu ar iekļautu kolekciju, kur realitāte daudzi tiek

realizēta kā iekļautā kolekcija. Relāciju objektu variantā lietojot Oracle sintaksi tiek veidota tabula ar

iekļautu kolekciju. Piemērā (attēls 8), darbinieks var strādāt maksimāli vienā firmā. Firmā var būt

neviens darbinieks, viens darbinieks vai daudzi darbinieki. Vispirms izveido objekta tipu T_Darbinieks,

pēc tam izveido kolekcijas tipu Tabula_Darbinieks. Veidojot tabulu Firma tipu Tabula_darbinieks, kas

ir kolekcija izvēlas kā kolonnas tipu.

8. att. Saites viens pret daudziem transformācija

Piemērā (attēls 9), katra prece ir piesaistīta tieši vienai partijai, partijā var būt viena vai vairākas preces.

Šī situācija no iepriekšējās atšķiras ar to, ka šajā situācijā kolekcija nedrīkst būt tukša. Lai to realizētu

tabulas definīcijā iekļauj ierobežojumu NOT NULL. Realitāte prece tiek transformēta kā iekļauta

kolekcija. Definējot tabulu partija tiek iekļauts ierobežojums, ka šī iekļautā kolekcija nedrīkst būt tukša.

9

9. att. Saites viens pret daudziem transformācija

Piemērā (attēls 10), katrs departaments publicē vienu vai vairākas atskaites. Nav obligāti, ka kāda

konkrēta atskaite ir departamenta publicēta. Šī situācija no iepriekšējām atšķiras ar to, ka šeit atskaite

var tikt glabāta arī atsevišķi bez piesaistes departamentam, un tādēļ nevar veidot tabulu ar iekļauto

kolekciju līdzīgi kā iepriekšējos piemēros. Lai realizētu to, ka atskaite tiek glabāta atsevišķi. atskaitei

veido salikto tipu, un objektu tabulu pamatojoties uz šo tipu. Otru tabulu departamenti veido kā objektu

tabulu ar iekļauto kolekciju, kur kolekcija satur norādes uz atskaitēm. Šādā realizācijā tiek nodrošināts,

ka atskaite var būt piesaistīta kādam departamentam, tādā gadījumā uz atskaiti būs norāde no

departamentu tabulas, un atskaite var nebūt piesaistīta departamentam tādā gadījumā norādes nebūs.

10

10. att. Saites viens pret daudziem transformācija

Saites viens pret vienu transformācija

Saite viens pret vienu tiek transformēta uz divām objektu tabulām. Piemērā (attēls 11) katrai atskaitei ir

viena abreviatūra un katra abreviatūra reprezentē tieši vienu atskaiti. Tiek veidoti divi objektu tipi ar

norādēm vienam uz otru, jo katrai atskaitei ir jābūt abreviatūrai un katrai abreviatūrai jābūt atskaitei, un

šādām norādēm ir obligāti jābūt. Tā, kā definējot objekta tipus nevar nodefinēt tipa atribūtu

ierobežojumus, tad ierobežojumus definē, definējot tabulu, ierobežojums NOT NULL nozīmē, ka

atsauce uz otru tipu nedrīkst būt tukša.

11

11. att. Saites viens pret vienu transformācija

Piemērā (attēls 12) jābūt vadītājam priekš katra departamenta, bet darbinieks var vadīt vienu

departamentu, vai nevienu departamentu. Šis piemērs no iepriekšējā piemēra atšķiras ar to, ka šajā

piemērā viena no saitēm ir neobligāta.

12. attēls Saites viens pret vienu transformācija

Piemērā (attēls 13), daži no datoriem ir piesaistīti inženieriem, bet ne obligāti visiem inženieriem ir

dators, tas nozīmē, ka šoreiz abas saites ir neobligātas un obligātuma nosacījums nav nepieciešams.

12

13. att. Saites viens pret vienu transformācija

Saites daudzi pret daudziem transformācija

Saiti daudzi pret daudziem var realizēt kā divas objektu tabulas ar iekļautu kolekciju, vai divas tabulas

ar iekļautu kolekciju. Piemērā (attēls 14), katrs darbinieks var strādāt nevienā, vienā vai vairākās

firmās, bet katrā firmā ir neviens, viens, vai vairāki darbinieki. Tiek veidoti divi objekti ar iekļautu

kolekciju. Kolekcijas satur norādes uz otru objektu.

14. attēls. Saites daudzi pret daudziem transformācija

13

Ternārās un n-ārās saites transformācija

Ternāro saiti transformē kā trīs objektu tabulas ar norādēm savā starpā. Piemērā (attēls 15), 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. Tiek veidoti trīs objekta

tipi, kuros katrā ir norādes uz pārējiem diviem objekta tipiem.

15. attēls Ternārās saites transformācija

Piemērā (attēls 16), 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. Tipā darbinieks ir norāde uz tipu izvietojums, un uz tipu projekts. Tipā

Izvietojums ir kolekcija ats_uz_darb kas satur norādes uz tipu darbinieks, un norāde uz tipu projekts.

Tipā projekts ir kolekcija ar norādēm uz tipu darbinieks, un norāde uz tipu izvietojums.

14

16. attēls Ternārās saites transformācija

Piemērā (attēls 17), 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.

17. att. Ternārās saites transformācija

15

Piemērā (attēls 18), viens darbinieks piedalās vairākos projektos, un viņam ir vairākas iemaņas, vienā

projektā ir vairāki darbinieki un tiek izmantotas vairākas iemaņas.

18 att. Ternārās saites transformācija

Vispārinājuma saites transformācija

Piemērā (attēls 19), Cilvēks var būt pircējs, vai darbinieks, vai abi kopā, vai neviens no tiem.

19. att. Vispārinājuma saites transformācija

16

PostrgreSQL realicācijā tiek izveidota pamata tabula Cilveks un divas tabulas, kas manto atribūtus no

pamata tabulas un pievieno savu individuālo atribūtu.

Saites ar asociācijas klasi transformācija

Piemērā (attēls 20), Darbinieks var strādāt nevienā vai vienā firmā, vienā firmā strādā neviens vai

vairāki darbinieki. Asociācijas klase šajā transformācijā tiek glabāta kopā ar atsaucēm. Tips algoti satur

tipu algo kas satur asociācijas klases atribūtus, un atsauci uz tipu darbinieks.

20. att. Saites viens pret daudziem ar asociācijas klasi transformācija

Piemērā (attēls 21), Darbinieks var strādāt vairākās firmās.

17

21. att. Saites daudzi pret daudziem ar asociācijas klasi transformācija

Unārās saites transformācijas

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

objekta definīcijā tiek ietverts atribūts ar norādi uz šo pašu tipu. Tipam darbinieks tiek izveidots

atribūts ir_precejies, un tas satur norādi uz citu darbinieku.

22. att. Unārās saites transformācija

18

Piemērā (attēls 23), viens inženieris var vadīt citus inženierus. Šajā transformācijā tiek izveidota

kolekcija ar norādēm uz tipu inzenieris, jo inženieris var vadīt vairākus citus inženierus.

23. att Unārās saites transformācija

Piemērā (attēls 24), katram darbiniekam ir iespēja būt par atskaites līdzautoru kopā ar citiem

darbiniekiem, vai arī uzrakstīt atskaiti vienam. Šeit tipam darbinieks tiek veidota kolekcija ar norādēm

uz šo pašu tipu darbinieks.

24. att Unārās saites transformācija