RĪGAS TEHNISKĀ UNIVERSITĀTE
Datorzinātnes un informācijas tehnoloģijas fakultāte
Lietišķo datorzinātņu institūts
Praktiskais darbs mācību priekšmetā “Daudzbāzes”Izkliedētas datubāzes
Katrīna Kronberga
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
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