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