INFORMACIONE TEHNOLOGIJE U MEDICINI 2012/13 LEKCIJA 6

INFORMACIONE TEHNOLOGIJE U MEDICINI 2012/13 LEKCIJA 6 Mateja Opačić PROJEKTOVANJE BAZE PODATAKA Baza podataka predstavlja kolekciju formatizovanih podataka organizovanih za laku pretragu i obradu. Neki primeri baza podataka su: Arhiva zdravstvenih kartona Arhiva studentskih ocena (Grupa) XML datoteka... Nad podacima koji čine jednu bazu podataka mogu se vršiti sledede operacije: 1. Kreiranje novog sloga 2. Izmena postojedeg sloga 3. Modifikacija podataka u slogu 4. Čitanje podataka iz sloga 5. Obrada podataka, kao i 6. Kombinacija prethodno navedenih operacija. Dokument - orjentisane baze podataka Još uvek je u vedinskoj upotrebi u paperware obliku (zdravstveni karton), ali postoje i u računarskim sistemima i u tom slučaju je jedan dokument jedna datoteka (XML). Problemi koji se javljaju kod skladištenja podataka na ovaj način su: redundantnost (ponavljanje podataka) problemi pri pretraživanju/obradi podataka. Relacione baze podataka Podaci su grupisani u tabele, pri čemu: svaka tabela predstavlja jedan entitet svaka kolona predstavlja jedan atribut entiteta svaki red predstavlja jednu instancu entiteta Relacije između entiteta se realizuju kroz šifriranje instanci. Primer: tabela Student 1

Primarni ključ jedinstveno određuje instancu, svaka instanca ima tačno jedan primarni ključ. Jedinstveni ključ jedinstveno određuje instancu, svaka instanca ima bar jedan jedinstven ključ (primarni). Strani ključevi su primarni ključevi drugih entiteta i predstavljaju relacije. Primer: tabele Student, Ocena Primer: tabele Student, Ocena, Predmet Metodologija i baze podataka Baze podataka su obično deo projektovanja nekog vedeg sistema pa se na njih primenjuje metodologija odabrana za ceo sistem. Uobičajeni koraci pri projektovanju baze su: 1. Uzimanje zahteva 2. Definisanje sistemskih parametara 3. Definisanje radnih procesa 4. Izrada konceptualnog modela podataka 5. Izrada fizičkog modela podataka 6. Testiranje i optimizacija Entiteti Entiteti su apstraktni koncepti (osobe, mesta, stvari, događaji,...) za koje postoji interes da se u okviru sistema čuvaju informacije o njima u periodima kada sistem nije aktivan (perzistencija). Entitet je specificiran svojim atributima, identifikatorima i relacijama sa ostalim entitetima. Odabir entiteta zavisi od zahteva sistema. Entiteti se biraju klasifikacijom posmatranog ambijenta, odnosno uočavanjem zajedničkih karakteristika koje su bitne za sistem. Neki primeri entiteta su: Entitet Boja može imati više instanci koje predstavljaju konkretne boje (crvena, bela,...) Entitet Student može imati više instanci koje predstavljaju pojedine studente. Atributi Atribut (svojstvo) opisuje jedno svojstvo entiteta koje je od interesa za sistem. Svaki entitet je definisan skupom svojstava. Svaka instanca entiteta je određena skupom vrednosti koje su dodeljene atributima. Na primer, ako entitet Student sadrži svojstva br. indeksa, ime, prezime, jedna od instanci ovog entiteta je određena vrednostima 403, Marko, Markovid. 2

Domeni Domen podataka predstavlja skup svih dozvoljenih vrednosti i uključuje: osnovni tip podataka (string, int, ), pravila za validaciju vrednosti - lista vrednosti - nabrajanje - opseg vrednosti - od, do - vrsta saržaja - [A..Z] [a..z] [0..9] - NULL vrednosti - nedefinisana vrednost atributa Domen vrednosti se dodeljuje atributima. Identifikatori Identifikator predstavlja skup atributa čije vrednosti na jedinstven način identifikuju svaku instancu nekog entiteta. Identifikatori mogu biti: 1. Primarni (tačno jedan) 2. Sekundarni (nula ili više) Relacije Relacije predstavljaju veze između entiteta. Razlikujemo: 1. Asocijaciju - bilo koja vrsta zavisnosti Agregacija - vezan životni ciklus Kompozicija - isti životni cikus 2. Generalizaciju Princip nasleđivanja u OO jezicima Klasifikacija jednog entiteta kao podskup drugog Primeri: krug i geometrijska figura; student i osoba. Reprezentacija relacija u ER notaciji Svaka relacija je određena: Nazivom koji je jedinstven za model Kardinalnošdu - 1:1, 1:N, N:M Minimalnim brojem pojava Zavisnošdu (dependency) 3

Između bilo koja dva entiteta može postojati nijedna, jedna ili više relacija. Broj pojava ( mandatory zastavica) Ako zastavica postoji, neophodno je da instanca tog entiteta postoji. Nijedan, jedan ili oba entiteta u relaciji mogu biti obavezna (mandatory). Zavisnost ( dependent zastavica) Identifikator zavisnog entiteta se proširuje identifikatorom polaznog entiteta. Polazni entitet je implicitno obavezan. Kardinalnost - broj pojava 0,1 nijedna ili jedna 0,n nijedna, jedna ili više 1,1 tačno jedna 1,n jedna ili više Određuje neophodan broj pojava entiteta na određenom kraju relacije. Poslovna pravila Poslovna pravila podrazumevaju pravila inicijalizacije, manipulacije, interpretacije i upotrebe podataka. Poslovna pravila mogu biti: ograničenja nad vrednostima koje se dodeljuju atributima, ograničenja nad akcijama za manipulaciju entitetima, kalkulacije koje se primenjuju nad podacima, definicije pojmova koje su u upotrebi u domenu. Konceptualni model podataka U konceptualnom modelu se bavimo samo problemom organizacije podataka. Eksperti u određenim biznis domenima konceptualno predstavljaju podatke i obično nemaju informacije o tehničkim detaljima DB sistema. Konceptualno modelovanje je pogodno za posmatranje celokupne slike sistema. Konceptualno modelovanje dozvoljava N:M veze. 4

Slika 1: Kreiranje novog CDM Slika 2: Model properties 5

Slika 3: Model options «Display preferences» omogudavaju da se promeni vizuelna prezentacija objekata na dijagramu: generalne izmene nad načinom na koji se odvaja ime, skraduje, pravi prelom reči, kao i izmene u grafičkoj prezentaciji poput boje objekata, boje teksta, veličine teksta, debljine linije, itd. Slika 4: Display preferences 6

Entity properties omogudavaju unos opštih podataka o entitetu kao što su: naziv, kod, komentar, broj, stereotip, itd. Dodatni podaci o entitetu Slika 5: Entity properties Svaki entitet može da ima dodatne informacije kao što su: Attributes - podaci koji predstavjaju informacije o tom entitetu Identifiers - primarni ključevi koji jedinstveno definišu instance entiteta Notes - opisi i anotacije Rules - biznis pravila koja su vezana za taj entitet Dependencies - odnosi i relacije. Data item Data item predstavlja najmanji smisleni delid informacije u konceptualnom modelu. Data item koji je povezan sa nekim entitetom predstavlja atribut tog entiteta. Može biti kreiran implicitno ili eksplicitno. Osnovni podaci vezani za neki atribut su: 7

Name naziv atributa jedinstven na nivou entiteta. Naziv treba da bude jasan i jednosmisleno da definiše značenje atributa. Treba da bude jasan i netehničkim korisnicima. Code skraden naziv koji se korsiti u PD Data Type standardni tip podatka, definiše njegov tip, veličinu i preciznost Domain opciona vrednost koja definiše detalje o atributu o Doman imenovana vrednost koja definiše tip podatka, dužinu preciznost i služi da bi se pomodu njega definisao jedan ili više atributa. Mandatory flag boolean vrednost koja obeležava da li je atribut neophodan u entitetu Primary Indentifier flag boolean vrednost koja definiše da li je neki atribut primarni ključ za taj entitet Displayed flag označava da li de atribut biti prikazan na dijagramu. Slika 6: Attribute properties Poslovna pravila Poslovna pravila su dodatne informacije koje ne mogu da se smeste u dijagrame i na entitete ili njihove relacije. Poslovna pravila mogu da se odnose ne entitete, atribute, relacije ili na sistem u celosti. Jedno poslovno pravilo može da se odnosi na jedan ili više elemenata konceptualnog modela. 8

Biznis pravila Biznis pravila služe da bi se zabeležile informacije koje su bitne za sistem, a ne mogu da se direktno predstave na dijagramu. Prilikom uzimanja informacija o sistemu, neke od njih nije mogude prikazati u konceptuanom dijagramu, ali su bitne zbog drugih modela (oom, pdm, eam...) Slika 7: Biznis pravilo - unos pravila Slika 8: Biznis pravilo na entitetu 9

Slika 9: Biznis pravilo nad atributom Tipovi biznis pravila Biznis pravila mogu da se odnosne na nekoliko različitih aspekata sistema. Na primer, mogu da budu posledica nekog ograničenja (constraint) ili da budu neka činjenica o sistemu (fact) ili formula po kojoj se izračunava neki podatak ili validaciono pravo ili neka definicija podatka, itd. Slika 10: Tipovi biznis pravila 10

Dodavanje pravila Ako isto pravilo treba dodati još nekom objektu nije potrebno ponovo pisati pravilo ved je mogude postojede pravilo samo dodati. Lista biznis pravila Lista svih biznis pravila, može da se vidi iz opcije Model -> Business Rules : 11

Provera modela PowerDesigner ima mehanizam pomodu koga može da se proveri kreirani model. Provera modela obezbeđuje da se eventualne greške na modelu uoče pre nego što se model upotrebi za generisanje nekog drugog modela ili finalnog koda. Provera modela može da se ograniči, odnosno da se u proveru ne uključi neki od objekata modela. Na primer, može da se uradi provera samo Entiteta. Takođe je mogude izvršiti proveru modela samo za odabrane objekte, ne za sve. To se radi u delu selekcije objekata iz modela. Generisanje fizičkog modela Slika 11: Generisanje fizičkog modela za DBMS MySQL, verziju 5 12

DBMS koji su podržani PowerDesigner podržava skoro sve poznate DBMS sisteme, uključujudi i različite verzije tih sistema. Slika 12: Opcije fizičkog modela 13

Nakon generisanja fizičkog modela, u PowerDesigneru postoje dva modela, konceptualni i fizički. Fizički model Fizički model je vrlo sličan konceptualnom, ali se razlikuje jer odslikava odnos između tabela koji de biti u DBMS-u (DataBase Management System). Fizički model predstavlja reprezentaciju dizajna strukture podataka, uzimajudi u obzir ograničenja i elemente koje obezbeđuje ciljani RDBMS. Omogudava predstavljanje dizajna sa tačke gledišta fizičke implementacije. Fizički model se formira na kraju procesa analize strukture podataka. Fizički model prikazuje: tabele, njihove kolone, ključeve, indekse, reference, ograničenja. Predstavlja šemu baze podataka na zadatom/izabranom RDBMS i koristi se za generisanje niza komandi čijim izvršavanjem se formira i inicijalizuje baza podataka (DDL komande). Osnovni elemetni fizičkog modela 1. Tabela Tabela je semantička celina i podrazumeva skup vrednosti povezanih u celinu zadatog značenja. Tabela predstavlja dvodimenzionalnu matricu koja sadrži: 14

Vrste vertikalna dimenzija zapisi (records) Kolone horizontalna dimenzija atributi Vrste su osnovna jedinica manipulacije. Sve vrste u tabeli imaju istovetnu strukturu (Vrsta(Row), Zapis(Record), Slog(Tuple)). Pristup podacima u tabeli se vrši kroz selekciju/projekciju po dimenzijama: o Podskup kolona izbor atributa o Podskup vrsta po nekom kriterijumu Tabela nastaje preslikavanjem entiteta o Entitet -> Tabela o Atribut -> Kolona Svaka kolona je zadatog tipa koji je podržan od strane RDBMS. 2. Kolone Kolone nastaju direktno iz atributa nekog entiteta. One predstavljaju jednu dimenziju tabele, definišu jedan slog i definisane su tipovima i ograničenjima. U zavisnosti od odabranog RDBMS, potrebno je odabrati osnovni tip podatka koji taj RDBMS podržava. 3. Ključevi Primarni ključ Postoji tačno jedan za svaku tabelu i sastoji se od jedne ili više kolona tabele. Bilo koja kombinacija vrednosti kolona primarnog ključa uvek određuje tačno jedan slog tabele. Vrednosti kolona primarnog ključa ne mogu biti nedefinisane (NULL). Primarni ključevi su pradeni indeksima koji se koriste za poboljšanje performansi upita. Strani ključevi Strani ključevi se sastoje od jedne ili više kolona tabele i definišu referencu između tabela. Vrednosti mogu biti nedefinisane ako referenca nije obavezna. Nastaju preslikavanjem identifikatora tako što kolone primarnog ključa referencirane tabele postaju kolone stranog ključa u tabeli koja sadrži referencu. Strani ključevi su pradeni indeksima. 15

Alternativni ključevi Alternativni ključ se sastoji od jedne ili više kolona tabele. Bilo koja kombinacija vrednosti kolona alternativnog ključa uvek određuje tačno jedan slog tabele. Vrednosti kolona alternativnog ključa ne mogu biti nedefinisane (NULL). Alternativni ključevi su pradeni indeksima koji se koriste za poboljšanje performansi upita. Prirodni ključevi Podrazumevaju upotrebu postojedih atributa za identifikatore. Velika mana je mogudnost promene vrednosti primarnog ključa (komplikovano održavanje referencijalnog integriteta). Lakše se manipuliše bazom podataka preko prirodnih i razumljivih vrednosti kolona primarnog ključa. Surogat (Generisani) ključevi Delegiranje RDBMS da generiše vrednost primarnog ključa za svaki slog. Najčešde je to inkrement prirodnog broja za svaki slog. Prednost je što korisnik ne vidi niti može da menja vrednost ključa (lakše održavanje referencijalnog integriteta). Mana se oslikava u tome što nisu prirodni atributi entiteta, ved brojevi koji ništa ne znače. 4. Reference Reprezentuju referenciranje sloga u podređenoj tabeli od strane sloga u nadređenoj tabeli preko stranog ključa - izjednačavanjem vrednosti kolona koje predstavljaju primarni ključ sa vrednostima kolona koje predstavljaju strani ključ. Nastaju preslikavanjem relacije - kolone identifikatora nadređenog entiteta postaju kolone podređenog entiteta. Relacije kardinalnosti N:M je potrebno razrešiti dodavanjem nove tabele sa kojom polazne tabele imaju 1:N odnos. Vrste referencijalnog ograničenja: o Primenjuju se na Update i Delete akcije o Restrict - promena vrednosti stranog ključa nije dozvoljena, brisanje sloga nadređene tabele nije dozvoljeno. o Cascade - promena vrednosti ključa u nadređenoj tabeli de se odraziti nad slogovima podređene tabele. Brisanje sloga nadređene tabele de prethodno obrisati slogove podređene tabele koji referenciraju podređeni slog. 16

o Set NULL - brisanje sloga ili promena vrednosti ključa sloga nadređene tabele de dovesti do postavljanja NULL vrednosti svih kolona stranog ključa u slogovima podređene tabele koji referenciraju slog čiji ključ se promenio. o Set Default - isto kao Set NULL, samo što se umesto NULL vrednosti postavlja neka predefinisana vrednost. 5. Ograničenja (Constraints) Ograničenja definišu pravila koja se proveravaju pre zapisivanja vrednosti u kolonu i izvode se iz domena konceptualnog modela. Vrste ograničenja: o Strani ključevi Referencijalni integritet o Not NULL Vrednost mora biti definisana o Enumeracija Vrednost mora biti u predefinisanom skupu nabrojanih vrednosti o Validacija Dodatna pravila koja ograničavaju skup mogudih vrednosti. 6. Indeksi Indeksi nisu direktno deo relacionog modela. Koriste se za unapređivanje performansi. Realizovani su kao posebni skup zapisa (specijalna tabela), pri čemu slogovi indeksa pokazuju na slogove tabele. Koriste se za efikasno izdvajanje podskupa slogova tabele, odnosno, pretraživanje tabele se vrši pretragom indeksa i ključevi skoro uvek imaju svoj indeks. Tabela može imati nula, jedan ili više indeksa. Opcije fizičkog modela U ovim opcijama se nalaze infromacije kako se podaci iz fizičkog modela smeštaju u bazu i kako se iz baze reverznim inžinjeringom dobija fizički model. 17

Slika 13: Osnovni podaci o tabeli 18

Slika14: Kolone tabele Slika 15: Strani ključevi tabele 19

SQL DDL kod Za svaku tabelu može da se dobije SQL DLL skripta koja kreira tu tabelu. Ova opcija se nalazi u tabu Preview. Slika16: Osobine kolona 20

Slika 17: Osobine veze Slika 18: PDM nakon konverzije iz CMD 21

Slika 19: Predviđen broj instanci Razlika između fizičkog i konceptualnog modela Tabela Kolona Primarni ključ Entitet Atribut Identifikator CDM iz PDM-a Izmene u PDM modelu mogu da se prenesu i nazad na CDM tako što se uradi generisanje CDM iz PDM-a (opcija update). 22

SQL I DDL SQL - Structured Query Language - jezik za struktuirane upite, za manipulaciju podacima u RDBMS. DDL - Data Definition Language Jezik za definisanje (formalizovanje) podataka, predstavlja podskup SQL-a. Sada se skradenica koristi i za ostale jezike (ne samo SQL) koji se koriste u ovu svrhu. DDL Osnovna sintaksa za kreiranje nove tabele CREATE TABLE [SCHEMA.] <ime_tabele> ( def-kolone {, def-kolone} [, def-prim-kljuca] [, def-str-kljuca {, def-str-kljuca}] [, uslov-ogranicenja {, uslov-ogranicenja}] ) [ostali parametri] 23

Osnovna sintaksa za definiciju kolone: <ime_kolone> <tip_podatka> [DEFAULT <izraz>] [ogranicenje] Tipovi podataka (variraju u zavisnosti od RDBMS): Brojevi Znakovi Datum/vreme Numerički tipovi podataka Numerički tip u Oracle DB je NUMBER i definisan je sa dve dimenzije: Tačnost - koliko cifara maksimalno broj može sadržati Razmera - broj cifara desno od decimalne tačke <ime_kolone> NUMBER (tacnost [, razmera]) Primeri: br_indeksa NUMBER (3) cena NUMBER (7,2) MySQL koristi tipove: SMALLINT, INT i BIGINT za cele brojeve FLOAT, DOUBLE i DECIMAL za realne brojeve Znakovni tipovi podataka Ovi podaci se čuvaju kao serija bajtova, asocirana sa odgovarajudom kodnom stranom, za skladištenje alfanumeričkih podataka. Tipovi char - fiksna dužina <ime_kolone> CHAR (<velicina>) 24

varchar - varijabilna dužina <ime_kolone> VARCHAR (<max_velicina>) Datum i vreme Tipovi variraju u zavisnosti od RDBMS. MySQL podržava nekoliko osnovnih tipova: DATE datum YYYY-MM-DD TIME vreme HH:MM:SS DATETIME datum i vreme YYYY-MM-DD HH:MM:SS Primer Student CREATE TABLE Studenti ( BrIndeksa int, Ime varchar(50), Prezime varchar(50), Adresa varchar(255) ) Ova komanda de kreirati praznu tabelu Studenti. Primer 1 CREATE DATABASE projekat DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci; USE projekat; CREATE TABLE Komentar ( 25

ID ime bigint(20) AUTO_INCREMENT NOT NULL PRIMARY KEY, varchar(20) NOT NULL, prezime varchar(20) NOT NULL, email varchar(30) NULL, tekst varchar(250) NOT NULL, narudzbenica varchar(250) NOT NULL, adresa varchar(250) NOT NULL )DEFAULT CHARACTER SET utf8; Primer 2 CREATE DATABASE dj DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci; Use dj; CREATE TABLE Narudzbina ( ID bigint(20) AUTO_INCREMENT NOT NULL PRIMARY KEY, ime varchar(30) NOT NULL, prezime godiste tip datum varchar(30) NOT NULL, integer NOT NULL, varchar(20) NOT NULL, date NOT NULL, napomena varchar(1024) )DEFAULT CHARACTER SET utf8; Složeni primer CREATE DATABASE yoga DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci; Use yoga; create table Korisnik 26

( KORISNIK_ID KORISNIK_IME KORISNIK_PASS KORISNIK_ROLA bigint not null auto_increment, varchar(25) not null, varchar(25) not null, varchar(25) not null, KORISNIK_ACTIVE KORISNIK_USER KORISNIK_TS bool not null, varchar(30) not null, timestamp DEFAULT CURRENT_TIMESTAMP, primary key (KORISNIK_ID) ); create table Paket ( PAKET_ID YOGA_ID CENE_ID PAKET_SIFRA PAKET_NAZIV PAKET_OPIS PAKET_ACTIVE PAKET_USER PAKET_TS bigint not null auto_increment, bigint, bigint, varchar(4) not null, varchar(25) not null, varchar(4096), bool not null, varchar(30) not null, timestamp DEFAULT CURRENT_TIMESTAMP, ); primary key (PAKET_ID) 27

create table Cene ( CENE_ID CENE_POSEBNA bigint not null auto_increment, numeric(20,0) not null, CENE_MALPRODAJNA numeric(20,0) not null, CENE_DATUM CENE_ACTIVE CENE_USER CENE_TS date not null, bool not null, varchar(30) not null, timestamp DEFAULT CURRENT_TIMESTAMP, primary key (CENE_ID) ); create table TipYoge ( YOGA_ID YOGA_OZNAKA YOGA_OPIS YOGA_ACTIVE YOGA_USER YOGA_TS bigint not null auto_increment, varchar(25) not null, varchar(256), bool not null, varchar(30) not null, timestamp DEFAULT CURRENT_TIMESTAMP, primary key (YOGA_ID) ); alter table Paket add constraint FK_CENE_PAKET foreign key (CENE_ID) references Cene (CENE_ID) on delete restrict on update restrict; alter table Paket add constraint FK_YOGA_PAKET foreign key (YOGA_ID) references YOGA (YOGA_ID) on delete restrict on update restrict; 28

Postojeda baza podataka Vedina kompanija ved poseduje napunjene baze podataka nad kojima treba izvršiti neke izmene ili ih treba analizirati. Da bi se izvela ova operacija treba postojedu bazu uvudi u PowerDesigner i ova operacija se zove reverzni inženjering. Postojede baze podataka mogu da budu na razne načine kreirane i od raznih vendora, PD može da izvrši reverzni inženjering bez obzira na tip baze i njen sadržaj. Konfiguracija MySQL-a Reverzni inženjering de biti demnostriran na primeru MySQL baze podataka. Server: MySQL 5 Host: 192.168.120.255 Database name: art Port: 3306 Username: root Password: ******** Reverzni inženjering Odabrati opciju File Reverse Engineer Database Dodati naziv modela, odabrati DBMS (u ovom slučaju MySQL version 5). 29

Konekcija na Data Source Odabrati Data Source Kreirati new ODBC machine User ID i password Podrazumevani username za MySQL server je root Nema podrazumevani password za MySQL (prazno polje) Da bi napravili new connection odabrati Configure... Konfiguracija Data Connection Data connection može da bude: ODBC Machine Data Source ODBC File Data Source Connection Profile Da bi se napravila konekcija ka MySQL 30

Dodati Data source (Ctrl+N) Kreiranje novog Data Source-a 31

Slika 20: Konekcija 32

Testiranje konekcije Na dugme Test može da se testira konekcija ka bazi, ako je konekcija uspešna dobide se informacija o tome, odnosno poruka o grešci ako konekcija nije uspešno ostvarena. Konekcija na Data Source Nakon konfigurisanja ODBC-a, PD može da se poveže sa konkretnom bazom U dijalogu Connect to a Data Source odabrati ODBC machine data source, odabrati MySQL ODBC 5.1 Driver i uneti username i password. 33

Slika 21: Opcije reverznog inženjeringa Odabir tabela za reverzni inženjering Kada se PD nakači na MySQL server ponudide da uradi reverzni inžinjering svih tabela i baza sa servera kojima taj korisnik ima pristupa. Treba odabrati samo one koje u datom trenutku treba uvudi u PD. 34

Odabir ostalih objekata MySQL-a Osim tabela, baza podataka sadrži i druge opcije kao što su pogledi, trigeri, procedure, etc... Za svaki od ovih elemenata treba napraviti selekciju šta treba uvudi u PD. 35

Rezultat rada 11PD treba neko vreme da bi izvršio reverzni inženjering. Vreme rada zavisi od veličine baze i njene strukture. Kada se reverzni inženjering završi rezultat se vidi u browser prozoru, i na defaultom dijagramu. 36

Dijagram nakon reverznog inženjeringa Na default-nom dijagramu de biti prikazane sve tabele i ostali elementi. Za vede baze ovaj dijagram je obično suviše natrpan da bi bio upotrebljiv. Uvek nakon reverznog inžinjeringa treba uraditi analizu i kreiranje upotrebljivih dijagrama. Rezultat reverznog inženjeringa Svi podaci iz baze podataka su uvezeni u PowerDesigner. Svi objekti su prikazani na default-nom dijagramu i u browser prozoru. Svi strani ključevi su pretvoreni u veze između tabela Procedure su prikazane kao posebni objekti, nisu vezani za tabele. Trigeri nisu prikazani, ali se nalaze u tabelema i mogu da se vide kada se uđe u opcije tabele. 37