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



Podobne dokumenty
Modelowanie danych Model związków-encji

Modelowanie danych Model związków-encji

Modelowanie danych, projektowanie systemu informatycznego

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

Modelowanie danych. Biologiczne Aplikacje Baz Danych

1 Projektowanie systemu informatycznego

Transformacja modelu ER do modelu relacyjnego

MODELOWANIE DANYCH. Biologiczne Aplikacje Baz Danych. dr inż. Anna Leśniewska

Projektowanie bazy danych

PLAN WYKŁADU BAZY DANYCH GŁÓWNE ETAPY PROJEKTOWANIA BAZY MODELOWANIE LOGICZNE

Systemy informatyczne. Modelowanie danych systemów informatycznych

Transformacja modelu ER do modelu relacyjnego

Bazy danych i usługi sieciowe

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

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

Modelowanie związków encji. Etapy budowy systemu informatycznego przedsiębiorstwa (1/4) Etapy budowy systemu informatycznego przedsiębiorstwa (2/4)

TRANSFORMACJA MODELU ER DO MODELU RELACYJNEGO

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

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

Temat: Modelowanie schematu bazy danych za pomocą diagramów związków encji (Entity Relationship Diagrams ERD)

Modelowanie związków encji. Etapy budowy systemu informatycznego przedsiębiorstwa (1/4) Etapy budowy systemu informatycznego przedsiębiorstwa (2/4)

Paweł Kurzawa, Delfina Kongo

Rysunek 1: Przykłady graficznej prezentacji klas.

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

Świat rzeczywisty i jego model

Projektowanie logiki aplikacji

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

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

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

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

Zaawansowane Modelowanie I Analiza Systemów Informatycznych

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

Język UML w modelowaniu systemów informatycznych

Autor: Joanna Karwowska

Technologie baz danych

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

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

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

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

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

Podstawy modelowania w języku UML

Wykład I. Wprowadzenie do baz danych

Projektowanie Systemów Informacyjnych

Modelowanie klas i obiektów. Jarosław Kuchta Projektowanie Aplikacji Internetowych

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

WYKŁAD 1. Wprowadzenie do problematyki baz danych

Projektowanie Zorientowane na Dziedzinę. ang. Domain Driven Design

Baza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego

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

Drużyny piłkarskie. Rozwiązanie

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

Mariusz Trzaska Modelowanie i implementacja systemów informatycznych

TECHNIKI MODELOWANIA STRUKTURY INFORMACYJNEJ

Podejście obiektowe - podstawowe pojęcia

Baza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego

Modelowanie związków encji

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

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

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

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

TECHNOLOGIE OBIEKTOWE. Wykład 3

Technologie obiektowe

MAS dr. Inż. Mariusz Trzaska

Bazy danych. Plan wykładu. Proces modelowania i implementacji bazy danych. Elementy ERD. Wykład 2: Diagramy zwizków encji (ERD)

Bazy danych wykład trzeci. trzeci Modelowanie schematu bazy danych 1 / 40

Bazy danych wykład trzeci. trzeci Przekształcenie modelu ER na model relacyjny 1 / 19

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

Wybrane problemy z dziedziny modelowania i wdrażania baz danych przestrzennych w aspekcie dydaktyki. Artur Krawczyk AGH Akademia Górniczo Hutnicza

problem w określonym kontekście siły istotę jego rozwiązania

Projektowanie BD Diagramy związków encji

Plan wykładu: Relacyjny model danych: opis modelu, podstawowe pojęcia, ograniczenia, więzy.

Projektowanie relacyjnych baz danych model związków encji (Entity-Relationship, ER)

UML w Visual Studio. Michał Ciećwierz

Bazy danych. Plan wykładu. Proces modelowania i implementacji bazy danych. Elementy ERD. Wykład 2: Diagramy zwizków encji (ERD)

Projektowanie baz danych

PLAN WYKŁADU BAZY DANYCH MODEL DANYCH. Relacyjny model danych Struktury danych Operacje Integralność danych Algebra relacyjna HISTORIA

TEORIA GRAFÓW I SIECI

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

Systemy GIS Systemy baz danych

Plan wykładu: Etapy projektowania bazy danych. Modelowanie danych za pomocą diagramów związków encji:

Bazy danych. Andrzej Łachwa, UJ, /15

z dnia r. w sprawie bazy danych obiektów topograficznych oraz mapy zasadniczej

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

Zaawansowane Modelowanie I Analiza Systemów Informatycznych

Inżynieria oprogramowania. Część 5: UML Diagramy klas

MODELOWANIE OBIEKTOWE

Diagramy klas. dr Jarosław Skaruz

ZARZĄDZANIU. Wykład VI. dr Jan Kazimirski

Modelowanie obiektowe - Ćw. 3.

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

Faza Określania Wymagań

Podejście obiektowe wprowadzenie

Tworzenie warstwy zasobów projektowanie metodą strukturalną

KSS: Modelowanie konceptualne przykład

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

Diagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych. Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska

Diagramy klas. WYKŁAD Piotr Ciskowski

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

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

Transkrypt:

Modelowanie danych. Model związków-encji

Plan wykładu Wprowadzenie do modelowania i projektowania kartograficznych systemów informatycznych Model związków-encji encje atrybuty encji związki pomiędzy encjami hierarchia generalizacji

Modelowanie - modele Modelowanie - odwzorowanie rzeczywistych obiektów świata rzeczywistego w systemie informatycznym (bazie danych) Modele koncepcyjne - reprezentacja obiektów w uniwersalnym modelu niezależnym od modelu implementacyjnego implementacyjne modele wykorzystywane do implementacji koncepcyjnych modele danych (relacyjne, obiektowe, itp.)

Cykl projektowy systemu informatycznego

Obiekty świata rzeczywistego Obiekty materialne obiekty kartograficzne, budynki, sprzęt geodezyjny zasoby ludzkie (grupa pracowników) Obiekty niematerialne wiedza (znajomość technologii) zdarzenia (otrzymanie nagrody, urlopu) stany rzeczywistości (stan rachunku bankowego, polisa ubezpieczeniowa) r

Model związków-encji Model związków-encji (entity-relationship model - ER) obiekty świata rzeczywistego reprezentowane za pomocą encji (entities) powiązania między obiektami świata rzeczywistego reprezentowane za pomocą związków (relationships) pomiędzy encjami

Encja Reprezentuje zbiór obiektów opisany tymi samymi cechami (atrybutami, własnościami) Informacje o tych obiektach będą przechowywane w bazie danych Konkretny obiekt świata rzeczywistego jest reprezentowany jako wystąpienie encji (instancję encji)

Modelowanie encji (1) Obiekty świata rzeczywistego Firma posiada sprzęt geodezyjny. Chcemy przechowywać informacje nt. typu, gwarancji, danych technicznych).

Modelowanie encji (2) Obiekty świata rzeczywistego firma kartograficzna posiada mapy: chcemy mieć wiedzę o ich numerach, odwzorowaniach, skali, dacie wydania, rzucie itd.

Modelowanie encji (2) Każda encja posiada unikalną nazwę zbiór cech (atrybutów) Encje wchodzą w związki z innymi encjami wyjątkiem są encje reprezentujące dane słownikowe i konfiguracyjne Dowolna rzecz lub obiekt może być reprezentowana tylko przez jedną encję Nazwa encji powinna być rzeczownikiem w liczbie pojedynczej

Atrybuty encji (1) Identyfikator atrybut lub zbiór atrybutów jednoznacznie identyfikujący wystąpienie encji zbiór atrybutów + związki związki Identyfikatory naturalne -PESEL, NIP, nr dowodu, nr paszportu, nr rejestracyjny, ISBN Identyfikatory sztuczne -numer pozycji katalogowej, identyfikator sprzętu

Atrybuty encji (2) Deskryptory (atrybuty deskrypcyjne) wszystkie inne atrybuty poza identyfikatorami reprezentują podstawowe cechy/własności encji cechy te będą przechowywane w bazie danych atrybuty z wartościami opcjonalnymi atrybuty z wartościami obowiązkowymi

Definicja atrybutu encji Nazwa Dziedzina typ danych i maksymalny rozmiar zbiór dozwolonych wartości zakres dozwolonych wartości Dozwolone / niedozwolone wartości puste Opcjonalnie unikalność wartości

Atrybuty encji - przykład Pracownicy firmy są opisani numerem PESEL, adresem zamieszkania, pensją i opcjonalnie numerem telefonu

Związek Związek (asocjacja) reprezentuje powiązania pomiędzy obiektami świata rzeczywistego klienci posiadają rachunki bankowe studenci otrzymują oceny z egzaminów W modelu ER związek łączy encje Związek z każdego końca posiada krótki opis ułatwiający interpretację związku

Związki Modelowanie związków (1) Pracownicy firmy posiadają różne samochody. Chcemy przechować informację na temat faktu posiadania samochodu przez pracownika.

Modelowanie związków (2) Wiemy, że istnieje związek pomiędzy pracownikami a samochodami Chcielibyśmy wiedzieć: Ile samochodów może posiadać pracownik? Ilu pracowników może posiadać ten sam samochód? Czy każdy samochód musi do kogoś należeć? Czy każdy pracownik musi posiadać samochód?

Cechy związku Stopień związku unarny (binarny rekursywny) binarny ternarny n-arny Typ asocjacji (kardynalność) - jeden-do-jeden (1:1) jeden-do-wiele (1:M) wiele-do-wiele (M:N) Istnienie (klasa przynależności) opcjonalny obowiązkowy

Cechy związku - przykład (1) Pracownicy firmy posiadają samochody W celu udostępnienia miejsca parkingowego należy zarejestrować pracownika i jego samochód Każdy pracownik ma prawo parkować tylko jeden konkretny samochód Nie każdy pracownik ma samochód Zarejestrowany w rejestrze parkingowym samochód na pewno jest własnością jednego pracownika

Interpretacja Typ asocjacji 1:1 - przykład (2) pracownik może być kierownikiem tylko jednego działu istnieją pracownicy, którzy nie kierują żadnym działem każdy dział musi być kierowany przez dokładnie jednego pracownika

Typ asocjacji 1:M (1) Związek binarny typu jeden-do-wiele (1:M) Każdy pracownik pracuje dokładnie w jednym dziale. Dział może zatrudniać (ale nie koniecznie) wielu pracowników.

Typ asocjacji 1:M (2) Interpretacja każdy pracownik musi pracować w jakimś dziale w jednym dziale pracuje jeden lub wielu pracowników dział może zatrudniać pracowników istnieją działy, które nie zatrudniają pracowników

Typ asocjacji 1:M (3) Związek binarny 1:M obustronnie obowiązkowy Drużyna piłkarska musi być złożona z zawodników nie ma drużyny bez zawodników Każdy piłkarz należy do dokładnie jednej drużyny piłkarz, który nie należy do drużyny (nie gra) nie jest Piłkarzem

Typ asocjacji 1:M (4) Związek binarny 1:M obustronnie obowiązkowy z każdym rachunkiem bankowym musi być związana historia operacji na nim istniejąca operacja została wykonana na konkretnym rachunku nie istnieją operacje nie związanych z rachunkiem

Typ asocjacji M:N (1) Związek binarny typu wiele-do-wiele (M:N) Pracownik może brać udział w jednym lub wielu projektach; może też nie brać udziału w żadnym projekcie. Każdy projekt Realizuje przynajmniej jeden pracownik. r

Interpretacja Typ asocjacji M:N (2) pracownik może brać udział w projekcie -istnieją pracownicy nie biorący udziału w żadnym projekcie projekt musi być realizowany przez przynajmniej jednego pracownika w tym samym projekcie może brać udział wielu pracowników

Typ asocjacji M:N (3) Związek binarny M:N obustronnie opcjonalny każdy student może należeć do jednej lub wielu organizacji studenckich -mogą istnieć studenci nie należący do żadnej organizacji dana organizacja może zrzeszać jednego lub wielu Studentów -mogą istnieć organizacje, które nie zrzeszają żadnego Studenta

Atrybuty związku (1) Związek binarny typu wiele-do-wiele (M:N) Pracownik może brać udział w jednym lub wielu projektach; może też nie brać udziału w żadnym projekcie. Każdy projekt realizuje przynajmniej jeden pracownik. Dla pracowników, którzy biorą udział w projektach należy zapamiętać ich funkcję, wynagrodzenie oraz daty początku i końca ich udziału w projekcie.

Atrybuty związku (2) Jeśli związek posiada dodatkowe cechy należy wprowadzić dodatkową encję (Realizacja) Do encji tej dochodzą obowiązkowe związki typu wiele interpretacja obowiązkowości związków jeśli istnieje wystąpienie encji Realizacja, to musi ono dotyczyć jakiegoś projektu i pracownika nie może istnieć realizacja bez pracownika i projektu

Encja słaba Encja słaba (weak entity) nie posiada swojego identyfikatora wystąpienia encji mogą istnieć tylko w kontekście wystąpień encji powiązanych z encją słabą konkretne wystąpienie encji Realizacja może wystąpić wyłącznie w kontekście konkretnego pracownika i konkretnego projektu

Związek binarny rekursywny (1) Określa powiązanie pomiędzy wystąpieniem encji a innym wystąpieniem tej samej encji Modelowanie zależności służbowych

Związek binarny rekursywny (2) Modelowanie elementów złożonych Istnieją podzespoły elementarne, niedekomponowalne i Podzespoły złożone. Podzespół złożony składa się z kolejnych podzespołów. Każdy z kolejnych podzespołów może być złożony z innych podzespołów. Poziom złożoności podzespołów nie może być dowolny.

Związki ternarne (1) Związek ternarny Kierowca może otrzymać mandat za popełnione wykroczenie. Mandat jest wystawiany przez konkretnego policjanta.

Związki ternarne (2) W omawianej notacji związek ternarny jest reprezentowany jako encja (Mandat) do encji Mandat dochodzą związki obowiązkowe - jeśli wystawiono mandat to jest on dla konkretnej osoby, - został wystawiony przez konkretnego policjanta i dotyczy konkretnego wykroczenia

Związki wyłączne Związki wyłączne (exclusive relationships) konkretne wystąpienie encji może w danym momencie wchodzić tylko w jeden z ze związków

Hierarchia encji / generalizacja Związek generalizacji określa, że pewne encje o wspólnym zbiorze atrybutów można uogólnić i stworzyć encję wyższego poziomu encję generalizacji Encje niższego poziomu w hierarchii generalizacji encje specjalizacji Relacja opisująca związki typu generalizacja/specjalizacja pomiędzy encjami hierarchia generalizacji/specjalizacji lub hierarchia encji

Hierarchia encji (1) Dziedziczenie atrybutów Firma zatrudnia pracowników kontraktowych i godzinowych. Wszyscy pracownicy posiadają pewien zbiór wspólnych atrybutów (PESEL, imię, nazwisko, adres). Pracownicy kontraktowi i godzinowi posiadają specyficzne dla siebie atrybuty. Dla pracowników kontraktowych jest to numer kontraktu, a dla pracowników godzinowych są to: liczba godzin pracy w tygodniu i stawka godzinowa.

Interpretacja Hierarchia encji (2) podencje dziedziczą wszystkie atrybuty swojej nadencji każde wystąpienie nadencji jest zawsze wystąpieniem jednej podencji semantyka związku generalizacji oznacza, że każde wystąpienie podencji JEST wystąpieniem nadencji pracownik kontraktowy JEST pracownikiem pracownik godzinowy JEST pracownikiem identyfikator nadencji jest wspólny dla wszystkich jej podencji podencje nie posiadają swoich identyfikatorów