Wykorzystanie oprogramowania Oracle Designer do budowy systemów informatycznych
|
|
- Kazimierz Białek
- 5 lat temu
- Przeglądów:
Transkrypt
1 Wykorzystanie oprogramowania Oracle Designer do budowy systemów informatycznych Bartosz Bębel, Krzysztof Jankiewicz Instytut Informatyki, Politechnika Poznańska
2 Cykl życia systemu informacyjnego Metodyka Oracle CASE (CASE*Method) STRATEGIA ANALIZA PROJEKTOWANIE IMPLEMENTACJA DOKUMENTACJA WDROŻENIE EKSPLOATACJA (C) Instytut Informatyki, Politechnika Poznańska 2
3 Metodyka Oracle CASE strategia ogólny model przedsiębiorstwa, wymagania, harmonogram prac, ograniczenia finansowe i techniczne, STRATEGIA modele: procesów (PD), danych (ERD), funkcji (FHD), przepływów (DFD). ANALIZA PROJEKTOWANIE IMPLEMENTACJA DOKUMENTACJA WDROŻENIE EKSPLOATACJA (C) Instytut Informatyki, Politechnika Poznańska 3
4 Metodyka Oracle CASE analiza uzupełnienie informacji zebranych na etapie strategii, szczegółowe, zaakceptowane modele: procesów (PD), danych (ERD), funkcji (FHD), przepływów (DFD), diagramy matrycowe. STRATEGIA ANALIZA PROJEKTOWANIE IMPLEMENTACJA DOKUMENTACJA WDROŻENIE EKSPLOATACJA (C) Instytut Informatyki, Politechnika Poznańska 4
5 Metodyka Oracle CASE projektowanie model danych, struktura logiczna i fizyczna bazy danych, modele aplikacji STRATEGIA (formularzy, ANALIZA raportów, itp.) PROJEKTOWANIE IMPLEMENTACJA DOKUMENTACJA WDROŻENIE EKSPLOATACJA (C) Instytut Informatyki, Politechnika Poznańska 5
6 Metodyka Oracle CASE implementacja i dokumentacja generacja, modyfikacja i testowanie aplikacji, implementacja + strojenie, dokumentacja STRATEGIA użytkownika i ANALIZA techniczna. PROJEKTOWANIE IMPLEMENTACJA DOKUMENTACJA WDROŻENIE EKSPLOATACJA (C) Instytut Informatyki, Politechnika Poznańska 6
7 Cykl życia systemu informatycznego Oracle Designer 6i Implementacja strategia + analiza projektowanie dokumentacja (C) Instytut Informatyki, Politechnika Poznańska 7
8 Metodyki realizacji projektów informatycznych
9 Projektowanie SI z wykorzystaniem Designer6i narzędzia do modelowania: PD, ERD, FHD, DFD, transformacje, struktura logiczna bazy danych (model relacyjny), definicje aplikacji, generowanie obiektów bazy danych i kodu po stronie serwera, generowanie aplikacji. (C) Instytut Informatyki, Politechnika Poznańska 9
10 Metodyka RAD (Rapid Application Development) szybkie tworzenie prototypów aplikacji, modyfikowanie prototypów zgodnie z wymaganiami użytkowników, tylko małe systemy, krótki czas od rozpoczęcia projektu do chwili dostarczenia aplikacji użytkownikowi. (C) Instytut Informatyki, Politechnika Poznańska 10
11 Metodyka IE (Information Engineering) technika top-down, główny nacisk na model danych, specyfikacja funkcji przetwarzających dane. (C) Instytut Informatyki, Politechnika Poznańska 11
12 Metodyka PMD (Process Model Driven) często używana jako punkt początkowy dla rozwoju systemów informatycznych, pozwala na identyfikację podstawowych procesów w organizacji przed analizą zakresu informacji potrzebnej do ich realizacji. (C) Instytut Informatyki, Politechnika Poznańska 12
13 Metodyka DCD (Design Capture Driven) stosowana w przypadku istnienia już systemów w przedsiębiorstwie, wykorzystuje mechanizmy reverse-engineering, pozwala na generowanie nowych systemów korzystając ze starych definicji, pozwala realizować nowe potrzeby przedsiębiorstwa przy minimalnych nakładach czasowych i finansowych. (C) Instytut Informatyki, Politechnika Poznańska 13
14 Modelowanie procesów
15 Modelowanie procesów Określa kolejność i miejsce realizacji funkcji przedsiębiorstwa. Umożliwia i ułatwia komunikację pomiędzy: różnymi działami firmy, użytkownikami a projektantami, projektantami a programistami. Pozwala na zrozumienie funkcjonowania organizacji. (C) Instytut Informatyki, Politechnika Poznańska 15
16 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, A B prawne, inne. (C) Instytut Informatyki, Politechnika Poznańska 16
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 17
18 Obiekty diagramu procesów Jednostka organizacyjna Proces Składnica Zależność Wynik Wyzwalacz (C) Instytut Informatyki, Politechnika Poznańska 18
19 Jednostka organizacyjna (organization unit) Określa miejsce realizacji poszczególnych procesów. Może dotyczyć jednostki organizacyjnej lub osoby o określonych kompetencjach. (C) Instytut Informatyki, Politechnika Poznańska 19
20 Proces (process) Opisuje operację składową działalności przedsiębiorstwa. (C) Instytut Informatyki, Politechnika Poznańska 20
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 21
22 Przepływ zależność (flow) Pokazuje przepływy informacyjne i materiałowe oraz zależności czasowe pomiędzy procesami. (C) Instytut Informatyki, Politechnika Poznańska 22
23 Przepływ zależność (flow) Czy przepływ jest wystarczający do rozpoczęcia realizacji procesu przeznaczenia? Warunek oraz częstość wyboru jednego z wielu przepływów wyjściowych przepływu (dotyczy punktów decyzyjnych). (C) Instytut Informatyki, Politechnika Poznańska 23
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 24
25 Wyzwalacz (trigger) Bodziec do podjęcia realizacji określonych procesów. Typy wyzwalaczy: okresowy (time), systemowy (system), inny (other). (C) Instytut Informatyki, Politechnika Poznańska 25
26 Składnica (store) Magazyn informacji (zbiór relacji, arkuszy kalkulacyjnych akt itp.), materiałów lub inny. (C) Instytut Informatyki, Politechnika Poznańska 26
27 Składnica (store) Typy składnic: informacyjna (data store), materialna (material store), ogólna (store). (C) Instytut Informatyki, Politechnika Poznańska 27
28 Wynik (outcome) Jest efektem realizacji sekwencji czynności. Typy wyników: okresowy (time), systemowy (system), inny (other). (C) Instytut Informatyki, Politechnika Poznańska 28
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 29
30 Modelowanie elementów składowych procesów (C) Instytut Informatyki, Politechnika Poznańska 30
31 Identyfikacja procesów wymagających reorganizacji (C) Instytut Informatyki, Politechnika Poznańska 31
32 Import istniejących obiektów do diagramów (C) Instytut Informatyki, Politechnika Poznańska 32
33 Modelowanie związków encji
34 Modelowanie związków encji Metoda określania potrzeb informacyjnych firmy lub organizacji. Modelowanie związków encji ma na celu: Dostarczenie dokładnego modelu potrzeb informacyjnych przedsiębiorstwa, który stanowiłby podstawę do konstruowania nowych lub ulepszonych systemów, dostarczanie modelu niezależnego od sposobu przechowywania danych i metod dostępu do nich, umożliwiającego podejmowanie decyzji, dotyczących metod implementacji oraz sposobu współdziałania z istniejącymi systemami. (C) Instytut Informatyki, Politechnika Poznańska 34
35 Diagramy związków encji (C) Instytut Informatyki, Politechnika Poznańska 35
36 Obiekty występujące na diagramach związków encji Encja Związki jeden do wiele Związki jeden do jeden Związki wiele do wiele (C) Instytut Informatyki, Politechnika Poznańska 36
37 Encja (entity) Encja obiekt rzeczywisty lub niematerialny mający znaczenie dla organizacji, o którym informacje muszą być przechowywane. (C) Instytut Informatyki, Politechnika Poznańska 37
38 Encja (entity) Każda encja musi być jednoznacznie identyfikowalna to znaczy, że każda instancja (wystąpienie) encji musi być wyraźnie odróżnialna od wszystkich innych instancji tego typu encji. Uzyskuje się to poprzez definicję jednoznacznego identyfikatora. (C) Instytut Informatyki, Politechnika Poznańska 38
39 Unikalny identyfikator (unique identifier) Unikalny identyfikator to zbiór atrybutów, końców związków lub związków wykluczających, których wartości pozwalają rozróżnić instancje encji. (C) Instytut Informatyki, Politechnika Poznańska 39
40 Atrybut (attribute) Atrybut cecha służąca do identyfikacji, klasyfikacji lub wyrażenia stanu encji. (C) Instytut Informatyki, Politechnika Poznańska 40
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 41
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ÓŁ składową złożony z INSTYTUT Wiele Wymagany Opcjonalny Jeden Związek rekurencyjny (C) Instytut Informatyki, Politechnika Poznańska 42
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 43
44 Dziedzina (domain) Zbiór reguł kontroli poprawności danych, ich formatów, i innych własności stosowanych do definicji atrybutów. (C) Instytut Informatyki, Politechnika Poznańska 44
45 Dziedzina (domain) Wartości dopuszczalne zdefiniowane w ramach domen będą wpływały na zawartość relacji CG_REF_CODES. (C) Instytut Informatyki, Politechnika Poznańska 45
46 Konstrukcje specjalne Związki wykluczające Hierarchie encji Związki nieprzechodnie (C) Instytut Informatyki, Politechnika Poznańska 46
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 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. (C) Instytut Informatyki, Politechnika Poznańska 47
48 Tworzenie związku wykluczającego (C) Instytut Informatyki, Politechnika Poznańska 48
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 dziedziczone z encji-nadtypu. (C) Instytut Informatyki, Politechnika Poznańska 49
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 encji wynikającego z tego związku. Zespół raz przypisany do określonego instytutu nie może zostać przeniesiony do innego instytutu (nie może zmienić przypisania). (C) Instytut Informatyki, Politechnika Poznańska 50
51 Entity Relationship Diagrammer Jest narzędziem służącym do modelowania i definiowania potrzeb informacyjnych w postaci diagramów związków encji. Pozwala na: tworzenie diagramów związków encji, automatyczny rozkład obiektów na diagramie, dostęp do narzędzi systemu Oracle Designer powiązanych i weryfikujących związki encji. (C) Instytut Informatyki, Politechnika Poznańska 51
52 Modelowanie przepływów danych
53 Modelowanie przepływu danych Modelowanie przepływu danych (ang. Dataflow Diagrams) ma na celu zobrazowanie procesów zachodzących w organizacji, wymiany informacji między nimi oraz miejsc wprowadzania i wyprowadzania danych. (C) Instytut Informatyki, Politechnika Poznańska 53
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 54
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 55
56 Obiekty diagramów przepływów danych Proces funkcja Przepływ Byt zewnętrzny Składnica danych (C) Instytut Informatyki, Politechnika Poznańska 56
57 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 (C) Instytut Informatyki, Politechnika Poznańska 57
58 Składnica danych Typy składnic danych: komputerowe (computer), papierowe (manual), inne (transient). (C) Instytut Informatyki, Politechnika Poznańska 58
59 Przepływ danych (dataflow) Przepływ danych jest nazwaną kolekcją encji i ich atrybutów przekazywanych między dwoma procesami, procesem a składnicą lub procesem a bytem zewnętrznym. (C) Instytut Informatyki, Politechnika Poznańska 59
60 Przepływ danych (dataflow) Przepływ danych jest chwilowym przeniesieniem danych. Gdy osiągną one cel (proces) decyzja o tym co się z nimi dalej stanie zależy od procesu przyjmującego. Jeśli odbiorca zignoruje nadchodzące dane zostaną one utracone na zawsze. (C) Instytut Informatyki, Politechnika Poznańska 60
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ących się w składnicy. Składnica danych służy do przechwytywania na stałe chwilowego przepływu danych. (C) Instytut Informatyki, Politechnika Poznańska 61
62 Proces (function) Opisuje składową działalności przedsiębiorstwa. (C) Instytut Informatyki, Politechnika Poznańska 62
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 do funkcji nie ma wpływu na ENTITY USAGES. Zawartość ENTITY USAGES dla funkcji nie ma żadnego wpływu na zawartość przepływów związanych z tą funkcją. (C) Instytut Informatyki, Politechnika Poznańska 63
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ę lub jednostkę organizacyjną. (C) Instytut Informatyki, Politechnika Poznańska 64
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 encji przez funkcje, przechodzenie do składowych procesów lub procesów znajdujących się wyżej w hierarchii. (C) Instytut Informatyki, Politechnika Poznańska 65
66 Modelowanie hierarchii funkcji
67 Modelowanie hierarchii funkcji Modelowanie hierarchii funkcji tworzy diagramy pokazujące dekompozycję funkcji na różnych poziomach działalności przedsiębiorstwa. (C) Instytut Informatyki, Politechnika Poznańska 67
68 Funkcja (function) Składowa operacja przedsiębiorstwa. (C) Instytut Informatyki, Politechnika Poznańska 68
69 Funkcje specjalnego znaczenia Funkcje wspólne (common function). Funkcje atomowe (atomic function) funkcje, które nie podlegają dalszej dekompozycji. Funkcje atomowe Funkcje elementarne (elementary function). (C) Instytut Informatyki, Politechnika Poznańska 69
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 tylko referencje do funkcji głównej. Funkcje wspólne Funkcja główna (C) Instytut Informatyki, Politechnika Poznańska 70
71 Funkcje elementarne Funkcje elementarne pozostawiają system w stanie spójnym, wykonanie funkcji elementarnej, nie będącej funkcją atomową, wymaga pomyślnej realizacji wszystkich jej funkcji podrzędnych. (C) Instytut Informatyki, Politechnika Poznańska 71
72 Function Hierarchy Diagrammer Pozwala na utworzenie diagramu hierarchii funkcji realizowanych przez organizację. Umożliwia: tworzenie, modyfikację i dekompozycję funkcji, automatyczne tworzenie podzbiorów dużych i złożonych hierarchii, określanie sposobu wykorzystania danych przez funkcje, zwijanie i rozwijanie gałęzi hierarchii, automatyczną zmianę układu funkcji (pionowy, poziomy, hybrydowy). (C) Instytut Informatyki, Politechnika Poznańska 72
73 Repozytorium Oracle Designer 6i
74 Repozytorium Oracle Designer 6i Repozytorium Oracle Designer 6i jest miejscem składowania wszelkich obiektów tworzonych na diagramach. Dzięki repozytorium obiekty utworzone np. na diagramie zależności procesów można importować do pozostałych diagramów. (C) Instytut Informatyki, Politechnika Poznańska 74
75 Repository Object Navigator Służy do przeglądania i modyfikacji obiektów składowanych w repozytorium Oracle Designer6i. Dla każdego obiektu dostępna jest lista własności. (C) Instytut Informatyki, Politechnika Poznańska 75
76 Zależności pomiędzy diagramami
77 Zależności pomiędzy diagramami Wszystkie trzy metody modelowania procesów i funkcji, tj. konstrukcja diagramów zależności procesów, modelowania przepływów danych i tworzenie hierarchii funkcji przenikają się wzajemnie operując na tych samych obiektach. (C) Instytut Informatyki, Politechnika Poznańska 77
78 Funkcje procesy (C) Instytut Informatyki, Politechnika Poznańska 78
79 Składnice danych (C) Instytut Informatyki, Politechnika Poznańska 79
80 Przepływy (C) Instytut Informatyki, Politechnika Poznańska 80
81 Hierarchie funkcji (C) Instytut Informatyki, Politechnika Poznańska 81
82 Sposoby i wskazówki dotyczące tworzenia diagramów i modeli
83 Poziomy modelowania systemu informatycznego Poziom przedsiębiorstwa dotyczy podstawowych obszarów działalności przedsiębiorstwa. Poziom systemu wyznacza sposób, w jaki wymagania przedsiębiorstwa są lub mogą być realizowane. Funkcje na tym poziomie pokazują czynności pracowników. Poziom programu pokazuje sposób fizycznej realizacji funkcji systemu przez określone mechanizmy komputerowe, biurowe itp. Funkcje na tym poziomie pokazują elementarne operacje. (C) Instytut Informatyki, Politechnika Poznańska 83
84 Wykorzystanie metod modelowania Metody modelowania Poziom przedsiębiorstwa Poziom systemu Poziom programu Hierarchia funkcji Diagram zależności procesów Diagramy przepływów danych Podstawowa Podstawowa Podstawowa Opcjonalna Podstawowa Opcjonalna Opcjonalna Podstawowa Opcjonalna (C) Instytut Informatyki, Politechnika Poznańska 84
85 Podstawowe podejścia przy modelowaniu funkcji Modelowanie z góry do dołu polega na dekompozycji kolejnych poziomów rozpoczynając od pojedynczej funkcji głównej reprezentującej działalność przedsiębiorstwa. Modelowanie z dołu do góry na początku identyfikuje się funkcje przedsiębiorstwa, a następnie dla każdej z nich próbuje się znaleźć odpowiednie miejsce w hierarchii funkcji. Technika mieszana. (C) Instytut Informatyki, Politechnika Poznańska 85
86 Kiedy zakończyć dekompozycję funkcji? Metoda funkcji elementarnych: Hierarchia funkcji jest traktowana jako kompletną, jeżeli przejście od funkcji głównej do funkcji atomowych możliwe jest tylko przez funkcje elementarne. (C) Instytut Informatyki, Politechnika Poznańska 86
87 Mechanizmy Powiązania określonych funkcji ze sposobem ich realizacji. Typy mechanizmów: myślowy, komputerowy, mechaniczny, ręczny. Unikanie mechanizmów w nazwach i opisach funkcji pozwala budować modele bardziej ogólne. Pobudza do reorganizacji, usprawniania lub wprowadzania nowych metod realizacji określonych zadań. (C) Instytut Informatyki, Politechnika Poznańska 87
88 Tworzenie modeli informacyjnych Warunkiem tworzenia poprawnych i efektywnych modeli informacyjnych jest stosowanie określonych konwencji i zasad. Nie dopuszczają one do powstawania niejednoznaczności i ułatwiają zrozumienie potrzeb informacyjnych przedsiębiorstwa. (C) Instytut Informatyki, Politechnika Poznańska 88
89 Zasady dotyczące encji! Każda instancja encji musi być wyraźnie odróżnialna od wszystkich innych instancji tej encji. Każda encja powinna:! być związana co najmniej jednym związkiem,! posiadać co najmniej dwa atrybuty,! być wykorzystywana przez co najmniej jedną funkcję, po zakończeniu etapu analizy być kompletna informacyjnie. (C) Instytut Informatyki, Politechnika Poznańska 89
90 Zasady dotyczące związków Nazwy pojawiające się na końcach związków powinny tworzyć poprawne konstrukcje zdaniowe z poprzedzającymi je zwrotami musi być dla związków wymaganych lub może być dla związków opcjonalnych. Związek nie może wchodzić w skład więcej niż jednego łuku. Każdy związek po zakończeniu etapu analizy powinien być kompletny informacyjnie. (C) Instytut Informatyki, Politechnika Poznańska 90
91 Nieprawidłowe związki (C) Instytut Informatyki, Politechnika Poznańska 91
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 powinien być informacyjnie kompletny. (C) Instytut Informatyki, Politechnika Poznańska 92
93 Zasady dotyczące związków wykluczających Łuk musi obejmować co najmniej dwa końce związków, a zwykle nie więcej niż trzy lub cztery. Łuki prawie zawsze rysuje się wokół końców wiele związków. Jeśli jeden koniec związku, będącego częścią jednoznacznego identyfikatora encji, znajduje się w łuku, wówczas każdy inny koniec związku w tym łuku musi być również częścią jednoznacznego identyfikatora dla tej encji. (C) Instytut Informatyki, Politechnika Poznańska 93
94 Niepoprawne związki wykluczające Łuki mogą dotyczyć końców związków, które albo wszystkie są obowiązkowe, albo wszystkie opcjonalne. Łuki nie mogą obejmować związków dotyczących różnych encji. (C) Instytut Informatyki, Politechnika Poznańska 94
95 Reguły rozmieszczania elementów na diagramie związków encji Końce związków wiele umieszcza się na górze lub po lewej stronie, dzięki temu obiekty o dużym znaczeniu, służące do opisywania innych obiektów, są grupowane i znajdują się na dole po prawej stronie diagramu. Na diagramach rozmiar i kształt encji nie jest istotny wszystko ma służyć przejrzystości i czytelności diagramu. (C) Instytut Informatyki, Politechnika Poznańska 95
96 Zamiana związków wiele do wiele Encja intersekcji Historyczność Encje referencyjne REZERWACJA # * status * data STATUS # * wartość # * od dnia do dnia REZERWACJA # * data (C) Instytut Informatyki, Politechnika Poznańska 96
97 Budowanie bazy danych
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 98
99 Przebieg procesu krok 1. Transformowanie diagramów związków encji do schematu logicznego bazy danych krok 2. Generowanie schematu fizycznego bazy danych (C) Instytut Informatyki, Politechnika Poznańska 99
100 Budowanie bazy danych krok 1. Transformowanie diagramów związków encji do schematu logicznego bazy danych (C) Instytut Informatyki, Politechnika Poznańska 100
101 Reguły transformacji Jak przetransformować: encję? hierarchię encji? związek? (C) Instytut Informatyki, Politechnika Poznańska 101
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 102
103 Transformacja hierarchii encji Sposoby: transformacja do pojedynczej relacji transformacja do oddzielnych relacji transformacja do oddzielnych relacji połączonych ograniczeniami referencyjnymi w łuku (C) Instytut Informatyki, Politechnika Poznańska 103
104 Transformacja hierarchii Sposób pierwszy Zasady: jedna relacja schemat relacji: atrybuty wszystkich encji z hierarchii + dodatkowa kolumna, określająca typ specjalizacji Kiedy stosować: większość atrybutów w nadtypie większość związków do nadtypu Zalety: uproszczenie schematu bazy danych Wady: atrybuty obowiązkowe podtypu stają się kolumnami opcjonalnymi (C) Instytut Informatyki, Politechnika Poznańska 104
105 Transformacja hierarchii Sposób drugi Zasady: jedna relacja dla każdego podtypu schemat relacji: atrybuty nadtypu + atrybuty podtypu Kiedy stosować: większość atrybutów w podtypach większość związków do podtypów Zalety: zachowanie obowiązkowości atrybutów w podtypach Wady: komplikacja schematu konieczność powielenia kluczy obcych implementujących związki przyłączone do nadtypu (C) Instytut Informatyki, Politechnika Poznańska 105
106 Transformacja hierarchii Sposób trzeci Zasady: jedna relacja z atrybutami wspólnymi, dla każdego podtypu osobna relacja z jego atrybutami specyficznymi relacje połączone kluczami obcymi w łuku Kiedy stosować: związki przywiązane zarówno do nadtypu jak i podtypów Zalety: zachowanie obowiązkowości atrybutów w podtypach łatwy dostęp do informacji z nadtypu Wady: komplikacja schematu konieczność stosowania połączeń (SQL) (C) Instytut Informatyki, Politechnika Poznańska 106
107 Transformacja związków Implementacja związku za pomocą ograniczeń referencyjnych (kluczy obcych) Sposób transformacji zależy od parametrów związku: krotności (1:1, 1:N, M:N) obowiązkowości/opcjonalności (C) Instytut Informatyki, Politechnika Poznańska 107
108 Transformacja związków Związek 1:1 jednostronnie obowiązkowy Zasady: do relacji impl. encję wiązaną obowiązkowo zostaje dodany klucz obcy, wskazujący na klucz podstawowy relacji impl. encję wiązaną opcjonalnie (z drugiej strony związku) na kolumny klucza obcego zostaje nałożone ograniczenie not null TABLICA_A ( ID_A PRIMARY KEY, ATR_1 NULL) TABLICA_B ( ID_B PRIMARY KEY, ATR_1 NOT NULL ID_A NOT NULL REFERENCES TABLICA_A(ID_A)) (C) Instytut Informatyki, Politechnika Poznańska 108
109 Transformacja związków Zasady: Związek 1:1 obustronnie opcjonalny do relacji impl. tą encję ze związku, dla której określono większy średni przyrost wystąpień, zostaje dodany klucz obcy, wskazujący na klucz podstawowy z relacji impl. drugą encję w związku na kolumny klucza obcego nałożone zostaje ograniczenie null (C) Instytut Informatyki, Politechnika Poznańska 109
110 Transformacja związków Związek 1:N Zasady: do relacji impl. encję po stronie N związku zostaje dodany klucz obcy, wskazujący na klucz podstawowy relacji impl. encję po stronie 1 związku obowiązkowość związku po stronie N - ograniczenie not null na kolumny w kluczu obcym opcjonalność związku po stronie N - ograniczenie null na kolumny w kluczu obcym obowiązkowość/opcjonalność związku po stronie 1 nie ma wpływu na transformację TABLICA_A ( ID_A PRIMARY KEY, ATR_1 NULL ID_B NOT NULL REFERENCES TABLICA_B(ID_B)) TABLICA_B ( ID_B PRIMARY KEY, ATR_1 NOT NULL) (C) Instytut Informatyki, Politechnika Poznańska 110
111 Transformacja związków Związek M:N Zasady: zostaje utworzona nowa relacja w nowej relacji zostają utworzone klucze obce, wskazujące na klucze podstawowe relacji w związku kolumny obu kluczy obcych tworzą klucz podstawowy relacji 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)) (C) Instytut Informatyki, Politechnika Poznańska 111
112 Proces transformacji
113 Proces transformacji Krok 1. Uruchomić narzędzie Database Design Transformer z grupy Transform Preliminary Designs (C) Instytut Informatyki, Politechnika Poznańska 113
114 Proces transformacji Krok 2 - opcje transformacji transformacja wg ustawień domyślnych transformacja wg ustawień użytkownika (C) Instytut Informatyki, Politechnika Poznańska 114
115 Proces transformacji Dostępne ustawienia wybór encji do transformacji - domyślnie wszystkie sposób transformacja hierarchii - domyślnie do jednej relacji wybór typów tworzonych elementów (relacje, kolumny, klucze, indeksy) - domyślnie wszystkie wybór typów modyfikowanych elementów (istniejących już w repozytorium relacji, kolumn, kluczy, indeksów) - domyślnie żadne (C) Instytut Informatyki, Politechnika Poznańska 115
116 Proces transformacji Dostępne ustawienia (2) opcje ograniczeń referencyjnych: usuwanie kaskadowe - domyślnie zabronione modyfikowanie kaskadowe - domyślnie zabronione tworzenie sztucznych kluczy podstawowych relacji (w postaci dodatkowej kolumny numerycznej) - domyślnie tylko dla encji bez unikalnych identyfikatorów przedrostek nazw relacji - domyślnie brak przedrostki nazw kolumn (na podstawie krótkich nazw encji) - domyślnie brak (C) Instytut Informatyki, Politechnika Poznańska 116
117 Proces transformacji Krok 3 - uruchomienie procesu Uruchomienie transformacji - przycisk Run (C) Instytut Informatyki, Politechnika Poznańska 117
118 Proces transformacji Wynik Umieszczone repozytorium systemu definicje: relacji kolumn ograniczeń integralnościowych indeksów liczników - dla sztucznych kluczy podstawowych (C) Instytut Informatyki, Politechnika Poznańska 118
119 Proces transformacji Wynik (2) Podgląd definicji w repozytorium - narzędzie Design Editor z grupy Design and Generate (C) Instytut Informatyki, Politechnika Poznańska 119
120 Design Editor Umożliwia: przeglądanie i ręczną modyfikację powstałego w wyniku transformacji schematu logicznego bazy danych definiowanie dodatkowych obiektów schematu logicznego: liczników perspektyw kodu PL/SQL utworzenie diagramu schematu modelu relacyjnego - pokazuje połączenia między relacjami (ograniczenia referencyjne) (C) Instytut Informatyki, Politechnika Poznańska 120
121 Design Editor Przeglądanie i modyfikacja schematu logicznego Zakładka Server Model, gałęzie: Relational Table Definitions - relacje, kolumny, ograniczenia itegralnościowe, inne Relational View Definition - perspektywy Sequence Definitions - liczniki PL/SQL Definitions - kod składowany (C) Instytut Informatyki, Politechnika Poznańska 121
122 Design Editor Z menu kontekstowego wybrać Show on New Diagram Tworzenie diagramu schematu logicznego Zaznaczyć obiekty (relacje lub perspektywy), które mają być uwidocznione na diagramie (C) Instytut Informatyki, Politechnika Poznańska 122
123 Design Editor Przykładowy diagramu schematu logicznego (C) Instytut Informatyki, Politechnika Poznańska 123
124 Jak to zrobić? Jak przetransformować hierarchię encji w sposób inny niż domyślny? (C) Instytut Informatyki, Politechnika Poznańska 124
125 Jak to zrobić - hierarchia encji Transformacja do oddzielnych relacji krok 1. Uruchomić Database Design Transformer krok 2. Zaznaczyć opcję Customize the Database Transformer i wybrać zakładkę Table Mappings (C) Instytut Informatyki, Politechnika Poznańska 125
126 Jak to zrobić - hierarchia encji Transformacja do oddzielnych relacji krok 3. Zmienić zbiór encji do transformacji - wyłączyć ze zbioru encję-nadtyp, dodać encjepodtypy (C) Instytut Informatyki, Politechnika Poznańska 126
127 Jak to zrobić - hierarchia encji Transformacja do oddzielnych relacji krok 4. Przystąpić do transformacji Wynik: (C) Instytut Informatyki, Politechnika Poznańska 127
128 Jak to zrobić - hierarchia encji Transformacja do relacji w łuku krok 1. Uruchomić Database Design Transformer krok 2. Zaznaczyć opcję Customize the Database Transformer i wybrać zakładkę Table Mappings (C) Instytut Informatyki, Politechnika Poznańska 128
129 Jak to zrobić - hierarchia encji Transformacja do relacji w łuku krok 3. Zmienić zbiór encji do transformacji - włączyć do zbioru encję-nadtyp wraz z encjami-podtypami (C) Instytut Informatyki, Politechnika Poznańska 129
130 Jak to zrobić - hierarchia encji Transformacja do relacji w łuku krok 4. Zmienić typ elementów do transformacji - zakładka Run Options - tylko definicje relacji (bez kolumn i ograniczeń integralnościowych) krok 5. Uruchomić transformację. Wygenerowane zostaną jedynie definicje relacji. Pozostać w narzędziu (C) Instytut Informatyki, Politechnika Poznańska 130
131 Jak to zrobić - hierarchia encji Transformacja do relacji w łuku krok 6. Przy encjach-podtypach zaznaczyć opcję Arc krok 7. Zmienić typ elementów do transformacji - zakładka Run Options - wszystkie elementy (C) Instytut Informatyki, Politechnika Poznańska 131
132 Jak to zrobić - hierarchia encji Transformacja do relacji w łuku krok 8. Przystąpić do transformacji Wynik: (C) Instytut Informatyki, Politechnika Poznańska 132
133 Budowanie bazy danych krok 2. Generowanie schematu fizycznego bazy danych (C) Instytut Informatyki, Politechnika Poznańska 133
134 Generacja bazy danych Przebieg procesu krok 1. Uruchomić narzędzie Design Editor. Przejść na zakładkę Server Model, rozwinąć gałąź systemu aplikacji krok 2. Wybrać pozycję Generate Database from Server Model z menu Generate (C) Instytut Informatyki, Politechnika Poznańska 134
135 Generacja bazy danych Przebieg procesu krok 3. Ustalić parametry generacji - zakładka Target: Cel generacji: skrypty DDL (różne formaty) wskazany użytkownik bazy danych Oracle baza danych ODBC Lokalizacja skryptów (C) Instytut Informatyki, Politechnika Poznańska 135
136 Generacja bazy danych Przebieg procesu krok 4. Wybrać obiekty do generacji - zakładka Objects: Typ obiektu: relacje liczniki perspektywy i inne Konkretny obiekt (C) Instytut Informatyki, Politechnika Poznańska 136
137 Generacja bazy danych Przebieg procesu krok 5. Uruchomić proces - przycisk Start Wynik - w zależności od parametrów generacji: skrypty DDL we wskazanym katalogu obiekty w schemacie wskazanego użytkownika obiekty w bazie danych przyłączonej za pomocą ODBC (C) Instytut Informatyki, Politechnika Poznańska 137
138 Budowanie aplikacji
139 Dane wejściowe Diagramy hierarchii funkcji i przepływów danych, a w szczególności: definicje funkcji sposób użycia encji przez funkcje przepływy z i do funkcji Wynik Definicje aplikacji w wybranym języku programowania (C) Instytut Informatyki, Politechnika Poznańska 139
140 Przebieg procesu krok 1. Transformowanie definicji funkcji do projektów aplikacji krok 2. Modyfikacja struktury aplikacji krok 3. Generowanie aplikacji w wybranym języku programowania (C) Instytut Informatyki, Politechnika Poznańska 140
141 Budowanie aplikacji krok 1. Transformowanie definicji funkcji do projektów aplikacji (C) Instytut Informatyki, Politechnika Poznańska 141
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 142
143 Reguły transformacji Które funkcje transformować? Kandydatami do transformacji są: liście hierarchii bez przodków, będących funkcjami elementarnymi lub wspólnymi funkcje wspólne funkcje elementarne (C) Instytut Informatyki, Politechnika Poznańska 143
144 Reguły transformacji Które funkcje transformować? (C) Instytut Informatyki, Politechnika Poznańska 144
145 Reguły transformacji Co wpływa na typ aplikacji? Typy aplikacji: formularz (ang. Screen) - odczytuje i modyfikuje dane z relacji wydruk (ang. Report) - tylko odczytuje dane z relacji aplikacja użytkowa (ang. Utility) - może to być biblioteka, funkcja i procedura składowana, pakiet (C) Instytut Informatyki, Politechnika Poznańska 145
146 Reguły transformacji Co wpływa na typ aplikacji? (2) Jak określić typ aplikacji? na podstawie zestawu operacji, jakie transformowana funkcja realizuje na encjach na podstawie własności Reakcja (ang. Response) funkcji (ang. Immediate - Natychmiastowa, ang. Overnight - Odroczona) (C) Instytut Informatyki, Politechnika Poznańska 146
147 Reguły transformacji Zasady: Co wpływa na typ aplikacji? (3) encje, których używa funkcja, nie zostały zaimplementowane jako relacje - typ aplikacji nieokreślony (musi zostać wskazany przez projektanta) własność Reakcja określono na Natychmiastowa - typ aplikacji to formularz funkcja realizuje tylko operacje odczytu na encjach, zaimplementowanych jako relacje - typ aplikacji to wydruk, własność Reakcja określono na Odroczona - typ aplikacji to aplikacja użytkowa w pozostałych przypadkach - typ aplikacji to formularz (C) Instytut Informatyki, Politechnika Poznańska 147
148 Reguły transformacji Kryteria: Łączenie funkcji łącz funkcje przetwarzające ten sam zestaw encji łącz funkcje przetwarzające ten sam zestaw encji i wykonujące ten sam zestaw operacji na encjach łącz funkcje używające tych samych atrybutów encji (C) Instytut Informatyki, Politechnika Poznańska 148
149 Proces transformacji
150 Proces transformacji Krok 1. Uruchomić narzędzie Application Design Transformer z grupy Transform Preliminary Designs (C) Instytut Informatyki, Politechnika Poznańska 150
151 Proces transformacji Krok 2. - ustawienie parametrów wybór funkcji w hierarchii, od której rozpocznie się transformacja - Start Function przedrostek nazwy aplikacji - Module Prefix początkowy numer - będzie tworzył nazwę aplikacji w połączeniu z przedrostkiem - Start number domyślne języki implementacji aplikacji poszczególnych typów - Language (np. Oracle Forms, Oracle Reports, Visual Basic, itd.) kryteria łączenia funkcji - Merge Granularity (C) Instytut Informatyki, Politechnika Poznańska 151
152 Proces transformacji Krok 3. - uruchomienie procesu Uruchomienie transformacji - przycisk Generate (C) Instytut Informatyki, Politechnika Poznańska 152
153 Proces transformacji Wynik Umieszczone w repozytorium systemu definicje modułówkandydatów na aplikacje Przeglądanie struktury - Design Editor, zakładka Modules, gałąź Modules (C) Instytut Informatyki, Politechnika Poznańska 153
154 Budowanie aplikacji krok 2. Modyfikacja struktury aplikacji (C) Instytut Informatyki, Politechnika Poznańska 154
155 Struktura aplikacji - składniki moduł - reprezentuje aplikację tabela bazowa - wskazuje relację, którą przetwarza aplikacja; przechowuje informacje o dopuszczalnych operacjach na relacji tabela look-up - uzupełnia dane z tabeli bazowej o dane z relacji powiązanej za pomocą ograniczeń referencyjnych; zawiera elementy związane wyświetlające dane z tej relacji powiązania między tablicami bazowymi lub między tablicą bazową a tablicą look-up - modelują hierarchię (C) Instytut Informatyki, Politechnika Poznańska 155
156 Struktura aplikacji - składniki (2) element związany - wskazuje na kolumny relacji, którą przetwarza aplikacja; grupowane w tabeli bazowej lub look-up; najczęściej służą do wyświetlania danych z kolumn relacji element niezwiązany - wyświetla informacje wyliczane, nie ma odpowiednika w schemacie relacji; nie wskazuje na żadną kolumnę w relacji komponent - grupuje elementy w strukturze (tabele bazowe, elementy związane i niezwiązane) okna argument aplikacji - wartość przesyłana do aplikacji po jej uruchomieniu lub zapisywana przez aplikację przy jej zakończeniu; służą do komunikacji pomiędzy aplikacjami (C) Instytut Informatyki, Politechnika Poznańska 156
157 Struktura aplikacji - składniki (3) Każdy element struktury posiada listę własności, określających m.in.: nazwę elementu typ elementu (np. grupa radiowa, lista, itd.) dopuszczalne operacje, itd. (C) Instytut Informatyki, Politechnika Poznańska 157
158 Diagramy struktury aplikacji Tworzenie - menu kontekstowego danej aplikacji wybrać Show on New Diagram\ Rodzaje widok danych - pokazuje wewnętrzną strukturę aplikacji widok interfejsu - pokazuje układ interfejsu aplikacji Przełączanie pomiędzy widokami - przyciski (C) Instytut Informatyki, Politechnika Poznańska 158
159 Diagramy struktury aplikacji (2) widok danych nadrzędna tabela bazowa moduł widok interfejsu tabela look-up element niezwiązany powiązania okno zawartość okna podrzędna tabela bazowa komponent element interfejsu element związany (C) Instytut Informatyki, Politechnika Poznańska 159
160 Proces modyfikacji struktury aplikacji
161 Struktura aplikacji po transformacji jedna tabela bazowa dla każdej relacji, implementującej encję używaną przez funkcję elementy związane, odpowiadające kolumnom relacji argumenty aplikacji, odpowiadające atrybutom z przepływów wejściowych i wyjściowych funkcji brak powiązań między tabelami bazowymi brak tabel look-up brak elementów niezwiązanych (C) Instytut Informatyki, Politechnika Poznańska 161
162 Proces modyfikacji struktury Krok 1. Zaakceptowanie modułów-kandydatów jako aplikacji do ostatecznej generacji - ustawienie własności Candidate? na No. Wybór języka implementacji aplikacji. formularz kandydat wydruk aplikacja użytkowa (C) Instytut Informatyki, Politechnika Poznańska 162
163 Proces modyfikacji struktury Krok 2. Utworzenie związków pomiędzy tabelami bazowymi modelują hierarchię nadrzędnypodrzędny korzystają z definicji ograniczeń referencyjnych między relacjami Metody: tworzenie automatyczne tworzenie ręczne (C) Instytut Informatyki, Politechnika Poznańska 163
164 Proces modyfikacji struktury Krok 2. - wynik (C) Instytut Informatyki, Politechnika Poznańska 164
165 Proces modyfikacji struktury Krok 3. Utworzenie związku typu look-up (C) Instytut Informatyki, Politechnika Poznańska 165
166 Proces modyfikacji struktury Krok 4. Określenie własności poszczególnych składników struktury, np. zmiana typu elementu (C) Instytut Informatyki, Politechnika Poznańska 166
167 Proces modyfikacji struktury Krok 5. - dodanie elementu niezwiązanego Podział ze względu na źródło danych: funkcja agregujące (MIN, MAX, SUM, AVG, COUNT) - Computed (wyliczany) funkcja składowana na serwerze - Server Side Function funkcja aplikacji - Client Side Function wyrażenie wykorzystujące funkcje SQL, np. TO_DATE, TO_CHAR, LTRIM, itd. - SQL Expression Przykład - dodanie elementu niezwiązanego LICZBA_PRACOWNIKÓW - oblicza, ilu pracowników jest zatrudnionych w danym zespole (C) Instytut Informatyki, Politechnika Poznańska 167
168 Proces modyfikacji struktury Krok 5a) Dodanie elementu: (C) Instytut Informatyki, Politechnika Poznańska 168
169 Proces modyfikacji struktury Krok 5b) Określenie własności: (C) Instytut Informatyki, Politechnika Poznańska 169
170 Proces modyfikacji struktury Krok 5. - Wynik (C) Instytut Informatyki, Politechnika Poznańska 170
171 Budowanie aplikacji krok 3. Generowanie aplikacji (C) Instytut Informatyki, Politechnika Poznańska 171
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 172
173 Preferencje generacji Zbiór ustawień, określających: sposób implementacji struktury sposób pracy aplikacji wygląd elementów interfejsu układ elementów interfejsu Ustawiane dla: całego systemu aplikacji konkretnej aplikacji konkretnego elementu (C) Instytut Informatyki, Politechnika Poznańska 173
174 Preferencje generacji (2) Wyświetlanie zbioru preferencji: całego systemu aplikacji konkretnej aplikacji (C) Instytut Informatyki, Politechnika Poznańska 174
175 Proces generacji aplikacji
176 Proces generacji aplikacji Krok 1. Uruchomić generator aplikacji lub (C) Instytut Informatyki, Politechnika Poznańska 176
177 Proces generacji aplikacji Krok 2. Ustawić parametry - przycisk Options: lokalizacja wersji źródłowych aplikacji (system plików czy baza danych) lokalizacja wersji wykonywalnych czy aplikacja ma zostać uruchomiona po generacji (C) Instytut Informatyki, Politechnika Poznańska 177
178 Proces generacji aplikacji Krok 3. Uruchomić proces - przycisk Start Przebieg procesu, komunikaty (C) Instytut Informatyki, Politechnika Poznańska 178
179 Proces generacji aplikacji Wynik (C) Instytut Informatyki, Politechnika Poznańska 179
180 Proces generacji aplikacji Uwagi Proces generacji ma najczęściej charakter cykliczny: pierwsza generacja zmiana preferencji kolejna generacja, itd. aż do uzyskania maksymalnie funkcjonalnej aplikacji Nie opłaca się kontynuować tego procesu aż do wygenerowania w pełni funkcjonalnej aplikacji. (C) Instytut Informatyki, Politechnika Poznańska 180
Dane wejściowe. Oracle Designer Generowanie bazy danych. Wynik. Przebieg procesu
Dane wejściowe Oracle Designer Generowanie bazy danych 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
Bardziej szczegółowoWykorzystanie oprogramowania Oracle Designer do budowy systemów informatycznych
Wykorzystanie oprogramowania Oracle Designer do budowy systemów informatycznych Bartosz Bębel, Krzysztof Jankiewicz Instytut Informatyki, Politechnika Poznańska Bartosz.Bebel@cs.put.poznan.pl Krzysztof.Jankiewicz@cs.put.poznan.pl
Bardziej szczegółowoModelowanie związków encji. Oracle Designer: Diagramy związków encji. Encja (1)
Modelowanie związków encji Oracle Designer: Modelowanie związków encji Technika określania potrzeb informacyjnych organizacji. Modelowanie związków encji ma na celu: dostarczenie dokładnego modelu potrzeb
Bardziej szczegółowoPrzepływy danych. Oracle Designer: Modelowanie przepływów danych. Diagramy przepływów danych (1) Diagramy przepływów danych (2)
Przepływy danych Oracle Designer: Modelowanie przepływów danych Cele: zobrazowanie funkcji zachodzących w organizacji, identyfikacja szczegółowych informacji, przetwarzanych przez funkcje, pokazanie wymiany
Bardziej szczegółowoWprowadzenie do metodologii modelowania systemów informacyjnych. Strategia (1) Strategia (2) Etapy Ŝycia systemu informacyjnego
Etapy Ŝycia systemu informacyjnego Wprowadzenie do metodologii modelowania systemów informacyjnych 1. Strategia 2. Analiza 3. Projektowanie 4. Implementowanie, testowanie i dokumentowanie 5. WdroŜenie
Bardziej szczegółowoModelowanie procesów (1) Oracle Designer: Modelowanie procesów. Modelowania procesów (2) Modelowanie procesów (3)
Modelowanie procesów (1) Oracle Designer: Modelowanie procesów Identyfikuje kluczowe aktywności w działalności organizacji. Modeluje wybrane lub wszystkie aktywności w ramach organizacji. Określa kolejność
Bardziej szczegółowoZasady transformacji modelu DOZ do projektu tabel bazy danych
Zasady transformacji modelu DOZ do projektu tabel bazy danych A. Obiekty proste B. Obiekty z podtypami C. Związki rozłączne GHJ 1 A. Projektowanie - obiekty proste TRASA # * numer POZYCJA o planowana godzina
Bardziej szczegółowo030 PROJEKTOWANIE BAZ DANYCH. Prof. dr hab. Marek Wisła
030 PROJEKTOWANIE BAZ DANYCH Prof. dr hab. Marek Wisła Elementy procesu projektowania bazy danych Badanie zależności funkcyjnych Normalizacja Projektowanie bazy danych Model ER, diagramy ERD Encje, atrybuty,
Bardziej szczegółowo1 Projektowanie systemu informatycznego
Plan wykładu Spis treści 1 Projektowanie systemu informatycznego 1 2 Modelowanie pojęciowe 4 2.1 Encja....................................... 5 2.2 Własności.................................... 6 2.3 Związki.....................................
Bardziej szczegółowoDiagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym
Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym konceptualnym modelem danych jest tzw. model związków encji (ERM
Bardziej szczegółowoTransformacja modelu ER do modelu relacyjnego
Transformacja modelu ER do modelu relacyjnego Wykład przygotował: Robert Wrembel BD wykład 4 (1) 1 Plan wykładu Transformacja encji Transformacja związków Transformacja hierarchii encji BD wykład 4 (2)
Bardziej szczegółowoDiagramu Związków Encji - CELE. Diagram Związków Encji - CHARAKTERYSTYKA. Diagram Związków Encji - Podstawowe bloki składowe i reguły konstrukcji
Diagramy związków encji (ERD) 1 Projektowanie bazy danych za pomocą narzędzi CASE Materiał pochodzi ze strony : http://jjakiela.prz.edu.pl/labs.htm Diagramu Związków Encji - CELE Zrozumienie struktury
Bardziej szczegółowoBazy danych TERMINOLOGIA
Bazy danych TERMINOLOGIA Dane Dane są wartościami przechowywanymi w bazie danych. Dane są statyczne w tym sensie, że zachowują swój stan aż do zmodyfikowania ich ręcznie lub przez jakiś automatyczny proces.
Bardziej szczegółowoPODSTAWY BAZ DANYCH. 5. Modelowanie danych. 2009/ Notatki do wykładu "Podstawy baz danych"
PODSTAWY BAZ DANYCH 5. Modelowanie danych 1 Etapy tworzenia systemu informatycznego Etapy tworzenia systemu informatycznego - (według CASE*Method) (CASE Computer Aided Systems Engineering ) Analiza wymagań
Bardziej szczegółowoWykład 2. Relacyjny model danych
Wykład 2 Relacyjny model danych Wymagania stawiane modelowi danych Unikanie nadmiarowości danych (redundancji) jedna informacja powinna być wpisana do bazy danych tylko jeden raz Problem powtarzających
Bardziej szczegółowoZagadnienia (1/3) Data-flow diagramy przepływów danych ERD diagramy związków encji Diagramy obiektowe w UML (ang. Unified Modeling Language)
Zagadnienia (1/3) Rola modelu systemu w procesie analizy wymagań (inżynierii wymagań) Prezentacja różnego rodzaju informacji o systemie w zależności od rodzaju modelu. Budowanie pełnego obrazu systemu
Bardziej szczegółowoWPROWADZENIE DO BAZ DANYCH
WPROWADZENIE DO BAZ DANYCH Pojęcie danych i baz danych Dane to wszystkie informacje jakie przechowujemy, aby w każdej chwili mieć do nich dostęp. Baza danych (data base) to uporządkowany zbiór danych z
Bardziej szczegółowoBAZY DANYCH LABORATORIUM. Studia niestacjonarne I stopnia
BAZY DANYCH LABORATORIUM Studia niestacjonarne I stopnia Gdańsk, 2011 1. Cel zajęć Celem zajęć laboratoryjnych jest wyrobienie praktycznej umiejętności tworzenia modelu logicznego danych a nastepnie implementacji
Bardziej szczegółowoLABORATORIUM 8,9: BAZA DANYCH MS-ACCESS
UNIWERSYTET ZIELONOGÓRSKI INSTYTUT INFORMATYKI I ELEKTROTECHNIKI ZAKŁAD INŻYNIERII KOMPUTEROWEJ Przygotowali: mgr inż. Arkadiusz Bukowiec mgr inż. Remigiusz Wiśniewski LABORATORIUM 8,9: BAZA DANYCH MS-ACCESS
Bardziej szczegółowoUsługi analityczne budowa kostki analitycznej Część pierwsza.
Usługi analityczne budowa kostki analitycznej Część pierwsza. Wprowadzenie W wielu dziedzinach działalności człowieka analiza zebranych danych jest jednym z najważniejszych mechanizmów podejmowania decyzji.
Bardziej szczegółowoPlan. Aplikacja. Architektura aplikacji. Architektura aplikacji Tworzenie aplikacji Application Builder podstawy
Plan Podstawy narzędzia Application Builder, 2 budowa strony, kreatory Architektura Tworzenie Tworzenie formularza tabelarycznego Budowa strony 2 Architektura Aplikacja kolekcja stron połączonych ze sobą
Bardziej szczegółowoHurtownie danych - przegląd technologii
Hurtownie danych - przegląd technologii Problematyka zasilania hurtowni danych - Oracle Data Integrator Politechnika Poznańska Instytut Informatyki Robert.Wrembel@cs.put.poznan.pl www.cs.put.poznan.pl/rwrembel
Bardziej szczegółowoSystemy baz danych Prowadzący: Adam Czyszczoń. Systemy baz danych. 1. Import bazy z MS Access do MS SQL Server 2012:
Systemy baz danych 16.04.2013 1. Plan: 10. Implementacja Bazy Danych - diagram fizyczny 11. Implementacja Bazy Danych - implementacja 2. Zadania: 1. Przygotować model fizyczny dla wybranego projektu bazy
Bardziej szczegółowoUtwórz klucz podstawowy relacji na podstawie unikalnego identyfikatora encji. podstawie kluczy podstawowych wiązanych relacji.
TRANSFORMACJA DO SCHEMATU RELACYJNEGO pojęcia podstawowe Repetytorium pojęcia podstawowe relacyjnego modelu danych Schemat implementacyjny (logiczny) bazy danych: schemat, na którym działają aplikacje.
Bardziej szczegółowoSystemy baz danych. mgr inż. Sylwia Glińska
Systemy baz danych Wykład 1 mgr inż. Sylwia Glińska Baza danych Baza danych to uporządkowany zbiór danych z określonej dziedziny tematycznej, zorganizowany w sposób ułatwiający do nich dostęp. System zarządzania
Bardziej szczegółowoBazy danych. Plan wykładu. Diagramy ER. Podstawy modeli relacyjnych. Podstawy modeli relacyjnych. Podstawy modeli relacyjnych
Plan wykładu Bazy danych Wykład 9: Przechodzenie od diagramów E/R do modelu relacyjnego. Definiowanie perspektyw. Diagramy E/R - powtórzenie Relacyjne bazy danych Od diagramów E/R do relacji SQL - perspektywy
Bardziej szczegółowoProjektowanie baz danych za pomocą narzędzi CASE
Projektowanie baz danych za pomocą narzędzi CASE Metody tworzenia systemów informatycznych w tym, także rozbudowanych baz danych są komputerowo wspomagane przez narzędzia CASE (ang. Computer Aided Software
Bardziej szczegółowoModelowanie danych, projektowanie systemu informatycznego
Modelowanie danych, projektowanie systemu informatycznego Modelowanie odwzorowanie rzeczywistych obiektów świata rzeczywistego w systemie informatycznym Modele - konceptualne reprezentacja obiektów w uniwersalnym
Bardziej szczegółowoTransformacja modelu EER do postaci relacyjnego modelu danych. Zbyszko Królikowski
Transformacja modelu EER do postaci relacyjnego modelu danych Zbyszko Królikowski 1 Repetytorium pojęcia podstawowe relacyjnego modelu danych Schemat implementacyjny (logiczny) bazy danych: schemat, na
Bardziej szczegółowoKrzysztof Kadowski. PL-E3579, PL-EA0312,
Krzysztof Kadowski PL-E3579, PL-EA0312, kadowski@jkk.edu.pl Bazą danych nazywamy zbiór informacji w postaci tabel oraz narzędzi stosowanych do gromadzenia, przekształcania oraz wyszukiwania danych. Baza
Bardziej szczegółowoPlan. Wprowadzenie. Co to jest APEX? Wprowadzenie. Administracja obszarem roboczym
1 Wprowadzenie do środowiska Oracle APEX, obszary robocze, użytkownicy Wprowadzenie Plan Administracja obszarem roboczym 2 Wprowadzenie Co to jest APEX? Co to jest APEX? Architektura Środowisko Oracle
Bardziej szczegółowoPlan. Raport. Tworzenie raportu z kreatora (1/3)
3 Budowa prostych raportów opartych o bazę danych Plan Co to jest raport? Tworzenie za pomocą kreatora Tworzenie opartego o polecenie SQL Edycja atrybutów Atrybuty regionu Atrybuty Atrybuty kolumn 2 Raport
Bardziej szczegółowoTechnologia informacyjna
Technologia informacyjna Pracownia nr 9 (studia stacjonarne) - 05.12.2008 - Rok akademicki 2008/2009 2/16 Bazy danych - Plan zajęć Podstawowe pojęcia: baza danych, system zarządzania bazą danych tabela,
Bardziej szczegółowoBazy danych. Zachodniopomorski Uniwersytet Technologiczny w Szczecinie. Wykład 3: Model związków encji.
Zachodniopomorski Uniwersytet Technologiczny w Szczecinie Bazy danych Wykład 3: Model związków encji. dr inż. Magdalena Krakowiak makrakowiak@wi.zut.edu.pl Co to jest model związków encji? Model związków
Bardziej szczegółowoBazy danych 1. Wykład 5 Metodologia projektowania baz danych. (projektowanie logiczne)
Bazy danych 1 Wykład 5 Metodologia projektowania baz danych (projektowanie logiczne) Projektowanie logiczne przegląd krok po kroku 1. Usuń własności niekompatybilne z modelem relacyjnym 2. Wyznacz relacje
Bardziej szczegółowoRELACYJNE BAZY DANYCH
RELACYJNE BAZY DANYCH Aleksander Łuczyk Bielsko-Biała, 15 kwiecień 2015 r. Ludzie używają baz danych każdego dnia. Książka telefoniczna, zbiór wizytówek przypiętych nad biurkiem, encyklopedia czy chociażby
Bardziej szczegółowoMODELOWANIE PRZEPŁYWU DANYCH
MODELOWANIE PRZEPŁYWU DANYCH 1. Diagram przepływu danych (DFD) 2. Weryfikacja modelu strukturalnego za pomocą DFD Modelowanie SI - GHJ 1 Definicja i struktura DFD Model części organizacji rozważany z punktu
Bardziej szczegółowoPlan. Formularz i jego typy. Tworzenie formularza. Co to jest formularz? Typy formularzy Tworzenie prostego formularza Budowa prostego formularza
4 Budowa prostych formularzy, stany sesji, tworzenie przycisków Plan Co to jest formularz? Typy formularzy Tworzenie prostego formularza Budowa prostego formularza 2 Formularz i jego typy Tworzenie formularza
Bardziej szczegółowoInżynieria Programowania Laboratorium 3 Projektowanie i implementacja bazy danych. Paweł Paduch paduch@tu.kielce.pl
Inżynieria Programowania Laboratorium 3 Projektowanie i implementacja bazy danych Paweł Paduch paduch@tu.kielce.pl 06-04-2013 Rozdział 1 Wstęp Na dzisiejszych zajęciach zajmiemy się projektem bazy danych.
Bardziej szczegółowoTRANSFORMACJA MODELU ER DO MODELU RELACYJNEGO
TRANSFORMACJA MODELU ER DO MODELU RELACYJNEGO Biologiczne Aplikacje Baz Danych dr inż. Anna Leśniewska alesniewska@cs.put.poznan.pl REPETYTORIUM Schemat bazy danych zbiór schematów relacji Relacja (tabela)
Bardziej szczegółowoDiagramy związków encji. Laboratorium. Akademia Morska w Gdyni
Akademia Morska w Gdyni Gdynia 2004 1. Podstawowe definicje Baza danych to uporządkowany zbiór danych umożliwiający łatwe przeszukiwanie i aktualizację. System zarządzania bazą danych (DBMS) to oprogramowanie
Bardziej szczegółowoProjektowanie Systemów Informacyjnych
Projektowanie Systemów Informacyjnych Wykład II Encje, Związki, Diagramy związków encji, Opracowano na podstawie: Podstawowy Wykład z Systemów Baz Danych, J.D.Ullman, J.Widom Copyrights by Arkadiusz Rzucidło
Bardziej szczegółowoLK1: Wprowadzenie do MS Access Zakładanie bazy danych i tworzenie interfejsu użytkownika
LK1: Wprowadzenie do MS Access Zakładanie bazy danych i tworzenie interfejsu użytkownika Prowadzący: Dr inż. Jacek Habel Instytut Technologii Maszyn i Automatyzacji Produkcji Zakład Projektowania Procesów
Bardziej szczegółowoLaboratorium Technologii Informacyjnych. Projektowanie Baz Danych
Laboratorium Technologii Informacyjnych Projektowanie Baz Danych Komputerowe bazy danych są obecne podstawowym narzędziem służącym przechowywaniu, przetwarzaniu i analizie danych. Gromadzone są dane w
Bardziej szczegółowoProjektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Modelowanie danych Diagramy ERD
Projektowanie systemów informatycznych Roman Simiński roman.siminski@us.edu.pl siminskionline.pl Modelowanie danych Diagramy ERD Modelowanie danych dlaczego? Od biznesowego gadania do magazynu na biznesowe
Bardziej szczegółowoKomputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl
Komputerowe Systemy Przemysłowe: Modelowanie - UML Arkadiusz Banasik arkadiusz.banasik@polsl.pl Plan prezentacji Wprowadzenie UML Diagram przypadków użycia Diagram klas Podsumowanie Wprowadzenie Języki
Bardziej szczegółowoUniwersytet Zielonogórski Instytut Sterowania i Systemów Informatycznych Bazy Danych - Projekt. Zasady przygotowania i oceny projektów
Uniwersytet Zielonogórski Instytut Sterowania i Systemów Informatycznych Bazy Danych - Projekt Zasady przygotowania i oceny projektów 1 Cel projektu Celem niniejszego projektu jest zaprojektowanie i implementacja
Bardziej szczegółowoBaza danych sql. 1. Wprowadzenie
Baza danych sql 1. Wprowadzenie Do tej pory operowaliście na listach. W tej instrukcji pokazane zostanie jak stworzyć bazę danych. W zadaniu skorzystamy z edytora graficznego struktury bazy danych, który
Bardziej szczegółowoProjektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34
Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34 Projektowanie oprogramowania cd. 2/34 Modelowanie CRC Modelowanie CRC (class-responsibility-collaborator) Metoda identyfikowania poszczególnych
Bardziej szczegółowoAnaliza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32
Analiza i projektowanie oprogramowania Analiza i projektowanie oprogramowania 1/32 Analiza i projektowanie oprogramowania 2/32 Cel analizy Celem fazy określania wymagań jest udzielenie odpowiedzi na pytanie:
Bardziej szczegółowoOfficeObjects e-forms
OfficeObjects e-forms Rodan Development Sp. z o.o. 02-820 Warszawa, ul. Wyczółki 89, tel.: (+48-22) 643 92 08, fax: (+48-22) 643 92 10, http://www.rodan.pl Spis treści Wstęp... 3 Łatwość tworzenia i publikacji
Bardziej szczegółowoWykład II Encja, atrybuty, klucze Związki encji. Opracowano na podstawie: Podstawowy Wykład z Systemów Baz Danych, J.D.Ullman, J.
Bazy Danych Wykład II Encja, atrybuty, klucze Związki encji Opracowano na podstawie: Podstawowy Wykład z Systemów Baz Danych, J.D.Ullman, J.Widom Copyrights by Arkadiusz Rzucidło 1 Encja Byt pojęciowy
Bardziej szczegółowoPaweł Kurzawa, Delfina Kongo
Paweł Kurzawa, Delfina Kongo Pierwsze prace nad standaryzacją Obiektowych baz danych zaczęły się w roku 1991. Stworzona została grupa do prac nad standardem, została ona nazwana Object Database Management
Bardziej szczegółowoPRZESTRZENNE BAZY DANYCH WYKŁAD 2
PRZESTRZENNE BAZY DANYCH WYKŁAD 2 Baza danych to zbiór plików, które fizycznie przechowują dane oraz system, który nimi zarządza (DBMS, ang. Database Management System). Zadaniem DBMS jest prawidłowe przechowywanie
Bardziej szczegółowoBazy danych 2. dr inż. Tadeusz Jeleniewski
Wykład 4 Projektowanie bazy danych i procesów aplikacji Modelowanie reguł przetwarzania Środowisko przykładowego programu do modelowania reguł przetwarzania Reguły poprawności 2018-02-23 Bazy danych 2
Bardziej szczegółowoPLAN WYKŁADU BAZY DANYCH GŁÓWNE ETAPY PROJEKTOWANIA BAZY MODELOWANIE LOGICZNE
PLAN WYKŁADU Modelowanie logiczne Transformacja ERD w model relacyjny Odwzorowanie encji Odwzorowanie związków Odwzorowanie specjalizacji i generalizacji BAZY DANYCH Wykład 7 dr inż. Agnieszka Bołtuć GŁÓWNE
Bardziej szczegółowoDiagramy przepływu danych I
Literatura bazowa: Projektowanie systemów informatycznych Zajęcia: Diagramy przepływu danych I E.Yourdon, Współczesna analiza strukturalna, WNT, Warszawa 1996 J.Roberston, S.Robertson, Pełna analiza systemowa,
Bardziej szczegółowoAutor: Joanna Karwowska
Autor: Joanna Karwowska W bazie danych przechowujemy tylko niektóre informacje o świecie rzeczywistym. Wybór właściwych wycinków rzeczywistości i dotyczących ich danych jest bardzo istotny od niego zależy
Bardziej szczegółowoJęzyk SQL. Rozdział 9. Język definiowania danych DDL, część 2.
Język SQL. Rozdział 9. Język definiowania danych DDL, część 2. Ograniczenia integralnościowe, modyfikowanie struktury relacji, zarządzanie ograniczeniami. 1 Ograniczenia integralnościowe Służą do weryfikacji
Bardziej szczegółowoBaza danych. Modele danych
Rola baz danych Systemy informatyczne stosowane w obsłudze działalności gospodarczej pełnią funkcję polegającą na gromadzeniu i przetwarzaniu danych. Typowe operacje wykonywane na danych w systemach ewidencyjno-sprawozdawczych
Bardziej szczegółowoBazy danych - wykład wstępny
Bazy danych - wykład wstępny Wykład: baza danych, modele, hierarchiczny, sieciowy, relacyjny, obiektowy, schemat logiczny, tabela, kwerenda, SQL, rekord, krotka, pole, atrybut, klucz podstawowy, relacja,
Bardziej szczegółowoTechnologie baz danych
Technologie baz danych Wykład 4: Diagramy związków encji (ERD). SQL funkcje grupujące. Małgorzata Krętowska Wydział Informatyki Politechnika Białostocka Plan wykładu Diagramy związków encji elementy ERD
Bardziej szczegółowoInstytut Mechaniki i Inżynierii Obliczeniowej fb.com/groups/bazydanychmt/
Instytut Mechaniki i Inżynierii Obliczeniowej www.imio.polsl.pl fb.com/imiopolsl @imiopolsl fb.com/groups/bazydanychmt/ Wydział Mechaniczny technologiczny Politechnika Śląska Laboratorium 4 (Asocjacje,
Bardziej szczegółowoTworzenie bazy danych na przykładzie Access
Tworzenie bazy danych na przykładzie Access Tworzenie tabeli Kwerendy (zapytania) Selekcja Projekcja Złączenie Relacja 1 Relacja 2 Tworzenie kwedend w widoku projektu Wybór tabeli (tabel) źródłowych Wybieramy
Bardziej szczegółowoBlaski i cienie wyzwalaczy w relacyjnych bazach danych. Mgr inż. Andrzej Ptasznik
Blaski i cienie wyzwalaczy w relacyjnych bazach danych. Mgr inż. Andrzej Ptasznik Technologia Przykłady praktycznych zastosowań wyzwalaczy będą omawiane na bazie systemu MS SQL Server 2005 Wprowadzenie
Bardziej szczegółowoBazy Danych. Modele danych. Krzysztof Regulski WIMiIP, KISiM,
Bazy Danych Modele danych Krzysztof Regulski WIMiIP, KISiM, regulski@agh.edu.pl Cele modelowania Strategia informatyzacji organizacji Cele informatyzacji Specyfikacja wymagań użytkownika Model procesów
Bardziej szczegółowoAnaliza i projektowanie obiektowe 2016/2017. Wykład 10: Tworzenie projektowego diagramu klas
Analiza i projektowanie obiektowe 2016/2017 Wykład 10: Tworzenie projektowego diagramu klas Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Projektowy
Bardziej szczegółowoWdrożenie modułu płatności eservice. dla systemu oscommerce 2.3.x
Wdrożenie modułu płatności eservice dla systemu oscommerce 2.3.x - dokumentacja techniczna Wer. 01 Warszawa, styczeń 2014 1 Spis treści: 1 Wstęp... 3 1.1 Przeznaczenie dokumentu... 3 1.2 Przygotowanie
Bardziej szczegółowoBudowa argumentacji bezpieczeństwa z użyciem NOR-STA Instrukcja krok po kroku
Budowa argumentacji bezpieczeństwa z użyciem NOR-STA Instrukcja krok po kroku NOR-STA jest narzędziem wspierającym budowę, ocenę oraz zarządzanie strukturą argumentacji wiarygodności (assurance case),
Bardziej szczegółowoDefinicje. Algorytm to:
Algorytmy Definicje Algorytm to: skończony ciąg operacji na obiektach, ze ściśle ustalonym porządkiem wykonania, dający możliwość realizacji zadania określonej klasy pewien ciąg czynności, który prowadzi
Bardziej szczegółowoDefinicja bazy danych TECHNOLOGIE BAZ DANYCH. System zarządzania bazą danych (SZBD) Oczekiwania wobec SZBD. Oczekiwania wobec SZBD c.d.
TECHNOLOGIE BAZ DANYCH WYKŁAD 1 Wprowadzenie do baz danych. Normalizacja. (Wybrane materiały) Dr inż. E. Busłowska Definicja bazy danych Uporządkowany zbiór informacji, posiadający własną strukturę i wartość.
Bardziej szczegółowoUML w Visual Studio. Michał Ciećwierz
UML w Visual Studio Michał Ciećwierz UNIFIED MODELING LANGUAGE (Zunifikowany język modelowania) Pozwala tworzyć wiele systemów (np. informatycznych) Pozwala obrazować, specyfikować, tworzyć i dokumentować
Bardziej szczegółowoOracle Designer. Oracle Designer jest jednym z głównych komponentów pakietu Oracle Developer Suite. Oracle Designer wspiera :
Oracle Designer Oracle Designer jest jednym z głównych komponentów pakietu Oracle Developer Suite. Oracle Designer wspiera : - modelowanie procesów biznesowych - analizę systemu informatycznego - projektowanie
Bardziej szczegółowoTECHNIKI MODELOWANIA STRUKTURY INFORMACYJNEJ
TECHNIKI MODELOWANIA STRUKTURY INFORMACYJNEJ 1. Diagram obiektów i związków (DOZ) 2. Szczegółowa specyfikacja obiektów, atrybutów i związków GHJ 1 Metodyki strukturalne IE (Information Engineering) Martin
Bardziej szczegółowoZSE - Systemy baz danych 1 ZASADY PROJEKTOWANIA BAZ DANYCH
ZSE - Systemy baz danych 1 ZASADY PROJEKTOWANIA BAZ DANYCH ZSE - Systemy baz danych 2 rzeczywistość uzyskanie od użytkowników początkowych informacji i wymagań dotyczących przetwarzania danych analiza
Bardziej szczegółowoPodręcznik Użytkownika LSI WRPO
Podręcznik użytkownika Lokalnego Systemu Informatycznego do obsługi Wielkopolskiego Regionalnego Programu Operacyjnego na lata 2007 2013 w zakresie wypełniania wniosków o dofinansowanie Wersja 1 Podręcznik
Bardziej szczegółowo7. Formularze master-detail
7. Formularze master-detail 1. Utworzymy teraz jeden z bardziej złożonych formularzy dostępnych z kreatora formularz master-detail. Będzie on swoją strukturą przypominał utworzony wcześniej formularz dotyczący
Bardziej szczegółowoBazy danych. Andrzej Grzybowski. Instytut Fizyki, Uniwersytet Śląski
Bazy danych Andrzej Grzybowski Instytut Fizyki, Uniwersytet Śląski Wykład 6 Model relacyjny danych projektowanie relacyjnych baz danych, model logiczny i relacyjny, zastosowanie Oracle SQL Developer Data
Bardziej szczegółowoZastosowanie Oracle Designer/2000 do projektowania i implementacji aplikacji WWW
V Konferencja PLOUG Zakopane Październik 1999 Zastosowanie Oracle Designer/2000 do projektowania i implementacji aplikacji WWW Grzegorz Bliźniuk gbliz@isi.wat.waw.pl. Roman Wantoch-Rekowski rekowski@isi.wat.waw.pl.
Bardziej szczegółowoSpis treści. 1 Modelowanie logiczne. Plan wykładu. 1 Modelowanie logiczne 1
Plan wykładu Spis treści 1 Modelowanie logiczne 1 2 Transformacja modelu pojęciowego do logicznego 2 2.1 Transformacja własności............................ 3 2.2 Transformacja związków............................
Bardziej szczegółowoWprowadzenie do hurtowni danych
Wprowadzenie do hurtowni danych przygotował: Paweł Kasprowski Kostka Kostka (cube) to podstawowy element hurtowni Kostka jest wielowymiarowa (od 1 do N wymiarów) Kostka składa się z: faktów wektora wartości
Bardziej szczegółowoWykład I. Wprowadzenie do baz danych
Wykład I Wprowadzenie do baz danych Trochę historii Pierwsze znane użycie terminu baza danych miało miejsce w listopadzie w 1963 roku. W latach sześcdziesątych XX wieku został opracowany przez Charles
Bardziej szczegółowoUstalanie dostępu do plików - Windows XP Home/Professional
Ustalanie dostępu do plików - Windows XP Home/Professional Aby edytować atrybuty dostępu do plikow/ katalogow w systemie plików NTFS wpierw sprawdź czy jest Wyłączone proste udostępnianie czyli przejdź
Bardziej szczegółowoBaza danych to zbiór wzajemnie powiązanych ze sobą i zintegrowanych danych z pewnej dziedziny.
PI-14 01/12 Baza danych to zbiór wzajemnie powiązanych ze sobą i zintegrowanych danych z pewnej dziedziny.! Likwidacja lub znaczne ograniczenie redundancji (powtarzania się) danych! Integracja danych!
Bardziej szczegółowoWdrożenie modułu płatności eservice. dla systemu Zen Cart 1.3.9 1.5
Wdrożenie modułu płatności eservice dla systemu Zen Cart 1.3.9 1.5 - dokumentacja techniczna Wer. 01 Warszawa, styczeń 2014 1 Spis treści: 1 Wstęp... 3 1.1 Przeznaczenie dokumentu... 3 1.2 Przygotowanie
Bardziej szczegółowoMicrosoft Excel 2003 profesjonalna analiza i raportowanie oraz prezentacja danych
Microsoft Excel 2003 profesjonalna analiza i raportowanie oraz prezentacja danych Projekt: Wdrożenie strategii szkoleniowej prowadzony przez KancelarięPrezesa Rady Ministrów Projekt współfinansowany przez
Bardziej szczegółowoInformatyka Ćwiczenie 10. Bazy danych. Strukturę bazy danych można określić w formie jak na rysunku 1. atrybuty
Informatyka Ćwiczenie 10 Bazy danych Baza danych jest zbiór informacji (zbiór danych). Strukturę bazy danych można określić w formie jak na rysunku 1. Pracownik(ID pracownika, imie, nazwisko, pensja) Klient(ID
Bardziej szczegółowoTomasz Grześ. Systemy zarządzania treścią
Tomasz Grześ Systemy zarządzania treścią Co to jest CMS? CMS (ang. Content Management System System Zarządzania Treścią) CMS definicje TREŚĆ Dowolny rodzaj informacji cyfrowej. Może to być np. tekst, obraz,
Bardziej szczegółowoProjektowanie oprogramowania. Warstwa integracji z bazą danych oparta na technologii ORM Platforma Java EE Autor: Zofia Kruczkiewicz
Projektowanie oprogramowania Warstwa integracji z bazą danych oparta na technologii ORM Platforma Java EE Autor: Zofia Kruczkiewicz 1 Wykonanie czterowarstwowej aplikacji EE z dostępem do bazy danych,
Bardziej szczegółowoTechnologie informacyjne - wykład 12 -
Zakład Fizyki Budowli i Komputerowych Metod Projektowania Instytut Budownictwa Wydział Budownictwa Lądowego i Wodnego Politechnika Wrocławska Technologie informacyjne - wykład 12 - Prowadzący: Dmochowski
Bardziej szczegółowoBudowa aplikacji ASP.NET współpracującej z bazą dany do przeprowadzania ankiet internetowych
Budowa aplikacji ASP.NET współpracującej z bazą dany do przeprowadzania ankiet internetowych widok ankiety w przeglądarce Rozpoczniemy od zaprojektowania bazy danych w programie SYBASE/PowerDesigner umieszczamy
Bardziej szczegółowoProgram szkoleniowy Efektywni50+ Moduł IV Podstawy relacyjnych baz danych i język SQL
Program szkoleniowy Efektywni50+ Moduł IV Podstawy relacyjnych baz danych i język SQL 1 Podstawy relacyjnego modelu danych. 3h UWAGA: Temat zajęć jest typowo teoretyczny i stanowi wprowadzenie do zagadnień
Bardziej szczegółowoANALYSIS SERVICES. 1. Tworzymy połączenie ze źródłem danych. 2. Tworzymy nowy widok dla źródła danych
1 ANALYSIS SERVICES 1. Tworzymy połączenie ze źródłem danych Możliwości są dwie, ale dodajemy projekt analityczny do projektu w którym mamy procesy ETL (Add Project) albo tworzymy nowy projekt (New Project).
Bardziej szczegółowoSystemy informatyczne. Modelowanie danych systemów informatycznych
Modelowanie danych systemów informatycznych Diagramy związków encji Entity-Relationship Diagrams Modelowanie danych diagramy związków encji ERD (ang. Entity-Relationship Diagrams) diagramy związków encji
Bardziej szczegółowoModelowanie KONCEPCJA. przedstawiana przez INDYWIDUALNOŚĆ GHJ 6
Modelowanie KONCEPCJA staje się zrozumiała wyrażona za pomocą INDYWIDUALNOŚĆ przedstawiana przez SYMBOL GHJ 6 Podejścia w modelowaniu Pełny zakres WSTĘPUJĄCE Opuszczone szczegóły ZSTĘPUJĄCE Niepotrzebne
Bardziej szczegółowoWymagania dotyczące projektu do przedmiotu: Systemy baz danych 2 / Bazy danych projekt 1 (P)
Wymagania dotyczące projektu do przedmiotu: Systemy baz danych 2 / Bazy danych projekt 1 (P) Założenie: zaprojektowanie schematu bazy danych modelującej wybrany fragment oraz implementacja tego schematu
Bardziej szczegółowo- Narzędzie Windows Forms. - Przykładowe aplikacje. Wyższa Metody Szkoła programowania Techniczno Ekonomiczna 1 w Świdnicy
Wyższa Metody Szkoła programowania Techniczno Ekonomiczna 1 w Świdnicy - Narzędzie Windows Forms - Przykładowe aplikacje 1 Narzędzia Windows Form Windows Form jest narzędziem do tworzenia aplikacji dla
Bardziej szczegółowoSYSTEM INFORMATYCZNY KS-SEW
DOKUMENTACJA TECHNICZNA KAMSOFT S.A. 40-235 Katowice ul. 1-Maja 133 Tel. (032) 2090705, Fax. (032) 2090715 http://www.kamsoft.pl, e-mail: 5420@kamsoft.pl SYSTEM INFORMATYCZNY NR KATALOGOWY 2334PI06.00
Bardziej szczegółowoWymagania klienta mogą być opisane na różnych poziomach abstrakcji: Podział wymagań: Wymagania funkcjonalne Wymagania niefunkcjonalne
Definiowanie wymagań Wymagania klienta mogą być opisane na różnych poziomach abstrakcji: 1. Definicja wymagań jest zapisana w języku naturalnym jako rezultat rozmów z przedstawiciela klienta 2. Specyfikacja
Bardziej szczegółowo