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

Bartosz.Bebel@cs.put.poznan.plKrzysztof.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

�� 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

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

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

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

Cykl życia systemu informatycznego� Oracle Designer 6i

strategiastrategia + + analizaanaliza

projektowanieprojektowanie

ImplementImplementacjaacja

dokumentacjadokumentacja

Metodyki realizacji projektówinformatycznych

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,

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.

Metodyka IE(Information Engineering)

� technika top-down,� główny nacisk na

model danych,� specyfikacja funkcji

przetwarzającychdane.

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.

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

� 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.

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.

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.

Obiekty diagramu procesów

Jednostkaorganizacyjna

Proces

Składnica

Zależność Wyzwalacz

Jednostka organizacyjna(organization unit)

� Określa miejsce realizacjiposzczególnych procesów.

� Może dotyczyć jednostki organizacyjnejlub osoby o określonychkompetencjach.

Proces (process)

� Opisuje operację składową działalnościprzedsiębiorstwa.

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).

Przepływ � zależność (flow)

� Pokazuje przepływy informacyjne imateriałowe oraz zależności czasowepomiędzy procesami.

� 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).

� Typy przepływów:� przepływ (flow),� temporalny (temporal) �

zależność czasowa,� danych (data),� materialny (material).

Wyzwalacz (trigger)

� Bodziec do podjęcia realizacji określonychprocesów.

� Typy wyzwalaczy:� okresowy (time),� systemowy

(system),� inny (other).

Składnica (store)

� Magazyn informacji (zbiór relacji, arkuszykalkulacyjnych akt itp.), materiałów lub inny.

Składnica (store)

� Typy składnic:� informacyjna (data store),� materialna (material store),� ogólna (store).

Wynik (outcome)

� Jest efektem realizacji sekwencji czynności.� Typy wyników:

� okresowy (time),� systemowy

(system),� inny (other).

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.

Modelowanie elementówskładowych procesów

Identyfikacja procesówwymagających reorganizacji

Import istniejących obiektówdo diagramów

Modelowanie związków encji

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.

Diagramy związków encji

Obiekty występujące nadiagramach związków encji

Związki jeden do wiele

Związki wiele do wiele

Związki jedendo jeden

Encja (entity)

� Encja � obiekt rzeczywisty lub niematerialnymający znaczenie dla organizacji, o któryminformacje muszą być przechowywane.

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.

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.

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 zbiór wartości dopuszczalnych.

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

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.

Dziedzina (domain)

� Zbiór reguł kontroli poprawności danych,ich formatów, i innych własnościstosowanych do definicji atrybutów.

Dziedzina (domain)� Wartości dopuszczalne zdefiniowane w ramach

domen będą wpływały na zawartość relacjiCG_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ą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.

Tworzenie związkuwykluczającego

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.

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).

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

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.

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 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.

Obiekty diagramówprzepływów danych

Proces � funkcja

Przepływ

Składnica danych

Byt zewnętrzny

Składnica danych(datastore)

� Składnica danych � kolekcja encji i ich atrybutów,które powinny być przechowywane przezokreś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 ichatrybutów przekazywanych między dwomaprocesami, procesem a składnicą lub procesem abytem zewnętrznym.

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.

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.

Proces (function)� Opisuje

składowądziałalnościprzedsię-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 dofunkcji nie ma wpływuna ENTITY USAGES.

� ZawartośćENTITY USAGES dlafunkcji nie ma żadnegowpływu na zawartośćprzepływów związanychz tą funkcją.

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ą.

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

Modelowaniehierarchii funkcji

� Modelowanie hierarchii funkcji tworzy diagramypokazujące dekompozycję funkcji na różnych poziomachdziałalności przedsiębiorstwa.

Funkcja (function)

� Składowa operacjaprzedsiębiorstwa.

Funkcjespecjalnego znaczenia

� Funkcje wspólne (common function).� Funkcje atomowe (atomic function) �

funkcje, które nie podlegają dalszejdekompozycji.

� Funkcje elementarne (elementary function).

Funkcje atomowe

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

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.

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

� 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.

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

� 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.

Funkcje � procesy

Składnice danych

Przepływy

Hierarchie funkcji

Sposoby i wskazówki dotyczącetworzenia diagramów i modeli

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.

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

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.

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.

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ń.

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.

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.

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.

Nieprawidłowe związki

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.

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.

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.

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.

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

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

Baza danych projektowanego systemu

Przebieg procesu

krok 1. Transformowanie diagramówzwiązków encji do schematulogicznego bazy danych

krok 2. Generowanie schematu fizycznegobazy danych

Budowanie bazy danychkrok 1.

Transformowanie diagramów związkówencji do schematu logicznego bazy

danych

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 encjiSposoby:

� transformacja do pojedynczej relacji� transformacja do oddzielnych relacji� transformacja do oddzielnych relacji

połączonych ograniczeniamireferencyjnymi w łuku

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

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

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 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

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

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))

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

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ę

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)

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

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

Krok 1.Uruchomić narzędzie Database DesignTransformer z grupy Transform PreliminaryDesigns

Krok 2 - opcje transformacji� transformacja wg

ustawień domyślnych� transformacja wg

ustawieńużytkownika

Dostępne ustawienia

� 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

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 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

Krok 3 - uruchomienie procesuUruchomienietransformacji -przycisk Run

Umieszczone repozytorium systemu definicje:� relacji� kolumn� ograniczeń integralnościowych� indeksów� liczników - dla sztucznych kluczy

podstawowych

Wynik (2)

Podgląd definicji w repozytorium - narzędzieDesign Editor z grupy Design and Generate

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)

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

Tworzenie diagramuschematu logicznego

� Z menu kontekstowegowybrać Show on NewDiagram

Design Editor

� Zaznaczyć obiekty (relacje lub perspektywy), które mają byćuwidocznione na diagramie

Przykładowy diagramuschematu logicznego

Design Editor

Jak to zrobić?

Jak przetransformować hierarchię encji wsposób inny niż domyślny?

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

Transformacja do oddzielnych relacjikrok 3. Zmienić zbiór encji do transformacji -

wyłączyć ze zbioru encję-nadtyp, dodać encje-podtypy

Transformacja do oddzielnych relacjiJak to zrobić - hierarchia encji

krok 4. Przystąpić do transformacji

Wynik:

Transformacja do relacji w łukukrok 1. Uruchomić Database Design Transformerkrok 2. Zaznaczyć opcję Customize the Database

Transformer i wybrać zakładkę Table Mappings

Transformacja do relacji w łukukrok 3. Zmienić zbiór encji do transformacji - włączyć

do zbioru encję-nadtyp wraz z encjami-podtypami

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

krok 6. Przy encjach-podtypach zaznaczyć opcję Arc

krok 7. Zmienić typ elementów do transformacji -zakładka Run Options - wszystkie elementy

krok 8. Przystąpić do transformacji

Wynik:

Budowanie bazy danychkrok 2.

Generowanie schematu fizycznegobazy danych

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

Przebieg procesukrok 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

Przebieg procesukrok 4. Wybrać obiekty do generacji - zakładka Objects:

� Typ obiektu:� relacje� liczniki� perspektywy i inne

� Konkretny obiekt

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ą

Budowanie aplikacji

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

Przebieg procesu

krok 1. Transformowanie definicji funkcji doprojektów aplikacji

krok 2. Modyfikacja struktury aplikacji

krok 3. Generowanie aplikacji w wybranymjęzyku programowania

Budowanie aplikacjikrok 1.

Transformowanie definicji funkcji doprojektów aplikacji

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

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

Które 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, jakietransformowana funkcjarealizuje na encjach

� na podstawie własnościReakcja (ang. Response)funkcji (ang. Immediate -Natychmiastowa, ang.Overnight - Odroczona)

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 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

Łą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

Krok 1.Uruchomić narzędzie Application DesignTransformer z grupy Transform PreliminaryDesigns

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

Krok 3. - uruchomienie procesuUruchomienie transformacji - przycisk Generate

WynikProces transformacji

� Umieszczone w repozytorium systemudefinicje modułów-kandydatów na aplikacje

� Przeglądanie struktury -Design Editor, zakładkaModules, gałąź Modules

Modyfikacja struktury aplikacji

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ę

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

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,

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

Diagramy struktury aplikacji (2)

widok danych widok interfejsu

moduł

podrzędnatabelabazowa

tabelalook-up

element związany

komponent

elementniezwiązanypowiązania

zawartośćokna

elementinterfejsu

nadrzędnatabelabazowa

Proces modyfikacjistruktury aplikacji

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

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

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

Krok 2. - wynik

Krok 3.Utworzenie związku typu look-up

Krok 4.Określenie własności poszczególnych składników struktury, np.zmiana typu elementu

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

Krok 5a)Dodanie elementu:

Krok 5b)Proces modyfikacji struktury

Określenie własności:

Krok 5. - WynikProces modyfikacji struktury

Generowanie aplikacji

Warunki wstępne

� Uporządkowana struktura aplikacji� Dostępny schemat fizyczny bazy danych, na

którym ma pracować aplikacja

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

Preferencje generacji (2)Wyświetlanie zbioru preferencji:

� całego systemu aplikacji

� konkretnej aplikacji

Proces generacji aplikacji

Krok 1.Uruchomić generator aplikacji

Krok 2.Ustawić parametry - przycisk Options:

� lokalizacja wersji źródłowychaplikacji (system plików czybaza danych)

� lokalizacja wersjiwykonywalnych

� czy aplikacja ma zostaćuruchomiona po generacji

Krok 3.Uruchomić proces - przycisk Start

Przebieg procesu, komunikaty

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.

wykorzystanie oprogramowania oracle designer do budowy ... · (pd Œ process diagram) Ł struktura...

Documents

wspÓŁpraca gospodarcza pomiĘdzy kazachstanem a polskĄ

wykorzystanie platformy epuap w wymianie informacji między...

koncepcja zagospodarowania skweru pomiędzy ulicą letnią i

analiza powiązań współpracy pomiędzy przedsiębiorcami

z klasą · 2020-01-15 · ubezpieczonych z osobami...

stosunki pomiędzy polską i ukrainą

„usprawnienie połączenia komunikacyjnego pomiędzy...

instytut logistyki i magazynowania klastering i współpraca...

pomiędzy nami góry fragment

pomiędzy ciałem indywidualnym a zbiorowym. praktyki...

obszary i formy współdziałania kuratora oświaty z...

współpraca pomiędzy jst a organizacjami pozarządowymi...

fenomen bezpieczeństwa. pomiędzy zagrożeniem a kulturą

regulamin organizacyjny spółki mazowieckie...

gdzieś pomiędzy

zarządzanie kształtowanie relacji pomiędzy pracodawcą a

fundusze europejskie · web viewbeneficjent zobowiązany...

dialog pomiĘdzy profesorem - ateistĄ a muzuŁmaŃskim ...

komunikacja - puls biznesu · podczas tegorocznego forum...

„jak wykorzystywać synergię pomiędzy funduszami...