RĪGAS TEHNISKĀ UNIVERSITĀTEDATORZINĀTNES UN INFORMĀCIJAS TEHNOLOĢIJAS FAKULTĀTE

Informācijas tehnoloģijas institūts

Artūrs Līcis

DATU BĀZES VADĪBAS SISTĒMAS KODOLA PAPLAŠINĀJUMA IESPĒJU PĒTĪŠANA

Bakalaura darbs

Vadības informācijas tehnoloģijas katedraMeža 1/3Tālrunis 7089515

Zinātniskais vadītājs: Jānis Eiduksprofesors

Rīga - 2006

2

AnotācijaBakalaura darbā tiek apskatīti DBVS kodola paplašināšanas arhitektūras rašanās

priekšnosacījumi, kā arī novērtēta tās nepieciešamība mūsdienās. Darbā tiek analizēts Oracle

kodola paplašināšanas tehnoloģijas iespēju klāsts un raksturota Oracle paplašināšanas

arhitektūras specifika, kā arī tiek apskatīta kodola paplašinājumu attīstība.

Darba praktiskajā daļā tiek realizēts kodola paplašinājums konkrētam uzdevumam,

demonstrējot paplašināmās indeksēšanas darbības specifiku.

Darbā apskatīto piemēru realizācijai tika izmantoti sekojoši rīki: DBVS Oracle 9i,

SQL*Plus, SQL*Plus Worksheet un SQL Navigator 4.2.

Darba apjoms ir 82 lpp., tas satur 8 tabulas un 79 attēlus.

3

SATURS

IEVADS......................................................................................................................................8

1. KODOLA PAPLAŠINĀJUMU VĒSTURISKIE PRIEKŠNOSACĪJUMI.........................11

2. ORACLE KODOLA PAPLAŠINĀŠANAS IESPĒJU KLĀSTS........................................17

2.1. Paplašināmo tipu sistēma..............................................................................................17

2.1.1. Objektu tipi.............................................................................................................17

2.1.2. Kolekcijas...............................................................................................................19

2.1.3. Atsauču tips (REF).................................................................................................21

2.1.4. Lielie objekti un ārējie faili....................................................................................22

2.2. Servera izpildvides........................................................................................................25

2.2.1. PL/SQL...................................................................................................................27

2.2.2. JAVA.......................................................................................................................27

2.2.3. C/C++....................................................................................................................28

2.3. Paplašināmās indeksēšanas mehānisms........................................................................28

2.3.1. Lietotāju definēti operatori un indeksēšana...........................................................32

2.4. Paplašināmais optimizators...........................................................................................33

2.4.1. Statistika.................................................................................................................35

2.4.2. Selektivitāte............................................................................................................35

2.4.3. Izmaksas.................................................................................................................35

2.5. Lietotāja definētas agregātfunkcijas..............................................................................36

2.6. Abstraktās tabulas un tabulu funkcijas..........................................................................39

2.6.1. Abstraktās tabulas..................................................................................................39

2.6.2. Tabulu funkcijas.....................................................................................................41

3. ORACLE KODOLA PAPLAŠINĀJUMU ATTĪSTĪBA....................................................42

3.1. Oracle 8i........................................................................................................................43

3.2. Oracle 9i........................................................................................................................43

3.3. Oracle 10g.....................................................................................................................45

4. ORACLE KODOLA PAPLAŠINĀJUMA PIEMĒRA PROJEKTĒŠANA........................47

4.1. Ieskats problēmsfērā......................................................................................................47

4.2. Realizācijas iespēju izvērtējums...................................................................................49

4.2.1. „Plakans” DB modelis...........................................................................................49

4.2.2. RDB modelis ar ārējām atslēgām..........................................................................50

4

4.2.3. RODB modelis ar kolekciju....................................................................................50

4.3. Problēmsfēras operatori................................................................................................51

4.4. Objektu kolonnas indeksēšanas princips.......................................................................54

5. ORACLE KODOLA PAPLAŠINĀJUMA PIEMĒRA REALIZĀCIJA.............................55

5.1. Kolekcijas un objektu tipi.............................................................................................55

5.2. Operatoru izveide..........................................................................................................56

5.3. Indeksēšanas interfeisa realizācija................................................................................58

5.3.1. Metode ODCIGetInterfaces...................................................................................59

5.3.2. Metodes ODCIIndexCreate un ODCIIndexDrop..................................................60

5.3.3. Metodes ODCIIndexStart, ODCIIndexFetch un ODCIIndexClose.......................62

5.3.4. Metodes ODCIIndexInsert, ODCIIndexUpdate un ODCIIndexDelete..................68

5.4. Indeksa tipa izveide.......................................................................................................72

5.5. Problēmsfēras indeksa darbības testēšana.....................................................................72

SECINĀJUMI...........................................................................................................................79

LITERATŪRA.........................................................................................................................82

5

IEVADS

„Datu bāzes ir neizbēgamas. Tā, iespējams,

ir visnopietnākā mācība, kuru guvu visu gadu

laikā kā programmētājs.”

D. Gelardo

Starp dažādām informācijas tehnoloģijām datu bāžu tehnoloģijas, neapšaubāmi, ieņem

vienu no vadošajām vietām. Datu koplietošanas efektīva realizēšana bija viena no

svarīgākajām un aktuālākajām problēmām, un datu bāzes jau gadu desmitiem risina šo

uzdevumu. Protams, tehnoloģijas attīstās, un datu bāžu vadības sistēmas (DBVS) papildina

savu funkcionalitāti ar daudzām jaunām iespējām, taču pamatjautājums paliek nemainīgs: „Kā

pēc iespējams efektīvāk operēt ar koplietojamajiem datiem, minimizējot laika un resursu

patēriņus?”

Viens no lielākajiem pavērsieniem datu bāžu industrijā bija relāciju datu bāžu (RDB)

modeļa izveide un praktiska ieviešana. Relāciju datu bāzes eksistē jau vairāk nekā 25 gadus.

Tās aptvēra multi-miljardu dolāru industriju, un ir visplašāk izmantotais datu bāzes tips

mūsdienās, kā arī ir būtiska ikdienas dzīves sastāvdaļa [4]. Nav šaubu, ka šis apgalvojums ir

patiess. Ilgus gadus DBVS ir attīstījušās uz šī modeļa pamata, un praktiski visi DB serveru

uzlabošanas virzieni bija saistīti ar dažāda veida datu glabāšanas, apstrādes un izgūšanas

efektivitāti un drošību šī modeļa ietvaros. Apstrādājamo datu apjomi pieauga, un DBVS

pastāvīgi pielāgojās jaunajām prasībām ar dažādiem progresīvajiem risinājumiem.

RDB modeļa ietvaros ilgu tika apstrādāti vienīgi skalāri datu tipi, kā skaitļi, simboli,

vienkārši teksti, kā arī ar laiku un datumu saistītie formāti. Taču ar laiku attīstījās ne tikai

apstrādājamo datu apjoms, bet arī to specifika – daudziem uz dažādām problēmsfērām

orientētajiem lietojumiem parādījās nepieciešamība apstrādāt problēmsfērai raksturīgos datu

tipus, kuri bieži vien ir sarežģīti strukturēti (vai pat nestrukturēti). Par piemēru var kalpot

ģeogrāfiskās informācijas sistēmas, kuru neatņemama sastāvdaļa ir telpiskie dati. Telpisko

datu apstrādē jāsaskaras ar sarežģītiem ģeometriskiem objektiem un nopietnu ģeometrijas

matemātiku. RDB modelis nespēj apmierināt absolūti visas telpisko datu apstrādes un

glabāšanas prasības.

Tieši saturā bagātu datu glabāšanas un apstrādes problemātikai tiek pievērsta

uzmanība pirmajā daba nodaļā, kura ir veltīta datu bāzes vadības sistēmas kodola

paplašināšanas aktualitātei. Datu bāzes, protams, varētu pielāgoties atsevišķu lietojumu

6

prasībām pēc noteiktiem datu tipiem un ar tiem saistītu biznesa loģiku, taču tas nemaz nav

labs risinājums. Vienmēr būs lietojumi, kas pieprasīs tādus datu tipus, kurus uz doto brīdi

neatbalsta datu bāžu vadības sistēmas [10]. Tādēļ ilgu laiku, un arī joprojām, vairākas

specifiskās datu apstrādes problēmas risina paši lietojumi. Bet, pateicoties tam, ka

koplietošanas jautājumi ir neizbēgami, problēmsfēras dati vienalga tiek glabāti datu bāzēs.

Iespējamie risinājumi ir datu glabāšana datu bāzē lielo objektu veidā, kā arī

starpprogrammatūras izmantošana. Taču šie risinājumi slēpj vairākas datu apstrādes

efektivitātes problēmas, kas arī tiek apskatītas pirmajā nodaļā.

Tādēļ kā vienīgais pareizais risinājums šīm problēmām varētu būt tikai un vienīgi

iespēja paplašināt datu bāzes kodolu, kas dotu iespēju ne tikai glabāt problēmsfērai

raksturīgos datus, bet pielāgot datu bāzes kodolu efektīvai darbībai ar tiem.

Astoņdesmitajos gados sāka attīstīties objektorientētās programmēšanas koncepcija,

un vispārīgi objektorientētā pieeja problēmu risināšanai. Tas nevarēja neatstāt iespaidu arī

datu bāžu jomā. Līdz ar to parādījās pirmās relāciju – objektu datu bāzes (RODB). Tas

nenozīmēja tikai jaunu datu tipu definēšanas iespējas datu bāzē, bet arī noteiktas uzvedības

sasaiste ar tiem, kā arī iespēju tādus datu tipus apstrādāt vajadzīgajā manierē – gluži kā ar

klasēm objektorientētajā programmēšanā.

Darbā tiek uzsvērts, ka ar lietotāju definētu tipu realizēšana datu bāzes pusē vien ir par

maz. Pēc būtības relāciju – objektu datu bāzes atrisināja daudzas problēmas, un deva iespēju

vienkāršot lietojumus, kā arī starpprogrammatūru (vai arī vispār atbrīvoties no tās). Taču datu

bāzes kodols būtu jāpaplašina līdz tādam līmenim, lai sarežģītu strukturētu datu apstrādes

iespējas varētu pielīdzināt skalāro datu tipu apstrādes iespējām, kuras ir cieši integrētas datu

bāzes vadības sistēmā.

Vienu no iespaidīgākajām datu bāzes kodola paplašināšanas tehnoloģijām mūsdienās

piedāvā Oracle DBVS. Darba otrā nodaļa tiek veltīta šīs tehnoloģijas iespēju izklāstam, kurā

ne tikai tiek uzskaitītas kodola paplašināšanas iespējas un to specifika, bet arī virspusēji

raksturots, kādā veidā katra no šīm iespējām tiek realizēta un kādā veidā notiek mijiedarbība

ar DBVS kodolu. Oracle piedāvā ne tikai iespējas definēt un uzglabāt problēmsfērai

raksturīgās datu struktūras ne tikai izveidot uz tām orientētas metodes problēmsfēras datu

apstrādei, bet arī optimizēt datu glabāšanu, sniedzot iespēju veidot problēmsfēras indeksu

tipus, problēmsfēras agregātfunkcijas, optimizēt vaicājumu izpildi. Piekļuve datu bāzes

vadības kodolam notiek caur interfeisiem, kas dod iespēju definēt datu bāzes vadības sistēmas

kodola uzvedību vajadzīgajās situācijās un pielāgot datu bāzes darbību problēmsfēras

7

prasībām.

Viens no spilgtākajiem piemēriem ir Oracle Spatial kodola paplašinājums, kas ir

orientēts uz telpisko datu glabāšanu un apstrādi datu bāzē. Oracle Spatial ne tikai piedāvā

elegantu telpisko datu glabāšanas objektu modeli ar ārkārtīgi plašu funkciju klāstu tā apstrādei

un vaicājumu veikšanai, bet arī telpisko datu indeksēšanas mehānismu, kas ir realizēts ar

paplašināmās indeksēšanas iespējām.

Oracle kodola paplašinājumu attīstībai veltītajā nodaļā tiek apskatītas jaunās iespējas,

kuras parādījās katrā no nākamajām Oracle versijām, sākot ar Oracle 8i, kurā pirmo reizi tika

piedāvāta kodola paplašināšanas tehnoloģija. Kārtējā no versijām Oracle veic noteiktas

izmaiņas kodola paplašināšanas arhitektūrā, attīstot to, kas liecina par šīs arhitektūras

aktualitāti un uztura nepieciešamību.

Darba praktiskajā daļā tiek piedāvāta nesarežģīta uzdevuma analīze, ar kura palīdzību

tika demonstrētas dažas no kodola paplašināšanas iespējām – problēmsfērai raksturīgo tipu

definēšana datu bāzē, kā arī, kas ir pats būtiskākais, problēmsfēras indeksa izveidošana. Šī

piemēra nolūks nebija demonstrēt kādu algoritmisku risinājumu datu uzglabāšanas

optimizēšanai, bet gan parādīt, kādi ir problēmsfēras indeksa veidošanas pamatposmi un kādā

veidā šis mehānisms strādā.

Pēdējā nodaļa tiek veltīta problēmsfēras datu tipu un problēmsfēras indeksa

realizācijai un testēšanai, kuras laikā tiek pārbaudīta problēmsfēras indeksa reakcija uz

dažādiem ar pamatdatiem saistītiem notikumiem, kā arī tā darbība vaicājuma izpildes laikā.

Ar piemēru un vaicājumu izpildes gaitas analīzes palīdzību viennozīmīgi tika parādīta

problēmsfēras indeksa integrēšana DBVS kodolā.

8

1. KODOLA PAPLAŠINĀJUMU VĒSTURISKIE PRIEKŠNOSACĪJUMI

Relāciju datu bāžu (RDB) modeļa pirmie „uzmetumi” radās jau pagājušā gadsimta

sešdesmito gadu beigās. Šajā jomā neapšaubāmi lielākais ieguldījums ir IBM zinātniskajam

pētniekam Edgaram F. Kodam, kurš tajā laikā meklēja jaunu pieeju tam, kā apstrādāt liela

apjoma datus. Tādā veidā viņš kļuva par RDB modeļa radītāju, un jau 1970. gadā nāca klajā

viņa grāmata, kurā tiek atspoguļoti slavenie Koda likumi. Šie likumi lika pamatus tādam RDB

modelim, kurš nu jau vairākus gadu desmitus eksistē un neapšaubāmi dominē.

Pēc Koda principu definēšanas, RDB guva plašu rezonansi, un praktiski jebkura to

laiku perspektīva datu bāžu vadības sistēma (DBVS) realizēja šo datu apstrādes modeli.

Firmas personāla informācija, veikalu produktu uzskaites sistēmas, arī banku sistēmas – visās

šajās jomās RDB modelis bija labi piemērojams, un nodrošināja efektīvu strukturētu tabulāru

datu apstrādi.

Bet tehnoloģijas attīstījās, un līdz ar to apstrādājamo datu apjoms kļuva aizvien

lielāks. Arī DBVS nācās sekot līdzi jaunajām tendencēm, piedāvājot dažādas pieejas datu

apstrādes ātrdarbības un drošības uzlabošanai. Lai arī kādi optimizācijas mehānismi netika

realizēti, dati vienalga tika apstrādāti RDB modeļa ietvaros. Datortīklu izmēri un pārraidāmo

datu apjoms pieauga

Multimediju dati, kā attēli, kartes, video un audi klipi, reiz bija reti redzami ārpus

speciālās programmatūras. Šodien, vairākiem uz datortīkliem orientētiem lietojumiem ir

vajadzība pēc saviem DB serveriem, lai varētu efektīvāk operēt ar šādiem datiem. Citam

programmatūras tipam parādījās nepieciešamība glabāt datus, kuriem ir saikne ar

finansiālajiem instrumentiem, inženierdiagrammām, vai arī pat molekulārām struktūrām, it

sevišķi organiskajā ķīmijā. Neaprakstāmi liels lietojumu skaits pieprasa „saturā bagātus” datu

tipus, un ar tiem asociētu saturam raksturīgu biznesa loģiku, lai varētu veikt attiecīgus

vaicājumus šo datu ietvaros, kā arī sasniegt maksimālu ātrdarbību.

Datus, ar kuriem nākas saskartiem mūsdienu lietojumiem un datu bāžu vadības

sistēmām, var nosacīti iedalīt sekojošās grupās: vienkārši strukturēti dati, sarežģīti strukturēti

dati, daļēji strukturēti dati un nestrukturēti dati [7].

Tādu datu iedalījuma apskats ir veikts 1.1.tabulā.

9

1.1. tabula

Datu iedalījums

Datu tips Raksturojums

Vienkārši strukturēti dati Dati, kas var tikt organizēti vienkāršās tabulās, kas ir strukturētas, balstoties uz

noteiktiem biznesa likumiem.

Sarežģīti strukturēti dati Dati, kas pēc būtības ir komplicēti, un to aprakstīšanai praktiski neiztikt bez objektu

– relāciju DBVS iespējām, starp kurām ir lietotāju definētie datu tipi, kolekcijas,

atsauces u.c.

Daļēji strukturēti dati Dati, kuriem ir noteikta loģiska struktūra, un kurus parasti datu bāzes nespēj

interpretēt – tādi var būt specifiska formāta dokumenti.

Nestrukturēti dati Dati, kas netiek sadalīti mazākās loģiskās struktūrās, un tos parasti neinterpretē nedz

lietojums, nedz arī datu bāzes vadības sistēma – par piemēru var kalpot attēls, kas ir

saglabāts binārā formātā; taču pat tādi dati bieži vien satur noteiktu

papildinformāciju (attēla gadījumā tas varētu būt tā paplašinājums, krāsu skaits u.c.)

Relāciju datu bāzes līdz noteiktam brīdim atrada jo efektīvu pielietojumu vienkāršu,

strukturētu biznesa datu apstrādē un glabāšanā. Agrīno deviņdesmito gadu biznesa dati

sastāvēja no „plakaniem”, uz rindiņām orientētiem datiem (t.i., tabulāri dati bez iekļautām vai

strukturētām kolonnām) [2]. Shematiski tādu datu glabāšana datu bāzē parādīta 1.1. attēlā.

Datu bāzē nonāk tikai skalāri dati, katrs ieraksts pēc būtības satur atomāru vērtību.

1.1. att. Vienkāršu strukturētu datu glabāšana datu bāzē

Tipiski datu bāzēs netika glabāti tādi dati, kā skaņu ieraksti, videoklipi, vai arī jebkuri

specifiskas struktūras dati, kurus būtu grūti atspoguļot vienkāršā tabulārā veidā. Ar laiku

parādījās iespēja glabāt datu bāzes kolonnās liela izmēra nestrukturētus datus – lielos

objektus.

10

Lielākā daļa relāciju DBVS ražotāju paplašināja datu bāzes iespējas ar lielo bināro

objektu manipulēšanas iespējām. Taču tādas realizācijas nav pietiekoši labas. Dati tiek glabāti

lielajos objektos kā neinterpretējamu baitu kopa. Pateicoties tādam vienkāršam

vispārinājumam, DBVS nav nekādas informācijas, kas saistās ar lielo objektu saturu vai arī to

iekšējo struktūru [10].

Līdz pat deviņdesmito gadu beigām visu nestandarta datu tipu glabāšana un operēšana

bija lietojumu ziņā (1.2. attēls), t.i., ārpus DBVS. Tam bija vairāki iemesli [10]:

datu bāzēs nebija iespējams glabāt nestrukturētus vai daļēji strukturētus datus, kā,

piem., specifiska formāta tekstu;

datu bāzes nespēja veikt specializētos vaicājumus specifisko datu gadījumā (kādi,

piem., ir telpiskie dati);

pat ja DBVS realizēja iespēju glabāt nestrukturētus vai daļēji strukturētus datus (lielos

objektus), tās nenodrošināja adekvātu ātrdarbību efektīvām manipulācijām ar saturīgi

bagātiem datiem (tādiem kā iepriekšminētajos piemēros), t.i., tādu ātrdarbību, lai

vaicājumi tiktu realizēti pieņemamā laikā.

1.2. att. Saturā bagātu datu glabāšanas neiespējamība DB deviņdesmito gadu sākumā

Kā viens no šīs problēmas risinājumiem kļuva specializētie lietojumi, kurus piegādāja

dažādi programmatūras izstrādātāji. Šie lietojumi – starpprogrammatūra – izpildīja starpnieka

funkciju starp datu bāzi un lietojumiem, kas strādāja ar specializētajiem datiem.

Parasti tāda starpprogrammatūra realizēja daļu problēmsfēras biznesa loģikas, kā arī

veica noteiktus datu pārveidojumus, lai varētu datus pielāgot attiecīgajai DBVS glabāšanas

struktūrai, mēģinot apmierināt klienta un datu bāzes prasības. Starpprogrammatūra

izstrādājamai lietojumprogrammai nodrošināja vienu noteiktu saskarni (1.3. attēls).

11

1.3. att. Starpprogrammatūras izmantošana datu glabāšanai un apstrādei

Tādā veidā šie lietojumi varēja veikt specifiskas informācijas apstrādi (piem., telpisko

datu analīze un pielāgošana glabāšanai datu bāzē). Taču tādiem vāji integrētajiem

starpniekiem piemīt vairāki trūkumi[2]:

katrai problēmsfērai bija jāizstrādā sava starpprogrammatūra;

lietojumi kļuva pārāk lieli, komplicēti un neelastīgi izmaiņām;

lai arī starpnieki veica specializēto datu apstrādi, tie tika izpildīti ārpus datu bāzes

servera, izraisot ātrdarbības krišanos, jo palielinājās savstarpējā mijiedarbība ar

serveri;

datu avotu optimizācija nevarēja tikt veikta efektīvi – starpprogrammatūrai vajadzēja

izgūt datus no datu bāzes servera lielos apjomos, jo visas loģiskās operācijas tika

veiktas tieši starpprogrammatūras pusē.

Tā kā saturā bagātu datu apstrāde ārpus DBVS izraisīja dažādas problēmas un

efektivitātes krišanos, radās jautājums par DBVS pielāgošanu dažāda veida saturā bagātiem

datiem. Ar lielo objektu glabāšanas iespēju bija vien par maz, jo jebkurā gadījumā tādi dati

tika apstrādāti ārpus datu bāzes servera, un tas neatbrīvoja no nepieciešamības izmantot

dažāda veida starpniekus vai arī realizēt daļu vai visu problēmsfēras biznesa loģiku klienta

pusē. Datu bāzes servera nespēja optimāli operēt ar lielajiem objektiem nozīmēja to, ka datus

no datu bāzes nācās izgūt pilnos apjomos, t.i., bez jebkādas atlases datu bāzes servera pusē.

Kā vienīgais loģiskais risinājums šai problēmai bija, neapšaubāmi, saturā bagātu datu

manipulācijas iespēja datu bāzes servera pusē. Tas nozīmēja jaunu tehnoloģisku risinājumu –

arhitektūru, kas dotu iespēju paplašināt DBVS kodolu ar nolūku nodrošināt daļēji strukturētu,

sarežģīti strukturētu un nestrukturētu datu glabāšanu un apstrādi,- definēt savus tipus un veikt

noteiktas operācijas ar tiem. Tātad, tādai datu bāzes vadības sistēmai vajadzētu nodrošināt

programmēšanas iespējas servera pusē, kas lietojumiem dotu iespēju atbrīvoties no

starpprogrammatūras (1.4. attēls).

12

1.4. att. Sarežģītas struktūras datu apstrāde datu bāzes servera pusē

Ar tādiem tehnoloģiskajiem līdzekļiem šīs aktuālās problēmas risināšanai visvairāk

pietuvojās Oracle, IBM Informix un IMB DB2 datu bāzes vadības sistēmas, realizējot

paplašināšanas arhitektūru, kas dotu iespēju datu bāzē ne tikai glabāt saturā bagātus datus, bet

arī veikt ar tiem noteiktas operācijas, kā arī optimizēt to apstrādes un izgūšanas efektivitāti.

Primārā prasība paplašināmai DBVS ir paplašināmo tipu sistēma, kas dod iespēju aprakstīt

sarežģītus strukturētus datus, kā arī glabāt nestrukturētus datus un operēt ar tiem. Tā datu bāze

iegūst relāciju – objektu iezīmes, kuras, jāpiebilst, mūsdienās jau atbalsta vairākas DBVS.

Taču ne mazāk svarīga ir tādu datu apstrādes ātrdarbība, tādēļ viens no būtiskākajiem

jautājumiem ir indeksēšanas mehānisma izveidošanas iespēja problēmsfēras datu tipiem.

IBM Informix DBVS deva iespēju izstrādāt savus datu tipus, taču nestrukturētu un

daļēji strukturētu datu glabāšana un apstrāde varēja notikt praktiski ārpus datu bāzes, t.i.,

apstrādāta kā ārējie dati, līdz ar to tādu datu apstrāde nepiedalās transakcijās, netiek bloķēta

un kopsummā norāda uz zemu integrācijas līmeni ar DBVS [10].

IBM DB2 kodola paplašinājumi nodrošina jaudīgu mehānismu lietotāju definētu datu

apstrādei, taču datu indeksēšana ir ierobežota tikai ar četrām pamatfunkcijām, ar kuru

palīdzību varēja radīt tikai B-koku indeksus problēmsfēras objektiem. Līdz ar to nekāda

darbības brīvība kodola paplašinājumu izstrādātājam netiek sniegta [10].

Jāpiebilst, ka no šīm trijām DBVS visspilgtāko paplašināšanas arhitektūru piedāvāja

Oracle, nodrošinot lietotāju ar plašu interfeisu klāstu visdažādāko DBVS kodola

paplašināšanas iespēju realizācijai. Noteiktā veidā realizējot iespējamos interfeisus, lietotājs

var definēt visdažādākās funkcijas, kuras izpildīs serveris, apstrādājot problēmsfēras datus.

Programmēšanas gaitā ir pieejams noteikts datu bāzes servisu klāsts, kas dod iespēju

mijiedarboties ar datu bāzes kodolu (darboties ar paplašināmo tipu sistēmu, konstruēt un

izpildīt vaicājumus, mijiedarbība starp dažādām programmēšanas valodām u.c.) Kodola

13

paplašinājumu vienkāršoti var uztvert kā neatkarīgi izstrādājamu programmu (bieži vien arī

dažādās valodās), kas, pateicoties Oracle paplašināšanas arhitektūrai, tiek cieši integrēta ar

kodolu un paplašina to (1.5. attēls).

1.5. att. Oracle kodola paplašināšanas arhitektūra

Tāda arhitektūra dod iespēju ne tikai glabāt sarežģītus strukturētus, daļēji strukturētus,

kā arī nestrukturētus datus datu bāzē, bet arī optimizēt to apstrādi, saistīt ar tiem biznesa

loģiku. Tā rezultātā atkrīt vajadzība izmantot starpprogrammatūru, līdz ar to pārraidāmo datu

apjoms samazinās. Arī lietojumu izstrāde var tikt vienkāršota, jo svarīgākās datu apstrādes

funkcijas var realizēt servera pusē, piegādājot lietojumiem tikai vajadzīgus, pēc prasītiem

kritērijiem atlasītus, kā arī pēc noteiktām prasībām apstrādātus datus.

Līdz ar to Oracle DBVS realizēja 1.4. attēlā skatāmās diagrammas koncepciju –

iespēju ne tikai glabāt saturā bagātus datus, bet arī realizēt tās optimizācijas un apstrādes

darbības, kuras līdz šim bija pieejamas tikai skalārajiem datu tipiem.

Iespējami būtiskākais no paplašināšanas aspektiem ir paplašināmās indeksēšanas

arhitektūra, kas ir pielāgojama problēmsfērai specifiskajām DBVS lietojuma prasībām. Tās

pamatnolūks ir atbalstīt dabiskās problēmsfēras operācijas ar datiem efektīvai glabāšanai un

izgūšanai [1].

Paplašināmās indeksēšanas mehānisms dod iespēju izjaukt barjeru, kas līdz šim radīja

grūtības liela apjoma sarežģītu struktūru datu efektīvai glabāšanai un apstrādei datu bāzē.

Oracle piedāvā patiešām universālas paplašināmās indeksēšanas iespējas – ar attiecīgo

interfeisu iespējams kontrolēt datu glabāšanu, apstrādi, un izgūšanu no indeksa, analoģiski

tam, kā tas tiek darīts skalāro datu tipu gadījumā. Tādēļ arī darba praktiskā daļa veltīta

paplašināmā indeksa izstrādes jautājumam.

14

2. ORACLE KODOLA PAPLAŠINĀŠANAS IESPĒJU KLĀSTS

Oracle kodola paplašināšanas arhitektūrai jau tika veltīti daži vārdi. Savukārt šajā

nodaļā tiks izklāstītas Oracle kodola paplašināšanas iespējas.

Realizējot katru no kodola paplašinājumiem, programmētājam jāizpilda noteikta

darbību kopa. Saskarni starp programmētāja kodu un kodolu nodrošina vai interfeiss

(interface). Realizējot noteiktus interfeisus, ir iespējams integrēt kodolā vienu vai otru kodola

paplašinājumu un likt DBVS kodolam rīkoties attiecīgi kodola paplašinājuma realizācijai.

Turpmākajās apakšnodaļās tiks uzskaitītas kodola paplašināšanas tehnoloģiju

veidojoši stūrakmeņi, gan piedāvātie Oracle 8i versijā, gan arī tie, kas parādījās tik nākamajās

Oracle versijās (Oracle 9i un Oracle 10G).

2.1. Paplašināmo tipu sistēma

Paplašināmo tipu sistēma ir viens no būtiskākajiem Oracle kodola paplašinājumiem,

un varētu pat teikt, ka svarīgākais. Tas ir ne tikai iespēja papildināt jau definētos tipus, bet arī

rīks, ar kura palīdzību tiek realizēti vairāki kodola paplašinājumu interfeisi

Paplašināmo tipu sistēma nodrošina augsta līmeņa (SQL – bāzētu) interfeisu tipu

definēšanā. Tipu „uzvedība” var tikt realizēta Java, C/C++ vai arī PL/SQL valodā (tam tiks

veltīta viena no nākamajām apakšnodaļām). Oracle DBVS automātiski nodrošina zema

līmeņa infrastruktūras servisus, kuri nepieciešami datu ievadei – izvadei, daudzveidīgai

piekļuvei jaunajiem datu tipiem, optimizāciju datu pārraidei starp datu bāzi un lietojumiem

u.c. Pēc būtības paplašināmos tipu sistēma nodrošina sarežģītu strukturētu, daļēji strukturētu

un nestrukturētu datu glabāšanas iespējas datu bāzē.

Paplašināmo tipu sistēmas svarīgākā sastāvdaļa ir objektu tips, taču ar to nebeidzas

lietotāja definēto tipu klāsts. Apskatīsim tipus, kurus varam droši nosaukt par paplašināšanas

arhitektūras sastāvdaļu.

2.1.1. Objektu tipi

Objektu tipi, atšķirībā no SQL datu tipiem, ir lietotāja definēti. Tie pēc būtības satur

sevī datus (objektu tipa atribūti) un tiem raksturīgo uzvedību (objektu tipu metodes). Tos

izmanto, lai paplašinātu dzimto datu tipu nodrošināto iespēju modelēšanu. Ar objektu tipu

palīdzību var izstrādāt sarežģītus reālās pasaules entītiju modeļus. Objektu tips satur atribūtus,

kas attēlo entītiju struktūru, un metodes, kas realizē operācijas ar entītiju.

15

Objektu atribūti var tikt veidoti no dažādiem tipiem, ieskaitot „dzimtos” SQL tipus,

lielos objektus (LOB – large objects), kolekcijas, citus objektu tipus, vai arī atsauču tipus

(minētie tipu veidi ir aprakstīti turpmākajās apakšnodaļās).

Kā interfeiss objektu tipu definēšanai tiek izmantota Oracle SQL komanda CREATE

[OR REPLACE] TYPE nosaukums AS OBJECT (2.6. attēls).

2.6. att. Objektu tipa izveidošana

Kā redzams, objektu tipa ķermenis tiek definēts atsevišķi, pēc tipa izveidošanas. Tas

dod iespēju nākotnē mainīt objektu metožu uzvedību, neaizskarot pašu objektu tipu.

Objektu tipi var kalpot kā atribūti citos objektu tipos, vai arī kā tabulu kolonnas (2.7.

attēls). Oracle piedāvā divu veidu objektu iekļaušanu tabulās: objektu tabula, kad objektu tips

ir vienīgais tabulas atribūts, un objektu kolonna, kad objektu tips nav vienīgais tabulas

atribūts.

2.7. att. Objekti tips kā tabulas kolonna

Objektu tipu realizācijā ir iespējama arī mantošana – līdz ar to objektu tipi iegūst īstas

objektorientētās iezīmes. Objektu tipu metodes iespējams pārslogot un aizvietot, līdz ar to

objektu tipus var salīdzināt ar klasēm klasiskajā objektorientētajā programmēšanā. Objektu

eksemplārs var būt viens no mantiniekiem; Oracle SQL ir iekļautas speciālas komandas

apakštipu noteikšanai un salīdzināšanai. Tas viss dod iespēju pielietot objektorientēto pieeju

gan projektēšanā, gan arī problēmsfēras datu bāzes realizācijā.

16

Objektu tabulas gadījumā Oracle dod iespēju piekļūt tai gan kā parastai tabulai, gan arī

lietojot punkta notāciju atribūtu piekļuvei un metožu izpildei. Šī iespēja ir noderīga DB

savienošanai un pielāgošanai vecākiem lietojumiem, kuros tiek izmantoti standarta relāciju

SQL vaicājumi.

Lietojot objektu tipus ne tikai lokālu uzdevumu risināšanai vienas datu bāzes ietvaros,

bet gan arī ar nolūku realizēt pilnvērtīgu kodola paplašinājumu noteiktai problēmsfērai, kas

tiks izmantots vairākās datubāzēs, ir jāveic vēl viena papildus darbība – katram objektam

jāpiesaista objekta identifikators (OID – Object Identifier). Pēc noklusējuma katram lietotāja

definētajam objektam tiek piešķirts noteikts identifikators, kuru izvēlas DBVS. Līdz ar to,

izveidojot vienu un to pašu objektu tipu divās dažādās datu bāzēs, to identifikatori visdrīzāk

atšķirsies. Oracle izmanto objekta identifikatoru iekšējām operācijām ar objektu tipu, tādēļ

viena un tā paša objektu tipa identifikatora izmantošana ir nepieciešama, ja tiek plānots

dalīties ar objektu eksemplāriem starp datu bāzēm tādās operācijās, kā

eksportēšana/importēšana vai arī sadalītos vaicājumos.

Katram objektu tipam vajag piemērot unikālu objekta identifikatoru. Oracle paredzēta

speciāla metode SYS_OP_GUID(), ar kuru palīdzību ir iespējams izgūt unikālus objekta

identifikatorus. Līdz ar to kodola paplašinājuma objektu tipu projektēšanai un realizācijai būtu

jānotiek vienas datu bāzes ietvaros, ģenerējot katram objektu tipam savu unikālo objektu

identifikatoru.

2.1.2. Kolekcijas

Kolekcijas Oracle datu bāzēs ir analoģiskas konstrukcijas masīviem programmēšanā.

Vienā kolekcijas eksemplārā ir iespējams apvienot vairākus kāda noteikta tipa eksemplārus.

Oracle piedāvā triju veidu kolekcijas, kas atšķiras viena no otras gan pēc realizācijas, gan arī

pēc datu glabāšanas veida, gan arī ar noteiktiem ierobežojumiem.

Pirmos divus kolekciju tipus ir iespējams glabāt datu bāzē kā atribūtus; tie ir mainīga

izmēra masīvi (2.8.(a) attēls) un iekļautās tabulas (2.8.(b) attēls).

a) b)

17

2.8. att. Mainīga izmēra masīva (a) un iekļautās tabulas (b) kolekciju veidi

Mainīga izmēra masīvs pēc būtības līdzinās parastajiem viendimensijas masīviem ar

noteiktu maksimālo robežu, kas tiek norādīta tipa definēšanas brīdī. Līdz ar to katrā mainīga

izmēra masīva eksemplārā var glabāties jebkurš skaits elementu, kas nepārsniedz uzrādīto

robežu. Izdzēst atsevišķus elementus no tādas kolekcijas nav iespējams. Mainīga izmēra

masīva definēšanas komanda skatāma 2.9. attēlā.

2.9. att. Mainīga izmēra masīva izveidošana

Iekļautās tabulas pēc būtības ir līdzīgas mainīga izmēra masīviem, taču tām nenorāda

maksimālo robežu, kā arī ir iespējams dzēst atsevišķus iekļautās tabulas elementus. Protams,

arī to definēšanas sintakse atšķiras – lai izveidotu iekļautās tabulas tipu, komandā tiek

norādīta atslēga „AS TABLE OF pamattips” (.attēls).

2.10. att. Iekļautās tabulas kolekcijas tipa izveidošana

Arī iekļauto tabulu specifika ir atšķirīga. Ja mēs izveidojam objektu tipu ar vairākiem

atribūtiem, un, balstoties uz tā, iekļautās tabulas tipu, tad tik tiešām šī kolekcija tiek uztverta

kā tabula, kas ir ievietota noteiktajā pamattabulas atribūtā. Tādēļ, definējot iekļautās tabulas

kā atribūtus, nepieciešams norādīt arī tabulas nosaukumu to glabāšanai – Oracle glabā

iekļautās tabulas atsevišķajās tabulās (veicot interpretācijas operācijas automātiski). Tabulas,

kas satur iekļautās tabulas, tiek definētas, atsevišķi norādot, ka tā satur iekļauto tabulu

(NESTED TABLE .. ), kuras glabāšanai tiek norādīta tabula (STORE AS .. ). Iekļautās

tabulas kā atribūta izmantošana tabulā norādīta 2.11. attēlā.

18

2.11. att. Iekļautās tabulas kā atribūta izmantošana tabulā

Indeksētās tabulas (2.12. attēls) ar savu specifiku atšķiras no iepriekšējiem diviem

kolekciju tipiem pēc glabāšanas principa.

2.12. att. Indeksētas tabulas kolekcijas veids

Indeksētām tabulām nav nekāda limita, un tās tiek paplašinātas, piešķirot elementiem

vērtības, izmantojot indeksa numuru, kas vēl neeksistē. Līdz ar to vērtības var būt

„izkliedētas”, un indeksa numurs var kalpot arī kā noteikts informācijas nesējs.

Būtiskākais indeksēto tabulu ierobežojums ir tāds, ka tās nevar izmantot standarta

SQL komandās, līdz ar to arī kā atribūtus tabulās. Indeksētās tabulas tiek izmantotas tikai un

vienīgi PL/SQL blokos (PL/SQL Oracle procedurālā valoda tiks minēta nākamajās

apakšnodaļās). Tās definē kā tipu mainīgo definēšanas sadaļā (piem., anonīmajā blokā, kura

fragments skatāms 2.13. attēlā) un vēlāk izmanto programmas kodā dažādu operāciju

veikšanai ar datiem.

2.13. att. Indeksētas tabulas tipa deklarēšana anonīmajā blokā

Visi trīs kolekciju veidi ir ļoti jaudīgs instruments datu masīvu glabāšanai un

apstrādei, kas bieži vien ir nepieciešams dažādu problēmsfēru atsevišķu konstrukciju

definēšanai kodola paplašinājuma realizācijas gaitā.

19

2.1.3. Atsauču tips (REF)

Lai varētu definēt attieksmi starp dažādiem objektu tipu eksemplāriem, kas būtu

analoģiska ārējai atslēgai, Oracle ieviesa atsauču tipu (reference – REF). Šis tips līdzinās

atsaucēm (pointers) klasiskajā programmēšanā, jo norāda uz atsevišķa objekta tipa

eksemplāru. Atsaucēm ir ļoti liela nozīme navigācijā starp objektu eksemplāriem, jo tie

nodrošina ātru piekļuvi datiem. Speciālais REF operators tiek izmantots, lai iegūtu atsauci uz

rindiņas objektu, savukārt DEREF operatoru izmanto datu piekļuvei (2.14. attēls).

2.14. att. Atsauču izmantošana objektu – relāciju datu bāzēs

Atsauču definēšanas sintakse ir ļoti vienkārša – pirms pamattipa tiek norādīts atslēgas

vārds REF. Savukārt atsauces iegūšana uz konkrētu objektu notiek ar komandas SELECT

REF(objekts) INTO.. palīdzību, kas tiek darīts PL/SQL blokos (kā tas redzams 2.15. attēlā) –

sākumā tiek iegūta atsauce un saglabāta mainīgajā, savukārt pēc tam ar to tiek veiktas

vajadzīgās operācijas, piem., ievietošana atsauces atribūtā.

2.15. att. Atsauces definēšana un saglabāšana mainīgajā

Kaut arī atsauču iegūšana notiek tikai PL/SQL blokos, to izmantošana ir plaši

pielietojama dažādos vaicājumos, jo šī iespēja ir viens no relāciju – objektu datu bāžu

(RODB) stūrakmeņiem.

20

2.1.4. Lielie objekti un ārējie faili

Oracle piedāvāja lielo objektu tipu (large object – LOB), lai varētu operēt ar attēliem,

videoklipiem, skaņu, dokumentiem, kā arī jebkuriem citiem nestrukturētiem (vai daļēji

strukturētiem) datu veidiem. Lielie objekti tiek glabāti tādā veidā, lai optimizētu atmiņas

izmantošanu un nodrošinātu efektīvu pieeju šiem datiem.

Lielie objekti sastāv no lokatoriem un ar tiem asociētiem binārajiem vai simbolu

datiem. Lielo objektu lokatori tiek glabāti vienkopus ar pārējiem atribūtiem un, iekšējo lielo

objektu gadījumā, asociētie dati var tikt glabāti atsevišķā datu bāzes glabāšanas apgabalā.

Katrs LOB atribūts var tikt glabāts atsevišķā tabulu telpā, un pat dažādās sekundārās

glabāšanas ierīcēs. Kopsummā Oracle piedāvā četru veidu lielos objektus (trīs no tiem

glabāšanai datu bāzē un vienu kā ārējo failu), kuri ir uzskaitīti 2.2. tabulā.

2.2. tabula

Lielo objektu tipi

Lielā objekta tips Pielietojums

BLOB (Binary Large Object –

binārais lielais objekts)

Paredzēts jebkura tipa datu glabāšanai binārajā formātā. Tipiski

pielietojams nestrukturētu datu glabāšanai (piem., attēls, audioieraksts

u.c.)

CLOB (Character Large Object –

simbolu lielais objekts)

Saglabā teksta datus datu bāzē kā simbolus. Tiek pielietots liela izmēra

tekstu glabāšanai (tiek pielietots datu bāzes simbolu formāts).

NCLOB (National Character Lage

Object – nacionālo simbolu lielais

objekts)

Teksta glabāšana nacionālo simbolu formātā. Tiek pielietots liela izmēra

tekstu glabāšanai, kuros tiek izmantots datu bāzē nokonfigurētais

nacionālo simbolu formāts.

BFILE (External Binary File –

ārējais binārais fails)

Piekļuve binārajiem failiem, kas glabājas ārpus datu bāzes un satur

noteiktu informāciju. Šī informācija var tikt tikai nolasīta, bet tas

nenoliedz tālāko manipulāciju ar šiem datiem vai arī to interpretāciju un

saglabāšanu citu veidu lielajos objektos.

Līdz ar to lielie objekti dod iespēju glabāt nestrukturētus un daļēji strukturētus datus

kā tabulas (vai objektu tipa) atribūtu (2.16. attēls).

21

2.16. att. Lielie objekti datu bāzes tabulās

Lielo objektus definē kā jebkurus citus tabulu vai objektu tipu atribūtus. Taču tiem var

norādīt arī papildus opciju – glabāšanas parametrus, kā, piemēram, tabulu telpu, atmiņas

vienības bloku izmērus u.c. Ir pat iespējams atļaut/aizliegt lielo objektu datu glabāšanu

tabulas rindiņā (gadījumā, ja tā izmērs nav liels – glabāšanai tabulas rindiņā robeža ir 4

kilobaiti). Pateicoties glabāšanas parametriem ir iespējams optimizēt lielo objektu apstrādes

ātrdarbību.

Darbībām ar lielajiem objektiem Oracle ir paredzēta speciāla pakotne DBMS_LOB,

kura ietver sevī lielu klāstu visdažādāko procedūru un funkciju. Ar to palīdzību var izgūt

datus un kopēt tos fragmentiem, piem., buferos, kopēt datus lielajos objektos no failiem utt.

Arī Java un C/C++ valodu izmantošanas gadījumā programmētājam ir piedāvātas plašas

iespējas realizēt visas nepieciešamās operācijas ar lielajiem objektiem.

Lielo objektu eksemplāri pēc būtības datu bāzē var atrasties trijos stāvokļos:

NULL (ieraksts ir izveidots, taču tam nav nedz lokatora, nedz vērtības);

tukšs (lokators tiek izveidots, taču tam nav vērtības, t.i., lielā objekta apjoms ir nulle);

aizpildīts (lielā objekta eksemplārs satur gan lokatoru, gan datus).

Parasti tukša lielā objekta ievietošanai izmanto speciālās funkcijas: EMPTY_BLOB(),

EMPTY_CLOB(). Tā, piemēram, binārā objekta tabulas definēšanas un aizpildīšanas ar tukšu

objektu piemērs skatāms 2.17. attēlā.

22

2.17. att. Lielā objekta atribūta definēšana un tukšu datu ievadīšana tabulā

Ārējo lielo objektu gadījumā dati tiek glabāti failā ārpus datubāzes tabulu telpām –

operētājsistēmas failu sistēmā (2.18. attēls). Tādu lielo objektu datus var tikai nolasīt, kā arī

ārējo lielo objektu dati nepiedalās transakcijās. Neskatoties uz to, ārējiem failiem ir plašs

praktisks pielietojums. Ārējos objektus tipiski izmanto, lai uzglabātu [7]:

tādus bināros datus, kas lietojuma darbības laikā nemainās (piem., attēlus);

datus, kurus vēlāk ielādē citos lielos objektos (kā BLOB un CLOB) ar nolūku veikt

manipulācijas ar tiem;

datus, kas ir piemēroti baitu plūsmas piekļuvei, kā multimediju dati;

tikai lasīšanai paredzētus relatīvi liela izmēra datus – ar nolūku izvairīties no lielu datu

apjomu saglabāšanas datu bāzes tabulu telpās.

2.18. att. BFILE – iespēja piekļūt failu sistēmas faila datiem

Pēc būtības ārējo failu piesaistīšana BFILE atribūtam ir ļoti vienkārša – tas tiek

paveikts ar funkcijas BFILENAME palīdzību, kas atgriež attiecīgo lokatoru uz failu. Kā

argumentus šī funkcijas pieņem direktorijas pseidonīmu (kas tiek izveidots ar CREATE

DIRECTORY komandas palīdzību, norādot attiecīgo direktorijas ceļu) un faila nosaukumu kā

23

argumentus. Ārējā faila lielā objekta izmantošana tabulā, kā arī direktorijas izveidošanas un

faila piesaistes piemērs skatāms 2.19. attēlā.

2.19. att. BFILE izmantošanas piemērs

Kā redzams, direktorijas ‘dir_pseidonims’ tiek sasaistīts ar failu sistēmas direktoriju

‘c:\direktorija’, un vēlāk ārējā faila atribūtam tiek piesaistīts fails ar nosaukumu ‘fails’ no šīs

direktorijas. Pēc šīs operācijas var veikt datu nolasīšanu no ārējā faila.

2.2. Servera izpildvides

Viena no svarīgākajām Oracle paplašināšanas arhitektūras iezīmēm ir iespēja realizēt

procedūras un funkcijas dažādās programmēšanas valodās. Oracle piedāvā lietotāja funkcijas

un metodes realizēt dzimtajā PL/SQL valodā, Java vai arī C/C++ valodās. Katra funkcija var

tikt realizēta kādā noteiktā valodā; dažādas viena objekta metodes var tikt realizētas dažādās

valodās – līdz ar to programmētāja rīcībā ir brīvība, kas dod iespēju katras

funkcijas/procedūras gadījumā izvēlēties piemērotāko no valodām.

Ļoti lielu vērību Oracle piešķir drošības jautājumiem, kas ir saistīti ar tā saucamā

„nedrošā” programmas koda izpildi. Gadījumā, kad programma tiek realizēta PL/SQL valodā

(vai arī Java valodā, kura ir dziļi integrēta Oracle DBVS), tā var tikt izpildīta Oracle adrešu

telpā, jo, pateicoties dažādiem iekšējiem aizsardzības mehānismiem, tās izpilde nevar kaitēt

datu bāzes servera darbībai.

Savukārt C/C++ valodas kodu varētu nosaukt par „bīstamu”, jo viena no šīs valodas

specifikām ir programmētāja iespēja operēt ar atmiņu patvaļīgi, līdz ar to nav garantiju, ka

kāda kļūda algoritmā nekaitēs tās atmiņas adrešu telpai, kura ir pieejama programmai. Līdz ar

to šajā gadījumā Oracle tādas programmas izpilda ārējā adrešu telpā. Shematiski ārējās

procedūras izpildes process ir skatāms 2.20. attēlā.

24

2.20. att. Mijiedarbība starp lietotāja kodu un datu bāzes serveri

Pateicoties tādam sadalījumam tiek nodrošināta lielāka datu aizsardzība un izslēgta

nesankcionētu instrukciju izpilde, kas varētu kaitēt Oracle servera darbībai. Par šo drošību

atbild extproc (external procedure) – speciāls izdalīts ārējās procedūras aģents, kas nodrošina

ārējo procedūru izpildi. Neapšaubāmi, šajā shēmā parādās arī Listener process, kurš atbild uz

lietotāja procesu prasībām pieslēgties datu bāzei, un līdz ar to darbojas kā starpposms starp

lietojumu un datu bāzi. Izmantojot tīkla pieslēgumu, kuru nodibināja Listener process,

lietojums nodod ārējās procedūras aģentam bibliotēkas vārdu, ārējās procedūras nosaukumu

un visus nepieciešamos parametrus [6].

Līdz ar to var izskatīt procesus, kas notiek katrā no adrešu telpām [5].

Ārējā adrešu telpā:

ārējo procedūru aģents tiek izsaukts vai nu ar Listener procesu vai arī ar

bibliotēku;

ārējās procedūras aģents izsauc starpvalodu metožu servisu Oracle adrešu

telpā.

Oracle adrešu telpā:

starpvalodu metožu serviss piekļūst Oracle datu bāzei caur Oracle serveri;

starpvalodu metožu serviss izsauc vai nu Listener, vai nu ārējo procedūru

aģentu ārējā adrešu telpā.

25

2.2.1. PL/SQL

PL/SQL ir jaudīga procedurāla valoda, kuru Oracle piedāvā kā servera

programmēšanas valodu. Tā sevī iekļauj tradicionālās procedurālās valodas operācijas

(IF..THEN, ciklus, masīvu apstrādi), kā speciālas operācijas darbībai ar kursoriem un citiem

Oracle objektiem. Šo valodu izmantot ir ļoti ērti, jo nevajag realizēt nekādu speciālu saikni ar

serveri – programmēšana notiek servera pusē, izpildot kodu analoģiski SQL vaicājumiem.

Oracle ir bagāta ar standarta pakotnēm, kuras sevī iekļauj ļoti daudz vērtīgu funkciju

un kuras ir ērti izmantot PL/SQL blokos. Tas atvieglo datu bāzes servera programmēšanu un

samazina nepieciešamā koda daudzumu. Praktiskajā daļā izmantoju tieši PL/SQL valodu

kodola paplašinājuma iespēju demonstrācijai, jo tās iespējas deva iespēju realizēt visas

nepieciešamās funkcijas.

2.2.2. JAVA

Java tehnoloģijām ir izdalīta speciāla vieta Oracle tehnoloģijās. Oracle ir nodrošināts

ar augstas produktivitātes Java Virtuālo Mašīnu (Java Virtual Machine – JVM), kas dod

iespēju ar šo valodu realizēt glabājamās procedūras, objektu tipu metodes un funkcijas. Šī

JVM darbojas DB servera adrešu telpā, līdz ar to standarta Java uzvedība var tikt realizēta

datu bāzes iekšienē. Java datu bāzes pieslēgšanās bibliotēkas (Java Data Base Connectivity –

JDBC) dod iespēju darboties ar datiem objektorientētajā līmenī.

Java valoda var kalpot kā jaudīgs rīks gan dažādu datu bāzes metožu realizācijā, gan

arī datu bāzes klientu izstrādē, jo mūsdienās Java tehnoloģijas attīstās ļoti strauji un tiek plaši

pielietotas. Bagātīgais bibliotēku klāsts var atvieglot dažādu algoritmu realizāciju, kā arī,

pateicoties Java valodas īpatnībām, programmas koda izstrāde var prasīt mazāk laika, nekā

analoģiska koda izstrāde C/C++ valodās.

2.2.3. C/C++

Kaut arī PL/SQL un Java nodrošina diezgan jaudīgus un ērtus rīkus datu apstrādei,

tomēr bieži ir gadījumi, kad ir nepieciešama augsta līmeņa efektivitāte datu apstrādei (piem.,

dažu sarežģītu algoritmu realizācijai, kuru izstrādē ātrdarbība ir kritiskā vieta). Šajā gadījumā

lietderīgāk izmantot C/C++ programmēšanas valodas tāda veida funkciju realizēšanai.

Lai nodrošinātu dažāda veida argumentu nodošanu C/C++ funkcijām un saskarni ar

serveri, Oracle ir izstrādājusi speciālas bibliotēkas, kuras jāpieslēdz programmas izstrādes

gaitā. Šo bibliotēku kopumu sauc par Oracle izsaukumu interfeisu (Oracle Call Interface –

26

OCI). Tas nodrošina lietojumu programmēšanas interfeisu (Application Programming

Interface – API), kas dod iespēju izmantot funkciju izsaukumus ar nolūku piekļūt Oracle datu

bāzes serverim un kontrolēt visas SQL vaicājumu izpildes fāzes. OCI atbalsta datu tipus,

izsaukumu pieņēmumus, sintaksi, kā arī C un C++ semantiku.

2.3. Paplašināmās indeksēšanas mehānisms

Indeksēšana ir viens no būtiskākajiem mehānismiem datu apstrādes optimizācijā, jo

dod iespēju ātri piekļūt tabulas rindiņām. Indekss tiek izveidots vienai vai vairākām tabulas

kolonnām. Pēc būtības indekss ir tabulas daļas kopija, kas ir strukturēta specifiskā formātā, un

ar šīs struktūras palīdzību ir iespējams atrast prasītās vērtības krietni ātrāk, izvairoties no

pilnas rindiņu izskatīšanas, jeb skenēšanas.

Indeksu klasiskais salīdzināšanas piemērs ir grāmatas satura rādītājs vai arī alfabētiskā

secībā sakārtots terminu rādītājs. Pateicoties šiem rīkiem lasītājs var krietni ātrāk atrast

vajadzīgo nodaļu, jo satura un terminu rādītāja izskatīšana aizņem daudz mazāk laika, nekā

visas grāmatas šķirstīšana. Termini ir sakārtoti alfabētiskā secībā, līdz ar to vajadzīgā vārda

atrašana aizņem pavisam maz laika; savukārt katram terminam ir minētas lappuses, kurās šis

termins tiek sastapts. Līdzīgi ir ar indeksiem. Tie ir organizēti tādā veidā, ka meklējamās

vērtības tiek atrastas samērā ātri, un tām ir piesaistītas attiecīgās pamattabulas rindiņas.

Tipiskās DBVS atbalsta tikai dažas datu indeksēšanas metodes. Balansētie koki

(Balanced tree, jeb B-tree) tiek izmantoti skaitlisko tipu indeksēšanai. Balansētais koks pēc

būtības ir grafa struktūra koks, un attiecīgo vērtību pārmeklēšana tajā notiek, virzoties uz

dziļākajiem koka līmeņiem, līdz netiek sasniegtas koka strupceļa virsotnes. Balansēto koku

algoritms nodrošina efektīvu datu ievietošanu un izdzēšanu, rūpīgi balansējot koka plašumu

un dziļumu.

Heša indeksi (hash indexes) ir vairāk paredzēti simbolisko vērtību indeksēšanai. Tie

dod ātru pieeju specifiskajam ieraksta, balstoties uz dotā lauka izskaitļoto vērtību, ko sauc par

heša vērtību. Katrai indeksējamās kolonnas vērtībai tiek izskaitļota heša vērtība, un rezultāti

saglabāti indeksa tabulā. Tādā veidā, meklējot noteiktas vērtības, datu bāzes vadības sistēma

var izskaitļot to heša vērtību un veikt attiecīgo atlasi no indeksa tabulas datiem.

Tie bija izplatītākie indeksēšanas algoritmi, kuri gan ir piemērojami tikai skalāriem

standarta datu tipiem. Taču, parādoties iespējai glabāt datu bāzē tādus datus, kuru struktūra

DBVS nav zināma, parādījās arī vajadzība pēc tādu datu indeksācijas, jo bieži vien standarta

indeksācijas mehānismi ir vai nu nepielietojami, vai nu DBVS nezin, kā tos pielietot noteiktai

27

lietotāja datu struktūrai.

Tā kā indeksēšana dažādiem datu tipiem var krasi atšķirties, Oracle piedāvā universālu

paplašināmās indeksācijas mehānismu, ar kura palīdzību ir iespējams[5]:

definēt problēmsfēras indeksu kā jaunu indeksa tipu;

glabāt indeksa datus vai nu Oracle DB (tabulu veidā), vai arī ārpus tās;

kontrolēt, izgūt un izmantot indeksu datus, lai optimālāk realizētu lietotāja vaicājumus.

Tādus indeksus sauksim par problēmsfēras indeksiem, jo tie indeksē datus

problēmsfēras specifiskajā veidā.

Kad DB serveris kontrolē problēmsfēras indeksu glabāšanu, kodola paplašinājumam

nepieciešams [2]:

definēt indeksa formātu un saturu;

izveidot, izdzēst un atjaunot indeksu;

piekļūt un interpretēt indeksa saturu (vaicājumu izpildes laikā).

Atbalstot paplašināmo indeksēšanu, Oracle serveris ievērojami samazina to pūļu

līmeni, kas ir nepieciešams augstas ātrdarbības sasniegšanai sarežģītu datu tipu apstrādē.

Indeksa tipa definēšana notiek pakāpeniski. Sākumā tiek definēti problēmsfēras

operatori, tad objektu tips ar tā ķermeni, kas realizē pilnvērtīgai indeksa darbībai

nepieciešamās metodes, un tikai tad tiek izveidots indeksa tips, balstoties uz dotajiem uz

iepriekš izveidotajiem operatoriem un objektu tipu.

Oracle paplašināmo indeksu darbības pamatprincips ir pamattabulas rindiņu

identifikatoru glabāšana kopā ar datiem – darbojoties indeksa mehānismam vaicājuma laikā,

datu bāzes vadības sistēmai tiek nodotas to rindiņu identifikatori, kas apmierina specializēto

vaicājumu (indeksa mehānisms var tikt iedarbināts, kad vaicājuma WHERE daļā parādās

problēmsfēras operators, kas ir piesaistīts indeksa tipam). Tādā veidā, ja vien ir iespējams,

rindiņas, kuras var tikt izgūtas, balstoties uz operatora predikāta izteiksmi, tiek izgūtas

pateicoties indeksa mehānisma darbībai,- ja vien optimizators nosaka, ka griešanās pie

problēmsfēras indeksa ir izdevīgāka (paplašināmā optimizatora specifika tiks apskatīta

nākamajā apakšnodaļā).

Darba praktiskajā daļā tiks demonstrēta problēmsfēras indeksa izveidošanai konkrētai

problēmai, savukārt 2.3. tabulā ir aprakstītas svarīgākās indeksa interfeisa metodes, kuras

programmētājam jārealizē, lai indeksācijas mehānisms darbotos korekti.

28

2.3. tabula

Indeksa interfeisa metožu raksturojums

Indkesa metode Apraksts

ODCIGetInterfaces Atgriež interfeisa versiju realizējamajam indeksam („ODCIINDEX2” gadījumā,

ja izmanto jaunākas Oracle 9i iespējas, pretējā gadījumā „ODCIINDEX1”).

ODCIIndexCreate Izveido tabulu, kur tiek glabāti indeksējamie dati, tiek izsaukta indeksa izveides

laikā. Jāparedz gadījumi, kad pamattabula nav tukša.

ODCIIndexDrop Izdzēš tabulu ar indeksējamajiem datiem. Tiek izsaukta DROP INDEX vai

pamattabulas dzēšanas gadījumā.

ODCIIndexAlter Atjauno indeksa tabulu, balstoties uz izmainītajiem indeksa parametriem. Tiek

izsaukta ALTER INDEX gadījumā.

ODCIIndexStart Inicializē indeksa skenēšanu iepriekšdefinētam un ar indeksa tipu sasaistītam

operatoram. Pēc būtības nodefinē kursoru vaicājumam, kas tiek konstruēts uz

operatora bāzes (gadījumā, kad vaicājumā parādās operatori, kuri var tikt

analizēti ar indeksa palīdzību).

ODCIIndexFetch Atgriež ROWID katrai rindiņai, kura apmierina operatora predikātu, t.i., ar

indeksa palīdzību izgūstam nepieciešamās rindiņas.

ODCIIndexClose Beidz vaicājuma izpildi, aizver kursoru

ODCIIndexInsert Maina indeksa struktūru gadījumā, kad pamattabulā tiek ievietoti dati.

ODCIIndexDelete Maina indeksa struktūru gadījumā, kad no pamattabulas tiek izdzēsti dati.

ODCIIndexUpdate Maina indeksa struktūru gadījumā, kad pamattabulā tiek atjaunoti dati.

ODCIIndexGetMetadata

Dod iespēju eksportēt un importēt ar indeksu realizāciju saistītus metadatus.

Jāpiebilst, ka lokālo problēmsfēras indeksu gadījumā (par ko tiks minēts Oracle

kodola paplašinājumu attīstībai veltītajā nodaļā) ir jārealizē vēl dažas metodes –

ODCIIndexSplitPartition, ODCIIndexMergePartition un ODCIIndexExchangePartition, kuras

kontrolē darbības ar dalīto tabulu partīcijām. Bet tās ir tikai optimālas metodes, un

nepieciešamas tikai tajā gadījumā, ja tabula ar problēmsfēras objektu kolonnu tiks sadalīta

partīcijās.

Arī Oracle Spatial – telpisko datu apstrādes kodola paplašinājuma – problēmsfēras

indeksi tika realizēti ar paplašināmās indeksēšanas mehānismu. Piemēram, viens no telpisko

29

indeksu veidiem ir R-koka indekss. Šī indeksa darbības princips ir katras ģeometrijas

aproksimācija ar tās mazāko ierobežojuma taisnstūri. Tādā veidā tiek aptverta visu ģeometriju

kopa, un izveidots tādu taisnstūru koks (2.21. attēls)

2.21. att. Telpisko datu R-koka indeksēšanas metode

Indeksa interfeisa objektu tips saucas RTREE_INDEX_METHOD, kas satur visas

nepieciešamās metodes indeksa darbības kontrolēšanai (2.22. attēls).

2.22. att. Objektu tips ar R-koka indeksa interfeisa metodēm

Kā redzams, indeksa tipam paredzētais objektu tips satur ne tikai visas nepieciešamās

metodes, bet arī papildus atribūtu. Tas var kalpot kā palīgmainīgais dažādos indeksa apstrādes

procesos. Arī praktiskajā daļā realizētajā indeksa tipa objekta metodē ir atribūts, kas kalpo kā

kursors indeksa skenēšanas vaicājuma kontrolēšanai.

2.3.1. Lietotāju definēti operatori un indeksēšana

Operatori ir augsta līmeņa shēmas elementi. To realizācija ir ļoti cieši sasaistīta ar

paplašināmo indeksēšanu. Gadījumā, ja noteikts operators, kas ir piesaistīts problēmsfēras

30

indeksa tipam, ir sastopams vaicājuma WHERE daļā, tad indeksācijas mehānisms, balstoties

uz operatora predikātu informāciju, var optimizēt vaicājumu un iedarbināt indeksēšanas

mehānismu, t.i., neveicot pilnu tabulas skenēšanu, bet gan analizējot indeksa struktūru –

indeksam tiks nodota visa informācija par operatora predikāta izteiksmi, uz kā bāzes tad arī

notiks attiecīgās darbības pamattabulas rindiņu izgūšanai.

Lietotāju definēti operatori tiek piesaistīti noteiktai funkcijai, kura kā pirmo parametru

noteikti satur objektu tipu, kuram šis operators tiek piemērots.

Sākumā tiek izveidotas attiecīgās funkcijas, un tad operatori – ar CREATE

OPERATOR palīdzību. Praktiskajā daļā tiks apskatīti operatoru izveide un indeksa tipa

izveide problēmsfēras objektu tipa indeksēšanai.

2.4. Paplašināmais optimizators

Vaicājumu optimizēšana ir visefektīvākā SQL vaicājuma ceļa izvēles process [2]. Kad

izmaksu optimizators tika pirmo reizi piedāvāts Oracle7 versijā, Oracle atbalstīja tikai

standarta relāciju datus [5]. Objektu parādīšanās paplašināja atbalstāmos datu tipus un

funkcijas. Paplašināmās indeksēšanas iespējas piedāvāja jaunas, lietotāja – definētas, datu

piekļuves metodes.

Paplašināmais optimizators dod iespēju lietotāju definētu funkciju un indeksu

autoriem izveidot statistikas kolekcionēšanas, selektivitātes, kā arī izmaksu funkcijas, kuras

izmanto optimizators, izvēloties vaicājuma plānu. Optimizatora izmaksu modelis tiek

paplašināts, lai integrētu lietotāja nodrošinātu informāciju par procesora un ievades/izvades

izmaksām, kur procesora izmaksas pēc būtības ir izmantoto datora instrukciju skaits, bet

ievades/izvades izmaksas ir apstrādāto datu bloku skaits.

Ar paplašināmā optimizatora palīdzību ir iespējams [5]:

sasaistīt izmaksu funkcijas ar problēmsfēru indeksiem, indeksu tipiem, pakotnēm, kā

arī atsevišķām funkcijām; optimizators var novērtēt problēmsfēras indeksa skenēšanas

izmaksas (Oracle 10g versijā iespējams vērtēt arī atsevišķu partīciju skenēšanas

izmaksas dalītu tabulu gadījumā);

asociēt selektivitātes funkcijas ar objektu tipu metodēm, pakotņu funkcijām vai arī

atsevišķām funkcijām;

asociēt statistikas kolekcionēšanas funkcijas ar problēmsfēras indeksiem un tabulu

kolonnām;

kārtot predikātus ar funkcijām, balstoties uz izmaksām;

31

izvēlēties lietotāja definētu pieejas metodi (problēmsfēras indeksi) tabulai, balstoties

uz piekļuves izmaksām;

izmantot speciālu DBMS_STATS pakotni ar nolūku izsaukt lietotāja definētas

statistikas kolekcionēšanas un dzēšanas funkcijas;

izmantot jaunus datu vārdnīcas skatus, lai iekļautu informāciju par statistikas

kolekcionēšanu, izmaksu, vai selektivitātes funkcijām, kas tiek asociētas ar kolonnām,

problēmsfēras indeksiem, indeksu tipiem vai funkcijām;

pievienot padomus (hints) ar nolūku ietekmēt funkciju predikātu izskaitļošanas

kārtību.

Optimizators ģenerē izpildes plānu SQL un datu manipulācijas valodas vaicājumiem –

SELECT, INSERT, UPDATE, vai arī DELETE izteiksmēm.

Izpildes plāns iekļauj pieejas metodi katrai tabulai no FROM daļas, un kārtu, kas tiek

saukta par apvienošanas kārtu, tabulām no FROM daļas. Sistēmas definētas pieejas metodes

iekļauj indeksus, hešu klasterus un tabulas skenēšanu. Optimizators izvēlas plānu, ģenerējot

apvienošanas kārtas kopu (permutācijas), izskaitļojot katras izmaksas, un tad izvēloties

procesu ar zemākajām izmaksām. Katrai apvienošanas kārtas tabulai optimizators izskaitļo

katras iespējamās piekļuves un apvienošanas metodes izmaksas, pēc tam izvēlas to, kurai ir

zemākās izmaksas. Apvienošanas kārtas izmaksas ir pieejas un apvienošanas metožu izmaksu

summa. Izmaksas izskaitļo ar algoritmu palīdzību, kas kopā ietver izmaksu modeli. Izmaksu

modelis iekļauj sevī mainīgu detalizācijas līmeni par fizisko vidi, kurā vaicājums tiek

izpildīts. 2.23. attēlā redzama izmaksu optimizatora (IO) darbība vaicājuma laikā: no

iespējamajiem ceļiem (C1, C2, C3 un C4) tiek izvēlēts tas ceļš, kura izmaksas (I) ir

minimālas; rezultātā izmaksu optimizators ietekmē apvienošanas kārtu, t.i., kādā secībā tiks

apskatītas tabulas no WHERE daļas, kā arī pieejas metodes – kādā veidā dati tiks atlasīti no

katras tabulas. Ar padomu (hints) palīdzību var tiešā veidā ietekmēt funkciju predikātu

izskaitļošanas kārtību.

32

2.23. att. Izmaksu optimizatora ietekme uz izpildes plānu

Lietotāja definētajiem operatoriem un problēmsfēras indeksiem paplašināmais

optimizators dod iespēju kontrolēt trīs pamatkomponentes, kuras tiek izmantotas, izvēloties

vaicājuma izpildes plānu: statistiku, selektivitāti un izmaksas.

2.4.1. Statistika

Optimizators izmanto statistiku par vaicājumā minētajiem objektiem, lai izskaitļotu

selektivitāti un izmaksas [2], tātad, tas ir rīks, kas nodrošina papildinformāciju par

problēmsfēras objektiem. Realizējot paplašināmā optimizatora metodes, statistikai tiek

paredzēta metode ODCIStatsCollect, ar kuras palīdzību tiks savākta statistika par noteikta tipa

kolonnu (parasti saista ar problēmsfēras tipa kolonnu, kas tiek indeksēta). Tas, ko tieši veic šī

metode, nav zināms. Taču tās savāktā informācija kalpos par pamatu selektivitātes un

izmaksu analīzei.

Šī metode tiek izmantota tajā gadījumā, ja statistika tiek asociēta ar noteiktu tabulas

kolonnu, un vēlāk izsaukta ANALYZE komanda – kā tas ir redzams 2.24. attēlā.

2.24. att. Lietotāja definētas statistikas pielietojums

Statistika tiek asociēta ar noteiktu kolonnu, izmantojot ODCIStatsTips objektu tipu,

kuram noteikti jārealizē ODCIStatsCollect metodi analizējamās kolonnas tipam.

33

2.4.2. Selektivitāte

Optimizators izmanto statistiku, lai izskaitļotu predikātu selektivitāti [2]. Predikāta

selektivitāte ir ar predikātu izgūstamo rindiņu skaita dalījums ar kopējo rindiņu skaitu (līdz ar

to tas ir skaitlis no intervālā [0; 1]). Praktiskajā daļā izmantotajam piemēram varētu izveidot

statistikas savākšanas funkciju, kas vienkārši katram reģionam atrastu minimālo un

maksimālo vērtību. Balstoties uz šo informāciju, varētu aptuveni novērtēt, cik procentuāli

daudz rindiņu tiks izgūtas, ja tiks meklēta noteikta vērtība. Dažos gadījumos tas var

nodrošināt izvairīšanos no datu pārlases. Ja mēs atlasām datus, izvēloties tās datu rindiņas,

kurām noteikta reģiona vērtība ir vienāda ar prasīto vērtību, bet prasītā vērtība neietilpst

intervālā starp minimālo un maksimālo vērtību, tad, neapšaubāmi, selektivitāte tādam

predikātam būs vienāda ar 0,- neviena datu rindiņa neapmierinās predikāta vērtību.

Selektivitāte palīdz izvēlēties optimālo apvienošanas kārtu, un piekļuves metodes, balstoties

uz WHERE daļā norādītajiem predikātiem.

2.4.3. Izmaksas

Optimizators novērtē dažādu piekļuves ceļu izmaksas, lai izvēlētos optimālo plānu.

Piemēram, tas var izskaitļot indeksa izmantošanas un pilnas tabulas skenēšanas izmaksas, lai

varētu izvēlēties starp šīm divām pieejas metodēm [2]. Kodola paplašinājuma definēto

problēmsfēras indeksu gadījumā optimizators nezin neko par indeksu iekšējo glabāšanas

struktūru. Tādā veidā optimizators nevar precīzi izvērtēt tādu indeksu izmantošanas izmaksas.

Tāpat optimizators pēc noklusējuma nezin neko par lietotāja funkciju procesora resursu

patēriņu. Funkcijas var arī patērēt ievada/izvades resursus, gadījumā ja tā apstrādā lielo

objektu eksemplāru

Lai varētu veikt tāda veida analīzi, paplašināmais optimizators realizē noteiktas

funkcijas, ar kuru palīdzību tiek noteiktas lietotāju definēto funkciju un problēmsfēras indeksu

izmantošanas izmaksas.

Lietotāja definētās izmaksu funkcijas var atgriezt trīs parametrus, kas raksturo lietotāja

funkcijas vai problēmsfēras indeksa izmantošanas resursu ietilpību:

cpu – datora instrukciju skaits, kuras izpilda funkcija vai indeksa implementācija;

i/o – problēmsfēras indeksa vai funkcijas nolasīto datu bloku skaits

network – pārraidīto bloku skaits tīklā.

34

2.4. tabula

Paplašināmā optimizatora interfeisa metožu raksturojumi

Metode Apraksts

ODCIStatsCollect Metode statistikas savākšanai kolonnai vai indeksa datiem.

ODCIStatsDelete Izdzēš statistiku par kolonnu vai indeksa datiem.

ODCIStatsSelectivity Novērtē lietotāja definētu funkcijas vai operatora predikāta selektivitāti.

ODCIStatsFunctionCost Balstoties uz uzdotajiem funkcijas parametriem, izskaitļo funkcijas izpildes

izmaksas.

ODCIStatsIndexCost Balstoties uz uzdoto operatora predikātu, izskaitļo problēmsfēras indeksa

skenēšanas izmaksas.

2.5. Lietotāja definētas agregātfunkcijas

Oracle nodrošina lietotāju ar noteiktām visiem labi zināmām agregātfunkcijām MAX,

MIN, SUM u.c., kas veic operācijas ar rindiņu kopām. Šīs definētās agregātfunkcijas var tikt

izmantotas tikai skalāriem datiem. Taču bieži rodas vajadzība definēt kādu jaunu funkciju

datu analīzei, vai arī agregātfunkciju, kas darbotos ar sarežģītiem – lietotāja definētajiem

datiem, līdz ar to realizējot ar problēmsfēru saistīto loģiku.

Lietotāju definētas agregātfunkcijas, analoģiski paplašināmās indeksācijas

mehānismam un paplašināmajam optimizatoram, tiek reģistrētas serverī ar interfeisu

palīdzību; šajā gadījumā tas ir ODCIAggregate interfeiss, kuram ir paredzētas metodes

agregācijas uzsākšanai (ODCIAggregateInititalize), agregācijas solim

(ODCIAggregateIterate), kā arī agregācijas nobeigšanai (ODCIAggregateTerminate).

Lietotāja definētas agregātfunkcijas var piemērot jebkura tipa datiem, līdz ar to arī

skalārajiem datiem tas varētu būt ļoti noderīgs rīks, piem., strādājot ar sarežģītiem

finansiāliem vai zinātniskiem statistikas datiem.

35

2.25. att. Agregātfunkcijas darbības shēma

Efektivitātes apsvērumu dēļ agregātfunkcijas cikli bieži vien tiek izpildīti paralēli. T.i.,

vienas datu kopas dažādiem apgabaliem var tikt piemērota vien un tā pati agregātfunkcija, bet

vēlāk to rezultāti apvienoti attiecīgā veidā. Piem., ja tā ir summa, tad tiek saskaitīta paralēlajos

procesos iegūtās summas. Ja tā ir mazākās vērtības, tad rezultāts ir mazākā vērtība no

paralēlajiem procesiem. Shematiski tādas agregātfunkcijas darbība ir parādīta . attēlā.

Kā redzams, pirms cikla nobeigšanas jāizpildās apvienojuma funkcijai. Tādu

agregātfunkciju realizētajā objektu tipā ir papildus funkcija – ODCIAggregateMerge, kura

veic apvienošanas funkcijas.

2.26. att. Paralēlās agregātfunkcijas darbības shēma

Informācija par lietotāju definētu agregātfunkcijas interfeisa metodēm ir apkopota 2.5.

tabulā.

2.5. tabula

Agregātfunkciju interfeisa metožu raksturojumi

Metode Apraksts

ODCIAggregateInitialize Šo metodi Oracle izsauc, lai inicializētu lietotāja definētu agregātfunkciju

skaitļošanas procesu. Inicializēta agregāta konteksts tiek nodots Oracle kā

objektu tipa eksemplārs (kas var saturēt agregātvērtības skaitļošanai

36

Metode Apraksts

nepieciešamos atribūtus)

ODCIAggregateIterate Metode tiek atkārtoti izsaukta katrai agregātfunkcijā pielietotajai vērtībai,

kas tiek nodota funkcijai kā arguments. Arī ar šo agregātvērtības

skaitļošanas sesiju saistītais objektu tips (konteksts) tiek nodots kā

arguments. Rezultātā funkcija apstrādā jauno vērtību(as), un atgriež

DBVS atjaunoto kontekstu. Jāpiebilst, ka NULL vērtības netiek

apstrādātas.

ODCIAggregateMerge Metodi Oracle izsauc paralēlās agregātfunkciju skaitļošanas gadījumā. Tā

kombinē divus agregāciju kontekstus un atgriež galīgo rezultātu.

ODCIAggregateTerminate Metode tiek izsaukta agregācijas pēdējā solī. Metode atgriež rezultāta

vērtību, balstoties uz agregācijas kontekstu.

2.6. Abstraktās tabulas un tabulu funkcijas

Kodola paplašinājuma izstrādātājam var rasties vajadzība piekļūt datiem, kas ir ārpus

datu bāzes vai arī atrodas lielo objektu eksemplāros. Tādos gadījumos DBVS nezin neko par

šo datu struktūru, pat ja tie ir noteiktā veidā strukturēti.

Šajā gadījumā ir iespējams rīkoties divos veidos:

1. izveidot abstrakto tabulu;

2. vaicājumos izmantot tabulu funkciju.

2.6.1. Abstraktās tabulas

Abstraktā tabula tiek interpretēta kā parastā, taču par to saturu, kas pēc būtības ir

virtuāls, atbild noteikts objektu tips, kas realizē ODCITable interfeisu. Tipisks gadījums

varētu būt kāds fails failu sistēmā, piem., XML fails, kura struktūra nav zināma datu bāzei,

bet tajā glabājas noteikti tabulāri interpretējami dati (2.27. attēls)

37

2.27. att. Abstraktās tabulas – iespēja interpretēt datus tabulu veidā

Informācija par svarīgākajām abstrakto tabulu interfeisa metodēm ir apkopota 2.6.

tabulā.

2.6. tabula

Abstrakto tabulu interfeisa metožu raksturojumi

Metode Apraksts

ODCITableStart Uzsāk virtuālo tabulas izskatīšanu.

ODCITableFetch Atgriež rindiņu kopu kārtējā solī.

ODCITableClose Veic nobeigšanas procedūras, kad datu izgūšana ir beigusies.

Vizuāli šo metožu darbību raksturo 2.28. attēls. Kā redzams, abstrakto tabulu darbības

princips ir līdzīgs kursoriem – kamēr rezultāts nav NULL, notiek izgūstamo datu apstrāde

(t.i., tā tiek interpretēta kā virtuāla tabula). Savukārt, kad šis process beidzas, ar

ODCITableClose metodes palīdzību tiek veikti nobeigšanas darbi (piem., aizvērti datu bāzes

kursori vai arī attīrītas temporālās struktūras vai arī tabulas).

38

2.28. att. ODCITable interfeisa metožu darbības shēma

Rezultātā lietotāja dati tiek interpretēti tabulas veidā, un tālākā darbība ar tādu tabulu

norit gluži kā ar parastu. Ja ir vajadzība datus papildināt vai izdzēst (kas, protams, virtuālās

tabulas gadījumā nav iespējams), tad var veidot uz tādas tabulas balstītu skatu un realizēt

INSTEAD OF trigeri, kas imitēs datu ierakstīšanu šajā tabulā vai dzēšanu no tās (t.i.,

darbosies ar datu avotu).

Abstraktās tabulas izveidošanas piemērs ir skatāms 2.29. attēlā.

2.29. att. Abstraktās tabulas izveidošana

Tagad, griežoties pie abstraktās tabulas, iteratīvai rindiņu izgūšanai tiks pielietotas

ODCITableTips objektu tipa metodes, attiecīgi 2.28. attēlā redzamajai shēmai.

2.6.2. Tabulu funkcijas

Kodola paplašinājuma izstrādātājam var parādīties vajadzība pēc dinamiskas,

iteratīvas uzvedības pār virtuāli izveidotajām tabulām. Paplašināšanas arhitektūra tāpat

nodrošina iteratīvas tabulu funkcijas kā papildinājumu abstraktām tabulām [2].

39

Tabulu funkcijas ir tādas funkcijas, kas rezultātā izdod rindiņu kolekciju (vai nu

iekļautu tabulu vai arī VARRAY – mainīga izmēra masīvu) ar nolūku veikt vaicājumus šai

datu kopai, analoģiski fiziskajai datu bāzes tabulai. Tabulu funkcija var tikt izmantota gluži kā

datu bāzes tabulas nosaukums vaicājuma FROM daļā.

Tādas funkcijas ir bieži noderīgas datu interpretācijai, jo kā argumentus var pieņemt

gan kolekciju tipu, gan arī kursora mainīgo (REF CURSOR). Taču pēc būtības tās ir ļoti

līdzīgas abstraktajām tabulām – tās tiek piesaistītas ODCITable interfeisa metodes

realizējošam objektu tipam.

Atkarībā no tā, vai noteiktu virtuālu datu izgūšanā ir nepieciešamība norādīt

parametrus, jāizvēlas attiecīgais veids, kā šo izgūšanu realizēt – vai nu abstraktās tabulas

(kuros vai nu netiek norādīti nekādi parametri, vai arī tie tiek norādīti tabulas izveidošanas

brīdī), vai arī tabulu funkcijas (kurās ik reizes var norādīt dažādus parametrus).

40

3. ORACLE KODOLA PAPLAŠINĀJUMU ATTĪSTĪBA

Lai arī liela daļa kodola paplašināšanas iespēju tika realizēta tieši Oracle 8i versijā,

gadu laikā šai arhitektūrai bija jāattīstās. Nākamajās Oracle versijās – Oracle 9i un Oracle

10G – parādījās jaunas kodola paplašināšanas iespējas, kā arī tika uzlabotas vai papildinātas

vecās. Neskatoties uz to, Oracle saglabāja paplašināšanas arhitektūras pamatrealizāciju.

Kodola paplašinājumi, realizēti Oracle 8i versijā, joprojām tiek plaši izmantoti. Daži tika

minimāli koriģēti, iekļaujot jaunās iespējas, taču jebkura vecā kodola paplašinājuma

realizācija varēja tikt pielietota jaunākajās versijās. Tā jaunākas Oracle DBVS versijas

realizēja savienojamību ar vecajām versijām.

Taču lietderīgi gūt ieskatu kodola paplašināšanas attīstībā, lai skaidri varētu nošķirt

kodola paplašinājumu iespējas un ierobežojumus gan versijā Oracle 8i, gan arī nākamajās

divās – Oracle 9i un Oracle 10G.

3.30. attēls skaidri parāda Oracle kodola paplašināšanas arhitektūras attīstību triju

pēdējo versiju ietvaros.

3.30. att. Oracle kodola paplašināšanas arhitektūras attīstība

Katra no versijām tiks apskatīta nākamajās apakšnodaļās.

41

3.1. Oracle 8i

Oracle 8i bija pirmā no Oracle DBVS sērijas, kas nāca klajā ar paplašināšanas

arhitektūru. Kā redzams 3.30. attēla diagrammā, šī versija realizē kodola paplašinājumu

pamatelementus, kas kļūst par mugurkaulu paplašināmās arhitektūras attīstībā.

Paplašināmā tipu sistēma ;

Parādās iespēja definēt lietotāju tipus ar tiem saistītu funkcionālo loģiku; iekļauj

objektu tipus, kolekcijas (iekļautās tabulas un mainīga izmēra masīvs), lielos objektus.

Paplašināmā servera izpildvide ;

Iespēja realizēt objektu metodes, kā arī funkcijas un procedūras gan Oracle

izstrādātajā PL/SQL procedūrvalodā, kura ir integrēta datu bāzē, gan arī Java un C/C++

valodās, izmantojot dažādus Oracle piedāvātos servisus vaicājumu apstrādei, kļūdu

kontrolei u.c. Ārējo procedūru aģents nodrošina datu bāzes adrešu telpas aizsardzību un

realizē saikni starp programmām, kas realizētas kā ārējās bibliotēkas (kā tar ir C/C++

gadījumā).

Paplašināmā indeksēšana

Tiek definēts paplašināmā indeksēšanas mehānisma interfeisa metodes. Nākamajās

versijās tās gan tiek papildinātas gan ar parametriem, gan ar iespējām, taču indeksēšanas

mehānisma loģika paliek tieši šajā versijā piedāvātā.

Paplašināmais optimizators

Analoģiski paplašināmās indeksēšanas mehānismam, būtiskākā paplašināmā

optimizatora loģika tika realizēta Oracle 8i versijā.

Acīmredzami, šo iespēju pietika, lai jau Oracle 8i versijas ietvaros tiktu izstrādāti

vairāki kodola paplašinājumi (Oracle Spatial, interMedia, kā arī Oracle TimeSeries, kura

attīstību Oracle gan neatbalstīja turpmākajās versijās).

3.2. Oracle 9i

Oracle 9i versija ir viena no visplašāk pielietotajām versijām uz doto brīdi, jo iespēju

ziņā ir ļoti bagāta un joprojām apmierina lielu uzņēmumu prasības, neskatoties uz jaunākas -

Oracle 10 G – versijas eksistenci.

Svarīgākās Oracle 9i kodola paplašinājumu izmaiņas ietver sevī vairākas

Lokālie problēmsfēras indeksi

8i versijā paplašināmo indeksu veidošana bija iespējama tikai vienkāršām tabulām,

42

savukārt dalītām tabulām tas nebija izdarāms. Tādas tabulas speciāli tiek sadalītas vairākās

partīcijās, kur katra no daļām glabājas savā tabulu telpā (3.31. att.) Katrā no partīcijām

glabājas tabulas dati kāda atribūta noteiktam intervālam (vai arī uz kāda cita nosacījuma

balstīts tabulas vērtību intervāls).

3.31. att. Dalīta tabula

Oracle 9i realizēja iespēju realizēt un pielietot paplašināmos indeksus arī tādos gadījumos,

un nosauca tos par lokālajiem problēmsfēras indeksiem – kā pretstatu globālajiem

indeksiem, kuri nav sadalīti, t.i., tiem nav partīciju (partitions). Jaunās interfeisa metodes

(ODCIIndexExchangePartition, ODCIIndexMergePartition, ODCIIndexSplitPartition)

nodrošināja iespēju operēt ar šīm partīcijām.

ODCIEnv tips

Šī tipa parametrs tika ieviests vairāku kodola paplašinājumu interfeisu metodēs. Tas

glabā vispārīgu informāciju par izpildvidi, kurā paplašinājuma metodes tiek izpildītas. Ar

tā palīdzību metodei tiek paziņots, vai ir ieslēgts atkļūdošanas režīms, kā arī šis parametrs

ir nepieciešams lokālo problēmsfēras indeksu realizācijai, ar kura palīdzību var noteikt, vai

metode tiek izsaukta pēdējo reizi (pēdējai partīcijai).

Alter Indextype iespēja

Ar šīs iespējas palīdzību var mainīt paplašināmā indeksa interfeisa tipa saturu,

nelikvidējot to, t.i., izvairoties no vajadzības izdzēst un vēlāk atjaunot eksistējošus

problēmsfēras indeksus.

Vairāku plūsmu extproc

Kā jau tika minēts, extproc ir aģents, kas darbojas ārpus servera adrešu telpas un

nodrošina to objektu metožu un procedūru izpildi, kuru realizācija glabājas bibliotēkās, t.i.,

43

nav PL/SQL kods. Pateicoties vairākām extproc plūsmām DB serveris nodrošina lielāku

ātrdarbību intensīvas ārējo bibliotēku izmantošanas gadījumā.

Abstraktie SQL datu tipi

Lai nodrošinātu ciešāku integrāciju ar Java un C/C++ valodām, Oracle izveidoja

abstraktos datu tipus, t.i., tādus datu tipus, kuru iekšējā struktūra nav zināma datu bāzei. Šo

datu tipu iekšējā struktūra tiek modelēta kādā no valodām, kurā tiek realizētas ārējās

metodes, funkcijas vai procedūras (Java vai C/C++). Datu bāze nodrošina šo tipu

eksemplāru glabāšanu datu bāzē, nosakot šo datu tipu izmēru robežas (fiksēts izmērs

parastajiem datu tipi un mainīgs izmērs kolekcijām). Glabāšanas nosacījumi tiek nodoti ar

tipa specifikāciju.

Abstraktās tabulas un tabulu funkcijas

Šī iespēja jau tika izskatīta – ar funkciju palīdzību iespējams veidot virtuālu tabulu,

piem., lai interpretētu kādus datus, par kuru struktūru DB nav ne jausmas, tabulas veidā.

DBMS_ODCI pakotne

Ar šīs pakotnes palīdzību varēja labāk novērtēt lietotāju funkciju izmaksas –

pateicoties tam paplašināmā optimizatora realizēšana kļuva vienkāršāka.

Lietotāju definētas agregātfunkcijas

Šis kodola paplašinājuma jauninājums deva iespēju realizēt savas agregātfunkcijas,

saistītu ar realizējamās problēmsfēras loģiku.

3.3. Oracle 10g

Oracle 10g versija minimāli papildināja paplašināmās arhitektūras loģiku, bet gan

pievērsa uzmanību kodola paplašinājumu ātrdarbības uzlabošanas jautājumiem.

Masīvu ievietošana

Iepriekšējās versijās vērtību masīvu ievietošana netika atbalstīta problēmsfēras

indeksos, līdz ar to INSERT operācijas efektivitāte nebija maksimāla. Oracle 10G versijā

masīvu ievietošana var tikt realizēta grupveidīgi, izmantojot ODCIIndexInsert interfeisa

metodi.

Alter Operator iespēja

Tā kā indeksēšanas shēma parasti attīstās, var rasties situācija, kad ir nepieciešams

sasaistīt operatoru ar kādu jaunu funkciju, vai arī likvidēt kādu eksistējošu operatora saikni.

Tādā veidā tiek nodrošināta operatora attīstība, bez vajadzības to likvidēt.

Transportējamas tabulu telpas problēmsfēras indeksiem

44

Transportējamu tabulu telpu iespēja dod iespēju ātri kopēt datu bāzes apakškopas

(tabulu telpas) no vienas Oracle datu bāzes citā. Transportējamas tabulu telpas var tikt

izmantotas arī indeksu kopēšanai citā datu bāzē, kas ir labāka alternatīva, nekā eksportēt un

importēt šos indeksus. Transportējamu tabulu telpu izmantošana datu pārraidē ir krietni

ātrāka nekā parastās datu pārraides metodes, jo tā pieprasa tikai datu failu kopēšanu un

tabulu telpas strukturālās informācijas integrēšanu jaunajā datu bāzē (3.32. attēls)

3.32. att. Transportējamas tabulu telpas

Tādā veidā atkrīt indeksu pārbūvēšanas vajadzība, kā tas ir datu importēšanas/ielādēšanas

gadījumos.

Paralēlā lokālo problēmsfēras indeksu izveidošana/pārveidošana

Lokāliem problēmsfēras indeksiem jāapstrādā liela apjoma dati, jo dalītas tabulas

parasti tiek veidotas ar nolūku novērst liela apjoma datu glabāšanu vienkopus. Līdz ar to

indeksa izveidošana tādām tabulām bija šaurā vieta, jo prasīja daudz laika resursu. Oracle

10G versijā lokālie problēmsfēras indeksi var tikt izveidoti paralēli (ar starppartīciju

paralēlismu, t.i., paralēli katrai partīcijai). Tādā veidā indeksu veidošanas laiks tiek

samazināts tik reizes, cik partīcijās ir sadalīta tabula.

45

4. ORACLE KODOLA PAPLAŠINĀJUMA PIEMĒRA

PROJEKTĒŠANA

Kā jau tika minēts, viens no svarīgākajiem aspektiem kodola paplašināšanas

tehnoloģijās ir datu struktūru izveidošanas iespējas problēmsfērai, kā arī indeksācijas

mehānisma realizācija. Pretējā gadījumā datu apstrāde var notikt ļoti lēni, jo, kā jau zināms,

indeksācijas mehānisms ir viens no jaudīgākajiem ātrdarbības palielināšanai.

Darbā tiek piedāvāts nesarežģīts praktisks uzdevums, kas sevī ietver samērā reālas

problēmas – elektroenerģijas patēriņa apstrādes – datu bāzes realizāciju. Dažas algoritmiskas

idejas ir aizgūtas no eksistējošajiem dokumentācijas piemēriem [5], tādēļ praktiskā daļa

iekļauj sevī detalizētu indeksēšanas mehānisma realizācijas analīzi.

4.1. Ieskats problēmsfērā

Analizējot elektroenerģijas patēriņu kādā ģeogrāfiskā apgabalā, ir būtiski novērot

elektroenerģijas patēriņa maiņu atkarībā no laika. Lai novērojumi sniegtu vairāk informācijas,

ir lietderīgi sadalīt apgabalu reģionos, ko parasti veic, „uzklājot” uz apgabala tīklojumu no

NxM vienāda izmēra rūtiņām. Piemērā ģeogrāfiskais apgabals tiks dalīts 5x5 reģionos, un tiek

tiks numurēti pēc kārtas, sākot ar kreiso augšējo stūri (4.33. attēls).

4.33. att. 5x5 reģionos dalīta apgabala numerācija

Tāda numerācija ir viens no veidiem, kā norādīt uz konkrētu reģionu. Tā kā

programmēšanā visbiežāk saskaras ar viendimensijas masīviem, un jo vairāk – Oracle ir

paredzēts VARRAY mainīga izmēra vienas dimensijas masīvs – tad arī tiek piedāvāta lineāra

reģionu numerācija.

Tādā veidā mēs uzklājam 5x5 rūtiņu lielu tīklu uz kādu ģeogrāfisku apgabalu, un

piešķiram katram reģionam savu skaitli, jeb indeksu. Konkrētajā reģionā veiktie mērījumi tiks

attiecināti tieši šim reģionam. Vizuāli tāds reģionāls sadalījums konkrētam ģeogrāfiskam

46

apgabalam redzams 4.34. attēlā.

4.34. att. Ģeogrāfiska apgabala sadalījums reģionos

Pieņemsim, ka mērījumi notiek katru stundu. Tādā veidā datu bāze iegūst temporālas

iezīmes, glabājot viena tipa datus dažādiem laika momentiem.

Datu glabāšanas pamatprincipu lieliski parāda 4.35. attēlā redzamā shēma. Ik pēc

noteikta laika intervālos datu bāzē nonāk 25 vērtības – elektroenerģijas patēriņš katrā no

ģeogrāfiskā apgabala reģioniem.

47

4.35. att. Vērtību ierakstīšana datu bāzē laika gaitā

Tāda veida sadalījums un sistemātiska datu uzkrāšana dod iespēju veikt svarīgu analīzi

par ģeogrāfisko apgabalu. Mēs varam noteikt, kurās stundās tiek visvairāk patērēta

elektroenerģija un kuros reģionos. Mēs varam pētīt elektroenerģijas patēriņa likumsakarības

starp blakusesošajiem reģioniem un veikt attiecīgos secinājumus. Tādā veidā elektroenerģijas

patēriņš var tikt kontrolēts, kas palīdzētu veikt precīzākus elektroenerģijas sadalījuma darbus

starp reģioniem.

Īstenībā likumsakarības var pētīt ne tikai starp elektroenerģijas patēriņu dažādos

reģionos. Uzdevumu varētu papildināt, veicot, piem., temperatūras mērījumu katrā no

reģioniem, tādā veidā meklējot likumsakarības starp temperatūras un elektroenerģijas patēriņa

izmaiņām. Taču arī elektroenerģijas patēriņa uzdevums tīrā veidā ir jau gana informatīvs un

pietiekošs, lai varētu demonstrēt DBVS kodola paplašināšanas iespējas.

4.2. Realizācijas iespēju izvērtējums

Tas, kā tiek realizēta datu glabāšana, vistiešākajā veidā atspoguļojas uz datu

glabāšanas ērtumu, ātrdarbību un elastību izmaiņām. Es mēģināju piedāvāt spilgtākos

realizācijas piemērus, attēlojot to priekšrocības un trūkumus.

4.2.1. „Plakans” DB modelis

Šī realizācija ietver sevī reģionu izskatīšanu kā atsevišķas kolonnas. Kaut arī tas ir

realizējams, taču strādāt ar 25 kolonnām nav diez ko ērti, kā arī var rasties grūtības gadījumā,

ja parādīsies vajadzība datus struktūru mainīt; reģionu skaitam palielinoties, realizācija kļūs

praktiski neiespējama.

48

4.36. att. „Plakans” DB modelis

Līdz ar to šī pieeja var tikt raksturota kā ļoti slikta. Taču tas nenoliedz, ka tāda pieeja

vispār netiek izmantota. Piem., ja mums būtu 5 reģioni, nevis 25, tad, neapšaubāmi, tieši šis

modelis pirmais ienāktu prātā. Tā realizācija būtu vienkārša, taču neelastība izmaiņām ir

būtiskākais zemūdens akmens. Ja reģionālais sadalījums mainītos, un papildus nāktu kaut vai

viens reģions, tabulas struktūru nāktos izjaukt. Tas nozīmē veikt veselu darbību kopu veco

datu transportēšanai, tabulas struktūras izjaukšanai utt.

4.2.2. RDB modelis ar ārējām atslēgām

Ir iespējams realizēt arī relāciju datu bāzi, kur reģionu vērtības tiks glabātas atsevišķā

tabulā, kā tas ir redzams 4.37. attēlā. Reģionu vērtība saturēs ārējo atslēgu uz attiecīgo

ierakstu, kas satur mērījuma laiku un arī citus iespējamos atribūtus. Šajā gadījumā datu bāze

kļūst elastīgāka izmaiņām, tā vairs nav „plakana”. Neapšaubāmi, vaicājumi sanāk nedaudz

sarežģītāki, taču pilnībā loģiski un saprotami.

4.37. att. RDB modelis ar ārējām atslēgām

Kā redzams, nekur netiek ierobežots maksimālais reģionu skaits, taču, lai apstrādātu

visas konkrēta ieraksta reģiona vērtības, mums ir jāveic speciāli vaicājumi šo datu izgūšanai.

4.2.3. RODB modelis ar kolekciju

Relāciju datu bāzes modelis tik tiešām ir ērts, un arī mūsdienās jo plaši pielietojams.

49

Taču, projektējot datu bāzes modeli noteiktai problēmsfērai, mums var rasties nepieciešamība

sasaistīt ar datu bāzi attiecīgo problēmsfēras biznesa loģiku, kas palīdzētu vairākas

manipulācijas veikt datu bāzes servera pusē, nevis klienta daļā, tādā veidā samazinot datu

pārraidi tīklā, vienkāršojot klientu un optimizējot vairākus skaitļošanas procesus.

Paplašināmo tipu sistēma dod iespēja aprakstīt tādus sarežģītus strukturētus datus kā

vienus veselus, un glabāt visu reģionu vērtības kopā ar citiem svarīgiem atribūtiem kā vienu

veselu ierakstu. Tāda pieeja skatāma 4.38. attēlā.

4.38. att. Salikta objektu tipa izmantošana reģionālu vērtību glabāšanai

Pateicoties tādai pieejai parādās vairākas priekšrocības:

elastīgums izmaiņu gadījumā;

objektu tipu vienmēr iespējams papildināt ar jauniem atribūtiem un metodēm;

katra ieraksta objekta tipa eksemplārs satur uzreiz visas reģionu vērtības, kas sniedz

lielas priekšrocības datu analīzē;

iespējams veidot atsauces uz objektiem no citām tabulām (REF);

Taču ir arī būtisks trūkums: neviena DBVS nepiedāvā iebūvētus indeksācijas

mehānismus lietotāju definētajiem tipiem, jo neko nezin par šo tipu struktūru. Līdz ar to,

darbojoties ar lieliem datu apjomiem, var rasties ātrdarbības problēma, un vaicājumi netiks

izpildīti pieņemamā laikā.

Problēmas risinājums: izveidot indeksācijas mehānismu, ar kuras palīdzību tiks

nodrošināta ātrāka datu izgūšana specifiskos problēmsfēras vaicājumos. Savā darbā es

nepiedāvāju jaudīgu indeksācijas algoritmu, bet gan demonstrāciju, kā tiek izveidots

paplašināmais indeksācijas mehānisms un saistīts ar DBVS kodolu.

4.3. Problēmsfēras operatori

Operators, kā jau tika minēts, ir augstākā līmeņa DBVS shēmas elements, kuru

50

izmanto paplašināmās indeksācijas realizācijai.

Gadījumā, ja vaicājumā WHERE parādās problēmsfēras operatori, kas tiek piesaistīti

problēmsfēras indeksa tipam, parādās iespēja veikt datu atlasi ar indeksa mehānisma

palīdzību, nevis veicot pilnu pamattabulas izskatīšanu.

Kādi tad varētu būt operatori dotajā problēmsfērā?

Loģiski, mūs interesē elektroenerģijas patēriņš kādā noteiktā reģionā vai arī visā

apgabalā kopumā. Un mūs noteikti interesēs, vai datu bāzē esošās vērtības ir lielākas,

mazākas vai vienādas ar uzdoto vērtību. Tā, piemēram, varam definēt operatoru

ENERGO_VIENADS(eksemplārs, reģions, vērtība), kurš atgriezīs 1 (taisnība), gadījumā, ja

ieraksta eksemplāra noteikta reģiona vērtība ir vienāda ar operatorā uzdoto un 0 (aplams), ja

reģiona vērtība nav vienāda ar operatorā uzdoto.

Es definēšu trīs operatorus vērtības salīdzināšanai konkrētam reģionam, kā arī trīs

līdzīgus operatorus, tikai vērtības salīdzināšanai jebkuram reģionam. 4.7. tabulā ir apkopoti

problēmsfēras operatori, kā arī sniegti apraksti par tiem.

4.7. tabula

Problēmsfēras operatori un to apraksti

Operators Apraksts

ENERGO_VIENADS(eksemplārs,

reģions, vērtība)

Atgriež 1, ja eksemplāra reģiona vērtība ir vienāda ar operatorā

uzdoto vērtību; pretējā gadījumā atgriež 0

ENERGO_LIELAKS(eksemplārs,

reģions, vērtība)

Atgriež 1, ja eksemplāra reģiona vērtība ir lielāka par operatorā

uzdoto vērtību; pretējā gadījumā atgriež 0

ENERGO_MAZAKS(eksemplārs,

reģions, vērtība)

Atgriež 1, ja eksemplāra reģiona vērtība ir mazāka par operatorā

uzdoto vērtību; pretējā gadījumā atgriež 0

ENERGO_VIENADS_JEBK

(eksemplārs, vērtība)

Atgriež 1, ja jebkura no eksemplāra reģionu vērtībām ir vienāda ar

operatorā uzdoto vērtību; pretējā gadījumā atgriež 0

ENERGO_LIELAKS_JEKB

(eksemplārs, vērtība)

Atgriež 1, ja jebkura no eksemplāra reģionu vērtībām ir lielāka par

operatorā uzdoto vērtību; pretējā gadījumā atgriež 0

ENERGO_MAZAKS_JEBK

(eksemplārs, vērtība)

Atgriež 1, ja jebkura no eksemplāra reģionu vērtībām ir mazāka par

operatorā uzdoto vērtību; pretējā gadījumā atgriež 0

Piemēram, mūsu rīcībā ir 4.39. attēlā redzamais paraugs.

51

4.39. att. Reģionu vērtību piemērs

Lai rastu skaidrāku priekšstatu par problēmsfēras operatoru patiesumvērtības principu,

4.8. tabulā ir apkopoti daži piemēri ar operatoru izteiksmēm.

4.8. tabula

Problēmsfēras operatoru izteiksmju piemēri

Operatora izteiksme Patiesumvērtība

ENERGO_VIENADS(paraugs, 1, 5) =

1

Patiess, jo 1. reģiona vērtība ir 5

ENERGO_LIELAKS(paraugs, 2, 8) =

0

Patiess, jo 2. reģiona vērtība nav lielāka par 8

ENERGO_VIENADS_JEBK

(paraugs, 3) = 1

Aplams, jo neviena no vērtībām nav vienāda ar 3

ENERGO_LIELAKS_JEKB (paraugs,

13) = 1

Patiess, jo 12. reģiona vērtība tik tiešām ir lielāka par 13

ENERGO_MAZAKS_JEBK

(paraugs, 6) = 0

Aplams, jo vairākas vērtības ir mazākas par 6

Gadījumos, kad operatora izteiksmes patiesumvērtība būs „patiess”, datu rindiņas tiks

izgūtas no tabulas tālākai apstrādei, t.i., šīs rindiņas apmierinās vaicājuma nosacījuma

WHERE daļu, kas attiecas tieši uz problēmsfēras operatora izteiksmi.

Pēc būtības mēs darbojamies ar predikātu patiesumvērtībām un veicam loģiskās

operācijas, ar kuru palīdzību tiek noskaidrota nepieciešamā informācija par elektroenerģijas

patēriņu gan atsevišķos reģionos, gan arī visā apgabalā kopumā.

Tādā veidā ar šo operatoru palīdzību ir iespējams analizēt elektroenerģijas patēriņu

gan atsevišķos reģionos, gan arī visā ģeogrāfiskajā apgabalā kopumā. Mūs var interesēt, vai

52

kāda reģiona vērtība konkrētajās stundās nepārsniedz noteiktu vērtību (jo tas liecinās par

pārāk lielu noslodzi), kā arī mūs var interesēt tie ieraksti, kuros enerģijas patēriņš jebkurā no

reģioniem nokrīt zem noteiktas robežas (kas norāda par iespējamo elektrības vadu

pārrāvumu).

4.4. Objektu kolonnas indeksēšanas princips

Tā kā es piedāvāju objektu pieeju elektroenerģijas patēriņa vērtību glabāšanai

kolekcijā, tad attiecīgi šim tipam tiks izveidots indeksēšanas mehānisms. Šī mehānisma būtība

ir nevis realizēt kaut kādu sarežģītu algoritmu, bet gan parādīt indeksēšanas darbības

pamatprincipus, to izveides soļus un mijiedarbību ar Oracle DBVS kodolu.

Darbība ar objektu tipiem, it sevišķi kolekcijām, notiek nedaudz lēnāk, nekā ar

parastajām tabulām. Līdz ar to, lai izvairītos no pilnas objektu tipu saturošās tabulas

skenēšanas, mēs varam interpretēt datus un saglabāt tos papildtabulā. Tādā veidā, kad

vaicājuma WHERE daļā parādīsies kāds problēmsfēras operators, varēs vaicājumu interpretēt

un pielāgot papildtabulai, un ar tās palīdzību izgūt to pamattabulas rindiņu numurus, kas

apmierina dotos vaicājuma nosacījumus. Tāda interpretācija ir skatāma 4.40. attēlā.

4.40. att. Reģionu vērtību interpretācija un saglabāšana indeksa tabulā

Attēlā redzams, kā pirmās trīs kolekcijas vērtības nonāk indeksa tabulā. Katrai vērtībai

tiek norādīta attiecīga pozīcija kolekcijā, un visām trim vērtībām ir viens un tas pats attiecīgās

rindiņas identifikācijas numurs.

53

5. ORACLE KODOLA PAPLAŠINĀJUMA PIEMĒRA REALIZĀCIJA

Pēc tam, kad tika veikti projektēšanas darbi un noteikts, kādas datu struktūras ir

jārealizē problēmsfēras datu glabāšanai un indeksēšanai, var realizēt attiecīgās struktūras datu

bāzē un realizēt indeksēšanas mehānismu.

5.1. Kolekcijas un objektu tipi

Pirmkārt tiek definēts kolekciju tips reģionu vērtību glabāšanai. Tādas kolekcijas

shematisks attēls un izveidošanas skripts skatāms 5.41. attēlā.

5.41. att. Kolekcijas tips un tā definēšana reģionu vērtību glabāšanai

Pēc tam tiek izveidots objektu tips reģionu vērtību glabāšanai, kas papildus satur

ieraksta laiku, kā arī minimālās, maksimālās un kopējās elektroenerģijas patēriņa vērtības un

metodi to noteikšanai. Tāda objekta tipa shematisks attēlojums un veidošanas skripts skatāms

5.42. attēlā.

5.42. att. Objektu tips reģionu vērtību un ieraksta laika glabāšanai

Tādā veidā, definējot objektu tipa eksemplāru, tajā var ierakstīt reģionu vērtības un ar

metodēm noteikt minimālo, maksimālo un kopējo pieprasījumu dotajam ierakstam. Šīs

metodes, loģiski, tiek izsauktas tikai vienu reizi, pēc tam, kad reģionu vērtības ir ierakstītas.

Oracle 10g iespējams definēt konstruktora funkcijas, kas šo metožu izsaukšanu var

54

veikt automātiski, taču savā gadījumā datu bāzi realizēju Oracle 9i, kur šīs iespējas nav, līdz

ar to metodi jāizsauc tiešā veidā.

Viena metode – APR_PIEPRAS – kalpos kopējā, minimālā un maksimālā

elektroenerģijas patēriņa aprēķināšanai un saglabāšanai atribūtos. Objektu tipa ķermeņa

izveidošana skatāma 5.43. attēlā.

5.43. att. Objektu tipa ķermenis ar metodi APR_PIEPRAS

Algoritms pēc būtības ir vienkāršs – tas iziet cauri visām kolekcijas vērtībām, un

izskaitļo to summu, kā arī atrod minimālo un maksimālo vērtības.

5.2. Operatoru izveide

Oracle operatori tiek piesaistīti konkrētajām funkcijām. Līdz ar to sākumā ir jāizveido

attiecīgās funkcijas, un pēc tam ar noteiktu komandu palīdzību jāpiesaista operatoriem.

Lai mazinātu sajaukumu, piedāvāju funkciju nosaukumus, kas ir analogi attiecīgo

operatoru nosaukumiem, taču ar priedēkli „F_”. Acīmredzami, argumentu vērtībām arī

jāsakrīt ar operatora argumentiem.

5.44. attēlā redzama funkcijas F_ENERGO_VIENADS, kas kā parametrus pieņem

attiecīgā objektu tipa eksemplāru (kas satur reģionu vērtību kolekciju), reģiona numuru un

vērtību, ar kuru funkcija veic salīdzināšanu.

55

Kā redzams, funkcija pārbauda, vai gadījumā norādītā reģiona indekss nepārsniedz

masīva pēdējo indeksu, un salīdzina argumentos sniegto vērtību ar attiecīgā reģiona ierakstīto

vērtību objektu tipa eksemplārā. Ja vērtības ir vienādas, tad funkcija atgriež vērtību „1”

(patiess), pretējā gadījumā – „0” (aplams).

5.44. att. F_ENERGO_VIENADS funkcija

F_ENERGO_LIELAKS un F_ENERGO_MAZAKS funkcijas ir analoģiskas nupat

minētajai, tikai veic funkcijām attiecīgās salīdzināšanas operācijas (vai argumentā minētā

vērtība ir lielāka/mazāka par parauga reģiona vērtību?)

5.45. attēlā redzamā funkcija F_ENERGO_VIENADS_JEBK atšķiras no funkcijas

F_ENERGO_VIENADS ar to, ka atgriež patiesību (1) tad, ja parauga reģiona vērtība ir

vienāda ar argumenta vērtību jebkuram no reģioniem.

5.45. att. F_ENERGO_VIENADS_JEBK funkcija

Attiecīgi tiek realizētas arī funkcija F_ENERGO_LIELAKS_JEBK, kas atgriež 1

gadījumā, ja argumenta vērtība ir lielāka par jebkuru no parauga reģionu vērtībām (t.i., ir

reģioni ar mazākām vērtībām nekā argumenta vērtība), kā arī funkcija

56

F_ENERGO_MAZAKS_JEBK, kas atgriež 1 gadījumā, ja argumenta vērtība ir mazāka par

jebkuru no parauga reģionu vērtībām.

Kad funkcijas ir izveidotas, tās var piesaistīt operatoriem. Operatoru izveide Oracle

notiek ar komandas CREATE OPERATOR palīdzību, kur operatora nosaukumam norāda

parametru kopu un atgriežamo vērtību, un, svarīgākais – izmantojamo funkciju. Operatoru

izveide, izmantojot sešas nupat izveidotās funkcijas, redzama 5.46. attēlā.

5.46. att. Operatoru izveide un piesaiste attiecīgajām funkcijām

5.3. Indeksēšanas interfeisa realizācija

Pirms tiek izveidots indeksa tips, tam ir jārealizē objektu tips, kas saturēs svarīgākās

interfeisa metodes, kuras ir nepieciešamas indeksēšanas mehānisma darbībai. 5.47. attēlā

redzams tāds objektu tips ar metožu klāstu. Dažas no tām ir realizētas kā STATIC, dažas kā

MEMBER – tas ir atkarīgs no funkcijas specifikācijas. MEMBER funkcijas tiek izpildītas

konkrētam eksemplāram, tām ir piekļuve visiem objektu tipa argumentiem. Savukārt STATIC

funkcija var tikt izsaukta pat tad, ja nav izveidots objektu tipa eksemplārs.

Šīs metodes īsumā jau tika apskatītas paplašināmai indeksēšanai veltītajā apakšnodaļā-

2.3. tabulā. Precīzāk katras metodes darbības problēmsfēras indeksa darbības kontrolēšanai

tiks izskatītas katrā no nākamajām apakšnodaļām.

Kā redzams, objektu tips satur vienu papildmainīgo – KURSORS (NUMBER tipa

atribūts). Šis kursors tiks izmantots, lai varētu veikt problēmsfēras indeksa skenēšanu. Ar

pakotnes DBMS_SQL palīdzību kursors tiks saistīts ar dinamiski izveidotu vaicājumu, un šis

kursors tiks izmantots metodēs, kas atbild par datu izgūšanu no indeksa tabulas.

57

5.47. att. Problēmsfēras indeksa tipam paredzētais objektu tips

Objektu tipa ķermenis satur šo metožu realizāciju. Tās tiks izklāstītas nākamajās

apakšnodaļās.

5.3.1. Metode ODCIGetInterfaces

ODCIIndexGetInterfaces metode ar IFCLIST argumentu atgriež interfeisa realizācijas

versiju, kā tas ir redzams 5.48. attēlā.

5.48. att. ODCIGetInterfaces metode

Šī versija sniedz DBVS kodolam precīzu informāciju par indeksa realizēto metožu

versiju. Ja ir realizētas Oracle 9i un augstāku versiju iespējas (kas ir funkcionāli bagātākas un

58

satur papildus argumentus), tad ar IFCLIST parametru atgriež „ODCIINDEX2”, kā tas ir

manā gadījumā.

5.3.2. Metodes ODCIIndexCreate un ODCIIndexDrop

ODCIIndexCreate ir metode, kas reaģē uz indeksa izveidošanas procedūru. Manā

gadījumā tā izveido indeksa datiem paredzēto tabulu (pirmais solis) un aizpilda indeksa

tabulu, interpretējot pamattabulas datus (otrais solis). Shematiski tas ir parādīts 5.49. attēlā.

5.49. att. ODCIIndexCreate metodes darbība

Metodes sākas ar to, ka tiek izveidota tabula, kuras nosaukums tiek izvēlēts attiecīgajā

veidā: indeksa nosaukums + „_EIND”. Informācija par indeksa nosaukumu un shēmu, kurā

indeksu izveido, tiek ņemta no IA argumenta (SYS.ODCIIndexInfo tips). PL/SQL koda daļa,

kas atbild par tādas tabulas izveidošanu, ir skatāma 5.50. attēlā.

5.50. att. Indeksa tabulas izveide

Nākamās rindiņas ģenerē otro un trešo vaicājumu, kas savstarpēji ir saistīti. Otrais

59

vaicājums ievieto attiecīgās rindiņas identifikācijas numuru, reģiona numuru un vērtību

indeksa tabulā konkrētam rindiņas numuram, kas tiek iegūts no trešā vaicājuma un piesaistīts

otrajam vaicājumam kā mainīgais. Dinamiskajā SQL tiek aktīvi izmantoti mainīgie (par ko

norāda divpunkts izteiksmes priekšā), savukārt rindiņas ID iegūšanai un sasaistei

DBMS_SQL pakotnē ir attiecīgās metodes – COLUMN_VALUE_ROWID rindiņas numura

izgūšanai, kā arī BIND_VARIABLE_ROWID, kas piesaista dinamiskās izteiksmes

mainīgajam PL/SQL mainīgo.

Vienkāršāk izsakoties – pamattabulas attiecīgās rindiņas numurs, kā arī reģionu

vērtības ar to attiecīgajiem numuriem tiek saglabātas indeksa tabulā, pielietojot šo operāciju

katrai pamattabulas datu rindiņai. Metodes ODCIIndexCreate fragments, kas atbild par

indeksa tabulas aizpildīšanu, ir skatāms 5.51. attēlā.

5.51. att. Indeksa tabulas aizpildīšana

Metode ODCIIndexDrop reaģē uz indeksa dzēšanas procedūru. Dotajā gadījumā tā

veic attīrīšanas darbus – izdzēš indeksa tabulu.

Arī metodes ODCIIndexDrop gadījumā tiek dinamiski ģenerēts vaicājums, balstoties

uz indeksa nosaukumu un shēmu, kurā tas tika izveidots (šo informāciju sniedz

60

Sys.ODCIIndexInfo tipa arguments). Metodes ķermenis ir skatāms 5.52. attēlā.

5.52. att. Metodes ODCIIndexDrop ķermenis

Metode ODCIIndexDrop nostrādā indeksa dzēšanas (DROP INDEX), kā arī

pamattabulas dzēšanas gadījumā (DROP TABLE).

5.3.3. Metodes ODCIIndexStart, ODCIIndexFetch un ODCIIndexClose

Ja vaicājumā parādās kāds no operatoriem WHERE daļā, kas ir sasaistīti ar konkrēto

indeksēšanas mehānismu, tad Oracle kodols var izvēlēties datus meklēt nevis pamattabulā,

veicot tās datu rindiņu pilnīgu pārlasi, bet gan griezties pie indeksēšanas mehānisma.

Pamattabulas rindiņu identifikatoru izgūšanai tiek izmantotas ODCIIndexStart,

ODCIIndexFetch un ODCIIndexClose metodes.

ODCIIndexStart atver kursoru speciālam vaicājumam, kurš tiek ģenerēts uz operatora

izteiksmes pamata. Šī vaicājuma izpildes gaitā (ODCIIndexFetch) speciālajā kolekcijā (kas ir

viens no ODCIIndexFetch argumentiem) tiek saglabāti pamattabulas rindiņu numuri, kas

apmierina dotā vaicājuma nosacījumus. Beigās ODCIIndexClose aizver kursoru. Gala

rezultātā mēs iegūstam tās datu rindiņas, kuru numuri tika atgriezti ar ODCIIndexFetch

metodi. Shematiski šie posmi ir skatāmi 5.53. attēlā.

61

5.53. att. Indeksa darbība vaicājuma laikā

ODCIIndexStart metodes var būt vairākas. To argumentu skaits un tips var variēt –

pēc standartargumentiem seko argumenti, kas atbilst operatoru argumentiem (bez objektu

tipa). Manā gadījumā ir divi dažādi operatoru tipi: pirmajā gadījumā ar diviem argumentiem

(vērtība konkrētam reģionam), un otrajā gadījumā – tikai salīdzināmā energopatēriņa vērtība.

Kurš tieši operators tiek izsauks no trijiem, tiek noteikts metodes izpildes gaitā, jo arguments

OP (SYS.ODCIPREDINFO tips) satur informāciju par operatoru.

5.54. attēlā var redzēt ODCIIndexStart metodes definīciju gadījumam, kad operatorā

bez salīdzināmās vērtības tiek norādīts arī konkrēts reģions.

62

5.54. att. ODCIIndexStart metode ar diviem papildargumentiem

Savukārt 5.55. attēlā var redzēt ODCIIndexStart metodes definīciju gadījumam, kad ar

operatoriem tiek salīdzinātas vērtības ar jebkuru no reģioniem. Tātad, šai metodei ir tikai

viens papildarguments. Abos attēlos papildargumenti ir ierāmēti ar raustītu līniju.

5.55. att. ODCIIndexStart metode ar vienu papildargumentu

Lai izgūtu attiecīgos datus no indeksa tabulas, ODCIIndexStart metodei jākonstruē

vaicājums, kas rezultātā interpretētu operatora predikātu tādā veidā, lai reģionu vērtības tiktu

salīdzinātas indeksa tabulā.

Pirmajā gadījumā ODCIIndexStart metodei jākonstruē vaicājums, kas ņem vērā

63

reģiona pozīcijas numuru. No visa ir trīs operatori, un atkarībā no tiem, kā arī operatora

predikāta vērtības (1 vai 0), tiks piemeklēts vajadzīgais attieksmes operators vērtību

salīdzināšanai indeksa tabulā. Šī metodes ODCIIndexStart daļa ir skatāma 5.56. attēlā.

5.56. att. Salīdzināšanas operatoru noteikšana pirmā tipa operatoriem (konkrēts reģions)

Šis attieksmju operators tiks saglabāts teksta veidā – mainīgajā RELOP. Balstoties uz

šo operatoru tiek konstruēts dinamiskais vaicājums, kas izvēlēsies attiecīgās pamattabulas

rindiņu numurus no indeksa tabulas: tiek salīdzināts gan reģiona numurs, gan arī vērtība.

Reģiona vērtība tiek salīdzināta ar uzrādīto vērtību ar salīdzināšanas operatoru, kas tika

izvests metodes sākumdaļā. Šī ODCIIndexStart metodes daļa ir skatāma 5.57. attēlā.

64

5.57. att. Vaicājuma izveidošana pirmajā ODCIIndexStart metodē

Savukārt ODCIIndexStart metode operatoriem, kuri salīdzina jebkuru reģiona vērtību,

var tik realizēta nedaudz vienkāršāk, nekā pirmajā gadījumā. Ja operatora predikāts ir vienāds

ar 0, tad var izmantot „inversiju” – ar operatora MINUS palīdzību tiks izgūtas tās rindiņas,

kas nebūtu izgūtas, ja operatora predikāta vērtība būtu 1. Tāda vaicājuma ģenerēšana ir

skatāma 5.58. attēlā.

5.58. att. Vaicājuma izveidošana otrajā ODCIIndexStart metodē

Metode ODCIIndexFetch ar parametru RIDS (SYS.ODCIRidList tips) atgriež to

65

pamattabulas rindiņu unikālos numurus, kas apmierina ODCIIndexStart metodes kursora

rezultātu. Būtiski atzīmēt, ka tā maksimāli var atgriezt tik rindiņu, cik norādīts NROWS

argumentā. Līdz ar to ciklā tiek pārbaudīts, vai kārtējās porcijas rindiņu skaits nav sasniedzis

maksimumu ( IF IDX > NROWS THEN BEIGAS := TRUE; ). ODCIIndexFetch metodes

ķermenis ir parādīts 5.59. attēlā.

5.59. att. Metodes ODCIIndexFetch ķermenis

Acīmredzami, metode tiks izsaukta tik ilgi, kamēr kārtējā metodes izpildes reizē

kolekcijas beigās nebūs NULL vērtības.

Metodes ODCIIndexClose ķermenis ir skatāms 5.60. attēlā.

5.60. att. Metodes ODCIIndexClose ķermenis

Ar šīs metodes palīdzību tiek aizvērts kursors, kas tika atvērts ar vienu no

ODCIIndexStart metodēm.

66

5.3.4. Metodes ODCIIndexInsert, ODCIIndexUpdate un ODCIIndexDelete

Šīs trīs metodes nostrādā gluži kā trigeri datu manipulāciju gadījumā: kad dati tiek

ievadīti pamattabulā (ODCIIndexInsert), kad dati tiek atjaunoti tajā (ODCIIndexUpdate) un

kad dati tiek dzēsti no tās (ODCIIndexDelete). Ar šo metožu palīdzību informācija tiek

sinhronizēta starp pamattabulu un indeksa tabulu, lai saturiski tās būtu ekvivalentas.

Kad dati tiek ievietoti pamattabulā, ODCIIndexInsert metode ievieto indeksa tabulā

rindiņas, kas satur pamattabulas rindiņas numuru, reģiona numuru un tam piesaistīto vērtību.

Shematiski tas ir parādīts 5.61. attēlā.

5.61. att. Problēmsfēras indeksa reakcija uz datu ievietošanu

5.62. attēlā ir redzams metodes ODCIIndexInsert kods. Gan ievietojamās rindiņas

identifikācijas numurs, gan arī jaunais objektu tipa eksemplārs tiek nodots kā argumenti.

Pateicoties tam nav nepieciešamības griezties pie pamattabulas un var veikt visas indeksa

tabulas papildināšanas darbības uzreiz.

Jāpiebilst, ka daļēji šīs metodes darbība ir ļoti līdzīga ODCIIndexCreate, taču

ODCIIndexCreate metode indeksa tabulu aizpilda, apskatoties katru rindiņu, līdz ar to tā

griežas pie pamattabulas, kas, protams, ir darbietilpīgs process lielu datu apjomu gadījumā.

Arī šajā gadījumā tiek aktīvi izmantots dinamiskais SQL, kur parādās trīs argumenti –

rindiņas identifikācijas numurs. Rindiņas ID piesaistīšana notiek tikai vienu reizi, bet reģiona

numura un tās vērtība – ciklā. Šajā gadījumā tiek izmantota pakotnes DBMS_SQL vienkāršā

funkcija BIND_VARIABLE, piesaistot vaicājuma mainīgajam attiecīgā PL/SQL mainīgā

vērtību.

67

5.62. att. Metodes ODCIIndexInsert ķermenis

ODCIIndexUpdate metode ir ļoti līdzīga ODCIIndexInsert metodei, taču tai ir

pieejama arī vecā objektu tipa vērtība, kas var palīdzēt veikt attiecīgās indeksa atjaunošanas

operācijas. Problēmsfēras indeksa reakcijas uz objektu tipa eksemplāra atjaunošanu

shematisks attēlojums ir parādīts 5.63. attēlā.

5.63. att. Problēmsfēras indeksa reakcija uz datu atjaunošanu

ODCIIndexUpdate metodes kods pēc būtības arī ir ļoti vienkāršs: tā kā mums ir

zināma pamattabulas rindiņas numurs, tad sākumā var vienkārši izdzēst attiecīgās indeksa

68

tabulas. Šī metodes ODCIIndexUpdate daļa ir skatāma 5.64. attēlā.

5.64. att. Metodes ODCIndexUpdate daļa, kas atbild par veco vērtību izdzēšanu

Pēc tam, kad izdzēstas vajadzīgās indeksa tabulas rindiņas, var ierakstīt jaunās, kas

atbilstu atjaunotajai objektu tipa vērtībai. Šī metodes daļa ir skatāma 5.65. attēlā.

5.65. att. Metodes ODCIndexUpdate daļa, kas atbild par jauno vērtību ievadīšanu

Pēdējā metode no šīs sērijas – ODCIIndexDelete – pēc būtības ir ļoti vienkārša un

69

sakrīt ar ODCIIndexUpdate metodes sākumu – tā izdzēš visas indeksa tabulas rindiņas, kas

atbilst no pamattabulas izdzēstajai datu rindiņai. Šīs darbības shematisks attēlojums ir skatāms

5.66. attēlā.

5.66. att. Problēmsfēras indeksa reakcija uz datu dzēšanu

Metodes ODCIIndexDelete ķermenis ir skatāms 5.67. attēlā.

5.67. att. Metodes ODCIIndexDelete ķermenis

Arī šīs metodes argumenti sniedz informāciju par dzēšamās rindiņas numuru un

objekta tipu, taču dotajā gadījumā pietiek tikai ar pamattabulas rindiņas identifikācijas

numuru, lai konstruētu dinamisko vaicājumu vajadzīgo rindiņu dzēšanai no indeksa tabulas.

70

5.4. Indeksa tipa izveide

Kad beidzot ir realizēts indeksa objektu tips, var izveidot indeksa tipu, norādot

operatorus, uz kuru pamata indeksēšanas mehānisms spēs meklēt atbilstošās pamatdatu

rindiņas identifikatorus indeksa tabulā. Problēmsfēras indeksa tipa izveide ir skatāma 5.68.

attēlā.

5.68. att. ENERGO_INDEKSS problēmsfēras indeksa tipa izveide

Kā redzams, tiek norādīts atslēgvārds FOR, pēc kura tiek uzskaitīti attiecīgie

problēmsfēras operatori un to argumenti iekavās. Pirmais arguments vienmēr ir problēmsfēras

datus raksturojošs tips, kas raksturos arī indeksējamo tabulas kolonnu. Pēc tam seko pārējo

argumentu tipi, kas tad arī nosaka metožu ODCIIndexStart skaitu.

5.5. Problēmsfēras indeksa darbības testēšana

Lai pārliecinātos, ka problēmsfēras indekss darbojas pareizi un atbilstoši uzdotajam

algoritmam, katrā no problēmsfēras indeksa metodēm tika realizēt informācijas izvade teksta

veidā (pēc būtības – speciālajā buferī). Aktīvi tika izmantota metode

SYS.ODCIIndexInfoDump, kas izvada informāciju par indeksu, balstoties uz

SYS.ODCIIndexInfo tipa argumentu. Tādā veidā būs iespējams pārbaudīt, vai problēmsfēras

indekss reaģē uz vajadzīgajiem notikumiem un veic attiecīgās operācijas ar indeksa tabulu ar

nolūku to papildināt, atjaunot, vai arī izgūt vajadzīgos datus, kas apmierinātu vaicājumu.

Sākumā, protams, jāizveido pamattabula. Lai vieglāk būtu demonstrēt indeksa

darbību, tā būs ļoti vienkārša – saturēs tikai primāro atslēgu (ieraksta numuru), kā arī

elektroenerģijas pieprasījuma paraugu. Tabula izveidošanas skripts ir skatāms 5.69. attēlā.

71

5.69. att. Tabulas ENERGO_TABULA izveidošana

Tagad var izveidot problēmsfēras indeksu ar komandas CREATE INDEX palīdzību.

Šī un pārējās operācijas tiks veiktas SQL*Plus programmā, jo tā nodrošina bufera teksta

izvadi (tieši tādā veidā indeksa metodes izvada informāciju darbības laikā). Problēmsfēras

indeksa izveidošana skatāma 5.70. attēlā.

5.70. att. Problēmsfēras indeksa izveidošana objektu kolonnai

Rezultātā tiek izvadīta visa informācija, kas norāda uz indeksa metodes

ODCIIndexCreate izsaukšanu. SYS.ODCIIndexInfoDump procedūra nodrošina vispārīgas

informācijas izvadi (indeksa īpašnieks, nosaukums, tabulas īpašnieks, tabulas nosaukums,

indeksējamā tabulas kolonna un tas tips). Šī ir speciāla Oracle metode, kura palīdz testēt

problēmsfēras indeksa darbību, un kuru es izmantoju visās indeksa metodēs.

5.71. attēlā ir redzama ODCIIndexCreate izvadītā operācija. Tiek realizēts vaicājums

indeksa tabulas izveidošanai (a), kā arī divi vaicājumi tās aizpildīšanai (b), kuru savstarpējā

mijiedarbība jau tika aprakstīta iepriekš: viens no tiem izgūst katras rindiņas identifikācijas

numuru no pamattabulas, kas tiek izmantots vērtību aizpildīšanai indeksa tabulā (c).

5.71. att. Metodes ODCIIndexCreate izvadītā informācija

Tagad var pamēģināt ievietot vērtības indeksa tabulā. Anonīmajā blokā tiek izveidots

72

objektu tipa eksemplārs, izsaukta tā metode (lai aprēķinātu maksimālo, minimālo un kopējo

energopieprasījumu), un tad šis objekts tiek ievietots tabulā (5.72. attēls).

5.72. att. Datu ievade tabulā ENERGO_TABULA

Kā reakcija datu ievietošanai pamattabulā ir ODCIIndexInsert metode. 5.73. attēlā ir

redzams tikai tās izvadītās informācijas fragments – pēc būtības tā izvada visus reģionu

numurus un attiecīgās elektroenerģijas patēriņa vērtības.

5.73. att. Metodes ODCIIndexInsert izvadītā informācija par datu ievadīšanu

5.74. attēlā var redzēt divu vaicājumu rezultātu fragmentus: reģionu vērtības no

pamattabulas un visas vērtības no indeksa tabulas. Kā redzams, rindiņas identifikators indeksa

tabulā ir viens un tas pats, kas norāda uz vienu un to pašu rindiņu pamattabulā (neaizmirsīsim,

ka pamattabulā ir tikai viena datu rindiņa). Ar bultiņām parādīts, kā reģionu vērtības tika

73

sasaistītas ar pozīciju un saglabātas indeksa tabulā.

5.74. att. Pamattabulas un indeksa tabulas datu salīdzināšana

Kā jau vairākkārt tika uzsvērts, datu indeksēšanas nolūks ir izvairīšanās no pilnas

pamattabulas rindiņu izskatīšanās ar nolūku atgriezt vaicājuma rezultātu ātrāk. Ja vien

iespējams, izgūstamo datu rindiņu identifikatori tiek iegūtu, balstoties uz indeksa tabulas

izskatīšanu. Parasti indeksa struktūra nodrošina ātrāku datu atlasi, taču dotajā gadījumā

nekāds sarežģīts algoritms netika realizēts – indeksēšanas mehānisms tika veidots

demonstratīvos nolūkos, lai parādītu, pēc kāda principa tiek paplašināts DBVS kodols un

realizēts problēmsfēras indeksa tips.

Kā jau zināms, indeksa mehānisms tiek iedarbināts gadījumā, kad vaicājuma WHERE

daļā parādās noteikts salīdzināšanas operators, kas norāda, pēc kādiem kritērijiem dati tiek

atlasīti. Problēmsfēras indeksa gadījumā tiek izsauktas indeksa metodes ODCIIndexStart,

ODCIIndexFetch un ODCIIndexClose, ar kuru palīdzību tiek izskatīta indeksa tabula un

atgrieztas vajadzīgās rindiņas. Pārliecināties, vai šīs metodes tiešām izpildās, var divos

veidos: novērot, vai šīs attiecīgās metodes tiek izsauktas (tiks izvadīta attiecīgā teksta

informācija), kā arī apskatoties vaicājuma izpildes plānu (ko veikšu ar EXPLAIN PLAN

komandu).

Ja vaicājums tiek veikts bez problēmsfēras indeksa operatoriem WHERE daļā, tad

vaicājuma izpildes plānā redzams, ka Oracle veic pilnu piekļuvi pamattabulai – TABLE

ACCESS FULL, ko var novērot, analizējot vaicājuma izpildes plānu, kas ir skatāms 5.75.

attēlā. Vaicājums ir samērā vienkāršs, un, kaut arī tas griežas pie problēmsfēras objektu tipa,

salīdzinot tā atribūtu ar noteiktu vērtību, vaicājuma WHERE daļā neparādās neviens no

sešiem problēmsfēras operatoriem.

74

5.75. att. Vaicājuma izpildes plāns bez problēmsfēras operatoriem

Savukārt, ja tiek veikts vaicājums, kura WHERE daļā parādās kāds no problēmsfēras

operatoriem, kas ir saistīts ar indeksa tipu, izpildes plāns norāda, ka datu atlase notiek no

indeksa tabulas EINDEKSS_EIND, Oracle veic piekļuvi indeksa tabulai, kā tas ir redzams

5.76. attēlā, kur vaicājuma WHERE daļā parādās operatora izteiksme:

ENERGO_VIENADS_JEBK(PARAUGS, 6) = 1.

5.76. att. Vaicājuma izpildes plāns ar problēmsfēras operatoru

Protams, tiek izsauktas arī attiecīgās indeksa skenēšanas metodes – ODCIIndexStart,

ODCIIndexFetch un ODCIIndexClose, kuru izvadāmā informācija attiecīgajam vaicājumam

ir skatāma 5.77. attēlā.

Kā redzams, balstoties uz operatora tipu, tā argumentiem un salīdzināmo vērtību, tiek

konstruēts attiecīgais vaicājums to pamattabulas rindiņu izgūšanai, kuri apmierinātu operatora

izteiksmes prasības. Mūsu gadījumā tie ir ieraksti, kuros jebkurā no reģioniem

elektroenerģijas patēriņa vērtība ir vienāda ar 6 (5.77. attēlā ar rāmīti apvilkta tā daļa, kurā

redzams dinamiski konstruēts vaicājums unikālo pamattabulas rindiņu identifikatoru

izgūšanai no indeksa tabulas).

75

5.77. att. Problēmsfēras indeksa metožu izvadītā informācija vaicājuma izpildes laikā

Ja no pamattabulas tiek dzēstas rindiņas, tad attiecīgi tiek izdzēstas visi ieraksti no

indeksa tabulas, kuri norāda uz pamattabulas rindiņu. Problēmsfēras indeksa reakcija uz

dzēšanu no pamattabulas skatāma 5.78. attēlā. Par vērtību dzēšanu atbild metode

ODCIIndexDelete, un tā konstruē attiecīgo vaicājumu datu dzēšanai no indeksa tabulas.

5.78. att. ODCIIndexDelete metodes reakcija uz pamattabulas datu dzēšanu

Pēdējā problēmsfēras indeksa funkcija ir attiecīgā reakcija uz tā dzēšanu. 5.79. attēlā ir

redzama problēmsfēras indeksa metodes ODCIIndexDrop izvadāmā informācija, kurā parādās

arī dinamiski izveidotais vaicājums attiecīgās indeksa tabulas dzēšanai.

76

5.79. att. ODCIIndexDelete metodes reakcija uz pamattabulas datu dzēšanu

Analīze parādīja, ka problēmsfēras indekss darbojas atbilstoši tam, kā tas tika plānots,

un attiecīgās indeksa metodes tiek izsauktas vajadzīgajā brīdī.

Jāpiebilst, ka dotajā gadījumā, realizējot datu bāzi, netika īstenots problēmsfēras

paplašināmais optimizators. Uz doto brīdi dati vienmēr tiks atlasīti, balstoties uz

problēmsfēras indeksu, kad vaicājuma WHERE daļā parādīsies saistītie problēmsfēras

operatori. Paplašināmais optimizators varētu nodrošināt efektīvāku vaicājuma ceļu izpildi, kā

arī dot iespēju izvairīties no tabulas vai indeksa skenēšanas gadījumos, kad tā ir bezjēdzīga

(piem., tiek veikts salīdzinājums konkrētam reģionam ar vērtību, kura neietilpst intervālā starp

minimālo un maksimālo elektroenerģijas patēriņu dotajam reģionam) – tādas iespējas ir

realizējamas tieši ar paplašināmā optimizatora palīdzību.

Praktiskā daļa aptvēra detalizētu paplašināmā indeksa darbības demonstrāciju un

analīzi uz samērā vienkārša piemēra. Nekāds sarežģīts algoritms netika realizēts, taču

paplašināmās indeksēšanas mehānisms tika demonstrēts pilnībā. Taču tas neizslēdz

algoritmiskās optimizācijas iespēju: lielu labumu no problēmsfēras indeksa varētu gūt tajā

gadījumā, ja, sastopot konkrēta reģiona numuru, notiktu to indeksa tabulas rindiņu

izskatīšana, kas atbilst dotajam reģionam. Šī struktūra varētu nedaudz atgādināt balansēto

koku struktūru, tika būtu krietni vienkāršāka, jo ir noteikts reģionu skaits, un jaunās vērtības

tiktu piesaistītas noteiktam reģionam.

77

SECINĀJUMI

Dotajā bakalaura darbā tika pētītas un analizētas datu bāzes vadības sistēmas kodola

paplašināšanas iespējas, kā arī veikta virspusēja tādas arhitektūras analīze. Veicot bakalaura

darbu, tika demonstrēti kodola paplašināšanas iespēju piemēri, balstoties uz Oracle DBVS, to

nepieciešamība sarežģīti un daļēji strukturētu datu apstrādes efektivitātes palielināšanai datu

bāzes servera pusē. Praktiskais piemērs parādīja, kā var tikt realizēts problēmsfēras indekss un

kādā veidā tas tiek integrēts DBVS kodolā. Balstoties uz darbā veiktajiem posmiem, tika

izdarīti vairāki secinājumi.

1. Lielie objekti ir viens no risinājumiem, ar kuru palīdzību var uzglabāt sarežģīti

strukturētus, daļēji strukturētus un nestrukturētus datus datu bāzē. Taču, ja DBVS

nenodrošina iespēju veikt šo datu apstrādi datu bāzes servera pusē (atstājot to

lietojumu ziņā), to var uzskatīt par neefektīvu koplietojamo datu uzglabāšanas

organizāciju – lai lietojumi izgūtu vajadzīgo informāciju, kuru satur lielo objektu

eksemplāri, tos pilnībā jānogādā lietojumiem (vai starpprogrammatūrai). Tas nozīmē,

ka tīklā pārraidāmās informācijas apjoms būs krietni lielāks, nekā tas būtu tajā

gadījumā, kad vajadzīgā datu analīze tiktu veikta datu bāzes servera pusē, un

lietojumam tiktu nogādāta tikai pieprasītā informācija.

2. DBVS kodola paplašināšanas arhitektūras iezīmes jau parādījās vairākus gadus

atpakaļ, taču to joprojām var nosaukt par samērā jaunu tehnoloģisku risinājumu.

Relāciju datu bāžu modelis, pielietojot standarta skalāros datu tipus, arī mūsdienās

apmierina vairākumu lietojumu koplietojamo datu uzglabāšanas prasības. Taču,

palielinoties datu apjomam un datu struktūru sarežģītības līmenim, jāsecina, ka DBVS

kodola paplašināšana kļūs par neatņemamu sastāvdaļu to lietojumu realizācijā, kuros ir

vajadzība pēc datu bāzes servera efektīvai sarežģīti strukturētu koplietojamo datu

uzglabāšanai. Piem., telpisko datu uzglabāšana un apstrāde datu bāzes servera pusē ir

viens no plašākajiem tādas arhitektūras pielietojumiem.

3. Lietotāju definētos tipus varētu nosaukt par visplašāk pielietojamo DBVS kodola

paplašināšanas iespēju. Daudzas DBVS sistēmas piedāvā paplašināmo tipu sistēmu, ar

kuru palīdzību iespējams definēt tipus, kas satur vairākus atribūtus un, iespējams, arī

noteiktas metodes datu tipa uzvedības definēšanai – gluži kā ar klasēm

objektorientētajā programmēšanā. Pateicoties tādiem lietotāju definētajiem tipiem ir

iespējams vienkāršot sarežģītu entītiju uzglabāšanu datu bāzē, kā arī veikt attiecīgās

78

operācijas, kas tiek nodrošināts ar datu bāzes servera programmēšanu. Lietotāju

definētie tipi ir relāciju – objektu datu bāžu pamats.

4. Neskatoties uz to, ka lietotāju definētu tipi un objektorientētā pieeja datu bāžu

projektēšanā sniedz plašas iespējas, pilnvērtīgai datu apstrādes optimizācijai datu

bāzes servera pusē ar to vien ir par maz. Par pilnvērtīgu to var nosaukt tajā gadījumā,

ja problēmsfēras dati tiek apstrādāti analoģiski standarta skalārajiem datu tipiem – tos

iespējams indeksēt problēmsfērai raksturīgajā manierē, tiem var realizēt problēmsfēras

agregātfunkcijas un funkcijas, kas spēj saprast un interpretēt šos datus, kā arī optimizēt

problēmsfērai raksturīgo vaicājumu izpildi.

5. Balstoties uz dažādu literatūras avotu analīzi [1, 2, 5, 10], Oracle varētu nosaukt par

perspektīvāko DBVS, kas piedāvā kodola paplašināšanas arhitektūru. Ar dažāda veida

interfeisiem iespējams definēt DBVS uzvedību problēmsfēras datu apstrādē. Ar to

palīdzību var definēt DBVS kodola reakciju uz dažāda veida problēmsfēras datu

apstrādes procedūrām. Oracle ar savu arhitektūru piedāvā ne tikai sarežģīti strukturētu

datu definēšanas iespēju, bet arī to efektīvu apstrādi datu bāzes servera pusē ar

paplašināmās indeksēšanas un vaicājumu optimizācijas rīku palīdzību.

6. Par nopietnāko Oracle DBVS kodola paplašināšanas iespēju var droši uzskatīt

paplašināmo indeksēšanu, kas dod iespēju realizēt problēmsfēras indeksu, optimizējot

datu glabāšanas struktūru tādā veidā, kas nodrošinātu visātrāko vajadzīgo datu atlasi

vaicājuma darbības laikā. Oracle paplašināmās indeksēšanas mehānisms neuzstāda

nekādus ierobežojumus indeksēšanas algoritmam, kā tas ir, piem., IBM DB2

gadījumā, kur indeksa struktūra var būt tikai balansētais koks. Indeksa struktūra un

glabāšanas veids DBVS nav zināms – realizējot paplašināmās indeksēšanas

mehānismu, programmētājam jārealizē galvenās metodes, kuras reaģēs uz datu bāzes

notikumiem, kā, piem., indeksa izveidošanu vai izdzēšanu, kā arī pamattabulas rindiņu

izgūšanu to vaicājumu laikā, kuros tiek veikta noteikta problēmsfēras datu atlase.

7. Oracle kodola paplašināšanas arhitektūras attīstība liecina par šīs tehnoloģijas

perspektīvajām iezīmēm. Oracle Spatial un interMedia kodola paplašinājumi jau tiek

atbalstīti un attīstīti, sākot ar Oracle 8i versiju; Oracle kodola paplašināšanas

arhitektūra tiek plaši izmantota arī ķīmijas datu bāžu realizācijai – kā piemērs var

kalpot JChem un Daylight kodola paplašinājumi, kuri realizē ne tikai problēmsfēras

datu tipus, bet plašu funkciju klāstu un indeksācijas mehānismu ar nolūku efektīvāk

veikt ķīmisko formulu uzglabāšanu un analīzi (it sevišķi organiskajā ķīmijā).

79

8. Problēmsfēras indeksa tipa realizācija ir ļoti sarežģīts process, kur mazākā kļūda

algoritmā var atspoguļoties uz datu apstrādes precizitāti – Oracle DBVS neko nezin

par indeksēšanas algoritmu, kas atgriež pamattabulas rindiņas vaicājuma laikā. Ja

algoritmā ir kļūda, tad pilnīgi iespējams, ka vaicājumu izpilde būs nekorekta, kas var

novest pie nevēlamām sekām. Tādēļ pēc problēmsfēras indeksa tipa izstrādes

ieteicams salīdzināt vaicājumu rezultātus abos gadījumos: gan datu indeksēšanas

gadījumā, gan arī bez tās.

9. Viena no svarīgākajām īpašībām problēmsfēras datu apstrādē un jo sevišķi

problēmsfēras indeksa realizācijā ir dinamiskā SQL iespējas, ar kura palīdzību var

veidot vaicājumus, balstoties pēc apstākļiem. Oracle DBVS atbalsta gan dinamisko

SQL, gan arī dinamisko PL/SQL, ar kura palīdzību ir iespējams ne tikai konstruēt no

mainīgajiem standarta SQL vaicājumus, bet arī veselus PL/SQL izejas tekstus kā

tekstu, un vēlāk tos izpildīt. Šis rīks ir neatņemams tajos gadījumos, kad, piem.,

atkarībā no problēmsfēras operatora jāizveido attiecīgais indeksa tabulas skenēšanas

vaicājums, kā tas bija praktiskajā piemērā – balstoties uz operatora izteiksmi, tā

argumentiem un salīdzināmo vērtību, tika konstruēts vaicājums, kas izskatīja indeksa

tabulu, nu jau izmantojot salīdzināšanas operatorus skalārajiem datu tipiem.

80

LITERATŪRA

1. Acker R., Pieringer R., Bayer R. Towards Truly Extensible Database Systems.

Whitepaper – Transaction Software GmbH, 2005 - 10 p.

2. Dittrich K., Geppert A. Component Database Systems. – Morgan Kaufmann, 2000 –

294 p.

3. Gallardo D. Java Oracle Database Development. – Prentice Hall PTR, 2002 – 420 p.

4. Hernandez M. Database Design for Mere Mortals. – Addison Wesley, 2003 – 672 p.

5. Oracle Corporation. Oracle Data Cartridge Developer’s Guide, 10g Release 1. –

Oracle Corporation, 2003

6. Oracle Corporation. Oracle Database Application Developer's Guide – Fundamentals,

10g Release 1. – Oracle Corporation, 2003

7. Oracle Corporation. Oracle Database Application Developer's Guide – Large Objects,

10g Release 1. – Oracle Corporation, 2003

8. Oracle Corporation. Oracle Database Concepts, 10g Release 1. – Oracle Corporation,

2003

9. Oracle Corporation. Oracle Database SQL Reference 10g Release 1. – Oracle

Corporation, 2003

10. Rennhackkamp M. Extending Relational DBMS [Electronic resource] – Online

resource – DBMS and Internet Systems, 1997 – Access: web. URL:

http://www.dbmsmag.com/9712d15.html - Resource reviewed at 20th of May, 2006

11. Sarda S. Extensible Indexing - What is it and who needs it? [Electronic resource] –

Online resource. – Oracle. Oracle Technology Network, 2006 – Access: web. URL:

http://www.oracle.com/technology/pub/articles/sarda-ext-index.html - Resource

reviewed at 6th of May, 2006

12. Галатенко В., Ладыженский Г. Объектные технолокии в продуктах Oracle // Jet

Info: Информационный бюллетень – № 9-10 (1998), с. 20 – 35

13. Кайт Т. Oracle для профессионалов. Книга 2. Архитектура и основные

особенности. – ДиаСофт, 2005 – 656 с.

14. Кайт Т. Oracle для профессионалов. Книга 2. Расширение возможностей и

защита. – ДиаСофт, 2005 – 816 с.

15. Урман С. Oracle8i. Новые возможности на языке PL/SQL. – Москва: Лори, 2001

– 654 с.

81