RĪGAS TEHNISKĀ UNIVERSITĀTE

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

Informācijas tehnoloģijas institūts

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

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

„Toad Data Modeler”

Autors: Santa Pūce

Grupa: 2DMI0-2

Pārbaudīja: prof. J. Eiduks

RĪGA 2011

ANOTĀCIJA

2.praktiskajā darbā ir izprojektēts datu bāzes Universitāte piemērs ar DB un

lietojumprogrammu projektēšanas rīku Toad Data Modeler, kurš sevī apvieno objektorientēto,

konceptuālo un fizisko datu modelēšanas iespējas.

Darbs ir izstrādāts 2 daļās - teorētiskā daļa, kurā tiek apskatīts un izpētīts izmantojamais

CASE rīks, tā iespējas un funkcionalitāte, un praktiskā daļa, kurā tiek apskatīta DB realizācija ar

Toad Data Modeler rīka palīdzību. Vēl teorētiskajā daļā tiek apskatīti vairāki piemēri tām rīka

iespējām, kuras praktiskajā darba daļā netiek izmantotas - apvērstā inženierija, versiju

menedžeris, uzdevumu saraksts, sinhronizācija un automātiskā izkārtošana. Darba gaitā tiek

izveidots loģiskais modelis, kurš pēc īpašībām ir arī konceptuālais modelis ar entītijām, saitēm

un ierobežojumiem. Pēc loģiskā modeļa transformācijas, tiek iegūts fiziskais DB modelis. Abi

modeļi tiek salīdzināti savā starpā, kā arī no fiziskā modeļa atkārtoti ir iegūts loģiskais modelis ar

nolūku salīdzināt sākotnējo loģisko modeli ar beigu modeli. Gan fiziskajam, gan loģiskajam

modelim tiek uzģenerētas atskaites. Gala rezultātā tiek iegūts arī SQL kods izveidotajai DB.

2

Saturs

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

2. Teorētiskā daļa...........................................................................................................................5

2.1. СASE rīks: definīcija, raksturojums un izmantošana...........................................................5

2.2. Toad Data Modeler: definīcija un iespējas..........................................................................6

2.3. Toad Data Modeler instalācija.............................................................................................7

2.4. CASE rīka Toad Data Modeler darba vide........................................................................11

2.5. Modeļa priekšstata līmeņi...................................................................................................12

2.6. Rīka tehniskās prasības un iespējas...................................................................................13

2.7. TDM Modeļi........................................................................................................................19

2.8. Fiziskais modelis un ar to saistīta funkcionalitāte.............................................................21

2.9. Apvērstā inženierija (reverse engineering)........................................................................25

2.10. Papildus TQM funkcijas un iespējas................................................................................28

3. Praktiskā daļa..........................................................................................................................30

3.1. Konceptuālais modelis „Visio” vidē..................................................................................30

3.2. Loģiskais modelis................................................................................................................30

3.3. Fiziskais modelis.................................................................................................................44

3.4. SQL koda ģenerēšana.........................................................................................................54

3.5. Loģiskā un fiziskā modeļa salīdzināšana............................................................................55

4. Subjektīvais novērtējums........................................................................................................58

Secinājumi....................................................................................................................................59

Izmantotā literatūra....................................................................................................................60

1.pielikums.....................................................................................................................................61

3

1. UZDEVUMA NOSTĀDNE

1. Jāizpēta CASE rīkā realizējamie modeļi un to, kā tie saistīti savā starpā:

konceptuālais modelis;

loģiskais modelis (dati);

fiziskais modelis.

2. Jāizpēta apzīmējumiem izmantojamās notācijas.

3. Jāsniedz piemēri:

konceptuālais modelis loģiskais modelis fiziskais modelis

4. Jāizpēta CASE rīka redaktora iespējas (automātiskais un manuālais):

loģiskā modeļa manuālās redaktora iespējas;

fiziskā modeļa redaktora iespējas (automātiskās un ar roku).

5. Jāsniedz subjektīva kritika CASE rīka iespējām un struktūrām:

realizējamās un nerealizējamās struktūras;

rīka priekšrocības un trūkumi.

6. Jāsniedz secinājumi par izpētīto CASE rīku.

4

2. TEORĒTISKĀ DAĻA

2.1. СASE rīks: definīcija, raksturojums un izmantošana

Definīcija. CASE (Computer Aided Software Engineering) - agrāk tas tika pielietots

attiecībā uz programmnodrošinājuma izstrādes automatizāciju, bet mūsdienās CASE rīks apzīmē

informācijas sistēmu (IS) izstrādes procesu kopumā, ietverot:

IS izstrādi un nodrošinājumu;

analīzi;

prasību formulēšanu;

lietišķu programmnodrošinājumu un datu bāžu projektēšanu;

koda ģenerēšanu;

testēšanu;

dokumentēšanu;

kvalitātes nodrošināšanu;

konfigurācijas;

projekta vadību;

un citus procesus.

Līdz ar to CASE tehnoloģijas veido veselu, atsevišķu IS izstrādes vidi. Vispārīgā nozīmē

CASE tehnoloģija ir programmsistēmu projektēšanas metodoloģija, kā arī instrumentālu līdzekļu

salikums, kas ļauj uzskatāmā formā modelēt priekšmetisko vidi, analizēt izveidoto modeli visos

izstrādes un IS nodrošinājuma etapos, kā arī izstrādāt lietojumprogrammatūras, atbilstoši

lietotāju sniegtās informācijas prasībām. Lielākā daļa no eksistējošiem CASE rīkiem, ir bāzēti uz

strukturālām vai objektorientētām analīzes un projektēšanas metodoloģijām, kas izmanto

specifikācijas diagrammu vai teksta veidu, lai aprakstītu ārējās prasības, saites starp sistēmas

modeļiem, sistēmas uzvedības dinamiku un programmlīdzekļu arhitektūru.

CASE produkta galvenās sastāvdaļas:

metodoloģija (Method Diagrams) - nosaka vienotu grafisko valodu un noteikumus

strādājot ar to;

5

grafiskie redaktori (Graphic Editors) - palīdz zīmēt diagrammas (parādījās kopā ar

PC un GUI izplatīšanos (tā saucamā „upper case” tehnoloģija));

ģenerators - pēc modeļa grafiskā priekšstata var noģenerēt izejas kodu dažādām

platformām (tā saucamā „low case” CASE tehnoloģiju daļa);

repozitorijs - savdabīga datu bāze programmētāju darba rezultātu glabāšanai.

Dažādi statistiskie mūsdienu pētījumi apgalvo, ka CASE rīku izmantošanas

programmlīdzekļu izstrādes procesā ir efektīva. Tomēr eksistē neveiksmju procents, kurš ir

diezgan liels. Ņemot vērā CASE rīku dabas daudzveidību, nevajadzētu galvot par reāliem

ieguvumiem no to izmantošanas. Daži faktori, kas apgrūtina CASE rīka izmantošanas

iespējamā efekta noteikšanu:

plaša CASE rīku kvalitātes un iespēju daudzveidība;

relatīvi neliela CASE rīku izmantošanas pieredze;

plaša ieviešanas prakses daudzveidība;

detalizētu metriku trūkums;

plašs priekšmetisko apgabalu diapazons;

dažāda CASE rīku integrācijas pakāpe dažādos projektos.

2.2. Toad Data Modeler: definīcija un iespējas

Definīcija. Toad Data Modeler – daudzfunkcionāls datu bāžu un lietojumprogrammu

izstrādes rīks, kas vienā integrētā vidē apvieno gan objektorientētās, gan konceptuālās fizisko

datu modelēšanas iespējas. Intuitīvi saprotamais lietotāja interfeiss un populāro datu bāzes

vadības sistēmu (DBVS) atbalsts padara Toad Data Modeler par unikālu risinājumu tam, lai

paātrinātu sarežģītu informācijas sistēmas DB, kā arī lietojumprogrammu izstrādi un analīzi. Ir

iespējama datu plūsmas diagrammu izveide un ātra ER-diagrammu izveide dažādām datubāzes

sistēmām, kā piemēram MS SQL, Oracle, Sybase.

Izmantojot Toad Data Modeler, ir iespējams:

grafiski realizēt DB struktūru (loģiskās un fiziskās ER diagrammas);

veidot ER diagrammas vairākām DB sistēmām (Oracle, MS SQL, DB2, MySQL, PostgreSQL, utml.)

pārveidot jau eksistējošu DB struktūru un attēlot eksistējošās DB struktūru diagrammas formā;

6

pievienot loģiskos datus diagrammām un labāk aprakstīt eksistējošās DB struktūras;

pārbaudīt ER diagrammas modeļus un apskatīt piedāvāto kļūdu, brīdinājumu un ieteikumu (hints) sarakstus;

automātiski ģenerēt SQL kodu, atbilstoši izvēlētajai DB;

ģenerēt detalizētu dokumentāciju HTML, PDF, RTF formātos;

sinhronizēt modeli ar fiziski eksistējošām DB, izmantojot Alter Script Generation un Model Merge opcijas;

saglabāt izmaiņu masīvus, izmantojot Version Manager opcijas;

veidot uzdevumu sarakstu, kurš attiecas uz modeli vai noteiktu modeļa daļu, izmantojot To-Do list opciju;

ātri un ērti izpildīt ikdienas uzdevumus, pateicoties GUI uzlabojumiem;

konfigurēt produktu, atbilstoši lietotāja prasībām;

ietekmēt objektus ER diagrammās caur iekšējo skriptingu.

2.3. Toad Data Modeler instalācija

Lai izpētītu CASE rīku Toad Data Modeler, tas ir jāuzinstalē lietotāja datorā. Šim

mērķim tiek palaists Toad Data Modeler setup.exe fails. Pēc noklusējuma tiek piedāvāta vieta

lietotāja datorā, kurā atradīsies Toad Data Modeler pēc instalācijas. Instalācijas gaitā tiek

izvēlētas īpatnības (atbalsts priekš atšķirīgām DB sistēmām), kuras vēlamies instalēt. CASE rīka

instalācijas procesu ir iespējams apskatīt zemāk attēlotajos attēlos.

7

2.1. att. CASE rīka Toad Data Modeler palaišana

2.2. att. Licences apstiprināšana

2.3. att. Instalācijas personalizācija – iespējams uzstādīt piekļuvi rīkam vienam

vai jebkuram lietotājam

8

2.4. att. Rīka atrašanās vietas uzstādīšana (tiek izvēlēts noklusējums)

2.5. att. Datubāzu atbalsta izvēle, kurās tiks ieinstalētas TDM

2.6. att. Tiek izvēlēti papildus uzstādījumi rīka ikonas izvietošanā uz lietotāja datora

9

2.7. att. Rīka instalēšanas process

2.8. att. Instalācijas pabeigšana

Ierobežojumi: rīka trial version neiekļauj visas iespējas un atļauj lietotājam saglabāt

modeli, kurā ir mazāk nekā 25 entītijas.

10

2.9. att. TDM pirmā palaišana, kur tiek izvēlēta jauna konfigurācija

2.10. att. Darba uzsākšana

2.4. CASE rīka Toad Data Modeler darba vide

Lietotāja saskarne

Rīka lietotāja saskarne ir izpildīta Windows-lietotnes stilā. Tā ir pietiekami vienkārša un

intuitīvi skaidra.

Rīku joslas funkcijas:

atvērt jaunu modeli

eksistējošā modeļa atvēršanas

dialoga logs

saglabāt modeli

apvērstās inženierijas veidne

pievienot modeli versiju menedžerim

drukāšanas dialoga logs

pirms drukas aplūkošanas dialoga

logs

lietotnes pārlūka logs

opciju dialoga logs

lapas formāta izvēles logs

modeļa pārlūka logs

modeļa pārbaudes dialoga logs

skripta ģenerēšanas dialoga logs

atskaišu veidošanas veidne

Fiziskā modeļa veidošanas funkcijas:

izvēles veikšanas kursors

pievienot entītiju modelī

pievienot identificējošu saiti modelī

11

pievienot neidentificējošu saiti

modelī

pievienot M:N saiti modelī

pievienot Skatu modelī

pievienot Materializētu skatu modelī

pievienot piezīmi modelī

pievienot piezīmju līniju modelī

pievienot izstrādāšanas zīmogu

modelī

pievienot uzrakstu kategorijām

modelī

Loģiskā modeļa veidošanas funkcijas:

izvēles veikšanas kursors

pievienot entītiju modelī

pievienot identificējošo saiti modelī

pievienot neidentificējošu saiti

modelī

pievienot mantošanas struktūru

modelī

pievienot piezīmi modelī

pievienot piezīmju līniju modelī

pievieno izstrādāšanas zīmogu

modelī

pievieno uzrakstu kategorijām

modelī

12

Meta modeļa veidošanas funkcijas:

izvēles veikšanas kursors

pievienot klasi meta modelī

pievienot asociāciju meta

modelī

pievienot ģeneralizāciju meta

modelī

pievienot piezīmi meta modelī

pievienot piezīmju līniju meta

modelī

pievienot izstrādāšanas zīmogu

meta modelī

pievienot uzrakstu kategorijām

meta modelī

Meta modeļa veidošanas rīki:

mērogošanas rīks - var

izvēlēties apgabalu, kuru ir

jāpalielina

samazināt

palielināt

procentuāla mērogošana

attēlošanas līmeņa izvēlne

izklājuma dialoga logs

izlīdzina izvēlēto saišu punktus

13

2.5. Modeļa priekšstata līmeņi

Toad Data Modeler pastāv divi modeļa priekšstata līmeņi – loģiskais un fiziskais.

Loģiskais līmenis – abstrakts skats uz datiem. Šajā līmenī dati tiek izskatīti tā kā tie ir

reālajā dzīvē. Modeļa objekti, kas tiek piedāvāti loģiskajā līmenī, saucas par realitātēm

(entītijām) un atribūtiem. Loģiskais modelis ir universāls un šajā līmenī nav saistīts ar konkrētu

realizāciju DBV sistēmā.

Fiziskais līmenis - atkarīgs no konkrētās DBVS. Faktiski tas ir sistēmas kataloga

attēlojums. Fiziskajā modelī ir informācija par visiem DB objektiem. Tā kā objektu standarti

neeksistē (piemēram, nav datu tipa standartu), fiziskais modelis ir atkarīgs no konkrētas DBVS.

Līdz ar to, vienam un tam pašam loģiskajam modelim var atbilst vairāki fiziskie modeļi.

2.6. Rīka tehniskās prasības un iespējas

TDM tehniskās prasības

Toad Data Modeler tehniskās prasības ir aprakstītas Tab.1.

2.1. tabula

TDM tehniskās prasības

Minimālās prasības Optimālās prasības

Platforma Pentium IV Pentium dual core

Atmiņa 256 MB 1 GB

Vieta uz cietā diska 100 MB 200 MB

Operētājsistēma Windows 2000/XP/Vista Windows 2000/XP/Vista

Toad Data Modeler cena ir 479$. Darba gaitā tiks izmantota programmas „trial” versija.

Atbalstīto DB saraksts

Viena no svarīgām Toad Data Modeler īpašībām ir liels datu bāžu skaits, ko atbalsta šis

CASE rīks. Zemāk ir uzskaitītas datu bāzes, kurām var realizēt fizisko ER diagrammas modeli

Toad Data Modeler rīkā:

DB2 v. 9 (LUW)

DB2 UDB v. 8 (LUW)

MS Access 2000/2002/2003

MS SQL Server 2008

MS SQL Server 2005

MS SQLServer 2000

MySQL 5.1

MySQL 5.0

Oracle 11g

Oracle 10g

Oracle 9

PostgreSQL 8.3

PostgreSQL 8.2

PostgreSQL 8.1

Sybase ASE 15

Sybase ASE 12.5

Diagrammu attēlošanas līmeņi

Toad Data Modeler ir vairāki diagrammu attēlošanas līmeņi:

entītiju līmenis,

atribūtu līmenis,

primāro atslēgu līmenis,

unikālo atribūtu līmenis,

aprakstu līmenis.

Pārslēgties uz citiem attēlošanas līmeņiem var izvēloties vēlamo līmeni no rīku paneļiem,

kā arī no galvenās izvēlnes ViewDisplay Level.

2.11. att. Attēlošanas līmeņa izvēle no rīku paneļa

2.12. att. Attēlošanas līmeņa izvēle no galvenās izvēlnes

Notācijas

Modeļu veidošanai Toad Data Modeler rīkā ir iespējams izmantot divas notācijas:

IDEF1X,

IE (Information Engineering).

IDEF1X metodoloģija tika izstrādāta ASV armijas vajadzībām un ir plaši pielietojama

ASV valsts iestādes, finanšu un rūpniecības korporācijās. IE metodoloģija tiek pielietotas,

galvenokārt, rūpniecībā. Informācijas modelēšanas notācijas IDEF1X un IE tiek bāzētas uz

diagrammām „realitāte-saite”, kas iekļauj sevī divus bāzes elementus:

realitāte – objekts, kas var tikt identificēts kaut-kādā veidā, kas atšķirtu to no pārējiem

objektiem. Abās metodoloģijās realitāte ir attēlota kā taisnstūris, kur taisnstūra augšā ir

realitātes nosaukums. Taisnstūris ir sadalīts ar horizontālo līniju. Zem līnijas ir realitātes

atribūti – pašā augšā ir primāro atslēgu atribūti, bet zemāk - parēji atribūti. Eksistē divu

tipu realitātes:

atkarīga realitāte – šī realitātes eksemplāra noteikšanai ir nepieciešams

atsaukties uz neatkarīgas realitātes eksemplāru, ar kuru saistīta atkarīgā realitāte;

neatkarīga realitāte – šī realitātes eksemplāra noteikšanai nav nepieciešams

atsaukties uz citām realitātēm;

saite – loģiskā asociācija, kas nosaka atkarību starp realitātēm. Saites tiek attēlotas kā

līnijas starp realitātēm. Atkarībā no saites lomas, realitāte var būt „vecāku” vai „bērnu”.

IDEF1X notācijā „bērna” realitātes saitē ir punkts, bet IE notācijā tiek izmantota „vārna

kāja”. Katrai saitei atbilst darbības vārds, kas raksturo saiti. Darbības vārds lasās pēc

sekojošas formas: „vecāku” realitātes nosaukums + darbības vārds + „bērna” realitātes

nosaukums. Eksistē dažādi saišu tipi:

identificējošā saite – norāda uz to, ka „bērnu” realitāte saitē ir atkarīga no

„vecāku” realitātes. Atkarīgās realitātes eksemplārs var būt viennozīmīgi noteikts

tikai tad, ja šajā eksemplārā ir atsauce uz neatkarīgās realitātes eksemplāru;

neidentificējošā saite – norāda uz saiti starp „vecāku” un „bērnu” realitātēm,

pie tam „bērnu” realitātes eksemplārs var būt viennozīmīgi identificēts bez

atsauces uz „vecāku” realitātes eksemplāru;

daudzi pret daudziem (N:M) – nespecifisks saišu tips, kas liecina par analīzes

nepabeigtību. Pēdējos modelēšanas etapos visas saites N:M tiek pārveidotas citās

(identificējošās un neidentificējošās) saitēs. Saitē N:M netiek izdalītas „vecāku” un

„bērnu” realitātes un biežāk tiek izmantoti divi darbības vārdi;

hierarhiskā saite – norāda uz realitātes saiti uz sevi un kategoriju hierarhiju saites.

Metodoloģijas IDEF1X un IE ir ļoti līdzīgas un atšķiras tikai ar grafisku saites jaudas

attēlošanu un atšķirīgu kategoriju hierarhiju traktējumu un attēlošanu.

Definīcija. Saites jauda – attiecība, kas parāda to, kādam „bērna” realitātes eksemplāru

skaitam var atbilst „vecāku” realitātes eksemplārs.

Definīcija. Kategoriju hierarhija – attiecas uz realitātēm, kuriem daļa no atribūtiem un

saitēm ir vienāda. Līdzīgi atribūti novietojas superrealitātē (supertips), bet atšķirīgi atribūti

novietojas apakš realitātēs (apakštips).

IDEF1X metodoloģijā var būt divu tipu kategoriju hierarhija: pilna un nepilna, kur:

pilnā hierarhija liecina par analīzes pabeigtību. Tajā piedāvāto apakštipu salikumu var

uzskatīt par izsmeļošu;

nepilnā hierarhija var būt arī citas apakšrealitātes, kas vēl nav noteiktas.

IE metodoloģijā visas kategoriju hierarhijas ir pilnas. Atšķiras arī kategoriju hierarhiju

nozīme, kas var būt izslēdzoša un iekļaujoša, kur:

pie izslēdzošas hierarhijas superrealitāte var spēlēt tikai vienas apakšrealitātes

lomu;

pie iekļaujošas hierarhijas superrealitāte var spēlēt vairāk nekā vienu lomu.

Abu notāciju salīdzinājumus ir attēlots tabulā 2.2.

2.2. tabulaIDEF1X un IE notāciju salīdzinājums un to apzīmējumi

Notācijas elements IDEF1X notācija IE notācija Apraksts

RealitāteRealitātes nosaukums atrodas virs taisnstūra. Iekšā atrodas atribūtu saraksts, kur atslēgas atribūti iedalīti citā krāsā vai atdalīti ar svītru.

Identificējošā saite

Neidentificējošā saite

Saite 1 : 0,1

Saite 1 : 1,N

Saite 1 : 0,1 N

Saite 1 : X Tiek definēta konstanta vērtība.

Saite N : MSaites tips, kas liecina par analīzes nepabeigtību; modelēšanas turpmākajos etapos tā tiek pārveidota citā saitē.

Hierarhiskā saite Realitātes saite pašai ar sevi.

Pilnā kategoriju hierarhija

Izslēdzoša kategoriju hierarhija.

Iekļaujoša kategoriju hierarhija.

Nepilnā kategoriju hierarhija

Toad Data Modeler piedāvā 2 notāciju izvēles iespējas, nodrošinot vieglu „pārslēgšanos”

no IDEF1X uz IE notāciju. Lai to izdarītu, ir jāizvēlas „Notation” opcija no galvenās rīku

izvēlnes (2.13. att.).

2.13. att. Notāciju izvēles iespēja

IDEF1X un IE notāciju realizāciju Toad Data Modeler var apskatīt, izmantojot

programmas „Help”, kurā viegli pārskatāmi ir paradīti saišu un realitāšu realizācijas piemēri

(att.2.14 – 2.17.).

2.14. att. „Help” par IE notācijām

2.15. att. Saišu un saišu jaudas (cardinality) realizācijas piemēri IE notācijām

20

2.16. att.. „Help” par IDEF1X notācijām

Saišu un saišu jaudas (cardinality) realizācijas piemēri IDEF1X notācijām ir apskatāmi att. 2.17.

2.17. att. IDEF1X notācijas saišu veidi

Šī darba izpildei tiks izmantota IE notācija.

21

2.7. TDM Modeļi

Loģiskais modelis un ar to saistītā funkcionalitāte (LER)

Loģiskā modeļa veidošana

Toad Data Modeler vidē ir iespējams izveidot loģisko modeli, definējot darba telpu,

pievienojot entītijas (realitātes), atribūtus, unikālos identifikatorus, pievienojot un definējot

saites, pievienojot un specificējot mantošanu. Toad Data Modeler piedāvā iespēju veidot

kategorijas, kas ar krāsām izdalīs modeļa daļas. Piemērām entītijām (realitātēm), kas savā starpā

ir loģiski saistītas, var noteikt atsevišķu kategoriju un attēlot tās katru savā krāsā.

Loģiskā modeļa verifikācija

Viena no rīka priekšrocībām ir tāda, ka tajā ir iespēja pārbaudīt loģisko modeli, veicot

modeļa verifikāciju, kas palīdz atklāt modeļa kļūdas un brīdinājumus. Loģiskā modeļa

verifikācija tiks detalizēti aprakstīta darba praktiskajā daļā (2.18. att.).

2.18. att. Loģiskā modeļa pārbaude

Atskaišu veidošana

Toad Data Modeler automātiski ģenerē atskaites loģiskajiem modeļiem. Atskaites tiek

realizētas HTML formātā, un ir ļoti ērtas un pārskatāmas. Sīkāk atskaišu ģenerēšanas piemērs

tiks apskatīts darba praktiskajā daļā, kur tiks ģenerēta atskaite Universitātes priekšmetiskās vides

loģiskajam modelim. HTML atskaites var modificēt, paplašinot eksistējošo metodi. Izmantojot

Script Explorer var redzēt BasicHTMLPERReportOR skriptu ar funkciju

ReportTableUserProperties. Tieši šis skripts ģenerē tabulu lapas HTML atskaitēs. Tādā veidā to

var mainīt, pielāgojot savām vajadzībām.

22

2.19. att. Loģiskā modeļa Script Explorer atskaišu rediģēšana

Modeļu salīdzināšana

Šajā rīkā pastāv arī iespēja salīdzināt modeļus savā starpā ar Comparator funkcijas

palīdzību, ko var atrast rīku panelī: Model -> Compare.

2.20. att. Modeļu salīdzināšana

Salīdzināt var gan loģiskos modeļus, gan fiziskos modeļus, kā arī pastāv iespēja

automātiski noģenerēt atskaiti HTML formātā, kas saturēs atšķirīgos datus.

Loģiskā modeļa atjaunošana un apvienošana

Gadījumā, kad loģiskais modelis jau ir konvertēts fiziskajā modelī un tajā tiek veiktas

izmaiņas, pastāv iespēja atjaunot arī loģisko modeli, atbilstoši izmaiņām, kas tika veiktas

fiziskajā modelī. Šim nolūkam tiek izmantots Convertor. Tā pat ir iespējams apvienot divus

loģiskus modeļus vienā, izmantojot Merge Models funkciju.

2.21. att. Modeļa atjaunošana un apvienošana

23

Loģiskā modeļa transformācija uz fizisko modeli (LER PER)

Toad Data Modeler ļauj transformēt loģisko modeli fiziskajā modelī. Šim mērķim, tiek

izmantots Convertor, izvēloties Model -> Simple Model Conversion vai Model Conversion,

Model Merge.

2.22. att. Modeļa transformēšanas aktivizēšana

Pirms loģiskā modeļa konvertēšanas uz fizisko modeli, ir jāņem vērā šādi nosacījumi:

fiziskais modelis atbalsta tikai neidentificējošas unāras saites;

fiziskajā modelī nav atbalstīta mantošana;

atslēgas migrē pēc transformācijas fiziskajā modelī;

var izvēlēties savienojuma metodi loģiskajā modelī;

M:N saites atbalstītas gan LER, gan PER modeļos u.c.

2.8. Fiziskais modelis un ar to saistīta funkcionalitāte

Fiziskā modeļa veidošana

Toad Data Modeler(TDM) vidē ir iespējams veidot fizisko modeli. Tā kā TDM atbalsta

vairākas DBVS, pirms modeļa veidošanas ir jānokonkretizē un jāizvēlas kāda no DB sistēmām.

Pēc tam ir iespējams pievienot entītijas, un nodefinēt to īpašības.

2.23. att. Entītiju īpašību aplūkošana un definēšana

24

TDM rīks piedāvā daudz funkcijas, kuras ir iespējams, veidojot entītiju fiziskajā modelī:

General – visi galvenie uzstatījumi, kas definē entītiju: nosaukums, uzraksts, kategorija,

izmērs

Attributes – var veidot, koriģēt un dzēst entītijas atribūtus

Keys – var veidot primāras atslēgas un alternatīvas atslēgas

Indexes – var veidot indeksus

Check Constraints – var veidot ierobežojumus

Triggers – var veidot trigerus

Permissions – var definēt pieejas atļaujas lietotājiem vai lietotāju grupām

To Do – var definēt uzdevumus entītijām

Notes – entītiju detaļas, paskaidrojumi

SQL Preview – entītijas SQL kods (att. 2.24).

2.24. att. Entītijas SQL koda pārlūks

Fiziskajā modelī ir iespējams nodefinēt saites, kardinalitātes (saišu jaudas) (2.25 att.).

2.25. att. Saišu definēšana fiziskajā modelī

25

Neskaitot šīs pamata iespējas, Toad Data Modeler fiziskajā modelī ir iespējams realizēt

vēl dažas svarīgas opcijas:

skatu un materializētu skatu pievienošanu,

procedūru un funkciju definēšanu,

indeksu, trigeru definēšanu

lietotāja datu tipu definēšana ērtākam darbam.

Fiziskā modeļa verifikācija

Tā pat kā loģiskajā modelī, arī šeit ir iespējams pārbaudīt fizisko modeli, veicot modeļa

verifikāciju, kas palīdz atklāt kļūdas un brīdinājumus.

2.26. att. Fiziskā modeļa verifikācija

Dokumentācija

Toad Data Modeler automātiskā dokumentācija fiziskajam modelim piedāvā sekojošas

iespējas:

ģenerēt atskaites HTML, RTF un PDF formātos, izmantojot Report Wizard.

2.27. att. Fiziskā modeļa atskaišu ģenerēšana

izveidot lietotāju atskaites fiziskajam modelim – HTML, PDF, CSV, text vai XML

formātos, izvēloties sev piemērotākos.

ģenerēt XSD failu fiziskajam modelim.

2.28. att. XSD fails fiziskajam modelim

26

Skripta ģenerēšana

No fiziskā modeļa ir iespējams ģenerēt DDL/SQL kodu, kā arī Toad Data Modeler

piedāvā iespēju izvēlēties objektu ģenerēšanas kārtību, piemēram, ģenerēt lietotājus pirms

lietotāju privilēģijām. Vispārīgi var mainīt kārtību sekojošiem objektiem:

domēni,

entītijas,

skati,

vārdnīcas tipi,

glabājamās procedūras,

funkcijas,

lietotāji,

lietotāju datu tipi.

2.29. att. DDL/SQL koda ģenerēšana

Fiziskā modeļa transformācija uz fizisko un loģisko modeli (PER ->PER,LER)

Toad Data Modeler ļauj konvertēt fizisko modeli no vienas DB sistēmas uz citu,

piemēram, Oracle 10g fiziskais modelis var būt konvertēts uz SQL Server 2005 modeli. Tāpat

Toad Data Modeler ļauj transformēt fizisko modeli loģiskajā. Šī opcija dod iespēju veidot jaunu

loģisko modeli, no eksistējošā fiziskā modeļa.

2.30. att. Modeļa konvertēšana

27

2.9. Apvērstā inženierija (reverse engineering)

Apvērstās inženierijas opcija dod iespēju ielādēt jau eksistējošo DB struktūru un veidot

jaunas ER diagrammas. Pastāv divi apvērstās inženierijas veidi:

standard reverse engineering,

live reverse engineering.

Standard reverse engineering režīmā indeksi, komentāri, trigeri, saites, ierobežojumi,

funkcijas, skati, procedūras, lietotāju tipi ielādējās jaunajā ER diagrammā atbilstoši eksistējošai

DB struktūrai.

Live reverse engineering piedāvā vieglu un ātru iespēju pievienot jaunas entītijas, jaunus

skatus un sinonīmus jau eksistējošā Oracle modelī (un tikai Oracle). Dažreiz šo opciju var

izmantot, lai vienkārši atjaunotu modeli.

Tālāk ir redzams kā tas tiek izpildīts.

Sākumā ir jāizvēlas saglabātus pseidonīmus (at. 2.31.) un pēc tam ir jāizvēlas DB (att. 2.32).

2.31. att. Saglabāto pseidonīmu izvēle

2.32. att. Datu bāzes izvēle

28

Kad tas ir izdarīts, ir jāizvēlas savienošanas tips no izvēlētajai DB pieejamiem tipiem.

2.33. att. Savienošanas tipu izvēle

Ir pieejami ADO; Native; TCP/IP; ODBC savienošanas tipi (atkarībā no DB). Pēc tam

notiek savienojuma konfigurācija (att.2.34) un jāizvēlas datu migrators (att. 2.35).

2.34. att. Savienojuma konfigurācija

2.35. att. Datu migratora izvēle

29

2.36. att. Pārveidojamo objektu izvēle (jāizvēlas objekti, kuri ir jāpārveido)

Tālāk notiek pseidonīma saglabāšana uz datora, pēc kuras notiek shēmu un tabulu izvēle.

2.37. att. Shēmu un tabulu izvēle

Spiežot pogu „Execute”, tiek izvadīts paziņojums par apvērstās inženierijas pabeigšanas

procesu.

2.38. att. Apvērstās inženierijas pabeigšanas procesa ziņojums

Kad apvērstā inženierija ir pabeigta, var apskatīt jauno ER diagrammu no iepriekš

eksistējošas datu bāzes. Tika izveidots fiziskais modelis.

30

2.39. att. Apvērstās inženierijas rezultāta fiziskais modelis

2.10. Papildus TQM funkcijas un iespējas

Automātiskā modeļa izkārtošana

Automātiskā izkārtojuma funkcija ļauj automātiski izvietot modeļa objektus darba telpā.

Tā varētu būt noderīga pēc loģiska modeļa konvertēšanas uz fizisko modeli.

2.40. att. Automātiskā izkārtojuma aktivizēšana

Sinhronizācija

Toad Data Modeler ļauj sinhronizēt:

datu bāzi un Toad Data Modeler modeli;

fizisko un loģisko modeli.

31

Version Manager

Toad Data Modeler rīkā ir iespējams veidot projektus, pievienot modeļus un citus failus,

mainīt modeļus, veidot to versijas. Ir iespējams veidot neierobežotu projektu skaitu. Lai

pievienotu esošo modeli kādam konkrētam projektam, ir jāizveido jauns projekts, izmantojot Add

Project. Pēc tam projektam ir jāpievieno esošais modelis, izmantojot Add to Version Manager.

Pēc apstiprināšanas, izvēlētais modelis (tāpat kā katrs no jauna pievienotais modelis) tiks

pievienots konkrētam projektam, līdz ar to vienmēr būs iespēja apskatīt projekta vairākas

versijas, kuras ir bijušas pievienotas projektam ar Version Manager.

To-Do list

To-Do saraksts ļauj veidot ierakstus, kas atgādina uzdevumus, kurus ir jāveic vai atgādina

par nepabeigtām darbībām.

To-Do list ir jāpievieno:

kāda modeļa daļa, uzklikšķot uz objekta ar labo peles pogu un Edit izvēlnē izvēloties

Properties, kurā tālāk jāizvēlas To Do cilne. Rezultātā tiks attēlots uzdevumu saraksts, kas ir

saistīts ar izvēlēto objektu;

galvenais To Do dialoga logs, kas atrodas zem Model To Do. Rezultātā tiek paradīts pilns

uzdevumu saraksts. Lai pievienotu jaunu uzdevumu, ir jāizvēlas Add opcija, lai izmainītu

esošo uzdevumu, ir jāizvēlas opcija Edit, savukārt lai izdzēstu uzdevumu, ir jāizvēlas opcija

Delete.

Toad Data Modeler vidē var piesaistīt uzdevumus ne tikai modelim kopumā, bet arī

atsevišķiem objektiem.

Objektu saraksts, kuriem var pievienot uzdevumus:

modelis,

entītija,

saite,

atribūti,

atslēgas,

indeksi,

ierobežojumi,

trigeri,

lietotāji,

lietotāju grupas,

vārdnīcas tipi,

lietotāja datu tipi,

domēni,

likumi,

skati,

procedūras,

shēmas,

kategorijas,

meta modeļi.

32

3. PRAKTISKĀ DAĻA

3.1. Konceptuālais modelis „Visio” vidē

Darba gaitā tiek izmantota IS “Universitāte”, kas ir aprakstīta dokumentā

“PowerDesignr15.doc” un apraksta universitātes struktūru. Toad Data Modeler nav iespējas

izveidot konceptuālo modeli, tāpēc tas tiek realizēts Visio vidē, balstoties uz iepriekš minētā

piemēra struktūras (att. 3.1.).

3.1. att. Priekšmetiskās vides konceptuālais modelis

Tālāk, lai veiktu modeļa realizāciju, tiek veidots loģiskais modelis.

3.2. Loģiskais modelis

Modeļa izveide

Sākot loģiskā modeļa izveidi, ir jāizveido jauns modelis ar FileNew Model... palīdzību

(galvenā izvēlne). Pēc tam atveras dialoga logs, kur jāveic izvēle Logical Data Model.

33

3.2. att. Loģiskā modeļa izveide

Lai pievienotu modelim entītiju, galvenajā izvēlnē ir nepieciešams izvēlēties

ObjectsEntity opciju.

3.3. att. Entītijas izveidošana

Tālāk parādās jauna entītija, uz kuras, uzklikšķinot ar peles kreiso taustiņu, parādās jauns

logs EntityProperties.

34

3.4. att. Entītijas „Fakultāte” datu definēšana

3.5. att. Entītijas „Fakultāte” atribūtu definēšana

3.6. att. Entītijas „Fakultāte” atribūtu veidošana

35

3.7. att. Visi definētie entītijas atribūti

Nedrīkst aizmirst, ka vienam no atribūtiem obligāti jābūt primārajai atslēgai. Tālāk tiek

izmantotas UniqueIdentifiers iespējas.

3.8. att. Unikālo identifikatoru (primāro atslēgu) rediģēšana

Lai pievienotu primāro atslēgu (unikālo identifikatoru), ir jānospiež Add, un tālāk ir

iespējams izvēlēties primārās atslēgas Attributes cilnē. Izvēlētie atribūti ar bultu pogām tiek

aizvirzīti uz labo logu.

3.9. att. Unikālo identifikatoru pievienošana

Gala rezultātā ir apskatāma izveidotā entītija Fakultāte.

36

3.10. att. Izveidotā entītija „Fakultāte”

Šādi tiek definētas visas nepieciešamās entītijas priekšmetiskās vides realizācijai.

Binārās saites izveide

Tālāk tiek definētas saites starp entītijām. Attēlā 3.11 ir redzama binārā saite starp

realitātēm Fakultāte un Institūts.

3.11. att. Binārā saite starp realitātēm Fakultāte un Institūts

3.12. att. Binārās saites realizācija TDM rīkā

Tiek izvēlēta saite no rīku joslas Objects Relationship un uzklikšķināts ar ar peles

kreiso taustiņu 1.reizi uz vienas, 2. reizi uz otras entītijas - entītijas, kurai būs foreign key lauks.

Veicot šīs darbības, paradās saite starp 2 izvēlētajām entītijām. Uzklikšķinot uz saites ar

peles kreiso taustiņu 2 reizes, paradīsies logs RelationshipProperties.

3.13. att. RelationshipProperties - saites datu definēšana37

Ārējās atslēgas nosaukums F_Num laukam ForeignUniqueIdentifier. Saite tiek

nosaukta par „Ir”, jo attiecība starp „Vecāku” un „Bērnu” pastāv, kas nozīmē, Fakultātei ir jeb

pieder Institūts. Cilnē Cardinality ir iespējams izvēlēties saites veidu, kura mums ir

nepieciešama 1:1, vai 1:N.

3.14. att. Saites veida izvēle

Mantošanas realizācija

Izmantojot atribūtus un unikālus identifikatorus, kā arī Objects Inheritance opciju, tiek

izveidota mantošana starp trim realitātēm Cilvēks ir Parent entītija, Students un Pasniedzējs ir

Child entītijas.

3.16. att. Mantošanas realizācijas instrumenta izvēle

38

32.att.

3.17. att. Mantošanas tipa izvēle

Cilnē Generation ir iespēja atzīmēt kurš ko mantos – vecāks visus bērnus, katras bērns

vecāku, vai arī transformējot modeli fiziskajā, tas sakritīs ar loģisko. Tiks izvēlēts otrais variants,

lai pārbaudītu mantošanas struktūru konvertācijas procesā.

3.18. att. Mantošanas kārtas izvēle

Modelī mantošana ir realizējama starp realitātēm bērnu Pasniedzējs, Students un vecāku

realitātes Cilvēks.

3.19. att. Konceptuālā modeļa mantošanas struktūra

Realizējot šo struktūru ar Toad Data Modeler CASE rīka palīdzību, šī struktūra izskatās

diezgan līdzīga.

39

3.20. att. Realizētā mantošanas struktūra TDM vidē

Unārās saites izveide

Lai realizētu unāro saiti realitātei Students, tiks izmantots saites instrument, un nospiests

uz vienas un tās pašas entītijas 2 reizes, kā arī saitei tiek uzstādīti noteikti parametri.

3.21. att. Konceptuālā modeļa unārās saites struktūra

3.22. att. Realizētā unārās saites struktūra TDM vidē

Vājās realitātes realizācija

Vājā realitāte loģiskajā modelī ir realizējama realitātei Atzīme, kas ir atkarīga no

realitātēm Students un Pasniedzējs.

3.23. att. Konceptuālā modeļa vājās realitātes struktūra

40

3.24. att. Realizētā vājās realitātes struktūra TDM vidē

Saites N:M izveide

Modelī ir divas N:M saites starp realitātēm Mācību programma un Mācību priekšmets,

kā arī starp realitātēm Pasniedzējs un Mācību priekšmets.

3.25. att. Konceptuālā modeļa N:M saišu struktūras

3.26. att. Realizētās N:M saišu struktūras TDM vidē

41

Ternārās saites izveide

Modelī ternārā saite ir starp realitātēm Atzīme un Mācību priekšmets, Students. Ternāro

saiti realizē ar asociācijas tabulas Studenta_Atz_Saraksts palīdzību, kura savā starpā savieno

visas realitātes.

3.27. att. Konceptuālā modeļa ternārās saites struktūra

3.28. att. Realizētās ternārās saites struktūra TDM vidē

Kategoriju izveide

Tālāk tiks izveidotas kategorijas entītijām, kuras ir loģiski saistītas savā starpā. Tiks

izdalīta kategorija Personas, kurā attiecīgi atradīsies visas entītijas, kas būtībā atrodas

mantošanās attiecībās. Realizēšanai tiek atvērtas entītijas Cilvēks īpašības un galvenajā cilnē tiek

izvēlēta kategorija, no sākuma definējot kategoriju. Tā pat tiek definētas kategorijas entītijām

Students un Pasniedzējs, vienīgi šeit būs jāizvēlas jau eksistējošā kategorija jau no kategoriju

saraksta.

3.29. att. Kategoriju definēšana, izmantojot „Entity Properties”

42

3.30. att. Vienas kategorijas pārstāvju entītijas

3.31. att. Kategorijas UniversitatesAdministracija pārstāvju entītijas

Tālāk tiek izveidota „leģenda” ar kategoriju nosaukumiem, izmantojot ikonu Category

rīku joslā. Parādās taisnstūris ar darba telpā eksistējošām kategorijām. Tādā veidā ir iespējams

grafiski izdalīt loģiski saistītas realitātes, kas ir uzskatāmi, un grafiski ar to palīdzību ir iespējams

realizēt superrealitāšu saites.

3.32. att. Darba telpā eksistējošo kategoriju saraksts

Modelis ir izveidots līdz galam - ir definētas visas entītijas un saites. Tālāk notiek modeļa

verifikācija (sistēmas pārbaude), ko parasti veic tās izstrādāšanas gaitā, lai pārliecinātos, vai

izstrādāšanas procesā aplūkojamā posma rezultāti atbilst tā sākumā definētajiem noteikumiem un

prasībām.

Loģiskā modeļa verifikācija

Loģiskā modeļa verifikāciju pārbaudi veic, izvēloties Model VerifyModel galvenajā

izvēlē.

43

3.33. att. Modeļa verifikācijas uzsākšana

3.34. att. Verifikācijas kritēriju izvēles logs

3.35. att. Verifikācijas rezultāta ziņojuma logs pēc Verify nospiešanas

Ja ir radušās kļūdas, tās tiek izlabotas un veikta atkārtota modeļa verifikācija. Ja ir

radušies kādi brīdinājumi, ir jāmēģina tos novērst un atkārtoti veikt verifikāciju, kamēr vairs

netiek konstatētas kļūdas un brīdinājumi.

44

Kopējais modelis

Darba gaitā it izveidots loģiskais modelis izvēlētajai priekšmetiskai videi Universitāte.

3.36. att. Izveidotais loģiskais modelis Universitāte TDM vidē

Loģiskā modeļa atskaites ģenerēšana HTML formātā

Toad Data Modeler Report Wizard palīdzību tiks izveidota atskaite par loģisko modeli.

3.37. att. Atskaites formāta izvēle

3.38. att. Izvēlēties, kam veikt atskaiti

45

3.39. att. Atskaites vizuālā tēla izvēle

3.40. att. Atskaitē attēlojamās informācijas izvēle

Spiežot pogu Execute atskaite tiek uzģenerēta ar izvēlētajiem parametriem. Lai apskatītu

izveidoto atskaiti, ir jāizvēlas poga Show Report poga. Tālāk it redzamas loģiskā aplūkot loģiskā

modeļa atskaites. Atskaites lapā ir vairākas cilnes, kur var apskatīt dažādu informāciju par

entītijām, par atribūtiem, par mantošanas attiecībām, kā arī var apskatīt ER diagrammu un

vispārīgu informāciju par modeli.

46

3.41. att. Atskaites ER diagramma

3.3. Fiziskais modelis

Šajā darbā jaunizveidotais loģiskais modelis tiks konvertēts fiziskajā modelī. Lai uzsāktu

modeļa konvertēšanu, galvenajā izvēlnē ir jāizvēlas opcija Model Model Conversion,

ModelMerge.... Katra struktūra tiks transformēta atsevišķi, līdz ar to iepriekšējās transformācijas

katrā no jaunajām struktūrām nebūs redzamas.

3.42. att. Modeļa konvertēšanas uzsākšana

Atsevišķu elementu transformācija

Mantošanas transformācija

Mantošanas realizācijā loģiskajā modelī piedalās 3 entītijas – Cilvēks kā „vecāku”

realitāte un divas bērnu realitātes Students un Pasniedzējs.

3.43. att. Mantošana loģiskajā modelī

47

Pēc Model Model Conversion, ModelMerge palaišanas atvērsies logs, kur ir jāizvēlas

fiziskā modeļa tips (šajā gadījumā Oracle9i). Attēlotajā logā ir iespējams ar zilo bultu palīdzību

izvēlēties vēlamos elementus transformācijai – mantošanas entītijas, mantošanu un kategorijas

(tiks izvēlēta kategorija Personas, kurā ir iekļautas minētās entītijas loģiskajā modelī). Pēc tam ir

jānospiež poga Execute.

3.44. att. Modeļa transformēšana mantošanai

Pēc tam atveras papildus cilne, kurā ir attēlota transformētā loģiskā modeļa struktūra

fiziskajā modelī. Attēlā ir redzams, ka ir pazudusi „vecāka” realitāte un tās atribūti ir pārgājuši

uz abām „bērnu” tabulām (atribūti: pers_kods, vards, uzvards).

3.45. att. Atsevišķa mantošanas transformēšana

Unāras saites transformācija

Unārās saites realizācijā loģiskajā modelī piedalās entītija Students ar saiti pašai uz sevi.

3.46. att. Unārā saite loģiskajā modelī

Transformācijas logā tiek izvēlēti tie elementi, kuri attiecas uz jauno transformējamo

struktūru vēlamā entītija un saite, kuru jātransformē.

48

3.47. att. Modeļa transformēšana unārai saitei

Rezultātā transformētajā fiziskajā modelī parādās vēlamās struktūras transformācija.

Transformācijā ir redzams, ka 2 reizes atkārtojas atribūts S_NUM, kas nozīmē to, ka viens no

tiem ir primārā atslēga, bet otrs - ārējā atslēga. Līdz ar to, viens atribūts atsaucas uz otru.

3.48. att. Atsevišķa unārās saites transformēšana

Vājās realitātes transformācija

Vājās realitātes realizācijā loģiskajā modelī piedalās entītijas Students un Pasniedzējs, no

kuriem, savukārt, ir atkarīga vājā realitāte Atzīme.

3.49. att. Vājā realitāte loģiskajā modelī

Transformācijas logā tiek izvēlēti elementus, kas attiecas uz jauno transformējamo

struktūru - vēlamās entītijas un saites, kuras jātransformē.

49

3.50. att. Modeļa transformēšana vājai realitātei

Rezultātā transformētajā fiziskajā modelī parādās transformēšanai izvēlētā struktūra.

Attēlā var redzēt, ka vājajā realitātē ir nonākušas primārās atslēgas no abām tabulām, no kurām ir

atkarīga vājā realitāte.

3.51. att. Atsevišķa vājās realitātes transformēšana

Saites N:M transformācija

Loģiskajā modelī saites N:M ir 2, kurās piedalās entītijas Mācību priekšmets un

Pasniedzējs, kā arī Mācību priekšmets un Mācību programma.

3.52. att. Saites N:M loģiskajā modelī

Transformācijas logā tiek izvēlēti elementi, kuri attiecas uz jauno transformējamo

struktūru - vēlamās entītijas un saites, kuras jātransformē.

50

3.53. att. Modeļa transformēšana saitēm N:M

Rezultātā transformētajā fiziskajā modelī parādās transformēšanai izvēlētā struktūra. Pēc

transformācijas redzam, ka ir izveidojušās divas starptabulas starp tabulām Pasniedzējs un

Mācību priekšmets ir izveidojusies starptabula Mācību priekšmeta pasniedzējs, kura ir mantojusi

abu tabulu primārās atslēgas. Tas pats notiek ar tabulām Mācību programma un Mācību

priekšmets – starp tām ir izveidojusies starptabula Mācību programmas mācību priekšmets ar

mantotām primārajām atslēgām.

3.54. att. Atsevišķa saišu N:M transformēšana

Ternārās saites transformācija

Ternārās saites realizācijā loģiskajā modelī piedalās 4 entītijas - Students, Atzīme, Mācību

priekšmets un Studenta_Atz_Saraksts (kalpo par sava veida asociāciju realitāti tabulu

savienošanai).

51

3.55. att. Ternārā saite loģiskajā modelī

Transformācijas logā tiek izvēlēti elementi, kuri attiecas uz jauno transformējamo

struktūru - vēlamās entītijas un saites, kuras jātransformē.

3.56. att. Modeļa transformēšana saitēm N:M

Rezultātā transformētajā fiziskajā modelī parādās transformēšanai izvēlētā struktūra.

3.57. att. Atsevišķa saišu N:M transformēšana

52

Tālāk tiek veikta kopējā modeļa transformācija, kur ārējās atslēgas ies nedaudz savādāk

un tabulas būs pilnākas ar atribūtiem, jo tad transformēsies visas entītijas.

Kopējā modeļa transformācija

Kopējā loģiskā modeļa transformācijai galvenajā izvēlnē jāizvēlas Model Model

Conversion, ModelMerge...un dialoga logā Convertor, kurš atvērsies, ir jānorāda fiziskā modeļa

tips, kurai DB tas tiek domāts. Tiek izvēlēts Oracle9i DB tips.

3.58. att. Modeļa transformēšana

Jāņem vērā, ka transformējot loģisko modeli fiziskajā, ir jātransformē gan saites,

realitātes u.c., gan atribūtu ierobežojumi, piemēram, entītijas Atzīme atribūta Atz_Vertiba var būt

robežās no 1 līdz 10. Tālāk notiek transformācija LERPER, kur PER modelis manto ārējās

atslēgas, izveido starptabulas u.tml.

53

3.59. att. Transformētais loģiskais modelis Universitāte fiziskajā modelī,

izmantojot TDM vidi

Jebkurā fiziskā modeļa vietā ir iespējams veikt labojumus gan nosaukumos, gan

ierobežojumos, kā arī ir iespējams pārveidot jebkuru SQL kodu. Līdzīgā veidā ir transformējušās

arī citas entītijas. 3.60. att. ir redzams entītijas „Atzīme” SQL kods. To var mainīt manuāli. Kodā

ir redzams, ka ir izveidojusies tabula, kurā jau ir iekļauts ierobežojums atzīmes vērtības laukam.

Tā pat visi pārējie atribūti ir pieņēmuši savus vēl loģiskajā modelī piešķirtos tipus.

3.60. att. Entītijas Atzīme SQL kods

Fiziskā modeļa papildināšana

Pēc fiziskā modeļa transformēšanas ir iespējams to palabot un pievienot tam visu, kas ir

nepieciešams, piemēram, skatus, trigerus, ierobežojumus, glabājamās procedūras, virknes,

sinonīmus, procedūru pakotnes, funkcijas u.c. Papildināt fizisko modeli Toad Data Modeler vidē

var vairākos veidos:

katras entītijas opcijās (Properties) ir iespējams pievienot trigerus,

galvenās izvēlnes joslā (Model Views) ir iespējams izvēlēties skati, materializētu

skatu, funkciju, procedūru, sinonīmu veidošanu,

fiziskā modeļa pārlūkā ir iespējams izveidot vajadzīgo objektu atbilstošajā mapē skati,

funkcijas, procedūras, virknes, pakotnes, sinonīmi, materializētie skati.

Skata pievienošana

Piemēram tiks pievienots skats, kas atlasa studentu datus un atbilstošas grupas datus.

Skata izveidošana jāsāk no galvenās izvēlnes Model Views opcijas. Tiek rakstīts tikai

vaicājuma teksts. Skatu pievienošanas process ir pusautomātisks - manuāli ir jāievada skata SQL

skripts cilnē SQL.

3.61. att. Skata SQL skripts

Pēc skata izveidošanas tas ir redzams fiziskā modeļa darba telpā.

3.62. att. Izveidotais skats fiziskā modeļa darba telpā

Fiziskā modeļa atskaites ģenerēšana PDF formātā

Pēc loģiskā modeļa konvertēšanas fiziskā modelī tiek apskatīta atskaišu ģenerēšana PER

modeļiem. Ar Toad Data Modeler Report Wizard palīdzību tiks izveidota atskate par

transformēto fizisko modeli.

3.63. att. Fiziskā modeļa atskaites ģenerēšanas uzsākšana

Atšķirīgi no loģiskā modeļa, atskaišu ģenerēšanas procesā fiziskajam modelim var

izvēlēties atskaites formātu. Piemēram, var izvēlēties PDF formātu, kā arī atskaitei nepieciešamo

informāciju. Atskaites ģenerēšanas soļi ir tādi paši kā ģenerējot loģiskā modeļa atskaiti. Atverot

atskaiti, atveras galvenā lapa. Atskaitē ir iekļauts detalizēts modeļa apraksts. Tā pat atskaitē

atsevišķi pa daļām ir aprakstīta katra struktūra - saites, atribūti, trigeri, virknes u.c. Atskaite ir

pilnībā gatava drukāšanai.

3.64. att. Fiziskā modeļa atskaites galvenā lapa

3.4. SQL koda ģenerēšana

Tiek izveidots DDL skripts, galvenajā izvēlnē izvēloties Model Generate DDL Skript.

Visu SQL koda skriptu var aplūkot 1.pielikumā.

3.65. att. DDL/SQL koda ģenerēšanas uzsākšana

Tālāk no saraksta jāizvēlas visi elementi, kuriem tiks ģenerēts kods, piemēram, visas

entītijas, funkcijas, skati, pakotnes.

3.66. att. DDL/SQL koda ģenerēšanas elementu izvēle

3.67. att. DDL/SQL koda primāro atslēgu ģenerēšanas vietas izvēle

Pēc pogas Generate nospiešanas tiek saglabāts fails *.sql formātā norādītajā mapē.

Uzģenerēto kodu var aplūkot, nospiežot pogu Show Code. Logā būs iespējams redzēt SQL kodu

visām entītijām, atribūtiem un to tipiem. Kopumā kods tiek uzģenerēts precīzi.

3.68. att. Uzģenerētais SQL kods

3.5. Loģiskā un fiziskā modeļa salīdzināšana

Abu modeļu salīdzināšana tiek veikta galvenajā izvēlnē izvēloties Model Compare....

3.69. att. Modeļu salīdzināšanas uzsākšana

Dialoga logā ir iespējams izvēlēties otro modeli, ar kuru salīdzināt tekošo loģisko modeli.

Darbā tiks salīdzināts loģiskais modelis ar transformēto modeli, kurš tika iegūts pēc

transformācijas tiek salīdzināti 2 modeļi LER un PER (sākumdati ar beigu datiem).

3.70. att. Modeļu salīdzināšana

Loga kreisā daļa atbilst LER modelim, bet labā - PER modelim. Logā ir skaidri redzams,

ka kreisajā pusē ir entītija Cilvēks. Šī entītija piedalās mantošanā kā „vecāka” entītija kopā ar

diviem bērniem Pasniedzējs un Students. Labajā loga pusē šī entītija neeksistē, jo entītijas

atribūti ir pārgājuši pie abiem bērniem ar visu primāro atslēgu. Tā pat var redzēt, ka PER modelī

ir parādījušās divas jaunas entītijas, kuras nebija loģiskajā modelī, jo loģiskajā modelī bija

realizētas N:M saites, kuras pēc transformācijas ir papildinājušās ar starptabulām. Ir redzams, ka

oģiskajā modelī ir realizēta mantošanas struktūra, taču fiziskajā modelī šī struktūra nav redzama,

jo notiek „vecāku” realitātes sadalīšana uz abām „bērnu” realitātēm. Tālāk tiek transformēts

esošais fiziskais modelis atpakaļ loģiskajā modelī, veicot tādas pašas darbības kā iepriekš,

transformējot LER PER.

3.71. att. Fiziskā modeļa transformācija loģiskajā modelī

3.72. att. Jauns loģiskais modelis, transformēts no fiziskā modeļa

Ārējās atslēgas atkal ir pazudušas no tabulām, un ir parādījušās divas pavisam tukšas

tabulas, kuras fiziskajā modelī bija starptabulas un saturēja tikai ārējās atslēgas.

Tālāk tiek salīdzināts sākuma modelis LER ar modeli, kurš tika iegūts pēc otrās kārtas

transformācijas LER PER un tad PERLER2.

3.73. att. Pirmā un otrā loģisko modeļu salīdzināšana

Katru reizi tiek interpretēta transformācija pēc saviem likumiem. Var redzēt kā sākuma

LER modelis nav vienāds ar beigu LER modeli. Pirmkārt, ir pazaudēta mantošanas struktūra

transformācijas gaitā un otrās kārtas LER modelī mantošana vairs neeksistē. Entītija Cilvēks arī

vairs nav jaunajā LER modelī. Otrkārt, jaunajā LER modelī ir jaunas 2 tabulas (fiziskajā modelī

tās bija starptabulas), kuras sākuma modelī nav. Pēc katras transformācijas modelis mainās.

Nekad nevar iegūt to pašu, kas bija iepriekš.

4. SUBJEKTĪVAIS NOVĒRTĒJUMS4.1. tabula

CASE rīka Toad Data Modeler vājās un stiprās puses

Plusi Mīnusi

Modeļu salīdzināšana Manuāla skatu, procedūru definēšana (SQL

kods)

Atskaites Loģiskā un konceptuālā modeļa līdzība

Mantošanas realizācija trigerī pēc

transformācijas

Tikai 2 notācijas

Help iespējas AutoLayout nepārskatāms izvietojums

Modeļu atjaunošana pēc labojumiem Nepārskatāms izkārtojums pēc

transformācijas

Versiju glabāšana projekta ietvaros Tehniskās prasības

Ērta lietotāju saskarne Var realizēt tikai dažas struktūras

Transformācijas

(LERPER; PERLER; PERPER)

Trial versijas ierobežojumi

SQL skripts

PER modeļa papildināšana

Liels DBVS atbalsts

Apvērstā inženierija

Diagrammu kā grafisko attēlu

saglabāšana

Solis-pa-solim iespējas

Liela funkcionalitāte

SECINĀJUMI

Dotais darba uzdevums ir izstrādāts atbilstoši definētajai uzdevuma nostādnei, kuras

galvenais mērķis bija realizēt DB struktūru ar CASE tehnoloģijas palīdzību, izmantojot Toad

Data Modeler CASE rīku, kurš sevī apvieno objektorientēto, konceptuālo un fizisko datu

modelēšanas iespējas.

Darbs sastāv no 2 pamatdaļām. Teorētiskajā daļā tika apskatītas izvēlētā rīka iespējas,

lietotāja saskarne un tā pamatfunkcijas, savukārt praktiskā darba gaitā tika izstrādāts loģiskais

(konceptuālais) modelis Universitāte.

Darba izpildei tika izvēlēta ”Quest” produkta Toad Data Modeler versija 3.3.8.11.

Darbs tika uzsākts ar nelielu ieskatu CASE rīkos un Toad Data Modeler rīkā. No sākuma

bija diezgan grūti orientēties visās rīka iespējās, jo tiek piedāvātas diezgan daudzas opcijas. Lai

ātrāk orientētos šajā rīkā izmantoju Help iespējas, kas bija labs palīgs darba izpildes gaitā.

Darba gaitā tika izmantota Oracle datu bāze, kā rezultātā tika attēlotas visas datu bāzes

tabulas ar visām saitēm, kā arī daudzas tabulas, kuras nebija saistītas ne ar vienu citu.

Pēc loģiskā modeļa izveides tika veikta šī modeļa atsevišķa transformācija uz

fizisko modeli un beigās tika iegūts arī kopējā transformācija. Salīdzinot iegūtās transformācijas

ar sākotnējo modeli tika pamanītas diezgan daudzas izmaiņas. Bija uzskatāmi redzams, ka pēc

katras transformācijas modelis mainās un nekad nevar iegūt to pašu, kas bija iepriekš. Darba

gaitā tika apskatīta arī SQL koda ģenerācija, kas arī bija diezgan interesants pasākums.

1.pielikumā ir redzams uzģenerētais kods.

Darba noslēgumā ir sniegts subjektīvs rīka novērtējums. Diemžēl man bija iespēja

izmantot tikai trial rīka versiju, kurai bija diezgan daudz ierobežojumi. Taču nedaudz papētīju arī

pilnās Expert rīka iespējas. Ar rīku strādāt bija viegli un ļoti saprotami. Par spīti dažiem rīka

mīnusiem, manuprāt, rīka plusi ir spēcīgāki.

IZMANTOTĀ LITERATŪRA

J.Eiduks, 2008./2009.māc.g. Izdales materiāli no diska.

Semināra materiāli: vaicājumi valodā SQL un tas paplašinājums PL/SQL. J. Eiduks (no 2002

gada).

Toad Data Modeler Help.

http://www.casestudio.com/enu/products.aspx

http://www.casestudio.com/enu/tdm_statement_of_direction.aspx

http://modeling.inside.quest.com/index.jspa

http://en.wikipedia.org/wiki/Toad_Data_Modeler

http://www.toadsoft.com/toaddm/toad_data_modeler.htm

1.PIELIKUMS

Uzģenerētā SQL koda pirmteksts/*Created: 20.09.2009Modified: 20.09.2009Model: UniversitateDatabase: Oracle 9i*/-- Create tables section --------------------------------------------------- Table Katedra

CREATE TABLE "Katedra"( "K_Num" Integer NOT NULL, "K_Nos" Varchar2(50 ), "K_Tel" Integer CONSTRAINT "ValidValuesK_Tel" CHECK (("K_Tel" BETWEEN 20000000 AND 29999999)), "Dat_No_P" Date, "Dat_Lidz_P" Date, "I_Num" Integer, "Pasn_Num" Integer, "PASN_Pers_Kods" Varchar2(15 ), CONSTRAINT "K_Num" PRIMARY KEY ("K_Num"))/

-- Table Fakultate

CREATE TABLE "Fakultate"( "F_Num" Integer NOT NULL, "F_Nos" Varchar2(50 ), "F_Tel" Integer CONSTRAINT "ValidValuesF_Tel" CHECK (("F_Tel" BETWEEN 20000000 AND 29999999)), CONSTRAINT "F_Num" PRIMARY KEY ("F_Num"))/

-- Table Instituts

CREATE TABLE "Instituts"( "I_Num" Integer NOT NULL, "I_Nos" Varchar2(50 ), "I_Tel" Varchar2(15 ), "F_Num" Integer, CONSTRAINT "I_Num" PRIMARY KEY ("I_Num"))/

-- Table Atzime

CREATE TABLE "Atzime"( "Atz_Vertiba" Integer CONSTRAINT "ValidValuesAtz_Vertiba" CHECK (("Atz_Vertiba" BETWEEN 1 AND 10)), "Pasn_Num" Integer, "S_Num" Integer, "STU_Pers_Kods" Varchar2(15 ), "PASN_Pers_Kods" Varchar2(15 ))/

-- Table Studentu_grupa

CREATE TABLE "Studentu_grupa"( "Gr_Num" Integer NOT NULL, "Gr_Nos" Varchar2(50 ), CONSTRAINT "Gr_Num" PRIMARY KEY ("Gr_Num"))/

-- Table Asociacija1

CREATE TABLE "Asociacija1"( "Dat_No" Date, "Dat_Lidz" Date, "Mp_Num" Integer NOT NULL, "K_Num" Integer NOT NULL, CONSTRAINT "UI02" PRIMARY KEY ("Mp_Num","K_Num"))/

-- Table Macibu_Programma

CREATE TABLE "Macibu_Programma"( "Mp_Num" Integer NOT NULL, "Mp_Nos" Varchar2(50 ), CONSTRAINT "Mp_Num" PRIMARY KEY ("Mp_Num"))/

-- Table Macibu_Priekshmets

CREATE TABLE "Macibu_Priekshmets"( "P_Num" Integer NOT NULL, "P_Nos" Varchar2(50 ), CONSTRAINT "P_Num" PRIMARY KEY ("P_Num"))/

-- Table Asociacija2

CREATE TABLE "Asociacija2"( "Dat_No" Date, "Dat_Lidz" Date, "Gr_Num" Integer, "Mp_Num" Integer)/

-- Table Students

CREATE TABLE "Students"( "Vards" Varchar2(50 ), "Uzvards" Varchar2(50 ), "STU_Pers_Kods" Varchar2(15 ) NOT NULL, "S_Num" Integer NOT NULL, "Gr_Num" Integer, "A_S_Num" Integer, "A_STU_Pers_Kods" Varchar2(15 ), CONSTRAINT "S_Num" PRIMARY KEY ("S_Num","STU_Pers_Kods"))/

-- Create triggers for table Students

CREATE TRIGGER "InheritanceStudents" BEFORE INSERT ON "Students" for each rowdeclare numrows integerbegin select count(*) into numrows from Pasniedzejs where Pers_Kods = :NEW.Pers_Kods if (numrows > 0) then RAISE_APPLICATION_ERROR(-20003,'Exlusive Inheritance violation with entity Pasniedzejs'); end if; end; /

-- Table Pasniedzejs

CREATE TABLE "Pasniedzejs"( "Vards" Varchar2(50 ), "Uzvards" Varchar2(50 ), "PASN_Pers_Kods" Varchar2(15 ) NOT NULL, "Pasn_Num" Integer NOT NULL, "Pasn_Amats" Varchar2(50 ), CONSTRAINT "Pasn_Num" PRIMARY KEY ("Pasn_Num","PASN_Pers_Kods"))/

-- Create triggers for table Pasniedzejs

CREATE TRIGGER "InheritancePasniedzejs" BEFORE INSERT ON "Pasniedzejs" for each rowdeclare numrows integerbegin select count(*) into numrows from Students where Pers_Kods = :NEW.Pers_Kods if (numrows > 0) then RAISE_APPLICATION_ERROR(-20003,'Exlusive Inheritance violation with entity Students'); end if; end; /

-- Table Studenta_Atz_Saraksts

CREATE TABLE "Studenta_Atz_Saraksts"( "Sar_Num" Number, "Pasn_Num" Integer, "P_Num" Integer, "S_Num" Integer, "STU_Pers_Kods" Varchar2(15 ), "PASN_Pers_Kods" Varchar2(15 ))/

-- Table Macibu_Priekshmets_Pasniedzejs

CREATE TABLE "Macibu_Priekshmets_Pasniedzejs"( "P_Num" Integer, "Pasn_Num" Integer, "PASN_Pers_Kods" Varchar2(15 ))/

-- Table Macibu_Programma_Macibu_Priekshmets

CREATE TABLE "Macibu_Programma_Macibu_Priekshmets"( "Mp_Num" Integer, "P_Num" Integer)/

-- Create views section -------------------------------------------------

CREATE VIEW "Studentu_grupas" AS SELECT A.Vards, A.Uzvards, A.STU_Pers_Kods, B.Gr_Num, B.Gr_NosFROM Students A, Studentu_grupa BWHERE A.Gr_Num=B.Gr_Num/

-- Create procedures section -------------------------------------------------

CREATE PROCEDURE "GlabProc"SELECT A.Vards, A.Uzvards, B.Gr_NumFROM Students A, Studentu_grupa BWHERE A.Gr_Num=B.Gr_NumEND GlabProc/

-- Create synonyms section -------------------------------------------------

CREATE SYNONYM "Syn_StudGrupa" FOR "Studentu_grupa"/

-- Create sequences section -------------------------------------------------

CREATE SEQUENCE "Fak_Seq" INCREMENT BY 1 START WITH 2 NOMAXVALUE NOMINVALUE CACHE 20/

-- Create relationships section -------------------------------------------------

ALTER TABLE "Instituts" ADD CONSTRAINT "Ir1" FOREIGN KEY ("F_Num") REFERENCES "Fakultate" ("F_Num")/

ALTER TABLE "Katedra" ADD CONSTRAINT "Ir2" FOREIGN KEY ("I_Num") REFERENCES "Instituts" ("I_Num")/

ALTER TABLE "Asociacija1" ADD CONSTRAINT "Asociacija1" FOREIGN KEY ("Mp_Num") REFERENCES "Macibu_Programma" ("Mp_Num")/

ALTER TABLE "Asociacija1" ADD CONSTRAINT "Asociacija_1" FOREIGN KEY ("K_Num") REFERENCES "Katedra" ("K_Num")/

ALTER TABLE "Asociacija2" ADD CONSTRAINT "Asociacija2" FOREIGN KEY ("Gr_Num") REFERENCES "Studentu_grupa" ("Gr_Num")/

ALTER TABLE "Asociacija2" ADD CONSTRAINT "Asociacija_2" FOREIGN KEY ("Mp_Num") REFERENCES "Macibu_Programma" ("Mp_Num")/

ALTER TABLE "Atzime" ADD CONSTRAINT "Saite1" FOREIGN KEY ("Pasn_Num", "PASN_Pers_Kods") REFERENCES "Pasniedzejs" ("Pasn_Num", "PASN_Pers_Kods")/

ALTER TABLE "Studenta_Atz_Saraksts" ADD CONSTRAINT "Saite2" FOREIGN KEY ("Pasn_Num", "PASN_Pers_Kods") REFERENCES "Pasniedzejs" ("Pasn_Num", "PASN_Pers_Kods")/

ALTER TABLE "Katedra" ADD CONSTRAINT "Saite8" FOREIGN KEY ("Pasn_Num", "PASN_Pers_Kods") REFERENCES "Pasniedzejs" ("Pasn_Num", "PASN_Pers_Kods")/

ALTER TABLE "Studenta_Atz_Saraksts" ADD CONSTRAINT "Studenta_atz_Saraksts1" FOREIGN KEY ("P_Num") REFERENCES "Macibu_Priekshmets" ("P_Num")/

ALTER TABLE "Atzime" ADD CONSTRAINT "Studenta_atz_Saraksts" FOREIGN KEY () REFERENCES "Studenta_Atz_Saraksts" ()/

ALTER TABLE "Students" ADD CONSTRAINT "Saite_5" FOREIGN KEY ("Gr_Num") REFERENCES "Studentu_grupa" ("Gr_Num")/

ALTER TABLE "Atzime" ADD CONSTRAINT "Saite6" FOREIGN KEY ("S_Num", "STU_Pers_Kods") REFERENCES "Students" ("S_Num", "STU_Pers_Kods")/

ALTER TABLE "Studenta_Atz_Saraksts" ADD CONSTRAINT "Saite7" FOREIGN KEY ("S_Num", "STU_Pers_Kods") REFERENCES "Students" ("S_Num", "STU_Pers_Kods")/

ALTER TABLE "Macibu_Priekshmets_Pasniedzejs" ADD CONSTRAINT "Relationship1_1" FOREIGN KEY ("P_Num") REFERENCES "Macibu_Priekshmets" ("P_Num")/

ALTER TABLE "Macibu_Priekshmets_Pasniedzejs" ADD CONSTRAINT "Relationship1" FOREIGN KEY ("Pasn_Num", "PASN_Pers_Kods") REFERENCES "Pasniedzejs" ("Pasn_Num", "PASN_Pers_Kods")/

ALTER TABLE "Students" ADD CONSTRAINT "Relationship4" FOREIGN KEY ("A_S_Num", "A_STU_Pers_Kods") REFERENCES "Students" ("S_Num", "STU_Pers_Kods")/

ALTER TABLE "Macibu_Programma_Macibu_Priekshmets" ADD CONSTRAINT "Relationship5_1" FOREIGN KEY ("Mp_Num") REFERENCES "Macibu_Programma" ("Mp_Num")/

ALTER TABLE "Macibu_Programma_Macibu_Priekshmets" ADD CONSTRAINT "Relationship5" FOREIGN KEY ("P_Num") REFERENCES "Macibu_Priekshmets" ("P_Num")/