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

„CASE rīki datu bāzu projektēšanā”

Modelēšanas rīks „ER Studio Data Architect”

Izstrādāja: Mārtiņš Paukšte (II DGDB – 3 Apl.Num.: 051RDB097)Pārbaudīja: asoc. prof. Jānis Eiduks

Rīga, 2012

Ievads_________________________________________________________________________________4

ER Studio Data Architect funkcionalitātes apskats______________________________________________6

1. Produkta reģistrācija un instalācija___________________________________________________________6

2. Datu modeļa izveide_______________________________________________________________________9

3. Datu vārdnīcas domēnu lietošana___________________________________________________________10

4. Realitāšu saišu veidošana__________________________________________________________________14

5. Sub-Modeļu veidošana____________________________________________________________________16

6. Fiziskā modeļa ģenerēšana no loģiskā modeļa_________________________________________________19

7. Modeļu salīdzināšana (Compare and Merge Utility)_____________________________________________24

8. Fiziskā modeļa de-normalizēšana____________________________________________________________27

9. DDL iegūšana no fiziskā datu modeļa_________________________________________________________31

10. SQL DDL faila imports___________________________________________________________________34

11. Reversā inženierija un iekštīkla (Intranet) vārdnīcas pārskata veidošana__________________________37

12. Datu plūsmas veidošana_________________________________________________________________46

13. Diagrammas navigācija un estētika________________________________________________________47

14. Macros (Automatizētās darbības)_________________________________________________________53

Testa sistēmas projektēšana ar ER Studio DA_________________________________________________54

Darba uzsākšana un domēnu veidošana___________________________________________________________54

Realitāšu veidošana___________________________________________________________________________56

Relāciju veidošana____________________________________________________________________________62

Viens pret viens_____________________________________________________________________________________62

Viens pret daudziem__________________________________________________________________________________63

Rekursīvā saite______________________________________________________________________________________65

Daudzi pret daudziem________________________________________________________________________________66

Modeļa sakārtošana__________________________________________________________________________67

Fiziskā modeļa ģenerēšana_____________________________________________________________________69

DDL skripta ģenerēšana________________________________________________________________________74

Kopsavilkums__________________________________________________________________________79

Trūkumi____________________________________________________________________________________79

Priekšrocības________________________________________________________________________________81

Izmantotie avoti________________________________________________________________________82

Vārdnīca______________________________________________________________________________82

Ievads

Izvērtējot atsauksmes par apmēram 30 populārākajiem CASE tehnoloģiju programmatūru

produktiem, tika izvēlēts rīks, kas ir viens no kompānijas rīku grupas

„ER Studio Enterprise” produktiem - „Data Architect”:

Tika izvēlēts izmēģināt versiju 9.1, kas uz šo brīdi ir aktuālākā.

Apraksts ir sadalīts 2 galvenajās daļās – viena, kurā ar nelieliem piemēriem apskatīta produkta galvenā

funkcionalitāte un otra, kurā, izmantojot rīku, tiek iziets neliels projektēšanas cikls konkrētai sistēmai, sākot

no koncepcijas un beidzot ar DDL skripta izpildi datubāzē. Plašāks funkcionalitātes apraksts ir 1. daļā, bet

detalizētāk konkrēti soļi ir aprakstīti 2. daļā.

Aprakstā iekļauts subjektīvs vērtējums un varētu teikt, ka ir izpētīts apmēram 60% no rīka iespējām, tāpēc

ne visi apgalvojumi var izrādīties neapgāžami.

ER Studio Data Architect funkcionalitātes apskats

1. Produkta reģistrācija un instalācija

Reģistrējoties vietnē https://downloads.embarcadero.com/free/er_studio kompānija izsniedz

reģistrācijas kodu 14 dienu izmēģinājuma periodam. Instalējot produktu, tas ir jāreģistrē, izmantojot šo

kodu un savu reģistrācijas informāciju:

Konkrētajā gadījumā instalācija tika darbināta uz Windows 7 64-bitu operētājsistēmas, un paši izstrādātāji

apgalvo, ka arī problēmām nebūtu jābūt uz citām platformām. Sistēmas prasības:

Instalācijas gaitā ir jāizvēlas ER diagrammas noklusētā notācija, ko pēc tam vēlāk, protams, var mainīt.

Tiek piedāvāts izvēlēties 4 viedus:

IDEF1X: Datu modelēšanas tehnika, kuru plaši izmanto ASV.

IE (Martin/Finkelstein): Informācijas inženierijas (Information Engineering – IE) formāts, ko

izstrādāja Džeimss Martins (James Martin) un vēlāk pilnveidojis Klaivs Finkelsteins (Clive Finkelstein)

IE (Crow’s Feet): Lieto IE notāciju un attēlo saites ar savienojošām līnijām starp realitātēm, un

simboli šo līniju galos apzīmē saites veidu. Šādu notāciju izmanto Oracle savos aprakstos un citās

lietojumprogrammās tādās kā, piemēram, Visio. Ārējās atslēgas attēlo pie pašas realitātes - kastītē

(šajā dokumentā pārsvarā tiks izmantota šī notācija).

IE (Hide Foreign Keys): Izmanto standarta IE notāciju, taču ārējās atslēgas neattēlo realitāšu

kastītēs.

Piezīme: Noklusēto notāciju vēlāk var mainīt, izvēloties Tools > Options no ER/Studio Data Architect

galvenās izvēlnes un izvēloties šķirkli Logical vai Physical.

Piezīme: Programmas instalācijas un palaišanas laikā jāseko līdzi paziņojumiem, ko var izdot antivīrusa

programma. Konkrētajā gadījumā AV programma „F-Secure" rīku uzskatīja par kaitīgu, tāpēc bija speciāli

jānorāda, ka programma ir tomēr vēlama un tai ir jāļauj darboties.

Īss ieskats programmas interfeisā:

Piezīme: Pēc instalācijas pabeigšanas, palaižot programmu, nav nekādu pazīmju, ka kāds process būtu

uzsācies – kaut kur fonā programma lādējas, vispār resursus neslogojot un sāk jau šķist, ka būs jāstrādā ar

citu OS, tomēr ir vienkārši jāpagaida un pēc neilga brīža programma atvērsies.

2. Datu modeļa izveide

Pirmo reizi atverot ER/Studio Data Architect, tiek piedāvāts sekojošs dialoglogs:

Tiek piedāvātas vairākas iespējas sākt modelēšanu:

Veidot jaunu izstrādi no nulles, zīmējot jaunu modeli.

Veidot datu modeli no jau eksistējošas datu bāzēs caur reverso inženieriju.

Importēt izstrādes no citiem modelēšanas rīkiem, piemēram, ERwin vai no SQL failiem.

Izvēlamies pirmo opciju, lai veidotu jaunu datu modeli.

Atveras sekojošs logs, kurā var sākt zīmēt datu loģisko modeli:

3. Datu vārdnīcas domēnu lietošana

Pirms sākt zīmēt datu modeli, vispirms vajadzētu ielādēt domēnus, ja tādi ir pieejami (Domēni – otrreiz

lietojami atribūti).

Ar File > Import Data Dictionary var ielādēt jebkura cita iepriekš veidota modeļa (faila „*.md1”) domēnus:

Ja nav pieejami importējami modeļu domēni, tad varam tos izveidot, izvēloties zem modeļu koka apakšā

šķirklī Data Dictionary. Atvērtajā kokā uz mapes Domains izvēlas New Domain Folder veidošanu:

Izveido mapi „Skaitliskie”:

Jaunizveidotajā domēnu mapē veido jaunu domēnu:

Sekojošajā dialoglogā apraksta domēna īpašības. Tādas kā datu tipu, garumu, vai tas drīkst būt nenorādīts

utt.

Piemēra pēc izveidosim vēl vienu domēnu mapi un domēnu:

Izveido domēnu „Nosaukums”, kas būs tekstuālas informācijas domēns:

Atgriežas datu modelī (zem koka izvēlas šķirkli Data Models):

Veido jaunu realitāti, izvēloties rīku no modelēšanas joslas:

Izveido 2 realitātes „Klients” un „Produkts”:

Tālāk varam izmantot izveidotos domēnus, lai nav katrā realitātē katram atribūtam jāapraksta vienas un tās

pašas īpašības.

Domēnu piešķir no domēnu koka izvēloties un ar peli ievelkot vajadzīgo domēnu:

Mīnuss šai metodei ir tas, ka ir jāpārsauc pēc tam lauks:

Bet ir otrs variants – atver Entity Editor (dubultklikšķis uz realitāti) un tajā norāda konkrētam laukam, kurš

domēns tiks izmantots:

Tāpat norāda gan lauku ID, gan Nosaukums otrai realitātei „Produkts”.

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

Modelēšanas rīkjoslā izvēlas, piemēram, Non-Identifying, Mandatory Relationship rīku.

Attēlotā rīkjosla var mainīties atkarībā no izvēlētas modelēšanas notācijas (kā jau minēts, notāciju var

mainīt).

Lai starp divām realitātēm izveidotu saiti, uzklikšķina uz vienas realitātes un pēc tam uz otras. Rekursīvas

saites gadījumā divreiz uzklikšķina uz tās pašas realitātes.

Šajā notācijā var veidot vairāku veidu saites:

1) Identifying (Identificējoša) – apzīmē ar nepārtrauktu līniju, un tas nozīmē, ka R2 primārā atslēga tiks veidota no 2 laukiem – R2_ID (Pašas tabulas ID) un R1_ID (saistītās tabulas ID).

Saites galā simbols (krustiņš) nozīmē, ka saites pastāvēšanai šīs realitāte elements ir obligāts (R2 nevar pastāvēt bez R1).

Simbols (žebērklis) nozīmē, ka šīs realitātes elementi var būt vairāki atbilstoši otrai realitātei (R1 var atbilst vairāki R2). Aplītis nozīmē to vai šī realitāte ir obligāta otrai realitātei (R1 var pastāvēt bez R2).

2) Non-Identifying, Mandatory (Ne-identificējoša, Obligāta) – neidentificējošu saiti zīmē ar raustītu līniju. Tas nozīmē, ka R2 tiek veidota vienkārša ārējā atslēga (Foreign Key) ar R1 identificējošu lauku (R1_ID).Obligātums – tas nozīmē, ka R2 nevar pastāvēt bez R2.

3) Non-Identifying, Optional (Ne-identificējoša, Neobligāta) – tāda pati kā iepriekšējā, tikai šajā gadījumā realitātes var pastāvēt vienas bez otras.

4) One-to-One (Viens-pret-Vienu) – R1 nevar būt vairāku atbilstošu R2 un otrādi. „Z” pie saites apzīmē to, ka R2 var būt vai nu viens vai nav vispār.

5) Non-Specific (Nenoteikta) – šī ir saite daudzi pret daudziem. Citās notācijās M:N.

Var sakombinēt vēl citus variantus atverot saites īpašības un labojot sadaļu Cardinality:

5. Sub-Modeļu veidošana

Sub-modeļi un iegultie sub-modeļi tiek veidoti, lai sadalītu lielus sarežģītus datu modeļus ar nolūku –

koncentrēties uz kādu konkrētu daļu. Svarīgs sub-modeļu aspekts, kas jāsaprot, ir tas, ka jebkuras izmaiņas,

kas tiek veiktas sub-modelī (izņemot tādas īpašības kā izvietojums, krāsa, attēlošanas iestatījumi, notācija

utt., kas var būt unikālas katram sub-modelim) automātiski parādīsies arī galvenajā modelī. Citiem vārdiem

sakot, izmainot vai pievienojot atribūtu objektam sub-modelī, šīs izmaiņas automātiski iestrādāsies

saistītajā objektā galvenajā modelī.

Sekojošajā attēlā parādīta kāda attīstītāka datu modeļa struktūra:

Šis modelis iekļauj vairākas sub-modeļu mapes, kas palīdz aprakstīt loģisko modeli:

Main model – šis ir visu loģisko objektu apkopojums „Orders.dm1” failā. Galvenā modeļa mapi var

atšķirt ar to, ka tai nav virsū palielināmā stikla simbols.

Bill of Materials līdz Shopping Cart – šie ir sub-modeļi, kas ir mazākas no galvenā modeļa aizgūtu

realitāšu kopas, kas palīdz aprakstīt galvenā modeļa konkrētus apgabalus, atbrīvojot skatu no citām

realitātēm, kas neattiecas uz interesējošo apgabalu.

Alternate Key līdz Primary Key – šie ir iegultie sub-modeļi, kas pēc būtības ir sub-modeļu sub-

modeļi un tie var būt n līmeņu dziļumā.

Piemēram, galvenajā modelī atrodas vairākas realitātes, kas apraksta adresi:

Lai šīs visas realitātes apvienotu vienā sub-modelī, tos visus vienkārši iezīmē un rīkjoslā izvēlas Model >

Create Submodel, kur tālāk norāda sub-modeļa nosaukumu:

Modeļu pārlūkā tagad „Adreses komponente” parādās kā atsevišķa mape:

6. Fiziskā modeļa ģenerēšana no loģiskā modeļa

Nostājās kokā uz galvenā loģiskā modeļa (Main Model) un rīkjoslā izvēlas Model > Generate Physical

Model, kas atver sekojošu logu:

Norāda fiziskā modeļa nosaukumu un izvēlas DBVS platformu (šajā gadījumā „Oracle 11g”).

Tālākajos dialoglogos vednis piedāvā pielāgot tādas lietas kā atsevišķu objektu izvēli, indeksu piešķiršanu,

noklusētos glabāšanas parametrus, kā apieties ar daudzi-pret-daudziem saitēm (kas var būt loģiskajā

modelī), nosaukumu veidošanas nosacījumi. Daži no norādāmajiem parametriem ir atkarīgi no izvēlētās

DBVS.

Fiziskā modeļa ģenerēšana – 2. vedņa logs

Fiziskā modeļa ģenerēšana – 3. vedņa logs

Fiziskā modeļa ģenerēšana – 4. vedņa logs

Fiziskā modeļa ģenerēšana – 5. vedņa logs

Pēc tam blakus datu modelim kokā parādās fiziskais modelis, kas jau satur visas lietas, kas attiecas uz DBVS:

Piezīme: Ērti ir tas, ka fiziskos modeļus var ģenerēt vienu pēc otra un tie atrodas turpat kokā blakus viens

otram. Var veikt izmaiņas datu modelī un atkal ģenerēt jaunu fiziskā modeļa versiju.

Katram fiziskā modeļa objektam, piemēram, tabulai ir savs īpašību kopums, ko var atvērt no izvēlnes:

Atvērtajā logā ir daudz un dažādas pielāgojamas lietas.

Viena no ērti izmantojamām lietām ir šķirklī DDL apskatīt objekta DDL skriptu:

Tas ir ērti, jo var pielāgot objektu un redzēt jau tā kodu pirms kopējā DDL skripta ģenerēšanas vedņa startēšanas.

7. Modeļu salīdzināšana (Compare and Merge Utility)

Diezgan noderīgs rīks ir objektu salīdzināšana. Salīdzināt var, piemēram, divus fiziskos modeļus.

Nostājas kokā uz modeļa, ar kuru grib salīdzināt kādu citu un rīkjoslā (vai no peles labā taustiņa izvēles)

Model izvēlas Compare and Merge Utility:

Tālāk vednī izvēlas, no kurienes tiks ņemti salīdzināmie objekti – vai nu šajā pašā failā vai citos failos:

Kad tas ir izdarīts, norāda no pārējiem pieejamajiem modeļiem – ar kuru vēlas salīdzināt:

Norāda, cik daudz un dažādas objektu īpašības tiks iekļautas salīdzināšanā:

Norāda konkrētus modeļu objektus, kas tiks iekļauti salīdzināšanā (pēc noklusējuma – visi):

Konkrētu modeļu objektu izvēle

Salīdzināšanas rezultātā rāda logu ar visiem atšķirīgajiem objektiem un atšķirīgajām īpašībām.

Var izvērtēt atšķirības un izvēlēties vai nu katru atsevišķi vai visas uzreiz – iepludināt vienā vai otrā modelī, vai arī neko nedarīt:

Modeļu salīdzināšanas rezultāts

8. Fiziskā modeļa de-normalizēšana

ER/Studio DA komplektā nāk de-normalizēšanas vedņi, kas palīdz optimizēt fizisko konstrukciju pēc

tam, kad fiziskais datu modelis ir uzģenerēts. Vedņi palīdz automatizēt šo procesu un saglabā sasaistes

starp fiziskajām tabulām un loģiskajām realitātēm.

Tas kādi denormalizācijas vedņi ir pieejami, ir atkarīgs no iezīmētajām tabulām fiziskajā modelī brīdī, kad

izvēlas Denormalization Mapping. Piemēram, ja ir izvēlētas 2 tabulas, kas ir saistītas viena ar otru, tad būs

pieejamas Rollups un Rolldowns operācijas:

Kad ir iezīmēta tikai 1 tabula, tad kļūst pieejamas tabulas sadalīšanas opcijas (Horizontal Splits un Vertical

Splits). Kad ir iezīmētas 2 savstarpēji nesaistītas tabulas, tad kļūst pieejama tabulu apvienošanas iespēja

(Table Merges).

Izmēģināsim, piemēram, tabulas sadalīšanas iespēju. Teiksim, mēs vēlamies samazināt noslodzi klientu

tabulai, sadalot to divās fiziskās tabulās: „Klienti Austrumos” un „Klienti Rietumos”. Tabulas sadalīšana var

samazināt vaicājumu izpildes laiku uz tabulu un nodrošināt iespēju glabāt tabulas dažādās fiziskās vietās,

kas arī varētu samazināt meklēšanas laiku. Lai veiktu operāciju ar peles labo klikšķi spiež uz tabulas fiziskajā

modelī un izvēlas Denormalization Mapping > Horizontal Splits:

Tālāk norāda, cik eksemplāros tabulu vēlas sadalīt un norāda jauno tabulu nosaukumus:

Nākošajā dialoglogā norāda, kuras saites pēc de-normalizācijas tiks paturētas:

Kā redzams fiziskajā datu modelī, vienas tabulas vietā parādās abas jaunās ar attiecīgajām sasaistēm:

Šajā gadījumā tabulas ir identiskas, izņemot to nosaukumus. Variantā, kad izvēlas Vertical Split, var

izvēlēties, kuri atribūti nonāks kurā rezultējošajā tabulā.

Jebkuram objektam modelī ir pieejama sadaļa WHERE USED:

Tajā var redzēt, piemēram, kura tabula ir cēlusies no kuras realitātes. ER/Studio DA glabā objektu stāvokļus

pirms un pēc jebkuras operācijas. Tāpat ir saglabāta informācija par šo de-normalizācijas operāciju:

Tas ir noderīgi ne tikai informatīvi, bet rīks ļauj arī atgriezt objektus kādā no iepriekš fiksētajiem

stāvokļiem.

9. DDL iegūšana no fiziskā datu modeļa

Kad fiziskais modelis ir pabeigts (būtībā, kad viss ir pabeigts) un esam gatavi to migrēt uz konkrētas

DBVS, tad kokā iezīmē fizisko datu modeli un izvēlas Generate Database:

Tālāk seko 3 dialoglogi, kuros norāda DDL skripta ģenerēšanas parametrus:

DDL skripta ģenerēšana (1)

DDL skripta ģenerēšana (2)

DDL skripta ģenerēšana (3)

Bet, pirms procesa pabeigšanas, ieteicams paskatīties ar SQL Preview kāds ar šādiem parametriem būs

sanācis skripts. Visticamāk ar pirmo piegājienu tas nebūs tāds kādu vēlas, tāpēc var atgriezties pie

iepriekšējiem vedņa logiem un pamainīt iestatījumus.

Pēc tam tiek piedāvāts apskatīt skriptu ER/Studio DA iebūvētajā SQL apstrādes rīkā Universal ISQL:

10. SQL DDL faila imports

Izvēlas jauna modeļa veidošanu un Import Model From norāda „SQL File”, kas ir iespēja izveidot datu

modeli no faila, kas satur SQL DDL ar datu bāzes objektiem.

Opcija „ERX File” ļauj ieimportēt populārā rīka „Computer Associates ERwin 3.5.2” modeļu failus.

„External Metadata” atver vedni, kas dod iespēj importēt no alternatīviem avotiem.

Pieņemsim, ka mums ir sagatavots neliels SQL DDL fails ar 4 tabulām:CREATE TABLE da_klienti( id NUMBER NOT NULL, nosaukums VARCHAR2 (255) NOT NULL, talrunis VARCHAR2 (30));ALTER TABLE da_klienti ADD CONSTRAINT pk_da_klienti PRIMARY KEY (id);CREATE TABLE da_pasutijumi( id NUMBER NOT NULL, pasutijuma_nr NUMBER NOT NULL, datums DATE NOT NULL, klienta_id NUMBER NOT NULL);ALTER TABLE da_pasutijumi ADD CONSTRAINT pk_da_pasutijumi PRIMARY KEY (id);ALTER TABLE da_pasutijumi ADD CONSTRAINT fk_klienti_pasutijumi FOREIGN KEY (klienta_id) REFERENCES da_klienti(id);CREATE TABLE da_pasutijuma_detalas( id NUMBER NOT NULL, skaits NUMBER NOT NULL, pasutijuma_id NUMBER NOT NULL, preces_id NUMBER NOT NULL);ALTER TABLE da_pasutijuma_detalas ADD CONSTRAINT pk_da_pasutijuma_detalas PRIMARY KEY (id);ALTER TABLE da_pasutijuma_detalas ADD CONSTRAINT fk_pasutijumi_pas_det FOREIGN KEY (pasutijuma_id) REFERENCES da_pasutijumi(id);ALTER TABLE da_pasutijuma_detalas ADD CONSTRAINT fk_preces_pas_det FOREIGN KEY (preces_id) REFERENCES da_preces(id);CREATE TABLE da_preces( id NUMBER NOT NULL, nosaukums VARCHAR2 (255) NOT NULL);ALTER TABLE da_preces ADD CONSTRAINT pk_da_preces PRIMARY KEY (id);

Tālākajā vedņa logā izvēlamies šo failu, norādām kādas DBVS DDL tas ir, norādām diagrammas izkārtojuma

stilu un citus parametrus:

DDL importa žurnāls

Rezultātā šādi izskatās uzģenerētais datu modelis rīkā ER/Studio DA:

11. Reversā inženierija un iekštīkla (Intranet) vārdnīcas pārskata veidošana

Viens no ER/Studio DA spēcīgākajiem rīkiem ir tā dokumentācijas ģeneratora spēja interpretēt

kompleksas datubāzes un asociētus meta datus. ER/Studio DA ir aprīkots ar daudzpusīgām pārskatu

ģenerēšanas iespējām:

HTML pārskatu ģenerēšana – tūlītējas HTML-balstītas tīmekļa vietnes ģenerēšana, kas nodrošina

vienkāršu navigāciju pa datu modeļiem un modeļu meta datiem, izmantojot tādas standarta

pārlūkprogrammas kā Microsoft Internet Explorer vai Mozilla Firefox.

RTF pārskatu ģenerēšana – momentāni uzģenerē dokumentāciju, kas ir lasāma tādos lietojumos kā

Microsoft Word.

Zemāk redzamajā piemērā, mēs izmantosim reverso inženieriju, lai no eksistējošās datubāzēs

uzģenerētu HTML pārskatu. Tas varētu būt paredzēts, piemēram, personām, kas ir atkarīgas no dotās

informācijas par datu modeli, taču tām nav tiesību pieslēgties datubāzei drošības vai organizatorisku

iemeslu dēļ.

Pieņemsim, ka mums ir datu bāze, kurai varam pieslēgties ar nolūku to dokumentēt.

Atverot ER/Studio DA, izvēlas File > New:

Izvēlas Reverse-engineer an existing database un spiež Login.

Šim nolūkam ir iespējams pieslēgties datubāzei vai nu ar ODBC definētajiem datu avotiem vai caur Native

RDBMS klienta savienojumu. Šajā piemērā izmantosim ODBC avotu – MS Access datubāzes failu.

Nākošajā logā (pieņemam, ka jau ir nodefinēts datu avots) izvēlamies datu avotu „HospitalDB” un spiežam Next.

Tālākajos posmos vednis Reverse Engineer Wizard jautā kādus objektus izvēlēties, dažādas opcijas un izvietojuma parametrus.

Objektu grupu izvēle

Konkrētu objektu izvēle

Kopsavilkums par izvēlētajiem objektiem

Objektu izkārtojuma iestatījumi

Nospiež Finish un DA veic reverso inženieriju izvēlētajai datubāzei.

Tiek uzģenerēts fiziskais un loģiskais datu modelis un tā diagramma ir apskatāma un modificējama tāpat kā jebkura

cita ar rīku veidota:

Kad datubāzes reversā inženierija ir pabeigta, varam tai uzģenerēt pilnvērtīgu HTML pārskatu, ko var lietot citi

lietotāji, kam nav nepieciešams ER/Studio DA.

Kokā nostājas uz fiziskā datu modeļa (Physical > Main Model) un no galvenās rīkjoslas izvēlas Tools > Generate Reports:

Norāda kāda veida pārskatu vēlamies veidot (šajā piemērā izvēlamies „HTML report”):

Nākošajā vedņa dialogā iespējams atzīmēt elementus, kurus iekļausim pārskatā. Atzīmējam visus ar abām Select All

pogām:

Piezīme: Šķirkļi, kas redzami 2. dialogā ir atkarīgi no tā kādus objektus uztur izvēlētā datubāzes platforma

izvēlētajam modelim. Piemēram, Oracle datubāzei šeit būtu tādi šķirkļi procedūrām, funkcijām, trigeriem,

pakotnēm u.c.

Nākošajā logā var atzīmēt sub-modeļus, ja tādi eksistē. Arī atzīmē Select All.

Šajā logā arī var nomainīt logo un saiti, kas pēc noklusējuma ir „Embarcadero Technologies”:

Pēdējā logā norāda autora informāciju un spiež Finish.

Rezultātā interneta pārlūkā tiek atvērts HTML dokuments, kurš ir pēc navigācijas līdzīgs DA rīkam – kreisajā pusē ir

modeļu/objektu pārskats – koks un labajā pusē tiek vizuāli/detalizēti parādīts izvēlētais koka elements:

12. Datu plūsmas veidošana

Diagrammu datu plūsmu veidošanas iespēja ER/Studio DA ļauj dokumentēt datu kustību no punkta A uz

punktu B (un starp jebkuriem soļiem vēl pa vidu tiem). Šo kustību mēdz dēvēt arī par ieguvi, transformāciju

un uzkrāšanu (Extraction, Transformation and Load (ETL)). Ar punktiem A un B ir domāti tādu datu uzkrājēji

kā, piemēram, parasti faili, datubāzes tādas kā Oracle un DB2, XML, Access datubāzes un Excel tabulas.

Dažreiz šo funkcionalitāti sauc par avota un mērķa sasaisti (Source and Target Mapping). Datu arhitektiem

var būt nepieciešams specificēt datu avotu un mērķi līdz pat tabulu kolonnu līmenim. Kopā ar meta datiem

tas nosaka avotu un mērķa sasaiste ir likumi – kā dati pa ceļam (transformācijas laikā) tiek manipulēti.

Datu plūsma

Šī iespēja gan netika pētīta šī darba ietvaros.

13. Diagrammas navigācija un estētika

Lai palīdzētu izveidot kvalitatīvas (prezentācijām derīgas) diagrammas, kurās ir viegli orientēties un tās

būtu estētiski baudāmas, ER/Studio DA piedāvā progresīvu diagrammu automātisku izkārtojumu un

navigācijas utilītas, kas arī palīdz sakopt kompleksas diagrammas. Modelētājiem būtu jāpavada laiks risinot

sarežģītus datubāzu vai biznesa datu modeļu uzdevumus, nevis bīdot kastītes un līnijas, lai tās izskatītos

labi.

Izkārtojuma rīkjosla – var lietot jebkuru no 4 auto-izkārtojuma veidiem, kas ar vienu klikšķi

pārkārtos visu diagrammu. Šie auto-izkārtojuma stili ir pilnībā pielāgojami. Diagrammas izkārtojumu

arī var pielāgot arī caur izvēlni: Layout > Layout Properties.

Diagrammu formatēšanas rīkjosla

Modeļu pārlūks – noklikšķinot uz jebkuru objektu modeļa pārlūka kokā, tas automātiski tiks

iezīmēts modeļa diagrammā un nofokusēts abos palīglodziņos: Zoom Window un Overview.

Pārskata lodziņš – šo lodziņu izmanto kā diagrammas sīktēlu (thumbnail), lai „saķertu” ar peli visu

diagrammu/pietuvinātu vai attālinātu to (F9 – šo logu ieslēdz/izslēdz).

Palielināmais „stikls” – to izmanto kā palielināmo stiklu, lai redzētu smalkāk to diagrammas daļu,

kas atrodas zem peles kursora. Ar SHIFT+F8 iesaldē lodziņa stāvokli, kamēr peles kursoru var virzīt

tālāk pa diagrammu (F8 – šo logu ieslēdz/izslēdz).

Vispārīgi viens no lieliem ieguvumiem datu modeļu konstruēšanā ir plašais dalībnieku loks, kas var gūt

labumu no tiem. Daļēji tas ir atkarīgs no tā, kādu informāciju attēlo diagramma. Atkarībā no skatītāja, var

būt vēlme ierobežot vai izvērst kādas noteiktas informācijas attēlošanu diagrammā. Piemēram,

izstrādātājiem ir labums, skatoties uz modeli, kas attēlo datu tipus, vērtības obligātumu pazīmes, unikālo un

neunikālo indeksu informāciju, kamēr biznesa analītiķiem vajag redzēt tikai realitāšu nosaukumus un to

definīcijas. ER Studio DA piedāvā daudzus attēlošanas veidus, kas var tikt iestatīti tieši šādiem mērķiem.

Lai pielāgotu diagrammas attēlojumu, izvēlas datu modeli un rīkjoslā Diagram Toolbar izvēlas Diagram

and Object Display Options:

Atvērtajā logā izvēlas šķirkli Entity un tad blokā Display Level atzīmē Entity:

Nospiež OK un rezultātā datu modelī attēlojas tikai realitāšu nosaukumi (Pēc šādas pārslēgšanas var būt

vēlama arī diagrammas elementu pārkārtošana).

Piezīme: Būtiski, ja attēlojamā informācija kastītēs maina apjomu, tad, lai tās pielāgotos jaunajam

saturam, ir jāiezīmē viss modelis un ar peles labot taustiņu no izvēlnes jāizpilda Resize:

Līdzīgi var pielāgot arī fiziskā modeļ aizskatu.

Izvēlas kokā fizisko modeli un, atverot Diagram and Object Display Options, būs pieejams pieejams

šķriklis Table.

Blokā Display Level atzīmē, piemēram, Physical Attribute Ordering. Blokā Available Options atzīmē

papildus specifiskās īpāsības, kuras vēlas attēlot, piemēram, Data Type.

Rezultātā diagrammā parādās vairāk tehniskas informācijas:

Diagrammu atēlojuma iestatījumus, kas darbojas pēc noklusējuma, iespējams norādīt Tools > Options sadaļā Display:

14. Macros (Automatizētās darbības)

ER/Studio DA satur daudzas jau gatavas paraug-makrodefinīcijas (Macros), kas rakstītas specializētā

programmēšanas valodā „Sax Basic” un kuras var izmantot tādas kādas tās ir vai arī modificēt pēc

vajadzības. Prasmīga makrodefinīciju izmantošana ļauj ietaupīt laiku. Makrodefinīciju kodā ir to darbības

apraksti angļu valodā un arī paša koda pārskatīšana var sniegt ātru ieskatu vai makrodefinīcija būs

pielietojama vai nē – kods ir diezgan viegli uztverams, jo tas ir ļoti līdzīgs Visual Basic kodam (Sax Basic ir

savietojams ar Microsoft Visual Basic for Applications).

Makrodefinīcijas var izmantot, piemēram, lai ieimportētu vai izeksportētu domēnu definīcijas un atsauces vērtības no MS Excel dokumenta, ja domēnus vajag ielādēt no citiem avotiem – tādiem kā kāds ārējo meta datu (External Metadata) repozitorijs. Visas makrodefinīcijas var atrast šķirklī Macro:

Macro šabloni un Visual Basic+ kods

Testa sistēmas projektēšana ar ER Studio DA

Darba uzsākšana un domēnu veidošana

File > New:

Kokā izveidojas datu modelis:

Saglabā un norāda faila nosaukumu:

Pirms realitāšu veidošanas vēlams nodefinēt datu domēnus – datu tipus, kurus varēs izmantot atkārtoti realitāšu atribūtos. Zem koka izvēlas šķirkli Data Dictionary un mapē „Domains” izvēlas New Domain:

Domēnam norāda nosaukumu, datu tipu, garumu, to vai tas būs obligāts un citas īpašības. Piemēram, izveido domēnu datuma formāta laukam:

Izveido vēl vienu domēnu arī datuma formātam, bet norāda, ka tas būs obligāti aizpildāms:

Tādā pašā garā izveido domēnus arī citiem tipiskiem datu tipiem jeb formātiem:

Realitāšu veidošana

Atgriežas datu modelī (zem koka izvēlas šķirkli Data Model):

Izvēlas rīku Entity un ieklikšķina diagrammas brīvajā laukumā ar peli.

Izveidojas realitāte, kurai uzreiz dod nosaukumu „Contract” („Līgums”).

Tālāk no rīkjoslas izvēlas bultiņu:

Tagad, klikšķinot uz realitātes, atveras tās īpašības, kurās šķirklī Attributes norāda pārējos laukus. Sāk ar realitātes identificējošo lauku:

1) Izvēlas domēnu (šajā gadījumā „ID”, kas konfigurēts kā obligāti aizpildāms Number tipa lauks). Tas automātiski aizpilda visas īpašības, kas tika jau norādītas domēnam.

2) Norāda atribūta nosaukumu.3) Norāda, ka tā būs realitātes primārā atslēga.4) Nospiež pievienošanas pogu.

Tāpat pie realitātes īpašībām jānorāda arī tabulas nosaukums – kā sauksies tabula, kas būs realitātes pamatā. Pēc noklusējuma laukā būs tāds pats nosaukums kā realitātei, bet ir pieņemts, ka tabulas nosaukumu norāda daudzskaitlī:

Izveidotā realitāte diagrammas logā izskatās šādi:

Tādā paša garā uztaisa arī citas realitātes.

Realitāte „Client” („Klients”):

Realitāte „Address” („Adrese”):

Realitāte „Bill” („Rēķins”):

Realitāte „Contract Type” („Līguma Tips”):

Realitāte „Product” („Produkts”):

Realitāte „Contract Line” („Līguma Rinda”):

Rezultātā visas realitātes izskatās apmēram šādi:

Relāciju veidošana

Viens pret viens

No rīkjoslas izvēlas attiecīgo saites veidu un pašu saiti veido ar peli uzklikšķinot uz vienas realitātes un pēc

tam uz otras realitātes:

Saites īpašības:

Izmainām tā, lai saite būtu obligāta (Existence: Mandatory) un to, ka saites būs 1:1 (Cardinality: One Exactly: 1):

Saites izskatās „Z” simbola vietā tagad rādās „1”:

Ir izveidota saite 1:1 starp klientu un adresi, kas nozīmē, ka katram klientam būs tikai 1 adrese un tā ir obligāti jānorāda.

Viens pret daudziem

Veidojot šo saiti, svarīgi ir uz pirmās uzklikšķināt uz vecāka (Parent) realitātes un pēc tam uz pakārtotās

(Child) realitātes:

Saite 1:N starp klientu un līgumu, kas nozīmē, ka vienam klientam var būt vairāki līgumi:

Saite 1:N starp līgumu un rēķinu, kas nozīmē, ka katram līgumam var izrakstīt vairākus rēķinus:

Saites 1:N starp līgumu un līguma rindu, kas nozīmē, ka katram līgumam var būt vairākas līguma rindas:

Rekursīvā saite

No rīkjoslas var izvēlēties, piemēram, to pašu saites tipu, ko iepriekš (veidojot 1:N), tikai īpatnība ir tāda, ka

vienkārši 2 reizes ir jānospiež uz tās realitātes, kurai būs šī rekursīvā saite.

Tālāk dialoglogā ir jānorāda kā realitātes iekšienē izpaudīsies šī rekursivitātes – kurš lauks norādīs uz vecāka

realitātes ID:

Rekursīvā saite līgumam – tas nozīmē, ka vienam līgumam var būt vairāki apakšlīgumi:

Daudzi pret daudziem

Saite M:N starp līgumu un līguma tipu – tas nozīmē, ka līgums var piederēt vairākiem tipiem (ietilpst vairākās klasifikācijās):

Saite M:N starp līguma rindu un produktu – tas nozīmē, ka katra līguma līgumu rindās var būt vairāki produkti, kā arī produkti var būt izmantoti vairākos līgumos:

Modeļa sakārtošana

Patiesībā, ja realitātes nebūtu tikušas pārvietotas, tad pēc saišu izveidošanas diagramma izskatītos apmēram šādi:

Skats nepavisam nav baudāms, tāpēc var izmantot kādu no diagrammas sakārtošanas rīkjoslas iespējām. Piemēram, hierarhiskais izkārtojums:

Fiziskā modeļa ģenerēšana

Kokā izvēlas datu modeli un izvēlas Generate Physical Model:

Vedņa 1. logā norāda fiziskā modeļa nosaukumu un kādai DBVS tiks paredzēts šis fiziskais modelis:

2. vedņa logā atzīmē, kuras konkrēti (vai visas) realitātes tiks iekļautas fiziskā modeļa ģenerēšanā:

3. solī norāda prefiksu, kāds tiks iekļauts visu fiziskā modeļa objektu nosaukumos. Tas ir ērti, ja vēlāk

jāizpilda DDL skripts datubāzē, kur jau eksistē citi objekti un tad ir vieglāk atšķirt objektus, kas nākuši no

dotā projekta:

Šķirklī General Options var atzīmēt, kas tiks darīts ar atstarpēm realitāšu un atribūtu nosaukumos, kādā

reģistrā (Case) tiks pārveidoti nosaukumi – lieliem vai maziem burtiem un kas tiks darīts ar

nepieņemamiem simboliem (piemēram, ne visas vides varēs pieņemt diakritiskās zīmes).

4. solī var norādīt dažādas datubāzei specifiskus glabāšanas parametrus:

5. solī norāda, kā rīkosies ar saitēm M:N un citas lietas:

Pēdējais fiziskā modeļa vedņa solis

Pēc pogas Finish nospiešanas šādi izskatās fiziskais modelis. Ir redzams, ka ir uzģenerētas 2 starptabulas

„mpa_contracts_contract_types” un „mpa_contract_lines_product” vietās, kur starp realitātēm bija saite

„Daudzi-pret-daudziem”:

DDL skripta ģenerēšana

Database > Generate Database:

Tālāk seko 3 vedņa dialoglogi, kuros norādīt dažādas lietas, kas attiecas uz ģenerējamo DDL:

1. DDL vedņa logs

2. DDL vedņa logs

3. DDL vedņa logs

Tālāk tiek piedāvāts atvērt kodu ar programmu, kas nāk komplektā ar Data Architect – „Universal ISQL”:

Ar šo rīku iespējams pieslēgties pie konkrētas DB un izpildīt uzģenerēto skriptu:

Konkrētā gadījumā skripta izpildei tomēr tika izvēlēts cits rīks, taču tas nav svarīgi.

Sekojošais DDL skripts tika veiksmīgi izpildīts Oracle DVBS 11.2.0.2.0---- ER/Studio Data Architect 9.1 SQL Code Generation-- Project : MPA_Test_System.DM1---- Date Created : Wednesday, October 24, 2012 00:20:06-- Target DBMS : Oracle 11g--

-- -- TABLE: mpa_addresses --CREATE TABLE mpa_addresses( address_id NUMBER(15, 0) NOT NULL, country VARCHAR2(255) NOT NULL, city VARCHAR2(255), street VARCHAR2(255), street_number VARCHAR2(30), postal_code VARCHAR2(30), client_id NUMBER(15, 0) NOT NULL,

CONSTRAINT pk20 PRIMARY KEY (address_id));-- -- TABLE: mpa_bills --CREATE TABLE mpa_bills( bill_id NUMBER(15, 0) NOT NULL, bill_number VARCHAR2(30) NOT NULL, amount NUMBER(15, 0) NOT NULL, contract_id NUMBER(15, 0) NOT NULL, CONSTRAINT pk7 PRIMARY KEY (bill_id));-- -- TABLE: mpa_clients --CREATE TABLE mpa_clients( client_id NUMBER(15, 0) NOT NULL, phone VARCHAR2(255), first_name VARCHAR2(255), last_name VARCHAR2(255), CONSTRAINT pk1 PRIMARY KEY (client_id));-- -- TABLE: mpa_contract_lines --CREATE TABLE mpa_contract_lines( contract_line_id NUMBER(15, 0) NOT NULL, date_from DATE NOT NULL, date_to DATE, contract_id NUMBER(15, 0) NOT NULL, CONSTRAINT pk9 PRIMARY KEY (contract_line_id));-- -- TABLE: mpa_contract_lines_product --CREATE TABLE mpa_contract_lines_product( contract_line_id NUMBER(15, 0) NOT NULL, product_id NUMBER(15, 0) NOT NULL, CONSTRAINT PK11 PRIMARY KEY (contract_line_id, product_id));-- -- TABLE: mpa_contract_types --CREATE TABLE mpa_contract_types( type_id NUMBER(15, 0) NOT NULL, type_name VARCHAR2(255) NOT NULL, CONSTRAINT pk21 PRIMARY KEY (type_id));-- -- TABLE: mpa_contracts --CREATE TABLE mpa_contracts( contract_id NUMBER(15, 0) NOT NULL, parent_contract_id NUMBER(15, 0) NOT NULL, contract_number VARCHAR2(30) NOT NULL, status VARCHAR2(30) NOT NULL, start_date DATE NOT NULL, end_date DATE, client_id NUMBER(15, 0) NOT NULL, CONSTRAINT PK2 PRIMARY KEY (contract_id));-- -- TABLE: mpa_contracts_contract_types --CREATE TABLE mpa_contracts_contract_types( contract_id NUMBER(15, 0) NOT NULL, type_id NUMBER(15, 0) NOT NULL, CONSTRAINT PK10 PRIMARY KEY (contract_id, type_id));-- -- TABLE: mpa_product --CREATE TABLE mpa_product( product_id NUMBER(15, 0) NOT NULL, product_name VARCHAR2(255) NOT NULL, product_type VARCHAR2(30) NOT NULL, CONSTRAINT pk27 PRIMARY KEY (product_id)

);-- -- TABLE: mpa_addresses --ALTER TABLE mpa_addresses ADD CONSTRAINT Refmpa_clients2 FOREIGN KEY (client_id) REFERENCES mpa_clients(client_id);-- -- TABLE: mpa_bills --ALTER TABLE mpa_bills ADD CONSTRAINT Refmpa_contracts5 FOREIGN KEY (contract_id) REFERENCES mpa_contracts(contract_id);-- -- TABLE: mpa_contract_lines --ALTER TABLE mpa_contract_lines ADD CONSTRAINT Refmpa_contracts7 FOREIGN KEY (contract_id) REFERENCES mpa_contracts(contract_id);-- -- TABLE: mpa_contract_lines_product --ALTER TABLE mpa_contract_lines_product ADD CONSTRAINT Refmpa_contract_lines12 FOREIGN KEY (contract_line_id) REFERENCES mpa_contract_lines(contract_line_id);

ALTER TABLE mpa_contract_lines_product ADD CONSTRAINT Refmpa_product13 FOREIGN KEY (product_id) REFERENCES mpa_product(product_id);-- -- TABLE: mpa_contracts --ALTER TABLE mpa_contracts ADD CONSTRAINT Refmpa_clients3 FOREIGN KEY (client_id) REFERENCES mpa_clients(client_id);

ALTER TABLE mpa_contracts ADD CONSTRAINT Refmpa_contracts14 FOREIGN KEY (parent_contract_id) REFERENCES mpa_contracts(contract_id);-- -- TABLE: mpa_contracts_contract_types --ALTER TABLE mpa_contracts_contract_types ADD CONSTRAINT Refmpa_contracts9 FOREIGN KEY (contract_id) REFERENCES mpa_contracts(contract_id);

ALTER TABLE mpa_contracts_contract_types ADD CONSTRAINT Refmpa_contract_types10 FOREIGN KEY (type_id) REFERENCES mpa_contract_types(type_id);

Kopsavilkums

Trūkumi

Vairāki dialoglogi neparedz atkāpes (uz sistēmas jautājumu jāatbild TAGAD un TŪLĪT). Piemēram,

veidojot saiti starp 2 realitātēm, kurām unikālais atribūts bija nosaukts vienādi („Number”), biju

spiests ar to tikt galā nekavējoties – nav „Cancel” pogas:

Nav iespējams labot īpašības vairākām realitātēm vienlaicīgi:

Šis punkts ir izsvītrots, jo tas šķita kā trūkums sākumā, taču, kad darbošanās tika apgūta, pareizi

strādājot, pēc šādas opcijas vairs nebija vajadzības.

Daudziem logiem vienkārši NEVAR izmainīt izmērus, lai gan vieta tiek nelietderīgi izmantota un it kā

pat ir pieejama loga izmēru maiņa, taču sašaurināšana nestrādā. Jo īpaši neērti tas bija tāpēc, ka

šāda uzskates veida dokumenta gatavošanai vajadzīgs piemērot logu izmērus, lai izceltu tikai tās

daļas, kas nepieciešamas konkrētajā reizē (Screenshot veidošanai).

Uzģenerētā DDL apskates rīks „Universal ISQL” izskatās tik vecmodīgs, ka tas bojā visa pārējā Data

Architect rīka tēlu:

Varēja to vispār nerādīt. Tas gan arī īsti nav trūkums – varētu domāt, ka labāk jau kaut kas nekā

nekas.

It kā sīkums, taču nav paredzēta tāda kā vārdnīca, kurā var norādīt realitātes nosaukumu vienskaitlī

un realitātes nosaukumu daudzskaitlī (kā zināms, tabulām pieņemts nosaukumus rakstīt

daudzskaitļa formā).

Rīkam nav ekrāna formu veidošana. Ar to domāta iespēja uzģenerēt vai uzbūvēt manuāli nelielu

prototipu, kurā lietotājs varētu „pataustīt” topošo (modelējamo) sistēmu vismaz primitīvā izskatā.

(Iespējams, ka tas tā arī ir domāts un šī funkcionalitāte paredzēta kādā citā ER/Studio rīkā. Tas

netika pētīts).

Priekšrocības

Mūsdienīgs interfeiss. Intuitīvi saprotams (Look & Feel) interfeiss OS Windows lietotājiem (Unix

programmatūras piekritēji, iespējams, to neskaitītu pie priekšrocībām)

„Viegls” -> tik, cik nācās pārstrādāt ar rīku, lai iegūtu informāciju šī darba sagatavošanai, par

programmu radās vienkāršības/nesarežģītības iespaids un arī reakcijas ātrums uz lietotāja darbībām

notiek šķietami ātri, un visas ģenerēšanas/kalkulācijas šķiet pietiekoši efektīvas, ka neradīja nekādu

laika aizturi lietojamībā.

Pamatīga lietotāja rokasgrāmata ar lietotāja instrukcijām. Protams, bez „aptaustīšanas” un

izmēģināšanas ar lietotāja instrukciju vien neiztikt.

Multi-bāzu atbalsts reversajai inženierijai un koda ģenerēšanai:

Secinājums ir tāds, ka rīks izskatās diezgan perspektīvs, mūsdienīgs. Noteikti ieteicams tādu

jautājumu studēšanai kā CASE tehnoloģijas.

Izmantotie avoti

1) Embarcadero Tochnologies produktu dokumentācija

http://docs.embarcadero.com/products/er_studio/

2) EData Tech & Consulting portāls

http://www.edata-tc.com/D-A-Tools/ERStudioSoftwareArchitect.aspx

Vārdnīca

Entity - Realitāte

Macros – Makrodefinīcijas

Tutorial – Ceļvedis/Instrukcija

Data Lineage – Datu plūsma

Domain – Domēns – Otrreiz lietojams atribūts

Extraction, Transformation and Load (ETL) – Ieguve, transformācija un uzkrāšana (ITU)

Source and Target Mapping - Avota un mērķa sasaiste

Merge – Iepludināt/Sapludināt

Wizard – Vednis

Thumbnail – Sīktēls

Toolbar – Rīkjosla

Log File – Žurnāla fails