IEVADS 31. SYBASE 4

1.1. PowerDesigner 15.2..........................................................................................................42. PROBLĒMVIDES APRAKSTS 6

2.1. Motivācija.........................................................................................................................62.2. Problēmvides vispārējs apraksts.......................................................................................62.3. Datu bāzē ietvertās datu prasības......................................................................................6

3. KONCEPTUĀLAIS MODELIS83.1. Realitāšu-saišu diagrammas..............................................................................................83.2. Objekt-orientēts datu modelis...........................................................................................93.3. Konceptuālā modeļa notācijas..........................................................................................9

4. KONCEPTUĀLĀ MODEĻA IZVEIDOŠANA124.1. Realitāšu veidošana.........................................................................................................154.2. Domēnu veidošana..........................................................................................................174.3. Biznesa likumu definēšana..............................................................................................184.4. Realitāšu saišu veidošana................................................................................................21

4.4.1. Vājās realitātes veidošana........................................................................................234.4.2. Mantošanas veidošana.............................................................................................25

4.5. Stereotipu veidošana (transformāciju pārdefinēšana).....................................................265. JAUNI ELEMENTI 356. LOĢISKAIS MODELIS377. FIZISKAIS MODELIS 42

7.1. Fiziskā modeļa ģenerēšana..............................................................................................427.2. Ģenerētais fiziskais modelis............................................................................................437.3. Fiziskā modeļa sastāvdaļas.............................................................................................43

8. ATSKAIŠU VEIDOŠANA 459. DEFINĒJUMU PAREIZĪBAS KONTROLE 4810. PĀRVEIDOJUMU ANALĪZE 5011. IZVEIDOTĀ MODEĻA TESTĒŠANA 5512. SQL DATU BĀZES STRUKTŪRAS ĢENERĒŠNA 5913. APVĒRSTĀ INŽENIERIJA 60SECINĀJUMI64LITERATŪRAS SARAKSTS 65PIELIKUMS 66

IEVADS

Kā zināms PowerDesigner ir vadošo nozaru modelēšanas un metadatu vadības risinājums

datu arhitektūrai, informācijas arhitektūrai un uzņēmumu arhitektūrai. Un tas darbojas ar vairāk

kā 60 relāciju datu bāzu pārvaldības sistēmām. Līdz ar to mūsu darba uzdevumā tiek apskatītas

CASE rīka PowerDesigner 15.2 piedāvātās iespējas.

Uzsākot darbu tiek nodefinēta turpmākajā darbības laikā apskatāmā problēmvide. Mūsu

gadījumā tā ir Zemnieku saimniecība „Asie Kadiķi”, kas nodarbojas ar lopkopību: audzē gan

gaļas, gan piena liellopus. Dzīvnieki tiek apvienoti baros, kuri ganās pļavās. Saimniecības

saražotie produkti tiek pārdoti dažādām privātpersonām. Saimniecībā strādā dažādi darbinieki.

Kad tiek aprakstīta problēmvide, izveido realitāšu saišu diagrammu bez CASE rīka un,

kad tas tika izdarīts, tika uzsākts darbs ar PowerDesigner rīku. Rīkā izveidoja pirms tam ar roku

izveidoto realitāšu-saišu diagrammu. Tiek izveidots datu konceptuālais modelis, uz kura pamata

tiek ģenerēts datu loģiskais un fiziskai modelis.

Darba uzdevumā, kas tika veikts, ir apskatītas rīka piedāvātās iespējas, proti, saišu

veidošana, transformācijas, stereotipu veidošana, apvērstā inženierija, izveidotā modeļa

testēšana.

2

1. SYBASESybase ir līderis datu bāzu tehnoloģiju attīstībā un paplašināšanā. Sybase dibināts 1984.

gadā un ir nopelnījies uzticību daudzās vadošajās kompānijās pasaulē ar spēju pārvaldīt

informāciju un sniedzot nepārspējamu datu ticamības un drošības līmeni.

Sybase ir pasaulē lielākā biznesa programmatūras kompānija ar specializāciju

informācijas pārvaldībā un mobilizēšanā no datu centra līdz darbības vietai. Sybase piedāvā

atvērtus, risinājumus dažādām platformām, kas informāciju piegādā droši, jebkurā laikā, jebkurā

vietā, ļaujot klientiem izmantot informācijas priekšrocības. Pasaules svarīgākie komerciālie,

komunikāciju, finanšu, valsts pārvaldes un veselības aprūpes dati darbojas tieši ar Sybase.

Sybase produktu piegāde nodrošina ar nepieciešamo informāciju un pieteikumiem iegūt

darbiniekus, partnerus un klientus jebkurā laikā un jebkurā vietā. Sybase produkti reālajā laikā

vienmēr ir pieejami pilnībā integrēti un nodrošinot piekļuvi visai informācijai, kas atrodas

iekšējās sistēmās.

Kompānija piedāvā daudzveidīgu produktu klāstu, piemēram, biznesa inteliģencei,

mobilajiem risinājumiem, datubāzēm, izstrādei un integrācijai. Tā kā Sybase piedāvā daudzus

rīkus, tad visus nepieminam, kā tikai dažus no tiem, piemēram:

Adaptive Server Enterprise Sybase CEP Afaria

SQL Anywhere PowerBuilder iAnywhere Mobile Office

Advantage Database Server PowerDesigner Sybase Unwired Platform

Replication Server Sybase SMS 365 SQL Anywhere

RAP - The Trading Edition Sybase Operator Analytics 365 Sybase mBanking 365

Šajā darbā tiks aplūkots nozares vadošais datu modelēšanas un projektēšanas

PowerDesigner 15.2 rīks.

3

1.1. PowerDesigner 15.2

IT nozares datu modelēšanas un lietojumprogrammu projektēšanas instruments Nr. 1!

Uzņēmumiem, kam nepieciešams izveidot vai pārveidot lietojumprogrammas ātri, izdevīgi un

saskaņoti. PowerDesigner var uzņemties daudzas lomas un funkcijas lai uzlabot informatīvo

sistēmu kvalitāti, integritāti un izpildi.

PowerDesigner ir vadošo nozaru modelēšanas un metadatu vadības risinājums datu

arhitektūrai, informācijas arhitektūrai un uzņēmumu arhitektūrai. Un tas darbojas ar vairāk kā 60

relāciju datu bāzu pārvaldības sistēmām.

PowerDesigner v15.2 ietver jaunas iezīmes konceptuālajā, loģiskajā un fiziskajā datu

modelī. Būtiskākais jaunums likās, ka tagad ir izstrādāti jauni vedņi, ar kuru palīdzību var

importēt datus no Erwin CASE rīka un Excel izklājlapām. Tiek atbalstītas jaunas DBVS versijas:

Sybase IQ v15.2 un Sybase ASE v15.5. Tāpat arī tiek atbalstītas jaunas vides: Windows 7,

Windows 2008 Server,V3.5 Eclipse. Piedāvā jaunu notāciju- Barker notāciju.

PowerDesigner izmaksā no 7495 $ līdz 11495 $ saskaņā ar Sybase.

PowerDesigner rīka attīstības vēsturi var aplūkot Ilustrācija 1, kur pirmā rīka versija tika

palaista 1989. gadā, lai gan attēlā ir parādītas tikai 11 versijas, jāpiemin, ka šodien ir pieejam

15.2 versija, kura arī šajā darbā tiek aplūkota. Var redzēt to, ka no 1989 līdz 1996. gadam ir vecā

paaudze pilnība saistīta ar tradicionālo E/R. Savukārt no 1999 līdz šim gadam ir jaunā paaudze,

kas ir pārstrādāta iekļaujot UML un Biznesa modelēšanu.

4

Ilustrācija 1 PowerDesigner versiju vēsture

2. PROBLĒMVIDES APRAKSTS

2.1. Motivācija

Mūsdienās lielākā daļa datu bāzu ir saistītas ar tādām jomām kā finanses, tirdzniecība,

transports, noliktavu uzskaite utml. Taču tās nav vienīgās jomas, kur var veidot datu bāzes. Tiek

izvēlēts veidot datu bāzi jomā, kur tās parasti netiek lietotas – lauksaimniecībā.

2.2. Problēmvides vispārējs apraksts

Zemnieku saimniecība „Asie Kadiķi” nodarbojas ar lopkopību: audzē gan gaļas, gan

piena liellopus. Dzīvnieki tiek apvienoti baros, kuri ganās pļavās. Saimniecības saražotie

produkti tiek pārdoti dažādām privātpersonām. Saimniecībā strādā dažādi darbinieki.

5

2.3. Datu bāzē ietvertās datu prasības

Katram liellopam tiks uzskaitīts tā vārds, pēc kura katrs dzīvnieks tiks identificēts, svars

(kilogramos), dzimums un suga: Hereforas (HE), Anguss (AN), Latvijas brūnā (LB), Šarolē

(SH).

Katrs liellops var piederēt tikai vienam baram, kas tiek identificēts pēc bara numura.

Katrā barā ir noteikts skaits dzīvnieku. Pļavas, kurās ganās dzīvnieki, tiek identificētas pēc

vārdiem, turklāt vēl datu bāzē par katru pļavu tiek glabāts tās zemesgrāmatas numurs, kadastrālā

ērtība un maksimālais dzīvnieku skaits, kas var atrasties uz šīs pļavas (šo noteikuši paši

saimniecības īpašnieki). Katrs dzīvnieku vienā laika momentā ganās vienā pļavā, taču katrā pļavā

dažādos laika momentos var ganīties dažādi bari. Tiek uzskaitīts, no kura laika katrā pļavā katrs

bars sāk ganīties. Lai pļavās paspētu ataugt zālē, pļavā dzīvnieki var arī neganīties.

Saimniecības darbiniekiem tiek saglabāts vārds, personas kods, amats (piemēram, kopējs,

veterinārārsts, zootehniķis un traktorists utml.) un noteiktā mēnešalga. Tā kā par vienu baru ir

atbildīgi vairāki darbinieki, jo tie veic dažādus uzdevumus, tāpat katrs darbinieks ir atbildīgs par

vienu vai vairākiem bariem, līdz ar to veidojas attiecības n:m.

Saimniecībā tiek ražoti divu veidu produkti: dzīvnieks var kļūt par gaļu vai arī vairākas

reizes var dot pienu. Par katru radīto produktu saglabājams tā derīguma termiņš, tips (gaļa vai

piens) un daudzums. Produkts nevar eksistēt, ja nav zināms, dzīvnieks, no kura tas radies.

Saimniecības radītie produkti (piens un gaļa) tiek pārdoti dažādiem pircējiem (personām),

par kuriem tiek glabāts vārds, personas kods un adrese. Pircēji veic pirkumus, turklāt, lai

pirkuma fakts varētu notikt, nepieciešams gan viens pircējs, gan vismaz viens (vai vairāki)

produkti. Katrā pirkumā var būt dažāds daudzums dažādu produktu, bet datu bāzē glabājams

pirkuma veikšanas datums un kopsumma.

Sākotnējo izstrādāto konceptuālo modeli var apskatīt Ilustrācija 2.

6

Ilustrācija 2 Sākotnējais konceptuālais modelis

7

3. KONCEPTUĀLAIS MODELISKonceptuālais datu modelis, šo modeli dažreiz sauc par domēnu modeli, kuru parasti

izmanto, lai izpētītu domēna koncepcijas ar projektā ieinteresētajām pusēm. Datu bāzes dizains

sākās konceptuālajā līmenī līdz ar konceptuālā modeļa veidošanu. Konceptuālais modelis

atspoguļo vispārīgo datubāzes struktūru, kas ir neatkarīga no jebkuras programmatūras vai datu

glabātuves veida. Šajā līmenī arī tiek apdomāti un ietverti datu objekti, kurus plāno implementēt

fiziskajā datu bāzē.

Konceptuālais modelis atļauj veidot realitāšu – saišu diagrammas, uzģenerēt fizisko

modeli, uzģenerēt objektorientētu modeli (OOM), kas specificē konceptuālo modeli izmantojot

UML standartu.

3.1. Realitāšu-saišu diagrammas

ER (Entity-Relationship) modelis ir datu konceptuālais modelis ko 1976. gadā izstrādāja

P. Čens (Chen), lai atvieglotu datu bāzes projektēšanu. ER diagrammas pamatelementi ir:

a) realitātes tipi (entity type);

b) atribūti;

c) saites tipi.

Realitātes tips ir priekšmetiskās vides noteikta objektu, subjektu vai procesu klase.

Realitāte ir realitātes tipa eksemplārs (entity instance, entity occurance). Tipam parasti ir daudz

eksemplāru. Realitātes tipus var sadalīt: patstāvīgos realitātes tipos (parent, owner, dominant);

pakārtotos realitātes tipos (child, dependent, subordinate).

ER modelim ir daudz ierobežojumu. Lai varētu pilnvērtīgāk veidot datu bāzes datu

konceptuālo modeli tika izveidots ER modeļa paplašinājums – Paplašinātais ER modelis (EER).

ER modelis tiek paplašināts ar superklases un apakšklases jēdzieniem. Superklases realitāte ir

patstāvīga realitāte, kas ietver sevī apakšklases realitātes. Apakšklases realitātes ir patstāvīgas

realitātes, kuras superklasē veido vienotu loģisko apvienojumu. Superklases un apakšklases

realitāšu attiecības var modelēt arī atribūtu mantošanu (specialization, generalization).

Parēja no ER diagrammas uz tabulu sākotnējo struktūru notiek, ievērojot pārveidojumu

vai transformāciju likumus:

1) ER modeļa realitāte pārvēršas par tabulu;

2) ER modeļa realitātes atribūts pārvēršas par tabulas lauku;

3) ER modeļa realitāšu saite var pārvērsties par attiecīgo tabulu saiti, bet ja saitei ir atribūti, tad

izveidotie arī jauna tabula.

3.2. Objekt-orientēts datu modelis

Objektorientētā 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.

Statisko struktūru modelēšanai UML lieto Klašu diagrammu. To lieto lai identificētu

objektus, kas sastāda sistēmu un noteiktu, kā tie ir savstarpēji saistīti. Klase atspoguļo objektu

kopu un asociācijas apraksta saišu kopu. Klašu diagrammas elementi nodrošina loģisko

skatījumu uz sistēmu kopumā vai tās daļām. Klašu diagrammas būvē, lai vienkāršotu

modelējamās sistēmas objektu mijiedarbību.

Objektu transformācija no konceptuālā modeļa uz objekt-orientētu modeli.

Konceptuālā modeļa objekti OOM objekti

Realitāte Klase

Realitātes atribūts Klases atribūts

Primārais identifikators Identifikators

Saite Saite (asociācija, agregācija, kompozīcija

Asociācija Klase, piesaistīta asociācijas saitei, kas

savieno 2 citas klases

Asociācijas linki Saites, kas saista iepriekšminēto klasi ar citām

klasēm

Mantošana Vispārināšana

9

3.3. Konceptuālā modeļa notācijas

PowerDesigner 15.2 piedāvā veidot konceptuālo modeli ar Ilustrācija 3 redzamajām

notācijām.

Ilustrācija 3 Konceptuālā modeļa notācijas

Realitāšu-saišu notācija

Realitāšu saišu (Entity/Relationship) notācijā modeļi var veidot izmantojot sekojošus elementus:

1) realitāti;

2) saiti;

3) mantošanas saiti.

Merise notācija

Merise notācija modeļi var veidot izmantojot sekojošus elementus:

1) realitāti;

2) mantošanas saiti;

3) asociāciju;

4) asociācijas saiti.

E/R + Merise notācija

10

Ir pieejami visi Realitāšu-saišu un Merise notācijas elementi:

1) realitāti;

2) saiti;

3) mantošanas saiti;

4) asociāciju;

5) asociācijas saiti.

IDEF1X notācija

Notācija ļauj veidot tos pašus elementus, ko ļauj veidot realitāšu-saišu notācija, bet atšķirībā no

tās, IDEF1X notācijā tiek lietoti citi saišu grafiskie apzīmējumi. Papildus IDEF1X notācijā var

attēlot:

1) atkarīgas realitātes (dependent), jeb vājas realitātes, kad “bērna” realitāte nevar

pastāvēt bez “vecāka” realitātes;

Kā jaunums PowerDesigner 15.2 ir Barker notācija

Barker notācija modeļi var veidot izmantojot sekojošus elementus:

1) realitāti;

2) saiti;

11

4. KONCEPTUĀLĀ MODEĻA IZVEIDOŠANA

Uzsākot darbu Sybase Power designer 15.2 norādām, ka veidojam jaunu modeli

(Ilustrācija 4 – create model), vai arī ja darbs jau ir uzsākts ir iespēja atvērt vienu no nesen

apskatītajiem modeļiem (Ilustrācija 4 – recent models), ir iespēja izveidot projektu (create

project), atvērt jau esošu modeli vai projektu (open model or project), ir iespēja apskatīties

Sybase piedāvātos piemērus (Examples), skatīt palīdzības failu (help), saņemt informāciju par

jaunumiem Power Designer 15.2 versijā (What’s new in PowerDesigner 15.2), aplūkot

dokumentāciju un video materiālus (documentation and videos), iet uz PowerDesigner web lapu

(PowerDesigner Web site). Sākumā izvēlamies veidot jaunu modeli, atveras logs, kurā varam

izvēlēties kādu modeli veidosim, skatīt Ilustrācija 5

Ilustrācija 4. Sākuma logs

12

Kā redzams ilustrācija izvēloties modeli ir iespēja tos sakārtot pa kategorijām vai pa

modeļu tipiem. Šajā gadījumā izvēlamies pa kategorijām. Konceptuālais modelis atrodas

kategorijā Informācija (information), šajā kategorijā ir arī loģiskais un fiziskais datu modelis, kā

arī datu plūsmu diagramma, UML klašu diagramma, XML un daudzdimensionālo datu

diagramma. Izvēlamies konceptuālo datu modeli un ievadām tā nosaukumu. To izdarot atveras

Sybase modeļu veidošanas vide.

Ilustrācija 5. Modeļu veidi

Šobrīd modeļu veidošanas vides pārlūka daļā ir redzams tikai modeļa un diagrammas

nosaukums, sākot veidot realitātes tur parādās arī realitāšu sadaļa, definējot atribūtus realitātēm –

datu vienību sadaļa un tamlīdzīgi. Pirms sākt darbu norādām kādu notāciju izmantosim (rīkjoslā

izvēlamies Tools -> Model options), iespējamas šādas notācijas konceptuālā modeļa veidošanai:

Entity/Relationship,

Merise,

13

E/R + Merise,

IDEF1X,

Barkera notācijas.

Konceptuālā modeļa veidošanai izvēlamies E/R + Merise, jo šī notācija satur vairāk iespēju kā

pārējās notācijas (piemēram, asociāciju). Šajā īpašību logā tiek norādīts arī, ka saitēm un

atribūtiem tiks izmantoti unikāli kodi, ir atļauta atribūtu atkārtota lietošana un tiek izmantots datu

tipu pilns nosaukums (skatīt Ilustrācija 6).

Ilustrācija 6. Modeļa īpašību definēšana

Ērtai modeļa veidošanai ir pieejama palete, kas satur nepieciešamos objektus (skatīt

Ilustrācija 7). Palete satur gan realitāšu veidošanas objektu, gan saišu, mantošanas, asociāciju,

izgriešanas, modeļa palielināšanas, samazināšanas, papildus objektus modeļa

attēlošanai un citus objektus.

14

4.1. Realitāšu veidošana

Izvēlamies veidot realitāti , nospiežot divreiz datorpeles kreiso taustiņu atveras realitāšu

īpašību dialoglogs, skatīt Ilustrācija 8.

Ilustrācija 8. Realitāšu īpašību dialoglogs

Dialogloga vispārīgajā sadaļā (General) norādām realitātes nosaukumu, un norādām, ka

realitāte būs jāģenerē (ieliekot ķeksīti pie Generate) transformējot šo modeli loģiskajā un

fiziskajā. Savukārt sadaļā atribūti norādām atribūtus, to kodus, datu tipus, ja nepieciešams to

garumu, precizitāti, primāro atslēgu, vai atribūts tiks attēlots, vai atribūts ir obligāti jāaizpilda un

15

Ilustrācija 7. palete

ja ir norādām arī domēnu. Identifikatoru sadaļā tiek nodefinēts realitātes ID, piezīmju sadaļā ir

iespējams ierakstīt kādas piezīmes, ja ir nepieciešams kaut paskaidrot. Likumu sadaļā definējam

likumus, tas tiks apskatīts citā nodaļā. Izveidoto realitāti aplūkot Ilustrācija 9.

barsbara nrdzivn daudzums

<pi> IntegerInteger

<None><None>

<M><M>

Identifier_1...

<pi>

Ilustrācija 9. Realitāte

Rīkjoslā izvēlamies Tools->Display Preferences un izvēlamies īpašības, kuras ir

nepieciešams, lai tiktu attēlotas, piemēram, lai parādītu realitātes stereotipu, identifikatoru,

domēnu vai datu tipu, parādīt visus atribūtus, skatīt Ilustrācija 10.

Ilustrācija 10.dialoglogs Display Preferences

4.2. Domēnu veidošana

Domēns ir datu vienības iespējamo vērtību kopa, kuru var izmantot vairākas realitātes.

Lai izveidotu domēnu izvēlamies rīkjoslā izvēlamies Model->domains.. atveras dialoglogs, skatīt

Ilustrācija 11, kurā norādām domēna vārdu, kodu, datu tipu, garumu, precizitāti. Šādi domēnu

sarakstā (domain list) tiek pievienots jauns domēns, izvēlamies izveidoto domēnu no saraksta,

nospiežam uz domēna īpašībām, lai nodefinētu domēnu kopu, skatīt Ilustrācija 12.

16

Ilustrācija 11. Domēna nodefinēšana

Ilustrācija 12. Domēna datu kopas definēšana

17

Kā redzams augšējā attēlā, definējot domēna datu kopu ir iespējams norādīt arī noklusēto

vērtību, maksimālo, minimālo vērtību un citas īpašības. Kad domēns ir šādi nodefinēts to var

lietot realitātēs, kā jau iepriekš minēts, pie atribūtu definēšanas.

4.3. Biznesa likumu definēšana

Līdzīgi kā domēna definēšanā, arī biznesa likumu definēšanai izvēlamies Model->Business

Rules.. atveras dialoglogs, līdzīgi kā domēna definēšanā, kurā norādām biznesa likuma

nosaukumu un kodu, skatīt Ilustrācija 13.

Ilustrācija 13. Biznesa likumu definēšana

Nospiežot divreiz datorpeles kreiso taustiņu atveras dialoglogs, kurā vispārējā sadaļā

norādām likuma tipu(šoreiz validation) , izteiksmes sadaļā norādām, ka dzīvnieku daudzums

barā nevar būt lielāks kā 50, skatīt Ilustrācija 14. Tagad šo likumu var izmantot realitātēs, skatīt

Ilustrācija 15. Ja likums tiktu attēlots client pusē tas netiktu attēlots datu bāzē tas vairāk

dokumentācijai, tādēļ attēlojam server pusē.

18

Ilustrācija 14. Likuma definēšana

Ir iespējami šādi likumu tipi:

1) definition (Characteristics or properties of an object in the information system. Example: A

customer is a person identified by a name and an address.);

2) fact (Certainty or existence in the information system. Example: A client places one or more

orders.);

3) formula (Calculation used by the information system. Example: The total order is the sum of

all the order line costs.);

4) requirement (Functional specification in the information system. Example: The model is

designed so that total losses do not exceed 10% of total sales.);

5) validation (Constraint on a value in the information system. Example: Validation business

rules are generated in the database. Example: The sum of all order totals for a client must not be

greater than the allowance for the client.);

6) constraint (Additional check constraint on a value. You can assign multiple constraint

business rules to a table or a column. Constraint business rules are generated in the database.

Example: The start date should be inferior to the end date of a Project.).

19

Ilustrācija 15. Biznesa likuma pievienošana realitātei

4.4. Realitāšu saišu veidošana

Saite starp divām realitātēm ir loģiskas attieksme starp tām un attiecas uz divu realitāšu vienu

eksemplāru. Rīks PowerDesigner izdala divu tipu saites— atkarīgās un neatkarīgās. Neatkarīgās

(Independent) saites tiek uzstādītas arī starp vecāku un meitas realitātēm, bet meitas realitāte šajā

gadījumā paliek neatkarīga.

Lai izveidotu jaunu saiti paletē izvēlamies saites veidošanas objektu, nospiežam uz tā un turot

uz datorpeles kreisā taustiņa velkam saiti no vienas realitātes uz otru. Kad saite ir novilkta

atveram saites īpašību dialoglogu, kura vispārējā sadaļā iespējams norādīt:

saites nosaukumu (Name);

saites kodu (Code);

saites informatīvo aprakstu (Comment);

stereotipu (stereotype);

realitātes, kas savā starpā saistītas ar doto saiti (Entity1, Entity2);

norādi, par saites ģenerēšanu fiziskajā modelī (Generate);

sadaļā kardinalitāte (cardinality) ir iespējams norādīt:

20

Dominējošo lomu- attieksmē 1:1, norāda uz to, ka datu fiziskajā modelī jāveido

viena saite un tikai norādītājā virzienā (Dominant role);

Tekstu, kas raksturo attieksmi no realitātesA uz realitātiB (Role name);

Norādi uz to, ka katrs realitātesA eksemplārs tiek identificēts ar realitātesB

eksemplāru (Dependent);

Norādi uz to, ka katram realitātesA eksemplāram ir obligāti jābūt saistītam ar

realitātesB eksemplāru (Mandatory);

Norādi par maksimālo un minimālo realitātesA eksemplāru skaitu, kas ir saistīti ar

realitātiB (Cardinality).

Piezīmju sadaļā ir iespējams pievienot piezīmes, kā arī biznesa likumu sadaļā – ar saiti

saistītos biznesa likumus. Power Designer pieļauj sekojošus saišu veidus:

One-to-one <1..1> Pirmās realitātes viens eksemplārs var būt saistīts tikai ar vienu otrās realitātes

eksemplāru

One-to-many <1..n> Pirmās realitātes viens eksemplārs var būt saistīts ar otrās realitātes vairākiem

eksemplāriem.

Many-to-one <n..1> Pirmās realitātes vairāki eksemplāri var būt saistīti ar otrās realitātes vienu

eksemplāru.

Many-to-

many

<n..n> Pirmās realitātes vairāki eksemplāri var būt saistīti ar otrās realitātes vairākiem

eksemplāriem.

Ilustrācija 16 ir redzams saites īpašību dialoglogs, šajā gadījumā tiek veidota N:M saite

un atzīmējot izvēlni Mandatory, tiek norādīts, ka vienas realitātes eksemplāram ir vienmēr jābūt

saistītam ar otras realitātes eksemplāru (abos virzienos). Šajā gadījumā ir, ka katram darbiniekam

ir jāstrādā vismaz ar vienu vai vairākiem bariem, un katrā barā strādā vismaz viens vai vairāki

darbinieki. Līdzīgi tiek izveidotas arī pārējās saites.

21

Ilustrācija 16.Saites īpašību dialoglogs

Gadījumā, ja realitātes vieno saite 1:1, jānorāda, kurai no šim realitātēm būtu dominējošā

loma. Šajā konceptuālajā modelī šādas saites nav.

Ilustrācija 17 parāda izveidoto saiti starp realitātēm Bars un Darbinieks.

Ilustrācija 17. Saite starp realitātēm bars un darbinieks konceptuālajā modelī

4.4.1. Vājās realitātes veidošana

Vājā realitāte tiek izveidota norādot, ka saite ir atkarīga (Dependent). Atkarīgās saites

tiek uzstādītas starp neatkarīgo realitāti (vecāku realitāti) un atkarīgo realitāti (meitas realitāti).

Šajā gadījumā vecāku realitātes primārās atslēgas atribūti automātiski tiek pievienoti meitas

realitātes atribūtu sarakstam. Notiks it kā atribūtu migrācija. Vājajā realitātē iekļautie atribūti

kļūs par ārējām atslēgām (foreign key –FK). Ilustrācija 18 ir redzama saites starp dzīvnieku un

22

produktu veidošana. Tiek izveidota 1:N saite, kas nozīmē, ka no viena dzīvnieka tiek iegūti viens

vai vairāki produkti, kā arī tiek norādīts ar atkarību (dependent), ka realitāte produkts ir atkarīga

no realitātes dzīvnieks. Saitē vājā realitāte tiek apzīmēta ar .

Ilustrācija 18. Vājās realitātes veidošana

Šajā modelī vājās realitātes ir lietošana, produkts un pirkums. Ilustrācija 19 ir redzama

saite starp dzīvnieku un produktu, realitāte produkts ir vājā realitāte.

klust par

dzivniekssugasvarsdzivnieka_vardsdz_dzimums

<pi>

TextDecimalTextdzimums

<None><None><None>dzimums

<M>

<M>

Identifier_1 <pi>

produktstipsder terminssarazotais_daudzumstauku procuzglabasanas tempprodukta tipssastāvs

Variable characters (20)DateTextDecimalIntegerVariable characters (30)Variable characters (200)

<None><None><None><None><None><None><None>

<M><M><M>

Ilustrācija 19. Vājā realitāte

23

4.4.2. Mantošanas veidošana

Mantošana atļauj definēt vienu realitāti kā kādas citas realitātes speciālu gadījumu.

Galvenā realitāte tiek uzskatīta par supertipa (jeb „vecāks”) realitāti un tā satur visas kopīgās

īpašības. Speciālā gadījuma realitāte tiek saukta par apakštipa (jeb „bērns”) realitāti un satur tikai

daļu specifisko īpašību. Lai definētu mantošanas saiti, rīku paletē jāizvēlas ikona Inheritence.

Izdarot dubultklikšķi uz izveidotas saites, atveras saites īpašību logs, kurā iespējams noteikt

sekojošas saites īpašības:

mantošanas saites nosaukumu (Name);

kodu mantošanas saitei (Code);

mantošanas saites apraktu (Comment);

stereotipu (stereotype);

supertipa realitātes nosaukumu (Parent);

norādi, vai dalījums ir pilns (complete);

norādi vai savstarpēji izslēdzoša mantošana (mutually eclusive children)

īpašību kopumu, kas iespaido fizisko realizāciju(Generation – vai tiks ģenerēti bērni

vai vecāki un citas īpašības);

apakštipa realitāšu sarakstu (Children);

piezīmes, kas saistītas ar mantošanas saiti (Notes);

biznesa likumus, kas saistīti ar mantošanu;

Šajā modelī tiek izveidots mantošanas tips vispārinājums. Tiek norādīts, ka tiks ģenerēti

vecāki un tiek norādīts, ka būs pilns dalījums. Kā arī tiek izmantots stereotips s2, skatīt

Ilustrācija 20. Stereotips s2 tiek definēts līdzīgi kā stereotips classification, tādēļ skatīties

stereotipa definēšanas procedūru nodaļā 4.5.

24

Ilustrācija 20. Mantošanas saite

4.5. Stereotipu veidošana (transformāciju pārdefinēšana)

Stereotipi tiek pielietoti, lai klasificētu instances un apkopotu paplašinājumus

metaklasēm, kas atbalsta stereotipu konceptu. Stereotipi var tikt izmantoti arī lai izveidotu

metaklasi jau izvēlētajā metaklasē, tas tiek saukts par metaklašu stereotipiem. Šis mehānisms

iekļauj stereotipu jaunā metaklasē ar specifisku sarakstu pārlūkā. Vienai metaklasei var tikt

definēti vairāki stereotipi. Izveidotie stereotipi var tikt apstiprināti jebkurai metaklases instancei.

Stereotipu izmantošana tiek uzskatīta par vienas instances paplašināšanas mehānismu.

Stereotipus var izmantot arī mantošanā, vecāku stereotipa pazīmes tiek mantotas bērnu

stereotipiem.

Tā kā Power Designer nenodrošina klasifikācijas iespēju tad izvēlamies izveidot

paplašināto tipu klasifikācijas iespējamībai. Šajā gadījumā klasifikācija tiks veikta produktiem,

klasificēsim vai tas ir piena vai gaļas produkts. Mēs uzskatām, ka lai izveidotu klasifikāciju ir

jāveic mantošanas tipa paplašināšana. Tas var tikt veikts definējot tam stereotipu. Kā jau minēts

kā vecāku realitāte būs produkts un kā bērnu realitātes būs piena un gaļas produkti.

Ilustrācija 21 parāda mantošanas attiecības starp produktu un piena un gaļas produktu.

25

Classification

produktstipsder terminssarazotais_daudzumstauku procuzglabasanas tempprodukta tipssastāvs

Variable characters (20)DateTextDecimalIntegerVariable characters (30)Variable characters (200)

<None><None><None><None><None><None><None>

<M><M><M>

piena produkts galas produkts

Ilustrācija 21.mantošanas saite

Sākumā definēsim Classification stereotipu un tam atbilstošo simbolu. Lai to izdarītu

izvēlamies Model->Extended model definition. To izdarot atveras dialoglogs, kurā varam

nodefinēt jauno stereotipu, skatīt Ilustrācija 22.

.

Ilustrācija 22. Stereotipa definēšana

26

Kad stereotips ir nodefinēts un apstiprināts ar kreiso dubultklikšķi uzspiežot uz tā atveras

īpašību dialoglogs. Paplašināta modeļa definēšanas īpašību dialoglogā, kreisajā pusē, kur ir

attēlota koka struktūra ir virsotne Profile, uz šis virsotnes jāuzspiež datorpeles labais taustiņš,

jāizvēlas Add Metaclasses... un metaklašu izvēles logā jāatzīmē Inheritance, tādā veidā tiks

pievienota jauna metaklase šim modelim. Balstoties uz metaklasēm tiek definēti jauni koncepti.

Nospiežot datorpeles labo taustiņu uz tikko izveidotās metaklases, pievienojam tai stereotipu ar

nosaukumu Classification. Īpašība use as metaclass nozīmē, ka tiks veikta apakšklasifikācija

esošajai metaklasei. Ir iespēja izveidot paplašinājumam savu paleti, to var izdarīt izvēloties

palette custom tool. Šajā gadījumā tas netiek izvēlēts. Nospiežam datorpeles labo taustiņu uz

stereotipa un izvēlamies custom symbol, lai pievienotu jaunajam stereotipam atbilstošu

attēlojumu. Ir iespēja izvēlēties no jau esošiem vai arī pievienot pašam savu. Tiks izvēlēta 2.

Iespēja pievienot savu attēlojumu, skatīt Ilustrācija 23.

Ilustrācija 23. Attēlojuma pievienošana

27

Tagad ir nodefinēts jauns stereotips. Tagad tas var tikt izmantots konceptuālajā modelī

mantošanā. Izveidotajā produkta un mantošanas struktūrā norādām klasifikācijas stereotipu, pēc

tā struktūru skatīt Ilustrācija 24.

<<Classification>>Classification

produktstipsder terminssarazotais_daudzumstauku procuzglabasanas tempprodukta tipssastāvs

<pi><pi>

Variable characters (20)DateTextDecimalIntegerVariable characters (30)Variable characters (200)

<None><None><None><None><None><None><None>

<M><M><M>

Identifier_1...

<pi>

piena produktsgalas produkts

Ilustrācija 24. Klasifikācijas stereotipa izmantojums

Tagad realitātēm piena un gaļas produkts norādām pēc kāda kritērija nosaka kādi produkti

tur tiks glabāti. Lai to izdarītu tiek definēti jauni likumi, to veidošana jau ir aprakstīta nodaļā

Error: Reference source not found, tādēļ šo likumu veidošana netiks sīkāk apskatīta. Pievienojam

šos likumus attiecīgajām realitātēm. Tagad varam veikt modeļa transformāciju uz fizisko modeli,

lai aplūkotu rezultātu, skatīt Ilustrācija 25. Veiktā transformācija no CDM uz PDMIlustrācija 25.

Kā redzams šajā ilustrācijā tad šobrīd tā ir vienkārša mantošana, jo šobrīd ir tikai nodefinēts

stereotips konceptuālajā datu modelī, bet nav izveidota transformācija fiziskajā datu modelī.

Transformācijas rezultātā, kā klasifikācijai, vēlamies iegūt vienu tabulu un 2 skatus.

28

FK_PIENA PR_CLASSIFIC_PRODUKTSFK_GALAS PR_CLASSIFIC_PRODUKTS

produktsdzivnieka_vardsder terminstipssarazotais_daudzumstauku procuzglabasanas tempprodukta tipssastāvs...

NOTEDATEVARCHAR(20)NOTENUMBERINTEGERVARCHAR(30)VARCHAR(200)

<pk,fk><pk><pk>

piena produktsdzivnieka_vardsder terminstipssarazotais_daudzumstauku procuzglabasanas tempprodukta tipssastāvs

NOTEDATEVARCHAR(20)NOTENUMBERINTEGERVARCHAR(30)VARCHAR(200)

<pk,fk><pk,fk><pk,fk>

galas produktsdzivnieka_vardsder terminstipssarazotais_daudzumstauku procuzglabasanas tempprodukta tipssastāvs...

NOTEDATEVARCHAR(20)NOTENUMBERINTEGERVARCHAR(30)VARCHAR(200)

<pk,fk><pk,fk><pk,fk>

Ilustrācija 25. Veiktā transformācija no CDM uz PDM

Līdzīgi kā konceptuālajam modelim, vispirms izveidojam paplašinātā modeļa definējumu,

ko nosaucam par ClassificationPDM. Nospiežot dubultklikšķi uz paplašinātā modeļa nosaukuma,

atveras īpašību dialoglogs, kurā tiks pievienota jauna metaklase. Šajā gadījumā tā būs Reference,

jo mantošanas saite atrodas šajā metaklasē. Nospiežot labo datorpeles taustiņu pievienojam

atsaucei transformāciju, ko tā veiks fiziskajā datu modelī. Transformācijas nosaukums būs

Transf1, lai tiktu nodrošināta vēlamā transformācija dialogloga sadaļā Transformation script ir

nepieciešams ievadīt skriptu, skatīt Ilustrācija 26.

Ilustrācija 26. Transformācijas veidošana

29

Transformācijas skripts:

Sub %Transformation%(obj, trfm) ' Implement your transformation on <obj> here dim orig,inh, tab, rule set orig = obj.GenerationOrigin 'konccept mod if orig.classKind = PdCDM.cls_InheritanceLink then set inh = orig.Inheritance if inh.stereoType = "Classification" then 'ja ir stereotips

classification tad set tab = obj.childTable dim tabName tabName = obj.parentTable.code set tab = tab.ReplaceByNewKind(PdPDM.cls_view) 'pārveido

tabulu par skatu set obj = obj.ReplaceByNewKind(PdPDM.cls_viewReference)

'izveido saiti starp skatu un tabulu tab.sqlQuery = "SELECT * FROM " + tabName dim cond cond = 0 for each rule in tab.attachedRules if cond = 0 then tab.sqlQuery = tab.sqlQuery + " WHERE " +

rule.serverExpression cond = 1 else tab.sqlQuery = tab.sqlQuery + " AND " +

rule.serverExpression end if next end if end if Dim MyDiag 'parādīt uz diagrammas visus elementus Set MyDiag = obj.model.DefaultDiagram MyDiag.AttachAllObjectsEnd Sub

Kad scripts ir ievadīts ir jāizveido uz metaklasi attiecīgs transformācijas profils, kas nosaka

kādā secībā izpildīsies transformācijas. Lai pievienotu transformācijas profilus nospiežam

datorpeles labo taustiņu uz pārlūka virsotnes ClassificationPDM un pievienojam. Nospiežot labo

klikšķi uz tā pievienojam jaunu profilu ar nosaukumu prof1. Tā sadaļā post generetion norādām

transformāciju ko jāizpilda – transf1, skatīt Ilustrācija 27. Pre un post generation nozīme:

- pirmsģenerēšanas transformācijas, tiek veiktas modelī pirms ģenerēšanas – piemēram,

ja ir jāizdzēš kāds elements no diagrammas pēc tās pārveidošanas citā modelī;

- pēcģenerēšanas transformācijas, tiek veiktas modelī pēc ģenerēšanas – piemēram, ja

nepieciešams modeļa elementiem mainīt nosaukumus;

30

Ilustrācija 27. Transformācijas pievienošana transformācijas profilam

Tagad atkārtoti atveram konceptuālo modeli, lai ģenerētu fizisko modeli, tikai šoreiz sadaļā

details norādām, ka tiks lietotas transformācijas (Enable transformations) un sadaļā Post-

Generation norādām izmantojamo transformāciju, skatīt Ilustrācija 28.

Ilustrācija 28. Fiziskā modeļa ģenerēšana

31

Iegūstot fizisko modeli pārliecināmies, ka tiek iegūta viena tabula ar 2 skatiem, kā tam ir jābūt,

skatīt Ilustrācija 29.

Ilustrācija 29. Izveidotās transformācijas rezultāts

No apskatītā piemēra ir redzams, ka šādā veidā var tikt veikta transformāciju pārdefinēšana.

Konceptuālais modelis pirms loģiskā modeļa ģenerēšanas ir skatāms .

32

<<s2>>vispārinājums

<<Classification>>Classification

pieder

veic

klust par

bars lieto

lietot plavu

satur

strādā ar

Plavamax ietilpibazemes gr nrkadastra vertnosaukums <pi>

TextIntegerIntegerText

<None><None><None><None>

Identifier_1 <pi>

cilvekspers kodsvardsuzvardsdzimums

<pi> IntegerTextTextdzimums

<None><None><None>dzimums

<M><M><M><M>

Identifier_1 <pi>

lietosanadatums1 <pi> Date <None> <M>Identifier_1...

<pi>

barsbara nrdzivn daudzums

<pi> IntegerInteger

<None><None>

<M><M>

Identifier_1...

<pi>

dzivniekssugasvarsdzivnieka_vardsdz_dzimums

<pi>

TextDecimalTextdzimums

<None><None><None>dzimums

<M>

<M>

Identifier_1 <pi>

produktstipsder terminssarazotais_daudzumstauku procuzglabasanas tempprodukta tipssastāvs

<pi><pi>

Variable characters (20)DateTextDecimalIntegerVariable characters (30)Variable characters (200)

<None><None><None><None><None><None><None>

<M><M><M>

Identifier_1...

<pi>

pirkumssummadatums12nopirktais_daudzums

<pi>DecimalDate & TimeText

<None><None><None>

<M><M>

Identifier_1...

<pi>

piena produktsgalas produkts

pircejsadrese Text <None>

darbinieksalgaamats

DecimalText

<None><None>

<M><M>

Ilustrācija 30.konceptuālais modelis

33

5. JAUNI ELEMENTI

Jaunums piecpadsmitajā Power Designer versijā ir loģiskais datu modelis. Loģiskais datu

modelis ir denormalizēts un paredzēts pilnveidošanai un shēmu optimizēšanai, tas atbalsta ārējās

atslēgas. Loģiskais modelis ir neatkarīgs no DBVS un tādēļ tas var tikt izmantots lai ģenerētu

fizisko modeli. Loģiskais datu modelis satur visas standarta notācijas. Šis modelis var tikt

ģenerēts no konceptuālā un fiziskā datu modeļa.

Kā jauns ieviesums ir arī Impact Analysis Model (IAM). Šis modulis paplašina Power

Designer iespējas efektīvā analīzē (modeļa izmaiņu rezultāti) un nodrošina jaunu atbalstu

izcelšanās analīzei(objekti, kas veido objekta bāzi). Papildus tradicionālajai saskarnei, kas

nodrošina pagaidu skatu analīzei, ir iespēja ģenerēt un saglabāt analīzes modeļus, kas nodrošina

izcelšanās un efektīvās analīzes hierarhiju grafiskos skatus. Šie modeļi var tikt saglabāti lai

nodrošinātu momentuzņēmumu no konkrētās situācijas izstrādes procesā, modeļi var tikt

salīdzināti laika gaitā, kā arī tikt lietoti kā pamats, lai ģenerētu sarežģītas atskaites. Šie modeļi ir

pieejami gan konceptuālajā, gan loģiskajā, gan fiziskajā datu modelī. Ilustrācija 31 un Ilustrācija

32 parāda izveidotā konceptuāla modeļa analīzi.

34

Ilustrācija 31. Impact and lineage analysis

Child Inheritances

Child Entities Relationships

Relationships

Child Entities Relationships Relationships

Relationships

Child Inheritances Child EntitiesChild Entities

Relationships

Relationships

(Conceptual Data_1)Entity cilveks

[Change]s2 vispārinājums

(Conceptual Data_1)Entity darbinieks

[Change]

(Conceptual Data_1)Entity bars[Change]

(Conceptual Data_1)Entity dzivnieks

[Change]

(Conceptual Data_1)Entity produkts

[Change]

(Conceptual Data_1)Entity pirkums

[Change]

(Conceptual Data_1)Entity pircejs

[Change]

Inheritance Classification

(Conceptual Data_1)Entity piena produkts

[Change]

(Conceptual Data_1)Entity galas produkts

[Change]

(Conceptual Data_1)Entity lietosana

[Change]

(Conceptual Data_1)Entity Plava

[Change]

Ilustrācija 32. Impact and lineage analysis diagrammas veidā

Kā redzams Ilustrācija 32 tiek attēlots viens izvēlētais sākuma objekts (realitāte cilvēks)

un visas ar to saistītās realitātes.

Konceptuālajā datu modelī ir ieviesta jauna notācija – Barkera notācija, kas ir pieejama

arī loģiskajā modelī. Kā ir ierasts Oracle CASE riku lietotājiem, šī populārā notācija bērnu

realitātes attēlo vecāku realitātē, kā arī šajā notācijā ir liels skaits ar saviem apzīmējumiem. Kā

arī jaunums ir iespēja pievienot stereotipu. Šī iespēja ir aprakstīta Error: Reference source not

found nodaļā.

35

Fiziskajā modelī tiek pievienots jauns datu bāzu vadības sistēmu atbalsts un uzlabots

esošais:

IBM DB2 v9 Microsoft SQL Server 2008 (limited) ORACLE 11g Sybase ASA 11 Sybase ASE 15.0.2 Teradata V2 R6.1 and 6.2

36

6. LOĢISKAIS MODELIS

Loģiskais datu modelis (LDM) ir fiziskā datu modeļa paveids, bet kurš nav atkarīgs no

DBVS. LDM ir starpposms starp konceptuālo modeli un fizisko modeli, tas ir detalizētāks par

konceptuālo modeli un šajā modelī, ja nepieciešams var veikt tabulu denormalizāciju, rediģēt

saites.

Darba gaitas uzsākot tiek izveidots konceptuālais modelis ar E/R+Merise notāciju

Ilustrācija 33, kā nākamais darba solis seko loģiskā datu modeļa izveide. Rezultāts kāds sanācis

pēc konceptuālajā modelī ģenerētā loģiskā modeļa var apskatīt Ilustrācija 34.

Ilustrācija 33 Konceptuālais modelis

37

Ilustrācija 34 Loģiskais datu modelis

Iegūtais loģiskais modelis ir ar Barker notāciju, apskatot Ilustrācija 35 var redzēt, ka

loģiskajā modelī realitāte Cilveks sevī ietver realitātes Pircejs un Darbinieks. Apskatot realitātes

Cilveks rekvizītus cilnē Attributes redzam, ka tiek apvienoti visi atribūti no realitātēm Pircejs un

Darbinieks , skatīt Ilustrācija 36.

Ilustrācija 35 Loģiskā modeļa realitāte

38

Ilustrācija 36 Realitātes Darbinieks atribūti

Kā redzam loģiskajā modelī saites no Pircejs un Darbinieks tieši vizuāli nav redzamas.

Izpētot loģisko modeli var manīt to, ka saite N:N tiek attēlota tabulas veida, jo relāciju

datu bāzē to nevar attēlot, loģiskajā modelī parādās divās vietās, kur konceptuālajā modelī tika

definētas saites N:M Ilustrācija 37 un Ilustrācija 38.

Ilustrācija 37 Saites N: N Loģiskajā modelī

39

Ilustrācija 38 Saites N: N Loģiskajā modelī

Nomainot loģiskajam modelim Entity/Relationship notāciju var redzēt, ka saiti N: N arī

attēlo tabulas veidā. Realitāte Cilveks sevī ietver realitātes Pircejs un Darbinieks, tāpat kā ar

Barkera notāciju, Ilustrācija 39.

Ilustrācija 39 Loģiskais modelis ar Entity/Relationship notāciju

Apskatot loģiskajā modelī realitāti Produkts Ilustrācija 34 īpašību logu var apskatīt

realitātes atribūtu sarakstu, esošajam sarakstam var pievienot kādu jaunu atribūtu, pievienot kādu

esošo no citām piesaistītām realitātes atribūtiem.

40

Ilustrācija 40 Realitātes Produkts īpašību logs

Dependencies cilnī Ilustrācija 41 var apskatīt kādas ir Realitātes Produkts saites, ar

kādām realitātēm ir saistīta. Jaunu saiti nav iespējams pievienot, bet ir iespējams nomainīt saites.

Ilustrācija 41 Realitātes Produkts īpašību logs

41

7. FIZISKAIS MODELIS

7.1. Fiziskā modeļa ģenerēšana

No konceptuālā vai loģiskā modeļa iespējams izveidot fizisko modeli: Tools Generate

Physical Data Model, skat. Ilustrācija 42. Fiziskais modelis attēlo, kā konceptuālajā modelī

iekļautie dati tiks realizēti datu bāzē.

Ilustrācija 42 Fiziskā modeļa ģenerēšana

Iestatījumos var norādīt, vai tiks veidots jauns vai atjaunots esošs fiziskais modelis, tā

vārds, nepieciešamā datu bāzu vadības sistēma u.c.. DBVS saraksts ir plašs: ADABAS D,

ALLBASE/SQL G.1, ANSI Level 2, AS/400, IBM DB2 UDB 9.5, INFORMIX SQL 11.x,

Ingres R3 3.0.1, InterBase 6.x, Mirosoft Access 2000, Microsoft SQL Server 2008, MySQL 5.0,

Netezza 4.5, NonStop SQL, ODBC 3.0, ORACLE Version 11g, PostgreSQL 8, RedBrick

Warehouse 6.2, Sybase AS Anywhere 9, Sybase AS Enterprice 15.5, Sybase Avaki, Sybase IQ

15.2, Sybase SQL Anywhere 11, Teradata V12. Pilnu PowerDesigner 15.2. atbalstīto DBVS

sarakstu skat. pielikumā nr. 1. Vēl pie iestatījumiem (cilnī Selection) var norādīt, kuras realitātes

modelī attēlojamas, bet Detail cilnī var norādīt, kādi prefiksi lietojami, nosaucot jaunās tabulas,

saites utml.

42

7.2. Ģenerētais fiziskais modelis

Ilustrācija 43 Fiziskais modelis

7.3. Fiziskā modeļa sastāvdaļas

`Fiziskais modelis sastāv no tabulām, skatiem un saitēm starp tiem. Vēl var definēt trigerus,

kas ir pie konkrētām tabulām vai skatiem piesaistīti SQL kodi datu ievadīšanai, dzēšanai vai

labošanai. Taču var būt arī pie konkrētām tabulām vai skatiem nepiesaistīti trigeri, taču šādā

gadījumā tie tiek definēti Model Triggers DBMS Triggers.

Fiziskajā modelī vairs nav realitātes – tās kļuvušas par tabulām. Katrai tabulai pie tās

īpašību apraksta parādījušies jauni ciļņi, piemēram, Indexes, kas uzrāda automātiski izveidotos

indeksus katras tabulas primārajām un ārējām atslēgām. Vairs netiek vizuāli norādīts saites veids,

kā tas bija konceptuālajā modelī. Saites tagad kļuvušas par atsaucēm. Tāpat kā konceptuālajā un

loģiskajā modelī, iespējams rediģēt tabulu un atsauču parametrus, piemēram, pārsaukt

jaunizveidoto tabulu Relationship_7, skat. Ilustrāciju 44, vai pievienot tabulai jaunu kolonnu vai

biznesa likumu. Ir apskatāms katras tabulas un saites SQL kods.

43

Ilustrācija 44 Tabulas pārsaukšana

Kā jau iepriekš minēts, arī fiziskajā modelī vietās, kur konceptuālajā modelī bija saite

N:M, ir izveidota jauna tabula, kas sevī ietver abu N:M saites savienoto tabulu unikālos

identifikatorus.

Atšķirībā no loģiskā modeļa, parādījušies abi ar stereotipu palīdzību veidotie skati. Taču,

ja tas nepieciešams, fiziskajā modelī iespējams izveidot jaunus skatus (Model Views... ),

uzrakstot tiem atbilstošus SQL vaicājumus.

Ilustrācija 45 Jauns skats

44

8. ATSKAIŠU VEIDOŠANALai noskaidrotu nepieciešamās lietas par izveidoto modeli, piemēram, par konceptuālo

modeli, pārskatāmā veidā, ir iespējams izveidot atskaiti. To ir iespējams izdarīt izvēloties Report

un kādu no piedāvātajām iespējam, piemēram, izveidot atskaiti ar vedņa (wizard) palīdzību,

skatīt Ilustrācija 46.

Ilustrācija 46 Atskaišu veidošana

Ir iespēja izvēlēties rīkjoslā pogu Report, atveras dialoglogs, skatīt Ilustrācija 47, kurā ir

iespējams norādīt atskaites nosaukumu, izvēlēties valodu, kā arī izvēlēties atskaites šablonu.

Ilustrācija 47 Atskaišu veidošana-šablona izvēle

Šajā gadījumā izvēlamies standarta konceptuālo atskaiti (Standard conceptual report).

Izderot šo izvēli atveras dialoglogs, kurā varam norādīt ko vēlamies attēlot atskaitē. Kad tas ir

izdarīts atskaišu paletē var izvēlēties – printēt, apskatīt printēšanai, ģenerēt atskaiti ar vedņa

palīdzību, ģenerēt html formātā vai ģenerēt rtf formātā. Ilustrācija 48 ir redzama atskaite html

formātā un Ilustrācija 49 rtf formātā.

45

Veidojot atskaiti rtf formātā, tiek vaicāts vai veidot to ar galveno rtf redaktoru, to

apstiprinot atskaite tiek ģenerēta word dokumentā.

Ilustrācija 48 Atskaite html formātā

46

Ilustrācija 49 Atskaite rtf formātā

Šāda veida atskaites var tikt veidotas arī loģiskajam un fiziskajam modelim.

47

9. DEFINĒJUMU PAREIZĪBAS KONTROLELai pārbaudītu modeļa pareizību izvēlamies Tools->Check model, skatīt Ilustrācija 50.

Ilustrācija 50. Izvēlne

Izvēloties pārbaudīt modeli atveras modeļa pārbaudes parametru logs, kurā ir iespējams

atzīmēt, kurus modeļa elementus nepieciešams pārbaudīt. Pēc noklusējuma atzīmēti ir visi

modeļa elementi. Tā kā modeli nepieciešams pārbaudīt pilnībā, nekas netiek mainīts un tiek

veikta pilna modeļa pārbaude, skatīt Ilustrācija 51.

48

Ilustrācija 51. Modeļa pārbaudes parametru logs

Pirms apstiprinām sadaļā izvēle (selection) norādām, kam tiks veikta pārbaude un

apstiprinām, skatīt Ilustrācija 52.

Ilustrācija 52. Modeļa izvēle pārbaudei

49

Ilustrācija 53 parāda pieļautās kļūdas modeļa veidošanā, kā redzams, tad kļūdas nav

pieļautas, bet ir brīdinājumi, kas ļauj ģenerēt loģisko un fizisko datu modeli. Šie brīdinājumi var

radīt vai arī neradīt traucējumus citu modeļu ģenerēšanā.

Ilustrācija 53. Kļūdu izvade

Šajā gadījumā tika novērsts pirmais brīdinājums par neizmantoti datu vienību. Nākošie

brīdinājumi norāda, ka eksistē saites vai asociācijas.

10. PĀRVEIDOJUMU ANALĪZE

Šajā darbā tika izveidoti trīs modeļi – konceptuālais modelis no kura tika ģenerēts

loģiskais un fiziskais datu modelis. Lai apskatītu kādas izmaiņas ir notikušas modeļu veidošanas

laikā salīdzinām izveidotās struktūras (realitāte, vājā realitāte, saite N:M, mantošana –

vispārināšana, klasifikācija) visos trīs modeļos.

Realitāte – konceptuālajā datu modelī ir realitāte, kuru apraksta ar atribūtiem,

identifikatoru, primāro atslēgu, likumiem un citām īpašībām, loģiskajā modelī realitāte tiek

atspoguļota tāpat kā konceptuālajā modelī, savukārt fiziskajā modelī realitāte tiek transformēta

par datu bāzes tabulu, kurai atkarībā no izvēlētās datubāzes ir iespēja paskatīties kodu kādā tā

tiek ģenerēta, piemēram, sql kodu un citas īpašības. Kā parāda Ilustrācija 54, tiek pārveidoti arī

datu tipi, piemēram, konceptuālajā un loģiskajā datu modelī atribūtam max ietilpība tips ir text,

bet fiziskajā datu modelī, kas paredzēts Access 2000, tas pārtop par Note. Kā arī ir nākuši klāt

loģiskajā un fiziskajā datu modelī tabulai atribūti, kas konceptuālajā datu modelī nav – ārējās

50

atslēgas lauki, piemēram, tabulai dzīvnieks. Realitātes attēlojumi konceptuālajā un loģiskajā datu

modelī atšķiras jo tiem tiek izmantotas dažādas notācijas.

Ilustrācija 54. Realitātes transformācija

Vājā realitāte – darbā tika izveidotas vairākas realitātes, kā piemēru, parādīsim vājo

realitāti pirkums. Kā redzams Ilustrācija 55 tad šāda veida realitātei izpildās tādas pašas īpašības

kā parastai realitātei ar atšķirību, ka vājajai realitātei konceptuālajā modelī nav primārās atslēgas,

savukārt loģiskajā un fiziskajā datu modelī šai realitātei (PDM - tabulai) parādās primārā atslēga

no realitātēm, kas ir saistītas ar šo realitāti ar vājo saiti. Jaunizveidotās primārās atslēgas tiek

izmantotas arī kā ārējās atslēgas vienlaicīgi.

51

Ilustrācija 55. Vājās realitātes transformācija

Saite N:M – konceptuālajā modelī ir iespēja izveidot saiti N:M, taču relāciju datu bāzes

neatbalsta šādu struktūru, tādēļ tiek veidota papildus tabula starp divām realitātēm, kas ir saistītas

ar šādu saiti. Šī tabula satur primāro atslēgu laukus no abām saistītajām tabulām. Tāda veida

tabulas var novērot loģiskajā (realitātes) un fiziskajā datu modelī. Fiziskajā modeli visa veida

saites tiek pārveidotas par atsaucēm. Ilustrācija 56 parāda atšķirības starp saišu realizācijām.

52

Ilustrācija 56. Saites N:M transformācija

Mantošana – darbā tika izmantots mantošanas veids vispārinājums. Aplūkojot

vispārinājumu visos trijos modeļos redzam, ka konceptuālajā datu modelī vispārinājums tiek

attēlots kā trīs dažādas realitātes. Bērnu realitātēm nav primārās atslēgas. Loģiskajā modelī

redzam ka ir trīs realitātes no kurām divas (bērnu realitātes) ir ievietotas vecāka realitātē. Abas

bērnu realitātes sastāv no saviem atribūtiem + vecāka atribūtiem. Savukārt fiziskajā modelī

redzam, ka ir izveidota viena tabula, kas sastāv no visiem vecāka un bērnu atribūtiem, skatīt

Ilustrācija 57. Vispārinājuma veidošanai tika izmantots – ģenerēt vecākus.

53

Ilustrācija 57. Vispārinājuma transformācija

Klasifikācija –konceptuālajā modelī klasifikācija tika veidota ar vienkāršas mantošanas

palīdzību, kurai tika pievienots stereotips Classification. Piena un gaļa produktu realitātes ir

tukšas, tās mantos visas īpašības no vecākiem. Loģiskajā datu modelī līdzīgi kā mantošanā bērnu

realitātes atrodas vecāku realitātēs un bērnu realitātes ir mantojušas visas vecāka īpašības.

Savukārt fiziskajā modelī, tiek nodefinēts, ka mantošanas vietā (bērnu tabulu vietā) parādās

skati, vecāku tabula saglabājās. Atkarībā no tā vai izpildās likums par tips=piena produkts vai

tips=gaļas produkts, produkti tiks klasificēti, katram no skatiem. Šajā gadījumā konceptuālajā

modelī tika definēts, ka ģenerēs gan vecākus, gan bērnus. Ilustrācija 58 parāda iegūtas atšķirības

vispārināšanai katrā no modeļiem.

54

Ilustrācija 58. Klasifikācijas transformācija

55

11. IZVEIDOTĀ MODEĻA TESTĒŠANA

Lai testētu PowerDesigner izveidoto datu bāzes struktūras definēšanas SQL kodu, tiek

lejupielādēta un uzinstalēta PostgreSQL (versija 8.4.4-1 Windows operētājsistēmai) datu bāzu

vadības sistēma, kuras administrēšdanai tiek izmantots rīks pgAdmin III (versija 1.10.3).

Ilustrācija 59 Datu bāzes vadības sistēmas administrēšdanas rīks pgAdmin III

Vispirms tiek izveidota jauna datubāze, kur tiek iekopēts ar PowerDesigner ģenērētais

SQL kods, pirms tam pie koda ģenerēšanas norādot DBVS veidu PostgreSQL 8. SQL datubāzes

struktūras ģenerēšanas aprakstu skat. 8. nodaļā, bet ģenērēto SQL kodu PostgreSQL 8 skat. 2.

pielikumā.

56

Ilustrācija 60 Datu bāzes izveide

Tiek saņemti vairāki kļūdu paziņojumi, piemēram, sekojošais:

Ilustrācija 61 Kļūdas paziņojums

Kļūda tiek risināta, ieliekot nepieciešamās pēdiņas:

Ilustrācija 62 Kļūdas labojums

57

Rezultātā tiek izveidota datu bāze, kas sastāv no viena domēna, deviņām tabulām un diviem

skatiem.

Ilustrācija 63 Izveidotās datu bāzes struktūra

pdAdmin III ar elementāru SQL vaicājumu („Insert into plava values (23, 23489439, 556,

'Zala');” un „Select * from plava;”) palīdzību tabulā „Pļava” tiek pamēģināts gan ievadīt datus,

gan izgūt tos. Tas izdodas sekmīgi:

Ilustrācija 64 SQL vaicājuma rezultāts

58

59

12. SQL DATU BĀZES STRUKTŪRAS ĢENERĒŠNA

Lai varētu ģenerēt SQL skriptu no konceptuālā datu modeļa nepieciešams uzģenerēt

fizisko datu modeli, jo tikai šajā modelī var ģenerēt SQL skriptu (skat. Pielikums 3). Lai

ģenerētu SQL skriptu, izvēlamies Database Database Generation, tad atveras Database

Generation logs Ilustrācija 65. Pirms ģenerēšanas PowerDesigner piedāvā iestādīt DB īpašības

datu bāzes Options logā, savukārt pie Preview iespējams apskatīt pašu SQL kodu un, ja

nepieciešams, nokopēt.

Šajā logā norāda, kur tiks saglabāts SQL skripts, protams, nodefinējam faila nosaukumu

ar paplašinājumu .dat. Tāpat tiek norādīts Generation type, kas šajā gadījumā ir Script

generation. Var norādīt tabulu, kolonu, atslēgu un indeksu ģenerācijas parametrus.

Ilustrācija 65 Database Generation logs

Faila nosaukums ir SQL skripts un nospiežam pogu OK. Tā rezultātā PowerDesigner dod

sekojošu paziņojumu:

60

Ilustrācija 66 SQL skripta ģenerācijas rezultāts

Tas nozīmē, ka norādītajā direktorijā ir izveidots SQL skriptu saturošs fails ar

paplašinājumu .dat.

13. APVĒRSTĀ INŽENIERIJAAr apvērsto inženieriju saprot ERD diagrammu ģenerēšanu no iepriekšējā nodaļā

aprakstītā, iegūtā SQL skripta. Šim nolūkam no izvēlnes Database izvēlamies Update Model

from Database... Atveras datu bāzes apgrieztās inženierijas īpašību logs (Ilustrācija 67), kam ir

trīs šķirkļi— Selection, Options un Target Models. Šķirklī Selection norādām failu, kuru

izmantosim apgrieztās inženierijas veikšanai.

61

Ilustrācija 67 Apvērstās inženierijas īpašību logs

Datu bāzes apvērstās inženierijas īpašību loga šķirklī Options var norādīt atsauču un/vai

primāro atslēgu atkārtotu izveidi. Pēc noklusējuma neviena no šim opcijām nav izvēlēta.

Šķirklī Target Model iespējams norādīt eksistējošu fizisko datu modeli, kurā tiks ievietoti

apvērstās inženierijas rezultāti. Pēc noklusējuma šajā šķirklī nav vērtības, tāpēc rezultāti tiks

ievietoti jaunā datu fiziskajā modelī.

Nospiežot pogu OK tiek veikta apvērstā inženierija (Ilustrācija 68). Pēc pāris sekundēm

PowerDesigner dod paziņojumu par apvērstās inženierijas veiksmīgu izpildīšanu (Ilustrācija 69).

Ilustrācija 68 Apvērstās inženierijas process

62

Ilustrācija 69 Apvērtās inženierijas veiksmīga izpilde

Rezultātā no SQL skripta iegūstam nepieciešamo datu modeli, no kāda tas tika sākotnēji

ģenerēts. Ilustrācija 70 var redzēt, ka pilnīgi viss tiek iegūts.

Ilustrācija 70 Iegūtais modelis

63

Tagad no ģenerētā fiziskā datu modeļa mēģināsim iegūt konceptuālo datu modeli

Ilustrācija 71. Iegūto konceptuālo modeli salīdzinot ar darba sākumā veidoto Ilustrācija 33, to, ka

neattēlojās vājās realitātes. Realitātē Cilveks tiek ievietoti realitāšu Darbinieks un Pircejs

atribūti, savukārt viss pārējais ir tieši tāds pats, kā darba sākumā veidotajam konceptuālajam

modelim.

Ilustrācija 71 Konceptuālais modelis no ģenerētā fiziskā modeļa

64

SECINĀJUMIIzstrādātajā darbā tiek apskatīts viens no daudzajiem CASE rīkiem PowerDesigner 15.2.,

tā piedāvātās iespējas, proti, saišu veidošanu, transformācijas, stereotipu veidošanu, apvērsto

inženieriju, izveidotā modeļa testēšanu.

Iepazīstoties ar kolēģu prezentācijām secinām, ka rīks Power Designer ir spēcīgāks,

piemēram, transformāciju pārdefinēšanā, ko realizējam ar stereotipiem. Tomēr šo īpašību varētu

arī pelt tādā ziņā, ka tā nav viegli veidojama nepieredzējušam lietotājam. Salīdzinot ar Toad

Power Designer ir iespēja izveidot gan konceptuālo, gan loģisko, gan fizisko datu modeli. Ir arī

līdzīgas iespējas, piemēram, atskaišu veidošana, Auto layout, kas līdzīgi kā Toad risinājumā

nesniedz gaidīto rezultātu. Mūsu izmantotajā CASE rīkā ir plašs izmantojamo datu bāzu vadības

sistēmu skaits. Patīkam pārsteidz arī tas, ka , piemēram, loģiskā modeļa ģenerēšanai pietiek

izvēlnē nospiest iespēju ģenerēt loģisko modeli, kas tiek ģenerēts automātiski nevis izmantojot

vedņu palīdzību, kā tas ir bijis rīkā Toad. Diezgan ērti šajā rīkā ir izveidota arī palete ar

nepieciešamākajiem rīkiem.

Strādājot ar 15.2 versiju un atceroties darbu no datu bāzēm 1, redzam, ka tiešām ir veiktas

izmaiņas un uzlabojumi, piemēram, PowerDesigner 12 ar kuru tika strādāts nepastāvēja loģiskais

datu modelis. Loģiskais datu modelis ir denormalizēts un paredzēts pilnveidošanai un shēmu

optimizēšanai, tas atbalsta ārējās atslēgas. Loģiskais datu modelis satur visas standarta notācijas.

Šis modelis var tikt ģenerēts no konceptuālā un fiziskā datu modeļa.

PowerDesigner 15.2 atbalsta pietiekami daudz datu bāzu vadības sistēmu un to versiju.

Turklāt Sybase nemitīgi papildina PowerDesigner atbalstīto DBVS sarakstu. Lai testētu darba

gaitā izveidoto datu bāzes fizisko modeli, tika izvēlēta PostgreSQL 8.2, lai apskatītu līdz šim

datu bāzu kursu praktiskajos darbos nepielietotu datu bāzu vadības sistēmu. Jāatzīst, ka ar

PowerDesigner izveidotā modeļa SQL kodu viegli varēja pārkopēt uz pgAdmin III, vienīgi

vietām radās problēmas ar pēdiņām pie saliktiem atribūtu nosaukumiem.

No Power Designer jaunumiem jāpiemin jauns Impact Analysis Model (IAM). Šis

modulis paplašina Power Designer iespējas efektīvā analīzē (modeļa izmaiņu rezultāti) un

nodrošina jaunu atbalstu izcelšanās analīzei.

65

LITERATŪRAS SARAKSTS

1. http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.dc38628.1520/

doc/html/rad1232022065342.html

2. http://www.sybase.com/products/modelingdevelopment/powerdesigner

66

PIELIKUMS

67

Pielikums nr. 1

PowerDesigner 15.2. atbalstītās DBVS

ADABAS D,

ALLBASE/SQL G.1,

ANSI Level 2,

AS/400,

IBM DB2 5.x for OS/390,,

IBM DB2 UDB 6 for OS/390,,

IBM DB2 UDB 6.x Common Server,

IBM DB2 UDB 7 for OS/390,

IBM DB2 UDB 7.x Common Server,

IBM DB2 UDB 8 for OS/390,

IBM DB2 UDB 8.x Common Server,

IBM DB2 UDB 9.0 Common Server,

IBM DB2 UDB 9.5 Common Server,

IBM DB2 Version 9.x for z/OS,

INFORMIX SQL 8.x,

INFORMIX SQL 9.x,

INFORMIX SQL 10.x,

INFORMIX SQL 11.x,

Ingres R3 3.0.1,

InterBase 5.x,

InterBase 6.x,

Mirosoft Access 95 & 97,

Mirosoft Access 2000,

Microsoft SQL Server 7.x,

Microsoft SQL Server 2000,

Microsoft SQL Server 2005,

Microsoft SQL Server 2008,

MySQL 3.22,

MySQL 3.23,

MySQL 4.0,

MySQL 5.0,

Netezza 4.5,

NonStop SQL,

ODBC 3.0,

ORACLE Version 8,

ORACLE Version 8i,

ORACLE Version 8i2,

ORACLE Version 9i2,

ORACLE Version 10g,

ORACLE Version 10gR2,

ORACLE Version 11g,

PostgreSQL 7.3,

PostgreSQL 8,

RedBrick Warehouse 6.2,

Sybase AS Anywhere 7,

Sybase AS Anywhere 8,

Sybase AS Anywhere 9,

Sybase AS Enterprice 11.0,

Sybase AS Enterprice 11.5-11.9,

Sybase AS Enterprice 12.0,

Sybase AS Enterprice 12.5,

Sybase AS Enterprice 12.5.1,

Sybase AS Enterprice 12.5.2,

Sybase AS Enterprice 12.5.3a,

68

Sybase AS Enterprice 15.0,

Sybase AS Enterprice 15.0.2,

Sybase AS Enterprice 15.5,

Sybase Avaki,

Sybase IQ 12.0,

Sybase IQ 12.4.3,

Sybase IQ 12.5,

Sybase IQ 12.6,

Sybase IQ 12.7,

Sybase IQ 15.0 – 15.1,

Sybase IQ 15.2,

Sybase SQL Anywhere 10,

Sybase SQL Anywhere 11,

Teradata V2R5,

Teradata V2R6,

Teradata V12

69

Pielikums nr. 2

PostgreSQL Datu bāzes struktūras SQL kodsdrop view "galas produkts";

drop view "piena produkts";

drop table Plava;

drop table Relationship_7;

drop table bars;

drop table cilveks;

drop table dzivnieks;

drop table lietosana;

drop table pirkums;

drop table produkts;

drop table satur;

drop domain dzimums;

/*==============================================================*//* Domain: dzimums *//*==============================================================*/create domain dzimums as VARCHAR(10);

/*==============================================================*//* Table: Plava *//*==============================================================*/create table Plava ( "max ietilpiba" VARCHAR(254) not null, "zemes gramatas nr" INT4 not null, "kadastra vērt" INT4 not null, nosaukums VARCHAR(254) not null, constraint PK_PLAVA primary key (nosaukums));

/*==============================================================*//* Table: Relationship_7 *//*==============================================================*/create table Relationship_7 ( "pers kods" INT4 not null, "bara nr" INT4 not null, constraint PK_RELATIONSHIP_7 primary key ("pers kods", "bara nr"));

70

/*==============================================================*//* Table: bars *//*==============================================================*/create table bars ( "bara nr" INT4 not null, "dzivn daudzums" INT4 not null, constraint PK_BARS primary key ("bara nr"), constraint CKT_BARS check ((dzivn daudzums > 0) and (dzivn daudzums < 50)));

/*==============================================================*//* Table: cilveks *//*==============================================================*/create table cilveks ( "pers kods" INT4 not null, vards3 VARCHAR(254) not null, uzvards VARCHAR(254) not null, dzimums VARCHAR(10) not null constraint CKC_DZIMUMS_CILVEKS check (dzimums in ('siev','vir')), alga DECIMAL null, amats VARCHAR(254) null, adrese VARCHAR(254) null, constraint PK_CILVEKS primary key ("pers kods"));

/*==============================================================*//* Table: dzivnieks *//*==============================================================*/create table dzivnieks ( suga VARCHAR(254) not null, svars DECIMAL null, dzivnieka_vards VARCHAR(254) not null, "bara nr" INT4 not null, dz_dzimums VARCHAR(10) null constraint CKC_DZ_DZIMUMS_DZIVNIEK check (dz_dzimums is null or (dz_dzimums in ('siev','vir'))), constraint PK_DZIVNIEKS primary key (dzivnieka_vards));

/*==============================================================*//* Table: lietosana *//*==============================================================*/create table lietosana ( "bara nr" INT4 not null, nosaukums VARCHAR(254) not null, datums1 DATE not null, constraint PK_LIETOSANA primary key ("bara nr", nosaukums, datums1));

/*==============================================================*//* Table: pirkums *//*==============================================================*/create table pirkums ( "pers kods" INT4 not null, datums12 DATE not null, summa DECIMAL not null,

71

nopirktais_daudzums VARCHAR(254) null, constraint PK_PIRKUMS primary key ("pers kods", datums12));

/*==============================================================*//* Table: produkts *//*==============================================================*/create table produkts ( dzivnieka_vards VARCHAR(254) not null, "der termins" DATE not null, tips VARCHAR(20) not null, sarazotais_daudzums VARCHAR(254) not null, "tauku proc" DECIMAL null, "uzglabasanas temp" INT4 null, "produkta tips" VARCHAR(30) null, sastāvs VARCHAR(200) null, constraint PK_PRODUKTS primary key (dzivnieka_vards, "der termins", tips));

/*==============================================================*//* Table: satur *//*==============================================================*/create table satur ( dzivnieka_vards VARCHAR(254) not null, "der termins" DATE not null, tips VARCHAR(20) not null, "pers kods" INT4 not null, datums12 DATE not null, constraint PK_SATUR primary key (dzivnieka_vards, "der termins", tips, "pers kods", datums12));

/*==============================================================*//* View: "galas produkts" *//*==============================================================*/create or replace view "galas produkts" asSELECT * FROM produkts WHERE tips='galas produkts';

/*==============================================================*//* View: "piena produkts" *//*==============================================================*/create or replace view "piena produkts" asSELECT * FROM produkts WHERE tips='piena produkts';

alter table Relationship_7 add constraint FK_RELATION_RELATIONS_CILVEKS foreign key ("pers kods") references cilveks ("pers kods") on delete restrict on update restrict;

alter table Relationship_7 add constraint FK_RELATION_RELATIONS_BARS foreign key ("bara nr") references bars ("bara nr") on delete restrict on update restrict;

alter table dzivnieks add constraint FK_DZIVNIEK_PIEDER_BARS foreign key ("bara nr")

72

references bars ("bara nr") on delete restrict on update restrict;

alter table lietosana add constraint "FK_LIETOSAN_BARS LIET_BARS" foreign key ("bara nr") references bars ("bara nr") on delete restrict on update restrict;

alter table lietosana add constraint "FK_LIETOSAN_LIETOT PL_PLAVA" foreign key (nosaukums) references Plava (nosaukums) on delete restrict on update restrict;

alter table pirkums add constraint FK_PIRKUMS_VEIC_CILVEKS foreign key ("pers kods") references cilveks ("pers kods") on delete restrict on update restrict;

alter table produkts add constraint "FK_PRODUKTS_KLUST PAR_DZIVNIEK" foreign key (dzivnieka_vards) references dzivnieks (dzivnieka_vards) on delete restrict on update restrict;

alter table satur add constraint FK_SATUR_SATUR_PRODUKTS foreign key (dzivnieka_vards, "der termins", tips) references produkts (dzivnieka_vards, "der termins", tips) on delete restrict on update restrict;

alter table satur add constraint FK_SATUR_SATUR2_PIRKUMS foreign key ("pers kods", datums12) references pirkums ("pers kods", datums12) on delete restrict on update restrict;

73

Pielikums nr. 2

Konceptuālā modeļa uzģenerētais SQL skripts

#==============================================================# DBMS name: Microsoft Access 2000# Created on: 2010.05.24. 19:54:50#==============================================================

RemoveJoin C=FK_RELATION_RELATIONS_CILVEKS T=Relationship_7 P=cilveks;

RemoveJoin C=FK_RELATION_RELATIONS_BARS T=Relationship_7 P=bars;

RemoveJoin C=FK_DZIVNIEK_PIEDER_BARS T=dzivnieks P=bars;

RemoveJoin C="FK_LIETOSAN_BARS LIET_BARS" T=lietosana P=bars;

RemoveJoin C="FK_LIETOSAN_LIETOT PL_PLAVA" T=lietosana P=Plava;

RemoveJoin C=FK_PIRKUMS_VEIC_CILVEKS T=pirkums P=cilveks;

RemoveJoin C="FK_PRODUKTS_KLUST PAR_DZIVNIEK" T=produkts P=dzivnieks;

RemoveJoin C=FK_SATUR_SATUR_PRODUKTS T=satur P=produkts;

RemoveJoin C=FK_SATUR_SATUR2_PIRKUMS T=satur P=pirkums;

RemoveView C="galas produkts";

RemoveView C="piena produkts";

RemoveTble C=Plava;

RemoveTble C=Relationship_7;

RemoveTble C=bars;

RemoveTble C=cilveks;

RemoveTble C=dzivnieks;

RemoveTble C=lietosana;

RemoveTble C=pirkums;

RemoveTble C=produkts;

74

RemoveTble C=satur;

#==============================================================# Table: Plava#==============================================================CreateTble C=Plava N="Plava"( C="max ietilpiba" T="NOTE" P=No M=Yes N="max ietilpiba" Z=false, C="zemes gramatas nr" T="INTEGER" P=No M=Yes N="zemes gr nr" Z=false, C="kadastra vērt" T="INTEGER" P=No M=Yes N="kadastra vert" Z=false, C=nosaukums T="NOTE" P=Yes M=Yes N="nosaukums" Z=false);

#==============================================================# Table: Relationship_7#==============================================================CreateTble C=Relationship_7 N="Relationship_7"( C="pers kods" T="INTEGER" P=Yes M=Yes N="pers kods" Z=false, C="bara nr" T="INTEGER" P=Yes M=Yes N="bara nr" Z=false);

#==============================================================# Table: bars#==============================================================CreateTble C=bars N="bars"( C="bara nr" T="INTEGER" P=Yes M=Yes N="bara nr" Z=false, C="dzivn daudzums" T="INTEGER" P=No M=Yes N="dzivn daudzums" Z=false);

#==============================================================# Table: cilveks#==============================================================CreateTble C=cilveks N="cilveks"( C="pers kods" T="INTEGER" P=Yes M=Yes N="pers kods" Z=false, C=vards3 T="NOTE" P=No M=Yes N="vards" Z=false, C=uzvards T="NOTE" P=No M=Yes N="uzvards" Z=false, C=dzimums T="VARCHAR(10)" P=No M=Yes N="dzimums" S=("siev","vir") Z=false, C=alga T="NUMBER" P=No M=No N="alga" Z=false, C=amats T="NOTE" P=No M=No N="amats" Z=false, C=adrese T="NOTE" P=No M=No N="adrese" Z=false);

#==============================================================# Table: dzivnieks#==============================================================CreateTble C=dzivnieks N="dzivnieks"

75

( C=suga T="NOTE" P=No M=Yes N="suga" Z=false, C=svars T="NUMBER" P=No M=No N="svars" Z=false, C=dzivnieka_vards T="NOTE" P=Yes M=Yes N="dzivnieka_vards" Z=false, C="bara nr" T="INTEGER" P=No M=Yes N="bara nr" Z=false, C=dz_dzimums T="VARCHAR(10)" P=No M=No N="dz_dzimums" S=("siev","vir") Z=false);

#==============================================================# Table: lietosana#==============================================================CreateTble C=lietosana N="lietosana"( C="bara nr" T="INTEGER" P=Yes M=Yes N="bara nr" Z=false, C=nosaukums T="NOTE" P=Yes M=Yes N="nosaukums" Z=false, C=datums1 T="DATE" P=Yes M=Yes N="datums1" Z=false);

#==============================================================# Table: pirkums#==============================================================CreateTble C=pirkums N="pirkums"( C="pers kods" T="INTEGER" P=Yes M=Yes N="pers kods" Z=false, C=datums12 T="DATETIME" P=Yes M=Yes N="datums12" Z=false, C=summa T="NUMBER" P=No M=Yes N="summa" Z=false, C=nopirktais_daudzums T="NOTE" P=No M=No N="nopirktais_daudzums" Z=false);

#==============================================================# Table: produkts#==============================================================CreateTble C=produkts N="produkts"( C=dzivnieka_vards T="NOTE" P=Yes M=Yes N="dzivnieka_vards" Z=false, C="der termins" T="DATE" P=Yes M=Yes N="der termins" Z=false, C=tips T="VARCHAR(20)" P=Yes M=Yes N="tips" Z=false, C=sarazotais_daudzums T="NOTE" P=No M=Yes N="sarazotais_daudzums" Z=false, C="tauku proc" T="NUMBER" P=No M=No N="tauku proc" Z=false, C="uzglabasanas temp" T="INTEGER" P=No M=No N="uzglabasanas temp" Z=false, C="produkta tips" T="VARCHAR(30)" P=No M=No N="produkta tips" Z=false, C=sastāvs T="VARCHAR(200)" P=No M=No N="sastāvs" Z=false);

#==============================================================# Table: satur#==============================================================CreateTble C=satur N="satur"( C=dzivnieka_vards T="NOTE" P=Yes M=Yes N="dzivnieka_vards" Z=false,

76

C="der termins" T="DATE" P=Yes M=Yes N="der termins" Z=false, C=tips T="VARCHAR(20)" P=Yes M=Yes N="tips" Z=false, C="pers kods" T="INTEGER" P=Yes M=Yes N="pers kods" Z=false, C=datums12 T="DATETIME" P=Yes M=Yes N="datums12" Z=false);

#==============================================================# View: "galas produkts"#==============================================================CreateView C="galas produkts" T="SELECT * FROM produkts WHERE tips='galas produkts'";

#==============================================================# View: "piena produkts"#==============================================================CreateView C="piena produkts" T="SELECT * FROM produkts WHERE tips='piena produkts'";

CreateJoin C=FK_RELATION_RELATIONS_CILVEKS T=Relationship_7 P=cilveks D=restrict U=restrict( P="pers kods" F="pers kods");

CreateJoin C=FK_RELATION_RELATIONS_BARS T=Relationship_7 P=bars D=restrict U=restrict( P="bara nr" F="bara nr");

CreateJoin C=FK_DZIVNIEK_PIEDER_BARS T=dzivnieks P=bars D=restrict U=restrict( P="bara nr" F="bara nr");

CreateJoin C="FK_LIETOSAN_BARS LIET_BARS" T=lietosana P=bars D=restrict U=restrict( P="bara nr" F="bara nr");

CreateJoin C="FK_LIETOSAN_LIETOT PL_PLAVA" T=lietosana P=Plava D=restrict U=restrict( P=nosaukums F=nosaukums);

CreateJoin C=FK_PIRKUMS_VEIC_CILVEKS T=pirkums P=cilveks D=restrict U=restrict( P="pers kods" F="pers kods");

CreateJoin C="FK_PRODUKTS_KLUST PAR_DZIVNIEK" T=produkts P=dzivnieks D=restrict U=restrict(

77

P=dzivnieka_vards F=dzivnieka_vards);

CreateJoin C=FK_SATUR_SATUR_PRODUKTS T=satur P=produkts D=restrict U=restrict( P=dzivnieka_vards F=dzivnieka_vards, P="der termins" F="der termins", P=tips F=tips);

CreateJoin C=FK_SATUR_SATUR2_PIRKUMS T=satur P=pirkums D=restrict U=restrict( P="pers kods" F="pers kods", P=datums12 F=datums12);

78