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