Realitāšu-saišu notācija€¦ · Web viewTā kā par vienu baru ir atbildīgi vairāki...
Transcript of Realitāšu-saišu notācija€¦ · Web viewTā kā par vienu baru ir atbildīgi vairāki...
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 MODELIS.............................................................................................83.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ŠANA....................................................................124.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 MODELIS.......................................................................................................377. 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ĀJUMI................................................................................................................................64LITERATŪ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.
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
3
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.
Ilustrācija 1 PowerDesigner versiju vēsture
4
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.
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.
5
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.
Ilustrācija 2 Sākotnējais konceptuālais modelis
6
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;
7
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
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.
8
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
Ir pieejami visi Realitāšu-saišu un Merise notācijas elementi:
1) realitāti;
2) saiti;
9
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;
10
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
11
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,
12
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.
13
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
14
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
15
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.
Ilustrācija 11. Domēna nodefinēšana
16
Ilustrācija 12. Domēna datu kopas definēšana
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.
17
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
22
kļūs par ārējām atslēgām (foreign key –FK). Ilustrācija 18 ir redzama saites starp dzīvnieku un
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
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
49
Š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
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
50
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.
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.
51
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.
52
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.
53
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ā.
55
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:
56
Ilustrācija 62 Kļūdas labojums
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
57
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
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:
59
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.
60
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
61
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
62
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
63
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.
64
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
65
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,
Sybase AS Enterprice 15.0,
Sybase AS Enterprice 15.0.2,
67
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
68
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"));
/*==============================================================*//* Table: bars *//*==============================================================*/
69
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, nopirktais_daudzums VARCHAR(254) null, constraint PK_PIRKUMS primary key ("pers kods", datums12));
70
/*==============================================================*//* 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") references bars ("bara nr") on delete restrict on update restrict;
71
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;
72
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;
RemoveTble C=satur;
73
#==============================================================# 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"( C=suga T="NOTE" P=No M=Yes N="suga" Z=false,
74
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, 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,
75
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( P=dzivnieka_vards F=dzivnieka_vards);
76