datubaze.files.wordpress.com · web vieweksistē vairākas notācijas, kurus lieto dkm...

Z. Žukova

„Objektorientētā un konceptuālā modeļu salīdzinājums relāciju datu bāzes ģenerēšanai”

Vadītājs: Dr. sc.ing., prof. J. Eiduks

Rīga, 2007.g.

SATURS

SATURS..................................................................................................................................................................................................................................2

ANOTĀCIJA..........................................................................................................................................................................................................................4

PROBLĒMSFĒRAS APRAKSTS........................................................................................................................................................................................5

UZDEVUMA NOSTĀDNE...................................................................................................................................................................................................7

UZDEVUMS #1......................................................................................................................................................................................................................8

DATU KONCEPTUĀLAIS MODELIS (DKM)...........................................................................................................................................................................8Kas ir DKM? ER/Merise-diagrammas, to pamatelementi..............................................................................................................................................8Domēni..........................................................................................................................................................................................................................11Realitātes, Atribūti un Identifikatori.............................................................................................................................................................................12Saites.............................................................................................................................................................................................................................16Asociācijas....................................................................................................................................................................................................................19Mantošana.....................................................................................................................................................................................................................20

TRANSFORMĀCIJA #1. DATU KONCEPTUĀLAIS MODELIS (DKM) DATU FIZISKAIS MODELIS (DFM)............................................................................23Kas ir DFM? Transformācijas likumi...........................................................................................................................................................................23Realitāšu, Atributu un Identifikatoru transformācija...................................................................................................................................................27Domēnu transformācija................................................................................................................................................................................................32Saišu transformācija.....................................................................................................................................................................................................32Associāciju un asocācijas linku transformācija...........................................................................................................................................................33Mantošanas transformācija..........................................................................................................................................................................................35

TRANSFORMĀCIJA #2. DFM DATU BĀZE MS ACCESS VIDĒ..........................................................................................................................................36Kļūdu un brīdinājumu analīze......................................................................................................................................................................................40

UZDEVUMS #2....................................................................................................................................................................................................................41

DATU OBJEKTORIENTĒTS MODELIS (OOM).......................................................................................................................................................................41Kas ir OOM? Klašu diagramma, tās pamatelementi....................................................................................................................................................41Klases............................................................................................................................................................................................................................44Domēni..........................................................................................................................................................................................................................44Saites (kompozīcija, asociācija, agregācija)................................................................................................................................................................45Interfeiss, realizācija, ports, pieprasījuma links...........................................................................................................................................................48Vispārināšana...............................................................................................................................................................................................................49

TRANSFORMĀCIJA #1. OBJEKTORIENTĒTAIS MODELIS (OOM) DATU KONCEPTUĀLAIS MODELIS (DKM)...................................................................50

2

Domēnu transformācija................................................................................................................................................................................................52Klašu transformācija....................................................................................................................................................................................................52Saišu transformācija.....................................................................................................................................................................................................53Interfeisu, realizāciju, portu, pieprasījuma linku transformācija.................................................................................................................................54Vispārināšanas transformācija.....................................................................................................................................................................................54

TRANSFORMĀCIJA #2. DATU KONCEPTUĀLAIS MODELIS (DKM) DATU FIZISKAIS MODELIS (DFM)............................................................................55TRANSFORMĀCIJA #3. DFM DATU BĀZE MS ACCESS VIDĒ..........................................................................................................................................57

SALĪDZINĀŠANA UN SECINĀJUMI..............................................................................................................................................................................59

OOM un DKM sākotnējo iespēju salīdzinājums...........................................................................................................................................................59Darbs ar Power Designer rīku un iegūto DFM salīdzinājums.....................................................................................................................................60

SAĪSINĀJUMI......................................................................................................................................................................................................................62

LITERATŪRAS SARAKSTS.............................................................................................................................................................................................63

3

ANOTĀCIJA

Darba mērķis – salīdzināt objektorientēto un konceptuālo pieeju sistēmu modelēšanai ar mērķi uzģenerēt relāciju datubāzi (RDB). Secināt kura no pieejām ir piemērotāka. Objektorientētā modeļa (OOM) realizācijai izvēlējos UML Klašu diagrammu, datu konceptuālā modeļa (DKM) – ER/Merise diagrammu. Modelēšanai izmantoju Sybase case rīku Power Designer.

Praktiskais piemērs balstās uz biznesa procesu vadības tehnoloģiju problēmsfēru. Respektīvi, relāciju datu bāzes projektējumu priekš Biznesa Procesu Vadības Dzinēja (turpmāk BPVD).

Pirmajā uzdevumā izveidoju konceptuālo modeli, kuru transformēju uz fizisko un tālāk uz datu bāzes ģenerēšanas skriptu, kuru iemportēju DBVSā un ieguvu RDB. Otrajā uzdevumā sākumā izveidoju objektorientēto modeli, kuru transformēju konceptuālajā un tālāk, tāpat kā pirmājā uzdevumā, ieguvu RDB. Pēc OOM transformācijas DKM tika pazaudēti objektorientēti elementi, ko ietekmēja mērķis iegūt RDB, nevis objektu datubāzi (ODB).

Lai būtu iespējams salīdzināt pirmā un otrā uzdevumu rezultātus – abos uzdevumos tika uzmodelēta viena un tā pati semantika. Abos uzdevumos struktūru definēju tikai sākotnējam modelim DKM vai OOM. Tālākajās transformācijās vairs neiejaucos, ļaujot rīkam pašam veidot gālējo struktūru pēc iebuvētajiem transformācijas noteikumiem.

Izanalizēju katru transformācijas posmu, salīdzināju abu modeļu sākotnējas iespējas ar rezultātiem RDB. Secināju, ka RDB ir iespējams uzgenerēt no abiem modeļiem, bet piemērotāks ir DKM, jo tā sākotnējie elementi atbilst RDB elementiem un modelēšana ir intuitīvi saprotama. OOM būtu mazāk piemērots RDB izveidei, jo specefiskie objektorientētie elementi – tādi kā metodes un interfeisi - pēc transformācijas uz RDB pazūd, kā arī attieksmju detalizācija (kompozīcija, agregācija, asociācija) nenonāk RDB, līdz ar to viņu definēšana zaudē jēgu.

Balstoties uz veikto analīzi secināju, ka vēloties uzbūvēt RDB, optimāli ir lietot atbilstošo modeli – konceptuālo, bet OOM jālieto būvējot ODB.

4

PROBLĒMSFĒRAS APRAKSTS

Problēmsfēras izvēli ietekmēja Biznesa Procesu Modelēšanas tehnoloģiju izmantošana darbavietā.

Kas ir BPEL?

BPEL - Business Process Execution Language ir Biznesa Procesu Izpildes Valoda priekš WEB Servisiem, tā ir XML notācija, kura apsraksta paplašinājamu kolekciju ar procesa vadības elementiem (abstrakcijām, aktivitāšu konteineriem, notikumu un izņēmumu apstrādi u.c.). Sākotnēji izstrādāja IBM, Microsoft un BEA, pašlaik ar izstrādi nodarbojas WSBPEL Tehniskā Komiteja.

Kas ir BPEL dzinējs?

BPEL dzinējs, rakstīts uz Java vai citas platformas, kas nolasa no datu bāzes BPEL procesu definīcijas un izveido BPEL procesu instances. Kad ienākošais ziņojums iedarbina trigeri, BPEL dzinējs izveido un piestartē jaunu biznesa procesa instanci. Dzinējs arī rūpējas par nepārtraktu uzdevumu padošanu, brīdinājumiem, rindām un citām izpildes detaļām.

BPEL process parasti apraksta biznesa procesu. BPEL process iesaista WEB servisus funkcionālo uzdevumu izpildē. Procesi dalās abstraktos vai palaižamos. Abstraktie apraksta biznesa procesus citiem avotiem, kas grib pieslēgties un izmantot tos. Palaižamie – satur izpildāmus soļus, kuri atspoguļo kādu uzdevumu.

Process sastāv no aktivitātēm, kas saistītas ar linkiem. (Process reizēm var saturēt tikai vienu aktivitāti, kas ir konteiners citām aktivitātēm). To, kā un kad jāizpildās ar linkiem saistītām aktivitātēm, var iedefinēt ar mainīgajiem un loģiskajām izteiksmēm.

Biznesa procesus var apvienot plānos. Tad katrs plāns noteiks viena vai vairāku procesu izpildi.

Šo tehnoloģiju izmanto lielās sistēmās, piemēram bankās, naktsdarbu automatizācijai, taču tai var atrast pielietojumu arī parastais datora lietotājs, piemēram iedefinējot kādus uzdevumus pie datora ieslēgšanas.

BPVD modeļa apraksts

Eksperimentāliem nolūkiem tika izstrādāts biznesa procesu vadības dzinēja datu bāzes modelis. Lai būtu iespējams salīdzināt pirmā un otrā uzdevumu rezultātus – abos uzdevumos tika uzmodelēta viena un tā pati

semantika.

5

Dzinējam ir datubāze, kurā glabājas saraksti ar visām iespējamām plāniem, procesiem un aktivitātēm, tie ir uzdevumu tipi. Tur pat, datubāzē glabājas uzdevumu instances, respektīvi: plānu procesi, jeb plāni ar iedefinētiem un sakārtotiem procesiem, procesu aktivitātes, jeb procesi ar iedefinētām un sakārtotām aktivitātēm.

Uzdevumu tipiem atbilst tabulas Activity_type, Process_type, Plan_type. Instancēm attiecīgi: Process_activities, Plan_processes.

Vēl ir tabulas Status_type, Activity_statuses. Aktivitāte ir atomāra uzdevuma vienība, taču lai būtu iespējams atsekot aktivitātes izpildi, tai tiek definēts parametrs statuss. Statuss norāda vai aktivitāte ir startēta, pabeigta vai ir neaktīva - „idle”. Statusa veidus nosaka tabulā Status_type iedefinēts statusu saraksts. Tabulā Activity statuses katrai aktivitātei piekārtoti iespējami statusi.

Lai biznesa procesam būtu iespējama zarošanās, tam ir nodrošināta brīdinājumu apstrāde. Brīdinājums ir kāds uzdevums, ko iespējams piekārtot attiecīgi plānam, procesam vai aktivitātei, lai nostrādātu kādas citas, brīdinājumā iedefinētas darbības startēšana. Brīdinājumam var arī iedefinēt taimeru, kurš nodrošinās viņa palaišanu pēc noteikta laika perioda kopš iedefinēta notikuma. Par brīdinājumu tipiem atbild tabula Alarm_type un viņas bērnu tabulas Activity_alarm, Process_alarm, Plan_alarm. Brīdinājuma instance ir iedefinēts brīdinājums, kurš ir piekārtots kādam uzdevumam, tas glabājas tabulā Alarm_instances.

Pati galvenā biznes procesu vadības dzinēja tabula ir Process_states. Šī tabula satur uzdevumu izpildes grafiku. Visus aktīvus plānus, procesus un aktivitātes. Brīdinājumu identifikatorus, kas

piekārtoti šiem uzdevumiem, kā arī uzdevumu iniciatoru, jeb lietotāju, kurš to palaida. Iespējamo lietotāju saraksts glabājas tabulā Initiator.

6

UZDEVUMA NOSTĀDNE

1. Uzdevums: uzģenerēt RDB no Datu Konceptuālā Modeļa, lietojot case rīku Power Designer: izveidot DKM transformēt DKM uz Datu Fizisko Modeli (DFM) DFM transformēt uz sql skriptu, lasāmu ar kādu DBVS Iegūto skriptu ielasīt DBVS un iegūt RDB

2. Uzdevums: uzģenerēt RDB no ObjektOrientētā datu Modeļa, lietojot case rīku Power Designer: izveidot OOM transformēt DKM uz DFM DFM transformēt uz sql skriptu, lasāmu ar kādu DBVS Iegūto skriptu ielasīt DBVS un iegūt RDB

3. Salīdzināt pieejas, veikt secinājumus.

7

UZDEVUMS #1

Uzģenerēt RDB no Konceptuāla Datu Modeļa, lietojot case rīku Power Designer: izveidot DKM transformēt DKM uz DFM DFM transformēt uz sql skriptu, lasāmu ar kādu DBVS Iegūto skriptu ielasīt DBVS un dabūt RDB

Datu Konceptuālais Modelis (DKM)

Kas ir DKM? ER/Merise-diagrammas, to pamatelementi

Kas ir DKM?

Datu bāzes dizains sākās konceptuālajā līmenī līdz ar DKM veidošanu. DKM 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ē.

Datu Konceptuālais Modelis atļauj: Grafiski atspoguļot datu organizāciju, veidot Realitāšu – Saišu diagrammas (ERD – Entity-Relationship Diagram) Validēt datu dizainu Uzģenerēt DFM, kas specificē datu bāzes fizisko implementēšanu Uzģenerēt OOM, kas specificē DKM izmantojot UML standartu Uzģenerēt citu DKM, ar mērķi izveidot citu modeļa versiju, kas atspoguļo citas dizaina stadijas.

8

ER/Merise diagrammas

Eksistē vairākas notācijas, kurus lieto DKM atspoguļošanai: ER, Merise, E/R + Merise, IDEF1X. Lielākoties šīs notācijas atspoguļo vienu un to pašu būtību, bet atškiras ar simboliskajiem apzīmējumiem.

Šajā darbā tiks lietota ER un Merise notācijas, jo tas ļauj precīzāk izklāstīt koncepciju.ER notācijā savieno divas realitātes ar saiti, atspoguļojot kādu attiecības veidu (1..*; *..*, u.t.t.). Šīm attiecībām ir īpašības,

kas ietekmē abas iesaistītas realitātes. Merise notācija atšķiras no ER ar to, ka tajā saišu vietā lieto tā sauktās asociācijas. Kad vairākas realitātes apvieno kāds

notikums, ko nevar īsti atspoguļot ar citu realitāti, viņas saista kopā ar asociāciju. Katrai realitātei izveidojas asociācijas saite ar asociāciju, kurai ir jāizvēlās attiecības veids (1..*; *..*, u.t.t.).

Savā modelī es uzskatīju par loģisku arī asociāciju izmantošanu, līdz ar to man šī ir jauktā notācija – ER/Merise.Turpmāk darbā varēs dziļāk iepazīties ar ER/Merise notāciju, uz apskatāma modeļa piemēra.

ER/Merise diagrammas pamatelementi

Domēns - kāda konkrēta lauka (atribūta) nozīmīgo vērtību kopu.

Realitāte – koncepts (persona, vieta, lieta utml.), kura īpašības ir svarīgas uzņēmumam un par kuru ir nepieciešams glabāt informāciju.

Realitātes atribūts – atomāra informācijas daļa, kas raksturo realitāti

Identifikators – realitātes atribūts, vai atribūtu kopa, kuru vērtība viennozīmīgi identificē katru realitātes vienību.

Saite – attiecība starp divām realitātēm.

Associācija – realitātes paveids, kas saista divas vai vairāk realitātes. Asociācija - ir realitāšu alternatīva. Arī tām ir raksturīga Merise notācija, kurā saišu vietā koncepšu savienošanai izmanto tikai asociācijas.

Asociāciju links - saite, kas savieno realitāti ar asociāciju.

Mantošana – īpaša attiecība, kura nosaka kā šī realitāte ir kādas visparīgākas realitātes konkrēta izpausme.

9

BPVD konceptuālais modelis

Attēlā 1. atspoguļots DKM, kas tika izstrādāts šīm uzdevumam.

is_a_type_of

0,n0,n 0,n0,n

is_ini tiated_by

Is_an_instance_of

includes

is_defined_byis_defined_byis_defined_by

includes

includes

is_defined_by is_defined_by is_defined_by

0,n 0,n

includesincludes

Plan_type

Plan_namePlan_idPlan_desc

<pi>NAMEIDDESCRIPT ION

<M>

Plan_id <pi>

Process_type

Process_nameProcess_descriptionProcess_id <pi>

NAMEDESCRIPTIONID <M>

Process_id <pi>

Alarm_type

Alarm_actionAlarm_intervalAlarm_descAlarm_id <pi>

IDIntegerDESCRIPT IONID

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

Alarm_id <pi>

Alarm_instances

Alarm_start_timeAlarm_inst_id <pi>

T IMEID

Alarm_inst_id <pi>

Process_alarm Plan_alarmActivi ty_alarm

Process_states

Activi ty_start_timeStatus_start_timeProcess_state_id <pi>

T IMETIMEID <M>

Proces_state_id <pi>

Initiator

Initiator_nameInitiator_descInitiator_id <pi>

NAMEDESCRIPT IONID <M>

Initiator_id <pi>

Activi ty_type

Activi ty_nameActivi ty_descActivi ty_id <pi>

NAMEDESCRIPT IONID

Activi ty_id <pi>

Process_activi ties

Prev_activi ty_idNext_activi ty_id

IDID

Plan_processes

Status_type

Status_nameStatus_descStatus_idStatus_value

<pi>

NAMEDESCRIPT IONIDSTAT US

<M>

Status_id <pi>

Activi ty_statuses

Att. 1 BPVD Konceptuālais Datu Modelis

10

BPVD konceptuālo elementu apraksts

Tālāk detalizētāk tiek aprakstīti modeļa elementi no fiziskās implementācijas skatījuma, ar mērķi atsekot un izanalizēt šo elementu transformāciju uz reāliem fiziskiem elementiem Datu Fiziskajā Modelī.

Domēni

Domēna veidošana rīkā Power Designer

1. Solis – Domēna definēšna.Lai iedefinētu domēnu ModelDomains, jāpieliek sarakstam jauns ieraksts ar domēna nosaukumu, datu tipu u.c

raksturojumiem. 2. Solis – Domēna specificēšana.

Konkrētam domēnam var norādīt vērtību apgabalu, min-max-default vērtības, vai arī iedefinēt iespējamas vērtības(skat Att. 2)

Att. 2 Domēna specificēšanaTabula 1 Domēni BPVD modelī

11

Nosaukums Kods Datu tips Nolūksdate DATE Date Procesu, plānu, aktivitāšu un brīdinājumu palaišanas laiku uzstādīšanaidescription DESCRIPTION Text Kāda procesa elementa tipa aprakstamid ID Integer Identifikatoriemname NAME Text Biznes procesa elementa nosaukumamtime TIME Time Procesu, plānu, aktivitāšu un brīdinājumu palaišanas laiku uzstādīšanai

Realitātes, Atribūti un Identifikatori

Realitātes veidošana rīkā Power Designer

1. Solis – Realitātes definēšna.Lai iedefinētu realitāti ModelEntities,

jāpieliek sarakstam jauns ieraksts ar realitātes nosaukumu.

2. Solis – Realitātes atribūtu definēšanaJaunizveidotai realitātei ieliktnī Attributes

jāiedefinē atribūti, un to datu tips. Izvēloties atribūtam domēnu, datu tips būs piešķirts tāds pats kā atbilstošam domēnam.

3. Solis – Identifikatoru definēšanaJaunizveidotai realitātei ieliktnī Identifiers

var pielikt kādu no esošajiem, vai jaunu atribūtu, atzīmējot viņam „p”, pēc transformācijas uz fizisko modeli tas kļūst par tabulas primāro atslēgu. Ja par identifikatoru izvēlēts kāds no esošajiem atribūtiem, un ir vēlme, lai viņš kļūst par primāro atslēgu, ieliktnī Attributes arī jāatzīmē burts „p”. (skat. Error: Reference source notfound), savādāk tas paliks par alternatīvo atslēgu. Att. 3 Identifikatoru definēšana

12

Realitātes, Atribūti un Identifikatori BPDM modelī (Skat. Tabula 2)Tabula 2 BPVD modeļa realitātes

Activity_type


NAMEDESCRIPT IONID

Activi ty_id <pi>

ACTIVITY_TYPE - Saraksts ar biznesa procesu aktivitāšu veidiem

Nosaukums Kods Identifikators Domēns NolūksActivity_name ACTIVITY_NAME - Text Aktivitātes nosaukumsActivity_desc ACTIVITY_DESC - Text Aktivitātes aprakstsActivity_id ACTIVITY_ID Prim.atslēga Integer Aktivitātes identifikators

Alarm _instances

Alarm _start_timeAlarm _inst_id <pi>

T IMEID

Alarm _inst_id <pi>

ALARM_INSTANCES - Brīdinājuma precedenti. Parādās tikai biznesa procesu, plānu vai aktivitāšu darbības laikā.

Nosaukums Kods Identifikators Domēns NolūksAlarm_start_time ALARM_START_TIME - time Brīdinājuma palaišanas brīdisAlarm_inst_id ALARM_INST_ID Prim.atslēga id Brīdinājuma identifikators

Alarm_type



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

Alarm_id <pi>

ALARM_TYPE - Saraksts ar brīdinājumu veidiem

Nosaukums Kods Identifikators Domēns NolūksAlarm_action ALARM_ACTION Prim.atslēga id Darbība, kurai jāpalaižās brīdinājuma

nostradāšanas gadījumā

13

Alarm_interval ALARM_INTERVAL - <None> Intervāls starp brīdinājuma palaišanu un nostrādāšanu

Alarm_desc ALARM_DESC - description Brīdinājuma aprakstsAlarm_id ALARM_ID Prim.atslēga id Brīdinājuma identifikators

Ini tiator

Ini tiator_nameIni tiator_descIni tiator_id <pi>


Ini tiator_id <pi>

INITIATOR - Saraksts ar aktieriem, kas var palaist biznesa procesu, plānu vai aktivitāti

Nosaukums Kods Identifikators Domēns NolūksInitiator_name INITIATOR_NAME Text name Iniciatora nosaukumsInitiator_desc INITIATOR_DESC Text description Iniciatora aprakstsInitiator_id INITIATOR_ID Integer id Iniciatora identifikators

Plan_type


<pi>NAM EIDDESCRIPT ION

<M >

Plan_id <pi>

PLAN_TYPE - Saraksts ar plānu veidiem

Nosaukums Kods Identifikators Domēns NolūksPlan_name PLAN_NAME name Plāna nosaukumsPlan_id PLAN_ID Prim.atslēga id Plāna identifikatorsPlan_desc PLAN_DESC description Plāna apraksts

Process_states

Activi ty_start_tim eStatus_start_timeProcess_state_id <pi>

TIMETIMEID <M>


PROCESS_STATES

Galvenā realitāte, kas atspoguļo Biznesa procesu izpildes norisi

Nosaukums Kods Identifikators Domēns NolūksActivity_start_time ACTIVITY_START_TIME - time Aktivitātes palaišanas brīdisStatus_start_time STATUS_START_TIME - time Aktivitātes statusa nomaiņas brīdisProcess_state_id PROCESS_STATE_ID Prim.atslēga id Procesa stāvokļa identifikators

14

Process_type



Process_id <pi>

PROCESS_TYPE

Saraksts ar biznesa procesiem

Nosaukums Kods Identifikators Domēns NolūksProcess_name PROCESS_NAME - name Biznesa procesa nosaukumsProcess_description PROCESS_DESCRIPTION - description Procesa aprakstsProcess_id PROCESS_ID Prim.atslēga id Procesa identifikators

Status_type

Status_nam eStatus_descStatus_idStatus_value

<pi>

NAMEDESCRIPT IONIDST ATUS

<M>

Status_id <pi>

STATUS_TYPE - araksts ar statusiem, kurā var atrasties aktivitāte

Nosaukums Kods Identifikators Domēns NolūksStatus_name STATUS_NAME name Statusa nosaukumsStatus_desc STATUS_DESC description Statusa aprakstsStatus_id STATUS_ID Prim.atslēga id Statusa identifikatorsStatus_value STATUS_VALUE Status Statusa vērtība

Zemāk apskatītas ir bērnu realitātes vecākam ALARM_TYPE, līdz ar to tie mantos vecāka atribūtus un konceptuālā līmenī paliek tukšas.

Activity_alarm ACTIVITY_ALARM - Brīdinājuma paveids. Brīdinājums, ko var izraisīt tikai aktivitātes darbība

Process_alarm PROCESS_ALARM - Brīdinājuma paveids. Brīdinājums, ko var izraisīt tikai procesa darbība

15

Plan_alarm

PLAN_ALARM - Brīdinājuma paveids. Brīdinājums, ko var izraisīt tikai plāna darbība

Saites

Saišu veidošana rīkā Power Designer

1. Solis - Saites veidošana.Lai izveidotu saites izvelnē ModelRelationships (skat. Att. 4), jāpieliek jauns ieraksts, norādot abas saistītas realitātes.

Att. 4 Saites veidošanas piemērs rīkā Power Designer

16

2. Solis – Saites specificēšana.Kad saite ir izveidota, tā ir jāspecificē, norādot attiecības starp realitātēm. Šīs ir būtisks moments, jo tas ietekmēs modeļa

transformāciju.

Att. 5 Saites specificēšana

Divreiz noklikšķinot uz saites parādās tās īpašību izvelne. Ieliktnī „Cardinalities” norādam attiecības katrai realitātei pret otru (0,1; 0,n; 1,1; 1,n).

17

Saites BPVD modelī

- nulle vai daudz pret vienu

- viens pret nulle vai daudziem

- nulle vai viens pret vienu

Tabula 3 Saites BPVD modelī

Nosaukums Kods Realitāte #1 Saite Realitāte #2includes RELATIONSHIP_9 Alarm_instances Process_statesincludes INCLUDES Process_type Process_statesincludes RELATIONSHIP_14 Plan_type Process_statesincludes RELATIONSHIP_15 Activity_type Process_statesIs_an_instance_of IS_AN_INSTANCE_OF Alarm_type Alarm_instancesis_defined_by IS_DEFINED_BY Plan_type Plan_alarmis_defined_by RELATIONSHIP_7 Process_alarm Process_typeis_defined_by RELATIONSHIP_12 Activity_type Process_alarmis_defined_by RELATIONSHIP_11 Status_type Process_statesis_defined_by RELATIONSHIP_10 Activity_alarm Status_typeis_defined_by RELATIONSHIP_13 Process_type Plan_alarmis_defined_by RELATIONSHIP_8 Activity_alarm Activity_typeis_initiated_by IS_INITIATED_BY Initiator Process_states

18

Asociācijas

Asociācijas veidošana rīkā Power Designer.

1. Solis - Asociācijas veidošana.Asociāciju var izveidot no galvenās izvelnes ModelAssociations.

2. Solis – Asociācijas linka veidošana un specificēšana.Tad nepieciešams saistīt šo asociāciju ar vienu vai vairākām relācijam (skat Att. 6). Norādam relāciju, asociāciju un

specificējam attiecības (0,1; 0,n; 1,1; 1,n).

Att. 6 Asociācijas Linka definēšana

19

Asociācijas BPVD modelīTabula 4 Asociācijas un to linki izmantoti BPVD modelī

Process_activi ties


IDID

PROCESS_ACTIVITIES - sakārtots aktivitāšu saraksts, piesaistīts procesam.Saista relācijas PROCESS_TYPE un ACTIVITY_TYPE ar asociācijas linka kardinalitāti 0..*.

Nosaukums Domēns NolūksPREV_ACTIVITY_ID name Iepriekšējas aktivitātes identifikatorsNEXT_ACTIVITY_ID description Nākamās aktivitātes identifikators

Activi ty_statusesACTIVITY_STATUSES - Saraksts ar iespējamiem aktivitātes statusiemSaista relācijas STATUS_TYPE un ACTIVITY_TYPE ar asociācijas linka kardinalitāti 0..*.Atribūtu nav, jo ir atkarīgs no saistītām realitātēm

Plan_processes PLAN_PROCESSES – sakārtots katra plāna procesu saraksts.Saista relācijas PLAN_TYPE un PROCESS_TYPE ar asociācijas linka kardinalitāti 0..*.Atribūtu nav, jo ir atkarīgs no saistītām realitātēm.

Mantošana

Mantošanas veidošana rīkā Power Designer.

1. Solis – Realitātes pārvēršana par Vēcāku, jeb mantošanas elementa veidošana.Galvenajā izvelnē ModelInheritance definējam mantošanas saiti kādai realitātei.

20

2. Solis – Bērnu definēšana. Mantošanas saites ieliktnī Children definējam bērnu realitātes, piesaistot tos vecāku realitātei (skat. Att. 7)

Att. 7 Mantošanas definēšana

Attēlā 8 parādīta mantošana BPVD modelī. Vispārīgajam tipam Alarm_type ir definēti specifiskāki brīdinājumu paveidi, Activity_alarm, Process_alarm un Plan_alarm.

21

is_a_type_of

Alarm _type

Alarm _actionAlarm _intervalAlarm _descAlarm _id <pi>


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

Alarm _id <pi>

Process_alarmPlan_alarmActivi ty_alarm

Att. 8 Mantošanas atspoguļošana

Mantošana BPVD Modelī

Tabula 5 BPVD Modelī definēta mantošana

Nosaukums Kods Vecāka realitāte Bērna realitāteis_a_type_of IS_A_TYPE_OF Alarm_type Process_alarmis_a_type_of IS_A_TYPE_OF Alarm_type Plan_alarmis_a_type_of IS_A_TYPE_OF Alarm_type Activity_alarm

Bērnu realitātēm konceptuālajā modelī nav atribūtu, taču, izņemot vecāku realitāti, tie ir arī saistīti ar citām tabulām, no kurām pēc transformācijas iegūs specifiskus atribūtus.

22

Transformācija #1. Datu konceptuālais modelis (DKM) Datu fiziskais modelis (DFM)

Kas ir DFM? Transformācijas likumi.

DFM – ir datu bāzes dizaina fiziskais modelis. Tas definē fizisko struktūru un datu vaicājumu implementāciju. Kad ģenerē datu fizisko modeli no konceptuālā, Power Designer pēc iebūvētajiem likumiem pārkonvertē DKM objektus un datu tipus par DFM objektiem un datu tipiem. Jābūt uzmanīgam ar datu tipu konvertāciju. Lai izvairītos no konvertācijas problēmām, jau DKM līmenī jādefinē tikai tādus datu tipus, ko uztur konkrētā DBVS. Piemēram, strādājot ar Access, tādu tipu kā varchar2 jāaizvieto ar string.

DFM ģenerācija pārkonvertē konceptuālos objektus fiziskajos atbistoši Tabula 6

Tabula 6 Konceptuālo objektu konvertācija fiziskajos

DKM objekti Kardinalitāte

Uzģenerētie DFM objekti

Realitāte TabulaRealitātes atribūts Tabulas kolonnaPrimārais identifikators Primārā atslēga savā tabulā

Papildus kolonna un sveša atslēga saistītajās tabulāsIdentifikators Alternatīva atslēga savā tabulāSaite Atsauce

*..* Veidojas starptabula, kas ir saistīta ar abām tabulām ar obligāto atsauci 1..*

1..*, *..1 No tabulas ar attiecību * uz tabulu ar attiecību 1 veidojas obligāta atsauce

0..*, 0..* No tabulas ar attiecību * uz tabulu ar attiecību 0 veidojas neobligāta atsauce

1..1, 0..0 Veidojas 2 obligātas vai 2 neobligātas atsauces uz abām tabulām1..0, 0..1 Veidojas 2 atsauces, obligāta un neobligāta

Mantošanas Veidojas atsevišķa saite katrai bērnu tabulai ar vecākuAsociācija TabulaAsociācijas links Atsauce

23

Iespējams iedefinēt, kā tiks veidoti nosaukumi modeļa elementiem.BPVD modelī izmantoju automātisko kolonnu pārsaukšanu, Divas kolonnas nevar būt vienlaikus vienādi nosauktas. Ja kolonnas nosaukums konfliktē dēļ svešas atslēgas migrācijas,

PowerDesigner automātiski pārsauc migrēto kolonnu. Jaunais kolonnas nosaukums ir salikts no originālās relācijas nosaukuma 3 pirmajiem burtiem pluss atribūta kods.

DKMDFM transformācija rīkā Power Designer

1. Solis – DBVS izvēle, kurā plānots implementēt datu bāzi.Vajadzīgo DBVS var izvēlēties galvenajā izvelnē atverot ieliktni DatabaseChange Current DBMS. Manā gadijumā DBVS

bija MS Access. To var arī norādīt pie pašas ģenerēšanas (skat Att.10)2. Solis – DFM ģenerēšanas konfigurācija

Konfigurācija pieejama izvelnē ToolsGenerate Physical Model. Ieliktnī Selection var norādīt, kurus objektus iekļaut DFM. Lai vispār būtu iespējams uzģenerēt objektus, katra objekta īpašībās vajag iezīmēt opciju Generate. Tad tie parādīsies Selection ieliktnī un tos varēs iekļaut vai neiekļaut modelī.

24

Att 9.2 DFK ģenerēšana

Attēlā 10 parādīts BPVD modelis pēc transformācijas no DKM uz DFM.

25

FK_PROCESS__IS_A_TYPE_ALARM_T Y

FK_PLAN_ALA_IS_A_TYPE_ALARM _TYFK_ACTIVIT Y_IS_A_TYPE_ALARM_TY

FK_PROCESS__PROCESS_A_PROCESS_FK_PROCESS__PROCESS_A_ACTIVIT Y FK_PLAN_PRO_PLAN_PROC_PLAN_T YP

FK_PLAN_PRO_PLAN_PROC_PROCESS_

FK_PROCESS__IS_INIT IA_INIT IATO

FK_ALARM_IN_IS_AN_INS_ALARM_T Y

FK_PROCESS__INCLUDES_PROCESS_

FK_PLAN_ALA_IS_DEFINE_PLAN_T YPFK_PROCESS__RELAT IONS_PROCESS_FK_ACT IVIT Y_RELAT IONS_ACTIVITY

FK_ALARM_IN_RELAT IONS_PROCESS_

FK_PROCESS__RELATIONS_ALARM_IN

FK_PROCESS__RELATIONS_STATUS_T

FK_ACT IVITY_RELAT IONS_STATUS_T FK_PROCESS__RELAT IONS_ACTIVITY FK_PLAN_ALA_RELATIONS_PROCESS_

FK_ACT IVITY_ACTIVITY__STAT US_TFK_ACTIVIT Y_ACTIVITY__ACT IVITY

FK_PROCESS__RELAT IONS_PLAN_T YP

FK_PROCESS__RELAT IONS_ACT IVITY

Plan_type


NOTEINTEGERNOTE

<pk>

Process_type

Process_nameProcess_descriptionProcess_id

NOT ENOT EINTEGER <pk>

Alarm_type

Alarm_actionAlarm_intervalAlarm_descAlarm_id

INTEGERINTEGERNOT EINTEGER <pk>

Alarm_instances

Alarm_start_timeAlarm_inst_idAlarm_idProcess_state_id

TIM EINT EGERINT EGERINT EGER

<pk><fk1><fk2>

Process_alarm

Alarm_idActivi ty_idProcess_id

INT EGERINT EGERINT EGER

<pk,fk3><fk2><fk1>

Plan_alarm

Alarm_idProcess_idPlan_id

INTEGERINTEGERINTEGER

<pk,fk3><fk2><fk1>

Activi ty_alarm

Alarm_idStatus_idActivi ty_id


<pk,fk3><fk2><fk1>

Process_states

Activi ty_start_timeStatus_start_tim eProcess_state_idActivi ty_ idInitia tor_idAlarm_inst_idPlan_idProcess_idStatus_id

TIM ETIM EINT EGERINT EGERINT EGERINT EGERINT EGERINT EGERINT EGER

<pk><fk6><fk1><fk3><fk5><fk2><fk4>

Initia tor

Ini tiator_nameInitiator_descInitiator_id

NOT ENOT EINT EGER <pk>

Activi ty_type

Activi ty_nameActivi ty_descActivi ty_ id

NOT ENOT EINTEGER <pk>

Process_activi ties

Process_idActivi ty_idPrev_activi ty_idNext_activi ty_id

INT EGERINT EGERINT EGERINT EGER

<pk,fk1><pk,fk2>

Plan_processes

Plan_idProcess_id

INTEGERINTEGER

<pk,fk1><pk,fk2>

Status_type


NOT ENOT EINT EGERNOT E

<pk>

Activi ty_statuses

Status_idActivi ty_id

INTEGERINTEGER

<pk,fk1><pk,fk2>

Att. 9 BPVD Fiziskais Datu Modelis

26

DKMDFM transformācija BPVD modelī

Realitāšu, Atributu un Identifikatoru transformācija

Tabula 7 Realitāšu transformācija tabulās

# Realitātes kods Uzģenerētās tabulas kods1 ACTIVITY_ALARM ACTIVITY_ALARM2 ACTIVITY_TYPE ACTIVITY_TYPE3 ALARM_INSTANCES ALARM_INSTANCES4 ALARM_TYPE ALARM_TYPE5 INITIATOR INITIATOR6 PLAN_ALARM PLAN_ALARM7 PLAN_TYPE PLAN_TYPE8 PROCESS_ALARM PROCESS_ALARM9 PROCESS_STATES PROCESS_STATES10 PROCESS_TYPE PROCESS_ACTIVITIES11 STATUS_TYPES STATUS_TYPE

Rezultāts: Pēc transformācijas visas realitātes palika par tabulām. Tabulu līmenī izmaiņas struktūrā nenotika.

Atribūti, Identifikatori transformējās uz kolonnām un atslēgām.

27

Att. 10 Atribūtu un Identifikatoru transformācijas piemērs BPVD

Atslēgu ģenerēšana no identifikatoriemPrimārie identifikatori DFMā ģenerē primārās un svešās atslēgas. Identifikatori, kas nav primārie, ģenerē altarnatīvas

atslēgas. Atslēgas tips, kas tik uzģenerēts DFM, ir atkarīgs no starprelāciju saites specifikas.

Primārā atslēga – kolonna vai kolonnas, kuru vērtības unikāli identificē tabulas rakstu.Sveša atslēga – kolonna vai kolonnas, kuras ir atkarīgas un migrētas no primāras atslēgas kolonnas citā tabulā.Alternatīva atslēga – kolonna vai kolonnas, kuru vērtības unikāli identificē tabulas rakstu, bet nav primāras atslēgas.

Tabula 8 Realitāšu un identifikatoru transformācija BPVD

28

Pēc transformācijas sekojošas tabulas palika nemainīgas, jo nebija atkarīgas no citām tabulām.Process_type



Process_id <pi>

Process_type

Process_nam eProcess_descriptionProcess_id <pi>


Process_id <pi>

Activity_type

Activity_nam eActivity_descActivity_id <pi>

NAM EDESCRIPT IONID

Activity_id <pi>

Activi ty_type

Activi ty_nameActivi ty_descActivi ty_id

NOTENOTEINTEGER <pk>

Plan_type



<M >

Plan_id <pi>

Plan_type


NOTEINTEGERNOTE

<pk>

Status_type


<pi>

NAMEDESCRIPT IONIDSTATUS

<M>

Status_id <pi>

Status_type


NOTENOTEINTEGERNOTE

<pk>

Alarm_type



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

Alarm_id <pi>

Alarm_type


INTEGERINTEGERNOTEINTEGER <pk>

29

Ini tiator

Ini tiator_nam eIni tiator_descIni tiator_id <pi>


Ini tiator_id <pi>

Ini tiator

Ini tiator_nameIni tiator_descIni tiator_id

NOTENOTEINTEGER <pk>

Sekojošās tabulas papildinājās ar kolonnām:

Activi ty_alarm

Activi ty_alarm



<pk,fk3><fk2><fk1>

Migrēts no realitātes Migrētās kolonnas nosaukums Palika par identifikatoruAlarm_type Alarm_id PK, FKActivity_type Activity_id FKStatus_type Status_id FK

Process_alarm

Process_alarm

Alarm _idActivi ty_idProcess_id


<pk,fk3><fk2><fk1>

Migrēts no realitātes Migrētās kolonnas nosaukums Palika par identifikatoruAlarm_type Alarm_id PK, FKActivity_type Activity_id FKProcess_type Process_id FK

Plan_alarm

Plan_alarm

Alarm _idProcess_idPlan_id


<pk,fk3><fk2><fk1>

Migrēts no realitātes Migrētās kolonnas nosaukums Palika par identifikatoruAlarm_type Alarm_id PA, FAProcess_type Process_id FKPlan_type Plan_id FK

30

Process_states

Activi ty_start_tim eStatus_start_timeProcess_state_id <pi>

T IMET IMEID <M>


Process_states

Activi ty_start_timeStatus_start_timeProcess_state_idActivi ty_idIni tiator_idAlarm _inst_idPlan_idProcess_idStatus_id

T IMET IMEINTEGERINTEGERINTEGERINTEGERINTEGERINTEGERINTEGER

<pk><fk6><fk1><fk3><fk5><fk2><fk4>

Migrēts no realitātes Migrētās kolonnas nosaukums Palika par identifikatoruActivity_type Activity_id FKInitiator_type Initiator_id FKAlarm_instances Alarm_inst_id FKPlan_type Plan_id FKProcess_type Process_id FKStatus_type Status_id FK

Alarm_instances


T IMEID

Alarm_inst_id <pi>

Alarm_instances

Alarm_start_timeAlarm_inst_idAlarm_idProcess_state_id

T IMEINTEGERINTEGERINTEGER

<pk><fk1><fk2>

Migrēts no realitātes Migrētās kolonnas nosaukums Palika par identifikatoruAlarm_type Alarm_id FKProcess_states Process_state_id FK

31

Domēnu transformācija

Pēc transformācijas domēni palika nemainīgi.

Saišu transformācija

Pēc transformācijas esošās saites saglabājās ar jaunu nosaukumu, kā arī parādījās jaunas.Saites atspoguļo svešās atslēgas, ar kurām tika papildinātas atkarīgās tabulas. Saites palika par atsaucēm.

Tabula 9 saišu transformācija BPVD modelī

Atsauces kods Vecāka tabula Bērnu tabula Saites nosaukums tips atslēga

Saites ar tipu 1..*, *..1, 0..*, 0..* saglabājās

RELATIONSHIP_11 Status_type Process_states FK_PROCESS__RELATIONS_STATUS_T 0..* Status_idRELATIONSHIP_15 Plan_type Process_states FK_PROCESS__RELATIONS_PLAN_TYP 0..* Plan_idRELATIONSHIP_9 Process_states Alarm_instances FK_ALARM_IN_RELATIONS_PROCESS_ 0..1 Proces_state_idINCLUDES Process_type Process_states FK_PROCESS__INCLUDES_PROCESS_ 0..* Process_idRELATIONSHIP_10 Alarm_instances Process_states FK_PROCESS__RELATIONS_ALARM_IN 1..1 Alarm_inst_idIS_AN_INSTANCE_OF Alarm_type Alarm_instances FK_ALARM_IN_IS_AN_INS_ALARM_TY 0..* Alarm_idRELATIONSHIP_8 Activity_type Activity_alarm FK_ACTIVITY_RELATIONS_ACTIVITY 0..* Activity_idRELATIONSHIP_14 Process_type Plan_alarm FK_PLAN_ALA_RELATIONS_PROCESS_ 0..* Process_idRELATIONSHIP_7 Process_type Process_alarm FK_PROCESS__RELATIONS_PROCESS_ 0..* Process_idRELATIONSHIP_12 Status_type Activity_alarm FK_ACTIVITY_RELATIONS_STATUS_T 0..* Status_idRELATIONSHIP_13 Activity_type Process_alarm FK_PROCESS__RELATIONS_ACTIVITY 0..* Activity_idRELATIONSHIP_16 Activity_type Process_states FK_PROCESS__RELATIONS_ACTIVITY 0..* Activity_idIS_DEFINED_BY Plan_type Plan_alarm FK_PLAN_ALA_IS_DEFINE_PLAN_TYP 0..* Plan_idIS_INITIATED_BY Initiator Process_states FK_PROCESS__IS_INITIA_INITIATO 0..* Initiator_id

32

Transformējot saiti ar tipu 0..1 izveidojas 2 saites: viena obligāta un otra neobligāta

RELATIONSHIP_9 Process_states Alarm_instances FK_ALARM_IN_RELATIONS_PROCESS_ 0..1 Proces_state_idRELATIONSHIP_10 Alarm_instances Process_states FK_PROCESS__RELATIONS_ALARM_IN 1..1 Alarm_inst_id

Mantošanas saites - transfromējās sekojoši: izveidojās atsevišķa saite katrai bērnu tabulai ar vecāka tabulu

IS_A_TYPE_OF3 Alarm_type Activity_alarm FK_ACTIVITY_IS_A_TYPE_ALARM_TY 0..* Alarm_idIS_A_TYPE_OF2 Alarm_type Plan_alarm FK_PLAN_ALA_IS_A_TYPE_ALARM_TY 0..* Alarm_idIS_A_TYPE_OF Alarm_type Process_alarm FK_PROCESS__IS_A_TYPE_ALARM_TY 0..* Alarm_id

Asociāciju linki – palika par saitēm ar tipu 0..*

ACTIVITY_STATUSES Status_type Activity_statuses FK_ACTIVITY_ACTIVITY__STATUS_T 0..* Status_idACTIVITY_STATUSES2 Activity_type Activity_statuses FK_ACTIVITY_ACTIVITY__ACTIVITY 0..* Activity_idPLAN_PROCESSES Plan_type Plan_processes FK_PLAN_PRO_PLAN_PROC_PLAN_TYP 0..* Plan_idPLAN_PROCESSES2 Process_type Plan_processes FK_PLAN_PRO_PLAN_PROC_PROCESS_ 0..* Process_idPROCESS_ACTIVITIES Process_type Process_activitie

sFK_PROCESS__PROCESS_A_PROCESS_ 0..* Process_id

PROCESS_ACTIVITIES2 Activity_type Process_activities

FK_PROCESS__PROCESS_A_ACTIVITY 0..* Activity_id

Associāciju un asocācijas linku transformācija

Tabulas 10 un 11 pārāda, kā asociācijas transformējas uz tabulām un linki uz atsaucēm.

Tabula 10 Asociāciju transformācija BPVD modelī

Process_activi ties

Prev_activity_idNext_activity_id

IDID

Process_activi ties


INTEGERINTEGERINTEGERINTEGER

<pk,fk1><pk,fk2>

Migrēts no realitātes Migrētās kolonnas nosaukums Palika par identifikatoru

33

Process_type Process_id PK, FKActivity_type Activity_id PK, FK

Activi ty_statuses

Activi ty_statuses


INTEGERINTEGER

<pk,fk1><pk,fk2>

Migrēts no realitātes Migrētās kolonnas nosaukums Palika par identifikatoruStatus_type Status_id PK, FKActivity_type Activity_id PK, FK

Plan_processes

Plan_processes

Plan_idProcess_id

INTEGERINTEGER

<pk,fk1><pk,fk2>

Migrēts no realitātes Migrētās kolonnas nosaukums Palika par identifikatoruPlan_type Plan_id PK, FKProcess_type Process_id PK, FK

Tabula 11 Asociāciju linku transformācija BPVD modelī

Atsauces kods Vecāka tabula Bērnu tabula Atsauces nosaukums tips atslēgaACTIVITY_STATUSES Status_type Activity_statuses FK_ACTIVITY_ACTIVITY__STATUS_T 0..* Status_idACTIVITY_STATUSES2 Activity_type Activity_statuses FK_ACTIVITY_ACTIVITY__ACTIVITY 0..* Activity_idPLAN_PROCESSES Plan_type Plan_processes FK_PLAN_PRO_PLAN_PROC_PLAN_TYP 0..* Plan_idPLAN_PROCESSES2 Process_type Plan_processes FK_PLAN_PRO_PLAN_PROC_PROCESS_ 0..* Process_idPROCESS_ACTIVITIES Process_type Process_activities FK_PROCESS__PROCESS_A_PROCESS_ 0..* Process_idPROCESS_ACTIVITIES2 Activity_type Process_activities FK_PROCESS__PROCESS_A_ACTIVITY 0..* Activity_id

34

Mantošanas transformācija

Mantošanas transformācija rīkā Power Designer

1. Solis InheritancePropertiesGeneration

Lai bērnu tabulās nonaktu tikai primārie viecāka atribūti, jāatzīmē punktu “Mantot tikai primāros atribūtus” ģenerējot Fizisko modeli (skat. Att. 11)

Att. 11 Mantošanas konfigurācija

Rezultātā fiziskajā modelī bērnu tabulas ieguva tikai primārus vecākas tabulas atribūtus, nevis kopiju no visām vecāku tabulas atribūtiem.

35

Att. 12 BPVD mantošanas

transformācija no DKM uz DFM

Transformācija #2. DFM Datu bāze MS Access vidē

DFM Datu bāze MS Access vidē, transformācija rīkā Power Designer

1. Solis – Datu bāzes skripta ģenerēšana

Datu bāzes importam kādā DBVSā, ģenerē skriptu ar objektu veidošanas vaicājumiem. Izvelnē DatabaseGenerate Database, var sakonfigurēt šo ģenerēšanu. Ieliktnī Selection jāatzīmē struktūras, kuras nepieciešams iekļaut skriptā, bet pašu skripta saturu var apskatīties ieliktnī Preview (skat Att. 13). Uzģenerētais skripts atrodams Power Designer direktorijās.

FK_PROCESS__IS_A_TYPE_ALARM_TY

FK_PLAN_ALA_IS_A_TYPE_ALARM_T YFK_ACTIVIT Y_IS_A_TYPE_ALARM_T Y

Alarm_type


INTEGERINTEGERNOT EINTEGER <pk>

Process_alarm

Alarm_idActivi ty_idProcess_id


<pk,fk3><fk2><fk1>

Plan_alarm

Alarm_idProcess_idPlan_id


<pk,fk3><fk2><fk1>

Activi ty_alarm


INT EGERINT EGERINT EGER

<pk,fk3><fk2><fk1>

is_a_type_of

Alarm_type



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

Alarm_id <pi>

Process_alarmPlan_alarmActivity_alarm

36

Att. 13 Datu bāzes *.sql skripta ģenerēšana

2. Solis – Datu bāzes veidošana ar *.sql skriptu. Ja skripts tika veiksmīgi uzģenerēts, Power Designer izvada sekojošu importēšanas instrukciju:

Usage: (1) Launch Microsoft Access 2000 (2) Open the Access2k.mdb file (in tools directory) (3) Select the 'Generate Access database' button (4) Fill in the destination Access DB name (5) For the 'Script File' enter C:\Program Files\Sybase\

PowerDesigner 12\OOM_zju\BPVD.sql (6) Click on 'Create'

37

Pēc šīs instrukcijas soļu izpildes tiek izveidots *.mdb datu bāzes fails, atverams ar MS Access programmu.

MS Access datu bāzes veidošana no BMPD DFM

Transformējot BMPD fizisko modeli ieguvu saistīto tabulu struktūru MS Access vidē. Skat Att 14

38

Att 14 no DKM izveidota BMPD datu bāze MS Access videi

39

Kļūdu un brīdinājumu analīze

Pie katras transformācijas notiek modeļa pārbaude. Pārbaude var konstatēt kļūdas un nepilnības modelī. Nepilnību gadījumā tiek izvadīts brīdinājums, bet modelis tiek transformēts. Kļūdas apstādina transformāciju, līdz tās tiek izlabotas.Modelēšanas laikā sastapos ar vairākiem kļūdu un brīdinājumu gadījumiem. Šeit ir daži piemēri.

Database GenerationGeneration: Check model starting...Generation aborted due to errors detected during the verification of the model.

Checking package ... -- # 1,2 kļūdu iemesls: automātiskā nomenklatūra piešķira vienādus - Circular references -- nosaukumus Foreign key „FK_PROCESS__RELATIONS_ACTIVITY”- Constraint name uniqueness

Error The following objects do not have unique constraint names:-> Reference 'is_defined_by' (<Model>)-> Reference 'includes' (<Model>)

- Index inclusionWarning The following index includes another one:

-> Index 'Activity_statuses.ACTIVITY_STATUSES_PK' includes 'ACTIVITY_STATUSES_FK'(<Model>::Activity_statuses)

-> Index 'Plan_processes.PLAN_PROCESSES_PK' includes 'PLAN_PROCESSES_FK'(<Model>::Plan_processes)

-> Index 'Process_activities.PROCESS_ACTIVITIES_PK' includes 'PROCESS_ACTIVITIES_FK'(<Model>::Process_activities)

2 error(s), 3 warning(s).The Physical Data Model is incorrect; there are 2 error(s).

40

UZDEVUMS #2

Uzdevums: uzģenerēt RDB no Objektorientēta Datu Modeļa, lietojot case rīku Power Designer: izveidot OOM transformēt DKM uz DFM DFM transformēt uz sql skriptu, lasāmu ar kādu DBVS

Datu Objektorientēts modelis (OOM)

Kas ir OOM? Klašu diagramma, tās pamatelementi

Kas ir OOM?

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 savstārpēji saistīti. Klase atspoguļo objektu kopu un asociācijas apraksta saišu kopu.

Klašu diagrammas elementi nodrošina logisko skatījumu uz sistēmu kopumā vai tās daļām.Klašu diagrammas buvē lai vienkāršotu modelējamās sistēmas objektu mijedarbību.

Klašu diagrammas pamatelementi

Klase – ir objektu kopas apraksts, kuriem ir līdzīga struktūra un uzvedība, vieni un tie paši atribūti, operācijas, metodes, attiecības un semantika.

41

Klases struktūra ir aprakstāma ar tās atributiem un asociācijām. Klases uzvedību apraksta viņas operācijas. Klases un attiecības starp tām veido Objekt Orientēto Modeli. Klase definē kādu konceptu – fizisku būtni, biznesa terminu, loģisku struktūru, uzvedības paraugu u.c.

Asociācija – pārstāv strukturālo attiecību starp klasēm vai starp klasi un interfeisu. Katram asocācijas galam var definēt lomu, kas aprakstītu šī klases funkciju, no otras klases skatu punkta. (Piemēram darbinieks uzskata kompāniju par darbadevēju, savukārt kompānija uzskata darbinieku par darbaņemēju). Iespējamas refleksīvas asociācijas klasei pašai uz sevi.

Agregācija – Asociācijas forma, kura definē “daļa-vesels” attiecības starp klasi un agregēto klasi. (Piemēram mašīnai ir riteņi).

Kompozīcija – agregācijas speciāls gadījums, kad daļas ir ļoti cieši saistītas ar veselo. Daļas izveidojas un dzīvo un pārstāj eksistēt līdz ar veselu. (Piemēram krūze un tās rokturis)

Interfeiss – Līdzīgs klasei, bet lietots lai specificētu uzvedību. Tā ir operāciju kopa, kas apraksta ārpasaulei redzamu klases uzvedību. Interfeisam nav savas implementācijas.

Ports - Mijiedarbības punkts starp klasi un tās vidi. Caur ports klase specificē servisus, ko piedāvā videi, un ko sagaida no tās.

Vispārināšana – Attiecība starp vispārīgo elementu (vecāku) un specifisko (bērns). Specifikais elements ir raksturojams ar vispārīgo, taču tam pieder arī papildus informācija.

Pieprasījuma Links – savieno klasi, komponenti vai portu ar interfeisu.

Atkarība – semantiska attiecība starp diviem objektiem, kad viena saistītā objekta izmaiņa var izraisīt izmaiņas otrā. Atkarības var pastāvēt starp: klasi un interfeisu, divām klasēm, diviem interfeisiem.

Realizācija – semantiskā attiecība starp klasi, komponenti vai interfeisu. Realizācijā klase implementē metodes, ko specificē interfeiss. Interfeiss tiek saukts par specifikācijas elementu un klase par implementēšanas elementu.

BPVD Objekt Orientēts modelisAttēlā 15 ir atspoguļots BPVD OOM, kas tika izstrādāts šīm uzdevumam.

42

0..*Process_activi ties

0..*Plan_processes

0..*Plan_processes

0..*Activi ty_statuses

0..*Activi ty_statuses

1..1

0..*

1..1

0..*

1..1

0..*

1..1

0..*

1..1

0..*

1..1

0..*

1..10..1

1..1

0..*

1..1

0..*

1..1

0..*

1..1

0..*

1..1

0..*

1..1

0..*

Plan_type

+++


: java.lang.String: int: java.lang.String

Process_type

+++


: java.lang.String: java.lang.String: int

Alarm_type

++++


: int: int: java.lang.String: int

Alarm_instances

++

Alarm_start_timeAlarm_inst_id

: java.uti l .Date: int


Process_states

+++

Activi ty_start_timeStatus_start_timeProcess_state_id

: java.uti l .Date: java.uti l .Date: int

+++

start_activi ty ()get_activi ty ()idle_activi ty ()

: int: int: int

Port_1

Initiator

+++

Initiator_nameInitiator_descInitiator_id


Activi ty_type

+++



Status_type

++++


: java.lang.String: java.lang.String: int: java.lang.String

Interface_1

+++

start_activi ty ()get_activi ty ()idle_activity ()

: int: int: int

Interface_2

++

get_T ime ()set_T ime ()

: time: time

Process_activi ties

--


: int: int

Att 15 BPVD Objektorientēts Modelis

43

BPVD objektorientēto elementu apraksts

Tā kā OOM modeļis atspoguļo to pašu biznesa ideju, kas bija aprakstīta uzdevumā #1 DKM modelim, tālāk neatkārtošos struktūras aprakstā, bet iekļaušu tikai to elementu definējumu, kas ir raksturīgi OOM.

Klases

OOM ir papildus klase Process_activities.

Process_activities

--


: int: int

ProcessActivities - Sakārtots saraksts ar aktivitātēm kas ietilpst konkrētajā procesā

Šī klase ir domāta kā asociācija starp tabulām Activity_type un Process_type. Tās atribūti aprakstīti uzd.1 Asociācijas.

Klase bija nepieciešama dēļ tā, ka OOM nav iespējams iedefinēt atribūtus asociācijai , savienoju klases Activity_type un Process_type ar asociāciju un tai pieliku klasi Process_activities, iedefinējot atribūtus.

Domēni

Domēni tādi paši kas uzdevumā #1.

44

Saites (kompozīcija, asociācija, agregācija)

Kompozīcija

Tabula 12 Kompozīcijas saites BPVD OOM modelī

Nosaukums Klase A Kardinalitāte Klase Bincludes Process_states Alarm_instancesIs_an_instance_of Alarm_type Alarm_instancesis_defined_by Status_type Activity_alarmis_defined_by Activity_type Activity_alarmis_defined_by Process_type Plan_alarmis_defined_by Activity_type Process_alarmis_defined_by Process_type Process_alarmis_defined_by Plan_type Plan_alarm

Kompozīcijas piemērs: klase Activity_type un Process_type satur klasi Process_alarm.

1..1

0..*

1..1

0..*

Process_type

+++



Process_alarm

Activi ty_type

+++

Activi ty_nam eActivi ty_descActivi ty_id


Asociācija

45

Asociācijas veido attieksmi daudzi pret daudziem. To raksturo ar lomām virzienā no A uz B un otrādi. (Skat Tabula 13)

Tabula 13 Asociācijas saites BPVD OOM modelī

Nosaukums Klase A Kardinalitāte Klase Bincludes Plan_type 1..1 0..* Process_statesincludes Activity_type 1..1 0..* Process_statesincludes Status_type 1..1 0..* Process_statesincludes Process_type 1..1 0..* Process_statesis_initiated_by Initiator 1..1 0..* Process_states

Asociācijas piemērs: klase Process_states ir saistīta ar klasi Initiator ar asociāciju. Klases ir līdzvērtīgas.

1..1

0..*

Process_states

+++



+++

start_activi ty ()get_activi ty ()idle_activi ty ()

: int: int: int

Port_1

Ini tiator

+++



46

Agregācija:

Tabula 14 Agregācijas saites BPVD OOM modelī

Nosaukums Klase A Klase B Loma A-B Kardinalitāte(Klase B satur A)

Plan_processes Plan_type Process_type Plan_processes

Process_activities Process_type Activity_type Process_activities

Activity_statuses Status_type Activity_type Activity_statuses

Agregācijas piemērs: Klase Activity_type ir saistīta ar agregāciju ar klasi Process_type. Agregācijas saitei tika piekārtota klase, Process_activities, kas raksturo šo saiti ar atribūtiem.

0..*Process_activities


Process_type

+++



Activi ty_type

+++



Process_activities

--


: int: int

47

Interfeiss, realizācija, ports, pieprasījuma links

Tabula 15 Interfeisi BPVD OOM modelī

Klase Interfeiss Metode Kods Atgriež NolūksProcess_states Interface1 get_Time getTime time Saņemt laiku

set_Time setTime time Uzstādīt laiku Alarm_instances Interface2 start_activity startActivity int Apstadināt aktivitāti

get_activity getActivity int Saņemt aktivitātes ididle_activity idleActivity int Apstadināt aktivitāti

Alarm_instances

++



Interface_2

++

get_T ime ()set_T ime ()

: time: time

Interfeisa un relizācija BPVD modelī:

Interfeiss_2 realizē klasē Alarm_instances specificētās metodes

Process_states

+++



+++

start_acti vi ty ()get_activi ty ()id le_activi ty ()

: int: int: int

Port_1

Interface_1

+++

start_activi ty ()get_activi ty ()id le_activi ty ()

: int: int: int

Ports un Pieprasījuma Links BPVD modelī:

Interfeiss_1 realizē klasē Process_states specificētās metodes caur pieprasījuma linku Require_Link_1, kas pieslēgts portam Port_1.

48

Vispārināšana

Tabula 16 Vispārināšana BPVD OOM modelī

Nosaukums Kods Vecāka klase Bērnu klaseact type of alarm act_type_of_alarm Alarm_type Plan_alarmplan type of alarm plan_type_of_alarm Alarm_type Activity_alarmproc type of alarm proc_type_of_alarm Alarm_type Process_alarm

Vispārināšana BPVD modelī: Klase Alarm_type sadalīta apakšklasēs Activity_alarm, Process_alarm un Plan_alarm

Alarm _type

++++

Alarm _actionAlarm _intervalAlarm _descAlarm _id



49

Transformācija #1. Objektorientētais modelis (OOM) Datu konceptuālais modelis (DKM)

Transformācija notiek analoģiski uzdevumā #1 aprakstītām transformācijām.Galvenā izvelnē Tools Genereate Conceptual Data Model transformē OOM uz DKM.

DFM ģenerācija pārkonvertē objektus par konceptiem atbistoši tabulai 17.

Tabula 17 Objektu transformācija konceptos

OOM objekti Uzģenerētie DKM objektiKlase RealitāteKlases atribūts Realitātes atribūtsIdentifikators Primārais identifikatorsSaite (asociācija, agregācija, kompozīcija SaiteKlase, piesaistīta asociācijas saitei, kas savieno 2 citas klases Asociācija

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

Vispārināšana Mantošana

Attēlā 16 parādīts BPVD modelis pēc transformācijas no OOM uz DKM.

50

Process_activi ties

0,n

Process_activi ties

0,n

Plan_processes

Plan_processesPlan_processesActivi ty_statuses

Activi ty_statuses

Activi ty_statuses

is_in i tiated_by

Is_an_instance_of

includes

is_defined_byis_defined_byis_defined_by

includes

(D)

includes

is_defined_by is_defined_by

is_defined_by

includesincludes

plan type of alarmproc type of a larm act type of al arm

Plan_type



<M>

Plan_id <pi>

Process_type


NAMEDESCRIPTIONID <M>

Process_id <pi>

Alarm_type


IDIntegerDESCRIPTIONID

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

Alarm_id <pi>

Alarm_instances


TIM EID <M>

Alarm_inst_id <pi>


Process_states

Activi ty_start_timeStatus_start_tim eProcess_state_id <pi>

T IM ET IM EID <M>


Ini tiator

Ini tiator_nameIni tiator_descIni tiator_id <pi>


Ini tiator_id <pi>

Activi ty_type



Activi ty_id <pi>

Status_type


<pi>

NAMEDESCRIPT IONIDST AT US

<M>

Status_id <pi>

Process_activi ties


IDID

Att 16 BPVD Konceptuālais Datu Modelis

51

Domēnu transformācija

Pēc transformācijas domēni palika nemainīgi.

Klašu transformācija

Klašu Activity_type in Process_type un Process_Activities transformācijas piemērs ir uz Att 17. Pārējas klases tika transformētas analoģijskā veidā.



Process_type

+++



Acti vi ty_type

+++

Activity_nameActivity_descActivity_id


Process_activities

--


: int: int

Process_activi ties

0,nProcess_activi ties

0,n

Process_type



Process_id <pi>

Activi ty_type

Activi ty_nam eActivi ty_descActivi ty_id <pi>


Activi ty_id <pi>

Process_activi ties


IDID

Att 17 klašu un identifikatoru transformācija

Identifikatori pārveidojas par Primārajām atslēgam.

Klase Process_activities, kas bija piesaistīta asociācijai starp Activity_type in Process_type, tika transformēta kā asociācijas tabula.

52

Saišu transformācija

OOM dažāda tipa saites (kompozīcijas, asociācijas, agregācijas) transformējas uz ER saitēm, saglabājot kardinalitātes.

Saišu transformācijas piemērs: Kompozīcija tika transformēta uz saiti, ar tām pašām kardinalitātēm - 1..1, 0..*. (Skat Att 18.) līdz ar to papildus informācija, ko sniedza OOM, pazuda.

1..1

0..*

1..1

0..*

Process_type

+++



Process_alarm

Activi ty_type

+++

Activi ty_nam eActivi ty_descActivi ty_id


is_defined_byis_defined_by

Process_type



Process_id <pi>

Process_alarm

Activi ty_type



Activi ty_id <pi>

Att 18 Kompozīcijas transformācija OOMDKM

53

Interfeisu, realizāciju, portu, pieprasījuma linku transformācija

Šīs īpašības ir tikai OOM, pie transformēšanas uz CDM šie objekti pazuda (skat. Att19).Alarm_instances

++



Interface_2

++

get_T im e ()set_T im e ()

: time: time

Alarm_instances

Alarm_idAlarm_inst_idAlarm_start_time

INTEGERINTEGERTIME

<pk,fk><pk>

Att 19 Interfeisu, realizāciju, portu, pieprasījuma linku transformācija no OOM uz CDM

Vispārināšanas transformācija

Vispārināšana pārvēršās par mantošanu, semantiskā jēga saglābājas.

Alarm_type

++++




plan type of alarm

proc type of alarmact type of alarm

Alarm_type



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

Alarm_id <pi>

Process_alarm Plan_alarmActivity_alarm

Att 20 Vispārināšanas transformācija BPVD modelī

54

Transformācija #2. Datu konceptuālais modelis (DKM) Datu fiziskais modelis (DFM)

Modeļa ģenerēšanas soļi aprakstīti uzdevumā # 1.Transformēšanā saglabājas tie paši noteikumi kas aprakstīti uzd.#1.

Zemāk tiek parādītas transformācijas īpatnības ko nevarēja novērot uzdevumā #1.

Saites *..* transformacija: Uz saites starp tabulu Status_type un Activity_type piemēra var redzēt, kā saite *..* transformējas uz papildus tabulu, kas saistītā ar atsaucēm ar kardinalitātēm 0..*, 0..* .

Starptabulai arī izveidojas atribūti, kas kļuva vienlaicīgi par svešām atslēgām un salikto primāro atslēgu.

Activi ty_statusesActivi ty_statuses

Activi ty_statuses

Activi ty_type



Activi ty_id <pi>

Status_type


<pi>

NAMEDESCRIPT IONIDSTAT US

<M>

Status_id <pi>

FK_ACTIVIT Y_ACTIVIT Y__STATUS_T

Activity_statuses

Activity_statuses

FK_ACT IVITY_ACT IVITY__ACTIVITYActivity_statuses

Activity_statuses

Activity_type

Activity_nameActivity_descActivity_id

MEMOMEMOINTEGER <pk>

Status_type


MEMOMEMOINTEGERMEMO

<pk>

Activity_statuses

Status_idActivity_id

INTEGERINTEGER

<pk,fk1><pk,fk2>

Att 21 Saites *..* transformācija uz starptabulu DKMDFM

55

FK_PROCESSA_PROCESS_A_ACT IVITYProcess_activi ties

FK_PROCESSA_PROCESS_A_PROCESS_

Process_activi ties

FK_PLANPROC_PLAN_PROC_PLAN_T YP

Plan_processes

Plan_processes

FK_PLANPROC_PLAN_PROC_PROCESS_

Plan_processes

Plan_processes

FK_ACTIVITY_ACT IVITY__ST AT US_T

Activi ty_statuses

Activi ty_statuses

FK_ACTIVIT Y_ACTIVITY__ACTIVITYActivity_statuses

Activi ty_statuses

FK_PROCESS__ISINIT IAT_INIT IATO

FK_ALARM_IN_ISANINST A_ALARM_TY

FK_PROCESS__INCLUDES_PROCESS_

FK_PLAN_ALA_ISDEFINED_PLAN_TYPFK_PROCESS__ISDEFINED_PROCESS_FK_ACTIVITY_ISDEFINED_ACTIVITY

FK_PROCESS__INCLUDES_ALARM_IN

FK_PROCESS__INCLUDES_ST ATUS_T

FK_ACTIVITY_ISDEFINED_STAT US_T FK_PROCESS__ISDEFINED_ACT IVITY FK_PLAN_ALA_ISDEFINED_PROCESS_

FK_PROCESS__INCLUDES_PLAN_T YPFK_PROCESS__INCLUDES_ACTIVITY

FK_ACTIVITY_PLAN_TYPE_ALARM_T Y

FK_PROCESS__PROC_T YPE_ALARM_T YFK_PLAN_ALA_ACT_TYPE__ALARM_TY

Plan_type


MEMOINT EGERMEMO

<pk>

Process_type



Alarm_type


INT EGERINT EGERMEMOINT EGER <pk>

Alarm_instances

Alarm_idAlarm_inst_idAlarm_start_time

INTEGERINTEGERTIME

<pk,fk><pk>

Process_alarm

Process_idActivi ty_idAlarm_id


<pk,fk1><pk,fk2><pk,fk3>

Plan_alarm

Plan_idProcess_idAlarm_id



Activi ty_alarm

Activi ty_idStatus_idAlarm_id



Process_states

Activi ty_start_timeStatus_start_timeProcess_state_idStatus_idPlan_idIni tiator_idAlarm_idAlarm_inst_idActivi ty_idProcess_id

T IMETIMEINT EGERINT EGERINT EGERINT EGERINT EGERINT EGERINT EGERINT EGER

<pk><fk4><fk5><fk1><fk3><fk3><fk6><fk2>

Ini tiator



Activi ty_type


MEMOMEMOINT EGER <pk>

Status_type


MEMOMEMOINTEGERMEMO

<pk>

Process_activi ties


INTEGERINTEGERINTEGERINTEGER

<pk,fk1><pk,fk2>

Plan_processes

Plan_idProcess_id

INTEGERINTEGER

<pk,fk1><pk,fk2>

Activi ty_statuses


INT EGERINT EGER

<pk,fk1><pk,fk2>

Att 22 BPVD Fiziskais Datu Modelis

56

Transformācija #3. DFM Datu bāze MS Access vidē

Modeļa ģenerēšanas soļi aprakstīti uzdevumā # 1.Transformēšanā saglabājas tie paši noteikumi kas aprakstīti uzdevumā #1.

Attēlā 23 parādīta no OOM izveidotā BPVD datu bāze MS Access videi.

57

Att 23 no OOM izveidota BMPD datu bāze MS Access videi

58

SALĪDZINĀŠANA UN SECINĀJUMI

Lai būtu iespējams salīdzināt pirmā un otrā uzdevumu rezultātus – abos uzdevumos modelēju vienu un to pašu semantiku.

Abos uzdevumos struktūru definēju tikai sākotnējam modelim DKM vai OOM. Tālākajās transformācijās vairs neiejaucos, ļaujot rīkam pašam veidot gālējo struktūru pēc iebuvētajiem transformācijas noteikumiem.

OOM un DKM sākotnējo iespēju salīdzinājums

Lai var salīdzināt, ko ir iespējams izveidot no viena vai cita modeļa, apskatījos rīka Power Designer iespējas attiecībā uz modeļu elementiem (Skat. Tabula 18)

Tabula 18 Power Designer modeļu iespēju salīdzinājums

# DKM OOM DFM1 Realitāte Klase Tabula2 Realitātes atribūti Klases atributi Tabulas kolonnas3 Identifikators - Identifikators4 - - Identifikators - PK5 - - Identifikators - FK6 - - Identifikators - AK7 Saite Asociācija Atsauce8 - Asociācija - kompozīcija -9 Asociācijas links Asociācija – asociācija -10 - Asociācija - agregācija -12 Asociācija Klase Tabula13 Domēns Domēns Domēns14 Mantošana Vispārināšana Saistītās tabulas15 - Metodes -16 - Interfeisi -17 - Porti -

Tabula 18 var redzēt, ka ne visi elementi, kurus iespējams iedefinēt vienam modelim, pastāv arī citam.

59

DFM ir pēdējais posms, pirms tiek uzģenerēts RDB veidojošais scripts, līdz ar to, par piemērotāku RDB ģenerēšanai tiks uzskatīts modelis, kurš spētu atspoguļot pēc iespējas vairāk tādu elementu, kas parādās arī DFM.

Salīdzinot DKM un OOM atbilstību DFM elementiem, redzams, ka tie ir apmēram vienādi, bet OOM trūkst Identifikatora elements. Pēc būtības klašu diagrammā nav paredzēta identifikatora definēšana, bet RDB tā ir nepieciešama.

Savstārpēji salīdzinot DKM un OOM pēc tabulas 18, redzams kā OOM ir vairāk iespēju: asociāciju dažādība – var iedefinēt 3 dažādus veidus, kompozīciju, asociāciju un agregāciju metožu un interfeisu definēšana – var modelēt ne tikai statisko sistēmas struktūru, bet arī uzvedību.

Taču ja paskatīties uz DFM, šīs iespējas tur nevar iedefinēt, līdz ar to šādu elementu definēšanai nav jēgas, jo tapat viņi nenonāks RDB.

Darbs ar Power Designer rīku un iegūto DFM salīdzinājums

Klases/Realitātes un Saites

Gan OOM klases, gan DKM realitātes nonāca DFM, transformācijas laikā vienīgi bija jāpiestrādā pie identifikatoru definēšanas. DKM bija jāsaprot, ka, lai izveidotos pareizi saistīta struktūra, ir jāiedefinē tikai primārā atslēga, saites un to kardinalitātes ar citām tabulām. Pārējo rīks izdara pats. Pats pārvieto primāro atslēgu laukus saistītajās tabulās, kā svešās atslēgas un/vai primārās atslēgas. Līdz ar to sanāca, ka dažas tabulas pirms transformācijas no DKM uz DFM bija jāatstāj bez laukiem.

Asociāciju dažādība OOM pēc transformācijas reducējas uz parasto saiti, saglabājot tikai kardinalitāti. Šī OOM iespēja ir pārmērīga un lieka priekš RDB.

Identifikatori

OOM Klašu diagrammā nav paredzēta identifikatora definēšana. Taču, ja to neiedefinēt, nav iespējams transformēt DKM uz DFM, jo datu bāzei identifikators ir nepieciešams. Eksperimentējot ar savu klašu diagrammu, es cerēju, ka, pārējot no OOM uz DKM, tiks pielikts sintētiskais atslēgas lauks, kurš turpmāk kļūs par atslēgu, bet tā nenotika. Tālāk transformējot CDM uz DFM parādījas kļūdas par atslēgas lauka trūkumu un DFM netika uzģenerēts.

Šo problēmu bija iespējams atrisināt divējādi - vai nu ar reverso ģenerēšanu transformēt pirmajā uzdevumā iedefinēto DKM uz OOM un pēc šīs transformācijas identifikatori nonāktu uz OOM. Vai arī izmantot paplašinātās klašu diagrammas īpašības (iezīmēt klasi, tad PropertiesMoreIdentifiers). Acimredzami, iespēja piešķirt klasei identifikatoru tika saglabāta rīkā tieši šādu problēmu risināšanai.

60

Asociācijas

Tabulu pāriem Status_type – Activity_type, Activity_type – Process_type un Process_type – Plan_type ir asociācijas attiecīgi Activity_statuses, Process_activities un Process_Plans.

OOM to bija vienkārši realizēt, savienojot savstarpēji pārus ar asociāciju saiti ar kardinalitāti *..*. Tad transformācijas rezultatā rīks automātiski izveidoja atbilstošās asociāciju starptabulas. Taču šai saitei nav iespējams iedefinēt atribūtus, un, lai tiktu ar to galā, nācās piekārtot asociācijas saitei tabulu ar atribūtiem. Transformāciju rezultatā šī tabula pārvērtās par asociācijas tabulu.

DKM savienojot šos pārus ar asociācijam uzreiz veidojās asociācijas tabula, kurai, nepieciešamības gadījumā, var iedefinēt atribūtus.

Kaut arī pieiejas bija dažādas, rezultējošā struktūra abiem modeļiem sanāca apmēram vienāda.

Mantošana

Sākot būvēšanu no DKM, ir iespējams iedefinēt identifikatoru, kurš kļūs par primāro atslēgu. Vecāku klasei iedefinēju šādu lauku, kā arī īpašību, ka bērnu klasēm tiks nodots tikai identifikatoru lauks.

Rezultatā, DFM bērnu tabulām PK sastādīja vienīgs vecāku tabulas PK. Pārējie atribūti bija FK kas nāca no citām saistītajām tabulām.

Tā kā OOM nepastāv tāds jēdziens kā identifikators, un viņa esamība ir mākslīgi ieviesta, lai dotu rīkam ziņu, kuru tad lauku pēc transformācijam uztaisīt par identifikatoru, rīka darbības rezultatā DFM katrai bērnu tabulai izveidojās salikts PK, kas veidojas no visu saistīto tabulu identifikatoriem, kuri nonāca uz šo bērnu tabulu kā atribūti. Manuprāt šajā gadījumā labāk ieviest vienu sintētisko atslēgu.

Objektorientētie elementi

Kā jau minēju, OOM sākumā bija iedefinēti tādi elementi kā interfeisi un metodes. Eksperimentējot ar savu modeli, pārliecinājos, ka tiešām, jau transformācijas posmā no OOM uz DKM, no fiziskās RDB struktūras pazūd objektorientētie elementi.

Objektorientēto elementu zudums protams balstās uz to ka mēs gribam panākt tieši RDB, nevis ODB.

Balstoties uz veikto analīzi, mans secinājums ir tāds, ka vēloties uzbūvēt RDB, optimāli ir lietot atbilstošo modeli – konceptuālo, bet OOM jālieto būvējot ODB.

61

SAĪSINĀJUMI

DKM - Datu Konceptuālais Modelis (DCM – Data Conceptual Model)OOM – Objektorientētais Modelis (OOM – Object Oriented Model)DFM – Fiziskais Datu Modelis (PDM – Physical Data Model)ERD1 – Realitāšu Saišu Diagramma (ER, ERD – Entity Relationship Diagram), UML1 – Vienotā Modelēšanas Valoda (UML - Unified Modeling Language)BPVD – Biznesa Procesu Vadības Dzinējs (BPME – Business Process Management Engine)BPEL1 – Biznesa Procesu Izpildes Valoda (BPEL - Business Process Execution Language)DBVS – Datu Bāzu Vadības SistēmaPK1 – Primārā atslēga (PK – Primary Key)FK1 – Svešā atslēga (FK – Foreign Key)AK – Alternatīva atslēga (AK – Alternate Key)RDB – Relāciju Datu Bāze (Relation Data Base)ODB – Objektu Datu Bāze (Object Data Base)

1 Darbā lietotā angļu abbreviatūra

62

LITERATŪRAS SARAKSTS

1. BPEL apraksts http://www.active-endpoints.com/active-bpel-engine-overview.htm 2. Power Designer 12 – User Guide.

63

http://www.active-endpoints.com/active-bpel-engine-overview.htm

datubaze.files.wordpress.com · web vieweksistē vairākas notācijas, kurus lieto dkm...

Documents