Modelowanie związków encji. Oracle Designer: Diagramy związków encji. Encja (1)

Podobne dokumenty
Przepływy danych. Oracle Designer: Modelowanie przepływów danych. Diagramy przepływów danych (1) Diagramy przepływów danych (2)

Dane wejściowe. Oracle Designer Generowanie bazy danych. Wynik. Przebieg procesu

Modelowanie danych, projektowanie systemu informatycznego

TECHNIKI MODELOWANIA STRUKTURY INFORMACYJNEJ

1 Projektowanie systemu informatycznego

030 PROJEKTOWANIE BAZ DANYCH. Prof. dr hab. Marek Wisła

Technologia informacyjna

PODSTAWY BAZ DANYCH. 5. Modelowanie danych. 2009/ Notatki do wykładu "Podstawy baz danych"

Wykorzystanie oprogramowania Oracle Designer do budowy systemów informatycznych

Bazy Danych. Modele danych. Krzysztof Regulski WIMiIP, KISiM,

Wykorzystanie oprogramowania Oracle Designer do budowy systemów informatycznych

Technologie baz danych

Zasady transformacji modelu DOZ do projektu tabel bazy danych

PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU>

Bazy danych 1. Wykład 5 Metodologia projektowania baz danych. (projektowanie logiczne)

Autor: Joanna Karwowska

Bazy danych TERMINOLOGIA

Transformacja modelu ER do modelu relacyjnego

Bazy danych. Zachodniopomorski Uniwersytet Technologiczny w Szczecinie. Wykład 3: Model związków encji.

Wydział Elektroniki Politechniki Wrocławskiej. Kierunek: Informatyka Specjalność: InŜynieria Systemów Informatycznych

Bazy danych. Plan wykładu. Diagramy ER. Podstawy modeli relacyjnych. Podstawy modeli relacyjnych. Podstawy modeli relacyjnych

Laboratorium nr 5. Temat: Funkcje agregujące, klauzule GROUP BY, HAVING

Modelowanie procesów (1) Oracle Designer: Modelowanie procesów. Modelowania procesów (2) Modelowanie procesów (3)

Paweł Kurzawa, Delfina Kongo

Diagramu Związków Encji - CELE. Diagram Związków Encji - CHARAKTERYSTYKA. Diagram Związków Encji - Podstawowe bloki składowe i reguły konstrukcji

Transformacja modelu EER do postaci relacyjnego modelu danych. Zbyszko Królikowski

INFORMATYKA GEODEZYJNO- KARTOGRAFICZNA. Modelowanie danych. Model związków-encji

TRANSFORMACJA MODELU ER DO MODELU RELACYJNEGO

Ćwiczenie 3 funkcje agregujące

Bazy danych. wprowadzenie teoretyczne. Piotr Prekurat 1

Bazy Danych 2008 Część 1 Egzamin Pisemny

Wykład II Encja, atrybuty, klucze Związki encji. Opracowano na podstawie: Podstawowy Wykład z Systemów Baz Danych, J.D.Ullman, J.

Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym

Bazy danych Access KWERENDY

Systemy baz danych. 1. Plan: 2. Zadania: Projekt Bazy Danych - wybór tematów, wstępna kategoryzacja 8. Projekt Bazy Danych - diagram ER

WSCAD. Wykład 5 Szafy sterownicze

Systemy baz danych. mgr inż. Sylwia Glińska

C-geo definicja/edycja obiektów, zapis danych w formacie shape

Informatyka I. Klasy i obiekty. Podstawy programowania obiektowego. dr inż. Andrzej Czerepicki. Politechnika Warszawska Wydział Transportu 2018

Krzysztof Kluza proste ćwiczenia z baz danych

Autor: Joanna Karwowska

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 2 Ćwiczenia w narzędziu CASE diagram klas. Materiały dla nauczyciela

Utwórz klucz podstawowy relacji na podstawie unikalnego identyfikatora encji. podstawie kluczy podstawowych wiązanych relacji.

Wykład 2. Relacyjny model danych

Bazy danych 1. Wykład 4 Metodologia projektowania baz danych

Plan. Raport. Tworzenie raportu z kreatora (1/3)

FK - Deklaracje CIT-8

Systemy informatyczne. Modelowanie danych systemów informatycznych

Tworzenie tabel. Bazy danych - laboratorium, Hanna Kleban 1

Program do obsługi ubezpieczeń minifort

Diagramy związków encji ERD Ćwiczenia w modelowaniu danych

Sekretariat Optivum. Jak przygotować listę uczniów zawierającą tylko wybrane dane, np. adresy ucznia i jego opiekunów? Projektowanie listy

Projektowanie Systemów Informacyjnych

INFORMATOR TECHNICZNY WONDERWARE. Narzędzie redundancji systemu alarmowania Alarm Hot Backup dla oprogramowania. Struktura systemu redundantnego

WPROWADZENIE DO BAZ DANYCH

Ogranicz listę klasyfikacji budżetowych do powiązanych z danym kontem księgowym

Modelowanie związków encji

7. Formularze master-detail

Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34

Projektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Modelowanie danych Diagramy ERD

Laboratorium nr 4. Temat: SQL część II. Polecenia DML

Instrukcja automatycznego tworzenia pozycji towarowych SAD na podstawie danych wczytywanych z plików zewnętrznych (XLS).

Systemy baz danych Prowadzący: Adam Czyszczoń. Systemy baz danych. 1. Import bazy z MS Access do MS SQL Server 2012:

PROJEKT INTERFEJSU UśYTKOWNIKA PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU>

Krzysztof Kadowski. PL-E3579, PL-EA0312,

D D L S Q L. Co to jest DDL SQL i jakie s jego ą podstawowe polecenia?

Ustawianie lokalizacji dla indeksów Ustawianie lokalizacji dla indeksów spis kroków

Analiza najczęstszych błędów w sprawozdawanych danych

Modelowanie wymiarów

Sposób tworzenia tabeli przestawnej pokażę na przykładzie listy krajów z podstawowymi informacjami o nich.

1.0 v2. INSTRUKCJA OBSŁUGI SAD EC Win - Moduł Monitorowanie GRN

Oracle Application Express

Program Zamiana towarów dla Subiekta GT.

KaŜdy z formularzy naleŝy podpiąć do usługi. Nazwa usługi moŝe pokrywać się z nazwą formularza, nie jest to jednak konieczne.

PROJEKT CZĘŚCIOWO FINANSOWANY PRZEZ UNIĘ EUROPEJSKĄ. Opis działania raportów w ClearQuest

Bazy danych 2. Wykład 3. Metodologia projektowania baz danych (projektowanie fizyczne)

Model relacyjny bazy danych

Program do obsługi ubezpieczeń minifort

Bazy danych. Zasady konstrukcji baz danych

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 1 Wprowadzenie do narzędzia CASE. Materiały dla nauczyciela

9 Zakup [ Zakup ] Zakup

Aby pobrać program FotoSender naleŝy na stronę lub i kliknąć na link Program do wysyłki zdjęć Internetem.

Zaawansowane Modelowanie I Analiza Systemów Informatycznych

Instrukcja zarządzania kontami i prawami

PRZEWODNIK PO ETRADER ROZDZIAŁ XII. ALERTY SPIS TREŚCI

Relacyjny model baz danych, model związków encji, normalizacje

Ćwiczenie 4 Konspekt numerowany

Oracle Application Express

III. Dane podstawowe definiowanie organizacji

Wykład IV Modelowanie danych, projektowanie systemu informatycznego Modelowanie konceptualne implementacyjne Modelowanie pojęciowe na encjach

Zasady budowy i przekazywania komunikatów wykorzystywanych w Systemie IT KDPW_CCP

Projektowanie bazy danych

Warszawa, lipiec 2013 r.

Baza danych. Modele danych

1. Logowanie się do panelu Adminitracyjnego

Bazy danych Access KWERENDY

MsAccess ćwiczenie nr 3 Kwerendy wybierające cd oraz kwerendy funkcjonalne

KaŜdemu atrybutowi A przyporządkowana jest dziedzina Dom(A), czyli zbiór dopuszczalnych wartości.

KSS: Modelowanie konceptualne przykład

Konsolidacja FP- Depozyty

Transkrypt:

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 informacyjnych przedsiębiorstwa, który stanowiłby podstawę do konstruowania nowych lub ulepszonych systemów, w szczególności: jakie obiekty są waŝne z punktu widzenia organizacji, jakie są cechy tych obiektów, w jaki sposób obiekty zaleŝą od siebie. dostarczenie modelu niezaleŝnego od sposobu przechowywania danych i metod dostępu do nich. (C) Instytut Informatyki, Politechnika Poznańska 2 Diagramy związków encji Encja (1) Obiekt rzeczywisty lub niematerialny, mający znaczenie dla organizacji, o którym informacje muszą być przechowywane. Encja musi być jednoznacznie identyfikowalna kaŝde wystąpienie (instancja) encji musi być odróŝnialne od innych wystąpień tej samej encji. Zasady nazywania encji: nazwa znacząca, nazwa w liczbie pojedynczej, nazwa określająca klasę obiektów, a nie ich wystąpienia ( Osoba, a nie Kowalski ). (C) Instytut Informatyki, Politechnika Poznańska 3 (C) Instytut Informatyki, Politechnika Poznańska 4

Encja (2) Atrybut encji (1) Dodatkowe cechy: skrót nazwy encji pole Short Name, nazwa w liczbie mnogiej pole Plural, nazwa encji nadrzędnej pole Type of, liczba wystąpień encji: początkowa pole Initial, średnia pole Average, maksymalna pole Maximum, spodziewany procentowy roczny przyrost liczby wystąpień pole Growth Rate czy encja jest wymiarem lub faktem pole Type. (C) Instytut Informatyki, Politechnika Poznańska 5 Cecha słuŝąca do identyfikacji, klasyfikacji lub wyraŝenia stanu encji. Zasady nazywania atrybutów: nazwa znacząca, nazwa w liczbie pojedynczej, nazwa atrybutu nie powinna zawierać nazwy encji. Oznaczenia na diagramie: # atrybut wchodzi w skład unikalnego identyfikatora encji, * atrybut obowiązkowy, o atrybut opcjonalny. (C) Instytut Informatyki, Politechnika Poznańska 6 Atrybut encji (2) Główne cechy atrybutu: kolejność wyświetlania na diagramie pole Seq, czy opcjonalny pole Opt, typ danych atrybutu pole Format, długość typu danych pole MaxLen, liczba pozycji ułamkowych typu danych pole Dec, czy atrybut wchodzi w skład unikalnego identyfikatora encji pole Primary, komentarz pole Comment. Atrybut encji (3) Dodatkowe cechy atrybutu: liczba wystąpień encji, w których atrybut posiada wartość pola: Initial początkowa, Average średnia, nazwa dziedziny, określająca typ wartości atrybutu pole Domain, jednostki miary atrybutu (kg, sztuki, itd.) pole Units, wyraŝenie określające sposób wyliczenia wartości atrybutu pole Derivation, warunki określające moŝliwość uŝycia atrybutu pole On Condition, wartość określająca atrybut pusty pole Null Value, wartość domyślna pole Default. (C) Instytut Informatyki, Politechnika Poznańska 7 (C) Instytut Informatyki, Politechnika Poznańska 8

Atrybut encji (4) Określenie wartości, jakie moŝe przyjmować atrybut: numer porządkowy wartości pole Seq, wartość dla atrybutu pole Value, określa równieŝ najmniejszą dopuszczalną wartość w przypadku definicji zakresu wartości, największa dopuszczalna wartość dla atrybutu w przypadku definicji zakresu wartości pole High Value, skrót dla wartości pole Abbreviation, pełny opis wartości pole Meaning. Unikalny identyfikator encji Zbiór atrybutów i/lub końców związków, których wartości pozwalają jednoznacznie rozróŝnić wystąpienia encji. Tworzenie głównego identyfikatora encji: 1. zdefiniowanie nazwy, 2. zaznaczenie opcji Primary?, 3. przeniesienie elementów do pola Unique Identifier Contents. Identyfikator bez opcji Primary? to identyfikator drugorzędny. (C) Instytut Informatyki, Politechnika Poznańska 9 (C) Instytut Informatyki, Politechnika Poznańska 10 Dziedzina atrybutu (1) Zbiór reguł kontroli poprawności danych, ich formatów i innych własności stosowanych do definicji atrybutów. Zastosowanie dziedziny dla atrybutu pole Domain w oknie definicji atrybutu. Dziedzina atrybutu (2) Cechy dziedziny (zakładka Detail): nazwa pole Domain, format atrybutów, korzystających z dziedziny grupa Attribute, format pól i kolumn, jakie zostaną utworzone z atrybutów, korzystających z dziedziny grupa Column, czy zbiór dopuszczalnych wartości w dziedzinie jest statyczny czy moŝe się zmieniać pole Dynamic List? (C) Instytut Informatyki, Politechnika Poznańska 11 (C) Instytut Informatyki, Politechnika Poznańska 12

Dziedzina atrybutu (3) Zbiór wartości w dziedzinie (zakładka Values): analogicznie jak w przypadku zbioru wartości dla atrybutu, wartości zdefiniowane w ramach dziedzin będą składowane w bazie danych w relacji CG_REF_CODES. Związek (1) Związek nazwane, istotne powiązanie pomiędzy dwiema 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 (C) Instytut Informatyki, Politechnika Poznańska 13 Wiele Wymagany Opcjonalny Jeden Związek rekurencyjny (C) Instytut Informatyki, Politechnika Poznańska 14 Związek (2) Zasady nazewnictwa: 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. Związek (3) Rzadka, prawie zawsze błędna konstrukcja: Konstrukcje błędne: (C) Instytut Informatyki, Politechnika Poznańska 15 (C) Instytut Informatyki, Politechnika Poznańska 16

Związek (4) Dodatkowe cechy: związek w unikalnym identyfikatorze encji pole Primary UID, związek nieprzechodni pole Transferable. Związek nieprzechodni Instancja encji, przy której istnieje związek nieprzechodni, nie moŝe zmieniać przypisania do innej instancji encji wynikającego z tego związku. Oznaczany za pomocą rombu przy jednym z końców związku. ENCJA A składową złoŝony z Zespół raz przypisany do określonego instytutu nie moŝe zostać przeniesiony do innego instytutu (nie moŝe zmienić przypisania). ENCJA B (C) Instytut Informatyki, Politechnika Poznańska 17 (C) Instytut Informatyki, Politechnika Poznańska 18 Związki wykluczające się (1) 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. Związki wykluczające się (2) Tworzenie: 1. zaznaczyć związki, które mają się wzajemnie wykluczać, 2. wykonać Utilities -> Create Arc. 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 19 (C) Instytut Informatyki, Politechnika Poznańska 20

Związki wykluczające się (3) Związki wykluczające się (4) Zasady: Ł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. Konstrukcje błędne: ł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 21 (C) Instytut Informatyki, Politechnika Poznańska 22 Hierarchie encji Składają się z encji-nadtypu i zawartych w niej encjipodtypów. Podtyp oprócz swoich własnych atrybutów i związków, posiada wszystkie atrybuty i związki dziedziczone z encjinadtypu. Kontrola jakości diagramu ER (C) Instytut Informatyki, Politechnika Poznańska 23

Kontrola encji Kontrola związków 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. 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 25 (C) Instytut Informatyki, Politechnika Poznańska 26 Kontrola 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. 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 27 (C) Instytut Informatyki, Politechnika Poznańska 28

Zamiana związków wiele do wiele REZERWACJA # * status * data Historyczność STATUS # * wartość # * od dnia do dnia Encja intersekcji Encje referencyjne REZERWACJA # * data Entity Relationship Diagrammer Narzędzie słuŝące do modelowania i definiowania potrzeb informacyjnych w postaci diagramów związków encji. UmoŜliwia: 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 29 (C) Instytut Informatyki, Politechnika Poznańska 30 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 31