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

Podobne dokumenty
Diagram Przepływu Danych - podstawowe bloki składowe i reguły konstrukcji

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

Autor: Joanna Karwowska

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

Projektowanie i wdrażanie systemów informatycznych (materiały do wykładu cz. II)

MODELOWANIE PRZEPŁYWU DANYCH

Systemy informatyczne. Modelowanie danych systemów informatycznych

Modelowanie danych, projektowanie systemu informatycznego

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

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl

Świat rzeczywisty i jego model

Zachodniopomorski Uniwersytet Technologiczny w Szczecinie. Bazy danych. Wykład 4: Model SERM. dr inż. Magdalena Krakowiak

Piotr Kulicki Katolicki Uniwersytet Lubelski Jana Pawła II Instytut Filozofii Teoretycznej Katedra Podstaw Informatyki

Analiza i projektowanie obiektowe 2017/2018. Wykład 3: Model wiedzy dziedzinowej

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

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

Diagramy przepływu danych I

Modelowanie obiektowe - Ćw. 3.

Zagadnienia (1/3) Data-flow diagramy przepływów danych ERD diagramy związków encji Diagramy obiektowe w UML (ang. Unified Modeling Language)

TECHNOLOGIE OBIEKTOWE. Wykład 3

Bazy danych 2. dr inż. Tadeusz Jeleniewski

1 Projektowanie systemu informatycznego

Modelowanie związków encji

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

UML w Visual Studio. Michał Ciećwierz

Wymagania klienta mogą być opisane na różnych poziomach abstrakcji: Podział wymagań: Wymagania funkcjonalne Wymagania niefunkcjonalne

Diagramy czynności. Widok logiczny. Widok fizyczny

Projektowanie Systemów Informacyjnych

Diagramy przepływu danych II model środowiskowy, diagram odpowiedzi na zdarzenia KI AE PSI

Bazy danych i usługi sieciowe

Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34

Analiza i projektowanie obiektowe 2016/2017. Wykład 10: Tworzenie projektowego diagramu klas

Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32

Uniwersytet Zielonogórski Instytut Sterowania i Systemów Informatycznych Bazy Danych - Projekt. Zasady przygotowania i oceny projektów

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

Tworzenie warstwy zasobów projektowanie metodą strukturalną

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

Wprowadzenie do metodologii modelowania systemów informacyjnych. Strategia (1) Strategia (2) Etapy Ŝycia systemu informacyjnego

Baza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego

Projektowanie baz danych za pomocą narzędzi CASE

ZSE - Systemy baz danych 1 ZASADY PROJEKTOWANIA BAZ DANYCH

Inżynieria oprogramowania wykład VI Faza analizy Analiza strukturalna modelowanie procesów, słownik danych

Projektowanie bazy danych przykład

Diagramy związków encji. Laboratorium. Akademia Morska w Gdyni

Rysunek 1: Przykłady graficznej prezentacji klas.

BAZY DANYCH model związków encji. Opracował: dr inż. Piotr Suchomski

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

Podstawowy Wykład z Systemów Baz Danych

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

Wykład 3 Wymagania. MIS n Inżynieria oprogramowania Październik Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie

Diagramy klas. WYKŁAD Piotr Ciskowski

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

Strukturalne metodyki projektowania systemûw informatycznych

Modelowanie obiektowe

Przykłady normalizacji

Projektowanie logiki aplikacji

KSS: Modelowanie konceptualne przykład

Iteracyjno-rozwojowy proces tworzenia oprogramowania Wykład 3 część 1

APIO. W4 ZDARZENIA BIZNESOWE. ZALEŻNOŚCI MIĘDZY FUNKCJAMI. ELEMENTY DEFINICJI PROCESU. DIAGRAM ZALEŻNOŚCI FUNKCJI.

Projekt małej Bazy Danych.

Baza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego

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

Projektowanie bazy danych

Język UML w modelowaniu systemów informatycznych

Modelowanie konceptualne. Modelowanie konceptualne przykład. Modelowanie konceptualne model ER. Model ER Entity-Relationship

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

TECHNOLOGIE OBIEKTOWE WYKŁAD 2. Anna Mroczek

Wprowadzenie do baz danych

POLITECHNIKA OPOLSKA

MiASI. Modelowanie systemów biznesowych. Piotr Fulmański. 7 stycznia Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska

LK1: Wprowadzenie do MS Access Zakładanie bazy danych i tworzenie interfejsu użytkownika

Podstawy projektowania systemów komputerowych

Faza analizy (modelowania) Faza projektowania

Tworzenie modelu logicznego i fizycznego danych.

Zaawansowane Modelowanie I Analiza Systemów Informatycznych

Podstawy inżynierii oprogramowania

Informatyzacja przedsiębiorstw WYKŁAD

Inżynieria oprogramowania

Procesowa specyfikacja systemów IT

Diagramy przypadków użycia

Wykład I. Wprowadzenie do baz danych

Spis treści. Analiza i modelowanie_nowicki, Chomiak_Księga1.indb :03:08

Podstawy Automatyki. Wykład 4 - algebra schematów blokowych. dr inż. Jakub Możaryn. Warszawa, Instytut Automatyki i Robotyki

Szczegółowa specyfikacja funkcjonalności zamawianego oprogramowania.

Podstawy programowania III WYKŁAD 4

Kurs programowania. Wykład 12. Wojciech Macyna. 7 czerwca 2017

Technologie baz danych

Analiza strukturalna systemów informatycznych

Projektowanie Zorientowane na Dziedzinę. ang. Domain Driven Design

Przykładowa baza danych BIBLIOTEKA

INFORMATYCZNE SYSTEMY ZARZĄDZANIA

Zaawansowane Modelowanie I Analiza Systemów Informatycznych

Narzędzia szczegółowe - diagramy. specyfikacje procesów (pseudokod).

Nowe narzędzia zarządzania jakością

WOJSKOWA AKADEMIA TECHNICZNA

Projektowanie baz danych

Podejście obiektowe - podstawowe pojęcia

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

Bazy danych. Andrzej Łachwa, UJ, /15

Transkrypt:

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 danych przetwarzanych w organizacji; Dostarczenie dokładnego modelu potrzeb informacyjnych przedsiębiorstwa, który stanowiłby podstawę do konstruowania nowych lub ulepszonych systemów; Dostarczenie modelu niezależnego od sposobu przetwarzania, przechowywania danych i dostępu do nich, umożliwiającego podejmowanie celowych decyzji, jeśli chodzi o metody implementacyjne i współdziałanie z istniejącymi systemami; Diagram Związków Encji - CHARAKTERYSTYKA Najpopularniejszym konceptualnym modelem danych jest tzw. model związków encji (ERM - entity relationship model), którego graficznym odpowiednikiem jest diagram związków encji (ERD - entity relationship diagram). Diagram Związków Encji - Podstawowe bloki składowe i reguły konstrukcji Diagram ERD przedstawia: 1. obiekty, o których informacje są istotne z punktu widzenia realizacji celów strategicznych firmy; 2. atrybuty obiektów; 3. związki pomiędzy obiektami. Wyodrębnione obiekty mogą być rzeczywiste lub mogą być pojęciami abstrakcyjnymi. Obiekty mające te same atrybuty łączy się w typy obiektów np. Towar, Klient, Dostawca, Zamówienie. ENCJA ENCJA jest rzeczą lub obiektem mającym dla nas znaczenie, rzeczywistym bądź wyobrażonym, o którym informacje muszą być znane lub przechowywane. Graficzną reprezentacją ENCJI jest prostokąt z nazwą ENCJI zapisaną w liczbie pojedynczej. ZWIĄZEK 1 http://jjakiela.prz.edu.pl/erd.htm 1

ZWIĄZEK jest nazwanym, istotnym powiązaniem pomiędzy dwiema encjami. Związki przedstawiają zależności zachodzące pomiędzy obiektami. Każdy związek ma dwa końce, z których każdy ma przypisane następujące atrybuty nazwę; liczebność (jak wiele); opcjonalność (opcjonalny czy wymagany). Związek jest reprezentowany za pomocą linii łączącej dwie encje. Na powyższym schemacie jest przedstawiony najczęściej występujący związek jeden-do-wiele. PRZYKŁADY ZWIĄZKÓW KLIENT składa ZAMÓWIENIE Arność: Jeden do Jeden-lub-Wiele DOSTAWCA dostarcza TOWAR Arność: Wiele do Wiele KLIENT posiada NIP 2

Arność: Jeden do Jeden (opcjonalnie) ATRYBUTY ATRYBUT jest dowolnym szczegółem służącym do kwalifikowania, identyfikowania, klasyfikowania, określania ilości lub wyrażania stanu ENCJI. Lub ATRYBUT jest dowolnym opisem mającym znaczenie dla ENCJI. ATRYBUT może być tekstem, liczbą, wartością logiczną lub obrazem. Przykład atrybutów ENCJI klient. Zasady tworzenia diagramów ERD Poniżej przedstawiona jest metoda tworzenia diagramów ERD jako proces składający się z pięciu kroków: Identyfikacja zbioru obiektów, o których informacje są istotne; o Identyfikację obiektów rozpoczynamy od wyodrębnienia kluczy głównych poszczególnych obiektów, czyli identyfikatorów jednoznacznie identyfikujących obiekt. Wyróżnione identyfikatory pozwalają na uformowanie wstępnej listy obiektów; Określenie związków zachodzących pomiędzy obiektami oraz rodzaju związków; o Identyfikacja bezpośrednich zależności pomiędzy obiektami, które odzwierciedlają pewne reguły przyjęte w firmie. Należy zbadać istnienie bezpośrednich powiązań między wszystkimi parami obiektów w systemie; Identyfikacja atrybutów obiektów; o Po wyodrębnieniu istotnych obiektów oraz związków zachodzących pomiędzy nimi można uzupełnić opis obiektów identyfikując potrzebne atrybuty tzn. dane istotne dla firmy opisujące konkretny obiekt; Stworzenie wstępnego modelu pojęciowego; Sprawdzenie poprawności otrzymanej struktury. 3

Na podstawie zidentyfikowanych obiektów oraz powiązań między nimi możemy narysować wstępny diagram związków encji. PRZYKŁAD Pobierz i zainstaluj program: DBDesigner4.0.5.6_Setup.exe 4

Materiał dodatkowy: Diagram Hierarchii Funkcji - CHARAKTERYSTYKA Diagram Hierarchii Funkcji (DHF) jest narzędziem modelowania, pozwalającym opisać w postaci modelu pojęciowego (konceptualnego) czym zajmuje się organizacja, dla której docelowo chcemy stworzyć system informatyczny. Ustalenie czym zajmuje się organizacja, jest pierwszym etapem w procesie określania wymagań funkcjonalnych systemu. Tworząc DHF patrzymy na dziedzinę problemu (organizację lub jej część) z perspektywy funkcji, które są realizowane w kontekście celów, które firma chce osiągnąć. Przykładowo, w firmie zajmującej się wydawaniem i sprzedażą książek mogą wystąpić następujące funkcje: Wydawanie książek; Sprzedawanie wydanych książek; Prowadzenie finansów firmy; Prowadzenie działań marketingowych; Kupowanie niezbędnych materiałów; Po zidentyfikowaniu funkcji najwyższego poziomu poszczególne funkcje są dalej dekomponowane aż analityk dojdzie do niezbędnego poziomu szczegółowości. 5

Diagram Przepływu Danych - podstawowe bloki składowe i reguły konstrukcji BLOKI SKŁADOWE DIAGRAMU W zależności od wybranej metodologii możemy korzystać z różnych symboli przedstawiających elementy składowe diagramu. Niniejszy opis diagramu DFD wykorzystuje metodologię Ganea- Sarsona. Podstawowe bloki składowe diagramu DFD są przedstawione poniżej. Symbol procesu Symbol obiektu zewnętrznego (terminatora) Symbol magazynu danych Symbol przepływu 6

PROCES Proces jest zbiorem funkcji, które zajmują się przetwarzaniem. Proces pobiera coś na wejściu, przetwarza a następnie generuje przepływ na wyjściu. Przyjmij zamówienie zbiór funkcji odpowiedzialnych za pobranie informacji nt. kontrahenta, zamawianego produktu lub usługi, ilości zamawianych pozycji etc. Po pobraniu informacji proces Przyjmij zamówienie zapisuje informacje w magazynach danych Klienci oraz Zamówienia a następnie przesyła informacje do procesu odpowiedzialnego za realizację zamówienia. OBIEKT ZEWNĘTRZNY (terminator) Terminator symbolizuje obiekty zewnętrzne wobec systemu. Zwykle jest to osoba lub firma, z którą organizacja się komunikuje. Przykładowo w przypadku firmy takiej jak Placówka Sprzedaży Detalicznej obiektami zewnętrznymi są: Klient (konsument), Dostawca (hurtownik), Bank. Obiektem zewnętrznym może być również inny dział firmy, z którym system się komunikuje lub pracownik firmy, który pobiera lub przekazuje dane do systemu. MAGAZYN DANYCH Magazyn danych jest symbolem miejsca, gdzie przechowywane są dane istotne dla firmy. Magazyn służy do buforowania danych wykorzystywanych przez kilka procesów w przypadku braku współmierności czasowej. 7

Nazwa magazynu to liczba mnoga od nazwy pakietów przenoszonych przepływami do i z magazynu. Docelowo magazyn danych jest zwykle implementowany jako plik bazy danych. W początkowej fazie modelowania systemu magazynem danych mogą być również inne obiekty takie jak segregator, szafa z dokumentami etc. Należy pamiętać, że magazyn danych jest strukturą statyczną. Oznacza to, że dane nie wychodzą z magazynu dopóki nie zażąda tego proces. Ponadto magazyn nie ulega zmianie jeżeli pakiet wychodzi z magazynu jest to tzw. odczyt nieniszczący. Innymi słowy kopia pakietu jest pobierana z magazynu, a stan magazynu pozostaje bez zmiany. PRZEPŁYW Przepływ przedstawia proces przenoszenia pakietów informacji pomiędzy elementami systemu lub pomiędzy obiektami zewnętrznymi oraz systemem. Przepływ przedstawia dane w ruchu podczas gdy magazyn danych przedstawia dane w spoczynku. Nazwa pakietu reprezentuje znaczenie pakietu poruszającego się wzdłuż przepływu. Należy pamiętać, że w modelu fizycznym systemu, tzn. modelu, który przedstawia stan obecny organizacji dla której chcemy zaprojektować system na przepływach oprócz pakietów informacji mogą pojawić się również obiekty fizyczne. GRAMATYKA DIAGRAMU W przypadku diagramów DFD istnieje zbiór reguł mówiących o zasadach poprawnego tworzenia diagramu. Brak komunikacji pomiędzy obiektami zewnętrznymi. Brak komunikacji pomiędzy magazynami danych magazyn danych komunikuje się z procesami. Brak komunikacji pomiędzy obiektami zewnętrznymi oraz magazynami danych. 8

Brak czarnych dziur. Czarną dziurą jest proces, który pobiera na wejściu pakiety informacji a nie generuje nic na wyjściu. Brak magicznych procesów. Magicznym procesem jest proces, który nic nie pobiera na wejściu a na wyjściu generuje przepływ. Diagram Przepływu Danych - Tworzenie diagramu DFD DIAGRAM KONTEKSTOWY Tworzenie diagramu przepływu danych rozpoczynamy od określenia obiektów zewnętrznych i stworzenia diagramu kontekstowego. Diagram kontekstowy to szczególny przypadek DFD, na którym pojedynczy proces reprezentuje cały modelowany system. Podobnie jak to miało miejsce w diagramie hierarchii funkcji przechodzimy od ogółu do sytuacji szczegółowej. W dalszych działaniach stosujemy zasadę dekompozycji. Diagram kontekstowy przedstawia proces komunikacji obiektów zewnętrznych z systemem. 9

Przykładowy diagram kontekstowy dla hipotetycznej firmy zajmującej się sprzedażą książek jest przedstawiony poniżej. DIAGRAMY NIŻSZYCH POZIOMÓW Po stworzeniu diagramu kontekstowego przechodzimy na tak zwany poziom "0", gdzie dekomponujemy proces występujący na diagramie kontekstowym na zbiór kluczowych procesów występujących w firmie. Każdy z procesów zajmuje się obsługą jednego lub więcej przepływów. W kolejnych krokach procesy zidentyfikowane na poziomie "0" są dalej dekomponowane aż do momentu, gdy poszczególne procesy mogą zostać opisane w tak zwanych minispecyfikacjach procesów. 10

11