RĪGAS TEHNISKĀ UNIVERSITĀTE

Datorzinātnes un informācijas tehnoloģijas fakultāte

Lietišķo datorzinātņu institūts

Praktiskais darbsmācību priekšmetā

“Multibāzes”Izkliedētas datubāzes

Izstrādāja: Katrīna Kronberga

1 (2.). kurss 3. grupa

Stud. apl. nr: 131RDB013

Rīga 2017

SatursIevads.................................................................................................................3

1 Izkliedētas datubāzes...................................................................................4

1.1 Izkliedētu datubāzu klasifikācija..........................................................5

1.2 Izkliedētu datu uzglabāšana..................................................................7

1.2.1 Datu replikācija..............................................................................7

1.2.2 Datu fragmentācija.........................................................................8

1.2.3 Datubāzes pārredzamība.................................................................8

1.2.4 Nosaukumu serveris.......................................................................9

1.2.5 Vietnes identifikatori......................................................................9

1.2.6 Aliasi............................................................................................10

2 Lokālā datubāze.........................................................................................11

2.1 Tabulu izveide un aizpilde lokālajā DB.............................................11

3 Ārējās datubāze..........................................................................................14

3.1 Datubāzes izveidošana un savienošana ar SQL Developer................14

3.2 Tabulu izveide un aizpilde ārējā DB..................................................17

4 Izkliedētās datubāzes izveidošana.............................................................19

4.1 Saites izveide starp lokālo un ārējo datubāzi......................................19

4.2 Datu izguve no ārējās datubāzes.........................................................21

4.3 Sinonīmu ieviešana.............................................................................24

Secinājumi........................................................................................................26

Izmantotā literatūra..........................................................................................27

1

Ievads

Šajā darbā tiek izpētīta pieejamā literatūra par izkliedētām datubāzēm, kā arī tiek izveidots

vienkāršs izkliedētas homogēnās datubāzes piemērs un izpētītas tā iespējas.

Pirmajā dokumenta daļā ir apkopota informācija par izkliedētajām datubāzēm; otrajā

aprakstītas abas datubāzu instances; trešajā izveidota izkliedētā datubāze un ar to veiktas darbība.

2

1 Izkliedētas datubāzes

Izkliedēta datubāze ir datubāze (turpmāk – DB), kuru veido vairākas fiziskas datubāzu

instances, kas atrodas uz dažādiem datoriem viena lokālā tīkla ietvaros, bet lietojumi sadarbojas ar

to kā ar vienu datubāzes eksemplāru. Rezultātā klientu programmatūra var izdarīt operācijas

vienlaicīgi vairākās datubāzēs.

Izkliedētām DB piemīt gan centralizētām sistēmām raksturīgas funkcijas, gan sadalītu

sistēmu funkcijas [1]:

a) centralizēto sistēmu funkcijas:

1) datu glabāšana, saņemšana un atjaunošana;

2) kataloga, kas pieejams lietotājam, atbalsts (kataloga glābās datu elementu

apraksts);

3) transakciju atbalsts;

4) paralēlisma vadība;

5) atjaunošanas servisi;

6) pieejas pie datiem kontrole;

7) datu apmaiņas atbalsts;

8) instrumentu, kas kontrolē datu un to izmaiņas doto noteikumu atbilstību,

atbalsts;

9) programmu no datiem neatkarības atbalsts;

10) daži palīgdienesti (importēšana, monitorings, analīze u.t.t.).

b) sadalītu sistēmu funkcijas:

1) pieeja pie citiem mezgliem un apmaiņa ar datiem;

2) kataloga, kas ļauj glābāt datu izvietojuma ziņas, atbalsts;

3) sadalītu vaicājumu apstrāde;

4) paplašinātas funkcijas paralēlisma vadībai;

5) paplašinātas atjaunošanas iespējas.

Katra datubāze izkliedētā sistēmā no citām var atšķirties ar to saturu, tabulu struktūru un

nosaukumu - vairākas fiziskas datubāzes distributīvā datubāzes sistēmā var tikt nosauktas vienādi,

tomēr to globālajam nosaukumam ir jāatšķiras. Globālais datubāzes nosaukums ir unikāls

nosaukums, kurš tiek piešķirts DB izkliedētā sistēmā, lai to būtu iespējams identificēt. Šie (parasti)

tiek veidoti automātiski, piemēram, Oracle veido globālo datubāzes nosaukumu apvienojot tīkla

domēna nosaukumu ar datubāzes individuālo nosaukumu[2,3].

3

1.1 Izkliedētu datubāzu klasifikācija

Izkliedētās datubāzes ir iespējams klasificēt (skat. . attēlu):

Homogēnā datubāzē visas savienojumā saslēgtās datubāzes instances atrodas vienādās

datubāzu vadības sistēmās un ir balstītas uz vienādu operētājsistēmu. Tām piemīt īpašības:

o Visas datubāzu instances izmanto līdzīgu vai identisku programmatūru;

o Visas instances izmanto vienādas datubāzu vadības sistēmas (DBMS) (piemēram,

visas izmanto Oracle);

o Katra instance apzinās pārējo instanču eksistenci un visas sadarbojas savā starpā, lai

izpildītu lietotāja vaicājumus;

o Izkliedētajā datubāzei piekļūst izmantojot vienu interfeisu, radot iespaidu, ka tā ir

viena nesadalīta sistēma.

Homogēnas datubāzes iedalās:

o Autonomā datubāze – katra datubāzes instance ir neatkarīga no pārējām, tā pastāv

un funkcionē neatkarīgi no pārējo darbības. Visbiežāk tajās ir integrēta kāda

automātiska datu apmaiņas lietotne, kura uz pārējām DB instancēm padod datu

izmaiņas;

o Neautonomā datubāze – dati ir izkliedēti pa visām homogēnajām instancēm un

centrālā datubāzes vadības sistēma koordinē datu izmaiņas visās instancēs.

Heterogēnā datubāzē savienojumā saslēgtās datubāzes var būs balstītas uz dažādām

operētājsistēmām, dažādām vadības sistēmām un datu modeļiem. Tām piemīt īpašības:

o Dažādas datubāzu instances izmanto atšķirīgu programmatūru;

o Dažādas datubāzu instances izmanto dažādas vadības sistēmas, to struktūras var būt

ļoti atšķirīgas;

o Vaicājumu izpilde ir sarežģīta, jo atšķiras datu shēmas un struktūras;

o Datu apmaiņu izpilde ir sarežģīta programmatūras atšķirību dēļ;

o Viena datubāzes instance var neapzināties pārējo datubāzes instanču darbību, to

sadarbība ir ierobežota.

o Heterogēnām DB ir nepieciešama ārējs nosaukumu serveris, kurš uzglabā to, kā

dažādās DB tiek dēvētas dažādas tabulas un lauki.

Heterogēnās datubāzes iedalās:

o Federated datubāze – datubāzes instances ir neatkarīgas, bet tās ir savienotas, lai

darbotos kā vienota sistēma;

o Nefederated datubāze jeb Multidatabase – datubāzes sistēma izmanto centrālo

koordinācijas elementu, caur kuru datubāzei var piekļūt.4

No lietojuma skatpunkta, izkliedētai datubāzei ir iespējami šādi arhitektūras modeļi:

Klienta - servera arhitektūra;

Peer-to-peer arhitektūra;

Multi – datubāzu sistēmu arhitektūra.

1. attēls. Izkliedētu datubāzu iedalījums pēc to arhitektūras

Klienta - servera datubāzēm ir raksturīga divu līmeņu arhitektūra, kurā sistēmas darbība ir

sadalīta serveru un klientu daļā. Servera daļā tiek veikta datu vadība, vaicājumu apstrāde,

optimizācija un datu apmaiņa. Klienta daļas pamatā ir lietotāja interfeiss.

Klienta - servera datubāzes iedalās “viens serveris/vairāki klienti” arhitektūrā un “vairāki

serveri/ vairāki klienti” arhitektūrā (skat. . attēlu).

5

Izkliedēta datubāze

Homogēna datubāze

Autonoma datubāze

Neautonoma datubāze

Heterogēna datubāze

Federated datubāzeMultidatabase

2. attēls. "Vairāki serveri / vairāki lietotāji" arhitektūra

Peer-to-peer arhitektūrā katra datubāzes instance funkcionē gan kā klients, gan kā serveris.

Multi – datubāzu sistēmu arhitektūras pamatā ir gan peer-to-peer sistēmas, gan klienta

servera sistēmas.

1.2 Izkliedētu datu uzglabāšana

Izkliedētās DB dati un to relācijas var tikt uzglabāti divos veidos, izmantojot[2]:

datu replikāciju,

datu fragmentāciju,

replikācijas un fragmentācijas apvienojumu.

1.2.1 Datu replikācija

DB sistēmā, dažādās lokācijās tiek uzglabātas identiskas relācijas kopijas.

Šādam datu uzglabāšanas veidam ir zināmi plusi[2]:

+ Datu replikācija nodrošina sistēmas darbību, ja kāda no lokālajām DB, kas uzglabā relāciju,

pārtrauc darboties, jo relācija būs pieejama arī citās lokācijās.

+ Replikācija nodrošina paralēlu darbību, t.i., ja jāizpilda vaicājums, kurš sevī satur relāciju,

un šis vaicājums tiek vienlaicīgi izpildīts vairākās DB, ir lielāka iespēja, ka vaicājums

izpildīsies ātrāk.

Kā arī trūkumi[2,3]:

‒ Ja rodas nepieciešamība atjaunināt kādus no replicētajiem datiem, tad, jo vairāk replikācijas

būs saglabātas DB sistēmā, jo sarežģītāka un ilgāka datu atjaunošana var būt; un, ja

atjaunināšana nenotiek pilnīgi, tas var sagādāt problēmas turpmākā datu izguvē.

6

Atjaunināšanas problēma var tikt novērsta, izvirzot vienu relācijas kopiju par primāro kopiju

– to, pēc kuras var noteikt vai cita relācija ir atbilstoši atjaunota[3].

1.2.2 Datu fragmentācija

DB sistēmās esošās relācijas tiek sadalītas vairākos fragmentos tā, ka katrs fragments satur

pietiekami daudz informāciju par relāciju, lai varētu tikt izpildītas ar relāciju saistītas darbības, un

fragmenti ir uzglabāti vairākās DB[2].

Fragmentāciju var iedalīt horizontālā un vertikālā fragmentācijā[2].

Horizontāla fragmentācija sadala relāciju vairākos fragmentos un fragmenti tiek uzglabāti

apakškopās, atbilstoši to izmantošanas biežumam ar mērķi mazināt datu pārnesi.

Vertikāla fragmentācija tiek veikta ar mērķi mazināt datu/relāciju dublēšanos datu bāzes

ietvaros.

1.2.3 Datubāzes pārredzamība

Datu pārredzamība (angļu val. – transparency) nosaka to, ka datu integritātes dēļ datubāzes

lietotājam nedrīkst būt pieejama informācija par datu fizisko atrašanos vietu vai to, kā dati tiek

iegūti no konkrētas DB lokācijas.

Izkliedētā DB jābūt nodrošinātai vairāku veidu datu pārredzamībai[2]:

Fragmentācijas pārredzamība, kas attiecas uz to, ka lietotājam nedrīkst būt zināms tas, kā

relācijas ir tikušas safragmentētas;

Replikācijas pārredzamība, kas attiecas uz to, ka lietotājam katru datu objektu būtu jāsaskata

kā unikālu vienību, t.i., lietotājam nav jāapzinās kuri datu objekti ir replicēti sistēmas

ātrdarbības dēļ;

Lokācijas pārredzamība, kas attiecas uz to, ka lietotājiem nav jāzina datu lokācija.

Izkliedētai datubāzei ir pašai jāspēj atrast datubāzē saglabātos objektus – iespējamie

risinājumi šai problēmai ir aprakstīti nodaļās 1.2.4., 1.2.5. un 1.2.6.

1.2.4 Nosaukumu serveris

Nosaukumu serveris ir centrāla sistēma, kura ir pieslēgta visām izkliedētās DB lokācijām.

Tajā tiek uzglabāti tabulu un lauku nosaukumi visām sistēmā saslēgtajām DB, ar mērķi atvieglot

vaicājumu izpildi, lai vaicājumā iesaistītie datu objekti tiek pārtulkoti atbilstoši katras DB

unikālajiem nosaukumiem, un novērst situāciju, ka dažādiem datu objektiem (tabulām/laukiem) tiek

piešķirti vienādi nosaukumi.

Tomēr nosaukumus serveris var radīt problēmas sistēmas darbībā[3]:

Nosaukumu serveris var kļūt par sistēmas veiktspējas vājo (sastrēgumu) vietu (angļu val.

– bottleneck);

7

Ja nosaukumu serveris iziet no ierindas (pārstāj darboties), tad visa sistēma var pārtraukt

strādāt.

Alternatīvs risinājums unikālu nosaukumu nodrošināšanai, ir sinonīmu ieviešana un vietnes

identifikatori.

1.2.5 Vietnes identifikatori

Vietnes identifikatoru ieviešana ir populāra alternatīva nosaukumu servera ieviešanai, jo nav

jāpaļaujas uz kāda servera darbības spējām, lai varētu veiksmīgi noritēt datu apmaiņa.

Identifikatoru princips ir šāds – katra lokālā DB katram tās ģenerētajam nosaukumam pievieno klāt

identificējošu pazīmi (t.i. identifikatoru). Piemēram, skolotājs@skola vai skola.skolotājs [2-3].

Oracle datubāzē tabulas adrese tiek norādīta aiz “@” simbola, un tas izskatās šādi:

tabula@savienojums

Šī pieeja nodrošina to, ka neradīsies situācija, kad divas DB ievieš vienādus nosaukumus

atšķirīgām datu kopām, kā arī nav vajadzība pēc centrālas vadības sistēmas.[3]

Tomēr šī pieeja nenodrošina datubāzes pārredzamību (angļu val. - transparency), t.i.,

nenodrošina to, ka datu fiziskā atrašanās vieta (vai veids kā tiem tiek piekļūts), ir apslēpts datu

bāzes lietotājiem.

Šajā izkliedētājā datubāzē savienojums sauksies tāpat kā datubāze, ar kuru tiks veikts

savienojums “DistributedDB2”.

1.2.6 Sinonīmi

Šo problēmu ir iespējams apiet ar sinonīmiem (sinonīmiem) – sistēma datu objektiem

izveido alternatīvu nosaukumam (jeb sinonīmu), kurš tiešā veidā nesatur informāciju par datu

atrašanos vietu un avotu, bet tiek saglabāts (kopā ar reālo nosaukumu) lokāli katrā sistēmā [2,3].

Izmantojot sinonīmus, lietotājs nezina par datu fizikālo atrašanos vietu, kā arī lietotājs

neapzināsies, ja datu bāzes administrators būs pārvietojis datu kopu no vienas DB uz citu [2,3].

8

Tabulas nosaukums

datubāzē, kurā tā ir

nodefinēta

Tabulas adrese jeb savienojuma nosaukums, kurš tiek nodefinēts savienojuma izveides brīdī

2 Lokālā datubāze

Šajā darbā tiks izveidota peer-to-peer tipa homogēna izkliedētā datubāze, kuru veidos divas

datubāzu instances – tā sauktā “lokālā datubāze” DistributedDB1 un “ārējā datubāze”

DistributedDB2.

Pirmā tiek izveidota lokālā datubāze DistributedDB1, no kuras galvenokārt tiks veiktas

darbības – no tās notiks piekļuve ārējai datubāzēm.

Datubāze ir veidota Oracle 12c, tai tiek piekļūts izmantojot SQL Developer un SQL plus.

Sākotnēji lokālajā datubāzē tiek ievietotas divas tabulas “Studenti” un “Kursi”, un tabulas

tiek aizpildītas ar informāciju par studentiem un mācību kursiem.

2.1 Tabulu izveide un aizpilde lokālajā DB

Tiek izmantoti vienkārši create table vaicājumi, lai izveidotu abas tabulas (skat. . un . attēlu).

3. attēls. Tabulas “Kursi” izveidošana

4. attēls. Tabulas “Studenti” izveidošana

Tiek pievienota informācija par diviem mācību kursiem – Datorzinātņu un IT.

9

5. attēls. Tabulas “Kursi” aizpildīšana

Pēc tam tiek ievietota informācija par desmit studentiem, kuri mācās Datorzinātnes, un par

vienu studentu, kurš mācās IT (skat. . attēlu).

6. attēls. Tabulas “Studenti” aizpildīšana

Kad tas ir izdarīts, tiek veikta pārbaude, t.i., tiek izvadīti visi tabulā “Studenti” esošo

studentu vārdi un uzvārdi, kā arī n tabulas “Kursi” tiek izgūts institūts, kurā studenti mācās.

Vaicājumu un vaicājuma rezultātu var redzēt . attēlā.

10

7. attēls. Vaicājums un vaicājumu rezultāts studentu informācijas izguvei

Pagaidām ar šādu datu kopu pietiek; informācija par citiem studentiem būs pieejama ārējā

datubāzē DistributedDB2.

11

3 Ārējās datubāze

Tiek izveidota ārējā datubāze DistributedDB2.

Ir pieejami daudzi varianti, kā izveidot vēl vienu datu bāzes instanci – var instalēt citu

Oracle versiju, instalēt Oracle virtuālajā mašīnā, vai veidot savienojumu ar citu datubāzi pavisam

citā datorā, bet šajā piemērā, izmantojot Database Configuration Assistant, tiks izveidota vēl viena

Oracle 12c datubāze šajā pašā ierīcē.

3.1 Datubāzes izveidošana un savienošana ar SQL Developer

Lai izveidotu jauno datubāzes instanci, tiek palaists Database Configuration Assistant (skat.

. attēlu) un tiek norādīts, ka jāveido jauna datubāze. Atbilstoši, pēc tam nākošajā saskarnē tiek

ievadīti dažādi datubāzes parametri un tā tiek ieinstalēta.

8. attēls. Database Configuration Assistant pirmā saskarne

Kad datubāze ir izveidota, tiek izvadīts datubāzes veidošanas kopsavilkums (Create

Database – Summary), kurš var noderēt vēlāk veidojot savienojumu ar lokālo datubāzi (skat. .

attēlu).

12

9. attēls. Datubāzes instalācijas kopsavilkums

13

Lai gan datubāze ir izveidota, tā vēl nav attēlota SQL Developer izveidoto savienojumu

sadaļā (skat. . attēlu).

10. attēls. SQL developer savienojumu sadaļa, kurā attēlots tikai lokālās datubāzes savienojums

Lai izveidotu jaunu savienojumu, nepieciešams veikt darbību “Add new Database

Connection”, un atbilstoši nokalibrēt savienojumu, lai pēc tam varētu izveidot savienojumu arī ar

lokālo datubāzi. Konkrēti – tiek norādīts hostname, port un Service name – vērtības, kuras tiks

izmantotas nodefinējot savienojumu ar lokālo datubāzi (skat. . attēlu).

11. attēls. SQL developer savienošana ar datubāzi DistributedDB2 – ārējo datubāzi.

Pēc savienojuma notestēšanas (taustiņš “Test”), savienojums tiek saglabāts un palaists. Kad

tas ir darīts, DistributedDB2 uzrādās savienojumu sadaļā iekš SQL developer.

12. attēls. SQL developer savienojumu sadaļa, kurā attēlots savienojums ar abām datubāzēm

3.2 Tabulu izveide un aizpilde ārējā DB

Āŗējā datubāzē DistributedDB2 tiek izveidotas tabulas “Studenti” un “Kursi”, kuras ir

vienādas ar tabulām jau izveidotajā datubāzē.

14

Tabulas tiek izveidotas, izmantojot vaicājumus:

create table Kursi (Kursa ID number,Instituts varchar2(20),Gads number,Constraint PK_KURSS Primary key(KursaID));

create table Studenti(StuID number,StudVards varchar2(20),StudUzvards varchar2(20),KursaID number,Constraint PK_STUDENTS Primary key (StudID),Constraint fk_KursaID foreign key (KursaID) references Kursi(KursaID));

Pēc tam tabulas var tikt aizpildītas. Šajā gadījumā abās datubāzēs tabulas “Kursi” saturēs

pilnīgi vienādas vērtības, bet tabulas “Studenti” saturēs atšķirīgas – astoņi ieraksti būs par

studentiem, kuri mācas IT institūtā, un viens būs par studentu no datorzinātņu institūta.

13. attēls. Vērtību ievietošana tabulā "Kursi"

14. attēls. Vērtību ievietošana tabulā "Studenti"

Ar vaicājumu, kuru var redzēt . attēlā, tiek pārbaudīts vai tabula aizpildījusies pareizi.

15

15. attēls. Vaicājums un vaicājuma rezultāts

Kā var redzēt, tabula ir aizpildīta pareizi.

16

Lokālā DB1 Ārējā DB2

Pieprasījums

Atbilde

4 Izkliedētās datubāzes izveidošana

4.1 Saites izveide starp lokālo un ārējo datubāzi

Kad SQL developer ir savienots ar abām tabulām – lokālo DistributedDB1 un ārējo

DistributedDB2, starp abām datubāzēm var tikt veidots savienojums – un tās kļūst par izkliedēto

datubāzi.

Šajā darbā paredzēts izveidot vienpusēju savienojumu, kurā lokālā datubāze var izgūt datus

no ārējās datubāzes, bet ārējā nevar no lokālās. Citiem vārdiem sakot, Lokālā datubāze var tikai

nosūtīt pieprasījumu uz Ārējo datubāzi, un Ārējā datubāze var tikai atbildēt (skat. . attēlu).

Lai īstenotu šādu savienojumu, lokālajā datubāzē tiek izpildīts vaicājums:

create database link DistributedDB2 connect to scott identified by newpassword using '(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521))(CONNECT_DATA=(service_name=DistributedDB2)))';

Kurā:

“[link] DistributedDB2” – savienojuma nosaukums,

“scott” un “newpassword” – lietotājs un lietotāja parole, ar kuru savienojums būs pieejams,

“Protocol=TCP” – savienojuma protokola veids,

“localhost” – ārējās datubāzes resursdatora nosaukums (atšķiras no Lokālās datubāzes

resursdatora nosaukuma),

“port” – porta, pa kuru tiks padoti/saņemti dati, numurs,

“service_name=DistributedDB2” – datubāzes, ar kuru tiks savienots, servisa nosaukums.

Vaicājuma izpilde ir attēlota . attēlā.

17. attēls. Savienojuma “DistributedDB2” izveide starp lokālo un ārējo datubāzi

17

16. attēls. Datu apmaiņa starp lokālo un ārējo DB

Kad šī saite ir izveidota, tā tiek attēlota kā lokālās datubāzes “DistributedDB1” elements

(skat. . attēlu).

18. attēls. Saite “DistributedDB2” kā lokālās datubāzes apakšelements

Pēc tam tiek veikta automatizēta savienojuma pārbaude (skat. . attēlu un . attēlu).

19. attēls. Datubāzes savienojuma pārbaude

18

20. attēls. Paziņojums, ka datubāzes savienojums ir veiksmīgi notestēts

4.2 Datu izguve no ārējās datubāzes

Tiek uzrakstīts vienkāršs vaicājums:

Select * from studenti@DistributedDB2;

Šajā vaicājumā “Studenti” ir tabulas nosaukums, un “@DistributedDB2” norāda uz tabulas

avotu – šajā gadījumā datubāzi DistributedDB2, kura ir savienota at datubāzi DistributedDB1,

izmantojot saiti DistributedDB2.

Šis vaicājums izvada pareizu tabulas struktūru (StudID, StudVards, StudUzvards, KursaID),

bet tabula tiek uzrādīta kā tukša, jo datubāzes izmaiņas netika izpildīti (angļu val. Commit).

21. attēls. Vaicājums, kurš izgūst datus no datubāzes DistributedDB2, tabulas Studenti, un rezultāti netiek izvadīti

Abām datubāzēm tiek veikta darbība commit, un par to tiek izvadīti atbilstoši paziņojumi.

19

22. attēls. Darbības Commit veikšana abās DB

Pēc tam lokālajā datubāzē DB1 tiek atkal izpildīts vaicājums, kurš izgūst visas vērtības no

ārējās datubāzes DB2, un šoreiz rezultāti uzrādās:

23. attēls. Tas pats vaicājums, bet šoreiz tiek attēloti dati

Tālāk, izmantojot darbību UNION, tiek izvadīti visi ieraksti no tabulām “Studenti” un no

tabulām “Kursi” tiek piemeklēts institūta nosaukums un atbilstošais mācību gads.

Vaicājums:

select sa.studvards as Vards, sa.studuzvards as Uzvards, k.instituts as Instituts, k.gads as Gads

20

from studenti@DistributedDB2 sa, kursi kwhere k.kursaID = sa.kursaIDUNION select si.studvards as Vards, si.studuzvards as Uzvards, k.instituts as Instituts, k.gads as Gadsfrom studenti si, kursi kwhere k.kursaID = si.kursaID;

Izgūto datu kopu var redzēt attēlā:

24. attēls. Vaicājumā izgūtie dati

4.3 Sinonīmu ieviešana

Ārējā datubāzē tiek ieviesta jauna tabula SensitInfo, kura satur sensitīva rakstura informāciju

– šajā gadījumā studenta personas kodu un tautību. Tiek izmantots vaicājums:

create table SensitInfo(InfoID number,PersKods number,Tautiba varchar(3),Constraint PK_InfoID Primary key (InfoID));

Atbilstoši pēc tam tabulai Studenti tiek pievienota kolonna “SensitInfoID”, kura satur ārējo

atslēgu uz tabulas “SensitInfo” ierakstiem. Lai to pievienotu, tiek izmantots vaicājums:

alter table Studenti add SensitInfoID number;

21

add constraint FK_SensitID foreign key(SensitInfoID) references SensitInfo(InfoID);

Klientu-servera sistēmā būtu ļoti noderīgi apslēgt šādas tabulas avotu, t.i., kurā datubāzē

šāda informācija tiek uzglabāta, lai mazinātu informācijas noplūdes iespējamību, tādēļ šai tabulai un

tās adresei (SensitInfo@DistributedDB2) tiks piešķirts sinonīms – nosaukums, kurš nesatur adresi.

Tas tiek izdarīts ar vaicājumu:

create synonym SensitInfo for SensitInfo@DistributedDB2;

25. attēls. Sinonīma izveides vaicājums

Kad sinonīms ir izveidots, lokālās datubāzes lietotājam arī ir vieglāk darboties ar šo tabulu,

jo tās nosaukums ir ievērojami īsāks. Datu ievadi no lokālās DB, izmantojot sinonīmu, var redzēt .

attēlā.

26. attēls. Datu ievade ārējās datubāzes tabulā SensitInfo no iekšējās datubāzes, izmantojot sinonīmu

22

Secinājumi

Tika izveidots vienkāršs piemērs izkliedētai datubāzei, kā arī iepazinos ar literatūru par

izkliedētām datubāzu sistēmām.

Diemžēl laika plānošanas problēmu dēļ šis darbs netika izstrādāts līdz galam semestra laikā

un tas tiks nodots tikai sesijas pagarinājumā.

Izveidoto datubāzi veido divas Oracle 12c instances, kuras ir izvietotas vienā datorā un satur

ļoti līdzīgas datu struktūras. Šādu datubāzi var uzskatīt par homogēnu izkliedētu datubāzi. Darba

izpildes gaitā bija centieni izveidot arī nehomogēnu datubāzi – izmantojot MS Access uz Linux OS

- , taču šie centieni bija veltīgi, jo pieejamā virtuālā mašīna strādāja kļūdaini un pārāk bremzēja, lai

darbu varētu veiksmīgi pabeigt.

Par spīti tam, darba izpildes gaitā ieguvu skaidrību par izkliedētām datubāzēm un to

iespējām, kā arī papildus zināšanas datu uzglabāšanas drošību. Vēl jāpiebilst, ka šī darba izpilde

veicināja izpratni par esošo datubāzu sistēmu manā darba vietā, tādējādi varu apgalvot, ka šajā

darbā iegūtās zināšanas ir noderējušas arī praksē.

23

Izmantotā literatūra

[1] Mācību materiāli, pieejami,

https://datubaze.wordpress.com/macibu-kursi/db4/db4_literatura/

[2] Silberschatz A., Korth H.F., & Sudarchan S., Database System Concepts, 5th edition

(McGraw-Hill International Edition), 2005

[3] Özsu M.T., & Valduriez P., Pinciples of Distributed Database Systems, 3rd edition,

ISBN 978-1-4419-8834-8, 2010, 833p.

24