datu bāzes tehnoloģijas · web viewmaģistra darbā apskatīta datu bāzes projektēšana....
TRANSCRIPT
`
Uldis Vaicis
Objektu datu bāzes projektēšanas automatizācijas realizēšanas
tehnoloģiju
analīze un izvērtējums
Maģistra DARBS
Zinātniskais vadītājs:
Profesors, Dr.sc.ing. Jānis Eiduks
Rīga 2016
`
ANOTĀCIJA
RELĀCIJU – OBJEKTU DATU BĀZE, CASE RĪKI, UML, KLAŠU DIAGRAMMA,
DATU MODEĻU TRANSFORMĀCIJA, DATU MODELIS, DATU BĀZES
PROJEKTĒŠANA
Maģistra darbā apskatīta datu bāzes projektēšana. Galvenā vērība veltīta relāciju –
objektu datu bāzes projektēšanas iespēju izpētei. Noskaidrots, ka atšķirībā no relāciju un
objektorientēto datu bāžu projektēšanas, relāciju – objektu datu bāzei no datu semantiskā
modeļa tiek iegūti struktūru varianti. Tātad transformācija nav viennozīmīga un jālieto
iteratīvas daudzkriteriālās optimizācijas procedūras. To realizēšanai ir apskatīti saliktu
struktūru vērtēšanas kritēriji jeb metrikas. Ir veikta izpēte, kā tiek iegūtas relāciju – objektu
datu bāzes struktūras eksistējošajās realizācijās, kādi modeļi un tehnoloģijas tiek lietoti, un
kādi ir to izmantošanas ierobežojumi. Veiktā analīze, ļāva darbāizveidot relāciju – objektu
datu bāzes projektēšanas automatizācijas sistēmas prototipu, kurš ļauj projektētājam precizēt
savas vēlmes, izvēloties vienu no potenciālajiem relāciju – objektu datu bāzes struktūras
variantiem. Šāda iespēja relāciju – objektu datu bāzei tiek realizēta pirmo reizi.
Maģistra darba apjoms ir 88 lappuses, 67attēli un12 tabulas. Darbā ir ievietotas
atsauces uz 16 literatūras avotiem.
`
SatursIEVADS.....................................................................................................................................8
1. DATU BĀZES UN PROBLĒMVIDE.............................................................................11
1.1. Datu bāzes projektēšana............................................................................................11
1.2. Relāciju datu bāzes neatbilstība problēmu vidēm ar saliktiem objektiem (relāciju
datu bāzes trūkumi)..............................................................................................................12
1.3. Relāciju-objektu datu bāzes nepieciešamība saliktām problēmu vidēm...................14
2. RELĀCIJU-OBJEKTU DATU BĀZES DATU GLABĀŠANAS STRUKTŪRAS.......24
2.1. Objektu orientētās tehnoloģijas relāciju-objektu datubāzē........................................24
2.2. Datu bāzes objekts.....................................................................................................26
2.3. Glabāšanas elementi un struktūras:...........................................................................30
2.4. Asociāciju veidi.........................................................................................................32
3. RELĀCIJU – OBJEKTU DATU BĀZES PROJEKTĒŠANA........................................33
3.1. Relāciju – objektu datu bāzes konceptuālais modelis...............................................33
3.2. Objektu orientētie konceptuālie modeļi.....................................................................35
3.2.1. Projektēšanas iespējas izmantojot UML diagrammu saimes klašu diagrammu 35
3.2.2. Paplašinātais UML modelis relāciju-objektu datu bāzes projektēšanai.............38
3.3. Objektu relāciju datu bāzes projektēšanas automatizācija[3]....................................44
3.4. Daudzkriterialitāte relāciju – objektu datu bāzes projektēšanā.................................47
4. TRANSFORMĀCIJAS NO KONCEPTUĀLĀ MODEĻA UZ RELĀCIJU-OBJEKTU
FIZISKO MODELI..................................................................................................................51
4.1. Transformāciju veidi.................................................................................................51
5. RELĀCIJU-OBJEKTU DATU BĀZES PROJEKTĒŠANAS RĪKI...............................58
5.1. MIGROX integrētais karkass....................................................................................58
5.2. O-ODM relāciju-objektu datu bāzes projektēšanas karkass......................................59
`
6. RELĀCIJU-OBJEKTU DATU BĀZES DATU STRUKTŪRAS NOVĒRTĒJUMA
KRITĒRIJI...............................................................................................................................61
6.1. Objektorientētās struktūras novērtējuma metrikas....................................................61
6.2. Relāciju - objektu datu bāzes struktūras novērtējuma metrikas................................64
7. VEIDŅA VADĪTA RELĀCIJU - OBJEKTU DATU BĀZES PROJEKTĒŠANAS
AUTOMATIZĀCIJAS PROTOTIPS......................................................................................66
7.1. Konceptuālā modeļa izveide......................................................................................67
7.2. Lietotāja definētas konstruktora funkcijas.................................................................68
7.3. Lietotāja definēti šabloni objektu metodēm..............................................................70
7.4. Konceptuālā modeļa un transformāciju datu glabāšanas datu bāzes struktūras........71
7.5. Izmantotie kritēriji struktūras vērtējumam................................................................76
7.6. Veidņa vadītas sistēmas prototips.............................................................................81
SECINĀJUMI..........................................................................................................................86
IZMANTOTĀ LITERATŪRA................................................................................................88
`
IEVADSIkdienas dzīvē (darbā un atpūtā) cilvēki saskaras ar dažādām datu sistēmām. Datu
sistēma ir organizēta simbolu (grafiska zīme, vārds, skaitlis, priekšmets, subjekts, kas tāds
kas apzīmē kādu ideju, īpašību) kolekcija un metodes, ko izmanto, lai darbotos ar tiem. Lai
risinātu savus biznesa vai pētniecības uzdevumus, cilvēks veido savu priekšstatu (modeli) par
attiecīgajām datu sistēmām. Tas tiek izmantots gan analīzei, gan lēmumu pieņemšanai. Datu
sistēmas bieži ir ļoti apjomīgas. To efektīvai izmantošanai ir nepieciešams datorizēts atbalsts.
Tiek izstrādātas informācijas sistēmas (IS), kuras nodrošina datu sistēmas modeļa glabāšanu,
nepieciešamo datu iegūšanu un to attēlošanu. Datu glabāšanai un nepieciešamo datu
iegūšanai vairāk nekā 90% gadījumos izmanto datu bāzes tehnoloģiju. Tās lietošana
nodrošina sekojošas priekšrocības:
1) datu sistematizācija;
2) datu dublēšanās novēršana;
3) datu veseluma (integritātes) nodrošināšana;
4) lietotāja autentifikācijas un tiesību kontrole (datu aizsardzība);
5) vienotas datu bāzes valodas izmantošana vaicājumiem un administrēšanai;
6) lietojumprogrammu neatkarība, no datu bāzes loģiskā un fiziskā modeļa
izmaiņām.
Datu bāze iekļauj lielu faktu daudzumu. Starp tiem eksistē daudzas un dažādas saites.
Tas jāņem vērā, veidojot datu bāzes datu glabāšanas struktūru. Sākotnēji (19. gs. 60, 70 gadi)
izstrādātāji vairāk domāja par datu fiziskās glabāšanas iespējām, un mazāk uzmanības
pievērsa datu semantikai. Rezultātā izstrādātās datu bāzes un informācijas sistēmas nebija
kvalitatīvas (lietotāji bieži nebija apmierināti). Arī mūsdienās ir problēmas ar informācijas
sistēmu kvalitāti. Pēdējo pētījumu rezultāti parāda, ka no visām izstrādātajām informācijas
sistēmām tikai 25% var uzskatīt par kvalitatīvām. Kāpēc? Problēmas parasti nav saistītas ar
lietojumprogrammām (tikai speciālos gadījumos). Vaina ir datu bāzē: nekorekts vai
neveiksmīgs datu bāzes struktūras definējums, izstrādātāji nav izpratuši problēmvides
semantiku, lietotāju vajadzības un fiziskās realizācija iespējas.
5
`
Sākot ar 19. gs. 70 gadu beigām, datu konceptuālai analīzei (nesaistītai ar realizāciju)
tika pievērsta ar vien lielāka uzmanība.Datu bāzes projektēšanas process tika sadalīts 3
etapos:
1) datu (ne datu bāzes) konceptuālā modeļa izstrāde;
2) datu bāzes loģiskā modeļa izstrāde (izvēlētā datu bāzes vadības sistēmas tipa
datu bāzes loģiskās struktūras konstruēšana);
3) datu bāzes fiziskā modeļa izstrāde (izvēlētās datu bāzes vadības sistēmas datu
bāzes fiziskās struktūras konstruēšana).
Lai varētu veikt pirmo etapu, bija nepieciešama konceptuālā modeļa notācijas: datu,
datu grupējumu un saišu apzīmējumu sistēma. 19. gs. 70 gadu vidū Pīters Čens izstrādāja
realitāšu - saišu (Entity-Relationship (ER)) konceptuālo modeli. To izmantoja relāciju un
hierarhisku datu bāžu projektēšanai.
Datu bāzē ir daudz dažāda tipa dati un attiecīgas saites starp tiem. Lai pilnvērtīgi un
kvalitatīvi varētu veidot datu konceptuālo modeli, bija nepieciešams datora atbalsts (modeļa
diagrammas vizualizēšana, visu datu, to grupējumu aprakstu glabāšana un sistematizācija).
19. gs. 70 gadu beigās tika izstrādāta CASE (Computer Aided/Assisted Software/System)
tehnoloģija (lieto arī terminu datorizētā sistēminženierija).
Tiek izmantoti trīs galvenie datu bāzes vadības sistēmu (DBVS) tipi:
1) relāciju DBVS;
2) objektorientētās DBVS;
3) relāciju - objektu DBVS.
Relāciju datu bāzes sistēma ir izstrādāta, izmantojot relāciju algebru. Šis
matemātiskais pamats ļauj izmantot daudzas noderīgas metodes un teorēmas no kopu teorijas.
Tomēr tās var izmantot tikai vienkāršiem datiem. Ir arī problēmas ar datu nepieciešamajām
transformācijām starp lietojumu un datu bāzes sistēmu. Lietojumos tiek izmantoti objekti
(objektu orientētās programmēšanas valodas), bet relāciju datu bāzē objektu konstrukciju nav.
Objektorientētās datu bāzēs var veidot lietotāja definētus datu tipus, dažādus objektu
konteinerus (kolekcijas un sarakstus), kā arī iekļautus objektus. Tas rada kopību starp
lietojumprogrammas un datu bāzes datu tipa sistēmām, kas ļauj vienkāršāk pieprasīt un
saņemt objektu tipa datus. Diemžēl objektorientētajām datu bāzes sistēmām nav stingra
matemātiska pamatojuma, kas rada problēmas to darbības metožu detalizētai analīzei un
jaunu efektīvāku pilnveidojumu veidošanai.
6
`
Kā jau minēts, relāciju datu bāzes konceptuālā modeļa veidošanai lieto P. Čena
izstrādāto realitāšu – saišu (Entity – Relationship (ER)) modeli. Objektorientētās datu bāzes
konceptuālā modeļa veidošanai tiek izmantota Unificētās modelēšanas valodas (Unified
Modeling Language (UML)) klašu diagramma. Relāciju – objektu datu bāzes konceptuālā
modeļa izstrādei speciāla modeļa nav. Maģistra darbā ir mēģināts šo problēmu analizēt un
risināt.
7
`
1. DATU BĀZES UN PROBLĒMVIDE
1.1. Datu bāzes projektēšana
Lai izstrādātu kvalitatīvu lietojumu, ir jāveic datu bāzes projektēšana atbilstošajai
problēmu videi. Par datu bāzes projektēšanas procesu tiek uzskatīts darbību kopums, kurš ir
jāveic, lai no problēmvides, tajā esošajiem elementiem un asociācijām, tiktu iegūta atbilstoša
datu bāzes struktūra, kura pilnībā atbilst sistēmas definētajām prasībām. Izveidot piemērotu
datu bāzes struktūru datu bāzē ne vienmēr ir iespējams reālās dzīves atbilstošās situācijas
sarežģītības un nepārskatāmības dēļ. Datu bāzes projektēšanas process sastāv no trīs fāzēm –
konceptuālā modeļa izveidošanas, konceptuālā modeļa transformēšanas uz loģisko modeli,
loģiskā modeļa transformēšana uz fizisko modeli. Konceptuālajā modelī tiek attēloti reālās
dzīves koncepti un saites ar citiem konceptiem. Pamatā tas tiek veidots balstoties uz
projektējamās sistēmas biznesa prasībām – kādi koncepti tiks iekļauti biznesa sistēmā un kuri
koncepti savā starpā mijiedarbosies. Tādējādi tiek iegūts vienkāršs, viegli pārskatāms un
saprotams problēmvides atspoguļojums. Šis modelis netiek veidots kādai datu bāzes sistēmai
un nav atkarīgs no tālākās realizācijas – tas sniedz vispārīgu priekšstatu par projektējamo
reālās dzīves situāciju un iesaistītajiem konceptiem. Līdz ar to, šis modelis ir kā izejas punkts
citu specifiskāku modeļu izveidošanai. Transformējot konceptuālo modeli uz loģisko modeli,
tiek iegūts padziļināts problēmvides modelis. Šajā modelī jau katram konceptam ir definēts
tā atribūtu jeb īpašību kopumus. Tāpat arī šajā fāzē konceptiem tiek izdalīti unikāli
identifikatori (primārās atslēgas) un norādīts, kādā veidā koncepti mijiedarbojos – kuri ir
atribūti, ar kuriem koncepti tiek sasaistīti (arējās atslēgas). Fiziskā modeļa veidošana,
balsoties uz izveidoto loģisko modeli, ir datu bāzes projektēšanas pēdējā fāze. Šajā fāzē tiek
veidota izvēlētās datu bāzes vadības sistēmas datu bāzes struktūra. Tas nozīmē, ka visi
loģiskā modeļa elementi tiek pārveidoti par atbilstošās datu bāzes sistēmas elementiem. Šajā
fāzē ir nepieciešams arī noteikt visus datu tipus visiem atribūtiem, lai būtu iespējams izveidot
nepieciešamās tabulas un to struktūras.
8
`
1.2. Relāciju datu bāzes neatbilstība problēmu vidēm ar saliktiem
objektiem (relāciju datu bāzes trūkumi)Datu bāze – strukturēta datu kopas glabāšanas sistēma, lai dati būtu pieejami dažādiem
lietojumiem. Relāciju datu bāzē informācija tiek attēlota tabulās, kuras sastāv no rindām un
kolonnām. Tabula tiek uzskatīta par relāciju tādā mērā, ka tā ir kolekcija no viena veida datu
tipiem-rindām. Dati tabulās var tikt sasaistīti balstoties uz izveidotām atslēgām vai
konceptiem un ir iespēja no tabulas šos datus izgūt balstoties uz pielietotajiem sasaistes un
identifikācijas mehānismiem. Datu bāzes vadības sistēma (DBMS) nodrošina datu glabāšanu,
uzturēšanu un izgūšanu. Relāciju datu bāzes gadījumā relāciju datu bāzes sistēma nodrošina
šos uzdevumus. Relāciju datu bāzē dati tiek organizēti ievērojot dažādus integritātes likumus,
lai nodrošinātu, ka dati ir korekti un pieejami. Kā pirmais nosacījums ir – lai rindas datu
bāzes tabulā būtu unikālas – to nodrošina ar primārās atslēgas kolonnām vai kolonnu kopu.
Datu bāze ir organizēta no tabulām, kurās glabājas dati. Relāciju datu bāzē kolonas satur datu
bāzē definētos vienkāršos tipus (number, varchar, char, utt). Izmantojot SQL (Structured
Query Language) ir iespējams šos datus no datu bāzes izgūt norādot dažādus kritērijus.
Relāciju tabulas veidošanas komanda ir :create table <tabulas nosaukums> (
<atribūta nosaukums><atribūta datu tips>,
. . .
);
Tātad, tabulu var izveidot sekojoši:create table magistra_darbs(
md_id number,
md_nosaukums varchar2(2000 char),
md_apraksts varchar2(2000 char),
md_datums date,
md_autors varchar2(2000 char),
md_atzime number);
Datu ievietošanas tabulā sql komanda:INSERT INTO
MAGISTRA_DARBS( MD_ID, MD_NOSAUKUMS, MD_APRAKSTS,
MD_DATUMS, MD_AUTORS, MD_ATZIME )
VALUES
9
`
( mg_seq.nextval, 'Relāciju objektu db projektēšana', 'Kā
projektēt relāciju datu bāzi', sysdate, 'Uldis Vaicis', null
);
Datu izgūšanas vienkāršs piemērs:select * from MAGISTRA_DARBS where MD_ATZIME is null;
Iegūtais rezultāts:
1.1. att. Datu izgūšanas piemēra rezultāti
Lai relāciju datu bāzē modelētu saites, nepieciešams izmantot pazīmes, ar kurām
vairāku tabulu datus sasaistītu kopā. Pārsvarā tiek izmantota pamata tabulas kolonna, kura
kalpo kā primārā atslēga (Primary Key (PK)) un saistītās tabulas kolonna – ārējā atslēga
(Foreign Key (FK)), kura saistās ar pamata tabulas primāro atslēgu. Primārā atslēga tabulā ir
unikāls lauks, kurš tabulā viennozīmīgi identificē kādu no datu rindām. Lai veiktu sasaisti,
nepieciešams datu izguves vaicājumā sasaistīt iesaistīto tabulu primārās un ārējās atslēgas.
Parasti šīs atslēgas tiek veidotas tabulu projektēšanas vai veidošanas brīdī, bet diemžēl ir
iespējams, ka šīs atslēgas nav definētas. Ja tās ir nepieciešams definēt, tad pamata tabulas
primāro atslēgu var definēt sekojoši:alter table MAGISTRA_DARBS add constraint "MAGISTRA_DARBS_PK" PRIMARY
KEY ("MD_ID");
Nākamais solis ir saistītās tabulas izveide un ārējās atslēgas izveidošana.create table MD_NODALAS(
MDN_ID number,
MD_ID number,
MDN_NOSAUKUMS varchar2(2000 char));
ALTER TABLE MD_NODALAS ADD CONSTRAINT "MD_NODALAS_FK1" FOREIGN KEY
("MD_ID")
REFERENCES "MG"."MAGISTRA_DARBS" ("MD_ID") ENABLE
Kad tas ir izdarīts, tad ir iespējams izgūt datus sasaistot tabulas izmantojot atribūta
MD_ID vērtības:select * from MAGISTRA_DARBS MD , MD_NODALAS MDN
where MDN.MD_ID = MD.MD_ID
Šajā gadījumā ir tikai divas mazas tabulas, kurās sasaisti izveidot ir vienkārši, bet
problēmas rodas tad, ja datu bāzē ir simtiem tabulu, starp kurām ir jādefinē sasaistes un arī
10
`
jāraksta datu izguves vaicājumi, lai atlasītu nepieciešamos datus. Tā kā dati datu bāzē
glabājas relāciju veidā, tad datu izgūšana no, piemēram, piecām saistītām tabulām jau ir
diezgan sarežģīta un pats izguves vaicājums ir nepārskatāms. Rakstot sarežģītākus datu
izguves vaicājumus, palielinās arī lietotāja iespēja kļūdīties veicot datu atlasi. Kā arī, ja
vairākas tabulas tiek sasaistītas kopā datu izguves vaicājumos, tas atstāj negatīvu efektu arī uz
vaicājumu izpildes ātrumu.
Relāciju datu bāzes priekšrocības:
Vienkāršāks datu modelis
Vienkāršāki datu atlases vaicājumi, lietotājam vieglāk izgūt datus
Vieglāki optimizācijas mehānismi
Datu neatkarība izmantojot normalizācijas mehānismus
Relāciju datu bāzes trūkumi:
Veiktspēja
Grūti modelēt reālās dzīves modeļus
1.3. Relāciju-objektu datu bāzes nepieciešamība saliktām problēmu vidēmAttīstoties objektorientētajai programmēšanas tehnoloģijai, radās nepieciešamība
ieviest objektorientētu pieeju arī datu bāzes līmenī, jo pamatā datu bāzē tiek glabāti reālās
dzīves modeļi ar visām saitēm – objekti ar saistītajiem objektiem. Tā kā datu bāzē reālās
dzīves objekti tiek glabāti tabulu relāciju veidā, tad ir nepieciešami dažādi mehānismi, kā
lietojumos šīs relācijas notranslē uz objektiem. Ieviešot objektorientētu pieeju – izveidojot
relāciju - objektu datu bāzes sistēmu var panākt daudz efektīvāku lietojumu un datubāzes
sadarbību. Izmantojot objektorientētu pieeju arī ir vieglāk glabāt reālās dzīves objektus un to
komponentes. Šāda pieeja arī ietekmē datu bāzes ātrdarbību, kas pie mūsdienās arvien
pieaugošākā datu apjoma ir būtiska iezīme. Arī objektu uzvedību, izmantojot relāciju -
objektu datu bāzes sistēmas, var aprakstīt datu bāzes līmenī un tā vairs nav jāapraksta
lietojuma pusē, kā arī datu bāzes pusē ir iespējams nodrošināt pārējās objektiem raksturīgās
īpašības – abstrakcija, iekapsulēšana, mantošana un polimorfisms. Lietotāja definēto tipu var
veidot sekojoši:create type magistra_darbs_type as object
(
11
`
"MD_NOSAUKUMS" VARCHAR2(2000 CHAR),
"MD_APRAKSTS" VARCHAR2(2000 CHAR),
"MD_DATUMS" DATE,
"MD_AUTORS" VARCHAR2(2000 CHAR),
"MD_ATZIME" NUMBER)
Piemērā tiek izveidot objekts, kuram ir definēti pieci atribūti no Oracle datu bāzē
iekļautajiem datu tipiem. Tālāk no šī tipa var izveidot tabulu:create table magistra_darbs_obj_table of magistra_darbs_type
Datu ievietošana šādā tabulā gan ir nedaudz sarežģītāka, nepieciešams iniciēt
izveidoto tipu ar visiem norādītajiem atribūtiem – tiek izsaukta objekta konstruktora funkcija.
Datu ievietošanas komanda:insert into magistra_darbs_obj_table values(
magistra_darbs_type('Relāciju objektu db projektēšana',
'Kā projektēt relāciju datu bāzi',
sysdate,
'Uldis Vaicis',
null))
Lai no šīs tabulas atlasītu datus, nepieciešams izpildīt datu izguves vaicājumu, kurš
šādas vienkāršas objektu tabulas gadījumā ir identisks relāciju datu bāzes datu atlases
komandai:select * from magistra_darbs_obj_table where md_atzime is null;
Relāciju objektu datu bāzē sasaisti starp objektiem nodrošina norāžu veidošana vai arī
objekta saglabāšana tabulas kolonnā. Atšķirībā no relāciju datu bāzes, atsauces izveidošana
prasa vairāk zināšanu, bet iegūtais rezultāts vieglāk izmantojams, jo sasaite vairs nav jāraksta
ar roku. Projektēšanas fāzē ir svarīgi izvēlēties, kā šīs sasaistes veidot – relāciju - objektu
datu bāzē pastāv vairāku veidu glabāšanas struktūras un tehnoloģijas. Kā viena no iespējām
veidojot sasaisti ir atsauces ievietošana saistītajā tabulā. Iepriekš relāciju datu bāzes
apskatītajā struktūrā tika sasaistīta maģistra darba tabula ar nodaļu tabulu. Relāciju objektu
datu bāzes gadījumā sasaistes veidošanas soļi ir sekojoši:
tipa izveidošanacreate type md_nodalas_type as object
(
MDN_NOSAUKUMS varchar2(2000 char)
);
tabulas izveidošana:
12
`
create table md_nodalas_obj_table
(
md_atsauce ref magistra_darbs_type,
nodala md_nodalas_type
);
datu ievietošana tabulā izmantojot pamata tabulas atsauci uz iepriekš izveidoto
objektu:insert into md_nodalas_obj_table values((select ref(a) from
magistra_darbs_obj_table a where a.md_atzime is null),
md_nodalas_type('Nodala 2') );
Datu izguves vaicājums izskatās nedaudz sarežģītāks nekā relāciju datu bāzes
gadījumā, bet svarīga priekšrocība ir tā, ka sasaiste tika nodefinēta veidojot objektus un pēc
tam, veicot datu izguvi, šī sasaiste no jauna vairs nav jāraksta. Saistīto objektu datus ir
iespējams iegūt no nodaļu tabulas, jo šajā tabulā tiek saglabāta arī atsauce uz pamata tabulu.
Atsevišķi datu izguves vaicājumā pamata tabulu nav nepieciešams norādīt:select deref(a.md_atsauce)."MD_NOSAUKUMS",a.nodala.MDN_NOSAUKUMS
from md_nodalas_obj_table a
1.2. att. Iegūtais datu izguves rezultāts
Veicot divu identisku objektu saglabāšanu divu veidu struktūrās (izmantojot relāciju -
objektu datu bāzes tehnoloģiju un relāciju datu bāzes tehnoloģiju), ir redzams, ka, izmantojot
objektus, ir nepieciešamas specifiskas zināšanas par objektiem un relāciju - objektu struktūru
veidošanu, bet sasaistes veidošana starp objektiem notiek tikai vienu reizi – objektu
veidošanas procesā. Datu atlasē nav nepieciešams zināt, kuri lauki ar kuriem un kā ir saistīti,
līdz ar to kompleksu objektu izgūšana ir vieglāk realizējama un ir iespēja strādāt ar
sarežģītākiem un dzīvei atbilstošākiem datu modeļiem un objektiem.
Tāpat arī izmantojot relāciju - objektu datu bāzi ir iespējams atrisināt relāciju datu
bāzē eksistējošās problēmas[13] – normalizācijas problēmas, tādas kā transitīvo atkarību,
daudzu vērtību atribūtus un ne pirmo (Non-1st) normālformu. Kā arī piedāvā risinājumus
datu sarežģītības problēmām izmantojot tādas relāciju - objektu datu bāzes iespējas kā
objektu skatījums, objektu mantošana un objektu integrāciju. Par normalizācijas procesu sauc
13
`
loģisko datu modelēšanas tehniku izstrādes gaitā, lai iegūtu pareizi strukturētu relāciju datu
bāzes struktūru. Process sastāv no anomāliju saturošu tabulu sadalīšanas mazākās tabulās.
Parasti normalizētas tiek tabulas, kuras neatbilst pirmajai normālformai un daudzu vērtību
atribūti vismaz līdz trešajai normālformai, kā arī tiek likvidēta transitīvā atkarība.
Par transitīvo atkarību sauc situāciju, kad viena atribūta vērtība ir tieši atkarīga no kāda cita
atribūta vērtības. Piemēram, adrese parasti sastāv no vairākām daļām- atribūtiem, kuri ir
sekojoši: māja, iela, rajons un pasta indekss.1.1. tabula
Lietotāju-adrešu tabula
ID Vārds Uzvārds Māja Iela Rajons Pasta indekss1 Uldis Vaicis 5 Brīvības iela Centrs LV-10102 Jānis Bērziņš 1 Elizabetes
ielaCentrs LV-1111
Augstāk minētā tabula atbilst otrajai normālformai, bet tiek pārkāpts trešās
normālformas likums, jo tabulā šādā tabulā eksistē transitīvā atkarība, jo pasta indekss ir
atkarīgs no mājas, ielas un ielas. Funkcionāli to var attēlot kā: Fn(pasta indekss) =
māja,iela,rajons. Relāciju datu bāzē šo transitīvo atkarības problēmu var risināt trijos veidos.
Kā pirmais no variantiem ir šo tabulu nemainīt un atstāt struktūru tādu, kāda tā ir, bet tabula
saglabā otro normālformu un nav korekts relāciju datu bāzes risinājums. Otrais no
iespējamajiem variantiem ir sadalīt tabulu divās daļās veidojot lietotāju tabulu un adrešu
tabulu.1.2. tabula
Normalizēta lietotāju tabula
ID Vārds Uzvārds Pasta Indekss1 Uldis Vaicis LV-10102 Jānis Bērziņš LV-1111
1.3. tabula
Normalizēta adrešu tabula
Pasta Indekss Māja Iela RajonsLV-1010 5 Brīvības iela CentrsLV-1111 1 Elizabetes iela Centrs
Bet šāds risinājums rada nepieciešamību izmantot sasaistes starp tabulām, kuras ir
jāraksta ar roku un kuras arī atstāj iespaidu uz datu izgūšanas un labošanas veiktspēju. Vēl kā
14
`
variants ir iespējams arī saglabāt adrešu datus vienā kolonnā, bet šāda pieeja sarežģī datu
izguvi.1.4. tabula
Adrese vienā kolonnā
ID Vārds Uzvārds Adrese1 Uldis Vaicis LV-1010, 5, Brīvības
iela, Centrs2 Jānis Bērziņš LV- 1111,1,Elizabetes
iela,CentrsPiemēram, nav iespējams izgūt datus balstoties uz kādu no adreses sastāvdaļām vai arī
izgūtos datus sakārtot augošā vai dilstošā secībā. Vienīgā datu sakārtošanas iespēja pēc
adreses ir veikt kārtošanu pēc pilnās tekstuālās informācijas konkrētajā tabulas kolonnā.
Vadoties pēc relāciju datu bāzes likumiem, iespējām un efektivitātes, tad neviens no
risinājumiem nav atzīstams par ideālu, jo pastāv problēmas ar datu izgūšanu, nepieciešamas
sasaistes starp tabulām vai arī tabula neatbilst pirmajai normālformai. Izmantojot relāciju -
objektu datu bāzes tehnoloģijas – adreses struktūru var definēt kā lietotāja definēto datu dipu.
Arī lietotāja pamatinformācija tiek realizēta izmantojot lietotāja definēto datu tipu un adreses
informācija tiek iekļauta lietotāja objektā. Izmantojot UML klašu diagrammas elementus, to
var attēlot sekojoši.
LietotajsID:integer-vārds:varchar2-uzvārds:varchar2-adrese:Object+getVards()+getAdresse()
1.3. att. Lietotāja klases objekts UML pierakstā
Lai šo salikto objektu realizētu relāciju - objektu datu bāzē, nepieciešams definēt
vajadzīgos objektu tipus, lai uz to pamata varētu izveidot tabulu, kurā tiks saglabāti dati.create or replace type address_type as object
(
Māja varchar2(200) ,
Iela varchar2(200) ,
Rajons varchar2(200) ,
pasta_indekss varchar2(200)
);
Kad tips ir definēts, tad jau ir iespējams definēt arī pašu tabulu, kurā glabāsies dati.create table lietotaji
(
15
`
ID number,
Vards varchar2(200) ,
Uzvards varchar2(200) ,
Adrese address_type
);
Relāciju modelī vairāku vērtību atribūtu izmantošana ir pretrunā ar pirmo
normālformu. Pamata risinājums izmantojot relāciju datu bāzi ir šos vairāku vērtību atribūtus
sadalīt tā, lai katrs no tiem atrastos savā tabulā. Piemēram, ja tabulai ir pieci vairāku vērtību
atribūti, tad ir nepieciešamas sešas tabulas. Viena kā pamata tabula un piecas tabulas, kurās
katrā ir pa vienam daudzu vērtību atribūtam. Ja nepieciešams izgūt visas vairāku vērtību
atribūta vērtības, ir nepieciešams definēt SQL vaicājumu, kurš savieno visas iesaistītās
tabulas. Šādu vaicājumu nav ērti veidot, kā arī tas vairs nav pārskatāms un viegli saprotams.
Relāciju objektu tehnoloģija ļauj lietotājam definēt mainīga garuma masīvu kā jaunu vairāku
vērtību atribūtu glabāšanas veidu. Mainīgā garuma masīvs tiek definēts sekojoši :CREATE TYPE varray_telefons_ty AS VARRAY(3)
OF VARCHAR2(14);
Šajā masīvā ir iespējams saglabāt trīs tālruņa numurus ar garumu 14 rakstu zīmes. Pēc
tam šo pašu izveidoto tipu ar sekojošu komandu var pievienot jau izveidotajai lietotāju
tabulai.Alter table lietotaji add ( tālruna_numuri varray_telefons_ty).
Tagad, lai atlasītu visas vairāku vērtību atribūta vērtības, vairs nav nepieciešams
izmantot vairākas tabulas un veidot sasaistes starp tām. Datus labot ir iespējams izpildot
sekojošu komandu:Update lietotaji set tālruna_numuri =
(varray_telefons_ty(‘1234’,’2342423’)) where ID = 1;
Kā redzams izmanītajā piemērā, tad izmantojot relāciju - objektu tehnoloģijas ne tikai
tiek atrisināta problēma ar vairāku vērtību atribūtiem, bet arī tiek ievērojami palielināts
vaicājumu izpildes ātrums un izmantotie vaicājumi kļūst vienkāršāki. Ne pirmās
normālformas gadījumus ir iespējams arī risināt izmantojot iekļautās tabulas. Ar iekļautām
tabulām vairāku kolonnu kolekcija var tikt iekļauta citas tabulas vienā kolonnā, kā arī ir
iespējams iekļaut vairāku vērtību atribūtus tabulā, ja no tiem izveido objektu. Tādā veidā ir
iespējams izveidot kompozīciju, kas ir viena no asociāciju veidiem un ievērojami paātrināt
datu izguvi no pamata tabulas, jo vairs nav nepieciešams datu izgūšanas vaicājumos veidot
sasaistes starp tabulām. Kā piemērs tiek paņemts velosipēds un tā detaļas. Tiek pieņemts, ka
16
`
velosipēds sastāv no riteņiem, pārslēgiem un rāmja. Protams, ir vēl daudz un dažādu citu
detaļu, bet tās netiek apskatītas.
1.4. att. Velosipēda modeļa kompozīcija
Tālāk tiek izveidoti visi nepieciešami objektu tipi, kur glabāt kompozīcijas objektus.create type ritenis_type as object
(ID NUMBER,
SPIEKI varchar2(200 char),
DISKS varchar2(200 char),
RIEPA varchar2(200 char));
create type parslegs_type as object
(ID NUMBER,
ATRUMU_SKAITS varchar2(200 char),
RAZOTAJS varchar2(200 char));
create type ramis_type as object
(ID NUMBER,
IZMERS varchar2(200 char),
SVARS varchar2(200 char));
17
`
Pēc tam, balsoties uz šiem tipiem, tiek izveidotas iekļautās tabulas.create type nt_ritenis_type as table of ritenis_type;
create type nt_parslegs_type as table of parslegs_type;
create type nt_ramis_type as table of ramis_type;
Kad tas ir izdarīts, tiek veidota galvenā tabula, kura saturēs pamatinformāciju par
velosipēdu, kā arī visas saistītās iekļautās tabulas. Atšķirībā no tabulu veidošanas, kur visi
pēc noklusējuma datu bāzē iekļautie datu tipi, veidojot tabulas ar iekļautām tabulām, ir
jāizmanto speciāla komanda „NESTED TABLE <ieklauta_tabula> store as
<nosaukums>”.create table velosipeds(
REG_NUMURS varchar2(200 char),
MODELA_TIPS varchar2(200 char),
DAUDZUMS NUMBER,
CENA NUMBER,
PRIEKSEJAIS_RITENIS nt_ritenis_type,
AIZMUGURES_RITENS nt_ritenis_type,
PARSLEGI nt_parslegs_type,
RAMIS nt_ramis_type)
NESTED TABLE PRIEKSEJAIS_RITENIS store as PRIEKSEJAIS_RITENIS_NT,
NESTED TABLE AIZMUGURES_RITENS store as AIZMUGURES_RITENS_NT,
NESTED TABLE PARSLEGI store as PARSLEGI_NT,
NESTED TABLE RAMIS store as RAMIS_NT;
Relāciju objektu datu bāzes nodrošina arī objektu skatījumu veidošanu izmantojot
relāciju tabulas. Objektu skatījumi ir virtuālas objektu tabulas, kuras ļauj izstrādātājiem
pievienot objektu orientētas struktūras balstoties uz eksistējošajām tabulām un ļauj izmantot
objektu orientētās metodes strādājot ar relāciju datiem. Tas ir kā tilts starp relāciju datu bāzi
un objektu orientēto programmēšanas tehnoloģiju. Objektu skatījums izveido sava veida
objektu slāni virs relāciju tabulām un nodrošina iespēju strādāt ar datiem tā, it kā tie būtu
objekti. Vispirms tiek izveidota parasta relāciju tabula, kurā katra kolonna ir vienkāršais datu
tips, un tajā tiek ievietoti daži ieraksti.create table darijums(
darijuma_id number,
darijuma_datums date,
klienta_id number,
18
`
pardeveja_id number)
insert into darijums values (1,sysdate-4,2,5);
insert into darijums values (2,sysdate-6,34,43);
Pēc tam, balstoties uz iepriekš izmantotajiem datu tipiem, tiek izveidos jauns objekta
tips.
create type darijums_typ as object
(darijuma_id number,
darijuma_datums date,
klienta_id number,
pardeveja_id number);
Izmantojot izveidoto objekta tipu ir iespējams izveidot skatījumu, kurā relāciju tabulas
struktūra tiek transformēta uz objektu tipu struktūru.create view darijumu_skats of darijums_typ
WITH object identifier (darijuma_id) as
select darijuma_id,darijuma_datums,klienta_id,pardeveja_id from
darijums
Šajā gadījumā datu atlase no skatījuma un tabulas gan ir vienāda un ir veicama
sekojošā veidā: select * from darijumu_skats;
1.5. att. Objektu skatījums
Objektu skatījumus ar izmantot arī, lai loģiski sagrupētu relāciju datus un iegūtu
augstāku datu bāzes veiktspēju un atviegloto objektorientētu lietojumu izstrādātāju darbu ar
datu bāzi. Papildinot relāciju datu bāzes modeli ar relāciju - objektu datu bāzes iespējām tiek
nodrošināta arī funkcionalitātes un objektu atkārtota izmantošana un dalīšanās. Tas nozīmē,
ka dažādi lietojumi var izmantot vienus un tos pašus objektus, lai nodrošinātu identisku
funkcionalitāti un loģika nebūtu jāimplementē vairākās vietās. Relāciju datu bāze piedāvā
iespēju arī veidot datu tipu hierarhijas. Izmantojot šo iespēju, tiek nodrošināta iespēja veidot
augstāka un zemāka līmeņa datu tipus, kuri atrodas vienā mantošanas kokā. Piemēram, kā
augstākā līmeņa tipu var definēt darbinieku ar visiem tā atribūtiem un pēc tam zemāka līmeņa
datu tipus, kuros darbinieks tiek iedalīts kā pilnas slodzes vai daļējas slodzes darbinieks. Abu
19
`
darbinieka tipu kopīgie atribūti tiek mantoti no augšējā līmeņa darbinieka tipa. Lai izveidotu
tipu zem kāda cita tipa, ir jāizmanto atslēgvārds UNDER - CREATE TYPE pilna_laika_ty
UNDER darbinieks_ty (atribūti definēšana);
1.6. att. Virstips un apakštipi
SQL komanda lai izveidotu tipu :CREATE TYPE darbinieks_ty AS OBJECT (
vards name_ty,
telefons varray_phone_ty,
adrese address_ty
) NOT FINAL NOT INSTANTIABLE;
SQL komanda, lai izveidotu darbinieka tipu zem augstākā līmeņa datu tipa un
balstoties uz šo datu tipu izveidotu tabulu:CREATE TYPE pilna_laika_ty UNDER darbinieks _ty (
ALGA NUMBER(8,2));
CREATE TABLE PILNA_LAIKA_DARBNIEKI of pilna_laika_ty;
Objektu integrāciju tiek nodrošināta ar interfeisiem, relāciju - objektu datu bāzē
atribūti un metodes tiek kombinētas vienā strukturētā objekta tipā. Par interfeisu šajā
gadījumā tiek saukts datu tipa apraksts galvenes līmenī. Šajā līmenī definētās metodes ir
pieejamas, ja ir piešķirtas tiesības uz doto datu tipu. Metodes ir iespējams definēt arī datu tipa
ķermenī, šīs metodes vairs nav publiski pieejamas.
Relāciju objektu datu bāzes priekšrocības:
atkārtota izmantošana un komponenšu koplietošana
uzlabota produktivitāte
plašāka funkcionalitāte
20
`
plašākas iespējas modelēt reālās dzīves modeļus
sistēmas veiktspējas uzlabojumi
Relāciju objektu datu bāzes trūkumi:
sarežģītāks datu modelis
nepieciešama augstāka kvalifikācija
2. RELĀCIJU-OBJEKTU DATU BĀZES DATU GLABĀŠANAS
STRUKTŪRASLīdz ar objektu orientētas koncepcijas attīstību lietojumu izstrādes tehnoloģijās, arī datu
bāzes līmenī tika ieviesta iespēja veidot objektu orientētas struktūras. Šī koncepcija tiek arī
izmantota relāciju-objektu datu bāzēs. Līdzīgi kā objektu orientētajās tehnoloģijās, arī datu
bāzē pats pamats ir objekts, kuram ir specifiskā veidā aprakstīta definīcija – kādi atribūti un
kāda uzvedība ir objektam.
2.1. Objektu orientētās tehnoloģijasrelāciju-objektu datubāzēLai datu bāzes līmenī varētu nodrošināt darbu ar objektiem, kā tas ir objektorientētajās
programmēšanas tehnoloģijā, nepieciešams objektorientētos konceptus realizēt arī datu bāzes
līmenī. Tas nozīmē, ka datu bāzē tiek nodrošināta iespēja saglabāt objektus, kā arī objektiem
ir savs datu tips, dati un metodes, ar kurām ir iespējams mainīt objektu stāvokli un uzvedību.
Relāciju – objektu datu bāzē realizētās objektorientētās iespējas un īpašības attēlotas tabulā
2.1. [14]. Kā redzams tabulā, tad būtiskākā atšķirība ir klašu hierarhijas veidošana, jo relāciju
– objektu datu bāzes pieejā šāda struktūras sauc par saliktiem objektiem. Saliktu klašu
jēdziena objektorientētajā programmēšanā nav – ir pamata klases un klases, kuras ir
iesaistītas mantošanā. Būtiska atšķirība vēl ir tā, ka datu bāzes līmenī klasei atbilst lietotāja
definēts tips.2.5. tabula
Objekorientētā pieeja relāciju – objektu datu bāzē
Objektorientētā pieeja Relāciju – objektu datu bāze
21
`
2.2. Datu bāzes objektsParasti ar objektu tiek apzīmēts kādu sastāvdaļu vienots kopums, un katra objektam,
tāpat arī sastāvdaļām ir definēts savs tips. Datu bāzes objekta tips ir lietotāja definēts tips
(User Defined Type (UDT)), ar kura palīdzību ir iespējams modelēt reālās dzīves realitātes kā
objektus datu bāzē. Jauni objekta tipi var tikt veidoti gan izmantojot jau pēc noklusējuma
veidotos datu tipus, kuri ir definēti datu bāzē, gan arī jebkurus tipus, atsauces un kolekcijas,
kuras iepriekš tikušas izveidotas. Objektu tipos var tikt saglabāti arī kompleksie dati – tādi kā
22
`
audio, video un attēli. Arī lietotāja definēto tipu metadati ir pieejami tieši tāpat, kā relāciju
datu bāzes tabulām. Objektu tipi nodrošina austākā līmeņa iespējas organizēt piekļuvi datiem
datu bāzē. Objektiem var būt arī definētas metodes, ar kuru palīdzību no objekta datiem var
iegūt nepieciešamos rezultātus. Piemēram – objekts ir pasūtījums ar vairākām precēm un
pasūtījuma objektam ir metode, ar kuru var izrēķināt cik maksāja visas preces kopā. Lielākais
ieguvums no šādām struktūrām ir tas, ka objekta tipi un metodes tiek glabātas datu bāzē tāpat
kā dati un tās ir pieejamas no jebkura lietojuma. Ja tiek izstrādātas vairākas sistēmas dažādās
tehnoloģijās, nav vairs nepieciešams pārdefinēt objektu tipus un pārrakstīt jau datu bāzes
pusē eksistējošās metodes, lai nodrošinātu tādu pašu funkcionalitāti. Tāpat arī no uzturēšanas
un atkļūdošanas viedokļa, liels ieguvums ir tas, ka metožu loģika ir tikai vienā vietā – t.i. datu
bāzē. Atšķirībā arī no relāciju datu bāzes, ja tiek veikts vaicājums pēc viena objekta, tad tiek
izgūti arī visi saistītie objekti. Nav nepieciešams rakstīt dažādus vaicājumus, lai iegūtu
saistītos datus. Objekts tiek veidots no objekta tipa. Objektu tips savukārt ir datu tips, kurš var
tikt izmantos kā jebkurš cits datu bāzes datu tips. Tas arī ir kā šablons pašam objektam, kurš
iekļauj objekta definīciju un uzvedību. Definīcija sastāv no atribūtiem, kuri var būt gan
vienkāršā datu tipa, gan objektu datu tipa. Uzvedību definē metodes (procedūras un
funkcijas). Var izšķirt trīs metožu tipus: konstruktora metodes, statiskās metodes un instances
metodes. Instances metodes izmanto, lai piekļūtu objekta datiem un definētu dažādas
operācijas, kuras pēc tam varētu izsaukt no lietojuma. Statiskās metodes nestrādā ar instanču
datiem un instancēm, tās jau ir globālas pašam objektu tipam. Katram objektam pēc
noklusējuma ir sava konstruktora metode, bet ir iespējams to pārrakstīt, ja nepieciešams
iniciēt klasi ar citādāku parametru skaitu, nekā to piedāvā noklusējuma konstruktora metode.
Piemērs: tiek izveidots tips eksāmens, veidošanas komanda ir sekojoša:create type eksamens as object (
nosaukums varchar2(200) );
Ar šo komandu tiek nodefinēts lietotāja definētais datu tips, kuram ir definēts
nosaukums ar datu bāzē iekļauto datu tipu varchar2 un izmēru 200 rakstu zīmes. Šim tipam
ķermenis netiek definēts.
Tiek izveidots tips students – tipā iekļautas gan instances metodes, gan konstruktora funkcijas
gan arī statiskās metodes:create or replace type students as object (
vards varchar2(200),
23
`
uzvards varchar2(200),
apliecibas_nr varchar2(200),
STATIC PROCEDURE kas_ir_students,
MEMBER FUNCTION karto(p_eksamens eksamens ) return varchar2,
MEMBER PROCEDURE pievienot_apl_numuru(p_nr varchar2) ,
CONSTRUCTOR FUNCTION students(p_vards varchar2,p_uzvards varchar2)
return SELF as RESULT)
Tiek izveidots arī tipa ķermenis, kurā tiek aprakstītas visas definētās metodes un procedūras.
create or replace type body students as
CONSTRUCTOR FUNCTION students(p_vards varchar2,p_uzvards varchar2)
return self
as RESULT
AS
begin
SELF.vards :=p_vards;
SELF.uzvards:=p_uzvards;
SELF.apliecibas_nr:='Nav piešķirts';
RETURN;
end;
STATIC PROCEDURE kas_ir_students
as
begin
dbms_output.put_line('Students is tas, kurš studē');
end;
MEMBER FUNCTION karto(p_eksamens eksamens) return varchar2
as
begin
return null;
end;
MEMBER PROCEDURE pievienot_apl_numuru(p_nr varchar2)
as
begin
SELF.apliecibas_nr := p_nr;
end;
24
`
end;
Tipam students ir definēta statiska procedūra- kas_ir_students. Lai izsauktu šo
procedūru, nav nepieciešams izveidot pašu studenta objektu – tā tiek izsaukta no objekta tipa.
Izsaukšanas piemērs:begin
students.kas_ir_students();
end;
Lai izsauktu visas pārējās metodes gan ir nepieciešams iniciēt objektu – tas ir –
izveidot klases eksemplāru izsaucot konstruktora metodi. To var izdarīt gan izsaucot definēto
konstruktora metodi, gan arī izmantojot konstruktora metodi, kura izveidojas pēc
noklusējuma.declare
p_students students;
p_students2 students;
begin
p_students:=students('uldis','vaicis');
dbms_output.put_line(p_students.apliecibas_nr);
p_students.pievienot_apl_numuru('ir numurs');
dbms_output.put_line(p_students.apliecibas_nr);
p_students2:=students('uldis','vaicis','test');
dbms_output.put_line(p_students2.apliecibas_nr);
end;
Pievienotajā piemērā ir redzami abi konstruktora metodes izsaukumi un arī viens
instances metodes izsaukums – pievienot_apl_numuru(numurs), ar kuru tiek pievienots
apliecības numurs izveidotajam studenta objekta eksemplāram, kurš veidots saucot lietotāja
definēto konstruktora metodi. Izmantojot pēc noklusējuma izveidoto konstruktora metodi,
apliecības numurs jau ir viens no obligātajiem parametriem.
Veidojot objektu tabulas no objekta tipiem, ja netiek norādīts objekta identifikators
(object id – jeb OID), tad Oracle pats to uzģenerē, lai efektīvāk strādātu ar objektiem. Jāsaka
gan, ka šis OID ir slēptais objekta atribūts un lietotājam nav pieejams. Ieteicamāks variants ir
pašam parūpēties par OID lauka vērtību un ģenerēt to pašam, ja šo lauku nepieciešams redzēt
vai aizpildīt ar paša izvēlētām vērtībām (šis OID ir objekta rindas primārā atslēga).
Ir ļoti neefektīvi nodot kā parametru objektus, jo tas aizņem gan laiku, gan arī nepieciešams
vairāk resursu. Lai to būtu iespējams efektīvāk izdarīt, tad starp metodēm tiek nodota objektu
25
`
atsauce jeb reference (REF). Tā ir kā norāde uz konkurēto objektu. Zemāk redzamajā piemērā
tiek veidota objektu tabula, kur vien no kolonnām ir norāde uz citu objektu.create or replace type studenta_personas_kartina as object (
persona REF students,
iestasanas_datums date)
create table kartinu_tabula of studenta_personas_kartina;
Šādi tiek izveidota tabula kartinu_tabula no tikko izveidotā tipa, kurā viens no
parametriem ir norāde uz studenta objektu un lauku, kurā atrodas šī norāde sauc par
„persona”. Ir iespējams nolasīt norādi izmantojot funkciju REF. Lai no norādes tiktu pie
objekta, nepieciešams izsaukt funkciju DEREF, ar kuru no norādes tiek iegūts objekts ar
visiem saistītajiem parametriem un atribūtiem. REF un DEREF lietošanas piemērs, kur
izveidotajā tabulā tiek ievietota jauna rinda un norāde uz personas studenta objektu, tad šī
norāde tiek nolasīta un izmantojot DEREF no norādes tiek iegūts objekts. Objektam tiek
pamainīta vērtība un objekts tiek atjaunots tabulā, kura ir saistīta ar tabulu, kurā atrodas
norāde. Pēc tam tiek izpildīts vaicājums, lai pārliecinātos, ka caur tabulu kartinu_tabula
izgūstot objektu no norādes, tiek iegūta atjaunotā vērtība.:declare
p_ref REF students;
p_students students;
spk studenta_personas_kartina;
begin
select REF(ss) into p_ref from studentu_saraksts ss;
spk:=studenta_personas_kartina(p_ref,sysdate);
insert into kartinu_tabula values(spk);
select persona into p_ref from kartinu_tabula;
select deref(p_ref) into p_students from dual;
p_students.vards :='uldis2';
UPDATE studentu_saraksts p SET p = p_students WHERE
ref(p) = p_ref;
end;
select DEREF(persona).vards from kartinu_tabula
26
`
Oracle datu bāzē var tikt izmantotas divu veidu kolekcijas[10] – mainīga garuma
masīvi (varibable-length array (VARRAY)) un iekļautās tabulas (nested tables). Mainīgā
garuma masīva veidošanas sql komanda ir : CREATE TYPE [tipa nosaukums] is VARRAY(izmērs) of [datu tips],
kur tipa nosaukums ir lietotāja izvēlēts datu tipa nosaukums, izmērs ir nepieciešamais
elementu skaits masīvā un datu tips – ir oracle iekšējais datu tips vai arī lietotāja definētais
datu tips.
Lai izveidotu iekļauto tabulu, veidošanas komanda ir:CREATE TYPE [tipa_nosaukums] as TABLE of [datu tips],
kur tipa nosaukums ir lietotāja izvēlēts tipa nosaukums un datu tips ir Oracle iekšējais datu
tips vai arī lietotāja iepriekš definēts datu tips. Ar šo komandu tiek izveidota iekļautā tabula,
kur katra rinda sastāv no izvēlētā datu tipa.
2.3. Glabāšanas elementi un struktūras:
Relāciju tabula – pamatelements relāciju - objektu datu bāzē, visi objekti tiek glabāti
tabulās, kuras var būt gan objektu tabulas – kur visa tabulas rinda ir objekts un veidota no
lietotāja izveidotā datu tipa vai arī kā tabula, kurai viena no kolonnām sastāv no objektiem.
Relāciju tabula :
2.7. att. Tabula
Vienkāršs objekts – veidots no lietotāja definēta datu tipa ar definētiem atribūtiem un
uzvedību.
2.8. att. Vienkāršs objekts
Vienkāršs objekts ar identifikatoru – līdzīgi kā iepriekš apskatītajam objektam –
veidots no lietotāja definētā datu tipa, bet klāt vēl nāk OID (object id ) atribūts :
27
`
2.9. att. Vienkāršs objekts ar identifikātoru
Salikts objekts – objekts, kura viens no atribūtiem ir cits objekts, kurš izveidots no
lietotāja definētā tipa, kuram savukārt ir pašam savi atribūti:
2.10. att. Salikts objekts
Salikts objekts ar identifikatoru – līdzīgs kā saliktais objekts, bet ir papildus atribūts
OID.
2.11. att. Salikts objekts ar identifikatoru
Objektu kolekcija – masīvs no vairākiem izveidotiem objektiem:
2.12. att. Objektu kolekcija
Objektu kolekcija ar identifikatoru – vienīgā atšķirība no objektu kolekcijas ir tā, ka
klāt nāk OID atribūts:
2.13. att. Objektu kolekcija ar identifikatoru
Tabula ar rindas tipa objektiem – šādā tabulā ir tikai viena kolonna, kur katra no
rindām satur objektu:
28
`
2.14. Tabula ar rindas tipa objektiem
Tabula ar objektu kolonnu – atšķirībā no iepriekšējās tabulas, šeit viena vai vairākas
kolonnas var saturēt objektus, bet var būt arī parastie Oracle datu bāzē pēc noklusējuma
definētie datu tipi :
2.15. att. Tabula ar objektu kolonnu
Tabula ar neviendabīgiem objektiem – objektu kolonnā iespējams saglabāt dažādu
klašu objektus, tiem gan ir jāatbilst vienam tipam – objektiem jābūt vienā mantošanas kokā:
2.16. att. Tabula ar neviendabīgiem objektiem
2.4. Asociāciju veidiPar asociāciju sauc objektu sasaisti vienam ar otru. Tas nozīmē, ka viens objekts ir saistīts ar
otru un klases eksemplārs izmanto citu klases eksemplāru. Oracle datu bāzē starp objektiem
eksistē vairāku veidu asociācijas, tās ir: agregācija, atkarība, kompozīcija, mantošana.
Atkarība nozīmē to, ka vienas klases objekts ir tieši atkarīgs no cita klases objekta un tam ir
nepieciešamas otras klases funkcijas, lai spētu veikt savas darbības.
Agregācija ir asociācija, kura veido „vesels-daļa” saiti starp objektiem un visi „daļa” objekti
veido pilnu veselo objektu. Šajā gadījumā objekts var tikt izveidots no vairākiem objektiem
vai arī objekts sastāv no vairākiem objektiem.
Kompozīcija savukārt ir speciāls agregācijas veids, kad agregāta ( „veselā” daļas) sastāvdaļas
(„komponentes”) ir neatņemamas un agregāta daļas bez agregāta nespēj eksistēt.
29
`
Tāpat arī par asociāciju sauc speciālu saites veidu objektorientētajās datu bāzēs.
3. RELĀCIJU – OBJEKTU DATU BĀZES PROJEKTĒŠANA
3.1. Relāciju – objektu datu bāzes konceptuālais modelis
Datu semantiskais modelis tiek definēts kā priekšmetu vides datu modelis, kurš ir
neatkarīgs no datu bāzes realizēšanai izmantojamā datu bāzes tipa. Tomēr jāņem vērā, ka
dāžādiem datu bāzes vadības sistēmu tipiem ir atšķirīgas iespējas realizēt datu semantikas
konstrukcijas. Tāpēc viens un tas pats datu semantiskais modelis neļauj pilnvērtīgi iekļaut tās
zināšanas, kuras varētu tikt lietderīgi izmantotas veidojot datu bāzes loģisko modeli.
Relāciju datu bāzes konceptuālā modeļa veidošanai P. Čens izstrādāja realitāšu – saišu
(Entity – Relationship (ER)) modeli. Objektorientētās datu bāzes konceptuālā modeļa
veidošanai tiek izmantota Unificētās modelēšanas valodas (Unified Modeling Language
(UML)) klašu diagramma. Relāciju – objektu datu bāzes konceptuālā modeļa izstrādei
speciāla modeļa nav. Tāpēc ir mēģinājumi minētos modeļus pielāgot relāciju – objektu datu
bāzes vajadzībām.
ER modelis tiek paplašināts:
1) iekļaujot tajā elementus datu mantošanas, agregācijas un kompozīcijas attiecību
norādei. Tātad tiek pilnveidota saišu sistēma. Šadu ER modeli sauc par Paplašināto
ER diagrammu (Extende ER diagramm).
2) papildus eksistējošajiem datu grupējumu elementiem, tiek veidoti jauni, kuri
reprezentē datu objektus ar metodēm.
Pirmā veida paplašinājumi tiek iekļauti arī projektēšanas CASE (Computer Aided
System Engineering) rīkos. Lai ER modelī nodrošinātu otrā veida paplašinājumus, CASE rīki
ir papildināti ar iespējām veidot jaunus datu grupējumu elementus un saites. Kā piemēru var
minēt firmas Sybase CASE rīku PowerDesigner. Tajā ir iekļautas plašas iespējas apvienot
dažādas konceptuālā modeļa notācijas un veidot jaunus datu grupējumu un saišu elementus.
Protams šiem elementiem ir jādefinē arī atbilstošās transformācijas no datu konceptuālā
modeļa uz datu bāzes loģisko modeli.
Veidojot semantisko modeli ar objektorientētas tehnoloģijas izmantošanu, modelī tiek
iekļautas svarīgākās objektorientētās paradigmas koncepcijas: klases, objekti, iekapsulēšana,
30
`
agregācija, mantošana, polimorfisms un abstrakcija. UML valoda ļauj attēlot gan modeļa
statikas, gan dināmikas īpašības. Ļoti svarīgi, ka UML valodas izstrādātāji ir sapratuši
nepieciešamību un iekļavuši modeļa paplašināšanas un specializēšanas iespējas. UML
standarta notācijas un diagrammas var tikt pielāgotas
sekojošiem aspektiem:
1) lietošanas nosacījumiem. Relāciju – objektu datu bāzē tiek izmantoti salikti dati
(XML, multimēdiju dati, grafiskie dati).
2) kopējam datu struktūras modelim;
3) tipiskām darbībām ar datiem.
Lai to realizētu, tiek izmantoti:
1) stereotipi, tie ļauj paplašināt UML vārdnīcu ar jauna tipa datu blokiem, kuri tiek
atvasināti no eksistējošiem. Šiem blokiem var būt specifiskas īpašības, kuras
raksturīgas apskatāmajai problēmvidei. Tiem ir jauns attēlojums un semantika.
2) komentāri dod papildus skaidrojumus gad datu blokiem, gan saitēm. Tiek norādītas to
īpatnības, kuras jāņem vērā, veicot transformāciju, lai iegūtu datu bāzes loģisko
modeli.
3) ierobežojumi ļauj modificēt eksistējošos likumus vai definēt jaunus, ievērojot
problēmvides specifiku.
4) iezīmētas vērtības (tagged values). Ar stereotipu palīdzību var veidot jaunus datu
bloku un saišu tipus, bet ar iezīmēto vērtību palīdzību var tiem definēt jaunas īpašības.
Stereotipu, komentāru, ierobežojumu un iezīmēto vērtību kopa veido semantiskā modeļa
aprakstu (profile). Tātad UML klašu diagrammu var pielāgot realitāšu – objektu datu bāzes
semantiskā modeļa izstrādei.
Gan paplašinātai ER diagrammai, gan specializācijas izmantošanai UML klašu
diagrammā ir būtisks trūkums. Paplašinājumi tiek veikti uz jau eksistējošu konstrukciju
bāzes, nevis veidojot jaunus datu blokus un saites bet modificējot standarta variantus. Tas
būtiski apgrūti jaunievedumu veikšanu. Šie modeļi ir jātransformē datu bāzes loģiskajā
modelī. Arī šī uzdevuma veikšana notiek divos soļos. Tiek realizētas divas transformācijas:
1) transformācija no standarta pamatelementa atbilstošā datu bāzes loģiskā modeļa
sastāvdaļas iegūšanai (1. Transformācija3.17. att.);
2) iegūtā rezultāta korekcija saskaņā ar veiktajiem paplašinājumiem (2. Transformācija
3.17. att.).
31
`
3.17. att. Datu bāzes projektēšanas process
3.2. Objektu orientētie konceptuālie modeļiLai varētu izveidot kroketu un reālai dzīvei atbilstošu datu bāzes modeli, ir
nepieciešams izveidot modeļa konceptuālo modeli. Jāņem vērā tas, ka šajā gadījumā jāveido
objektu orientēts konceptuālais modelis. Konceptuālo modeli var izveidot izmantojot gan
UML saimes klašu diagrammu, gan arī paplašināto realitāšu saišu diagrammu. Tajā tiek
attēloti koncepti ar visiem nepieciešamajiem atribūtiem, kā arī definēts, kā koncepti savā
starpā sadarbojas – kādas saites starp tiem. Pamatelementi konceptuālajā modelī ir realitātes,
realitāšu atribūti un to metodes (apraksta realitātes uzvedību).
3.2.1. Projektēšanas iespējas izmantojot UML diagrammu saimes klašu diagrammu
Kā viena no konceptuālā modeļa projektēšanas iespējām var tikt izmantota UML
diagrammu saimes klašu diagramma. Klašu diagrammas elementi visvairāk atbilst relāciju -
objektu datu bāzes struktūras konceptuālajam modelim. Tas sevī iekļauj klašu jeb realitāšu
veidošanu, atribūtu norādīšanu, kā arī metožu pievienošanu klasēm/realitātēm. Tāpat ir
iespēja arī modelēt saites starp realitātēm. Piemēram tiešsasaistes diagrammu rīka
creately.com[11] nodrošinātie saišu veidi starp realitātēm ir asociācija, agregācija,
kompozīcija un atkarība. Tieši šie saišu veidi arī pamatā raksturo objektorientētās pieejas
īpašības.
UML[2] ir lietošanas gadījumu vadīta modelēšanas valoda, ar kuras palīdzību ir
iespējams attēlot sistēmas funkcionalitāti.
32
`
3.18. att. Projektēšanas shēma
Lietošanas gadījumu apraksts ir teksta veida aprasts, kurš atspoguļo sistēmas pamata
funkcionalitāti un kas tiek sagaidīts no izveidotās relāciju - objektu datu bāzes shēmas.
Apraksts tiek veidots par pamatu ņemot sistēmas funkcionālās prasības.
3.19. att. Lietošanas gadījumu apraksts
Lietošanas gadījumu diagramma tiek iegūta no lietošanas gadījumu
apraksta.Secību(sequence) diagrammu veido no lietošanas gadījumu diagrammas, katram
lietošanas gadījumam iegūstot vienu secību diagrammu. Tā attēlo objektus no lietošanas
gadījumu diagrammas un ziņojumus, ar kuriem objekti apmainās katrā no lietošanas
gadījumiem. Objekti(klases) tiek iegūti no aktieriem un izmantotajiem objektiem.
UML klašu diagrammā datus un metodes var iekļaut klasēs, tādējādi nodrošinot
objektorientēto pieeju. Tāpat arī ziņojumi no attiecīgās secību diagrammas tiek iekļautas
saistīto objektu metodēs.
Dizaina plūsma (design worklow) strukturē statiskos un dinamiskos objektu relāciju
sistēmas aspektus no analīzes plūsmas. Šajā plūsmā tiek atrisinātas tradicionālās relāciju datu
33
`
bāzes problēmas – daudz vērtību atribūti, normālformas (izņemot pirmo normālformu), kā arī
transitīvā atkarība starp objektiem.
3.20. att. Relāciju – objektu datu bāzes struktūras projektēšana
UML diagrammas transformācija sastāv no tās loģiskās datu struktūras un datu
uzvedības. Atšķirībā no Relāciju datu bāzes, objektu tipi objektu relāciju datu bāzē pilnībā
atbalsta iekapsulēšana, kur metožu definīcijas tieši var saistīt ar objektu tipu definīcijām.
UML diagramma piedāvā arī agregāciju un kompozīciju, ko nespēj piedāvāt ERD.
3.21. att. Objeta tipu mantošana
Pēc tam seko ieviešanas fāze, kur UML klašu diagrammas elementi tiek sasaistīti ar
relāciju - objektu datu bāzes tipiem un glabāšanas iespējām – objektu datu tipu iekapsulēšana,
objektu tipu mantošana, kolekcijas tipi – VARRAY vairāku vērtību atribūtiem, kompozīcija
izmantojot iekļautās tabulas.
34
`
Objektu datu tipi :
3.22. att. Objektu datu tipi
Objektu tipu mantošana ļauj lietotājam definēt datu tipu hierarhijas. Izmantojot
hierarhijas ir iespējams definēt apakš tipus klasēm, kuras var mantot visus superklases
atribūtus.
VARRAY ir Relāciju objektu datu bāzes kolekcijas tips, kurš sastāv no objektu kopas,
kuriem ir tāds pats sākotnēji definētais datu tips. Relāciju datu bāzē šādas struktūras tiek
glabātas veidojot jaunu tabulu katram no atribūtiem, lai atbilstu pirmajai normālformai.
3.23. att. Mainīga garuma masīvu (Varray) izmantošana
Iekļautā tabula ir tabula, kura var tikt saglabāta citā tabulā. Tādējādi vairāku tabulu
kolekcija var tikt saglabāta kā viena kolonna citā tabulā.
3.2.2. Paplašinātais UML modelis relāciju-objektu datu bāzes projektēšanai
UML modelis arī sevī iekļauj paplašināšanas iespējas, lai to varētu papildināt ar
nepieciešamajām modelēšanas iespējām. Tiek piedāvāti sekojoši papildināšanas elementi:
Stereotipi – stereotips papildina UML valodu, ļaujot izmantot jauna tipa blokus, kuru
īpašības ir mantotas no eksistējošajiem, bet ir iespējams pievienot problēmai
specifikas īpašības. Katram jaunajam blokam ir savas īpašības, semantika (katrs
stereotips var iekļaut dažādus ierobežojumus) un notācija. Stereotips ir kā jaunā
izveidotā bloka nosaukums.
35
`
Iezīmētās vērtības – paplašina UML bloka atribūtus ļaujot pievienot jaunu informāciju
elementa specifikācijā un pievienot jaunus atribūtus. Tie tiek attēloti zem
jaunizveidotā bloka nosaukuma.
Ierobežojumi – papildina UML bloka semantiku dodot iespēju pievienot jaunus
likumus vai arī mainot eksistējošos. Tie attēlo īpašus likumus, kuriem ir jābūt
patiesiem, lai modelis būtu korekti. Vizuāli tas tiek attēlots, kā teksta virkne, kura ir
novietota blakus saistītajam elementam.
Relāciju datu bāzes modelim atbilstošie stereotipi ir redzami sekojošā tabulā:
3.6. tabula
Stereotipi
Datu bāzes elements
UML Elements Stereotips Ikona
Arhitektūras Datubāze Komponente <<Database>>
Shēma Pakotne <<Schema>>
Konceptuālie Pastāvībā klase Klase <<Persistent>>Daudzvērtību atribūts
Atribūts <<MA>>
Aprēķināmais atribūts
Atribūts <<DA>>
Kompozīta atribūts Atribūts <<CA>>Identifikators Attribūts <<ID>>
Loģiskie Tabula Klase <<Table>>
Skatījums Klase <<View>>Kolonna Atribūts <<Column>>Primārā atslēga Atribūts <<PK>>Ārējā atslēga Atribūts <<FK>>Ne nulles ierobežojums
Atribūts <<NOT NULL>>
Unikālais ierobežojums
Atribūts <<Unique>>
Trigeris Ierobežojums <<Trigger>>Pārbaudes ierobežojums
Ierobežojums <<Check>>
Procedūra Klase <<Stored Procedure>>
Fiziskie Tabulvieta Komponente <<Tablespace>>Indekss Klase <<Index>>
Kā redzams, tad starp stereotipiem nav relāciju - objektu datu bāzei raksturīgās lietas
– kolekciju tipi, atsauču tipi un metodes. Lai būtu iespējams modelēt relāciju - objektu datu
36
`
bāzi, nepieciešams paplašināt UML valodu ar jauniem stereotipiem. Stereotipi norādīti
balstoties uz SQL:1999 , gan arī uz Oracle8i specifikāciju.3.7. tabula
SQL:1999 Stereotipi
Strukurēts tips (Structured Type) Metamodeļa klase Klase Apraksts <<UDT>> attēlo lietotāja definētos tipus Ikona Nav Ierobežojumi Izmanto tikai, lai definētu vērtības tipu Iezīmētās vērtības NavTipu tabula (Typed table) Metamodeļa klase Klase Apraksts Definēts kā <<Object Type>>. Attēlo datu bāzes shēmas klasi, kurai jābūt
definētai kā strukturēta tipa tabulai Ikona
Ierobežojumi Tipu tabula iekļauj strukturētā tipa definīciju Iezīmētās vērtības NavKnows Apraksts <<Knows>> asociācija ir speciāla tipa saite, kura savieno klasi ar lietotāja
definēto tipu <<UDT>>. Tā ir viena virziena sasaiste. Ikona Nav Ierobežojumi Var tikt izmantos tikai, lai sasaistītu <<Object Type>> klasi ar <<UDT>>
klasi Iezīmētās vērtības NavAtsauces tips (REF Type) Apraksts <<REF>> attēlo sasaisti ar kādu <<Object Type>> klasi Ikona Ierobežojumi <<REF>> atribūts var atsaukties tikai uz <<Object Type>> klasi Iezīmētās vērtības <<Object Type>> klase, uz kuru tā attiecasMasīvs (ARRAY) Metamodeļa klase Atribūts Apraksts <<ARRAY>> reprezentē indeksētu un ierobežotu kolekcijas tipu Ikona Ierobežojumi Masīva elementi var būt jebkura datu tipa, izņemot masīva tipa elementi Iezīmētās vērtības Masīva elementu tipi
Elementu skaits masīvā
Rindas tips (ROW Type) Metamodeļa klase Atribūts Apraksts <<row>> reprezentē salikta tipa atribūtu ar noteiktu elementiem, katrs no
tiem var būt ar citu datu tipu Ikona
Ierobežojumi Nav iespējams izmantot metodes Iezīmētās vērtības Katra elementa nosaukums un datu tipsPārdefinētā metode (Redefined method) Metamodeļa klase Metode Apraksts <<redef>> metode no jauna ir implementēta bērna klasē Ikona Nav Ierobežojumi Nav
37
`
Iezīmētās vērtības Metodes parametri un to datu tipi, kā arī metodes atgrieztais datu tipsAtliktā metode (Deffered method) Metamodeļa klase Metode Apraksts <<def>> metode ir metode, kura tiek implementēta bērna klasē Ikona Nav Ierobežojumi Jābūt definētai klasē, kurai ir bērni Iezīmētās vērtības Metodes parametri un to datu tipi, kā arī metodes atgrieztais datu tips
3.8. tabula
Oracle8i Stereotipi
Objekta tips (Object Type) Metamodeļa klase Klase Apraksts <<UDT>> attēlo lietotāja definētos tipus, atbilst
SQL:1999 strukturētajam tipam. Ikona Nav Ierobežojumi Izmanto tikai, lai definētu vērtības tipu Iezīmētās vērtības NavObjektu tabula (Ojbect table) Metamodeļa klase Klase Apraksts Definēts kā <<Object Type>>. Attēlo datu bāzes
shēmas klasi, kurai jābūt definētai kā objektu tipu tabulai. Atbilst SQL:1999 tipu tabulai.
Ikona
Ierobežojumi Tipu tabula iekļauj strukturētā tipa definīciju Iezīmētās vērtības NavKnows Metamodeļa klase Asociācija Apraksts <<Knows>> asociācija ir speciāla tipa saite, kura
savieno klasi ar lietotāja definēto tipu (<<UDT>>,<<ARRAY>> vai <<NT>>), kurš tiek izmantots klasē. Tā ir viena virziena sasaiste.
Ikona Nav Ierobežojumi Var tikt izmantos tikai, lai sasaistītu <<Object
Type>> klasi ar <<UDT>> klasi Iezīmētās vērtības NavAtsauces tips (REF Type) Apraksts <<REF>> attēlo sasaisti ar kādu <<Object Type>>
klasi Ikona Ierobežojumi <<REF>> atribūts var atsaukties tikai uz <<Object
Type>> klasi Iezīmētās vērtības <<Object Type>> klase, uz kuru tā attiecasMainīga garuma masīvs (VARRAY) Metamodeļa klase Atribūts/Klase Apraksts <<ARRAY>> reprezentē indeksētu un ierobežotu
kolekcijas tipu, atbilst masīva tipam SQL:1999 standartā.
Ikona Ierobežojumi Masīva elementi var būt jebkura datu tipa, izņemot
citu kolekciju tipa elementi Iezīmētās vērtības Masīva elementu tipi
38
`
Elementu skaits masīvā
Iekļauta tabula (Nested table) Metamodeļa klase Klase Apraksts <<NT>> reprezentē neindeksētu, neierobežotu
kolekcijas tipu Ikona Ierobežojumi Iekļautās tabulas elementi var būt jebkura tipa,
izņemot kolekcijas tipus Iezīmētās vērtības Iekļautās tabulas pamata tips
Autoru piedāvātā relāciju - objektu datu bāzes projektēšanas metodoloģija pamatā
sastāv no trīs fāzēm – analīzes, projektēšanas un ieviešanas daļas.
3.24. att. Projektēšanas fāzes
Analīzes daļā tiek izveidota UML diagramma, kurā attēlots modeļa konceptuālā
shēma. Projektēšanas daļa savukārt sastāv no divām daļām – standarta loģiskais projektējums
un specifiskais loģiskais projektējums. Standarta projektējums ir neatkarīgs modelis, kurš ir
vispārīgs un nav domāts kādai konkrētai ieviešanas valodai vai tehnoloģijai. Specifiskas
loģiskais modelis jau ir projektējums konkrētai tehnoloģijai, piemēram, Oracle8i. Standarta
modeli ir iespējams veidot izmantojot SQL:1999 specifikāciju vai UML , kuram pievienoti
iepriekš apskatītie SQL:1999 stereoptipi. Arī veidojot specifisko modeli, ir divas iespējas. Tā
kā šis modelis jau ir specifisks un veidots konkrētai tehnoloģijai, šajā gadījumā Oracle8i, tad
ir iespējams šo modeli definēt izmantojot Oracle8i standartus, vai arī UML ar pievienotajiem
Oraclei8i specifiskajiem stereotipiem. Projektēšanas fāzē starp sandarta un loģisko
projektējumu vispārīgie stereotipi tiek aizstāti ar produktam specifiskajiem stereotipiem.
39
`
Tālāk jau iplementācijas fāzē tiek ģenerēts fiziskais modelis veicot iegūtā modeļa elementu
transformācijas. Zemāk redzamajā tabulā/attēlā redzams, kādi elementi UML diagrammā
atbilst SQL:1999 un Oracle8i standartiem.
3.9. tabula
UML Dagrammas, SQL:1999 un Oracle8i salīdzinājums
UML SQL:1999 Oracle8iKlase Strukturētais tips Objekta tips Klases papildinājums Tipu tabula Tabula no objekta tipaAtribūts Atribūts Atribūts Daudzvēŗtību Masīvs Mainīga garuma masīvs/iekļautā
tabula Pamata Rinda/Strukturēta tipa kolonna Kolonna ar objekta tipu Aprēķinātais Trigeris/Metode Trigeris/MetodeAsociācija Viens pret vienu Atsauce/[Atsauce] Atsauce/[Atsauce] Viens pret daudziem [Atsauce]/[Masīvs] [Atsauce]/[Iekļauta tabula/Mainīga
garuma masīvs] Daudzi pret daudziem Masīvs/Masīvs Iekļauta tabula/iekļauta tabula
Mainīga garuma masīvs/Mainīga garuma masīvs
Agregācija Masīvs Iekļauta tabula/ Mainīga garuma atsauču masīvs
Kompozīcija Masīvs Iekļauta tabula/ Mainīga garuma objektu masīvs
Vispārināšana Tipi/Tipu tabulas Koncepts netiek atbalstīts
3.3. Objektu relāciju datu bāzes projektēšanas automatizācijaRelāciju – objektu datu glabāšanas struktūru veido divas sastāvdaļas:
1) lietotāju definēto tipu objekti;
2) relāciju datu bāzes tabulu karkass.
Lietojot kā datu semantisko modeli UML klašu diagrammu, var definēt datu, datu
grupējumu un saišu īpašības, no kurām var iegūt objektu, objektu kolekciju un to savstarpējo
saišu struktūru. Bet tas vēl nav datu bāzes loģiskais modelis. Vēl šie objekti ir jāizvieto pa
tabulu kolonām un jānodrošina to sasaistes iespējas. Pilnvērtīgas informācijas, lai iegūtu
tabulu struktūru nav. Jo var būt nepieciešamība veidot saliktus objektus, un tos izvietot tabulu
kolonās. Lai veidotu vienkāršotu tabulu struktūru, var pielāgot relāciju datu bāzes tabulu
sasaistes likumus un mantošanas transformēšanai no semantiskā modeļa nodefinēt papildus
universālus likumus.
40
`
M. F. Golobiski un A. Vecehietti (M. F. Golobisky, A. Vecehietti) savā darbā [3]
ierosina relāciju – objektu datu bāzes projektēšanai izmantot 3 datu attēlošanas slāņus:
1) UML klases diagrammas slānis, kas atbilst projektējamās sistēmas datu konceptuālajam
modelim. Tas sastāv no klasēm, asociācijām, atribūtiem. Tiek nodrošinātas dažādu veidu
asociācijas starp objektiem: agregācija, kompozīcija, hierarhija, asociācijas klases.
2) objektu – saišu slānis (object – relational layer), kas ir izveidots no standarta SQL: 2003
definētajiem elementiem: Objektu relāciju slānis sastāv no elementiem, kurus raksturo
SQL:2003 standarts. Tie ir lietotāja definētie tipi, strukturētie tipi, atsauces, rindu tipi un
kolekcijas (masīvi un kopas). Tās nav datu glabāšanas struktūras.
3) objektu – relāciju datu glabāšanas slānis (object – relational persistent layer). Tiek
atrisināts jautājums, kādā veidā objektus glabāt, kādās tabulās, kādās kolonās.
Objektu - relāciju datu glabāšanas slānis sastāv no vienkāršām tabulām un tabulām ar objekta
tipa kolonām, kuras veidotas no objektiem, kuri definēti iepriekšējā slānī. Tiek iekļauti arī
relāciju elementi – ierobežojumi, domēni un citi. Kā redzams attēlā, tad lai UML diagrammu
transformētu relāciju tabulu shēmā ir nepieciešams viens solis. Lai transformētu UML
diagrammu objektu relāciju datu bāzes loģiskajā modelī, jau ir nepieciešami divi soļi.
3.25. att. Attēlošanas slāņi
Lai iegūtu pilnīgāku datu modeļa attēlojumu, tiek izmantos UML klašu diagrammas
metamodelis, jo ar tā palīdzību var attēlot struktūras, saites starp struktūrām un datu
41
`
semantiku. Klases grupē objektus, kuriem ir vienāda specifikācija, ierobežojumi un
semantika. Tām ir atribūti un operācijas. Asociācijas specificē semantiskās attiecības starp
klases instancēm. Tām ir divas izejas(association ends), kuras sauc par asociāciju izejām.
SQL:2003 datu tipu metamodelis pamatā sastāv no trīs dažāda tipa shēmas objektiem:
ierobežojumiem, domēniem un tabulām.Tabulas ierobežojumi iekļauj gan primārās atslēgas,
unikālās atslēgas un ārējās atslēgas. Tabulas var būt gan pamata tabulas, gan arī tabulas,
kuras tiek veidotas kā skatījumi.
UML diagramma sastāv no dažādiem objektiem: klases (C), atribūti (A) ,
operācijas(O), saites®. Saites savukārt var būt gan agregācijas(Agg), gan kompozīcijas(Cm),
binārās asociācijas(BAS), asociāciju klases(AC) un generalization-specialization(GS).
Klase: balstoties uz UML metamodeli, klasi ir izeikta kā C=(name,
isAbstract,properties,operations,superclass), kur isAbstract nozīmē, vai klases objekts var tikt
izveidots. Superklase norāda, no kuras klases tiek mantoti atribūti un operācijas. Operācijas
apzīmē, kādas metodes klase var izpildīt. Īpašības raksturo klases atribūtus. Atribūti var būt
vienkārši (vienas vērtības) un kompleksi (vairāku vērtību atribūti). Vienkāršajiem atribūtiem
kārta ir 1, vairāku vērtību atribūtiem kārta var būt no 1 līdz n.
Līdz ar to atribūts var tikt izteikts kā: A=(name,atributeType,multiplicity), kur
nosaukums ir atribūta nosaukums, atributeType ir pēc noklusējuma definētais datu tips un
multiplicity raksturo kārtu, jeb atribūtu skaitu kopā.
Klases tiek savienotas ar asociāciju izejām divos dažādos veidos. Tās definē klasi,
kura piedalās asociācijā un arī attiecas uz klases pseidoatribūtu.
Agregācijas saite ir binārā saite, kas raksturo pilns-daļējs tipa sait un tiek definēta kā
Agg=(name,AEs), kur name ir piešķirtais agregācijas nosaukums un AEs ir asociāciju izejas.
Agregācijā daļa var piederēt vairākiem veselajiem un var eksistēt neatkarīgi, atšķirībā no
kompozīcijas, kura ir stingrāka pilns-daļējs saite. Agregācijai arī nevar būt cikli un objekts
nevar tieši vai netieši būt daļa no paša.
Kompozīcijas saite – arī ir asociācija, kura raksturo daļējs-pilns tipa saiti, bet tā ir
stingrāka nekā agregācija, jo daļa nevar eksistēt neatkarīgi no veselā. Arī pamatā datu plūsma
ir vienā virzienā – no pilnā uz daļēju. To var izteikt kā Cm=(name,AEs).
Binārās asociācijas saite savieno divas realitātes. Pamatā izmanto -lai sasaistītu
objektus. To izsaka BAs=(name, AEs)Asociāciju klases saitei ir gan asociācijas, gan klases
īpašības.
42
`
3.4. Daudzkriterialitāte relāciju – objektu datu bāzes projektēšanāRelāciju – objektu datu bāzes projektēšanā ir vēl divas lielas problēmas:
1) objektu hierarhijas projektēšana. Var tikt veidoti vienkārši objekti ar saviem
atribūtiem, metodēm un iekļauti tabulu kolonās (kā rindas tipa objekts vai kolonas tipa
objekts). Bieži lietderīgāk ir veidot saliktus objektus, kuri iekļauj citu objektu vai objektu
kolekciju. Iekļauto objektu hierarhijas dziļums pēc vajadzības var būt ļoti dažāds. Gan
paplašinātā ER diagramma, gan UML klašu diagramma nesatur norādes par vēlamo objektu
hierarhijas dziļumu.
2) risinājumu daudzveidība.Datu semantiskā modeļa transformācija relāciju datu
bāzes datu struktūrā ir viennozīmīga. Relāciju objektu datu bāzes gadījumā datu semantiskais
modelis var tikt transformēts daudzās dažādās struktūrās, jo var tikt izmantoti gan salikti
objekti, gan objektu atsauču (references) mehānisms.
Apskatītās problēmas neļauj semantiskajā modelī viennozīmīgi definīnēt datu
aprakstu, kuru izmantojot tiktu iegūta tikai viena atbilstošā datu bāzes datu glabāšanas
struktūra. Nepieciešama risinājuma papildus precizēšanas problēma. Jārisina datu bāzes
struktūras optimizācijas uzdevums.
Struktūras optimizācijas uzdevums ir ļoti populārs. Projektējot mājas, tiltus,
lidmašīnas, visādas mehāniskas un elektroniskas iekārtas, vienmēr jāizvēlas labākā struktūra
no iespējamām. Bet kas ir labākā struktūra? Šis vērtējums ir integrāls, tas sastāv no daudziem
atsevišķiem vienkāršākiem vērtējumiem: cena, izturība, izskats, tehniskie raksturojumi. Arī
datu bāzes struktūras gadījumā tiek lietoti dažādi vērtējumi: ātrdarbība, vaicājumu
definēšanas vienkāršība, izmaiņu un papildinājumu veikšanas vienkāršība, semantikas
izprotamība. Šādus uzdevumus sauc par daudzkriteriālās optimizācijas uzdevumiem.
Matemātiskā to formalizācija ir šāda:
q1(X) optimum X Sq2(X) optimum X S X*r = P. . .qk(X) optimum X S
43
∈
∈
∈
`
Dažiem kritērijiem tiek meklētas maksimālās vērtības, dažiem – minimālās: optimum = min,
max. Lai novērstu mērķu neviendabību, kritēriji tiek transformēti, lai visiem būtu vēlams
iegūt vai nu tikai maksimālās, vai tikai minimālās vērtības (turpmāk optimum = max).
q1(X), q2(X), ... , qk(X) ir kvalitātes kritēriju modeļi, kuru vērtības ir atkarīgas no maināmo
lielumu X =(x1, x2, ... , xn) vērtībām. Mainīgajiem lielumiem ir pieļaujamo vērtību apgabals S,
kurš tiek definēts ar vienādības un nevienādības tipa ierobežojumiem:
gi(X) 0 (i = 1, ... , m1),
hi(X) 0 (i = 1, ... , m2).
Viena kritērija gadījumā tiek meklēts risinājums (optimums), kuram ir vislielākā kritērija
vērtība (3.10. att.). Ja ir vairāki kvalitātes rādītāji, optimums neeksistē. Ir atsevišķo kritēriju
optimumi (3.10. att.), bet formāla kopējā optimuma (ekstrēma) jēdziena nav.
3.26. att. Vairāku kritēriju optimizācijas problēma
Formālais daudzkriteriālās optimizācijas uzdevuma risinājums ir Pareto kopa P, kuru veido
risinājumi, par kuriem formāli labākus risinājumu iegūt nav iespējams.
Risinājums X1 ir labāks par risinājumu X2, ja visas X1 kritēriju vērtības
q i(X1 )≥qi(X 2)( i=1 , .. . , k )un eksistē tāds kritērijs q j (X ) j∈1 ,. .. , k , kuram qj(X1) > qj(X2):
∀ i∈1 ,. .. , k [ qi(X 1)≥qi (X2 )] un
∃ i∈ 1 ,. . ., k [ qi (X1 )>g i(X2 ) ]
Izmantojot šo definējumu, pieļaujamos risinājumus var sadalīt divās kopās:
1) risinājumi, par kuriem ir kāds formāli labāks risinājums;
2) risinājumi, par kuriem nav formāli labāku risinājumu. Šie risinājumi veido Pareto kopu P.
44
¿
¿
`
3.11. att. parādīta kritēriju telpa uzdevumam, kuram ir divi kvalitātes rādītāji q1(X) un q2(X).
Labākais (optimālais) risinājums pēc pirmā kritērija ir X1max, pēc otrā kritērija – X2max . Ω ir
pieļaujamo risinājumu kopa. Risinājums X2 ir labāks kā risinājums X1, jo abu kritēriju
vērtības X2 ir labākas (lielākas). Salīdzinot risinājumus X3 un X2, varam secināt, ka X3 ir
labāks risinājums, jo otrā kritērija vērtība tam ir labāka, bet pirmā kritērija vērtības abiem
risinājumiem ir vienādas.
Analizējot pieļaujamo risinājumu kopas Ω robežu starp risinājumiem X1max un X2max redzam,
ka tā iekļauj risinājumus, par kuriem formāli labāku nav. Tātad tie ir Pareto risinājumi.
Risinot konkrētu uzdevumu, protams, ir jāiegūst viens labākais risinājums X**. Lai to
realizētu nepieciešams Pareto risinājumu kopā noteikt variantu, kurš visvairāk apmierinātu
pētnieka prasības. Atsevišķos gadījumos var pielietot leksikogrāfisko optimizāciju - kritērijus
var sakārtot prioritāšu rindā: vissvarīgākais un nākošie pēc nozīmības. Ja šāds variants nav
iespējams, jāveic kompromisu analīze: par cik var pasliktināt viena kritērija vērtību iegūstot
zināmu uzlabojumu par citu kritēriju.
3.27. att. Daudzkriteriālās optimizācijas kritēriju telpas piemērs.
Daudzkriteriālās optimizācijas uzdevumu risināšanai tiek izmantotas dažādas pieejas:
1) tiek izmantoti vērtējumu (kritēriju) prioritāšu sistēma (ja tā ir zināma). Šo pieeju
sauc par aprioro pieeju, vajadzīgā informācija risinājumu salīdzināšanai ir zināma,
tā ir jāizmanto. Šāda situācija reālajā dzīvē ir ļoti reti.
2) lai noskaidrotu kritēriju prioritāšu sistēmu, tiek veikti eksperimenti un savākta
papildus informācija. Mātemātisku un loģisku aprēķinu veidā tiek notekti kritēriju
proritāšu rādītāji, lai salīdzinātu potenciālos risinājumus un iegūtu labāko.
Diemžēl arī šo pieeju ir grūti izmantot, jo kritēriju proritāšu sistēma nav konstanta,
bet atkarīga no kritēriju vērtību savstarpējām attiecībām. Ir jāveis ļoti daudz
45
`
eksperimentu, lai iegūtu dināmisku prioritāšu sistēmu visam potenciālo risinājumu
kopas apgabalam.
3) adaptīvā, iteratīvā jeb dialoga izmantošanas pieeja. Izvēlas vienu sākotnējo Pareto
kopas risinājumu X0 (risinājums var arī nepiederēt Pareto kopai). Noskaidro
projektētāja vēlmes I1 par kritēriju vērtību uzlabošanu (arī par pieļaujamiem dažu
kritēriju pasliktinājumiem). Tiek sameklēts atbilstošais Pareto kopas risinājums.
Iterāciju process tiek turpināts, līdz projektētājs ir pārliecinājies, ka labāku
(subjektīvi) risinājumu Pareto kopā nevar iegūt:
I1 I2
q1(X0), q2(X0), .... , qk(X0) q1(X1), q2(X1), .... , qk(X1)
I3 Ir
q1(X2), q2(X2), .... , qk(X2) ... q1(X**), q2(X**), .... , qk(X**); X** - labākais
risinājums.
Kvalitatīvu labāko risinājumu iegūšanu var nodrošināt tikai adaptīvā pieeja. Projektētājs savu
vēlmju virzienā pārskata Pareto risinājumus, precizē arī savu priekšstatu par Pareto kopu.
Viņam veidojas kritēriju vērtību kompromisa modelis. Meklējot labāko risinājumu (the most
preferable solution), tiek risināti trīs uzdevumi:
1) Pareto kopas risinājumu iegūšana;
2) kompromisa iespēju noskaidrošana;
3) subjektīvā faktora ietekmes samazināšana.
Pareto kopas pārskatīšana var tikt realizēta dažādos variantos. Visbiežāk izmanto
parametrizēto globālo kritēriju W(X):
W(X) = F (λ1q1(X), λ2q2(X), .... , λkqk(X)) optim X* pieder P
Tiek izmantoti projektētāja kritēriju prioritāšu svara (nozīmības) koeficienti λ1, λ2, ... , λk un
"svērto" kritēriju vērtību agregāta veidošanas funkcija F. Veicot parametrizētā globālā
kritērija izteiksmes skalāru optimizāciju, iegūstam vajadzīgo risinājumu Pareto kopā.
Relāciju – objektu datu bāzes struktūras izvērtēšanai ir izstrādāti daudzi kritēriji, kuri raksturo
dažādas datu bāzes struktūras īpašības.
46
`
4. TRANSFORMĀCIJAS NO KONCEPTUĀLĀ MODEĻA UZ
RELĀCIJU-OBJEKTU FIZISKO MODELI
4.1. Transformāciju veidiNo relāciju datu bāzes tiek pārņemtas saites viens pret vienu, viens pret daudziem un
daudzi pret daudziem. Savukārt objektu tehnoloģijām raksturīgās saites ir mantošana,
agregācija, kompozīcija un asociācija. Saite viens pret vienu ietver divu dažādu objektu
sasaisti tādā veidā, ka katram no objektiem var būt viens un tikai viens saistītais objekts.
Konceptuālajā modelī šī saite tiek attēlota ar diviem savstarpēji sasaistītiem objektiem, starp
kuriem eksistē sasaiste viens pret vienu. Piemēram, ir divi objekti – objekts a un objekts b, un
tie ir sasaistīti ar saiti viens pret vienu.
att. 4.1. Konceptuālais modelis - saite viens pret vienu
Ir iespējami vairāki veidi, kā relāciju - objektu datu bāzē saglabāt šo sasaisti starp
objektiem. Kā viens no variantiem – ir izveidot vienu tabulu un tajā saglabāt abus saistītos
objektus vienā rindā. Šādā veidā viens objekts iekļauj otru objektu sevī kā atribūtu un
kopumā tiek izveidota viens rindas tipa objekts datu bāzē. Ir iespējams, šo te pašu struktūru
saglabāt tabulā – katram no objektiem paredzot savu kolonnu, bet šādā gadījumā netiek
veidots rindas tipa objekts tabulā un līdz ar to tiek sarežģīta saišu veidošana izmantojot
atsauces. Atsauces uz objektiem iespējams izmantot tikai tad, ja tabulās ir rindas tipa objekti.
4.28. att. Saites viens pret vienu glabāšana vienā tabulā
Ir iespējams arī šo pašu situāciju saglabāt divās tabulās. Vienā tabulā ir objekts un
atsauce uz otras tabulu, kurā glabājas saistītais objekts.
4.29. att. Saites viens pret vienu glabāšana divās tabulās
47
`
Izmantojot divas tabulas, šos pašus objektus var saglabāt arī iekļaujot atsauci objektā,
kurš ir saistīts ar otru objektu.
4.30. att. Saites viens pret vienu glabāšana divās tabulās
Saite viens pret daudziem datu bāzes projektēšanā ir visbiežāk sastopamā saite. Šī
saite nozīmē to, ka vienam objektam var būt piesaistīti vairāki cita objekta eksemplāri.
Piemēram – attiecība starp skolu un skolēniem attēlo saiti viens pret daudziem. Skola ir
viena, bet tajā mācās daudzi skolēni. Savukārt skolēns mācās tikai vienā skolā vienā un tajā
pašā laika momentā. Vienīgā atšķirībā attēlojumā konceptuālajā modelī ir saites kārtas
norādīšana pie objekta, kura vairākas versijas var tikt piesaistītas vienam objektam. Vizuāli
saite tiek attēlota sekojoši – objektam „a” ir piesaistīti vairāki objekti „b”
4.31. att. Konceptuālais modelis - saite viens pret daudziem
Relāciju datu bāzē šai sasaistei eksistē tikai viena realizācija – divas tabulas un
sasaiste starp tām. Viena no tām ir kā pamata tabula, kuras vienam ierakstam saistītajā tabulā
ir pakārtoti vairāki citi ieraksti, kuri ir sasaistīti izmantojot identifikatorus. Relāciju objektu
datu bāzē šai saitei eksistē vairākas realizācijas. Ir iespēja visus saistītos objektus saglabāt
vienā tabulā izmantojot relāciju - objektu datu bāzes iekļautās tabulas konstrukciju. Tāpat ir
arī iespējams šo pašu saiti datu bāzē realizēt kā divas sasaistītas tabulas izmantojot objektu
atsauces. Bet arī izmantojot divas tabulas, ir iespējams divas realizācijas. Viena no tām ir
tabula, kur viena rinda ir viens objekts un atsauce uz saistīto ierakstu, kā arī rinda, kurā ir
atsauce uz saistīto objektu un objektu kolekcija. Ja tiek izvēlēta vienas tabulas glabāšanas
struktūra, tad tabula sastāv vismaz no divām kolonnām. Vienā kolonnā ir objekts, kurš saitē
piedalās kā vienīgais eksemplārs un otrā tabulas kolonnā ir relāciju - objektu datu bāzes īpaša
glabāšanas struktūra, kura nodrošina kolekciju veidošanu. Līdz ar to – vienas tabulas vienā
rindā ir iespējams saglabāt visus sasaistē iesaistītos objektus. Datu bāzes struktūras attēlojums
redzams attēlā (4.5. att.)
48
`
4.32. att. Saite viens pret daudziem - viena tabula
Šo pašu objektu sasaisti ir iespējams arī saglabāt divās tabulās. Izmantojot šādu
risinājumu, vienā tabulā tiek saglabāts objekts, kurš sasaistē ir kā viens eksemplārs un otrā
tabulā tiek glabāta atsauce uz pirmās tabulas objektu, kā arī tiek saglabāti visi objekti, kuri
sasaistē ir ar kārtu N. Saistītos objektus ir iespējams saglabāt divos veidos. Viena no
realizācijām ir līdzīga kā apskatītajā vienas tabulas variantā – arī tiek izmantota iekļautā
tabula. Saistītajā tabulā ir viena rinda, kur vienā kolonnā tiek saglabāta atsauce uz galvenās
tabulas objektu, bet otrā kolonnā ir objektu kolekcija. Katrā izmantotajā tabulā ir tikai viena
rinda.
4.33. att. Saite viens pret daudziem - divas tabulas un iekļautā tabula
Ir iespējams šo pašu sasaisti saglabāt arī neizmantojot iekļautās tabulas un objektu
kolekcijas. Izmantojot šādu realizāciju, saistītās tabulas rindu skaits ir vienāds ar saistīto
objektu skaitu, katrā rindā glabājas viens saistītais objekts un atsauce uz galvenās tabulas
objektu.
4.34. att. Saite viens pret daudziem - divas tabulas un objektu rindas
49
`
Saite daudzi pret daudziem ir nedaudz retāk sastopama saite. Tas nozīmē, ka kādam
no kopas „a” objektiem atbilst vairāki „b” kopas objekti un arī “b” kopas objektam var atbilst
vairāki kopas “a” objekti. Saites daudzi pret daudziem attēlojums:
4.35. att. Konceptuālais modelis - saite viens pret daudziem
Relāciju datu bāzē šāda sasaiste tiek realizēta izmantojot saišu starptabulu, kurās ir
norādes uz saistīto tabulu rindām. Arī relāciju - objektu datu bāzē ir iespējama šāda pieeja –
tiek izveidota starptabula, kurā glabājas objektu atsauces.
4.36. att. Saite daudzi pret daudziem - atsauču starptabula
No objektu tehnoloģijām tiks izmantota agregācija, kompozīcija un mantošana starp
objektiem. Par agregāciju sauc objektu kopumu, kad viens objekts ir kā vesels un pārējie
objekti ir daļas. Šajā gadījumā objekts sastāv no vairākām daļām vai tam pieder vairākas
daļas, bet katra no daļām var eksistēt atsevišķi, kā arī objekts var eksistēt atsevišķi.
Piemēram, asociācija starp departamentu un strādnieku ir uzskatāma par agregāciju, jo
departamentā strādā darbinieki, bet darbinieku neesamība departamentā nenozīmē, ka
departamenta nav. Tāpat arī, ja nav departamenta, tad tas nenozīmē, ka nav arī strādnieku.
Tie vairs nav saistīti ar departamentu un var strādāt citās struktūrās. Tātad – darbinieks un
departaments ir vājā „pilns-daļa” saite, kas nozīmē, ka pilnais var eksistēt bez daļas, kā arī
daļa var eksistēt bez pilnā, bet pilnais un daļa kopā veido vienu veselumu. Vizuāli agregācija
tiek attēlota kā objekti (realitātes) un saite starp šiem objektiem.
4.37. att. Agregācijas saite
50
`
Tā kā objekti savā starpā nav cieši saistīti, tad datu bāzē tiek izmantotas jau
aprakstītās saišu glabāšanas struktūras. Tās ir saite viens pret vienu, viens pret daudziem un
daudzi pret daudziem. Atšķirība no iepriekš apskatītajām saitēm ir tāda, ka netiek izmantoti
risinājumi, kuros objekti tiek glabāti atsevišķās tabulās, lai nodrošinātu objektu neatkarību un
būtu iespējams dzēst vai mainīt jebkuru no iesaistītajiem objektiem neietekmējot saistītos
objektus.
Situāciju, kad sasaite „pilns-daļa” ir stingra – daļa nevar eksistēt bez veselā, kā arī
veselais nevar eksistēt bez daļas, sauc par kompozīciju. Piemēram, asociācija starp
departamentu un universitāti ir uzskatāma par kompozīciju, jo departaments un universitāte ir
cieši saistīta. Ja universitātē nav neviena departamenta, tad to vairs nevar saukt par
universitāti, kā arī – departaments nevar eksistēt bez universitātes. Tas nozīmē, ka sasaiste ir
cieša un objekti ir stingri saistīti. Objekti, kuri asociācijā ir kā „daļa” eksistē tik ilgi, kamēr
eksistē arī saistītais „pilnais” objekts. Attēlojums ir līdzīgs kā agregācijai, vienīgā atšķirība ir
tā, ka uz saites esošais četrstūris tiek iekrāsots.
4.38. att. Kompozīcijas saite
Kompozīcijas realizācija gan atšķiras no agregācijas realizācijas, jo ir nepieciešams
nodrošināt objektu atkarību vienam no otra. Dzēšot objektu, kurš ir kompozīcija, ir
jānodrošina arī visu saistīto objektu dzēšanu no datu bāzes. Līdz ar to, kā glabāšanas
struktūras var tikt izmantotas iekļautās tabulas, objekta saglabāšana tipā vai arī tabula katram
objektam atsevišķi, bet tādā gadījumā ir arī jāizveido mehānisms, kā saistītos objektus dzēst.
Vienkāršākā iespēja saglabāt kompozīcijas tipa asociāciju datu bāzē ir objektu saglabāt
atsevišķā kolonnā. Tādējādi kompozīcijas objekta rinda datu bāzē ietver arī saistītos objektus
un, dzēšot datu rindu, automātiski arī tiek dzēsti visi kompozīcijas objekti. Šāda veida
realizācija gan ir iespējama tikai tad, ja sasaiste starp objektiem ir viens pret vienu.
4.39. att. Kompozīcija - saite viens pret vienu
Līdzīgā veidā ir iespējams saglabāt ari situāciju, kad starp saistītajiem objektiem ir
sasaiste viens pret daudziem. Tādā gadījumā tabulā ir jāveido iekļautā tabula, kurā tiek
51
`
saglabāti visi saistītie objekti. Arī šādā realizācijā, dzēšot vienu datu rindu, tiek dzēsti arī visi
kompozīcijas objekti un tiek nodrošināta objektu dzīvotspēja tikai visiem kopā.
4.40. att. Kompozīcija - saite viens pret daudziem
Nozīmīga objektu pieejas īpašība ir mantošanas iespēja un tās izmantošana. Par
mantošanu sauc situāciju, kad viens objekts pārmanto cita objekta īpašības tādējādi veidojot
jaunu objektu. Jaunais objekts satur visas mantotās īpašības, kā arī ir iespēja definēt tikai
jaunajam objektam raksturīgās īpašības. Piemēram, ja par pamatu ņem cilvēku, tad tam ir
iespējams definēt vārdu, uzvārdu kā arī citus atribūtus un metodes, kuras raksturo cilvēku un
tā uzvedību. Bet ir iespējams izveidot jaunus objektus – students un darbinieks. Abi jaunie
objekti manto atribūtus un metodes no cilvēka objekta, bet gan objektam students, gan
objektam darbinieks, ir iespēja definēt specifiskus nepieciešamos parametrus, lai aprakstītu
studenta un darbinieka atšķirīgās uzvedības. Studentu raksturojošs atribūts ir studenta
apliecības numurs, bet darbiniekam šāds atribūts varētu būt amats. Vizuāli to varētu attēlot
sekojoši:
4.41. att. Mantošanas saite
Ir vairāki iespējamie varianti, kā mantošana un mantošanas asociācija starp objektiem var
tikt realizēta relāciju datu bāzē. Kā viena no iespējām, ir visus objektus glabāt vienā tabulā.
Relāciju objektu datu bāzē ir iespējams definēt tipus un apakštipus. Ja tabulas kolonnai ir
52
`
definēts kāds noteikts tips, tad šajā kolonnā var saglabāt arī visus saistītos tipus. Šādu tabulu,
kurā vienā kolonnā atrodas dažāda veida objekti, sauc par heterogēnu tabulu.
4.42. att. Tabula ar heterogēniem objektiem
Vēl ir iespēja katram tipam veidot savu tabulu un katrā tabulā glabāt tikai konkrētā
tipa objektus un pēc tam saistītajā pamata tabulā izveidot atsauces uz atsevišķajām tabulām.
Šeit jāņem vērā tas, ka atsauces jādefinē atbilstoši visiem mantošanā iesaistītajiem objektiem.
Vienu atsauci izmantot nav iespējams, jo nav zināms, kura tipa objekts tiks piesaistīts, tāpēc
ir galvenajam objektam ir jādefinē visas veida atsauces.
4.43. att. Tabula katram objekta tipam
Kā trešā iespēja ir apvienot dažus no tipiem un tādējādi iegūstot mazāku tabulu skaitu.
Realizācija ir līdzīga, kāda tā bija veidojot heterogēnu tabulu un saglabājot tajā visus
mantošanas koka objektus, bet atšķirība ir tā, ka daži no tipiem tiek glabāti atsevišķi un daži
no tipiem tiek grupēti pēc kādam no iezīmēm vai lietošanas nepieciešamības. Zemāk
redzamajā attēlā ir izveidota tabula, kurā sagrupēti tipi ar diviem un trīs atribūtiem, savukārt
četru atribūtu objektam ir pašam sava tabula.
4.44. att. Tabula ar apvienotiem tipiem
Kā redzams apskatītajos piemēros, tad ir vairāku veidu realizācijas, kā saglabāt
mantošanas asociāciju relāciju - objektu datu bāzē. Iespējamo kombināciju skaits palielinās
līdz ar iesaistīto objektu skaitu un automātiski nav iespējams noteikt, kura no realizācijām ir
nepieciešama katrā no gadījumiem.
53
`
5. RELĀCIJU-OBJEKTU DATU BĀZES PROJEKTĒŠANAS RĪKI
5.1. MIGROX integrētais karkassMetodes nosaukums MIGROX[1] nozīmē – „Migrēšana no Relāciju dabu bāzes uz
Objektu bāzētām un XML datu bāzēm”, no angļu valodas ( MIGrating an RDB into Object-
based and Xml databases). MIGROX sastāv no trīs fāzēm: semantiskās bagātināšanas,
shēmas translācijas un datu pārveidošanas. Pirmajā fāzē tiek izveidots CDM(kanoniskais datu
modelis), kuru pēc tam papildina ar Relāciju Datu bāzes datu semantiku. Tālāk iegūtais
CDM tiek izmantots otrajā fāzē. Trešā fāze pārvērš Relāciju Datu bāzes datus jaunās datu
bāzes vides ekvivalentos.
Semantiskā papildināšanas fāzē no Relāciju dabu bāzes modeļa tiek iegūts RSR un no
iegūtā RSR tiek ģenerēts CDM. Lai izveidotu RSR, ir nepieciešams iekļaut relāciju
nosaukumus un atribūtu īpašības (nosaukumi, tipi , izmērs). Liela nozīme ir arī saišu
definēšanai. Tiek izmantotas unikālās atslēgas, primārās atslēgas, ārējās atslēgas un arī
eksportētās atslēgas – ārējo atslēgu inversās versijas. Eksportētās atslēgas ir svarīgas, lai
atbalstītu divvirzienu saites starp objektiem. Relāciju datu bāzes shēma tiek attēlota kā
elementu kopa : RSR:=R|R:=[rn,Arsr,PK,FK,EK,UK]. CDM sastāv no trīs konceptiem:
klase, atribūts un saites starp objektiem. CDM tiek attēlota kā klašu kopa : CDM:=C|C:=[cn,
cls, abs , Acdm,Rel,UK], kur cn ir klases nosaukums, cls ir klasifikācija, abs – pazīme vai
klase ir abstrakta, Acdm ir klases atribūtu kopa, Saišu kopa un unikālo atslēgu kopa.
Otrajā fāzē iegūtais CDM tiek transformēts mērķa shēmās (pieeja ļauj izveidot gan
objektu bāzētas, gan XML datu bāzes. Autori ir izveidojuši likumu kopu, kā CDM modeli ir
iespējams transformēt izvēlētajā datu bāzes modelī. Relāciju objektu datu bāzes shēmas
definīcija: ORSchema:=UT,TT,UKor, kur UT ir lietotāja definēto tipu (UTD) kopa, TT ir
tipu tabulu kopa un UKor ir unikālo atslēgu kopa.
Trešā noslēdzošā fāze ir datu konvertēšana mērķa shēmas ekvivalentos. Fāze no datu
transformācijas, lai to formāts atbilstu nepieciešamajam formātam un transformētie dati tiek
ievietoti failos, lai tos varētu tālāk izmantot.
54
`
Ir veikti arī testi izpildot dažādus vaicājumus, lai salīdzinātu, vai avota un mērķa datu
bāzes sakrīt un dati tajās ir vienādi. Rezultāti ir identiski un tas nozīmē, ka MIGROX metode
ir veikusi korektu datu bāzes struktūras un to datu migrāciju. Tiesa gan – salīdzināti tiek tikai
vaicājumu atgrieztie rezultāti, netiek salīdzināti izpildes ātrumi un netiek vērtēts, vai iegūtā
struktūra ir optimālā un ir izveidota vislabākā iespējamā Relāciju Objektu datu bāzes
struktūra. Tāpat nav arī minēts, vai šī metode nodrošina objektu metožu veidošanu, kas tomēr
ir ļoti būtiska lieta relāciju datu bāzes struktūrā un izveidoto objektu/tipu lietošanas ērtumā.
5.2. O-ODM relāciju-objektu datu bāzes projektēšanas karkassKā vēl viena metode, kā no objektiem lietojumos tiek iegūta relāciju - objektu datu
bāzes shēma, ir O-ODM[12] ( Object-Object Database Mapping) pastāvīgais karkass jeb
ietvars, kurš radīts, lai padarītu izstrādātāju darbu produktīvāku un tiem nebūtu jābūt ar
augstu kompetenci datu bāzes vadības sistēmās. Industrijā ir daudz zināmu ORM (Object
Relational Mapping) pastāvīgo ietvaru, kuri palīdz sasaistīt relāciju datu bāzi un lietojuma
objektus. Populārākie no tiem ir Hibernate[15], EclipseLink[16], kā arī daži ne tik populāri,
piemēram, MyIbatis[17]. Šie ORM pastāvīgie ietvari nodrošina iespēju veikt izmaiņas datu
bāzē strādājot tikai ar lietojumu, tādējādi ļaujot izstrādātājiem koncentrēties tikai uz lietojuma
funkcionalitātes attīstīšanu. Bet, izmantojot ORM pastāvīgos ietvarus, ir iespējams strādāt ar
relāciju datu bāzi. Izmantojot O-ODM tiek piedāvāta iespēja lietojuma objektus sasaistīt ar
relāciju - objektu datu bāzes sistēmu un tās tabulām. Dominējošā tehnoloģija ORM pastāvīgo
ietvaru realizācijās ir programmēšanas valoda JAVA un arī O-ODM ir veidots izmantojot šo
programmēšanas tehnoloģiju. ORM un O-ODM izmanto vienus un tos pašus JDO (Java Data
Object) un JPA (Java Persistence API) – piekļuve datiem tikai no ietvara, darbība ar datiem
notiek objektorientētā valodā, Java klasēm tiek izmantotas anotācijas. Anotācijas palīdz
pievienot informāciju Java klasēm, no kuras vēlāk tiek ģenerēts SQL kods. Autori ir
definējuši sekojošus likumus, kā no objektorientētas tehnoloģijas iegūt relāciju - objektu datu
bāzei atbilstošus objektus, tipus un sasaistes. Tabulā 5.1. attēlots kā objektorientētās
tehnoloģijas objekti tiek pārveidoto relāciju - objektu datu bāzes shēmā.5.10. tabula
Lietojuma objektu - relāciju datu bāzes objektu sasaiste
Objektorientētā tehnoloģija Relāciju objektu datu bāzes vadības sistēmaKlase Tabula
Lietotāja definēts tipsAbstraktā klase Lietotāja definēts tips
55
`
Vienkāršais atribūts Datu bāzē iekļautais datu tipsVairāku vērtību atribūts Masīvs
Iekļautās tabulasObjektu metodes Lietotāja definēto tipu metodes
Tādā pašā veidā tiek arī definēta asociāciju aizvietošana ar relāciju - objektu datu
bāzes piedāvātajām iespējām. Tabulā 5.2. autoru aprakstītie attēlojumi.5.11. tabula
Lietojuma objektu attiecību - relāciju datu bāzes sasaiste
Objektorientētā tehnoloģija Relāciju objektu datu bāzes vadības sistēmaDivvirzienu asociācija Kompozīcija
AsociācijaAgregācija
Vienvirziena asociācija KompozīcijaAsociācijaAgregācija
N-pakāpes asociācija Tabula – ar atsaucēm uz visiem lietotāja definētajiem datu tipiemLietotāja definēts tips– ar atsaucēm uz visiem lietotāja definētajiem datu tipiem
Asociatīvā klase Tabula– ar atsaucēm uz visiem lietotāja definētajiem datu tipiem
Lietotāja definēts tips– ar atsaucēm uz visiem lietotāja definētajiem datu tipiem
Vispārināšana/Specializācija Lietotāja definēts datu tips katrai klasei hierarhijā
O-ODM pastāvīgais ietvars var apstrādāt gan datus, kuri tiek nodoti Java klašu formā,
gan arī datus, kuri ir noformēti XML struktūrā. Java klašu gadījumā tiek izmantotas
anotācijas, lai transformētu aprakstīto struktūru relāciju - objektu datu bāzes struktūrā.
Savukārt XML dokumenta aprakstošā XSD shēma tika papildināta, lai tajā būtu iespējams
definēt objektorientētas struktūras, kuras iekļauj gan mantošanu, gan objektus, gan metodes
un kolekcijas. Izmantojot Java klases – lietojuma objektu translācija sastāv no diviem soļiem.
Pirmajā solī tiek izveidots jau iepriekš minētais XML dokuments un pēc tam otrajā solī no
iegūtā dokumenta tiek ģenerēta relāciju - objektu datu bāzes struktūra.
56
`
6. RELĀCIJU-OBJEKTU DATU BĀZES DATU STRUKTŪRAS
NOVĒRTĒJUMA KRITĒRIJILai izveidotu optimālu relāciju - objektu datu bāzes struktūru, nepieciešams
veidojamo struktūru novērtēt – šos novērtējumus sauc par metrikām. Tāpat, izmantojot
metrikas, ir iespējams prognozēt nepieciešamos resursus sistēmas uzturēšanai, kā arī dod
iespēju uzlabot sistēmas kvalitāti un pazemināt sarežģītību iegūstamajai relāciju - objektu
datu bāzes shēmai. Zemāka sistēmas, jeb datu bāzes shēmas sarežģītība, arī ļauj turpmāk
vieglāk veikt dažādas izmaiņas sistēmā, tādējādi ietaupot gan cilvēkresursus, gan laiku, gan
naudu, kā arī ir zemāki riski neiekļauties termiņos vai nespēt realizēt nepieciešamās prasības.
Lai metriku iegūtos rezultātus varētu vieglāk apstrādāt, novērtēšanas algoritmi parastie tiek
standartizēti un formalizēti, lai mērījuma rezultātus iegūtu viegli salīdzināmus rezultātus.
Dažādi autori ir apskatījuši dažāda veida metrikas[4,6,7,8,9], lai novērtētu relāciju - objektu
datu bāzes struktūru. Līdzīgi novērtētas tiek arī struktūras objektorientētajās sistēmās.
6.1. Objektorientētās struktūras novērtējuma metrikasJebkuras sarežģītas sistēmas pamatā ir projektēšanas process, bet lai uzlabotu
projektēšanas rezultātu, arī objektorientētās struktūras tiek mērītas ar dažāda veida metrikām.
Iegūtie mērījumi palīdz saprast pētāmo modeli un tā sarežģītību, kā arī noteikt, kuras modeļa
īpašības nepieciešams pamainīt, lai iegūtu vienkāršāku, vieglāk uzturamu un saprotamu
struktūru. Lai novērtētu objektorientētas sistēmas modeli, tiek izmantotas metrikas, kuras
attiecina uz: klasi, sasaisti, kohēziju , iekapsulēšanu, mantošanu, polimorfismu un atkārtotu
izmantošanu [8].
Klases metrikas – mēra sistēmā izmantotos atribūtus un metodes, kā arī klases
sarežģītību:
Atribūtu skaits klasē (Number of Attributes per Class (NOA)) – attēlo kopējo
atribūtu skaitu, kurš definēts klasē.
Klases metožu skaits (Number of Methods per Class(NOM)) – šī metrika mēra
kopējo metožu skaitu, kuras ir definētas klasē.
Svērtās klašu metodes Weighted Methods per Class (WMC) – ir visu klases
metožu sarežģītību summa. Lai šo metriku pielietotu, ir jānormalizē visas
metodes tā, lai vienkāršākā no tām būtu ar koeficientu 1. Attiecīgi
57
`
sarežģītākām metodēm koeficients būs lielāks un koeficientu summa būs
klases visu metožu sarežģītības skaitliskā vērtība.
Klases atbilžu skaits (Response For a Class (RFC)) – tiek uzskaitītas visas
metodes, kuras var tikt izsauktas, ja izsauc kādu no klases metodēm. Svarīgi
pieminēt, ka šeit tiek pieskaitītas klāt arī saistīto objektu metodes. Piemēram,
ja ir Objekts Grāmata, un objektam ir divas metodes: iegūtAutorus un
iegūtPārdevējus, kuras savukārt izsauc metodes no objektiem Autori un
Pārdevēji, tad Objekta Grāmata atbilžu skaits ir summa no visu objektu
metodēm.
Atkārtošanās metrikas – Objektorientētā sistēmā atkārtošanās palielina sistēmas
sarežģītību samazina iekapsulēšanu, iespējamu funkcionalitātes atkārtotu izmantošanu
kā arī palielina sistēmas sarežģītību un padara to grūtāk uzturamu.
Objektu īpašību atkārtošanās (Coupling Between Objects (CBO)) – starp
diviem objektiem atkārtošanās tiek identificēta tad, ja viena objekts izmanto
cita objekta atribūtus vai metodes.
Datu abstrakcijas atkārtošanās (Data Abstraction Coupling (DAC)) – šī
metrika mēra lietotāja definētos datu tipus – sauktus arī par abstraktajiem datu
tipiem, un to atkārtošanos objektos.
Ziņojumu atkārtošanās ( Message Passing Coupling (MPC)) – autori šo
metriku ir definējuši kā „ziņojumu skaitu, kurš tiek nosūtīts”. Piemēram, ja
objektam A ir divas metodes, kuras izsauc vien uun to pašu objekta B metodi,
tad tā ir ziņojumu atkārtošanās.
Atkārtošanās indekss (Coupling Factor (FC)) –tiek mērītas visas iepriekš
minētās atkārtošanās. Šim indeksam ir jābūt pēc iespējas mazākam –
objektorientētajā pieejā viens objekts izsauc cita objekta metodes un tiek
nodoti dati starp objektiem, tāpēc indeksa vērtība nekad nebūs vienāda ar 0.
Kohēzijas metrikas –
Kohēzijas trūkums metodēs (Lack of Cohesion in Methods (LCOM)) – mēra
atšķirības starp metodēm un izmantotajiem instances mainīgajiem un metožu
parametriem. Jo zemāka šī vērtība, jo mazāka klases cohesive.
Ciešā klases kohēzija (Tight Class Kohēzija(TCC)) – definēta kā procentuālā attiecība
starp klases publisko metožu pāriem pret kopīgo atribūtu lietojumu metodēs.
58
`
Piemēram ir klase Klients un ir definētas četras metodes:
pievienot_klientu(klienta_id, vards,uzvards,adrese)
dzest_klientu(klienta_id)
meklēt_pēc_vārda(vards)
meklēt_pēc_uzvārda(uzvārds)
Šai gadījumā kopā ir 6 metožu pāri un 3 gadījumi, kad tiek koplietoti metodes
atribūti. Metode – pievienot_klientu koplieto atribūtus ar visām pārējām metodēm.
TCC tiek iegūts sekojoši 3/6*100= 50
Nenoteiktā klases kohēzija (Loose Class Cohesion(LCC)) – līdzīgi kā ciešā klases
kohēzija, bet šeit vērā tiek ņemtas arī metodes un parametri, kuri nav tieši saistīti.
Informācijas plūsmas kohēzija (Information Flow Based Cohesion (IFBC)) – šis
rādītājs parāda , cik klases metodes izsauc viena otru un ir savā starpā saistītas. Ja
klasei A ir metode B un no metodes B tiek izsaukta tās pašas klases A metode C, tad
šeit tiek diagnosticēta informācijas plūsmas kohēzija un ir viena saite starp metodēm.
Mantošanas metrikas – kopā tiek izšķirtas četras dažādas mantošanas metrikas
objektorientētajā struktūrā.
Mantošanas koka dziļums (Depth of inheritance tree ( DIT)) –tiek mērīts soļu skaits,
kurš ir nepieciešams, lai no vecāka mezgla nokļūtu līdz zemākā bērna mezglam, kur
katrs solis ir saite starp diviem blakus esošiem mezgliem(klasēm) mantošanas kokā.
Bērnu skaits (Number of Children (NOC)) – NOC ir skaitlis, kurš raksturo klases
tiešo apakšklašu skaitu klases hierarhijas kokā.
Metožu mantošanas faktors (Method Inheritance Factor (MIF)) un Atribūtu
mantošanas faktors (Attribute Inheritance Factor (AIF)) nosaka klasē definēto
metožu/atribūtu skaita attiecību pret klases mantoto metožu/atribūtu skaitu.
Polimorfisma faktors (Polymorphism Factor (PF)) – raksturo metožu pārklāšanos
mantošanas kokā.
Atkārtotas izmantošanas metrikas – palīdz noteikt un izmērīt, kādā mērā ir iespējams
izmantotos objektus izmantot atkārtoti citām vajadzībām vai citai funkcionalitātei.
Atkārtotā izmantošanas indekss (Reuse Ratio (U))– attiecība starp kopējo superklašu
skaitu un kopējo klašu/objektu skaitu projektā.
Specializācijas indekss (Specialization Ratio (S)) – apakšklašu attiecība pret
superklasēm.
59
`
6.2. Relāciju - objektu datu bāzes struktūras novērtējuma metrikasArī projektējot relāciju - objektu datu bāzi, dažas no struktūras metrikām tiek aizgūtas
no objektorientētajām metrikām. Par metriku ietekmējošiem faktoriem tiek uzskatīti tabulas
izmērs, metožu sarežģītība, kohēzija starp objektiem,objektu sasaiste, mantoto atribūtu skaits,
asociāciju leņķis un dziļums relāciju kokā.
Justus un Iyakutti[4] definēja sekojošas metrikas relāciju - objektu datu bāzei:
Tabulas izmērs (TS – table size): tas attēlo summāro tabulas kolonnu izmēru, ņemot
vērā gan vienkāršās kolonnas, kuras satur pamata datu tipus, gan arī kompleksās
kolonnas, kurās tiek glabāti lietotāja definētie tipi (UDT). Jo lielāka ir šī skaitliskā
vērtība, jo lielākas ir uzturēšanas izmaksas. Skaitliskā vērtība tiek iegūta:
µ ir metrikas funkcija, SC attēlo vienkāršās kolonnas un to skaitu, CC ir kompleksās
kolonnas un to skaits.
Metožu sarežģītība ( Complexity of Weighted Methods - CWM): attēlo visu metožu
sarežģītību summu. To aprēķina:
Ci ir metodes i sarežģītība
Kohēziju starp metodēm (Cohesion between methods): Mēra metožu līdzību un tā tiek
mērīta kā proporcija starp līdzīgiem izmantotajiem atribūtiem metodes un klases pilno
atribūtu skaitu. Augsta līdzība palīdz sagrupēt līdzīgās metodes kopā. Zema līdzība
var radīt negatīvu ietekmi uz uzturēšanas izmaksām un resursiem. To rēķina sekojoši:
I ir parametru skaits klasē un V ir kopējais atribūtu skaits klasē.
Objektu sasaiste (Coupling between Objects(CBO)): šī metrika attēlo divu dažādu
klašu divu metožu atkarību vienai no otras. Jo vērtība zemāka, jo lielāki ir ieguvumi
un mazākas iespējamās uzturēšanas problēmas.
Minvj ir izsaukto metožu skaits un vidējais argumentu skaits katrā izsaukumā.
Saistīto parametru skaits: attēlo, cik parametrus bērns manto no sava vecāka.
To aprēķina sekojoši:
60
`
Kur Mj=[tipu skaits * CWM]+[metožu skaits *]
Asociāciju leņķis (referential degree)(RD): raksturo ārējo un referso atsauču summāro
rezultātu.
Dziļums relāciju kokā ( Depth in Relational Tree) : atspoguļo garāko ceļu starp
diviem objektiem objektu hierarhijas kokā. Tas tiek rēķināts:
, kur d ir attālums starp saistītājām tabulām vai objektiem.
Lai būtu iespēja iepriekš definētās metrikas izmantot, tika piedāvātas sekojošas metrikas
novērtējuma vienības:
Kolonnas sarežģītība (clm), kura tiek izmantota TS (tabulas izmēra) metrikā. Tālāk
jau balstoties uz šo iegūto vērtību ir iespējams spriest, kādas varētu būt uzturēšanas
izmaksas.
Darbības ar parametriem (Number of interactions per variables set ) I/vs tiek
izmantota , lai izteiktu kohēzijas metriku.
Importēto vai eksportēto ziņojumu skaits vienā mijiedarbībā. To izmanto, lai
aprēķinātu sasaisti
„laxity” vienība, kuru izmanto atkārtotās izmantojamības metrikā (NIP). Šī metrika
nosaka, cik liela iespēja ir pielietot jau esošās klases citās klasēs vai tipos.
Autori arī ir izstrādājuši rīku, kurš automātiski šīs visas metrikas spēj iegūt.
61
`
7. VEIDŅA VADĪTA RELĀCIJU-OBJEKTU DATU BĀZES
PROJEKTĒŠANAS AUTOMATIZĀCIJAS PROTOTIPSApskatītajos autoru darbos aprakstītas procedūras, kā iegūt relāciju - objektu datu
bāzes loģisko modeli. Eksperimentos arī tiek pierādīts, ka iegūtais modelis ir atbilstošs
sākotnējam konceptuālajam modelim un visas saites starp objektiem tiek saglabātas. Bet šīm
procedūrām ir viens būtiskstrūkums – tās ir realizētas tā, lai tiktu iegūts viens modeļa
variants. Tāpēc ir iekļauti papildus noteikumi, lai to nodrošinātu. Līdz ar to tiek iegūta viena
datu glabāšanas struktūra no iespējamo struktūru kopas. Vai tā būs labākā? Droši vien nē.
Tāpēc projektētājam jādod iespēja izvērtēt iegūtās struktūras un izvēlēties labāko. Tātad
projektēšana jārealizē kā iteratīva procedūra, lai datu bāzes struktūras projektētājs varētu
atlasīt labāko. Atlasē tiek izmantoti gan subjektīvi, gan objektīvi kritēriji. Dažos gadījumos
lietotājam prioritāri ir salikti objekti, citreiz vienkārši. Ir situācijas, kad nepieciešams saistītos
objektus glabāt pie augšējā līmeņa objekta, bet ir situācijas, kad pareizāka realizācija ir glabāt
tikai atsauces uz objektiem. Tāpat arī – transformācijas 1:N ir iespējams glabāt kā iekļautās
tabulas, gan arī kā savstarpēji sasaistītas tabulas ar objektiem. Automātiski to
viennozīmīginevar novērtēt, jo tas ir atkarīgs no sistēmas specifikas, glabājamajiem datiem
un konkrēto objektu īpašībām. Tāpēc liels ieguvums varētu būt lietotāja iesaistīšana
struktūras transformēšanas procesā veidojot relāciju-objektu datu bāzi.
Apskatītajos piemēros netika apskatīta objektu metožu veidošana. Tiek veidotas tikai
datu glabāšanas struktūras. Arī metožu veidošana transformācijas procesā atvieglotu darbu ar
iegūto relāciju - objektu datu bāzes sistēmu. Strādājot ar relāciju - objektu datu bāzi, kā viena
no neērtībām ir tā, ka objektam pēc noklusējuma tiek izveidota konstruktora metode, kurai
vienmēr ir jānorāda visi parametri, lai izveidotu objektu. Ir gadījumi, kad tas nav
nepieciešams, un dažas parametru vērtības varētu tikt piešķirtas pēc noklusējuma principa.
Jaunu konstruktora metožu definēšana atrisinātu šo neērtību un būtu iespējams definēt
konstruktora metodi tikai ar nepieciešamajiem objekta atribūtiem. Tapāt arī liels ieguvums
būtu arī objekta metožu šablonu definēšana – objekta metodes nosaukums un izmantotie
atribūti. Metožu ķermeņu definēšana gan ērtāka ir izmantojot datu bāzes pārlūkprogrammas.
Veidojot relāciju - objektu datu bāzi no konceptuālā modeļa, reizēm ir nepilnīgi veikta
modeļa veidošana. Objektu atribūtu papildināšana transformācijas procesā ļautu papildināt
62
`
veidojamos objektus ar jauniem atribūtiem – šeit gan jāņem vērā, ka varētu tikt pievienoti
tikai atribūti ar iekļautajiem datu tipiem.
Jaunajā projektēšanas rīkā būs iegūstami relāciju - objektu datu bāzes struktūras
novērtējumi dažās no apskatītājām metrikām. Tas palīdzētu novērtēt, vai kāds no objektiem
nav pārāk sarežģīts un vai nav uzmodelētas pārāk dziļas hierarhijas struktūras starp
objektiem, kas varētu apgrūtināt iegūtās datu bāzes struktūras lietošanu un funkcionalitātes
izstrādi. Balstoties uz visu iepriekš minēto, jaunajam rīkam jānodrošina sekojošas iespējas:
veidot jaunas konstruktora funkcijas tipiem;
dzēst/pievienot jaunus atribūtus;
pievienot jaunas procedūras/funkcijas;
izvēlēties sasaistes veidu – viens pret vienu, viens pret daudziem, daudzi pret
daudziem, mantošana, agregācija, kompozīcija;
attēlo shēmas sarežģītību ņemot vērā dažas no metrikām (mantošanas dziļums,
tabulas izmērs, sarežģītība).
7.1. Konceptuālā modeļa izveideLai varētu veikt kvalitatīvu relāciju - objektu datu bāzes projektēšanu, jānodrošina
iespēja datu bāzē iekļautos objektus attēlot vizuāli. Tādējādi objektus un to saites ir vieglāk
uztvert un izprast, kādas izmaiņas ir veicamas, lai izveidotu vēlamo datu bāzes modeli.
Konceptuālā modeļa veidošanas mehānisms tiek veidots no jauna – netiek izmantoti jau
gatavi risinājumi, līdz ar to ir iespējams projektēšanā iekļautos elementus izvēlēties pēc
nepieciešamības un ieviest tikai tos, kuri ir nepieciešami. Pamata elementi ir aizgūti no
iepriekšējās nodaļās aprakstītās UML modelēšanas valodas. Tie ir klase, atribūti, metodes un
dažāda veida sasaistes starp objektiem. Lai paplašinātu modelēšanas iespējas un ieviestu
jaunu funkcionalitāti, metožu definēšana tiek sadalīta divās daļās. Viena no daļām atbild par
objekta konstruktora metožu veidošanu, otra daļa - par objektiem specifisku metožu
definēšanu, kuras pielietojot tiek manīts objekta stāvoklis. Kā jauna pazīme klasei tiek
pievienota arī iespēja pievienot klases aprakstu, no kura automātiski tiks ģenerēta statiskā
metode, lai datu bāzē izgūtu objekta aprakstu. Tas ir līdzīgi, kā programmēšanas valodā Java,
kad ir iespējams izveidot klases dokumentāciju balstoties uz klases aprakstu – atribūtiem un
metodēm.
63
`
7.2. Lietotāja definētas konstruktora funkcijasObjektorientētajai pieejai galvenā iezīme ir tā, ka ir nepieciešams iniciēt objektu –
izveidot klases eksemplāru, lai pēc tam būtu iespējams ar to strādāt.Eksemplāra izveidošanu
nodrošina konstruktora funkcijas. Tās, veidojot objekta tipu, tiek izveidotas pēc noklusējuma.
Tomēr ir situācijas, kad pēc noklusējuma izveidoto konstruktora metodi nav ērti izmantot –
definēti pārāk daudzi atribūti, kuri pie eksemplāra iniciēšanas nav nepieciešami. Kā viena no
situācijām, kad dažus no atribūtiem nav nepieciešams aizpildīt pie objekta eksemplāra
iniciēšanas, ir objekta atribūti, kuri attēlo objekta pēdējo mainītāju un maiņas datumu
(relāciju datu bāzē bieži šie lauki tiek izmantoti, lai redzētu, kuri lietotāji un kad ir veikuši
izmaiņas datu rindās). Izveidojot objekta tipu, noklusētā konstruktora funkcija tiek izveidota,
izmantojot visus objekta tipa atribūtus. Piemēram, veidojot tipu AUGI_typ un kā atribūtus
norādot nosaukumu, aprakstu, attēlu, izveidošanas datumu un labošanas datumu, vienīgā
iespēja izveidot objekta eksemplāru, ir izsaukt konstruktora funkciju norādot visus iepriekš
minētos atribūtus.create or replace type AUGI_typ as object(
nosaukums varchar2(200 char) ,
apraksts varchar2(200 char) ,
attēls blob ,
created date,
modified date);
insert into AUGI values (AUGI_typ('Alveja','Alveja tiek
izmantota....',null,sysdate,null));
Šajā situācijā, veidojot objekta eksemplāru, tiek norādīts nosaukums, apraksts un
izveidošanas datums. Attēls un ieraksta modificēšanas laiks šajā brīdī vēl nav zināms,
veidojot objektu, tāpat ir jānorāda vērtības. Ja objekts ir komplekss un satur daudz atribūtus,
tas var sagādāt neērtības. Lai šo problēmu atrisinātu, veidojot objekta tipu, var norādīt arī
konstruktora funkciju ar nepieciešamajiem atribūtiem. Konstruktora funkcijas apraksts ir
jāpievieno objekta tipa veidošanas komandai. Kā atribūti tiek norādīti nosaukums un
apraksts. create or replace type AUGI_typ as object(
nosaukums varchar2(200 char) ,
apraksts varchar2(200 char) ,
attēls blob ,
created date,
64
`
modified date,
CONSTRUCTOR FUNCTION AUGI_typ(nosaukums varchar2,apraksts varchar2)
RETURN SELF AS RESULT);
Veidojot konstruktora funkciju, gan jāņem vērā, ka nepieciešams funkciju aprakstīt arī
tipa ķermenī. Svarīgi atzīmēt, ka pēc noklusējuma izveidotā un izmantojamā konstruktora
funkcija nav redzama objekta tipa ķermenī un ir izmantojama, neizveidojot objekta tipa
ķermeni. Kā arī – pēc specifiskas konstruktora funkcijas izveidošanas, tiek saglabāta arī
iespēja izmantot noklusēto konstruktora funkciju. CREATE OR REPLACE
TYPE BODY AUGI_TYP AS
CONSTRUCTOR FUNCTION AUGI_typ(nosaukums varchar2,apraksts varchar2)
RETURN SELF AS RESULT
AS
BEGIN
SELF.nosaukums:=nosaukums;
SELF.apraksts:=apraksts;
SELF.created:=sysdate;
RETURN;
END;
END;
insert into AUGI values (AUGI_typ('Arekas palma','Arekas rieksti
satur....'));
Tipa ķermenī konstruktora funkcijā tiek aprakstīts, kādas darbības ir veicamas,
iniciējot klases eksemplāru. Apskatītajā piemērā objekta tipam tiek piešķirts nosaukums un
apraksts no objekta eksemplāra veidošanā norādītajām vērtībām un automātiski tiek aizpildīts
arī izveidošanas laiks – lauks „created”. Šādā veidā nav nepieciešams izmantot trigerus vai
kādus citus mehānismus, kā norādīt izveidošanas laiku. Tas tiek paveikts konstruktora
funkcijā un, iniciējot objekta eksemplāru, nav jānorāda visi atribūti, kuru vērtības tajā brīdī
vēl nav zināmas.
Automatizēt konstruktora funkciju ģenerēšanu var ieviešot mehānismu, kurš nodrošina
iespēju katram objektu tipam norādīt, kuri no atribūtiem ir izmantojami (7.45. att.).
65
`
7.45. att. Konstruktora funkciju definēšana
Attēlā parādīts ekrāns, kurā notiek konstruktora funkciju un to atribūtu izvēle. Tiek
izmantota objektorientētās pieejas iespēja definēt metodi ar vienu nosaukumu, bet ar dažādu
skaitu parametriem. Tā kā viena objekta visām konstruktora funkcijām nosaukumi ir vienādi,
tad atsevišķa iespēja izvēlēties konstruktora funkcijas nosaukumu nav nepieciešama. Ir
nepieciešama iespēja pievienot vai dzēst konstruktora funkciju. Jānodrošina arī iespēja
izvēlēties, kuri parametri tiks iekļauti konstruktora funkcijas definīcijā – kurus atribūtus
izmantos, iniciējot objekta eksemplāru. Tiek nodrošināta arī iespēja izvēlēties vērtības pēc
noklusējuma brīvi izvēlētiem atribūtiem.
7.3. Lietotāja definēti šabloni objektu metodēmRelāciju objektu datu bāzē darbs pamatā notiek ar izveidotajiem objektu eksemplāriem,
kuri izveidoti no objektu tipa. Lai to būtu iespējams veikt, ir jāizveido dažādas objektu
metodes, kuras mainītu objekta stāvokli un uzvedību – mainītu atribūtu un saistīto objektu
atribūtu vērtības. Vienīgais veids, kā izveidot metodi, ir norādīt metodes aprakstu un ķermeni
objekta tipā. Ieviešot automātiskus šablonus, datu bāzes projektētājam būtu iespēja šādas
metodes datu bāzē nerakstīt no jauna, bet jau izmantot ģenerētās metodes – tās būtu tikai
66
`
jāpapildina ar nepieciešamo funkcionalitāti. Atšķirībā no iepriekš apskatītās konstruktora
funkciju definēšanas iespējas, objektu metodēm un funkcijām gan ir nepieciešams norādīt arī
nosaukumu un atkarībā no veida, arī to, vai tiks atgriezts kāds datu tips (7.46. att.).
7.46. att. Objektu metodes
Objekta procedūru definēšana savukārt ir līdzīga funkciju definēšanai, vienīgā atšķirība
ir tā, ka netiek norādīts atgrieztais datu tips. Relāciju objektu datu bāzē gan funkcijas, gan
procedūras tiek aprakstītas tāpat kā jau apskatītās konstruktora funkcijas. Veidojot objekta
tipu, ir jānorāda funkcijas vai procedūras apraksts – nosaukums, ieejas parametri un funkcijas
gadījumā atgriežamais datu tips. Objekta tipa ķermenī ir jānorāda funkciju un procedūru
implementācija tieši tāpat, kā tas ir konstruktora funkcijām.
7.4. Konceptuālā modeļa un transformāciju datu glabāšanas datubāzes
struktūrasVeicot fizikā modeļa ģenerēšanu no konceptuālā modeļa, ir nepieciešamas datu bāzes
struktūras, kurās saglabāt visus izveidotos konceptuālā modeļa elementus un arī
transformācijas, kā no loģiskā modeļa tiek iegūts fiziskais modelis. Šim nolūkam tiek
67
`
izmantota relāciju datu bāze. Tiek izveidotas atbilstošas tabulas, kur glabāt visus
nepieciešamos elementus, kā arī transformāciju veidus. Lai saglabātu visas realitātes, kuras
tiek transformētas relāciju - objektu datu bāzes struktūrā, kā arī visus realitātei piederošos
atribūtus, tiek izveidotas tabulas objektiem (7.47. att.) un atribūtiem (7.48. att.). Realitātes
aprakstošie atribūti ir realitātes nosaukums („NAME”), dziļums mantošanas kokā
(„INHERITANCELEVEL”), ja realitāte ir sasaistīta ar citām realitātēm, izmantojot
mantošanas asociāciju. Kā atribūti ir iekļauti arī realitātes apraksts („DESCRIPTION”) – kurā
glabājas informācija, kam ir domāta realitāte un kādus datus datu bāzē saturēs saistītais
izveidotais relāciju datu bāzes objekts. Transformācijas procesā, izmantojot šo atribūtu, tiek
ģenerēta objekta tipa statiskā metode, kuru izsaucot tiek izvadīts objekta apraksts. Realitātei
arī ir pievienota pazīme – „IS_AUTO”, kura nozīmē to, vai realitāte ir izveidota
transformācijas ceļā, vai arī to ir izveidojis lietotājs, kurš ir definējis transformējamo
konceptuālo modeli. Pazīme – „IS_TABLE” norāda to, vai šo realitāti noteikti ir
nepieciešams pārveidot uz objektu tabulu. Transformējot realitāti, var veidot objektu tabulu,
vai arī iegūto objektu glabāt citā objektā. Katrai realitātei ir arī lauki „TYPE_H” un
„TYPE_B”, kuros tiek saglabāts ģenerētais objekta tips un objekta tipa ķermenis. Visas
veidotās tabulas arī iekļauj primāro atslēgu – tā ir kolonna „ID”.
7.47. att. Realitātes tabula
Realitāšu tabula ir cieši saistīta ar realitāšu atribūtu tabulu, tajā tiek norādīta saite uz
realitāti, kolonna („EID” – EntityID), kā arī visi realitātei definētie atribūti, to tipi un izmērs,
ja tiek izmantots pēc noklusējuma piedāvātais datu tips. Transformācijas ceļā ir iespējams, ka
tiek pievienoti jauni atribūti, kuru tips ir kāds no izveidotajiem objekta tipiem, tādā gadījumā
atribūta izmērs netiek norādīts.
68
`
7.48. att. Realitātes atribūti
Kā nākamās svarīgākās tabulas ir pašu saišu definēšanas tabulas. Datu bāzes līmenī
tās tiek nosauktas par transformācijas tabulām. Transformāciju definīcijas tiek glabātas divās
tabulās, viena no tām ir tabula, kur glabājas transformācijas tips, jeb saites veids. Iespējamie
sasaistes veidi ir viens pret vienu, viens pret daudziem, daudzi pret daudziem, mantošanas
saite, kompozīcija un agregācija.
7.49. att. Transformāciju aprakstošā tabula
Otra izveidotā transformāciju jeb saišu tabula ir tabula, kurā tiek glabāts definēto saišu
pārveidošanas veids.
7.50. att. Transformāciju detaļu tabula
Ir definēti kodi, kuri nosaka, kā transformācija ir veicama un katrai transformācijai ir
piesaistīts ieraksts no transformāciju tipu tabulas. Kopā transformācijas tips un
transformācijas kods definē, kādā veidā tiek transformētas realitātes. Daži no definētajiem
tipiem ir:
INCLREF - nozīmē, ka izveidotais objekta tips iekļauj sevī saistītā objekta
atsauci;
SEPREF – apraksta, ka izveidotais objekta tips nesatur sevī saistītā objekta
atsauci, atkarībā no tā – vai jāveido tabula vai nē. Atsauci var saglabāt tabulas
kolonnā vai arī tiek veidota jauns objekta tips, uz kura bāzes tiek veidota
69
`
tabula, lai turpmākās sasaistēs izveidotajam tipam būtu iespējams veidot
sasaistes – tiktu izveidota objektu rindu tabula;
INCLUDE – savukārt nozīmē, ka viens objekts tiek iekļauts citā objektā –
pamatā tiek izmantos kompozīcijas saitēs vai arī saitēs viens pret daudziem,
kad kā sasaistes veids tiek izmantota iekļautā tabula.
Saites starp realitātēm savukārt tiek aprakstītas transformāciju tabulā (7.51.att.). Šī
tabula satur informāciju par to, kāda veida transformācija ir definēta starp realitātēm
(atsauces uz transformācijas aprakstu un detaļām), kā arī atsauces uz saistītajām realitātēm.
Kolonna „RESULT_CODE” tiek izmantota, lai saglabātu transformācijas starprezultātus.
Tāpat ir arī kolonna, kura raksturo to, vai transformācija ir apstrādāta. Svarīga pazīme ir arī
atribūta „AUTO_GEN” vērtība, kura nozīmē, vai transformāciju ir definējis lietotājs,
izmantojot dialogus un veidņus, vai arī transformācija ir veidojusies realitāšu pārveidošanas
procesā. Tas notiek gadījumos, kad tiek izveidota jauna realitāte, izmantojot jau esošās, un
notiek saišu aizvietošana, lai aprakstītu jaunās realitātes asociācijas ar citām realitātēm.
7.51. att. Transformācijas
Tā kā tiek nodrošināta arī iespēja konfigurēt konstruktora funkciju, objekta funkciju
un objekta procedūru šablonu veidošanu, tad arī šai funkcionalitātei ir izveidotas atbalsta
tabulas. Katram no objekta metožu veidiem (konstruktora funkcija, objekta funkcija, objekta
procedūra) ir izveidots tabulu pāris – aprakstošā daļa vai galvene, kā arī detalizācija.
Konstruktora funkciju galvenes tabulā (7.8. att.) tiek glabāta informācija par to, kurai no
realitātēm tiek definēta minētā funkcija, kā arī ir nodrošināta konstruktora funkcijas
aprakstošās daļas un izveidotā ķermeņa apraksta saglabāšana. Papildus tam ir arī atribūts,
kurš nosaka, vai konstruktora funkcijas ģenerēšana ir pabeigta. Detalizācijas apraksts (7.9.
att.), savukārt, ietver tikai konstruktora funkcijas un iesaistīto atribūtu sasaisti, lai ģenerējot
70
`
šablonus, būtu avots, kurā ir definēti katrai konstruktora funkcijai definētos parametrus. Kā
jau iepriekš tika minēts, tad konstruktora funkcijai nav nepieciešams definēt nosaukumu. Tas
ir vienāds ar izveidotā objekta tipa nosaukumu.
7.52. att. Konstruktora funkcijas apraksts
7.53. att. Konstruktora funkcijas detalizācija
Līdzīgā veidā ir aprakstītas arī objekta funkciju un objekta procedūru apraksta
glabāšanas struktūras. Detalizācijas līmenī būtisku atšķirību nav, izmaiņas ir tikai
aprakstošajā daļā. Kā redzams attēlā (7.54. att.), tad atšķirīgais ir tas, ka nāk klāt procedūras
un funkcijas nosaukums, kā arī funkcijai tiek norādīts atgriežamais datu tips.
7.54. att. Funkciju un procedūru apraksts
Kopējā glabāšanas struktūru tabulu un to asociāciju shēma redzama attēlā (7.11. att.).
71
`
7.55. att. Glabāšanas struktūras un asociācijas starp tām
7.5. Izmantotiekritēriji struktūras vērtējumamLai novērtētu projektējamo struktūru, nepieciešams izmantot dažādus kritērijus.
Projektēšanas automatizācijas prototipā struktūra tiek vērtētā divos posmos. Pirmo reizi
struktūra tiek vērtēta, veidojot konceptuālo modeli. Pēc tam, kad ir pielietoti visi
transformāciju likumi un iegūta relāciju – objektu datu bāzes shēma, tad struktūra tiek
atkārtoti novērtēta. No visiem iepriekš apskatītajiem kritērijiem struktūras vērtējumam šajā
gadījumā vispiemērotākie ir: tabulas izmērs, atribūtu skaits, mantošanas dziļums, saišu skaits
starp objektiem, kopējais objektu skaits un kopējais tabulu skaits. Daži no šiem kritērijiem ir
pielietojami tikai konceptuālā modeļa izveidē, daži no kritērijiem, savukārt tiek izmantoti
tikai relāciju – objektu datu bāzes struktūras novērtējumam. Līdz ar to tiek iegūtas divas
kritēriju kopas – konceptuālā modeļa kritēriju kopa un relāciju - objektu struktūras kritēriju
kopa. Pirmajā kopā ietilpst kritēriji, kuri tiek pielietoti vērtējot konceptuālo modeli. Tie ir –
atribūtu skaits, mantošanas dziļums, saišu skaits, kopējais objektu skaits. Izmantojot šos
kritērijus, nav iespējams noteikt vai struktūra ir optimāla vai nē, bet kritēriju ieviešana dod
iespēju projektēšanas gaitā iegūt atskaiti par to, vai izmaiņas konceptuālajā modelī sarežģī
modeli vai tieši otrādi – padara to vienkāršāku. Ja konceptuālais modelis sastāv no liela skaita
realitātēm, tad bez kritēriju izmantošanas, sarežģītību ir grūti novērtēt. Arī, ja pie viena
konceptuālā modeļa strādā vairāki cilvēki, tad pēc kritēriju vērtībām ir vieglāk noteikt kāda
72
`
veida izmaiņas ir veikusi otra iesaistītā persona. Kā piemērs tiek paņemts konceptuālais
modelis, kurā attēlots augs, tā fiziskās un ķīmiskās īpašības, kā arī novākšanas un žāvēšanas
asociācijas. Augam objektam ir savas auga specifiskās īpašības, kā arī nosaukums, apraksts,
attēls un izplatība. Tāpat augam ir arī vairāki ievākšanas veidi, jo katrs augs var būt ievācams
vairākos laika periodos, piemēram, pavasarī un rudenī, kā arī katram augam ir savas
komponentes, kuras tiek ievāktas. Tās var būt – miza, augļi, sēklas, ogas un citi. Tāpat katrs
augs satur ķīmiskās vielas, kurām ir dažādas īpašības. Vielas var būt gan kaitīgas, gan
veselīgas. Katram augam ir arī specifiski žāvēšanas apstākļi.
7.56. att. Augi - konceptuālais modelis
Konceptuālajā modelī izvēlētie kritēriji ir viegli nosakāmi, jo visas vērtības ir vizuāli
redzamas modelī. Sarežģītāk ir tad, ja modelis ir sarežģīts un vairs nav pārskatāms.
Konkrētajā modelī izvēlētās kritēriju kopas vērtības ir šādas:
Objektu skaits – 14;
Objektu skaits neskaitot iesaisti mantošanas kokā – 9;
Mantošanas kokos esošo objektu skaits neskaitot augšējo līmeni – 5;
Dziļums mantošanas kokā (vidējā vērtība) – 2 ( tiek izmantoti divi mantošanas līmeņi)
Mantošanas koku skaits – 2;
Atribūtu skaits – 26;
73
`
Lielākais atribūtu skaits – 4;
Mazākais atribūtu skaits – 1;
Vidējais atribūtu skaits – 26/14 = ~2 atribūti;
Saišu skaits starp objektiem – 14;
Pēc kritēriju aprēķināšanas ir iespējams novērtēt, kuras lietas konceptuālajā modelī
varētu būt pamaināmas. Piemēram, ja ir zināms vidējais atribūtu skaits objektā un
minimālais/maksimālais atribūtu skaits, tad ir iespējams pārbaudīt, vai modeli nav iespējams
padarīt vienkāršāku un kādu no sarežģītākiem objektiem padarīt vienkāršāku sadalot to
vairākās daļās. Kā arī pārbaudīt, vai objekti ar minimālo skaitu atribūtiem vispār ir vajadzīgi
un vai nav iespēja tos pievienot kādam citam no objektiem. Pārbaudot mantošanas koka
vērtības,arī ir iespējams redzēt, vai mantošana nav pārāk dziļa (pārāk dziļš mantošanas koks)
vai pārāk plata (pārāk plats mantošanas koks). Piemēram, ja ir zināms, ka vidējais
mantošanas līmenis ir 2 un ir tikai 3 mantošanas koki, bet mantošanā ir iesaistīti 30 objekti,
tas nozīmē, ka vismaz vienā no mantošanas kokiem vienā līmenī eksistē 10 vai vairāki
objekti. Balstoties uz šo informāciju, ir iespējams pieņemt lēmumu, vai objektus sagrupēt, lai
mantošanā būtu iesaistīti mazāk objektu, vai arī izdalīt jaunus objektu tipus, lai palielinātu
mantošanas koka dziļumu un tādējādi samazinātu mantošanas koka platumu.
Otrajā kritēriju kopā ietilpst tabulas izmērs, kuru aprēķinot, objekta vienkāršajiem un
saliktajiematribūtiem tiek piemēroti koeficienti – tādējādi iegūstot katru objekta rindas tabulu
raksturojošu lielumu. Arī heterogēniem atribūtiem tiek piemērots koeficients. Šajā kopā tiek
izmantots arī kopējo objektu tipu skaits, saišu skaits starp objektu tipiem un iegūto tabulu
skaits. Attēlā (7.13. att.) ir attēlota viena no relāciju – objektu datu bāzes glabāšanas struktūru
realizācijām iepriekš apskatītajam konceptuālajam modelim. Savukārt tabulā (7.1. tabula) ir
minēti struktūrā redzamie apzīmējumi un to skaidrojumi.7.12. tabula
Relāciju - objektu struktūras attēlojumu skaidrojums
Apzīmējums SkaidrojumsVienkāršā tipa atribūts
Relāciju objektu datu bāzes objekts
Atsauce
74
`
Tabula
Heterogēna tabula – viena kolonna, dažāda tipa objekti no mantošanas koka
7.57. att. Relāciju – objektu glabāšanas struktūras attēlojums
Redzamajā piemērā ir izmantotas divas tabulas – viena tabula augiem, otra tabula
augu īpašībām. Tā kā īpašības iedalās trīs veidos un tās visi glabājas vienā tabulā, kā arī ir
saistītas gan ar augiem, gan ar augu ķīmiskajām vielām, tad ir nepieciešamas divas saites, lai
sasaistītu īpašības ar saistītajiem objektiem. Tā kā pārējie objekti tiek uzreiz iekļauti citos
objektos, tad vairāk saišu starp objektiem nav. Arī iegūtais tabulu skaits ir divas tabulas, jo
nepieciešams glabāt gan augus, gan arī to īpašības atsevišķās tabulās.
Kritēriju kopas vērtības:
Objektu tipu skaits – 14 (piemērā to nevar redzēt redzēt, jo vērā tiek ņemta arī
mantošana, kura realizācijā ir attēlota kā heterogēnā tabula vai heterogēnā
iekļautā tabula, bet katram objektam konceptuālajā modelī atbilst viens
objekta tips relāciju – objektu datu bāzes struktūrā);
Tabulu skaits -2;
Saišu skaits – 2;
Tabulu sarežģītība – 36/2=18 (izmantotie koeficienti: atribūts – 2, objekta tips
– 4, heterogēna tabula – 8)
Kā viens no alternatīviem struktūras saglabāšanas veidiem ir parādīts attēlā (7.58. att.)
:
75
`
7.58. att. Relāciju - objektu struktūra
Atšķirībā no iepriekšējā piemērā – objektu tipu skaits paliek nemainīgs, jo tipu
apvienošana vai sadalīšana nav notikusi, bet ir notikušas citas strukturālas izmaiņas.
Būtiskākā no tām ir tabulu skaita palielināšanās un saišu skaita starp objektu tipiem
palielināšanās. Alternatīvās glabāšanas struktūras kritēriju vērtības:
Objektu tipu skaits – 14 (saglabājas nemainīgs, jo netiek veikta ne objektu sadalīšana,
ne apvienošana);
Tabulu skaits -5 (īpašību glabāšanai šajā gadījumā tiek paredzēta sava tabula katram
īpašību tipam);
Saišu skaits – 4;
Vidējā tabulu sarežģītība – 42/5 = ~8 samazināta tabulu sarežģītība (izmantoti
koeficienti tie paši, bet tā kā palielinās tabulu skaits, tad attiecīgi samazinās
sarežģītība).
Arī šeit viennozīmīgi nav iespējams spriest, kura no pieejām ir labāka un kāda veids
struktūra ir optimāla un ieteicama, bet, veicot dažādus pielāgojumus un glabāšanas struktūru
labojumus, ir iespējams pamainīt kritēriju skaitliskās vērtības un tādējādi iegūt vienkāršāku
datu bāzes modeli. Rezultāts arī atkarīgs no tā – kas ir prioritāte – tabulu skaita un saišu
skaita palielināšana vai arī tieši otrādi – neatkarīgu objektu skaita un tabulu skaita
samazināšana. Savi trūkumi un priekšrocības ir gan vienai gan otrai pieejai atkarībā no
problēmsfēras vajadzībām un nosacījumiem, bet, dodot projektētājam iespēju mainīt
konfigurācijas projektēšanas posmā,tiek nodrošināta relāciju – objektu datu bāzes struktūras
lielāka elastība un pielāgojamība dažādiem reālās dzīves modeļiem.
76
`
7.6. Veidņa vadītas sistēmas prototipsPrototips kopumā sastāv no divām lielām komponentēm. Viena no tām ir lietojums ar
grafisko lietotāja interfeisu, kurā veikt konceptuālā modeļa grafisku veidošanu. Otra ir datu
bāze un konceptuālā modeļa transformācijas mehānisms, izmantojot norādītās saites un
aprakstītos transformācijas likumus. Lietojums ar grafisko interfeisu tiek veidots izveidojot
JAVA FX tehnoloģiju. Java tiek izvēlēta tāpēc, ka tā ir viena no populārākajām izstrādes
tehnoloģijām un tā ir bagātīga ar dažādiem paplašinājumiem, kuri ļoti nozīmīgi atvieglo
izstrādes procesu. Prototipam ir jānodrošina konceptuālā modeļa attēlojums grafiski un arī
struktūras veidā. Izstrādājot prototipu, tika izvēlēta XML attēlojumu struktūra, līdz ar to,
viens no lietojuma paneļiem satur arī informāciju par realitātēm, atribūtiem, funkcijām un
saitēm. Prototipa viens no vēlamajiem attēlojumiem parādīts attēlā (7.15. att.)
7.59. att. Prototipa lietotāja interfeiss
Attēlā parādīta koka struktūra, kurā attēlotas realitātes, kā arī realitātes tiek attēlotas
vizuāli un ir iespēja tās brīvi pārveidot, mainīt to īpašības, kā arī dzēst un veidot sasaistes.
Procedūru, funkciju un konstruktora funkciju veidošanas un labošanas lietotāja grafiskais
interfeiss apskatīts iepriekš attēlā (7.1 att.) un attēlā (7.2 att.) Visi attēlā redzamie elementi
attiecīgi tiek saglabāti 7.4 nodaļā aprakstītās datu bāzes struktūrās. Atbilstošie ieraksti datu
bāzē izskatās sekojoši:
77
`
7.60. att. Konceptuālā modeļa realitāšu attēlojums
7.61. att. Konceptuālā modeļa atribūtu attēlojums
Tādā pašā veidā jau iepriekš aprakstītajās struktūras tiek saglabātas konstruktora
funkcijas konfigurācija, objekta funkciju konfigurācija un objekta procedūru konfigurācija.
Arī saišu tabulā tiek definēts, kādas saites starp objektiem eksistē. Sākot transformācijas
procesu, projektētājam dialogu veidā tiek uzdoti jautājumi, kuras saites un kādā veidā
saglabāt datubāzē. Vienkāršots shematisks saišu attēlojums starp realitātēm:
7.62. att. Realitāšu saites - vienkāršots attēlojums
Transformāciju apstrādes algoritms atspoguļots attēlā (7.63. att.). Vispirms tiek
apstrādāta pēdējā sasaiste starp realitātēm. Transformācijas rezultātā tiek iegūts kāds objekta
tips un/vai tabulas veidošanas sql komanda. Otrajā solī, savukārt tiek apstrādāta otrā saite
starp objektiem un tiek iegūts jauns objekta tips ar iepriekš definēto relāciju - objektu datu
bāzes sasaistes veidu. Pirms transformāciju saišu apstrādes, vispirms tiek izveidotas visas
konstruktora funkcijas, procedūras un objekta tipu funkcijas. Izpildot datu bāzes procesu
definētajām realitātēm un to konfigurācijām tiek iegūtas nepieciešamie pl/sql koda fragmenti.
Piemēram, ģenerētās konstruktora funkcijas izskatās redzamas attēlā (7.20. att.).
78
`
7.63. att. Transformāciju algoritms
7.64. att. Ģenerētās konstruktora funkcijas
Kā redzams attēlā, tad tiek izveidota gan konstruktora funkcijas definīcijas galvene,
kā arī definīcijas ķermenis. To arī var redzēt, pēc attēlotajiem pl/sql koda gabaliem. Identiskā
veidā tiek apstrādātas pilnīgi visas realitātes un no visām iepriekš definētajām konfigurācijām
tiek saģenerēti pl/sql koda daļas. Pēc tam, kad visas daļas ir saģenerētas, no šiem koda
gabaliem arī tiek izveidota katras atbilstošās realitātes objekta tipa galvene un arī objekta tipa
ķermenis. Kad transformācijas process ir pilnībā pabeidzis darbu, tiek iegūtas relāciju-objektu
struktūras, kuras pirms tam tika norādītas konceptuālajā modelī. Apskatītā piemēra ģenerētie
objekta tipu galvenes redzamas attēlos - 7.21. attēlā. , 7.22. attēlā. un 7.23. attēlā:
79
`
7.65. att. Realitāte_3 objekta tipa galvene
Kā redzams saišu attēlojumā, tad starp „realitāte 2” un „realitāte 3” ir definēta saite
viens pret vienu ar tipu INCLREF – tas nozīmē, ka „realitāte 2” iekļaus atsauci uz „realitāte
3”. Līdz ar to, tas nozīmē, ka no „realitāte 3” tiek izveidots objekta tips un no šī tipa tiek
veidota tabula ar rindas tipa objektiem, lai būtu iespējams norādīt atsauci (to iespējams
norādīt tikai uz rindas tipa objektiem). Šajā gadījumā „realitāte 3” atbilst gan objekta tips, gan
arī tabula, kas veidota par pamatu ņemot „realitāte 3”.
7.66. att. Realitāte_2 objekta tipa galvene
Veidojot „realitāte 2” tipa ķermeni, tiek norādīta atsauce uz „realitāte 3” izveidoto
objekta tipu. Nākamā saite starp realitātēm ir definēta kā saite – viens pret vienu ar tipu
INCLUDE. Tas nozīmē, ka „realitāte 1” iekļaus sevī „realitāte 2”. Vizuāls objektu attēlojums
redzams attēlā (7.19. att.). Transformācijas procesa solī tas nozīmē, ka pie „realitāte 1”
atribūtiem tiek automātiski pievienota „realitāte 2” ar tipu „realitāte 2_typ”. Kā arī katrai no
realitātēm tika definētas objekta funkcijas, objekta procedūras vai arī konstruktora funkcijas
izmantojot nodaļā 7.4. aprakstītās datu bāzes struktūras, kuras arī redzamas uzģenerētajās
objekta tipu galvenēs.
80
`
7.67. att. Realitāte_1 objekta tipa galvene
81
SECINĀJUMIDarba izstrādes gaitā, veicot datu bāzes projektēšanas mehānismu un tehnoloģiju
analīzi, kā arī iepazīstoties ar relāciju datu bāzes un relāciju – objektu datu bāzes
priekšrocībām un trūkumiem, autors ir nonācis pie šādiem secinājumiem:
1. Paplašinātais realitāšu saišu(EER) modelis tiek izmantots, lai projektētu relāciju datu
bāzes un iegūtu datu mantošanas realizējumus relāciju datu bāzes variantā.
2. UML klašu diagrammatiek pielietota, lai projektētu objektorientētās bāzes.
3. Relāciju – objektu datu bāzes projektēšanai nav atbilstoša semantiskā modeļa.
4. Relāciju datu bāze nav piemērota sarežģītu reālās datu struktūru attēlojumam un
nenodrošina visus nepieciešamos datu sasaistes veidus.
5. Izmantojot relāciju – objektu datu bāzi ir iespējams realizēt sarežģītas reālās dzīves
datu struktūras, jo ir iespēja izveidot problēmsfērai atbilstošākas datu glabāšanas
struktūras.
6. Lai nodrošinātu relāciju datu bāzes un lietojuma sadarbību, ir nepieciešami papildus
karkasi, jo lietojumi pamatā tiek izstrādāti, izmantojot objektorientēto pieeju.
7. EER/UML modelis nevar tikt izmantots, lai projektētu relāciju – objektu datu bāzes,
jo šajos modeļos nav iespējams norādīt visa veida sasaistes, ar kādām objekti var būt
sasaistīti datu bāzes līmenī.
8. Relāciju – objektu datu bāzes struktūru apguve un izmantošana prasa ilgāku laiku un
dziļākas zināšanas.
9. Populārie projektēšanas rīki nenodrošina relāciju – objektu datu bāzes projektēšanu,
kaut arī ir iespēja projektēšanas gaitā norādīt objektiem raksturīgās īpašības.
10. Ir dažādas pieejas un mehānismi, kā projektēt relāciju – objektu datu bāzi, bet
transformācijas likumi ir stingri definēti katrā no pieejām, līdz ar to viena konceptuālā
modeļa objektu sasaiste vienmēr tiks pārveidota vienā un tajā pašā relāciju – objektu
datu bāzes struktūrā.
11. Apskatītajās pieejās galvenais trūkums ir tas, ka nav iespējams izvēlēties, kāda gala
struktūra tiek iegūta projektēšanas rezultātā. Relāciju – objektu datu bāzē ir vairākas
iespējamās realizācijas vienam konceptuālajam modelim.
`
12. Relāciju – objektu datubāzes modeļa dažādajām realizācijām ir iespējams pielietot
dažādus kritērijus, tādējādi novērtējot dažādu modeļu atbilstību vēlamajam.
13. Nodrošinot iespēju projektētājam izvēlēties atbilstošās glabāšanas struktūras relāciju –
objektu datu bāzē, ir iespējams projektēt relāciju – objektu datu bāzi, kura atbilst
biznesa prasībām. Kā arī, papildinot projektēšanas procesu ar dažāda veida
konfigurācijām, ir iespējams samazināt izstrādātāja veicamo darbu apjomu datu bāzes
funkcionalitātes nodrošināšanā.
14. Nav piemērota modeļa, ko izmantot, lai projektētu relāciju – objektu datu bāzi.
15. Relāciju – objektu datu bāzes gan prasa vairāk zināšanas, lai tās izstrādātu un
uzturētu, bet tiek atvieglota lietojumu izstrāde un nodrošināta datu kopumu
nepieciešamās apstrādes funkcionalitātes glabāšana kopā ar datu vienībām.
16. Izveidotais relāciju – objektu datu bāzes projektēšanas prototips, ļauj veidot
komerciālu projektēšanas sistēmu, jo izpētīti un doti risinājumi galvenām relāciju –
objektu datu bāzes projektēšanas problēmām.
83
`
IZMANTOTĀ LITERATŪRA1. Abdelsalam Maatuk, Akhtar Ali, And Nick Rossiter School Of Computing,
Engineering &Information Sciences Northumbria University, Newcastle Upon Tyne, Uk, An
Integrated Approach To Relational Database Migration, 2008
2. Ming Wang, California State University , Using Uml For Object - Relational
Database Systems Development: A Framework, 2008
3. María Fernanda Golobisky1 And Aldo Vecchietti, Fundamentals For The
Automation Of Object-Relational Database Design, 2011
4. Automating The Collection Of Object Relational
Database Metrics,2011
5. Hibernate karksass, Internets. - http://hibernate.org
6. Objektorientētie kritēriji, Internets -
http://agile.csc.ncsu.edu/sematerials/oometrics.htm
7. Objektorientētie kritēriji, Internets -
http://www.cc.uah.es/drg/b/rodharrama00.english.pdf
8. Objektorientētie kritēriji, Internets -
http://www.jot.fm/issues/issue_2006_11/article5.pdf
9. Objektorientētie kritēriji, Internets -
http://www.literateprogramming.com/ooapply.pdf
10. Oracle dokumentācija, Internets -
https://docs.oracle.com/cd/a87860_01/doc/java.817/a83723/objcoll4.htm
11. Brīvi pieejams tiešsasaistes diagrammu zīmēšanas rīks, Internets
-http://creately.com/
12. Carlos Alberto Rombaldo Jr, Solange N. Alves Souza, Department Of Computing
Engineering AndDigital System Of University Of São Paulo, São Paulo, Brazil. Luiz Sergio
De Souza, Faculdade De Tecnologia - Carapicuíba, São Paulo, Brazil O-Odm Framework For
Object-Relational Databases, 2012
13. Ming Wang, California State University, [email protected], Using
Object-Relational Database Technology To Solve Problems In Database Development. 2010
14. Profesora Jāņa Eiduka mācību materiāli
84
`
15. Eclipselink karkass, Internets -http://www.eclipse.org/eclipselink/
16. Myibatis karksass, Internets - http://www.mybatis.org/mybatis-3/
85