Saturs IEVADS....................................................... 3 1. UNIVERSĀLĀS DATU BĀZES SISTĒMAS...........................3 1.1 Relāciju datu bāzes sistēmas............................3 1.2 Objektu datu bāzu sistēmas..............................3 1.3 Relāciju – objektu datu bāzu sistēmas...................3 2.RELĀCIJU OBJEKTU DATU BĀZU SISTĒMU REALIZĀCIJAS............3 2.1 Firmas Oracle datu bāzu sistēma.........................3 2.1.1. Tabula ar objektu kolonnu..........................3 2.1.2. Objektu tabula ar rindas tipa objektiem............3 2.1.3 Iekļautās kolekcijas................................3 2.1.4 Objektu skati.......................................3 2.1.5. Objektu metodes....................................3 2.2 Informix................................................3 2.2.1 Informix datu tipi..................................3 2.2.1.3. Tipu mantošana...................................3 2.3 DBVS DB2...............................................3 2.3.1 Objekts............................................. 3 2.3.2 Objektu tabula......................................3 2.3.3 Tabula ar objektu kolonnu...........................3 2.3.4 Tipu hierarhija.....................................3 2.3.5 Objektu skats.......................................3 2.4 Datu bāzu sistēma PostgreSQL............................3 2.4.1 PostgreSQL DBVS.....................................3 2.4.2 Saliktie datu tipi..................................3 3. Relāciju – Objektu DB sistēmu izmantošana IS projektēšanā. 3 3.1 DBS projektēšana........................................3
93
Embed
IEVADS - datubaze.files.wordpress.com · Web viewObjektu datubāzes labi sadarbojas ar tādām objektu orientētām programmēšanas valodām kā Ruby, Python, Perl, Java, C#,C++.
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.
Datu bāzu vadības sistēmas PostgreSQL unikāla īpašība ir tās iebūvētie ģeometriskie datu tipi,
kas ļauj glabāt un apstrādāt tādus telpiskus objektus kā punkts, taisne, daudzstūris, riņķis.
2.1 Tabula
Ģeometriskie datu tipi
Nosaukums Izmērs Attēlojums Aprakstspoint 16 baiti Punkts plaknē (x,y)line 32 baiti Neierobežota līnija ((x1,y1),(x2,y2))lseg 32 baiti Ierobežots līnijas
segments((x1,y1),(x2,y2))
box 32 baiti Taisnstūra logs ((x1,y1),(x2,y2))path 16+16n baiti Slēgta daļa ((x1,y1),...)path 16+16n baiti Atvērta daļa [(x1,y1),...]polygon 40+16n baiti Daudzstūris ((x1,y1),...)circle 24 baiti Riņķis <(x,y),r> (centrs un
rādiuss)
Ģeometriskie datu tipi:
Punkts(point).
40
Punkts ir pamata divdimensiju ģeometriskais tips. Punkta vērtību piešķiršanai tiek
lietota sekojoša sintakse:
( x , y )
Kur x un y ir atbilstošās koordinātes kā peldošā punkta skaitlis.
Līnijas segments(lseg).Līnijas segments tiek attēlots kā punktu pāris. Lseg vērtības tiek attēlotas lietojot
sekojošu sintaksi:
( ( x1 , y1 ) , ( x2 , y2 ) )
Kur ( x1 , y1 ) un ( x2 , y2 ) ir segmenta beigu punkti.
Logs(box).Logi tiek attēloti kā punktu pāri, kas ir pretējie loga punkti. Loga vērtības tiek
attēlotas lietojot sekojošu sintaksi:
( ( x1 , y1 ) , ( x2 , y2 ) )
Kur ( x1 , y1 ) un ( x2 , y2 ) ir divi pretējie loga stūri.
Daļa(path).Daļas tiek attēlotas kā saraksts ar slēgtiem punktiem. Daļas var būt atvērtas, kur
pirmie un pēdējie punkti sarakstā nav slēgti, un daļas var būt slēgtas kur pirmie un
pēdējie punkti ir slēgti.
( ( x1 , y1 ) ,..., ( xn , yn ) )
[ ( x1 , y1 ) ,..., ( xn , yn ) ]
Daudzstūri(polygon).Daudzstūri tiek attēloti kā punktu saraksts(daudzstūru virsotnes).
((x1,y1),...,(xn,yn))
Riņķis(Circle)Riņķi tiek attēloti kā centra punkts un rādiuss.
<(x,y),r>
Kur (x,y) ir centra punkta koordinātes un r ir riņķa rādiuss
PostgreSQL piedāvā funkcijas, kas apstrādā šos telpiskos datu tipus, piemēram, aprēķina
objekta laukumu, diametru, objekta centru.
Tabula 2.2
Ģeometrisko tipu funkcijasFunkcija Atgriežamais tips Apraksts Piemērs
CREATE TABLE video( video_id CHARACTER(8) PRIMARY KEY, nosaukums VARCHAR(80), ilgums INTERVAL);Tabulai DVD atribūti ir tādi paši kā bāzes tabulai VIDEO plus atribūts skanas_celini ar datu
tipu VARCHAR[], kurā glabāsies pieejami skaņu celiņi.
CREATE TABLE dvd(
skanas_celini VARCHAR[]
) INHERITS (video);
INHERITS nosaka to, ka tabula DVD manto no tabulas VIDEO.
INSERT INTO dvd VALUES( 'AAA-750', -- video_id 'Spriditis, -- nosaukums '121 minutes', -- ilgums '{Latviesu,Anglu}' -- skanas_celini);
SELECT * FROM dvd;
video_id | nosaukums | ilgums | skanas_celini---------+-----------+----------+------------------- AAA-750 | Spriditis | 02:01:00 | {Latviesu,Anglu} SELECT * FROM video;
Rezultātāvideo_id | nosaukums | ilgums ---------+-----------+---------- AAA-750 | Spriditis | 02:01:00
DVD ir video. Kad ir izveidots SELECT tipa vaicājums tabulai VIDEO, rezultātā ir tie
atribūti, kurus satur tabula VIDEO. Kad SELECT tipa vaicājums attiecas uz DVD tabulu,
rezultātā ir atribūti, kurus satur tabula DVD.
Lai izgūtu ierakstus tikai no bāzu tabulas, neiekļaujot ierakstus no pēcteču tabulām, lieto
ONLY. Lai izgūtu datus tikai no VIDEO tabulas, neiekļaujot datus no DVD tabulas,
jāizmanto vaicājums:SELECT * FROM ONLY video;
45
Mantošanas realizācijā atvasinātās tabulas nemanto no bāzu tabulas pieeju tiesības. Lai
lietotājs varētu piekļūt bāzes tabulai, viņam jābūt tiesībām uz visām atvasinātām tabulām vai
jālieto ONLY notāciju. Atvasinātās tabulas nemanto indeksus (arī UNIQUE ierobežojumu) un
FOREIGN KEY ierobežojumu. Ja bāzes tabulai ir nodefinēti trigeri, tie arī netiek mantoti
pēcteču tabulām [16].
46
3. Relāciju – Objektu DB sistēmu izmantošana IS projektēšanā
3.1 DBS projektēšana.Tiek lietotas dažādas datu bāzes projektēšanas tehnoloģijas. Tās cita no citas atšķiras ar
dažādiem gala lietotāju priekšstatu veidiem par projektējamo informācijas sistēmu. Tiek
meklēts priekšstata variants, kurš ir vislabāk saprotams, lai lietotājs varētu sniegt visvairāk
informācijas par savām vēlmēm viņam vispiemērotākā formā.
Sākotnēji izstrādājamo informācijas sistēmu apskatīja kā “melno kasti”, kurai ir zināmi
tikai ieejas un izejas dati (tātad tos bija jāuzzina no lietotāja). Izmantojot šo informāciju,
Džeksons izstrādāja vienu no pirmajām formalizētajām datu bāzes projektēšanas metodēm.
Turpinājumā datu bāzes projektēšanas speciālistu domas dalījās:
1) vieni uzskatīja, ka lietderīgi noskaidrot projektējamās sistēmas darbības
pamatfunkcijas un tajās figurējošos datus (šiem mērķiem tika izveidota, piemēram,
datu plūsmas diagramma);
2) otri, lietderīgi veidot visu izmantojamo datu savstarpējās saistības modeli (šim
mērķim tika izstrādāta, piemēram, realitāšu-saišu diagramma).
Attīstoties objektorientētai programmēšanai, tika radītas arī objektu datu bāzes. Līdz ar to
veidojās uzskats, ka datus lietderīgi analizēt objektu formā, papildus apskatot ar objektiem
veicamās darbības (metodes). Tika izstrādātas tādas informācijas sistēmas modelēšanas
metode kā UML valoda (Unified Modeling Language). UML valodas modelēšanas tehnika
ietvēra sevī vairākas diagrammas, bet datu bāzes projektēšanai nozīmīgākā bija klašu
diagramma.
Datu bāzes sistēmas projektēšanas pamatdarbību secība var atšķirties, bet tai jāiekļauj sevī
tādus punktus kā problēmvides analīze un modelēšana, prasību iegūšana, datu diagrammu
izveidošana, sākotnējo datu struktūru veidošana un to kvalitātes pārbaude, datu bāzes
struktūrās definēšana (4.1. att.).
47
4.1 att. Datu bāzes sistēmas projektēšanas pamatdarbību secība
Veidojot datu bāzi, dati tiek apskatīti un analizēti trīs līmeņos(4.2 att):
1) konceptuālais līmenis – lietotājs un datu bāzes izstrādātājs apskata problēmvides
datus, atlasa nepieciešamos un nosaka datu savstarpējas saites. Līmeņa rezultāts ir
pilnīgi neatkarīgs no datu bāzes realizācijas un tā var būt realitāšu-saišu diagramma,
UML klašu diagramma vai arī kāds cits modelis;
2) loģiskais līmenis – datu bāzes projektētājs veido datu loģisko modeli noteiktām datu
bāzes sistēmas tipam, piemēram, relāciju, objektu vai relāciju-objektu;
3) fiziskais līmenis – datu bāzes projektētājs realizē datu loģisko modeli konkrētai datu
bāzes vadības sistēmai, iegūstot datu glabāšanas fizisko struktūru definējumus.
48
4.2 att Datu bāzes veidošana (trīs līmeņi
3.2 Pamata transformācijas.
3.2.1 Klases transformācija
Klase no konceptuālā līmeņa tiek transformēta uz saliktu objektu. Tālāk šo objektu var
izmantot lai definētu objektu tabulu vai izmantot kā kolonnu tabulā. Piemērā(Attēls 1) tiek
transformēta klase darbinieks ar relāciju objektu pieeju uz salikto tipu ar nosaukumu
Darbinieks.
4.3 att Klases transformācija
49
3.2.2 Klases atribūta transformācija
Klases atribūts transformējot tiek transformēts kā saliktā tipa atribūts. Definējot salikto tipu,
pie tipa definīcijas tiek noteikti atribūti, un to tipi. Piemērā(Attēls 2) klasei Darbinieks tiek
definēts atribūts Uzvards ar tipu CHAR(40).
4.4 att Klases atribūta transformācija
3.2.3 Atslēgas atribūta transformācija
Definējot objekta tipu, tā atribūtiem nevar noteikt ierobežojumus. Lai kādam no saliktā tipa
atribūtiem noteiktu ierobežojumus, šie ierobežojumi ir jānodefinē veidojot tabulu.
Piemērā(Attēls 3), klases Darbinieks atslēgas atribūts ir numurs. Atribūts tiek definēts
veidojot salikto tipu darbinieks, bet ierobežojums, kas nosaka, ka šis atribūts būs atslēgas
atribūts tiek noteikts veidojot tabulu darbinieki.
4.5 att Atslēgas atribūta transformācija
50
3.2.4 Atribūta obligātuma transformācija
Līdzīgi kā transformējot atslēgas atribūtu, arī atribūta obligātumu nevar noteikt definējot
salikto tipu, tas jānodefinē veidojot tabulu. Piemērā(Attēls 4), klasei Darbinieks ir obligāts
atribūts vards. Atribūts un tā tips tiek nodefinēts veidojot objektu, bet ierobežojums, kurš
nosaka, ka šis atribūts būs obligāts tiek noteikts veidojot tabulu.
4.6 att. Atribūta obligātuma transformācija
3.2.5 Klases metodes transformācija
Lai transformētu klases metodi, veidojot salikto tipu tiek ierakstīts tikai šīs metodes
nosaukums. Pati metode tiek veidota, veidojot tipa ķermeni. Piemērā(Attēls 5), klasei
Darbinieks ir metode getUzvards. Veidojot salikto tipu tiek nosaukta metode ar komandu
MEMBER PROCEDURE getUzvards. Tālāk veidojot tipa ķermeni tiek veidota pati metode.
51
4.7 att Klases metodes transformācija
3.2.6 Saites viens pret daudziem transformācija.
Saiti viens pret daudziem var transformēt uz tabulu ar iekļautu kolekciju, kur realitāte daudzi
tiek realizēta kā iekļautā kolekcija. Relāciju objektu variantā lietojot Oracle sintaksi tiek
veidota tabula ar iekļautu kolekciju. Piemērā(Attēls 6), darbinieks var strādāt maksimāli vienā
firmā. Firmā var būt neviens darbinieks, viens darbinieks vai daudzi darbinieki. Vispirms
izveido objekta tipu T_Darbinieks, pēc tam izveido kolekcijas tipu Tabula_Darbinieks.
Veidojot tabulu Firma tipu Tabula_darbinieks, kas ir kolekcija izvēlas kā kolonnas tipu.
4.8 att Saites viens pret daudziem transformācija
52
Piemērā(Attēls 7), katra prece ir piesaistīta tieši vienai partijai, partijā var būt viena vai
vairākas preces. Šī situācija no iepriekšējās atšķiras ar to, ka šajā situācijā kolekcija nedrīkst
būt tukša. Lai to realizētu tabulas definīcijā iekļauj ierobežojumu NOT NULL. Realitāte prece
tiek transformēta kā iekļauta kolekcija. Definējot tabulu partija tiek iekļauts ierobežojums, ka
šī iekļautā kolekcija nedrīkst būt tukša.
4.9 att Saites viens pret daudziem transformācija
Piemērā(Attēls 8), katrs departaments publicē vienu vai vairākas atskaites. Nav obligāti, ka
kāda konkrēta atskaite ir departamenta publicēta. Šī situācija no iepriekšējām atšķiras ar to, ka
šeit atskaite var tikt glabāta arī atsevišķi bez piesaistes departamentam, un tādēļ nevar veidot
tabulu ar iekļauto kolekciju līdzīgi kā iepriekšējos piemēros. Lai realizētu to, ka atskaite tiek
glabāta atsevišķi. atskaitei veido salikto tipu, un objektu tabulu pamatojoties uz šo tipu. Otru
tabulu departamenti veido kā objektu tabulu ar iekļauto kolekciju, kur kolekcija satur norādes
uz atskaitēm. Šādā realizācijā tiek nodrošināts, ka atskaite var būt piesaistīta kādam
departamentam, tādā gadījumā uz atskaiti būs norāde no departamentu tabulas, un atskaite var
nebūt piesaistīta departamentam tādā gadījumā norādes nebūs.
53
4.10 att Saites viens pret daudziem transformācija
3.2.7 Saites viens pret vienu transformācija
Saite viens pret vienu tiek transformēta uz divām objektu tabulām. Piemērā(Attēls 9) katrai
atskaitei ir viena abreviatūra un katra abreviatūra reprezentē tieši vienu atskaiti. Tiek veidoti
divi objektu tipi ar norādēm vienam uz otru, jo katrai atskaitei ir jābūt abreviatūrai un katrai
abreviatūrai jābūt atskaitei, un šādām norādēm ir obligāti jābūt. Tā, kā definējot objekta tipus
nevar nodefinēt tipa atribūtu ierobežojumus, tad ierobežojumus definē, definējot tabulu,
ierobežojums NOT NULL nozīmē, ka atsauce uz otru tipu nedrīkst būt tukša.
54
4.11 att Saites viens pret vienu transformācija
Piemērā(Attēls 10) jābūt vadītājam priekš katra departamenta, bet darbinieks var vadīt vienu
departamentu, vai nevienu departamentu. Šis piemērs no iepriekšējā piemēra atšķiras ar to, ka
šajā piemērā viena no saitēm ir neobligāta.
4.12 attēls Saites viens pret vienu transformācija
55
Piemērā(Attēls 11), daži no datoriem ir piesaistīti inženieriem, bet ne obligāti visiem
inženieriem ir dators, tas nozīmē, ka šoreiz abas saites ir neobligātas un obligātuma
nosacījums nav nepieciešams.
4.13 att. Saites viens pret vienu transformācija
3.2.8 Saites daudzi pret daudziem transformācija
Saiti daudzi pret daudziem var realizēt kā divas objektu tabulas ar iekļautu kolekciju, vai
divas tabulas ar iekļautu kolekciju. Piemērā(Attēls 12), katrs darbinieks var strādāt nevienā,
vienā vai vairākās firmās, bet katrā firmā ir neviens, viens, vai vairāki darbinieki. Tiek veidoti
divi objekti ar iekļautu kolekciju. Kolekcijas satur norādes uz otru objektu.
4.14 attēls Saites daudzi pret daudziem transformācija
56
3.2.9 Ternārās un n-ārās saites transformācija
Ternāro saiti transformē kā trīs objektu tabulas ar norādēm savā starpā. Piemērā(Attēls 13),
darbinieks izmanto tieši vienu datoru priekš katra no projektiem. Katrs dators projektā tiek
piesaistīts darbiniekam. Darbinieks var strādāt vairākos projektos, katrā no tām izmantojot
citu datoru. Tiek veidoti trīs objekta tipi, kuros katrā ir norādes uz pārējiem diviem objekta
tipiem.
4.15 attēls Ternārās saites transformācija
Piemērā(Attēls 14), katrs projektam piesaistītais darbinieks strādā šīm projektam paredzētājā
vietā (izvietojums), bet var strādāt arī kādā citā projektā, atbilstoši citā vietā. Jebkurā no
izvietojumiem var strādāt vairāki darbinieki. Tipā darbinieks ir norāde uz tipu izvietojums, un
uz tipu projekts. Tipā Izvietojums ir kolekcija ats_uz_darb kas satur norādes uz tipu
darbinieks, un norāde uz tipu projekts. Tipā projekts ir kolekcija ar norādēm uz tipu
darbinieks, un norāde uz tipu izvietojums.
57
4.16 attēls Ternārās saites transformācija
Piemērā(Attēls 15), katram no inženieriem, strādājot noteiktajā projektā, ir tieši viens vadītājs,
bet projektam var būt vairāki vadītāji, bet inženieriem var būt vairāki vadītāji un vairāki
projekti. Vadītājs var pārvaldīt vairākus projektus.
4.17 att. Ternārās saites transformācija
58
Piemērā(Attēls 16), viens darbinieks piedalās vairākos projektos, un viņam ir vairākas
iemaņas, vienā projektā ir vairāki darbinieki un tiek izmantotas vairākas iemaņas.
4.18 att. Ternārās saites transformācija
3.2.10 Vispārinājuma saites transformācija
Piemērā(Attēls 17), Cilvēks var būt pircējs, vai darbinieks, vai abi kopā, vai neviens no tiem.
4.19 att. Vispārinājuma saites transformācija
59
PostrgreSQL realicācijā tiek izveidota pamata tabula Cilveks un divas tabulas, kas manto
atribūtus no pamata tabulas un pievieno savu individuālo atribūtu.
3.2.11 Saites ar asociācijas klasi transformācija
Piemērā(Attēls 18), Darbinieks var strādāt nevienā vai vienā firmā, vienā firmā strādā neviens
vai vairāki darbinieki. Asociācijas klase šajā transformācijā tiek glabāta kopā ar atsaucēm.
Tips algoti satur tipu algo kas satur asociācijas klases atribūtus, un atsauci uz tipu darbinieks.
4.19 att. Saites viens pret daudziem ar asociācijas klasi transformācija
Piemērā(Attēls 19), Darbinieks var strādāt vairākās firmās.
60
4.21 att. Saites daudzi pret daudziem ar asociācijas klasi transformācija
3.2.12 Unārās saites transformācijas
Ir iespējama situācija, kad darbinieks ir laulāts ar citu kompānijas darbinieku. Šajā
transformācijā objekta definīcijā tiek ietverts atribūts ar norādi uz šo pašu tipu. Tipam
darbinieks tiek izveidots atribūts ir_precejies, un tas satur norādi uz citu darbinieku.
4.22 att. Unārās saites transformācija
61
Piemērā(Attēls 21), viens inženieris var vadīt citus inženierus. Šajā transformācijā tiek
izveidota kolekcija ar norādēm uz tipu inzenieris, jo inženieris var vadīt vairākus citus
inženierus.
4.23 att Unārās saites transformācija
Piemērā(Attēls 22), katram darbiniekam ir iespēja būt par atskaites līdzautoru kopā ar citiem
darbiniekiem, vai arī uzrakstīt atskaiti vienam. Šeit tipam darbinieks tiek veidota kolekcija ar
norādēm uz šo pašu tipu darbinieks.
4.24 att Unārās saites transformācija
62
4 RELĀCIJU OBJEKTU DATUBĀZU IESPĒJU SALĪDZINĀJUMSDarbā tika apskatītas 4 relāciju-objektu datubāzu vadības sistēmas. Visas no apskatītajām
datubāzēm atbalsta objektu orientētos paplašinājumus. Tabulā dots datubāzu vadības sistēmu
salīdzinājums.
Tabula 4.1
Relāciju objektu datubāzu iespēju salīdzinājums
Kritērijs Oracle Informix DB2 PostgreSQL
Saliktu datu
tipu
izveidošana
Saliktā tipa
karkasa un tipa
ķermeņa
veidošana.
Nosauktais un
nenosauktais
raksta tips.
Saliktais tips ar
vairākiem
atribūtiem.
Saliktais tips ar
vairākiem
atribūtiem.
Kolekcijas Tiek izveidots
kolekcijas tips
un tad
kolekcija
izmantota lai
definētu
tabulu.
Kolekcijas ar
tipiem
LIST,SET,
MULTISET.
Tiek definētas
definējot
tabulu.
Kolekcijas
veidošana
netiek
atbalstīta.
Kolekcija
netiek
atbalstīta. To
veido ar
mainīga izmēra
masīvu.
Iebūvēti
saliktie datu
tipi
Ģeometriskie
datu tipi ar to
apstrādes
funkcijām
Metodes Metodes
definēšana tipa
ķermenī.
Metodes
definēšana
reizē ar tipu.
Tabulas
struktūras
mantošana
- - - Pakārtotā
tabula manto
visus
virstabulas
atribūtus, un
pievieno savus
63
individuālos
atribūtus.
Salikto tipu
mantošana
Pakārtotais tips
manto visas
virstipa
atribūtus un
pievieno savus
Pakārtotais tips
manto visas
virstipa
atribūtus un
pievieno savus
Pakārtotais tips
manto visas
virstipa
atribūtus un
pievieno savus
Objektu skatu
veidošana
Objektu skats
pamatojoties
uz saliktajiem
tipiem
Objektu skats
pamatojoties
uz saliktajiem
datu tipiem
64
SECINĀJUMIDarbā tika analizētas 4 populārākās relāciju-objektu datubāzu sistēmas (DBS). Veicot to
izpēti var izdarīt sekojošus secinājumus.
1. Salikto tipu veidošana ir kritērijs, kas atšķir relāciju-objektu datubāzu vadības sistēmas no
relāciju datu bāzu sistēmām. Visas no aplūkotajām datu bāzu sistēmām atbalsta salikto tipu
veidošanu. Visu datubāzu vadības sistēmu saliktajiem datu tipiem pamatā ir iebūvētie datu
tipi, vai citi saliktie tipi.
2. No pārējo DBS saliktajiem tipiem atšķiras Oracle salikto tipu veidošana, kurā no sākuma
tiek izveidots tipa karkass un pēc tam tiek veidots tipa ķermenis.
3. Informix DBS ir iespēja veidot nosaukto un nenosaukto raksta tipu. Nosauktais raksta tips
tiek veidots kā salikts datu tips, ar vairākiem atribūtiem. Tas datubāzē glabājas kā atsevišķs
datu tips, kuru kā tipu var izmantot vairāku tabulu kolonnu veidošanai, vai citu salikto tipu
veidošanai. Nenosauktais raksta tips tiek veidots tabulas definēšanas laikā un to nevar
izmantot citu tabulu kolonnu veidošanai, jo tas tiek veidots tikai vienai konkrētai tabulai.
Nenosaukto raksta tipu nevar piesaistīt tabulai, tas tiek lietots tikai lai identificētu tabulas
lauku.
4. Būtiska relāciju-objektu DBS priekšrocība ir kolekciju veidošana. No aplūkotajām datu
bāzu sistēmām kolekciju veidošanu atbalsta Oracle un Informix.
5.Vispārdomātākā kolekciju veidošana ir Informix DBVS, jo tur kolekcijai ir iespējams
norādīt papildus tipu LIST, SET, MULTISET kuri nosaka vai kolekcijas elementi var
atkārtoties, un vai tie ir sakārtoti.
6. DBVS PostgreSQL, kura nenodrošina kolekciju veidošanu nodrošina līdzīgu
funkcionalitāti lietojot mainīga izmēra masīvus. PostgreSQL masīvi var būt noteikta izmēra,
un mainīga izmēra.Kā masīva tipu nevar izmantot lietotāja definētos saliktos datu tipus.
7. DB2 kolekcijas nevar veidot vispār. Kolekciju veidošanas nenodrošināšana ir PostgreSQL
un DB2 būtisks trūkums, jo projektējot relāciju-objektu DBS ar kolekciju ir ērti veidot saiti
daudzi pret daudziem. Lai realizētu šo saiti starp divām tabulām datubāzu vadības sistēmā
PostgreSQL jāveido 3 tabulas, kurā divas no tām ir pamata tabulas un trešajā tabulā glabājas
atsauces uz abām tabulām. Šajā gadījumā būs sarežģītāka vaicājumu veidošana un ilgāks
vaicājuma izpildes laiks salīdzinājumā ar paņēmienu kad triju tabulu vietā tiek veidotas divas
tabulas ar iekļauto kolekciju, kur kolekcijas satur atsauces uz otru tabulu.
65
8. Iebūvētus saliktos ģeogrāfiskos datu tipus piedāvā tikai PostgreSQL DBVS, iebūvētie
saliktie ģeometriskie datu tipi nodrošina telpisku objektu glabāšanu. PostgreSQL DBVS ir
pieejamas arī funkcijas, kas darbojas ar šiem ģeometriskajiem datu tipiem. Tieši šīs īpašības
dēļ PostgreSQL datubāzu vadības sistēma tiek pielietota ģeogrāfiskajās informācijas sistēmās.
9. Metožu veidošanu atbalsta Oracle un DB2. Oracle metode tiek veidota tipa ķermenī, bet
DB2 metode tiek veidota definējot tipu. Metožu veidošana netiek atbalstīta Informix un
PostgreSQL.
10. Tabulas struktūras mantošanu atbalsta tikai PostgreSQL. Tabulas struktūras mantošana
ļauj ērti izveidot vispārinājuma saiti. Lai mantošanu realizētu pārējās datubāzu vadības
sistēmās vispirms ir jāveido saliktie datu tipi starp tiem jārealizē mantošana, un pēc tam
balstoties uz šiem tipiem jāveido tabulas. Salikto tipu mantošanā apakštipam var būt viens
virstips un vienai apakštabulai viena virstabula, bet tabulas struktūras mantošanā PostgreSQL
vienai apakštabulai var būt vairāki virstipi, tas nozīmē, ka viena tabula var mantot kolonnas
no vairākām tabulām.
11. Visas no aplūkotajām DBS piedāvā līdzīgu funkcionalitāti, bet visplašākā funkcionalitāte
ir firmas Oracle datu bāzes serverim. Oracle ir relāciju objektu datu bāzu tirgus līderis.
12. Ļoti aktuāls jautājums ir relāciju-objektu DB projektēšana. Diemžēl šai problēmai ir veltīti
ļoti maz darbu. Bakalaura darbā ir izstrādātas konceptuālo modeļu elementu un struktūru
transformācijas uz relāciju-objektu loģisko modeli DBS Oracle. Tas ļauj veidot atbilstošus
projektēšanas automatizācijas rīkus.
66
LITERATŪRA
1. Date, C.J.: An Introduction to Database Systems. Eight edition. Addison Wesley (2005)2. Codd, E. F.: A relational model of data for large shared data banks. CACM (1970)
3. C. J. Date. Database in Depth. Relational Theory for Practitioners. O’Reilly (2005)
4. Simon, A.R.: Strategic Database Technology: management for the year 2000. Morgan Kaufman Publishers, Inc. (1995)