Rīgas Tehniskā universitāteDatorzinātnes un Informācijas tehnoloģijas fakultāte

Lietišķo datorsistēmu institūts

2. referāts priekšmetāInformācijas sistēmas un CASE rīki

Sybase PowerDesigner

Dmitrijs SkripkinsAndrejs PavlovičsVladislavs Zubkovs

Rīga 2010

1

Saturs1. PowerDesigner vēsture, izplatīšana, atbalsts un iespējas..........................................................3

1.1. Rīka vēsture........................................................................................................................31.2. Rīka izplatīšana...................................................................................................................41.3. Rīka atbalsts....................................................................................................................... 41.4. Rīka iespējas.......................................................................................................................5

2.Modeļu veidošana un transformācija.........................................................................................62.1. Problēmsfēras apraksts......................................................................................................62.2. Konceptuālā modeļa veidošana.........................................................................................62.3. Loģiskā modeļa ģenerēšana.............................................................................................102.4. Fiziskā modeļa ģenerēšana...............................................................................................14

Secinājumi....................................................................................................................................20

2

1. PowerDesigner vēsture, izplatīšana, atbalsts un iespējas

1.1. Rīka vēsturePowerDesigner vēsture sākas ar produktu, kura nosaukums bija AMC Designor Francijāun S-Designor pārejā pasaulē. To izstrādāja kompānijas SDP Technologies darbinieks Xiao-Yun Wang.Ir vērts atzīmēt, ka burti „or“, kas ir izvietoti nosaukuma beigās, norāda, ka dotais produkts attiecas uz Oracle. Rīks bija izveidots, lai darboties ar Oracle datu bāzēm, bet diezgan ātri tika paplašināts ar visu pamata relāciju datu bāžu vadības sistēmu atbalsta iespējam.

SDP Technologies ir Franču kompānija, kas sāka savu darbību 1883. gadā. 1995. gadā SDP kļuva par Powersoft īpašumu, kuru, savukārt, gadu agrāk pārņēma Sybase. Beigu beigās, produkta nosaukums tika nomainīts ar mērķi paradīt tā piederību Powersoft kompānijai. Visas tiesības uz PowerDesigner un PowerAMC (rīka nosaukums Francijā) pieder Sybase.

Daži svarīgi fakti no PowerDesigner vēstures: 1989.— pirmā komerciālā AMC Designor relīze Francijā; 1992.— pirmā komerciālā S-Designor relīze ASV; 1994.— ProcessAnalyst tika pievienots programmas paketei; 1995.— S-Designor kļūst par PowerDesigner, AMC Designor kļūst par PowerAMC; 1998.— WarehouseArchitect pievienots paketei; 1999.— PowerDesigner 7.0 tika pārveidots, piedāvājot jaunas tehnoloģijas

un lietotāja saskarni, līdzīgo citiem Sybase produktiem; 2006.— PowerDesigner 12 relīze ar transformāciju un atskaišu veidošanas iespējām; 2006.— PowerDesigner 12.1 relīze ar Microsoft Visual Studio un SQL Server atbalstu; 2007.— PowerDesigner 12.5”relīze ar jauniem modelēšanas principiem: ETL, EII

un pilno UML 2.0 diagrammu atbalstu; 2008. —PowerDesigner 15 relīze ar modeli Enterprica Architect Model un jauno notāciju

atbalstu (piemēram, Barker); 2010. — pēdējā oficiāli pieejamā versija PowerDesigner 15.3.

3

1.2. Rīka izplatīšanaPowerDesigner ir programmatūra ar maksas licenci. To var iegūt šādos veidos:

Ielādēt no Sybase oficiālas mājas lapas produkta izmēģinājuma versiju(tagadir pieejama relīze 15.2). Tā ir pilnīgi funkcionālā, tomēr izmantošanas periods ir ierobežots — 15 dienas.

Iegadāties PowerDesigner licenci. Pastāv divu tipu licences: Standalone Seat License, kas ir derīga vienam datoram, kurā arī turpmāk tiks lietota; un Floating User License, kas var tikt instalēta uz vairākām darba vietām, bet lietotāju skaits, kas vienlaicīgi strādās ar produktu, nevar pārsniegt noradītu licencē.

1.3. Rīka atbalstsSybase piedāvā savam produktam pietiekami lielu un detalizētu informācijas atbalstu. Oficiālajā mājas lapā ir iespēja ielādēt gan produkta tehnisko dokumentācija, gan lietotāju pamācības gan angļu (priekš PowerDesigner) gan franču (priekš PowerAMC) valodās. Ir arī norādes uz biežāk uzdotiem jautājumiem un lietotāju forumu.

Kļūstot par PowerDesigner vai PowerAMC licencēto lietotāju parādās iespēja lietot arī Sybase tehnisko atbalstu. Tas dod iespēju ne tikai operatīvi saņemt tehniska atbalsta dienesta palīdzību, bet arī regulāri atjaunot produktu.

4

1.4. Rīka iespējasProgrammatūra PowerDesigner var tikt pielietota vairāku tipu uzdevumu realizācijai. Produktam ir šādas pamata funkcijas un iespējas:

biznesa procesu modelēšana ar moduli ProcessAnalyst; koda ģenerēšana vairākām populāram programmēšanas valodām

(Java, C#, Hibernate, EJB3, NHibernate, JSF, WinForm utt.); datu modeļu veidošana un transformācija; datu glabāšanas modelēšana ar moduli WarehouseArchitect; Eclipse un Visual Studio moduli; Objektu modelēšana un UML 2.0atbalsts; atskaišu ģenerēšana; prasību analīze; XML modelēšana; XML Schema un DTD standartu atbalsts.

5

2. Modeļu veidošana un transformācijaAr Sybase PowerDesigner palīdzību var veidot dažādus datu modeļu tipus un automātiski transformēt tos viens otrā. Lai detalizēti aprakstītu šo procesu, tika nolemts paņemt konceptuālā modeļa piemēru Merise notācijā un pārveidot to vispirms loģiskajā modelī, bet pēc tam arī fiziskajā modelī, rezultātā saņemot gatavu SQL kodu.

2.1. Problēmsfēras aprakstsKā problēmsfēra piemēra veidošanai tika izvēlēts mobilais operators — tāds uzņēmums kā LMT, Tele2 vai Bite, kurš darbojas Latvijas teritorijā. Lai piemērs būtu interesantāks un aptverošāks, tika nolemts uzprojektēt pēc iespējas pilnvērtīgāko mobilā operatora datu bāzes struktūru, iekļaujot tajā šādas datu kategorijas:

dati par uzņēmuma klientiem — privātpersonām un uzņēmumiem; dati par uzņēmuma resursiem — mobilā operatora darbiniekiem un veikaliem; tehniskie dati — eksistējošie telefona numuri, piedāvātie tālruņu modeli; grāmatvedība — līgumi starp mobilo operatoru un tā klientiem.

Analizējot doto piemēru no tehniskas puses, tika nolemts iekļaut tajā šādus elementus: vairākas realitātes; asociācijas starp realitātēm ar un bez papildus atribūtiem; dažādus saišu tipus — „1, 1”, „1, n” un „n, m”; relācijas starp realitātēm — kompozīciju, agregāciju utt.; mantošanu.

2.2. Konceptuālā modeļa veidošanaKonceptuālā modeļa veidošanas gaitā tika izmantotas 11 realitātes, 8 asociācijas starp tām, kā arī divas dažādas mantošanas saites. Izveidotais modelis ir parādīts 4. lpp. Savukārt, zemāk ir detalizēti aprakstītas visas tajā iekļautas realitātes un saites starp tām.

Realitāte „Klients”Reprezentē visus mobilā operatora klientus: gan privātpersonas, gan uzņēmumus.

# Atribūts Tips Apraksts1. Klienta_id Long integer Primārais identifikators2. Klienta_numurs Characters (10) Klienta numurs, kuru viņam piešķir mobilais operators3. Statuss Byte Klienta statuss: aktīvs, atslēgts utt.

Realitāte „Privātpersona”Reprezentē mobilā operatora klientus — privātpersonas. Šī realitāte manto (tiek izmantota pilnīga mantošana, jo viens un tas pats klients nevar būt privātpersona un uzņēmums vienlaicīgi) visus realitātes „Klients” atribūtus un pievieno tiem dažus citus.

# Atribūts Tips Apraksts1. Vards Characters (100) Privātpersonas vārds2. Uzvards Characters (100) Privātpersonas uzvārds3. Personas_kods Characters (12) Personas kods LR standartā

6

Realitāte „Uzņēmums”Reprezentē mobilā operatora korporatīvos klientus — uzņēmumus. Šī realitāte manto (tiek izmantota pilnīga mantošana, jo viens un tas pats klients nevar būt privātpersona un uzņēmums vienlaicīgi) visus realitātes „Klients” atribūtus un pievieno tiem dažus citus.

# Atribūts Tips Apraksts1. Nosaukums Characters (100) Uzņēmuma nosaukums2. Registracijas_numurs Characters (13) Uzņēmuma reģistrācijas numurs LR standartā

Realitāte „Adrese”Reprezentē adreses, kuros dzīvo mobilā operatora klienti. Šī realitāte tiek savienota ar realitāti „Klients”, pielietojot kompozīciju. Tas nozīmē, ka, ja kāda adrese vairs nedzīvo neviens klients, tā tiek automātiski nodzēsta no datu bāzes.

# Atribūts Tips Apraksts1. Adrese_id Long integer Primārais identifikators2. Adrese Characters (256) Adrese teksta veidā3. Pasta_indekss Characters (50) Atbilstošs pasta indekss LR standartā

Realitāte „Numurs”Reprezentē tālruņa numurus, kurus pielieto mobilā operatora klienti. Šī realitāte tiek savienota ar realitāti „Klients”, izmantojot agregāciju. Tas nozīmē, ka, ja kāds tālruņa numurs paliek brīvs (klients vairs to nelieto), tas paliek datu bāzē un var tikt pievienots kādam citam klientam.

# Atribūts Tips Apraksts1. Numurs_id Long integer Primārais identifikators2. Numurs Integer Numurs skaitļa veidā3. Statuss Byte Numura statuss: aktīvs, brīvs utt.

Realitāte „Veikals”Reprezentē mobilā operatora veikalu tīklu.

# Atribūts Tips Apraksts1. Veikals_id Long integer Primārais identifikators2. Nosaukums Characters (100) Veikala nosaukums3. Tips Byte Veikala tips: vai tas pārsvarā strādā ar privātpersonām,

uzņēmumiem, vai arī ar visiem mobilā operatora klientiem

7

Realitāte „Darbinieks”Reprezentē visus mobilā operatora darbiniekus. Tā kā daži no darbiniekiem ir vadītāji (vada citus darbiniekus), šajā realitātē tiek pielietota asociācijas saite pret sevi. Savukārt, tie darbinieki, kuri strādā veikalos, tiek pievienoti reālitātei „Veikals” ar asociācijas „Strādā” palīdzību. Šī asociācija definē darbinieka amatu veikalā, algu un darbības periodu.

# Atribūts Tips Apraksts1. Darbinieks_id Long integer Primārais identifikators2. Vards Characters (100) Darbinieka vārds3. Uzvards Characters (100) Darbinieka uzvārds4. Personas_kods Characters (12) Darbinieka personas kods LR standartā

Realitāte „Telefons”Reprezentē telefonu modeļus, kurus pārdod mobilā operatora veikali un pērk tā klienti. Lai attēlotu tirdzniecības procedūru datu bāzē, tiek pielietotas divas asociācijas: „Tirgo”, kas savieno veikalus ar telefoniem, un „Pērk”, kas telefonus savieno ar klientiem.

# Atribūts Tips Apraksts1. Telefons_id Long integer Primārais identifikators2. Razotajs Characters (100) Telefona ražotāja nosaukums3. Modelis Characters (100) Telefona modeļa kods4. IMEI_kods Characters (16) Telefona unikāls IMEI kods

Realitāte „Līgums”Reprezentē līgumus, kurus sastāda mobilā operatora veikali un pārraksta tā klienti. Lai attēlotu šo procedūru datu bāzē, tiek pielietotas divas asociācijas: „Sastāda”, kas savieno veikalus ar līgumiem, un „Pārraksta”, kas līgumus savieno ar klientiem.

# Atribūts Tips Apraksts1. Ligums_id Long integer Primārais identifikators2. Summa Money Līgumā noradīta summa3. Ilgums Byte Līguma ilgums mēnešos4. Statuss Byte Līgums statuss: sastādīts, parakstīts utt.

Realitāte „Jauns līgums”Reprezentē jaunu līgumu starp veikalu un klientu. Šī realitāte manto visus realitātes „Līgums” atribūtus un pievieno tiem dažus citus.

# Atribūts Tips Apraksts1. Tarifs Characters (50) Tarifu plāns, kuru izvēlējas klients

Realitāte „Pagarināts līgums”Reprezentē pagarinātu līgumu starp veikalu un klientu, kurš tiek parakstīts iepriekšēja līguma beigām. Šī realitāte manto visus realitātes „Līgums” atribūtus un pievieno tiem dažus citus.

# Atribūts Tips Apraksts1. Subsidija Money Subsīdijas apmērs, kurš tiek piešķirts klientam

8

Zemāk ir parādīts iegūtais konceptuālais modelis, kurš aprakstā mobilā operatora datu bāzes struktūru. Šī modeļa zīmēšanas process PowerDesigner vidē nesagādāja nekādas grūtības: tas notika līdzīgi tādiem diagrammu zīmēšanas rīkiem kā Microsoft Visio.

9

2.3. Loģiskā modeļa ģenerēšanaNākamais solis pēc konceptuālā modeļa veidošanas ir loģiskā modeļa ģenerēšana. Pēc definīcijas, loģiskais modelis attēlo sistēmas struktūru neatkarīgi no tās iespējamām implementācijām un nodrošina konsekventu pāreju no konceptuālā līdz fiziskajam modelim.

Loģiskais modelis ir īpaši lietderīgs lielos projektos, kur ir plānots izmantot vairākas dažādas datu bāžu vadības sistēmas (DVBS). Savukārt, mazos projektos šī modeļa ģenerēšana nav obligāts posms, un dažreiz no konceptuālā tiek uzreiz ģenerēts fiziskais modelis: PowerDesigner vidē ir nodrošināta arī šāda iespēja.

Pirms sāktu konceptuālā modeļa transformāciju, ir ieteicams pārbaudīt tā pareizību. PowerDesigner programmatūrā ir iebūvēts rīks, kurš piedāvā pārbaudīt jebkuru modeli automātiskajā režīmā. Izsaukt šo rīku var ar komandas Tools — Check Model palīdzību. Automātiskās pārbaudes rezultātā ekrānā parādās logs ar visām modelī atrastām kļūdām un brīdinājumiem.

Kopumā loģiskā modeļa ģenerēšanas process sastāv no šādiem posmiem: modeļa nosaukuma ievade; realitāšu izvēle transformācijai; modeļa notācijas izvēle; citu papildus opciju definēšana.

Uzsākt loģiskā modeļa ģenerēšanas procesu var ar komandas Tools — Generate Logical Data Model palīdzību no PowerDesigner galvenās izvēlnes.

10

Pēc komandas palaišanas ekrānā parādās logs ar dažām transformācijas pamata opcijām. Piemēram, PowerDesigner piedāvā iespēju ievadīt loģiskā modeļa nosaukumu.

Tā kā PowerDesigner ļauj transformēt ne tikai visu konceptuālo modeli, bet arī atsevišķas tā daļas, iepriekšminētajā logā ir redzama nodaļa Selection, kura nodrošina iespēju definēt realitāšu sarakstu pārveidošanai.

11

Nospiežot uz pogu Configure Model Options, tiek parādītas dažas papildus loģiskā modeļa konfigurācijas iespējas. Piemēram, lietotājs var izvēlēties tā notāciju. Sarakstā ir ER, IDEF1X un Barker notācijas. Merise notācijas šeit nav, jo tā ir domāta tikai konceptuālajiem modeļiem.

PowerDesigner piedāvā arī citas opcijas, ar kuru palīdzību var precīzāk definēt jauna modeļa ģenerēšanas principus: modeļa elementu nosaukumu veidošanas likumus, datu tipus utt.

Kad konfigurēšanas process ir pabeigts, paliek tikai nospiest uz pogu OK, un pēc dažiem mirkļiem ekrānā parādās jauns loģiskais modelis (mūsu gadījumā tam tika izvēlēta Barker notācija). Izveidotais modelis pilnībā ir parādīts 8. lpp, savukārt, zemāk ir minētas tā svarīgākas atšķirības no konceptuālā modeļa:

modelī pazuda asociācijas ar saiti „1, n” un saiti pret sevi(tās vietā parādās ārējas atslēgas);

asociācijas ar saiti „n, m” pārvēršas par atsevišķām realitātēm; būtiski izmainījās mantošanas attēlojums.

12

Zemāk ir parādīts loģiskais modelis, kurš tika izveidots konceptuālā modeļa transformācijas rezultātā.

13

2.4. Fiziskā modeļa ģenerēšanaPēdējais solis pēc loģiskā modeļa veidošanas ir fiziskā modeļa ģenerēšana. Fiziskais modelis ir uz vēl vienu soli tuvāk datu bāzes tehnoloģijām nekā konceptuālais vai loģiskais datu modelis. Šīs modelis nodrošina grafisko datu bāzes struktūru attēlojumu, kā arī palīdz analizēt tabulas (ieskaitot tas kolonnas, indeksus, un trigerus), skatus, procedūras un saites starp tiem.

Fiziskais modelis ļauj definēt, kā dati no konceptuālā modeļa tiek īstenoti datu bāzē un automātiski ģenerē SQL kodu izvēlētāj DBVS. Šīs modelis pārsvara tiek veidots datu analizēs procesa beigas, pirms sākas programmēšana. PowerDesigner pastāv iespēja ģenerēt fizisko modeli gan no konceptuālā modeļa, gan no loģiskā modeļa.

Modeļus ģenerēšanas procesi PowerDesigner ir ļoti līdzīgi. Līdz ar to fiziska modeļa ģenerēšanas process minimāli atšķiras no loģiska modeļa ģenerēšanas procesa un sastāv no šādiem posmiem:

modeļa nosaukuma ievade; DBVS izvēle; modeļa notācijas izvēle; citu papildus opciju definēšana.

Uzsākt fiziskā modeļa ģenerēšanas procesu var ar komandas Tools — Generate Physical Data Model (Ctrl+Shift+P) palīdzību no PowerDesigner galvenās izvēlnes.

14

Pēc komandas palaišanas ekrānā parādās logs ar dažām transformācijas pamata opcijām. Piemēram, PowerDesigner piedāvā iespēju ģenerēt jaunu fizisko modeli vai arī atjaunot (papildināt) jau esošo, kā arī ievadīt fiziskā modeļa nosaukumu.

PowerDesigner ļauj lietotājam izvelēties DBVS, kurā tiks automātiski ģenerēts SQL kods.

15

Tā kā PowerDesigner ļauj transformēt ne tikai visu konceptuālo vai loģisko modeli, bet arī atsevišķas tā daļas, iepriekšminētajā logā ir redzama nodaļa Selection, kura nodrošina iespēju definēt realitāšu sarakstu pārveidošanai.

Nospiežot uz pogu Configure Model Options, tiek parādītas dažas papildus fiziskā modeļa konfigurācijas iespējas. Piemēram, lietotājs var izvēlēties tā notāciju no Relational, CODASYL, Conceptual, IDEF1X notācijām. Pēc noklusējuma ir Relational notācija.

16

Kad konfigurēšanas process ir pabeigts, nospiežam uz pogu OK. Ekrānā parādās jauns fiziskais modelis (mūsu gadījumā tam tika izvēlēta Relational notācija). Izveidotais modelis pilnībā ir parādīts 18. lpp, savukārt, zemāk ir minētas tā svarīgākas atšķirības no loģiskā modeļa:

izmainījās mantošanas attēlojums — pazudusi superklases realitāte; realitātes pārvēršas par tabulām; datu tipi izmainījās atbilstoši izvēlētam DBVS standartam; parādījās primāras un ārējas atslēgas; relācijām vairs nav apzīmējuma.

17

Zemāk ir parādīts fiziskais modelis, kurš tika izveidots loģiskā modeļa transformācijas rezultātā.

18

Lai apskatīt un pielietot SQL kodu, kas ir automātiski noģenerēts kopā ar fizisko modeli ir janospiež uz fiziskās diagrammas ikonu rīkā kreisajā pusē un jāizvēlas Properties (Alt+Enter)

Logā ir jāizvēlas Preview, kur lietotājs varēs redzēt SQL kodu. Šīs SQL kods ļauj izveidot datu bāzi kura ir attēlota fiziskajā modelī.

19

SecinājumiSybase PowerDesigner ir pati populārākais CASE rīks, kurš tiek plaši izmantots industrijā. Tomēr, protams, ka visai pārējai programmatūrai, tam ir savas priekšrocības un trūkumi, ar kuriem var sastapties datu modeļu izstrādes laikā.

PowerDesigner priekšrocības: vairāku notāciju atbalsts; vairāku datu bāžu vadības sistēmu atbalsts; iespēja veikt izmaiņas modeļos jebkurā to izstrādes brīdī; transformācijas no visiem modeļiem uz visiem modeļiem.

PowerDesigner trūkumi: programmatūrai trūkst dokumentācijas —

ne visas iespējamas kļūdas ir pilnībā aprakstītas; dažas nepilnības un neērtības lietotāja saskarsmē.

20