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



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

Projektowanie baz danych za pomocą narzędzi CASE

Autor: Joanna Karwowska

1 Projektowanie systemu informatycznego

Modelowanie danych, projektowanie systemu informatycznego

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

Systemy informatyczne. Modelowanie danych systemów informatycznych

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

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

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

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

ZSE - Systemy baz danych 1 ZASADY PROJEKTOWANIA BAZ DANYCH

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

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

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

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

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

Modelowanie obiektowe - Ćw. 3.

Modelowanie związków encji

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

Baza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego

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

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

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

Bazy danych 2. dr inż. Tadeusz Jeleniewski

Projektowanie baz danych

Projektowanie bazy danych

Projektowanie bazy danych przykład

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

Podstawy programowania III WYKŁAD 4

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

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

Świat rzeczywisty i jego model

Paweł Kurzawa, Delfina Kongo

Wykład I. Wprowadzenie do baz danych

Projektowanie BAZY DANYCH

Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34

Technologia informacyjna

Zaawansowane Modelowanie I Analiza Systemów Informatycznych

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

Bazy danych i usługi sieciowe

Bazy Danych i Systemy informacyjne Wykład 7. Piotr Syga

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

Baza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego

UML w Visual Studio. Michał Ciećwierz

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

TECHNIKI MODELOWANIA STRUKTURY INFORMACYJNEJ

Projekt małej Bazy Danych.

Zastosowanie metody CASE do analizy systemu informacyjnego

Projektowanie Graficznych Interfejsów Użytkownika Robert Szmurło

Wykład 1 Inżynieria Oprogramowania

Technologie baz danych

Zaawansowane Modelowanie I Analiza Systemów Informatycznych

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

Bazy danych. Andrzej Grzybowski. Instytut Fizyki, Uniwersytet Śląski

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

Model logiczny SZBD. Model fizyczny. Systemy klientserwer. Systemy rozproszone BD. No SQL

Projektowanie logiki aplikacji

Inżynieria Programowania Inżynieria wymagań. Plan wykładu. Motto. Wstęp. Notatki. Notatki. Notatki. Notatki. Arkadiusz Chrobot

Zasady transformacji modelu DOZ do projektu tabel bazy danych

Projektowanie Systemów Informacyjnych

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

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

Podejście obiektowe - podstawowe pojęcia

Modelowanie i analiza systemów informatycznych

Język UML w modelowaniu systemów informatycznych

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

Przykłady normalizacji

ZARZĄDZANIE I INŻYNIERIA PRODUKCJI

Bazy danych. Andrzej Łachwa, UJ, /15

TECHNOLOGIE OBIEKTOWE. Wykład 3

Wykaz osób, które będą uczestniczyć w wykonywaniu zamówienia

Wprowadzenie do baz danych

KSS: Modelowanie konceptualne przykład

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

Wymiar poziomy: oś na której umieszczono instancje klasyfikatorów biorące udział w interakcji.

Procesowa specyfikacja systemów IT

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

Rysunek 1: Przykłady graficznej prezentacji klas.

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

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

TRANSFORMACJA MODELU ER DO MODELU RELACYJNEGO

Analizy systemowa a filozofia. Piotr Kulicki

Szczegółowa specyfikacja funkcjonalności zamawianego oprogramowania.

Wprowadzenie do projektowania i wykorzystania baz danych Relacje i elementy projektowania baz

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

Pojęcie bazy danych. Funkcje i możliwości.

PRZEWODNIK PO PRZEDMIOCIE

Inżynieria Programowania Inżynieria wymagań

Baza danych to zbiór wzajemnie powiązanych ze sobą i zintegrowanych danych z pewnej dziedziny.

ANALIZA SYSTEMOWA A FILOZOFIA

Podstawy projektowania systemów komputerowych

Diagramy czynności Na podstawie UML 2.0 Tutorial

Tworzenie warstwy zasobów projektowanie metodą strukturalną

PRZEWODNIK PO PRZEDMIOCIE

Modelowanie testów. czyli po co testerowi znajomość UML

ANALIZA EKONOMICZNO-FINANSOWA

Bazy Danych. Bazy Danych i SQL Podstawowe informacje o bazach danych. Krzysztof Regulski WIMiIP, KISiM,

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

Co to jest jest oprogramowanie? 8. Co to jest inżynieria oprogramowania? 9. Jaka jest różnica pomiędzy inżynierią oprogramowania a informatyką?

Transkrypt:

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 - entity relationship model), którego graficznym odpowiednikiem jest diagram związków encji (ERD - entity relationship diagram). Diagram ten spotyka się w różnych notacjach, do których zaliczamy m.in. notacje Chena, Martina, Bachmana, IDEF1X. Diagram ERD to rodzaj graficznego przedstawienia związków pomiędzy encjami używany w projektowaniu systemów informacyjnych. ERD pozwala na zrozumienie struktury danych, przygotowania późniejszej strategii optymalizacji bazy oraz stanowi podstawową dokumentację systemu przechowywania informacji. ERD jest częścią wielu popularnych narzędzi CASE (Computer Aided Software Engineering), pozwalających na wygenerowanie fizycznej struktury bazodanowej na podstawie zaprojektowanego diagramu. Systemy CASE, które wspierają tworzenia tych diagramów, mogą na ich podstawie automatycznie tworzyć bazy danych odpowiadające relacjom na diagramie. Przykłady diagramów ERD w różnych notacjach:

Diagram ERD przedstawia: obiekty, o których informacje są istotne z punktu widzenia realizacji celów strategicznych firmy; atrybuty obiektów; 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 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 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. KLIENT składa ZAMÓWIENIE Arność: Jeden do Jeden-lub-Wiele

DOSTAWCA dostarcza TOWAR Arność: Wiele do Wiele KLIENT posiada NIP Arność: Jeden do Jeden (opcjonalnie) Związek NADTYP-PODTYP Związek nadtyp-podtyp obejmuje zwykle typ obiektu oraz jedną lub więcej podkategorii. Atrybuty nadtypu odnoszą się do wszystkich podtypów, natomiast atrybuty podtypów są unikalne w zakresie podtypu. Poniżej znajduje się przykład związku nadtyp-podtyp opisujący klienta w rozbiciu na klienta indywidualnego oraz instytucjonalnego.

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; 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; 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; 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. Na podstawie zidentyfikowanych obiektów oraz powiązań między nimi możemy narysować wstępny diagram związków encji. PRZYKŁAD Weryfikacja

WERYFIKACJA POD KĄTEM WYMAGAŃ UŻYTKOWNIKA Otrzymany na podstawie opisu organizacji model należy zweryfikować, pod kątem spełnienia wymagań użytkownika. Jest to oczywiście wstępna weryfikacja, gdyż na etapie analizy próbujemy formalnie naszkicować część modelowanej rzeczywistości, natomiast podczas etapu projektowania modele te zostaną rozwinięte i uszczegółowione. Jeżeli utworzony model danych nie spełnia wymagań użytkownika, to należy uzupełnić go o dodatkowe obiekty i powiązania. WERYFIKACJA POD KĄTEM SPÓJNOŚCI PERSPEKTYW PRZEDSIĘBIORSTWA Jeżeli modelujemy kilka fragmentów firmy, zawarcie wszystkiego w jednym diagramie jest właściwie niemożliwe. Nawet w przypadku stworzenia takiego diagramu jest on nieczytelny i trudny do analizy. W takich przypadkach można zastosować rozbicie wg perspektyw przedsiębiorstwa. Perspektywa przedsiębiorstwa jest to zbiór obiektów zawartych w polu zainteresowań wybranej grupy pracowników firmy. Oczywiście perspektywy mogą się częściowo nakładać. Wynika to z faktu, że różne grupy pracowników mogą korzystać z podobnych informacji. 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 Engineering). Dzięki narzędziom CASE, proces tworzenia systemu staje się o wiele krótszy pociągając za sobą mniejsze koszty. Ponadto narzędzia CASE zapewniają wyższą jakość tworzonego systemu. Narzędzia CASE zawierają w sobie inżynierię dwustronną: inżynieria do przodu oraz inżynieria wstecz. Inżynieria do przodu jest niczym innym jak generacją kodu na podstawie modelu. Inżynieria wstecz to proces analizy oprogramowania, którego celem jest odtworzenie projektu i specyfikacji. W tym procesie program nie ulega zmianie. Kod źródłowy oprogramowania jest zwykle dostępny i stanowi daną wejściową dla procesu inżynierii wstecz. Celem inżynierii wstecz jest określenie projektu i specyfikacji systemu na podstawie kodu źródłowego. Przykładem tego typu narzędzia jest program DBDesigner4. Jest to system wizualnego projektowania, modelowania i tworzenia baz danych. Program jest w całości darmowy i mona go pobrać ze strony internetowej: http://fabforce.net/index.php. DBDesigner4 jest w wersji zarówno dla systemu Windows jak i Linux.