RĪGAS TEHNISKĀ UNIVERSITĀTEDatorzinātnes un informācijas tehnoloģijas fakultāte

Lietišķo datorsistēmu institūts

Dmitriy Shulzhenkobakalaura akadēmisko studiju programmas „Datorsistēmas”

students, stud. apl. nr. 131RDB357

Objektu tehnoloģiju izmantošanas datu bāzē analīze un izvērtējums

BAKALAURA DARBS

Zinātniskais vadītājsprofesors, Dr.sci.ing.

Jānis Eiduks

RĪGA2016

SATURS

IEVADS......................................................................................................................................8

1. OBJEKTU – RELĀCIJU DATU BĀZE UN OBJEKTORIENTĒTĀ PARADIGMA....13

1.1. Klases un eksemplāra jēdziens, datu iekapsulēšana........................................................13

1.2. Klases metodes, metožu pārslogošana.............................................................................14

1.3. Mantošanas jēdziens........................................................................................................17

1.4. Metožu pārrakstīšana.......................................................................................................21

1.5. Abstraktā klase.................................................................................................................21

1.6. Polimorfisms....................................................................................................................22

1.7. Objektu atsauces..............................................................................................................25

1.8. Objekta skats....................................................................................................................25

1.8.1. Objekta skata izveidošana...................................................................................25

1.8.2. Objekta ievietošana, atjaunošana un izdzēšana..................................................27

1.9. Datu mantošana................................................................................................................28

1.10. Kopsavilkums..................................................................................................................29

2. MANTOŠANAS REALIZĒŠANA DATU BĀZĒ...........................................................32

2.1. Mantošanas realizēšana relāciju datu bāzē......................................................................32

2.1.1. Apvienotas tabulas izmantošana.........................................................................33

2.1.2. Konkrētas tabulas izmantošana...........................................................................35

2.1.3. Klases tabulas izmantošana.................................................................................36

2.1.4. Šablonu salīdzinājums........................................................................................38

2.2. Mantošana realizāciju objektu – relāciju datu bāzē.........................................................38

2.2.1. Transformācija no objekta uz objektu – relāciju komponentiem........................38

2.2.2. Transformāciju no objektu – relāciju komponentiem uz objektu – relāciju

tabulām 38

2.3. Dažādu mantošanas veidu realizācija, izmantojot objektu – relāciju struktūras.............40

2.3.1. Vienkāršā mantošana..........................................................................................40

2.3.2. Daudzlīmeņu mantošana.....................................................................................41

2.3.3. Hierarhiskā mantošana........................................................................................42

2.3.4. Savstarpēji izslēdzošā mantošana.......................................................................43

2.3.5. Pārklāšanās tipa mantošana.................................................................................44

2.4. Kopsavilkums..................................................................................................................45

2

3. DATU BĀZES UN LIETOJUMA OBJEKTU SASKAŅOŠANA..................................46

3.1. JDBC dzinis.....................................................................................................................46

3.2. Vāji tipizētās klases izmantošana....................................................................................48

3.2.1. Struct saskarnes darbība......................................................................................48

3.2.2. Struct objektus un atribūtus izgūšana.................................................................49

3.3. Stipri tipizētās klases izmantošana..................................................................................52

3.3.1. SQLData saskarne...............................................................................................52

SECINĀJUMI...........................................................................................................................56

LITERATŪRA.........................................................................................................................57

PIELIKUMI..............................................................................................................................58

PIELIKUMA NOSAUKUMS..................................................................................................59

3

IEVADS

Datu bāzes un datu bāzes sistēmas (datu bāze un datu bāzes vadības sistēma) ir

nogājušas garu attīstības ceļu sākot no 19. gs. 60 gadiem. Ir izstrādāti un izmantoti

hierarhiskie, tīklveida, relāciju, objektorientētie, relāciju-objektu datu bāzes loģiskie modeļi.

Ļoti nozīmīga bija pāreja no hierarhiskiem un tīklveida modeļiem uz relāciju modeli. F.

Kodda izstrādātā relāciju algebra un tās izmantojums relāciju datu bāzē1, noteica tai šādas

pamatprasības:

1) dati tiek glabāti tabulās, katra tabulas rinda ir unikāla, katrai tabulas rindai ir

unikāla atslēga (primārā atslēga, kolonas vai kolonu kopas vērtība), tabulas tiek savienotas

izmantojot ārējās atslēgas, tiek nodrošināti datu integritātes noteikumi;

2) datu bāzes valodai jābūt deklaratīvai un jānodrošina visu relāciju algebras

darbību izpilde.

Sistēmas, kurās izpildās pirmās grupas prasības, bet neizpildās otrās grupas prasības,

sauc par daļēji relāciju (semi-relational) datu bāzes sistēmām2.

Relāciju datu bāzes ir visplašāk lietotais datu bāzes tips. Diemžēl relāciju datu bāzei ir

arī daudz trūkumu:

1) reālās pasaules objekti, subjekti un procesi (būtības) tiek sadalītas mazās

sastāvdaļās (normalizācijas prasības). Ir nepieciešama saišu sistēma, kas tās apvieno. Saišu

realizēšana ir darbietilpīga operācija, kas bieži nenodrošina nepieciešamo ātrdarbību.

2) relāciju modelī ir tikai tabulas un saites. Saitēm var būt dažāda semantika: ir,

saturēt (has), piederēt (owns), pārzināt, vadīt (manages). Relāciju modelī to nevar norādīt.

3) ir nepietiekams datu integritātes nodrošinājums (korporatīvie likumi);

4) datu struktūras viendabība, kolonas lauka vērtības atomaritāte. Vēlama būtu

kopu, kortežu, hierarhisku kortežu, kortežu kopu, iekļautu attieksmju izmantošana. Kā

pozitīvu iezīmi var minēt lielo objektu tehnoloģijas (Binary Large OBjects) iekļaušanu, kuros

var glabāt attēlus, audio-datus, programmas.

5) ierobežots operāciju skaits. Problēmas ar jaunu operāciju ieviešanu.

6) datu nesaskaņotības problēma (impedance mismatch). SQL valodā vieni datu

tipi, programmēšanas valodās citi.

7) ilglaicīgām vaicājuma izpildēm ir apgrūtināta transakciju vadība;

1 DB-Engines Ranking. http://db-engines.com/en/ranking2Frank Stajano. A Gentle Introduction to Relational and Object Oriented Databases. ORL Technical Report TR-98-2. http://www.orl.co.uk/~fms/ fstajano@orl.co.uk

4

8) datu bāzes shēmas izmaiņas problēmas (piemēram, lauka pārveidošana no

skaitļu tipa uz teksta tipu).

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

lietojumu realizēšanas tehnoloģijām. Datu apmaiņai starp lietojumu un datu bāzes sistēmu

tika izstrādātas specializētas (katrai datu bāzes vadības sistēmai) interfeisa bibliotēkas. Vēlāk

tās tika standartizētas (ODBC, OLE DB, ADO, JDBC).

Pieaugot izmantojamo datu struktūru sarežģītībai (grafiskie dati, temporālie dati,

hierarhiskie dati) un, attīstoties objektu orientētajai programmēšanai, arvien aktuālāks kļuva

jautājums par programmu un datu bāzes datu apmaiņas efektivitātes uzlabošanu. Programmu

un datu bāzes datu struktūru saskaņošanu. Objektorientētā paradigma novirzīja uzmanību no

koda uz datiem. Tā pasauli interpretē kā objektu (dati kopā ar metodēm) kopu un to

mijiedarbību. Tās galvenās iezīmes ir:

1) abstrakcijas izmantošana – maznozīmīgākā ierobežošana, būtiskā akcentēšana;

2) iekapsulēšana – datu un metožu apvienošana;

3) mantošana – objektu līdzības modelēšana;

4) polimorfisms – vienādu metožu dažādas izpildes iespējas.

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ī datu bāzes saliktie dati un to apstrādes

metodes veidotu šādus objektus. Tika izstrādātas objektorientētās datu bāzes sistēmas.

Diemžēl netika atrasti objektu glabāšanas varianti ārējā atmiņā, kuri nodrošinātu efektīvu

(ātru) vaicājumu izpildi. Jāatceras arī, ka datu bāze nav viena lietojuma datu pastāvīga

(persistent) glabāšanas vieta3. Datu bāzi veido daudziem lietojumiem un tai ir arī sava

„dzīve”, neatkarīga no lietojumiem (datu bāzes veidošana, datu ievade, uzturēšana,

optimizācija, drošības pasākumi). Programmu un datu bāzes objekti eksistē atšķirīgās vidēs:

operatīvajā atmiņā un ārējā (external memory) atmiņā (ar izņēmumiem). Objektu ieviešanu

datu bāzē gribēja veikt revolucionārā veidā, bez nopietna matemātiska pamatojuma.

Kāda datu bāze tad ir vajadzīga? Galvenās prasības ir šādas:

1) datu bāzes sistēmai jāsadarbojas efektīvi ar lietojumu, kurš veidots objektu-

orientētajā valodā;

2) datu bāzes datu glabāšanas struktūrām jānodrošina sarežģītu reālas dzīves

objektu datu un to hierarhijas efektīva glabāšana;

3 Date, C.J.: An Introduction to Database Systems. Eight edition. Addison Wesley, 2005.5

3) datu apjomam strauji pieaugot, ļoti svarīgi ir nepieciešamās ātrdarbība

nodrošināšana.

Analizējot relāciju datu bāzes tehnoloģijas un objektorientētās tehnoloģijas

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

pāreja no pirms relāciju (prior relation) datu bāzes sistēmām uz relāciju datu bāzes sistēmām.

Pirmie datu bāzes sistēmu 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 jau gandrīz 30 gadus relāciju datu

bāzes vai SQL datu bāzestiek plaši lietotas informācijas sistēmu veidošanai. Tas

izskaidrojams ar to nopietno un veiksmīgo matemātisko pamatojumu, ko izstrādāja F. T.

Kodds un viņa pētniecības grupa4.

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

pamata karkasu, kas daudzu gadu ekspluatācijā ir parādījis savas labās īpašības5. Pēc vairāku

vadošo speciālistu domām, 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šas6. Tāpēc tās bieži vien sauc arī par pseido(gandrīz)relācijas DB sistēmām.

Datu bāzes tehnoloģijas attīstības izpratnei un prognozēšanai ir veltīts ļoti daudz

dažādu diskusiju, darbu un pētījumu. Nozīmīgākie ir trīs datu bāzes sistēmu manifesti, kuru

veidošanā piedalījušies vadošie datu bāzes tehnoloģijas speciālisti. Pirmajā manifestā -

Objektorientētās datu bāzes sistēmas manifestā (1989. g.) datu bāzes sistēmai tika izvirzīti

divi kritēriji:

1) datu bāzes vadības sistēmai jānodrošina: datu permanenta glabāšana,

sekundārās atmiņas vadība, datu izmantošanas konkurences vadība, datu atjaunošanas iespējas

un neprognozējamu (ad hoc) vaicājumu izpildes iespējas;

2) objektorientētai datu bāzes sistēmai jānodrošina saliktu objektu veidošana,

objektu identitāte, datu iekapsulēšana, mantošana, paplašināšanas iespējas un lietojumu un

datu bāzes datu struktūru saskaņotība.

4Codd, E. F.: A relational model of data for large shared data banks. CACM, 1970.5C. J. Date. Database in Depth. Relational Theory for Practitioners. O’Reilly (2005)6Simon, A.R.: Strategic Database Technology: management for the year 2000. Morgan Kaufman Publishers, Inc., 1995.

6

Kopējais secinājums bija, ka relāciju datu bāzes sistēmas ir novecojušas un

neatbilstošas reālo uzdevumu risināšanai7. Jāpilnveido un jālieto objektorientētās datu bāzes

sistēmas.

Otrajā manifestā - Trešās paaudzes datu bāzes sistēmas manifestā8 (1990. g.) definēja

3 pamatprincipus, kuri jārealizē jaunajās datu bāzes vadības sistēmās:

1) papildus tradicionālajiem datu vadības servisiem, jārealizē plašāks atbalsts

sarežģītākām datu struktūrām un likumiem;

2) jāiekļauj otrās paaudzes (relāciju) datu bāzes vadības sistēmu iespējas;

3) tām jābūt atvērtām (savienošanas un paplašināšanas iespējas) dažādām

apakšsistēmām.

Galvenais secinājums: jāiekļauj jaunu datu tipu veidošana, mantošana, bet jāsaglabā

deklaratīva vaicājumu valoda un SQL.

Trešajā manifestā – J. Deita un H. Darvena Trešajā manifestā9 galvenās prasības

jaunajai datu bāzes sistēmai bija sekojošas:

1) saglabāt relāciju modeli;

2) iekļaut objektu atbalst un lietotāju definētos tipus;

3) veidot alternatīvu datu bāzes valodai SQL – valodu D. J. Deits un H. Darvens

norādīja, kādas ir vēlamās un nevēlamās D valodas īpašības. Tika izstrādātas vairākas D

valodas realizācijas: D4, Alphora Dataphor, Rel, Opus, Duro, Dee, bet popularitāti tās nav

ieguvušas.

Apskatot visus manifestus, var veikt šādus secinājumus:

1) nepieciešama objektu glabāšana datu bāzē;

2) nepieciešama efektīva objektu vaicājumu valoda (objektu SQL);

3) relāciju datu bāzē nav objektu;

4) objektu datu bāzē nav efektīvas vaicājumu valodas;

5) SQL valodu var pielāgot objektu vaicājumiem;

6) jāizmanto relāciju datu bāzes datu glabāšanas karkas, jāiekļauj lietotāju

definētie tipi un objektu metode, jāpielāgo SQL valoda objektu vaicājumiem.

7The Object-Oriented Database System Manifesto. Malcolm Atkinson (University of Glasgow), François Bancilhon (Altaïr), David DeWitt (University of Wisconsin), Klaus Dittrich (University of Zurich), David Maier(Oregon Graduate Center), Stanley Zdonik (Brown University), 1989.

8 The Committee for Advanced DBMS Function, 1990.https://www.cl.cam.ac.uk/teaching/2003/DBaseThy/or-manifesto.pdf

9Date, C. J.; Darwen, Hugh (2000). Foundation for Future Database Systems: The Third Manifesto: a detailed study of the impact of type theory on the relational model of data, including a comprehensive model of type inheritance (2nd ed.). Reading, MA: Addison-Wesley Professional. xxiii, 547.

7

Tātad datu bāzes sistēmu speciālisti nolēma, ka jāveido relāciju un objektorientēto

datu bāžu apvienots variants.

Relāciju un objektorientēto datu bāzes sistēmu apvienošanas pētījumi tika uzsākti 19.

gs. 80 gados10. Pirmās objektu-relāciju datu bāzes sistēmas Postgres izstrāde tika sākta 1986.

g. Kalifornijas Universitātē Berklijā. To iniciēja un vadīja Mihails Stonebreikers (Michael

Stonebraker). Izstrāde ilga 8 gadus. Pirms tam viņš piedalījās relāciju datu bāzes sistēmas

Ingres izstrādē firmai Relational Technology (no 1977. – 1985. g.). 1995. g. Postgres datu

bāzes valoda POSTQUEL tika nomainīta ar SQL un arī sistēma ieguva jaunu nosaukumu

Postgres95 (tagad PotgreSQL).

Patreiz populārākās objektu – relāciju datu bāzes sistēmas ir Oracle Database (firma

Oracle), MySQL (firma Oracle) , Microsoft SQL Server, MongoDB (atvērtā koda sistēma),

PostgreSQL (atvērtā koda sistēma), DB2 (firma IBM).

Bakalaura darbā ir veikta objektu – relāciju datu bāzes iespēju izvērtējums gan izpētot

pieļaujamās datu glabāšanas struktūras, gan eksperimentāli pārbaudot to realizēšanas un

izmantošanas iespējas. Apkopojot iegūto informāciju, izdarīti attiecīgie secinājumi.

10M.Wang, Using UML for object-relational database systems development: A framework, Issues in Information Systems, vol.9, no.2, 2008, ISSN 1529-7314 [E.Marcos, B.Vela, J.M.Cavero, P.Cáceres, R.Juan, Aggregation and Composition in Object – Relational Database Design, 2001 E.Marcos, B.Vela, J.M.Cavero, A Methodological Approach for Object-Relational Database Design using UML , Software and Systems Modeling Journal, vol.2, no.1, 2003, pp.59–72, ISSN 1619-1374 P. Brown. Object-relational database development. Upper Saddle River, NJ: Prentice Hall, 2001.

8

1. OBJEKTU – RELĀCIJU DATU BĀZE UN OBJEKTORIENTĒTĀ

PARADIGMA

1.1. Klases un eksemplāra jēdziens, datu iekapsulēšanaObjektorientētā programmēšanā klase ir līdzīgo objektu definējums jeb šablons, no

kura objekti ir izveidoti. Klase apraksta objekta statiskos atribūtus un dinamisko uzvedību[8].

Klase ietver:

klases nosaukumu, kas identificē klasi;

atribūtus (angļu val. attributes), kas reprezentē klases mainīgos;

metodes (angļu val. methods), kas satur klases dinamisko uzvedību.

Eksemplārs ir klases konkrētā realizācija. 1.1. att. ilustrē, ka eksemplāram ir savs

unikālais identifikators un tas satur visus atribūtus un metodes, kuri bija definēti klases

aprakstā. Unikālais identifikators ir ievadīts no programmatūras izstrādātāja.

1.1. att. Objekta eksemplāra realizācija no klases šablona

Objektu – relāciju datu bāzē, definīcija “klase” ir aizstāta ar “objekta tips”. Līdzīgi kā

klasei objekta tips apraksta objekta statiskos mainīgos un dinamisko uzvedību, kā arī satur

tipa nosaukumu, atribūtus un metodes.

Eksemplāram ir atribūti un metodes no objekta tipa apraksta. 1.2. att. ir redzams, ka

atšķirīgi no objektorientētas programmēšanas, eksemplāra unikālais identifikators, var būt

izveidots 2 veidos:

sistēmas-ģenerētais eksemplāra identifikators – OID;

eksemplāra identifikators, kas ir balstīts uz primāro atslēgu.[13]

1.3.a. att. demonstrē, kādā veidā notiek datu iekapsulēšana (angļu val. encapsulation)

objektorientētā programmēšanā. Tā ir realizēta 2 posmos:

1) Tiek aizliegta tieša pieeja pie visiem klases mainīgiem;

9

2) Tiek izveidotas “dzimtās” metodes, kuras nodrošina pieeju pie mainīgiem. Šīs

metodes iedalās divas grupas: vērtību ievadīšanas metodes un vērtību izgūšanas

metodes.[8]

1.2. att. Datu bāzes objekta eksemplāra realizācija no objekta tipa

Objektu – relāciju datu bāzēs datu iekapsulēšana ir nedaudz zemākā līmenī nekā

objektorientētā programmēšanā. 1.3.b. att. ir redzams, ka ir 2 iespējas, ka piekļūt pie datiem.

1.3. att. Datu iekapsulēšana a)objektorientētā programmēšanā un b) objektu – relāciju datu bāzē

Tāpat, dati ir pieejami ar “dzimtām” metodēm. Vienlaikus, pie datiem var piekļūt,

izmantojot relāciju iespējas – SQL ar objektorientētām īpašībām, kas ir nodrošinātas sākot ar

SQL:1999 standartu.[9] Citi nosaukumi standartam ir SQL3 vai OSQL.

1.2. Klases metodes, metožu pārslogošana

Objektorientētās programmēšanas metode ir darbību kopums, kas izpilda noteiktas

operācijas pēc dažiem datiem, un var vai nevar atgriezt rezultātu. Metode var saturēt vai

nesaturēt parametrus.[7]

10

Parametri ļauj metodei saņemt sākumvērtības, ar kurām notiek apstrāde. Parametri ir

deklarēti kopā ar pašu metodi. Metode var nolasīt parametru vai izmainīt to, ja ir

nepieciešams. Tomēr ir iespēja aizliegt iespēju mainīt parametra vērtību. To var izdarīt

metodes deklarācijā, norādot operatoru FINAL pirms parametra.[7]

Metode var atgriezt rezultātu. Lai norādītu, ka metode atgriež rezultātu, metodes

deklarācijā ir jādefinē atgriežams tips. Ar operatoru RETURN tiek noteikts, kāda vērtība būs

atgriezta rezultātā.[7]

Katrai klasei ir speciālas metodes – konstruktora metodes (angļu val.

constructormethod). Tās ir izsauktās, kad objekts ir inicializēts. Klasei obligāti jābūt vismaz 1

konstruktoram. Ja, konstruktors nav definēts, tad kompilators pats izveido konstruktoru bez

parametriem. Šis konstruktors tikai inicializē objektu, bet neiestata tās atribūtus. Tomēr

parasti, konstruktoram ir parametri. Šie parametri ļauj iestāt atribūtu vērtības jaunizveidotā

objektā [7].

Objektu – relāciju datu bāzē metode ir funkcija vai procedūra, kuru ir iespējams

deklarēt objekta tipa definējumā un implementēt vajadzīgo uzvedību noteiktam objektam

[13].

Pēc būtības, metodes objektu – relāciju datu bāzē ir līdzīgas metodēm objektorientētā

programmēšanā. Tomēr ir dažādas atšķirības. Pirmkārt, eksistē dažādi metožu tipi:

konstruktora metode – ir līdzīga konstruktora metodei objektorientētā

programmēšanā. Konstruktora metode ir sistēmas definēta vai lietotāja definēta.

Sistēmas definētais konstruktors ir netieši definēts pēc noklusējuma. Konstruktors

saņem visas atribūtu vērtības un izveido jauno objektu. Lietotāja definētais

konstruktors var implementēt kaut kādu loģiku atribūtu vērtību definēšanai.

Parametru daudzumam nav obligāti jāsakrīt ar atribūtu daudzumu;[13]

salīdzināšanas metodes – pastāvēs 2 salīdzināšanas metodes: MAP metode un

ORDER metode. Katrs objekta tips varēs definēt tikai vienu no metodēm. MAP

metodes būtība ir vērtību aprēķināšana no eksemplāra atribūtiem. Kad ir

nepieciešams salīdzināt objektus, MAP metode tiek izsaukta abiem objektiem un

tiek aprēķināta vērtība. Šīs vērtības tiek salīdzinātas, kā arī tiek noskaidrots, kurš

objekts ir “lielāks”. ORDER metode ir tieša objekta-pret-objektu salīdzināšana.

Izmantojot definētu algoritmu, metode atgriež vērtību -1,1 vai 0, kura nosaka, kurš

objekts ir lielāks vai tie ir vienādi. MAP metode labāk izmantot, kad ir

11

nepieciešamas sakārtot, lielu objektu daudzumu. ORDER metode ir labāk

piemērota, kad salīdzināšanas loģika ir sarežģītāka nekā vērtību aprēķināšana;[13]

MEMBER metode – metode vispārējiem mērķiem. Metode ļauj manipulēt ar pašu

objektu jeb eksemplāru. Metodei ir iebūvēts parametrs SELF, kurš norāda uz pašu

objektu, ar kuru notiek manipulācija;[13]

STATIC metode – šī metode tiek izmantota, lai veiktu globālās operācijas ar

objekta tipu nevis eksemplāru. STATIC metodei nav iebūvēto parametru SELF.

[13]

Otrkārt, objektu – relāciju datu bāzē ir 3 dažādi parametru veidi – IN parametrs, OUT

parametrs un IN OUT parametrs[13]:

IN parametrs dod iespēju nodot metodei sākumvērtības. Metodē IN parametru

mainīt nedrīkst, tas paliek ka konstante. IN parametrs var būt inicializēts ar

noklusējamu vērtību. Tā tiek izmantota, kad, izsaucot metodi, netiek nodota

parametra vērtība;[13]

OUT parametrs atgriež vērtību metodes izsaucējam. Kad metode tiek izsaukta,

parametra vērtība ir NULL. Metodes izpildes laikā šim parametram tiek nodota

vērtība un parametrs tiek atgriezts kā viens no rezultātiem;[13]

IN OUT parametrs apvieno sevī gan IN, gan OUT parametru darbību. Kad metode

ir izsaukta, šim parametram ir nodota sākumvērtība. Metodes izpildes laikā šī

parametra vērtība tiek izmainīta un nodota metodes izsaucējam kā vienam no

rezultātiem. Atšķirībā no IN parametra, šīm parametram nedrīkst definēt

noklusējamo vērtību.[13]

Metožu pārslogošana (angļu val. method overloading) ir koncepcija, kur dažādas

metodes var pastāvēt un izpildīt līdzīgas operācijas, tomēr nosaukums tiem ir vienāds.

Kompilators vai sistēma var atpazīt, kura metode ir jāizpilda, analizējot parametru sarakstu.

[8] Att. 1.4. ir attēlots metožu pārslogošanas piemērs.

12

1.4. att. Konstruktora metožu pārslodze

Šajā gadījumā notiek konstruktoru pārslodze. Tādējādi, lai pārslogotu metodes, tam ir

jānodod vienāds nosaukums, bet atšķirīgu parametru saraksts. Atšķirības var būt sekojošas:

parametru daudzums, parametru tipi, parametru kartība. Metožu pārslogošanas koncepcija ir

vienāda gan objektorientētā programmēšanā, gan objektu – relāciju datu bāzē.

1.3. Mantošanas jēdziens

Daudzas lietas pasaulē ir saistītas grupās, tā saucamās “ģimenes”. Mantošanas (angļu

val. inheritance) ideja ir raksturīgo pazīmju nodošana no “vecākiem” “bērniem”. Turklāt,

“bērns” pievieno klāt savas unikālās pazīmes. Mantošanai ir svarīga nozīme objektorientētā

paradigmā [8].

Kad klase manto no citas klases, tā manto elementus, kas sastāda “vecāko” klasi –

mainīgos un metodes. “Vecāko” klasi citādi sauc par virsklasi vai superklasi. Klasi, kas

manto, sauc par apakšklasi [3].

Mantošana tiek nodrošināta, gan objektorientētā programmēšanā, gan objektu –

relāciju datu bāzē.

13

1.5. att. Mantošanas realizācija objektorientētā programmēšanā

1.5. att. ir parādīts, kas tiek pārmantots objektorientētā programmēšanā, bet 1.6. att.,

kas objektu – relāciju datu bāzē.

1.6. att. Mantošanas realizācija objektu – relāciju datu bāzē

14

Būtiska atšķirība ir tāda, ka objektorientētā programmēšanā mantojas tikai atribūti un

metodes ar modifikatoru PUBLICvai PROTECTED.[7] Savukārt objektu – relāciju datu bāzē

tiek mantoti visi atribūti un tikai MEMBER un STATIC tipa metodes no virstipa.[13] Tas

nozīmē, ka salīdzināšanas metodē var būt definēti tikai saknes tipi, kuram nav virstipa.

Papildus, objekta tipam var norādīt modifikatoru FINAL, kas aizliedz pārmantošanu no tā

(1.7. att.).

1.7. att. Mantošanas aizliegšana objektu – relāciju datu bāzē

Lai izveidotu mantošanu, eksistē 2 atšķirīgi paņēmieni: vispārināšana (angļu val.

generalization) un specializācija (angļu val. specialization).

Vispārināšanas ideja ir virsklases izveidošana no 2 vai vairāk līdzīgām klasēm. Ideja ir

līdzīga analīzei “no lejas uz augšu”. Izvelkot kopīgo no klasēm (mainīgus un metodes), tiek

izveidota virsklase. Šīs līdzīgās klases kļūst jaunizveidotai virsklasei par apakšklasēm. 1.8.

att. ir parādīts vispārināšanas piemērs.

15

1.8. att. Vispārināšanas realizācija Eksistē 2 klases:

Students ar mainīgajiem: vārds, uzvārds, dzimšanas_gads, personas_kods,

kurssun metodēm: aprēķinātVecumu(), pārcelt(),

Pasniedzējs ar mainīgajiem: vārds, uzvārds, dzimšanas_gads,

personas_kods, zinatniskais_grads un metodēm: aprēķinātVecumu().

Ir redzams, ka klasēm ir kopīgās pazīmes. Izsvītrojot tās un pārceļot jaunajā klasē,

kuru varam nosaukt Cilvēks, mēs izveidojam mantošanas hierarhiju.

Specializācija atgādina analīzi “no augšas uz leju”. No 1 klases, pievienojot unikālos

jeb specializētos mainīgos un metodes, tiek izveidotas jaunās apakšklases. Piemērs ir parādīts

1.9 att. 16

1.9. att. Specializācijas realizācija

No esošas klases Cilvēks tiek izveidotas 2 apakšklases – Students un Pasniedzējs.

Klasei Students ir pievienots mainīgais kurss un metode pārcelt(). Klasei Pasniedzējs

parādās jauns mainīgais zinatniskais_grads.

1.4. Metožu pārrakstīšana

Apakšklase manto metodes no virsklases un tādējādi tai vienmēr jānodrošina vismaz

tik daudz metodes, cik bija virsklasē, bieži vien vairāk. Tomēr metožu implementācija

apakšklasē var būt izmainīta. Šis paņēmiens ir nosaukts par metožu pārrakstīšanu (angļu val.

method overriding).[8]

17

Jaunajai metodei, pēc būtības, ir jāizpilda līdzīgā funkcionalitāte. Ar jauno metodi ir

iespējams uzlabot metodi un izveidot piemērotāko funkcionalitāti noteiktai apakšklasei [8].

Objektorientētā programmēšanā ir iespējams pārrakstīt visas metodes, kuras ir

apzīmētas ar pieejas modifikatoru PUBLICvai PROTECTED. Lai pārrakstītu metodi, tās

signatūrai apakšklasē ir jāsakrīt ar metodes signatūru virsklasē. Tas nozīme, ka ir jāsakrīt

metodes nosaukumam, parametru nosaukumam un tipiem, kā arī parametru daudzumam un

kartībai [7].

Objektu – relāciju datu bāzē var pārrakstīt visas metodes, kuras ir pārmantotas. Līdzīgi

kā objektorientētā programmēšanā metodes signatūrai ir jāsakrīt ar virsklases metodes

signatūru. Ir pieņemts, ka STATIC metodes pārrakstīšana ir saukta par metožu slēpšanu.

Objekta tipa definīcijā metodes var apzīmēt ar modifikatoru FINAL, un tās aizliegs metožu

pārrakstīšanu [13].

1.5. Abstraktā klase

Objektorientētā programmēšanā abstraktā klase ir klase, kura nevar būt inicializēta jeb

nav iespējams izveidot šīs klases eksemplāru. Abstraktās klases mērķis ir darboties kā bāzei

vai šablonam apakšklasēm. Lai apzīmētu, ka klase ir abstrakta, klases aprakstā pievieno

atslēgvārdu ABSTRACT [7].

Abstraktajā klasē var izveidot abstraktās metodes. Metodi var deklarēt kā abstrakto,

norādot modifikatoru ABSTRACT metodes definējumā. Abstraktai metodei nav

implementācijas, tas ir, nav nekāda izpildāmā koda, bet ir tikai metodes signatūra. Tomēr ne

visām metodēm jābūt abstraktām. Abstraktā klase satur gan abstraktās metodes, gan parastās.

[7]

Abstraktās klases apakšklasēm ir obligāti jāpārraksta visas abstraktās metodes. Visas

citas metodes ir pārmantotas kā parasti. Tomēr tās ir iespējams pārrakstīt kā

vienmēr.Vienīgais gadījums, kad apakšklase var nepārrakstīt abstrakto metodi, ir, ja paša

apakšklase ir definēta kā abstraktā.[7]

Objektu – relāciju datu bāzē ir līdzīgs mehānisms, bet ar citu nosaukumu – NOT

INSTANTIABLE tipi un metodes. Līdzīgi kā iepriekš, šis tips nevar būt inicializēts un tam

nav konstruktora. NOT INSTANTIABLE metodes nesatur nekādu implementāciju, un var

eksistēt tikai iekš NOT INSTANTIABLE tipa.[13]

NOT INSTANTIABLE tipi un metodes izpilda tādu pašu funkciju kā abstraktās klases

un metodes. Tips dod šablonu visiem apakštipiem, bet metodes ir obligāti jāpārraksta

18

apakštipos. Tāpat, ja apakštips ir definēts kā NOT INSTANTIABLE, tad tas var nepārrakstīt

NOT INSTANTIABLE metodes.[13]

1.6. Polimorfisms

Apakšklases eksemplārs vienlaikus ir arī virsklases eksemplārs, jo apakšklase

pārmanto visas virsklases īpašības. Tās nozīmē, ka ir iespēja apstrādāt apakšklases objektu kā

virsklases objektu. Turklāt, tā kā virsklase garantē, ka apakšklasēm būs noteiktas metodes, ir

iespēja izsaukt šīs metodes, nedomājot, kādai apakšklasei pieder klases eksemplārs. Šī

parādība objektorientētā programmēšanā tiek saukta par polimorfismu (angļu val.

polymorphism).[3]

No polimorfisma izriet tipu aizvietošana (angļu val. type substitutability). Ideja ir

sekojoša, ka apakšklases eksemplārs vienlaikus pieder gan apakšklases eksemplāram, gan

virsklases eksemplāram. Kad programmā ir gaidāms virsklases eksemplārs, šo eksemplāru var

aizvietot ar apakšklases eksemplāru, nemainot programmu un netraucējot tai. Attēlos 1.10. un

1.11. ir parādīts, kā šo parādību var izmantot. Ir definēta klašu hierarhija, kur apakšklases ir

mantotas no abstraktās klases Cilvēks.

Pateicoties polimorfismam ir iespēja izveidot masīvu no Cilvēka objektu

eksemplāriem. Bet Cilvēka klase ir abstraktā un tādēļ masīvā tiek ievietoti tikai apakšklases

eksemplāri. Turklāt ir iespējams katram masīva elementam izsaukt metodi

attēlotInformāciju()neraugoties uz to, ka masīvā glabājas dažādu apakšklašu eksemplāri.

19

1.10. att. Klašu hierarhija

1.11. att. Cilvēka objektu masīvs

Objektu – relāciju datu bāzē arī pastāv polimorfisms un tipu aizvietošana. Tā būtība ir

līdzīga polimorfismam objektorientētā programmēšanā. Kad ir nepieciešams iegūt virstipa

eksemplārus, papildus tiek atgriezti visi apakštipa eksemplāri. Piemēram, ir definēta objekta

tipu hierarhija, kura ir redzama 1.12. att. Šī hierarhija ir līdzīga klašu hierarhijai 1.10 attēlā.

Objektu – relāciju datu bāzē ir iespējams izveidot tabulu, kur glābājas Cilvēka_tipa

eksemplāri. 1.13. att. ir attēlots, ka šajā tabulā ir iespējams glābāt visu apakštipu eksemplārus

līdzīgi ka Cilvēka objektu masīvā. Šeit izveidojas tabula ar nehomogēniem objektiem.

20

1.12. att. Objekta tipu hierarhija

1.13. att. Tabula ar cilvēka tipa eksemplāriem

Rezultātā visi objekti var tikt apstrādāti kā Cilvēka_tipa objekti, jo Pasniedzējs un citi

apakštipi vienlaikus ir Cilvēki. Visiem objektiem ir iespējams izsaukt metodi

attēlotInformāciju().

Papildus tam objektu-relāciju datu bāzē ir iespēja aizliegt tipu aizvietošanu. To var

izdarīt, norādot NOT SUBSTITUTABLE AT ALL LEVELS modifikatoru tabulas definīcijā.

[13]

21

1.7. Objektu atsauces

Objektorientētā programmēšanā viens vai vairāki mainīgie var saturēt objektu atsauci

(angļu val. object reference). Objektu atsauce nesatur pašu objektu, bet gan norāda uz citu

objektu. Tās dod iespēju sasaistīt dažādus objektus un izveidot, piemēram, agregāciju saites.

[3]

Objektu – relāciju datu bāzē pastāv līdzīgs mehānisms – REF loģiskā norāde. Norāde

var aizvietot arējās atslēgas, kuras ir nepieciešamas relāciju datu bāzē. REF norādi izmanto,

lai modelētu viens – pret – vienu un viens - pret – daudziem attiecības.[13]

1.8. Objekta skats

Relāciju datu bāze, skats (angļu val. view), ir virtuālā tabula, kura ir bāzēta uz vienu

vai vairākām tabulām vai skatiem. Pats skats neglabā datus, bet tikai piedāvā alternatīvu

skatienu uz datiem tabulās. Skati var būt izmantoti, lai parādītu tikai būtisko informāciju un

paslēpt no lietotājiem nevajadzīgo informāciju.

Objekta skats (angļu val. object view) ļauj mums piekļūt un manipulēt ar relāciju

datiem kā ar objektiem, it kā dati glabājas nevis relāciju tabulā, bet objektu tabulā. Katra rinda

objektu skatā ir objekta tipaeksemplārs, kuram ir iespējams izsaukt metodes, piekļūt tā datiem

ar punkta notāciju vai izveidot REF atsauci, kas norāda uz šo objektu.[13]

Objekta skati ir noderīgi, lai pārietu uz objektorientētiem lietojumiem, jo objektu skata

dati ir ņemti no relāciju tabulas. Tās nozīmē, ka ir iespēja izmanot objektorientētu lietojumu,

bez nepieciešamības konvertēt tekošās tabulas un datus uz citu fizisko struktūru. Objekta skati

var tikt izmantoti līdzīgi kā relāciju skati, lai parādītu tikai vajadzīgo informāciju.[13]

Objekta skati piedāvā jaunas iespējas datu izgūšanas nolūkiem. Objekta skati var būt

izmantoti sarežģīto tabulu apvienošanas vietā. Objekta skatus ir viegli modificēt un uzlabot, jo

izmaiņas notiek tikai skatu definīcijā, nemainot datus tabulā. Objekta skati ļauj izveidot

dažādus datu modeļus vienai un tai pašai datu kopai.[13]

Objekta skati var uzlabot veiktspēju:

relāciju dati, kuri ir transformēti par objektiem, ir pārvietoti pa tīklu kā vesela

vienība;

datu pārveidošana par objektiem notiek datu bāzes pusē ne lietojuma pusē. Tas

nozīmē, kas tīkls tiek mazāk pārslogots.[13]

22

1.8.1. Objekta skata izveidošana

Att.3.1. tiek parādīti galvenie soļi objekta skata izveidošanā:

1) eksistē relāciju tabula, kura ir aizpildīta ar datiem;

2) ir definēts objekta tips, kur katrs atribūts atbilst relācijas tabulas kolonnai;

3) tiek izveidots objekta skats, kurā pamatojas uz iepriekš izveidotu objekta tipu un

relāciju tabulu. Objekta skata definīcijā ir 2 svarīgi soļi. Pirmkārt, ir SELECT

vaicājums, kurš definē, kādi dati tiek izgūti un kādā kartībā. Kartībai ir jābūt tādai

pašai kā objekta tipu definīcijā. Otrkārt, ir jāspecificē unikālā vērtība, kura kalpos

kā objekta identifikators jeb OID (kas tika apskatīts 1. nodaļā).[13]

3.2. att. Objektu skata izveidošana process.

23

Rezultātā relāciju dati tiek pārveidoti par objektiem (3.1. att. 4. punkts), nemainot

pašus datus. Tagad šo objekta skats kalpos kā objektu tabula, un ar šiem objektiem var izpildīt

dažādas darbības, piemēram:

izsaukt objektiem metodes, kuras bija definētas objekta tipā;

nodot objektus lietojumam objekta veidā nevis relāciju veidā (tas bija apskatīts

iepriekšējā nodaļā);

veidot vaicājumus objekta skatam;

veidot atsauces uz objektiem no objekta skata.

1.8.2. Objekta ievietošana, atjaunošana un izdzēšana

Lielākoties objekta skats tiek izmantots, lai attēlotu informāciju objektu veidā. Turklāt

objekta skatam ir iespējams veikt ievietošanas, atjaunošanas un izdzēšanas operācijas, līdzīgi

kā objektu tabulai. Datu bāzes vadības sistēma automātiski šajā gadījumā veic izmaiņas

atbilstošas relāciju tabulās.[13]

Tomēr, relāciju tabula ne vienmēr tiek automātiski izmainīta. Ja objekta skata

definīcijā, SELECT vaicājumā ir:

1) dažādu tabulu apvienošana;

2) kopas operatori;

3) kopsummas funkcijas;

4) grupēšana;

5) unikālo rakstu attēlošanas operācija.[13]

Tad objekta skatam ne var veikttiešas ievietošanas, atjaunošanas un izdzēšanas

operācijas. Bet ir iespēja to izdarīt, izmantojot INSTEAD OF trigerus. Ir jādefinē savs trigeris

katrai manipulēšanas operācijai - INSERT, UPDATE, DELETE. Iekš trigera ir jāraksta sava

operācija, kāda veidā tiek izmainīti relācijas dati.[13] Trigeru definīcijas ir sekojošas:CREATE TRIGGER ... INSTEAD OF INSERT on ... FOR EACH ROWBEGIN

//operāciju kods

//

END;

CREATE TRIGGER ... INSTEAD OF UPDATE on ... FOR EACH ROWBEGIN

//operāciju kods

24

//

END;

CREATE TRIGGER ... INSTEAD OF DELETE on ... FOR EACH ROWBEGIN

//operāciju kods

//

END;Trigeru rakstīšana var būt sarežģīts uzdevums. Tomēr katrs trigeris ir jāraksta tikai

vienu reizi katram objekta skatam. Trigeris ir jāmaina tikai tad, kad ir mainīta relāciju tabulu

shēma, bet tas ir pietiekami rets gadījums.[10]

1.9. Datu mantošana

Iepriekš bija apskatīts, ka apakštipa un virstipa eksemplārus var glabāt vienā tabulā,

kuru sauc par tabulu ar nehomogēniem objektiem. Tomēr, eksistē cita iespēja, ka to var

izdarīt.

1.15. att. ir parādīta objektu tipu hierarhija. Lai glabātu objektu eksemplārus, var būt

izmantotas vairākas tabulas. Virstipam Cilvēka_tips tiek izveidota tabula Cilvēki, kur glabās

tikai Cilvēka_tipa eksemplāri. Katram apakštipam tiek izveidota sava tabula. Rezultātā,

apakštipa objekti glabās savās tabulās, bet virstipa dati glabās virstipa tabulā.[6]

1.15. Objektu tipu hierarhijaŠādā tabulu struktūra dod iespēju uzlabot vaicājumus, pievienot iespēju netieši

apskatīt visas apakštabulas.[6] Piemēram, vaicājot Cilvēku tabulai, rezultātā, tiek atgriezti ne

tikai Cilvēka_tipa eksemplāri no Cilvēku tabulas, bet arī Cilvēka_tipa eksemplāri no visām

25

apakštabulām. Tomēr, tiek atgriezti tikai tie atribūti, kuri ir Cilvēka_tipam. Tās ir, iespējams,

patiecoties tipu aizvietošanas īpašībai, jo Students vienlaikus ir Cilvēks.

Rezultātā iznāk, ka loģiski, apakštipa dati, kuri attiecās uz virstipu, ir glabāti nevis

apakštabulā, bet virstabulā (1.16. att.). Var secināt, ka apakštips manto ne tikai atribūtus un

metodes no virstipa, bet arī datus.

1.16. att. Datu mantošanas būtība

1.10. Kopsavilkums

Veicot objektu – relāciju datu bāzes un objektorientētās programmēšanas objektu

tehnoloģiju analīzi, tikai apkopotas galvenās objektu tehnoloģijas, kuras ir redzamās Objektu

tehnoloģijas iekļaušana objektu – relāciju datu bāzē tabulā.

Tika secināts, ka objektu – relāciju datu bāze pietiekami pilnīgi iekļauj objektu

tehnoloģijas no objektorientētās programmēšanas. Turklāt objektu – relāciju datu bāze

paplašina šīs tehnoloģijas, piemēram, mantošanas aizliegšana. Objektu tehnoloģiju

implementācija objektu – relāciju datu bāzē nedaudz atšķiras no objektorientētās

programmēšanas, lai apmierinātu datu bāzes vajadzības.

26

Objektu tehnoloģijas iekļaušana objektu – relāciju datu bāzē

N.p.

k.

OO programmēšana Objektu – relāciju datu bāze

1.

2.

3.

4.

27

N.p.

k.

OO programmēšana Objektu – relāciju datu bāze

5.

6.

7.

28

2. MANTOŠANAS REALIZĒŠANA DATU BĀZĒ

2.1. Mantošanas realizēšana relāciju datu bāzē

Mantošanas realizēšana ir problēma relāciju datu bāzēm, tāpēc ka nav nekādas

iespējas to realizēt, izmantojot dzimto SQL valodu[2]. Tomēr var izmantot vairākus

mantošanas realizēšanas šablonus[1,2]. 2.1 att. ir parādīta UML klašu diagramma 4 klasēm,

kuru sasaistei tiek izmantota mantošana. No vieniem un tiem pašiem klašu modeļiem tiek

izgūti 3 dažādi relāciju datu bāzes fiziskie modeļi, izmantojot dažādus transformēšanas

šablonus:

apvienotas tabulas (angļu val. single table) izmantošana – visu tipu objekti tiks

glabāti vienā tabulā;

konkrētas tabulas (angļu val. concrete table) izmantošana – katrai klasei, kurai ir

iespējams izveidot eksemplāru ir sava unikālā tabula;

klases tabulas (angļu val. class table) izmantošana – katrai klasei, gan abstraktai,

gan ne abstraktai, ir sava unikālā tabula.[1,2]

Katram variantam ir savas priekšrocības un trūkumi. Izgūto datu bāzes struktūru

vērtēšanai var tikt izmantoti tādi kritēriju kā:

1) dublēto datu apjoms;

2) datu izgūšanas ātrums.[2]

Klases tabulas mantošanai ir vienkāršākas attiecības starp klasēm un tabulām, bet, lai

izgūtu vai ievietotu vienu objektu, ir nepieciešamas vairākas tabulu apvienošanas operācijas,

kas parasti samazina veiktspēju.[2]

Konkrētas tabulas mantošanai nav nekādu tabulu apvienošanas operāciju, kas ļauj

izgūt veselu objektu uzreiz no vienas tabulas. No otras puses, šis šablons ir grūti izmaināms.

Veicot izmaiņu virsklasē, to ir nepieciešams manuāli pārnest visās tabulās. Izmaiņas pašā

hierarhijā var novest pie lielākām problēmām. Turklāt superklases tabulas neesamība var

pagrūtināt primāras atslēgas vadību.[2]

Vienas tabulas mantošanas lielākais trūkums ir atmiņas zudums, tā kā katrai rindai ir

kolonnas katram iespējamam apakštipam, rezultātā parādās tukšas kolonnas. Vēl viens

trūkums ir tabulas izmērs.[2]

Visas iespējas nav savstarpēji izslēdzošas, un vienā hierarhijā šos šablonus var

kombinēt. Protams, tas palielina sarežģītību.Starp visām stratēģijām, nav skaidro uzvarētāju.

Stratēģiju izvēlei ir jāņem vērā gan tekoši apstākļi, gan izstrādātāja priekšrocības.[2]

29

2.1. att. Klašu modeļa transformācija uz datu bāzes struktūru, izmantojot a)apvienotu tabulu, b)konkrētas tabulas un c)klases tabulas

30

2.1.1. Apvienotas tabulas izmantošana

Ka bija minēts iepriekš, šis paņēmiens reprezentē klases hierarhiju vienā tabulā, kurā

ir kolonnas priekš katrai apakšklasei. 2.2. att ir parādīts, kāda tabula veidojas no iepriekš

definētās klases modeļa. Tabulā ir pievienots lauks, kas identificē katru objektu. Katra

apakšklase glabā tikai būtisko sev informāciju vienā ieraktā, jeb rindā. Visas kolonnas, kas

neattiecas uz noteikto apakšklasi, tiek atstātas tukšas.[2]

Kad objekts ir ielādēts tabulā, ir nepieciešams zināt, kādam tipam atbilst šis objekts.

Tādēļ tabulā tiek pievienots papildlauks (cilvēkaTips 2.2. att.), kurš identificē objekta tipu. Šis

lauks var būt vai veselas apakšklases nosaukums, vai arī kaut kāds kods.[2] Piemērām, kods

Svarētu apzīmēt, ka cilvēks ir students. Cits kods, piemērām, P apzīmē pasniedzēju. Šī pieeja

ir vienkārša, bet var sastapt problēmas, kad apakštipu skaits palielinās. Vel vairāk problēmu

rodas, kad objekts var piederēt dažādiem apakštipiem vienlaicīgi. Piemērām, cilvēks var būt

students, kas mācās doktora studijās un vienlaikus pasniegt lekcijas. [1]

2.2. att. Mantošana realizācija

Kad ir saprotams, ka apakštipu skaits un apakštipu kombinācijas ir pietiekami lielas, ir

vērts aizstāt tipu identificējošu lauku ar individuālo tipu karogiem. Parasti šie karogi tiek

realizēti kā loģiskas (angļu val. boolean) kolonnas.[1]

Kopumā vienas tabulas pieejai ir sekojošas priekšrocības:

visa informācija ir glabāta vienā tabulā, kas atvieglo datu bāzes administrēšanu;

datu izgūšanai nav nepieciešams izmantot tabulu apvienošanas operācijas;

ja klases atribūti ir pārvietoti augstāk vai zemāk hierarhijā, tad nav

nepieciešamības veikt izmaiņas tabulas struktūrā;

31

ārējiem lietojumiem, piemērām, pārskatu serverim, ir vieglāk strādāt ar datiem, jo

tie atrodas vienā vietā.[2]

No otras puses, pieejai ir daži trūkumi:

ieraksta lauki dažreiz ir saistīti ar ierakstu un dažreiz nē, kas var sajaukt datu bāzes

lietotāju;

ierakstā neizmantotie lauki noved pie atmiņas zaudēšanas datu bāzē. Tomēr

mūsdienīgām datu bāzēm ir mehānismi, kas var samazināt šo trūkumu. Piemērām,

Oracle datu bāze ir ļoti efektīva zaudēto atmiņu apgriešanā;

vienotā tabula var būt ļoti liela ar augstu indeksu skaitu un biežo bloķēšanu, kas

var novest pie veiktspējas zuduma;

lauku nosaukumiem ir tikai viena vārdtelpa, kas var apgrūtināt tabulas

izveidošanu.[2]

2.1.2. Konkrētas tabulas izmantošana

Konkrētās tabulas mantošana izmanto dažādas tabulas katrai konkrētai klasei (par

konkrētu klasi ir domāta klase, no kuras tiek izveidoti objekti) hierarhijā. Katra tabula satur

tikai kolonnas saistītus ar attiecīgu apakšklasi un papildus, visas kolonnas no virsklasēm.

Tādēļ, virsklases atribūti tiek dubultoti katrā apakšklasē.[2] 2.3. att. ir ilustrēts, kādas tabulas

tiek izveidotas. Varam redzēt, ka katrā tabulā ir sava primārā atslēga.

Izmantojot šo pieeju, ir nepieciešams pievērst uzmanību primārām atslēgām. Problēma

ir tāda, lai primārās atslēgas būtu unikālas nevis starp ierakstiem vienā tabulā, bet ierakstiem

visā hierarhijā. Tas ir vajadzīgs, kad ir nepieciešams savākt informāciju par visiem objektiem

vienlaicīgi. Tādā gadījumā, ja primārās atslēgas nebūs unikālas visā hierarhijā, tad vienai

atslēgai atbildīs vairāki ieraksti.[2]

Bez tam, problēmas var rasties ar referenciālo integritātidatu bāzē. Piemērām, nav

iespējams izveidot attiecības ar abstrakto virsklasi, ja nav tabulas, kas attēlo virsklasi. Tādēļ ir

izvēle vai nu izvairīties no attiecībām ar abstrakto klasi, vai dublēt attiecības ar katru konkrēto

tabulu.[2]

32

2.3. att. Konkrētas tabulas mantošana realizācija (kopā ar ēnojuma informācijas)

Kopumā, pieejai ir sekojošas priekšrocības:

katra tabula ir autonoma un satur tikai būtiskās kolonnas;

lai izgūtu datus par konkrētajām apakšklasēm, nav nepieciešams izmantot tabulu

apvienošanas operācijas;

katra tabula tiek izmantota tikai tad, kad ir nepieciešama noteikta klase, kas

samazina tabulas izmantošanas slodzi;

ārējiem lietojumiem ir vieglāk strādāt, jo informācijas par konkrēto objektu atrodas

vienā vietā.[2]

Konkrētas tabulas mantošanas trūkumi:

var būt problēmas ar primārās atslēgas vadību;

nav iespējams izveidot attiecības ar abstrakto klasi;

ja klases atribūti ir pārvietoti augstāk vai zemāk hierarhijā, tad ir jāveic izmaiņas

visās tabulās;

ja virsklases atribūti ir izmainīti, ir jāizmaina kolonnas visās apakštabulās;

ja ir nepieciešams iegūt informāciju par dažādiem objektiem, ir nepieciešams

izpildīt dažādus vaicājumus vai izveidot sarežģītu vaicājumu.[2]

2.1.3. Klases tabulas izmantošana

Šai pieejai galvenā ideja ir tāda, ka katrai klasei ir sava tabula. Ir virsklases tabula, kas

satur kopīgu informāciju par visiem objektiem. Citas tabulas attēlo tikai informāciju par

noteiktu apakšklasi.[2] 2.4. att. ir attēlota fiziskā realizācija. Redzams, ka katrā tabulā ir

33

identifikators, kurš ir kopīgs visā hierarhijā. Šis identifikators kalpo gan par primāro atslēgu,

gan par ārējo atslēgu.

Pirmā pieejas problēma ir, kā sasaistīt atbilstošas rindas dažādās tabulās. Iespējamais

risinājums ir kopīga primārā atslēgas izmantošana. Piemērām, ja virsklases tabulā ir ieraksts

ar atslēgu 201 un apakšklases tabulā arī ir ieraksts ar atslēgu 201, tad abi ieraksti apraksta

vienu un to pašu objektu. Tā kā virsklases tabula glabā informāciju par visiem objektiem, tad

primārās atslēgas būs unikālas visā hierarhijā.[2]

2.4. att. Klases tabulas mantošana realizācija (kopā ar ēnojuma informācijas)

Nākamā problēma ir datu izgūšana. Tā kā dati par vienu objektu glabājas dažādās

tabulās, tad, lai savāktu visu informāciju, ir nepieciešams izmantot tabulu apvienošanas

operācijas vai izsaukt tabulas dažas reizes. Abi risinājumi noteikti samazina datu izgūšanas

ātrumu.[2]

Kopumā, pieejai var uzskatīt sekojošas priekšrocības:

katra tabula satur tikai būtiskas kolonnas;

attiecība starp klases modeli un datu bāzes struktūru ir vienkārša;

ir viegli modificēt superklasi un pievienot jaunās apakšklases.[2]

Klases tabulas mantošanas trūkumi:

lai izgūtu informāciju par objektu, ir nepieciešamas izmantot tabulu apvienošanas

operācijas;

ja klases atribūti ir pārvietoti augšāk vai zemāk hierarhijā, tad ir jāveic izmaiņas

visās tabulās;

ārējiem lietojumiem ir grūtāk strādāt, tā kā informācija par objektu glābājas

dažādās vietās.[2]

34

Klases tabulas mantošanu var uzlabot, pievienojot superklasei papildlauku, kas

identificē objekta tipu vai individuālo tipu karogiem, līdzīgi kā vienas tabulas mantošanā. Tas

var atvieglot vaicājuma izveidošanu.[1]

2.1.4. Šablonu salīdzinājums

Katram šablonam ir savas priekšrocības un trūkumi. Tomēr var secināt, ka katram

šablonam ir piemierotākā situācija izmantošanai:

apvienotu tabulu ir labāk izmantot, kad klases hierarhija ir pietiekami vienkārša un

nav apakštipu pārklāšanās;

konkrētas tabulas ir piemierotākas, kad apakštipu pārklāšanās ir reta;

klases tabulas ir jāizmanto, kad ir liels apakštipu pārklāšanās skaits un tipu izmaiņa

ir bieža.[1]

2.2. Mantošana realizāciju objektu – relāciju datu bāzē

Transformācija no UML klases diagrammas uz objektu - relāciju datu bāzes fizisko

modeli, sastāv no 2 posmiem[4], kuri ir redzami 2.6. attēlā:

1) transformācija no klašu diagrammas uz objektu tipa diagrammu;

2) transformāciju no objektu tipa diagrammas uz objektu – relāciju fizisko modeli.

2.2.1. Transformācija no objekta uz objektu – relāciju komponentiem

Klases no UML diagrammas ir attēloti uz objektu tipiem. Klases atribūti ir attēloti kā

objektu tipa atribūti. Klases metodes ir attēlotas kā objekta tipa metodes. Ja klase ir definēta

kā abstraktā, tad izveidotais objektu tips būs NOT INSTANTIABLE (bija apskatīts 1.

nodaļā).[4]

Ja ir definēta hierarhija, tad šai hierarhijai jāpastāv arī objektu tipiem. Piemēram, klašu

diagrammā klase A ir klases B apakšklase. Tad objektu tipu diagrammā, objektu tips A`, kurš

attēlo klasi A, būs objektu tipa B`, kurš savukārt, attēlo klasi B, apakštips.

2.2.2. Transformāciju no objektu – relāciju komponentiem uz objektu – relāciju tabulām

Kad objektu tipu diagramma ir izveidota, tad ir jādefinē tabulas, kur šie objekti tiks

glabāti. Parasti katram objektu tipam ir definēta sava tabula, kur šie objektu tipa eksemplāri

tiek glabāti.[4]

35

36

2.5. att. Klašu diagrammas transformāciju uz datu bāzes struktūru37

Tomēr, ja ir definēta tipu hierarhija, tad tabulu izveidošana kļūst nedaudz sarežģītāka.

Līdzīgi kā relāciju datu bāzes gadījumā, eksistē 3 iespējas, kā var realizēt mantošanu:

1) tabulas ar nehomogēniem objektiem izmantošana (bija apskatītā 1. nodaļā). Tabula

tiek izveidota tikai virstipam, un, pateicoties tipu aizvietošanai, tabulā tiek glabāti

arī apakštipa eksemplāri;

2) vertikālā sadalīšana. Katram objektu tipam tiek izveidota sava tabula. Šīm tabulām

ir aizliegta tipu aizvietošana, tādēļ katrā tabulā glabājas tikai piemēroti objekti tipi;

3) horizontālā sadalīšana. Tabulas ir izveidotas tikai apakštipiem, pārsūtot tām visus

virstipa atribūtus. Tipu aizvietošanas iespēja ir izslēgta.[4]

2.3. Dažādu mantošanas veidu realizācija, izmantojot objektu – relāciju struktūras

Pastāv, dažādas mantošanasveidi – daudzlīmeņu, hierarhiskā, savstarpēji izslēdzošā

u.t.t. Tomēr, nav nekādas metodes, kura nosaka, ka pareizi var realizēt visas mantošanas

veidus. Parasti, pats izstrādātājs izdomā savas realizācijas. Tālāk nodaļā, ir aprakstītas idejas,

ka var realizēt mantošanu, izmantojot objektu – relāciju struktūras.

2.3.1. Vienkāršā mantošana

Vienkāršā (angļu val. single) mantošana – vispārīgā mantošanas veids, kad 1 apakštips

ir mantots no 1 virstipa. Uz 2.6. att. ir parādīts vienkāršas mantošanas piemērs.

2.6. att. Vienkārša objekta tipu mantošana

38

Lai to realizētu objektu – relāciju datu bāzē, tiek izveidoti 2 objektu tipi un izmantotā

1 tabula (tabula ar nehomogeniem objektiem). Šajā tabulā glabāsgan Darbinieka_tipa

eksemplāri, gan Vadītāja_tipa eksemplāri. Skripts, kurš definē tipu hierarhiju un tabulu, ir

apskatāms 2.7. att.

2.7. att. Vienkārša objekta tipu mantošanas realizācija

2.3.2. Daudzlīmeņu mantošana

Apakštips var būt mantots ne tikai no virstipa, bet no cita apakštipa. Šajā gadījumā

tiek veidota daudzlīmeņu (angļu val. multilevel) mantošana. Piemērs ir redzams uz 2.8. att.

2.8. att. Daudzlīmeņu objekta tipu mantošana

39

Objektu – relāciju datu bāzē, lai attēlotu daudzlīmeņu mantošanu, ir jāveido tipu

hierarhija. Lai glabātu objektu eksemplārus, var būt izmantoti daži paņēmieni. Šeit piemēra,

katrs objekta tipa eksemplārs glabās savā tabulā, t.i., būs izveidotas 3 tabulas. Uz 2.9. att. ir

parādīts realizācijas skripts.

2.9. att. Daudzlīmeņu objekta tipu mantošanas realizācija

2.3.3. Hierarhiskā mantošana

No viena virstipa, var būt izveidoti vairāki apakštipi. Ja apakštipu daudzums ir lielāks

par 1, tad šādu mantošanu sauc pār hierarhisko (angļu val. hierarhical) mantošanu, kuru var

apskatīt uz 2.10. att.

2.10. att. Hierarhiskā objekta tipu mantošanaObjektu – relāciju datu bāzē, šādu mantošanu var realizēt izmantojot datu mantošanas

mehānismu. Katram tipam būs sava tabula. Rezultātā, vaicājot virstipu tabulai, būs atgriezti

visi objektu tipu eksemplāri. Tomēr, vaicājot kādai no apakštipu tabulai, būs atgriezti tikai tā

tipa eksemplāri. Realizācijas skripts ir parādīts uz 2.11. att.

40

2.11. att. Hierarhiskā objekta tipu mantošanas realizācija

2.3.4. Savstarpēji izslēdzošā mantošana

Savstarpēji izslēdzošā (angļu val. mutual – exclusion), ir tāds mantošanas veids kad,

virstipa eksemplārs nevar piederēt vairākiem apakštipa eksemplāriem, un virstipa eksemplārs

var nepiederēt nevienam no apakštipam. Savstarpēji izslēdzošās mantošanas piemēru var

apskatīt uz 2.12. att. Darbinieks var būt programmētājs, sekretāre, vai parasts Darbinieks.

2.12. att. Savstarpēji izslēdzošā objekta tipu mantošanaObjektu – relāciju datu bāzē šo mantošanu var realizēt izmantojot tabulu ar

nehomogeniem objektiem. Ar virstipa lauku ID tiek kontrolēts, ka eksemplārs var piederēt

41

tikai vienam tipam - vai nu virstipam, vai apakštipam. Realizācijas skripts ir redzams uz 2.13.

att.

2.13. att. Savstarpēji izslēdzošā objekta tipu mantošanas realizācija

2.3.5. Pārklāšanās tipa mantošana

Pārklāšanās tipa mantošana (angļu val. overlapping) – katram bāzes klases

eksemplāram var atbilst vairāki apakšklašu eksemplāri. Piemērs ir redzams uz 2.14. att.

2.14. att. Pārklāšanās objekta tipu mantošanaLai realizētā šādu mantošanu objektu – relāciju datu bāzē, tikt izmantots datu

mantošanas mehānisms. Katram tipam ir izveidotās atsevišķas tabulas. Rezultātā, objektu tipu

eksemplārs var būt pievienots gan Studentu tabulai, gan Pasniedzēju tabulai. Šiem

eksemplāriem, būs vienāds ID, kas parādā to, ka eksemplārs pieder gan Studenta_tipam, gan

Pasniedzēja_tipam. Uz 2.15. att. var apskatīt skriptu, kas realizē šādu mantošanu.

42

2.15. att. Pārklāšanās objekta tipu mantošanas realizācija

2.4. Kopsavilkums

Var redzēt, ka transformācija no UML klases diagrammas uz relāciju fizisko modeli

ietver tikai 1 soli. Savukārt transformācija no UML klases diagrammas uz objektu - relāciju

fizisko modeli ietver jau 2 soļus. Papildu solis ir nepieciešams, lai izveidotu objektu tipus.

Tomēr solis, kur notiek tieša fiziska modeļa izveidošana, ir līdzīga abām datu bāzēm.

Gan relāciju datu bāzē, gan objektu – relāciju datu bāzē pastāv 3 iespējas, kā izveidot tabulas

mantošanas glabāšanai:

apvienotas tabulas izmantošana ir līdzīga tabulai ar nehomogēniem objektiem

izmantošanai, kur glabāšanā tiek izveidota tikai 1 tabula;

konkrētas tabulas izmantošana ir līdzīga vertikālai sadalīšanai. Šajā pieejā tabulas

ir izveidotas katram objektu tipam vai klasei;

klases tabulas izmantošana ir līdzīga horizontālai sadalīšanai. Katram apakštipam

vai klasei ir sava unikālā tabula.

Šeit tiek pieradīts, ka objektu – relāciju datu bāzes pamatā ir relāciju datu bāze.

Objektu tehnoloģijas (šajā gadījumā mantošana) tiek iekļautās relāciju datu bāze, saglabājot

relāciju īpašības. Bet ar objektu – relāciju struktūrām var veidot dažādu veidu mantošanas, kas

bija grūti relāciju datu bāzē.

43

3. DATU BĀZES UN LIETOJUMA OBJEKTU SASKAŅOŠANA

3.1. JDBC dzinis

JDBC dzinis (angļu val. driver) ir lietojumu programmu interfeisa specifikācija, kurš

izveido savienojumu ar datu bāzi. Tās piedāvā iespēju viegli savienot Java lietojumu ar plašo

datu bāzes klāstu[5,14]. JDBC ir definēts 2 bibliotēkās:

java.sqlnodrošina API datu bāzes datu piekļūšanu un apstrādi izmantojot Java

valodu;

javax.sqlpiedāvā paplašinātās iespējas.

JDBC ir firmas Sun Microsystems mēģinājums platformas neatkarīgu saskarni starp

datu bāzi un Java lietojumu[14].

Java lietojums izmanto JDBC, lai darbotos ar datu bāzi, nezinot konkrētu JDBC

implementāciju[14]. 3.1. att. parāda galvenās JDBC klases un saskarnes.

3.1. att. JDBC saskarnes galvenās komponentes Java lietojums izmanto DriverManager klasi, lai izveidotu java.sql.Connection

objektu, kurš reprezentē datu bāzes savienojumu. Tālāk, izmantojot Connection objektu, ir

iespējams izveidot vaicājuma objektu[5,14]. Pastāv 3 vaicājuma objekti:

1) Statement saskarne – tiek izmantota, lai izveidotu statisku SQL vaicājumu;

2) PreparedStatement saskarne – paplašina Statement saskarni un reprezentē

dinamisko SQL vaicājumu, kuram ir parametri;44

3) CallableStatement saskarne – tiek izmantota, lai izsauktu datu bāzes iekļautās

procedūrās.

Ja vaicājumam ir rezultāts, tad tiek izveidots ResultSet objekts, kur tiek glabāts

rezultāts.[5,14]

Uz 3.2. att. ir parādīts, ka izskatās informācijas sistēmas arhitektūra. Informācijas

sistēmu veido 3 sastāvdaļas – lietojuma serveris, datu bāzes sistēma un saskarne, kas savieno

Lietojuma serveri ar datu bāzes sistēmu. Pats lietojums savstarpēji iedarbojas tikai ar JDBC

saskarni. JDBC saskarne var nolasīt un ierakstīt datus datu bāzē. Papildus, JDBC var nolasīt

datu bāzes metadatus.

3.2.att. Informācijas sistēmas arhitektūraEksistē 2 iespējas, ka var izveidot Java programmu, kura sadarbojas ar datu bāzi:

1) Ka ārējo lietojumu, jeb klienta pusē;

2) Ka datu bāzē glabājamo procedūru, jeb servera pusē[12].

Ja programma ir glabātā lietojuma serverī, tad to izsauc un izpilda pats lietojuma

serveris. Ja programma atrodas datu bāzē, tad lietojums to tikai izsauc, ar JDBC saskarnes

palīdzību. Izpilde, notiek pašā datu bāzes serverī. Lietojumam, tiek atgriezts tikai programmas

rezultāts.

JDBC atbalsta strukturēta objekta izmantošanu datu bāzē, kur objekta datu tips ir

lietotāju definētais tips ar iekļautiem atribūtiem (kas bija apskatīts 1. nodaļā). Rezultātā,

objekti ir gan objektu – relāciju datu bāzē, gan objektorientētā lietojumā. Šeit izspaužas

problēma, ka šie objekti nav vienādi, jo datu bāzes vide atšķiras no objektorientētas lietojuma

vides. Strādājot ar datu bāzes objektu datu tipiem Java lietojumā, ir svarīgi apdomāt sekojošas

lietas:

1) Kā transformēt datu bāzes datu tipus programmēšanas valodas Java klasēs un

otrādi;

2) Kā glābāt datu bāzes objekta atribūtus atbilstošā Java objektā;

3) Kā pārveidot datus starp SQL un Java formātiem;

45

4) Kā piekļūt pie datiem.

Datu bāzes objekti var būt attēloti izmantojot 2 pieejas:

1) vāji tipizētās noklusētās Java klasesm kas implementē java.sql.Structsaskarni;

2) stipri tipizētas pašveidotās Java klases, kuras implementē

java.sql.SQLDatasaskarni. Katra saskarne deklarē metodes datu konvetēšanai

starp SQL un Java.

3.2. Vājitipizētāsklases izmantošana

Termins “vāji tipizēta klase” atsaucas uz objektu, kas implementē JDBC standartu

saskarni java.sql.Struct[10,11](turpmāk tiek nosaukts, ka Struct objekts). Struct objekta

darbība ir attēlotā uz 3.3. att. Struct objekts attēlo jebkura datu bāzes objekta tipu.

3.3.att. Vāji tipizētās klases darbībaBūtībā datu bāzes objekts tiek attēlots kā atribūtu kolekcija. Šie atribūti tiek glabāti

java.lang.Objectmasīvā, kur katrs atribūts ir Java objekts. Pēc noklusējuma atribūta klases

ir bāzētas uz SQL datu tipu un Java klašu attēlošanu, kas ir specificēts tabulā Noklusējamā

tipu attēlošana karte. Java objektu atribūtu kārtība ir tāda pati, kāda bija atribūtiem datu bāzes

objekta tipu deklarācijas laikā[10].

Vājo tipizēto klasi labāk izmantot 2 gadījumos:

lietojums, izgūstot datu bāzes objektus, nepārveido atribūtus kādā cita tipā,

piemēram, cita klasē,

lietojums neveic lielu atmiņas apstrādes apjomu, šim nolūkam ir ieteicams

izmantot stipri tipizēto Java klasi[10].

3.2.1. Struct saskarnes darbība

Struct objekts satur masīvu, kur atsevišķi glabājas katrā atribūtu vērtībā. Šis objekts

implementē java.sql.Structsaskarni. Saskarnei ir 3 standarta metodes, kuras atbilst JDBC

2.0 standartam[10,11]:

1) public Object[] getAttributes(Map map) throws SQLException– šī

metode atgriež atribūtu vērtības, izmantojot specifisku tipu attēlošanas tabulu, kurš

46

tiek asociēts ar Connection objektu. Ja Connection objektam nav specifiskas tipu

attēlošanas tabulas, tad dzinis izmanto standartu, kurš ir dots tabulā Noklusējamā

tipu attēlošana karte[10];

2) public Object[] getAttributes() throws SQLEcexption–šī metode ir

līdzīgā getAttributes (Map map)metodei, izņemot to, ka tās izmanto standartu

tipu attēlošanas tabulu, kura ir dota tabulā Noklusējamā tipu attēlošana karte[10];

3) public String getSQLTypeName() throws SQLException– šī metode atgriež

simbolu virkni, kas attēlo pilno datu bāzes objekta tipa nosaukumu, kuru šīs Struct

attēlo[10].

java.sql.Structsaskarne ne definē nekādas metodes, lai izveidotu savu Struct

objektu Java lietojumā[10]. Tās ir liels trūkums, jo nav nekādas iespējas ielādēt objektus datu

bāzē. Turklāt ir iespēja izmantot relācijas datu manipulēšanas valodu, lai ielādētu objekta

datus datu bāzē.

Noklusējamā tipu attēlošana karte

N.p.k. SQL datu tips Standarts Java tips

8. CHAR

VARCHAR2

LONG

java.lang.String

9. NUMBER java.math.BigDecimal

byte short int long

float double

10. RAW

LONGRAW

byte[]

11. DATE java.sql.Date

java.sql.Time

12. BLOB java.sql.Blob

13. CLOB java.sql.Clob

3.2.2. Struct objektus un atribūtus izgūšana

Lai detalizētu datu izgūšanu no Struct objekta tipa eksemplāra, tiek izveidots piemērs.

Ir izveidota objektu – relācijutabula ar sekojošu struktūru, kura ir parādīta uz 3.4. att.:

1) kolonna BD_ID satur bakalaura darba primāro atslēgu, un tās tips ir NUMBER;

47

2) kolonna BD_NOS satur bakalaura darba nosaukumu latviešu valodā, un tās tips ir

VARCHAR2(50);

3) kolonnas BD_AUT un BD_VAD satur atbilstoši bakalaura darba autoru un

zinātnisko vadītāju. Abām kolonnām tips ir objektu tips CILVEKS_T, kurš sastāv

no 3 atribūtiem – vārds, uzvārds, personas_kods;

Uzdevums ir izvadīt informāciju par bakalaura darbu ekrānā.

3.4. att. Objektu – relāciju tabula, kur glabās informācija par bakalaura darbiemUz 3.5. att ir parādīta tabulu izveidošana un datu sagatavošana.

3.5. att. Objektu – relāciju tabulas izveidošanaTālāk, Eclipse vidē, tiek izveidots vienkāršais lietojums, kurš atguva 1 rindu, un

izvada to.publicclass VajiTipizetaKlase {

48

publicstaticvoid main(String[] args) {try{

/* Tiek izveidots Oracle specifisks savienojuma un vaicājuma objekts */OracleDataSource datuAv = new OracleDataSource();

datuAv.setURL("jdbc:oracle:thin:DB_131RDB357/DB_131RDB357@85.254.218.

228:1521:DITF11");

Connection conn = datuAv.getConnection();

Statement stmt = conn.createStatement();

/* Rezultāta objektu izveidošana un vaicājuma izpildē */ResultSet rs = stmt.executeQuery("selectBD_ID, BD_NOS,

BD_AUT,BD_VAD from BAKALAURAS_DARBI where BD_ID = 2");

rs.next();

/* Relāciju datu izgūšana */intbd_id = rs.getInt(1);String bd_nos = rs.getString(2);

/* Objekta eksemplāru izgūšana, un tā ievietošana iekš Struct objektā*/java.sql.Struct StructAUT = (java.sql.Struct) rs.getObject(3);

java.sql.Struct StructVAD = (java.sql.Struct) rs.getObject(4);

/* No Struct objekta tiek izgūti atribūti iekš Object masīvā */Object[] AUT_attr = StructAUT.getAttributes();

Object[] VAD_attr = StructVAD.getAttributes();

/* Atribūti tiek pārveidoti vajadzīgos Java tipos */String AUT_vards = (String) AUT_attr[0];

String AUT_uzvards = (String) AUT_attr[1];

String VAD_vards = (String) VAD_attr[0];

String VAD_uzvards = (String) VAD_attr[1];

/* Rezultātu izvade un objektu aizvēršana*/System.out.println("Bakalaura darba nosaukums - " + bd_nos + " Autors - " + AUT_vards + " " + AUT_uzvards+ " Vaditājs - " + VAD_vards

+ " " + VAD_uzvards);

stmt.close();

conn.close();49

rs.close();

} catch (SQLException e) {System.err.println(e.getMessage());

} } }

Iegūtais rezultāts ir redzams 3.6.att.

3.6. att. Vāji tipizētās klases izmantošanas rezultāts

3.3. Stipri tipizētās klases izmantošana

Stipri tipizētā klase, ir pašizveidotā Java klase, kura attēlo datu bāzes objektu. Citiem

vārdiem, katrs datu objekta tips ir attēlots uz noteiktu Java klasi. Tomēr nav pietiekami tikai

izveidot klasi, JDBC dzinis ir jāzina 3 lietas:

kādai klasei atbilst noteikts datu bāzes objekta tips;

kādas Java klases ir jāizmanto, lai attēlotu objekta atribūtus;

kā dzinis var nolasīt no Java klases un kā ierakstīt Java klasē[10].

Visam šim nolūkam ir izstrādāta java.sql.SQLDatasaskarne.

3.3.1. SQLData saskarne

Uz 3.7. att. ir paradīts, ka darbojas stipri tipizētā klase. Klasei izveidošanai tiek

izmantota SQLData saskarne, un ir nepieciešams izveidot tipu attēlošanas tabulu ar kuru

palīdzību datu bāzes objektu tipu būs attēloti uz Java[12].

3.7.att. Stipri tipizētās klases darbība

Kad objekts tiek izgūts vai ielādēts datu bāzē, JDBC dzinis izsauc metodi

getSQLTypeName() no Java klases, kurš implementē SQLDatasaskarni, lai zinātu kādam

50

Oracle objektu tipam atbilst konkrēta Java klase. Tālāk, pats dzinis, izmantojot izveidotu tipu

attēlošanas tabulu, izpildi transformāciju starp SQL un Java formātiem[12].

Eksistē 2 iespējas, ka var izveidot savu tipu attēlošanas tabulu:

1) izveidot savu klasi, kurš implementē java.util.Mapsaskarni;

2) izmantot gatavu klasi java.util.Hashtable.[12]

Šī klase un saskarne implementē, put() metodi, kura saņem atslēgu-vērtību pāri kā

ievadi, kur atslēga atbilst SQL tipa nosaukumam un atbilstoša vērtība ir noteiktas Java klases

eksemplārs. Tipu attēlošanas tabulu ir asociētā ar savienojuma eksemplāru. Gan standarta

java.sql.Connection saskarne, gan oracle.jdbc.OracleConnection saskarne ietver

getTypeMap metodi, kura atgriež Map objektu.[12]

Lai asociētu tipu attēlošanas tabulu ar savienojuma eksemplāru, var izmantot 2

pieejas:

1) pievienot ierakstus esošai tipu attēlošanas tabulai. Vispirms ar metodi

getTypeMap() iegūstam esošu tipu attēlošanas tabulu un ar metodi put()

pievieno tai jaunus ierakstus;

2) izveidot jaunu tipu attēlošanas tabulas eksemplāru, pievienot tai ierakstus ar put()

metodi un ierakstīt jaunu tipu attēlošanas tabulu savienojuma objektam ar

setTypeMap() metodi.[12]

Ja stipri tipizētas klases izveidošanai ir izmantota SQLData saskarne, tad tai ir

jāimplementē sekojošas metodes:

1) getSQLTypeName(),kura tika apskatīta iepriekš;2) writeSQL();

3) readSQL().

writeSQL() metodi izmanto JDBC dzinis, lai ierakstītu datus datu plusmā no

pašveidotās Java klases eksemplāra, kura tālāk būs ierkastīta datu bāzē. Dzinis automatiski

izsauc šo metodi, ka ir izsaukta setObject() metode.[12]

readSQL() metodi izmanto JDBC dzinis, lai nolasītu datu plūsmu no datu bāzes, un

ieliek tos pašveidotās Java klases eksemplāra.Dzinis automātiski izsauc šo metodi tāpat kā ir

izsaukta getObject() metode.[12]

Tālāk tiek detalizētāk paradīts, ka var iegut un ierkastīt objektus, izmantojot SQLData

saskarni. Ir izveidots objektu tips STUDENTS_T ar sekojošiem atribūtiem – vārds, uzvārds,

st_apl_num, kurss un vid_atzime. Uz att. 3.8. ir paradīts, kādā veidā tiek definēts objektu tips

un tabula, kur glabās objekta tipa eksemplāri.

51

3.8. Objektu tabulas izveidošanaTālāk, es izveidošu savu stipri tipizēto klasi.

/* Klašu atribūtu definīcija. Atribūtu atbilst izveidotam objektu tipam. Atribūts

typeName norāda, kādu objektu tipu attēlo klase */publicclass Students implements SQLData{

privatefinal String typeName="STUDENTS_T";private String vards;private String uzvards;private String st_apl_num;privateint kurss;privatefloat vid_atzime;

/* Trīs vajadzīgo metožu pārrakstīšana */public String getSQLTypeName() throws SQLException {

return typeName;}

publicvoid readSQL(SQLInput inStream, String typeName) throwsSQLException {

vards = inStream.readString();uzvards = inStream.readString();st_apl_num = inStream.readString();kurss = inStream.readInt();vid_atzime = inStream.readFloat();

}

publicvoid writeSQL(SQLOutput outStream) throws SQLException {outStream.writeString(vards);outStream.writeString(uzvards);outStream.writeString(st_apl_num);outStream.writeInt(kurss);outStream.writeFloat(vid_atzime);

}

/* Papildus, ir definēts konstruktors, lai izveidotu objekta eksemplāru un informācijas

izvadīšanas metode*/public Students(String vards, String uzvards, String st_apl_num, intkurss, float vid_atzime) {

this.vards = vards;

52

this.uzvards = uzvards;this.st_apl_num = st_apl_num;this.kurss = kurss;this.vid_atzime = vid_atzime;

}

public String toString() {return kurss+". kursa students: "+vards+""+uzvards;

}

/* Savienojuma objekta izveidošana un tipu attēlošanas karti atjaunošana, lai dzinis

zinātu, kādam objektu tipam atbilst izveidota klase*/OracleDataSource datuAv = new OracleDataSource();datuAv.setURL("jdbc:oracle:thin:DB_131RDB357/DB_131RDB357@85.254.218.228:1521:DITF11");Connection conn = datuAv.getConnection();Map typeMap = conn.getTypeMap();typeMap.put("STUDENTS_T", Class.forName("Students"));

/*Vaicājuma objekta un rezultāta objekta izveidošana. Iegūtais rezultāts tiek attēlots*/Statement stmt = conn.createStatement();ResultSet rs = stmt.executeQuery("select * from STUDENTI");Students s=null;if (rs != null) {

while (rs.next()) {s = (Students)rs.getObject(1);}

}System.out.println(s);

/* Iegūtais rezultāts */

3.9. att. Objektu izgūšana rezultātsLai ierakstītu objektu tipa eksemplāru, ir jāveido tāds pats savienojuma objekts un

atjaunot tipa attēlošanas karti. Bet jāveido cits vaicājuma objekts. Rezultāta objekta nebūs, jo

vaicājumam nav nekāda rezultāta.

/* Objekta un vaicājuma objekta izveidošana. Vaicājuma izpildīšana.*/Students s=new Students("Dmitrijs","Koks","131RDB358",3,(float)9.5);PreparedStatement stmt = conn.prepareStatement("insert into STUDENTI values(?)");stmt.setObject(1, s);stmt.executeQuery();Tagad apskatīsim datu bāzes tabulu, lai pārliecinātos, ka ierakstīšana ir veiksmīga.

3.10. att. Objektu ierakstīšanas rezultāts

53

4. OBJEKTU – RELĀCIJU DATU BĀZES REALIZĀCIJA

Ir izveidota datu bāze, kurā glabās informāciju par augļu kokiem. Praktiski, šī datu

bāze bija izveidota, izmantojot relāciju struktūras. Lai apskatītu objektu – relāciju datu bāzes

izveidošanas procesu, tāda paša datu bāze, tiks izveidota, izmantojot objektu – relāciju

struktūras. Datu bāze ir izveidota, izmantojot DBVS Oracle 11g. Bakalaura darba ietvaros,

informācijas daudzums ir samazināts, salīdzinot ar reālo datu bāzi.

Uz 4.1. ir parādīta problēmsfēra. Katram augļu kokam ir sava ģints. Ģints sīkāk

iedalās sugās. Katrai sugai ir dažādi autori, glabāšanas dati un sugas tipiskie fenotipiskie dati.

Pie tā, fenotipiskie dati iedalās sīkākās grupās. Katrai sugai ir daudz paraugu. Paraugs ietver

sevī informāciju par ievākšanas vietu, atrašanās vietu un konkrētiem fenotipiskiem datiem.

Papildus, paraugs var piederēt kādam projektam.

4.1. Problēmsfēra

54

Lai realizētu problēmsituāciju, kas attēlota 4.1. att. relāciju objektu datu bāzes

variantā, bakalaura darba autors izstrādāja objektu - relāciju datu bāzes struktūru, kas redzama

4.2. att. Sākotnēji, tiks izveidoti visi primitīvie objektu tipu – Glabasanas_datu_tips,

Vietas_tips, Projekta_tips, Autora_tips. Tālāk, ar hierarhiskas mantošanas palīdzību, tiks

izveidoti Fenotipa_tips un visi apakštipi: Abeles_fenotipa_tips, Kirsu_fenotipa_tips,

Avenu_fenotipa_tips, Bumbiera_fenotipa_tips.

Tālāk, tiks veidots salikts objektu tips Parauga_tips. Tās satur informāciju par

paraugu, norādi uz attiecīgo projektu, un iekļauj sevī objekta tipu Vietas_tipa un

Fenotipa_tips eksemplārus.

Turpmāk, tiks veidots salikts objektu tips Sugas_tips. Tās ietver norāžu kolekciju uz

autoriem, norāžu kolekciju uz paraugiem un objekta tipu Glabašanas_datu_tips un

Fenotipa_tips eksemplārus.

No Sugas_tipa tiks izveidots objektu kolekcijas datu tips – Sugu_tips. Pēdējais objektu

tips, kas ir jāizveido, ir Ginta_tips. Tās satur ID, nosaukumu un objektu kolekciju Sugu_tips.

Papildus, Projekts_tipam ir metodes ilgums() un izmaksas_uz_dienu(). Pirmā

metode izvada projekta ilgumu dienās, otrā metode parāda dienas izmaksas. Sugas_tipam un

Ginta_tipam ir attiecīgi metodes paraugu_skaits()un sugu_skaits(). Metodes parāda, cik

daudz paraugu ir sugām un cik daudz sugu ir ģintij.

Nobeigumā, atliek izveidot tabulas, kur glabās objekti. No 4.2. att. ir redzams, ka būs

4 tabulas: tabula Projekti, kur glabās Projekta_tipa eksemplārs, tabula Paraugi, kur glabās

Parauga_tipa eksemplāri, tabula Autori ar Autora_tipa eksemplāriem un tabula Ginti,

Ginta_tipa eksemplāru glabāšanai.

Objekta tipu un tabulas realizācijas var apskatīt 1. pielikumā. Pielikumā ir testdatus

ievades vaicājumi.

55

4.2. att. Objektu – relāciju datu bāzes struktūraTālāk, tiek izveidoti dažādi vaicājumi, lai pārliecinātos, ka datu bāze strādā pareizi.

1. vaicājums.

Vaicājums, kas izvada visus projektus, un izsaukt tiem metodes.???select p.nosaukums, value(p).ilgums() "Ilgums",

value(p).izmaksas_uz_dienu() "Dienas izmaksas"

from Projekti p;

4.3. att. Pirmā vaicājuma rezultāts

Vaicājuma rezultāts ir patiess.

2. vaicājums.

Vaicājums, kas izvada visas ģintis, cik daudz sugu ģintij (izmantojot metodi

sugu_skaits()) un kādas sugas ir.selecta.nosaukums "Ģints",Value(a).sugu_skaits() "Sugu skaits",

b.nosaukums "Suga"

56

from ginti a, table(a.sugas) b;

4.4. att. Otrā vaicājuma rezultātsVaicājuma izvadītais numurs atbilst, patiesam sugu skaitam. Var secināt, rezultāts ir

patiess.

3.vaicājums.

Vaicājuma mērķis ir izvadīt visus autoru vārdus un uzvārdus, kuras atklāja Ābeli

Antonovku.selecta.nosaukums "Ģints", b.nosaukums "Suga", Value(c).vards

"Vārds",Value(c).uzvards "Uzvārds"

from ginti a, table(a.sugas) b, table(b.autori) c

where a.nosaukums='Abēle' and b.nosaukums = 'Antonovka';

4.5. att. Trešā vaicājuma rezultātsPārbaudot vaicājuma rezultātu, netika atrasta kļūda.

4. vaicājums.

Vaicājuma mērķis ir izvadīt, cik daudz paraugu ir katrai Bumbiera sugai. Šeit tika

izmantota metode paraugu_skaits().selectb.nosaukums "Suga", Value(b).paraugu_skaits() "Paraugu

skaits"

from ginti a, table(a.sugas) b

where a.nosaukums='Bumbiers';

4.5. Ceturtā vaicājuma rezultātsRezultāts atbilst patiesumam.

5. vaicājums

57

Vaicājums, kurš izvada Ābeles Golden sugas tipisko augļu izmēru, un katra parauga

konkrēto augļa izmēru, lai uzzināti, cik lielā mēra tās atšķiras no standarta.selectValue(c).ID "Parauga ID",

Value(c).parauga_fenotipskie_dati.aug_lielums "Parauga augla izmērs",

Value(b).sugas_fenotipiskie_dati.aug_lielums "Tipiskais augla izmērs"

from ginti a, table(a.sugas) b, table(b.paraugi) c

where a.nosaukums='Abēle' and b.nosaukums = 'Golden';

4.6. att. Piektā vaicājuma rezultāts

Aplūkot rezultātu, netika atrasta kļūda.

Visi vaicājumi, kuri bija izmantoti, lai pārbaudītu datu bāzes darbību, ir iekļauti 1.

pielikumā.

58

SECINĀJUMI

1.

2.

3.

...

59

LITERATŪRA

1. Ambler, S. Mapping Objects to Relational Databases: O/R Mapping In Detail [online].

2006 [viewed 3 March 2016] Available from:

http://agiledata.org/essays/mappingObjects.html

2. Fowler, M. Patterns of Enterprise Application Architecture. Addison-Wesley

Professional, 2003. 533 p. ISBN 978-0321127426.

3. Gaston, C.H. Learning Object-Oriented Programming. Birmingham: Packt Publishing,

2015. 280 p. ISBN 978-1-78528-993-4.

4. Golobiskym, M.F., Vecchietti, A. Fundamentals for the Automation of Object –

Relatioanl Database Design. International Journal of Computer Science Issues. May

2011, vol. 8, issue 3, no.2. e-ISSN 1694-0814.

5. Goodson, J., Steward. A.R. The Data Access Handbook: Achieving Optimal Database

Application Performance and Scalability. Prentice Hall, 2009. 360 p. ISBN: 978-

0137143931.

6. IBM. IBM DB2 10.5 for Linux, Unix and Windows documentation.

7. Jenkov, J. Java Language [online]. 2015 [viewed 15 February 2016] Available from:

http://tutorials.jenkov.com/java/index.html

8. Kendal, S. Object Orientied Programming using Java. Bookbon, 2009. 209 p. ISBN 978-

87-7681-501-1.

9. Melton, J., Eisenberg, A. SQL:1999, formerly known as SQL3.[online]. 1999 [viewed 15

March 2016] Available from: http://users.dcc.uchile.cl/~cgutierr/cursos/BD/standards.pdf

10. Menon, R.M. Expert Oracle JDBC Programming.New York: Apress, 2005. 744 p. ISBN

978-1-59059-407-0.

11. Mensah, K. Oracle Database Programming using Java and Web Services. Digital Press,

2006. 1120 p. ISBN: 978-1555583293.

12. Oracle. Database Java Developer's Guide.Oracle Database Online Documentation 12c

Release 1 (12.1)

13. Oracle. Database Object-Relational Developer's Guide.Oracle Database Online

Documentation 12c Release 1 (12.1)

14. Parsian, M. JDBC Recipes: A Problem-Solution Approach. New York: Apress, 2005. 636

p. ISBN: 978-1590595206.

15.

60

PIELIKUMI

61

1. pielikums

Objektu – relāciju datu bāzes realizācija

Objekta tipu izveidošanacreate or replace type Glabasanas_datu_tips as object(

klimata_tips varchar2(30),

teritorijas_tips varchar2(30),

augsnes_tips varchar2(30));

create or replace type Vietas_tips as object(

vieta varchar2(50),

g_garums varchar2(10),

g_platums varchar2(10));

create or replace type Autora_tips as object(

ID number,

vards varchar2(30),

uzvards varchar2(30),

amats varchar2(30));

create or replace type Projekta_tips as object(

ID number,

nosaukums varchar2(30),

pasutitajs varchar2(30),

izpilditajs varchar2(30),

sak_datums date,

beig_datums date,

izmaksas number,

member function ilgums return number,

member function izmaksas_uz_dienu return number);

create or replace type body Projekta_tips as

member function ilgums return number is

begin

return round(beig_datums-sak_datums);

end;

member function izmaksas_uz_dienu return number is

begin

return round(izmaksas/SELF.ilgums());

62

end;

end;

create or replace type Fenotipa_tips as object(

aug_lielums number,

aug_krasa varchar2(25))NOT FINAL;

create or replace type Avenu_fenotipa_tips under Fenotipa_tips(

gada__dzinumu_garums number);

create or replace type Abelu_fenotipa_tips under Fenotipa_tips(

ploiditate varchar2(30));

create or replace type Bumbieru_fenotipa_tips under Fenotipa_tips(

atzarosanas_tendence varchar2(30));

create or replace type Kirsu_fenotipa_tips under Fenotipa_tips(

hibrids char);

create or replace type Parauga_tips as object(

ID number,

nosaukums varchar2(30),

projekts ref Projekta_tips,

ievaksanas_vieta Vietas_tips,

augsanas_vieta Vietas_tips,

parauga_fenotipskie_dati Fenotipa_tips);

create or replace type autori_ref as table of

ref Autora_tips;

create or replace type paraugi_ref as table of

ref Parauga_tips;

create or replace type Sugas_tips as object(

ID number,

nosaukums varchar2(30),

autori autori_ref,

paraugi paraugi_ref,

dros_dublikata_vieta varchar2(30),

glabasanas_dati Glabasanas_datu_tips,

sugas_fenotipiskie_dati Fenotipa_tips,

63

member function paraugu_skaits return number);

create or replace type body Sugas_tips as

member function paraugu_skaits return number is

a number;

begin

select COUNT(*) into a FROM Ginti a, TABLE(a.sugas) b, Table

(b.paraugi) WHERE b.ID = SELF.ID GROUP BY b.ID;

return a;

end;

end;

create or replace type Sugu_tips as table of Sugas_tips;

create or replace type Ginta_tips as object(

ID number,

nosaukums varchar2(30),

sugas Sugu_tips,

member function sugu_skaits return number);

create or replace type body Ginta_tips as

member function sugu_skaits return number is

a number;

begin

select COUNT(*) into a FROM Ginti a, TABLE(a.sugas) b WHERE a.ID =

SELF.ID GROUP BY a.ID;

return a;

end;

end;

Tabulu izveidošana un testdatu pievienošana

create table Projekti of Projekta_tips(

primary key (ID));

insert into Projekti values(Projekta_tips(1,'Juglas meži','SIA

ABC','SIA Koki',

to_date('01/01/2016','dd/mm/yyyy'),to_date('01/06/2016','dd/mm/yyyy')

,10000));

64

insert into Projekti values(Projekta_tips(2,'Bolderājas

koki','RTU','SIA Mežs',

to_date('01/04/2015','dd/mm/yyyy'),to_date('01/01/2017','dd/mm/yyyy')

,45000));

insert into Projekti values(Projekta_tips(3,'Zala Jūrmala','LU','SIA

Ozols',

to_date('01/10/2015','dd/mm/yyyy'),to_date('01/01/2016','dd/mm/yyyy')

,1000));

create table Paraugi of Parauga_tips(

primary key (ID));

declare

ats1 ref Projekta_tips;

ats2 ref Projekta_tips;

ats3 ref Projekta_tips;

begin

select ref(p) into ats1 from Projekti p where p.ID=1;

select ref(p) into ats2 from Projekti p where p.ID=2;

select ref(p) into ats3 from Projekti p where p.ID=3;

insert into Paraugi values (Parauga_tips(1,'Ābeles Antonovkas

paraugs', ats1,

Vietas_tips('Rīga','55,75.1','60,20.1'),Vietas_tips('Jūrmala','56,60.

1','63,97.2'),

Abelu_fenotipa_tips(5,'sarkans','diploids')));

insert into Paraugi values (Parauga_tips(2,'Ābeles Antonovkas

paraugs', ats1,

Vietas_tips('Rīga','55,76.1','60,20.1'),Vietas_tips('Jūrmala','56,61.

1','63,97.2'),

Abelu_fenotipa_tips(4,'sarkans','diploids')));

insert into Paraugi values (Parauga_tips(3,'Ābeles Golden paraugs',

ats2,

Vietas_tips('Rīga','55,77.1','60,20.1'),Vietas_tips('Jūrmala','56,62.

1','63,97.2'),

65

Abelu_fenotipa_tips(8,'dzeltens','diploids')));

insert into Paraugi values (Parauga_tips(4,'Ābeles Golden paraugs',

ats2,

Vietas_tips('Rīga','55,78.1','60,20.1'),Vietas_tips('Jūrmala','56,63.

1','63,97.2'),

Abelu_fenotipa_tips(8,'dzeltens','diploids')));

insert into Paraugi values (Parauga_tips(5,'Ābeles Golden paraugs',

null,

Vietas_tips('Tukums','80,45.1','30,20.1'),Vietas_tips('Alūksne','46,6

0.1','79,97.2'),

Abelu_fenotipa_tips(9,'oranžs','diploids')));

insert into Paraugi values (Parauga_tips(6,'Bumbiera Conference

paraugs', ats3,

Vietas_tips('Daugavpils','67,75.1','40,20.1'),Vietas_tips('Rīga','59,

60.1','70,97.3'),

Bumbieru_fenotipa_tips(10,'zalš','vidēja')));

insert into Paraugi values (Parauga_tips(7,'Bumbiera Conference

paraugs', ats3,

Vietas_tips('Daugavpils','67,75.6','40,20.1'),Vietas_tips('Rīga','59,

57.1','70,97.4'),

Bumbieru_fenotipa_tips(11,'zalš','zema')));

insert into Paraugi values (Parauga_tips(8,'Bumbiera Conference

paraugs', ats3,

Vietas_tips('Daugavpils','67,76.1','40,20.1'),Vietas_tips('Rīga','59,

58.1','70,97.5'),

Bumbieru_fenotipa_tips(12,'zalš','vidēja')));

insert into Paraugi values (Parauga_tips(9,'Bumbiera Conference

paraugs', ats3,Vietas_tips('Daugavpils','67,76.6',

'40,20.1'),Vietas_tips('Rīga','59,59.1','70,97.6'),

Bumbieru_fenotipa_tips(11,'zalš','vidēja')));

insert into Paraugi values (Parauga_tips(10,'Bumbiera Viktorija

paraugs', null,

Vietas_tips('Liepāja','45,75.4','50,39.1'),Vietas_tips('Jūrmala','56,

63.1','63,99.2'),

66

Bumbieru_fenotipa_tips(6,'sarkans','augsta')));

end;

create table Autori of Autora_tips(

primary key (ID));

begin

insert into Autori values(Autora_tips(1,'Juris','Koks','profesors'));

insert into Autori values(Autora_tips(2,'Ivars','Berzs','biologs'));

insert into Autori values(Autora_tips(3,'Antons','Osis','biologs'));

insert into Autori values(Autora_tips(4,'Laila','Egle','docente'));

insert into Autori

values(Autora_tips(5,'Baiba','Ozole','profesore'));

end;

create table Ginti of Ginta_tips(

primary key (ID))

nested table sugas store as Sugas1

( NESTED TABLE autoriSTORE AS autori1,

NESTED TABLE paraugiSTORE AS paraugi1);

declare

atsA1 ref Autora_tips;

atsA2 ref Autora_tips;

atsA3 ref Autora_tips;

atsA4 ref Autora_tips;

atsA5 ref Autora_tips;

atsP1 ref Parauga_tips;

atsP2 ref Parauga_tips;

atsP3 ref Parauga_tips;

atsP4 ref Parauga_tips;

atsP5 ref Parauga_tips;

atsP6 ref Parauga_tips;

atsP7 ref Parauga_tips;

atsP8 ref Parauga_tips;

atsP9 ref Parauga_tips;

atsP10 ref Parauga_tips;

begin

select ref(a) into atsA1 from Autori a where a.ID=1;

67

select ref(a) into atsA2 from Autori a where a.ID=2;

select ref(a) into atsA3 from Autori a where a.ID=3;

select ref(a) into atsA4 from Autori a where a.ID=4;

select ref(a) into atsA5 from Autori a where a.ID=5;

select ref(p) into atsP1 from Paraugi p where p.ID=1;

select ref(p) into atsP2 from Paraugi p where p.ID=2;

select ref(p) into atsP3 from Paraugi p where p.ID=3;

select ref(p) into atsP4 from Paraugi p where p.ID=4;

select ref(p) into atsP5 from Paraugi p where p.ID=5;

select ref(p) into atsP6 from Paraugi p where p.ID=6;

select ref(p) into atsP7 from Paraugi p where p.ID=7;

select ref(p) into atsP8 from Paraugi p where p.ID=8;

select ref(p) into atsP9 from Paraugi p where p.ID=9;

select ref(p) into atsP10 from Paraugi p where p.ID=10;

insert into Ginti values (1, 'Abēle', Sugu_tips(Sugas_tips(1,

'Antonovka', autori_ref(atsA1,atsA2),

paraugi_ref(atsP1,atsP2),'LU Bioloģijas institūts',

Glabasanas_datu_tips('Piejūras', 'Mežs','Augnses tips 1'),

Abelu_fenotipa_tips(5, 'sarkans', 'diploids')), Sugas_tips(2,

'Golden', autori_ref(atsA1),

paraugi_ref(atsP3,atsP4,atsP5),'LU Bioloģijas institūts',

Glabasanas_datu_tips('Piejūras', 'Plava','Augnses tips 2'),

Abelu_fenotipa_tips(9, 'oranžs', 'diploids'))));

insert into Ginti values (2, 'Bumbiers', Sugu_tips(Sugas_tips(3,

'Conerence', autori_ref(atsA3,atsA5),

paraugi_ref(atsP6,atsP7,atsP8,atsP9),'Gaujas nacionālais parks',

Glabasanas_datu_tips('Piejūras', 'Smilts','Augnses tips 4'),

Bumbieru_fenotipa_tips(11, 'zalš', 'vidēja')), Sugas_tips(4,

'Golden', autori_ref(atsA4),

paraugi_ref(atsP10),'Gaujas nacionālais parks',

Glabasanas_datu_tips('Piejūras', 'Smilts','Augnses tips 6'),

Bumbieru_fenotipa_tips(5, 'sarkans', 'augsta')),Sugas_tips(5,

'Medus', autori_ref(atsA2),

null,'Lielupes nacionālais parks', Glabasanas_datu_tips('Mežs',

'Izcirtums','Augnses tips 1'),

Bumbieru_fenotipa_tips(12, 'dzeltens', 'zema'))));

68

insert into Ginti values (3, 'Avene', Sugu_tips(Sugas_tips(6,

'Saulīte', autori_ref(atsA1,atsA4),

null,'RTU MLKF', Glabasanas_datu_tips('Piejūras', 'Plava','Augnses

tips 3'),

Avenu_fenotipa_tips(1, 'roza', 6))));

end;

1.vaicājumsselect p.nosaukums, value(p).ilgums() "Ilgums",

value(p).izmaksas_uz_dienu() "Dienas izmaksas"

from Projekti p;

2.vaicājumsselecta.nosaukums "Ģints",Value(a).sugu_skaits() "Sugu skaits",

b.nosaukums "Suga"

from ginti a, table(a.sugas) b;

3.vaicājumsselecta.nosaukums "Ģints", b.nosaukums "Suga", Value(c).vards

"Vārds",Value(c).uzvards "Uzvārds"

from ginti a, table(a.sugas) b, table(b.autori) c

where a.nosaukums='Abēle' and b.nosaukums = 'Antonovka';

4.vaicājumsselectb.nosaukums "Suga", Value(b).paraugu_skaits() "Paraugu skaits"

from ginti a, table(a.sugas) b

where a.nosaukums='Bumbiers';

5.vaicājumsselectValue(c).ID "Parauga ID",

Value(c).parauga_fenotipskie_dati.aug_lielums "Parauga augla

izmērs", Value(b).sugas_fenotipiskie_dati.aug_lielums "Tipiskais

augla izmērs"

from ginti a, table(a.sugas) b, table(b.paraugi) c

where a.nosaukums='Abēle' and b.nosaukums = 'Golden';

69