Lielo objektu risinājumi DBVS MS Access

Text tipa lauks – maksimums 255 simboli.

Memo tipa lauks - maksimums 65 536 simboli.

OLE Object tipa lauks – formatēta teksta glabāšana.

Lielie objekti (LOB) un to tehnoloģija

1. Lielie objekti ir datu tipi, kurus izmanto, lai darbotos ar nestrukturizētiem

datiem.

2. Ar nestrukturizētiem datiem datu bāzu sistēma saprot tos datus, kuru tipus tā

neatpazīst.

3. Par nestrukturizētiem datiem datu bāzu sistēmai ir zināms, ka dati ir dažāda

garuma bitu virknējumi. Piemēram, attēla binārā forma:

4. Lielo objektu uzdevums ir glabāt liela apjomu datus.

2

Lielie objekti

1. Daudzpunktu (piece-wise) piekļuve – nodrošina piekļūšanu lielajam objektam

jebkurā punktā, pretstatā LONG datu tipa datiem var piekļūt tikai virkņu veidā, tas ir,

lasot no sākuma vai beigām, nevis uzreiz griežoties pie konkrētās datu atrašanās

vietas.

2. LOB lokators ir sistēmas ģenerēta vērtība, kura ir piekārtota katrai LOB instancei,

attiecīgi katrai LOB instancei ir savs lokators un vērtība.

3

Daudzpunktu piekļuve (piece-wise)

Virkņu veida piekļuve

Lielo objektu koncepcijas vēsturiskā attīstība

Oracle LOB attīstība: Oracle datu bāzes sistēma jau no agrīnajām versijām piedāvā

atbalstu nestrukturizētu datu glabāšanai.

Sākotnējās datu bāzes sistēmas versijās tika piedāvāti datu tipi LONG un LONG

RAW, kuri tika izveidoti un ieviesti tieši šādu uzdevumu risināšanai. Kopš Oracle

datu bāzes sistēmas astotās versijas (versija 8.0), tiek piedāvāts jauns risinājums -

lielie objekti jeb LOB.

IBM DB2 LOB attīstība: Sākot ar DB2 piekto versiju (versija 5.0) IBM piedāvāja

DB2 glabāt tādus datus, kā attēlus, video, audio un tekstu.

DB2 izstrādātāji šo datu glabāšanai lietoja lielos objektus, lai gan pirms lielo objektu

tehnoloģijas ieviešanas šajā datu bāzes sistēmā nestrukturizētie dati tika glabāti ar

datu tipu VARCHAR un VARGRAPHIC palīdzību.

PostgreSQL LOB attīstība: Jau sākot ar agrīnajām versijām PostgreSQL izstrādātāji

bija ieviesuši vairākus lielo objektu implementēšanas veidus, tomēr pieaugot datu

bāzes sistēmas popularitātei un lietotāju skaitam, tās izstrādātāji nolēma palikt pie

viena implementēšanas veida, attiecīgi - lielo objektu glabāšana datu bāzes iekšējās

struktūrās.

1983 19851984 1989198819871986 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006

v1.0

Oracle

IBM DB2

PostgreSQL

v4.0

v1.0 v3.0

v6.0 v7.0h

v5.0 **

v8.0 **

v7.1 **

v10.0g

v8.0

v8.1

** versija, ar kuru ir ieviests stabils lielo objektu atbalsts

4

Oracle 11g datu bāzes sistēmas risinājumi

Oracle 11g datu bāzes sistēmā, šie jautājumi tiek risināti ar datu bāzes SecureFiles

tipa objektiem – jauniem, ātrdarbīgiem lielajiem objektiem, kas ļauj izgūt grafiskos

datus ātrumos, kas līdzvērtīgi, un pat ātrāki kā ekvivalentās datņu sistēmu

konfigurācijās.

1) BLOB jeb binārais lielais objekts glabā dažāda veida datus binārajā formā. Parasti

tiek izmantots attēlu, audio un video datu glabāšanai.

2) CLOB jeb simbolu lielais objekts glabā simbolu virkņu datus datu bāzes

rakstzīmju kopas formātā.

3) NCLOB jeb nacionālo simbolu lielais objekts glabā simbolu virkņu datus

nacionālo rakstzīmju kopu formātā. Atbalsta dažāda garuma simbolu glabāšanu,

piemēram, Ķīnā lietoto rakstu zīmju glabāšanu.

4) BFILE jeb ārēja bināra datne ir speciāls SecureFiles datu tips - binārā datne, kura

tiek glabāta operētājsistēmā, bet datu bāzes sistēmai ir iespēja piekļūt šai datnei.

Uzlabotie SecureFiles algoritmi ir vairākas reizes ātrāki kā iepriekšējo LOB jeb lielo

objektu algoritmi.

5

IBM DB2 8.2 datu bāzes sistēmas lielo objektu tipi

BLOB (Binārais lielais objekts)

CLOB (Simbolu lielais objekts)

DBCLOB (Divbaitīgo simbolu lielais objekts)

IBM DB2 8.2 LOB datu tipi

IBM DB2 8.2 datu bāzes sistēma piedāvā trīs pamata LOB datu tipus:

1) BLOB (binārais lielais objekts) – glabā līdz 2GB apjoma dažāda veida datus

binārajā formā DB2 datu bāzē. Parasti tiek izmantots attēlu, audio un video

informācijas glabāšanai.

2) CLOB (simbolu lielais objekts) - glabā līdz 2GB apjoma vienbaitīgo simbolu

datus. CLOB ir piemērots datu tips apjomīgu teksta dokumentu glabāšanai.

3) DBCLOB (divbaitīgo simbolu lielais objekts)– glabā līdz 1GB divbaitīgo simbolu

datus (kopumā tas ir 2GB). DBCLOB ir piemērots datu tips, lai glabātu apjomīgus

dokumentus, kuri sastādīti valodās, kurās simbola aprakstīšanai nepieciešami divi

baiti, piemēram, Japānas rakstu zīmju kandži simboli.

DB2 datu bāzē šie trīs lielo objektu datu tipi var glabāt datu apjomu, kurš ir par vienu

baitu mazāk nekā 2GB.

6

PostgreSQL 8.1 datu bāzes sistēmas lielo objektu datu

tipi

PostgreSQL datu bāzes sistēmā nav ieviests vienkāršo lielo objektu datu tipu atbalsts,

attiecīgi nav pieejams neviens lielo objektu datu tips.

BYTEA datu tips ļauj PostgreSQL datu bāzes sistēmā glabāt binārās vai oktetu

virknes. Binārā virkne šajā kontekstā ir baitu virknējums, kura no simbolu virknes

atšķiras ar to, ka tā ļauj glabāt oktetus ar vērtību nulle un citām neierastām vērtībām,

kuras parasti ir ārpus 32-126 vērtību diapazona. Simbolu virknes neļauj glabāt nulles

vērtību oktetus, kā arī neļauj glabāt oktetu vērtības, kuras neatbilst datu bāzes

izvēlētajam simbolu kodēšanas veidam.

Operācijas ar binārajām virknēm darbojas tieši ar baitiem, kamēr simbolu virkņu

apstrāde vadās arī pēc iestatījumiem, piemēram, simbolu kodēšanas tabulas.

BYTEA tipa kolonnas var saturēt dažāda garuma vērtības, tomēr praksē pierādās, ka

maksimālais apjoms ir 1GB.

Ja salīdzina BYTEA teksta vērtību ievades veidu ar vienkāršo simbolu datu tipa

ievades veidu, ir pamanāmas atšķirības. Zīmīgākā no tām ir tā, ka pielietojot BYTEA

datu tipu un ievadot simbolu vērtības, ir jāpielieto divas reizes vairāk simbolu „\” -

slīpsvīra, nekā tas ir simbolu datu tipa vērtībām. Šī nianse ir zīmīga PostgreSQL

īpatnība.

Piemēram, ja lietojot BYTEA jāievada vērtība „Šī ir slīpa līnija \”, tad reāli tā pie

ievades izskatās „Šī ir slīpa līnija \\\\”. Šo slīpsvītru lietošanas specifika ir saistīta ar

PostgreSQL servera divu pakāpju simbola virkņu analizēšanas manieri.

7

Lielo objektu glabāšana Oracle 10g datu bāzes sistēmāNo glabāšanas viedokļa, Oracle 11g datu bāzes sistēmā SecureFiles tipa objekti var

būt divu veidu:

1) iekšējie SecureFiles tipa objekti – tiek glabāti datu bāzes telpās. Kā iekšējos

SecureFiles datu tipus var minēt BLOB, CLOB un NCLOB.

2) arējie SecureFiles tipa objekti – ir datu objekti, kuri tiek glabāti operētājsistēmas

datnēs - ārpus datu bāzes tabulu telpām. Datu bāzes sistēma piekļūst šiem objektiem

lietojot datu tipu BFILE. BFILE datu tipa objektam piemīt tikai lasīšanas tiesības.

8

1. Iekšējie LOB – lielie objekti tiek glabāti datu bāzē. Kā iekšējos LOB datu tipus

var minēt BLOB, CLOB un NCLOB.

Iekšējie lielie objekti var būt:

1) patstāvīgi objekti;

2) pagaidu objekti.

Patstāvīgs LOB ir tāds, kura instance eksistē tabulas rindā – datu bāzē.

Pagaidu LOB instance tiek izveidota LOB inicializācijas laikā uz nelielu brīdi,

piemēram, lietojuma darbības laikā. Pagaidu instance kļūst par patstāvīgu tad, kad tā

tiek ievietota tabulas rindā.

Patstāvīgie LOB var piedalīties datu bāzes sistēmas transakcijās. Tos var restaurēt, ja

notikusi transakcijas kļūda. Tāpat visas izmaiņas, kuras tiek veiktas ar patstāvīgajiem

lielajiem objektiem var tikt atgrieztas (rollback) un apstiprinātas (commit).

No izmantotās semantikas viedokļa, iekšējiem lieliem objektiem lieto kopēšanas

semantiku, attiecīgi, gan LOB rādītājs (lokators), gan arī objekta vērtība tiek loģiski

kopēta, piemēram, pie INSERT operācijas veikšanas. Šī veida semantika nodrošina

to, ka katra tabulas šūna vai katrs mainīgais, kurš satur lielo objektu, satur unikālu

LOB instanci.

9

2. Ārējie LOB – ir datu objekti, kuri tiek glabāti operētājsistēmas failos, ārpus datu

bāzes tabulu telpām. Datu bāzes sistēma piekļūst šiem lielajiem objektiem lietojot

datu tipu BFILE, kurš ir vienīgais vienkāršais Oracle 10g ārējo LOB datu tips.

BFILE datu tipa objektam piemīt tikai lasīšanas tiesības, kas nozīmē, ka nepastāv

iespējas BFILE datu tipa datos ierakstīt lietojuma informāciju. Datu bāzes sistēma,

darbojoties ar BFILE objektiem, izmanto rādītāju semantiku, tas ir, dati paliek

glabāties operētājsistēmā, nevis tiek ievietoti datu bāzes tabulu telpā, kopēts tiek tikai

LOB rādītājs.

Datu bāze

Operētājsistēma

BFILE objekts 1

Tabula

rādītājs1

10

BFILE parasti tiek lietots, lai glabātu:

1) bināros datus, kuri neizmainās lietojuma darbības laikā, piemēram, grafiskā

informācija;

2) datus, kuriem ir baitu plūsmas piekļuve, piemēram, video;

3) tikai nolasāmus datus, kuri apjoma ziņā ir pārāk lieli, lai tos glabātu datu bāzes

iekšējās struktūrās.

BFILE glabāšanai ir pieejama jebkura glabāšanas iekārta, kurai var piekļūt

operētājsistēma, attiecīgi šīs iekārtas var būt gan cietie diski, gan arī citi atmiņas

nesēji, piemēram, DVD un CD.

LOB lokators ir sistēmas ģenerēta vērtība, kura ir piekārtota katrai LOB instancei,

attiecīgi katrai LOB instancei ir savs lokators un vērtība.

LOB lokators ir rādītājs jeb atsauce uz fiziski glabāto LOB vērtību. LOB vērtība ir

dati, kuri tiek glabāti lielajā objektā. Kad tiek veikta operācija ar LOB, piemēram,

LOB tiek nodots kā parametrs, tad patiesībā nenotiek manipulēšana ar patieso lielā

objekta vērtību, bet gan ar LOB lokatoru.

Ja lielais objekts tiek inicializēts ar NULL vērtību, tad šim objektam netiek izveidots

lokators, savukārt, ja LOB tiek inicializēts ar nulli vai kā tukšs, tad neskatoties uz to

lielajam objektam tiek izveidots lokators.

Tātad LOB lokatori tiek glabāti LOB kolonnās. Atkarībā no kolonnu īpašībām, kuras

tiek iestatītas pie kolonnu izveides, LOB vērtības tiek glabātas vai nu tabulu rindās

(in-line) vai ārpus tabulu rindām (out-of-line).

Ja Oracle 10g datu bāzes sistēmā veido tabulu, kurā ir ietverta LOB kolonna, tad

sistēma automātiski izveido divus segmentus, kuros šīs LOB kolonnas patiesie dati

tiks glabāti. Šie segmenti ir LOBSEGMENT un LOBINDEX.

LOBINDEX segments ir domāts, lai veidotu piekļuvi lielajiem objektiem, kuri

glabājas LOBSEGMENT segmentā.

Šie abi segmenti Oracle 10g versijā glabājas tajā pašā tabulu telpā, kurā glabājas

tabula, kas satur šo segmentu lielos objektus.

11

Tomēr Oracle izstrādātāji iesaka to, ka, ja tiek veikta bieža piekļuve dažādiem

lielajiem objektiem, tad noderīgi ir nodefinēt atsevišķu tabulu telpu katrai LOB

kolonnai.

Datu bāzeTabulu telpa

Tabulas segments LOBINDEX segments

LOBSEGMENT segments

LOBZ1

LOBZ2

LOBZ3

Glabāšanu tabulu rindās Oracle izstrādātāji iesaka izmantot gadījumos, kad datu

bāzes lielajos objektos tiek glabātas relatīvi mazas vērtības (līdz 4 kilobaiti), pārējos

gadījumos vajadzētu izvēlēties glabāšanu ārpus tabulu rindām. (Paapanen, 2004)

Glabājot LOB tabulu rindās vieta lielajiem objektiem tiek rezervēta tabulas segmentā,

bet LOBINDEX un LOBSEGMENT segmenti paliek tukši.

LOB vērtības tabulu rindās tiek glabātas sekojošos gadījumos:

1) ja tiek definēts izteikums ENABLE STORAGE IN ROW, pie tabulas izveides un

ja glabājamā LOB apjoms ir mazāks kā 4 kilobaiti;

2) kad LOB vērtība ir NULL.

Glabājot LOB ārpus tabulu rindām vieta lielajiem objektiem tiek rezervēta

LOBSEGMENT segmentā.

LOB vērtības ārpus tabulu rindām tiek glabātas sekojošos gadījumos:

1) pēc noklusējuma, tas ir, ja tabulas izveides procesā netiek noteikts LOB glabāšanas

parametrs;

12

2) ja tabulas izveides procesā tiek noteikts parametrs DISABLE STORAGE IN

ROW;

3) gadījumā, ja LOB izmērs ir lielāks kā 4 kilobaiti.

LOB lokatori vienmēr tiek glabāti tabulas rindās, tāpat LOB lokators eksistē katrai

LOB instancei, vienalga vai LOB vērtība ir nulle vai cita.

LOB glabāšanas iestatījumi attiecas tikai uz iekšējiem LOB, BFILE datu tipa

kolonnas šie iestatījumi nekādā veidā neietekmē, jo BFILE dati tiek glabāti

operētājsistēmas failos ārpus datu bāzes.

Jāmin, ka lielo objektu indekss ir iekšēja struktūra, kas ir cieši saistīta ar LOB

glabāšanu. Tas nozīmē, ka lietotājs nevarēs dzēst LOB indeksu vai pārbūvēt to. LOB

indeksu nevar izmainīt.

Sistēma noskaidro kuru tabulu telpu izmantot LOB datiem un LOB indeksiem

atkarībā no LOB glabāšanas specifikācijas:

1) ja netiek norādīta tabulu telpa LOB datiem, tad pēc noklusējuma LOB datiem un

indeksiem tiek izmantota pamatdatu tabulas tabulu telpa;

2) ja LOB datiem norāda atsevišķu tabulu telpu, tad gan LOB dati, gan arī LOB

indekss izmantos šo definēto tabulu telpu.

LOB kolonnām nevar pielietot B-koka un Bitmap tipa indeksus. Pie tam Oracle

izstrādātāji papildus tradicionālajiem indeksiem, lielajiem objektiem piedāvā

izmantot paplašinājumu indeksus, piemēram, Oracle Text indeksu, kā arī

administratoram pašam definēt savus indeksus ar izteikuma INDEXTYPE palīdzību.

Tieši šāda administratora iespēja definēt jaunus indeksus ļauj datu bāzes sistēmas

lietotājiem sekmīgāk operēt ar lielo objektu datiem - šie definētie indeksi tiek

pievienoti pārējo indeksu klāstam.

Pastāv iespēja sadalīt tabulas, kuras satur LOB kolonnas. Rezultātā ir iespēja pielietot

prioritātes, kuras sniedz tabulu dalīšana:

1) LOB segmenti var tikt dalīti un izvietoti vairākās tabulu telpās, sabalansējot datu

bāzes sistēmas noslodzi un padarot vieglāk vadāmu rezerves kopēšanu un

atjaunošanu;

13

2) lielie objekti dalītajās tabulās ir vieglāk uzturami;

3) lielie objekti var tikt dalīti loģiskās grupās, lai paātrinātu grupu piekļuves

operācijas.

14

Lielo objektu glabāšana IBM DB2 8.2 datu bāzes

sistēmā

IBM DB2 izstrādātāji ir arī apzinājušies, ka manipulēt un pārvietot lielos objektus ir diezgan

dārgs process, tādēļ ar LOB datiem darbības notiek savādāk, nekā ierasts darbojoties ar

vienkāršajiem datiem.

Lielie objekti netiek glabāti tajā pašā struktūrā, kurā pārējie dati. Tabula, kurā tiek ieviesti

lielie objekti satur deskriptorus, kuri norāda uz patiesajiem lielajiem objektiem.

Savukārt LOB vērtības tiek glabātas atsevišķā tabulā – palīgtabulā (auxiliary table), kura

atrodas speciālā tabulu telpā, kuru sauc par LOB tabulu telpu.

Programmas, kuras lieto lielos objektus tiek rakstītas izmantojot LOB lokatorus. LOB

lokators parāda lielā objekta vērtību, lai gan patiesībā tas nesatur LOB datus. (skat. 2. piel.) Šī

metode tiek izmantota tādēļ, ka lielie objekti parasti ir apjomīgi, attiecīgi no resursu izmantošanas

viedokļa, manipulēšana ar šo objektu vērtībām var prasīt lielu daudzumu sistēmas resursus un

izmaksāt dārgi.

Tātad LOB kolonnas satur tikai informāciju par lielo objektu un tabulas, kurās ir ietvertas šīs

LOB kolonnas parasti tiek sauktas par bāzes tabulām.

15

LOB kolonnu izveides procesā sistēma automātiski izveido ROWID kolonu, kura pēc tam tiek

izmantota LOB datu atrašanai. ROWID kolonna satur 19 baitu garas sistēmas ģenerētas ROWID

vērtības, kur katra vērtība ir unikāla un identificē konkrēto tabulas rindu.

Vienai tabulai var būt tikai viena ROWID kolonna. LOB tabulai tiek veidots palīgindekss

(aux index), kurš ir arī tikai viens uz visu LOB tabulu telpu. Indeksa atslēgas ir ROWID vērtību

versijas. (Roberts, 2005)

DB2 nianse ir tā, ka viena LOB tabulu telpa ar vienu palīgtabulu var būt tikai vienai kolonnai,

vienā daļā (partīcijā), kas nozīmē, ja ir trīs LOB kolonnas tabulai, kas sadalīta 10 daļās, tad kopā

būs jāveido 30 LOB tabulu telpas. (sk. 2.11. att.)

2.11. att. Bāzes un palīgtabulas sasaiste glabājot LOB DB2 datu bāzē.

ROWID vērtība kopā ar versiju unikāli identificē lielo objektu LOB tabulu telpā. LOB tabulu

telpu nevar dalīt, tas ir - nevar veidot LOB tabulu telpas partīcijas.

LOB tabulu telpai ir jābūt izveidotai tajā pašā datu bāzē, kurā atrodas bāzes tabula.

16

Lielo objektu glabāšana PostgreSQL 8.1 datu bāzes

sistēmāPostgreSQL datu bāzes sistēmā lielie objekti ir glabāšanas metode, nevis datu tips. Šī

metode ļauj datu bāzē glabāt lielas kolonnas atsevišķi no kortežu pārējiem datiem.

Vienkāršo ierakstu tabulā netiek glabātas lielo objektu vērtības, to vietā glabājas OID,

kas ir rādītāji un konkrētiem lielajiem objektiem.

Implementējot lielos objektus šajā datu bāzē, objekti tiek sadalīti daļās un šīs daļas

tiek glabātas speciālā datu bāzes tabulā.

Lielā objekta daļiņas tiek indeksētas ar B-koka veida indeksēšanu, attiecīgi ļaujot šīs daļiņas ātri

vien sameklēt.

Būtībā PostgreSQL datu bāzes sistēma piedāvā trīs veidus kā var glabāt nestrukturizētos

datus. Viens no tiem ir lielie objekti, otrs ir ar datu tipa BYTEA palīdzību un trešais ir pielietojot

mehānismu TOAST.

Jaunākajā PostgreSQL literatūrā jau tiek minēts, ka TOAST mehānisms padara lielo objektu

tehnoloģiju PostgreSQL datu bāzes sistēmā par mazliet novecojušu un neaktuālu. (Douglas, 2005)

17

TOAST ļauj apstrādāt nestrukturizētos un apjomīgos datus tā, lai to glabāšana noritētu

sekmīgi.

Kopš PostgreSQL 7.1 versijas iznākšanas TOAST mehānisms kļuva par būtisku sistēmas

sastāvdaļu. TOAST veic apjomīgu vērtību saspiešanu un dalīšanu vairākās fiziskās rindās. Šis

process norit bez lietotāja iejaukšanās.

Ja kādas no kolonnām ir apjomīgas - pārāk lielas, lai saspiestu vai glabātu nesaspiestas kopējo

datu tabulā, tad datu bāzes sistēma automātiski tabulai, kurā atrodas šī kolonna izveido piekārtoto

TOAST tabulu, sasaistot tās ar objekta identifikatora palīdzību. Šo glabāšanas veidu pazīst, kā ārējo

glabāšanas veidu (out-of-line storing).

Ārējās TOAST apstrādātās (saspiestās un gabalos sadalītas) vērtības tiek glabātas TOAST

tabulā. Vērtību daļu maksimālais izmērs baitos tiek noteikts ar parametru

TOAST_MAX_CHUNK_SIZE.

Katrs gabals tiek glabāts kā atsevišķa rinda TOAST tabulā. Katrai TOAST tabulai ir kolonnas:

1.) CHUNK_ID - OID, kurš identificē noteikto ar TOAST apstrādāto vērtību.

2.) CHUNK_SEQ (kārtas numurs, kurš norāda gabala atrašanās vietu apstrādātajā vērtībā.

3.) CHUNK_DATA, kurā atrodas patiesā gabala vērtība.

Unikālais indekss, kurš izveidots CHUNK_ID un CHUNK_SEQ kolonnām, ļauj ātri izgūt

nepieciešamos gabalus. (sk. 2.13. att.)

18

Rādītāja datiem, kuri reprezentē ārējo ar TOAST apstrādāto vērtību, ir jāglabā arī OID, kurš norāda

uz TOAST tabulu un arī otru OID, kurš norāda uz gabala specifiskiem datiem (CHUNK_ID). Tāpat

rādītāju dati satur loģisko oriģinālo (nedalīto un nesaspiesto) datu apjomu un fiziski glabāto

apjomu, kas var būt mainīgs atkarībā no tā vai ir pielietota saspiešana.

Ar izteikuma SET STORAGE palīdzību ir iespējams iestatīt dažādas TOAST mehānisma

darbošanās stratēģijas: (PostgreSQL Global Development Group, 2005)

1.) PLAIN - neatļauj nedz vērtību saspiešanu nedz ārējo glabāšanu. Šī ir vienīgā glabāšanas

stratēģija datu tipiem, kurus nevar apstrādāt ar TOAST mehānismu.

2.) EXTENDED – ļauj gan saspiešanu gan ārējo glabāšanu. Šī stratēģija tiek pielietota

vairums datu tipiem, kurus apstrādā ar TOAST. Vispirms datus mēģina saspiest, bet pēc tam, ja tie

joprojām ir pārāk lieli, glabā ārēji. (out-of-line)

3.) EXTERNAL – ļauj ārējo glabāšanu, bet neļauj saspiešanu.

4.) MAIN – ļauj saspiešanu, bet neatļauj ārējo glabāšanu. (Patiesībā pielietojot šo stratēģiju

var tikt izmantota arī ārējā glabāšana, bet tā tiek pielietota tikai ārkārtas gadījumā, ja glabājamie

dati ir pārāk apjomīgi.)

TOAST apstrāde ir neredzama SQL darbošanās līmenī. TOAST mehānisms ir alternatīva lielo

objektu tehnoloģijai PostgreSQL datu bāzes sistēmā, tomēr PostgreSQL datu bāzes sistēmā var

realizēt to, ka arī lielie objekti tiek papildus apstrādāti ar TOAST mehānismu.

Šie trīs glabāšanas veidi ir aktuāls jautājums informācijas sistēmu projektētājiem, piemēram,

ja ir nepieciešamība PostgreSQL datu bāzē saglabāt attēlu - ja to tikai izmantos apskatei, tad

BYTEA tips būs piemērota izvēle. Ja attēls ir apjomīgs tad tas tiek apstrādāts ar TOAST

mehānismu.

Lielos objektus būtu izdevīgi izmantot, ja kāds lietojums veiks manipulācijas ar attēla saturu.

Lietojot lielo objektu glabāšanu pastāv iespējas objektā piekļūt noteiktam punktam, izmanīt

attiecīga apgabala vērtības un veikt citas operācijas, kuras ir izveidotas ar kādu no programmēšanas

valodām, piemēram, C valodā izstrādātu saskarni.

Ja lietot vienkāršu ar TOAST apstrādātu BYTEA kolonnu, tad, piemēram, viena bita izmaiņai

attēlā būtu nepieciešams ielasīt visu attēlu un pēc tam to pārglabāt no jauna. (Mustain, 2003)

Tā kā PostgreSQL 8.1 datu bāzes sistēmā nav neviena vienkārša lielo objektu datu tipa, tad

lielo objektu manipulēšanai šī datu bāzes sistēma spēj izmantot dažādas datu bibliotēkas. Bieži vien

lietotā bibliotēka, kuru izmanto PostgreSQL darbībām ar lieliem objektiem ir C valodā veidotā

libpq, tāpēc turpmāk šajā darbā tiks sīkāk apskatītas šīs bibliotēkas iespējas.

19

MySQL 5.1 lielo objektu risinājumi

Atšķirība starp šiem datu tipiem ir tā, ka tie spēj glabāt vērtības ar dažādiem

maksimālajiem garumiem.

Datu tipsMaksimālais teorētiskais

izmērs

TINYBLOB 255 baiti

BLOB 65 535 baiti

MEDIUMBLOB 16 777 215 baiti

LONGBLOB 4 294 967 295 baiti

Apstrādājot katru lielo objektu, atmiņā tiek izveidotas tā trīs kopijas, kuras tiek

glabātas dažādos buferos. Šī ir MySQL datu bāzes sistēmas īpatnība, attiecīgi, ja tiek

glabāti lieli LOB apjomi, ir nepieciešams liels apjoms atmiņas.

MySQL datu bāzes sistēmā, lielie objekti parasti tiek glabāti atsevišķi no pārējiem

tabulas datiem, līdzīgi aplūkotajām Oracle, DB2 un arī PostgreSQL datu bāzes

sistēmām.

20

Lielo objektu dati tiek indeksēti ar B-koka indeksu palīdzību, bet ģeogrāfiskie dati jeb

ĢIS dati tiek indeksēti ari R-koka palīdzību.

Līdz šim MySQL izstrādātāji nav ieviesuši glabāšanas mehānismu, kas ļautu lielos

objektus dalīt daļās, kā arī no aplūkotajām datu bāzu sistēmām, MySQL datu bāzes

sistēmā lielo objektu glabāšana nav tā attīstīta, kā tas ir piemēram Oracle datu bāzes

sistēmā.

21

Manipulēšana ar lielajiem objektiemManipulēšana ar lielajiem objektiem Oracle 10g datu bāzes sistēmāLOB kolonnas vērtības var būt:

1) NULL – tabulas šūna ir izveidota, tomēr tā nesatur nedz lokatoru nedz arī vērtību;

2) tukšs – šūna, kura satur LOB instanci ar lokatoru, bet nesatur vērtību. LOB apjoms ir

nulle.

3) piepildīta – šūna satur LOB instanci ar lokatoru un vērtību. Tabulas rindu, kurā atrodas

LOB var uz noteiktu transakcijas laiku slēgt, lai liegtu citiem datu bāzes lietotājiem

piekļuvi konkrētajam lielajam objektam. Kamēr rinda ir slēgta, pārējie lietotāji nevar slēgt

vai mainīt LOB vērtību.

Kad izveidota lielo objektu kolonna, nestrukturizēto datu importēšanai var izmantot Oracle

piedāvātos rīkus:

1) SQL*Loader;

2) Oracle DataPump.

Oracle LOB API iekļauj arī operācijas, kas ļauj atvērt un aizvērt lielo objektu instances. Atvēršanas

un aizvēršanas operācijas var veikt ar jebkuru no Oracle piedāvātajiem datu tipiem.

LOB atvēršanu var veikt, lai:

1) atvērtu LOB tikai lasīšanas režīmā. Šis režīms garantē, ka LOB vērtība un lokators netiks

mainīti līdz LOB aizvēršanas laikam. Parasti šo režīmu pielieto LOB apskates veikšanai.

2) atvērt LOB lasīšanas un rakstīšanas režīmā. Šo režīmu var pielietot lielajiem objektiem,

kuri ir BLOB, CLOB vai NCLOB datu tipa (iekšējiem lielajiem objektiem). Atverot LOB ar to var

veikt dažādas operācijas, tomēr pēc operāciju veikšanas LOB ir jāaizver.

Lai darbotos ar lielajiem objektiem kādā no programmēšanas vidēm, piemēram, PL/SQL, LOB

vērtībai ir jābūt ne-nullei, attiecīgi LOB ir jābūt savam lokatoram. Par šādām operācijām Oracle

vidē atbild funkcijas EMPTY_BLOB() un EMPTY_CLOB().

Funkcijas EMPTY_BLOB() un EMPTY_CLOB() palīdz izveidot tukšus lielos objektus ar derīgiem

lokatoriem.

Viena no populārākajām PL/SQL vidē ir DBMS_LOB programmu pakete.

Šī programmu pakete ietver vairākas procedūras un funkcijas, kuras ļauj veikt pat diezgan

sarežģītas operācijas ar lielajiem objektiem, piemēram:

1) noteiktas bitu virknes atrašanu lielajā objektā;

2) veikt LOB atvēršanu un aizvēršanu dažādos režīmos;

22

3) veikt LOB satura mainīšanu.

Jāpiebilst, ka NULL vērtības lielajam objektam nevar pielietot DBMS_LOB funkcijas un

procedūras.

Lai uzsāktu darbu ar DBMS_LOB programmu paketi no sākuma ir jāiegūst konkrētā lielā objekta

lokators un jāveic apstrādājamā lielā objekta slēgšana, jo DBMS_LOB pēc noklusējuma neveic šo

operāciju.

23

DBMS_LOB programmu paketes funkcijas un procedūras

Funkcija/Procedūra Pielietojums

APPEND Pievieno avota LOB saturu saņēmēja lielajam objektam.

CLOSE Aizver iepriekš atvērtos iekšējos vai ārējos LOB.

COMPARE Salīdzina divus LOB vai divas LOB daļas.

COPY Nokopē visus vai daļu no avota LOB uz saņēmēja LOB.

CREATETEMPORARY Izveido pagaidu BLOB vai CLOB ar pagaidu indeksu.

ERASE Izdzēš visas LOB daļas.

FILECLOSE Aizver failu.

FILECLOSEALL Aizver visus atvērtos failus.

FILEEXISTS Funkcija pārbauda vai uz servera eksistē norādītais fails.

FILEGETNAME Iegūst direktorijas un faila nosaukumus.

FILEISOPEN Funkcija pārbauda vai fails tika atvērts izmantojot BFILE lokatoru.

FILEOPEN Atver failu.

FREETEMPORARY Atbrīvo (dzēš) pagaidu BLOB vai CLOB no lietotāja pagaidu tabulu telpas.

GETCHUNKSIZE Funkcija atgriež vietas apjomu, kuru lieto LOB gabals (chunk), kurš glabā lielā objekta vērtību.

GETLENGTH Funkcija iegūst LOB vērtības garumu.

INSTR Funkcija atgriež saderīgo nth notikuma pozīciju no LOB parauga. (meklēšana)

ISOPEN Funkcija pārbauda vai LOB ir atvērts pēc konkrētā LOB lokatora.

ISTEMPORARY Funkcija pārbauda vai lokators norāda uz pagaidu LOB.

LOADFROMFILE Ievieto BFILE datus uz iekšējo LOB.

OPEN Atver LOB (iekšējo, ārējo vai pagaidu) norādītajā režīmā.

READ Nolasa datus no LOB sākot ar noteikto nobīdes pozīciju.

SUBSTR Funkcija atgriež daļu no LOB vērtības sākot ar noteikto nobīdes pozīciju.

TRIM Apgriež LOB vērtību mazāku pēc noteiktiem parametriem.

WRITE Ieraksta datus LOB no noteikta avota un noteiktas nobīdes pozīcijas

WRITEAPPEND Pievienot no bufera ņemtas vērtības LOB beigām.

COMPARE - šī funkcija salīdzina divus lielos objektus kopumā vai objektu

atsevišķas daļas. Salīdzinājumu var veikt tikai viena tipa lielajiem objektiem.

24

Funkcija atgriež nulli, ja objekti ir vienādi, pretējā gadījumā tiek atgriezta cita

vērtība.

DBMS_LOB.COMPARE ( lob_loc1 IN {BLOB | BFILE | CLOB CHARACTER SET ANY_CS}, lob_loc2 IN {BLOB | BFILE | CLOB CHARACTER SET ANY_CS}, amount IN INTEGER := 4294967295, offset IN INTEGER := 1, offset 2 IN INTEGER := 1) RETURN INTEGER;

SUBSTR - funkcija atgriež noteiktu simbolu virkni no LOB datu kopuma.

DBMS_LOB.SUBSTR ( lob_loc IN {BLOB | BFILE | CLOB CHARACTER SET ANY_CS}, amount IN INTEGER: = 32767, offset IN INTEGER: = 1) RETURN {RAW | VARCHAR2 CHARACTER SET lob_lob%CHARSET}

TRIM – šī procedūra izgriež noteiktu daļu no LOB datiem. Ja mēģina izgriezt

vērtību no tukša LOB, tad procedūra neizpildās. Ja izgriežamā vērtība tiek norādīta

lielāka nekā ir pats lielais objekts, tad procedūra atgriež paziņojumu par kļūdu.

DBMS_LOB.TRIM ( lob_loc IN OUT NOCOPY {BLOB | CLOB CHARACTER SET ANY_CS}, new_length IN INTEGER);

GETLENGTH - šī funkcija atgriež norādītā LOB garumu. Tukša LOB garums ir

nulle.

DBMS_LOB.GETLENGTH ( Lob_loc IN {BLOB | BFILE | CLOB CHARACTER SET ANY_CS}) RETURN INTEGER;

25

COPY - šī procedūra ļauj nokopēt visu vai tikai daļu no viena iekšējā lielā objekta uz

citu iekšējo lielo objektu. Ja saņēmēja lielajam objektam dati tiek pievienoti aiz tā

datu pēdējā bita (atstājot atstarpi), tad šī atstarpe tiek aizvietota ar nulles bitiem (A),

bet ja dati tiek pievienoti pirms pēdējā bita, tad saņēmēja lielā objekta noteiktie biti

tiek pārrakstīti ar jauno informāciju. (B)

A.) B.)

DBMS_LOB.COPY ( dest_lob IN OUT NOCOPY {BLOB | CLOB CHARACTER SET ANY_CS}, src_lob IN {BLOB | CLOB CHARACTER SET dest_lob%CHARSET}, amount IN INTEGER, dest_offset IN INTEGER: = 1, src_offset IN INTEGER:= 1);

LOADFROMFILE - šī funkcija tiek lietota, lai manipulētu ar ārējiem lielajiem

objektiem, jeb BFILE datu tipa objektiem. Procedūra nokopē visas BFILE objekta

avota daļas uz kādu no saņēmēja BFILE objektu. Šī procedūra darbojas līdzīgi COPY

procedūrai, galvenā atšķirība ir tā, ka šī procedūra darbojas ar ārējiem lielajiem

objektiem.

DBMS_LOB.LOADFROMFILE ( Dest_lob IN OUT NOCOPY {BLOB | CLOB CHARACTER SET ANY_CS}, Src_lob IN BFILE, Amount IN INTEGER, Dest_offset IN INTEGER: = 1, Src_offset IN INTEGER: = 1)

26

OPEN - šī procedūra atver iekšējo vai ārējo lielo objektu vienā (tikai lasīšanai) vai

divos (lasīšanai un rediģēšanai) režīmos. BFILE objektus var atvērt tikai lasīšanas

režīmā.

DBMS_LOB.OPEN ( lob_loc IN OUT NOCOPY {BLOB | BFILE | CLOB CHARACTER SET ANY_CS}, open_mode IN BINARY_INTEGER);

FILECLOSE, FILECLOSESHELL - Abas šīs procedūras tiek lietotas, lai aizvērtu

atvērtos BFILE tipa objektus. Pirmā procedūra iegūst BFILE lokatoru un aizver to

BFILE objektu, kurš ir asociēts ar šo lokatoru. Otrā funkcija aizver visus dotajā brīdī

atvētos BFILE objektus.

DBMS_LOB.FILECLOSE(file_loc IN OUT NOCOPY BFILE);

DBMS_LOB.FILECLOSEALL

READ - šī procedūra nolasa norādīto LOB daļu un ievieto to norādītajā buferī, kuru

norāda ar parametru buffer.

DBMS_LOB.READ ( lob_loc IN {BLOB | BFILE | CLOB CHARACTER SET ANY_CS}, amount IN OUT NOCOPY BINARY_INTEGER, offset IN INTEGER, buffer OUT {RAW | VARCHAR2 CHARACTER SET lob_lob%CHARSET};

APPEND - šī procedūra pievieno saturu no avota LOB uz saņēmēja LOB.

Pievienošanas procedūra darbojas tikai ar viena tipa datiem, attiecīgi, piemēram,

CLOB datu tipa datus var pievienot tikai CLOB datu tipa datiem.

DBMS_LOB.APPEND ( Dest_lob IN OUT NOCOPY {BLOB | CLOB CHARACTER SET ANY_CS}, Src_lob IN {BLOB | CLOB CHARACTER SET dest_lob%CHARSET});

27

WRITE - šī procedūra tiek lietota, lai ierakstītu noteiktu datu daudzumu no bufera uz

noteiktu iekšējo lielo objektu. Rakstīšanas sākumpunktu nosaka nobīdes (offset)

pozīcija. Ja LOB jau satur datus, tad tie tiek pārrakstīti ar jaunajiem datiem.

DBMS_LOB.WRITE ( Lob_loc IN OUT NOCOPY {BLOB | CLOB CHARACTER SET ANY_CS}, Amount IN BINARY_INTEGER, Offset IN INTEGER, Buffer IN {RAW | VARCHAR2 CHARACTER SET ANY_CS});

28

Lielo objektu lietošanas ierobežojumi

Oracle10g datu bāzēs sistēmā pastāv arī vairāki ierobežojumi, kuri jāievēro

darbojoties ar lielajiem objektiem:

1) LOB kolonnu nevar nodefinēt kā primārās atslēgas kolonnu;

2) klasteri nevar saturēt lielos objektus;

3) grupēšanas GROUP BY un kārtošanas ORDER BY izteikumu pielietošana LOB

kolonnām netiek pieļauta;

4) LOB kolonnas pielietošanas vaicājumos SELECT... DISTINCT vai SELECT

UNIQUE netiek atbalstīta;

5) vaicājumos ANALYZE... COMPUTE vai ANALYZE... ESTIMATE, LOB

kolonnu pielietošana netiek atļauta;

6) UPDATE DML trigera izveidošanas gadījumā, tā UPDATE OF izteikumā nevar

norādīt LOB kolonnu;

7) indeksa atslēgā nevar iekļaut LOB kolonnu, tomēr šo kolonnu var nodefinēt

funkcijas vai funkcijas veida indeksā;

8) INSERT... AS SELECT operācijas gadījumā, maksimālais piesaistāmo datu

apjoms LOB kolonnai ir 4000 baiti;

9) NCLOB datu tipa objekti nevar būt kā objekta atribūti.

29

Manipulēšana ar lielajiem objektiem IBM DB2 8.2 datu

bāzes sistēmāLOB datu meklēšana, kā jau iepriekš minēts sadaļā „Lielo objektu glabāšana IBM DB2 8.2

datu bāzes sistēmā” notiek ar ROWID kolonnas palīdzību. Tomēr pirms uzsākt meklēšanu un lielo

objektu izgūšanu jāaplūko objektu ievade datu bāzē.

Kad izveidota lielo objektu kolonna, nestrukturizēto datu ievade var norisināties divos veidos:

1.) Ar lietojumu LOAD – šis lietojums DB2 datu bāzes sistēmā paredzēts datu ievadei, kuru

izmērs nepārsniedz 32 kilobaiti.

2.) Ar izteikumu INSERT, IMPORT vai UPDATE.

Vairums gadījumos piekļuvi ar SQL lielo objektu kolonnām var veidot tāpat kā vienkāršo datu

kolonnām, tomēr ja Oracle 10g sistēmā ir izveidota speciāla programmpakete manipulēšanai ar

lielajiem objektiem DBMS_LOB, tad DB2 8.2 datu bāzes sistēmā šādas programmpaketes nav.

(Miller, 2005)

Šajā datu bāzes sistēmā vairums manipulēšanas norisinās lietojot LOB lokatorus, bet ir

jāatceras, ka LOB lokators ir tikai rādītājs uz lielo objektu un tas nesatur objektu informāciju. (sk.

2.15. att.)

2.15. att. LOB lokatoru lietošana DB2 datu bāzes sistēmā.

LOB lokators tiek asociēts ar LOB datu vērtību, nevis ar rindu DB2 tabulā vai patieso objekta

fiziskās glabāšanas vietu DB2 tabulu telpā. Pielietojot SELECT izteikumu LOB vērtībai izmantojot

30

LOB lokatoru, lokatora vērtība nemainās, lai gan patiesā LOB vērtība var mainīties. LOB lokatora

vērtība ir derīga tikai transakcijas laikā, tāpat ir jāsaprot, ka šī vērtība netiek glabāta datu bāzē, jo tā

tiek atkal izveidota jauna citas transakcijas uzsākšanas gadījumā.

DB2 piedāvā divus izteikumus lai darbotos ar LOB lokatoriem:

1.) FREE LOCATOR - dzēš asociāciju starp LOB lokatoru un tā LOB vērtību pirms noteiktas

darbības beigšanas.

2.) HOLD LOCATOR - saglabā asociāciju starp LOB lokatoru un tā LOB vērtību pēc

noteiktas darbības beigšanas. Šajā gadījumā LOB lokators saglabās asociāciju līdz brīdim, kad tiks

pielietots FREE LOCATOR izteikums vai līdz brīdim, kad programma pabeigs savu darbību.

LOB lokatorus var izmantot vaicājumos jeb arī izmantot tos kā mainīgos programmām. LOB

lokatori atbrīvo programmas no patieso apjomīgo objektu izmantošanas un tie tiek izmantoti

gadījumos, ja ir nepieciešams izgūt informāciju, kuru satur pats LOB.

Aplūkojot manipulēšanas iespējas ar pašiem lielajiem objektiem var izdalīt dažas

pamatfunkcijas:

SUBSTR (string, start, length)SUBSTR(:VARDS, :UZVARDA_POZ,5)

SUBSTR ir funkcija, kura ļauj atgriezt daļu no lielā objekta, kā parametri funkcijai tiek

norādīti meklējamā apgabala veids – binārs vai simbolu, bita pozīcija, ar kuru uzsāk apgabala

nolasīšanu un nolasāmā apgabala garums.

CONCAT (izteiksme_1, izteiksme_2)

CONCAT sinonīms ir „||”. Šī funkcija atgriež divu lielā objekta apgabalu apvienojumu ar

nosacījumu, ja apvienojamie objekti ir vienāda datu tipa.

LENGTH (izteiksme)LENGTH(:ADRESE)

LENGTH funkcija atgriež objekta vērtības garumu.

POSSTR (avota_virkne, meklējamā_virkne)

POSSTR funkcija atgriež to objekta sākuma pozīcijas vietu, kurā atrodas pirmā atrastā

vērtība, kura nodefinēta parametrā meklējamā_virkne. Parametrs avota_virkne nosaka vietu,

kurā notiek meklēšana (kolonnu vai šajā gadījumā objektu). Funkcijai ir vairāki ierobežojumi, viens

no primārajiem ir tas, ka meklējamās virknes garums nevar pārsniegt 4000 baitus. Tāpat arī

meklējamā virkne nevar būt lielais objekts (CLOB, DBLOB un BLOB).

31

IFNULL (izteiksme, vērtība)

SELECT darbinieka_nr, IFNULL(darbavieta, ‘nav’)

FROM darbinieki;

Funkcija atgriež uzdoto vērtību, ja izteiksme ir nulle. Ja izteiksme nav nulle, tad tiek atgriezta

pati izteiksme. Piemērā vaicājuma izpildes gadījumā tiek apskatīti visi kolonnas „darbavieta”

ieraksti un ja kādā no ierakstiem ir vērtībā nulle, tiek atgriezta vērtība „nav”

COALESCE (izteiksme, vērtība)

SELECT Darbinieka_Nr, COALESCE(Alga, 0)

FROM Darbinieki;

COALESCE funkcija atgriež pirmo argumentu, kura vērtība nav nulle. Šī funkcija ir sinonīms

funkcijai VALUE. Piemēra izpildes gadījumā atgriežot darbinieka numuru (Darbinieka_Nr) un

viņa algu (Alga), ja alga nebūs minēta (NULL), tad tiek atgriezta vērtība nulle.

Šīs ir pamata standarta DB2 funkcijas, kuras var izmantot darbībā ar lielajiem objektiem,

vairums citu operāciju veikšanas gadījumos ir nepieciešams veidot UDF jeb lietotāja definētās

funkcijas, kā arī izmantot gatavas vai paša rakstītas programmas un paplašinājumus. (Miller, 2005)

32

Manipulēšana ar lielajiem objektiem PostgreSQL 8.1

datu bāzes sistēmāManipulēšana ar lielajiem objektiem PostgreSQL 8.1 datu bāzes sistēmā norisinās lietojot

OID jeb objekta identifikatoru. OID ir 32 bitu garš pozitīvs vesels skaitlis. Pēc noklusējuma

kolonna, kura satur OID ir slēpta, tomēr tās saturu var apskatīt pielietojot attiecīgu SELECT

vaicājumu.

PostgreSQL darbībām ar lielajiem objektiem piedāvā izmantot vairākas bibliotēkas, viena no

pazīstamākajām un šajā darbā apskatītajām ir libpq, kurā apvienotas vairākas klienta puses

pamatfunkcijas darbam ar lielajiem objektiem:

1.) Lielo objektu izveide.

OID lo_creat(Pgconn *conn, int mode);

Funkcija izveido jaunu lielo objektu. Tā atgriež objekta identifikatoru, kurš tiek piesaistīts

konkrētajam jaunizveidotajam lielajam objektam. Ja funkcija nespēj izveidot lielo objektu, tad tā

atgriež vērtību InvalidOID (nulli).

Mode arguments vairs netiek izmantots un PostgreSQL 8.1 versijā šis arguments tiek ignorēts.

Tomēr, lai saskaņotu darbību ar iepriekšējām PostgreSQL versijām ir ieteicams uzstādīt šo

parametru ar vērtībām INV_READ, INV_WRITE vai INV_READ | INV_WRITE.

OID lo_create(Pgconn *conn, OID lobjId);

Šī funkcija arī veido jaunu lielo objektu. Bet OID, kuru vēlas piesaistīt šim objektam var

piešķirt ar parametra lobjId palīdzību. Kļūdas paziņojums šajā gadījumā tiek izvadīts, ja šis lielā

objekta identifikators jau tiek izmantots kādam citam lielajam objektam.

Ja lobjId arguments ir InvalidOID (nulle), tad funkcija lo_create uzvedas tāpat kā

funkcija lo_creat, attiecīgi piešķirot lielajam objektam neizmantotu objekta identifikatoru un

atgriež tā vērtību, bet ja lielā objekta izveide nav izdevusies, tā atgriež InvalidOID (nulli).

Lo_create ir jaunieviesta funkcija, kuru var lietot sākot ar PostgreSQL 8.1 versiju, tādēļ, ja to

pielieto vecākai versijai, tad tā atgriezīs vērtību InvalidOID.

2.) Lielo objektu importēšana.

OID lo_import(PGconn *conn, const char *filename);

33

Šī funkcija tiek lietota, lai importētu operētājsistēmas failus lielajos objektos. Arguments

filename norāda uz importējamo operētājsistēmā atrodošā faila vārdu.

Funkcija atgriež vērtību OID, kura tiek piesaistīta jaunizveidotajam lielajam objektam,

InvalidOid (nulle) tiek atgriezts, ja importēšana nav noritējusi sekmīgi.

Fails tiek lasīts ar klienta saskarnes bibliotēkas palīdzību, nevis ar servera palīdzību, attiecīgi

failam ir jāatrodas klienta failu sistēmā un klienta lietojumiem jāspēj lasīt šis fails.

3.) Lielo objektu eksportēšana.

int lo_export(PGconn *conn, Oid lobjId, const char *filename);

Šo funkciju lieto, lai lielo objektu eksportētu uz operētājsistēmas failu. Arguments lobjId

norāda objekta identifikatoru tam objektam, kuru vēlas eksportēt un arguments filename norāda tā

faila vārdu operētājsistēmā uz kuru tiks eksportēts lielais objekts. Fails tiek izveidots ar klienta

saskarnes palīdzību, nevis ar serveri.

Funkcija atgriež vērtību 1, ja eksportēšana ir noritējusi veiksmīgi, bet ja eksportēšana nav

noritējusi veiksmīgi, funkcija atgriež vērtību –1.

4.) Esoša lielā objekta atvēršana.

int lo_open(PGconn *conn, Oid lobjId, int mode);

Šo funkciju lieto, lai atvērtu jau esošu lielo objektu rediģēšanai vai lasīšanai. Arguments

lobjId norāda objekta identifikatoru tam lielajam objektam, kuru vēlamies atvērt. Argumenta mode

biti kontrolē vai objekts tiks atvērts tikai lasīšanai (INV_READ), rakstīšanai (INV_WRITE), vai arī

abām operācijām.

Lielo objektu nevar atvērt, pirms tas ir izveidots. Funkcija lo_open atgriež nenegatīvu lielā

objekta deskriptoru vēlākai lietošanai funkcijām lo_read, lo_write, lo_seek, lo_tell un

lo_close. Deskriptors ir derīgs tikai esošajai transakcijai. Ja atvēršana nav izdevusies funkcija

atgriež vērtību –1.

PostgreSQL serveris pagaidām nevar atšķirt iestatījumu INV_WRITE no INV_READ |

INV_WRITE. Vienalga kurš iestatījums no iepriekšminētajiem ir uzstādīts, lietotājs var lasīt

deskriptoru abos gadījumos.

Tomēr starp šiem iestatījumiem ir diezgan būtiskas atšķirības. Ja pielieto INV_READ, tad

rediģēšanas jeb rakstīšanas iespēja deskriptoram ir slēgta un dati, kuri nolasīti no deskriptora,

attēlos to lielā objekta informāciju, kura bija tā saturā, momentā, kad tika izpildīta funkcija

34

lo_open, neskatoties uz tām objekta izmaiņām, kuras veiktas pēc lo_open funkcijas aktivizācijas

momenta.

Lasot no deskriptora, kurš atvērts ar INV_WRITE, tiek attēlota lielā objekta informācija ar

visām citu transakciju veiktajām izmaiņām pat pēc lo_open funkcijas lietošanas.

5.) Datu ierakstīšana lielajā objektā.

int lo_write(PGconn *conn, int fd, const char *buf, size_t len);

Šī funkcija raksta len baitus no buf līdz lielā objekta deskriptoram fd. Argumentam fd jābūt

atgrieztam no iepriekš izpildītās lo_open funkcijas. Funkcija atgriež baitu skaitu, kuri tiek ierakstīti

lielajā objektā pēc funkcijas izpildes. Kļūdas gadījumā, vērtība, kuru atgriež funkcija ir negatīva.

Ierakstot vērtības lielajos objektos var izveidoties sava veida tukšumi, piemēram, ierakstot

tukšā lielā objektā vērtību sākot no simtā baita, pirmie 100 baiti tiks aizvietoti ar nullēm, tādejādi tie

nesaturēs nekādus datus.

6.) Lielā objekta datu nolasīšana.

int lo_read(PGconn *conn, int fd, char *buf, size_t len);

Funkcija nolasa len baitus no lielā objekta deskriptora fd, un ielasa tos buf. Argumentam fd

jābūt atgrieztam no iepriekš izpildītās lo_open funkcijas. Funkcija atgriež baitu skaitu, kuri tika

nolasīti. Kļūdas gadījumā, vērtība, kuru atgriež funkcija ir negatīva.

7.) Meklēšana lielajā objektā.

int lo_lseek(PGconn *conn, int fd, int offset, int whence);

Šo funkciju lieto, lai izmainītu esošo lasīšanas un rakstīšanas vietu, kas asociēta ar lielā

objekta deskriptoru.

Funkcija pārvieto esošās vietas lielā objekta deskriptora rādītāju fd uz jaunu vietu, kuru

norāda arguments offset. Argumenta whence vērtības var būt: SEEK_SET (meklēt no objekta

sākuma), SEEK_CUR (meklēt no esošās pozīcijas) un SEEK_END (meklēt sākot no objekta beigām).

Funkcijas atgrieztā vērtība ir rādītājs uz jauno objekta vietu, kļūdas gadījumā tiek atgriezta vērtība –

1.

8.) Lielā objekta meklēšanas pozīcijas saņemšana.

int lo_tell(PGconn *conn, int fd);

35

Funkciju lieto, lai iegūtu esošo lasīšanas un rakstīšanas lielā objekta deskriptora punkta

atrašanās vietu. Ja funkcijas izpildes rezultātā radusies kļūda, tiek atgriezta negatīva vērtība.

9.) Lielā objekta deskriptora aizvēršana.

int lo_close(PGconn *conn, int fd);

Funkciju lieto, lielā objekta deskriptoru aizvēršanai. Arguments fd ir lielā objekta deskriptors,

kurš iegūts pēc funkcijas lo_open izpildes.

Funkcijas sekmīgas izpildes gadījumā lo_close atgriež vērtību nulle. Kļūdas gadījumā tiek

atgriezta negatīva vērtība. Jebkuri lielo objektu deskriptori, kuri palikuši atvērti pēc transakcijas

pabeigšanas, tiek automātiski aizvērti.

10.) Lielo objektu dzēšana.

int lo_unlink(PGconn *conn, Oid lobjId);

Šo funkciju lieto, lai dzēstu lielos objektus no datu bāzes. Arguments lobjId norāda uz tā

lielā objekta OID, kuru vēlamies dzēst. Funkcija atgriež vērtību 1, ja dzēšana notikusi veiksmīgi,

kļūdas gadījumā tiek atgriezta vērtība –1.

PostgreSQL datu bāzes sistēmā ir arī vairākas servera puses funkcijas, kuras var izsaukt no

SQL. Būtībā katrai klienta puses funkcijai, kuras aplūkotas iepriekš atbilst noteiktas servera puses

funkcijas. Varētu teikt, ka klienta puses funkcijas ir speciāla saskarne noteiktām servera funkcijām.

Lietojot SQL ir iespēja izsaukt arī tādas servera puses funkcijas, kā: lo_creat, lo_create,

lo_unlink, lo_import un lo_export.

Servera puses funkcijas lo_import un lo_export uzvedas savādāk nekā to analogi klienta

pusē. Šīs funkcijas lasa un raksta failus servera failu sistēmā izmantojot datu bāzes īpašnieka

lietotāja tiesības. Tādēļ to izmantošana ir ierobežota superlietotājiem (superusers).

Salīdzinājumam, klienta puses importēšanas un eksportēšanas funkcijas lasa un raksta failus

klienta failu sistēmā izmantojot klienta tiesības. Klienta puses funkcijas var izmantot jebkurš

PostgreSQL lietotājs.

2.6.4. Manipulēšana ar lielajiem objektiem - kopsavilkums

Šajās sadaļās tika aplūkotas minēto datu bāzu sistēmu pamatiespējas darbībās ar lielajiem

objektiem. Protams, tiek piedāvāti vēl speciāli lietojumi, paplašinājumi un iespējas lietotājam pašam

veidot programmas, funkcijas un procedūras. Bet pavērtējot šīs datu bāzu sistēmas un to pamata

funkcionālās iespējas darbībām ar lielajiem objektiem, tad Oracle 10g datu bāzu sistēma izceļas ar

36

sakārtotu un speciāli izveidotu programmu paketi DBMS_LOB, kura dod iespēju veikt vairākas

pamatoperācijas ar lielajiem objektiem un to saturu PL/SQL vidē.

IBM DB2 8.2 datu bāzes sistēmā ir neliels klāsts pamatfunkciju darbībām ar lielajiem

objektiem, bet sarežģītāku operāciju veikšanai tiek piedāvāts lietotājiem pašiem definēt savas

funkcijas, veidot programmas, kā arī izmantot gatavus lietojumus un paplašinājumus.

PostgreSQL 8.1 datu bāzes sistēmā ir neliels skaits lielo objektu pamatfunkciju, kas ļauj veikt

tikai dažas operācijas ar lielajiem objektiem SQL vidē, tomēr praktiski nepastāv nevienas SQL

komandas, ar kuru palīdzību varētu manipulēt ar lielajiem objektiem. (Calsavara, 2002) Tiek

piedāvāts lietot funkcijas no dažādām bibliotēkām, attiecīgi lietotājiem sekmīgai šo bibliotēku

iespēju izmantošanai ir jāveido pašam savas programmas kādā no programmēšanas vidēm.

Tāpat aplūkotajām datu bāzu sistēmām kopīga lieta ir tā, ka manipulēšana norit ar objekta

identifikatoriem, kas nozīmē, ja kaut kādā veidā objekta identifikators tiek bojāts vai dzēsts, tad pats

lielais objekts netiek dzēsts un tā meklēšana datu bāzē var izrādīties laikietilpīgs process.

Jāsaprot, ka no lielajiem objektiem izgūto datu pilnvērtīgai attēlošanai ir nepieciešams

atsevišķs lietojums, jo piemēram, PSQL ir tikai teksta veida rīks, kurš nespēj attēlot, piemēram,

attēlus. Kā piemēru var minēt PostgreSQL literatūrā lielo objektu attēlu vizuālās apskates minētu

rīku Conjectrix Workstation. (Douglas, 2005)

2.7. Lielo objektu implementēšanas vadlīnijas

Lielo objektu implementēšanas vadlīnijas ir diezgan plašs temats, tomēr virspusēji

ielūkojoties šajā jautājumā, var izvirzīt vairākas lietas, kuras ir jāņem vērā darbojoties ar lielajiem

objektiem.

2.7.1. Lielo objektu implementēšanas vadlīnijas Oracle datu bāzes sistēmā

1.) Vispirms ir jāapzinās, ka Oracle datu bāzes sistēmā kopējais LOB apjoms var būt

maksimums no 8-128 terabaitiem – šī maksimālā robeža ir atkarīga no datu bāzes konfigurācijas.

Tomēr LOB kolonna var būt līdz 4GB apjomā. (Jegray, 2004)

2.) Jāapzinās arī viena datu faila izmēra ierobežojumi. Katrai operētājsistēmai ir savi

ierobežojumi attiecībā uz viena datu faila izmēriem.

Piemēram, Solaris 2.5 operētājsistēma atļauj operētājsistēmas failu izmērā līdz 2GB.

Attiecīgi, vadoties no šiem ierobežojumiem ir jāapsver tas, ka tiklīdz lielā objekta izmērs tuvojas

operētājsistēmas faila izmēra maksimumam, tā ir jāizveido papildus lielie objekti

37

3.) Darbojoties ar lieliem datu apjomiem uzstādīt PCTINCREASE parametru uz nulli:

PCTINCREASE parametrs LOB glabāšanā norāda procentuālo apjomu jaunam ekstentam.

Kad lielais objekts tiek aizpildīts pa apgabaliem, šī procesa rezultātā tiek izveidoti vairums

jaunu ekstentu. Ja ekstenta izmēri turpina pieaugt, par pēc noklusējuma vērtību 50% katru reizi, tad

ekstentu vadība paliek apgrūtinoša un diezgan liels tabulu telpas apjoms tiek nelietderīgi izmantots.

Tādēļ arī PCTINCREASE parametru vajadzētu uzstādīt kā nelielu vērtību vai pat nulli.

4.) Darbojoties ar lieliem datu apjomiem uzstādīt MAXEXTENTS vērtību pēc vajadzības vai

pat UNLIMITED.

MAXEXTENTS parametrs ierobežo ekstentu skaitu, kurš tiek atļauts LOB kolonnai. Pie

lielākiem LOB izmēriem veidojas liels skaits ekstentu, tādēļ šim parametram jābūt pietiekami

lielam, lai ekstenti tiktu veidoti nepieciešamajā daudzumā.

5.) Darbojoties ar lieliem datu apjomiem nepieciešams lietot lielus ekstentu izmērus. Katram

jaunajam ekstentam Oracle ģenerē atgriešanas (undo) informāciju. Ja ekstentu ir daudz, tad atrites

(rollback) segments var būt piepildīts. Lai no šīs problēmas izvairītos ir jāizvēlas liels ekstentu

izmērs, piemēram, 100 megabaiti – tas samazinās ekstentu izveides biežumu vai arī transakcijas

biežos apstiprinājumus.

6.) Darbojoties ar lielajiem objektiem nevajadzētu rediģēt lielā objekta lokatoru, lai nenotiktu

LOB „pazaudēšana” datu bāzē.

7.) Jāapsver PCTVERSION parametra iestatījumi. Īsumā sakot PCTVERSION ir tas atmiņas

apjoms – datu bloki, ko var izmantot lielā objekta pirms izmaiņas jeb vecāko versiju glabāšanai.

PCTVERSION vērtības var būt - pēc noklusējuma 10%, maksimālā 100% un minimālā 0%. Šīs

vērtības iestatījums ir diezgan būtisks un pirms to iestatīt ir jāapsver tādi jautājumi kā: Cik bieži

LOB tiek laboti un atjaunoti? Cik bieži atjaunotie LOB tiek lasīti? Oracle izstrādātāji piedāvā

sekojošus ieteikumus: (sk. 2.1. tab.) (Paapanen, 2004)

2.1 tabula

Oracle izstrādātāju ieteicamie PCTVERSION iestatījumi

LOB atjaunojumu iestatījums LOB nolasīšanas iestatījums PCTVERSIONatjauno XX% no LOB datiem nolasa atjaunotos LOB XX%atjauno XX% no LOB datiem lasa LOB, bet nelasa atjaunotos LOB 0%

atjauno XX% no LOB datiem lasa gan atjaunotos, gan neatjaunotos LOB XX%

nekad neatjauno LOB lasa LOB 0%

38

Būtībā jo retāki un nelielāki ir LOB atjauninājumi, jo mazāka PCTVERION vērtība ir

jāiestata.

8.) Jāapsver CACHE/NOCACHE/CACHE READS parametru iestatījums. Šo parametru

izvēlei Oracle izstrādātāji piedāvā sekojošas rekomendācijas: (sk. 2.2. tab.)

2.2. tabula

CACHE/NOCACHE/CACHE READS pielietošanas ieteikumi

CACHE Režīms Lasīšana Raksta uzCACHE READS bieži vienreiz vai reti

CACHE bieži biežiNOCACHE (noklusētā vērtība) vienreiz vai reti nekad

CACHE – Oracle ievieto LOB lapas buferī, ātrākai piekļuvei

NOCACHE – Nozīmē, ka LOB vērtības netiek ievietotas buferī, vai arī tiek ievietotas buferī

LRU saraksta beigās (nozīmē, ka piekļuve tām būs lēnāka, jo vērtības tiek lasītas no saraksta

sākuma).

CACHE READS – LOB vērtības buferī tiek ienestas tikai lasīšanas operācijas laikā.

Rakstīšanas operācijas laikā tās netiek nestas uz buferi.

9.) Glabāšana tabulas rindās vai ārpus tabulu rindām. Maksimālais LOB datu apjoms, kas var

tikt glabāts rindās ir maksimālā VARCHAR2 datu tipa vērtība, tas ir (4000). Ja tiek definēta vērtība,

kas ir lielāka par 4000 un norādīts to glabāt rindās, tad Oracle automātiski to pārvietos ārpus

rindām.

10.) INITIAL un NEXT parametru iestatīšana. INITIAL un NEXT parametru vienmēr ir

jāiestata lielāku nekā CHUNK parametru. Piemēram, ja datu bāzes bloks ir 2 kilobaiti, bet CHUNK

ir 8 kilobaiti, tad INITIAL un NEXT ir jābūt lielākam par 8 kilobaitiem. (šajā gadījumā ieteicami

būt 16KB) (Jegray, 2004)

2.7.2. Lielo objektu implementēšanas vadlīnijas IBM DB2 datu bāzes sistēmā

1.) Kad lielie objekti tiek izveidoti, datu bāzes administrators var norādīt vai lielais objekts

tiks reģistrēts sistēmas žurnālā vai nē.

Objektu apjoma dēļ, reģistrācija var patērēt lielu daļu resursus un vietu reģistra glabāšanai.

Attiecīgi pie lieliem datu apjomiem (virs 1 megabaita) vajadzētu izvairīties no lielo objektu

reģistrēšanas.

39

2.) Nevajadzētu censties rediģēt ROWID. ROWID kolonnas ir jāatstāj DB2 rīcībā, datu bāzes

sistēma automātiski ģenerē šīs kolonnas, tādejādi neļaujot lietotājam iejaukties šajā procesā.

ROWID nevar izmanīt.

3.) Nodefinēt ROWID kolonnas ar nosacījumu NOT NULL. ROWID kolonnai nevar būt

NULL vērtība. Pie kolonnas definēšanas ir noteikti jānorāda NOT NULL nosacījums.

4.) IBM DB2 izstrādātāji iesaka izmantot lietotāja definētus tipus jeb UDT. Darbojoties ar

lielajiem objektiem lietotāja definētie tipi tiek izmantoti biežāk un ir labāk uztverami.

Piemēram, ja vēlas izmantot nelielus skaņas gabalus, var izveidot sekojošu lietotāja definēto

tipu:

CREATE DISTINCT TYPE SKANAS_GABALS AS BLOB(1M)

Lietotājam ir vieglāk saprast to, ka tips SKANAS_GABALS ir skaņas tips. Ja piemēram,

lietotājs redzētu tipu BLOB(1M), tad to vienkārši varētu pieņemt tikpat labi par foto, video vai citu

informāciju.

5.) Noteiktu uzdevumu atkārtotai veikšanai var izmantot dažas LOB programmas, kuras ietver

DB2. Piemēram, programma DSN8DLRV, kura uzrakstīta C valodā un domāta LOB lokatoru

izmantošanai darbībā ar CLOB datu tipa datiem.

6.) Vajadzētu izvairīties no „maziem” LOB. „Mazais” lielais objekts skaitās LOB, kurš ir

mazāks par 32KB. Līdz 32KB apjoma informācijas ievietošana lielajos objektos nenesīs nekādu

labumu. Pie tam tiek zaudēts atmiņas apjoms, jo DB2 datu bāzes sistēmā viena lapa LOB tabulu

telpā var saturēt tikai vienu datu rindu.

7.) Iestatīt precīzus lapas iestatījumus LOB glabāšanai. Liela izmēra lielajiem objektiem lapas

izmēram ir jābūt 32KB. Mazākiem lielajiem objektiem iestatīt 4KB lielu lapu.

8.) No glabāšanas viedokļa maksimālais teorētiskais LOB kopējais apjoms, ko var glabāt

vienā kolonnā ir 127 terabaiti.

2.7.3. Lielo objektu implementēšanas vadlīnijas PostgreSQL datu bāzes sistēmā

1.) Nevajadzētu rediģēt OID vērtības, jo tādejādi ar identifikatoru asociētais lielais objekts var

tikt „pazaudēts” un tā meklēšana tabulu telpās var kļūt par laikietilpīgu procesu.

2.) Pie datu importēšanas lielajos objektos ir jāapzinās vai importējamie dati atrodas klienta

pusē (uz lietotāja sistēmas) vai servera pusē (uz attālināta servera). Attiecīgi ir nepieciešams

pielietot attiecīgās importēšanas funkcijas. (sk. 2.16. att.)

40

Var izmantot tikai datu bāzes īpašnieks

Servera funkcijalo_import

Var izmantot jebkurš datu bāzes lietotājs

Lokālie faili

PostgreSQLlietotāja sistēma

Attālinātie Faili

PostgreSQLServeris

Lokalā funkcijalo_import

2.16. att. Datu importēšanas funkcijas lietošana PostgreSQL datu bāzes sistēmā.

3.) Darbojoties ar vienkāršajiem datiem, kuriem ir piesaistīts lielais objekts ir jāatceras, ka

izdzēšot rindu, kurā „atrodas” lielais objekts, patiesībā LOB netiek dzēsts, bet dzēš tā lokatoru,

tāpēc vispirms ir jāizdzēš lielais objekts un tad viņam piekārtotā rinda tabulā. Protams, lieta, kas

jāapzinās ir tā, ka neviena cita rinda nenorāda uz dzēšamo lielo objektu.

2.7.4. Lielo objektu implementēšanas vadlīnijas - kopsavilkums

Katras datu bāzes sistēmas izstrādātājs piedāvā lielāku vai mazāku vadlīniju klāstu darbībām

ar lielajiem objektiem, tomēr var izdalīt vairākas kopīgas zīmīgās lietas, kuras jāņem vērā lietojot

lielos objektus:

1.) Lielo objektu izmērs parasti ir liels, šis faktors ir vienmēr jāņem vērā, jo objektu

materializācija spēj paņemt no sistēmas milzīgu resursu klāstu.

2.) Maza apjoma informācijas glabāšana lielajos objektos nav paredzēta, tāpēc tā bieži vien

var neefektīvi izmantot sistēmas resursus.

3.) Tā kā darbība ar lielajiem objektiem notiek izmantojot rādītājus, tad nevajadzētu censties

kaut kādā veidā koriģēt rādītāju saturu.

4.) Lielo objektu implementētājiem vajadzētu apzināties objektu apjomus, tādējādi veikt

precīzus glabāšanas iestatījumus, jo īpaši tad, kad lielie objekti sāk aizņemt lielus atmiņas apjomus

(vairākus gigabaitus vai terabaitus).

2.8. Lielo objektu tehnoloģijas nākotnes attīstība un iespējas

Katram no šo datu bāzu sistēmu izstrādātājiem ir savas vīzijas un plāni attiecībā uz šīs

tehnoloģijas izmantošanu nākamajās datu bāzu sistēmu versijās.

41

Oracle datu bāzu sistēmas izstrādātāji nākamajās versijās plāno veikt sekojošas izmaiņas un

papildinājumus:

1.) Paplašināts XML iespēju atbalsts – XML atbalsts datu bāzu sistēmās ļaus sekmīgāk

darboties (veidot hierarhijas) ar tādiem nestrukturizētiem datiem, kā saliktiem dokumentiem, tai

skaitā arī .pdf dokumentiem.

2.) Funkcionālo iespēju paplašinājums – plānots ieviest daudz vairāk gatavo lietotāju definēto

funkciju – paplašinājumus.

3.) Glabāšanas iespēju uzlabojumus – vairāku ierobežojumu pārvarēšanu, lielāku apjomu datu

glabāšanas iespēju ieviešanu.

IBM DB2 izstrādātāji arī turpina attīstīt šo tehnoloģiju savā datu bāzes sistēmā un plāno veikt

sekojošas izmaiņas:

1.) Tāpat, kā Oracle, IBM DB2 izstrādātāji darbojas pie XML atbalsta ieviešanas savā sistēmā,

plānots kā 2006. gadā tiks izlaists datu bāzes sistēmas „Viper” atjauninājums, kurā iekļautas

dažādas būtiskas izmaiņas attiecībā uz XML ieviešanu.

2.) Lielo objektu pieejamības jautājumu risinājumi. Piemēram, lietojuma REORG lietošanas

iespējas LOB tabulu telpām.

3.) Lielo objektu saspiešanas iespēju ieviešana.

PostgreSQL par nākamo versiju izmaiņām attiecībā uz lielajiem objektiem nepublicē

informāciju, iespējams, ka šīs datu bāzes sistēmas izstrādātāji lielo objektu tehnoloģijas krasai

attīstībai nepievērsīs lielu uzmanību, jo vairāk tiek attīstītas citas iespējas, piemēram,

nestrukturizēto un apjomīgo datu glabāšanas mehānismi, kā TOAST.

IBM un Oracle kompānijas ir vieni no sīvākiem konkurentiem, tādēļ arī šie izstrādātāji ne

labprāt publicē detalizētu informāciju par nākamo versiju izmaiņām, bet katrā ziņā šīs abas

kompānijas ir atzinušas, ka turpina intensīvu darbu pie šīs tehnoloģijas attīstības un uzlabošanas,

tāpēc nākamajās versijās iespējams sagaidāmi dažādi lielo objektu tehnoloģijas jauni pavērsieni.

42

Piemēru realizācija IBM DB2 8.2 datu bāzes sistēmā

DB2 8.2 datu bāzes sistēmā piemēru izstrāde notika lietojot rīku Command Editor un rīku Control Center. Šie rīki ir ietverti standarta DB2 datu bāzes sistēmas rīku komplektā.1) Tabulu veidošana.Izveidota tabula ar vienkāršiem datiem, kurā ietverti darbinieka numurs, vārds un uzvārds.CREATE TABLE lielieobjekti(darbinieka_nr SMALLINT NOT NULL,vards VARCHAR(10),uzvards VARCHAR (20));Izveidotā tabula tiek papildināta ar lielā objekta kolonnu foto glabāšanai binārā formā - BLOB datu tipa, izmērs 10 megabaiti.ALTER TABLE lielieobjektiADD foto BLOB(10M);Izveidotā tabula tiek papildināta ar lielā objekta kolonnu darbinieka CV glabāšanai simbolu formā - CLOB datu tipa, izmērs 5 megabaiti.ALTER TABLE lielieobjektiADD cv CLOB(5M);Tabulas aplūkošana IBM DB2 Control Center vidē:

Kad pamata tabula izveidota, tad lielo objektu glabāšanai jāveido LOB tabulu telpas un palīgtabulas. Nākamajā izteikumā demonstrēta LOB tabulu telpu veidošana, norādot, ka tās vadīs datu bāze, lietots tiks C:\lobi\dati atrodošais konteineris 10 megabaitu apjomā nosakot noteiktu ekstentu izmēru.CREATE LARGE TABLESPACE foto_ttMANAGED BY DATABASEUSING (file 'c:\lobi\dati' 10M)EXTENTSIZE 64;

CREATE LARGE TABLESPACE cv_ttMANAGED BY DATABASEUSING (file 'c:\lobi\dati_cv' 5M)EXTENTSIZE 64;

43

Kad tabulu telpas izveidotas, jāizveido palīgtabulas norādot tabulu telpas, kurās tās tiks glabāts, kā arī norādot kuras tabulas un kolonnas lielos objektus konkrētā palīgtabula glabās.CREATE AUXILARY TABLE foto_tabulaIN foto_ttSTORES lielieobjektiCOLUMN foto;commit;

CREATE AUXILARY TABLE cv_tabulaIN cv_ttSTORES lielieobjektiCOLUMN cv;commit;

Pēc tam tiek izveidoti palīgtabulu indeksi.

CREATE UNIQUE INDEX xfoto_tabulaon foto_tabula;commit;

CREATE UNIQUE INDEX xcv_tabulaon cv_tabula;commit;2) Datu importēšana un manipulēšana.Izveidotajā tabulā tiek importēti dati, konkrēti attēls no operētājsistēmas faila. Tiek norādīta fiziskā direktorija un faila atrašanās vieta, implementēšanas specifika, elementa numurs, noteikta ziņojumu saglabāšanas vieta un pēc tam dati tiek saglabāti datu bāzes tabulas lielieobjekti kolonnā foto, kura ir BLOB datu tipa.IMPORT FROM "C:\lob_direktorija\totoro1.jpg" OF DEL METHOD P (4) MESSAGES "C:\data" INSERT INTO lielieobjekti (foto) WHERE darbinieka_nr = 12;

IMPORT FROM "C:\lob_direktorija\totoro2.jpg" OF DEL METHOD P (4) MESSAGES "C:\data" INSERT INTO lielieobjekti (foto) WHERE darbinieka_nr = 13;

Datu visvienkāršāko apskati var veikt ar vaicājumu:

SELECT foto FROM lielieobjekti;Pamaina esošo tabulu, pievienojot vēl vienu kolonnu teva_foto ar datu tipu BLOB 10 megabaitu apjomā.

44

ALTER TABLE lielieobjektiADD teva_foto BLOB(10M);Izveido piekārtotu tabulu telpu, palīgtabulu un palīgtabulas indeksu.CREATE LARGE TABLESPACE teva_foto_ttMANAGED BY DATABASEUSING (file 'c:\lobi\dati' 10M)EXTENTSIZE 64;

CREATE AUXILARY TABLE teva_foto_tabulaIN teva_foto_ttSTORES lielieobjektiCOLUMN teva_foto;commit;

CREATE UNIQUE INDEX xteva_foto_tabulaon teva_foto_tabula;commit;

Tiek importēti dati no operētājsistēmas faila, norādot fizisko atrašanās vietu. Pēc tam dati tiek ievietoti tabulā lielieobjekti, kolonnā teva_foto, kur darbinieka numurs ir 12.

IMPORT FROM "C:\lob_direktorija\totoro3.jpg" OF DEL METHOD P (6) MESSAGES "C:\data" INSERT INTO lielieobjekti (teva_foto) WHERE darbinieka_nr = 12;Pēc tam tiek izveidots vaicājums funkcijas CONCAT demonstrējumam darbībā ar binārajiem lielajiem objektiem. Tiek apvienoti divi attēli, kuri ir piesaistīti tabulas lielieobjekti rindai ar darbinieka numuru 12, attiecīgi tiek izvadīts attēlu apvienojums, kurā redzams darbinieka foto apvienojums ar darbinieka tēva foto.SELECT darbinieka_nr, CONCAT (lielieobjekti.foto, lielieobjekti.teva_foto) AS APVIENOJUMSFROM lielieobjektiWHERE darbinieka_nr = 12;Izvade rīka Command Editor teksta vidē. Kreisajā pusē tiek izvadīts darbinieka numurs, bet labajā pusē daļa no apvienojuma teksta formā. (patiesais apvienojuma teksta garums ir daudz apjomīgāks)DARBINIEKA_NR APVIENOJUMS------------- ------------------------------------------------------------12 x'424D761801000000000036040000280000000201000010010000010008 00000000040140100741200007412000000000000000000000000000006050600090A1300081209000B11160012080A00140B140011130B001B14160007092600050836000B1126000A11360018092400120B36001616260018193600122816001A26350026040600260A1400251A1B00380206003408140034100B00331A1C0025

45

0B270028073400291C22002915350033053800321B2500371537002B211E002635160031221E002C22230024253B0027343900352828003A2D31003C312D003D32330003064700030557000A114A000A125600140947001607570016164700151756000F116E001D244C001C266C0031174B002D18700025294900262B56002A324B002A335700362A4A00352855003835490033375800232C660026277A002A3666002A39750036296600372A7600343B6700343D75001A463300304B3300175045000C5663001B64500000736000314B50002B4368002C447A0038446B0039487700385766040600260A1400251A1B0038020600340814324B002A335700362A4A00352001A26350026040600260A140024700160757001616470015151756000F2Grafiskā veidā funkcijas darbības rezultāts izskatās sekojoši. (sk. 3.3. att.)

Funkcijas CONCAT sekmīgas izpildes gadījumā, redzam, ka tiek apkopotas divas binārās virknes, tas ir veidojas divu attēlu kopums.

46

Piemēru realizācija PostgreSQL 8.1 datu bāzes sistēmā

PostgreSQL 8.1 datu bāzes sistēmā piemēru izstrāde notika lietojot rīku pgAdmin III Query. Šis rīks ir ietverts standarta PostgreSQL 8.1 datu bāzes sistēmas rīku komplektā.1) Tabulu veidošana.Izveidota tabula ar vienkāršo datu kolonnām – darbinieka identifikatoru, vārdu, uzvārdu un lielo objektu kolonnu foto. Tā kā šajā datu bāzes sistēmā nepastāv iebūvētie lielo objektu pamata datu tipi, tad definējot lielos objektus ir jānorāda atslēgvārds OID, kas nozīmē, ka kolonna glabās lielo objektu rādītājus.CREATE TABLE lielie_objekti(darbinieka_id int,vards CHAR(10),uzvards CHAR(10),foto oid,primary key (darbinieka_id));

2) Datu importēšana un manipulēšana.Kad tabula izveidota, tajā tiek ievietoti dati. Lielo objektu implementēšanai tiek lietota funkcija lo_import, kura ļauj importēt datus lielajā objektā no operētājsistēmas faila, konkrēti norādot faila fizisko atrašanās vietu.INSERT INTO lielie_objekti (darbinieka_id, vards, uzvards, foto, teva_foto)VALUES (12, 'gatis', 'vitols', lo_import('c:/lob_direktorija/totoro.jpg'), NULL);

INSERT INTO lielie_objekti (darbinieka_id, vards, uzvards, foto, teva_foto)VALUES (01, 'modris', 'vitols', lo_import('c:/lob_direktorija/modris.jpg'), lo_import('c:/lob_direktorija/juris.jpg'));Tā lielo objektu tabula tiek aizpildīta ar datiem, kad tas paveikts, tiek veidots vaicājums tabulas satura aplūkošanai.SELECT * FROM lielie_objekti;Rezultātā uz ekrāna tiek izvadīts tabulas saturs:

Attēlā var redzēt, ka foto un teva_foto kolonnas satur objekta identifikatorus, kuri ir saistīti ar patiesām lielo objektu vērtībām, kuras savukārt sistēma automātiski noglabā attiecīgajās struktūrās.PostgreSQL vidē no piedāvātajām lielo objektu funkcijām sekmīgi var izmantot tikai pāris, to skaitā lo_import un lo_export, pārējās funkcijas ir jāievieš programmās kādā no programmēšanas valodām.

47

Tiek veidots vaicājums lielā objekta identifikatora izgūšanai no esošās tabulas.SELECT foto FROM lielie_objekti WHERE darbinieka_id=12Rezultātā tiek izvadīta sekojoša vērtība.foto(oid)---------16694Lietojot eksportēšanas funkciju, eksportējot lielo objektu uz esošu failu tiek izvadīts paziņojums par kļūdu.SELECT lo_export( 16694, 'c:/lob_direktorija/arturs.jpg' );

ERROR: could not create server file "c:/lob_direktorija/arturs.jpg": Permission deniedBet eksportējot uz neesošu failu, tas tiek izveidots norādītajā operētājsistēmas atmiņas apgabalā - direktorijā.SELECT lo_export( 16694, 'c:/lob_direktorija/gatis_bernibas_bilde.jpg' );

Lielā objekta lokatora dzēšana.select lo_unlink (16694);

lo_unlnk(int4)--------------1Lielā objekta lokatora izveidošana.select lo_create (16666)

lo_create(oid)-------------16666Pārējo funkciju lietošanai un citās datu bāzu sistēmās SQL ekvivalentu darbību veikšanai šajā datu bāzes sistēmā ir jāveido programmas. Aplūkotās funkcijas ir vienīgās, kuras var lietot vienkāršajā SQL vidē.

48

Lielo objektu tehnoloģijas lietošana augļu koku informācijas sistēmā

Dati

Atributīvie Grafiskie

INFORMĀCIJAS SISTĒMA

Ievade (glabāšana) Vaicājumi (Manipulēšana)

Rezultātu pasniegšana (Vizualizācija)

49

Grafisko un atributīvo datu glabāšana

Datu bāze LOB tabulu telpaTabulu telpa

a.) b.)

LOBZ1 LOB1

- Šķirni izveidojis P. Upītis. Šķirne reģistrēta 1974. g. Starptautiskajā ceriņu šķirņu katalogā Kanādā. - KRŪMA augstums 1,7 - 2,5 m. Krūms vidēji spēcīgs. - ZIEDPUMPURI purpurvioleti. Ziedi purpurkrāsas pildīti ap 2,7 cm diametrā. Vainagam trīs kārtas. Pārziedot kļūst gaišāki. - ZIEDKOPAS vidēji lielas, 15 - 20 cm garas, 11 - 15 cm platas, piramidālas, ļoti blīvas. - ZIED no jūnija sākuma līdz jūnija vidum. Zied mēreni. - Piemērota audzēšanai soliteru un grupveida stādījumos. - Audzēšanai piemērotas vāji skābas vai neitrālas (pH 6 - 7) vidēji smagas mālsmilts vai smilšmāla augsnes - Vērtīga ar skaisto ziedu krāsu un blīvajām ziedkopām.

a.) b.)

50

Attēla daļas izguve lietojot LOB funkcijas

Divu attēlu apvienojums lietojot LOB funkcijas

51

Meklēšana pēc noteikta attēla daļas lietojot LOB

funkcijas

meklēt

ATRASTS!: LOB_Kirsis0503

Divu attēlu salīdzināšana lietojot LOB funkcijas

UN UN

=0 (nav vienādi) =1 (ir vienādi)

52

Attēla daļas nogriešanas operācija lietojot LOB

funkcijas

griezt

Jaunais attēla lielums

53

Kopējais LOB tehnoloģijas realizēšanas variantu salīdzinājums

KritērijsDatu bāzu sistēma

Oracle10g

IBMDB2 8.2

PostgreSQL8.1

Iebūvēti lielo objektu datu tipi darbam ar nestrukturizēto informāciju. + + -

Bināro datu glabāšanas iespējas lietojot lielos objektus. + + +

Simbolu datu glabāšanas iespējas lietojot lielos objektus. + + +

Literatūras klāsts par lielajiem objektiem. Plašs Plašs Minimāls

Lielo objektu indeksācijas iespēju atbalsts. + + +

Vai vienā tabulā var atrasties vairākas lielo objektu kolonnas? Var Var Var

Teorētiskais maksimālais lielo objektu datu bāzes izmērs. 8-128TB Nav zināms Nav zināms

SQL komandu atbalsts darbībām ar lielajiem objektiem. Plašs Vidējs Minimāls

Pamata funkciju un procedūru klāsts darbam ar lielajiem objektiem. Plašs Minimāls Minimāls

Maksimālais teorētiskais viena lielā objekta izmērs. 4GB 2GB-1B 2GB

Lielo objektu glabāšana tabulu rindās. + - -

Lielo objektu glabāšana operētājsistēmas failos. + - -

Lielo objektu glabāšana atsevišķās struktūrās (tabulu telpās, tabulās) + + +

Rādītāju semantikas lietošana darbam ar lielajiem objektiem.

LOB lokators

LOB deskriptors Objekta ID

Lielo objektu reģistrēšanas iespējas sistēmas žurnālā. + + +

Vai pastāv citas nestrukturizēto datu glabāšanas iespējas, neskaitot LOB. Pastāv Pastāv Pastāv

Speciālo (divbaitīgo) simbolu glabāšanas iespējas lietojot lielos objektus. + + -

UDF, UDT definēšanas iespējas lielajiem objektiem + + +

Lielo objektu alternatīvie glabāšanas - - TOAST

54

mehānismi.

Aplūkotās datu bāzes sistēmas lielo objektu pamatjautājumu izpratnes vienkāršība.

Samērā vienkārši Apgrūtinoši Apgrūtinoši

Datu bāzes sistēmas instalēšanas un konfigurēšanas vienkāršība Vienkārša Apgrūtinoša Vienkārša

Lielo objektu funkciju un procedūru izmantošanas vienkāršība. Vienkārši Apgrūtinoši Apgrūtinoši

Lielo objektu tehnoloģijas izstrādes aktivitāte. Aktīva Aktīva Neaktīva

55

Category Operator / Function SQL Example / Comments SQL PL/SQL

Concatenation ||, CONCAT() Select clobCol || clobCol2 from tab; Yes Yes

Comparison = , !=, >, >=, <, <=, <>, ^=

if clobCol=clobCol2 then... No Yes

Comparison IN, NOT IN if clobCol NOT IN (clob1, clob2, clob3) then...

No Yes

Comparison SOME, ANY, ALL if clobCol < SOME (select clobCol2 from...) then...

No N/A

Comparison BETWEEN if clobCol BETWEEN clobCol2 and clobCol3 then...

No Yes

Comparison LIKE [ESCAPE] if clobCol LIKE '%pattern%' then... Yes Yes

Comparison IS [NOT] NULL where clobCol IS NOT NULL Yes Yes

Character Functions

INITCAP, NLS_INITCAP

select INITCAP(clobCol) from... CNV CNV

Character Functions

LOWER, NLS_LOWER, UPPER, NLS_UPPER

...where LOWER(clobCol1) = LOWER(clobCol2)

Yes Yes

Character Functions

LPAD, RPAD select RPAD(clobCol, 20, ' La') from... Yes Yes

Character Functions

TRIM, LTRIM, RTRIM

...where RTRIM(LTRIM(clobCol,'ab'), 'xy') = 'cd'

Yes Yes

Character Functions

REPLACE select REPLACE(clobCol, 'orig','new') from...

Yes Yes

Character Functions

SOUNDEX ...where SOUNDEX(clobCOl) = SOUNDEX('SMYTHE')

CNV CNV

Character SUBSTR ...where substr(clobCol, 1,4) = 'THIS' Yes Yes

56

Category Operator / Function SQL Example / Comments SQL PL/SQL

Functions

Character Functions

TRANSLATE select TRANSLATE(clobCol, '123abc','NC') from...

CNV CNV

Character Functions

ASCII select ASCII(clobCol) from... CNV CNV

Character Functions

INSTR ...where instr(clobCol, 'book') = 11 Yes Yes

Character Functions

LENGTH ...where length(clobCol) != 7; Yes Yes

Character Functions

NLSSORT ...where NLSSORT (clobCol,'NLS_SORT = German') > NLSSORT ('S','NLS_SORT = German')

CNV CNV

Character Functions

INSTRB, SUBSTRB, LENGTHB

These functions are supported only for CLOBs that use single-byte character sets. (LENGTHB is supported for BLOBs as well as CLOBs.)

Yes Yes

Character Functions - Regular Expressions

REGEXP_LIKE This function searches a character column for a pattern. Use this function in the WHERE clause of a query to return rows matching the regular expression you specify.

Yes Yes

Character Functions - Regular Expressions

REGEXP_REPLACE This function searches for a pattern in a character column and replaces each occurrence of that pattern with the pattern you specify.

Yes Yes

Character Functions - Regular Expressions

REGEXP_INSTR This function searches a string for a given occurrence of a regular expression pattern. You specify which occurrence you want to find and the start position to search from. This function returns an integer indicating the position in the string where the match is found.

Yes Yes

Character REGEXP_SUBSTR This function returns the actual substring Yes Yes

57

Category Operator / Function SQL Example / Comments SQL PL/SQL

Functions - Regular Expressions

matching the regular expression pattern you specify.

Conversion CHARTOROWID CHARTOROWID(clobCol) CNV CNV

Conversion HEXTORAW HEXTORAW(CLOB) No CNV

Conversion CONVERT select CONVERT(clobCol,'WE8DEC','WE8HP') from...

Yes CNV

Conversion TO_DATE TO_DATE(clobCol) CNV CNV

Conversion TO_NUMBER TO_NUMBER(clobCol) CNV CNV

Conversion TO_TIMESTAMP TO_TIMESTAMP(clobCol) No CNV

ConversionTO_MULTI_BYTE

TO_SINGLE_BYTE

TO_MULTI_BYTE(clobCol)

TO_SINGLE_BYTE(clobCol)CNV CNV

Conversion TO_CHAR TO_CHAR(clobCol) Yes Yes

Conversion TO_NCHAR TO_NCHAR(clobCol) Yes Yes

Conversion TO_LOBINSERT INTO... SELECT TO_LOB(longCol)...

Note that TO_LOB can only be used to create or insert into a table with LOB columns as SELECT FROM a table with a LONG column.

N/A N/A

Conversion TO_CLOB TO_CLOB(varchar2Col) Yes Yes

Conversion TO_NCLOB TO_NCLOB(varchar2Clob) Yes Yes

Aggregate Functions

COUNT select count(clobCol) from... No N/A

Aggregate MAX, MIN select MAX(clobCol) from... No N/A

58

Category Operator / Function SQL Example / Comments SQL PL/SQL

Functions

Aggregate Functions

GROUPING select grouping(clobCol) from... group by cube (clobCol);

No N/A

Other Functions

GREATEST, LEAST select GREATEST (clobCol1, clobCol2) from...

No CNV

Other Functions

DECODE select DECODE(clobCol, condition1, value1, defaultValue) from...

CNV CNV

Other Functions

NVL select NVL(clobCol,'NULL') from... Yes Yes

Other Functions

DUMP select DUMP(clobCol) from... No N/A

Other Functions

VSIZE select VSIZE(clobCol) from... No N/A

Unicode INSTR2, SUBSTR2, LENGTH2, LIKE2

These functions use UCS2 code point semantics.

No CNV

Unicode INSTR4, SUBSTR4, LENGTH4, LIKE4

These functions use UCS4 code point semantics.

No CNV

Unicode INSTRC, SUBSTRC, LENGTHC, LIKEC

These functions use complete character semantics.

No CNV

59