RĪGAS TEHNISKĀ UNIVERSITĀTEDATORZINĀTNES UN INFORMĀCIJAS TEHNOLOĢIJAS FAKULTĀTE

INFORMĀCIJAS TEHNOLOĢIJAS INSTITŪTS

STUDIJU DARBS PRIEKŠMETĀInformācijas sistēmas un CASE rīki

„Toad Data Modeler”

RTU, RDMI0 1.kurss, 2.grupa

Izstrādāja:

Sergejs Provorovs Apl.Nr.: 961REB176

Vladimirs Starovoitovs Apl.Nr.: 051RDB230

Vitālijs Novoselovs Apl.Nr.: 061REB375

Pārbaudīja: prof. Jānis Eiduks

Rīga, 2010

2

SATURS

ANOTĀCIJA...............................................................................................................3UZDEVUMA NOSTĀDNE...........................................................................................4TEORĒTISKĀ DAĻA....................................................................................................51. СASE RĪKS: DEFINĪCIJA, RAKSTUROJUMS UN IZMANTOŠANA.............................52. TOAD DATA MODELER........................................................................................63. TOAD DATA MODELER INSTALĀCIJA PA SOĻIEM................................................74. KOPĒJAIS TOAD DATA MODELER APSKATS.........................................................12

4.1. Rīka instrumentārijs...................................................................................124.2. Modeļa priekšstata līmeņi.........................................................................144.3. Tehniskās prasības un cena.......................................................................154.4. Atbalstīto datu bāžu saraksts.....................................................................154.5. Diagrammu attēlošanas līmeņi..................................................................154.6. Notācijas....................................................................................................16

5. TOAD DATA MODELER MODEĻI..........................................................................235.1. Loģiskais modelis un ar to saistīta funkcionalitāte (LER)............................235.2. Fiziskais modelis un ar to saistīta funkcionalitāte (PER)............................255.3. Parējās funkcijas (papildus iespējas)..........................................................34

PRAKTISKĀ DAĻA......................................................................................................386. KONCEPTUĀLAIS MODELIS.................................................................................397. LOĢISKAIS MODELIS...........................................................................................40

7.1. Modeļa izveide..........................................................................................407.2. Loģiskā modeļa verifikācija........................................................................487.3. Kopējais modelis........................................................................................507.4. Loģiskā modeļa atskaites ģenerēšana HTML formātā...............................52

8. FIZISKAIS MODELIS.............................................................................................568.1. Loģiska modeļa transformācija uz fizisko modeli.......................................578.2. Fiziskā modeļa atskaites ģenerēšana PDF formātā....................................61

9. SQL KODA ĢENERĒŠANA....................................................................................6410. LOĢISKĀ UN FIZISKĀ MODEĻU SALĪDZINĀŠANA.................................................70SECINĀJUMI..............................................................................................................72LITERATŪRAS SARAKSTS...........................................................................................73PIELIKUMS................................................................................................................74

3

ANOTĀCIJA

Studijas darba ietvaros tika izpētīts Toad Data Modeler v3.5.10.4 CASE rīks uz konkrēta piemēra. Minētais rīks apvieno sevī objektorientēto, konceptuālo un fizisko datu modelēšanas iespējas. Izstrādātais darbs tika izpildīts grupā, kas sastāv no trim cilvēkiem.

Darbs ir sadalīts divās galvenās daļās. Pirmā daļa ir teorētiskā, kurā tiek apskatīts un izpētīts izmantojamais CASE rīks, tā iespējas un funkcionalitāte. Savukārt, otrajā daļā notiek pašas datu bāzes realizācija ar rīka palīdzību.

Darba izpildes gaitā tiek izveidots loģiskais modelis, kurš ir vienlaicīgi arī konceptuālais modelis (ar entītijām, saitēm utt.). Pēc loģiskā modeļa transformācijas, tiek iegūts fiziskais datu bāzes modelis. Abi modeļi tiek salīdzināti savā starpā: 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. Salīdzināšanas rezultātā tiek atrastas atšķirības. Gan fiziskajam, gan loģiskajam modelim uzģenerētas atskaites, kā arī rezultātā tiek iegūts SQL kods datu bāzes izveidošanai.

Darba izpildei izmantota sekojoša programmatūra:

Toad Data Modeler (v3.5.10.4); Microsoft Office 2003 – Word; Microsoft Office 2003 – PowerPoint (darba prezentācijai).

Darbs ir izklāstīts 77 lapaspusēs, iekļaujot sevī 10 nodaļas, secinājumus, literatūras sarakstu un pielikumu ar SQL kodu.

4

UZDEVUMA NOSTĀDNE

Pārbaudīt CASE rīka iespējas un funkcionalitāte uz konkrēta piemēra, jeb:

1. Izpētīt CASE rīkā konceptuālo, loģisko un fizisko modeļa izveides iespējas un to, kā tie ir saistīti sava starpā;

2. Izpētīt notācijas, izmantojamās apzīmējumiem;3. Izpētīt modeļu transformācijas iespējas;4. Izpētīt CASE rīka rediģēšanas iespējas;5. Izpētīt CASE rīka atskaites ģenerēšanas iespējas;6. Izpētīt CASE rīka SQL skripta ģenerēšanas iespējas;7. Aprakstīt rīka priekšrocības un trūkumus;8. Sniegt secinājumus par izpētīto CASE rīku.

5

TEORĒTISKĀ DAĻA

1. СASE RĪKS: DEFINĪCIJA, RAKSTUROJUMS UN IZMANTOŠANACASE (Computer Aided Software Engineering) termins mūsdienās ir plaši pielietojams.

Agrāk tas tika pielietots attiecībā uz programmnodrošinājuma izstrādes automatizāciju, savukārt mūsdienās CASE rīks apzīmē informācijas sistēmu (IS) izstrādes procesu kopumā:

IS izstrāde un nodrošinājums; analīze; prasību formulēšana;

lietišķa programmnodrošinājuma un datu bāžu projektēšana;

koda ģenerēšana;

testēšana;

dokumentēšana;

kvalitātes nodrošināšana;

konfigurācijas;

projekta vadība;

kā arī citi procesi.

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āka 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 veidā, 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 ir sekojošas: Metodoloģija (Method Diagrams), kas nosaka vienotu grafisko valodu un

noteikumus strādājot ar to; Grafiskie redaktori (Graphic Editors), kas 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 liecina par CASE rīku izmantošanas efektivitāti programmlīdzekļu izstrādes procesā. Tomēr eksistē neveiksmju procents, kurš ir diezgan liels.

6

Ņemot vērā CASE rīku dabas daudzveidību, būtu kļūdaini veikt apgalvojumus par reāliem ieguvumiem no to izmantošanu. Var pārskaitīt dažus faktorus, 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 praktiku 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. TOAD DATA MODELER

„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 saprotams 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 datu bāzi, kā arī lietojumprogrammu izstrādi un analīzi. Ir iespējama ātra ER-diagrammu izveide dažādām datubāzes sistēmām(MS SQL, Oracle, Sybase), kā arī datu plūsmas diagrammu izveide.

Ar Toad Data Modeler var:

Grafiski realizēt datu bāzes struktūru (Loģiskās un Fiziskās ER diagrammas);

Veidot EER diagrammas vairākām datu bāzes sistēmām (Oracle, MS SQL, DB2, MySQL, PostgreSQL, utt.);

Pārveidot jau eksistējošu datu bāzes struktūru un attēlot eksistējošās datu bāzes struktūru diagrammas formā;

Pievienot loģiskos datus diagrammām un labāk aprakstīt eksistējošās datu bāzes struktūras;

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

Automātiski ģenerēt SQL kodu, atbilstoši izvēlētai datu bāzei;

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

Sinhronizēt modeli ar fiziski eksistējošām datu bāzēm (izmantojot „Alter Script Generation” un „Model Merge” opcijas);

Saglabāt izmaiņu masīvus, izmantojot „Version Manager”;

Veidot uzdevumu sarakstu, kas 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.

7

8

3. „TOAD DATA MODELER” INSTALĀCIJA PA SOĻIEM

Pirms sākt CASE rīka izpēti, tas būtu jāinstalē lietotāja datorā. Šim mērķim palaidīsim Toad Data Modeler „Setup Wizard” un pakāpeniski iziesim instalācijas procesu pa soļiem.

Pēc noklusējumā ceļš, kur atradīsies Toad Data Modeler ir - C:\Program Files\Quest Software\Toad Data Modeler 3.

Izvēlēsimies, kādas īpatnības (atbalsts priekš atšķirīgām datu bāzes sistēmām) mēs gribam uzstādīt jeb instalēt.

Toad Data Modeler instalācijas procesa sākumā parādās dialoga logs, ar pamācībām tālākajam procesam (skat. 3.1.att.).

3.1.att. Programmas palaišana

Pēc tam lietotājs tiek iepazīstināts ar licences noteikumiem. Tā pat tiek paziņots, ka lietotājs par brīvu var izmantot „trial” (izmēģinājuma) versiju tikai 15 dienu laikā (skat. 3.2.att.).

3.2.att. Piekrišanas licences prasībām logs

9

Nākamajā solī ir iespējams izvēlēties to, kas izmantos Toad Data Modeler programmatūru (skat. 3.3.att.). Mēs izvelēsimies variantu pēc noklusējuma, jo mums nav principiāli tas, kurš no datora lietotājiem būs rīka lietotājs. Pretējā gadījumā var izvēlēties konkrēto lietotāju, kam būs sava parole un atsevišķa pieeja rīkam.

3.3.att. Rīka lietotāja izvēles logs

Tālāk tiek izvēlēta mape, kurā tiks instalēts Toad Data Modeler rīks (skat. 3.4.att.).

3.4.att. Instalēšanas vietas izvēles logs

Nākošajā instalācijas solī ir iespēja izvēlēties, kādas datu bāzes atbalstīs un tādas iespējas būs instalētas Toad Data Modeler rīkā (skat. 3.5.att.). Izvēloties tikai kādu noteiktu datu bāzi, mēs varam paātrināt darbības rīka ietvaros. Šī īpatnība būs uzstādītā tikai uz lokālā cieta diska.

10

3.5.att. Datu bāzu izvēles logs

Nākamajā solī ir iespēja izvēlēties instalācijas soļus, kurus nav nepieciešams uzstādīt. Šāds instalēšanas procesa logs parādās instalējot praktiski jebkuru programmatūru (piemēram, parasti tās ir „ātras piekļuves mapes”) (skat. 3.6.att.).

3.6.att. Ātro piekļuves mapju izvēles logs

Pēc tam ir jāpagaida, kamēr lokālajā diskā tiks izveidotas visas nepieciešamās datnes un mapes turpmākai darbībai. Instalācijas procesa beigās jāizvēlas „Run Toad Data Modeler” un jāspiež poga <Finish>, lai varētu sākt darbu ar programmu (skat. 3.7.att.).

11

3.7.att. Instalācijas procesa beigu logs

Piezīme: Pēdējā Toad Data Modeler versija pieļauj „side-by-side” instalāciju. Neskatoties uz to, ka šī ir pirmā Toad Data Modeler instalācija, tam ir nepieciešams izveidot jaunu instalācijas mapi, kur tiks glabāti konfigurācijas iestatījumi un citas datnes. Līdz ar to parādīsies dialoga logs, kurā ir iespējama mapes izvēle (skat. 3.8.att.). Pirmās instalācijas gadījumā, ir pieejama tikai ”New Configuration” opcijas. Jāspiež poga <OK>.

3.8.att. Rīka konfigurēšanas mapes izvēles logs

Tālāk ir jādod nosaukums instalācijas mapei. Nosaukums pēc noklusējuma ir „Standart Installation”. Apstiprināsim šo izvēli, piespiežot pogu <OK> (skat. 3.9.att.).

3.9.att. Rīka konfigurēšanas mapes izveidošanas logs

12

Tālāk, tā kā Toad Data Modeler būs pieejams testa jeb ”trial” (izmēģinājuma) versijā, paradīsies logs, kas par atgādinās, ka bezmaksas versija būs pieejama tikai 15 dienu laikā no instalēšanas momenta (skat. 3.10.att.).

3.10.att. Informācijas logs, ka izmēģinājuma versija ir pieejama pielietojumam 15 dienu laikā

Nospiežam <Continue Evaluation> pogu (logā, kurš attēlots 3.10.attēlā) un varam sākt izmantot „trial” versiju un beidzot iepazīties ar Toad Data Modeler rīku.

13

4. KOPĒJAIS TOAD DATA MODELER APSKATS

4.1. Rīka instrumentārijsLietotāja saskarne

Rīga lietotāja saskarne ir izpildīta Windows-lietotnes stilā. Tā ir pietiekami vienkārša un intuitīvi skaidra. Palaižot rīku, parādās piemēra „Sample” modelis.

Pamēģināsim izpētīt aprakstāmā CASE rīka iespējas. Galvenais logs – lietotāja saskarne, kurā strādāsim turpmāk, sastāv no galvenās izvēlnes, modeļu joslas, projektētāja, rīku joslas, darba telpas, modeļa pārlūka, lietotnes skata un ziņojumu pārlūka (skat. 4.1.1.att.).

4.1.1..att. Galvenā loga piemērs Trial Versijai

14

Rīku josla

Lietotnes rīks

Secīgi apskatīsim visas piedāvātas Lietotnes rīka funkcijas (skat. 4.1.2.att.).

4.1.2..att. Lietotnes rīks

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

Designer-instrumentārijs fiziskajam modelim

Secīgi apskatīsim visas piedāvātas fiziskā modeļa veidošanas instrumentārija funkcijas (skat. 4.1.3.att.).

4.1.3.att. Designer-instrumentārijs fiziskajam modelim

izvēles veikšanas kursors pievienot entītiju modelī pievienot identificējošu saiti modelī 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ī

Designer-instrumentārijs loģiskajam modelim

Secīgi apskatīsim visas piedāvātas loģiskā modeļa veidošanas instrumentārija funkcijas (skat. 4.1.4.att.).

4.1.4.att. Designer-instrumentārijs loģiskajam modelim

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ī

15

Designer-instrumentārijs meta modelim

16

Secīgi apskatīsim visas piedāvātās meta modeļa veidošanas instrumentārija funkcijas (skat. 4.1.5.att.).

4.1.5.att. Designer-instrumentārijs meta modelim

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ī

17

Darba telpa

Secīgi apskatīsim visas piedāvātās meta modeļa veidošanas instrumentārija funkcijas (skat. 4.1.6.att.).

4.1.6.att. Darba telpas instrumentārijs

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

4.2. Modeļa priekšstata līmeņiToad Data Modeler pastāv divi modeļa priekšstata līmeņi – loģiskais un fiziskais. Loģiskais līmenis – tas ir 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, savukārt, ir 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.

4.3. Tehniskās prasības un cenaToad Data Modeler tehniskās prasības ir aprakstītas 1.tabulā.

1.tabula

Toad Data Modele 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ēmaMicrosoft Windows 2000 Professional Edition (Service Pack 4)Microsoft Windows XP (32-bit or 64-bit)Microsoft Windows Vista (32-bit or 64-bit)Microsoft Windows Server 2003 (32-bit or 64-bit)Microsoft Windows Server 2008 (32-bit or 64-bit)Microsoft Windows 7 (32-bit or 64-bit)

Toad Data Modeler cena ir 479$. Savā darbā mēs strādāsim ar programmas „trial” versiju. Par ierobežojumiem „trial” versijā tika aprakstīts 3 nodaļā (instalācijas gaitā).

4.4. Atbalstīto datu bāžu sarakstsViena no svarīgām Toad Data Modeler īpašībām ir liels datu bāžu skaits, ko atbalsta šīs

CASE rīks. Zemāk ir pārskaitītas datu bāzes, kuriem Toad Data Modeler var realizēt fizisko ER diagrammas modeli:

DB2 9.7 (LUW) DB2 9.5 (LUW) DB2 v. 9 (LUW) DB2 UDB v. 8 (LUW) MS Access 2000/2002/2003 MS SQL Server 2008 MS SQL Server 2005 MS SQL Server 2000 MySQL 5.1 MySQL 5.0

Oracle 11g Release 2 Oracle 11g Release 1 Oracle 10g Oracle 9i PostgreSQL 8.4 PostgreSQL 8.3 PostgreSQL 8.2 PostgreSQL 8.1 Sybase ASE 15 Sybase ASE 12.5

4.5. Diagrammu attēlošanas līmeņiToad 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 (skat. 4.5.1.att.). Ka arī var to izvēlēties no galvenās izvēlnes View->Display Level (skat. 4.5.2.att.).

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

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

4.6. NotācijasModeļu veidošanai Toad Data Modeler rīkā ir iespējams izmantot divas notācijas: IDEF1X

un 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 ir pielietojama, 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. 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. 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. Pilna - liecina par analīzes pabeigtību. Tajā piedāvāto apakštipu salikumu var uzskatīt par izsmeļošu. Nepilnā - 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. Pie izslēdzošas hierarhijas superrealitāte var spēlēt tikai vienas apakšrealitātes lomu, bet pie iekļaujošas – vairāk nekā vienas. Aplūkosim abu notāciju salīdzinājumus 2.tabulā.

2.tabula

Nosacītie IDEF1X un IE notāciju apzīmējumi

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

Realitāte

Realitā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 : M Saites 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ā iespēju viegli „pārslēgties” no IDEF1X uz IE notāciju, izvēloties „Notation” opciju no galvenās rīku izvēlnes (skat.4.6.1.att.).

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

IDEF1X un IE notāciju realizāciju Toad Data Modeler var apskatīt programmas „Palīgā” (Help), kur ļoti pārskatāma veidā ir paradīti saišu un realitāšu realizācijas piemēri.

IE notācija (skat. 4.6.2.att.).

4.6.2.att. Palīgs par IE notācijām

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

4.6.3.att. IE notācijas saišu veidi

IDEF1X notācija (skat. 4.6.4.att.).

4.6.4.att. Palīgs par IDEF1X notācijām

27

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

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

Piezīme: Mūsu darba izpildei tiks izmantota IE notācija.

28

5. TOAD DATA MODELER MODEĻI

5.1. Loģiskais modelis un ar to saistīta funkcionalitāte (LER)Loģiskais modeļa veidošana

Toad Data Modeler vidē var veidot loģisko modeli, definējot darba telpu, pievienojot entītijas (realitātes), atribūtus, unikālus identifikatorus, pievienojot un definējot saites un pievienojot un specificējot mantošanu. Jāatzīmē, ka 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 atšķirīgā no citām krāsā.

Loģiskā modeļa verifikācija

Programmas viena no 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ļā. Verifikācijas aktivizēšana ir attēlota 5.1.1.attēlā.

5.1.1.att. Loģiskā modeļa pārbaudes aktivizēšana

Atskaišu veidošana

Toad Data Modeler var automātiski ģenerēt 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 mēs ģenerēsim atskaiti Universitātes priekšmetiskās vides loģiskajam modelim. Pie tam ir jāatzīmē tas, ka HTML atskaites var modificēt, paplašinot eksistējošo metodi. Iekš 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 (skat. 5.1.2.att.).

29

5.1.2.att. Loģiskā modeļa Script Explorer atskaišu rediģēšanas logs

Modeļu salīdzināšana

Šajā programmatūrā 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 (skat. 5.1.3.att.).

5.1.3.att. Modeļu salīdzināšanas aktivizēšana

Salīdzināt var kā loģiskos modeļus, tā arī fiziskus, pie tam pastāv iespēja automātiski noģenerēt atskaiti HTML formātā, kas saturēs „atšķirības” datus.

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

Gadījumā, kad loģiskais modelis jau ir konvertēts fiziskajā un tajā tiek izdarītas izmaiņas, pastāv iespēja atjaunot arī loģisko modeli, atbilstoši tām izmaiņām, kas tika veiktas fiziskajā modelī. Šim nolūkam, kalpo Convertor. Tā pat ir iespējams apvienot divus loģiskus modeļus vienā, izmantojot Merge Models funkciju. Šī rīka aktivizēšana ir apskatāma 5.1.4.attēlā).

5.1.4.att. Modeļa atjaunošanas un apvienošanas aktivizēšana

30

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

Toad Data Modeler ļauj transformēt loģisko modeli fiziskajā. Šim mērķim, tiek izmantots Convertor. Izvēloties Model -> Simple Model Conversion vai Model Conversion, Model Merge (skat. 5.1.4.att. kā arī iepriekš attēlotais 5.1.5.att.).

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

Pirms konvertēt loģisko modeli ->fiziskajā modelī, ir jāzina daži noteikumi:

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.t.t.

Sīkāk, loģiska modeļa konvertēšana fiziskajā modelī tiks apskatīts turpmāk darba gaitā.

5.2. Fiziskais modelis un ar to saistīta funkcionalitāteFiziskā modeļa veidošana

Toad Data Modeler(TDM) vidē var veidot fizisko modeli. Tā kā TDM atbalsta vairākas DBVS, pirms modeļa veidošanas ir jānokonkretizē un jāizvēlas kādu no datu bāzu sistēmām. Tad var pievienot entītijas, un nodefinēt to īpašības (skat. 5.2.1.att.).

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

31

Ka redzams iepriekšējā attēlā, ir vesela virkne funkciju, ko var pielietot, veidojot entītiju fiziskajā modelī:

General – šeit, visas galvenie uzstatījumi, kas definē entītiju: nosaukums, uzraksts, kategorija, izmērs

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

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

Indexes – šeit var veidot indeksus

Check Constraints – šeit var veidot ierobežojumus

Triggers – šeit var veidot trigerus

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

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

Notes – entītiju detaļas, paskaidrojumi u.t.t.

SQL Preview – entītijas SQL kods (skat. 5.2.2.att.).

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

Fiziskajā modelī var arī nodefinētas saites, kardinalitātes (saišu jaudas) u.t.t. (skat. 5.2.3.att.).

32

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

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šana, procedūru un funkciju definēšana, indeksu, trigeru definēšana un pat definēt lietotāja datu tipus, ērtākam darbam.

Fiziskā modeļa verifikācija

Tā pat kā loģiskajā modeli, šeit ir iespēja pārbaudīt fizisko modeli, veicot modeļa verifikāciju, kas palīdz atklāt kļūdas un brīdinājumus (skat. 5.2.4.att.).

5.2.4.att. Fiziskā modeļa verifikācijas aktivizēšana

Dokumentācija

Toad Data Modeler automātiskā dokumentācija priekš fiziskā modeļa piedāvā sekojošas iespējas:

Var ģenerēt atskaites HTML, RTF un PDF formātos, izmantojot Report Wizard (skat. 5.2.5.att.).

33

5.2.5.att. Fiziskā modeļa atskaišu ģenerēšanas izvēles logs

Var izveidot lietotāju atskaites fiziskajam modelim – HTML, PDF, CSV, text vai XML formātos (skat. 5.2.6.att.).

5.2.6.att. Fiziskā modeļa lietotāja atskaišu ģenerēšanas izvēles logs

Var ģenerēt XSD failu fiziskajam modelim (skat. 5.2.7.att.).

5.2.7.att. XSD fails fiziskajam modelim

Skripta ģenerēšana

No fiziskā modeļa var ģenerēt DDL/SQL kodu, pie tam 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

34

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. Iespējas aktivizēšana ir apskatāma 5.2.8.attēlā).

5.2.8.att. DDL/SQL koda ģenerēšanas aktivizēšana

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

Toad Data Modeler ļauj konvertēt fizisko modeli no vienas datu bāzes sistēmas uz citu, piemēram, Oracle 10g fiziskais modelis var būt konvertēts SQL Server 2005 modelī.

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. Funkcijas aktivizēšana ir apskatāma 5.2.9.attēlā.

5.2.9.att. Modeļa konvertēšanas aktivizēšana

Reverse engineering

Apvērstās inženierijas opcija ir viena no vissinteresantākām opcijām, kas eksistē Toad Data Modeler vidē. Šī opcija dod iespēju ielādēt jau eksistējošo datu bāzu struktūras un veidot jaunas ER diagrammas.

Pastāv divi apvērstās inženierijas veidi: standard reverse engineering un live reverse engineering.

Standard reverse engineering režīmā indeksi, komentāri, trigeri, saites, ierobežojumi, funkcijas, skati, procedūras, lietotāju tipi u.t.t. ielādējās jaunajā ER diagrammā, atbilstoši eksistējošai datu bāzes 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ā kā savā darbā mēs neizskatīsim šo Toad Data Modeler opciju, īsumā apskatīsim piemēru, kā tas tiek darīts.

Sākumā ir jāizvēlas saglabātus pseidonīmus (skat.5.2.10.att.).

35

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

Pēc tam ir jāizvēlas datu bāze (skat. 5.2.11.att.).

5.2.11.att. Datu bāzes izvēle

Tad jāizvēlas savienošanas tips no izvēlētajai datu bāzei pieejamiem tipiem (skat. 5.2.12.att.).

36

5.2.12.att. Savienošanas tipu izvēle

Ir pieejamie sekojošie savienošanas tipi (atkarībā no datu bāzes): ADO; Native; TCP/IP; ODBC.

Tad jānokonfigurē savienojums (skat. 5.2.13.att.).

5.2.13.att. Savienojuma konfigurācija

Tālāk ir jāizvēlas datu migrātors (skat. 5.2.14.att.).

37

5.2.14.att. Datu migrātora izvēle

Jāizvēlas objekti, kurus ir jāpārveido (skat. 5.2.15.att.).

5.2.15.att. Pārveidojamo objektu izvēle

Jāsaglabā pseidonīms (skat. 5.2.16.att.).

38

5.2.16.att. Pseidonīma saglabāšana

Jāizvēlas shēmas un tabulas (skat. 5.2.17.att.).

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

Visbeidzot tiek izvadīts paziņojums par apvērstās inženierijas pabeigšanas procesu (skat. 5.2.18.att.).

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

39

Tad, kad apvērstā inženierija ir pabeigta, var apskatīt jaunu ER diagrammu no iepriekš eksistējošas datu bāzes. Tika izveidots Fiziskais Modelis, kas ir redzams 5.2.19.attēlā.

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

5.3. Parējās funkcijas (papildus iespējas) Automātiskā modeļa izkārtošana

Automātiskā izkārtojuma funkcija ļauj izvietot modeļa objektus darba telpā automātiski. Tas varētu būt noderīgs pēc loģiska modeļa konvertēšanas fiziskajā modelī. Aktivizēšanas process ir apskatāms 5.3.1.attēlā.

40

5.3.1.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.

Version Manager

Toad Data Modeler var veidot projektus, pievienot modeļus un citus failus, ka arī mainīt modeļus, veidot to versijas u.t.t. Var veidot neierobežotu projektu skaitu.

Tā kā savā darbā šo opciju mēs neizskatīsim, tad apskatīsim vienu no piemēriem, kā pievienot esošo modeli kādam konkrētam projektam.

Sākumā ir jāizveido jaunu projektu ar Add Project palīdzību (skat. 5.3.2.att.).

5.3.2.att. Jauna projekta izveidošana

Tad jāpievieno šim projektam esošo modeli (Add to Version Manager) (skat. 5.3.3.att.).

5.3.3.att. Modeļa pievienošana projektam

41

Pēc apstiprināšanas, izvēlētais modelis (tā pat kā katrs jaunais pievienotais) tiks pievienots konkrētam projektam. Līdz ar to, vienmēr būs iespēja apskatīt projekta vairākas versijas, kuras vien 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. Uzdevumus var pievienot:

Kādai modeļa daļai, uzklikšķot uz objekta ar labo peles pogu un izvēloties no „Edit” izvēlnes šķirkli Properties, kurā tālāk jāizvēlas To Do cilnis (tab). Tiks attēlots uzdevumu saraksts, kuri ir saistīti tieši ar izvēlēto objektu.

Galvenā To Do dialoga logā, ko var atrast zem Model ->To Do (papildus šeit tiks paradīts pilns uzdevumu saraksts).

Galvenais To Do dialoga logs ir attēlots 5.3.4.attēlā. Var redzēt, ka ir norādīti divi uzdevumi, kas attiecas uz Loģisko modeli kopumā. Pievienot jaunu uzdevumu var ar Add opciju, izmainīt esošo uzdevumu ar Edit, un atbilstoši izdzēst uzdevumu vispār ar Delete.

5.3.4.att. Loģiskā modeļa uzdevumi

Apskatīsim vienu piemēru jauna uzdevuma pievienošanai (skat. 5.3.5.att.). Attēlā ir redzams tas, kā uzdevumam var noteikt prioritāti, noteikt izpildes termiņus un noteikt kategoriju.

42

5.3.5.att. Jauna uzdevuma definēšana

Kā jau bija minēts, Toad Data Modeler vidē var piesaistīt uzdevumus ne tikai modelim kopumā, bet arī atsevišķiem objektiem. Objektu saraksts, kuriem var pievienot uzdevumus ir sekojošs:

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.

Kā piemēru apskatīsim - kā var pievienot uzdevumu entītijai Studentu_grupa, izvēloties Properties izvēlnē cilni (tab) To Do (skat. 5.3.6.att.).

5.3.6.att. Jauna uzdevuma definēšana entītijai Studentu_grupa

43

Pārbaudām galveno To-Do sarakstu, kur automātiski ir pievienojies jauns uzdevums (skat. 5.3.7.att.).

5.3.7.att. Kopējais uzdevumu saraksts ar automātiski pievienoto uzdevumu

Ir redzams ka uzdevums ir automātiski pievienots kopējam sarakstam, un, atšķirība no pārējiem uzdevumiem, Object Name ailē ir entītijas nosaukums Studentu_grupa.

Tagad, kad šķiet, ka esam izpētījuši to, kā strādā mūsu pētāmais CASE rīks, varam izveidot mūsu priekšmetisko vidi, kuru arī mēģināsim realizēt ar Toad Data Modeler palīdzību. Līdz ar to mēs beidzot varam pāriet pie darba praktiskās daļas.

44

PRAKTISKĀ DAĻA

6. KONCEPTUĀLAIS MODELIS

Darba praktiskajā daļā mēs cenšamies paradīt visu iepriekš aprakstīto rīka funkcionalitāti uz konkrēta piemēra.

Par pamatu mēs izvelējāmies piemēru, kurš apraksta VID struktūru. Tā kā Toad Data Modeler nav iespējas izveidot konceptuālo modeli, tad to realizējam ConceptDraw vidē, balstoties uz iepriekš minēta piemēra struktūras (skat. 6.1.att.).

6.1.att. Konceptuālais modelis

45

7. LOĢISKAIS MODELIS

7.1. Modeļa izveide

Entītiju, atribūtu un primāro atslēgu izveide

Tātad, balstoties uz izveidoto konceptuālo modeli, sāksim realizēt loģisko modeli ar Toad Data Modeler palīdzību.

Sākot darbu, izvēlēsimies galvenajā izvēlnē File->New Model... Atvērsies dialoga logs, kur ir divas cilnes (tab): Logical Data Model un Physical Data Model. Jāizvēlas Logical Model un jāspiež poga <OK> (skat. 7.1.1.att.).

7.1.1.att. Loģiskā modeļa izveides logs

Lai pievienotu modelim entītiju, ir nepieciešams vai nu galvenajā izvēlnē izvēlēties Objects->Entity...,(skat. 7.1.2.att.) vai nu rīkjoslā izvēlēties entītijas apzīmējumu un nospiest jebkurā vietā, kur gribam izvietot entītiju ar peles kreiso taustiņu.

7.1.2.att. Entītijas izveidošana

46

Darba telpā paradās jauna Entītija. Uzklikšķinot uz to ar peles kreiso taustiņu divas reizes, paradīsies logs EntityProperties. (7.1.3.att.). Sākumā apskatīsim jaunas Entītijas izveidi un atribūtu definēšanu tajā. Nosauksim mūsu entītiju „VID”, ierakstot vērtību laukā Name.

7.1.3.att. Entītijas datu definēšana

Pēc tam definējam entītijai attiecīgus atribūtus. To var izveidot Attributes cilnē (tab) (skat. 7.1.4.att.).

7.1.4.att. Entītijas atribūtu definēšana (1)

47

Veidojam attiecīgus atribūtus. Sāksim ar Reg_Nt atribūtu, kur datu tips ir Integer (Long Integer tips netiek piedāvāts). Pievienojam atribūtu, un nospiežam pogu <OK+Add>. Pāriesim pie nākamā atribūta (skat. 7.1.5.att.)

7.1.5.att. Entītijas atribūtu definēšana(2)

Nākamais atribūts ir Adrese. izvēlēsimies datu tipu VarChar un atribūta garumu līdz 30 simboliem.

Tālāk, ja ir nepieciešams, turpināsim pievienot atribūtus, nospiežot pogu <Ok+Add>. Kad visi atribūti ir sekmīgi definēti, tad spiežam pogu <OK> (skat. 7.1.6.att.).

48

7.1.6.att. Visi entītijas atribūti

Visus atribūtus mēs varam aplūkot kopējā entītijas atribūtu logā. Tad, kad visi atribūti ir definēti, varam pāriet pie cilnes UniqueIdentifiers (skat.7.1.7.att.). Vienam no atribūtiem jābūt primārai atslēgai, mūsu gadījumā tas ir atribūts Reg_Nr.

7.1.7.att. Unikālo identifikatoru rediģēšanas logs

Lai pievienotu primāro atslēgu (unikālo identifikatoru), sākumā ir jānospiež poga <Add>. Mums parādās logs, kur mēs varam izdarīt primārās atslēgas izvēli „Attributes” cilnē. Šeit no piedāvātājiem atribūtiem ar bultiņu palīdzību pa labi > pārvilksim nepieciešamo primāras atslēgas atribūtu uz labo pusi (skat. 7.1.8.att.).

49

7.1.8.att. Unikālo identifikatoru izvēles logs

Visbeidzot, mūsu izveidotā entītija VID ir apskatāma 7.1.9.attēlā pēc visu atribūtu definēšanas un primāras atslēgas atribūta izvēles.

7.1.9.att. Izveidotā entītija „VID”

Tādā pašā veidā mēs pa soļiem definējam katru mums nepieciešamo entītiju, mūsu priekšmetiskās vides realizācijai.

Binārās saites izveide

Tagad sāksim saišu definēšanu starp entītijām. Sāksim ar bināro saiti starp realitātēm VID un Parvalde.

Tagad izvēlamies saiti no rīku joslas Objects -> Relationship (vai no rīka instrumentu paneļa) (skat. 7.1.10.att.) un uzklikšķinām vienu reizi uz vienas, otru reizi uz otras entītijas, kurai būs foreign key lauks ar peles kreiso taustiņu.

50

7.1.10.att. Saites izvēle

Paradīsies saite starp divām izvēlētām entītijām. Uzklikšķinot uz to saites ar peles kreiso taustiņu divas reizes, paradīsies logs RelationshipProperties (skat. 7.1.11.att.).

7.1.11.att. RelationshipProperties dialoga logs, saites datu definēšanai (1)

Nosauksim saiti „Relationship1”, jo attiecība starp „Vecāku” un „Bērnu” ir sekojoša: VIDā ir Parvalde.

Cilnē Cardinality varam izvēlēties saites veidu, kura mums ir nepieciešama 1:1, vai 1:N, u.t.t. (skat. 7.1.12.att.).

51

7.1.12.att. Saites veida izvēle

Mantošanas realizācija

Nākamajā solī izveidosim mantošanas attiecības starp trim realitātēm, kur Klients ir Parent entītija, bet Jur_persona un Fiz_persona ir Child entītijas. Izveidojot trīs realitātes un definējot tiem attiecīgus atribūtu un unikālus identifikatorus, izvēlēsimies Objects-> Inheritance (skat. 7.1.13.att.).

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

Ir arī iespēja izmantot rīka instrumentu joslā mantošanas pogu un nospiest sākumā uz vecāka entītijas lauku, t.i. Klients, ar peles kreiso taustiņu. Pēc tam jāspiež uz bērna entītijas lauku, piem. Jur_persona. Lai pievienotu otro bērnu, atkal rīku joslā izvelēsimies mantošanas

5232.att.

apzīmējumu un nospiežam uz mantošanas simbolu mūsu modelī . Tagad varam spiest, attiecīgi, uz otrā bērna realitāti, t.i. Fiz_persona.

Bez tam, uzklikšķinot divas reizes uz tā paša mantošanas simbola mūsu darba telpā, parādās mantošanas dialoga logs, kur ir iespējams atzīmēt vai tā būs pilnā vai izslēdzošā mantošana (skat. 7.1.14.att.).

7.1.14.att. Mantošanas tipa izvēle

Savukārt, paaudžu cilnē (Generation), ir iespēja atzīmēts kurš un ko mantos – vecāks visus bērnus, katras bērns vecāku, vai arī transformējot modeli fiziskajā, tas sakritīs ar loģisko (skat. 7.1.15.att.). Mūsu gadījumā, lai pārbaudītu to, kas notiks ar mantošanas struktūru konvertācijas procesā, izvelēsimies otro no minētajiem variantiem.

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

Mūsu modelī, kā jau tika minēts, mantošana ir realizējama starp realitātēm bērnu Jur_persona, Fiz_persona un vecāku realitātes Klients (skat. 7.1.16.att.).

53

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

Tātad, realizējot konceptuālā modeļa mantošanas struktūru ar Toad Data Modeler rīka palīdzību, tā izskatās sekojoši:

7.1.17.att. Realizētā mantošanas struktūra

7.2. Loģiskā modeļa verifikācijaLoģiskā modeļa verifikāciju jeb pārbaudi var veikt galvenajā izvēlnē izvēloties Model ->

VerifyModel (skat. 7.2.1.att.).

7.2.1.att. Verifikācijas aktivizēšana

Lietotājam parādās dialoga logs, kurā viņš var izvēlēties kritērijus, pēc kuriem tiks veikta modeļa pārbaude (skat. 7.2.2.att.).

54

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

Pēc veiktās izvēles ir jānospiež poga <Verify>, un Ziņojumu pārlūkā (Log) paradīsies verifikācijas un pārbaudes rezultāti (skat. 7.2.3.att.).

7.2.3.att. Verifikācijas rezultāta ziņojuma logs(1)

Pēc verifikācijas mūsu modelis ir pareizs. Kļūdu skaits ir 0, brīdinājumu skaits ir 0. (skat. 7.2.4.att.).

7.2.4.att. Verifikācijas rezultāta ziņojuma logs(2)

55

7.3. Kopējais modelisTātad, tagad mums ir izveidots loģiskais modelis mūsu izvēlētajai priekšmetiskai videi –

VID (skat. 7.3.1.att.).

7.3.1.att. Izveidotais loģiskais modelis(1)

Būtu lietderīgi arī apskatīties visu modeli nedaudz lielākā izklājumā, tikai darba telpas ietvaros (skat. 7.3.2.att.).

56

7.3.2.att. Ar Toad Data Modeler izveidotais Loģiskais modelis „VID”

58

7.4. Loģiskā modeļa atskaites ģenerēšana HTML formātāTagad, kad mēs izveidojām un pārbaudījām loģisko modeli, apskatīsim vēl vienu no

iepriekš minētam funkcijām: atskaišu ģenerēšana. Toad Data Modeler eksistē Report Wizard, ar kura palīdzību mēģināsim izveidot atskati par loģisko modeli (skat. 7.4.1.att.).

7.4.1.att. Atskaites izveides logs

Kā bija minēts, loģiskam modelim var veidot atskati tikai HTML formātā, tāpēc arī to izvēlāmies (skat. 7.4.2.att.).

7.4.2.att. Atskaites formāta izvēle

Rīkā ir piedāvāta iespēja izvēlēties atskaites grafisko elementu izkārtojumu, un CSS stilus (10 dažādi stili), un, protams, kā bija minēts agrāk, var pašiem mainīt HTML atskaišu struktūru, par ko ir aprakstīts darba teorētiskajā daļā (skat. 7.4.3.att).

59

7.4.3.att. Atskaites vizuālā tēla izveide

Pēc tam ir jāizvēlas to, kādu tieši informāciju gribām redzēt atskaitē (skat. 7.4.4.att.).

7.4.4.att. Atskaites informācijas izvēle

Kad atskaite būs noģenerēta, lietotajam tiks par to paziņos, un, lai apskatītu atskaiti, būs jānospiež <Show Report> poga (skat. 7.4.5.att.).

7.4.5.att. Atskaites izveides procesa pabeigšanas paziņojums

7.4.6., 7.4.7., 7.4.8. un 7.4.9. attēlos ir iespējams aplūkot loģiskā modeļa atskaites HTML formātā piemērus. Atskaites lapā ir vairākas cilnes, kur var apskatīt visdažādāko informāciju,

60

atsevišķi par entītijām, atsevišķi par atribūtiem, par mantošanas attiecībām, ka arī var apskatīt ER diagrammu kopumā un vispārīgu informāciju par modeli.

7.4.6.att. Atskaites „Model Info”

7.4.7.att. Atskaites „ER Diagram”

61

7.4.8.att. Atskaites informācija par entītiju „Darba_nemejs”

7.4.9.att. Atskaites informācija par modeļa mantošanas struktūrām

62

8. FIZISKAIS MODELIS

8.1. Loģiska modeļa transformācija uz fizisko modeli

Kad loģiskais modelis ir izveidots un pārbaudīts, ķersimies klāt tā konvertēšanai fiziskajā modelī. Sākumā izpētīsim kā transformējas atsevišķas loģiskā modeļa struktūras fiziskajā modelī, un tad apskatīsim visa modeļa konvertēšanu.

To var izdarīt sekojoša veidā: Galvenajā izvēlnē izvēlēsimies File -> Sync & Convert -> Sync & Convert Wizard (skat. 8.1.1.att.), jeb rīkjoslā jānospiež uz atbilstošu elementu.

8.1.1.att. Modeļa konvertēšanas aktivizēšana

Pēc tam paradās Wizarda logs, kur jāizvēlas turpmāku darbību. (skat. 8.1.2.att.)

63

8.1.2.att. Modeļa konvertēšanas palīgs (1)

Pēc tam izvelēsimies modeli, kuru gribam konvertēt un nospiežam Next. (skat. 8.1.3.att.)

8.1.3.att. Modeļa konvertēšanas palīgs (2)

Tālāk izvelēsimies datu bāzes platformu (mūsu gadījumā Oracle 10g) uz kuras grībām konvertēt mūsu modeli un nospiežam Next. (skat. 8.1.4.att.)

64

8.1.4.att. Modeļa konvertēšanas palīgs (3)

Tālāk ir piedāvāta iespēja izvelēties objektus konvertēšanai. Var izvelēties gan visus, gan tikai atsevišķus objektus. Mūsu gadījumā izvelēsimies visus objektus un nospiedīsim Next (skat. 8.1.5.att.).

8.1.5.att. Modeļa konvertēšanas palīgs (4) „Objektu izvēle”

Tālāk ir piedāvāta iespēja izvelēties objektus konvertēšanai. Var izvelēties gan visus, gan tikai atsevišķus objektus. Mūsu gadījumā izvelēsimies visus objektus un nospiedīsi Next. (skat. 8.1.6.att.)

65

8.1.6.att. Modeļa konvertēšanas palīgs „Objektu izvēle”

Pēc tam ir piedāvāts vēlreiz apskatīt konvertēšanas uzstādījumus un ievadīt mūsu fiziskā modeļa nosaukumu (skat. 8.1.7.att.)

8. 1.7.att. Modeļa konvertēšanas palīgs „Uzstādījumi”

Konvertācijas procesa uzsākšanai nospiedīsim „Finish” un pagaidīsim kad konvertācijas process tieks pabeigts.

66

Pēc konvertācijas procesa pabeigšanas tiek izveidots fiziskais modelis (skat. 8.1.8.att.)

8.1.8.att. Izveidotais „Fiziskais modelis”

67

8.2. Fiziskā modeļa atskaites ģenerēšana PDF formātāTagad, kad loģiskais modelis tika konvertēts un iegūts fiziskais modelis, apskatīsim atskaišu

ģenerēšanu tieši fiziskiem modeļiem. Toad Data Modeler eksistē Report Wizard, ar kuru palīdzību mēģināsim izveidot atskati par transformēto fizisko modeli (skat. 8.2.1.att.).

8.2.1.att. Fiziskā modeļa atskaites ģenerēšanas sākuma logs

Atšķirībā no loģiskā modeļa, atskaišu ģenerēšanai fiziskajam var izvēlēties atskaites formātu. Šoreiz kā piemēru izvēlēsimies PDF formātu, un, līdzīgi kā iepriekš, izvēlēsimies atskaitei vēlamo informāciju (skat. 8.2.2.att.).

8.2.2.att. Fiziskā modeļa atskaites informācijas izvēle

Atskaites ģenerēšanas soļi ir tādi paši kā ģenerējot loģiskā modeļa atskaiti. Kad atskaite ir noģenerēta, lietotājs par to saņem paziņojumu (skat. 8.2.3.att.).

68

8.2.3.att. Fiziskā modeļa atskaites ģenerēšanas pabeigšanas paziņojums

Kad atskaite ir uzģenerēta, mēs varam to apskatīties. Atverot atskaiti, mēs ieraugām galveno lapu (skat. 8.2.4.att.). Var pievērsts uzmanību, tam, ka kopējais atskaites lappušu skaits ir 43, kas liecina par ļoti sīku un detalizētu modeļa aprakstu. Piemēru divām lappusēm, kuras detalizēti apraksta Entītiju „Darba_nemejs” un „Eka”, var apskatīt 8.4.5.attēlā. Tā pat atskaitē atsevišķi pa daļām ir aprakstītas katras struktūras (saites, atribūti, trigeri, virknes, u.t.t.).

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

69

8.2.5.att. Fiziskā modeļa atskaites piemērs par entītiju „Darba_nemejs” un „Eka”

8.2.6.att. Fiziskā modeļa atskaites piemērs par entītiju „Trigger Report”

9. SQL KODA ĢENERĒŠANA

Pēc fiziska modeļa ģenerēšanas un koriģēšanas, pāriesim pie SQL koda ģenerēšanas. Izveidosim DDL skriptu. Galvenajā izvēlnē izvēlēsimies Model->Generate DDL Skript (skat. 9.1.att.). Visu SQL koda skriptu var aplūkot 1.pielikumā.

9.1.att. DDL/SQL koda ģenerēšanas aktivizēšana

Uz ekrāna parādīsies logs, kurā no saraksta izvēlēsimies visus elementus, kuriem ģenerēsim kodu, piemēram, visas Entītijas, Funkcijas, skati, Pakotnes, u.t.t. (skat. 9.2.att.).

71

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

9.3.att. DDL/SQL koda ģenerēšanas „Detail Settings”

Pēc tam ir jānospiež poga <Generate>. Pēc pogas nospiešanas tiek saglabāts fails *.sql formātā norādītajā mapē, kurā arī atrodas uzģenerētais kods.

Ziņojumu pārlūkā mēs varam redzēt ģenerēšanas procesu un paziņojumu par veiksmīgu koda ģenerēšanu (skat. 9.4.att.).

72

9.4.att. Ziņojuma logs par ģenerēšanas procesa gaitu

Uzģenerēto kodu mēs uzreiz arī varam aplūkot, nospiežot pogu <Show Code>. Mums atvērsies logs, kurā mēs redzēsim SQL kodu visām entītijām (jeb tabulām) ar visiem atribūtiem un to tipiem (skat. 9.5.att.).

9.5.att. Uzģenerētais kods

Pētāmajā CASE rīkā ir arī iespēja izvēlēties objektu ģenerēšanas kārtību. Šo funkciju var palaist no galvenās izvēlnes joslas, izvēloties Model -> Order of Generated Objects (skat. 9.6.att.).

9.6.att. Koda ģenerēšanas kārtības aktivizēšana

73

Tiek attēlots logs, kurā ir iespējams paskatīties un izlabot objektu ģenerēšanas kārtību (ar zaļo bultiņu palīdzību) (skat. 9.7.att.). Mēs uzstādīsim secību tādu, ka sākuma tiks ģenerētas entītijas, tad skati un procedūras, pēc tam tikai sinonīmi un virknes.

9.7.att. Koda ģenerēšanas kārtības izvēle

Pēc tam veicam atkārtotu ģenerēšanu un redzam, ka ģenerētā secība ir tāda, kādu mēs esam definējuši (skat. 9.8.att.).

74

9.8.att. Uzģenerētais SQL kods pēc secības izvēles

Tabulas ir izveidotas visai korekti, ar visiem tipiem, ierobežojumiem un primārām atslēgām.

Tālāk apskatīsimies kodu mantošanas struktūrām (skat. 9.9. un 9.10.att.).

9.9.att. Uzģenerētais kods mantošanas trigerim (1)

75

9.10.att. Uzģenerētais kods mantošanas trigerim (2)

Kā var redzēt, mantošanas saite abām tabulām Jur_persona un Fiz_persona tika realizēta kā trigeris. Izveidoto trigeru struktūra abos gadījumos ir vienāda. Gadījumā, ka vienā no tabulām tiek veikta jauna ieraksta pievienošana, tad pirms ievades trigeris pārbauda, vai otrajā tabulā jau nav ievadīts tāds pats reģistrācijas numurs, kas ir unikāla primārā atslēga. Gadījumā, ja tiek ievadīts tāds reģistrācijas numurs, kas jau otrā tabulā eksistē, tad tiek izvadīts kļūdas paziņojums.

Tagad izskatīsim to, kā realizējās ārējo atslēgu piesaistīšana (skat. 9.11.att.).

9.11.att. Uzģenerētais kods ārējo atslēgu piesaistīšanai uz unārās saites piemēra

Varam secināt, kā šī saite arī ir izpildīta veiksmīgi.

76

10. LOĢISKĀ UN FIZISKĀ MODEĻU SALĪDZINĀŠANA

Divu modeļu salīdzināšanu var veikt ar Sync &Convert Wizard (skat. 10.1.att.).

10.1.att. Modeļu salīdzināšanas procesa aktivizēšana

Bet ir jāatzīmē, ka dotajā Toad Data Modeler versijā (v3.5.10.4) nevar uzreiz salīdzināt loģiskā un fiziskā modeļu atbilstību savā starpā. Līdz ar ko pirms salīdzināšanas konvertēsim mūsu fizisko modeli atpakaļ uz loģisko modeli. Un tikai tad var salīdzināt mūsu modeļus.

Rezultāta iegūsim sekojošu tabulu (skat. 10.2.att.).:

10.2.att. Modeļu salīdzināšanas process

77

Pēc tabulas var redzēt, ka pēc transformācijas „Fiziskā modelī” tiek izveidota jauna tabula Parvalde_Eka, tas notiek tāpēc, ka starp tabulām Parvalde un Eka loģiskajā modelī tika uzstādīta saite N:M (daudz pret daudziem), līdz ar ko transformācijas procesā tika izveidota starptabula. Vēl var redzēt, kā pēc transformācijas uz fizisko modeli tika pazudušas trīs tabulas no loģiskā modeļa: Klient, Darbinieks un Amatpersona. Tas notiek mantošanas dēļ. Jo 1.mantošanā atribūti no tabulas Klient tika migrēti uz tabulu Jur_persona un Fiz_persona, un 2.mantošanas dēļ atribūti no tabulas Darbinieks un Amatpersona tika migrēti uz tabulu Darba_nemejs.

78

SECINĀJUMI

Studijas darba ietvaros tika izpētīts Toad Data Modeler v3.5.10.4 CASE rīks. Pēc iegūtiem rezultātiem var secināt, ka šīm rīkam ir gan plusi, gan arī mīnusi. Minēta rīka priekšrocības un trūkumus atspoguļosim sekojošā tabulā:

Toad Data Modeler plusi un mīnusi

Plusi MinusiĒrta lietotāju saskarne (User friendly

interface) Nevar izveidot konceptuālo modeli

Liels DBVS atbalsts Manuāla skatu un procedūru definēšana (SQL kods)

Mantošanas realizācija trigerī pēc transformācijas

Pēc transformācijas visas saites 1 : 1,N kļūst par 1 : 0,N (pēc tam jākoriģē ar rokam)

Modeļu atjaunošana pēc labojumiem Saites N:M tika realizēta ar starptabulām

Transformācijas (LER -> PER; PER -> LER)

Var salīdzināt tikai LER ar LER vai PER ar PER modeli, jeb nevar salīdzināt LER ar PER modeli pa taisni (jāatzīmē, ka iepriekšējā programmatūras versijā tāda iespēja eksistē)

Atsevišķu elementu transformācija Nepārskatāms izkārtojums pēc transformācijas (pēc tam jākoriģē ar rokam)

SQL skripts Tikai divas notācijas veidu atbalstsVersiju glabāšana projekta ietvaros AutoLayout nepārskatāms izvietojumsPER modeļa papildināšana Trial versijas ierobežojumiDetalizētas atskaites ģenerēšanaApvērstā inženierija (Reverse Engineering)Diagrammu kā grafisko attēlu saglabāšanaSolis-pa-solim vedņiModeļu salīdzināšanas iespējaRīka saprotama dokumentācija (Help)Savienojamība ar citu Quest

programmatūruRīka salīdzinoši neliela cena (USD 479,-)

Neskatoties uz augstāk aprakstītiem trūkumiem kopumā var pateikt, ka Toad Data Modeler ir labs rīks ar kura palīdzību var ātri izprojektēt dažādas informācijas sistēmas. Protams, ka daudzos gadījumos rīka intelekts nesakrīt ar cilvēka intelektu, līdz ar ko pēc visam transformācijām daudz ko jāpārbauda un jālabo ar rokām. Bet minētais trūkums raksturīgs praktiski visiem līdzīgam CASE rīkiem neatkarīgi no to cenas.

Skatoties nākotnē, ceramies, ka šī rīka turpmāka attīstība dot mums iespēju dabūt rokā jaudīgo instrumentu informācijas sistēmas projektēšanai ar kura palīdzību var viegli, ātri un bez kļūdām izprojektēt nepieciešamo datu bāzi.

79

LITERATŪRAS SARAKSTS

1. Toad Data Modeler v3.5.10.4 dokumentācija;2. DB5 kursa „Informācijas sistēmas un CASE rīki” lekciju konspekti un izdalītais mācību

materiāls, prof. J.Eiduks, RTU, 2010;3. Internets - http://www.toadsoft.com/toaddm/toad_data_modeler.htm;4. Internets - http://www.quest.com/Toad-Data-Modeler;5. Internets - http://en.wikipedia.org/wiki/Toad_Data_Moeler.

80

PIELIKUMS

SQL koda skripts datu bāzes izveidošanai

/*Created: 12.05.2010Modified: 13.05.2010Project: VIDModel: Physical modelCompany: RTU, RDMI0 1.kurss, 2.grupaAuthor: S.Provorovs, V.Starovoitovs, V.Novoselovs Version: 1.0Database: Oracle 10g*/

-- Create tables section -------------------------------------------------

-- Table VID

CREATE TABLE "VID"( "Reg_Nr" Integer, "Adrese" Varchar2(30 ), "Talrunis" Varchar2(30 ), "E-pasts" Varchar2(30 ))/

-- Table Darba_nemejs

CREATE TABLE "Darba_nemejs"( "DN_ID" Integer NOT NULL, "Vards" Varchar2(30 ), "Uzvards" Varchar2(30 ), "Pers_kods" Varchar2(12 ), "E-pasts" Varchar2(30 ), "Status" Varchar2(30 ), "P_ID" Integer NOT NULL, "D_ID" Integer NOT NULL, "N_ID" Integer NOT NULL, "S_ID" Integer NOT NULL, "Darba_Liguma_Nr" Varchar2(30 ), "Darba_Liguma_datums" Date, "Darba_Liguma_termins" Date, "Dienesta_pakape" Varchar2(30 ))/

-- Add keys for table Darba_nemejs

ALTER TABLE "Darba_nemejs" ADD CONSTRAINT "Unique_Identifier13" PRIMARY KEY ("DN_ID")/

-- Table Parvalde

CREATE TABLE "Parvalde"( "P_ID" Integer NOT NULL, "Nosaukums" Varchar2(30 ), "Adrese" Varchar2(30 ), "Talrunis" Varchar2(30 ),

81

"E-pasts" Varchar2(30 ))/

-- Add keys for table Parvalde

ALTER TABLE "Parvalde" ADD CONSTRAINT "Unique_Identifier2" PRIMARY KEY ("P_ID")/

-- Table Eka

CREATE TABLE "Eka"( "E_ID" Integer NOT NULL, "Adrese" Varchar2(30 ), "Pilseta" Varchar2(30 ), "Pasta_kods" Varchar2(30 ))/

-- Add keys for table Eka

ALTER TABLE "Eka" ADD CONSTRAINT "Unique_Identifier18" PRIMARY KEY ("E_ID")/

-- Table Dala

CREATE TABLE "Dala"( "D_ID" Integer NOT NULL, "Nosaukums" Varchar2(30 ), "P_ID" Integer NOT NULL)/

-- Add keys for table Dala

ALTER TABLE "Dala" ADD CONSTRAINT "Unique_Identifier3" PRIMARY KEY ("D_ID")/

-- Table Nodala

CREATE TABLE "Nodala"( "N_ID" Integer NOT NULL, "Nosaukums" Varchar2(30 ), "D_ID" Integer NOT NULL)/

-- Add keys for table Nodala

ALTER TABLE "Nodala" ADD CONSTRAINT "Unique_Identifier4" PRIMARY KEY ("N_ID")/

-- Table Sektors

CREATE TABLE "Sektors"( "S_ID" Integer NOT NULL, "Nosaukums" Varchar2(30 ), "N_ID" Integer NOT NULL)/

-- Add keys for table Sektors

82

ALTER TABLE "Sektors" ADD CONSTRAINT "Unique_Identifier5" PRIMARY KEY ("S_ID")/

-- Table Jur_persona

CREATE TABLE "Jur_persona"( "Klienta_status" Varchar2(30 ), "Licences_Nr" Varchar2(30 ), "Reg_Nr" Integer NOT NULL, "Nosaukums" Varchar2(30 ), "Adrese" Varchar2(30 ), "Talrunis" Varchar2(30 ), "E-pasts" Varchar2(30 ))/

-- Add keys for table Jur_persona

ALTER TABLE "Jur_persona" ADD CONSTRAINT "Unique_Identifier9" PRIMARY KEY ("Reg_Nr")/

-- Create triggers for table Jur_persona

CREATE TRIGGER "Inheritance_Jur_persona" BEFORE INSERT ON "Jur_persona" FOR EACH ROW declare numrows integer;begin select count(*) into numrows from Fiz_persona where Reg_Nr = :NEW.Reg_Nr; if (numrows > 0) then RAISE_APPLICATION_ERROR(-20001,'Exlusive Inheritance violation with table Fiz_persona. Cannot insert.'); end if;end;/

-- Table Fiz_persona

CREATE TABLE "Fiz_persona"( "Klienta_status" Varchar2(30 ), "Licences_Nr" Varchar2(30 ), "Reg_Nr" Integer NOT NULL, "Pers_kods" Varchar2(12 ), "Vards" Varchar2(30 ), "Uzvards" Varchar2(30 ), "Adrese" Varchar2(30 ), "Talrunis" Varchar2(30 ), "E-pasts" Integer)/

-- Add keys for table Fiz_persona

ALTER TABLE "Fiz_persona" ADD CONSTRAINT "Unique_Identifier12" PRIMARY KEY ("Reg_Nr")/

83

-- Create triggers for table Fiz_persona

CREATE TRIGGER "Inheritance_Fiz_persona" BEFORE INSERT ON "Fiz_persona" FOR EACH ROW declare numrows integer;begin select count(*) into numrows from Jur_persona where Reg_Nr = :NEW.Reg_Nr; if (numrows > 0) then RAISE_APPLICATION_ERROR(-20001,'Exlusive Inheritance violation with table Jur_persona. Cannot insert.'); end if;end;/

-- Table Amats

CREATE TABLE "Amats"( "Amata_kods" Integer NOT NULL, "Nosaukums" Varchar2(30 ), "DN_ID" Integer NOT NULL)/

-- Add keys for table Amats

ALTER TABLE "Amats" ADD CONSTRAINT "Unique_Identifier16" PRIMARY KEY ("Amata_kods","DN_ID")/

-- Table Atalgojums

CREATE TABLE "Atalgojums"( "Alga" Number(10,2), "Piemaksa" Number(10,2), "Premija" Number(10,2), "DN_ID" Integer NOT NULL)/

-- Add keys for table Atalgojums

ALTER TABLE "Atalgojums" ADD CONSTRAINT "Unique_Identifier17" PRIMARY KEY ("DN_ID")/

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

CREATE INDEX "IX_Relationship1" ON "Parvalde" () /ALTER TABLE "Parvalde" ADD CONSTRAINT "Relationship1" FOREIGN KEY () REFERENCES "VID" ()/

CREATE INDEX "IX_Relationship2" ON "Dala" ("P_ID") /ALTER TABLE "Dala" ADD CONSTRAINT "Relationship2" FOREIGN KEY ("P_ID") REFERENCES "Parvalde" ("P_ID")/

84

CREATE INDEX "IX_Relationship3" ON "Nodala" ("D_ID") /ALTER TABLE "Nodala" ADD CONSTRAINT "Relationship3" FOREIGN KEY ("D_ID") REFERENCES "Dala" ("D_ID")/

CREATE INDEX "IX_Relationship4" ON "Sektors" ("N_ID") /ALTER TABLE "Sektors" ADD CONSTRAINT "Relationship4" FOREIGN KEY ("N_ID") REFERENCES "Nodala" ("N_ID")/

CREATE INDEX "IX_Relationship5_1" ON "Jur_persona" () /ALTER TABLE "Jur_persona" ADD CONSTRAINT "Relationship5_1" FOREIGN KEY () REFERENCES "VID" ()/

CREATE INDEX "IX_Relationship5_2" ON "Fiz_persona" () /ALTER TABLE "Fiz_persona" ADD CONSTRAINT "Relationship5_2" FOREIGN KEY () REFERENCES "VID" ()/

CREATE INDEX "IX_Saite_P" ON "Darba_nemejs" ("P_ID") /ALTER TABLE "Darba_nemejs" ADD CONSTRAINT "Saite_P" FOREIGN KEY ("P_ID") REFERENCES "Parvalde" ("P_ID")/

CREATE INDEX "IX_Saite_D" ON "Darba_nemejs" ("D_ID") /ALTER TABLE "Darba_nemejs" ADD CONSTRAINT "Saite_D" FOREIGN KEY ("D_ID") REFERENCES "Dala" ("D_ID")/

CREATE INDEX "IX_Saite_N" ON "Darba_nemejs" ("N_ID") /ALTER TABLE "Darba_nemejs" ADD CONSTRAINT "Saite_N" FOREIGN KEY ("N_ID") REFERENCES "Nodala" ("N_ID")/

CREATE INDEX "IX_Saite_S" ON "Darba_nemejs" ("S_ID") /ALTER TABLE "Darba_nemejs" ADD CONSTRAINT "Saite_S" FOREIGN KEY ("S_ID") REFERENCES "Sektors" ("S_ID")/

CREATE INDEX "IX_Saite_Amats" ON "Amats" ("DN_ID") /ALTER TABLE "Amats" ADD CONSTRAINT "Saite_Amats" FOREIGN KEY ("DN_ID") REFERENCES "Darba_nemejs" ("DN_ID")/

CREATE INDEX "IX_Saite_Alga" ON "Atalgojums" ("DN_ID") /ALTER TABLE "Atalgojums" ADD CONSTRAINT "Saite_Alga" FOREIGN KEY ("DN_ID") REFERENCES "Darba_nemejs" ("DN_ID")/

85