MODELOWANIE DANYCH - DIAGRAMY ENCJI-ZWIĄZKÓW Notacja Barkera.

Slides:



Advertisements
Podobne prezentacje
7. Metody analizy i modelowania strukturalnego SI
Advertisements

Projektowanie baz danych
Modelowanie przypadków użycia
Modelowanie klas i obiektów
Kamil Łącki Dominik Strzelichowski
Implementacja asocjacji
Sztuczna Inteligencja Reprezentacja wiedzy II
Inżynieria oprogramowania
MS Access 2000 Normalizacja Paweł Górczyński 2005.
Projektowanie Aplikacji Komputerowych
08: ERD – podencje, łuki i pułapki
Modelowanie model związków encji
Inteligentne Systemy Informacyjne
Programowanie zorientowane obiektowo 1 Programowanie zorientowane obiektowo (object-oriented programming) jest to metodologia programowania bazująca na.
Tablice jednowymiarowe 1
POWTÓRZENIE Techniki zbierania informacji : Analiza dokumentacji
Projektowanie systemów informacyjnych
Wprowadzenie Sformułowanie problemu Typy reguł asocjacyjnych
Diagramy klas w języku UML
Projektowanie i programowanie obiektowe II - Wykład IV
Projektowanie i programowanie obiektowe II - Wykład II
Modele baz danych - spojrzenie na poziom fizyczny
Projektowanie - wprowadzenie
Model dziedziny. Świat rzeczywisty i jego model Świat rzeczywisty (dziedzina problemu) Świat obiektów (model dziedziny) Samochód Osoba Dom Modelowanie.
Wykład 4 Analiza i projektowanie obiektowe
Wykład 3 Analiza i projektowanie strukturalne
Teoria relacyjnych baz danych
Bazy Danych II prowadzący: mgr inż. Leszek Siwik
Unified Modeling Language graficzny język wizualizacji, specyfikowania, tworzenia i dokumentowania systemów informatycznych.
DIAGRAMY ER 2 (ENTITY-RELATIONSHIP DIAGRAMS 2) Ćwiczenia 2.
Diagramy ER (Entity-relationship diagrams)
OMT - Model obiektów, cz.3.
XML – eXtensible Markup Language
Wybrane zagadnienia relacyjnych baz danych
Model relacyjny.
Programowanie obiektowe – język C++
1 Analiza obiektowa Peter Coad / Edward Yourdon Analiza obiektowa wydawnictwo: Oficyna Wydawnicza READ ME, Warszawa 1994 dr Waldemar Wolski.
Programowanie obiektowe 2013/2014
ZWIĄZKI MIĘDZY KLASAMI KLASY ABSTRAKCYJNE OGRANICZENIA INTERFEJSY SZABLONY safa Michał Telus.
Modelowanie obiektowe Diagramy klas
Projektowanie relacyjnych baz danych – postacie normalne
UML W V ISUAL S TUDIO Mateusz Lamparski. UML D EFINICJA Unified Modeling Language (UML) to graficzny język do obrazowania, specyfikowania, tworzenia i.
Interakcja człowiek – komputer Podstawy metod obiektowych mgr inż. Marek Malinowski Zakład Matematyki i Fizyki Wydz. BMiP PW Płock.
Temat 3: Integralność danych. Integralność danych, określana również mianem spójności danych, jest to funkcja SZBD, która gwarantuje, że dane nie zostaną.
Michał Krawczykowski kl. IIIB
Model obiektowy bazy danych
Zadania – diagram klas.
Slajd 1© J.Rumiński Jacek Rumiński  Bazy danych Kontakt: Katedra Inżynierii Biomedycznej, pk. 106, tel.: , fax: ,
OCL.
Modelowanie obiektowe - system zarządzania projektami.
Projektowanie relacyjnych baz danych – diagramy związków encji
Projektowanie bazy danych z użyciem diagramów UML Obiektowe projektowanie relacyjnej bazy danych Paweł Jarecki.
Modelowanie model związków encji
Wstęp do systemów informatycznych Diagramy klas. Odbiór świata  Myślenie o dziedzinie problemu powinno być możliwie zbliżone do myślenia o systemie 
Zarządzanie projektami
Wykład 5 Model obiektowy (3)
Modelowanie Danych (ERD) – część 1 (Wspomaganie Modelowania danych)
Asocjacja,Kompozycja,Agregacja
Modelowanie Danych (ERD) – część 2. Staranny i przejrzysty Staranny i przejrzysty Niedwuznaczny tekst Niedwuznaczny tekst Łatwy do zapamiętania Łatwy.
Implementacja asocjacji (z atrybutami i bez) przy użyciu: referencji (kolekcji referencji) tablic asocjacyjnych przygotował: Kamil Kowalczyk.
Zaawansowane modelowanie danych (część 3). Modelowanie danych hierarchicznych Firma Oddział Zespół Dział Zespół # nazwa Dział # * nazwa Oddział # * nazwa.
Temat: Tworzenie bazy danych
PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH dr hab. inż. Maciej Zakrzewicz Instytut Informatyki Politechnika Poznańska (c) M.Zakrzewicz,M.Matysiak.
Transformacja modelu EER do modelu relacyjnego
Inżynieria systemów informacyjnych
Projektowanie systemów informacyjnych
PGO Dziedziczenie Michail Mokkas.
Modele baz danych - spojrzenie na poziom fizyczny
Zapis prezentacji:

MODELOWANIE DANYCH - DIAGRAMY ENCJI-ZWIĄZKÓW Notacja Barkera

Źródło modelu encji-związków Semantic networks - Quillian [1968] Is-part-of Street Address Is-part-of City Last_name Name Start_date Is-part-of Is-part-of Zip_code First_name Is-part-of Is-part-of Is-part-of Telephone Is-part-of Is-part-of Is-associated-with EMPLOYEE PROJECT Is-part-of Is-part-of Isa Isa Customer Budget HOURLY EMPLOYEE CONTRACT EMPLOYEE Is-part-of stosujemy do modelowania obiektów złożonych Isa stosujemy do modelowania związku dziedziczenia Is-associated-with stosujemy do modelowania zależności pomiędzy encjami Is-part-of Is-part-of Is-part-of hours_worked hourly_wage contractid

Model encji-związków (ER) ER notacja CHEN’a [1976] name street city zip code last name start date first name EMPLOYEE PROJECT budget m n Is_involved_in customer Isa Konstruktory: encje atrybuty związki hierarchie Contract E. Hourly E. cont.id h_work h_wages

Obiekty świata rzeczywistego Obiekty rzeczywiste pracownik, samochód, produkt, etc. CAR company_name factory_number max_speed Inne obiekty konto, zamówienia, grupa, etc. EMPLOYEE GROUP name number of employees average salary Zdarzenia choroba, nagroda, etc. ILLNESS start_date end_date type_of_illness KNOWLEDGE OF FOREIGN LANGUAGE language_name knowledge_degree Fakty znajomość języków obcych, stan konta, etc.

ENCJA Encja jest zbiorem obiektów posiadających wspólne własności, o których chcielibyśmy przechowywać informacje NAZWA ENCJI encja

Encja i wystąpienie encji Obiekty świata rzeczywistego Firma zatrudnia pracowników. Chcemy przechowywać informacje nt. danych personalnych pracowników (imię, nazwisko, adres i numer telefonu). Eva Brown Black Street 5/2 phone 753-624 Andy Green White Street 17 phone 333-951 John Smith Long Street 23 phone 253-485 Identyfikacja wspólnych cech obiektów Encja Employee first_name last_name address telephone Wystąpienia encji Employee first name = John last name = Smith address = Long Street 23 telephone = 256-485 Model Reguły dotyczące encji: Encja jest zbiorem obiektów nazywanych instancjami encji Nazwa encji powinna być rzeczownikiem w l. pojedynczej Dowolna rzecz lub obiekt może być reprezentowana tylko przez jedną encję; każda encja musi być jednoznacznie identyfikowalna

asocjacji posiadających Związki i asocjacje Asocjacje Pracownicy posiadają różne samochody. has Eva Brown Nissan belongs_to Identyfikacja asocjacji posiadających wspólne własności Andy Green has John Smith Opel belongs_to Istnieje asocjacja pomiędzy pracownikami a samochodami: pracownik może posiadać samochód samochód może należeć do pracownika Model Asocjacja i jej interpretacja has EMPLOYEE CAR belongs_to

ZWIĄZEK Związek reprezentuje asocjację występującą w świecie rzeczywistym pomiędzy jedną a kilkoma encjami Encja A Encja B związek

Związki Wiemy, że: Istnieje asocjacja pomiędzy encjami EPLOYEE i CAR has Eva Brown Nissan belongs_to Andy Green has John Smith Opel belongs_to has EMPLOYEE CAR belongs_to Wiemy, że: Istnieje asocjacja pomiędzy encjami EPLOYEE i CAR Chcielibyśmy wiedzieć: Ile samochodów pracownik może posiadać? Ilu pracowników może posiadać ten sam samochód? Czy każdy samochód musi do kogoś należeć?

Związki Konkretne wystąpienie związku nazywamy instancją związku Związki opisujemy w następujących terminach: stopień związku, typ asocjacji, rozmiar związku, i istnienie (klasa przynależności)

Własności związku Stopień związku określa liczbę encji występujących w związku: związek unarny (binarny rekursywny) związek binarny związek ternarny związek n-arny Typ asocjacji związku opisuje odwzorowanie pomiędzy wystąpieniami encji w związku. Typ asocjacji może przyjmować wartość “jeden” lub “wiele”. Aktualna liczba związana z typem asocjacji nosi nazwę rozmiaru związku. Wyróżniamy następujące typy asocjacji: związek jeden-do-jeden związek jeden-do-wiele związek wiele-do-wiele

Typ asocjacji (1:1) SALES ACCOUNT Związek typu jeden-do-jeden (1:1) Każdy dział musi mieć szefa, natomiast pracownik może być szefem co najwyżej jednego działu. manages Eva Brown SALES Andy Green is_ managed_by John Smith manages ACCOUNT Sam Yellow is_managed_by Związek typu jeden-do-jeden (1:1) manages EMPLOYEE Department is_managed_by Interpretacja: Pracownik może być szefem tylko jednego działu. Dział może być zarządzany dokładnie przez jednego pracownika.

Typ asocjacji (1:N) Związek typu jeden-do-wiele (1:N) Każdy pracownik pracuje dokładnie w jednym dziale; dział może zatrudniać (ale nie koniecznie) wielu pracowników. works_in Smith SALES has works_in has Brown ACCOUNT has works_in White Związek typu jeden-do-wiele (1:N) MARKETING works_in EMPLOYEE DEPARTMENT has Interpretacja: Pracownik pracuje dokładnie w jednym dziale. Dział może zatrudniać zero, jednego lub wielu pracowników.

Typ asocjacji (M:N) Project ALFA Project BETA Związek typu wiele-do-wiele (M:N) Pracownik może pracować nad jednym, lub wieloma (lub żadnym) projektami. Nad każdym projektem pracuje jeden lub wielu pracowników. works_on Brown Project ALFA Green is_worked_on Smith White works_on Yellow Project BETA is_worked_on Związek typu wiele-do-wiele (M:N) works_on EMPLOYEE PROJECT is_worked_on Interpretacja: Pracownik może pracować w zero, jednym lub wielu projektach. Nad każdym projektem pracuje jeden lub wielu pracowników.

Typ asocjacji Związek typu Związek typu Związek typu jeden-do-jeden jeden-do-wiele Związek typu wiele-do-wiele

Klasa przynależności związku has belongs_to Eva Brown Nissan belongs_to Andy Green Fiat has John Smith Opel belongs_to Związek opcjonalny w świecie rzeczywistym: nie każdy pracownik posiada samochód. często nie wiemy czy pracownik posiada samochód. Związek opcjonalny w świecie rzeczywistym : samochód musi należeć do co najmniej jednego pracownika Jednostronny związek obowiązkowy has EMPLOYEE CAR belongs_to Interpretacja: Każdy pracownik może posiadać zero, jeden lub wiele samochodów. Każdy samochód musi należeć do co najmniej jednego pracownika.

Związki opcjonalne i obowiązkowe (kont.) Związek dwustronnie obowiązkowy Firma posiada ciężarówki. Dla każdej ciężarówki musimy pamiętać informacje dotyczące przeglądu technicznego. Każdy przegląd dotyczy jednej ciężarówki. Związek dwustronnie opcjonalny Każde stowarzyszenie może posiadać zero, jednego, lub wielu członków inżynierów. Każdy inżynier może być członkiem jednego lub wielu (lub żadnego) stowarzyszenia. has belongs_to TRUCK SERVICE ENGINEER PROF_ASSOC has concerns

Związki binarne SALES ACCOUNT Asocjacja pomiędzy dwoma obiektami Eva Brown works in works in SALES Andy Green has works in John Smith has works in Sam Yellow ACCOUNT Asocjacja pomiędzy dwoma obiektami Związek binarny works in EMPLOYEE DEPARTMENT has Związek binarny

Związek binarny rekursywny Pracownicy są podzieleni na grupy. Każda grupa posiada swojego lidera Związek binarny rekursywny określa powiązanie pomiędzy wystąpieniem określonej instancji encji a innym wystąpieniem tej samej encji is subordinate EMPLOYEE is leader

Związki ternarne Project ALFA Manager Designer Asocjacja pomiędzy Eva Brown Manager Andy Green Designer Asocjacja pomiędzy trzema obiektami Sam Yellow Advisor Project BETA Związek ternarny works_on as Związek ternarny EMPLOYEE POSITION is_worked_on PROJECT

GENERALIZACJA LUB HIERARCHIA ENCJI 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ę nadklasy nazywaną często encją generalizacji Encje niższego poziomu – encje specjalizacji (podklasy) w hierarchii generalizacji – mogą zawierać rozłączne lub nakładające się na siebie podzbiory wystąpień encji generalizacji Relacja opisująca związki typu generalizacja/specjalizacja pomiędzy encjami nosi nazwę hierarchii generalizacji/specjalizacji lub hierarchii encji

Hierarchia encji Hierarchia encji Dziedziczenie atrybutów Firma zatrudnia pracowników kontraktowych i godzinowych. Wszyscy pracownicy posiadają pewien zbiór wspólnych atrybutów, jednakże zarówno pracownicy kontraktowi jak i godzinowi posiadają specyficzne atrybuty John Smith Napolean Street 2 hours_worked = 200 hourly_wage = 5 usd/h Andy Green Long Street 14/7 contractid = X57813862 hourly employees contract employees Hierarchia encji nadklasa Cechy hierarchii encji: Encje podklasy dziedziczą wszystkie atrybuty swojej encji nadklasy Każde wystąpienie encji nadklasy jest zawsze wystąpieniem jednej z encji podklasy. EMPLOYEE first_name last_name address CONTRACT EMPLOYEE contractid HOURLY EMPLOYEE hours_worked hourly_wage atrybuty wspólne podklasy atrybuty specyficzne

Hierarchia encji (kont.) Dziedziczenie związków Każdy pracownik pracuje na określonym stanowisku w swoim dziale. Dla pracowników kontraktowych chcielibyśmy przechowywać informację o firmach, w których byli uprzednio zatrudnieni. DEPARTMENT POSITION Związki: works_in i works_ as, dotyczą zarówno pracowników kontraktowych jak i godzinowy Związek worked in jest związkiem specyficznym obowiązującym tylko pracowników kontraktowych. has is_hold works_ in works_ as CONTRACT EMPLOYEE HOURLY EMPLOYEE EMPLOYEE worked in COMPANY consisted_of Własność hierarchii generalizacji: Wszystkie podklasy dziedziczą wszystkie związki swojej encji nadklasy

Atrybuty Wyróżniamy dwa typy atrybutów: identyfikatory deskryptory Identyfikator pozwala na jednoznaczną identyfikację dowolnej instancji (wystąpienia) encji Deskryptor służy do specyfikacji nieunikalnej własności dowolnej instancji (wystąpienia) encji Identyfikatory jak i deskryptory mogą być pojedynczymi atrybutami lub atrybutami złożonymi. Atrybuty mogą być jednowartościowe lub wielowartościowe

Unikalny identyfikator encji Każda encja musi być jednoznacznie identyfikowalna, tak aby można było odróżnić różne wystąpienia tej samej encji. Unikalny identyfikator encji może być pojedynczym atrybutem, kombinacją atrybutów, kombinacją związków, lub kombinacją atrybutów i związków. Identyfikatory naturalne PROJECT # symbol name budget start date end date PROJECT # symbol # start date name budget end date lub Sztuczne identyfikatory Kiedy: liczba atrybutów zapewniająca unikalność > 2, duże rozmiary wartości identyfikatora, wartości identyfikatora są często aktualizowane, EMPLOYEE # id_employee first name name address telephone

Własności atrybutów - ograniczenia integralnościowe Dziedzina atrybutu Zbiór wartości jakie może przyjmować atrybut encji. Notacja: project_name - VARCHAR(25) salary - NUMBER(8,2) Atrybuty obowiązkowe Atrybut, którego wartości muszą być zdefiniowane dla wszystkich instancji danej encji Notacja: * name o second_name Unikalny identyfikator Wartość identyfikatora musi być unikalna i zdefiniowana dla wszystkich instancji danej encji Notacja: # project_symbol Ograniczenie dziedziny atrybutu Dodatkowe ograniczenie nałożone na zbiór wartości danego atrybutu; zdefiniowane w postaci wyrażenia logicznego lub referencji do innych atrybutów Przykład: check(day(pay_date) <> ’Sunday’), check(end_date > start_date) Dynamiczne ograniczenia integralnościowe Zbiór dopuszczalnych przejść stanów danego atrybutu. Przykład: kawaler, żonaty, wdowiec

Własności związków – ograniczenia integralnościowe Związek obowiązkowy/opcjonalny: Dla każdej instancji encji musi istnieć odpowiadająca jej instancja związku Związek obowiązkowy Związek opcjonalny EMPLOYEE assigned_to EMPLOYEE works_in Unikalność: (patrz definicja encji słabej) PRODUCT BALANCE OF WAREHOUSE WAREHOUSE concern product describe quantity in Wyłączność (łuk): “każda pozycja może dotyczyć jednego i tylko jednego produktu lub jednej i tylko jednej usługi” ITEM PRODUCT SERVICE concerns Związki trwałe (nie-transferowalne): Związek jest trwały jeżeli dowolna instancja encji w tym związku nie może być rozłączona lub przełączona do innej instancji tej samej encji. ORDER ORDERED ITEM contains belongs_to

Unikalny identyfikator hierarchii generalizacji Metody definiowania identyfikatorów w hierarchii generalizacji : wiele identyfikatorów na najniższym poziomie hierarchii jeden identyfikator na najwyższym poziomie hierarchii generalizacji EMPLOYEE first_name last_name address CONTRACT EMPLOYEE contractid HOURLY EMPLOYEE hours_worked hourly-wage Unikalny identyfikator na poziomie encji nadklasy: wspólne, naturalne atrybuty encji nadklasy, sztuczny atrybut dodany do encji nadklasy, kombinacja związków encji nadklasy, kombinacja związków i atrybutów encji nadklasy WŁASNOŚCI: Unikalny identyfikator jest dziedziczony przez wszystkie podklasy. Umożliwia identyfikację wszystkich instancji wszystkich podklas Unikalne identyfikatory definiowane na poziomie podklas: Dla każdej podklasy na najniższym poziomie hierarchii definiujemy niezależny unikalny identyfikator.

Hierarchia encji bez atrybutów specyficznych - ŁUK Firma wydająca karty kredytowe zakłada konta klientów indywidualnych lub klientów zbiorowych (firmy), które mogą wystawiać karty kredytowe dla swoich pracowników Hierarchia encji ACCOUNT attributes against INDIVIDUAL ACCOUNT INDIVIDUAL against COMPANY ACCOUNT COMPANY Encje specjalizacji INDIVIDUAL ACCOUNT i COMPANY ACCOUNT nie posiadają specyficznych atrybutów. Encje specjalizacji mogą posiadać tylko specyficzne związki. Łuk against ACCOUNT INDIVIDUAL COMPANY against