Saturs

IEVADS......................................................................................................................................3

1. UNIVERSĀLĀS DATU BĀZES SISTĒMAS.......................................................................3

1.1 Relāciju datu bāzes sistēmas.............................................................................................3

1.2 Objektu datu bāzu sistēmas...............................................................................................3

1.3 Relāciju – objektu datu bāzu sistēmas..............................................................................3

2.RELĀCIJU OBJEKTU DATU BĀZU SISTĒMU REALIZĀCIJAS.....................................3

2.1 Firmas Oracle datu bāzu sistēma......................................................................................3

2.1.1. Tabula ar objektu kolonnu........................................................................................3

2.1.2. Objektu tabula ar rindas tipa objektiem....................................................................3

2.1.3 Iekļautās kolekcijas....................................................................................................3

2.1.4 Objektu skati..............................................................................................................3

2.1.5. Objektu metodes.......................................................................................................3

2.2 Informix............................................................................................................................3

2.2.1 Informix datu tipi.......................................................................................................3

2.2.1.3. Tipu mantošana......................................................................................................3

2.3 DBVS DB2......................................................................................................................3

2.3.1 Objekts.......................................................................................................................3

2.3.2 Objektu tabula............................................................................................................3

2.3.3 Tabula ar objektu kolonnu.........................................................................................3

2.3.4 Tipu hierarhija............................................................................................................3

2.3.5 Objektu skats..............................................................................................................3

2.4 Datu bāzu sistēma PostgreSQL.........................................................................................3

2.4.1 PostgreSQL DBVS....................................................................................................3

2.4.2 Saliktie datu tipi.........................................................................................................3

3. Relāciju – Objektu DB sistēmu izmantošana IS projektēšanā................................................3

3.1 DBS projektēšana..............................................................................................................3

3.2 Pamata transformācijas.....................................................................................................3

3.2.1 Klases transformācija.................................................................................................3

3.2.2 Klases atribūta transformācija....................................................................................3

3.2.3 Atslēgas atribūta transformācija................................................................................3

3.2.4 Atribūta obligātuma transformācija...........................................................................3

3.2.5 Klases metodes transformācija..................................................................................3

3.2.6 Saites viens pret daudziem transformācija.................................................................3

3.2.7 Saites viens pret vienu transformācija.......................................................................3

3.2.8 Saites daudzi pret daudziem transformācija..............................................................3

3.2.9 Ternārās un n-ārās saites transformācija....................................................................3

3.2.10 Vispārinājuma saites transformācija........................................................................3

3.2.11 Saites ar asociācijas klasi transformācija.................................................................3

3.2.12 Unārās saites transformācijas...................................................................................3

4 RELĀCIJU OBJEKTU DATUBĀZU IESPĒJU SALĪDZINĀJUMS....................................3

SECINĀJUMI.............................................................................................................................3

LITERATŪRA...........................................................................................................................3

IEVADSDatu bāzes (DB) tehnoloģija tās pirmsākumos attīstījās izolēti no lietojumprogrammu jeb

lietojumu (application) realizēšanas tehnoloģijām. Datu apmaiņai starp lietojumu un DB

sākumā tika izstrādātas specializētas (katrai DB vadības sistēmai) interfeisa bibliotēkas. Vēlāk

tās tika standartizētas. Pieaugot izmantojamo datu struktūru sarežģītībai (grafiskie dati,

temporālie dati, hierarhiskie dati) un attīstoties objektu orientētajai programmēšanai (object

oriented programming) arvien aktuālāks kļuva jautājums par programmu un DB datu

apmaiņas efektivitātes uzlabošanu.

Strādājot ar saliktiem datiem ir izdevīgi datus organizēt kopā ar tām procedūrām un

funkcijām, kuras veic ar tiem manipulācijas. Programmās tika veidoti objekti kā datu un

metožu apvienojumi. Līdz ar to bija vēlme, lai arī DB saliktie dati un to apstrādes metodes

veidotu šādus objektus. Bija mēģinājumi izveidot objektu DB. Diemžēl netika atrasti objektu

glabāšanas (store) varianti ārējā atmiņā, kuri nodrošinātu efektīvu (ātru) datu izguvi. Jāatceras

arī, ka DB nav viena lietojuma datu pastāvīga (persistent) glabāšanas vieta [1]. DB veido

daudziem lietojumiem un tai ir arī sava „dzīve”, neatkarīga no lietojumiem (DB veidošana,

datu ievade, uzturēšana, optimizācija, drošības pasākumi). Programmu un DB objekti eksistē

atšķirīgās vidēs: operatīvajā atmiņā un ārējā (external memory) atmiņā (ar izņēmumiem).

Objektu ieviešanu DB gribēja veikt revolucionārā veidā, bez nopietna matemātiska

pamatojuma.

Apskatot relāciju DB tehnoloģijas un objektu-orientētās (object oriented) tehnoloģijas

apvienošanu, jāsaprot, ka šī situācija atšķiras no iepriekšējās, kad tika veikta revolucionāra

pāreja no pirmsrelāciju (prior relation) DB sistēmām uz relāciju DB sistēmām. Pirmie DB

sistēmu (DB + DB vadības sistēma (database management system)) risinājumi tika veidoti

izmantojot inženiertehniskas idejas, kuras bija veidojušās vairāku gadu pieredzē strādājot ar

lieliem datu apjomiem. Protams, šīm sistēmām bija daudz nepilnību, jo trūka vienota skata uz

problēmu kopumā. 70-to gadu beigās tika izstrādāti matemātiskie pamati relāciju datu bāzēm

un nu jau gandrīz 30 gadus relāciju datu bāzes vai SQL datu bāzes tiek plaši lietotas

informācijas sistēmu veidošanai. Tas izskaidrojams ar to nopietno un veiksmīgo matemātisko

pamatojumu, ko izstrādāja T. Kodds un viņa pētniecības grupa [2].

Izstrādājot DB ar objektu orientētām struktūrām, ir vēlme saglabāt relāciju sistēmu

pamatkarkasu, kas daudzu gadu ekspluatācijā ir parādījis savas labās īpašības [3]. Pēc vairāku

3

vadošo speciālistu domām [1,4], relāciju DB modelī jau potenciāli ir iekļautas iespējas

izmantot saliktus datus (jaunus datu tipus), diemžēl eksistējošās relāciju DB vadības sistēmas

nav to realizējušas. Tāpēc tās bieži vien sauc arī par pseido (gandrīz) relācijas DB sistēmām.

Relāciju datu bāzes (DB) un objektu-orientēto tehnoloģiju apvienošanu var veikt

izmantojot dažādas pieejas [4]:

1) hibrīda DB vadības sistēmas (hybrid database management systems) veidošana;

2) paplašinātās relāciju tehnoloģijas (extended relational technology) izmantošana DB

realizēšanai.

Hibrīda DB vadības sistēmas izmanto tos pašus datu vadības mehānismus kā relāciju DB,

bet viņām tiek veidots objektu-orientēts ārējais interfeiss. Tas veic relāciju datu struktūru

transformāciju vajadzīgajās objektu struktūrās un otrādi (1.1 att.). Diemžēl relāciju-objektu un

objektu-relāciju transformāciju veikšana būtiski pasliktina DB sistēmas veiktspēju

(performance). Neskatoties uz šo pamattrūkumu, šī pieeja 80-to gadu beigu posmā tika plaši

izmantota repozitoriju (repository) veidošanai CASE (Computer Aided System Engineering)

un CAD (Computer Aided Design) sistēmās [4].

Paplašinātās relāciju tehnoloģijas DB vadības sistēmas papildina relāciju datu struktūras

ar objektiem un nodrošina vēlamās datu manipulāciju iespējas (1.1 att.). Šī tehnoloģija 90-

tajos gados guva plašu atzinību un tika izstrādātas daudzas atbilstošas DB vadības sistēmas.

1.1. att. Hibrīda un paplašinātā relācijas DBVS

Plašākie pētījumi tika izvērsti firmas IBM zinātniskajos centros un Kalifornijas universitātē.

Kā jaunās paaudzes pirmās DB vadības sistēmas var atzīmēt Informix Universal Server

(Informix Software, 1996), Oracle8i (Oracle Corp., 1997), DB2 Universal Database (IBM

Corp., 1997), UniSQL (UniSQL, Inc., 1998).

Paplašinātās relāciju DB vadības sistēmas sāka saukt par universālajiem DB serveriem

(universal database servers) vai objektu-relāciju DB vadības sistēmām (object-relational

DBMS). Daudzi DB tehnoloģijas speciālisti ar profesoru K. Deitu (Cris Date) priekšgalā, jau

šīs tehnoloģijas izmantošanas pirmsākumos atzīmēja, ka kā pamats tiek izmantota relāciju DB

tehnoloģija, kuru papildina objektu-orientēto principu iekļaušana [1]. Tāpēc pareizāk šīs

4

sistēmas būtu saukt par relāciju-objektu DB vadības sistēmām. Šāds nosaukums precīzāk

atspoguļotu DB sistēmās iekļautos principus (angļu valodas DB tehnoloģijas grāmatās un

publikācijās ir ieviesušies daudzi pavirši veidoti termini, tāpēc veicot to tulkojumu, būtu

lietderīgi šīs neprecizitātes likvidēt).

Objektu-relāciju DB papildus relāciju tehnoloģijai ļauj:

1) veidot lietotāja definētus saliktus datu tipus (piemēram, adrese (pilsēta, iela, mājas

numurs);

2) izmantot atribūtus, kuriem var būt vairākas vērtības (multivalued attributes);

3) realizēt datu tipu mantošanas (inheritance) mehānismus;

4) realizēt datu tabulu mantošanas mehānismus;

5) DB glabāt (store) un izmantot saliktu datu tipu objektu apstrādes metodes;

6) realizēt metožu mantošanas mehānismus.

Mūsdienās DB vadības sistēmu tirgū ir daudzas firmas, kuras izstrādā un pārdod relāciju-

objektu DB serverus: Daffodil Software, Ltd. (Daffodil DB), EnterpriseDB Corporation

(EnterpriseDB), FirstSQL, Inc. (FirstSQL/J), The GigaBase Project (GibaBase), IBM

(Cloudscape and DB2), InterSystems Corporation (Cache), Micro Data Base Systems, Inc.

(TITANIUM), OpenLink Software, Inc. (Vituoso Universal Server), Oracle Corporation

(Oracle), Paradigma Software (Valentina), PostgreSQL Global Development Group

(PostgreSQL). Visplašāko ievērību ir guvušas DB vadības sistēmas Oracle (vairāk kā 1/3 no

kopējā skaita) un DB2 (tuvu 1/5). Daudz teorētisko jauninājumu tiek ieviesti PostgreSQL

sistēmās [5, 6, 7].

Relāciju-objektu datu bāzes pirmās koncepcijas tika publicētas jau pagājušā gadsimta 80-

to gadu vidū, bet plašu ievērību tās guva tieši gadsimtu mijā. 2. attēlā parādīta rakstu un

grāmatu skaits par relāciju-objektu datu bāzes tehnoloģiju pēdējos 30 gados [8].

5

1. UNIVERSĀLĀS DATU BĀZES SISTĒMAS

1.1 Relāciju datu bāzes sistēmas

Relāciju datubāze sastāv no vairākām tabulām, kurās glabājas atsevišķas datu kopas. Šis

datubāzes veids ir standartizēts veids datu apstrādē un glabāšanā. Relāciju datubāzes koncepts

pamatojas uz relāciju algebru. Relāciju datubāzes pamatlicējs ir T.Kods. Vairākumam

mūsdienu datu bāzu sistēmu pamatā ir relāciju sistēma. Relāciju datubāzes vēsture aizsākās ar

T.Koda publikāciju A Relational Model of Data for Large Shared Data Banks. Šī teorija

noteica, ka datiem ir jābūt neatkarīgiem no aparatūras vai glabāšanas sistēmas, un jābūt brīvai

navigācijai starp datu elementiem. Praktiski tas nozīmē, ka datiem ir jāglabājas tabulās un

saites eksistē starp dažādām datu kopām vai tabulām. Relācija, kas ir divdimensiju tabula ir

pamata glabāšanas vienība relāciju datu bāzē. Relāciju datu bāze var saturēt vienu vai

vairākas šādas tabulas, katrai tabulai var būt atšķirīgs kolonnu un rindu skaits. Atsevišķs

ieraksts tiek glabāts kā rinda, kuras datu atribūti tiek definēti kā kolonnas, vai lauki tabulā.

Katrai kolonnai ir unikāls nosaukums, un tās saturam ir jābūt vienam datu tipam katrā rindā.

Tabulas var būt sasaistītas viena ar otru vairākos veidos. Funkcionālā atkarība tiek veidota

kad atribūts no vienas tabulas tiek sasaistīts ar atribūtu no citas tabulas. Vienkāršākā saite ir

viens pret vienu, kurā viens ieraksts tabulā tiek saistīts ar citu ierakstu citā tabulā. Saite viens

pret daudziem ir kad viens ieraksts tabulā ir saistīts ar vairākiem ierakstiem citā tabulā. Saite

daudzi pret daudziem nozīmē, ka vairāk kā viens ieraksts vienā tabulā ir saistīts ar vairāk kā

vienu ierakstu citā tabulā. Atslēga ir tabulas entītija, kas atšķir vienu datu rindu no citas.

Atslēga var būt viena kolonna vai sastāvēt no vairākām kolonnām kas unikāli identificē

ierakstu. Ārējā atslēga datubāzē saista tabulas. Ārējā atslēga vienā tabulā ir primārā atslēga

citā tabulā. Dati, kas tiek glabāti tabulās ir organizēti lai minimizētu datu dublēšanos, novērstu

datu anomālijas, un pastiprinātu datu integritāti. Process, kurā dati tiek loģiski organizēti tiek

saukts par normalizāciju. Normalizācija vienkāršo veidu kādā dati tiek definēti un nosaka to

struktūru. Normalizācijas procesā ir piecas formas, jo augstāka ir normalizācijas pakāpe jo

stingrāki ir nosacījumi. Ar datiem relāciju datu bāzēs manipulācijas tiek veiktas ar SQL. SQL

pamatā ir kopu teorija, relāciju operatori [12].

6

1.2 Objektu datu bāzu sistēmas

Objektu datubāze ir datubāzes modelis, kurā informācija tiek attēlota objektu formā tādā pašā

veidā kā objektu orientētajā programmēšanā. Objektu datubāzē datubāzes iespējas tiek

kombinētas ar objektorientētās programmēšanas iespējām. Mūsdienās plaši tiek izmantotas

objektu orientētās programmēšanas valodas, un objektu datubāze ir labi piemērota tai tajā

glabātu datus kas ir strukturēti kā objekti. Objektu datubāzes labi sadarbojas ar tādām objektu

orientētām programmēšanas valodām kā Ruby, Python, Perl, Java, C#,C++. Objektu

datubāzēs tiek izmantots tāds pats modelis kā objektorientētajās programmēšanas valodās.

Objektu datubāzēs tiek lietota speciāla vaicājumu valoda, kura nodrošina objektu meklēšanu

izmantojot deklaratīvo programmēšanas pieeju. Visplašāk tiek izmantota Objektu vaicājumu

valoda(Objektu Query Language) OQL. Objektu datubāzu priekšrocība ir datu apstrādes

ātrums. Objektu datubāzes datu apstrādi veic ātrāk kā relāciju datu bāzes, jo dati netiek glabāti

kā raksti un kolonnas, bet kā objekti. Objektiem ir saite daudzi pret daudziem un tiem var

piekļūt lietojot rādītājus. Rādītāji ir piesaistīti objektiem lai nodrošinātu saites. Salīdzinot ar

relāciju datu bāzēm, objektu datu bāzes priekšrocība ir tā, ka nav nepieciešams objektu

relāciju transformāciju slānis, lai transformētu lietojumprogrammas objektu modeli uz

datubāzes objektu modeli [13].

1.3 Relāciju – objektu datu bāzu sistēmas

Kā jau iepriekš minēts, objektu-relāciju DB pamatstruktūru jeb karkasu veido relāciju

DB, kurai izveidota objektu virsbūve [9]. Tāpēc objektu-relāciju DB realizē visas relāciju DB

iespējas un papildus:

1) raksta tipa objektu (row objects) un kolonas tipa objektu (colon type) veidošanu.

Izmantojot objektu identifikatorus (OID), uz raksta tipa objektiem var veikt norādes

(references).

2) objektiem tiek piesaistītas to apstrādes metodes;

3) apstrādes metodes tiek piesaistītas arī objektu skatu objektiem;

4) tiek realizēti datu un metožu mantošanas mehānismi;

5) daudzās situācijās ir iespējams objektus apskatīt arī kā relāciju tabulas kolonu vērtību

kopumu. Tātad objektu-relāciju DB tiek realizēti pārveidojumi no relāciju datiem uz

objektiem un otrādi.

7

6) strukturētā ne-procedūru vaicājumu valoda SQL (Structure Query Language) ir

papildināta ar jaunām funkcijām, kuras nodrošina objektu definēšanu, objektu datu

ievadi un manipulāciju veikšanu ar objektu datiem.

Dažādās objektu-relāciju DB vadības sistēmās (Oracle, DB2, PosgreSQL) objektu

virsbūve ir realizēta atšķirīgi [10, 11]. Pamats visās ir lietotāja definētie objekta tipi. Viens no

pārdomātākajiem un efektīvākajiem objektu virsbūves risinājumiem ir firmai Oracle [7]. Tiek

veidotas objektu tabulas (tabulas ar raksta tipa objektiem), tabulas ar objektu kolonām (kolonu

tipa objektu izmantošana), tabulas ar iekļautām objektu kolekcijām (nested table), tabulas ar

heterogeniem objektiem, kuras ļauj realizēt mantošanas (inheritance) mehānismus. Tabulas ar

iekļautajām kolekcijām arī ļauj veidot efektīvas objektu hierarhijas struktūras. Plašas DB

projektēšanas iespējas ļauj realizēt objektu skati un to hierarhijas.

Objektu-relāciju DB struktūras veido relāciju tabulu karkasi un iekļautie dažādas

sarežģītības pakāpes objekti. Rezultātā var tikt iegūtas sarežģītas struktūras, kuras atbilst nevis

vienam objektu-orientētās tehnoloģijas izmantotajam objektam, bet veselai objektu struktūrai.

Tas var ļoti sekmēt datu apmaiņas efektivitātes palielināšanu un jāņem vērā izstrādājot

objektu-orientēto tehnoloģiju objektu transformēšanu objektu-relāciju DB struktūrās.

Objektu identifikatoru un norādītāju izmantošana ne tikai sekmē datu izgūšanas

ātrdarbības palielināšanu, bet dod plašākas iespējas dažāda tipa saišu realizēšanai. Pretstatā

relāciju tehnoloģijai, šajā gadījumā saites ir vienvirziena. Tas ļauj realizēt saites tipu „daudzi

ar daudziem” , izslēdzošā VAI (exclude OR) tipa ierobežojumus (constraints), kā arī daudzus

citus ierobežojumus saitēm saliktās struktūrās. Attēlā 1.2 dotas DBVS Oracle galvenās

relāciju-objektu datu struktūras. Attēlā 1.3 parādīti objektu saišu veidi.

8

a) objektu tabula ar metodēm un norādēm

b) tabula ar objektu kolonnu

c) tabula ar kolekciju

d) objektu tabula ar kolekciju

e) tabula ar heterogēniem objektiem

f) objektu skats

1.2 att. DBVS Oracle10G DB galvenās relāciju-objektu struktūras

9

1.3 att. Objektu saišu un to realizēšanas variantu dažādība

10

2.RELĀCIJU OBJEKTU DATU BĀZU SISTĒMU REALIZĀCIJAS

2.1 Firmas Oracle datu bāzu sistēma

2.1.1. Tabula ar objektu kolonnu

Jauni objektu tipi var būt izveidoti no jebkuriem iebūvētiem tipiem un/vai no iepriekš

izveidotiem objektu tipiem, objektu norādēm un kolekciju tipiem. Objektu tipi un attiecīgas

objektu - relāciju īpašības, tādas kā masīvi un ieliktas tabulas, piedāvā augstākā līmeņa

iespējas datu organizācijai un piekļūšanai datu bāzei. Objektu līmenī dati joprojām glabājas

kolonnās un tabulās, bet ar tiem iespējams strādāt kā ar reālas pasaules būtībām, kas piešķir

datiem nozīmi. Kopumā, objekta tipa modelis ir līdzīgs C++ vai Java klases mehānismam.

Tapāt kā klase, objekts padara vieglāku reālas pasaules sarežģītas būtības un loģikas

modelēšanu, un objektu atkārtota izmantošana padara datu bāzes lietojuma veidošanu ātrāku

un efektīvāku [7].

Objekta tips tiek veidots ar komandu CREATE OR REPLACE TYPE. Tips adrese_t

satur atribūtus Iela, Majas_numurs, Dzivokla_numurs, Pilseta, Valsts. Tips adrese_t tiek

veidots ar sekojošu komandu:

CREATE OR REPLACE TYPE adrese_t AS OBJECT (

Iela VARCHAR2(30),

Majas_numurs NUMBER,

Dzivokla_numurs NUMBER,

Pilseta VARCHAR2(30),

Valsts VARCHAR2(30));

Iepriekš izveidoto tipu adrese var izmantot kā kolonnas tipu veidojot tabulu. Tabulā Cilveks

kolonnai adrese būs tips adrese_t. Tabula Cilveki tiek veidota ar sekojošu komandu:

CREATE TABLE Cilveks (

Numurs NUMBER,

Vards VARCHAR2(25),

Uzvards VARCHAR(35),

Adrese adrese_t );

Datu ievade tabulā tiek veikta ar sekojošu komandu:

INSERT INTO Cilveks VALUES (200,'Inese','Koks',

11

Adrese_t('Kr.Valdemāra',21,7,'Rīga','Latvija'));

Lai izgūtu visus datus no tabulas izmanto sekojošu vaicājumu:

Select * From Cilveks;

Vaicājuma rezultāts:

200 Inese Koks ADRESE_T('Kr.Valdemāra',21,7,'Rīga','Latvija')

2.1.2. Objektu tabula ar rindas tipa objektiem.

Objekta tabula (object table) ir tabula, kuras katra rinda ir objects (row-type-objects).

Objekta tabulas objektiem ir objektu identifikatori OID. Tie var tikt izmantoti lai norādītu uz

attiecīgo objektu. Vispirms izveido tipu cilvēks. Tips cilvēks satur atribūtus VAR, UZV, TEL.

Tips cilvēks tiek veidots ar sekojošu komandu:

Create or replace type CILVEKS AS object( varchar2(20),

VAR varchar2(30),

UZV varchar2(30),

TEL varchar2(20));

Pamatojoties uz tipu cilvēks tiek veidota tabula cilvēki. Tabula Cilveki ir objektu tabula kuras

tips ir cilvēks. Tabula cilvēki tiek veidota ar sekojošu komandu:

create table CILVEKI of CILVEKS;

Datu ievietošana tabulā tiek veikta ar komandu INSERT INTO. Datu ievade tabulā Cilveki

tiek veikta ar sekojošu komandu:

insert into CILVEKI values(CILVEKS('Anita','Koks',

'1111111'));

insert into CILVEKI

values(CILVEKS('Liene','Zars' ,'2222222'));

Viena ieraksta izgūšana no tabulas Cilveki tiek veikta ar sekojošu vaicājumu:

Select VALUE(A) from CILVEKI A where VALUE(A).VAR= 'Anita';

Vaicājuma rezultāts:

CILVEKS('Anita','Koks','1111111')

2.1.3 Iekļautās kolekcijas

Iekļauta tabula ir nesakārtota elementu kopa, kur visiem elementiem ir vienāds datu tips.

Tabulai ir viena kolonna un kolonnas tips var būt iebūvēts datu tips vai lietotāja veidots

objektu tips. Ja kolonna ieliktā tabulā ir ar objektu tipu, tad tabulu var apskatīt kā tabulu ar

12

vairākām kolonnām, kur kolonna ir objektu komponente. Ir dažādi veidi kā piekļūt ieliktai

tabulai. Viens var atgriezt ieliktu tabulu kā atomāro vērtību klienta objektu kešā un operēt ar

to izmantojot kolekcijas interfeisus (collection interfaces) pieejamu OCI vai ar ieliktām

tabulām var operēt izmantojot SQL paplašinājumus. Viens no tādiem paplašinājumiem ir

izlīdzināts apakšvaicājums (flattened subquery), kuras mērķis ir dot iespēju izvēlēties vienīgo

nepieciešamo ieliktu tabulu uz kuras vajag izdarīt kādas operācija.

Vispirms tiek izveidota objekta tips. Tips gramata satur atribūtus NOS, AUT, NUM. Tips

gramata tiek veidots ar sekojošu komandu:

CREATE OR REPLACE TYPE gramata AS OBJECT (

NOS VARCHAR2(50),

AUT VARCHAR2(30),

NUM NUMBER(6));

Kolekcija tiek veidota kā objekta tips ar kolekciju. Tips gramatas satur kolekciju ar tipu

gramata. Tips gramatas tiek veidots ar sekojošu komandu:

CREATE OR REPLACE TYPE gramatas AS TABLE OF gramata;

2.2 att. Tipa gramatas struktūra

Tabula Mācību grāmatas(mac_gram) satur atribūtus PRIEKSMETS, SEMESTRIS,

GRAMATAS. Atribūta GRAMATAS tips ir iepriekš izveidotais kolekcijas tips grāmatas.

CREATE TABLE Mac_gram(

PRIEKSMETS VARCHAR2(30),

SEMESTRIS VARCHAR2(2),

GRAMATAS gramatas)

NESTED TABLE IZM_LIT STORE AS Gramatas_t;

Datu ievade tabulā mac_gram tiek veikta ar sekojošu komandu:

INSERT INTO Mac_gram VALUES('Datu bāzes', 'A1',

gramatas(gramata('Datu bāzes tehnoloģija','J.Koks', 123),

gramata('Lielās datu bāzes', 'I. Ozols', 126)));

13

2.1.att. tipa gramata struktūra

2.1.4 Objektu skati

DBVS Oracle ir iespēja veidot objektu abstrakciju uz relāciju datiem izmantojot objektu

skatus (object views). DML paplašinājumi (un OCI paplašinājumi), lai operētu ar objektu

tabulām arī atbalsta objektu skatus. Tāpēc, objektu skati ir atslēga jaunu objektu - orientētu

lietojumu veidošanai bez vajadzības modificēt eksistējošu relāciju datu bāzes shēmu.

Objektu skatam ir sekojošas īpašības, līdzīgas objektu tabulai:

1) Objektu skats satur objektus rindas; kolonnas sakrīt ar objekta tipa augstāka līmeņa

atribūtiem.

2) Katram objektam ir ar to saistīts identifikators. Identifikators netiek ģenerēts ar

sistēmu, bet tiek specificēts ar lietotāju. Parasti, kā identifikatoru izmanto pamat

tabulas primāro atslēgu. Tas tiek specificēts izmantojot WITH OBJECT OID, kad

veido skatu.

3) Objektu skati ir atjaunojami. Skatus, kas ir neatjaunojami pēc mantošanas, atjauno

INSTEAD-OF trigeri. Kad objekta skats ir atjaunots (vai iekļauts, vai nodzēsts no

tabulas), sistēma vienkārši izpilda INSTEAD-OF trigeru, specificētu šim skatam.

Lietotājs var iekapsulēt (encapsulate) vajadzīgu atjaunošanas semantiku trigera

ķermenī.

Tabulas Darbinieki izveidošana:

CREATE TABLE Darbinieki (

D_NUM number(5),

UZV varchar2(20),

ALGA number(9,2),

AMATS varchar2(20));

Datu ievietošana tabulā Darbinieki:

INSERT INTO Darbinieki VALUES (1,'Koks',200.50, 'galdnieks');

INSERT INTO Darbinieki VALUES (2,'Zars',180.00, 'sekretāre');

Tipa darbinieks_tips izveidošana:

CREATE OR REPLACE TYPE Darbinieks_tips AS OBJECT(

D_NUM number (5),

UZV varchar2 (20),

ALGA number (9, 2),

AMATS varchar2 (20));

14

Skats Darb_skats tiek veidots pamatojoties uz tipu Darbinieks_tips un dati tiek ņemti no

tabulas Darbinieki. Skats Darb_skats tiek veidots ar sekojošu komandu:

CREATE VIEW Darb_skats OF Darbinieks_tips WITH OBJECT ID

(D_NUM) AS

SELECT A.D_NUM, A.UZV, A.ALGA, A.AMATS

FROM Darbinieki A;

Datu izgūšana no skata tiek veikta ar sekojošu komandu:

SELECT VALUE(A) FROM Darb_skats A;

VALUE(A)(D_NUM, UZV, ALGA, AMATS)

---------------------------------------------

DARBINIEKS_TIPS(1, 'Koks', 2,01, 'galdnieks')

DARBINIEKS_TIPS(2, 'Zars', 1,80, 'sekretāre')

MAKE_REF operators ir lietderīgs, lai pārveidotu ārējās atslēgas kolonnu uz REF

kolonnu objektu skatā. Piemēram, REF vērtība tiek veidota depart atribūtam no relāciju

tabulas kolonnas depnr. Skats Darb_skats tiek veidots ar sekojošu komandu:

CREATE VIEW Darb_skats OF Darbinieks WITH OBJECT ID

(id)AS SELECT p.d_id, p.d_darbinieks Make_Ref(depart,

p.d_depnr), p.d_amats, p.d_alga

FROM Darbinieki p

WHERE p.d_amats=’gramatvedis’;

CAST izteiksme var būt izmantota, lai paņemtu apakšvaicājuma rezultātus un konstruētu

ieliktas tabulas vērtību. Vienīga prasība, lai apakšvaicājuma kolonnas atbilstu ieliktas tabulas

objekta tipa atribūtiem pēc skaita, kārtības un tipa. Var izmantot izteiksmi MULTISET()

ieliktā apakšvaicājumā, lai apakšvaicājums atgrieztu rindu kopu, kas ir pretējais noklusēšanai

(kas ir vienīgā rinda). Piemēram:

SELECT depnr, CAST(MULTISET(SELECT p.d_id, p.d_darbinieks,

p.d_amats, p.d_alga

FROM Darbinieki p

WHERE p.d_depnr=d.dnr) AS DarbiniekuKopa)

FROM Departamenti d;

15

2.1.5. Objektu metodes

Metodes ir funkcijas vai procedūras, kuras var deklarēt objekta tipa definēšanā, lai

izveidotu uzvedību, kuru ar objektu var veikt.

DBVS Oracle tiek izmantoti sekojoši objekta metožu tipi:

1) konstruktora metodes (objekta veidošanai no komponentēm).

2) MAP member tipa metodes (objektu sakārtošanai);

3) ORDER member tipa metodes (objektu salīdzināšanai);

4) MEMBER tipa metodes (universālas metodes);

5) STATIC tipa metodes (objekta tipa definējuma koriģēšanai un papildināšanai);

Konstruktora metodi (constructor method) sistēma definē katram objektu tipam. Konstruktora

metodi izsauc, lai konstruētu vai izveidotu dotā tipa objekta eksemplāru.

Metodes tiek veidotas lai salīdzinātu objekta eksemplārus (MAP un ORDER tipa

metodes), lai izpildītu operācijas, kas neizmanto konkrēta objekta datus, bet ir globālas

objekta tipam (STATIC metodes). Metodes var būt uzrakstītas PL/SQL valodā vai jebkurā

citā programmēšanās valodā. Metodes , kas uzrakstītas PL/SQL vai Java programmēšanas

valodās, glabājas datu bāzē. Metodes uzrakstītas citās valodās, tādās kā C, glabājas ārpus datu

bāzes.

1)Konstruktora funkciju definēšana

Lai tipam nodefinētu konstruktora funkciju tipa karkasā ir jānorāda šī funkcija un tās atribūti.

Tipam Cilveks tiek veidota konstruktora funkcija kura var konstruēt objektu cilvēks tikai no

diviem atribūtiem NUM un UZVARDS.

Tipa CILVEKS ar konstruktora funkciju izveidošana:

create or replace type CILVEKS as object(

NUM number,

VARDS varchar2(50),

UZVARDS varchar2(50),

DZIMUMS char(8),

TELEFONS varchar2(10),

constructor function CILVEKS(NUM number, UZVARDS

varchar2)

return SELF as result);

Tipa ķermenī tiek definēta konstruktora funkcija:

create or replace type body CILVEKS as

16

constructor function CILVEKS(NUM number, UZVARDS

varchar2)

return SELF as result is

begin

SELF.NUM := NUM;

SELF.UZVARDS := UZVARDS;

return;

end;

2)Objektu salīdzināšanas metodes

1. Skalāru datu tipu vērtībām ir iepriekš definēta kārtība, kas ļauj tās salīdzināt.

2. Objektiem, kuriem ir vairāki atribūti ar dažādiem tipiem, iepriekš definētas kārtības nav.

Lai tos varētu salīdzināt vai sakārtot, vajag noteikt salīdzināšanas algoritmu.

3. RODB tehnoloģijā tiek izmantotas divas metodes, kuras tiek iekļautas tipa definējumā, un

veic objektu salīdzināšanu:

1) kopēja agregēta novērtējuma izveidošanas metode (MAP member method);

2) objektu tiešas salīdzināšanas metode (ORDER member method).

Objekta tips var deklarēt tikai vienu objektu atbilstības metodi, vai nu MAP member vai

ORDER member. Apakštips var deklarēt objektu atbilstības metodi, tikai ja viņa supertips

deklarē tādu.

a)MAP member tipa metodes

Metode veido katram objektam skalāru novērtējumu un pēc tā vērtībām objekti tiek sakārtoti

augšanas (alfabēta) vai dilšanas kārtībā (pretēji alfabēta kārtībai). Šāda metode objekta tipā

var tikt definēta tikai viena.

Objekta tipa KVADRATS ar MAP member metodi izveide:

create type KVADRATS as object(

MALA number,

MAP member function LAUKUMS return number );

Tipa ķermeņa izveidošana:

create type body KVADRATS as

MAP member function LAUKUMS return number is

begin

return SELF.MALA*SELF.MALA;

17

end LAUKUMS;

end;

Objektu tabulas KVADRATI izveidošana balstoties uz tipu KVADRATS:

create table KVADRATI of KVADRATS;

Datu ievade tabulā:

insert into KVADRATI values(KVADRATS(4));

insert into KVADRATI values(KVADRATS(5));

insert into KVADRATI values(KVADRATS(2));

MAP member metodes izmantošana vaicājumos:

select VALUE(A) from KVADRATI A order by VALUE(A).LAUKUMS()

ASC;

VALUE(A)(MALA)

--------------------------

KVADRATS(2)

KVADRATS(4)

KVADRATS(5)

b) ORDER member tipa metodes izmantošana

ORDER member metode izpilda tiešu objekts – objekts salīdzināšanu. Šī metode ir lietderīga

situācijās, kur salīdzināšanas semantika ir pārāk sarežģīta, lai izmantotu MAP member tipa

metodi.

Tipa KLIENTS ar ORDER member metodi SALIDZINAT izveidošana:

create or replace type KLIENTS as object(

NUM number,

NOS varchar2(30),

MAKSA number(8,2),

ORDER member function SALIDZINAT(m_obj KLIENTS) return

integer);

Tipa ķermeņa izveidošana:

create or replace type body KLIENTS as

ORDER member function SALIDZINAT(m_obj KLIENTS) return

integer IS

begin

if SELF.MAKSA < m_obj.MAKSA then return –1;

18

elsif SELF.MAKSA > m_obj.MAKSA then return 1;

else return 0;

end if;

end SALIDZINAT;

end;

Tabulas KLIENTI izveide:

create table KLIENTI of KLIENTS;

Datu ievade tabulā KLIENTI:

insert into KLIENTI values(KLIENTS(1, 'AA’, 100));

insert into KLIENTI values(KLIENTS(2, 'BB’, 500));

insert into KLIENTI values(KLIENTS(3, 'CC’, 300));

insert into KLIENTI values(KLIENTS(4, 'DD’, 200));

3)Metodes izmantošana vaicājumos

select VALUE(A).NOS,VALUE(A).SALIDZINAT(C.OBJ)

from KLIENTI A, (select VALUE(B) as OBJ

from KLIENTI B

where VALUE(B).NOS = 'DD') C;

VALUE(A).NOS VALUE(A).SALIDZINAT(C.OBJ)

--

AA -1

BB 1CC 1

DD 0

4)STATIC metodes izmantošana

Statiskās metodes izpildās objektu tipiem, bet ne to eksemplāriem. Statiskās metodes izmanto

operācijām, kur tiek veikti pārveidojumi objekta tipam. Statiskai metodei nav parametra

SELF. Statisko metodi izsauc izmantojot punkta notāciju:

Tipa_nosaukums.Metode()

Tipa Departaments_t izveide:

CREATE OR REPLACE TYPE Departaments_t AS OBJECT (

D_NUM number(10),

D_NOS char(30));

19

Tips Darbinieks_t satur STATIC metodi Konstruktor_f_darbin . Tipa Darbinieks_t

izveidošana:

CREATE OR REPLACE TYPE Darbinieks_t AS OBJECT(

DA_NUM raw(16),

DA_NOS char(31),

DEPART REF Departaments_t,

STATIC FUNCTION Konstruktor_f_darbin (DA_NOS varchar2,

DEPART REF Departaments_t) RETURN Darbinieks_t);

Tipa ķermeņa izveidošana:

CREATE OR REPLACE TYPE BODY Darbinieks_t IS

STATIC FUNCTION Konstruktor_fun_darbin (DA_NOS varchar2,

DEPART REF Departaments_t) RETURN Darbinieks_t) IS

BEGIN

RETURN Darbinieks_t(SYS_GUID() ,DA_NOS, DEPART);

END;

END;

Tabulas Darbinieki izveidošana:

CREATE TABLE Darbinieki OF Darbinieks_t;

Datu ievade tabulā Darbienieki izmantojot STATIC funkciju:

INSERT INTO Darbinieki VALUES

(Darbinieks_t.Konstruktor_f_darbin (Juris Koks, NULL));

Datu izgūšana no tabulas darbibinieki:

SELECT * FROM Darbinieki;

6F3AE6CE648D417BA7F5657C6C8D10F7 Juris Koks

20

RODBS InformixInformix datu bāzu serveris nodrošina iebūvētus datu tipus un paplašinātos datu tipus.

Paplašinātie datu tipi, var būt salikti datu tipi tādi kā kolekcijas datu tipi un raksta datu tipi.

Un paplašinātie datu tipi var būt lietotāja izveidoti datu tipi tādi kā unikālais(distinct) datu tips

un neskaidrais(opaque) datu tips.

2.3 att. Informix datu tipi.

2.2.1.1 Paplašinātie datu tipi

Paplašinātie datu tipi ļauj noraksturot datus, kurus nav viegli attēlot ar iebūvētajiem datu

tipiem. Paplašinātos datu tipus nevar izmantot sadalītajās transakcijās. Lietotāja definēts datu

tips ir datu tips, kuru nenodrošina datubāzes serveris. Ir nepieciešams nodrošināt visu

datubāzes serverim nepieciešamo informāciju lai tas tiktu galā ar lietotāja definētajiem datu

tipiem. Salikts datu tips apraksta gan datu objektu kolekciju ar kādu no

tipiem(LIST,SET,MULTISET), vai objektu grupas ar citiem tipiem(nosauktais un

nenosauktais rindas tips) [14].

1)Lietotāja veidotie datu tipi:

a) Unikālais(distinct) datu tips ir iekapsulēts datu tips, kas tiek izveidots ar komandu

CREATE DISTINCT TYPE priekšrakstu. Unikālajam datu tipam ir tāds pats

attēlojums kā datu tipam uz kuru tas ir bāzēts, bet ir noteikta forma. Unikālo datu tipu

var izveidot no iebūvētajiem datu tipiem, neskaidrajiem(opaque) tipiem, nosauktajiem

rindas tipiem vai citiem noteiktajiem tipiem. Kad unikālais datu tips tiek izveidots tiek 21

netieši definēta datu tipa struktūra, jo unikālais datu tips manto struktūru no tā avota

tipa. Unikālajam datu tipam var definēt funkcijas, operatorus, un agregātus, kas

darbojas ar šo tipu.

b) Necaurredzamie(opaque) datu tipi.

Necaurredzamais(opaque) datu tips ir iekapsulēts datu tips, kas tiek izveidots ar

CREATE OPAQUE TYPE priekšrakstu. Kad tiek veidots necaurredzamais datu tips,

skaidri ir jānodefinē tā struktūra, funkcijas, operatori un agregāti, kas darbojas ar

necaurredzamo datu tipu. Necaurredzamo datu tipu var izmantot lai definētu kolonnas

un programmas mainīgos, līdzīgi kā izmantojot iebūvētos datu tipus.

c) Datulapas(DataBlade) datu tipi.

Datulapas(DataBlade) datu tips, kaut arī patiesībā tas nav datu tips, tas ir lietotāja

izveidotu datu tipu un lietotāja izveidotu rutīnu komplekts, kas nodrošina rīkus

specifiskiem lietojumiem. Piemēram, attēlu un dinamisko rindu apstrādei.

d) Lielie objekti(smart large objects).

Lielie objekti(smart large objects) ir objekti, kas ir definēti kā BLOB vai CLOB datu

tipi. Lielie objekti atļauj lietojumprogrammām brīvi piekļūt kolonnas datiem, kas

nozīmē, ka var nolasīt vai ierakstīt jebkuru BLOB vai CLOB kolonnu patvaļīgā

kārtībā. BLOB un CLOB kolonnās var glabāt bināros vai rakstzīmju datus.

2.2.1.2. Saliktie datu tipi

Saliktie datu tipi(Complex data type) parasti ir veidoti no citiem datu tipiem. Piemēram,

var izveidot saliktu datu tipu, kura komponentes ir iebūvētie datu tipi, necaurredzamie datu

tipi noteiktie datu tipi vai citi salikti datu tipi. Salikto datu priekšrocība ir tā, ka var piekļūt un

darboties ar atsevišķām saliktā tipa komponentēm. Salīdzinājumā, iebūvētie un lietotāja

definētajiem tipi ir iekapsulēti datu tipi. Kā rezultātā vienīgais veids kā piekļūt necaurredzamā

datu tipa komponenšu vērtībām ir caur funkcijām kas nodefinētas necaurredzamajam datu

tipam.

a) Kolekcijas datu tips

Kolekcijas datu tips ļauj glabāt un vadīt datu kolekcijas tabulas vienas šūnas ietvaros.

Kolekcijas datu tipam ir divas komponentes: tipa konstruktors, kurš nosaka vai

kolekcijas tips ir SET, MULTISET vai LIST, un elementa tips, kurš nosaka datu tipu

ko satur kolekcija. Kolekcijas elementi var būt lielākā daļa datu tipu. Kolekcijas

elementi ir vērtības kuras kolekcija satur. Visiem kolekcijas elementiem ir jābūt

22

vienam datu tipam. Kolekcijas elementa tips var attēlot vienu datu tipu(kolonnu) vai

rindas tipa elementu, kas satur vairākus datu tipus.

Informix datubāzes serveris atbalsta šādus kolekciju tipus:

1) Kolekcijas tips SETSET ir nesakārtota elementu kolekcija, kurā katrs elements ir unikāls.

2) Kolekcijas tips MULTISETMULTISET ir elementu kolekcija, kurā elementiem var būt vienādas vērtības

3) Kolekcijas tips LISTLIST ir sakārtota elementu kolekcija, kura pieļauj vienādas vērtības. LIST atšķiras no

MULTISET ar to, ka katram elementam LIST kolekcijā ir kārtas pozīcija.

4) Iekļautais kolekcijas tipsIekļauta kolekcija ir kolekcijas tips, kas satur citu kolekcijas tipu. Jebkuru kolekcijas

tipu var iekļaut citā kolekcijas tipā.

Kolekcijā nevar iekļaut datu tipus: TEXT,BYTE,SERIAL,SERIAL8. Nevar izmantot

CREATE INDEX priekšrakstu lai izveidotu indeksu kolekcijai, un nevar izveidot funkcionālu

indeksu kolekcijas kolonnai. Lai izveidotu kolekciju, definējot tabulu kolekciju izvēlas kā

atribūta tipu. Tabulā Vadītāji kolonna Darbinieki ir vienkārša kolekcija, kolonna Projekti ir

iekļauta kolekcija. Iekļauta kolekcija ir kolekcija, kas satur citu kolekciju.

Tabula Vaditaji tiek veidota ar sekojošu komandu:

CREATE TABLE Vaditaji

(

Vards VARCHAR(30),

Nodala VARCHAR(12),

Darbinieki SET(VARCHAR(30) NOT NULL),

Projekti LIST(ROW(nosaukums VARCHAR(15),

dalibnieki SET(VARCHAR(20)

NOT NULL) ) NOT NULL)

);

Datu ievade tabulā tiek veikta ar komandu INSERT INTO tabulas_nosaukums(Atribūti)

VALUES(Atribūtu vērtības).

Datu ievade tabulā Vaditaji:

INSERT INTO Vaditaji(Vards,Nodala,Darbinieki,Projekti)

VALUES

(23

‘Andis’,’Projektu’,”SET{ ‘Miezis’,’Skara’,’Liepa’ }”,

”LIST{ ROW(‘Zelta projekts’,SET(‘Miezis’,’Skara’)),

ROW(”Stadiona projekts”,SET(‘Miezis’,’Liepa’))}”

);

INSERT INTO Vaditaji(Vards,Nodala,Darbinieki,Projekti)

VALUES

(

‘Leons’,’Uzturesanas’,”SET{ ‘Abele’,’Oga’,’Sotnieks’ }”,

”LIST{ ROW(‘Baseina_projekts’,SET(‘Abele’,’Oga’)), ROW(”Jumta

projekts”,SET(‘Oga’,’Sotnieks’))}”

);

Datu izgūšana:

1) Vienkāršās kolekcijas izgūšana.

SELECT Nodala,Darbinieki FROM Vaditaji;

Nodala DarbiniekiProjektu Miezis,Skara,LiepaUzturesanas Abele,Oga,Sotnieks

2) Iekļautās kolekcijas izgūšana:

SELECT Projekti FROM Vaditaji WHERE Vards=’Andis’;

ProjektiLIST(ROW(Zelta projekts,SET(Miezis,Skara)))LIST(ROW(Stadiona projekts,SET(Miezis,Liepa)))

b) Nosauktais rindas tips.

Nosauktais rindas tips ir lauku grupa, kas tiek definēta zem viena nosaukuma. Nosauktais

rindas tips var saturēt citus nosauktos rindas tipus. Lauks atsaucas uz rindas tipa komponenti

un nevar tikt sajaukts ar kolonnu, kas tiek asociēta tikai ar tabulu. Lauki rindas tipā ir analogi

laukiem programmēšanas valodas C struktūrā vai klases locekļiem objektorientētajā

programmēšanā. Pēc nosauktā rindas tipa izveidošanas, šī tipa nosaukums attēlo unikālu

datubāzes datu tipu. Lai izveidotu nosaukto rindas tipu, ir nepieciešams noteikt šī tipa

nosaukumu, un šī tipa lauku nosaukumus. Nosauktā rindas tipa laukiem lietotājs vienmēr var

tieši piekļūt, atšķirībā no necaurredzamā(opaque) datu tipa, kurā komponenšu vērtības ir

iekapsulētas, un tām var piekļūt tikai caur funkcijām.

Nosauktā rindas tipa izveidošana:24

CREATE ROW TYPE Adrese_t

(

Pilseta VARCHAR(20),

Iela VAR CHAR(20),

Numurs INTEGER;

)

Nosauktais rindas tips Darbinieks_t sevī ietver iepriekš nodefinēto nosaukto rindas tipu

Adrese _t

Sarežģītāka rindas tipa izveidošana:

CREATE ROW TYPE Darbinieks_t

(

Uzvards VARCHAR(30),

Alga INTEGER,

Adrese adrese_t)

Tabulas ar nosaukto rindas tipu izveidošana:

CREATE TABLE Darbinieki OF TYPE Darbinieks_t;

Tabula Darbinieki.

Datu izgūšana:

Izgūt visus datus no tabulas.

SELECT * FROM Darbinieki;

Uzvards Alga AdreseMiezis 200 Liepaja,Parka,9Auzins 500 Ludza,Alejas,12Izgūt objekta daļu.

SELECT Adrese FROM Darbinieki;25

2.4 att. Tipa Adrese_t struktūra

2.5 att. Tipa Darbinieks_t struktūra

2.6 att. Tabula Darbinieki

AdreseLiepaja,Parka,9Ludza,Alejas,12Izgūt daļu no objekta.

SELECT Adrese.Pilseta FROM Darbinieki;

Pilseta.LiepajaLudzaTabulas ar nosauktā tipa kolonnu izveidošana:

CREATE TABLE Klienti( Nosaukums VARCHAR(30), adrese Adrese_t);

2.7 att Tabula klienti

c)Nenosauktais rindas tips.

Nenosauktais rindas tips ir lauku grupa, kas tiek izveidota ar rindas(row) konstruktoru.

Būtiska atšķirība starp nosaukto un nenosaukto rindas tipu ir tā ka nenosaukto rindas tipu

nevar piesaistīt tabulai. Nenosauktais rindas tips tiek lietots tikai lai definētu tabulas lauku vai

kolonnu. Nenosauktais rindas tips tiek identificēts tikai ar struktūru, bet nosauktais rindas tips

tiek identificēts ar nosaukumu. [15]

Tabulas ar nenosaukto rindas tipu izveidošanu:

CREATE TABLE Studenti

(

Vards VARCHAR(30),

Adrese ROW(iela VARCHAR (20),

numurs INTEGER,

Pilseta VARCHAR(20))

);

26

2.8 att Tabula Studenti

2.2.1.3. Tipu mantošana.

Mantošana ir process, kas atļauj tipam vai tabulai iegūt īpašības no cita tipa vai tabulas.

Tips vai tabula, kas manto īpašības tiek saukta par apakš tipu vai apakš tabulu. Mantošana

atļauj pieaugošu modifikāciju kas nozīmē ka tips vai tabula manto pamata īpašību kopu un

pievieno savas specifiskas īpašības. Informix dinamiskais serveris atļauj mantošanu

nosauktajam rindas tipam un tipu tabulai. Informix pieļauj tikai vienreizēju mantošanu, kas

nozīmē, ka katrai apakštabulai vai apakštipam ir tikai viena virstabula, vai virstips.

Tipu mantošana ir atļauta tikai nosauktajam rindas tipam. Mantošana grupē nosauktos

rindas tipus tipu hierarhijā, kurā katrs apakš tips manto attēlojumu(datu laukus) un

uzvedību( funkcijas, agregātus un operatorus) no virs tipa zem kura tas ir definēts. Tipu

hierarhijas priekšrocības ir datu modeļa modulāra attēlojuma veicināšana, nodrošina shēmas

komponenšu atkārtotu izmantošanu, nodrošina, ka datu lauki netiek atstāti ārpusē, atļauj tipam

mantot funkcijas, kas ir definētas citam datu tipam.

Tipa persona_t izveidošana.

CREATE ROW TYPE persona_t

(

vards VARCHAR(30) NOT NULL,

adrese VARCHAR(20),

Pilseta VARCHAR(20),

Dz_datums DATE

);

Tips darbinieks_t manto visus atribūtus no tipa persona_t, un satur individuālus atribūtus alga

un vaditajs.

Tipa darbinieks_t izveidošana:

CREATE ROW TYPE darbinieks_t

(27

2.9 att. Tipa persona_t struktūra

2.10 att. Tipa darbinieks_t struktūra

alga INTEGER,

vaditajs VARCHAR(30)

)

UNDER persona_t;

Tips pardosanas_atsk_t satur visus tipa darbinieks_t atribūtus un satur savus individuālus

atribūtus atskaites_num, reģions, komisija.

Tipa pardosanas_atsk_t izveidošana:

CREATE ROW TYPE pardosanas_atsk_t

(

atskaites_num INT8,

regions_num INTEGER,

komisija DECIMAL

)

UNDER darbinieks_t;

2.11 att. Tipa pardosanas_atsk_t struktūra

2.12 att. Tipu hierarhija

Tabulas mantošanu atbalsta tikai tās tabulas, kas ir definētas balstoties uz nosaukto rindas

tipu. Tabulas mantošana ir īpašība, kas atļauj tabulai mantot uzvedību(ierobežojumus,

glabāšanas opcijas, trigerus) no virstabulas tabulu hierarhijā. Tabulas mantošanas

priekšrocības ir datu modeļa modulāra attēlojuma veicināšana, shēmas komponenšu atkārtota

izmantošana, tabulu mantošana atļauj veidot vaicājumus, kuru darbības lauks var būt dažas

vai visas tabulas tabulu hierarhijā. Tabulu hierarhijā apakštabula automātiski manto

28

virstabulas ierobežojumu definīcijas, glabāšanas opcijas, visus trigerus, indeksus un piekļuves

metodes.

Tabulu hierarhijas izveidošana.

CREATE TABLE personas OF TYPE persona_t;

CREATE TABLE darbinieki OF TYPE darbinieks_t UNDER persona;

CREATE TABLE pardosana OF TYPE pardosanas_atsk_t UNDER darbinieks;

2.13 att. Tipu un tabulu hierarhija

29

2.3 DBVS DB2

2.3.1 Objekts.

Lai izveidotu strukturētu tipu, nepieciešams definēt tipa nosaukumu, atribūtu nosaukumus un

to tipus.

CREATE TYPE Adrese_t AS

(Iela VARCHAR(30),

Nummurs CHAR(15),

Pilseta VARCHAR(30))

MODE DB2SQL;

Izveidotais tips Adrese_t satur atribūtus Iela ar tipu VARCHAR(30, Nummurs ar tpu

CHAR(15), Pilseta ar tipu VARCHAR(30).

DB2 datubāzes serverī strukturēto datu tipu var izmantot cita strukturētā tipa definēšanai.Lai

izveidotu sarežģītāku strukturēto tipu, iepriekš izveidoto datu tipu, izvēlas kā tipu kādam no

tipa atribūtiem.

CREATE TYPE Persona_t AS

(Vards VARCHAR(20),

Vecums INT,

Adrese Adrese_t)

MODE DB2SQL;

Izveidotais strukturētais tips Persona_t satur atribūtus Vards ar tipuVARCHAR(20), vecums

ar tipu INT, adrese ar tipu Adrese_t, kas tika izveidots iepriekš.

2.3.2 Objektu tabula

Lietotāja izveidotos strukturētos datu tipus var izmantot, lai definētu jaunu tabulu. Jaunas

tabulas veidošana notiek ar komandu CREATE TABLE tabulas_nosaukums OF

tipa_nosaukums. Tabulas nosaukumam ir jābūt unikālam. Tipa nosaukumam ir jāatspoguļo

tips kurš ir iepriekš izveidots.

CREATE TABLE Personas OF Persona_t

(REF IS Oid USER GENERATED);

Izveidotā tabula Personas ir veidota pamatojoties uz tipu Persona_t. REF IS Oid USER

GENERATED nosaka ka objekta identifikators ir lietotāja izveidots.

30

2.14 att. Tipa Adrese_t struktūra

2.15 att. Tipa Persona_t struktūra

Datu ievadīšana objektu tabulā.

Datu ievadīšana tabulā notiek ar INSERT INTO tabulas_nosaukums(Atribūti)

VALUES(tipa_nosaukums(Oid),Atribūti)

INSERT INTO Personas(Oid,Vards,Vecums,Adrese)

VALUES

(Persona_t(‘a’),’Juris’,20,Adrese_t( )..Iela(‘Sporta’)..Numurs(10)..Pilseta(‘Limbazi’))

INSERT INTO Personas(Oid,Vards,Vecums,Adrese)

VALUES

(Persona_t(‘b’),’Marija’,30,Adrese_t( )..Iela(‘Rigas’)..Numurs(31)..Pilseta(‘Aluksne’))

Datu izgūšana.

1) Tiek izgūti visi dati no tabulas.SELECT * FROM Personas

Oid Vards Vecums Adrese

a Juris 20 Sporta,10,Limbazi

b Marija 30 Rigas,31,Aluksne

2) Tiek izgūta viena rinda.SELECT *

FROM Personas

WHERE Vards=’Juris’;

Oid Vards Vecums Adrese

a Juris 20 Sporta,10,Limbazi

3) Tiek izgūts viss objekts.SELECT Adrese

FROM Personas

31

2.16 att. Tabulas Personas struktūra

WHERE Vards=’Juris’;

A

d

r

e

s

e

S

p

o

rt

a,

1

0,

L

i

m

b

a

zi

4) Tiek izgūta daļa no objekta.SELECT Adrese..Iela

FROM Personas

WHERE Vards=’Juris’;

Iela

Sporta

2.3.3 Tabula ar objektu kolonnu.

Objektu var izmantot arī kā kolonnas datu tipu. Lai objektu izmantotu kā kolonnas tipu, no

sākuma jāizveido objekta tips.

CREATE TYPE Adrese_t AS

(Iela VARCHAR(30),

32

Nummurs CHAR(15),

Pilseta VARCHAR(30))

MODE DB2SQL;

Veidojot tabulu ar objektu kolonnu, kolonnai, kura būs objekts par tipu tiek izvēlēts iepriekš

definēts strukturēts tips. Tabulā Rekviziti objektu kolonna būs Adrese kuras tips būs iepriekš

definētais tips Adrese_t.

CREATE TABLE Rekviziti

(SutijumaNumurs INT,

Adrese Adrese_t)

Ad re s e _ t

Ie la N um u rs P ilse ta

Ad re s e _ t

Ie la N um u rs P ilse ta

SutijumaNumurs

SutijumaNumurs

Datu ievadīšana tabulā ar objektu kolonnu.

INSERT INTO Rekviziti (SutijumaNumurs,Adrese)

VALUES

(1,Adrese_t( )..Iela('Parka')..Nummurs('5')..Pilseta('Ventspil

s'));

INSERT INTO Rekviziti (SutijumaNumurs,Adrese)

VALUES (2,

Adrese_t( )..Iela('Gildes')..Nummurs('8')..Pilseta('Liepaja'))

;

Datu izgūšana.

1) Izgūti visi dati no tabulasSELECT *

FROM Rekviziti;

SutijumaNumurs Adrese

1 Parka,5,Ventspils

2 Gildes,8,Liepaja

33

2.17 att. Tipa Adrese_t struktūra

2.18 att Tabulas Rekviziti struktūra

2) Izgūts viss objekts.SELECT Adrese

FROM Rekviziti;

Adrese

Parka,5,Ventspils

Gildes,8,Liepaja

3) Izgūta daļa no objekta.SELECT Adrese..Pilseta

FROM Rekviziti;

Pilseta

Ventspils

Liepaja

34

2.3.4 Tipu hierarhija.

DB2 datubāzes serveris atbalsta tipu mantošanu. Tips manto visus atribūtus no virstipa, un

pievieno vēl savus individuālos atribūtus.

Tiek izveidots tips Darbinieks_t. Tips Darbinieks_t tiks izmantots kā pamata tips, no kura citi

tipi mantos savus atribūtus.

CREATE TYPE Darbinieks_t AS (

ID INTEGER,

VARDS varchar(12),

UZVARDS varchar(12),

NODALAS_ID char(4),

ALGA decimal(7,2),

ADRESE address_t)

REF USING INTEGER

MODE DB2SQL;

Tips Pardevejs_t tiek izveidots mantojot visus atribūtus no tipa Darbinieks_t un pievienojot

jaunu atribūtu PIEMAKSA.

CREATE TYPE Pardevejs_t UNDER Darbinieks as (

Piemaksa decimal(7,2))

mode db2sql;

2.20 att. Tipa Pardevejs_t struktūra

Tips Inzenieris_t tiek izveidots mantojot visus atribūtus no tipa Darbinieks_t un pievienojot

jaunu atribūtu PAKAPE.

CREATE TYPE Inzenieris_t under Darbinieks as (

Pakape varchar(12))

mode db2sql;

35

2.19 att Tipa Darbinieks_t struktūra

2.21 att. Tipa Inzenieris_t struktūra

Tabulas Darbinieki izveidošana:

Tabulas Darbinieki tips ir iepriekš izveidotais tips Darbinieks_t

CREATE TABLE Darbinieki of Darbinieks_t

(ref is oid user generated)

Tabulas Pardeveji izveidošana:

Tabulas Pardeveji tips ir iepriekš izveidotais datu tips Pardeveji_t.

CREATE TABLE Pardeveji of Pardevejs_t under Darbinieki inherit

select privileges

Tabulas Inzenieri izveidošana:

Tabulas Inzenieri tips ir iepriekš izveidotais tips Inzenieris_t

CREATE TABLE Inzenieri of Inzenieris_t under Darbinieki

inherit select privileges

Datu ievade.

INSERT INTO Inzenieri (oid, id, vards, uzvards, nodalas_id,

alga,

pakape, adrese) values (Inzenieris_t(1), 22, 'Juris',

'Liepa',

'Z004', 650.00, ‘vecakais’, adrese () ..iela(‘Liepu’)

..numurs(8) ..pilseta('Priekule'));

INSERT INTO Pardeveji (oid, id, vards,uzvards, nodalas_id,

alga, Piemaksa, adrese)

values (Pardevejs_t(2), 33, 'Laima', 'Mieze', 'C012', 490.00,

150.00,

address_t() ..iela('Meza') ..numurs(8) ..pilseta('Ogre'))

Datu izgūšana.

1)SELECT *

FROM Darbinieki;

oid id vards uzvards nodalas_id alga adrese

1 22 Juris Liepa Z004 650.00 Liepu,8,Priekule36

2 33 Laima Mieze C012 490.00 Meza,8,Ogre

2)SELECT*

FROM Inzenieri

oid id vards uzvards nodalas_i

d

alga pakape adrese

1 22 Juris Liepa Z004 650.00 vecakais Liepu,8,Priekule

3)SELECT*

FROM Pardeveji

oid id vards uzvards nodalas_id alga Piemaksa adrese

2 33 Laima Mieze C012 490.00 150.00 Meza,8,Ogre

2.3.5 Objektu skats.

Vispirms tiek izveidots tips Persona_t:

CREATE TYPE Persona_t AS

(Vards VARCHAR(20),

Vecums INT,

Adrese Adrese_t)

INSTANTIABLE

REF USING VARCHAR(13) FOR BIT DATA

MODE DB2SQL;

Tabula Personas ir objektu tabula ar tipu Persona_t:

CREATE TABLE Personas OF Persona_t

(REF IS Oid USER GENERATED);

Objektu skatu veido lietojot priekšrakstu CREATE VIEW.

CREATE TYPE SK_Personas AS (Vards VARCHAR(20))

MODE DB2SQL;

CREATE VIEW SK_Personas OF SK_Personas MODE DB2SQL

(REF IS ObjektaID USER GENERATED)

AS SELECT SK_Personas(VARCHAR(Oid)), Vards FROM Personas;

OF teikums CREATE VIEW priekšrakstā nosaka skata pamata kolonnas. Piemērā, skata

kolonnas tiks bāzētas uz strukturēto tipu SK_PERSONAS. Skata kolonnai ObjektaID ir tips

37

REF(SK_Personas). Tādēļ, ka nevar tieši veidot REF(SK_Personas) no REF(Personas),

vispirms jāizveido Objekta identifikatora kolonna no tabulas Personas datu tipā VARCHAR,

un tad no datu tipa VARCHAR jāveido REF(SK_Personas).

USER GENERATED teikums nosaka, ka Objekta identifikatora kolonnu aizpildīs lietotājs

kad pievienos jaunu rindu. Objekta identifikatoru nevar izmainīt.

Skata ķermenis, kurš seko aiz atslēgvārda AS, ir SELECT priekšraksts, kas nosaka skata

saturu. Kolonnu tipi, kas tiek atgriezti ar šo SELECT priekšrakstu jābūt savienojamiem ar

kolonnu tipiem objektu skatā, ieskaitot objekta identifikatora kolonnu [5].

2.4 Datu bāzu sistēma PostgreSQL

2.4.1 PostgreSQL DBVS

PostgreSQL ir atklātā pirmkoda objektu relāciju datu bāzu vadības sistēma(DBVS).

PostgreSQL bez tā, ka tā ir relāciju DBVS ir arī objektu relāciju DBVS, kas nozīmē, ka tai ir

dažas objektu orientētas iezīmes. Piemēram, mantošana, iespēja veidot saliktus datu tipus ar

speciālām funkcijām, kas apstrādā šos datu tipus. Pašos pamatos PostgreSQL ir relāciju datu

bāzu vadības sistēma. PostgreSQL piedāvā vairākas iezīmes, kas nav sastopamas pat labi

zināmās komerciālās relāciju un relāciju objektu datu bāzu vadības sistēmās. Tiek atbalstīta

transakciju veidošana, trigeru veidošana, glabājamās procedūras, ierobežojumi, ārējās

atslēgas. PostgreSQL nodrošina dažādu programmēšanas valodu atbalstu lietotāja definēto

funkciju veidošanai. Tabulas struktūras mantošanas atbalsts, kas dažādās situācijās var būt ļoti

noderīgs. PostgreSQL piedāvā iebūvētos datu tipus tādus kā IP adrese, ģeometriskie datu tipi.

Masīvus datu bāzu vadības sistēmā PostgreSQL var izmantot lai nodefinētu laukus. Iespēja

definēt agregātu funkcijas, kas darbojas ar ierakstu kopām. Tiek piedāvāts virkņu koncepts.

PostgreSQL atbalsta dažādas operētājsistēmas (Linux, Windows, Unix, Mac).

2.4.2 Saliktie datu tipi

Saliktie datu tipi attēlo rindas vai ierakstu struktūru, kas patiesībā ir saraksts ar atribūtiem un

to tipiem. PostgreSQL piedāvā iebūvētus saliktos datu tipus, tādus kā IP adrese un

ģeometriskos datu tipus. PostgreSQL atļauj saliktos datu tipus lietot tāpat kā iebūvētos datu

tipus. Piemēram, definēt salikto tipu, kā kolonnas tipu.

38

2.4.2.1 Tabula ar objektu kolonnu

Lai datubāzē izveidotu objektu kolonnu vispirms tiek veidots saliktais datu tips, un veidojot

tabulu ar objektu kolonnu iepriekš izveidotais datu tips tiek izvēlēts kā kolonnas datu tips.

No sākuma tiek izveidots saliktais datu tips Prece_t , kas satur atribūtus nosaukums,

piegadataja_id un cena.

CREATE TYPE Prece_t AS (

nosaukums text,

piegadataja_id integer,

Cena numeric

);

Iepriekš izveidotais datu tips Prece_t tiek izmantots kā kolonnas tips tabulai Preces, attiecīgi

kā atribūta Prece tips tiek izvēlēts tips Prece_t. Tabulā Preces ir divi atribūti Prece un skaits.

CREATE TABLE Preces (

Prece Prece_t,

skaits integer

);

2.23 att Tabula Preces

Datu ievade tabulā Preces tiek veikta ar komandu INSERT INTO Preces

VALUES(ROW(...)); Tabulā Preces tiek ievietoti 4 ieraksti.

INSERT INTO Preces VALUES (ROW(’Kresls’, 42, 200), 200);

INSERT INTO Preces VALUES (ROW(’Skapis’, 43, 300), 34);

INSERT INTO Preces VALUES (ROW(’Durvis’, 42, 10), 50);

INSERT INTO Preces VALUES (ROW(’Lampa’, 43, 10), 240);

Datu izgūšana:

1) Izgūt visus datus no tabulas Preces.

SELECT * FROM Preces;

39

2.22 att. Tipa Prece_t struktūra

Prece SkaitsKresls, 42, 200 200Skapis, 43, 300 34Durvis, 42, 10 50Lampa, 43, 10 240

2) Izgūt tikai objekta daļu.

SELECT (Prece) FROM Preces.

PreceKresls, 42, 200Skapis, 43, 300Durvis, 42, 10Lampa, 43, 10

3) Izgūt daļu no objekta.SELECT (Prece).Nosaukums

FROM Preces;

PreceKreslsSkapisDurvisLampa

2.4.2.2 Ģeometriskie datu tipi

Datu bāzu vadības sistēmas PostgreSQL unikāla īpašība ir tās iebūvētie ģeometriskie datu tipi,

kas ļauj glabāt un apstrādāt tādus telpiskus objektus kā punkts, taisne, daudzstūris, riņķis.

2.1 Tabula

Ģeometriskie datu tipi

Nosaukums Izmērs Attēlojums Aprakstspoint 16 baiti Punkts plaknē (x,y)line 32 baiti Neierobežota līnija ((x1,y1),(x2,y2))lseg 32 baiti Ierobežots līnijas

segments((x1,y1),(x2,y2))

box 32 baiti Taisnstūra logs ((x1,y1),(x2,y2))path 16+16n baiti Slēgta daļa ((x1,y1),...)path 16+16n baiti Atvērta daļa [(x1,y1),...]polygon 40+16n baiti Daudzstūris ((x1,y1),...)circle 24 baiti Riņķis <(x,y),r> (centrs un

rādiuss)

Ģeometriskie datu tipi:

Punkts(point).

40

Punkts ir pamata divdimensiju ģeometriskais tips. Punkta vērtību piešķiršanai tiek

lietota sekojoša sintakse:

( x , y )

Kur x un y ir atbilstošās koordinātes kā peldošā punkta skaitlis.

Līnijas segments(lseg).Līnijas segments tiek attēlots kā punktu pāris. Lseg vērtības tiek attēlotas lietojot

sekojošu sintaksi:

( ( x1 , y1 ) , ( x2 , y2 ) )

Kur ( x1 , y1 ) un ( x2 , y2 ) ir segmenta beigu punkti.

Logs(box).Logi tiek attēloti kā punktu pāri, kas ir pretējie loga punkti. Loga vērtības tiek

attēlotas lietojot sekojošu sintaksi:

( ( x1 , y1 ) , ( x2 , y2 ) )

Kur ( x1 , y1 ) un ( x2 , y2 ) ir divi pretējie loga stūri.

Daļa(path).Daļas tiek attēlotas kā saraksts ar slēgtiem punktiem. Daļas var būt atvērtas, kur

pirmie un pēdējie punkti sarakstā nav slēgti, un daļas var būt slēgtas kur pirmie un

pēdējie punkti ir slēgti.

( ( x1 , y1 ) ,..., ( xn , yn ) )

[ ( x1 , y1 ) ,..., ( xn , yn ) ]

Daudzstūri(polygon).Daudzstūri tiek attēloti kā punktu saraksts(daudzstūru virsotnes).

((x1,y1),...,(xn,yn))

Riņķis(Circle)Riņķi tiek attēloti kā centra punkts un rādiuss.

<(x,y),r>

Kur (x,y) ir centra punkta koordinātes un r ir riņķa rādiuss

PostgreSQL piedāvā funkcijas, kas apstrādā šos telpiskos datu tipus, piemēram, aprēķina

objekta laukumu, diametru, objekta centru.

Tabula 2.2

Ģeometrisko tipu funkcijasFunkcija Atgriežamais tips Apraksts Piemērs

area(object) double precision objekta laukumsarea(box '((0,0),(1,1))')

center(bject) point objekta centrs center(box '((0,0),

41

(1,2))')

diameter(circle) double precision riņķa diametrisdiameter(circle '((0,0),2.0)')

height(box) double precision taisnstūra augstumsheight(box '((0,0),(1,1))')

length(object) double precision objekta garumslength(path '((-1,0),(1,0))')

npoints(path/polygon) int punktu skaitsnpoints(path '[(0,0),(1,1),(2,0)]')

radius(circle) double precision riņķa radiussradius(circle '((0,0),2.0)')

width(box) double precision taisnstūra garumswidth(box '((0,0),(1,1))')

2.4.2.3 Masīvi.

PostgreSQL ļauj tabulas kolonnas definēt kā mainīga garuma daudz dimensiju masīvus.

Masīvi var tikt veidoti no iebūvētiem vai lietotāja izveidotiem pamata datu tipiem. Masīvus

nevar veidot no saliktiem datu tipiem. Masīvs tiek veidots nosaucot datu tipu un

kvadrātiekavās ierakstot masīva izmēru: DATU_TIPS[ ][ ]. Kvadrātiekavu pāru skaits nosaka

masīva dimensiju skaitu. Ja masīva izmērs ir noteikts tad kvadrātiekavās raksta masīva

izmēru, ja masīva izmērs nav noteikts tad kvadrātiekavas atstāj tukšas.

Masīvu kā tabulas kolonnu veido norādot atribūta tipu masīvu, izvēloties masīva tipu un

dimensiju skaitu. Tabula mas_tabula satur tikai masīva kolonnu ar nosaukumu masivs.

CREATE TABLE mas_tabula(masivs integer[3][3]);

Tabula mas_tabula satur masīvu ar nosaukumu masivs. Masīvam ir tips integer, divas

dimensijas un masīva izmērs ir 3.

Datu ierakstīšana masīvā:

INSERT INTO mas_tabula

VALUES(masivs{{1,2,3},{4,5,6},{7,8,9}});

Masīvu operatori.

Masīva operatori ļauj salīdzināt masīvus, savienot masīvu ar masīvu un savienot masīvu ar

elementu.

Tabula 2.3

Masīvu apstrādes operatori

Operators

Apraksts Piemērs Rezultāts

= vienāds MASIVS[1.1,2.1,3.1]::int[] = patiess42

MASIVS[1,2,3]<> Nav vienāds MASIVS[1,2,3] <>

MASIVS[1,2,4]patiess

< Mazāks MASIVS[1,2,3] < MASIVS[1,2,4]

patiess

> lielāks MASIVS[1,4,3] >MASIVS[1,2,4]

patiess

<= Mazāks vai vienāds

MASIVS[1,2,3] <= MASIVS[1,2,3]

patiess

>= Lielāks vai vienāds MASIVS[1,4,3] >= MASIVS[1,4,3]

patiess

@> satur MASIVS[1,4,3] @> MASIVS[3,1]

patiess

@< ietilpst MASIVS[2,7] <@ MASIVS[1,7,4,2,6]

patiess

&& Daļēji nosedz MASIVS[1,4,3] && MASIVS[2,1]

patiess

|| Masīvu savienošana

MASIVS[1,2,3] || MASIVS[4,5,6]

{1,2,3,4,5,6}

|| Elementa un masīva savienošana

3 || MASIVS[4,5,6] {3,4,5,6}

Tabula 2.4

Masīvu funkcijas.

Masīvu apstrādes funkcijas nodrošina tādas darbības ar masīvu kā elementu pievienošana,

masīvu savienošana un citas.

Funkcija Atgrie

žamai

s tips

Apraksts Piemērs Rezultāts

array_append(masivs,

elements)

masivs Pievieno

elementu masīva

beigās

array_append(MASIVS[1,

2], 3)

{1,2,3}

array_cat(masivs,

masivs)

masivs Savieno divus

masīvus

array_cat(ARRAY[1,2,3],

ARRAY[4,5])

{1,2,3,4,5

}

array_dims(masivs) text Atgriež tekstu

kas raksturo

masīva

dimensijas

array_dims(ARRAY[[1,2,

3], [4,5,6]])

[1:2][1:3]

array_lower(anyarray, int Atgriež apakšējo array_lower('[0:2]={1,2,3} 0

43

int) robežu

pieprasītajai

masīva

dimensijai

'::int[], 1)

array_prepend(eleme

nts, masivs)

masīvs Pievieno

elementu masīva

sākumā

array_prepend(1,

ARRAY[2,3])

{1,2,3}

array_to_string(masiv

s, text)

text Savieno masīva

elementus

lietojot doto

atdalītāju

array_to_string(ARRAY[1

, 2, 3], '~^~')

1~^~2~^~

3

array_upper(anyarray,

int)

int Atgriež

maksimālo

masīva elementu

norādītajā

dimensijā

array_upper(ARRAY[1,2,

3,4], 1)

4

string_to_array(text,

text)

Text[] Sadala virkni

masīva

elementos

lietojot norādīto

atdalītāju

string_to_array('xx~^~yy~

^~zz', '~^~')

{xx,yy,zz}

2.4.3 Tabulas struktūras mantošana.

Tabulas mantošana ir īpatnība, kas nav atrodama parastās relāciju datu bāzu vadības

sistēmās, bet ir viena no raksturīgām iezīmēm objektu relāciju datu bāzu vadības sistēmās.

Tabulas mantošana nodrošina objektorientētu pieeju un relāciju datubāzes vienkāršību un

ātrumu. Tabula var mantot atribūtus no vienas tabulas vai vairākām tabulām. Rezultātā

pēcteču tabulām ir tie paši atribūti, kas bāzu tabulām un pievienoti savi personīgie atribūti.

Veidojot vaicājumu bāzu tabulai ir iespējams izgūt ierakstus tikai no bāzes tabulas vai arī no

atvasinātas tabulas vai tabulām. Atvasinātu tabulu ir iespējams veidot no vairākām bāzu

tabulām un otrādi, no vienas bāzu tabulas ir iespējams izveidot vairākas atvasinātās.

Atvasinātās tabulas izveidošanas sintakse ir sekojoša:

CREATE TABLE tabulas_nosaukums(

44

tabulas_definīcija)INHERITS ( bāzes_tabula [, ... ] )

CREATE TABLE video( video_id CHARACTER(8) PRIMARY KEY, nosaukums VARCHAR(80), ilgums INTERVAL);Tabulai DVD atribūti ir tādi paši kā bāzes tabulai VIDEO plus atribūts skanas_celini ar datu

tipu VARCHAR[], kurā glabāsies pieejami skaņu celiņi.

CREATE TABLE dvd(

skanas_celini VARCHAR[]

) INHERITS (video);

INHERITS nosaka to, ka tabula DVD manto no tabulas VIDEO.

INSERT INTO dvd VALUES( 'AAA-750', -- video_id 'Spriditis, -- nosaukums '121 minutes', -- ilgums '{Latviesu,Anglu}' -- skanas_celini);

SELECT * FROM dvd;

video_id | nosaukums | ilgums | skanas_celini---------+-----------+----------+------------------- AAA-750 | Spriditis | 02:01:00 | {Latviesu,Anglu} SELECT * FROM video;

Rezultātāvideo_id | nosaukums | ilgums ---------+-----------+---------- AAA-750 | Spriditis | 02:01:00

DVD ir video. Kad ir izveidots SELECT tipa vaicājums tabulai VIDEO, rezultātā ir tie

atribūti, kurus satur tabula VIDEO. Kad SELECT tipa vaicājums attiecas uz DVD tabulu,

rezultātā ir atribūti, kurus satur tabula DVD.

Lai izgūtu ierakstus tikai no bāzu tabulas, neiekļaujot ierakstus no pēcteču tabulām, lieto

ONLY. Lai izgūtu datus tikai no VIDEO tabulas, neiekļaujot datus no DVD tabulas,

jāizmanto vaicājums:SELECT * FROM ONLY video;

45

Mantošanas realizācijā atvasinātās tabulas nemanto no bāzu tabulas pieeju tiesības. Lai

lietotājs varētu piekļūt bāzes tabulai, viņam jābūt tiesībām uz visām atvasinātām tabulām vai

jālieto ONLY notāciju. Atvasinātās tabulas nemanto indeksus (arī UNIQUE ierobežojumu) un

FOREIGN KEY ierobežojumu. Ja bāzes tabulai ir nodefinēti trigeri, tie arī netiek mantoti

pēcteču tabulām [16].

46

3. Relāciju – Objektu DB sistēmu izmantošana IS projektēšanā

3.1 DBS projektēšana.Tiek lietotas dažādas datu bāzes projektēšanas tehnoloģijas. Tās cita no citas atšķiras ar

dažādiem gala lietotāju priekšstatu veidiem par projektējamo informācijas sistēmu. Tiek

meklēts priekšstata variants, kurš ir vislabāk saprotams, lai lietotājs varētu sniegt visvairāk

informācijas par savām vēlmēm viņam vispiemērotākā formā.

Sākotnēji izstrādājamo informācijas sistēmu apskatīja kā “melno kasti”, kurai ir zināmi

tikai ieejas un izejas dati (tātad tos bija jāuzzina no lietotāja). Izmantojot šo informāciju,

Džeksons izstrādāja vienu no pirmajām formalizētajām datu bāzes projektēšanas metodēm.

Turpinājumā datu bāzes projektēšanas speciālistu domas dalījās:

1) vieni uzskatīja, ka lietderīgi noskaidrot projektējamās sistēmas darbības

pamatfunkcijas un tajās figurējošos datus (šiem mērķiem tika izveidota, piemēram,

datu plūsmas diagramma);

2) otri, lietderīgi veidot visu izmantojamo datu savstarpējās saistības modeli (šim

mērķim tika izstrādāta, piemēram, realitāšu-saišu diagramma).

Attīstoties objektorientētai programmēšanai, tika radītas arī objektu datu bāzes. Līdz ar to

veidojās uzskats, ka datus lietderīgi analizēt objektu formā, papildus apskatot ar objektiem

veicamās darbības (metodes). Tika izstrādātas tādas informācijas sistēmas modelēšanas

metode kā UML valoda (Unified Modeling Language). UML valodas modelēšanas tehnika

ietvēra sevī vairākas diagrammas, bet datu bāzes projektēšanai nozīmīgākā bija klašu

diagramma.

Datu bāzes sistēmas projektēšanas pamatdarbību secība var atšķirties, bet tai jāiekļauj sevī

tādus punktus kā problēmvides analīze un modelēšana, prasību iegūšana, datu diagrammu

izveidošana, sākotnējo datu struktūru veidošana un to kvalitātes pārbaude, datu bāzes

struktūrās definēšana (4.1. att.).

47

4.1 att. Datu bāzes sistēmas projektēšanas pamatdarbību secība

Veidojot datu bāzi, dati tiek apskatīti un analizēti trīs līmeņos(4.2 att):

1) konceptuālais līmenis – lietotājs un datu bāzes izstrādātājs apskata problēmvides

datus, atlasa nepieciešamos un nosaka datu savstarpējas saites. Līmeņa rezultāts ir

pilnīgi neatkarīgs no datu bāzes realizācijas un tā var būt realitāšu-saišu diagramma,

UML klašu diagramma vai arī kāds cits modelis;

2) loģiskais līmenis – datu bāzes projektētājs veido datu loģisko modeli noteiktām datu

bāzes sistēmas tipam, piemēram, relāciju, objektu vai relāciju-objektu;

3) fiziskais līmenis – datu bāzes projektētājs realizē datu loģisko modeli konkrētai datu

bāzes vadības sistēmai, iegūstot datu glabāšanas fizisko struktūru definējumus.

48

4.2 att Datu bāzes veidošana (trīs līmeņi

3.2 Pamata transformācijas.

3.2.1 Klases transformācija

Klase no konceptuālā līmeņa tiek transformēta uz saliktu objektu. Tālāk šo objektu var

izmantot lai definētu objektu tabulu vai izmantot kā kolonnu tabulā. Piemērā(Attēls 1) tiek

transformēta klase darbinieks ar relāciju objektu pieeju uz salikto tipu ar nosaukumu

Darbinieks.

4.3 att Klases transformācija

49

3.2.2 Klases atribūta transformācija

Klases atribūts transformējot tiek transformēts kā saliktā tipa atribūts. Definējot salikto tipu,

pie tipa definīcijas tiek noteikti atribūti, un to tipi. Piemērā(Attēls 2) klasei Darbinieks tiek

definēts atribūts Uzvards ar tipu CHAR(40).

4.4 att Klases atribūta transformācija

3.2.3 Atslēgas atribūta transformācija

Definējot objekta tipu, tā atribūtiem nevar noteikt ierobežojumus. Lai kādam no saliktā tipa

atribūtiem noteiktu ierobežojumus, šie ierobežojumi ir jānodefinē veidojot tabulu.

Piemērā(Attēls 3), klases Darbinieks atslēgas atribūts ir numurs. Atribūts tiek definēts

veidojot salikto tipu darbinieks, bet ierobežojums, kas nosaka, ka šis atribūts būs atslēgas

atribūts tiek noteikts veidojot tabulu darbinieki.

4.5 att Atslēgas atribūta transformācija

50

3.2.4 Atribūta obligātuma transformācija

Līdzīgi kā transformējot atslēgas atribūtu, arī atribūta obligātumu nevar noteikt definējot

salikto tipu, tas jānodefinē veidojot tabulu. Piemērā(Attēls 4), klasei Darbinieks ir obligāts

atribūts vards. Atribūts un tā tips tiek nodefinēts veidojot objektu, bet ierobežojums, kurš

nosaka, ka šis atribūts būs obligāts tiek noteikts veidojot tabulu.

4.6 att. Atribūta obligātuma transformācija

3.2.5 Klases metodes transformācija

Lai transformētu klases metodi, veidojot salikto tipu tiek ierakstīts tikai šīs metodes

nosaukums. Pati metode tiek veidota, veidojot tipa ķermeni. Piemērā(Attēls 5), klasei

Darbinieks ir metode getUzvards. Veidojot salikto tipu tiek nosaukta metode ar komandu

MEMBER PROCEDURE getUzvards. Tālāk veidojot tipa ķermeni tiek veidota pati metode.

51

4.7 att Klases metodes transformācija

3.2.6 Saites viens pret daudziem transformācija.

Saiti viens pret daudziem var transformēt uz tabulu ar iekļautu kolekciju, kur realitāte daudzi

tiek realizēta kā iekļautā kolekcija. Relāciju objektu variantā lietojot Oracle sintaksi tiek

veidota tabula ar iekļautu kolekciju. Piemērā(Attēls 6), darbinieks var strādāt maksimāli vienā

firmā. Firmā var būt neviens darbinieks, viens darbinieks vai daudzi darbinieki. Vispirms

izveido objekta tipu T_Darbinieks, pēc tam izveido kolekcijas tipu Tabula_Darbinieks.

Veidojot tabulu Firma tipu Tabula_darbinieks, kas ir kolekcija izvēlas kā kolonnas tipu.

4.8 att Saites viens pret daudziem transformācija

52

Piemērā(Attēls 7), katra prece ir piesaistīta tieši vienai partijai, partijā var būt viena vai

vairākas preces. Šī situācija no iepriekšējās atšķiras ar to, ka šajā situācijā kolekcija nedrīkst

būt tukša. Lai to realizētu tabulas definīcijā iekļauj ierobežojumu NOT NULL. Realitāte prece

tiek transformēta kā iekļauta kolekcija. Definējot tabulu partija tiek iekļauts ierobežojums, ka

šī iekļautā kolekcija nedrīkst būt tukša.

4.9 att Saites viens pret daudziem transformācija

Piemērā(Attēls 8), katrs departaments publicē vienu vai vairākas atskaites. Nav obligāti, ka

kāda konkrēta atskaite ir departamenta publicēta. Šī situācija no iepriekšējām atšķiras ar to, ka

šeit atskaite var tikt glabāta arī atsevišķi bez piesaistes departamentam, un tādēļ nevar veidot

tabulu ar iekļauto kolekciju līdzīgi kā iepriekšējos piemēros. Lai realizētu to, ka atskaite tiek

glabāta atsevišķi. atskaitei veido salikto tipu, un objektu tabulu pamatojoties uz šo tipu. Otru

tabulu departamenti veido kā objektu tabulu ar iekļauto kolekciju, kur kolekcija satur norādes

uz atskaitēm. Šādā realizācijā tiek nodrošināts, ka atskaite var būt piesaistīta kādam

departamentam, tādā gadījumā uz atskaiti būs norāde no departamentu tabulas, un atskaite var

nebūt piesaistīta departamentam tādā gadījumā norādes nebūs.

53

4.10 att Saites viens pret daudziem transformācija

3.2.7 Saites viens pret vienu transformācija

Saite viens pret vienu tiek transformēta uz divām objektu tabulām. Piemērā(Attēls 9) katrai

atskaitei ir viena abreviatūra un katra abreviatūra reprezentē tieši vienu atskaiti. Tiek veidoti

divi objektu tipi ar norādēm vienam uz otru, jo katrai atskaitei ir jābūt abreviatūrai un katrai

abreviatūrai jābūt atskaitei, un šādām norādēm ir obligāti jābūt. Tā, kā definējot objekta tipus

nevar nodefinēt tipa atribūtu ierobežojumus, tad ierobežojumus definē, definējot tabulu,

ierobežojums NOT NULL nozīmē, ka atsauce uz otru tipu nedrīkst būt tukša.

54

4.11 att Saites viens pret vienu transformācija

Piemērā(Attēls 10) jābūt vadītājam priekš katra departamenta, bet darbinieks var vadīt vienu

departamentu, vai nevienu departamentu. Šis piemērs no iepriekšējā piemēra atšķiras ar to, ka

šajā piemērā viena no saitēm ir neobligāta.

4.12 attēls Saites viens pret vienu transformācija

55

Piemērā(Attēls 11), daži no datoriem ir piesaistīti inženieriem, bet ne obligāti visiem

inženieriem ir dators, tas nozīmē, ka šoreiz abas saites ir neobligātas un obligātuma

nosacījums nav nepieciešams.

4.13 att. Saites viens pret vienu transformācija

3.2.8 Saites daudzi pret daudziem transformācija

Saiti daudzi pret daudziem var realizēt kā divas objektu tabulas ar iekļautu kolekciju, vai

divas tabulas ar iekļautu kolekciju. Piemērā(Attēls 12), katrs darbinieks var strādāt nevienā,

vienā vai vairākās firmās, bet katrā firmā ir neviens, viens, vai vairāki darbinieki. Tiek veidoti

divi objekti ar iekļautu kolekciju. Kolekcijas satur norādes uz otru objektu.

4.14 attēls Saites daudzi pret daudziem transformācija

56

3.2.9 Ternārās un n-ārās saites transformācija

Ternāro saiti transformē kā trīs objektu tabulas ar norādēm savā starpā. Piemērā(Attēls 13),

darbinieks izmanto tieši vienu datoru priekš katra no projektiem. Katrs dators projektā tiek

piesaistīts darbiniekam. Darbinieks var strādāt vairākos projektos, katrā no tām izmantojot

citu datoru. Tiek veidoti trīs objekta tipi, kuros katrā ir norādes uz pārējiem diviem objekta

tipiem.

4.15 attēls Ternārās saites transformācija

Piemērā(Attēls 14), katrs projektam piesaistītais darbinieks strādā šīm projektam paredzētājā

vietā (izvietojums), bet var strādāt arī kādā citā projektā, atbilstoši citā vietā. Jebkurā no

izvietojumiem var strādāt vairāki darbinieki. Tipā darbinieks ir norāde uz tipu izvietojums, un

uz tipu projekts. Tipā Izvietojums ir kolekcija ats_uz_darb kas satur norādes uz tipu

darbinieks, un norāde uz tipu projekts. Tipā projekts ir kolekcija ar norādēm uz tipu

darbinieks, un norāde uz tipu izvietojums.

57

4.16 attēls Ternārās saites transformācija

Piemērā(Attēls 15), katram no inženieriem, strādājot noteiktajā projektā, ir tieši viens vadītājs,

bet projektam var būt vairāki vadītāji, bet inženieriem var būt vairāki vadītāji un vairāki

projekti. Vadītājs var pārvaldīt vairākus projektus.

4.17 att. Ternārās saites transformācija

58

Piemērā(Attēls 16), viens darbinieks piedalās vairākos projektos, un viņam ir vairākas

iemaņas, vienā projektā ir vairāki darbinieki un tiek izmantotas vairākas iemaņas.

4.18 att. Ternārās saites transformācija

3.2.10 Vispārinājuma saites transformācija

Piemērā(Attēls 17), Cilvēks var būt pircējs, vai darbinieks, vai abi kopā, vai neviens no tiem.

4.19 att. Vispārinājuma saites transformācija

59

PostrgreSQL realicācijā tiek izveidota pamata tabula Cilveks un divas tabulas, kas manto

atribūtus no pamata tabulas un pievieno savu individuālo atribūtu.

3.2.11 Saites ar asociācijas klasi transformācija

Piemērā(Attēls 18), Darbinieks var strādāt nevienā vai vienā firmā, vienā firmā strādā neviens

vai vairāki darbinieki. Asociācijas klase šajā transformācijā tiek glabāta kopā ar atsaucēm.

Tips algoti satur tipu algo kas satur asociācijas klases atribūtus, un atsauci uz tipu darbinieks.

4.19 att. Saites viens pret daudziem ar asociācijas klasi transformācija

Piemērā(Attēls 19), Darbinieks var strādāt vairākās firmās.

60

4.21 att. Saites daudzi pret daudziem ar asociācijas klasi transformācija

3.2.12 Unārās saites transformācijas

Ir iespējama situācija, kad darbinieks ir laulāts ar citu kompānijas darbinieku. Šajā

transformācijā objekta definīcijā tiek ietverts atribūts ar norādi uz šo pašu tipu. Tipam

darbinieks tiek izveidots atribūts ir_precejies, un tas satur norādi uz citu darbinieku.

4.22 att. Unārās saites transformācija

61

Piemērā(Attēls 21), viens inženieris var vadīt citus inženierus. Šajā transformācijā tiek

izveidota kolekcija ar norādēm uz tipu inzenieris, jo inženieris var vadīt vairākus citus

inženierus.

4.23 att Unārās saites transformācija

Piemērā(Attēls 22), katram darbiniekam ir iespēja būt par atskaites līdzautoru kopā ar citiem

darbiniekiem, vai arī uzrakstīt atskaiti vienam. Šeit tipam darbinieks tiek veidota kolekcija ar

norādēm uz šo pašu tipu darbinieks.

4.24 att Unārās saites transformācija

62

4 RELĀCIJU OBJEKTU DATUBĀZU IESPĒJU SALĪDZINĀJUMSDarbā tika apskatītas 4 relāciju-objektu datubāzu vadības sistēmas. Visas no apskatītajām

datubāzēm atbalsta objektu orientētos paplašinājumus. Tabulā dots datubāzu vadības sistēmu

salīdzinājums.

Tabula 4.1

Relāciju objektu datubāzu iespēju salīdzinājums

Kritērijs Oracle Informix DB2 PostgreSQL

Saliktu datu

tipu

izveidošana

Saliktā tipa

karkasa un tipa

ķermeņa

veidošana.

Nosauktais un

nenosauktais

raksta tips.

Saliktais tips ar

vairākiem

atribūtiem.

Saliktais tips ar

vairākiem

atribūtiem.

Kolekcijas Tiek izveidots

kolekcijas tips

un tad

kolekcija

izmantota lai

definētu

tabulu.

Kolekcijas ar

tipiem

LIST,SET,

MULTISET.

Tiek definētas

definējot

tabulu.

Kolekcijas

veidošana

netiek

atbalstīta.

Kolekcija

netiek

atbalstīta. To

veido ar

mainīga izmēra

masīvu.

Iebūvēti

saliktie datu

tipi

Ģeometriskie

datu tipi ar to

apstrādes

funkcijām

Metodes Metodes

definēšana tipa

ķermenī.

Metodes

definēšana

reizē ar tipu.

Tabulas

struktūras

mantošana

- - - Pakārtotā

tabula manto

visus

virstabulas

atribūtus, un

pievieno savus

63

individuālos

atribūtus.

Salikto tipu

mantošana

Pakārtotais tips

manto visas

virstipa

atribūtus un

pievieno savus

Pakārtotais tips

manto visas

virstipa

atribūtus un

pievieno savus

Pakārtotais tips

manto visas

virstipa

atribūtus un

pievieno savus

Objektu skatu

veidošana

Objektu skats

pamatojoties

uz saliktajiem

tipiem

Objektu skats

pamatojoties

uz saliktajiem

datu tipiem

64

SECINĀJUMIDarbā tika analizētas 4 populārākās relāciju-objektu datubāzu sistēmas (DBS). Veicot to

izpēti var izdarīt sekojošus secinājumus.

1. Salikto tipu veidošana ir kritērijs, kas atšķir relāciju-objektu datubāzu vadības sistēmas no

relāciju datu bāzu sistēmām. Visas no aplūkotajām datu bāzu sistēmām atbalsta salikto tipu

veidošanu. Visu datubāzu vadības sistēmu saliktajiem datu tipiem pamatā ir iebūvētie datu

tipi, vai citi saliktie tipi.

2. No pārējo DBS saliktajiem tipiem atšķiras Oracle salikto tipu veidošana, kurā no sākuma

tiek izveidots tipa karkass un pēc tam tiek veidots tipa ķermenis.

3. Informix DBS ir iespēja veidot nosaukto un nenosaukto raksta tipu. Nosauktais raksta tips

tiek veidots kā salikts datu tips, ar vairākiem atribūtiem. Tas datubāzē glabājas kā atsevišķs

datu tips, kuru kā tipu var izmantot vairāku tabulu kolonnu veidošanai, vai citu salikto tipu

veidošanai. Nenosauktais raksta tips tiek veidots tabulas definēšanas laikā un to nevar

izmantot citu tabulu kolonnu veidošanai, jo tas tiek veidots tikai vienai konkrētai tabulai.

Nenosaukto raksta tipu nevar piesaistīt tabulai, tas tiek lietots tikai lai identificētu tabulas

lauku.

4. Būtiska relāciju-objektu DBS priekšrocība ir kolekciju veidošana. No aplūkotajām datu

bāzu sistēmām kolekciju veidošanu atbalsta Oracle un Informix.

5.Vispārdomātākā kolekciju veidošana ir Informix DBVS, jo tur kolekcijai ir iespējams

norādīt papildus tipu LIST, SET, MULTISET kuri nosaka vai kolekcijas elementi var

atkārtoties, un vai tie ir sakārtoti.

6. DBVS PostgreSQL, kura nenodrošina kolekciju veidošanu nodrošina līdzīgu

funkcionalitāti lietojot mainīga izmēra masīvus. PostgreSQL masīvi var būt noteikta izmēra,

un mainīga izmēra.Kā masīva tipu nevar izmantot lietotāja definētos saliktos datu tipus.

7. DB2 kolekcijas nevar veidot vispār. Kolekciju veidošanas nenodrošināšana ir PostgreSQL

un DB2 būtisks trūkums, jo projektējot relāciju-objektu DBS ar kolekciju ir ērti veidot saiti

daudzi pret daudziem. Lai realizētu šo saiti starp divām tabulām datubāzu vadības sistēmā

PostgreSQL jāveido 3 tabulas, kurā divas no tām ir pamata tabulas un trešajā tabulā glabājas

atsauces uz abām tabulām. Šajā gadījumā būs sarežģītāka vaicājumu veidošana un ilgāks

vaicājuma izpildes laiks salīdzinājumā ar paņēmienu kad triju tabulu vietā tiek veidotas divas

tabulas ar iekļauto kolekciju, kur kolekcijas satur atsauces uz otru tabulu.

65

8. Iebūvētus saliktos ģeogrāfiskos datu tipus piedāvā tikai PostgreSQL DBVS, iebūvētie

saliktie ģeometriskie datu tipi nodrošina telpisku objektu glabāšanu. PostgreSQL DBVS ir

pieejamas arī funkcijas, kas darbojas ar šiem ģeometriskajiem datu tipiem. Tieši šīs īpašības

dēļ PostgreSQL datubāzu vadības sistēma tiek pielietota ģeogrāfiskajās informācijas sistēmās.

9. Metožu veidošanu atbalsta Oracle un DB2. Oracle metode tiek veidota tipa ķermenī, bet

DB2 metode tiek veidota definējot tipu. Metožu veidošana netiek atbalstīta Informix un

PostgreSQL.

10. Tabulas struktūras mantošanu atbalsta tikai PostgreSQL. Tabulas struktūras mantošana

ļauj ērti izveidot vispārinājuma saiti. Lai mantošanu realizētu pārējās datubāzu vadības

sistēmās vispirms ir jāveido saliktie datu tipi starp tiem jārealizē mantošana, un pēc tam

balstoties uz šiem tipiem jāveido tabulas. Salikto tipu mantošanā apakštipam var būt viens

virstips un vienai apakštabulai viena virstabula, bet tabulas struktūras mantošanā PostgreSQL

vienai apakštabulai var būt vairāki virstipi, tas nozīmē, ka viena tabula var mantot kolonnas

no vairākām tabulām.

11. Visas no aplūkotajām DBS piedāvā līdzīgu funkcionalitāti, bet visplašākā funkcionalitāte

ir firmas Oracle datu bāzes serverim. Oracle ir relāciju objektu datu bāzu tirgus līderis.

12. Ļoti aktuāls jautājums ir relāciju-objektu DB projektēšana. Diemžēl šai problēmai ir veltīti

ļoti maz darbu. Bakalaura darbā ir izstrādātas konceptuālo modeļu elementu un struktūru

transformācijas uz relāciju-objektu loģisko modeli DBS Oracle. Tas ļauj veidot atbilstošus

projektēšanas automatizācijas rīkus.

66

LITERATŪRA

1. Date, C.J.: An Introduction to Database Systems. Eight edition. Addison Wesley (2005)2. Codd, E. F.: A relational model of data for large shared data banks. CACM (1970)

3. C. J. Date. Database in Depth. Relational Theory for Practitioners. O’Reilly (2005)

4. Simon, A.R.: Strategic Database Technology: management for the year 2000. Morgan Kaufman Publishers, Inc. (1995)

5. Mullins, C.S.: DB2 Developer’s Guide. Sams Publishing (2004)

6. Matthew, N., Stones, R.: Beginning Databases with PostgreSQL: From Novice to

7. Loney, K.: Oracle Databas 10G: The Comlete Reference. McGraw-Hill (2004)

8. History of object relational databases. Skatīts 2010. gada 20. maijā. http :// www . google . com / search ?

q

= history + of + object + relation + databases & hl = en & sa = X & tbo = p & num =20& tbs = tl :1, tll :1990, tlh :1991& ei

= lKHEStXeHYPtAbqoZBH & oi = timeline _ histogram _ main & ct = timeline -

histogram & cd =6& ved =0 CBUQyQEoBg  

9. Date, C., Hugh, D.: Foundation for Object/Relational Databases: The Third Manifest. Addison-Wesley

(1998)

10. Saracco, C.M.: Universal Database Management: Guide to Object/Relational Technology. Morgan

Kaufman (1999)

11. Brown, P.: Developing Object-Relational Database Applications. Part 1: database analysis and design

methodology. Data Management Research, IBM (2002)

12. What is relational database? Skatīts 2010. gada 1. jūnijā http://www.wisegeek.com/what-is-a-

relational-database.htm13. Object Database skatīts 2010. gada 3. aprīlī http://en.wikipedia.org/wiki/Object_database

14 IBM Informix Dynamic server documentation.

15 Informix Press. Informix Guide to SQL Syntax

16. The PostgreSQL Global Development Group. PostgreSQL 8.4.4 Documentation

67