Wykorzystanie oprogramowania Oracle Designer do budowy ... · (PD Œ Process Diagram) Ł Struktura...
-
Upload
hoangkhuong -
Category
Documents
-
view
223 -
download
0
Transcript of Wykorzystanie oprogramowania Oracle Designer do budowy ... · (PD Œ Process Diagram) Ł Struktura...
Wykorzystanie oprogramowaniaOracle Designer do budowysystemów informatycznych
Bartosz Bębel, Krzysztof JankiewiczInstytut Informatyki, Politechnika Poznańska
[email protected]@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
(C) Instytut Informatyki, Politechnika Poznańska 3
Metodyka Oracle CASE �strategia
�� ogólnyogólny model model przedsiębiorstwaprzedsiębiorstwa,, w wymaganiaymagania,,harmonogram pracharmonogram prac, , ograniczenia finansowe ograniczenia finansowe iitechnicznetechniczne,,
�� modelemodele::�� procesówprocesów (PD), (PD),�� danychdanych (ERD), (ERD),�� funkcjifunkcji (FHD), (FHD),�� przepływówprzepływów (DFD) (DFD)..
STRATEGIA
ANALIZA
PROJEKTOWANIE
IMPLEMENTACJA
WDROŻENIE
EKSPLOATACJA
DOKUMENTACJA
(C) Instytut Informatyki, Politechnika Poznańska 4
Metodyka Oracle CASE �analiza
� uzupełnienie informacji zebranych na etapie strategii,� szczegółowe, zaakceptowane modele:
�� procesówprocesów (PD), (PD),�� danychdanych (ERD), (ERD),�� funkcjifunkcji (FHD), (FHD),�� przepływówprzepływów (DFD) (DFD),,
� diagramy matrycowe.
STRATEGIA
ANALIZA
PROJEKTOWANIE
IMPLEMENTACJA
WDROŻENIE
EKSPLOATACJA
DOKUMENTACJA
(C) Instytut Informatyki, Politechnika Poznańska 5
Metodyka Oracle CASE �projektowanie
� model danych,� struktura logiczna i fizyczna bazy danych,� modele aplikacji
(formularzy,raportów, itp.)
STRATEGIA
ANALIZA
PROJEKTOWANIE
IMPLEMENTACJA
WDROŻENIE
EKSPLOATACJA
DOKUMENTACJA
(C) Instytut Informatyki, Politechnika Poznańska 6
Metodyka Oracle CASE �implementacja i dokumentacja
� generacja, modyfikacja i testowanie aplikacji,� implementacja + strojenie,� dokumentacja
użytkownika itechniczna.
STRATEGIA
ANALIZA
PROJEKTOWANIE
IMPLEMENTACJA
WDROŻENIE
EKSPLOATACJA
DOKUMENTACJA
(C) Instytut Informatyki, Politechnika Poznańska 7
Cykl życia systemu informatycznego� Oracle Designer 6i
strategiastrategia + + analizaanaliza
projektowanieprojektowanie
ImplementImplementacjaacja
dokumentacjadokumentacja
Metodyki realizacji projektówinformatycznych
(C) Instytut Informatyki, Politechnika Poznańska 9
Projektowanie SI z wykorzystaniemDesigner6i
� narzędzia do modelowania:PD, ERD, FHD, DFD,
� struktura logiczna bazy danych(model relacyjny), definicjeaplikacji,
� generowanie obiektów bazydanych i kodu po stronie serwera,
� generowanie aplikacji.
� transformacje,
(C) Instytut Informatyki, Politechnika Poznańska 10
Metodyka RAD (RapidApplication Development)
� szybkie tworzenieprototypów aplikacji,
� modyfikowanieprototypów zgodnie zwymaganiamiużytkowników,
� tylko małe systemy,� krótki czas od
rozpoczęcia projektu dochwili dostarczeniaaplikacji użytkownikowi.
(C) Instytut Informatyki, Politechnika Poznańska 11
Metodyka IE(Information Engineering)
� technika top-down,� główny nacisk na
model danych,� specyfikacja funkcji
przetwarzającychdane.
(C) Instytut Informatyki, Politechnika Poznańska 12
Metodyka PMD(Process Model Driven)
� często używana jakopunkt początkowy dlarozwoju systemówinformatycznych,
� pozwala na identyfikacjępodstawowych procesóww organizacji przedanalizą zakresuinformacji potrzebnej doich realizacji.
(C) Instytut Informatyki, Politechnika Poznańska 13
Metodyka DCD(Design Capture Driven)
� stosowana w przypadkuistnienia już systemów wprzedsiębiorstwie,
� wykorzystuje mechanizmyreverse-engineering,
� pozwala na generowanienowych systemów korzystającze starych definicji,
� pozwala realizować nowepotrzeby przedsiębiorstwa przyminimalnych nakładachczasowych i finansowych.
Modelowanie procesów
(C) Instytut Informatyki, Politechnika Poznańska 15
Modelowanie procesów
� Określa kolejność i miejsce realizacji funkcjiprzedsiębiorstwa.
� Umożliwia i ułatwia komunikację pomiędzy:� różnymi działami firmy,� użytkownikami a projektantami,� projektantami a programistami.
� Pozwala na zrozumienie funkcjonowaniaorganizacji.
(C) Instytut Informatyki, Politechnika Poznańska 16
Definicja zależności procesów
� Zależność procesu B od procesu A oznacza,że proces B nie może się rozpocząć dopókinie zakończy się proces A.
� Powody zależności:� informacyjne,� produkcyjne,� prawne,� inne.
A B
(C) Instytut Informatyki, Politechnika Poznańska 17
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 18
Obiekty diagramu procesów
Jednostkaorganizacyjna
Proces
Składnica
Zależność Wyzwalacz
Wynik
(C) Instytut Informatyki, Politechnika Poznańska 19
Jednostka organizacyjna(organization unit)
� Określa miejsce realizacjiposzczególnych procesów.
� Może dotyczyć jednostki organizacyjnejlub osoby o określonychkompetencjach.
(C) Instytut Informatyki, Politechnika Poznańska 20
Proces (process)
� Opisuje operację składową działalnościprzedsiębiorstwa.
(C) Instytut Informatyki, Politechnika Poznańska 21
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 22
Przepływ � zależność (flow)
� Pokazuje przepływy informacyjne imateriałowe oraz zależności czasowepomiędzy procesami.
(C) Instytut Informatyki, Politechnika Poznańska 23
Przepływ � zależność (flow)
� Czy przepływ jest wystarczający dorozpoczęcia realizacji procesuprzeznaczenia?
� Warunek oraz częstość wyboru jednego zwielu przepływów wyjściowych przepływu(dotyczy punktów decyzyjnych).
(C) Instytut Informatyki, Politechnika Poznańska 24
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 25
Wyzwalacz (trigger)
� Bodziec do podjęcia realizacji określonychprocesów.
� Typy wyzwalaczy:� okresowy (time),� systemowy
(system),� inny (other).
(C) Instytut Informatyki, Politechnika Poznańska 26
Składnica (store)
� Magazyn informacji (zbiór relacji, arkuszykalkulacyjnych akt itp.), materiałów lub inny.
(C) Instytut Informatyki, Politechnika Poznańska 27
Składnica (store)
� Typy składnic:� informacyjna (data store),� materialna (material store),� ogólna (store).
(C) Instytut Informatyki, Politechnika Poznańska 28
Wynik (outcome)
� Jest efektem realizacji sekwencji czynności.� Typy wyników:
� okresowy (time),� systemowy
(system),� inny (other).
(C) Instytut Informatyki, Politechnika Poznańska 29
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 30
Modelowanie elementówskładowych procesów
(C) Instytut Informatyki, Politechnika Poznańska 31
Identyfikacja procesówwymagających reorganizacji
(C) Instytut Informatyki, Politechnika Poznańska 32
Import istniejących obiektówdo diagramów
Modelowanie związków encji
(C) Instytut Informatyki, Politechnika Poznańska 34
Modelowaniezwiązków encji
� Metoda określania potrzeb informacyjnych firmylub organizacji.
� Modelowanie związków encji ma na celu:� Dostarczenie dokładnego modelu potrzeb
informacyjnych przedsiębiorstwa, który stanowiłbypodstawę do konstruowania nowych lub ulepszonychsystemów,
� dostarczanie modelu niezależnego od sposobuprzechowywania danych i metod dostępu do nich,umożliwiającego podejmowanie decyzji, dotyczącychmetod implementacji oraz sposobu współdziałania zistniejącymi systemami.
(C) Instytut Informatyki, Politechnika Poznańska 35
Diagramy związków encji
(C) Instytut Informatyki, Politechnika Poznańska 36
Obiekty występujące nadiagramach związków encji
Encja
Związki jeden do wiele
Związki wiele do wiele
Związki jedendo jeden
(C) Instytut Informatyki, Politechnika Poznańska 37
Encja (entity)
� Encja � obiekt rzeczywisty lub niematerialnymający znaczenie dla organizacji, o któryminformacje muszą być przechowywane.
(C) Instytut Informatyki, Politechnika Poznańska 38
Encja (entity)
� Każda encja musi być jednoznacznieidentyfikowalna � to znaczy, że każda instancja(wystąpienie) encji musi być wyraźnieodróżnialna od wszystkich innych instancji tegotypu encji. Uzyskuje się to poprzez definicjęjednoznacznego identyfikatora.
(C) Instytut Informatyki, Politechnika Poznańska 39
Unikalny identyfikator(unique identifier)
� Unikalny identyfikator to zbiór atrybutów,końcówzwiązków lubzwiązkówwykluczających,których wartościpozwalająrozróżnićinstancje encji.
(C) Instytut Informatyki, Politechnika Poznańska 40
Atrybut (attribute)
� Atrybut � cecha służąca do identyfikacji,klasyfikacji lub wyrażenia stanu encji.
(C) Instytut Informatyki, Politechnika Poznańska 41
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 42
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).
ZESPÓŁ INSTYTUT
Wiele JedenWymaganyOpcjonalny
Związekrekurencyjny
składową złożony z
(C) Instytut Informatyki, Politechnika Poznańska 43
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 44
Dziedzina (domain)
� Zbiór reguł kontroli poprawności danych,ich formatów, i innych własnościstosowanych do definicji atrybutów.
(C) Instytut Informatyki, Politechnika Poznańska 45
Dziedzina (domain)� Wartości dopuszczalne zdefiniowane w ramach
domen będą wpływały na zawartość relacjiCG_REF_CODES.
(C) Instytut Informatyki, Politechnika Poznańska 46
Konstrukcje specjalne
� Związki wykluczające
� Hierarchie encji
� Związki nieprzechodnie
(C) Instytut Informatyki, Politechnika Poznańska 47
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.
Pracownik zatrudniony jestalbo na poziomie instytutu,albo na poziomie zespołu.
lub (precyzyjnie)Każdy Pracownik musi byćalbo zatrudniony w jednym itylko jednym instytuciealbo zatrudniony w jednym itylko jednym zespole.
(C) Instytut Informatyki, Politechnika Poznańska 48
Tworzenie związkuwykluczającego
(C) Instytut Informatyki, Politechnika Poznańska 49
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 dziedziczonez encji-nadtypu.
(C) Instytut Informatyki, Politechnika Poznańska 50
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 encjiwynikającego z tego związku.
Zespół raz przypisanydo określonegoinstytutu nie możezostać przeniesionydo innego instytutu(nie może zmienićprzypisania).
(C) Instytut Informatyki, Politechnika Poznańska 51
Entity RelationshipDiagrammer
� Jest narzędziem służącym do modelowania idefiniowania potrzeb informacyjnych wpostaci 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.
Modelowanieprzepływów danych
(C) Instytut Informatyki, Politechnika Poznańska 53
Modelowanieprzepływu danych
� Modelowanie przepływu danych (ang.Dataflow Diagrams) ma na celuzobrazowanie procesów zachodzących worganizacji, wymiany informacji międzynimi oraz miejsc wprowadzania iwyprowadzania danych.
(C) Instytut Informatyki, Politechnika Poznańska 54
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 55
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 56
Obiekty diagramówprzepływów danych
Proces � funkcja
Przepływ
Składnica danych
Byt zewnętrzny
(C) Instytut Informatyki, Politechnika Poznańska 57
Składnica danych(datastore)
� Składnica danych � kolekcja encji i ich atrybutów,które powinny być przechowywane przezokreślony czas.
Etykieta Nazwa opisowa
(C) Instytut Informatyki, Politechnika Poznańska 58
Składnica danych
� Typy składnic danych:� komputerowe (computer),� papierowe (manual),� inne (transient).
(C) Instytut Informatyki, Politechnika Poznańska 59
Przepływ danych(dataflow)
� Przepływ danych jest nazwaną kolekcją encji i ichatrybutów przekazywanych między dwomaprocesami, procesem a składnicą lub procesem abytem zewnętrznym.
(C) Instytut Informatyki, Politechnika Poznańska 60
Przepływ danych (dataflow)
� Przepływ danych jest chwilowym przeniesieniem danych.� Gdy osiągną one cel
(proces) decyzja o tymco się z nimi dalejstanie zależy od procesuprzyjmującego.Jeśli odbiorca zignorujenadchodzące danezostaną oneutracone na zawsze.
(C) Instytut Informatyki, Politechnika Poznańska 61
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ącychsię w składnicy.
� Składnica danych służy do przechwytywania nastałe chwilowego przepływu danych.
(C) Instytut Informatyki, Politechnika Poznańska 62
Proces (function)� Opisuje
składowądziałalnościprzedsię-biorstwa.
(C) Instytut Informatyki, Politechnika Poznańska 63
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 dofunkcji nie ma wpływuna ENTITY USAGES.
� ZawartośćENTITY USAGES dlafunkcji nie ma żadnegowpływu na zawartośćprzepływów związanychz tą funkcją.
(C) Instytut Informatyki, Politechnika Poznańska 64
Byt zewnętrzny(external)
� Obiekt będący zewnętrznym (poza systemem)źródłem lub odbiorcą informacji.
� Może reprezentować określoną encję lubjednostkę organizacyjną.
(C) Instytut Informatyki, Politechnika Poznańska 65
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 encjiprzez funkcje,
� przechodzenie doskładowych procesów lubprocesów znajdującychsię wyżej w hierarchii.
Modelowanie hierarchii funkcji
(C) Instytut Informatyki, Politechnika Poznańska 67
Modelowaniehierarchii funkcji
� Modelowanie hierarchii funkcji tworzy diagramypokazujące dekompozycję funkcji na różnych poziomachdziałalności przedsiębiorstwa.
(C) Instytut Informatyki, Politechnika Poznańska 68
Funkcja (function)
� Składowa operacjaprzedsiębiorstwa.
(C) Instytut Informatyki, Politechnika Poznańska 69
Funkcjespecjalnego znaczenia
� Funkcje wspólne (common function).� Funkcje atomowe (atomic function) �
funkcje, które nie podlegają dalszejdekompozycji.
� Funkcje elementarne (elementary function).
Funkcje atomowe
(C) Instytut Informatyki, Politechnika Poznańska 70
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 tylkoreferencje do funkcji głównej.
Funkcje wspólne
Funkcja główna
(C) Instytut Informatyki, Politechnika Poznańska 71
Funkcje elementarne
� Funkcje elementarne pozostawiają systemw stanie spójnym, wykonanie funkcjielementarnej, nie będącej funkcją atomową,wymaga pomyślnej realizacji wszystkich jejfunkcji podrzędnych.
(C) Instytut Informatyki, Politechnika Poznańska 72
FunctionHierarchy Diagrammer
� Pozwala na utworzenie diagramu hierarchiifunkcji 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).
RepozytoriumOracle Designer 6i
(C) Instytut Informatyki, Politechnika Poznańska 74
RepozytoriumOracle Designer 6i
� Repozytorium Oracle Designer 6i jestmiejscem składowania wszelkich obiektówtworzonych na diagramach.
� Dzięki repozytorium obiekty utworzone np.na diagramie zależności procesów możnaimportować do pozostałych diagramów.
(C) Instytut Informatyki, Politechnika Poznańska 75
RepositoryObject Navigator
� Służy do przeglądania i modyfikacjiobiektów składowanych wrepozytoriumOracle Designer6i.
� Dla każdegoobiektu dostępnajest lista własności.
Zależności pomiędzy diagramami
(C) Instytut Informatyki, Politechnika Poznańska 77
Zależności pomiędzy diagramami
� Wszystkie trzy metody modelowaniaprocesów i funkcji, tj. konstrukcjadiagramów zależności procesów,modelowania przepływów danych itworzenie hierarchii funkcji przenikają sięwzajemnie operując na tych samychobiektach.
(C) Instytut Informatyki, Politechnika Poznańska 78
Funkcje � procesy
(C) Instytut Informatyki, Politechnika Poznańska 79
Składnice danych
(C) Instytut Informatyki, Politechnika Poznańska 80
Przepływy
(C) Instytut Informatyki, Politechnika Poznańska 81
Hierarchie funkcji
Sposoby i wskazówki dotyczącetworzenia diagramów i modeli
(C) Instytut Informatyki, Politechnika Poznańska 83
Poziomy modelowania systemuinformatycznego
• Poziom przedsiębiorstwa � dotyczy podstawowychobszarów działalności przedsiębiorstwa.
• Poziom systemu � wyznacza sposób, w jaki wymaganiaprzedsiębiorstwa są lub mogą być realizowane. Funkcje natym poziomie pokazują czynności pracowników.
• Poziom programu � pokazuje sposób fizycznej realizacjifunkcji systemu przez określone mechanizmykomputerowe, biurowe itp. Funkcje na tym poziomiepokazują elementarne operacje.
(C) Instytut Informatyki, Politechnika Poznańska 84
Wykorzystanie metodmodelowania
MMeettooddyy mmooddeelloowwaanniiaa
PPoozziioomm pprrzzeeddssiięębbiioorrssttwwaa PPoozziioomm ssyysstteemmuu PPoozziioomm
pprrooggrraammuu
HHiieerraarrcchhiiaa ffuunnkkccjjii PPooddssttaawwoowwaa PPooddssttaawwoowwaa PPooddssttaawwoowwaa
DDiiaaggrraamm zzaalleeżżnnoośśccii pprroocceessóóww
OOppccjjoonnaallnnaa PPooddssttaawwoowwaa OOppccjjoonnaallnnaa
DDiiaaggrraammyy pprrzzeeppłłyywwóóww
ddaannyycchh OOppccjjoonnaallnnaa PPooddssttaawwoowwaa OOppccjjoonnaallnnaa
(C) Instytut Informatyki, Politechnika Poznańska 85
Podstawowe podejścia przymodelowaniu funkcji
� Modelowanie z góry do dołu � polega nadekompozycji kolejnych poziomówrozpoczynając od pojedynczej funkcji głównejreprezentującej działalność przedsiębiorstwa.
� Modelowanie z dołu do góry � na początkuidentyfikuje się funkcje przedsiębiorstwa, anastępnie dla każdej z nich próbuje się znaleźćodpowiednie miejsce w hierarchii funkcji.
� Technika mieszana.
(C) Instytut Informatyki, Politechnika Poznańska 86
Kiedy zakończyćdekompozycję funkcji?
� Metoda funkcjielementarnych:
Hierarchia funkcji jesttraktowana jako kompletną,jeżeli przejście od funkcjigłównej do funkcji atomowychmożliwe jest tylko przezfunkcje elementarne.
(C) Instytut Informatyki, Politechnika Poznańska 87
Mechanizmy
� Powiązania określonych funkcji ze sposobem ichrealizacji.
� Typy mechanizmów:� myślowy,� komputerowy,� mechaniczny,� ręczny.
� Unikanie mechanizmów w nazwach i opisach funkcjipozwala budować modele bardziej ogólne. Pobudza doreorganizacji, usprawniania lub wprowadzania nowychmetod realizacji określonych zadań.
(C) Instytut Informatyki, Politechnika Poznańska 88
Tworzenie modeliinformacyjnych
� Warunkiem tworzenia poprawnych iefektywnych modeli informacyjnych jeststosowanie określonych konwencji i zasad.
� Nie dopuszczają one do powstawanianiejednoznaczności i ułatwiają zrozumieniepotrzeb informacyjnych przedsiębiorstwa.
(C) Instytut Informatyki, Politechnika Poznańska 89
Zasady dotyczące encji
!Każda instancja encji musi być wyraźnieodróżnialna od wszystkich innych instancji tejencji.
� 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 90
Zasady dotyczące związków
• Nazwy pojawiające się na końcach związków powinnytworzyć poprawne konstrukcje zdaniowe zpoprzedzającymi je zwrotami �musi być� dla związkówwymaganych lub �może być� dla związkówopcjonalnych.
• Związek nie może wchodzić w skład więcej niżjednego łuku.
• Każdy związek po zakończeniu etapu analizy powinienbyć kompletny informacyjnie.
(C) Instytut Informatyki, Politechnika Poznańska 91
Nieprawidłowe związki
(C) Instytut Informatyki, Politechnika Poznańska 92
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 powinienbyć informacyjnie kompletny.
(C) Instytut Informatyki, Politechnika Poznańska 93
Zasady dotyczące związkówwykluczających
� Łuk musi obejmować co najmniej dwa końcezwią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 wtym łuku musi być również częściąjednoznacznego identyfikatora dla tej encji.
(C) Instytut Informatyki, Politechnika Poznańska 94
Niepoprawne związkiwykluczające
� Łuki mogą dotyczyć końców związków, którealbo wszystkie są obowiązkowe, albo wszystkieopcjonalne.
� Łuki nie mogą obejmować związków dotyczącychróżnych encji.
(C) Instytut Informatyki, Politechnika Poznańska 95
Reguły rozmieszczania elementówna diagramie związków encji
� Końce związków �wiele� umieszcza się na górzelub po lewej stronie, dzięki temu obiekty o dużymznaczeniu, służące do opisywania innychobiektów, są grupowane i znajdują się na dole poprawej stronie diagramu.
� Na diagramach rozmiar i kształt encji nie jestistotny � wszystko ma służyć przejrzystości iczytelności diagramu.
(C) Instytut Informatyki, Politechnika Poznańska 96
Zamiana związków wiele do wiele
Historyczność
REZERWACJA# * status
* data
REZERWACJA# * data
STATUS# * wartość# * od dnia ° do dnia
Encja intersekcji
Encje referencyjne
Budowanie bazy danych
(C) Instytut Informatyki, Politechnika Poznańska 98
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ówzwiązków encji do schematulogicznego bazy danych
krok 2. Generowanie schematu fizycznegobazy danych
(C) Instytut Informatyki, Politechnika Poznańska 100
Budowanie bazy danychkrok 1.
Transformowanie diagramów związkówencji 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 encjiSposoby:
� transformacja do pojedynczej relacji� transformacja do oddzielnych relacji� transformacja do oddzielnych relacji
połączonych ograniczeniamireferencyjnymi w łuku
(C) Instytut Informatyki, Politechnika Poznańska 104
Sposób pierwszyZasady:
� jedna relacja� schemat relacji: atrybuty wszystkich encji z
hierarchii + dodatkowa kolumna, określającatyp 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
Transformacja hierarchii
(C) Instytut Informatyki, Politechnika Poznańska 105
Sposób drugiZasady:
� jedna relacja dla każdego podtypu� schemat relacji: atrybuty nadtypu + atrybuty
podtypuKiedy 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
Transformacja hierarchii
(C) Instytut Informatyki, Politechnika Poznańska 106
Sposób trzeci
Kiedy stosować:� związki przywiązane zarówno do nadtypu jak
i podtypówZalety:
� zachowanie obowiązkowości atrybutóww podtypach
� łatwy dostęp do informacji z nadtypu
Wady:� komplikacja schematu� konieczność stosowania
połączeń (SQL)
Zasady:� jedna relacja z atrybutami wspólnymi, dla każdego podtypu
osobna relacja z jego atrybutami specyficznymi� relacje połączone kluczami obcymi w łuku
Transformacja hierarchii
(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ówzwiązku:� krotności (1:1, 1:N, M:N)� obowiązkowości/opcjonalności
(C) Instytut Informatyki, Politechnika Poznańska 108
Związek 1:1 jednostronnieobowiązkowy
Zasady:� do relacji impl. encję wiązaną
obowiązkowo zostaje dodanyklucz obcy, wskazujący naklucz podstawowy relacjiimpl. encję wiązanąopcjonalnie (z drugiej stronyzwiązku)
� na kolumny klucza obcegozostaje nałożone ograniczenienot null
Transformacja związków
TABLICA_A (ID_A PRIMARY KEY,ATR_1 NULL)
TABLICA_B (ID_B PRIMARY KEY,ATR_1 NOT NULLID_A NOT NULL REFERENCES
TABLICA_A(ID_A))
(C) Instytut Informatyki, Politechnika Poznańska 109
Związek 1:1 obustronnieopcjonalny
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ącyna klucz podstawowy z relacji impl. drugą encję w związku
� na kolumny klucza obcego nałożone zostaje ograniczenie null
Transformacja związków
(C) Instytut Informatyki, Politechnika Poznańska 110
Związek 1:NZasady:
� do relacji impl. encję po stronie �N�związku zostaje dodany kluczobcy, wskazujący na kluczpodstawowy relacji impl. encję postronie �1� związku
� obowiązkowość związku postronie �N� - ograniczenie not nullna kolumny w kluczu obcym
� opcjonalność związku po stronie�N� - ograniczenie null nakolumny w kluczu obcym
� obowiązkowość/opcjonalnośćzwiązku po stronie �1� nie mawpływu na transformację
Transformacja związków
TABLICA_A (ID_A PRIMARY KEY,ATR_1 NULLID_B NOT NULL REFERENCES
TABLICA_B(ID_B))
TABLICA_B (ID_B PRIMARY KEY,ATR_1 NOT NULL)
(C) Instytut Informatyki, Politechnika Poznańska 111
Związek M:NZasady:
� zostaje utworzona nowarelacja
� w nowej relacji zostająutworzone klucze obce,wskazujące na kluczepodstawowe relacji wzwiązku
� kolumny obu kluczy obcychtworzą klucz podstawowyrelacji
Transformacja związków
TABLICA_A (ID_A PRIMARY KEY,ATR_1 NULL)
TABLICA_B (ID_B PRIMARY KEY,ATR_1 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
(C) Instytut Informatyki, Politechnika Poznańska 113
Krok 1.Uruchomić narzędzie Database DesignTransformer z grupy Transform PreliminaryDesigns
Proces transformacji
(C) Instytut Informatyki, Politechnika Poznańska 114
Krok 2 - opcje transformacji� transformacja wg
ustawień domyślnych� transformacja wg
ustawieńużytkownika
Proces transformacji
(C) Instytut Informatyki, Politechnika Poznańska 115
Dostępne ustawienia
Proces transformacji
� wybór encji do transformacji - domyślniewszystkie
� 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
Dostępne ustawienia (2)
Proces transformacji
� opcje ograniczeń referencyjnych:� usuwanie kaskadowe - domyślnie zabronione� modyfikowanie kaskadowe - domyślnie
zabronione� tworzenie sztucznych kluczy podstawowych
relacji (w postaci dodatkowej kolumnynumerycznej) - domyślnie tylko dla encji bezunikalnych 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
Krok 3 - uruchomienie procesuUruchomienietransformacji -przycisk Run
Proces transformacji
(C) Instytut Informatyki, Politechnika Poznańska 118
Wynik
Proces transformacji
Umieszczone repozytorium systemu definicje:� relacji� kolumn� ograniczeń integralnościowych� indeksów� liczników - dla sztucznych kluczy
podstawowych
(C) Instytut Informatyki, Politechnika Poznańska 119
Wynik (2)
Proces transformacji
Podgląd definicji w repozytorium - narzędzieDesign Editor z grupy Design and Generate
(C) Instytut Informatyki, Politechnika Poznańska 120
Design EditorUmożliwia:
� przeglądanie i ręczną modyfikację powstałego w wynikutransformacji 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 (ograniczeniareferencyjne)
(C) Instytut Informatyki, Politechnika Poznańska 121
Przeglądanie i modyfikacjaschematu logicznego
Zakładka Server Model, gałęzie:
Design Editor
� Relational TableDefinitions - relacje,kolumny, ograniczeniaitegralnościowe, inne
� Relational ViewDefinition - perspektywy
� Sequence Definitions -liczniki
� PL/SQL Definitions -kod składowany
(C) Instytut Informatyki, Politechnika Poznańska 122
Tworzenie diagramuschematu logicznego
� Z menu kontekstowegowybrać Show on NewDiagram
Design Editor
� Zaznaczyć obiekty (relacje lub perspektywy), które mają byćuwidocznione na diagramie
(C) Instytut Informatyki, Politechnika Poznańska 123
Przykładowy diagramuschematu logicznego
Design Editor
(C) Instytut Informatyki, Politechnika Poznańska 124
Jak to zrobić?
Jak przetransformować hierarchię encji wsposób inny niż domyślny?
(C) Instytut Informatyki, Politechnika Poznańska 125
Transformacja do oddzielnych relacjikrok 1. Uruchomić Database Design Transformerkrok 2. Zaznaczyć opcję Customize the Database
Transformer i wybrać zakładkę Table Mappings
Jak to zrobić - hierarchia encji
(C) Instytut Informatyki, Politechnika Poznańska 126
Transformacja do oddzielnych relacjikrok 3. Zmienić zbiór encji do transformacji -
wyłączyć ze zbioru encję-nadtyp, dodać encje-podtypy
Jak to zrobić - hierarchia encji
(C) Instytut Informatyki, Politechnika Poznańska 127
Transformacja do oddzielnych relacjiJak to zrobić - hierarchia encji
krok 4. Przystąpić do transformacji
Wynik:
(C) Instytut Informatyki, Politechnika Poznańska 128
Transformacja do relacji w łukukrok 1. Uruchomić Database Design Transformerkrok 2. Zaznaczyć opcję Customize the Database
Transformer i wybrać zakładkę Table Mappings
Jak to zrobić - hierarchia encji
(C) Instytut Informatyki, Politechnika Poznańska 129
Transformacja do relacji w łukukrok 3. Zmienić zbiór encji do transformacji - włączyć
do zbioru encję-nadtyp wraz z encjami-podtypami
Jak to zrobić - hierarchia encji
(C) Instytut Informatyki, Politechnika Poznańska 130
Transformacja do relacji w łukuJak to zrobić - hierarchia encji
krok 4. Zmienić typ elementów do transformacji -zakładka Run Options - tylko definicje relacji (bezkolumn i ograniczeń integralnościowych)
krok 5. Uruchomić transformację. Wygenerowanezostaną jedynie definicje relacji. Pozostać wnarzędziu
(C) Instytut Informatyki, Politechnika Poznańska 131
Transformacja do relacji w łukuJak to zrobić - hierarchia encji
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
Transformacja do relacji w łukuJak to zrobić - hierarchia encji
krok 8. Przystąpić do transformacji
Wynik:
(C) Instytut Informatyki, Politechnika Poznańska 133
Budowanie bazy danychkrok 2.
Generowanie schematu fizycznegobazy danych
(C) Instytut Informatyki, Politechnika Poznańska 134
Przebieg procesu
krok 1. Uruchomić narzędzie Design Editor. Przejśćna zakładkę Server Model, rozwinąć gałąźsystemu aplikacji
Generacja bazy danych
krok 2. Wybrać pozycjęGenerate Database fromServer Model z menuGenerate
(C) Instytut Informatyki, Politechnika Poznańska 135
Przebieg procesukrok 3. Ustalić parametry generacji - zakładka Target:
Generacja bazy danych
� 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
Przebieg procesukrok 4. Wybrać obiekty do generacji - zakładka Objects:
Generacja bazy danych
� Typ obiektu:� relacje� liczniki� perspektywy i inne
� Konkretny obiekt
(C) Instytut Informatyki, Politechnika Poznańska 137
Przebieg procesukrok 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
Generacja bazy danych
Budowanie aplikacji
(C) Instytut Informatyki, Politechnika Poznańska 139
Dane wejścioweDiagramy 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
WynikDefinicje aplikacji w wybranym językuprogramowania
(C) Instytut Informatyki, Politechnika Poznańska 140
Przebieg procesu
krok 1. Transformowanie definicji funkcji doprojektów aplikacji
krok 2. Modyfikacja struktury aplikacji
krok 3. Generowanie aplikacji w wybranymjęzyku programowania
(C) Instytut Informatyki, Politechnika Poznańska 141
Budowanie aplikacjikrok 1.
Transformowanie definicji funkcji doprojektó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
Które funkcje transformować?
Reguły transformacji
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
Które funkcje transformować?
Reguły transformacji
(C) Instytut Informatyki, Politechnika Poznańska 145
Co wpływa na typ aplikacji?
Reguły transformacji
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
Co wpływa na typ aplikacji? (2)
Reguły transformacji
Jak określić typ aplikacji?� na podstawie zestawu
operacji, jakietransformowana funkcjarealizuje na encjach
� na podstawie własnościReakcja (ang. Response)funkcji (ang. Immediate -Natychmiastowa, ang.Overnight - Odroczona)
(C) Instytut Informatyki, Politechnika Poznańska 147
Co wpływa na typ aplikacji? (3)
Reguły transformacji
Zasady:� encje, których używa funkcja, nie zostały zaimplementowane jako
relacje - typ aplikacji nieokreślony (musi zostać wskazany przezprojektanta)
� własność Reakcja określono na Natychmiastowa - typ aplikacji toformularz
� funkcja realizuje tylko operacje odczytu na encjach,zaimplementowanych jako relacje - typ aplikacji to wydruk,
� własność Reakcja określono na Odroczona - typ aplikacji toaplikacja użytkowa
� w pozostałych przypadkach - typ aplikacji to formularz
(C) Instytut Informatyki, Politechnika Poznańska 148
Łączenie funkcji
Reguły transformacji
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
Proces transformacji
(C) Instytut Informatyki, Politechnika Poznańska 150
Krok 1.Uruchomić narzędzie Application DesignTransformer z grupy Transform PreliminaryDesigns
Proces transformacji
(C) Instytut Informatyki, Politechnika Poznańska 151
Krok 2. - ustawienie parametrówProces transformacji
� 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
Krok 3. - uruchomienie procesuUruchomienie transformacji - przycisk Generate
Proces transformacji
(C) Instytut Informatyki, Politechnika Poznańska 153
WynikProces transformacji
� Umieszczone w repozytorium systemudefinicje modułów-kandydatów na aplikacje
� Przeglądanie struktury -Design Editor, zakładkaModules, gałąź Modules
(C) Instytut Informatyki, Politechnika Poznańska 154
Budowanie aplikacjikrok 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 dopuszczalnychoperacjach na relacji
� tabela look-up - uzupełnia dane z tabeli bazowej o dane zrelacji 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 lublook-up; najczęściej służą do wyświetlania danych zkolumn relacji
� element niezwiązany - wyświetla informacje wyliczane, niema 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 jejzakończeniu; służą do komunikacji pomiędzy aplikacjami
(C) Instytut Informatyki, Politechnika Poznańska 157
Struktura aplikacji - składniki (3)Każdy element strukturyposiada 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 interfejsuaplikacji
Przełączanie pomiędzy widokami -przyciski
(C) Instytut Informatyki, Politechnika Poznańska 159
Diagramy struktury aplikacji (2)
widok danych widok interfejsu
moduł
podrzędnatabelabazowa
tabelalook-up
element związany
komponent
elementniezwiązanypowiązania
okno
zawartośćokna
elementinterfejsu
nadrzędnatabelabazowa
Proces modyfikacjistruktury aplikacji
(C) Instytut Informatyki, Politechnika Poznańska 161
Struktura aplikacji po transformacji
� jedna tabela bazowa dla każdej relacji,implementującej encję używaną przez funkcję
� elementy związane, odpowiadającekolumnom relacji
� argumenty aplikacji, odpowiadająceatrybutom z przepływów wejściowych iwyjś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
Krok 1.Zaakceptowanie modułów-kandydatówjako aplikacji do ostatecznej generacji -ustawienie własności Candidate? na No.Wybór języka implementacji aplikacji.
Proces modyfikacji struktury
kandydat
formularz
wydruk
aplikacja użytkowa
(C) Instytut Informatyki, Politechnika Poznańska 163
Krok 2.Utworzenie związków pomiędzytabelami bazowymi� modelują hierarchię nadrzędny-
podrzędny� korzystają z definicji ograniczeń
referencyjnych między relacjamiMetody:� tworzenie automatyczne� tworzenie ręczne
Proces modyfikacji struktury
(C) Instytut Informatyki, Politechnika Poznańska 164
Krok 2. - wynik
Proces modyfikacji struktury
(C) Instytut Informatyki, Politechnika Poznańska 165
Krok 3.Utworzenie związku typu look-up
Proces modyfikacji struktury
(C) Instytut Informatyki, Politechnika Poznańska 166
Krok 4.Określenie własności poszczególnych składników struktury, np.zmiana typu elementu
Proces modyfikacji struktury
(C) Instytut Informatyki, Politechnika Poznańska 167
Krok 5. - dodanie elementuniezwią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ązanegoLICZBA_PRACOWNIKÓW - oblicza, ilu pracowników jestzatrudnionych w danym zespole
Proces modyfikacji struktury
(C) Instytut Informatyki, Politechnika Poznańska 168
Krok 5a)Dodanie elementu:
Proces modyfikacji struktury
(C) Instytut Informatyki, Politechnika Poznańska 169
Krok 5b)Proces modyfikacji struktury
Określenie własności:
(C) Instytut Informatyki, Politechnika Poznańska 170
Krok 5. - WynikProces modyfikacji struktury
(C) Instytut Informatyki, Politechnika Poznańska 171
Budowanie aplikacjikrok 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 generacjiZbiór ustawień, określających:
� sposób implementacjistruktury
� 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
Proces generacji aplikacji
(C) Instytut Informatyki, Politechnika Poznańska 176
Krok 1.Uruchomić generator aplikacji
Proces generacji aplikacji
lub
(C) Instytut Informatyki, Politechnika Poznańska 177
Krok 2.Ustawić parametry - przycisk Options:
Proces generacji aplikacji
� lokalizacja wersji źródłowychaplikacji (system plików czybaza danych)
� lokalizacja wersjiwykonywalnych
� czy aplikacja ma zostaćuruchomiona po generacji
(C) Instytut Informatyki, Politechnika Poznańska 178
Krok 3.Uruchomić proces - przycisk Start
Proces generacji aplikacji
Przebieg procesu, komunikaty
(C) Instytut Informatyki, Politechnika Poznańska 179
Wynik
Proces generacji aplikacji
(C) Instytut Informatyki, Politechnika Poznańska 180
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ż dowygenerowania w pełni funkcjonalnej aplikacji.
Proces generacji aplikacji