Wykorzystanie oprogramowania Oracle Designer do budowy systemów informatycznych

Bartosz Bębel, Krzysztof JankiewiczInstytut Informatyki, Politechnika Poznańska

Bartosz.Bebel@cs.put.poznan.pl Krzysztof.Jankiewicz@cs.put.poznan.pl

(C) Instytut Informatyki, Politechnika Poznańska 2

Cykl życia systemu informacyjnego Metodyka Oracle CASE (CASE*Method)

STRATEGIA

ANALIZA

PROJEKTOWANIE

IMPLEMENTACJA

WDROŻENIE

EKSPLOATACJA

DOKUMENTACJA

Metodyka Oracle CASE – strategia

• ogólny model przedsiębiorstwa,ogólny model przedsiębiorstwa, w wymagania, ymagania, harmonogram prac, ograniczenia finansowe i harmonogram prac, ograniczenia finansowe i technicznetechniczne,,

• modele: modele: – procesów (PD), procesów (PD), – danych (ERD), danych (ERD), – funkcji (FHD), funkcji (FHD), – przepływów (DFD)przepływów (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ów (PD), procesów (PD), – danych (ERD), danych (ERD), – funkcji (FHD), funkcji (FHD), – przepływów (DFD)przepływów (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 i techniczna.

STRATEGIA

ANALIZA

PROJEKTOWANIE

IMPLEMENTACJA

WDROŻENIE

EKSPLOATACJA

DOKUMENTACJA

Cykl życia systemu informatycznego – Oracle Designer 6i

strategia + analizastrategia + analiza

projektowanieprojektowanie

ImplementImplementacja acja

dokumentacjadokumentacja

Metodyki realizacji projektów informatycznych

Projektowanie SI z wykorzystaniem Designer6i

• narzędzia do modelowania: PD, ERD, FHD, DFD,

• struktura logiczna bazy danych (model relacyjny), definicje aplikacji,

• generowanie obiektów bazy danych i kodu po stronie serwera,

• generowanie aplikacji.

• transformacje,

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.

Metodyka IE (Information Engineering)

• technika top-down,

• główny nacisk na model danych,

• specyfikacja funkcji przetwarzających dane.

Metodyka PMD (Process Model Driven)

• często używana jako punkt początkowy dla rozwoju systemów informatycznych,

• pozwala na identyfikację podstawowych procesów w organizacji przed analizą zakresu informacji potrzebnej do ich realizacji.

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.

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.

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.

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ślonych kompetencjach.

Proces (process)

• Opisuje operację składową działalności przedsię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 i materiałowe oraz zależności czasowe pomiędzy procesami.

• Czy przepływ jest wystarczający do rozpoczęcia realizacji procesu przeznaczenia?

• Warunek oraz częstość wyboru jednego z wielu przepł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ślonych procesów.

• Typy wyzwalaczy:– okresowy (time),– systemowy

(system),– inny (other).

Składnica (store)

• Magazyn informacji (zbiór relacji, arkuszy kalkulacyjnych 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ów składowych procesów

Identyfikacja procesów wymagających reorganizacji

Import istniejących obiektówdo diagramów

Modelowanie związków encji

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

Diagramy związków encji

Obiekty występujące na diagramach związków encji

Związki jeden do wiele

Związki wiele do wiele

Związki jedendo jeden

Encja (entity)

• Encja – obiekt rzeczywisty lub niematerialny mający znaczenie dla organizacji, o którym informacje muszą być przechowywane.

Encja (entity)

• Każda encja musi być jednoznacznie identyfikowalna – to znaczy, że każda instancja (wystąpienie) encji musi być wyraźnie odróżnialna od wszystkich innych instancji tego typu encji. Uzyskuje się to poprzez definicję jednoznacznego identyfikatora.

Unikalny identyfikator (unique identifier)

• Unikalny identyfikator to 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.

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 JedenWymagany

Opcjonalny

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ści stosowanych do definicji atrybutów.

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

domen będą wpływały na zawartość relacji CG_REF_CODES.

Konstrukcje specjalne

• Związki wykluczające

• Hierarchie encji

• Związki nieprzechodnie

Związki wykluczające• Występują w postaci łuku łączącego dwa (lub więcej)

końce zwią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 jest albo na poziomie instytutu, albo na poziomie zespołu.

lub (precyzyjnie)

Każdy Pracownik musi być albo zatrudniony w jednym i tylko jednym instytucie albo zatrudniony w jednym i tylko jednym zespole.

Tworzenie związku wykluczającego

Hierarchie encji• Hierarchie encji składają się z encji-nadtypu i zawartych w

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

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

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.

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.

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ów przepł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 przez określony czas.

Etykieta Nazwa opisowa

Składnica danych

• Typy składnic danych:– komputerowe (computer),– papierowe (manual),– inne (transient).

Przepływ danych (dataflow)

• Przepływ danych jest nazwaną kolekcją encji i ich atrybutów przekazywanych między dwoma procesami, procesem a składnicą lub procesem a bytem zewnętrznym.

Przepływ danych (dataflow)

• Przepływ danych jest chwilowym przeniesieniem danych.

• Gdy osiągną one cel (proces) decyzja o tym co się z nimi dalej stanie zależy od procesu przyjmującego. Jeśli odbiorca zignoruje nadchodzące dane zostaną one utracone na zawsze.

Przepływ danych a składnica

• Gdy przepływ danych dotrze do składnicy danych, jej zawartość jest modyfikowana zawartością przepływu. Może to oznaczać dodanie, modyfikację lub usunięcie danych znajdujących się w składnicy.

• Składnica danych służy do przechwytywania na stałe chwilowego przepływu danych.

Proces (function)

• Opisuje składową działalności przedsię-biorstwa.

Przepływ danych a proces• Zawartość przepływu wychodzącego z funkcji uzupełnia

zawartość ENTITY USAGES dla tej funkcji.• Zawartość przepływu

wchodzącego do funkcji nie ma wpływu na ENTITY USAGES.

• Zawartość ENTITY USAGES dla funkcji nie ma żadnego wpływu na zawartość przepływów związanych z 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ę lub jednostkę 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 encji przez funkcje,

– przechodzenie do składowych procesów lub procesów znajdujących się wyżej w hierarchii.

Modelowanie hierarchii funkcji

• Modelowanie hierarchii funkcji tworzy diagramy pokazujące dekompozycję funkcji na różnych poziomach działalności przedsiębiorstwa.

Funkcja (function)

• Składowa operacja przedsiębiorstwa.

Funkcje specjalnego znaczenia

• Funkcje wspólne (common function).

• Funkcje atomowe (atomic function) – funkcje, które nie podlegają dalszej dekompozycji.

• 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 tylko referencje do funkcji głównej.

Funkcje wspólne

Funkcja główna

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.

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

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.

Repository Object Navigator

• Służy do przeglądania i modyfikacji obiektów składowanych w repozytoriumOracle Designer6i.

• Dla każdegoobiektu dostępnajest lista własności.

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.

Funkcje – procesy

Składnice danych

Przepływy

Hierarchie funkcji

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.

Wykorzystanie metod modelowania

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

Kiedy zakończyć dekompozycję funkcji?

• Metoda funkcji elementarnych:

Hierarchia funkcji jest traktowana jako kompletną, jeżeli przejście od funkcji głównej do funkcji atomowych możliwe jest tylko przez funkcje elementarne.

Mechanizmy

• Powiązania określonych funkcji ze sposobem ich realizacji.

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

Tworzenie modeli informacyjnych

• Warunkiem tworzenia poprawnych i efektywnych modeli informacyjnych jest stosowanie określonych konwencji i zasad.

• Nie dopuszczają one do powstawania niejednoznaczności i ułatwiają zrozumienie potrzeb informacyjnych przedsiębiorstwa.

Zasady dotyczące encji

Każda instancja encji musi być wyraźnie odróżnialna od wszystkich innych instancji tej encji.

• Każda encja powinna:być związana co najmniej jednym związkiem,posiadać co najmniej dwa atrybuty,być wykorzystywana przez co najmniej jedną funkcję,

– po zakończeniu etapu analizy być kompletna informacyjnie.

Zasady dotyczące zwią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.

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 powinien być informacyjnie kompletny.

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.

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.

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.

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ów związków encji do schematu logicznego bazy danych

krok 2. Generowanie schematu fizycznego bazy danych

Budowanie bazy danychkrok 1.

Transformowanie diagramów związków encji 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 encji

Sposoby:– 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ą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

Transformacja hierarchii

Sposób drugiZasady:

– 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

Sposób trzeci

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)

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ów związku:– krotności (1:1, 1:N, M:N)– obowiązkowości/opcjonalności

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

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

Związek 1:NZasady:

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

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

– w nowej relacji zostają utworzone klucze obce, wskazujące na klucze podstawowe relacji w związku

– kolumny obu kluczy obcych tworzą klucz podstawowy relacji

TABLICA_A (ID_A PRIMARY KEY,ATR_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 Design Transformer z grupy Transform Preliminary Designs

Krok 2 - opcje transformacji– transformacja wg

ustawień domyślnych

– transformacja wg ustawień użytkownika

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

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

Krok 3 - uruchomienie procesu

Uruchomienie transformacji - 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ędzie Design Editor z grupy Design and Generate

Design Editor

Umożliwia:– przeglądanie i ręczną modyfikację powstałego w wyniku

transformacji schematu logicznego bazy danych

– definiowanie dodatkowych obiektów schematu logicznego:• liczników

• perspektyw

• kodu PL/SQL

– utworzenie diagramu schematu modelu relacyjnego - pokazuje połączenia między relacjami (ograniczenia referencyjne)

Przeglądanie i modyfikacja schematu logicznego

Zakładka Server Model, gałęzie:

Design Editor

• Relational Table Definitions - relacje, kolumny, ograniczenia itegralnościowe, inne

• Relational View Definition - perspektywy

• Sequence Definitions - liczniki

• PL/SQL Definitions - kod składowany

Tworzenie diagramuschematu logicznego

• Z menu kontekstowego wybrać Show on New Diagram

Design Editor

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

Przykładowy diagramu schematu logicznego

Design Editor

Jak to zrobić?

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

Transformacja do oddzielnych relacjikrok 1. Uruchomić Database Design Transformer

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

krok 4. Przystąpić do transformacji

Wynik:

Transformacja do relacji w łukukrok 1. Uruchomić Database Design Transformer

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

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 from Server Model z menu Generate

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

Definicje aplikacji w wybranym języku programowania

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

Budowanie aplikacjikrok 1.

Transformowanie definicji funkcji do projektó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, jakie transformowana funkcja realizuje na encjach

– na podstawie własności Reakcja (ang. Response) funkcji (ang. Immediate - Natychmiastowa, ang. Overnight - Odroczona)

Co wpływa na typ aplikacji? (3)

Zasady:– encje, 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

Łą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 Design Transformer z grupy Transform Preliminary Designs

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

Krok 3. - uruchomienie procesu

Uruchomienie transformacji - przycisk Generate

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

• Przeglądanie struktury - Design Editor, zakładka Modules, gałąź Modules

Modyfikacja struktury aplikacji

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ę

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

Struktura aplikacji - składniki (3)Każdy element struktury posiada listę własności, określających m.in.:

– nazwę elementu

– typ elementu (np. grupa radiowa, lista, itd.)

– dopuszczalne operacje, itd.

Diagramy struktury aplikacji

• Tworzenie - menu kontekstowego danej aplikacji wybrać Show on New Diagram\

• Rodzaje– widok danych - pokazuje wewnętrzną strukturę

aplikacji– widok interfejsu - pokazuje układ interfejsu

aplikacji

Przełączanie pomiędzy widokami - przyciski

Diagramy struktury aplikacji (2)

widok danych widok interfejsu

moduł

podrzędnatabelabazowa

tabelalook-up

element związany

komponent

elementniezwiązany

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

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.

Proces modyfikacji struktury

kandydat

formularz

wydruk

aplikacja użytkowa

Krok 2.Utworzenie związków pomiędzy

tabelami bazowymi• modelują hierarchię nadrzędny-podrzędny• korzystają z definicji ograniczeń

referencyjnych między relacjami

Metody:• tworzenie automatyczne• tworzenie ręczne

Krok 2. - wynik

Krok 3.

Utworzenie związku typu look-up

Krok 4.

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

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

Krok 5a)Dodanie elementu:

Krok 5b)

Określenie własności:

Krok 5. - Wynik

Generowanie aplikacji

Warunki wstępne

• Uporządkowana struktura aplikacji

• Dostępny schemat fizyczny bazy danych, na którym ma pracować aplikacja

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

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łowych aplikacji (system plików czy baza danych)

– lokalizacja wersji wykonywalnych

– 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ż do wygenerowania w pełni funkcjonalnej aplikacji.

Wykorzystanie oprogramowania Oracle Designer do budowy systemów informatycznych

Documents

Transcript of Wykorzystanie oprogramowania Oracle Designer do budowy systemów informatycznych

Agnieszka Gietko graphic designer illustrator portfolio

Instrukcja do instalacji Oracle Linux Enterprise http ...prac.us.edu.pl/~agrzybow/Ora11gR2.pdf · Instrukcja do instalacji Oracle Linux Enterprise ... Dokumentacja Oracle …

Zarządzanie instancją bazy danych Oracle 11g - mst.webd.plmst.webd.pl/_sggw/oracle/laboratorium_nr_2_-_zarz_dzanie_instancj... · W bazie Oracle istnieje wiele widoków w których

GRAPHIC DESIGNER PORTFOLIO 2012

Zarządzanie użytkownikami bazy danych Oracle 11gmst.webd.pl/_sggw/oracle/laboratorium_nr_5_i_6_-_zarz_dzanie_u... · Oracle Virtual Private Databese (VPD) – niskopoziomowe zarządzanie

Doradzamy, projektujemy, tworzymy, wdrażamy i utrzymujemy ...• ISTQB Certificate • Oracle Database: SQL Certified Expert • Oracle Java 7/8 Certified Programmer • Oracle Java

Oracle Discoverer 9.0 - cs.put.poznan.pl · Oracle Discoverer • Oracle Discoverer jest aplikacją wspomagającą w procesach podejmowania decyzji. • Oracle Discoverer pozwala

Matt Cave | food brand designer portfolio

Implementacja metod eksploracji danych - Oracle Data Mining · • Oracle Data Mining to opcja serwera Oracle umożliwiająca eksplorację danych • Eksploracja danych to zautomatyzowane

Ds 42 Designer En

Www Web Designer Wall Com

DESIGNER PORTFOLIO

żYję aby tworzyć concept designer

Coffee Designer

Brandbook Dhiego Designer

Lego Digital Designer

Monika (Interior designer) - Portfolio

Oracle versus MySQLi.wp.pl/.../InfoShare2007_SCichyRSokolowski_OraclevsMysql.pdf · SQL*PLUS • SET AUTOTRACE ON {EXPLAIN|STATISTICS} Szybciej… z Oracle-em Oracle ma wi ęcej mo

Brochure Deloitte - Oracle

Portfolio: Victor R. Soto, Graphic Designer