Upload
dangtram
View
227
Download
5
Embed Size (px)
Citation preview
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