Proces transformacji - Instytut Informatyki

advertisement
Wykorzystanie oprogramowania
Oracle Designer do budowy
systemów informatycznych
Bartosz Bębel, Krzysztof Jankiewicz
Instytut Informatyki, Politechnika Poznańska
[email protected]
[email protected]
Cykl życia systemu informacyjnego
Metodyka Oracle CASE (CASE*Method)
STRATEGIA
ANALIZA
PROJEKTOWANIE
IMPLEMENTACJA
DOKUMENTACJA
WDROŻENIE
EKSPLOATACJA
(C) Instytut Informatyki, Politechnika Poznańska
2
Metodyka Oracle CASE –
strategia
• ogólny model przedsiębiorstwa, wymagania,
harmonogram prac, ograniczenia finansowe i
techniczne,
• modele:
STRATEGIA
–
–
–
–
procesów (PD),
danych (ERD),
funkcji (FHD),
przepływów (DFD).
ANALIZA
PROJEKTOWANIE
IMPLEMENTACJA
DOKUMENTACJA
WDROŻENIE
(C) Instytut Informatyki, Politechnika Poznańska
EKSPLOATACJA
3
Metodyka Oracle CASE –
analiza
• uzupełnienie informacji zebranych na etapie strategii,
• szczegółowe, zaakceptowane modele:
–
–
–
–
procesów (PD),
danych (ERD),
funkcji (FHD),
przepływów (DFD),
• diagramy matrycowe.
STRATEGIA
ANALIZA
PROJEKTOWANIE
IMPLEMENTACJA
DOKUMENTACJA
WDROŻENIE
(C) Instytut Informatyki, Politechnika Poznańska
EKSPLOATACJA
4
Metodyka Oracle CASE –
projektowanie
• model danych,
• struktura logiczna i fizyczna bazy danych,
• modele aplikacji
(formularzy,
raportów, itp.)
STRATEGIA
ANALIZA
PROJEKTOWANIE
IMPLEMENTACJA
DOKUMENTACJA
WDROŻENIE
(C) Instytut Informatyki, Politechnika Poznańska
EKSPLOATACJA
5
Metodyka Oracle CASE –
implementacja i dokumentacja
• generacja, modyfikacja i testowanie aplikacji,
• implementacja + strojenie,
• dokumentacja
użytkownika i
techniczna.
STRATEGIA
ANALIZA
PROJEKTOWANIE
IMPLEMENTACJA
DOKUMENTACJA
WDROŻENIE
(C) Instytut Informatyki, Politechnika Poznańska
EKSPLOATACJA
6
Cykl życia systemu informatycznego
– Oracle Designer 6i
Implementacja
strategia + analiza
(C) Instytut Informatyki, Politechnika Poznańska
projektowanie
dokumentacja
7
Metodyki realizacji projektów
informatycznych
Projektowanie SI z wykorzystaniem
Designer6i
• narzędzia do modelowania:
PD, ERD, FHD, DFD,
• transformacje,
• struktura logiczna bazy danych
(model relacyjny), definicje
aplikacji,
• generowanie obiektów bazy
danych i kodu po stronie serwera,
• generowanie aplikacji.
(C) Instytut Informatyki, Politechnika Poznańska
9
Metodyka RAD (Rapid
Application Development)
• szybkie tworzenie
prototypów aplikacji,
• modyfikowanie
prototypów zgodnie z
wymaganiami
użytkowników,
• tylko małe systemy,
• krótki czas od
rozpoczęcia projektu do
chwili dostarczenia
aplikacji użytkownikowi.
(C) Instytut Informatyki, Politechnika Poznańska
10
Metodyka IE
(Information Engineering)
• technika top-down,
• główny nacisk na
model danych,
• specyfikacja funkcji
przetwarzających
dane.
(C) Instytut Informatyki, Politechnika Poznańska
11
Metodyka PMD
(Process Model Driven)
• często używana jako
punkt początkowy dla
rozwoju systemów
informatycznych,
• pozwala na identyfikację
podstawowych procesów
w organizacji przed
analizą zakresu
informacji potrzebnej do
ich realizacji.
(C) Instytut Informatyki, Politechnika Poznańska
12
Metodyka DCD
(Design Capture Driven)
• stosowana w przypadku
istnienia już systemów w
przedsiębiorstwie,
• wykorzystuje mechanizmy
reverse-engineering,
• pozwala na generowanie
nowych systemów korzystając
ze starych definicji,
• pozwala realizować nowe
potrzeby przedsiębiorstwa przy
minimalnych nakładach
czasowych i finansowych.
(C) Instytut Informatyki, Politechnika Poznańska
13
Modelowanie procesów
Modelowanie procesów
• 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.
(C) Instytut Informatyki, Politechnika Poznańska
15
Definicja zależności procesów
• Zależność procesu B od procesu A oznacza,
że proces B nie może się rozpocząć dopóki
nie zakończy się proces A.
• Powody zależności:
–
–
–
–
informacyjne,
produkcyjne,
prawne,
inne.
(C) Instytut Informatyki, Politechnika Poznańska
A
B
16
Diagramy zależności procesów
(PD – Process Diagram)
• Struktura i zależności pomiędzy jednostkami organizacyjnymi.
• Zależności pomiędzy procesami, składnicami, wyzwalaczami i
wynikami.
(C) Instytut Informatyki, Politechnika Poznańska
17
Obiekty diagramu procesów
Jednostka
organizacyjna
Proces
Składnica
Zależność
(C) Instytut Informatyki, Politechnika Poznańska
Wynik
Wyzwalacz
18
Jednostka organizacyjna
(organization unit)
• Określa miejsce realizacji
poszczególnych procesów.
• Może dotyczyć jednostki organizacyjnej
lub osoby o określonych
kompetencjach.
(C) Instytut Informatyki, Politechnika Poznańska
19
Proces (process)
• Opisuje operację składową działalności
przedsiębiorstwa.
(C) Instytut Informatyki, Politechnika Poznańska
20
Proces (process)
• Rodzaje procesów:
–
–
–
–
–
–
operacja składowa (process step),
punkt wprowadzania danych (data entry),
punkt decyzyjny (decision point),
raport (report),
zewnętrzny (external),
wewnętrzny (internal).
(C) Instytut Informatyki, Politechnika Poznańska
21
Przepływ – zależność (flow)
• Pokazuje przepływy informacyjne i
materiałowe oraz zależności czasowe
pomiędzy procesami.
(C) Instytut Informatyki, Politechnika Poznańska
22
Przepływ – zależność (flow)
• Czy przepływ jest wystarczający do
rozpoczęcia realizacji procesu
przeznaczenia?
• Warunek oraz częstość wyboru jednego z
wielu przepływów wyjściowych przepływu
(dotyczy punktów decyzyjnych).
(C) Instytut Informatyki, Politechnika Poznańska
23
Przepływ – zależność (flow)
• Typy przepływów:
– przepływ (flow),
– temporalny (temporal) –
zależność czasowa,
– danych (data),
– materialny (material).
(C) Instytut Informatyki, Politechnika Poznańska
24
Wyzwalacz (trigger)
• Bodziec do podjęcia realizacji określonych
procesów.
• Typy wyzwalaczy:
– okresowy (time),
– systemowy
(system),
– inny (other).
(C) Instytut Informatyki, Politechnika Poznańska
25
Składnica (store)
• Magazyn informacji (zbiór relacji, arkuszy
kalkulacyjnych akt itp.), materiałów lub inny.
(C) Instytut Informatyki, Politechnika Poznańska
26
Składnica (store)
• Typy składnic:
– informacyjna (data store),
– materialna (material store),
– ogólna (store).
(C) Instytut Informatyki, Politechnika Poznańska
27
Wynik (outcome)
• Jest efektem realizacji sekwencji czynności.
• Typy wyników:
– okresowy (time),
– systemowy
(system),
– inny (other).
(C) Instytut Informatyki, Politechnika Poznańska
28
Process Modeler
• Pozwala na:
– definiowanie podstawowych procesów zachodzących w
przedsiębiorstwie,
– modelowanie elementów składowych procesów,
– identyfikowanie procesów wymagających usprawnienia
– modyfikacji,
– modelowanie procesów nie istniejących w
przedsiębiorstwie,
– włączanie do diagramów obiektów utworzonych w
innych składnikach Oracle Designer6i.
(C) Instytut Informatyki, Politechnika Poznańska
29
Modelowanie elementów
składowych procesów
(C) Instytut Informatyki, Politechnika Poznańska
30
Identyfikacja procesów
wymagających reorganizacji
(C) Instytut Informatyki, Politechnika Poznańska
31
Import istniejących obiektów
do diagramów
(C) Instytut Informatyki, Politechnika Poznańska
32
Modelowanie związków encji
Modelowanie
związków encji
• Metoda określania potrzeb informacyjnych firmy
lub organizacji.
• Modelowanie związków encji ma na celu:
– Dostarczenie dokładnego modelu potrzeb
informacyjnych przedsiębiorstwa, który stanowiłby
podstawę do konstruowania nowych lub ulepszonych
systemów,
– 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.
(C) Instytut Informatyki, Politechnika Poznańska
34
Diagramy związków encji
(C) Instytut Informatyki, Politechnika Poznańska
35
Obiekty występujące na
diagramach związków encji
Encja
Związki jeden
do jeden
Związki wiele do wiele
Związki jeden do wiele
(C) Instytut Informatyki, Politechnika Poznańska
36
Encja (entity)
• Encja – obiekt rzeczywisty lub niematerialny
mający znaczenie dla organizacji, o którym
informacje muszą być przechowywane.
(C) Instytut Informatyki, Politechnika Poznańska
37
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.
(C) Instytut Informatyki, Politechnika Poznańska
38
Unikalny identyfikator
(unique identifier)
• Unikalny identyfikator to zbiór atrybutów, końców
związków lub
związków
wykluczających,
których wartości
pozwalają
rozróżnić
instancje encji.
(C) Instytut Informatyki, Politechnika Poznańska
39
Atrybut (attribute)
• Atrybut – cecha służąca do identyfikacji,
klasyfikacji lub wyrażenia stanu encji.
(C) Instytut Informatyki, Politechnika Poznańska
40
Atrybut (attribute)
• Wartości jakie mogą być przyjmowane przez
atrybuty są ograniczane przez typ, wielkość,
i zbiór wartości dopuszczalnych.
(C) Instytut Informatyki, Politechnika Poznańska
41
Związek (relationship)
• Związek – nazwane, istotne powiązanie
pomiędzy encjami.
• Każdy związek ma dwa końce, z
których każdy ma przypisaną:
– nazwę,
– stopień/liczebność,
– opcjonalność (opcjonalny/wymagany).
składową
złożony z
ZESPÓŁ
Wiele
(C) Instytut Informatyki, Politechnika Poznańska
Wymagany
INSTYTUT
Jeden
Opcjonalny
Związek
rekurencyjny
42
Nazywanie związków
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.
(C) Instytut Informatyki, Politechnika Poznańska
43
Dziedzina (domain)
• Zbiór reguł kontroli poprawności danych,
ich formatów, i innych własności
stosowanych do definicji atrybutów.
(C) Instytut Informatyki, Politechnika Poznańska
44
Dziedzina (domain)
• Wartości dopuszczalne zdefiniowane w ramach
domen będą wpływały na zawartość relacji
CG_REF_CODES.
(C) Instytut Informatyki, Politechnika Poznańska
45
Konstrukcje specjalne
• Związki wykluczające
• Hierarchie encji
• Związki nieprzechodnie
(C) Instytut Informatyki, Politechnika Poznańska
46
Związki wykluczające
• Występują w postaci łuku łączącego dwa (lub więcej)
końce związków dochodzących do tej samej encji.
• Opisują sytuacje kiedy dla pojedynczej instancji encji
może wystąpić tylko jeden ze związków wykluczających.
(C) Instytut Informatyki, Politechnika Poznańska
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.
47
Tworzenie związku
wykluczającego
(C) Instytut Informatyki, Politechnika Poznańska
48
Hierarchie encji
• Hierarchie encji składają się z encji-nadtypu i zawartych w
niej encji-podtypów.
• Podtyp oprócz swoich własnych atrybutów i związków,
posiada wszystkie atrybuty, związki i funkcje dziedziczone
z encji-nadtypu.
(C) Instytut Informatyki, Politechnika Poznańska
49
Związki nieprzechodnie
• Oznaczane są za pomocą rombu przy jednym z końców
związku.
• Instancja encji, przy której 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).
(C) Instytut Informatyki, Politechnika Poznańska
50
Entity Relationship
Diagrammer
• Jest narzędziem służącym do modelowania i
definiowania potrzeb informacyjnych w
postaci diagramów związków encji.
Pozwala na:
– tworzenie diagramów związków encji,
– automatyczny rozkład obiektów na diagramie,
– dostęp do narzędzi systemu Oracle Designer
powiązanych i weryfikujących związki encji.
(C) Instytut Informatyki, Politechnika Poznańska
51
Modelowanie
przepływów danych
Modelowanie
przepływu danych
• Modelowanie przepływu danych (ang.
Dataflow Diagrams) ma na celu
zobrazowanie procesów zachodzących w
organizacji, wymiany informacji między
nimi oraz miejsc wprowadzania i
wyprowadzania danych.
(C) Instytut Informatyki, Politechnika Poznańska
53
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.
(C) Instytut Informatyki, Politechnika Poznańska
54
Diagramy przepływu danych
• Są podstawowym narzędziem do wiązania procesów z
przetwarzanymi danymi.
• Na ogólnym poziomie specyfikacji procesów pozwalają
wyznaczyć funkcje elementarne oraz te, które 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 poszczególnych składowych.
(C) Instytut Informatyki, Politechnika Poznańska
55
Obiekty diagramów
przepływów danych
Proces – funkcja
Przepływ
Byt zewnętrzny
Składnica danych
(C) Instytut Informatyki, Politechnika Poznańska
56
Składnica danych
(datastore)
• Składnica danych – kolekcja encji i ich atrybutów,
które powinny być przechowywane przez
określony czas.
Etykieta
(C) Instytut Informatyki, Politechnika Poznańska
Nazwa opisowa
57
Składnica danych
• Typy składnic danych:
– komputerowe (computer),
– papierowe (manual),
– inne (transient).
(C) Instytut Informatyki, Politechnika Poznańska
58
Przepływ danych
(dataflow)
• Przepływ danych jest nazwaną kolekcją encji i ich
atrybutów przekazywanych między dwoma
procesami, procesem a składnicą lub procesem a
bytem zewnętrznym.
(C) Instytut Informatyki, Politechnika Poznańska
59
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.
(C) Instytut Informatyki, Politechnika Poznańska
60
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.
(C) Instytut Informatyki, Politechnika Poznańska
61
Proces (function)
• Opisuje
składową
działalności
przedsiębiorstwa.
(C) Instytut Informatyki, Politechnika Poznańska
62
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ływów związanych
z tą funkcją.
(C) Instytut Informatyki, Politechnika Poznańska
63
Byt zewnętrzny
(external)
• Obiekt będący zewnętrznym (poza systemem)
źródłem lub odbiorcą informacji.
• Może reprezentować określoną encję lub
jednostkę organizacyjną.
(C) Instytut Informatyki, Politechnika Poznańska
64
Dataflow Diagrammer
• Narzędzie służące do rysowania diagramów
przepływów danych. Pozwala na:
– jednoczesną współpracę wielu użytkowników,
– automatyczny rozkład elementów,
– dostęp do narzędzi weryfikujących kompletność
wykorzystania encji
przez funkcje,
– przechodzenie do
składowych procesów lub
procesów znajdujących
się wyżej w hierarchii.
(C) Instytut Informatyki, Politechnika Poznańska
65
Modelowanie hierarchii funkcji
Modelowanie
hierarchii funkcji
• Modelowanie hierarchii funkcji tworzy diagramy
pokazujące dekompozycję funkcji na różnych poziomach
działalności przedsiębiorstwa.
(C) Instytut Informatyki, Politechnika Poznańska
67
Funkcja (function)
• Składowa operacja
przedsiębiorstwa.
(C) Instytut Informatyki, Politechnika Poznańska
68
Funkcje
specjalnego znaczenia
• Funkcje wspólne (common function).
• Funkcje atomowe (atomic function) –
funkcje, które nie podlegają dalszej
dekompozycji.
Funkcje atomowe
• Funkcje elementarne (elementary function).
(C) Instytut Informatyki, Politechnika Poznańska
69
Funkcje wspólne
• 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 wspólne
Funkcja główna
(C) Instytut Informatyki, Politechnika Poznańska
70
Funkcje elementarne
• Funkcje elementarne pozostawiają system
w stanie spójnym, wykonanie funkcji
elementarnej, nie będącej funkcją atomową,
wymaga pomyślnej realizacji wszystkich jej
funkcji podrzędnych.
(C) Instytut Informatyki, Politechnika Poznańska
71
Function
Hierarchy Diagrammer
• Pozwala na utworzenie diagramu hierarchii
funkcji realizowanych przez organizację.
Umożliwia:
– tworzenie, modyfikację i dekompozycję funkcji,
– automatyczne tworzenie podzbiorów 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).
(C) Instytut Informatyki, Politechnika Poznańska
72
Repozytorium
Oracle Designer 6i
Repozytorium
Oracle Designer 6i
• Repozytorium Oracle Designer 6i jest
miejscem składowania wszelkich obiektów
tworzonych na diagramach.
• Dzięki repozytorium obiekty utworzone np.
na diagramie zależności procesów można
importować do pozostałych diagramów.
(C) Instytut Informatyki, Politechnika Poznańska
74
Repository
Object Navigator
• Służy do przeglądania i modyfikacji
obiektów składowanych w
repozytorium
Oracle Designer6i.
• Dla każdego
obiektu dostępna
jest lista własności.
(C) Instytut Informatyki, Politechnika Poznańska
75
Zależności pomiędzy diagramami
Zależności pomiędzy diagramami
• Wszystkie trzy metody modelowania
procesów i funkcji, tj. konstrukcja
diagramów zależności procesów,
modelowania przepływów danych i
tworzenie hierarchii funkcji przenikają się
wzajemnie operując na tych samych
obiektach.
(C) Instytut Informatyki, Politechnika Poznańska
77
Funkcje – procesy
(C) Instytut Informatyki, Politechnika Poznańska
78
Składnice danych
(C) Instytut Informatyki, Politechnika Poznańska
79
Przepływy
(C) Instytut Informatyki, Politechnika Poznańska
80
Hierarchie funkcji
(C) Instytut Informatyki, Politechnika Poznańska
81
Sposoby i wskazówki dotyczące
tworzenia diagramów i modeli
Poziomy modelowania systemu
informatycznego
 Poziom przedsiębiorstwa – dotyczy podstawowych
obszarów działalności przedsiębiorstwa.
 Poziom systemu – wyznacza sposób, w jaki wymagania
przedsiębiorstwa są lub mogą być realizowane. Funkcje na
tym poziomie pokazują czynności pracowników.
 Poziom programu – pokazuje sposób fizycznej realizacji
funkcji
systemu
przez
określone
mechanizmy
komputerowe, biurowe itp. Funkcje na tym poziomie
pokazują elementarne operacje.
(C) Instytut Informatyki, Politechnika Poznańska
83
Wykorzystanie metod
modelowania
M e to d y
Poziom
Poziom systemu
modelowania przedsiębiorstwa
Poziom
programu
Hierarchia
fu n k c j i
Podstawowa
Podstawowa
Podstawowa
Diagram
zależności
p ro c e s ó w
Opcjonalna
Podstawowa
Opcjonalna
Diagramy
przepływów
danych
Opcjonalna
Podstawowa
Opcjonalna
(C) Instytut Informatyki, Politechnika Poznańska
84
Podstawowe podejścia przy
modelowaniu funkcji
• Modelowanie z góry do dołu – polega na
dekompozycji kolejnych poziomów
rozpoczynając od pojedynczej funkcji głównej
reprezentującej działalność przedsiębiorstwa.
• Modelowanie z dołu do góry – na początku
identyfikuje się funkcje przedsiębiorstwa, a
następnie dla każdej z nich próbuje się znaleźć
odpowiednie miejsce w hierarchii funkcji.
• Technika mieszana.
(C) Instytut Informatyki, Politechnika Poznańska
85
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.
(C) Instytut Informatyki, Politechnika Poznańska
86
Mechanizmy
• Powiązania określonych funkcji ze sposobem ich
realizacji.
• Typy mechanizmów:
–
–
–
–
myślowy,
komputerowy,
mechaniczny,
ręczny.
• Unikanie mechanizmów w nazwach i opisach funkcji
pozwala budować modele bardziej ogólne. Pobudza do
reorganizacji, usprawniania lub wprowadzania nowych
metod realizacji określonych zadań.
(C) Instytut Informatyki, Politechnika Poznańska
87
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.
(C) Instytut Informatyki, Politechnika Poznańska
88
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.
(C) Instytut Informatyki, Politechnika Poznańska
89
Zasady dotyczące związków
 Nazwy pojawiające się na końcach związków powinny
tworzyć
poprawne
konstrukcje
zdaniowe
z
poprzedzającymi je zwrotami „musi być” dla związków
wymaganych lub „może być” dla związków
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.
(C) Instytut Informatyki, Politechnika Poznańska
90
Nieprawidłowe związki
(C) Instytut Informatyki, Politechnika Poznańska
91
Zasady dotyczące atrybutów
 Nazwy atrybutów 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 atrybutów
powinny być atomowe,
 wartość każdego atrybutu powinna zależeć od całości
jednoznacznego identyfikatora,
 wartości atrybutów powinny zależeć tylko od jednoznacznego
identyfikatora.
 Po zakończeniu etapu analizy każdy z atrybutów powinien
być informacyjnie kompletny.
(C) Instytut Informatyki, Politechnika Poznańska
92
Zasady dotyczące związków
wykluczających
• Łuk musi obejmować co najmniej dwa końce
związków, a zwykle nie więcej niż trzy lub cztery.
• Łuki prawie zawsze rysuje się wokół końców
„wiele” związków.
• Jeśli jeden koniec związku, będącego częścią
jednoznacznego identyfikatora encji, znajduje się
w łuku, wówczas każdy inny koniec związku w
tym łuku musi być również częścią
jednoznacznego identyfikatora dla tej encji.
(C) Instytut Informatyki, Politechnika Poznańska
93
Niepoprawne związki
wykluczające
• Łuki mogą dotyczyć końców związków, które
albo wszystkie są obowiązkowe, albo wszystkie
opcjonalne.
• Łuki nie mogą obejmować związków dotyczących
różnych encji.
(C) Instytut Informatyki, Politechnika Poznańska
94
Reguły rozmieszczania elementów
na diagramie związków encji
• Końce związków „wiele” umieszcza się na górze
lub po lewej stronie, dzięki temu obiekty o dużym
znaczeniu, służące do opisywania innych
obiektów, 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.
(C) Instytut Informatyki, Politechnika Poznańska
95
Zamiana związków wiele do wiele
Encja intersekcji
Encje referencyjne
Historyczność
REZERWACJA
# * status
* data
(C) Instytut Informatyki, Politechnika Poznańska
STATUS
# * wartość
# * od dnia
° do dnia
REZERWACJA
# * data
96
(C) Instytut Informatyki, Politechnika Poznańska
97
Budowanie bazy danych
Dane wejściowe
Diagramy związków encji, a w szczególności:
– definicje encji wraz z atrybutami
– definicje związków między encjami
– definicje dziedzin atrybutów encji
Wynik
Baza danych projektowanego systemu
(C) Instytut Informatyki, Politechnika Poznańska
99
Przebieg procesu
krok 1. Transformowanie diagramów
związków encji do schematu
logicznego bazy danych
krok 2. Generowanie schematu fizycznego
bazy danych
(C) Instytut Informatyki, Politechnika Poznańska
100
Budowanie bazy danych
krok 1.
Transformowanie diagramów związków
encji do schematu logicznego bazy
danych
(C) Instytut Informatyki, Politechnika Poznańska
101
Reguły transformacji
Jak przetransformować:
• encję?
• hierarchię encji?
• związek?
(C) Instytut Informatyki, Politechnika Poznańska
102
Transformacja encji
•
•
•
•
•
Encja  relacja
Atrybut encji  kolumna relacji
Typ atrybutu  typ kolumny
Dziedzina atrybutu  ograniczenie check
Unikalny identyfikator encji  klucz
podstawowy relacji
(C) Instytut Informatyki, Politechnika Poznańska
103
Transformacja hierarchii encji
Sposoby:
– transformacja do pojedynczej relacji
– transformacja do oddzielnych relacji
– transformacja do oddzielnych relacji
połączonych ograniczeniami
referencyjnymi w łuku
(C) Instytut Informatyki, Politechnika Poznańska
104
Transformacja hierarchii
Sposób pierwszy
Zasady:
– jedna relacja
– schemat relacji: atrybuty wszystkich encji z
hierarchii + dodatkowa kolumna, określająca
typ specjalizacji
Kiedy stosować:
– większość atrybutów w nadtypie
– większość związków do nadtypu
Zalety:
– uproszczenie schematu bazy danych
Wady:
– atrybuty obowiązkowe podtypu stają się kolumnami
opcjonalnymi
(C) Instytut Informatyki, Politechnika Poznańska
105
Transformacja hierarchii
Sposób drugi
Zasady:
– jedna relacja dla każdego podtypu
– schemat relacji: atrybuty nadtypu + atrybuty
podtypu
Kiedy stosować:
– większość atrybutów w podtypach
– większość związków do podtypów
Zalety:
– zachowanie obowiązkowości atrybutów w
podtypach
Wady:
– komplikacja schematu
– konieczność powielenia kluczy obcych implementujących
związki przyłączone do nadtypu
(C) Instytut Informatyki, Politechnika Poznańska
106
Transformacja hierarchii
Sposób trzeci
Zasady:
– jedna relacja z atrybutami wspólnymi, dla każdego podtypu
osobna relacja z jego atrybutami specyficznymi
– relacje połączone kluczami obcymi w łuku
Kiedy stosować:
– związki przywiązane zarówno do nadtypu jak
i podtypów
Zalety:
– zachowanie obowiązkowości atrybutów
w podtypach
– łatwy dostęp do informacji z nadtypu
Wady:
– komplikacja schematu
– konieczność stosowania
połączeń (SQL)
(C) Instytut Informatyki, Politechnika Poznańska
107
Transformacja związków
• Implementacja związku za pomocą
ograniczeń referencyjnych (kluczy obcych)
• Sposób transformacji zależy od parametrów
związku:
– krotności (1:1, 1:N, M:N)
– obowiązkowości/opcjonalności
(C) Instytut Informatyki, Politechnika Poznańska
108
Transformacja związków
Związek 1:1 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
(C) Instytut Informatyki, Politechnika Poznańska
TABLICA_A (
ID_A
ATR_1
PRIMARY KEY,
NULL)
TABLICA_B (
ID_B
ATR_1
ID_A
PRIMARY KEY,
NOT NULL
NOT NULL REFERENCES
TABLICA_A(ID_A))
109
Transformacja związków
Związek 1:1 obustronnie
opcjonalny
Zasady:
– do relacji impl. tą encję ze związku, dla której 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
110
Transformacja związków
Związek 1: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 „1” 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 „1” nie ma
wpływu na transformację
(C) Instytut Informatyki, Politechnika Poznańska
TABLICA_A (
ID_A
ATR_1
ID_B
PRIMARY KEY,
NULL
NOT NULL REFERENCES
TABLICA_B(ID_B))
TABLICA_B (
ID_B
ATR_1
PRIMARY KEY,
NOT NULL)
111
Transformacja związków
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
(C) Instytut Informatyki, Politechnika Poznańska
TABLICA_A (
ID_A
ATR_1
PRIMARY KEY,
NULL)
TABLICA_B (
ID_B
ATR_1
PRIMARY KEY,
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))
112
Proces transformacji
Proces transformacji
Krok 1.
Uruchomić narzędzie Database Design
Transformer z grupy Transform Preliminary
Designs
(C) Instytut Informatyki, Politechnika Poznańska
114
Proces transformacji
Krok 2 - opcje transformacji
– transformacja wg
ustawień domyślnych
– transformacja wg
ustawień
użytkownika
(C) Instytut Informatyki, Politechnika Poznańska
115
Proces transformacji
Dostępne ustawienia
• wybór encji do transformacji - domyślnie
wszystkie
• sposób transformacja hierarchii domyślnie do jednej relacji
• wybór typów tworzonych elementów
(relacje, kolumny, klucze, indeksy) domyślnie wszystkie
• wybór typów modyfikowanych elementów
(istniejących już w repozytorium relacji,
kolumn, kluczy, indeksów) - domyślnie
żadne
(C) Instytut Informatyki, Politechnika Poznańska
116
Proces transformacji
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 identyfikatorów
• przedrostek nazw relacji - domyślnie brak
• przedrostki nazw kolumn (na podstawie
krótkich nazw encji) - domyślnie brak
(C) Instytut Informatyki, Politechnika Poznańska
117
Proces transformacji
Krok 3 - uruchomienie procesu
Uruchomienie
transformacji przycisk Run
(C) Instytut Informatyki, Politechnika Poznańska
118
Proces transformacji
Wynik
Umieszczone repozytorium systemu definicje:
• relacji
• kolumn
• ograniczeń integralnościowych
• indeksów
• liczników - dla sztucznych kluczy
podstawowych
(C) Instytut Informatyki, Politechnika Poznańska
119
Proces transformacji
Wynik (2)
Podgląd definicji w repozytorium - narzędzie
Design Editor z grupy Design and Generate
(C) Instytut Informatyki, Politechnika Poznańska
120
Design Editor
Umożliwia:
– przeglądanie i ręczną modyfikację powstałego w wyniku
transformacji schematu logicznego bazy danych
– definiowanie dodatkowych obiektów schematu logicznego:
• liczników
• perspektyw
• kodu PL/SQL
– utworzenie diagramu schematu modelu relacyjnego pokazuje połączenia między relacjami (ograniczenia
referencyjne)
(C) Instytut Informatyki, Politechnika Poznańska
121
Design Editor
Przeglądanie i modyfikacja
schematu logicznego
Zakładka Server Model, gałęzie:
• Relational Table
Definitions - relacje,
kolumny, ograniczenia
itegralnościowe, inne
• Relational View
Definition - perspektywy
• Sequence Definitions liczniki
• PL/SQL Definitions kod składowany
(C) Instytut Informatyki, Politechnika Poznańska
122
Design Editor
Tworzenie diagramu
schematu logicznego
• Zaznaczyć obiekty (relacje lub perspektywy), które mają być
uwidocznione na diagramie
• Z menu kontekstowego
wybrać Show on New
Diagram
(C) Instytut Informatyki, Politechnika Poznańska
123
Design Editor
Przykładowy diagramu
schematu logicznego
(C) Instytut Informatyki, Politechnika Poznańska
124
Jak to zrobić?
Jak przetransformować hierarchię encji w
sposób inny niż domyślny?
(C) Instytut Informatyki, Politechnika Poznańska
125
Jak to zrobić - hierarchia encji
Transformacja do oddzielnych relacji
krok 1. Uruchomić Database Design Transformer
krok 2. Zaznaczyć opcję Customize the Database
Transformer i wybrać zakładkę Table Mappings
(C) Instytut Informatyki, Politechnika Poznańska
126
Jak to zrobić - hierarchia encji
Transformacja do oddzielnych relacji
krok 3. Zmienić zbiór encji do transformacji wyłączyć ze zbioru encję-nadtyp, dodać encjepodtypy
(C) Instytut Informatyki, Politechnika Poznańska
127
Jak to zrobić - hierarchia encji
Transformacja do oddzielnych relacji
krok 4. Przystąpić do transformacji
Wynik:
(C) Instytut Informatyki, Politechnika Poznańska
128
Jak to zrobić - hierarchia encji
Transformacja do relacji w łuku
krok 1. Uruchomić Database Design Transformer
krok 2. Zaznaczyć opcję Customize the Database
Transformer i wybrać zakładkę Table Mappings
(C) Instytut Informatyki, Politechnika Poznańska
129
Jak to zrobić - hierarchia encji
Transformacja do relacji w łuku
krok 3. Zmienić zbiór encji do transformacji - włączyć
do zbioru encję-nadtyp wraz z encjami-podtypami
(C) Instytut Informatyki, Politechnika Poznańska
130
Jak to zrobić - hierarchia encji
Transformacja do relacji w łuku
krok 4. Zmienić typ elementów 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
(C) Instytut Informatyki, Politechnika Poznańska
131
Jak to zrobić - hierarchia encji
Transformacja do relacji w łuku
krok 6. Przy encjach-podtypach zaznaczyć opcję Arc
krok 7. Zmienić typ elementów do transformacji zakładka Run Options - wszystkie elementy
(C) Instytut Informatyki, Politechnika Poznańska
132
Jak to zrobić - hierarchia encji
Transformacja do relacji w łuku
krok 8. Przystąpić do transformacji
Wynik:
(C) Instytut Informatyki, Politechnika Poznańska
133
Budowanie bazy danych
krok 2.
Generowanie schematu fizycznego
bazy danych
(C) Instytut Informatyki, Politechnika Poznańska
134
Generacja bazy danych
Przebieg procesu
krok 1. Uruchomić narzędzie Design Editor. Przejść
na zakładkę Server Model, rozwinąć gałąź
systemu aplikacji
krok 2. Wybrać pozycję
Generate Database from
Server Model z menu
Generate
(C) Instytut Informatyki, Politechnika Poznańska
135
Generacja bazy danych
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 skryptów
(C) Instytut Informatyki, Politechnika Poznańska
136
Generacja bazy danych
Przebieg procesu
krok 4. Wybrać obiekty do generacji - zakładka Objects:
• Typ obiektu:
– relacje
– liczniki
– perspektywy i inne
• Konkretny obiekt
(C) Instytut Informatyki, Politechnika Poznańska
137
Generacja bazy danych
Przebieg procesu
krok 5. Uruchomić proces - przycisk Start
Wynik - w zależności od parametrów generacji:
• skrypty DDL we wskazanym katalogu
• obiekty w schemacie wskazanego użytkownika
• obiekty w bazie danych przyłączonej za pomocą
ODBC
(C) Instytut Informatyki, Politechnika Poznańska
138
Budowanie aplikacji
Dane wejściowe
Diagramy hierarchii funkcji i przepływów danych,
a w szczególności:
– definicje funkcji
– sposób użycia encji przez funkcje
– przepływy z i do funkcji
Wynik
Definicje aplikacji w wybranym języku
programowania
(C) Instytut Informatyki, Politechnika Poznańska
140
Przebieg procesu
krok 1. Transformowanie definicji funkcji do
projektów aplikacji
krok 2. Modyfikacja struktury aplikacji
krok 3. Generowanie aplikacji w wybranym
języku programowania
(C) Instytut Informatyki, Politechnika Poznańska
141
Budowanie aplikacji
krok 1.
Transformowanie definicji funkcji do
projektów aplikacji
(C) Instytut Informatyki, Politechnika Poznańska
142
Reguły transformacji
1.Które funkcje transformować?
2.Co wpływa na wybór typu aplikacji, która
powstanie z funkcji?
3.Jak znaleźć funkcje, które mogą być
zaimplementowane przez tą samą aplikację?
- łączenie funkcji
(C) Instytut Informatyki, Politechnika Poznańska
143
Reguły transformacji
Które funkcje transformować?
Kandydatami do transformacji są:
– liście hierarchii bez przodków, będących
funkcjami elementarnymi lub wspólnymi
– funkcje wspólne
– funkcje elementarne
(C) Instytut Informatyki, Politechnika Poznańska
144
Reguły transformacji
Które funkcje transformować?
(C) Instytut Informatyki, Politechnika Poznańska
145
Reguły transformacji
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
(C) Instytut Informatyki, Politechnika Poznańska
146
Reguły transformacji
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)
(C) Instytut Informatyki, Politechnika Poznańska
147
Reguły transformacji
Co wpływa na typ aplikacji? (3)
Zasady:
– encje, których 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
(C) Instytut Informatyki, Politechnika Poznańska
148
Reguły transformacji
Łą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 atrybutów encji
(C) Instytut Informatyki, Politechnika Poznańska
149
Proces transformacji
Proces transformacji
Krok 1.
Uruchomić narzędzie Application Design
Transformer z grupy Transform Preliminary
Designs
(C) Instytut Informatyki, Politechnika Poznańska
151
Proces transformacji
Krok 2. - ustawienie parametrów
• wybór funkcji w hierarchii, od której 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
poszczególnych typów - Language (np. Oracle Forms,
Oracle Reports, Visual Basic, itd.)
• kryteria łączenia funkcji - Merge Granularity
(C) Instytut Informatyki, Politechnika Poznańska
152
Proces transformacji
Krok 3. - uruchomienie procesu
Uruchomienie transformacji - przycisk Generate
(C) Instytut Informatyki, Politechnika Poznańska
153
Proces transformacji
Wynik
• Umieszczone w repozytorium systemu
definicje modułówkandydatów na aplikacje
• Przeglądanie struktury Design Editor, zakładka
Modules, gałąź Modules
(C) Instytut Informatyki, Politechnika Poznańska
154
Budowanie aplikacji
krok 2.
Modyfikacja struktury aplikacji
(C) Instytut Informatyki, Politechnika Poznańska
155
Struktura aplikacji - składniki
• moduł - reprezentuje aplikację
• tabela bazowa - wskazuje relację, którą 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ę
(C) Instytut Informatyki, Politechnika Poznańska
156
Struktura aplikacji - składniki (2)
• element związany - wskazuje na kolumny relacji, którą
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
(C) Instytut Informatyki, Politechnika Poznańska
157
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.
(C) Instytut Informatyki, Politechnika Poznańska
158
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
(C) Instytut Informatyki, Politechnika Poznańska
159
Diagramy struktury aplikacji (2)
widok danych
nadrzędna
tabela
bazowa
widok interfejsu
moduł
tabela
okno
look-up
element
niezwiązany zawartość
powiązania okna
komponent
element
podrzędna
interfejsu
tabela
bazowa
(C) Instytut Informatyki, Politechnika Poznańska
element związany
160
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ływów wejściowych i
wyjściowych funkcji
• brak powiązań między tabelami bazowymi
• brak tabel look-up
• brak elementów niezwiązanych
(C) Instytut Informatyki, Politechnika Poznańska
162
Proces modyfikacji struktury
Krok 1.
Zaakceptowanie modułów-kandydatów
jako aplikacji do ostatecznej generacji ustawienie własności Candidate? na No.
Wybór języka implementacji aplikacji.
formularz
kandydat
wydruk
aplikacja użytkowa
(C) Instytut Informatyki, Politechnika Poznańska
163
Proces modyfikacji struktury
Krok 2.
Utworzenie związków pomiędzy
tabelami bazowymi
• modelują hierarchię nadrzędnypodrzędny
• korzystają z definicji ograniczeń
referencyjnych między relacjami
Metody:
• tworzenie automatyczne
• tworzenie ręczne
(C) Instytut Informatyki, Politechnika Poznańska
164
Proces modyfikacji struktury
Krok 2. - wynik
(C) Instytut Informatyki, Politechnika Poznańska
165
Proces modyfikacji struktury
Krok 3.
Utworzenie związku typu look-up
(C) Instytut Informatyki, Politechnika Poznańska
166
Proces modyfikacji struktury
Krok 4.
Określenie własności poszczególnych składników struktury, np.
zmiana typu elementu
(C) Instytut Informatyki, Politechnika Poznańska
167
Proces modyfikacji struktury
Krok 5. - dodanie elementu
niezwiązanego
Podział ze względu na źródł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_PRACOWNIKÓW - oblicza, ilu pracowników jest
zatrudnionych w danym zespole
(C) Instytut Informatyki, Politechnika Poznańska
168
Proces modyfikacji struktury
Krok 5a)
Dodanie elementu:
(C) Instytut Informatyki, Politechnika Poznańska
169
Proces modyfikacji struktury
Krok 5b)
Określenie własności:
(C) Instytut Informatyki, Politechnika Poznańska
170
Proces modyfikacji struktury
Krok 5. - Wynik
(C) Instytut Informatyki, Politechnika Poznańska
171
Budowanie aplikacji
krok 3.
Generowanie aplikacji
(C) Instytut Informatyki, Politechnika Poznańska
172
Warunki wstępne
• Uporządkowana struktura aplikacji
• Dostępny schemat fizyczny bazy danych, na
którym ma pracować aplikacja
(C) Instytut Informatyki, Politechnika Poznańska
173
Preferencje generacji
Zbiór ustawień, określających:
– sposób implementacji
struktury
– sposób pracy aplikacji
– wygląd elementów interfejsu
– układ elementów interfejsu
Ustawiane dla:
– całego systemu aplikacji
– konkretnej aplikacji
– konkretnego elementu
(C) Instytut Informatyki, Politechnika Poznańska
174
Preferencje generacji (2)
Wyświetlanie zbioru preferencji:
– całego systemu aplikacji
– konkretnej aplikacji
(C) Instytut Informatyki, Politechnika Poznańska
175
Proces generacji aplikacji
Proces generacji aplikacji
Krok 1.
Uruchomić generator aplikacji
lub
(C) Instytut Informatyki, Politechnika Poznańska
177
Proces generacji aplikacji
Krok 2.
Ustawić parametry - przycisk Options:
– lokalizacja wersji źródłowych
aplikacji (system plików czy
baza danych)
– lokalizacja wersji
wykonywalnych
– czy aplikacja ma zostać
uruchomiona po generacji
(C) Instytut Informatyki, Politechnika Poznańska
178
Proces generacji aplikacji
Krok 3.
Uruchomić proces - przycisk Start
Przebieg procesu, komunikaty
(C) Instytut Informatyki, Politechnika Poznańska
179
Proces generacji aplikacji
Wynik
(C) Instytut Informatyki, Politechnika Poznańska
180
Proces generacji aplikacji
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.
(C) Instytut Informatyki, Politechnika Poznańska
181
(C) Instytut Informatyki, Politechnika Poznańska
182
Download