anotĀcija · web view8.4.fiziskā modeļa atskaites ģenerēšana pdf formātā72 9.sql koda...

Rīgas Tehniskā universitāteDatorzinātnes un Informācijas tehnoloģiju fakultāte

Informācijas tehnoloģijas institūts

„Toad Data Modeler”

2.Praktiskais darbsPriekšmetā

Informācijas sistēmas un CASE rīki

Izstrādāja: Viktorija RaizinaJeļena Havkunova

Liāna Natenadze1DMIO-2 (ITI)

Rīga, 2009

ANOTĀCIJA

Darbā ir dots datu bāzes „Universitāte” izprojektēts piemērs ar datu bāzu 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 sadalīts divās daļās. Pirmā no tām ir teorētiskā daļa, kurā tiek apskatīts un izpētīts izmantojamais CASE rīks, tā iespējas un funkcionalitāte. Savukārt, otrās daļas pamatā ir pašas datu bāzes realizācija ar rīka palīdzību. Tā pat teorētiskajā daļā ir apskatīti vairāki piemēri tām rīka iespējām, kuras praktiskajā darba daļā netiks izpētītas sīkāk (apvērstā inženierija, versiju menedžeris, uzdevumu saraksts, sinhronizācija, automātiskā izkārtošana). Darba izpildes gaitā tiek izveidots loģiskais modelis, kurš pēc īpašībām ir vienlaicīgi 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 datu bāzes modelis. Pēc fiziskā modeļa izpētes, tas tiek papildināts ar skatu, procedūru, virkni un sinonīmu. 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. Salīdzināšanas rezultātā tiek atrastas lielas atšķirības. Gan fiziskajam, gan loģiskajam modelim uzģenerētas atskaites un visbeidzot ir iegūts ari SQL kods izveidotajai datu bāzei.

Izstrādātais darbs ir izpildīts grupā, kas sastāv no trim cilvēkiem. Tas pilnībā apmierina uzdevuma nosacījumus. Visa darba gaita ir detalizēti vizualizēta, labākai darba realizēšanas secības izprašanai.

Darba aprakstā ir 156 attēli, 3 tabulas, 10 nodaļas, secinājumi, saturs, 1 pielikums un informācijas avoti. Kopumā darbs ir izklāstīts 93 lappusēs.

2

SATURS

UZDEVUMA NOSTĀDNE...............................................................................................................................................5TEORĒTISKĀ UN APRAKSTOŠĀ DAĻA............................................................................................................................61. СASE rīks: definīcija, raksturojums un izmantošana...........................................................................................62. TOAD™ DATA MODELER.....................................................................................................................................73. TOAD™ DATA MODELER INSTALĀCIJA PA SOĻIEM..............................................................................................84. KOPĒJAIS TOAD DATA MODELER APSKATS.......................................................................................................13

4.1. Rīka instrumentārijs................................................................................................................................134.1.1. Lietotāja saskarne...............................................................................................................................134.1.2. Rīku josla............................................................................................................................................13

4.1.2.1. Lietotnes rīks.............................................................................................................................134.1.2.2. Designer-instrumentārijs fiziskajam modelim...........................................................................144.1.2.3. Designer-instrumentārijs loģiskajam modelim..........................................................................144.1.2.4. Designer-instrumentārijs meta modelim..................................................................................144.1.2.5. Darba telpa...............................................................................................................................15

4.2. Modeļa priekšstata līmeņi.......................................................................................................................154.3. Tehniskās prasības un cena.....................................................................................................................154.4. Atbalstīto datu bāžu saraksts..................................................................................................................164.5. Diagrammu attēlošanas līmeņi................................................................................................................164.6. Notācijas.................................................................................................................................................17

5. TDM MODEĻI....................................................................................................................................................225.1. Loģiskais modelis un ar to saistīta funkcionalitāte (LER).........................................................................22

5.1.1. Loģiskā modeļa veidošana..................................................................................................................225.1.2. Loģiskā modeļa verifikācija.................................................................................................................225.1.3. Atskaišu veidošana.............................................................................................................................225.1.4. Modeļu salīdzināšana.........................................................................................................................235.1.5. Loģiskā modeļa atjaunošana un apvienošana....................................................................................235.1.6. Loģiskā modeļa transformācija uz fizisko (LER ->PER)........................................................................24

5.2. Fiziskais modelis un ar to saistīta funkcionalitāte...................................................................................245.2.1. Fiziskā modeļa veidošana...................................................................................................................245.2.2. Fiziskā modeļa verifikācija..................................................................................................................265.2.3. Dokumentācija...................................................................................................................................265.2.4. Skripta ģenerēšana.............................................................................................................................275.2.5. Fiziskā modeļa transformācija uz fizisko un loģisko (PER ->PER,LER)..................................................275.2.6. Reverse engineering...........................................................................................................................27

5.3. Parējās funkcijas (papildus iespējas).......................................................................................................325.3.1. Automātiskā modeļa izkārtošana.......................................................................................................325.3.2. Sinhronizācija.....................................................................................................................................325.3.3. Version Manager................................................................................................................................335.3.4. To-Do list............................................................................................................................................33

PRAKTISKĀ UN REALIZĒJOŠĀ DAĻA............................................................................................................................366. KONCEPTUĀLAIS MODELIS VISIO VIDĒ.............................................................................................................367. LOĢISKAIS MODELIS.........................................................................................................................................37

7.1. Modeļa izveide........................................................................................................................................377.1.1. Entītiju, atribūtu un primāro atslēgu izveide......................................................................................377.1.2. Binārās saites izveide..........................................................................................................................417.1.3. Mantošanas realizācija.......................................................................................................................437.1.4. Unārās saites izveide..........................................................................................................................457.1.5. Vājās realitātes realizācija..................................................................................................................457.1.6. Saites N:M izveide..............................................................................................................................467.1.7. Ternārās saites izveide.......................................................................................................................467.1.8. Kategoriju izveide...............................................................................................................................47

7.2. Loģiskā modeļa verifikācija.....................................................................................................................497.3. Kopējais modelis.....................................................................................................................................517.4. Loģiskā modeļa atskaites ģenerēšana HTML formātā.............................................................................53

8. FIZISKAIS MODELIS...........................................................................................................................................568.1. Atsevišķu elementu transformācija.........................................................................................................56

3

8.1.1. Mantošana.........................................................................................................................................568.1.2. Unāra saite.........................................................................................................................................578.1.3. Vājā realitāte......................................................................................................................................588.1.4. Saite N:M............................................................................................................................................598.1.5. Ternārā saite......................................................................................................................................61

8.2. Kopējā modeļa transformācija................................................................................................................638.3. Fiziskā modeļa papildināšana..................................................................................................................68

8.3.1. Virknes pievienošana..........................................................................................................................698.3.2. Procedūras pievienošana...................................................................................................................708.3.3. Sinonīma pievienošana.......................................................................................................................708.3.4. Skata pievienošana.............................................................................................................................71

8.4. Fiziskā modeļa atskaites ģenerēšana PDF formātā..................................................................................729. SQL KODA ĢENERĒŠANA..................................................................................................................................7510. LOĢISKĀ UN FIZISKĀ MODEĻU SALĪDZINĀŠANA...............................................................................................81SUBJEKTĪVA KRITIKA...................................................................................................................................................84SECINĀJUMI...............................................................................................................................................................86INFORMĀCIJAS AVOTI................................................................................................................................................86PIELIKUMI..................................................................................................................................................................911.pielikums. Uzģenerētā SQL koda pirmteksts...........................................................................................................91

4

UZDEVUMA NOSTĀDNE

1. Jāizpēta CASE rīkā realizējamie modeļi un to, kā tie saistīti sava starpā: konceptuālais; loģiskais (Dati); fiziskais;

2. Jāizpēta apzīmējumiem izmantojamās notācijas;3. Jāsniedz piemēri:

Konceptuālais Loģiskais Fiziskais modelis ar pārveidojumiem;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.

5

TEORĒTISKĀ UN APRAKSTOŠĀ DAĻA1. ASE RĪKS: DEFINĪCIJA, RAKSTUROJUMS UNС

IZMANTOŠANA

CASE (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.

Ņ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;

6

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 ER diagrammas vairākām datu bāzes sistēmām (Oracle, MS SQL, DB2, MySQL,

PostgreSQL, u.t.t.); 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.

© 2009 Quest Software, Inc.

7

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

8

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.

9

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

10

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

11

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

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ā

Toad Data Modeler ”Trial” versijas ierobežojumi ir sekojoši:Ierobežojumi ir ne tikai izmantošanas ilgums – 15 dienas, bet arī modeļa lielums – modelī

var būt ne vairāk kā 25 entītijas. Nedrīkst saglabāt, drukāt, eksportēt modeli grafiskā datnē, ģenerēt atskaiti (iekļaujot sevī vecāko atskaiti un XSL transformācijas atskaiti), ģenerēt SQL/DDL skriptus, ja modelī ir vairāk nekā 25 entītijas (skat. 3.11.att.).

3.11.att. Izmēģinājuma versijas ierobežojumu paziņojums

Ierobežojumi attiecas gan uz fizisko, gan uz loģisko modeli.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.

12

4. KOPĒJAIS TOAD DATA MODELER APSKATS

4.1. Rīka instrumentārijs

4.1.1. Lietotā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.1.att.).

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

4.1.2. Rīku josla

4.1.2.1. Lietotnes rīks

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

4.1.2.1.1.att. Lietotnes rīks

13

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

4.1.2.2. Designer-instrumentārijs fiziskajam modelim

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

4.1.2.2.1.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ī

4.1.2.3. 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.2.3.1.att.).

4.1.2.3.1.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ī

4.1.2.4. Designer-instrumentārijs meta modelim

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

4.1.2.4.1.att. Designer-instrumentārijs meta modelim

14

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ī

4.1.2.5. Darba telpa

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

4.1.2.5.1.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ņi

Toad 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 cena

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

TDM tehniskās prasībasMinimālās

prasības Optimālās prasības

Platforma Pentium IV Pentium dual coreAtmiņa 256 MB 1 GBVieta uz cietā diska 100 MB 200 MBOperētājsistēma Windows

2000/XP/VistaWindows 2000/XP/Vista

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ā).

15

4.4. Atbalstīto datu bāžu saraksts

Viena 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 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

4.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 (skat. 4.5.1.att.). Ka arī var to izvēlēties no galvenās izvēlnes ViewDisplay 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ācijas

Modeļu veidošanai Toad Data Modeler rīkā ir iespējams izmantot divas notācijas: IDEF1X un IE (Information Engineering). IDEF1X metodoloģija tika

16

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

17

2.tabulaNosacī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 : 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.

18

Iekļaujoša kategoriju hierarhija.

Nepilnā kategoriju hierarhija

19

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.7.1.att.).

4.7.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.7.2.att.).

4.7.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.7.3.att.).

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

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

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

21

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

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

PIEZĪME: Mūsu darba izpildei tiks izmantota IE notācija.

22

5. TDM MODEĻI

5.1. Loģiskais modelis un ar to saistīta funkcionalitāte (LER)

5.1.1. Loģiskā 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ā.

5.1.2. 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.2.1.attēlā.

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

5.1.3. 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.3.1.att.).

23

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

5.1.4. 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.4.1.att.).

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

5.1.5. 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.5.1.attēlā).

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

24

5.1.6. 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.6.1.att. kā arī iepriekš attēlotais 5.1.5.1.att.).

5.1.6.1.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āte

5.2.1. Fiziskā 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.1.att.).

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

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

25

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.1.2.att.).

5.2.1.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.1.3.att.).

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

26

5.2.2. 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.2.1.att.).

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

5.2.3. 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.3.1.att.).

5.2.3.1.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.3.2.att.).

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

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

5.2.3.3.att. XSD fails fiziskajam modelim

5.2.4. 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 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.4.1.attēlā).

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

5.2.5. 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.5.1.attēlā.

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

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

28

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.6.1.att.).

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

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

5.2.6.2.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.6.3.att.).

29

5.2.6.3.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.6.4.att.).

5.2.6.4.att. Savienojuma konfigurācija

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

30

5.2.6.5.att. Datu migrātora izvēle

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

5.2.6.6.att. Pārveidojamo objektu izvēle

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

31

5.2.6.7.att. Pseidonīma saglabāšana

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

5.2.6.8.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.6.9.att.).

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

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.6.10.attēlā.

32

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

5.3. Parējās funkcijas (papildus iespējas)

5.3.1. 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.1.attēlā.

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

5.3.2. Sinhronizācija

Toad Data Modeler ļauj sinhronizēt:

datu bāzi un Toad Data Modeler modeli; fizisko un loģisko modeli.

33

5.3.3. 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.3.1.att.).

5.3.3.1.att. Jauna projekta izveidošana

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

5.3.3.2.att. Modeļa pievienošana projektam

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.

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

34

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.1.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.1.att. Loģiskā modeļa uzdevumi

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

5.3.4.2.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:

35

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.4.3.att.).

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

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

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

36

PRAKTISKĀ UN REALIZĒJOŠĀ DAĻA6. KONCEPTUĀLAIS MODELIS VISIO VIDĒ

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, kas tika aprakstīts PowerDesigner15.doc, kurš apraksta universitātes struktūru. Tā kā Toad Data Modeler nav iespējas izveidot konceptuālo modeli, tad to realizējam Visio vidē, balstoties uz iepriekš minēta piemēra struktūras (skat. 6.1.att.).

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

Izveidoto modeli sīki neaprakstīsim vairāku iemeslu dēļ. Pirmkārt, mums galvenais ir izpētīt rīka iespējas; otrkārt, universitātes struktūra ir diezgan labi saprotama katram studentam un pasniedzējam. Līdz ar to mēs uzreiz sāksim ar šī modeļa realizāciju.

37

7. LOĢISKAIS MODELIS

7.1. Modeļa izveide

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

Tātad, balstoties uz izveidoto konceptuālo modeli, var sākt realizēt loģisko modeli Toad Data Modeler vidē.

Sākot darbu, izvēlēsimies galvenajā izvēlnē FileNew 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.1.att.).

7.1.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.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.1.2.att. Entītijas izveidošana

38

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

7.1.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.1.4.att.).

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

Veidojam attiecīgus atribūtus. Sāksim ar F_Num 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.1.5.att.)

39

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

Nākamais atribūts ir F_Nos, t.i. Fakultātes nosaukums. izvēlēsimies datu tipu Varchar un atribūta garumu līdz 50 simboliem (jāpietiek priekš Fakultātes nosaukuma).

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.1.6.att.).

7.1.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.1.7.att.). Vienam no atribūtiem jābūt primārai atslēgai, mūsu gadījumā tas ir atribūts F_Num.

40

7.1.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.1.8.att.).

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

41

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

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

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.

7.1.2. 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 Fakultāte un Institūts (skat. 7.1.2.1.att.).

7.1.2.1.att. Konceptuālā modeļa binārās saites struktūra

Tagad izvēlamies saiti no rīku joslas Objects Relationship vai no rīka instrumentu paneļa

(skat. 7.1.2.2.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.

7.1.2.2.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.2.3.att.).

42

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

Izvelēsimies ārējas atslēgas nosaukumu F_Num laukam ForeignUniqueIdentifier. Nosauksim saiti „Ir”, jo attiecība starp „Vecāku” un „Bērnu” ir sekojoša: Fakultātei ir Institūts.

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

7.1.2.4.att. Saites veida izvēle

43

7.1.3. Mantošanas realizācija

Nākamajā solī izveidosim mantošanas attiecības starp trim realitātēm, kur Cilvēks ir Parent entītija, bet Students un Pasniedzējs 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.3.1.att.).

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

Ir arī iespēja izmantot rīka instrumentu joslā mantošanas apzīmējumu un nospiest sākumā uz vecāka entītijas lauku, t.i. Cilvēks, ar peles kreiso taustiņu. Pēc tam jāspiež uz bērna entītijas lauku, piem. Students. Lai pievienotu otro bērnu, atkal rīku joslā izvelēsimies mantošanas 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. Pasniedzējs.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.3.2.att.).

7.1.3.2.att. Mantošanas tipa izvēle

44

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.3.3.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.3.3.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 Pasniedzējs, Students un vecāku realitātes Cilvēks (skat. 7.1.3.4.att.).

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

Tātad, realizējot šo struktūru ar Toad Data Modeler rīka palīdzību, šī struktūra izskatās diezgan līdzīgi (skat. 7.1.3.5.att.).

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

45

7.1.4. Unārās saites izveide

Tagad realizēsim unāro saiti. Izmantojot saites instrumentu, nospiedīsim uz vienas un tās pašas entītijas divas reizes. Tā pat uzstādīsim saitei noteiktus parametrus.

Tātad, mūsu realizējamā saite sastāv no realitātes Students saites pašai uz sevi (skat. 7.1.4.1.att.).

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

Realizēto struktūru ar CASE rīka palīdzību var aplūkot 7.1.4.2.attēlā.

7.1.4.2.att. Realizētā unārās saites struktūra

7.1.5. Vājās realitātes realizācija

Vāja realitāte loģiskajā modelī ir realizējama realitātei Atzīme kā atkarīgai no realitātēm Students un Pasniedzējs (skat. 7.1.5.1.att.).

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


7.1.5.2.att. Realizētā vājās realitātes struktūra

46

7.1.6. Saites N:M izveide

Mūsu 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” (skat. 7.1.6.1.att.).

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


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

7.1.7. Ternārās saites izveide

Mūsu modelī ternārā saite ir starp realitātēm „Atzīme” un „Mācību priekšmets” un „Students” (skat. 7.1.7.1.att.).

47

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


7.1.7.2.att. Realizētās ternārās saites struktūra

Ternāro saiti mēs realizējām ar asociācijas tabulas palīdzību 9Studenta_Atz_Saraksts), kura savā starpā savieno visas realitātes

7.1.8. Kategoriju izveide

Tagad mēģināsim izveidot kategorijas tām entītijām, kas ir loģiski saistītas savā starpā. Izdalīsim kategoriju Personas, kurā attiecīgi atradīsies visas entītijas, kas būtībā atrodas mantošanās attiecībās. Lai to realizētu, atveram entītijas Cilvēks īpašības, un galvenajā cilnē izvēlāmies kategoriju. Tā kā kategoriju mēs vēl nebijām definējuši, veidosim to tagad (skat. 7.1.8.1.att.).

48

7.1.8.1.att. Kategoriju izveides logs

Kā jau tika minēts, kategorijas nosaukums ir Personas. Izvēlēsimies minētajai kategorijai zaļo krāsu. To pašu kategoriju, tādā pašā veidā definējam entītijām Students un Pasniedzējs, taču te jau no kategoriju saraksta būs jāizvēlas jau eksistējošā kategorija. Rezultātā, 7.1.8.2.attēlā varam aplūkot, ka kategorijas entītijas ir vienā krāsā.

7.1.8.2.att. Vienas kategorijas pārstāvju entītijas(1)

Tādā pašā veidā izveidosim vēl vienu kategoriju, kas sauksies UniversitatesAdministracija, un tajā ievietosim sekojošas realitātes: Fakultāte, Institūts un Katedra (skat. 7.1.8.2.att.).

7.1.8.2.att. Vienas kategorijas pārstāvju entītijas (2)

49

Darba telpā varam ievietot arī „leģendu” ar kategoriju nosaukumiem, nospiežot uz ikonas rīku joslā. Darba telpā parādās taisnstūris ar darba telpā eksistējošām kategorijām (skat. 7.1.8.3.att.).

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

Tātad, tādā veidā var grafiski izdalīt loģiski saistītas realitātes, tas ir uzskatami un katrā ziņā grafiski ar to palīdzību varētu realizēt superrealitāšu saites.

Tagad, kad modelis tiek izveidots līdz galam, visas entītijas un saites ir definētas, varam pāriet pie nākama soļa – modeļa verifikācijas, t.i. sistēmas pārbaudes, 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.

Ir jāpiezīmē, kā izveidojot loģisko modeli, mēs secinājām, kā principā tas pēc būtības ir gan konceptuālais, gan loģiskais modelis (pēc Toad Data Modeler izstrādātāju viedokļa). Uz to liecina sekojošie fakti:

tajā nevar realizēt skatus, kā to var darīt loģiskajā modelī; tajā var grafiski realizēt mantošanu, kā tas ir konceptuālajā modelī; tajā entītijas ir nevis realitātes, bet jau tabulas, kā tas ir loģiskajā modelī; ārējās atslēgas netiek attēlotas, kā tas ir loģiskajā modelī.

7.2. Loģiskā modeļa verifikācija

Loģiskā modeļa verifikāciju jeb pārbaudi var veikt galvenajā izvēlnē izvēloties ModelVerifyModel (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.).

50

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.

Piemēram, mēs, modeļa veidošanas gaitā, nejauši izveidojām vienādus saišu nosaukumus. Līdz ar to, mums tika paziņots par verifikācijas kļūdām (skat. 7.2.3.att.).

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

Tātad, mūsu modelī tika atrastas divas kļūdas. Pēc kļūdu labošanas, verifikācijas pārbaude tika atkārtoti palaista. Palika tikai brīdinājumi (skat. 7.2.4.att.).


Smalki izlasījām brīdinājumus, un mēģinājām tos novērst. Visbeidzot panācām to, ka tiek izlabotas gan kļūdas, gan brīdinājumi un mūsu modelis pēc verifikācijas ir pareizs. Kļūdu skaits ir 0, brīdinājumu skaits ir 0. (skat. 7.2.5.att.).

51


7.3. Kopējais modelis

Tātad, tagad mums ir izveidots loģiskais modelis mūsu izvēlētajai priekšmetiskai videi – Universitāte (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.).

52

7.3.2.att. Ar Toad Data Modeler izveidotais Loģiskais modelis „Universitāte”

53

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

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

54

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 un 7.4.8.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, 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.

55

7.4.6.att. Atskaites ER diagramma

7.4.7.att. Atskaites informācija par entītiju „Katedra”

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

56

8. FIZISKAIS MODELIS

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 Model->Model Conversion,

ModelMerge... (skat. 8.1.att.), jeb rīkjoslā jānospiež uz elementu .

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

Tā kā mēs transformējam katru struktūru atsevišķi, tad iepriekšējās transformācijas katrā no jaunajām struktūrām nebūs redzamas.

8.1. Atsevišķu elementu transformācija

8.1.1. Mantošana

Apskatīsim vienu no interesantākajām daļām, t.i. – mantošanas transformāciju. Kā varam atcerēties, tad mantošanas realizācijā loģiskajā modelī mums piedalījās 3 entītijas – „Cilvēks” kā „vecāku” realitāte un divas bērnu realitātes „Students” un „Pasniedzējs” (skat. 8.1.1.1.att.).

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

Tātad, mēs veicam transformāciju no loģiskā modeļa uz fizisko (LERPER). Atvērsies logs, kur ir jāizvēlas fiziskā modeļa tipu (piemērām, mūsu gadījumā Oracle9i)

(skat. 8.1.1.2.att.). Attēlotajā logā ir iespējams ar zilo bultu palīdzību izvēlēties vēlamos elements transformācijai – mantošanas entītijas, pašu mantošanu un izvēlēsimies arī kategoriju „personas”, kurā bija iekļautas minētās entītijas loģiskajā modelī. Pēc tam ir jānospiež poga <Execute>.

57

8.1.1.2.att. Modeļa transformēšanas logs mantošanai

Pēc neilga laika (dažas sekundes), mūsu darba telpā atvērsies papildus cilne, kur būs attēlota transformētā loģiskā modeļa struktūra fiziskajā modelī (skat. 8.1.1.3.att.).

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

Skaidri redzams ir tas, ka mums 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).

Izskatīsim citas struktūras.

8.1.2. Unāra saite

Kā varam atcerēties, tad unārās saites realizācijā loģiskajā modelī mums piedalījās entītija „Students” ar saiti pašai uz sevi (skat. 8.1.2.1.att.).

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

58

Transformācijas logā izvēlamies jau tos elementus, kas attiecas uz jauno transformējamo struktūru. Šeit izvēlamies vēlamo entītiju un saiti, kuru transformēsim (skat. 8.1.2.2.att.).

8.1.2.2.att. Modeļa transformēšanas logs unārai saitei

Mūsu transformētajā fiziskajā modelī parādījās vēlamās struktūras transformācija (skat. 8.1.2.3.att.).

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

Varam pamanīt to, ka divas reizes atkārtoja atribūts S_NUM. Tas nozīmē to, ka viens no tiem ir primārā atslēga, bet otra ir ārējā atslēga. Līdz ar to, viens atribūts atsaucas uz otru.

8.1.3. Vājā realitāte

Vājās realitātes realizācijā loģiskajā modelī mums piedalījās entītijas „Students” un „Pasniedzējs”, no kuriem, savukārt, bija atkarīga vājā realitāte „Atzīme”, jo atzīme pēc savas būtības nav nekas, ja vien students to nenopelna un pasniedzējs to neieliek (skat. 8.1.3.1.att.).

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

Transformācijas logā izvēlamies elementus, kas attiecas uz jauno transformējamo struktūru. Šeit atkal izvēlamies vēlamās entītijas un saites, kuras transformēsim (skat. 8.1.3.2.att.).

59

8.1.3.2.att. Modeļa transformēšanas logs vājai realitātei

Mūsu transformētajā fiziskajā modelī parādījās transformēšanai izvēlētā struktūra (skat. 8.1.3.3.att.).

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

Šeit varam 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īgā vājā.

8.1.4. Saite N:M

Saites N:M loģiskajā modelī mums bija divas. Tajās piedalījās entītijas „Mācību priekšmets” un „Pasniedzējs”, kā arī „Mācību priekšmets” un „Mācību programma”. (skat. 8.1.4.1.att.).

60

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

Transformācijas logā izvēlamies elementus, kas attiecas uz jauno transformējamo struktūru. Šeit atkal izvēlamies vēlamās entītijas un saites, kuras transformēsim (skat. 8.1.4.2.att.).

8.1.4.2.att. Modeļa transformēšanas logs saitēm N:M


61

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

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 ar tabulām „Mācību programma” un „Mācību priekšmets” – starp tām ir izveidojusies un mantojusi primārās atslēgas starptabula „Mācību programmas mācību priekšmets”.

8.1.5. Ternārā saite

Ternārās saites realizācijā loģiskajā modelī mums piedalījās četras entītijas: „Students”, „Atzīme”, „Mācību priekšmets” un „Studenta_Atz_Saraksts”, kas kalpoja par sava veida asociāciju realitāti tabulu savienošanai (skat. 8.1.5.1.att.).

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

Transformācijas logā izvēlamies elementus, kas attiecas uz šo transformējamo struktūru. Šeit atkal izvēlamies vēlamās entītijas un saites, kuras transformēsim (skat. 8.1.5.2.att.).

62

8.1.4.2.att. Modeļa transformēšanas logs saitēm N:M


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

Redzam, ka arī šeit visas ārējās atslēgas ir pārceļojušas vēlamajās tabulās.Gribētu piebilst arī to, ka veicot kopējo modeļa transformāciju, ārējās atslēgas ceļos

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

63

8.2. Kopējā modeļa transformācija

Kopējā loģiskā modeļa transformācija ir veicama ar tādu pašu darbību palīdzību: ir vai nu

jānospiež poga rīkjoslā ikona, vai arī no galvenās izvēlnes jāizvēlas Model->Model Conversion, ModelMerge... Atvērsies dialoga logs Convertor , kur jānorāda Fiziskā modeļa tipu (kurai datu bāzei tas tiek domāts). Mūsu piemērā, tā pat kā iepriekš, mēs izvēlēsimies Oracle9i datu bāzes tipu (skat. 8.2.1.att.).

8.2.1.att. Modeļa transformēšanas logs

Uzreiz pievērsīsim uzmanību tam, ka mēs, transformējot loģisko modeli fiziskajā, gribam transformēt ne tikai saites, realitātes, u.t.t., bet arī atribūtu ierobežojumus (piemēram, Entītijas „Atzīme” atribūta „Atz_Vertiba” var būt robežās no 1 līdz 10). Pēc tam mēs to pārbaudīsim, kad veiksim modeļu salīdzināšanu.

Pēc transformācijas LERPER veiksmīgas paveikšanas, PER modelis ir mantojis ārējās atslēgas, izveidojis starptabulas, u.t.t. (skat. 8.2.2.att.).

64

8.2.2.att. Ar Toad Data Modeler transformētais loģiskais modelis „Universitāte” fiziskajā modelī

66

Pa soļiem izskatīsim kā izskatās Entītijas fiziskajā modelī no „iekšpuses” (skat. 8.2.3.att.).

8.2.3.att. Entītijas „Atzīme” uzstatījumi fiziskajā modelī

Izpētīsim tabulu pa daļām. Tabulā bija tikai viens atribūts (Atz_Vertiba), taču tajā ir imigrējušas vēl 4 ārējās atslēgas (skat. attēla „a)” daļu). Nospiežot uz tabulas divas reizes, mēs redzēsim tabulas galveno cilni, kurā joprojām ir iespējams veikt labojumus (skat. attēla „b)” daļu). Nākošajā cilnī mēs redzam visus atribūtus (skat. attēla „c)” daļu). Šajā vietā, nospiežot uz atribūta „Atz_vertiba” (jo ka atceramies, loģiskajā modelī šim laukam mums ir bijis ierobežojums), atveras logs ar atribūta uzstatījumiem, kurā ierobežojumu cilnī ir redzams ieraksts (skat. attēla „d)” daļu). Uzklikšķinot uz tā divas reizes, atvērsies ierobežojuma uzstatījumu logs (skat. attēla „e)” daļu), kurā ir redzams SQL kods, kurš paziņo mums par to, ka atzīmes vērtība var būt intervālā no 1 līdz 10.

Apskatīsimies arī visas entītijas SQL kodu (skat. 8.2.4.att.). Tajā varam redzēt (un arī manuāli mainīt), ka izveidojas 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.

67

8.2.4.att. Entītijas „Atzīme” SQL kods

Svarīgi piebilst arī to, ka jebkurā fiziskā modeļa vietā mēs varam veikt labojumus – gan nosaukumos, gan ierobežojumos, kā arī pārveidot jebkuru SQL kodu.

Apskatīsimies arī mantošanas realizāciju (skat. 8.2.5.att.).

8.2.5.att. Entītijas „Students” uzstatījumi fiziskajā modelī 68

Arī šeit izpētīsim tabulu „Students” pa daļām. Tabulā bija tikai viens atribūts (S_NUM, kurš definēja arī primāro atslēgu), taču tajā ir imigrējušas vēl 3 ārējās atslēgas (grupas numurs, unārās saites studenta numurs un no mantošanas iegūtais studenta numurs kā unārās saites studenta numurs) un vēl viena ir nākusi kā primārā atslēga no mantošanas realizācijas ar diviem papildus atribūtiem (STU_pers_kods, vards un uzvards)(skat. attēla „a)” daļu). Nospiežot uz tabulas divas reizes, mēs redzēsim tabulas galveno cilni, kurā joprojām ir iespējams veikt labojumus, piemērām, nomainīt kategoriju (skat. attēla „b)” daļu). Nākošajā cilnī mēs redzam visus atribūtus (skat. attēla „c)” daļu). Pāriesim vēl pie cita cilņa – TRIGGERS (skat. attēla „d)” daļu). Šajā vietā, ir redzams, ka mums automātiski ir izveidojies trigeris „ InharitanceStudents”, kurš jau pēc sava nosaukuma liecina par to, ka tas ir izveidojies mantošanas transformācijas gaitā. Uzklikšķinot uz šī nosaukuma divas reizes, mēs nonāksim pie trigera opcijām (skat. attēla „e)” daļu), kur varam redzēt trigera īpašības (redzam, ka trigeris izpildās PIRMS-IEVADES (Before- insert) operācijas tabulā). Trigera īpašību nākošajā cilnī mēs varam aplūkot arī trigera SQL kodu (skat. attēla „f)” daļu). Pēc attēlotā koda varam spriest, ka trigeris pirms jauna ieraksta ievades tabulā „Students” pārbauda vai tāds pats personas kods jau neeksistē tabulā „Pasniedzējs”, jo tā ir unikāla vērtība, kura ir kā primārā atslēga migrējusi no „vecāku” tabulas „Cilvēks”. Līdz ar to, ja ievadāmais personas kods jau eksistē otrajā tabulā, tad tiks izvadīts paziņojums par ievades kļūdu.

Apskatīsimies arī visas entītijas „Students” SQL kodu (skat. 8.2.6.att.). Tajā varam redzēt (un arī manuāli mainīt), ka izveidojas tabula (definējot arī primārās atslēgas). Tā pat visi pārējie atribūti ir pieņēmuši savus vēl loģiskajā modelī piešķirtos tipus. Bez tam arī šeit mēs redzam, ka papildus tiek pievienots arī minētais trigeris.

8.2.6.att. Entītijas „Students” SQL kods

Līdzīgā veidā ir transformējušās arī citas entītijas. Šajā darba sadaļā tika apskatīti svarīgākie un interesantākie transformācijas gadījumi.

Tagad pāriesim pie mūsu fiziskā modeļa papildināšanas.

69

8.3. Fiziskā modeļa papildināšana

Kad mūsu fiziskais modelis ir transformēts, mēs varam to pielabot un pievienot tajā visu kas ir nepieciešams, piemērām, skatus (vai materializētus skatus), trigerus, ierobežojumus, glabājamas procedūras, virknes, sinonīmus, procedūru pakotnes, funkcijas, u.t.t.

Papildināt fizisko modeli Toad Data Modeler vidē var vairākos veidos:1) Katras entītijas opcijās ir iespējams pievienot trigerus (skat. 8.3.1.att.);2) No galvenās izvēlnes joslas (Model ..) ir iespējams izvēlēties skatu (arī no izvēlnes

Object Views (skat. 8.3.2.att.)), materializētu skatu, funkciju, procedūru, sinonīmu veidošanu (skat. 8.3.3.att.);

3) Fiziskā modeļa pārlūkā izveidot vajadzīgo objektu atbilstošajā mapē (skati, funkcijas, procedūras, virknes, pakotnes, sinonīmi, materializētie skati) (skat. 8.3.4.att.).

8.3.1.att. Objektu pievienošana entītijas opcijās

8.3.2.att. Galvenā izvēlne (Object) 8.3.3.att. Galvenā izvēlne (Model) 8.3.4.att. Modeļa pārlūks

Mūsu darba gaitā mēs izmantosim visus objektu pievienošanas veidus.

70

8.3.1. Virknes pievienošana

Sāksim ar virknes definēšanu tabulai „Fakultātes” (skat. 8.3.1.1.att.). Lai definētu virkni, modeļu pārlūkā, kreisajā pusē, ir jāatrod virkņu mape un tajā ir jāizveido jauna virkne, uz kuras ir jāveic dubults klikšķis. Mums atveras virknes definēšanas logs.

8.3.1.1.att. Virknes izveide

Galvenajā cilnē General mēs definējam virknes nosaukumu, definējam ka virknes pieaugums būs par vienu vienību un virkne sāksies ar „1”. Tā pat norādām, ka tai nebūs ciklu. Uzreiz varam aplūkot virknes SQL kodu cilnē SQL Preview (skat. 8.3.1.2.att.), kurā redzam tos datus, kurus tikko definējām.

8.3.1.2.att. Virknes SQL kods

71

8.3.2. Procedūras pievienošana

Definēt procedūru varam no galvenās izvēlnes izvēloties ModelProcedures.. vai arī tādā pašā veidā, kā ar virknēm, atrodot mapi modeļa pārlūkā un izveidojot tajā jaunu procedūru. Uz jaunas procedūras veicam dubultklikšķi un mums atveras procedūras veidošanas logs, kur galvenajā cilnē dotam procedūrai nosaukumu. Pēc tam cilnē SQL mēs rakstam vaicājumu (nenorādot sākuma rindu par procedūras izveidi – uzreiz procedūras ķermeni) un pēc tam cilnē SQL PREVIEW mēs varam apskatīties kopējo procedūras SQL kodu jau ar sākuma rindiņu. Tas ir tādēļ, ka automātiski jau ir nodefinēta procedūras izveides struktūra (CREATE PROCEDURE „Nosaukums”) (skat. 8.3.2.1.att.). Mūsu procedūra atlasīs studentu vārdus, uzvārdus un grupas numurus.

8.3.2.1.att. Procedūras SQL kods

8.3.3. Sinonīma pievienošana

Tagad pievienosim sinonīmu tabulai Studentu_grupa (skat. 8.3.3.1.att).

8.3.3.1.att. Sinonīma izveide

72

Modeļa pārlūkā atrodam sinonīmu mapi, izveidojam jaunu sinonīmu, uz tā dubultklikšķis un mums atveras sinonīmu veidošanas logs, kurā mēs definējam sinonīma nosaukumu un objektu, kuram tiek veidots sinonīms. Diezgan primitīvs sinonīma veids, bet tomēr, tas ir izveidojams.

8.3.4. Skata pievienošana

Beidzot pievienosim arī skatu, kurš, līdzīgi kā glabājama procedūra, atlasīs studentu datus un atbilstošas grupas datus.

Skata izveidošana ir iespējama no galvenās izvēlnes izvēloties ModelViews.. vai ObjectViews.. un pēc tam uzklikšķinot uz jebkuras darba telpas vietas. Parādās skata ikona, uz kuras ir jāveic dubultklikšķis skata definēšanai. Līdzīgi kā ar procedūru, mēs rakstam tikai vaicājuma tekstu.

Skatu pievienošanas process tapāt kā procedūru definēšanas process ir pusautomātisks. Tas nozīmē to, ka ar roku ir jāievada skata SQL skripts cilnē SQL (skat. 8.3.4.2.att.).

8.3.4.2.att. Skata SQL koda teksts

Neskatoties uz to, ka mēs ievadījām tikai SQL skriptu, izvēloties cilni SQL Preview, mēs varam redzēt, ka SQL skripts ir „pilns”, tas ir tāpēc, ka automātiski jau ir nodefinēta skata izveides struktūra (CREATE VIEW „Nosaukums” AS) (skat. 8.3.4.3.att.).

8.3.4.3.att. Pilnais skata SQL koda teksts

Pēc tam, kad esam definējuši skatu, varam to redzēt arī mūsu fiziskā modeļa darba telpā (skat. 8.2.4.4.att.).

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

73

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

Tagad, kad mēs esam konvertējuši loģisko modeli un ieguvām fizisko modeli, apskatīsim atskaišu ģenerēšana tieši PER (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.4.1.att.).

8.4.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.4.2.att.).

8.4.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.4.3.att.).

8.4.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.4.4.att.). Var pievērsts uzmanību, tam, ka kopējais atskaites lappušu skaits

74

ir 50, kas liecina par ļoti sīku un detalizētu modeļa aprakstu. Piemēru divām lappusēm, kuras detalizēti apraksta Entītiju „Atzīme”, 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.). Svarīgi ir arī tas, ka atskaite ir pilnībā gatava drukai. Pēc tam pāriesim pie atskaišu ģenerēšanas, bet šoreiz jau fiziskajam modelim.

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

75

8.4.5.att. Fiziskā modeļa atskaites piemērs par entītiju „Atzīme”

76

9. SQL KODA ĢENERĒŠANA

Pēc fiziska modeļa koriģēšanas, pāriesim pie SQL koda ģenerēšanas. Izveidosim DDL skriptu. Galvenajā izvēlnē izvelē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

Mums 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.).

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

Tā pat būtu vēlams nākošajā cilnī Detail Settings norādīt to, ka primārās atslēgas mēs vēlamies ģenerēt iekš tabulām, nevis pēc tam. Taču tas nav tik būtiski (skat. 9.3.att.).

77

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

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 9skat. 9.4.att.).

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

78

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 ModelOrder of Generated Objects (skat. 9.6.att.).

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

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.10.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.6.att. Koda ģenerēšanas kārtības izvēle

79

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.7.att.).

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

Tagad apskatīsies noģenerētā SQL koda kvalitāti. Sāksim ar tabulām. Tā kā to ir daudz, tad apskatīsim tikai dažas no tām (skat. 9.8.att.).

9.8.att. Uzģenerētais kods dažām tabulām

Tabulas ir izveidotas visai korekti, ar visiem tipiem, ierobežojumiem un primārām atslēgām. Vienīgais kas trūkst ir ārējo atslēgu definēšana, bet tas ir atsevišķs process, ko apskatīsim vēlāk, jo šo elementu definēšana notiek atsevišķi, pašās beigās.

80

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)

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

Kā var redzēt, mantošanas saite abām tabulām Students un Pasniedzējs 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 personas kods, kas ir unikāla primārā atslēga. Gadījumā, ja tiek ievadīts tāds personas kods, kas jau otrā tabulā eksistē, tad tiek izvadīts kļūdas paziņojums.

Pievērsim uzmanību skata, procedūras, sinonīma un virknes uzģenerētajiem kodiem (skat. 9.11.att.).

81

9.11.att. Uzģenerētais kods skatam, procedūrai, sinonīmam un virknei

Šīs konstrukcijas ir korektas un pareizas, jo gan skata, gan procedūras kodu mēs ievadījām manuāli. Tieši šī pusautomātiskās pieejas dēļ, šajās konstrukcijās varam būt droši.

Sinonīma un virknes izveide fiziskajā modelī arī nebija grūta un mēs varam redzēt, ka abas šīs struktūrās ir korektas.

Tagad atsevišķi izskatīsim to, kā realizējās ārējo atslēgu piesaistīšana uz unārās saites piemēra (skat. 9.12.att.).

9.12.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 (ir korekti definētas atsauces un ārējās atslēgas).

82

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

Divu modeļu salīdzināšanu var veikt, galvenajā izvēlnē izvēloties Model->Compare...(skat. 10.1.att.).

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

Paradīsies dialoga logs, kurā ir iespējams izvēlēties otro modeli, ar kuru mēs salīdzināsim tekošo loģisko modeli. Mūsu gadījumā mēs salīdzināsim loģisko modeli, ar transformēto modeli, kuru mēs ieguvām pēc transformācijas, t.i., salīdzināsim divus modeļus LER un PER (jeb sākumdatus ar beigu datiem) (skat. 10.2.att.).

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

Loga kreisā daļa atbilst LER modelim, bet labā, attiecīgi - PER modelim. Jau šajā logā ir skaidri redzams, piemēram, tas, 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. Bet labajā loga pusē šī entītija neeksistē (skat. attēla „a)” daļu). Tas ir izskaidrojams ar to, ka entītijas atribūti ir pārgājuši pie abiem bērniem ar visu primāro atslēgu.

Tā pat varam redzēt to, ka PER modelī ir parādījušās divas entītijas, kuru nebija loģiskajā modelī (skat. attēla „b)” daļu). Tas ir izskaidrojams ar to, ka loģiskajā modelī bija realizētas N:M saites, kuras pēc transformācijas ir papildinājušās ar šīm starptabulām.

83

Varam arī pamanīt to, ka loģiskajā modelī mums bija realizēta mantošanas struktūra (skat. attēla „c)” daļu), taču fiziskajā modelī šo struktūru mēs neredzam. Tam par iemeslu ir tas, ko mēs jau izpētījām iepriekš – „vecāku” realitātes sadalīšana uz abām „bērnu” realitātēm.

Intereses pēc varam pamēģināt arī transformēt mūsu jau esošo fizisko modeli atpakaļ loģiskajā modelī. To dara ar tādu pašu darbību palīdzību, kā mēs to darījām iepriekš, transformējot LERPER (skat. 10.3.att.).

10.3.att. Fiziskā modeļa transformācija loģiskajā

Apskatīsimies jauno loģisko modeli vizuāli (skat. 10.4.att.). Uzreiz varam pamanīt to, ka ārējās atslēgas atkal ir pazudušas no tabulām. Bez tam, mums ir parādījušās divas pavisam tukšas tabulas, kuras fiziskajā modelī kalpoja kā starptabulas un saturēja tikai ārējās atslēgas.

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

84

Tagad salīdzināsim sākuma modeli LER (kuru izveidojām darba gaitas pašā sākumā) ar to modeli, kuru ieguvām pēc otrās kārtas transformācijas (sākuma LER PER, un pēc tam PERLER2) (skat. 10.5.att.).

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

Varam secināt, ka katru reizi mašīna interpretē transformāciju no savas „pieredzes”, t.i. katru transformāciju veic pēc saviem likumiem. Varam redzēt kā sākuma LER modelis nav vienāds ar beigu LER modeli. Pirmkārt, mums uz visiem laikiem 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 divas tabulas (fiziskajā modelī bija starptabulas), kuras sākuma modelī nav.

Pēc katras transformācija modelis mainās. Nekad nevar iegūt to pašu kas bija iepriekš. Tas ir pārbaudīts praksē, kaut tomēr ir pats par sevi saprotams.

85

SUBJEKTĪVA KRITIKA

Izpētot TDM rīku, mēs mēģinājām atrast rīka priekšrocības un trūkumus (skat. 3.tabulu).3.tabula

Toad Data Modeler plusi un mīnusiPlusi 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ībaMantošanas realizācija trigerī pēc transformācijas Tikai 2 notācijasHelp AutoLayout nepārskatāms izvietojumsModeļu atjaunošana pēc labojumiem Nepārskatāms izkārtojums pēc transformācijasVersiju glabāšana projekta ietvaros Tehniskās prasībasĒrta lietotāju saskarne Var realizēt tikai dažas struktūrasTransformācijas (LERPER; PERLER; PERPER) Trial versijas ierobežojumiSQL skriptsPER modeļa papildināšanaLiels DBVS atbalstsApvērstā inženierijaDiagrammu kā grafisko attēlu saglabāšanaSolis-pa-solim vedņi

Savienojamība ar citu Quest programmatūruĻoti liela funkcionalitāte

Mēģināsim arī aprakstīt mūsu izveidotās tabulas kritiku ar nedaudz detalizētāku aprakstu.PLUSI:

Modeļu salīdzināšanas iespēja - var redzēt atšķirības vienā un otrā modelī. Tiek salīdzinātas Entītijas, Saites, Atribūti, Kategorijas, Ierobežojumi, Tipi un citi parametri (ļoti izsmeļošs divu modeļu salīdzinājums).

Ir pieejama iespēja atskaišu ģenerēšanai vairākos formātos – HTML, PDF, RTF un XSLT.Mantošanas realizācija trigerī ir notikusi pēc LER modeļa transformācijas uz PER. Abām

„bērnu” realitātēm tika pievienots trigeris, kurš pirms ievades vienā no tabulām pārbauda, vai otrajā tabulā nav tāds pats ieraksts pie primārās atslēgas. Līdz ar to, trigeris realizē diezgan netriviālu, loģisku un stabilu mantošanas risinājumu.

Ļoti izsmeļošs HELP fails - viegli atrast un saprast jebkuru informāciju, kura nav skaidra, ir sniegti izpildes piemēri ar detalizētu aprakstu.

Modeļu atjaunošana pēc labojumiem – lietderīga tad, kad, piemēram, LER modelis jau ir transformēts uz PER modeli, kurā jau ir veikti labojumi, piemēram, tas ir papildināts ar procedūrām, funkcijām, skatiem, u.c. Bet tad pēkšņi ir atrasta kļūda loģiskajā modelī, vai aizmirsta kāds ierobežojums. Ar konvertera palīdzību ir iespējams jaunās izmaiņas pārnest uz fizisko modeli, nepārveidojot to no jauna.

Ir iespējams izveidot ar Versiju Menedžera palīdzību veselu versiju projektu, kurā ir iespējams pievienot vairākus modeļus. Piemēram, tajā var ievietot modeļa pašu pirmo versiju. Pēc tam veikt tajā labojumus un pievienot jau kā jaunāku versiju. Līdz ar to lietotājam vienmēr ir iespēja redzēt sava modeļa attīstības gaitu.

Ir iespējams veikt transformācijas: LERPER, PERLER. Transformāciju var veikt ļoti viegli, jo ir labs dialogs ar lietotāju, kur ir jādefinē nepieciešamie elementi, kurus gribam redzēt transformētā modelī, kā arī uzstādīt citas transformācijas īpašības. Tā pat var veikt PER PER modeļu transformācijas no viena DBVS modeli uz citu.

Ļoti pārskatāmu DDL jeb SQL skriptu ģenerēšana ar iespēju izvēlēties elementu ģenerēšanas kārtību.

86

PER modeli var papildināt ar visiem nepieciešamajiem elementiem – skati, procedūras, funkcijas, trigeri, materializētie skati, procedūru pakotnes, virknes, sinonīmi, ierobežojumi.

TDM atbalsta ļoti daudzas DBVS, tādas kā Oracle, MySql, Postgre, Sybase utt. Ir arī iespēja izvelēties DBVS versijas.

Apvērstās inženierijas iespējas – ir iespēja izveidot PER modeli jau eksistējošai datu bāzei, importējot to, piemēram, no Oracle9i uz Toad Data Modeler.

Katru izveidoto modeli, jeb tā ER diagrammu ir iespējams eksportēt uz grafisko failu BMP, JPEG vai PNG formātā, kas ir ļoti ērti tad, ja attēls ir grūti pārskatāms rīka darba telpā.

Katrai kaut nedaudz īpatnējai rīka funkcijai ir pieejams „solis-pa-solim” vednis (interaktīvas palīdzības līdzeklis), piemēram, Report Wizard, Reverse Engeneering Wizard, u.t.t. Tā pat arī šie vedņi palīdz viegli veikt transformācijas, koda ģenerēšanu, u.tml. Tie palīdz lietotājam virzīties uz priekšu soli pa solim, uzstādot jautājumus, piedāvājot vajadzīgo informāciju un izskaidrojot iespējamos ceļus.

MĪNUSI:Skati, materializētie skati, funkcijas, procedūru pakotnes, trigeri (atsevišķos gadījumos),

procedūras ir jādefinē pašrocīgi ar SQL koda palīdzību.Loģiskais modelis (kaut arī izstrādātāji to sauc par “kompleksais loģiskais modelis”) ir

ļoti līdzīgs konceptuālajam modelim, jo tajā vēl nav migrējušas primārās atslēgas, ir iespējams definēt mantošanu, u.t.t. Tātad, darbs ir jāsāk uzreiz loģiskajā, vai pat fiziskajā modelī.

Var izvelēties tikai starp divām notācijām (izmantojām IE notāciju (ar „vārna kāju”)).Pēc automātiskā izkārtojuma visas entītijas ir izvietotas vienā vertikālē, vai horizontālē.

Labākajā gadījumā tās tiek izbīdītas ļoti lielā attālumā viena no otras, un tad, lai redzētu visu kopējo modeli, tas ir jāsamazina tik ļoti, ka nevar redzēt pat nosaukumus.

Pēc katras modeļa transformācijas vai atjaunošanas pēc labojumiem visi elementi atrodas darba telpā viens uz otra. Līdz ar to, lai izpētītu transformēto modeli, ir jāpatērē laiks elementu izbīdīšanai (ļoti nelietderīgi, ja ir datu bāze ar ļoti lielu realitāšu skaitu).

Kaut arī operatīvās atmiņas minimālās prasības ir 254MB, tomēr izstrādātājs min arī optimālās prasības – 1GB. Šāda programmatūra patērē diezgan daudz datora resursu, līdz ar to, pat uzinstalējot to uz datora ar 1GB operatīvās atmiņas, tā strādāja ļoti lēni.

Nav iespējas noradīt vājo realitāšu, superrealitāšu, arc, vai ternāro saišu struktūras (jārealizē pēc projektētāja interpretācijas), kā arī nevar saitēm pielikt klāt atribūtus (šajā gadījumā vajag definēt atsevišķi entītiju, kurā arī būtu jāieliek nepieciešamie atribūti).

Izmēģinājuma versijā nav iespējas izmantot vairākas programmas funkcijas, piemēram Versiju Menedžeri, kā arī ir noteikt entītiju skaits, ko varam vienlaicīgi izvietot darba telpā (25 entītijas), kā arī skripta ģenerēšanas ierobežojumi lielākam entītiju skaitam.

PLUSI / MĪNUSI:Programmas integrācija ar citu Quest programmatūru bieži vien traucē lietotāja

darbam. Piemēram, ja lietotājam ir uzstādīts Toad for Oracle, tad pēc SQL koda ģenerēšanas, kad ir vēlme apskatīties uzģenerēto kodu, tiek uzreiz atvērts Toad For Oracle, notiek pieslēgšanās kādai datu bāzei zem izvēlētā lietotāja, SQL fails tiek saskaldīts pa atsevišķiem CREATE failiem un katrs tiek atvērts atsevišķi dažādos ciļņos. Ērtāk tomēr apskatīties kodu paša TDM SQL failu attēlotājā, jo tas ir līdzīgs teksta redaktoram un ļauj pāršķirstīt failu lietotājam pierastajā veidā. No otras puses, ja iekš Toad for Oracle fails uzreiz tiek saskaldīts un programma jau ir pieslēgusies datu bāzei, tad šajā vietā, ja SQL teksts apmierina, to var uzreiz palaist un tas tiks izveidots datu bāzē.

Programmai ir milzīga funkcionalitāte un ļoti daudz iespēju. Lietotājs, kurš ir strādājis ar šo programmu tās sākuma versijās, varētu būt pārsteigts ar nepierastu lietotāja saskarni un nepierastajām funkcijām. TDM pieļauj tik lielu iespēju un funkciju klāstu, ka darba ietvaros pat nav iespējams apskatīt tās visas (par neskatoties uz trial versijas ierobežojumiem).

87

SECINĀJUMI

Dotais darbs ir izstrādāts atbilstoši definētajai uzdevuma nostādnei, kuras galvenais mērķis bija realizēt datu bāzes 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.

Praktiskā darba gaitā tika izstrādāts loģiskais (konceptuālais) modelis „Universitāte”, ar kura palīdzību tika realizēta arī visa darba praktiskā daļa, izpētot minēto rīku.

Darba izpildei mēs izvēlējāmies pašu pēdējo izstrādātāja ”Quest” produkta versiju 3.3.8.11, kura ir laista klājā 2009. gada 5.martā, kas liecina par to, ka izstrādātājs joprojām atbalsta šo programmlīdzekli un turpina to uzlabot.

Darbu sākām ar nelielu ieskatu CASE rīkos un arī pašā Toad Data Modeler (turpmāk TDM) rīkā. Līdz ar to, pirmo darba sadaļu nodēvējām par teorētisko. Šajā daļā mēs tuvāk iepazināmies ar rīka lietotāja saskarni un tā pamatfunkcijām. Sākumā, sākot darbu ar TDM, bija nedaudz sarežģīti tajā orientēties, jo lietotājam tiek piedāvāts ļoti liels funkciju un iespēju klāsts, kuru darbību sākumā bija grūti izprast. Taču tas ir normāli, sākot darbu pirmo reizi ar jebkuru programmatūru (ja vēl rēķinās ar to, ka ar šāda veida programmām iepriekš vispār nav bijusi pieredze). Taču, pateicoties „fenomenālam” un „fantastiskam” lietotāja ceļvedim un programmatūras Help failiem, mēs ātri tikām galā ar produkta izprašanu. Patiešām nepietiek pateicības vārdu izstrādātājiem par ceļveža izstrādi, jo tik labus Help-us mēs sen nebijām sastapuši.

Tātad, tieši darba praktiskajā daļā mēs centāmies aprakstīt visas interesantākās rīka iespējas un pat pievērst uzmanību tām funkcijām (sniedzot piemērus), kuras praktiskajā daļā nolēmām neizskatīt (citādi darba apjoms pārsniegtu pāris simtus lappušu). Centāmies ar piemēriem parādīt arī tās funkcijas, kuras mums, izmantojot 15-dienu izmēģinājuma versiju (trial), nebija pieejamas. Šādu piemēru attēlošanai ir nācies meklēt daudz informācijas internetā ar citu lietotāju atsauksmēm, kā arī izmantojot ceļvedī sniegto informāciju. Kā piemēru, varam minēt Version Manager iespēju, kura ir pieejama tikai Expert režīmā, ko neatbalsta izmēģinājuma versija. Bez tam, attēlojām arī apvērstās inženierijas piemērus. Šī iespēja arī mums pašiem bija pieejama, taču dziļāk to nepētījām. Mēs vienkārši pievienojāmies Oracle datu bāzei (zem „system” lietotāja) un nodrošinājām šīs datu bāzes modeļa automātisko TDM vidē. Rezultāts patiešām bija satriecošs, jo mums tika attēlotas visas datu bāzes tabulas ar visām saitēm, kā arī daudz tabulas, kuras nebija saistītas ne ar vienu citu. Tā pat izskatījām arī uzdevumu sarakstu (To-Do list), ar kura palīdzību lietotājs var izveidot sev (vai citam lietotājam, kurš vēlāk strādās ar modeli) atgādinājumu sarakstu, lai atcerētos to, kas, piemēram, būtu jāizdara nākošajā darba dienā.

Kad bijām pabeiguši programmatūras izpēti un teorētisko aprakstu, ķērāmies pie interesantākās daļas – saišu-realitāšu diagrammas veidošanas TDM vidēm izmantojot pasniedzēja piedāvāto priekšmetisko vidi „Universitāte”.

Uzreiz pirmajā solī sapratām to, ka izstrādātāja definētais „kompleksais loģiskais modelis” tomēr vairāk atbilst konceptuālā modeļa īpašībām. Pirmkārt, ārējās atslēgas uzreiz nemigrē (kā

88

tam jābūt loģiskajā modelī). Otrkārt, mums bija iespēja definēt mantošanas struktūru (loģiskajā modelī tai jau būtu jābūt transformētai struktūrai). Treškārt, mums nebija iespējas uzreiz izveidot skatus (kā to var izdarīt loģiskajā modelī). Tomēr, neskatoties uz to visu, daudzviet realitātes jau tomēr tiek dēvētas par „tabulām”, kā tas pēc būtības arī ir loģiskajā modelī (turpmāk LER). Līdz ar to mēs nonācām pie secinājuma, ka sākotnējais modelis ir sava veida loģiskā un konceptuālā modeļa simbioze. Neskatoties uz to, mēs tomēr uzzīmējām konceptuālā modeļa diagrammu, kurā attēlojām dažas struktūras, kuras TDM vidē nebija iespējams realizēt. Piemērām, mums bija jārealizē vājā realitāte kā tabula, kurā pēc transformācijas fiziskajā modelī būtu jāmigrē ārējām atslēgām no abām tabulām, ar kurām tā ir saistīta. Vēl kā piemēru varam minēt to, ka mums nebija iespējams pievienot saitei datus, līdz ar to šo struktūru mēs realizējām kā atsevišķu tabulu, ar vajadzīgajiem datiem (datums no, datums līdz). Tā pat mēs mēģinājām modelī ieviest arī dažviet kādus ierobežojumus atribūtiem, piemēram, atzīmes vērtībai iespējamo vērtību intervālu (no 1 līdz 10), lai pēc tam pārbaudītu vai šī informācija arī tiks transformēta. Pamēģinājām arī realizēt N:M saites, lai redzētu to, vai pēc transformācijas izveidosies starptabulas, kā tam būtu jānotiek pēc visiem transformēšanas likumiem. Un visbeidzot realizējām mantošanu no realitātēm Cilvēks, kura bija kā „vecāku” realitāte, un divām „bērnu” realitātēm – Students un Pasniedzējs. Bez tam, definējot mantošanu mēs uzstādījām parametru, ka abi bērni manto vecāku datus. Tas bija izdarīts ar mērķi izpētīt mantošanas transformāciju pēc modeļa konvertēšanas fiziskajā modelī (turpmāk PER).

Pabeidzot darbu ar LER modeli, mēs izveidojām atskaiti HTML formātā. Atskaites detalizētība patiešām var pārsteigt jebkuru lietotāju. Mums bija ne tikai iespēja izvēlēties atskaites vizuālo izskatu, bet arī definēt nepieciešamos elementus un objektus, kurus gribam redzēt atskaitē. Bez tam, varam droši apgalvot, ka atskaites kvalitāte ir ļoti laba, jo tā ir ērti pārskatāma, kā arī ir nodrošināta diezgan efektīva un interaktīva mijiedarbība ar lietotāju.

Pēc modeļa izveides, mēs veicām verifikāciju. Noskaidrojās ka mums bija ieviesušās dažas kļūdas. Sākumā bija grūti atrast veidu, ka apskatīties ieviesto kļūdu sarakstu, taču atkal pateicoties ļoti labam programmas ceļvedim mēs tikām galā ar šo problēmu, un visas kļūdas, kā arī brīdinājumi, tika novērsti.

Tad bija pienācis laiks modeļa konvertēšanai, jeb transformācijai uz PER modeli. Sākuma mums šķita, ka transformācija ir diezgan vienkāršs process, kur tikai jāizvēlas datu bāzes tips uz kuru konvertēsim un tad arī ar viena klikšķa palīdzību datu bāze būs gatava. Tomēr tā tas nav. PER modeļa izveide ir liels lērums papildināšanas darbību un jo vairāk uzmanības tiek pievērsts detaļām, jo kvalitatīvāks būs rezultāts. Pie tāda secinājuma mēs nonācām tikai pēc tam, kad izpētījām jau transformēto PER modeli un to papildinājām.

Tātad, sakumā nolēmām veikt atsevišķu elementu transformāciju. Visas transformācijas, pēc savas būtības, notika tā, ka mēs arī paredzējām – unārās saites ārējā atslēga migrēja otru reizi uz to pašu tabulu, dodot atsauci pašai uz sevi; N:M saites transformācijas gaitā ir izveidojušās starptabulas, kā arī ir migrējušas visas nepieciešamās ārējās atslēgas. Tā pat arī ar ierobežojumiem – tie bija pārvietojušies arī uz PER modeli, kas arī bija pats par sevi saprotams. Interesantāk bija ar mantošanu. PER modelī bija izzudusi „vecāku” tabula Cilvēks, savukārt tās atribūti bija pārvietojušies uz abām „bērnu” tabulām. Pie tam, papildus bija izveidojies arī

89

trigeris abām „bērnu” realitātes tabulām, kas patiešām mūs pārsteidza. Pēc SQL koda sapratām, ka trigeris pirms jauna ieraksta ievades (Before Insert) tabulā „Students” pārbauda vai tāds pats personas kods jau neeksistē tabulā „Pasniedzējs”, jo tā ir unikāla vērtība, kura ir kā primārā atslēga migrējusi no „vecāku” tabulas. Līdz ar to, ja ievadāmais personas kods jau eksistē otrajā tabulā, tad tiks izvadīts paziņojums par ievades kļūdu. Šāda veida trigeris realizē diezgan netriviālu, loģisku un stabilu mantošanas risinājumu.

Neskatoties uz to, pēc detalizētas izpētes mēs secinājām, ka šāda trigera izpilde pirms katras ievades var aizņemt daudz laika, jo tam būtu jāpārbauda visu tabulu (gadījumā ja tās apjoms ir ļoti liels. No otras puses – labāk lēnāk, bet korektāk. Tas arī tiek nodrošināts. Cits secinājums ir tāds, ka pēc būtības būtu jāizveido vēl viens pirms atjaunošanas (Before Update) trigeris, lai pārliecinātos par to, ka nav iespējams nomainīt primārās atslēgas, jo tad tās var pārstāt būt unikālas. Un visbeidzot – ja tiktu pievienota vēl viena atkarīgā tabula (trešā) (jo fiziskajā modelī ir iespējams vēl pievienot tabulas, saites, u.t.t.), tad visi trigeri būtu jāmaina. Neskatoties uz visu iepriekš minēto, šāds mantošanas interpretējums nav sastopams nevienā citā CASE rīkā, kas viennozīmīgi priecē.

Visbeidzot mēs veicām arī pilno modeļa transformāciju, iekļaujot tajā visus objektus. Pēc būtības, šādā transformācijas veidā vienīgā atšķirīgā īpašība bija primāro atslēgu migrēšanai tabulā Students. Šeit nāca klāt „vecāku” tabulas primārā atslēga un kļuva par tabulas Students primāro atslēgu un tieši tādēļ šī atslēga ir arī otro reizi migrējusi uz tabulu kā otrā primārā atslēga (aiz studenta numura) kā unārās saites atsauce pašai uz sevi.

Tālāk veicām modeļa papildināšanu. Mums ļoti patika tas, ka PER modelī ir iespēja ne tikai pievienot citas tabulas ar saitēm, bet arī izveidot skatus, procedūras, virknes, sinonīmus, funkcijas, procedūru pakotnes, citus ierobežojumus, kā ari citus trigerus. Tiesa gan, daži no šiem elementiem ir tīri manuāli izpildāmo darbību process, piemēram, skati, procedūras, funkcijas, trigeri un procedūru pakotnes ir jāraksta mums visiem pierastajā SQL kodā. Taču, ja labi padomā, tad kā gan savādāk. Nedaudz savādāk ir ar virkņu un sinonīmu realizēšanu. Šajā gadījumā mums tiek piedāvāta forma, kurā mums burtiski ir jāieraksta nosaukums, virkņu gadījumā - pieauguma skaits un sākuma skaitlis; sinonīma gadījumā – atbilstošais objekts. Protams, ka pēc būtības tas arī ir viss, kas jādefinē virknei vai sinonīmam. Tomēr, pēc šo parametru definēšanas uzreiz ir iespēja apskatīties SQL kodu un, pēc vēlmes vai nepieciešamības, to papildināt vai labot. Būtībā, mums ir iespēja PER modelī veikt jebkurus manuālus labojumus SQL kodā, kas arī uzreiz tiks attēlots labojamajā struktūrā.

Šeit būtu svarīgi piebilst to, ka ir nācies pēc tam, kad jau PER modelis tika papildināts ar citiem objektiem, atrast kādas kļūdas LER modelī. Par sava veida glābiņu šeit nāca rīka iespēja atjaunot modeli pēc labojumiem. Tā ir pēc būtības tā pati konvertācija, tikai konvertējot LER modeli atkārtoti, kā datu bāzes tipu transformācijai ir jāizvēlas jau esošais PER modelis. Tādā gadījumā tiks transformētas jau tikai tās LER modeļa sastāvdaļas, kuras nav PER modelī.

Pēc papildināšanas mēs izveidojām atskaiti PDF formātā. Šī atskaite bija tik pat detalizēta, kā LER modelī, un šoreiz aizņēma 50 lappuses. Patika tas, ka atskaite bija ļoti labi noformēta, ar titullapu un pilnībā gatava drukāšanai.

90

Nākošajā solī mēs ķērāmies klāt modeļu salīdzināšanai. Salīdzinājām LER un PER modeļus. Šeit uzreiz varējām redzēt to, ka ir izzudusi entītija Cilvēks, parādījās divas starptabulas, kā arī entītijas Students un Pasniedzējs ir ieguvušas papildus atribūtus. Tā pat izmēģinājām arī transformēt mūsu PER modeli atpakaļ uz LER modeli, lai varētu salīdzināt sākotnējo LER ar gala LER. Ari šeit rezultāts bija tāds pats. Šajā vietā varam secināt, ka katru reizi mašīna interpretē transformāciju no savas „pieredzes”, t.i. katru transformāciju veic pēc saviem likumiem. Pēc katras transformācija modelis mainās un mēs nekad nevaram iegūt atpakaļ to pašu, kas bija iepriekš. Tas ir pārbaudīts praksē, kaut tomēr ir pats par sevi saprotams. Gribētu pieminēt arī to, ka rīkā ir iespēja arī veikt PERPER transformāciju gadījumam, ja vienas datu bāzes vadības sistēmas PER modelis ir jātransformē citā datu bāzes vadības sistēmā.

Visbeidzot, darba noslēguma daļā mēs izpildījām koda ģenerēšanu. Koda ģenerēšana arī ir diezgan vienkārša, kur mums ir jāizvēlas objekti, kuriem mums ir jāiegūst kods. Tā pat mums arī varējām izvēlēties objektu ģenerēšanas secību un arī primāro atslēgu ģenerēšanas vietu (iekš tabulas vai ārpus tās). Ģenerēšanas secības izvēle ir diezgan lietderīga, jo mēs varam definēt konkrētu struktūru secību, lai nevajadzētu meklēt kurā faila vietā kāds kods atrodas. Šeit atradām ari vienu īpašību, kuru nevarētu nosaukt ne par programmas plusu, ne par mīnusu. Mūsuprāt, integrācija ar citu Quest programmatūru bieži vien traucē lietotāja darbam. Piemēram, ja lietotājam ir uzstādīts Toad for Oracle, tad pēc SQL koda ģenerēšanas, kad ir vēlme apskatīties uzģenerēto kodu, tiek uzreiz atvērts Toad For Oracle, notiek pieslēgšanās kādai datu bāzei zem izvēlētā lietotāja, SQL fails tiek saskaldīts pa atsevišķiem CREATE failiem un katrs tiek atvērts atsevišķi dažādos ciļņos. Ērtāk tomēr apskatīties kodu paša TDM SQL failu attēlotājā, jo tas ir līdzīgs teksta redaktoram un ļauj pāršķirstīt failu lietotājam pierastajā veidā. No otras puses, ja iekš Toad for Oracle fails uzreiz tiek saskaldīts un programma jau ir pieslēgusies datu bāzei, tad šajā vietā, ja SQL teksts apmierina, to var uzreiz palaist un tas tiks izveidots datu bāzē.

Gribētos uzsvērt arī programmas vienu no lielākajiem plusiem – solis-pa-solim vedņi. Tie palīdz lietotājam virzīties uz priekšu soli pa solim, uzstādot jautājumus, piedāvājot vajadzīgo informāciju un izskaidrojot iespējamos ceļus. Tas patiešām palīdz lietotājam, kas strādā ar šāda veida programmatūru vai nu pirmo reizi, vai arī ne visai skaidri saprot kā to var realizēt manuāli. Ar mūsu citiem definētajiem plusiem un mīnusiem izpētītajai programmai var iepazīties subjektīvās kritikas sadaļā. Protams, kā jau minējām, šī kritika ir vairāk subjektīva, jo mēs sniedzām vērtējumus pēc savas pieredzes, strādājot ar programmatūru.

Lielākā grūtība darba gaitā tomēr ir bijusi darba izpilde grupā no trim cilvēkiem. Katram ir savas idejas, savas pretenzijas un priekšlikumi. Katrs grib realizēt kaut ko savu, kas, iespējams, citi grupas biedri nepiekrist. Bez tam, katram ir savs darba izpildes stils, kas bieži vien liekas neskaidrs citam. Vieglāk tomēr ir katram orientēties savā darbā, kuru cilvēks pats ir veidojis un pārzina „no A līdz Z”, nekā mēģināt gūt skaidrību cita paveiktajā darbā.

Kopumā uzskatam, ka esam padarījušas lielu darbu, kurš patiešām ir veiksmīgi izpildīts. Mēs varam apgalvot, ka mašīna nespēj transformēt lielāko daļu virtuālās daļas un permanentās daļas struktūru. Galu galā – projektētājam vienmēr ir labāka pieredze nekā mašīnai un pati mašīna bez projektētāja, pat tad ja tā ir automatizēta, nespēj paveikt visu pati.

91

INFORMĀCIJAS AVOTI

Literatūra latviski:1) J.Eiduks, 2008./2009.māc.g. Izdales materiāli no diska.2) Semināra materiāli: vaicājumi valodā SQL un tas paplašinājums PL/SQL. J. Eiduks (no 2002 gada).

Literatūra krieviski:3) Базы данных, Проектированиеб реализация и сопровождение. Теория и практика / Под ред. Т. Конноли, К. Бегг, А. Страчан. – М., изд. дом Вильямс, 2000.4) „Дипломное проектирование” В.В.Родионов, учебно-методическое пособие.

Literatūra angliski:5) Toad Data Modeler Help.

Internets:6) http://www.interface.ru/fset.asp?Url=/ca/idef1x.htm7) http://www.casestudio.com/enu/products.aspx8) http://www.quest.com/common/registration.aspx?requestdefid=10037 9) http://www.networkcomputing.com/showitem.jhtml?articleID=47900819&pgno=610) http://www.casestudio.com/enu/tdm_statement_of_direction.aspx11) http://modeling.inside.quest.com/index.jspa12) http://zenobank.com/index.php?symbol=QSFT&page=quotesearch13) http://en.wikipedia.org/wiki/Toad_Data_Modeler14) http://www.toadsoft.com/toaddm/toad_data_modeler.htm15) http://www.databasejournal.com/features/oracle/article.php/3754671/Product-Review--Toad-Data-Modeler-3.htm16) http://www.dbta.com/cgi-bin/redir.cgi?id=quest_200711

92

PIELIKUMI

1.pielikums. Uzģenerētā SQL koda pirmteksts

/*Created: 02.05.2009Modified: 02.05.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 ),

93

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_Nos

94

FROM 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")/

95

anotĀcija · web view8.4.fiziskā modeļa atskaites ģenerēšana pdf formātā72 9.sql koda...

Documents