Modelowanie danych Model związków-encji

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

Modelowanie danych Model związków-encji

Modelowanie danych. Biologiczne Aplikacje Baz Danych

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. dr inż. Anna Leśniewska

1 Projektowanie systemu informatycznego

Transformacja modelu ER do modelu relacyjnego

Transformacja modelu ER do modelu relacyjnego

Projektowanie bazy danych

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

Systemy informatyczne. Modelowanie danych systemów informatycznych

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

Bazy danych i usługi sieciowe

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

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

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

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

TRANSFORMACJA MODELU ER DO MODELU RELACYJNEGO

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

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

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

Autor: Joanna Karwowska

Paweł Kurzawa, Delfina Kongo

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

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

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

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

Świat rzeczywisty i jego model

Technologie baz danych

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

WYKŁAD 1. Wprowadzenie do problematyki baz danych

Zaawansowane Modelowanie I Analiza Systemów Informatycznych

Projektowanie logiki aplikacji

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

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

Rysunek 1: Przykłady graficznej prezentacji klas.

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

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

TECHNIKI MODELOWANIA STRUKTURY INFORMACYJNEJ

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

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

Język UML w modelowaniu systemów informatycznych

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

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

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

Projektowanie baz danych

Wykład I. Wprowadzenie do baz danych

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

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

Podstawy modelowania w języku UML

Projektowanie Systemów Informacyjnych

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

Modelowanie obiektowe - Ćw. 3.

MAS dr. Inż. Mariusz Trzaska

Technologie obiektowe

Baza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego

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

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

Zaawansowane Modelowanie I Analiza Systemów Informatycznych

UML w Visual Studio. Michał Ciećwierz

TECHNOLOGIE OBIEKTOWE. Wykład 3

Zaawansowane Modelowanie I Analiza Systemów Informatycznych

Modelowanie związków encji

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

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

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

Projektowanie BD Diagramy związków encji

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

Tworzenie warstwy zasobów projektowanie metodą strukturalną

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

MODELOWANIE OBIEKTOWE

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

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

KSS: Modelowanie konceptualne przykład

Modelowanie i Programowanie Obiektowe

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

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

Podejście obiektowe - podstawowe pojęcia

Drużyny piłkarskie. Rozwiązanie

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

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

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

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

Baza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego

Mariusz Trzaska Modelowanie i implementacja systemów informatycznych

Przykłady normalizacji

Bazy danych. Andrzej Łachwa, UJ, /15

Podstawy programowania III WYKŁAD 4

Projektowanie Zorientowane na Dziedzinę. ang. Domain Driven Design

Język UML w modelowaniu systemów informatycznych

Modelowanie konceptualne model EER

TEORIA GRAFÓW I SIECI

Podstawy Programowania Obiektowego

Diagramy klas. WYKŁAD Piotr Ciskowski

Diagramy klas. dr Jarosław Skaruz

Wykład 2. Relacyjny model danych

Projektowanie systemów informatycznych. Diagramy przypadków użycia

Zad. 1. Systemy Baz Danych przykładowe zadania egzaminacyjne

Transkrypt:

Modelowanie danych Model związków-encji Wykład przygotował: Robert Wrembel BD wykład 3 (1)

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

Modelowanie - modele Modelowanie - odwzorowanie rzeczywistych obiektów świata rzeczywistego w systemie informatycznym (bazie danych) Modele konceptualne reprezentacja obiektów w uniwersalnym modelu niezależnym od modelu implementacyjnego model związków-encji model UML implementacyjne modele wykorzystywane do implementacji modeli konceptualnych modele danych (relacyjne, obiektowe, itp.) BD wykład 3 (3)

Obiekty świata rzeczywistego Obiekty materialne samochody, budynki, sprzęt komputerowy zasoby ludzkie (grupa pracowników) Obiekty niematerialne wiedza (znajomość technologii) zdarzenia (otrzymanie nagrody, urlopu) stany rzeczywistości (stan rachunku bankowego, polisa ubezpieczeniowa) BD wykład 3 (4)

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 Notacje modelu ER Chen Barker (Oracle) - stosowana na wykładzie BD wykład 3 (5)

Encja Jest szablonem dla zbioru obiektów, opisanych 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) BD wykład 3 (6)

Modelowanie encji (1) Obiekty świata rzeczywistego Firma zatrudnia pracowników. Chcemy przechowywać informacje nt. danych personalnych pracowników (imię, nazwisko, adres i numer telefonu). wspólne cechy pracowników Zenon Sikora ul. Polska 3 333333 Herman Klos ul. Rycerska 45 444444 Zdzisław Pirat ul. Helska 44 555555 Encja Pracownik imię nazwisko adres nr_telefonu Wystąpienia encji Pracownik imię = Zenon nazwisko = Sikora adres = ul. Polska 3 nr_telefonu = 333333 BD wykład 3 (7)

Modelowanie encji (2) Obiekty świata rzeczywistego Parking firmy jest przeznaczony do parkowania wielu różnych samochodów. Chcemy przechowywać informacje o samochodach (marka, model, numer rejestracyjny), które mogą parkować na parkingu firmy. wspólne cechy samochodów Subaru Forester PO0233A Peugeot 206 PO1236U Opel Astra PZI932Y Encja Samochód marka model nr_rejestracyjny Wystąpienia encji Samochód marka = Subaru model = Forester nr_rejestracyjny = PO0233A BD wykład 3 (8)

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 BD wykład 3 (9)

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 pracownika BD wykład 3 (10)

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 BD wykład 3 (11)

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 ograniczenia integralnościowe BD wykład 3 (12)

Atrybuty encji - przykład Pracownicy firmy są opisani numerem PESEL, adresem zamieszkania, pensją i opcjonalnie numerem telefonu identyfikator encji atrybuty z wartościami obowiązkowymi atrybut z wartością opcjonalną Pracownik # PESEL * adres * pensja o telefon BD wykład 3 (13)

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 BD wykład 3 (14)

Modelowanie związków (1) Związki Pracownicy firmy posiadają różne samochody. Chcemy przechować informację na temat faktu posiadania samochodu przez pracownika. Identyfikacja związków posiadających wspólne własności Zenon Sikora Herman Klos posiada jest własnością Subaru Forester Peugeot 206 Zdzisław Pirat Opel Astra Związki pomiędzy encjami posiada Pracownik jest własnością związek Samochód opis związku BD wykład 3 (15)

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? BD wykład 3 (16)

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

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 związek Pracownik-Samochód stopień związku: binarny typ asocjacji Pracownik (1) : Samochód (1) Zarejestrowany w rejestrze parkingowym samochód na pewno jest własnością jednego pracownika typ asocjacji Pracownik (1) : Samochód (1) istnienie Samochód musi być własnością istnienie Pracownik może posiadać BD wykład 3 (18)

Cechy związku - przykład (2) Związek binarny (łączy dwie encje) Związek opcjonalny od strony pracownika (linia przerywana) Związek obowiązkowy od strony samochodu (linia ciągła) Związek 1:1 (1 pracownik posiada 1 samochód) typ asocjacji Pracownik (1) : Samochód (1) związek Pracownik-Samochód stopień związku: binarny Pracownik posiada jest własnością Samochód związek opcjonalny Pracownik może posiadać związek obowiązkowy Samochód musi być własnością BD wykład 3 (19)

Typ asocjacji 1:1 - przykład (1) Związek binarny jeden-do-jeden (1:1) Każdy dział musi mieć kierownika, natomiast pracownik może być kierownikiem co najwyżej jednego działu. pracownicy Jan Jankielicz Tomasz Kociak kieruje Windykacja działy Hektor Miluś Adam Rysiu kieruje Kredyty Pracownik kieruje jest kierowany przez Dział BD wykład 3 (20)

Typ asocjacji 1:1 - przykład (2) Pracownik kieruje jest kierowany przez Dział związek opcjonalny Pracownik może kierować związek obowiązkowy Dział musi być kierowany Interpretacja 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 BD wykład 3 (21)

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. pracownicy Jan Jankielicz Tomasz Kociak pracuje w Windykacja działy Hektor Miluś Adam Rysiu pracuje w Kredyty Marketing pracuje w Pracownik zatrudnia Dział BD wykład 3 (22)

Typ asocjacji 1:M (2) Pracownik pracuje w zatrudnia Dział typ asocjacji: wiele (M) związek obowiązkowy Pracownik musi pracować w typ asocjacji: jeden (1) związek opcjonalny Dział może zatrudniać 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 BD wykład 3 (23)

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 Piłkarz gra w złożona z Drużyna BD wykład 3 (24)

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 Rachunek posiada historię wykonana na Operacja BD wykład 3 (25)

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. pracownicy Jan Jankielicz Tomasz Kociak realizuje Projekt A projekty Hektor Miluś Adam Rysiu realizuje Projekt B Henryk Kozak Pracownik realizuje realizowany przez Projekt BD wykład 3 (26)

Typ asocjacji M:N (2) Pracownik realizuje realizowany przez Projekt typ asocjacji: wiele (m) typ asocjacji: wiele (N) związek opcjonalny Pracownik może realizować związek obowiązkowy Projekt musi być realizowany Interpretacja 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 BD wykład 3 (27)

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 Student należy do zrzesza Organizacja BD wykład 3 (28)

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. kierownik 4500 programista 01.01.2005-31.12.2005 2500 01.01.2005-31.12.2005 pracownicy Jan Jankielicz Tomasz Kociak Hektor Miluś Adam Rysiu realizuje realizuje analityk 3200 01.01.2005-30.04.2005 Projekt A Projekt B projekty Henryk Kozak BD wykład 3 (29)

Atrybuty związku (2) Pracownik uczestniczy w przez Realizacja funkcja wynagrodzenie od do dotyczy podlega Projekt 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 BD wykład 3 (30)

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 Pracownik uczestniczy w przez Realizacja funkcja wynagrodzenie od do dotyczy podlega Projekt BD wykład 3 (31)

Identyfikator encji słabej Identyfikatorem encji słabej są wszystkie związki, w które wchodzi ta encja Pracownik uczestniczy w przez Realizacja funkcja wynagrodzenie od do dotyczy podlega Projekt oznaczenie związku wchodzącego w skład identyfikatora encji BD wykład 3 (32)

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 Pracownicy posiadają swich kierowników. Istnieją pracownicy, którzy nie są kierownikami. kieruje Pracownik podlega BD wykład 3 (33)

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. składa się z Podzespół jest częścią BD wykład 3 (34)

Związki ternarne (1) Związek ternarny Kierowca może otrzymać mandat za popełnione wykroczenie. Mandat jest wystawiany przez konkretnego policjanta. kierowcy Jan Jankielicz Tomasz Kociak Hektor Miluś otrzymuje policjanci wystawia Egon Miller Zenobia Orka ukarane bez pasów bez świateł wykroczenia BD wykład 3 (35)

Związki ternarne (2) Kierowca wystawiony dla wystawiony przez otrzymuje Mandat wystawia wystawiony za Policjant ukarane Wykroczenie W omawianej notacji Barkera 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 BD wykład 3 (36)

Związki ternarne przykład rozszerzony wystawiony dla wystawiony przez Kierowca Mandat Policjant # IdKierowcy * Imię * Nazwisko * Adres o Nr prawa jazdy * Nr rejestracyjny otrzymuje # Data wystawienia * Kwota wystawiony za wystawia # NrSłużbowy * Stopień ukarane Wykroczenie # NrWykroczenia * Nazwa * Punkty karne * Kwota min * Kwota max BD wykład 3 (37)

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 Rachunek bankowy należy do posiada Osoba fizyczna należy do posiada Osoba prywatna oznaczenie związku wyłącznego BD wykład 3 (38)

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 BD wykład 3 (39)

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. atrybuty wspólne atrybuty specyficzne Pracownik # PESEL * Imię * Nazwisko Kontraktowy * Nr kontraktu podencja encja specjalizacji nadencja encja generalizacji atrybuty specyficzne Godzinowy * liczba godzin * stawka podencja encja specjalizacji BD wykład 3 (40)

Hierarchia encji (2) Interpretacja 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 Pracownik # PESEL * Imię * Nazwisko Kontraktowy * Nr kontraktu Godzinowy * liczba godzin * stawka BD wykład 3 (41)

Hierarchia encji (3) BD wykład 3 (42)

Związki rzadkie Przypadek 1. Encja A Konstrukcja prawie zawsze niepoprawne! Encja B Przypadek 2. Encja A Encja B Konstrukcja o dyskusyjnej praktycznej poprawności. Przypadek 3. Encja A Encja B Konstrukcja prawie zawsze wymaga dalszej wnikliwej analiza. BD wykład 3 (43)

Związki niepoprawne Przypadek 1. Encja A Jednostka Organizacyjna Przypadek 2. Encja A Przypadek 3. Encja A BD wykład 3 (44)