rĪgas tehniskĀ universitĀte - datu bāzes tehnoloģijas€¦ · web viewrīgas tehniskā...
TRANSCRIPT
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/ [email protected]
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
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
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/[email protected].
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/[email protected]: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
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
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