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



Podobne dokumenty
Projektowanie bazy danych

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

TRANSFORMACJA MODELU ER DO MODELU RELACYJNEGO

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

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

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

Modelowanie danych, projektowanie systemu informatycznego

Systemy informatyczne. Modelowanie danych systemów informatycznych

Transformacja modelu ER do modelu relacyjnego

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

1 Projektowanie systemu informatycznego

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

Modelowanie danych Model związków-encji

KSS: Modelowanie konceptualne przykład

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

Bazy danych i usługi sieciowe

Transformacja modelu ER do modelu relacyjnego

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

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

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

Modelowanie danych Model związków-encji

Autor: Joanna Karwowska

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

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

Projektowanie Systemów Informacyjnych

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

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

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

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

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

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

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

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

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

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

Baza danych. Modele danych

Technologie baz danych

Zaawansowane Modelowanie I Analiza Systemów Informatycznych

Modelowanie danych. Biologiczne Aplikacje Baz Danych

Podstawowe pakiety komputerowe wykorzystywane w zarządzaniu przedsiębiorstwem. dr Jakub Boratyński. pok. A38

Posługiwanie się tabelami

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

Przykłady normalizacji

Przykładowa baza danych BIBLIOTEKA

WYKŁAD 1. Wprowadzenie do problematyki baz danych

Modelowanie konceptualne model EER

Projektowanie BAZY DANYCH

Informatyka Ćwiczenie 10. Bazy danych. Strukturę bazy danych można określić w formie jak na rysunku 1. atrybuty

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

Bazy danych 1. Wykład 5 Metodologia projektowania baz danych. (projektowanie logiczne)

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

Projektowanie baz danych

PODSTAWOWE POJĘCIA BAZ DANYCH

Projektowanie baz danych

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

Wykład 2. Relacyjny model danych

Wprowadzenie do baz danych

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

Modelowanie związków encji

Technologia informacyjna

WPROWADZENIE DO BAZ DANYCH

Zajęcia 1. W następnej tabeli zebrane są dane używane w bibliotece, które są przetwarzane przez bibliotekarza w różnych fazach obsługi czytelnika.


Projektowanie logiki aplikacji

Spis treści. 1 Modelowanie logiczne. Plan wykładu. 1 Modelowanie logiczne 1

Projektowanie BD Diagramy związków encji

Projektowanie bazy danych przykład

Bazy danych. Andrzej Łachwa, UJ, /15

Projekt aplikacji prywatnej przychodni weterynaryjnej

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

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

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

Związki pomiędzy tabelami

Język UML w modelowaniu systemów informatycznych

Zaawansowane Modelowanie I Analiza Systemów Informatycznych

Laboratorium nr 5. Bazy danych OpenOffice Base.

Przykład 1 Iteracja 1 tworzenia oprogramowania

Uniwersytet im. Adama Mickiewicza w Poznaniu Wydział Matematyki i Informatyki. Projekt bazy danych <Moja baza>

Bazy Danych egzamin poprawkowy, 2012 rozwiazania

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

Świat rzeczywisty i jego model

Diagram wdrożenia. Rys. 5.1 Diagram wdrożenia.

Zaawansowane Modelowanie I Analiza Systemów Informatycznych

P o d s t a w y j ę z y k a S Q L

Program wykładu. zastosowanie w aplikacjach i PL/SQL;

Bazy danych TERMINOLOGIA

Zasady transformacji modelu DOZ do projektu tabel bazy danych

Numer zadania. Treść zadania

Cel normalizacji. Tadeusz Pankowski

Definicja bazy danych TECHNOLOGIE BAZ DANYCH. System zarządzania bazą danych (SZBD) Oczekiwania wobec SZBD. Oczekiwania wobec SZBD c.d.

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

Model relacyjny. Wykład II

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

Baza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego

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

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ą

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

Agnieszka Ptaszek Michał Chojecki

Transkrypt:

W y k ł a d II Temat: Modelowanie schematu bazy danych za pomocą diagramów związków encji (Entity Relationship Diagrams ERD) Plan wykładu: Cel modelowania konceptualnego i modelu ER Etapy modelowania konceptualnego Model ER Jednostki i typy jednostek Związki i typy związków Związki binarne: 1:1, 1:, : Związki wieloczłonowe i ich właściwości Związki rekurencyjne Związki z uczestnictwem jednostek zależnych od czasu (zdarzeń) Sposób transformacji diagramów ER do modelu relacyjnego A. Pankowska 1

Architektura trójwarstwowa użytkownicy końcowi POZIOM ZEWĘTRZY perspektywa zewnętrzna... perspektywa zewnętrzna POZIOM KOCEPCYJY schemat koncepcyjny schemat wewnętrzny POZIOM WEWĘTRZY SKŁADOWAA BAZA DAYCH A. Pankowska 2

Model ER Model zaproponowany w: P.P. Chen, The Entity-Relationship Data Model: toward a unified view of data, ACM Transactions on Database Systems, Vol. 1, 1976. Opisuje dziedzinę przedmiotową za pomocą pojęć: encja (ang. entities) (po polsku także: jednostka, obiekt), atrybut (ang. attributes), związek (ang. relationships). A. Pankowska 3

Cel modelu ER Model ER służy do nieformalnego przedstawienia projektu bazy danych. Projekt ma postać graficzną zwaną diagramem ER (entity-relationship diagram) diagramem jednostkazwiązek lub diagramem związków encji. Istnieje procedura (pół)automatycznej transformacji diagramu ER do konkretnej implementacji, na przykład do relacyjnej bazy danych. A. Pankowska 4

Diagramy ER notacja Chen a encja reprezentuje byt ze świata rzeczywistego (obiekty materialne i niematerialne, zdarzenia i fakty) atrybut Cena opisuje szczegółowe właściwości encji; każda encja musi mieć artybut kluczowy związek reprezentuje powiązania między encjami (klienci kupują towary) azwa Towary Zakup Klienci Kategoria azwisko A. Pankowska 5

Diagramy ER notacja uproszczona graficznie TOWARY nazwa cena kategoria KLIECI adres A. Pankowska 6

Rodzaje związków związek binarny 1:1 PRACOWICY Id_prac 1 1 POKOJE numer pietro związek binarny 1: PRACOWICY Id_prac 1 POKOJE numer pietro związki opcjonalne PRACOWICY Id_prac 0.. 0..1 POKOJE numer pietro A. Pankowska 7

Rodzaje związków PRACOWICY PROJEKTY związek binarny : Id_prac numer nazwa data Problem 1: gdzie umieścić informację, ile godzin dany pracownik przepracował nad danym projektem? Odpowiedź: jest to atrybut związku PRACOWICY Id_prac liczba godzin PROJEKTY numer nazwa data A. Pankowska 8

Rodzaje związków Inne przykłady: PRACOWICY Id_prac stopien znajomosci JEZYKI OBCE nazwa KSIAZKI CZYTELICY Id_ksiazki tytul autor wydawnictwo wypozyczenia data pesel Atrybut powinien opisywać encję, przy której się go umieszcza! A. Pankowska 9

Rodzaje związków Problem 2 numery telefonów pracownika - atrybut encji czy nowa encja? Odpowiedź 1: zakładamy, że każdy pracownik może mieć maksymalnie trzy numery telefonów - atrybuty PRACOWICY Id_prac telefon_dom telefon_kom telefon_praca Odpowiedź 2: zakładamy, że każdy pracownik może mieć dowolną liczbę numerów telefonów nowa encja PRACOWICY Id_prac 1 TELEFOY numer Atrybut musi przyjmować pojedynczą wartość! A. Pankowska 10

Rodzaje związków związek cykliczny OSOBY r Pesel 1 jest współmałżonkiem A. Pankowska 11

związek ternarny (n-arny) Rodzaje związków Przykłady: pracownik pracuje w projekcie w określonej roli student chodzi na ćwiczenia prowadzone przez asystenta towar jest sprowadzany od dostawcy do użycia w przedsięwzięciu PRACOWICY PROJEKTY 1 ROLE A. Pankowska 12

Specjalizacja - generalizacja SAMOCHODY nr_rejestracyjny marka model OSOBOWE liczba miejsc CIEZAROWE ladownosc A. Pankowska 13

Encje słabe TOWARY Id_tow nazwa grupa cena 1 SZCZEGOLY numer sztuk VAT 1 FAKTURY numer data A. Pankowska 14

Przykład 1 PRZEDMIOT idprz Data EGZAMI Ocena UCZEŃ IdUcz 1 AUCZYCIEL Idau 1. PRZEDMIOT, AUCZYCIEL UCZEŃ Z iloma różnymi uczniami związana jest para (przedmiot, nauczyciel) w typie EGZAMI? Inaczej, Czy nauczyciel z danego przedmiotu może egzaminować więcej uczniów niż jednego? (TAK, może wielu etykieta " przy typie UCZEŃ) 2. PRZEDMIOT, UCZEŃ AUCZYCIEL Z iloma różnymi nauczycielami związana jest para (przedmiot, uczeń) w typie EGZAMI? Inaczej, czy uczeń z danego przedmiotu może zdawać egzamin u więcej niż u jednego nauczyciela? (IE, co najwyżej u jednego etykieta 1" przy klasie jednostek AUCZYCIEL) 3. AUCZYCIEL, UCZEŃ PRZEDMIOT Z iloma różnymi przedmiotami związana jest para (nauczyciel, uczeń) w typie EGZAMI? Inaczej, czy uczeń u danego nauczyciela może zdawać egzamin z więcej niż z jednego przedmiotu? (TAK etykieta " przy klasie jednostek PRZEDMIOT) A. Pankowska 15

Przykład 1 atrybut czasowy EGZAMI IdEgza Data Ocena PRZEDMIOT UCZEŃ idprz IdUcz 1 AUCZYCIEL Idau W poprzednim przykładzie egzamin identyfikowany jest przez trójkę IdPrz, IdUcz, Idau nie można więc pamiętać informacji o kilkakrotnym zdawaniu tego samego egzaminu (wartość klucza musiałaby się powtarzać, co jest niedopuszczalne). Aby modelować taką sytuację tworzymy jednostkę (encję) EGAZMI posiadającą własny atrybut kluczowy (identyfikator). Jednostka ta staje się uczestnikiem związku czteroczłonowego (jak na rysunku). A. Pankowska 16

Przykład 2 Baza danych FIRMA ma umożliwiać zarządzanie danymi pracowników, działów oraz realizowanych projektów. 1) Firma jest podzielona na działy. Każdy z tych działów ma nazwę, unikatowy numer oraz przydzielonego konkretnego pracownika, który tym działem kieruje. W bazie należy utrzymywać datę początkową, od której dany pracownik kieruje wskazanym działem. Każdy dział może być rozproszony i znajdować się w wielu miejscach. 2) Dział kontroluje wiele projektów, z których każdy ma unikatową nazwę, unikatowy numer oraz jedno miejsce realizacji. 3) Dla każdego pracownika przechowywany jest i nr PESEL, adres, wysokość pensji, płeć i data urodzenia. Pracownik musi być przypisany do jednego działu, ale może pracować nad wieloma projektami, które niekoniecznie muszą być kontrolowane przez ten sam dział. W bazie będziemy śledzić liczbę godzin, które pracownicy poświęcają poszczególnym projektom w ciągu tygodnia. Dla każdego pracownika przechowywana jest informacja o bezpośrednim zwierzchniku. 4) Chcemy przechowywać informacje o członkach rodziny pracownika. A. Pankowska 17

Przykład 2 0.. kieruje PRACOWICY r_pesel... 0..1 1 1 pracuje zarządza data_od 1 0..1 DZIALY nr_dzialu nazwa lokalizacja1 lokalizacja2 lokalizacja3 1 CZLOEK_RODZIY plec data_ur stopien_pokrewienstwa pracuje_nad godziny kontroluje PROJEKTY nr_proj nazwa lokalizacja A. Pankowska 18

Transformacja modelu ER w schemat relacyjny Transformacja encji azwę encji wyrażoną w liczbie mnogiej przenosimy jako nazwę relacji. Atrybuty encji przenosimy jako nazwy kolumn (atrybuty) relacji. Unikalny identyfikator encji przenosimy jako klucz podstawowy relacji. Obligatoryjność atrybutu encji przenosimy jako ograniczenie OT ULL atrybutu relacji. Opcjonalność atrybutu encji przenosimy jako własność ULL atrybutu relacji. Inne ograniczenia integralnościowe nałożone na atrybuty encji przenosimy w niezmienionej formie na atrybuty relacji. PRACOWICY Id_prac Pracownicy(Id_prac,, ) A. Pankowska 19

Transformacja modelu ER w schemat relacyjny Transformacja hierarchii encji - do trzech relacji Tworzymy jedną relację zawierającą atrybuty wspólne i atrybut określający typ specjalizacji. Dla każdej specjalizacji tworzymy relację zawierającą jej atrybuty specyficzne i klucz podstawowy dziedziczony z generalizacji. Transformacja hierarchii encji - do dwóch relacji Dla każdej specjalizacji tworzymy relację zawierającą atrybuty wspólne, atrybuty specyficzne danej specjalizacji i klucz podstawowy dziedziczony z generalizacji. Transformacja hierarchii encji - do jednej relacji Tworzymy relację zawierającą atrybuty wspólne, atrybuty specyficzne wszystkich specjalizacji i atrybut określający typ specjalizacji. Wszystkim atrybutom specyficznym poszczególnych specjalizacji nadajemy własność ULL. A. Pankowska 20

Transformacja modelu ER w schemat relacyjny Transformacja hierarchii encji - przykład do trzech relacji: SAMOCHODY nr_rej marka model Samochody (nr_rej, marka, model, typ) Osobowe (nr_rej, liczba_miejsc) Ciezarowe (nr_rej, ladownosc) do dwóch relacji: Osobowe (nr_rej, marka, model, liczba_miejsc) Ciezarowe (nr_rej, marka, model, ladownosc) OSOBOWE liczba miejsc CIEZAROWE ladownosc do jednej relacji: Samochody (nr_rej, marka, model, typ, liczba_miejsc, ladownosc) A. Pankowska 21

Transformacja modelu ER w schemat relacyjny Transformacja związków 1:1 Tworzymy klucz obcy w relacji wiązanej obligatoryjnie na podstawie klucza podstawowego drugiej relacji. a atrybuty klucza obcego nakładamy ograniczenie referencyjne. PRACOWICY Id_prac 1 1 POKOJE numer pietro PRACOWICY (Id_prac,, ) POKOJE (numer, pietro, id_prac) A. Pankowska 22

Transformacja modelu ER w schemat relacyjny Transformacja związków 1: Tworzymy klucz obcy w relacji po stronie "wiele" na podstawie klucza podstawowego relacji po stronie "jeden". a atrybuty klucza obcego nakładamy ograniczenie referencyjne. PRACOWICY Id_prac 1 POKOJE numer pietro PRACOWICY (Id_prac,,, numer) POKOJE (numer, pietro) A. Pankowska 23

Transformacja modelu ER w schemat relacyjny Transformacja związków : Związek : przenosimy jako nową relację. Tworzymy klucze obce na podstawie kluczy podstawowych dwóch pozostałych relacji. a atrybuty jednego i drugiego klucza obcego nakładamy dwa ograniczenia referencyjne. Wszystkie atrybuty relacji tworzą klucz podstawowy PRACOWICY PROJEKTY Id_prac numer nazwa data PRACOWICY (Id_prac,, ) PROJEKTY (numer, nazwa, data) PRACUJE (id_prac, numer) A. Pankowska 24

Transformacja modelu ER w schemat relacyjny Inne przykłady: PRACOWICY Id_prac liczba godz PROJEKTY numer nazwa data PRACOWICY (Id_prac,, ) PROJEKTY (numer, nazwa, data) PRACUJE (id_prac, numer, liczba_godz) PRACOWICY Id_prac stopien znajomosci JEZYKI nazwa PRACOWICY (id_prac,, ) JEZYKI (nazwa) ZAJOMOSC (id_prac, nazwa, stopien_znajom) A. Pankowska 25

Transformacja modelu ER w schemat relacyjny Przykład z encją słabą: TOWARY Id_tow nazwa grupa cena 1 SZCZEGOLY numer sztuk VAT TOWARY (id_tow, nazwa, grupa, cena) KLIECI (id_klienta,, adres) FAKTURY (numer, data, id_klienta) 1 SZCZEGOLY (numer_fakt, numer_pozycji, id_towaru, sztuk, VAT) FAKTURY numer data 1 KLIECI Id_klienta adres A. Pankowska 26

Transformacja modelu ER w schemat relacyjny Transformacja związków ternarnych - "wiele" przy wszystkich encjach Związek ternarny przenosimy jako nową relację. Tworzymy klucze obce na podstawie kluczy podstawowych trzech pozostałych relacji, nakładając ogr. referencyjne Tworzymy klucz podstawowy ze wszystkich atrybutów relacji Transformacja związków ternarnych - "jeden" przy jednej encji Związek ternarny przenosimy jako nową relację. Tworzymy klucze obce na podstawie kluczy podstawowych trzech pozostałych relacji, nakładając ogr. referencyjne Tworzymy klucz podstawowy w oparciu o klucze obce o stopniu asocjacji "wiele" A. Pankowska 27

Transformacja modelu ER w schemat relacyjny Przykład: PRZEDMIOT idprz nazwa Data EGZAMI 1 Ocena UCZEŃ IdUcz PRZEDMIOT (IdPrz, nazwa) UCZE (IdUcz, ) AUCZYCIEL Idau AUCZYCIEL (Idau, ) EGZAMI (IdPrz, IdUcz, Idau, data, ocena) A. Pankowska 28

Przykład FIRMA (slajd 18) PRACOWICY (r_pesel,,, kierownik, nr_dzialu) CZLOEK_RODZIY (r_pesel, Imie, plec, data_ur, stopien_pokrewienstwa) DZIALY (nr_dzialu, nazwa, lokalizacja1, lokalizacja2, lokalizacja3) PROJEKTY (nr_proj, nazwa, lokalizacja, nr_dzialu) PRACUJE_AD (r_pesel, r_proj, godziny) ZARZADZA (r_pesel, r_dzialu, data_od) A. Pankowska 29

Przykład A Zadaniem tego systemu jest zarządzanie fakturami wystawianymi dla klientów firmy. Klientami firmy są osoby fizyczne i prawne. Klient osoba prawna jest opisany przez: nazwę, IP, adres, i kontakt do osoby reprezentującej klienta. Klient osoba fizyczna jest opisany przez: imię,, adres, telefon. Klienci dokonują w firmie zakupów kosmetyków, z dwóch grup: popularnych i luksusowych. W każdej z tych grup sprzedaje się perfumy, wody toaletowe, mydła, szampony i kremy. Każdy kosmetyk jest dostarczany przez jednego producenta Klient zakupując kosmetyk otrzymuje fakturę. Każda faktura składa się z pozycji określających kosmetyk, jego cenę i liczbę sztuk. A. Pankowska 30

Przykład B Wypożyczalnia posiada w swojej ofercie książki, czasopisma i albumy. Wypożyczać mogą tylko te osoby, które zapisały się do wypożyczalni. Każdy czytelnik posiada unikalny numer karty. Dodatkowo, każdy czytelnik jest opisany niem, nazwiskiem, adresem i numerem telefonu. Jednorazowo czytelnik może wypożyczyć wiele pozycji. Każda pozycja, tj. książka, czasopismo i album posiada swój tytuł, autora (autorów) i wydawnictwo. Fakt wypożyczenia jest odnotowywany w bazie danych. Wypożyczając daną pozycję literaturową, pracownik wypożyczalni odnotowuje datę wypożyczenia i okres wypożyczenia. Po oddaniu pozycji przez czytelnika, pracownik odnotowuje datę jej oddania. A. Pankowska 31

Przykład C Zbuduj model potrzeb informatycznych w postaci diagramów związków encji dla systemu medycznego opisanego następująco: -dla każdego pacjenta chcemy pamiętać następujące informacje: nr. ubezpieczenia,, adres, wiek. r. ubezpieczenia jednoznacznie identyfikuje pacjenta -dla każdego lekarza pamiętamy: nr. ubezpieczenia,, specjalność, wysługa lat. r. ubezpieczenia jednoznacznie identyfikuje lekarza -każda firma farmaceutyczna jest opisana przez nazwę i telefon -dla każdego leku chcemy pamiętać jego nazwę handlową oraz podstawową substancję aktywną. Każdy lek jest sprzedawany przez firmę farmaceutyczną. azwa handlowa leku jednoznacznie identyfikuje ten lek spośród innych produktów tej firmy. Może być lek o tej samej nazwie z innej firmy -każdy pacjent jest prowadzony przez jednego lekarza. Każdy lekarz ma co najmniej jednego pacjenta. -dla każdej apteki chcemy pamiętać jej nazwę, adres, numer telefonu -każda apteka sprzedaje wiele leków. Każdy lek ma swoją cenę. Lek może być sprzedawany przez wiele aptek po różnych cenach - lekarze przepisują leki pacjentom w postaci recept. Lekarz może przepisać pacjentowi (wielu pacjentom) jeden lub więcej leków. Pacjent może przyjmować leki przepisane przez wielu lekarzy. Każda recepta ma datę i ilość specyfiku (leku) - firmy farmaceutyczne podpisują długoterminowe kontrakty z aptekami na sprzedaż leków. Jedna firma może mieć kontrakty z wieloma aptekami, podobnie apteki mogą mieć kontrakty z wieloma firmami. Dla każdego kontraktu chcemy pamiętać datę rozpoczęcia i datę zakończenia, oraz tekst kontraktu. A. Pankowska 32