seminarski informacione tehnologije

UNIVERZITET U NOVOM SADUFAKULTET TEHNIČKIH NAUKA

Industrijsko inženjerstvo i menadžment

Projektovanje informacionih sistema Oracle Designer9i

S E M I N A R S K I R A D

Studenti: Profesor: Krsmanović dr Cvijan Asistent: Pržulj mr Đorđe

Projektovanje informacionih sistema


Informacioni sistemi primenjuju se u različitim delatnostima i zavisno od toga imaju svojekarakteristike.

Osnovni cilj primene informacionog sistema u poslovnom sistemu je kvalitetniji, efikasniji i racionalniji rad tog poslovnog sistema. Da bi se postigao taj cilj informacioni sistem sistem treba da bude zasnovan na jedistvenoj bazi podataka, podržanoj odgovarajućim sistemskim aplikativnim softverom.

Projektovanje informacionog sistema kao dela poslovnog sistema je posebno važno. Pod projektovanjem se podrazumevaju faze izgradnje, uvođenja, praćenja i dogradnje informacionog sistema.

Projektovanje informacionog sistema podrazumeva sledeće faze: Identifikacija i analiza objektnog sistema; Modeliranje baze podataka informacionog sistema; Modeliranje tehničke podrške informacionog sistema; Modeliranje organizacione i kadrovske podrške; Modeliranje programske podrške; Kratka studija pretpostavki pod kojima se informacioni sistem može

implementirati nad objektnim sistemom da bi funkcionisao.

Uvod u Oracle Designer9i

Zadatak koji će biti analiziran u ovom seminarskom radu, baziran je na izradi idejnog rešenja informacionog sistema za realni sistem, primenom CASE alata.

Alate koje smo koristili u našem zadatku porez na nekretnine su alati Oracle Designer –a 9i.

Oracle Designer je razvojno okruženje za modelovanje, projektovanje i generisanje klient/server baza podataka i aplikacija koje nad njima rade. Pošto je integrisan sa razvojnim alatima Oracle Forms i Oracle Reports, Oracle Designer pruža rešenje za razvoj poslovnih klient/server sistema novije generacije.

Podaci Oracle Designer-a se čuvaju u centralnom rečniku podataka (repozotoriju), i na taj način omogućavaju olakšan rad u projektnim timovima i samoupravljanje projektima.

Nakon konekcije na Oracle bazu podataka i izbora radne površine (workarea), pojavljuje se prozor razvojnog okruženja Oracle Designer koji omogućava pristup svim alatima i uslužnim programima koji su potrebni za modelovanje, projektovanje i generisanje poslovnih kompanijiskih aplikacija.

2


sl.1 Oracle Designer9i

Statusna linija na dnu prozora Oracle Designer-a prikazuje korisničko ime, naziv baze podataka koja je korišćena za konekciju na centralni rečnik podataka (repozitorijum) i naziv radnog prostora koji se koristi.

Faze projektovanja: 1. Data Flow Diagrammer dijagram toka podataka (najbitniji dijagram, koji

pokazuje gde podaci nastaju, gde idu - tok)2. Entity Relationship Diagrammer - entiteti, informacije u sistemu i veze

izmedju entiteta3. Function Hierararchy Diagrammer - dijagram hijerarhije funkcija u

realnom sistemu4. Server Data Model - na osnovu entity relationship dijagrama dobijamo

bazu podataka5. Aplication Model Diagrammer - specifikacija klijentske strane nasih

korisnika (sta korisnik vidi, upisuje, tzv. specifikacija)

3


Data Flow DiagrammeDijagram tokova podataka predstavlja grafički prikaz sistema, njegovih

komponenata i veza između njih. Ovakvi dijagrami olakšavaju način razumevanja protoka informacija u relanom sistemu.

Pre samog početka rada ovog projekta, potrebno se upoznati sa nekim pojmovima.Evidentiranje – predstavlja funkciju realnog sistema koja se može predstaviti kao radno mesto;Evidencija – podaci koji potiču iz funkcije. Najčešće se prestavlja kao spisak izlaznih podataka. U daljoj obradi ovog seminarskog rada, kao izlazne veličine funkcije koristiću termin depozit.

Podaci se trajno ili pak privremeno čuvaju u depozitu, odnosno skladištu podataka. Između depozita ne mogu postojati direktni tokovi podataka.

Inace, sve što se radi u ovom programu, pamti se u repozitorijumu, tako da u slučaju isecanja nekog toka (desni klik Cat), izbrisano mozete vratiti, tako sto se desnim klikom izabrati opciju INCLUDE -> Data Flow nakon cega se otvara prozor sa nazivom obrisanog sadržaja. Izaberemo ono sto želimo da vratimo na staro i OK.

Procesi u sistemu, tokovi podataka (veze), depoziti i spoljni entiteti se mogu prikazati dijagramom toka podataka, pomoću odgovarajućih simbola.

Simboli koji se koriste za funkcije, tokove, depozite i entitete nalaze se u gornjem lijevom uglu radne površine dataflow diagrama.

sl.2 Simboli Dataflow diagrammer

4

functionon

function

Tok podata

depozit spoljni entitet


sl.3 Dataflow diagrammer u kom su prikazane sve funkcije, depoziti, tokovi i spoljni entitei neophodni za proces naplate poreza na nekretnine

Za rešenjeovog zadatka potrebno nam je nekoliko funkcija, koje opisuju tok ili proces obavljanja naplate poreza, od početka. Konkretno, krćemo od samog objekta, ulice u kojoj se objekat nalazi, lice, koje je vlasnik objekta, prava, zaduzenje, uplate i analiza naplata.

Objekat - entitet u realnom sistemu ( vrednost, namena, lokacija, starost objekta, kvalitet gradnje) svi ovi parametri utiču na formiranje i donošenje odluke o tome koliki će porez biti.

Ulica - (naziv ulice, reon- više ulica) Lice - u čijem je vlasništvu, dal su to pravna ili fizuička lica (naziv, adresa, vrsta

lica) Pravo - šta moramo znati (za koji objekat i obim prava) Zaduženje - koliko je zaduženje (iznos, lice, objekat, datum i godina) Uplate - (iznos, lice i datum) Analiza naplate

5


Nakon toga utvrdili smo da su izlazni tokovi iz depozita, ulazni tokovi odredjenih funkcija. Npr.

1. evidentiranje prava kao funkcija ima sledece ulazne tokove: objekat, lice i stranka;

2. generisanje zaduženja ima sledece ulazne tokove: lice, objekat i prava;3. evidentiranje lica ima ulazne tokove samo od stranke;4. evidentiranje uplata ima ulazne tokove od: lica i izcod banke (kao

externog entiteta);5. analiza uplate ima sledece ulazne tokove: zaduženja, uplate i lica;6. evidentiranje objekata ima za ulazne podatke: ulica i stranka;7. evidentiranje ulice je jedina f-ja koja nema ulazne tokove.

Entity Relationship Diagrammer

Konceptualno projektovanje ima za cilj da proizvede model baze podataka koji je nezavistan od bilo kojeg SUBP. Zato se u toj fazi, za projektovanje eksternih i konceptualne šeme, koristi neki model podataka visokog nivoa. Pored te šeme u ovoj fazi se opisuju i budući postupci korišćenja baze podataka.

Projektant baze podataka, poštujući sve zahteve koji se postavljaju pred neki informacioni sistem za koji se baza projektuje treba da osmisli i prezentuje model podataka.

Postoji više modela podataka od kojih će se u daljem radu korisiti Chenov model entiteta poveznika (ER model).

Osnovni element ER modela je realni entitet, koji ima naziv (obavezno u jednini) i svoje karakteristike (atribute). Za atribute potrebno je definisati naziv atributa, da li je obavezan (označava se sa *) ili neobavezan (označava se sa o) i tip podataka. Nazivi atributa moraju biti jasni, a njihov kompletan opis sadrži i tip podataka, širinu polja, format itd.

Model entity relationship sastoji se od dva osnovna koncepta: Entitet – model subjekata i objekata u realnom sistemu i Poveznik – koji može biti minimalnog kardinalitet, maximalnog kardinalitet

i identifikacione zavisnosti.Simbol koji koristimo za prikazivanje ENTITETA je prikazan na slici. Na vrhu

simbola upisuje se ime tog entiteta, a u listu atributi, sa naznakom dal se radi o PRIMARNOM #, OBAVEZNOM * ili OPCIONOM o (neobaveznim) atributi.

sl.4 Simboli za predstavljanje entiteta u ER dijagramu

6

ULICA

#ID

*NAZIV

oREON


# Primarni ključ je minimalni skup atributa, čija vrijednost jednoznačno identifikuje pojavu entiteta. Ovaj ključ ne može se više puta pojaviti u više pojava entiteta. Primarni ključ moze biti I dva atributa I njihova kombinacija se ne može ponoviti. Jedna opaska NAZIV kao ime atributa, ne bi trebao nikada biti primarni ključ.

* Sekundarni ključ je skup atributa, koji su obavezni za unos.o Opcioni ključ je ona vrsta atributa, koji nisu obavezni za unos.Definisanje važnosti ključeva se obavlja u kartici atributt gde se pored tipa

važnosti ključa definiše i redosled, format, dužina atributa i decimale.

Poveznice između entiteta imaju nekoliko osobina: MINIMALNI KARDINALITET

0 – nemora; oznaka je isprekidana linija - - - - - - - - 1 – mora; oznaka je puna linija

MAXIMALNI KARDINALITET – može biti jedan ili više 1 – najviše 1; nema simbol

n – više; oznaka > IDENTIFIKACIONA ZAVISNOST – kada pojave jednog entiteta identifikujemo u

okviru drugog entiteta. Oznaka je I prava ctrta, koja se stavlja u koliko nemamo kljuc u nekom entitetu, crtu stavljamo na kao znak preuzimanja ključa iz drugih entiteta.

7


sl.5 Entity Relationship Diagrammer za proces naplate poreza na nekretnine

8


Function Hierarchy Diagrammer

Function Hierarchi Diagrammer, kao sastavni deo Oracle Designer-a 9i služi za predstavljanje hijerarhije funkcija, pri čemu svakoj funkciji se dodeljuju odgovarajući entiteti i atributi, kao i aktivnosti koje se nad njima mogu sprovoditi.

Elementarne funkcije posmatranog realnog sistema, koje su sadržane u glavnoj funkciji poslovanja ovog realnog sistema, tj. sistema za naplatu poreza na nekretnine su:

funkcija evidencije ulica, funkcija evidencije objekata, funkcija evidencije lice, funkcija evidencije prava, funkcija generisanje zaduženja, funkcija evidencije uplata, funkcija analize uplate.

sl.6 Function Hierarchy Diagrammer

Na dijagramu je moguće uočiti da je funkcija NPN naplata poreza na nekretnine upravo i funkcija najvišeg nivoa, dok su joj sve ostale podređene.

9


Entity usages:

Za svaku funkciju potrebno je odrediti koje entitete i atribute će uptrebljavati i na koji način. Ovo određuje Entity usages (uspostavljanje veze između funkcionalne hijerarhije i modela podataka).

Entiteti se mogu, u opštem slučaju: Kreirati (create), Pretraživati (retrieve), Menjati (update) i Brisati (delete).

Dok za atribute važi da se mogu: Unositi (insert), Pretraživati (retrieve), Menjati (update) i Brisati (delete).

Obeležja primarnog ključa se mogu samo unositi i pretraživati, obeležja stranog ključa smeju se samo pretraživati, a sva ostala obeležja se smeju unositi, pretraživati, menjati i brisati.

sl.7 Entity Usages za objekat sl.8 Entity Usages za ulicu

10


sl.9 Entity Usages za lice sl.10 Entity Usages za prava

sl.11 Entity Usages za generisanje zaduženja sl.12 Entity Usages za evidenciju uplate

11


sl.13 Entity Usages za analizu naplate

Server ModelPrevodjenje ER modela u relacioni model podataka vrši se pomoću Data Design

Transformmer-a, koji predstavlja implementacionu šemu baze podataka, na osnovu koje generišemo DDL (Data Definition Language) naredbe. Objekte u bazi podataka možemo kreirati pokretanjem ove naredbe.

Svaki pravougaonik predstavlja šemu relacije, a linije odgovarajuća ograničenja stranog ključa.

Server model prikazan na slici dobijen je korišćenjem alata Database Design Transformer. Database Design Transformer kreira i održava preliminarni dizajn baza podataka ili serverskih modela zasnovanih na modelima entiteta snimljenih u centralnom rečniku podataka.

Alat kreira tabele za skladištenje svakog entiteta, kolone za skladištenje obeležja i ograničenja za implementaciju relacija između entiteta.

Transformer obezbeđuje potpunu kontrolu nad definisanim opsegom procesa projektovanja. Alat omogućava da se izabere tip mapiranja entitet-tabela, detaljnost mapiranja i tipove elemenata koje proces kreira ili modifikuje. Moguće je i brzo kreiranje serverskih modela tako da najbolje odgovaraju traženim zahtevima. Serverski model se može razvijati kao celina ili kao više manjih delova.

12


sl.14 Server Model

13

seminarski informacione tehnologije

Documents