of 124 /124
` 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

Datu bāzes tehnoloģijas  · Web viewMaģ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

  • Author
    others

  • View
    3

  • Download
    0

Embed Size (px)

Text of Datu bāzes tehnoloģijas  · Web viewMaģistra darbā apskatīta datu bāzes projektēšana....

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.

SatursIEVADS81.DATU BĀZES UN PROBLĒMVIDE111.1.Datu bāzes projektēšana111.2.Relāciju datu bāzes neatbilstība problēmu vidēm ar saliktiem objektiem (relāciju datu bāzes trūkumi)121.3.Relāciju-objektu datu bāzes nepieciešamība saliktām problēmu vidēm142.RELĀCIJU-OBJEKTU DATU BĀZES DATU GLABĀŠANAS STRUKTŪRAS242.1.Objektu orientētās tehnoloģijas relāciju-objektu datubāzē242.2.Datu bāzes objekts262.3.Glabāšanas elementi un struktūras:302.4.Asociāciju veidi323.RELĀCIJU – OBJEKTU DATU BĀZES PROJEKTĒŠANA333.1.Relāciju – objektu datu bāzes konceptuālais modelis333.2.Objektu orientētie konceptuālie modeļi353.2.1.Projektēšanas iespējas izmantojot UML diagrammu saimes klašu diagrammu353.2.2.Paplašinātais UML modelis relāciju-objektu datu bāzes projektēšanai383.3.Objektu relāciju datu bāzes projektēšanas automatizācija[3]443.4.Daudzkriterialitāte relāciju – objektu datu bāzes projektēšanā474.TRANSFORMĀCIJAS NO KONCEPTUĀLĀ MODEĻA UZ RELĀCIJU-OBJEKTU FIZISKO MODELI514.1.Transformāciju veidi515.RELĀCIJU-OBJEKTU DATU BĀZES PROJEKTĒŠANAS RĪKI585.1.MIGROX integrētais karkass585.2.O-ODM relāciju-objektu datu bāzes projektēšanas karkass596.RELĀCIJU-OBJEKTU DATU BĀZES DATU STRUKTŪRAS NOVĒRTĒJUMA KRITĒRIJI616.1.Objektorientētās struktūras novērtējuma metrikas616.2.Relāciju - objektu datu bāzes struktūras novērtējuma metrikas647.VEIDŅA VADĪTA RELĀCIJU - OBJEKTU DATU BĀZES PROJEKTĒŠANAS AUTOMATIZĀCIJAS PROTOTIPS667.1.Konceptuālā modeļa izveide677.2.Lietotāja definētas konstruktora funkcijas687.3.Lietotāja definēti šabloni objektu metodēm707.4.Konceptuālā modeļa un transformāciju datu glabāšanas datu bāzes struktūras717.5.Izmantotie kritēriji struktūras vērtējumam767.6.Veidņa vadītas sistēmas prototips81SECINĀJUMI86IZMANTOTĀ LITERATŪRA88

IEVADS

Ikdienas 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.

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.

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.

DATU BĀZES UN PROBLĒMVIDEDatu 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.

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 (

,

. . .

);

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

( 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ī 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

Relāciju-objektu datu bāzes nepieciešamība saliktām problēmu vidēm

Attī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

(

"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šana

create type md_nodalas_type as object

(

MDN_NOSAUKUMS varchar2(2000 char)

);

· tabulas izveidošana:

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 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 indekss

1

Uldis

Vaicis

5

Brīvības iela

Centrs

LV-1010

2

Jānis

Bērziņš

1

Elizabetes iela

Centrs

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 Indekss

1

Uldis

Vaicis

LV-1010

2

Jānis

Bērziņš

LV-1111

1.3. tabula

Normalizēta adrešu tabula

Pasta Indekss

Māja

Iela

Rajons

LV-1010

5

Brīvības iela

Centrs

LV-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ā 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

Adrese

1

Uldis

Vaicis

LV-1010, 5, Brīvības iela,Centrs

2

Jānis

Bērziņš

LV- 1111,1,Elizabetes iela,Centrs

Piemē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.

Lietotajs

ID: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

(

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 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));

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 store as ”.

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,

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 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

· 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

RELĀCIJU-OBJEKTU DATU BĀZES DATU GLABĀŠANAS STRUKTŪRAS

Lī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.

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.1. tabula

Objekorientētā pieeja relāciju – objektu datu bāzē

Objektorientētā pieeja

Relāciju – objektu datu bāze

Datu bāzes objekts

Parasti 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ā 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),

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;

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 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

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.

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.1. att. Tabula

Vienkāršs objekts – veidots no lietotāja definēta datu tipa ar definētiem atribūtiem un uzvedību.

2.2. 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 :

2.3. 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.4. att. Salikts objekts

Salikts objekts ar identifikatoru – līdzīgs kā saliktais objekts, bet ir papildus atribūts OID.

2.5. att. Salikts objekts ar identifikatoru

Objektu kolekcija – masīvs no vairākiem izveidotiem objektiem:

2.6. 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.7. att. Objektu kolekcija ar identifikatoru

Tabula ar rindas tipa objektiem – šādā tabulā ir tikai viena kolonna, kur katra no rindām satur objektu:

2.8. 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.9. 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.10. att. Tabula ar neviendabīgiem objektiem

Asociāciju veidi

Par 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.

Tāpat arī par asociāciju sauc speciālu saites veidu objektorientētajās datu bāzēs.

RELĀCIJU – OBJEKTU DATU BĀZES PROJEKTĒŠANARelā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, 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.1. att.);

2) iegūtā rezultāta korekcija saskaņā ar veiktajiem paplašinājumiem (2. Transformācija 3.1. att.).

3.1. att. Datu bāzes projektēšanas process

Objektu orientētie konceptuālie modeļi

Lai 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).

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.

3.2. 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.3. 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 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.4. 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.5. 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.

Objektu datu tipi :

3.6. 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.7. 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ā.

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.

· 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.1. tabula

Stereotipi

Datu bāzes elements

UML Elements

Stereotips

Ikona

Arhitektūras

Datubāze

Komponente

<>

Shēma

Pakotne

<>

Konceptuālie

Pastāvībā klase

Klase

<>

Daudzvērtību atribūts

Atribūts

<>

Aprēķināmais atribūts

Atribūts

<>

Kompozīta atribūts

Atribūts

<>

Identifikators

Attribūts

<>

Loģiskie

Tabula

Klase

<

>

Skatījums

Klase

<>

Kolonna

Atribūts

<>

Primārā atslēga

Atribūts

<>

Ārējā atslēga

Atribūts

<>

Ne nulles ierobežojums

Atribūts

<>

Unikālais ierobežojums

Atribūts

<>

Trigeris

Ierobežojums

<>

Pārbaudes ierobežojums

Ierobežojums

<>

Procedūra

Klase

<>

Fiziskie

Tabulvieta

Komponente

<>

Indekss

Klase

<>

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 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.2. tabula

SQL:1999 Stereotipi

Strukurēts tips (Structured Type)

Metamodeļa klase

Klase

Apraksts

<> 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

Nav

Tipu tabula (Typed table)

Metamodeļa klase

Klase

Apraksts

Definēts kā <>. 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

Nav

Knows

Apraksts

<> asociācija ir speciāla tipa saite, kura savieno klasi ar lietotāja definēto tipu <>. Tā ir viena virziena sasaiste.

Ikona

Nav

Ierobežojumi

Var tikt izmantos tikai, lai sasaistītu <> klasi ar <> klasi

Iezīmētās vērtības

Nav

Atsauces tips (REF Type)

Apraksts

<> attēlo sasaisti ar kādu <> klasi

Ikona

Ierobežojumi

<> atribūts var atsaukties tikai uz <> klasi

Iezīmētās vērtības

<> klase, uz kuru tā attiecas

Masīvs (ARRAY)

Metamodeļa klase

Atribūts

Apraksts

<> 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

<> 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 tips

Pārdefinētā metode (Redefined method)

Metamodeļa klase

Metode

Apraksts

<> metode no jauna ir implementēta bērna klasē

Ikona

Nav

Ierobežojumi

Nav

Iezīmētās vērtības

Metodes parametri un to datu tipi, kā arī metodes atgrieztais datu tips

Atliktā metode (Deffered method)

Metamodeļa klase

Metode

Apraksts

<> 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.3. tabula

Oracle8i Stereotipi

Objekta tips (Object Type)

Metamodeļa klase

Klase

Apraksts

<> 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

Nav

Objektu tabula (Ojbect table)

Metamodeļa klase

Klase

Apraksts

Definēts kā <>. 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

Nav

Knows

Metamodeļa klase

Asociācija

Apraksts

<> asociācija ir speciāla tipa saite, kura savieno klasi ar lietotāja definēto tipu (<>,<> vai <>), kurš tiek izmantots klasē. Tā ir viena virziena sasaiste.

Ikona

Nav

Ierobežojumi

Var tikt izmantos tikai, lai sasaistītu <> klasi ar <> klasi

Iezīmētās vērtības

Nav

Atsauces tips (REF Type)

Apraksts

<> attēlo sasaisti ar kādu <> klasi

Ikona

Ierobežojumi

<> atribūts var atsaukties tikai uz <> klasi

Iezīmētās vērtības

<> klase, uz kuru tā attiecas

Mainīga garuma masīvs (VARRAY)

Metamodeļa klase

Atribūts/Klase

Apraksts

<> 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

Elementu skaits masīvā

Iekļauta tabula (Nested table)

Metamodeļa klase

Klase

Apraksts

<> 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.8. 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. 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.4. tabula

UML Dagrammas, SQL:1999 un Oracle8i salīdzinājums

UML

SQL:1999

Oracle8i

Klase

Strukturētais tips

Objekta tips

Klases papildinājums

Tipu tabula

Tabula no objekta tipa

Atribū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/Metode

Asociā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

Objektu relāciju datu bāzes projektēšanas automatizācija

Relā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.

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.9. 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 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.

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 S

q2(X) optimum

X S {X*r} = P

. . .

qk(X) optimum

X S

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.10. 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 un eksistē tāds kritērijs , kuram qj(X1) > qj(X2):

un

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.

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.11. 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 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.

TRANSFORMĀCIJAS NO KONCEPTUĀLĀ MODEĻA UZ RELĀCIJU-OBJEKTU FIZISKO MODELITransformāciju veidi

No 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.1. 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.2. att. Saites viens pret vienu glabāšana divās tabulās

Izmantojot divas tabulas, šos pašus objektus var saglabāt arī iekļaujot atsauci objektā, kurš ir saistīts ar otru objektu.

4.3. 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.4. 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.)

4.5. 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.6. 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.7. att. Saite viens pret daudziem - divas tabulas un objektu rindas

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.8. 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.9. 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.10. att. Agregācijas saite

Tā kā objekti savā starpā nav cieši saistīti, tad datu bāzē tiek i