RĪGAS TEHNISKĀ UNIVERSITĀTE

DATORZINĀTNES UN INFORMĀCIJAS TEHNOLOĢIJAS FAKULTĀTE

Lietišķo datorsistēmu institūts

CASE RĪKI DB IZSTRĀDEI: NAVICAT UN DATA ARCHITECT

1. praktiskais darbs mācību priekšmetā

„Informācijas sistēmas un CASE rīki”

Darbu izstrādāja: M. Pudāne

081RDB061

Darbu pārbaudīja: prof. J.

Eiduks

Rīga - 2012

Saturs

1 Uzdevuma nostādne..................................................................................................4

2 Teorētiskais pamatojums..........................................................................................5

3 Navicat......................................................................................................................6

3.1 Par Navicat........................................................................................................6

3.2 Navicat iespēju izpēte........................................................................................7

3.3 Navicat datu modelēšanas iespēju izpēte..........................................................9

4 Piemēra realizācija..................................................................................................13

4.1 Problēmsfēras apraksts....................................................................................13

4.2 Datu prasības...................................................................................................13

4.3 Sākotnējais konceptuālais modelis..................................................................13

4.4 Konceptuālais - fiziskais modelis Navicat......................................................14

4.5 Datu bāzes ģenerēšana Navicat.......................................................................16

4.6 Apgrieztā inženierija Navicat..........................................................................20

5 IBM Infosphere Data Architect..............................................................................22

5.1 Par rīku un darba uzsākšana............................................................................22

5.2 Modeļu transformācijas...................................................................................24

5.2.1 No konceptuālā uz loģisko..................................................................................24

5.2.2 No loģiskā uz fizisko..........................................................................................24

5.2.3 Konfigurācijas iespējas.......................................................................................26

5.3 Saites un to specifiskās iespējas......................................................................26

6 Secinājumi..............................................................................................................30

7 Izmantotā literatūra.................................................................................................31

1 Uzdevuma nostādne

Šī darba ietvaros bija nepieciešams veikt modeļu transformāciju, rezultātā iegūstot

datubāzi. Darba izpildei izvēlējos tādu rīku, kas man likās interesants, tomēr pietiekoši aktuāls

– Navicat, tomēr Navicat iespēju trūkuma dēļ pēc tam daļu darba vēlreiz izpildīju ar IBM

Infosphere Data Architect.

Darba mērķis ir apgūt datu bāzu projektēšanas pamatprincipus un praktiski uzprojektēt

datubāzi.

Darba uzdevumi ir izvēlēties rīku darba izpildei, izveidot konceptuālo modeli, tad

loģisko un visbeidzot fizisko modeli un noģenerēt datu bāzi, darba gaitā izpētot izvēlētā rīka

specifiskās iespējas.

2 Teorētiskais pamatojums

Uz modeļiem balstītā datu bāzes projektēšana notiek trīs tipu modeļu palīdzību:

sākumā tiek izveidots konceptuālais modelis, tad loģiskais un visbeidzot fiziskais modelis, no

kura, savukārt, tiek ģenerēta datubāze.

Konceptuālais modelis no visiem ir visaugstākajā abstrakcijas līmenī. Parasti šo

modeli veido kopā ar klientu, cilvēkam tas ir vislasāmākais un satur vismazāk specifisko datu.

Konceptuālajā modelī norāda:

realitātes

to atribūtus

saites starp realitātēm

Konceptuālo modeli var veidot dažādās tehnikās: vispopulārākais variants ir realitāšu

saišu diagramma ar atribūtu un kardinalitāšu atspoguļošanu, tomēr var izmantot arī UML

konceptu modeli vai pēc būtības jebkuru metodiku, kas parāda saites starp realitātēm.

Loģiskais modelis no konceptuālā modeļa atšķiras ar to, ka tajā papildus tiek parādītas

primārās un ārējās atslēgas. Šo modeli praktiski visur atspoguļo kā realitāšu saišu diagrammu,

kur kardinalitāšu vietā ir ārējās atslēgas.

Fiziskais modelis ir pēdējais solis pirms datubāzes ieviešanas. Tajā tiek veiktas

transformācijas:

realitātes -> tabulas

atribūti -> kolonu nosaukumi

Tiek pievienoti:

atribūtu tipi (kolonu datu tipi)

Tiek saglabātas

ārējās atslēgas

primārās atslēgas

No fiziskā modeļa tiek ģenerēts SQL kods un izveidota datubāze.

Šobrīd datu bāzu modeļu transformācijā attīstībā ir šādi virzieni:

objektorientētā pieeja datu bāzu projektēšanā – piemēram, mantošanas saites;

plašākas ģenerēšanas iespējas – iespēja no konceptuālā modeļa pilnībā

noģenerēt datubāzi;

iespēja veikt optimizāciju starpposmos starp modeļu transformācijām.

3 Navicat

3.1 Par Navicat

Navicat ir datubāzu projektēšanas un pārvaldības rīks, kas lietotājam ļauj izmantot

grafisko saskarni, tādējādi darbu ar datubāzi padarot uzskatāmāku un ērtāku. Navicat pieder

kompānijai PremiumSoft CyberTech , kura galvenokārt koncentrējas uz datubāzu pārvaldības

risinājumiem lielām kompānijām ar lielu darbinieku skaitu. Šī iemesla dēļ Navicat klientu

skaitā ir tādas kompānijas kā Apple, Accenture, Google u.c, kopā vairāk nekā 500 uzņēmumu

un 2 miljoni lietotāju 138 pasaules valstīs. Papildus Navicat eksistē arī NaviCoder, kas

atbalsta Java lietojumu izstrādi.

Navicat grupā ietilpst vairāki produkti, tas ir, Navicat versijas dažādām datubāzu

sistēmām, kuras tas atbalsta, Navicat Premium, kurā ietilpst visas iespējas, Navicat Essential,

kas atbalsta tikai pamatus (bez modelēšanas, eksporta un importa iespējām) un, protams,

Navicat Data Modeler. Šie rīki ir maksas rīki, tomēr ir pieejamas izmēģinājuma versijas

vienam mēnesim (izņemot Navicat Essentials). Praktiskā darba izpildei lejupielādēju Navicat

Premium. Pēc tam salīdzināšanai lejupielādēju Navicat Data Modeler, tomēr jāsaka, Navicat

Premium modelēšanas sadaļa un Navicat Data Modeler atšķīrās tikai ar saskarnes dizainu.

Navicat atbalsta pieslēgšanos šādām datubāzu sistēmām:

MySQL (sākot ar 3.21 versiju);

SQL Server (sākot ar MS Server 2000; Microsoft Windows un Mac OS X);

SQLLite (2 un 3);

Oracle (sākot ar 8.1);

PostgreSQL (sākot ar 7.3).

Lielākā daļa produktu ir saistīta ar datu bāzu administrēšanu, tomēr Navicat ļauj veikt

arī datubāzes analīzi atpakaļejošās projektēšanas veidā, kā arī papildināt vai sinhronizēt

datubāzi ar citām tabulām, tam izmantojot transformācijas mehānismus, tāpat arī veikt

atsevišķus datu bāzes projektēšanas posmus.

3.2 Navicat iespēju izpēte

Tā kā Navicat ir arī apbalvots kā labākais datu bāzu pārvaldības rīks, tad šī nodaļa

veltīta datubāzes pārvaldības iespēju izpētei.

Tabulu izveide ir ļoti vienkārša, līdzīga kā MS Office Access. Ar labo klikšķi

izkrītošajā izvēlnē var izvēlēties vai nu esošu SQL failu, vai arī izveidot jaunu tabulu.

Tabulu atribūtus ir iespējams pievienot vai nu ar tabulas skata palīdzību, vai arī rakstot

SQL vaicājumus.

Ģenerētā koda daļa: CREATE TABLE [dbo].[NewTable] (

[Numuri1] numeric NULL ,

[Numuri2] numeric NULL

)

GO

Tā kā esošis savienojums uz manas darbstacijas ir MS SQL Server, tad arī kods tiek

ģenerēts atbilstoši MS SQL Server prasībām.

Šeit ar grafiskās saskarnes palīdzību iespējams definēt arī ārējās atslēgas, trigerus,

ierobežojumus, ārējās atslēgas, tabulas glabāšanas fiziskos parametrus utt.

Tādā pašā veidā notiek darbs arī ar funkcijām, skatiem, vaicājumiem un ziņojumiem

jeb atskaitēm.

Piemēram, funkcijām ir iespējams ģenerēt SQL fragmentus ar Function Wizard

palīdzību:

CREATE PROCEDURE [guest].[y]

WITH ENCRYPTION

AS

BEGIN

-- routine body goes here, e.g.

-- SELECT 'Navicat for SQL Server'

END

Viens no iemesliem, kāpēc lietotāji izvēlas izmantot Navicat ir tas, ka tabulu ierakstus

ir iespējams apstrādāt līdzīgi kā MS Office Excel, uzlikt filtrus u.tml. Diemžēl

dokumentācijas trūkuma dēļ šo iespēju nepārbaudīju.

3.3 Navicat datu modelēšanas iespēju izpēte

Navicat piedāvā zīmēt modeļus un diagrammas, ar modeli saprotot diagrammu plašākā

nozīmē. Modelis satur visas realitātes, bet diagrammās parāda, kā šīs realitātes ir saistītas savā

starpā. Navicat modeļu paplašinājums ir *.nmd.

Diagrammu zīmēšanas iespējas Navicat Data Modeler nav sevišķi plašas. Diagramma piedāvā 5 elementus:

Realitāti (jeb tabulu) Saiti Piezīmi Attēlu Slāni

Lai koriģētu tabulu, jāatver izkrītošā izvēlne.

Tabulas koriģēšanas logs ir līdzīgs kā MS Access. Papildus tas piedāvā uzreiz uzstādīt

ārējās atslēgas un tabulas indeksēt. Tabulā Parameter 1 nozīmē lauka garumu, bet Parameter 2

– skaitļu skaitu aiz komata. Citiem datu tipiem otrā parametra vērtība ir 0. Iespējams, šo

lauciņu būtu vērts citiem datu tipiem nobloķēt pavisam.

Saites ievieto jau gatavās tabulās ar gataviem atribūtiem, izmantojot „drag&drop”. Šī

sistēma ir pietiekoši ērta, tomēr ir grūti, jo nav iespējams vispirms salikt realitātes, savilkt

saites un tad salikt atribūtus – tā kā es to esmu pieradusi darīt. Šo problēmu varētu atrisināt ar

konceptuālā modeļa ieviešanu.

Saišu kardinalitātēm ir šādas opcijas:

Lai arī papildus elementi – slāņi, piezīmes, attēli it kā ir pieejami, tomēr tiem nav

sevišķas funkcionālas nozīmes, tie palīdz saprast diagrammu, to komentēt, grupēt, bet ne datu

bāzes ģenerēšanā.

Viena no rīka pozitīvajām pusēm ir tā ērtais dizains. Bieži ir tā, ka mazajos

diagrammu rīkos nav padomāts par to, ka, iespējams, būs jāzīmē liela diagramma. Man arī ne

sevišķi patīk automātiskā lapu pievienošana, kāda ir Visio. Šeit, savukārt, ir iespējams definēt

diagrammas plašumu. Sīkums, bet patīkami.

Arī diagrammas auto izkārtojums man nelika vilties, viss bija salasāms un saprotams.

Ļoti daudz iespēju noformēt diagrammu, bet šeit jāmin arī viens būtisks trūkums – lai arī rīka

aprakstā ir minētas notācijas, tomēr tās tikai maina stilu. Piemēram, UML klašu diagrammai

nav iespējams automātiski pievienot metodes (šāda iespēja pastāv Enterprise Architect).

Protams, ir iespēja nomainīt datubāzi. Atkarībā no datubāzes mainās atsevišķas

izvēlnes, un , protams, ģenerētais kods.

Navicat Data Modeler ļauj veikt arī apgriezto inženieriju, importējot datu modeļus no

gatavām datubāzēm. Ar eksportēšanas palīdzību iespējams iegūt *.sql skriptu. Abas šīs

iespējas aprakstītas nākamajā nodaļā.

Sinhronizācija ļauj ieimportēt divas dažādas datubāzes, tās savienot ar ERD palīdzību.

Sarkanā parāda atšķirības starp avota datubāzi un mērķa datubāzi, norādot arī izdarītās

izmaiņas.

4 Piemēra realizācija

4.1 Problēmsfēras apraksts

SIA „Latgales autobusu parks” nodarbojas ar pasažieru pārvadāšanu īsajos (līdz 30

km), vidēji īsajos (līdz 70 km) un vidējos (līdz 150 km) maršrutos Latgales teritorijā un ir

lielākais šāda veida pakalpojumu nodrošinātājs savā reģionā.

Uzņēmuma mērķis ir nodrošināt klientus ar pārvadāšanas pakalpojumiem, kuri gan

kvalitātes, gan cenas ziņā ir konkurētspējīgi ar lielajiem autobusu parkiem, kā arī pārvadāt

pasažierus uz apdzīvotām vietām, kur sabiedriskā transporta satiksme ir neregulāra vai arī

vispār neeksistē

4.2 Datu prasības

Par katru autobusu sistēmai ir jāuzglabā tā numurs un sēdvietu skaits. Autobusiem ir

arī tehniskā uzskaites kartīte, kurā uzrādīts katras labošanas reizes datums, izmaksas, labotājs

un tas, vai autobusu ir izdevies salabot. Šoferu dati iekļauj darba līguma numuru, tiesību

numuru, personas kodu, vārdu un uzvārdu, mehāniķu dati ir tādi paši, bet tiesību numura vietā

atrodas kvalifikācijas nosaukums. Katram šoferim, administratoram un katram

automehāniķim ir darba līgums, kurā tiek glabāti dati par pieņemšanas datumu un termiņu, un

algu.

Šoferiem ir noteikti maršruti, ko viņi brauc, katram šoferim vairāki maršruti. Maršruta

informācija ietver garumu, ilgumu, sākumpunktu, galapunktu. Katram maršrutam ir piesaistīts

vismaz viens autobuss, vairāki autobusi var būt piesaistīti vairākiem maršrutiem.

4.3 Sākotnējais konceptuālais modelis

Sākotnējā konceptuālajā modelī iekļauti atribūti, saites, realitātes un kardinalitātes. No

apraksta identificētas 8 realitātes, no kurām 3 ir apakškopas darbiniekiem. Lai arī rīkā nav

iespējams ievietot mantošanu vai sarežģītākas saites, tomēr konceptuālajā modelī loģikas dēļ

to iekļāvu.

Modelis zīmēts rīkā MS Visio. Realitātes iekrāsotas ar zaļu krāsu.

4.4 Konceptuālais - fiziskais modelis Navicat

Lai arī Navicat mājaslapā un arī citos avotos minēts, ka iespējama gan

konceptuālā/loģiskā, gan fiziskā modelēšana, tomēr vismaz tiešā veida rīkā Navicat

konceptuālā modelēšana nav iespējama, var tikai panākt, ka diagramma izskatās pēc

konceptuālā modeļa, nomainot notāciju. Līdz ar to transformācija no loģiskā fiziskajā modelī

nenotiek. Tiesa, šajā fiziskajā modelī nepieciešams norādīt arī kardinalitātes, bet tādā

gadījumā parādās arī ārējo atslēgu lauki un saites ir „jāsavelk” nevis starp realitātēm, bet jau

starp konkrētiem atribūtiem.

Modelī ir jābūt kļūdu pārbaudei, rīkā Navicat pārbaude tiek realizēta šādi: ja ir

nesakritības datu tipos vai arī tamlīdzīgas kļūdas, kas neļauj savienot šīs tabulas, saišu „gali”

jeb kardinalitāšu norādes iekrāsojas sarkanas.

Diezgan neērti šajā brīdī ir tas, ka nav īsti skaidrs, kur tieši ir kļūda, pie kam kļūdas

paziņojumu „neizmet” arī pie transformācijas.

Loģiskais/fiziskais modelis:

Kļūda modelī:

4.5 Datu bāzes ģenerēšana Navicat

Lai būtu iespējams ģenerēt datu bāzi, vispirms to nepieciešams eksportēt kā SQL failu.

Var izvēlēties konkrētas tabulas. Jānorāda izvades fails.

Noģenerētais datu bāzes kods generic datubāzei parādīts tālāk. Ja izvēlas konkrētu

datu bāzes sistēmu, tad kods izskatās mazliet citādi, piemēram, SQL Serverim.

CREATE TABLE "Maršruts" (

"Garums" NUMERIC NULL,

"Maršruta numurs" NUMERIC(5) NULL,

"Ilgums" TIME NULL,

"Sākumpunkts" VARCHAR(255) NULL,

"Galapunkts" VARCHAR(255) NULL,

PRIMARY KEY ("Maršruta numurs")

);

CREATE TABLE "Šoferis" (

"Vārds" VARCHAR(255) NOT NULL,

"Uzvārds" VARCHAR(255) NOT NULL,

"Personas kods" CHARACTER(85) NOT NULL,

"Līguma numurs" NUMERIC NOT NULL,

"Tiesību numurs" VARCHAR(255) NULL,

PRIMARY KEY ("Personas kods")

);

CREATE TABLE "Darbinieks" (

);

CREATE TABLE "Darba līgums" (

"Numurs" NUMERIC NOT NULL,

"Pieņemšanas datums" DATE NOT NULL,

"Kvalifikācija" VARCHAR(255) NOT NULL,

"Alga" FLOAT(2) NOT NULL,

PRIMARY KEY ("Numurs")

)

CREATE TABLE "Autobuss" (

"Numurs" NUMERIC NOT NULL,

"Sēdvietu skaits" NUMERIC NOT NULL,

PRIMARY KEY ("Numurs")

);

CREATE TABLE "Mehāniķis" (

"Vārds" VARCHAR(255) NOT NULL,

"Uzvārds" VARCHAR(255) NOT NULL,

"Personas kods" CHARACTER(85) NOT NULL,

"Līguma numurs" NUMERIC NOT NULL,

"Kvalifikācijas nosaukums" VARCHAR(255) NULL,

PRIMARY KEY ("Personas kods")

);

CREATE TABLE "Administrators" (

"Vārds" VARCHAR(255) NOT NULL,

"Uzvārds" VARCHAR(255) NOT NULL,

"Personas kods" CHARACTER(85) NOT NULL,

"Līguma numurs" NUMERIC NOT NULL,

PRIMARY KEY ("Personas kods")

);

CREATE TABLE "Tehniskā kartīte" (

"Autobusa numurs" NUMERIC NOT NULL,

"Labošanas datums" DATE NOT NULL,

"Labošanas izmaksas" FLOAT(5) NOT NULL

);

ALTER TABLE "Darba līgums" ADD CONSTRAINT "fk_Darba līgums_Šoferis_1"

FOREIGN KEY ("Numurs") REFERENCES "Šoferis" ("Līguma numurs");

ALTER TABLE "Maršruts" ADD CONSTRAINT "fk_Maršruts_Autobuss_1"

FOREIGN KEY ("Maršruta numurs") REFERENCES "Autobuss" ("Numurs");

ALTER TABLE "Administrators" ADD CONSTRAINT "fk_Administrators_Darba

līgums_1" FOREIGN KEY ("Līguma numurs") REFERENCES "Darba līgums"

("Numurs");

ALTER TABLE "Mehāniķis" ADD CONSTRAINT "fk_Mehāniķis_Darba līgums_1"

FOREIGN KEY ("Līguma numurs") REFERENCES "Darba līgums" ("Numurs");

ALTER TABLE "Šoferis" ADD CONSTRAINT "fk_Šoferis_Maršruts_1" FOREIGN

KEY ("Personas kods") REFERENCES "Maršruts" ("Maršruta numurs");

ALTER TABLE "Tehniskā kartīte" ADD CONSTRAINT "fk_Tehniskā

kartīte_Autobuss_1" FOREIGN KEY ("Autobusa numurs") REFERENCES "Autobuss"

("Numurs");

ALTER TABLE "Mehāniķis" ADD CONSTRAINT "fk_Mehāniķis_Tehniskā

kartīte_1" FOREIGN KEY ("Personas kods") REFERENCES "Tehniskā kartīte"

("Autobusa numurs");

Manā skatījumā, pozitīvi ir tas, ka šajā SQL failā var veikt izmaiņas pirms datu bāze ir

ģenerēta; trūkums – kods ir nepārskatāms.

Tālākie soļi paredz *.sql faila izpildi.

Var redzēt, ka kaut kur datu fiziskajā modelī man nav parādīta kļūda. Lai arī tabulas ir

izveidotas, viena saite starp tām palikusi neizpildīta.

Manuāli izlaboju kļūdu.

ALTER TABLE [dbo].[Tehniskā kartīte] ALTER COLUMN [Autobusa numurs]

decimal(5)

GO

Izveidotās tabulas. Tagad tās ir iespējams aizpildīt tāpat kā MS Access.

4.6 Apgrieztā inženierija Navicat

Tagad ar apgrieztās inženierijas palīdzību ir iespējams atkal izgūt datu bāzes fizisko

modeli – pārliecināšos, ka viss kārtībā.

Ģenerētais modelis:

Ģenerētais modelis vienai no noklusētajām datubāzēm.

5 IBM Infosphere Data Architect

Pēc tam, kad biju izpildījusi rīku Navicat, man tomēr radās vēlme izpētīt rīku ar mazliet

interesantākām iespējām. Tā kā darbā tāpat jau biju ieguldījusi diezgan laika, tad Data

Architect aprakstīju tikai šādus punktus (to, kas interesēja mani pašu):

mazliet par rīku;

par tā piedāvātājām iespējām modeļu transformācijai

par tā piedāvātajām iespējām saišu izveidē.

5.1 Par rīku un darba uzsākšana

IBM Infosphere grupā ietilpst rīki, kas domāti datu bāzu administrēšanai un

projektēšanai, kā arī savienošanai ar dažādām platformām un citiem IBM rīkiem. Šī darba

izpildei vispiemērotākais rīks ir Data Architect, kas ļauj veikt manipulācijas ar dažādiem

modeļiem. Rīkam ir pieejama izmēģinājuma versija 30 dienām, ar ko pilnīgi pietiek darba

izpildei. Cits jautājums ir tas, ka lai dabūtu šo versiju, ir jābūt reģistrētam IBM mājaslapā un

apstiprinātam kā studentam vai universitātes darbiniekam.

Darbs ar rīku, tāpat kā ar citiem IBM rīkiem, ir pietiekoši vienkāršs un intuitīvi

saprotams, bet retāk pieejamām iespējām ir nepieciešams lasīt dokumentāciju, kura, arī tipiski

IBM programmatūrai, ir kvalitatīva un labi strukturēta.

Tā kā rīku instalēju uz datora, uz kura nebija DB2, instalācijas laikā automātiski tika

uzstādīta Derby Apache datu bāze. Lietotāja saskarne:

Darbu uzsāk ar to, ka izvēlas darbtelpu (praktiski tā ir mape, kuras ceļš ir „zināms”

IBM rīkiem un līdz ar to ir atvieglots darbs ar izveidotajiem resursiem).

Darbu uzsāk ar loģiskā modeļa izveidi.

5.2 Modeļu transformācijas

5.2.1 No konceptuālā uz loģisko

Transformācijas kā tādas no konceptuālā uz loģisko modeli nav. Pamatdoma ir tāda,

ka pēc tam, kad ir izveidots konceptuālais modelis, to ir iespējams papildināt, lai izveidotu

loģisko modeli. Rezultātā izveidojas loģiskais modelis, kurā atspoguļotas arī primārās un (vai)

ārējās atslēgas

Ārējo atslēgu lauki parādās automātiski. Loģiskais modelis iepriekš aprakstītajam

piemēram:

5.2.2 No loģiskā uz fizisko

Transformācija no loģiskā uz fizisko modeli notiek diezgan tipiski šādiem rīkiem: ir

iespēja norādīt dažādas transformēšanas iespējas, piemēram, noklusēto datu tipu, virkņu

definēšanu, primāro atslēgu lauku definēšanu – praktiskas lietas, kuras jebkurā gadījumā būtu

jāveic manuāli.

Interesantākā lieta šeit, manuprāt, ir tā, ka līdz ar fiziskā modeļa ģenerēšanu, tabulas

parādās arī datu bāzē – turklāt iespējās neatradu vietu, kur šādu ģenerāciju varētu noņemt. Tā

kā darbu izpildīju tikai ar vienu datubāzi, pieņemu, ka tas varētu būt atkarīgs no datu bāzu

vadības sistēmas.

Galvenais transformācijas iespēju logs:

Ģenerēto fizisko modeli šis rīks attēlo kā pakotņu diagrammu (package diagram).

5.2.3 Konfigurācijas iespējas

Diezgan interesanti ir tas, ka Data Architect piedāvā izveidot lietotāja uzstādījumus

cita tipa transformācijām, piemēram, loģiskā modeļa pārveidošanai uz UML vai XML shēmu.

No šīm izmēģināju pārveidot uz UML – rezultāti aprakstīti mazliet tālāk, pie

mantošanas saites apraksta. Transformāciju izveides logs (kurā parādītas arī visas iespējas):

5.3 Saites un to specifiskās iespējas

Data Architect ir tiešām ļoti plašas iespējas, ar kuru palīdzību ir iespējams atspoguļot

dažādus saišu tipus.

Viena no noderīgākajām iespējām, manuprāt, ir iespējas, kādā veidā realizēt tabulu

izveidi gadījumā, ja šīs saites savā starpā ir saistītas. Ir trīs iespējas:

separate table – tabulas izveido parastajā veidā;

roll up - tabulu, kura ir kreisajā pusē, pievieno datubāzes tabulas augšpusē;

roll down – tabulu, kura ir kreisajā pusē, pievieno datubāzes tabulas apakšā.

Pēc fiziskā modeļa ģenerācijas var redzēt, ka visu trīs tabulu informācija apvienota

vienā tabulā ar nosaukumu „tehniskā kartīte” jo zem šīs tabulas tika „parullēta” informācija

par autobusiem un maršrutiem, savukārt maršruts tika pievienots augstāk par autobusu.

Tāpat saitēm eksistē arī standarta iespējas; ja saite iezīmēta kā neobligāta,

fiziskajā modelī to var neizveidot, ja tā traucē struktūrai, piemēram, veido ciklus.

Vēl viena svarīga iespēja, kas eksistē saitēm, ir variants, ko darīt gadījumā, ja tabulu

ieraksti tiek mainīti. Piemēram, ja ir iestatīta iespēja CASCADE, tad tabulas ieraksta

ievietošanas gadījumā tiek ievietots ieraksts pretējā atbilstošajā tabulā; dzēšanas gadījumā tiek

izdzēsts atbilstošais ieraksts otrajā tabulā.

Mantošanas iespēja:Kā jau minēju sākumā, viens no šī brīža attīstības virzieniem objektorientētās

pieejas datu bāzu projektēšanā, tāpēc noteikti vēlējos izmēģināt mantošanas saiti. Loģiskajā

modelī šo saiti realizē šādi:

Rezultātā tiek izveidota mantošanas grupa jeb klase, kurā parādās virsklases

nosaukums un atribūti. Tomēr, pēc tam, kad noģenerēju fizisko modeli, ir redzams, ka šī saite

pazūd vispār. Arī dokumentācijā par šo problēmu sīkāk neko neatradu.

Pēc tam, kad izmēģināju noģenerēt UML diagrammas (klašu diagrammu), tad gan šī

mantošanas saite uzrādījās.

Mans secinājums ir šāds: ar IBM Infosphere Data Architect mantošanas saiti realizēt ir

iespējams, tomēr vislabāk to darīt ar rollup iespējas palīdzību.

6 Secinājumi

Darba izpilde veicās pietiekoši gludi, ja neskaita to, ka grupa izjuka burtiski pēdējā

brīdī, tāpēc darbi bija jāpārplāno un atsevišķās vietās (piemēram, pie funkciju koda

ģenerācijas) gribējās papētīt un aprakstīt mazliet sīkāk.

Navicat rīks ir diezgan interesants, pirmā lieta, kas ir izlasāma gan atsauksmēs, gan arī

ieraugāma, tiklīdz tas ir palaists – lietotājam draudzīga saskarne, kas lielākoties ir intuitīvi

saprotama. Jāsaka, ka Help sadaļa (tātad dokumentācija) šai programmai nav sevišķi attīstīta,

paskaidrojumi ir ļoti lakoniski, bieži prasās plašākus piemērus vai detalizētāku aprakstu.

Mājaslapā pieejama videodokumentācija, tomēr man likās dīvaini, ka tēmas, kas man liekas

pašsaprotamas (diagrammas izveide) tajās ir iekļautas, savukārt sarežģītāku, piemēram,

sinhronizāciju, neatradu. Turpinot par saskarni – ar rīku ir ļoti viegli strādāt, liekas, ka šis ir

patīkamākais DB pārvaldības rīks, ar kādu man ir nācies saskarties. Tas nav pārslogots ar

liekām funkcijām, tomēr jāsaka – reizēm nav arī vajadzīgo funkciju.

Vislielākie rīka trūkumi, manuprāt, šobrīd ir transformācijas neesamība (no

konceptuālā modeļa uz fizisko) un modeļu pārbaude/kļūdu izvade.

Tās transformācijas, kuras ir, ir ļoti vienkārši izpildīt, tomēr novēroju, ka uz Oracle

11g versiju SQL „nepārnesas” tā, kā vajadzētu. Turklāt trūkst vairāku būtisku transformāciju,

lai arī mājaslapā ir rakstīts, ka tās ir pieejamas.

Viena no labākajām lietām ir tāda, ka starp fizisko modeli un gatavo datubāzi ir

iespēja palabot SQL kodu.

Kļūdu ziņojumi ir nesaprotami, turklāt bieži, pie transformācijām, to nav, un kļūda,

kas pieļauta agrākās projektēšanas stadijās, var pārvietoties tālāk.

Jāpiebilst, ka šim rīkam ir iespējas pilnveidoties, ņemot vērā, ka šī ir pirmā Navicat

versija ar datu modelētāju.

Pēc darba ar Navicat netīšām uzgāju rīku IBM Data Architect, kurā pamanīju vairākas

interesantas iespējas, tajā skaitā ģeneralizācijas saiti, kuru nolēmu izmēģināt. Tiesa, nācās

vilties, jo datu bāzes ģenerēšanā šī saite pazūd. Tomēr, tā kā diezgan pastrādāju arī ar šo rīku,

izlēmu to iekļaut darbā.

7 Izmantotā literatūra

1. http://publib.boulder.ibm.com/infocenter/dataarch/v7r6/index.jsp - IBM Infosphere Data

Architect dokumentācija

2. http://www.navicat.com/manual/online_manual/en/navicat_datamodeler/win_manual/

index.html - Navicat dokumentācija

3. http://www.zachman.com/ea-articles-reference/58-conceptual-logical-physical-it-is-

simple-by-john-a-zachman - atšķirības starp konceptuālo, loģisko, fizisko līmeni

4. http://en.wikipedia.org/wiki/Conceptual_model

5. http://en.wikipedia.org/wiki/Logical_data_model

6. http://www.1keydata.com/datawarehousing/data-modeling-levels.html (pielāgots)