datubaze.files.wordpress.com€¦ · Web viewRĪGAS TEHNISKĀ UNIVERSITĀTE. Datorzinātnes un...

RĪGAS TEHNISKĀ UNIVERSITĀTEDatorzinātnes un informācijas tehnoloģijas fakultāte

Lietišķo datorsistēmu institūts

Praktiskais darbs

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

„CASE rīku izmantošana datu bāzes projektēšanā”.

Izstrādāja: Ervīns KeišsStud.apl.nr: 081RDB221

2013/2014. m.g.

SATURS1 Uzdevuma nostādne................................................................................................3

2 Rīka vispārīgais raksturojums.................................................................................4

3 Konceptuālais modelis..........................................................................................10

3.1 Realitāšu izveide............................................................................................10

3.2 Saišu izveide..................................................................................................13

3.3 Modeļa pārbaude............................................................................................16

4 Loģiskais datu modelis..........................................................................................17

5 Fiziskais datu modelis...........................................................................................19

5.1 Fiziskā modeļa izveide...................................................................................19

5.2 Skripta iegūšana.............................................................................................21

6 Apvērstā inženierija..............................................................................................23

6.1 Fiziskā modeļa iegūšana, izmantojot .sql failu..............................................23

6.2 Fiziskā modeļa iegūšana, izmantojot pieslēgšanos datu avotam...................26

6.3 Cita veida apvērstā inženierija.......................................................................27

7 Secinājumi.............................................................................................................28

8 Izmantotā literatūra...............................................................................................29

9 Pielikumi...............................................................................................................30

1 UZDEVUMA NOSTĀDNE

Izveidot datu bāzes modeli, izmantojot Sybase PowerDesigner CASE rīku.

Pēc modeļa izveidošanas ielādēt to datu bāzes vadības sistēmā. Par datu bāzes vadības

sistēmu tiek izmantota Oracle 11R2 Express Edition. Darba gaitā jāveic sekojoši

uzdevumi:

1) vispārīgs rīka raksturojums

2) konceptuālā modeļa izveide;

3) loģiskā modeļa izveide;

4) fiziskā modeļa izveide;

5) datu bāzes shēmas ģenerēšanas skripta iegūšana;

6) datu ievade un vaicājumu izpilde;

7) reinženierijas iespēju izpēte rīka ietvaros;

2 RĪKA VISPĀRĪGAIS RAKSTUROJUMS

Sybase PowerDesigner ir vadošais datu modelēšanas industrijas rīks, kas

iekļauj sevī dažādas datu modelēšanas tehnoloģijas – tradicionālo konceptuālo,

loģisko un fizisko modelēšanu – apvienojot ietekmes analīzes un projektēšanas-

perioda izmaiņu vadību kopā ar formāliem datubāzes projektējumu risinājumiem.

Par PowerDesigner datu arhitekta galvenajām iezīmēm var uzskatīt:

- lietošanas vienkāršību;

- prasību vadību – detalizēta prasību analīze tiek panākta ar visu modeļu

sasaisti, tādējādi ļaujot skaidri izdalīt biznesa mērķus un stratēģijas,

kas virza datu noliktavas sākotnējo izstrādi un turpmākās izmaiņas;

- dokumentu ģenerēšanu – jaudīga atskaišu ģenerēšanas iespēja ļauj arī

lietotājiem, kuri nav saistīti ar modelēšanu, piekļūt metadatiem;

- ietekmes analīzi – visu tipu modeļi ir sasaistīti kopā, tādējādi ļaujot

veikt ietekmes analīzi projekta līmenī un uzlabot visas organizācijas

sadarbību, kā arī reakciju uz izmaiņām;

- plašu atbalstu – vienā rīkā tiek atbalstītas visas lielākās (vairāk nekā

90) relāciju DBVS platformas;

- pielāgojamību – pielāgojams interfeiss ļauj ērti veikt vispārējas

darbības, tajā pašā laikā sniedzot ātru pieeju darbībām arī augstākā

līmeņa lietotājiem;

- metadatu koplietošanu – atkarībā no lietotāja lomas tiek sniegta pieeja

attiecīgajiem metadatiem, tajā skaitā grafikai, pilnām elementu

definīcijām un aprakstiem;

- uzņēmuma repozitoriju – kā augsta mērogojamības līmeņa centralizēta

metadatu vadības vienība, uzņēmuma repozitorijs nodrošina uz lomām

balstītu pieeju modeļiem, versiju kontroli, ietekmes analīzi,

konfigurācijas vadību, versiju salīdzināšanu un visaptverošu

meklēšanu;

- repozitorija vārdnīcu – nodrošina to, ka biznesa jēdzieni un definīcijas

tiek viscaur modeļiem vienādi lietotas, tādējādi saglabājot vienotu

nosaukumu veidošanas standartu.

PowerDesigner atbalsta sekojošas modelēšanas tehnoloģijas:

- konceptuālā datu modelēšana – konceptuālais datu modelis atbalsta

vairākas vadošās notācijas un sniedz datu bāzes, kā arī tehnoloģijas

neatkarīgu organizācijai svarīgu objektu atspoguļošanas iespēju.

Konceptuālais modelis iteratīvi tiek pārvērsts vienā vai vairākos

loģiskajos vai fiziskajos modeļos, balstoties uz nepieciešamo

abstrakcijas līmeni un pieejām informācijas arhitektūrai no biznesa

viedokļa (1. att.)

1. att. Konceptuālā diagramma- loģiskā datu modelēšana – loģiskais datu modelis atbalsta vairākas

vadošās notācijas un sniedz no datu bāzes neatkarīgu relāciju struktūru

atspoguļošanu. Pēc validēšanas un apstiprināšanas, loģiskais modelis

kļūst par pamatu fiziskā datu modeļa izveidei (2. att.)

2. att. Loģiskā diagramma

- fiziskā datu modelēšana – fiziskais datu modelis parasti tiek ģenerēts

no loģiskā datu modeļa, taču ir iespējams pielietot arī apvērsto

inženieriju, tādējādi no jau gatavas datu bāzes shēmas iegūstot fizisko

modeli. Fiziskais datu modelis atbalsta vairākas vadošās notācijas, kā

arī dokumentu, ģenerēšanas un apvērstās inženierijas struktūras vairāk

nekā 90 DBVS (tajā skaitā pēdējās Oracle versijas, IBM, Microsoft,

Sybase, Teradata, MySQL, HO NeoView un daudzas citas). Atbalsts

iekļauj visus datu bāzu artefaktus, kuri nepieciešami tabulu sasaistu

izveidei vai arī lai panāktu uz veiktspējas uzlabošanu nostādītus

mērķus, kā piemēram, indeksi, ierobežojumu definīcijas, sasaistes

tabulas (linking tables), klāsteri un tādas tehnoloģijas kā Java, XML un

tīmekļa servisi datu bāzē, kā arī drošības modelēšana, augsta līmeņa

tehnoloģijas skatiem u.c. Fiziskais modelis bieži vien tiek izmantots,

lai aprēķinātu datu glabāšanai nepieciešamās atmiņas resursus, taču tas

iekļauj arī specifiskas detaļas par doto datu bāzes sistēmu (3. att.)

3. att. Fiziskā diagramma- datu noliktavu modelēšana – multidimensiju diagrammas parāda

OLAP vidi – kubus, faktus, dimensijas, dimensiju hierarhijas, kā arī no

tabulu, kas izmantotas datu noliktavas vai vitrīnas informācijas

glabāšanai, fiziskās struktūras neatkarīgus vaicājumus. Izmantojot datu

sasaistes redaktoru vai datu plūsmu diagrammas, iespējams izveidot

pilnīgu biznesa intelekta arhitektūru, izejot no pamata definīcijām,

transformācijām, datu noliktavām, datu vitrīnām un pārskata vides (4

att.)

4. att. Datu noliktavu modelēšana- XML datu modelēšana – XML specifiskas modelēšanas tehnoloģijas

XML shēmu un XML DTD struktūru dokumentēšanai, ģenerēšanai un

apvērstai inženierijai. XML modeļi ir sasaistīti ar datu modeļiem, lai

dokumentētu XML un relāciju sasaisti, kā arī XML konceptu saprotošu

DBVS XML definīciju izveidi (5. att.)

5. att. XML diagramma- datu plūsmu modelēšana – datu plūsmu modelēšana raksturo visu datu

pārvietošanos ceļu – sākuma datu krātuves, mērķa datu krātuves,

daudzkārtējas transformācijas, publikācijas utt. (6. att.)

6. att. Datu plūsmu diagramma- objektorientēta modelēšana – tā ir modelēšanas paradigma, kas apskata

problēmu kā objektu kopu, kas savstarpēji mijiedarbojas. Modelēšanas

uzdevums ir specificēt šo objektu kontekstu, to īpašības un metodes.

Izplatītāka OOM notācija ir UML. UML ir formāla, standartizēta,

objektorientēta modelēšanas valoda. Tajā ir labi definēta sintakse un

semantika, kas palīdz veidot skaidrus un vienkāršus modeļus.

Jaunumi 16.5 versijā:

a) uzlabota pārskatu grafiskā saskarne;

b) XML failu imports, definējot sasaisti starp elementiem XML shēmā un

objektiem PowerDesigner meta-modelī;

c) uzlabojumi objektu ģenerēšanā (objekta atribūtu, apakšobjektu, saistīto

objektu sasaiste);

d) repozitorija uzlabojumi;

e) SAP BusinessObjects ģenerēšana;

f) SAP HANA, SAP Solution Manager, SAP NetWeaver biznesa procesu

modelēšana, ģenerēšana, apvērsta inženierija;

g) atvieglota multidimensiju objektu modelēšana;

h) jaunu DBVS versiju pievienošana;

i) pilnībā pārrakstīts apvērstās inženierijas algoritms XSD failiem;

j) XML modeļa ģenerēšanas uzlabojumi.

3 PROBLĒMSFĒRAS APRAKSTS

Praktiskajā darbā realizēts auto sacīkšu seriāla Formula 1 (F1) datubāzes

projekts. Braucēji ir sportisti, kas pārstāv dažādas komandas (katrs sportists var

pārstāvēt tikai 1 komandu, taču 1 komandu var pārstāvēt vairāki braucēji) un ņem

dalību dažādās trasēs sezonas garumā. Ja komandu kodolu veido sportisti, tad apkārt

tiem vienmēr atrodas daudzi mehāniķi, kuri palīdz gan formulu testēšanā, labošanā,

gan jauninājumu izstrādē. Protams, ka komanda nevar eksistēt, sastāvot tikai no

sportistiem un to palīgiem, kādam ir jāvada viss, pretējā gadījumā komandā būs

haoss. Komandas vadītāji ir tie cilvēki, kuri dod pavēles, izvēlas stratēģiju un

koordinē kopējo komandas darbu. Katru komandu arī finansiāli atbalsta sponsori, kuri

individuāli atbalsta arī kādu sportistu.

Par galvenajiem komandas raksturlielumiem var uzskatīt, bez šaubām, tās

nosaukumu, kas atšķir to no citām, tās krāsas, jo reglamentā ir noteikts, ka bāzes

krāsai ir jāatšķiras. Komandas dzinējs (tā piegādātājs) ir vēl viens svarīgs parametrs,

kas veido komandas pilno nosaukumu pēc šablona ‘nosaukums-dzinēja piegādātājs’.

Jāmin arī kopējais darbinieku skaits, kas spēlē svarīgu lomu, kad tiek veidotas

atskaites par komandas darbību sezonā.

Ja runa iet par braucējiem, tad svarīgi ir zināt (kā jau katra cilvēka) vārdu,

uzvārdu, tautību, tāpat ir jāzina ar kāda numura formulu viņš brauc. Kā arī algas

apmērs un līguma datumi ir ļoti svarīgi parametri gan sportistam pašam, gan arī

komandai kopumā vairāk finansiālā ziņā.

Par sponsoriem svarīgi ir zināt to nosaukumu, piedāvāto summu, kā arī

sadarbības termiņu, kas ir pašsaprotami un ko īpaši laikam nevajadzētu uzsvērt.

Katru trasi (tāpat kā cilvēku raksturo savi „parametri”) raksturo tās

nosaukums, atklāšanas gads, rekords, skatītāju ietilpība un valsts, kurā tā atrodas.

Vadītāju izvēlētās stratēģijas vienmēr ietekmē trases tips.

Komandas vadītājus raksturo vārds, uzvārds, kategorija, kā arī licences

numurs, kas ir sava veida juridisks apliecinājums par cilvēka augsto kvalifikāciju un

atļauju vadīt komandu. Vadītājiem, tāpat kā braucējiem ir līgums ar komandu, kurš

nosaka darbības termiņu.

Visbeidzot komandas mehāniķi ir daļēji atbildīgi par to, kas notiek trasē.

Katram mehāniķim ir savs vārds, uzvārds. Specializācija norāda par kādu formulas

daļu vai jomu viņš atbild – skaidrs, ka viens mehāniķis nevar atbildēt par visu. Lielāka

uzticība tiek iegūta no mehāniķiem ar augstāku statusu jeb līmeni, kas svarīgi ietekmē

formulas konstrukcijā. Katram mehāniķim tiek izmaksāta alga pēc iepriekš noslēgtā

līguma.

4 KONCEPTUĀLAIS MODELIS

4.1 Realitāšu izveide

Par datu bāzes priekšmetisko jomu ir izvēlēta F1 klases sacīkšu sistēma, kuras

izveidē turpinājumā tiks izmantots Sybase PowerDesigner (versija 16.5) rīks.

Lai uzsāktu konceptuālā modeļa izveidi, rīka augšējā izvēlnē ir jāizvēlas File

→ New Model, kā rezultātā tiek atvērta izvēlne ar pieejamiem modeļu veidiem. Šajā

izvēlnē tiek izvēlēta informācijas kategorija un attiecīgi konceptuālais modelis (7.

att.).

7. att. Jauna modeļa izveidePēc jauna modeļa izveides tiek atvērta darba virsma, taču pirms tam ir

nepieciešams norādīt izmantojamo notāciju. To panāk augšējā izvēlnē izvēloties Tools

→ Model options un notācijas izvēlnē norādot vēlamo no 5 piedāvātajām. Šajā

gadījumā tiks lietota E/R+Merise notācija (8. att.).

8. att. Modeļa uzstādījumu maiņaDarba virsmas labajā pusē ir pieejams diagrammā iekļaujamo elementu

panelis (9. att.), kas sadalīts 4 daļās – standarta, konceptuālās diagrammas (atkarīgi no

izvēlētās notācijas), vienkāršie un iepriekšdefinētie elementi. Veidojot konceptuālo

diagrammu, tiks strādāts galvenokārt ar izvēlnes 2. daļu.

9. att. Elementu panelisLai izveidotu jaunu realitāti, nepieciešams izvēlēties realitātes (Entity)

elementu no iepriekš minētā elementu paneļa un noklikšķināt uz darba virsmas, kā

rezultātā uz darba virsmas grafiskā veidā tiks atspoguļota realitāte, savukārt kreisās

puses sarakstā tiks pievienots jauns ieraksts. Uzklikšķinot uz jaunizveidotās realitātes

elementa, tiek atvērts realitātes īpašību logs, kas satur 5 daļas (vispārēja, atribūti,

identifikatori, piezīmes un likumi). Šajā gadījumā tiks rediģētas tikai pirmās 2:

vispārējā (nosaukums, kods, komentāri, numurs, realitāte-vecāks) un atribūtu

(nosaukums, kods, datu tips, garums, precizitāte, obligāta aizpildīšana, primārais

identifikators, parādīšana un domēns) daļa (10. att.). Vispārējā daļā tika aizpildīts

realitātes nosaukums, savukārt atribūtu daļā tika definēti 5 dažādi atribūti.

10. att. Realitātes izveideTurpinot realitāšu izveidi, lietderīgi ir izveidot domēnus, kas kontrolēs atribūtu

vērtības. Šim nolūkam ir jāizmanto augšējās izvēlnes sadaļa Model un jāizvēlas

Domains. Tā kā turpinājumā tiks izveidota sacīkšu stratēģiju realitāte, domēns

raksturos sākotnējo riepu komplektu ({ H, M, S, SS, I, FW }) (11. att.).

11. att. Domēna izveide

Pēc domēna izveides kreisajā pusē parādās jauns saraksts ar visiem

izveidotajiem domēniem. Klikšķinot uz izveidotā domēna, tiks atvērts attiecīgā

domēna uzstādījumu logs. Šajā gadījumā dzimuma domēnam pie standarta pārbaudēm

tiks pievienotas iespējamās vērtības (12. att).

12. att. Domēna uzstādījumu maiņa

4.2 Saišu izveide

Veidojot saites starp realitātēm, no elementu paneļa labajā pusē nepieciešams

izvēlēties saites objektu un, klikšķinot uz sākotnējās realitātes, novilkt sasaisti uz otru

realitāti. Klikšķinot uz izveidotās saites, ir iespējams veikt izmaiņas saites

uzstādījumos (vispārējā daļa: saites nosaukums, kods, aprakts, stereotips, saistītās

realitātes; kardinalitāšu daļa: kardinalitātes tips (1:1, 1:N, N:1, N:N), attieksmes

nosaukums, realitātes atkarība no otras, obligātas sasaistes esamība, kā arī piezīmju un

likumu daļa) (13. att.)

13. att. Saites uzstādījumu maiņaŠajā gadījumā izveidotā saite ir norādīta kā atkarīga, tātad rezultātu realitāte ir

atkarīga no braucēju realitātes, kā arī trašu realitātes, jo pretējā gadījumā no rezultātu

realitātes nav jēgas.

Papildus vienkāršas saistības izveidei, ir iespējams norādīt, ka realitāte ir

mantotāja jeb apakšrealitāte. Piemēram, komandas sponsors var būt gan fiziska, gan

juridiska persona. Lai izveidotu mantošanas saiti, no elementu paneļa jāizvēlas

mantošanas saite un jānovelk tā virzienā uz vecāka realitāti. Klikšķinot uz izveidotās

saites, parādās mantošanas saites uzstādījumu logs, kurā iespējams mainīt tās

nosaukumu, kodu, aprakstu, stereotipu, vecāka realitāti, savstarpēji izslēdzošas bērnu

realitātes, sadalījuma pilnīgums, kā arī vecāku, bērnu ģenerēšanas nepieciešamību un

bērnu realitāšu norādi, piezīmes un likumus (14. att.).

14. att. Mantošanas saites uzstādījumu maiņaLietojot E/R+Merise notāciju, elementu panelī tiek aktivizēts arī asociācijas un

asociācijas saites elements. Asociācijas pievienošana un saites definēšana starp

asociāciju un realitāti notiek precīzi tāpat kā attiecīgi realitātes pievienošana un

realitāšu saistīšana. Vienīgi asociācijas saites uzstādījumu maiņas logā ir pieejama

tikai vispārīgā sadaļa, kas iekļauj saistāmo realitāti un asociāciju, kardinalitāti, lomu

un stereotipu (15. att.).

15. att. Asociācijas saites uzstādījumu maiņa

4.3 Modeļa pārbaude

Pēc tam, kad konceptuālais modelis ir izveidots, ir nepieciešama tā pārbaudes

veikšana, jo pretējā gadījumā, ja tiks atrastas kļūdas, loģiskā modeļa ģenerēšana nebūs

iespējama. Lai pārbaudītu izveidoto modeli, no augšējas izvēlnes jāizvēlas sadaļa

Tools→Check Model. Rezultātā parādīsies logs, kurā var atzīmēt visas pārbaudāmās

kategorijas (pakotne, domēns, realitātes, asociācijas utt.). Ja pārbaudes laikā tiks

konstatētas kļūdas, loģiskā modeļa ģenerēšanai vispirms būs jānovērš atrastās

nepilnības modelī. Papildus tam tiks uzrādīti brīdinājumi par neprecizitātēm modelī,

taču tas neliegs ģenerēt loģisko modeli. Kad visas kļūdas ir novērstas, konceptuālais

modelis ir uzskatāms par pabeigtu (16. att.).

16. att. Konceptuālais modelisIzveidotais konceptuālais modelis satur 15 realitātes un 2 asociācijas, kas savā

starpā savienotas ar 18 saitēm.

5 LOĢISKAIS DATU MODELIS

Loģiskā datu modeļa ģenerēšana paredz gatava, kļūdas nesaturoša konceptuālā

modeļa esamību – tas ir līdzīgs fiziskajam modelim, taču nebalstās uz izmantojamo

datu bāzes vadības sistēmu. Lai veikto loģiskā datu modeļa ģenerēšanu, no augšējās

izvēlnes jāizvēlas Tools → Generate Logical Data Model.

17. att. Loģiskā modeļa ģenerēšanaTiks atvērts logs (17. att.), kas piedāvās veikt modeļa ģenerēšanas

uzstādījumus – vispārējā daļa, kas nosaka vai ģenerēt jaunu modeli (ir iespējama

modeļa uzstādījumu veikšana, piemēram, modeļa notācija utt.), vai arī atjaunināt jau

eksistējošo; detaļu daļa, kas paredz konceptuālā modeļa iepriekšēju pārbaudi, kā arī

ģenerēšanas atkarību saglabāšanu un selekcijas daļu, kas nosaka ģenerēšanā

iekļaujamos objektus.

Pabeidzot loģiskā modeļa ģenerēšanas procesu, tiek iegūts jauns modelis, kas

izmanto Barkera notāciju diagrammas atspoguļošanā (18. att.).

18. att. Loģiskais datu modelisNo iegūtā modeļa redzams, ka mantošanas rezultātā bērnu realitātes atrodas

vecāka realitātes iekšpusē. Ja uzklikšķināt uz kādas no bērnu realitātēm, var redzēt, ka

atribūtu sarakstā ir pievienoti nerediģējami vecāka realitātes atribūti (19. att.).

Papildus tam katrai no realitātēm tika pievienotas attiecīgās ārējās atslēgas atkarībā no

to sasaistēm. Loģiskajā shēmā, tāpat kā konceptuālajā modelī ir atļauta realitāšu

pievienošana, kā arī saišu definēšana.

19. att. Bērna realitātes atribūtu saraksts

6 FIZISKAIS DATU MODELIS

6.1 Fiziskā modeļa izveide

Kad ir izveidots loģiskais modelis un ieviesti nepieciešamie papildinājumi, var

turpināt ar fiziskā modeļa izveidi, kas pēc būtības bija iespējams arī pēc konceptuālā

modeļa izveides posma.

Lai izveidotu fizisko modeli, nepieciešams augšējā izvēlnē izvēlēties Tools →

Generate Physical Data Model, kā rezultātā atvērsies ģenerēšanas uzstādījumu logs,

līdzīgi kā loģiskā modeļa ģenerēšanas gadījumā (20. att.).

20. att. Fiziskā modeļa izveides uzstādījumiNo attēla redzams, ka fiziskais modelis jau eksistē un ir iespējama tā

atjaunināšana – šim nolūkam no izvēlnes tiek izvēlēts attiecīgais modelis, kā arī datu

bāzes vadības sistēma, kas šoreiz ir Oracle 11g. Jauna fiziskā modeļa izveides

gadījumā, tāpat kā loģiskā modeļa izveides posmā, tiek piedāvāti gandrīz visi tie paši

uzstādījumi – gan modeļa nosaukums, gan tā pārbaudes, gan iekļaujamie objekti.

Jāmin, ka detaļu sadaļā papildus klāt nāk jaunu uzstādījumu kopa (21. att.), piemēram,

tabulu prefiksu definēšana, primāro un ārējo atslēgu nosaukšanas formāts, saistīto

ierakstu atjaunināšanas un dzēšanas likumi.

21. att. Detaļu sadaļa fiziskā modeļa ģenerēšanas posmāRezultātā tiek iegūts fiziskais modelis (22. att.).

22. att. Fiziskais datu modelisKatrai no izveidotajām tabulām (nevis realitātēm) ir pieejams krietni plašāks

uzstādījumu klāsts nekā iepriekšējos modeļos. Klikšķinot uz tabulu, tiks atvērts

tabulas uzstādījumu logs (23. att.).

23. att. Tabulas uzstādījumu maiņaTabulas uzstādījumu logā ir pieejamas vairākas sadaļas, kuru papildināšana

fiziskā modeļa līmenī var noderēt datu bāzes izveidē. Vispārējo uzstādījumu sadaļā kā

jau iepriekš pieejama tabulas nosaukuma, koda, apraksta un stereotipa maiņa,

savukārt papildus klāt nāk īpašnieka pievienošana un uzstādīšana, dimensiju tips

(neviens, faktu, dimensiju), tabulas tips (relāciju, objektu, XML vai temporālā).

Kolonnu sadaļa satur visas tabulas kolonnas, tajā skaitā ārējās atslēgas un mantošanas

rezultātā iegūtās kolonnas – šeit ir iespējama kolonnu tipu maiņa, primārās atslēgas

noteikšana, kā arī obligātas aizpildīšanas uzstādīšana. Indeksu sadaļa paredz jaunu

indeksu izveidi papildus jau automātiski noģenerētajiem (primārā, ārējā atslēga).

Savukārt trigeru sadaļa ļauj veidot jaunus trigerus, kas nodrošinās darbību izpildi pie

noteiktām operācijām. Lietderīgi izmantot arī fizisko uzstādījumu sadaļu, kas nosaka

kādā veidā tiek glabāta tabula, vai tā ir klāstera daļa utt. Visbeidzot priekšskatījuma

sadaļā iespējams redzēt izveidoto SQL skriptu tabulas izveidei.

6.2 Skripta iegūšana

Lai ģenerētu datu bāzi no fiziskā modeļa, augšējā izvēlnē jāizvēlas Database

→ Generate Database. Parādās logs, kurā iespējams norādīt veidojamās datu bāzes

parametrus. Pastāv divas iespējas – izveidot SQL skripta failu norādītajā direktorijā

(Script generation) vai realizēt datu bāzes shēmu pa tiešo datu bāzē (Direct

generation). Šajā reizē tiks izvēlēta skripta ģenerēšana direktorijā pēc noklusējuma

(24. att.).

24. att. Datu bāzes ģenerēšanas uzstādījumu veikšanaNospiežot pogu OK, tiks veikta modeļa pārbaude, kā arī skripta faila

ģenerēšana. Tad, kad skripts ir izveidots, tas tiek importēts datu bāzē, izmantojot

SQL*Plus rīku (25. att.).

25. att. Izveidotās tabulas

7 APVĒRSTĀ INŽENIERIJA

7.1 Fiziskā modeļa iegūšana, izmantojot .sql failu

Apvērstā inženierija pēc savas būtības paredz gala produkta analīzi, lai iegūtu

tā sākotnējo shēmu – šajā gadījumā iegūtās datu bāzes shēmas analīzi, ko raksturo

uzģenerētais SQL skripts, pārveidošanu diagrammu veidā. Lai veiktu šo

pārveidošanu, no augšējās izvēlnes jāizvēlas Database → Update Model from

Database, kā rezultātā atvērsies datu bāzes apvērstās inženierijas uzstādījumu logs.

Logs sastāv no 3 sadaļām – selekcija (datu avota izvēle – fails vai datu bāze), opcijas

(atsauču, primāro atslēgu izveide, rakstzīmju kopa u.c. uzstādījumi) (27. att.) un

mērķa modelis (var tikt izvēlēts modelis, kurā tiks ievietots rezultāts). Izvēloties

iepriekš izveidoto .sql failu un nospiežot pogu OK, tiek veikta fiziskā modeļa

ģenerēšana (26. att.).

26. att. Apvērstās inženierijas uzstādījumi

27. att. Apvērstās inženierijas uzstādījumu opciju sadaļaRezultātā tiek iegūts jauns fiziskais modelis (28. att.).

28. att. Iegūtais fiziskais modelisTāpat kā iepriekš no konceptuālā modeļa tika ģenerēts loģiskais modelis,

savukārt no loģiskā – fiziskais, šoreiz no fiziskā modeļa tiks ģenerēts loģiskais un tad

no loģiskā – konceptuālais. Rezultātā tikai iegūts loģiskais modelis (29. att.) un

konceptuālais modelis (30. att.).

29. att. Iegūtais loģiskais modelis

30. att. Iegūtais konceptuālais modelisSalīdzinot iegūto konceptuālo modeli ar sākotnēji izveidoto, ir novērojams 2

problēmas – pirmkārt, vājā realitāte (rezultāti) netiek pareizi attēlota un otrkārt, arī

mantošana ir notikusi neprecīzi, jo bērnu realitātes satur vecāka realitātes atribūtus,

piemēram, braucēja realitāte satur gan darbinieka vārdu, gan uzvārdu – tieši tāpat kā

darbinieku realitāte. Citā ziņā realitātes un attieksmes starp tām ir diezgan precīzi

atspoguļotas.

7.2 Fiziskā modeļa iegūšana, izmantojot pieslēgšanos datu avotam

Gadījumā, ja fiziskā modeļa iegūšanai netiek izmantots .sql skripts, bet gan

tieša piekļūšana datu avotam, tad pirms fiziskā modeļa ģenerēšanas uzsākšanas tiek

piedāvāts uzstādījumu veikšanas logs (31. att.).

31. att. Fiziskā modeļa iegūšana caur tiešu pieslēgšanos datu avotam

Atšķirībā no fiziskā modeļa ieguves no .sql faila, pieslēgšanās datu avotam

ļauj atzīmēt izvēlamās tabulas, skatus, lietotājus, lomas, trigerus utt., kā arī tam

pakārtotos raksturlielumus, piemēram, tabulai tās ir primārās atslēgas, ārējās atslēgas,

statistika (atšķirīgo vērtību skaits kolonnā, vidējais simbolu tipa lauka garums, u.c.)

utt., savukārt lietotājiem tās ir privilēģijas utt., turklāt pastāv iespēja skatus importēt

kā tabulas. Papildus tam ir iespēja atlasīt objektus pēc lietotāja – īpašnieka.

Šajā gadījumā modeļa izveides process ir ilgāks, taču to var izskaidrot ar pašu

datu bāzes apstrādi (piemēram, sasaistu izveide starp tabulām) un plašu importa

konfigurēšanas iespējamību. Gala rezultātā iegūtais fiziskais modelis ir identisks tam,

kas tika iegūts par importa pamatu izmantojot .sql failu.

7.3 Cita veida apvērstā inženierija

Neskaitot fiziskā modeļa iegūšana ar apvērstās inženierijas palīdzību,

PowerDesigner rīks spēj pielietot apvērsto inženieriju arī citos gadījumos:

a) XML modeļa izveide, izejot no XML shēmas (32. att.);

b) objektorientētu pirmteksta failu izmantošana objektorientēta modeļa (klašu

diagrammu) izveidē (tiek atbalstītas JAVA, IDL, PowerBuilder, XML, C#, VB,

VB.NET valodas) (33. att.);

c) pirmteksta failu (BPEL4WS, WSBPEL, ebXML BPSS valodas)

izmantošana biznesa procesa modeļu izveidē (34. att., 35. att.).

32. att. XML modeļa iegūšana no .xsd faila

33. att. Klašu diagrammu iegūšana no .java faila

34. att. Biznesa procesa diagrammas iegūšana no .bpel faila

35. att. Biznesa procesa diagrammas iegūšana (procesa apskats)

8 SECINĀJUMI

Praktiskā darba gaitā tika galvenokārt pētīta Sybase PowerDesigner 16.5

versijas CASE rīka darbība, kā arī iegūto rezultātu kontrolei izmantota Oracle 11gR2

DBVS un TOAD for Oracle 10.6 rīks.

Īpaša uzmanība tika pievērsta rīka piedāvātajām iespējām modeļu uzbūvē,

saistītu modeļu ģenerēšanai un apvērstai inženierijai. Patīkami pārsteidza ērtā

saskarne, kas skaidri nodalīja ekrānu 3 daļās – izveidotie objekti, darba virsma un

modeļa elementu palete, kā arī tas, ka saistītu modeļu (loģiskais, fiziskais) izveidei

nav jāpatērē atsevišķi laiks, lai veiktu, piemēram, elementu definīciju, jo modelis tiek

uzģenerēts uzreiz pēc lietotāja pieprasījuma. Tādējādi var teikt, ka datu bāzes shēmas

iegūšana, lai arī no 3 nosacītiem soļiem sastāvoša, tomēr balstās gandrīz vienīgi uz

konceptuālā modeļa izveidi. Jāuzsver arī salīdzinoši plašais piedāvāto notāciju klāsts,

kas ir atkarīgs no veidojamā modeļa, kā arī lielais DBVS saraksts, ko šis rīks atbalsta

uz abām pusēm – gan skripta ģenerēšanas, gan apvērstās inženierijas ziņā.

Pēc tam, kad konceptuālais modelis tiek izveidots, tas tiek pārbaudīts uz kļūdu

esamību, taču arī novērtēts vēlamu uzlabojumu ieviešanai – tas var palīdzēt nākotnē

izvairīties no nepatīkamām situācijām, kuras radušās līdz galam nepārdomāta datu

bāzes modeļa izveides rezultātā. Ja kļūdas netiek atrastas, tiek noģenerēts loģiskais

datu modelis, kurš sniedz iespēju projektētājam pārbaudīt kā izskatīsies datu bāze,

turklāt neatkarīgi no izmantojamās DBVS platformas. Savukārt fiziskais modelis jau

ņem vērā izvēlēto DBVS un tās īpatnības. Arī fiziskais modelis ir vienkārši

pārveidojams uz datu bāzes shēmas ģenerēšanas skriptu. Tieši tāds pats ceļš eksistē uz

otru pusi, proti, apvērstās inženierijas izskatā. Diemžēl prasīt pilnīgi identiskus

konceptuālos modeļus pirms un pēc apvērstās inženierijas iegūšanas ir sarežģīti, taču

jāsaka, ka pēc loģikas abi modeļi ir ļoti līdzīgi.

Kopumā var teikt, ka CASE rīka izpēte ir izdevusies – ir izpētītas tā galvenās

iespējas attiecībā pret relāciju datu bāzes izveidi, izejot no izveidota konceptuālā

modeļa, kā arī veiksmīgi novērtēta iegūtās struktūras atbilstība vēlamajam.

9 IZMANTOTĀ LITERATŪRA

1) http://www54.sap.com/pc/tech/database/software/powerdesigner-data-

architect/index.html

2) http://infocenter.sybase.com/help/index.jsp?topic=/

com.sybase.infocenter.help.pd.16.5/doc/html/title.html

3) http://download.101com.com/tdwi/SolGateway/Sybase/

Sybase_PD_for_DataArchitecture_ds.pdf

10PIELIKUMI

Datu bāzes shēmas ģenerēšanas skripts

/

*============================================================

==*/

/* DBMS name: ORACLE Version 11g */

/* Created on: 14.10.2013. 2:08:45 */

/

*============================================================

==*/

alter table "Atbalsta"

drop constraint FK_ATBALSTA_ATBALSTA_SPONSORS;


drop constraint FK_ATBALSTA_ATBALSTA2_KOMANDA;

alter table "Braucejs"

drop constraint FK_BRAUCEJS_INHERITAN_DARBINIE;


drop constraint FK_BRAUCEJS_PARSTAV_KOMANDA;

alter table "Fiziska persona"

drop constraint "FK_FIZISKA _INHERITAN_SPONSORS";

alter table "Izmanto"

drop constraint FK_IZMANTO_IZMANTO_VADITAJS;


drop constraint FK_IZMANTO_IZMANTO2_STRATEGI;

alter table "Jauns ligums"

drop constraint "FK_JAUNS LI_INHERITAN_LIGUMS";

alter table "Juridiska persona"

drop constraint FK_JURIDISK_INHERITAN_SPONSORS;

alter table "Komanda"

drop constraint FK_KOMANDA_PIEDER_BAZE;

alter table "Ligums"

drop constraint FK_LIGUMS_EKSISTE_DARBINIE;

alter table "Mehanikis"

drop constraint FK_MEHANIKI_INHERITAN_DARBINIE;


drop constraint FK_MEHANIKI_STRADA_KOMANDA;

alter table "Pagarinats ligums"

drop constraint FK_PAGARINA_INHERITAN_LIGUMS;

alter table "Rezultats"

drop constraint FK_REZULTAT_GUST_BRAUCEJS;


drop constraint "FK_REZULTAT_TIEK IEGU_TRASE";

alter table "Vaditajs"

drop constraint FK_VADITAJS_INHERITAN_DARBINIE;


drop constraint FK_VADITAJS_VADA_KOMANDA;

drop index "Atbalsta2_FK";

drop index "Atbalsta_FK";

drop table "Atbalsta" cascade constraints;

drop index "Parstav_FK";

drop table "Braucejs" cascade constraints;

drop table "Baze" cascade constraints;

drop table "Darbinieks" cascade constraints;

drop table "Fiziska persona" cascade constraints;

drop index "Izmanto2_FK";

drop index "Izmanto_FK";

drop table "Izmanto" cascade constraints;

drop table "Jauns ligums" cascade constraints;

drop table "Juridiska persona" cascade constraints;

drop index "Pieder_FK";

drop table "Komanda" cascade constraints;

drop index "Eksiste_FK";

drop table "Ligums" cascade constraints;

drop index "Strada_FK";

drop table "Mehanikis" cascade constraints;

drop table "Pagarinats ligums" cascade constraints;

drop index "Tiek ieguts_FK";

drop index "Gust_FK";

drop table "Rezultats" cascade constraints;

drop table "Sponsors" cascade constraints;

drop table "Strategija" cascade constraints;

drop table "Trase" cascade constraints;

drop index "Vada_FK";

drop table "Vaditajs" cascade constraints;

/

*============================================================

==*/

/* Table: "Atbalsta" */

/

*============================================================

==*/

create table "Atbalsta"

(

S_ID NUMBER(3) not null,

K_ID NUMBER not null,

"AT_No" DATE,

"AT_Lidz" DATE,

constraint PK_ATBALSTA primary key (S_ID, K_ID)

);

/

*============================================================

==*/

/* Index: "Atbalsta_FK" */

/

*============================================================

==*/

create index "Atbalsta_FK" on "Atbalsta" (

S_ID ASC

);

/

*============================================================

==*/

/* Index: "Atbalsta2_FK" */

/

*============================================================

==*/

create index "Atbalsta2_FK" on "Atbalsta" (

K_ID ASC

);

/

*============================================================

==*/

/* Table: "Braucejs" */

/

*============================================================

==*/

create table "Braucejs"

(

D_ID NUMBER(5) not null,


"D_Vards" VARCHAR2(30) not null,

"D_Uzvards" VARCHAR2(30) not null,

"BR_Formulas_nr" NUMBER(2) not null,

"BR_Tautiba" VARCHAR2(30) not null,

constraint PK_BRAUCEJS primary key (D_ID)

);

/

*============================================================

==*/

/* Index: "Parstav_FK" */

/

*============================================================

==*/

create index "Parstav_FK" on "Braucejs" (

K_ID ASC

);

/

*============================================================

==*/

/* Table: "Baze" */

/

*============================================================

==*/

create table "Baze"

(

B_ID NUMBER(3) not null,

"B_Valsts" CHAR(3) not null,

"B_Regions" VARCHAR2(30) not null,

"B_Pilseta" VARCHAR2(50) not null,

constraint PK_BAZE primary key (B_ID)

);

/

*============================================================

==*/

/* Table: "Darbinieks" */

/

*============================================================

==*/

create table "Darbinieks"

(




constraint PK_DARBINIEKS primary key (D_ID)

);

/

*============================================================

==*/

/* Table: "Fiziska persona" */

/

*============================================================

==*/

create table "Fiziska persona"

(


"S_Summa" NUMBER(8) not null,

"S_No" DATE not null,

"S_Lidz" DATE not null,

"FP_Vards" VARCHAR2(30) not null,

"FP_Uzvards" VARCHAR2(30) not null,

"FP_ID_numurs" CHAR(12) not null,

"FP_Dzimums" CHAR(1)

constraint CKC_FP_DZIMUMS_FIZISKA check ("FP_Dzimums" is null

or ("FP_Dzimums" in ('V','S'))),

constraint "PK_FIZISKA PERSONA" primary key (S_ID)

);

/

*============================================================

==*/

/* Table: "Izmanto" */

/

*============================================================

==*/

create table "Izmanto"

(


ST_ID NUMBER(3) not null,

"A1_Trases_tips" CHAR(2),

constraint PK_IZMANTO primary key (D_ID, ST_ID)

);

/

*============================================================

==*/

/* Index: "Izmanto_FK" */

/

*============================================================

==*/

create index "Izmanto_FK" on "Izmanto" (

D_ID ASC

);

/

*============================================================

==*/

/* Index: "Izmanto2_FK" */

/

*============================================================

==*/

create index "Izmanto2_FK" on "Izmanto" (

ST_ID ASC

);

/

*============================================================

==*/

/* Table: "Jauns ligums" */

/

*============================================================

==*/

create table "Jauns ligums"

(

L_ID NUMBER(5) not null,

D_ID NUMBER(5),

"L_No" DATE not null,

"L_Lidz" DATE not null,

"L_Summa" NUMBER(8) not null,

"JL_Summa_ieprieks_kom" NUMBER(7),

constraint "PK_JAUNS LIGUMS" primary key (L_ID)

);

/

*============================================================

==*/

/* Table: "Juridiska persona" */

/

*============================================================

==*/

create table "Juridiska persona"

(





"JP_Nosaukums" VARCHAR2(50) not null,

"JP_Numurs" VARCHAR2(20),

constraint "PK_JURIDISKA PERSONA" primary key (S_ID)

);

/

*============================================================

==*/

/* Table: "Komanda" */

/

*============================================================

==*/

create table "Komanda"

(


B_ID NUMBER(3) not null,

"K_Nosaukums" VARCHAR2(30) not null,

"K_Krasa" NUMBER(6) not null,

"K_Dzinejs" VARCHAR2(30) not null,

"K_Darbinieku_skaits" NUMBER(4) not null,

constraint PK_KOMANDA primary key (K_ID)

);

/

*============================================================

==*/

/* Index: "Pieder_FK" */

/

*============================================================

==*/

create index "Pieder_FK" on "Komanda" (

B_ID ASC

);

/

*============================================================

==*/

/* Table: "Ligums" */

/

*============================================================

==*/

create table "Ligums"

(






constraint PK_LIGUMS primary key (L_ID)

);

/

*============================================================

==*/

/* Index: "Eksiste_FK" */

/

*============================================================

==*/

create index "Eksiste_FK" on "Ligums" (

D_ID ASC

);

/

*============================================================

==*/

/* Table: "Mehanikis" */

/

*============================================================

==*/

create table "Mehanikis"

(





"M_Specializacija" VARCHAR2(50) not null,

"M_Statuss" VARCHAR2(30) not null,

constraint PK_MEHANIKIS primary key (D_ID)

);

/

*============================================================

==*/

/* Index: "Strada_FK" */

/

*============================================================

==*/

create index "Strada_FK" on "Mehanikis" (

K_ID ASC

);

/

*============================================================

==*/

/* Table: "Pagarinats ligums" */

/

*============================================================

==*/

create table "Pagarinats ligums"

(


D_ID NUMBER(5),




"PL_Ilgums" DATE not null,

"PL_Skaits" NUMBER(2) not null,

constraint "PK_PAGARINATS LIGUMS" primary key (L_ID)

);

/

*============================================================

==*/

/* Table: "Rezultats" */

/

*============================================================

==*/

create table "Rezultats"

(


T_ID NUMBER(3) not null,

"R_Punkti" INTEGER,

constraint PK_REZULTATS primary key (D_ID, T_ID)

);

/

*============================================================

==*/

/* Index: "Gust_FK" */

/

*============================================================

==*/

create index "Gust_FK" on "Rezultats" (

D_ID ASC

);

/

*============================================================

==*/

/* Index: "Tiek ieguts_FK" */

/

*============================================================

==*/

create index "Tiek ieguts_FK" on "Rezultats" (

T_ID ASC

);

/

*============================================================

==*/

/* Table: "Sponsors" */

/

*============================================================

==*/

create table "Sponsors"

(





constraint PK_SPONSORS primary key (S_ID)

);

/

*============================================================

==*/

/* Table: "Strategija" */

/

*============================================================

==*/

create table "Strategija"

(

ST_ID NUMBER(3) not null,

"ST_Pit_stop_sk" NUMBER(2) not null,

"ST_Riepas" CHAR(2) not null

constraint CKC_ST_RIEPAS_STRATEGI check ("ST_Riepas" in

('H','M','S','SS','I','FW')),

constraint PK_STRATEGIJA primary key (ST_ID)

);

/

*============================================================

==*/

/* Table: "Trase" */

/

*============================================================

==*/

create table "Trase"

(

T_ID NUMBER(3) not null,

"T_Nosaukums" VARCHAR2(50) not null,

"T_Valsts" VARCHAR2(30) not null,

"T_Garums" NUMBER(2) not null,

"T_Gads" NUMBER(4) not null,

"T_Ietilpiba" NUMBER(5) not null,

constraint PK_TRASE primary key (T_ID)

);

/

*============================================================

==*/

/* Table: "Vaditajs" */

/

*============================================================

==*/

create table "Vaditajs"

(





"V_Kategorija" VARCHAR2(30) not null,

"V_Licences_nr" VARCHAR2(15) not null,

constraint PK_VADITAJS primary key (D_ID)

);

/

*============================================================

==*/

/* Index: "Vada_FK" */

/

*============================================================

==*/

create index "Vada_FK" on "Vaditajs" (

K_ID ASC

);


add constraint FK_ATBALSTA_ATBALSTA_SPONSORS foreign key

(S_ID)

references "Sponsors" (S_ID);


add constraint FK_ATBALSTA_ATBALSTA2_KOMANDA foreign key

(K_ID)

references "Komanda" (K_ID);


add constraint FK_BRAUCEJS_INHERITAN_DARBINIE foreign key

(D_ID)

references "Darbinieks" (D_ID);


add constraint FK_BRAUCEJS_PARSTAV_KOMANDA foreign key

(K_ID)


alter table "Fiziska persona"

add constraint "FK_FIZISKA _INHERITAN_SPONSORS" foreign key

(S_ID)



add constraint FK_IZMANTO_IZMANTO_VADITAJS foreign key (D_ID)

references "Vaditajs" (D_ID);


add constraint FK_IZMANTO_IZMANTO2_STRATEGI foreign key

(ST_ID)

references "Strategija" (ST_ID);

alter table "Jauns ligums"

add constraint "FK_JAUNS LI_INHERITAN_LIGUMS" foreign key

(L_ID)

references "Ligums" (L_ID);

alter table "Juridiska persona"

add constraint FK_JURIDISK_INHERITAN_SPONSORS foreign key

(S_ID)


alter table "Komanda"

add constraint FK_KOMANDA_PIEDER_BAZE foreign key (B_ID)

references "Baze" (B_ID);

alter table "Ligums"

add constraint FK_LIGUMS_EKSISTE_DARBINIE foreign key (D_ID)



add constraint FK_MEHANIKI_INHERITAN_DARBINIE foreign key

(D_ID)



add constraint FK_MEHANIKI_STRADA_KOMANDA foreign key

(K_ID)


alter table "Pagarinats ligums"

add constraint FK_PAGARINA_INHERITAN_LIGUMS foreign key

(L_ID)

references "Ligums" (L_ID);


add constraint FK_REZULTAT_GUST_BRAUCEJS foreign key (D_ID)

references "Braucejs" (D_ID);


add constraint "FK_REZULTAT_TIEK IEGU_TRASE" foreign key (T_ID)

references "Trase" (T_ID);


add constraint FK_VADITAJS_INHERITAN_DARBINIE foreign key

(D_ID)



add constraint FK_VADITAJS_VADA_KOMANDA foreign key (K_ID)


Date post:	31-Aug-2019
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

datubaze.files.wordpress.com€¦ · Web viewRĪGAS TEHNISKĀ UNIVERSITĀTE. Datorzinātnes un...

Documents