RĪGAS TEHNISKĀ UNIVERSITĀTE Datorzinātnes un informācijas tehnoloģijas fakultāte Lietišķo datorsistēmu institūts Dmitriy Shulzhenko bakalaura 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ājs profesors, Dr.sci.ing. Jānis Eiduks
96
Embed
RĪGAS TEHNISKĀ UNIVERSITĀTE - Datu bāzes tehnoloģijas€¦ · Web viewRīgas Tehniskā universitāte. Datorzinātnes un informācijas tehnoloģijas fakultāte. Lietišķo datorsistēmu
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
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
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.
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
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
/* 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
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