Designer 6 I

Wykorzystanie oprogramowania
Oracle Designer do budowy

systemw informatycznych
Bartosz B!bel, Krzysztof Jankiewicz
Instytut Informatyki, Politechnika Pozna"ska
Bartosz.Bebel@cs.put.poznan.pl
Krzysztof.Jankiewicz@cs.put.poznan.pl
(C) Instytut Informatyki, Politechnika Pozna"ska 2
Cykl #ycia systemu informacyjnego
Metodyka Oracle CASE (CASE*Method)
STRATEGIA
ANALIZA
PROJEKTOWANIE
IMPLEMENTACJA
WDRO!ENIE
EKSPLOATACJA
DOKUMENTACJA
Metodyka Oracle CASE
strategia
oglny
oglny
model
model
przedsi!biorstwa
przedsi!biorstwa
,
,
w
w
ymagania
ymagania
,
,
harmonogram prac
harmonogram prac
,
,
ograniczenia finansowe
ograniczenia finansowe
i
i
techniczne
techniczne
,
,
modele
modele
:
:
procesw
procesw
(PD),
(PD),
danych
danych
(ERD),
(ERD),
funkcji
funkcji
(FHD),
(FHD),
przep$yww
przep$yww
(DFD)
(DFD)
.
.
STRATEGIA
ANALIZA
PROJEKTOWANIE
IMPLEMENTACJA
WDRO!ENIE
EKSPLOATACJA
DOKUMENTACJA
analiza
uzupe$nienie informacji zebranych na etapie strategii,
szczeg$owe, zaakceptowane modele:
procesw
procesw
(PD),
(PD),
danych
danych
(ERD),
(ERD),
funkcji
funkcji
(FHD),
(FHD),
przep$yww
przep$yww
(DFD)
(DFD)
,
,
diagramy matrycowe.
STRATEGIA
ANALIZA
PROJEKTOWANIE
IMPLEMENTACJA
WDRO!ENIE
EKSPLOATACJA
DOKUMENTACJA
projektowanie
model danych,
struktura logiczna i fizyczna bazy danych,
modele aplikacji
(formularzy,
raportw, itp.)
STRATEGIA
ANALIZA
PROJEKTOWANIE
IMPLEMENTACJA
WDRO!ENIE
EKSPLOATACJA
DOKUMENTACJA
implementacja i dokumentacja
generacja, modyfikacja i testowanie aplikacji,
implementacja + strojenie,
dokumentacja
u#ytkownika i
techniczna.
STRATEGIA
ANALIZA
PROJEKTOWANIE
IMPLEMENTACJA
WDRO!ENIE
EKSPLOATACJA
DOKUMENTACJA
Cykl #ycia systemu informatycznego
Oracle Designer 6i
strategia strategia + + analiza analiza
projektowanie projektowanie
Implement Implementacja acja
dokumentacja dokumentacja
Metodyki realizacji projektw
informatycznych
Projektowanie SI z wykorzystaniem
Designer6i
narz!dzia do modelowania:
PD, ERD, FHD, DFD,
struktura logiczna bazy danych
(model relacyjny), definicje
aplikacji,
generowanie obiektw bazy
danych i kodu po stronie serwera,
generowanie aplikacji.
transformacje,
(C) Instytut Informatyki, Politechnika Pozna"ska %0
Metodyka RAD (Rapid
Application Development)
szybkie tworzenie
prototypw aplikacji,
modyfikowanie
prototypw zgodnie z
wymaganiami
u#ytkownikw,
tylko ma$e systemy,
krtki czas od
rozpocz!cia projektu do
chwili dostarczenia
aplikacji u#ytkownikowi.
(C) Instytut Informatyki, Politechnika Pozna"ska %%
Metodyka IE
(Information Engineering)
technika top-down,
g$wny nacisk na
model danych,
specyfikacja funkcji
przetwarzaj&cych
dane.
Metodyka PMD
(Process Model Driven)
cz!sto u#ywana jako
punkt pocz&tkowy dla
rozwoju systemw
informatycznych,
pozwala na identyfikacj!
podstawowych procesw
w organizacji przed
analiz& zakresu
informacji potrzebnej do
ich realizacji.
Metodyka DCD
(Design Capture Driven)
stosowana w przypadku
istnienia ju# systemw w
przedsi!biorstwie,
wykorzystuje mechanizmy
reverse-engineering,
pozwala na generowanie
nowych systemw korzystaj&c
ze starych definicji,
pozwala realizowa' nowe
potrzeby przedsi!biorstwa przy
minimalnych nak$adach
czasowych i finansowych.
Modelowanie procesw
Modelowanie procesw
Okre(la kolejno(' i miejsce realizacji funkcji
przedsi!biorstwa.
Umo#liwia i u$atwia komunikacj! pomi!dzy:
r#nymi dzia$ami firmy,
u#ytkownikami a projektantami,
projektantami a programistami.
Pozwala na zrozumienie funkcjonowania
organizacji.
Definicja zale#no(ci procesw
Zale#no(' procesu B od procesu A oznacza,
#e proces B nie mo#e si! rozpocz&' dopki
nie zako"czy si! proces A.
Powody zale#no(ci:
informacyjne,
produkcyjne,
prawne,
inne.
A B
Diagramy zale#no(ci procesw
(PD Process Diagram)
Struktura i zale#no(ci pomi!dzy jednostkami organizacyjnymi.
Zale#no(ci pomi!dzy procesami, sk$adnicami, wyzwalaczami i
wynikami.
Obiekty diagramu procesw
Jednostka
organizacyjna
Proces
Sk!adnica
Zale"no#$ Wyzwalacz
Wynik
Jednostka organizacyjna
(organization unit)
Okre(la miejsce realizacji
poszczeglnych procesw.
Mo#e dotyczy' jednostki organizacyjnej
lub osoby o okre(lonych
kompetencjach.
Proces (process)
Opisuje operacj! sk$adow& dzia$alno(ci
przedsi!biorstwa.
(C) Instytut Informatyki, Politechnika Pozna"ska 2%
Proces (process)
Rodzaje procesw:
operacja sk$adowa (process step),
punkt wprowadzania danych (data entry),
punkt decyzyjny (decision point),
raport (report),
zewn!trzny (external),
wewn!trzny (internal).
Przep$yw zale#no(' (flow)
Pokazuje przep$ywy informacyjne i
materia$owe oraz zale#no(ci czasowe
pomi!dzy procesami.
Czy przep$yw jest wystarczaj&cy do
rozpocz!cia realizacji procesu
przeznaczenia?
Warunek oraz cz!sto(' wyboru jednego z
wielu przep$yww wyj(ciowych przep$ywu
(dotyczy punktw decyzyjnych).
Typy przep$yww:
przep$yw (flow),
temporalny (temporal)
zale#no(' czasowa,
danych (data),
materialny (material).
Wyzwalacz (trigger)
Bodziec do podj!cia realizacji okre(lonych
procesw.
Typy wyzwalaczy:
okresowy (time),
systemowy
(system),
inny (other).
Sk$adnica (store)
Magazyn informacji (zbir relacji, arkuszy
kalkulacyjnych akt itp.), materia$w lub inny.
Sk$adnica (store)
Typy sk$adnic:
informacyjna (data store),
materialna (material store),
oglna (store).
Wynik (outcome)
Jest efektem realizacji sekwencji czynno(ci.
Typy wynikw:
okresowy (time),
systemowy
(system),
inny (other).
Process Modeler
Pozwala na:
definiowanie podstawowych procesw zachodz&cych w
przedsi!biorstwie,
modelowanie elementw sk$adowych procesw,
identyfikowanie procesw wymagaj&cych usprawnienia
modyfikacji,
modelowanie procesw nie istniej&cych w
przedsi!biorstwie,
w$&czanie do diagramw obiektw utworzonych w
innych sk$adnikach Oracle Designer6i.
Modelowanie elementw
sk$adowych procesw
Identyfikacja procesw
wymagaj&cych reorganizacji
Import istniej&cych obiektw
do diagramw
Modelowanie zwi&zkw encji
Modelowanie
zwi&zkw encji
Metoda okre(lania potrzeb informacyjnych firmy
lub organizacji.
Modelowanie zwi&zkw encji ma na celu:
Dostarczenie dok$adnego modelu potrzeb
informacyjnych przedsi!biorstwa, ktry stanowi$by
podstaw! do konstruowania nowych lub ulepszonych
systemw,
dostarczanie modelu niezale#nego od sposobu
przechowywania danych i metod dost!pu do nich,
umo#liwiaj&cego podejmowanie decyzji, dotycz&cych
metod implementacji oraz sposobu wsp$dzia$ania z
istniej&cymi systemami.
Diagramy zwi&zkw encji
Obiekty wyst!puj&ce na
diagramach zwi&zkw encji
Encja
Zwi%zki jeden do wiele
Zwi%zki wiele do wiele
Zwi%zki jeden
do jeden
Encja (entity)
Encja obiekt rzeczywisty lub niematerialny
maj&cy znaczenie dla organizacji, o ktrym
informacje musz& by' przechowywane.
Encja (entity)
Ka#da encja musi by' jednoznacznie
identyfikowalna to znaczy, #e ka#da instancja
(wyst&pienie) encji musi by' wyra)nie
odr#nialna od wszystkich innych instancji tego
typu encji. Uzyskuje si! to poprzez definicj!
jednoznacznego identyfikatora.
Unikalny identyfikator
(unique identifier)
Unikalny identyfikator to zbir atrybutw,
ko"cw
zwi&zkw lub
zwi&zkw
wykluczaj&cych,
ktrych warto(ci
pozwalaj&
rozr#ni'
instancje encji.
Atrybut (attribute)
Atrybut cecha s$u#&ca do identyfikacji,
klasyfikacji lub wyra#enia stanu encji.
Atrybut (attribute)
Warto(ci jakie mog& by' przyjmowane przez
atrybuty s& ograniczane przez typ, wielko(',
i zbir warto(ci dopuszczalnych.
Zwi&zek (relationship)
Zwi&zek nazwane, istotne powi&zanie
pomi!dzy encjami.
Ka#dy zwi&zek ma dwa ko"ce, z
ktrych ka#dy ma przypisan&:
nazw!,
stopie"/liczebno(',
opcjonalno(' (opcjonalny/wymagany).
ZESP"
INSTYTUT
Wiele
Jeden
Wymagany
Opcjonalny
Zwi%zek
rekurencyjny
sk!adow%
z!o"ony z
Nazywanie zwi&zkw
Ka!dy INSTYTUT mo!e by" z#o!ony z jednego lub wielu ZESPO$W.
Ka!dy ZESP$ musi by" sk#adow% jednego i tylko jednego INSTYTUTU.
Dziedzina (domain)
Zbir regu$ kontroli poprawno(ci danych,
ich formatw, i innych w$asno(ci
stosowanych do definicji atrybutw.
Dziedzina (domain)
Warto(ci dopuszczalne zdefiniowane w ramach
domen b!d& wp$ywa$y na zawarto(' relacji
CG_REF_CODES.
Konstrukcje specjalne
Zwi&zki wykluczaj&ce
Hierarchie encji
Zwi&zki nieprzechodnie
Zwi&zki wykluczaj&ce
Wyst!puj& w postaci $uku $&cz&cego dwa (lub wi!cej)
ko"ce zwi&zkw dochodz&cych do tej samej encji.
Opisuj& sytuacje kiedy dla pojedynczej instancji encji
mo#e wyst&pi' tylko jeden ze zwi&zkw wykluczaj&cych.
Pracownik zatrudniony jest
albo na poziomie instytutu,
albo na poziomie zespo#u.
lub (precyzyjnie)
Ka!dy Pracownik musi by"
albo zatrudniony w jednym i
tylko jednym instytucie
albo zatrudniony w jednym i
tylko jednym zespole.
Tworzenie zwi&zku
wykluczaj&cego
Hierarchie encji
Hierarchie encji sk$adaj& si! z encji-nadtypu i zawartych w
niej encji-podtypw.
Podtyp oprcz swoich w$asnych atrybutw i zwi&zkw,
posiada wszystkie atrybuty, zwi&zki i funkcje dziedziczone
z encji-nadtypu.
Zwi&zki nieprzechodnie
Oznaczane s& za pomoc& rombu przy jednym z ko"cw
zwi&zku.
Instancja encji, przy ktrej istnieje zwi&zek nieprzechodni
nie mo#e zmienia' przypisania do innej instancji encji
wynikaj&cego z tego zwi&zku.
Zesp# raz przypisany
do okre&lonego
instytutu nie mo!e
zosta" przeniesiony
do innego instytutu
(nie mo!e zmieni"
przypisania).
Entity Relationship
Diagrammer
Jest narz!dziem s$u#&cym do modelowania i
definiowania potrzeb informacyjnych w
postaci diagramw zwi&zkw encji.
Pozwala na:
tworzenie diagramw zwi&zkw encji,
automatyczny rozk$ad obiektw na diagramie,
dost!p do narz!dzi systemu Oracle Designer
powi&zanych i weryfikuj&cych zwi&zki encji.
Modelowanie
przep$yww danych
Modelowanie
przep$ywu danych
Modelowanie przep$ywu danych (ang.
Dataflow Diagrams) ma na celu
zobrazowanie procesw zachodz&cych w
organizacji, wymiany informacji mi!dzy
nimi oraz miejsc wprowadzania i
wyprowadzania danych.
Diagramy przep$ywu danych
Opisuj& przep$yw informacji pomi!dzy
funkcjami procesami realizowanymi w systemie.
Reprezentuje wymian! danych mi!dzy elementami
systemu i wymian! danych ze (wiatem zewn!trznym.
Diagramy przep$ywu danych
S& podstawowym narz!dziem do wi&zania procesw z
przetwarzanymi danymi.
Na oglnym poziomie specyfikacji procesw pozwalaj&
wyznaczy' funkcje elementarne oraz te, ktre wymagaj&
dalszej dekompozycji.
Stanowi& podstaw! do specyfikacji aplikacji.
Nie opisuj& algorytmu przetwarzania danych wewn&trz
funkcji.
Nie opisuj& zale#no(ci czasowych i kolejno(ciowych
pomi!dzy funkcjami.
Odzwierciedlaj& pojedyncze procesy zaznaczaj&c udzia$ i
rol! ich poszczeglnych sk$adowych.
Obiekty diagramw
przep$yww danych
Proces funkcja
Przep!yw
Sk!adnica danych
Byt zewn&trzny
Sk$adnica danych
(datastore)
Sk$adnica danych kolekcja encji i ich atrybutw,
ktre powinny by' przechowywane przez
okre(lony czas.
Etykieta Nazwa opisowa
Sk$adnica danych
Typy sk$adnic danych:
komputerowe (computer),
papierowe (manual),
inne (transient).
Przep$yw danych
(dataflow)
Przep$yw danych jest nazwan& kolekcj& encji i ich
atrybutw przekazywanych mi!dzy dwoma
procesami, procesem a sk$adnic& lub procesem a
bytem zewn!trznym.
Przep$yw danych
(dataflow)
Przep$yw danych jest chwilowym przeniesieniem danych.
Gdy osi&gn& one cel
(proces) decyzja o tym
co si! z nimi dalej
stanie zale#y od procesu
przyjmuj&cego.
Je(li odbiorca zignoruje
nadchodz&ce dane
zostan& one
utracone na zawsze.
Przep$yw danych a sk$adnica
Gdy przep$yw danych dotrze do sk$adnicy danych,
jej zawarto(' jest modyfikowana zawarto(ci&
przep$ywu. Mo#e to oznacza' dodanie,
modyfikacj! lub usuni!cie danych znajduj&cych
si! w sk$adnicy.
Sk$adnica danych s$u#y do przechwytywania na
sta$e chwilowego przep$ywu danych.
Proces (function)
Opisuje
sk$adow&
dzia$alno(ci
przedsi!-
biorstwa.
Przep$yw danych a proces
Zawarto(' przep$ywu wychodz&cego z funkcji uzupe$nia
zawarto(' ENTITY USAGES dla tej funkcji.
Zawarto(' przep$ywu
wchodz&cego do
funkcji nie ma wp$ywu
na ENTITY USAGES.
Zawarto('
ENTITY USAGES dla
funkcji nie ma #adnego
wp$ywu na zawarto('
przep$yww zwi&zanych
z t& funkcj&.
Byt zewn!trzny
(external)
Obiekt b!d&cy zewn!trznym (poza systemem)
)rd$em lub odbiorc& informacji.
Mo#e reprezentowa' okre(lon& encj! lub
jednostk! organizacyjn&.
Dataflow Diagrammer
Narz!dzie s$u#&ce do rysowania diagramw
przep$yww danych. Pozwala na:
jednoczesn& wsp$prac! wielu u#ytkownikw,
automatyczny rozk$ad elementw,
dost!p do narz!dzi weryfikuj&cych kompletno('
wykorzystania encji
przez funkcje,
przechodzenie do
sk$adowych procesw lub
procesw znajduj&cych
si! wy#ej w hierarchii.
Modelowanie hierarchii funkcji
Modelowanie
hierarchii funkcji
Modelowanie hierarchii funkcji tworzy diagramy
pokazuj&ce dekompozycj! funkcji na r#nych poziomach
dzia$alno(ci przedsi!biorstwa.
Funkcja (function)
Sk$adowa operacja
przedsi!biorstwa.
Funkcje
specjalnego znaczenia
Funkcje wsplne (common function).
Funkcje atomowe (atomic function)
funkcje, ktre nie podlegaj& dalszej
dekompozycji.
Funkcje elementarne (elementary function).
Funkcje atomowe
Funkcje wsplne
Wyst!puj& w kilku miejscach w hierarchii reprezentuj&c t&
sam& operacj!.
Pierwsze wyst&pienie takiej funkcji nazwane jest funkcj&
g$wn& (master function), pozosta$e wyst&pienia to tylko
referencje do funkcji g$wnej.
Funkcje wsplne
Funkcja g!wna
Funkcje elementarne
Funkcje elementarne pozostawiaj& system
w stanie spjnym, wykonanie funkcji
elementarnej, nie b!d&cej funkcj& atomow&,
wymaga pomy(lnej realizacji wszystkich jej
funkcji podrz!dnych.
Function
Hierarchy Diagrammer
Pozwala na utworzenie diagramu hierarchii
funkcji realizowanych przez organizacj!.
Umo#liwia:
tworzenie, modyfikacj! i dekompozycj! funkcji,
automatyczne tworzenie podzbiorw du#ych i
z$o#onych hierarchii,
okre(lanie sposobu wykorzystania danych przez
funkcje,
zwijanie i rozwijanie ga$!zi hierarchii,
automatyczn& zmian! uk$adu funkcji (pionowy,
poziomy, hybrydowy).
Repozytorium
Oracle Designer 6i
Repozytorium
Oracle Designer 6i
Repozytorium Oracle Designer 6i jest
miejscem sk$adowania wszelkich obiektw
tworzonych na diagramach.
Dzi!ki repozytorium obiekty utworzone np.
na diagramie zale#no(ci procesw mo#na
importowa' do pozosta$ych diagramw.
Repository
Object Navigator
S$u#y do przegl&dania i modyfikacji
obiektw sk$adowanych w
repozytorium
Oracle Designer6i.
Dla ka#dego
obiektu dost!pna
jest lista w$asno(ci.
Zale#no(ci pomi!dzy diagramami
Zale#no(ci pomi!dzy diagramami
Wszystkie trzy metody modelowania
procesw i funkcji, tj. konstrukcja
diagramw zale#no(ci procesw,
modelowania przep$yww danych i
tworzenie hierarchii funkcji przenikaj& si!
wzajemnie operuj&c na tych samych
obiektach.
Funkcje procesy
Sk$adnice danych
Przep$ywy
Hierarchie funkcji
Sposoby i wskazwki dotycz&ce
tworzenia diagramw i modeli
Poziomy modelowania systemu
informatycznego
Poziom przedsi!biorstwa dotyczy podstawowych
obszarw dzia$alno(ci przedsi!biorstwa.
Poziom systemu wyznacza sposb, w jaki wymagania
przedsi!biorstwa s& lub mog& by' realizowane. Funkcje na
tym poziomie pokazuj& czynno(ci pracownikw.
Poziom programu pokazuje sposb fizycznej realizacji
funkcji systemu przez okre(lone mechanizmy
komputerowe, biurowe itp. Funkcje na tym poziomie
pokazuj& elementarne operacje.
Wykorzystanie metod
modelowania
M Me et to od dy y
m mo od de el lo ow wa an ni ia a
P Po oz zi io om m
p pr rz ze ed ds si i# #b bi io or rs st tw wa a
P Po oz zi io om m s sy ys st te em mu u
P Po oz zi io om m
p pr ro og gr ra am mu u
H Hi ie er ra ar rc ch hi ia a
f fu un nk kc cj ji i
P Po od ds st ta aw wo ow wa a P Po od ds st ta aw wo ow wa a P Po od ds st ta aw wo ow wa a
D Di ia ag gr ra am m
z za al le e" "n no o# #c ci i
p pr ro oc ce es s w w
O Op pc cj jo on na al ln na a P Po od ds st ta aw wo ow wa a O Op pc cj jo on na al ln na a
D Di ia ag gr ra am my y
p pr rz ze ep p! !y yw w w w
d da an ny yc ch h
O Op pc cj jo on na al ln na a P Po od ds st ta aw wo ow wa a O Op pc cj jo on na al ln na a

Podstawowe podej(cia przy
modelowaniu funkcji
Modelowanie z gry do do$u polega na
dekompozycji kolejnych poziomw
rozpoczynaj&c od pojedynczej funkcji g$wnej
reprezentuj&cej dzia$alno(' przedsi!biorstwa.
Modelowanie z do$u do gry na pocz&tku
identyfikuje si! funkcje przedsi!biorstwa, a
nast!pnie dla ka#dej z nich prbuje si! znale)'
odpowiednie miejsce w hierarchii funkcji.
Technika mieszana.
Kiedy zako"czy'
dekompozycj! funkcji?
Metoda funkcji
elementarnych:
Hierarchia funkcji jest
traktowana jako kompletn&,
je#eli przej(cie od funkcji
g$wnej do funkcji atomowych
mo#liwe jest tylko przez
funkcje elementarne.
Mechanizmy
Powi&zania okre(lonych funkcji ze sposobem ich
realizacji.
Typy mechanizmw:
my(lowy,
komputerowy,
mechaniczny,
r!czny.
Unikanie mechanizmw w nazwach i opisach funkcji
pozwala budowa' modele bardziej oglne. Pobudza do
reorganizacji, usprawniania lub wprowadzania nowych
metod realizacji okre(lonych zada".
Tworzenie modeli
informacyjnych
Warunkiem tworzenia poprawnych i
efektywnych modeli informacyjnych jest
stosowanie okre(lonych konwencji i zasad.
Nie dopuszczaj& one do powstawania
niejednoznaczno(ci i u$atwiaj& zrozumienie
potrzeb informacyjnych przedsi!biorstwa.
Zasady dotycz&ce encji
!Ka#da instancja encji musi by' wyra)nie
odr#nialna od wszystkich innych instancji tej
encji.
Ka#da encja powinna:
!by' zwi&zana co najmniej jednym zwi&zkiem,
!posiada' co najmniej dwa atrybuty,
!by' wykorzystywana przez co najmniej jedn& funkcj!,
po zako"czeniu etapu analizy by' kompletna
informacyjnie.
Zasady dotycz&ce zwi&zkw
Nazwy pojawiaj&ce si! na ko"cach zwi&zkw powinny
tworzy' poprawne konstrukcje zdaniowe z
poprzedzaj&cymi je zwrotami musi by' dla zwi&zkw
wymaganych lub mo#e by' dla zwi&zkw
opcjonalnych.
Zwi&zek nie mo#e wchodzi' w sk$ad wi!cej ni#
jednego $uku.
Ka#dy zwi&zek po zako"czeniu etapu analizy powinien
by' kompletny informacyjnie.
Nieprawid$owe zwi&zki
Zasady dotycz&ce atrybutw
Nazwy atrybutw nie powinny zawiera' w sobie nazw
encji.
*ci(le nale#y trzyma' si! regu$ normalizacji danych. W
uproszczeniu oznacza to, #e:
w encji nie mog& powtarza' si! atrybuty, warto(ci atrybutw
powinny by' atomowe,
warto(' ka#dego atrybutu powinna zale#e' od ca$o(ci
jednoznacznego identyfikatora,
warto(ci atrybutw powinny zale#e' tylko od jednoznacznego
identyfikatora.
Po zako"czeniu etapu analizy ka#dy z atrybutw powinien
by' informacyjnie kompletny.
Zasady dotycz&ce zwi&zkw
wykluczaj&cych
+uk musi obejmowa' co najmniej dwa ko"ce
zwi&zkw, a zwykle nie wi!cej ni# trzy lub cztery.
+uki prawie zawsze rysuje si! wok$ ko"cw
wiele zwi&zkw.
Je(li jeden koniec zwi&zku, b!d&cego cz!(ci&
jednoznacznego identyfikatora encji, znajduje si!
w $uku, wwczas ka#dy inny koniec zwi&zku w
tym $uku musi by' rwnie# cz!(ci&
jednoznacznego identyfikatora dla tej encji.
Niepoprawne zwi&zki
wykluczaj&ce
+uki mog& dotyczy' ko"cw zwi&zkw, ktre
albo wszystkie s& obowi&zkowe, albo wszystkie
opcjonalne.
+uki nie mog& obejmowa' zwi&zkw dotycz&cych
r#nych encji.
Regu$y rozmieszczania elementw
na diagramie zwi&zkw encji
Ko"ce zwi&zkw wiele umieszcza si! na grze
lub po lewej stronie, dzi!ki temu obiekty o du#ym
znaczeniu, s$u#&ce do opisywania innych
obiektw, s& grupowane i znajduj& si! na dole po
prawej stronie diagramu.
Na diagramach rozmiar i kszta$t encji nie jest
istotny wszystko ma s$u#y' przejrzysto(ci i
czytelno(ci diagramu.
Zamiana zwi&zkw wiele do wiele
Historyczno('
REZERWACJA
# * status
* data
REZERWACJA
# * data
STATUS
# * warto#$
# * od dnia
do dnia
Encja intersekcji
Encje referencyjne
Budowanie bazy danych
Dane wej(ciowe
Diagramy zwi&zkw encji, a w szczeglno(ci:
definicje encji wraz z atrybutami
definicje zwi&zkw mi!dzy encjami
definicje dziedzin atrybutw encji
Wynik
Baza danych projektowanego systemu
Przebieg procesu
krok %. Transformowanie diagramw
zwi&zkw encji do schematu
logicznego bazy danych
krok 2. Generowanie schematu fizycznego
bazy danych
krok %.
Transformowanie diagramw zwi&zkw
encji do schematu logicznego bazy
danych
(C) Instytut Informatyki, Politechnika Pozna"ska %0%
Regu$y transformacji
Jak przetransformowa':
encj!?
hierarchi! encji?
zwi&zek?
Transformacja encji
Encja " relacja
Atrybut encji " kolumna relacji
Typ atrybutu " typ kolumny
Dziedzina atrybutu " ograniczenie check
Unikalny identyfikator encji " klucz
podstawowy relacji
Transformacja hierarchii encji
Sposoby:
transformacja do pojedynczej relacji
transformacja do oddzielnych relacji
transformacja do oddzielnych relacji
po$&czonych ograniczeniami
referencyjnymi w $uku
Sposb pierwszy
Zasady:
jedna relacja
schemat relacji: atrybuty wszystkich encji z
hierarchii + dodatkowa kolumna, okre(laj&ca
typ specjalizacji
Kiedy stosowa':
wi!kszo(' atrybutw w nadtypie
wi!kszo(' zwi&zkw do nadtypu
Zalety:
uproszczenie schematu bazy danych
Wady:
atrybuty obowi&zkowe podtypu staj& si! kolumnami
opcjonalnymi
Transformacja hierarchii
Sposb drugi
Zasady:
jedna relacja dla ka#dego podtypu
schemat relacji: atrybuty nadtypu + atrybuty
podtypu
Kiedy stosowa':
wi!kszo(' atrybutw w podtypach
wi!kszo(' zwi&zkw do podtypw
Zalety:
zachowanie obowi&zkowo(ci atrybutw w
podtypach
Wady:
komplikacja schematu
konieczno(' powielenia kluczy obcych implementuj&cych
zwi&zki przy$&czone do nadtypu
Sposb trzeci
Kiedy stosowa':
zwi&zki przywi&zane zarwno do nadtypu jak
i podtypw
Zalety:
zachowanie obowi&zkowo(ci atrybutw
w podtypach
$atwy dost!p do informacji z nadtypu
Wady:
komplikacja schematu
konieczno(' stosowania
po$&cze" (SQL)
Zasady:
jedna relacja z atrybutami wsplnymi, dla ka#dego podtypu
osobna relacja z jego atrybutami specyficznymi
relacje po$&czone kluczami obcymi w $uku
Transformacja zwi&zkw
Implementacja zwi&zku za pomoc&
ogranicze" referencyjnych (kluczy obcych)
Sposb transformacji zale#y od parametrw
zwi&zku:
krotno(ci (%:%, %:N, M:N)
obowi&zkowo(ci/opcjonalno(ci
Zwi&zek %:% jednostronnie
obowi&zkowy
Zasady:
do relacji impl. encj! wi&zan&
obowi&zkowo zostaje dodany
klucz obcy, wskazuj&cy na
klucz podstawowy relacji
impl. encj! wi&zan&
opcjonalnie (z drugiej strony
zwi&zku)
na kolumny klucza obcego
zostaje na$o#one ograniczenie
not null
Transformacja zwi!zkw
TABLICA_A (
ID_A PRIMARY KEY,
ATR_% NULL)
TABLICA_B (
ID_B PRIMARY KEY,
ATR_% NOT NULL
ID_A NOT NULL REFERENCES
TABLICA_A(ID_A))
Zwi&zek %:% obustronnie
opcjonalny
Zasady:
do relacji impl. t& encj! ze zwi&zku, dla ktrej okre(lono wi!kszy
(redni przyrost wyst&pie", zostaje dodany klucz obcy, wskazuj&cy
na klucz podstawowy z relacji impl. drug& encj! w zwi&zku
na kolumny klucza obcego na$o#one zostaje ograniczenie null
(C) Instytut Informatyki, Politechnika Pozna"ska %%0
Zwi&zek %:N
Zasady:
do relacji impl. encj! po stronie N
zwi&zku zostaje dodany klucz
obcy, wskazuj&cy na klucz
podstawowy relacji impl. encj! po
stronie % zwi&zku
obowi&zkowo(' zwi&zku po
stronie N - ograniczenie not null
na kolumny w kluczu obcym
opcjonalno(' zwi&zku po stronie
N - ograniczenie null na
kolumny w kluczu obcym
obowi&zkowo('/opcjonalno('
zwi&zku po stronie % nie ma
wp$ywu na transformacj!
TABLICA_A (
ID_A PRIMARY KEY,
ATR_% NULL
ID_B NOT NULL REFERENCES
TABLICA_B(ID_B))
TABLICA_B (
ID_B PRIMARY KEY,
ATR_% NOT NULL)
(C) Instytut Informatyki, Politechnika Pozna"ska %%%
Zwi&zek M:N
Zasady:
zostaje utworzona nowa
relacja
w nowej relacji zostaj&
utworzone klucze obce,
wskazuj&ce na klucze
podstawowe relacji w
zwi&zku
kolumny obu kluczy obcych
tworz& klucz podstawowy
relacji
TABLICA_A (
ID_A PRIMARY KEY,
ATR_% NULL)
TABLICA_B (
ID_B PRIMARY KEY,
ATR_% NOT NULL)
TABLICA_A_B (
ID_A NOT NULL REFERENCES
TABLICA_A(ID_A),
ID_B NOT NULL REFERENCES
TABLICA_B(ID_B),
PRIMARY KEY(ID_A, ID_B))
Proces transformacji
Krok %.
Uruchomi' narz!dzie Database Design
Transformer z grupy Transform Preliminary
Designs
Krok 2 - opcje transformacji
transformacja wg
ustawie" domy(lnych
transformacja wg
ustawie"
u#ytkownika
Dost!pne ustawienia
wybr encji do transformacji - domy(lnie
wszystkie
sposb transformacja hierarchii -
domy(lnie do jednej relacji
wybr typw tworzonych elementw
(relacje, kolumny, klucze, indeksy) -
domy(lnie wszystkie
wybr typw modyfikowanych elementw
(istniej&cych ju# w repozytorium relacji,
kolumn, kluczy, indeksw) - domy(lnie
#adne
Dost!pne ustawienia (2)
opcje ogranicze" referencyjnych:
usuwanie kaskadowe - domy(lnie zabronione
modyfikowanie kaskadowe - domy(lnie
zabronione
tworzenie sztucznych kluczy podstawowych
relacji (w postaci dodatkowej kolumny
numerycznej) - domy(lnie tylko dla encji bez
unikalnych identyfikatorw
przedrostek nazw relacji - domy(lnie brak
przedrostki nazw kolumn (na podstawie
krtkich nazw encji) - domy(lnie brak
Krok 3 - uruchomienie procesu
Uruchomienie
transformacji -
przycisk Run
Wynik
Umieszczone repozytorium systemu definicje:
relacji
kolumn
ogranicze" integralno(ciowych
indeksw
licznikw - dla sztucznych kluczy
podstawowych
Wynik (2)
Podgl&d definicji w repozytorium - narz!dzie
Design Editor z grupy Design and Generate
Design Editor
Umo#liwia:
przegl&danie i r!czn& modyfikacj! powsta$ego w wyniku
transformacji schematu logicznego bazy danych
definiowanie dodatkowych obiektw schematu logicznego:
licznikw
perspektyw
kodu PL/SQL
utworzenie diagramu schematu modelu relacyjnego -
pokazuje po$&czenia mi!dzy relacjami (ograniczenia
referencyjne)
Przegl&danie i modyfikacja
schematu logicznego
Zak$adka Server Model, ga$!zie:
Design Editor
Relational Table
Definitions - relacje,
kolumny, ograniczenia
itegralno(ciowe, inne
Relational View
Definition - perspektywy
Sequence Definitions -
liczniki
PL/SQL Definitions -
kod sk$adowany
Tworzenie diagramu
schematu logicznego
Z menu kontekstowego
wybra' Show on New
Diagram
Design Editor
Zaznaczy' obiekty (relacje lub perspektywy), ktre maj& by'
uwidocznione na diagramie
Przyk$adowy diagramu
schematu logicznego
Design Editor
Jak to zrobi'?
Jak przetransformowa' hierarchi! encji w
sposb inny ni# domy(lny?
Transformacja do oddzielnych relacji
krok %. Uruchomi' Database Design Transformer
krok 2. Zaznaczy' opcj! Customize the Database
Transformer i wybra' zak$adk! Table Mappings
Jak to zrobi" - hierarchia encji
krok 3. Zmieni' zbir encji do transformacji -
wy$&czy' ze zbioru encj!-nadtyp, doda' encje-
podtypy
krok 4. Przyst&pi' do transformacji
Wynik:
Transformacja do relacji w $uku
krok %. Uruchomi' Database Design Transformer
krok 2. Zaznaczy' opcj! Customize the Database
Transformer i wybra' zak$adk! Table Mappings
krok 3. Zmieni' zbir encji do transformacji - w$&czy'
do zbioru encj!-nadtyp wraz z encjami-podtypami
krok 4. Zmieni' typ elementw do transformacji -
zak$adka Run Options - tylko definicje relacji (bez
kolumn i ogranicze" integralno(ciowych)
krok 5. Uruchomi' transformacj!. Wygenerowane
zostan& jedynie definicje relacji. Pozosta' w
narz!dziu
krok 6. Przy encjach-podtypach zaznaczy' opcj! Arc
krok 7. Zmieni' typ elementw do transformacji -
zak$adka Run Options - wszystkie elementy
krok 8. Przyst&pi' do transformacji
Wynik:
krok 2.
Generowanie schematu fizycznego
bazy danych
Przebieg procesu
krok %. Uruchomi' narz!dzie Design Editor. Przej('
na zak$adk! Server Model, rozwin&' ga$&)
systemu aplikacji
Generacja bazy danych
krok 2. Wybra' pozycj!
Generate Database from
Server Model z menu
Generate
Przebieg procesu
krok 3. Ustali' parametry generacji - zak$adka Target:
Cel generacji:
skrypty DDL (r#ne
formaty)
wskazany u#ytkownik
bazy danych Oracle
baza danych ODBC
Lokalizacja skryptw
Przebieg procesu
krok 4. Wybra' obiekty do generacji - zak$adka Objects:
Typ obiektu:
relacje
liczniki
perspektywy i inne
Konkretny obiekt
Przebieg procesu
krok 5. Uruchomi' proces - przycisk Start
Wynik - w zale#no(ci od parametrw generacji:
skrypty DDL we wskazanym katalogu
obiekty w schemacie wskazanego u#ytkownika
obiekty w bazie danych przy$&czonej za pomoc&
ODBC
Budowanie aplikacji
Dane wej(ciowe
Diagramy hierarchii funkcji i przep$yww danych,
a w szczeglno(ci:
definicje funkcji
sposb u#ycia encji przez funkcje
przep$ywy z i do funkcji
Wynik
Definicje aplikacji w wybranym j!zyku
programowania
Przebieg procesu
krok %. Transformowanie definicji funkcji do
projektw aplikacji
krok 2. Modyfikacja struktury aplikacji
krok 3. Generowanie aplikacji w wybranym
j!zyku programowania
Budowanie aplikacji
krok %.
Transformowanie definicji funkcji do
projektw aplikacji
Regu$y transformacji
%. Ktre funkcje transformowa'?
2. Co wp$ywa na wybr typu aplikacji, ktra
powstanie z funkcji?
3. Jak znale)' funkcje, ktre mog& by'
zaimplementowane przez t& sam& aplikacj!?
- $&czenie funkcji
Ktre funkcje transformowa'?
Regu#y transformacji
Kandydatami do transformacji s&:
li(cie hierarchii bez przodkw, b!d&cych
funkcjami elementarnymi lub wsplnymi
funkcje wsplne
funkcje elementarne
Ktre funkcje transformowa'?
Co wp$ywa na typ aplikacji?
Typy aplikacji:
formularz (ang. Screen) - odczytuje i modyfikuje dane
z relacji
wydruk (ang. Report) - tylko odczytuje dane z relacji
aplikacja u!ytkowa (ang. Utility) - mo#e to by'
biblioteka, funkcja i procedura sk$adowana, pakiet
Co wp$ywa na typ aplikacji? (2)
Jak okre(li' typ aplikacji?
na podstawie zestawu
operacji, jakie
transformowana funkcja
realizuje na encjach
na podstawie w$asno(ci
Reakcja (ang. Response)
funkcji (ang. Immediate -
Natychmiastowa, ang.
Overnight - Odroczona)
Co wp$ywa na typ aplikacji? (3)
Zasady:
encje, ktrych u#ywa funkcja, nie zosta$y zaimplementowane jako
relacje - typ aplikacji nieokre(lony (musi zosta' wskazany przez
projektanta)
w$asno(' Reakcja okre(lono na Natychmiastowa - typ aplikacji to
formularz
funkcja realizuje tylko operacje odczytu na encjach,
zaimplementowanych jako relacje - typ aplikacji to wydruk,
w$asno(' Reakcja okre(lono na Odroczona - typ aplikacji to
aplikacja u#ytkowa
w pozosta$ych przypadkach - typ aplikacji to formularz
+&czenie funkcji
Kryteria:
$&cz funkcje przetwarzaj&ce ten sam zestaw encji
$&cz funkcje przetwarzaj&ce ten sam zestaw encji
i wykonuj&ce ten sam zestaw operacji na encjach
$&cz funkcje u#ywaj&ce tych samych atrybutw encji
Krok %.
Uruchomi' narz!dzie Application Design
Transformer z grupy Transform Preliminary
Designs
Krok 2. - ustawienie parametrw
wybr funkcji w hierarchii, od ktrej rozpocznie si!
transformacja - Start Function
przedrostek nazwy aplikacji - Module Prefix
pocz&tkowy numer - b!dzie tworzy$ nazw! aplikacji w
po$&czeniu z przedrostkiem - Start number
domy(lne j!zyki implementacji aplikacji
poszczeglnych typw - Language (np. Oracle Forms,
Oracle Reports, Visual Basic, itd.)
kryteria $&czenia funkcji - Merge Granularity
Krok 3. - uruchomienie procesu
Uruchomienie transformacji - przycisk Generate
Wynik
Umieszczone w repozytorium systemu
definicje modu$w-
kandydatw na aplikacje
Przegl&danie struktury -
Design Editor, zak$adka
Modules, ga$&) Modules
Budowanie aplikacji
krok 2.
Modyfikacja struktury aplikacji
Struktura aplikacji - sk$adniki
modu# - reprezentuje aplikacj!
tabela bazowa - wskazuje relacj!, ktr& przetwarza
aplikacja; przechowuje informacje o dopuszczalnych
operacjach na relacji
tabela look-up - uzupe$nia dane z tabeli bazowej o dane z
relacji powi&zanej za pomoc& ogranicze" referencyjnych;
zawiera elementy zwi&zane wy(wietlaj&ce dane z tej relacji
powi&zania mi!dzy tablicami bazowymi lub mi!dzy tablic&
bazow& a tablic& look-up - modeluj& hierarchi!
Struktura aplikacji - sk$adniki (2)
element zwi%zany - wskazuje na kolumny relacji, ktr&
przetwarza aplikacja; grupowane w tabeli bazowej lub
look-up; najcz!(ciej s$u#& do wy(wietlania danych z
kolumn relacji
element niezwi%zany - wy(wietla informacje wyliczane, nie
ma odpowiednika w schemacie relacji; nie wskazuje na
#adn& kolumn! w relacji
komponent - grupuje elementy w strukturze (tabele bazowe,
elementy zwi&zane i niezwi&zane)
okna
argument aplikacji - warto(' przesy$ana do aplikacji po jej
uruchomieniu lub zapisywana przez aplikacj! przy jej
zako"czeniu; s$u#& do komunikacji pomi!dzy aplikacjami
Struktura aplikacji - sk$adniki (3)
Ka#dy element struktury
posiada list! w$asno(ci,
okre(laj&cych m.in.:
nazw! elementu
typ elementu (np. grupa
radiowa, lista, itd.)
dopuszczalne operacje,
itd.
Diagramy struktury aplikacji
Tworzenie - menu kontekstowego danej aplikacji wybra'
Show on New Diagram\
Rodzaje
widok danych - pokazuje wewn!trzn&
struktur! aplikacji
widok interfejsu - pokazuje uk$ad interfejsu
aplikacji
Prze$&czanie pomi!dzy widokami -
przyciski
Diagramy struktury aplikacji (2)
widok danych
widok interfejsu
modu$
podrz!dna
tabela
bazowa
tabela
look-up
element zwi&zany
komponent
element
niezwi&zany
powi&zania
okno
zawarto('
okna
element
interfejsu
nadrz!dna
tabela
bazowa
Proces modyfikacji
struktury aplikacji
Struktura aplikacji po transformacji
jedna tabela bazowa dla ka#dej relacji,
implementuj&cej encj! u#ywan& przez funkcj!
elementy zwi&zane, odpowiadaj&ce
kolumnom relacji
argumenty aplikacji, odpowiadaj&ce
atrybutom z przep$yww wej(ciowych i
wyj(ciowych funkcji
brak powi&za" mi!dzy tabelami bazowymi
brak tabel look-up
brak elementw niezwi&zanych
Krok %.
Zaakceptowanie modu$w-kandydatw
jako aplikacji do ostatecznej generacji -
ustawienie w$asno(ci Candidate? na No.
Wybr j!zyka implementacji aplikacji.
Proces modyfikacji struktury
kandydat
formularz
wydruk
aplikacja u$ytkowa
Krok 2.
Utworzenie zwi&zkw pomi!dzy
tabelami bazowymi
modeluj& hierarchi! nadrz!dny-
podrz!dny
korzystaj& z definicji ogranicze"
referencyjnych mi!dzy relacjami
Metody:
tworzenie automatyczne
tworzenie r!czne
Krok 2. - wynik
Krok 3.
Utworzenie zwi&zku typu look-up
Krok 4.
Okre(lenie w$asno(ci poszczeglnych sk$adnikw struktury, np.
zmiana typu elementu
Krok 5. - dodanie elementu
niezwi&zanego
Podzia$ ze wzgl!du na )rd$o danych:
funkcja agreguj&ce (MIN, MAX, SUM, AVG, COUNT) - Computed
(wyliczany)
funkcja sk$adowana na serwerze - Server Side Function
funkcja aplikacji - Client Side Function
wyra#enie wykorzystuj&ce funkcje SQL, np. TO_DATE, TO_CHAR,
LTRIM, itd. - SQL Expression
Przyk$ad - dodanie elementu niezwi&zanego
LICZBA_PRACOWNIKW - oblicza, ilu pracownikw jest
zatrudnionych w danym zespole
Krok 5a)
Dodanie elementu:
Krok 5b)
Okre(lenie w$asno(ci:
Krok 5. - Wynik
Budowanie aplikacji
krok 3.
Generowanie aplikacji
Warunki wst!pne
Uporz&dkowana struktura aplikacji
Dost!pny schemat fizyczny bazy danych, na
ktrym ma pracowa' aplikacja
Preferencje generacji
Zbir ustawie", okre(laj&cych:
sposb implementacji
struktury
sposb pracy aplikacji
wygl&d elementw interfejsu
uk$ad elementw interfejsu
Ustawiane dla:
ca$ego systemu aplikacji
konkretnej aplikacji
konkretnego elementu
Preferencje generacji (2)
Wy(wietlanie zbioru preferencji:
ca$ego systemu aplikacji
konkretnej aplikacji
Proces generacji aplikacji
Krok %.
Uruchomi' generator aplikacji
lub
Krok 2.
Ustawi' parametry - przycisk Options:
lokalizacja wersji )rd$owych
aplikacji (system plikw czy
baza danych)
lokalizacja wersji
wykonywalnych
czy aplikacja ma zosta'
uruchomiona po generacji
Krok 3.
Uruchomi' proces - przycisk Start
Przebieg procesu, komunikaty
Wynik
Uwagi
Proces generacji ma najcz!(ciej charakter cykliczny:
pierwsza generacja
zmiana preferencji
kolejna generacja, itd. a# do uzyskania maksymalnie
funkcjonalnej aplikacji
Nie op$aca si! kontynuowa' tego procesu a# do
wygenerowania w pe$ni funkcjonalnej aplikacji.

Designer 6 I

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Designer 6 I

Uploaded by

Copyright:

Available Formats

Wykorzystanie oprogramowania

Oracle Designer do budowy

You might also like