ievads - datubaze.files.wordpress.com · web viewobjektu datubāzes labi sadarbojas ar tādām...
Post on 31-Mar-2018
222 Views
Preview:
TRANSCRIPT
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
top related