Modele danych Wyrnia si podstawowe i wdroeniowe modele

Modele danych Wyróżnia się podstawowe i wdrożeniowe modele danych. Ø Model podstawowy, zwany też konceptualnym lub logicznym, jest ukierunkowany na potrzeby użytkownika. Ä Model ten opisuje dziedzinę przedmiotową, niezależnie od technicznej strony wdrożenia (modelowanie związków encji). Ø Model wdrożeniowy, dotyczy wdrożenia modelu danych w konkretnej technologii baz danych (np. relacyjne bazy danych). Projektowanie schematów relacyjnych 2

Modele – powody tworzenia Do ważnych powodów różnicowania modeli i tworzenia modeli podstawowych należą: v ograniczenie ryzyka utraty kompletnego opisu funkcjonalnego dziedziny przedmiotowej; v stworzenie możliwości komunikowania się kierownictwa, użytkowników i informatyków, we wspólnym, zrozumiałym dla wszystkich języku, bez uciekania się do technicznej terminologii informatyki. Projektowanie schematów relacyjnych 3

Baza danych – fazy projektowania Modelowany miniświat niezależne od SZBD analiza funkcjonalna zebranie wymagań projekt pojęciowy projekt logiczny projekt aplikacji zależne od SZBD implementacja transakcji Projektowanie schematów relacyjnych projekt fizyczny 4

Encja v Encja – oznacza obiekt, coś co istnieje i jest rozróżnialne od innych obiektów tego samego typu. v v Przyjmuje się, że encja jest dalej nierozbieralna. v Encje mogą istnieć rzeczywiście, bądź są wprowadzane jako obiekty abstrakcyjne. Obiekt w zależności od poziomu abstrakcji traktowany jako encja lub zbiór encji. Przykłady zbiorów encji: § samochody; § osoby; § zamówienia; § uprawnienia. Projektowanie schematów relacyjnych 5

Encja v Cechy encji: każda encja posiada cechy zwane atrybutami; każda encja posiada unikalny identyfikator; obiekt rzeczywisty może być reprezentowany w modelu przez co najwyżej jedną encję; reprezentacje konkretnych obiektów miniświata stanowią instancje (wystąpienia) encji. Projektowanie schematów relacyjnych 6

Encja v Metody definiowania zbiorów encji: ekstencjonalnie - wyliczenie elementów np. : {męski, żeński, nijaki}, {a, b, c, . . . , x, y, z}, {Pn, Wt, Śr, Czw, Pt, So, Ni}, {0, 1, . . . , 9}; intencjonalnie - specyfikacja własności np. : {x N, x jest podzielne przez 2}; operacje algebry zbiorów; operacje logiczne; nie sprecyzowane (np. : nazwisko). Projektowanie schematów relacyjnych 7

Encja v Co może reprezentować encja? obiekt materialny: pracownik, książka, samochód, towar obiekt niematerialny: faktura, projekt, konto, zamówienie, grupa pracowników zdarzenie: choroba pracownika, przyznanie nagrody, kontrola fakt: znajomość języka obcego, stan magazynowy produktu Projektowanie schematów relacyjnych 8

Encja instancje encji encja Pracownik 10345 Id_pracownika Kowalski nazwisko Dyrektor stanowisko data_urodzenia pensja …… 11233 Gilowska 10. 12. 1953 10197 Księgowa 7500 Bielecki 21. 04. 1965 …… Magazynier 6400 31. 07. 1955 …… 4200 …… Projektowanie schematów relacyjnych 9

Atrybuty encji q Informacja o encji jest wyrażana przez zbiór par (atrybut, wartość), np. : kolor=blue waga=45 cena=149 ilość=12 q q Dany zbiór atrybutów może być traktowany jako typ encji. Zwykle w tabelach umieszcza się zbiory encji tego samego typu. Projektowanie schematów relacyjnych 10

Typy atrybutów encji q Proste i złożone: § atrybut prosty/atomowy (sinmple/atomic) to atrybut niepodzielny, np. imię, nazwisko, pensja, etat; § atrybut złożony (composite) może być podzielony na atrybuty proste, np. adres; q Jednowartościowe i wielowartościowe: § atrybut jednowartościowy (single-valued) w dowolnej chwili posiada tylko jedną wartość, np. wiek § atrybut wielowartościowy (multi-valued) może posiadać wiele wartości (możliwe ograniczenia), np. języki obce. Projektowanie schematów relacyjnych 11

Typy atrybutów encji q Oryginalne i wywiedzione: § atrybut oryginalny (stored) to taki atrybut, którego wartość została zapisana w bazie danych; § atrybut wywiedziony (derived) to taki, którego wartość została wyliczona (określona) na podstawie innego atrybutu (innych atrybutów), np. wiek na podstawie daty urodzenia i bieżącej daty. Projektowanie schematów relacyjnych 12

Atrybuty kluczowe encji Ø Każda encja posiada atrybut (zbiór atrybutów) będących unikalnym identyfikatorem encji. Ø Wartości unikalnego identyfikatora są unikalne w ramach wszystkich wystąpień encji. Przykłady unikalnych identyfikatorów encji: § identyfikatory proste naturalne: PESEL, NIP, ISBN; § identyfikatory proste sztuczne: ID_PRACOWNIKA; § identyfikatory złożone: NR_REJESTRACYJNY. Projektowanie schematów relacyjnych 13

Związki Ø Związek R między encjami E 1, E 2, …, En definiuje zbiór asocjacji między instancjami tych encji. Ø Związek R między encjami E 1, E 2, …, En jest podzbiorem iloczynu kartezjańskiego E 1 x. E 2 x…x. En d 1 p 2 p 3 p 4 d 2 d 3 Pracownik Pracuje w r 1 x d 1 p 1 x r 2 p 2 x x p 3 Projektowanie schematów relacyjnych r 3 p 4 Departament d 2 d 3 r 4 14

Stopień związku Ø Stopień związku to liczba encji uczestniczących w związku. Ø Ze względu na stopień, wyróżnia się trzy rodzaje związków: § § § związki unarne; związki binarne; związki ternarne. Projektowanie schematów relacyjnych 15

Stopień związku Ø Związki unarne: to związki które wiążą jedną encję, o najczęściej reprezentują rekurencyjne powiązania hierarchiczne między obiektami określonego typu, o dla związków unarnych konieczne jest określenie roli jaką gra każda instancja encji w związku. Pracownik szef p 1 p 2 p 3 p 4 p 5 Projektowanie schematów relacyjnych Jest przełożonym r 1 podwładny szef podwładny r 2 podwładny 16

Stopień związku Ø Związki binarne to związki wiążące instancje dwu encji, o są to najpopularniejsze i najczęściej spotykane rodzaje związków. Pracownik Posiada r 1 s 1 p 2 p 3 p 4 Projektowanie schematów relacyjnych Samochód s 2 r 3 s 3 17

Stopień związku Ø Związki ternarne – związki wiążące instancje trzech encji, Pracownik Pracuje nad r 1 p 1 r 2 p 2 Projekt p 3 l 1 t 2 r 3 l 2 t 3 l 3 Rola Projektowanie schematów relacyjnych 18

Typ asocjacji v Typ asocjacji określa liczbę instancji związku w którym może brać udział instancja encji. v Wyróżnia się trzy typy powiązań: § powiązania jednoznaczne typu 1 do 1 ("1 - 1") § powiązania jednoznaczne 1 do n ("1 - n" ): § powiązania wieloznaczne n do m ("n - m") Projektowanie schematów relacyjnych 19

Typ asocjacji Ø Związki typ 1: 1 - każda instancja encji może brać udział w co najwyżej jednej instancji związku. Pracownik Jest kierownikiem Departament r 1 d 1 p 2 p 3 p 4 • • d 2 r 3 d 3 Pracownik może być kierownikiem co najwyżej jednego departamentu. Departament ma co najwyżej jednego kierownika. Projektowanie schematów relacyjnych 20

Typ asocjacji Ø Związki typ 1: n - instancje jednej encji mogą brać udział w co najwyżej jednej instancji związku, instancje drugiej encji mogą brać udział w dowolnej liczbie instancji związku. Producent p 1 Produkuje Część r 1 d 2 r 2 p 2 • • r 3 d 3 Producent może produkować wiele części. Każda część jest produkowana co najwyżej przez jednego producenta. Projektowanie schematów relacyjnych 21

Typ asocjacji Ø Związki typ n: m - instancje każdej encji mogą brać udział w dowolnej liczbie instancji związku. Dostawca d 1 d 2 Dostarcza Towar r 1 t 1 r 2 r 3 r 4 • • t 2 t 4 t 3 Każdy dostawca może dostarczać wiele towarów. Każda towar może mieć wielu dostawców. Projektowanie schematów relacyjnych 22

Przynależność do związku v Istnieją dwa rodzaje ograniczeń na przynależność: ü totalna przynależność (total participation) encji w związku oznacza, że każda instancja encji musi brać udział w jakiejś instancji związku (związek jest obligatoryjny). Projektowanie schematów relacyjnych 23

Przynależność do związku v Istnieją dwa rodzaje ograniczeń na przynależność: ü częściowa przynależność (partial participation) encji w związku oznacza, że mogą istnieć instancje encji nie biorące udziału w żadnej instancji związku (związek jest opcjonalny). Wykładowca w 1 w 2 w 3 Wykłada Przedmiot r 1 p 1 r 2 p 3 r 3 w 4 Projektowanie schematów relacyjnych 24

Encje słabe v Encje słabe (weak entities) nie posiadają własnego unikalnego identyfikatora, lecz są identyfikowane przez związek z encją nadrzędną (encją identyfikującą). Pracownik p 1 Posiada dziecko r 1 r 2 p 3 Projektowanie schematów relacyjnych r 3 Dziecko Anna d 1 Adam d 2 Anna d 3 25

Notacja (podstawowa) Pracownik encja Dziecko encja słaba Pracuje Prac nad związek Należy Prac do nazwisko kod ulica dom adres atrybut złożony wiek atrybut wywiedziony związek identyfikujący atrybut PESEL atrybut identyfikujący języki atrybut wielowartościowy Projektowanie schematów relacyjnych E 1 R R 1 R N (min, max) E 2 totalne uczestnictwo E 2 liczność związku E 2 ograniczenie liczności 26

Notacja (Chen) Pracownik encja Dziecko encja słaba Pracuje Prac nad związek Należy Prac do nazwisko kod ulica dom adres atrybut złożony wiek atrybut wywiedziony związek identyfikujący atrybut PESEL atrybut identyfikujący języki atrybut wielowartościowy Projektowanie schematów relacyjnych E 1 R R 1 N (min, max) E 2 totalne uczestnictwo E 2 liczność związku E 2 ograniczenie liczności 27

Notacja (Oracle) encja Pracownik # PESEL unikalny identyfikator * Nazwisko atrybut wymagany O Data_ur atrybut opcjonalny E 1 E 1 Projektowanie schematów relacyjnych R R E 2 związek 1 : 1 E 2 związek wymagany (opcjonalny) E 2 związek 1 : N E 2 związek identyfikujący 28

Hierarchia encji Ø Nadklasy i podklasy: § podobne encje o wspólnym zbiorze atrybutów można generalizować za pomocą encji nadklasy (superclass), zwanej też encją generalizacji; § każda instancja encji podklasy jest jednocześnie wystąpieniem encji nadklasy; § encje podklas mogą być rozłączne, lub nakładające się; § encja podklasy dziedziczy wszystkie atrybuty oraz związki encji nadklasy. Projektowanie schematów relacyjnych 29

Hierarchia encji 1001 Encji generalizacji Niebieski Pracownik Dyrektor nr_dow: DD 12345 Id_pracownika . . . 1004 nazwisko Brown stanowisko CFO pass: AB 001122. . . Encje podklasy Pracownik krajowy nr_dowodu_osobistego Pracownik zagraniczny nr_paszportu Projektowanie schematów relacyjnych 30

Hierarchia encji Ø Związki w hierarchii encji: § związki dotyczące encji nadklasy; § związki dotyczące encji podklasy; § związki wykluczające się. Departament Jednostka organizacyjna Pracownik Stanowisko Pracownik kontraktowy Projekt Pracownik tymczasowy Projektowanie schematów relacyjnych 31

Hierarchia encji PESEL Czy każda instancja encji nadklasy musi być instancją którejś z encji podklasy? Pr. techniczny kategoria Projektowanie schematów relacyjnych Nazwisko Data_ur Pracownik D encji podklasy są rozłączne (D) lub nakładające się (O) Pr. administracyjny Pr. inżynieryjny uprawnienia 32

Specjalizacja i generalizacja Ø Specjalizacja: § definiowanie zbioru encji podklas na podstawie encji nadklasy. Ø Generalizacja: § definiowanie ogólnej encji nadklasy na podstawie istniejącego zbioru encji, które automatycznie stają się encjami podklas. Ø Cechy specjalizacji/generalizacji: § definiowanie przez predykat, atrybut lub użytkownika; § specjalizacja może być rozłączna lub nakładająca się; § specjalizacja może być pełna lub częściowa. Projektowanie schematów relacyjnych 33

Kategorie Ø Kategoria: § kolekcja obiektów wystąpień różnych encji powiązanych w jeden typ nadklasy – typ połączeniowy (union type); § kategoria może mieć charakter pełny lub częściowy; § w przypadku kategorii następuje selektywne dziedziczenie atrybutów. Nazwisko Nazwa Osoba Firma Bank U Samochód Projektowanie schematów relacyjnych Właściciel 34

Ograniczenia integralnościowe Ø Dziedzina wartości: o Ø Obligatoryjność: o Ø unikalna wartość dla każdego wystąpienia encji: #PESEL Zawężenie dziedziny wartości: o Ø wartość dla każdego wystąpienia encji: *NAZWISKO IMIE Unikalność: o Ø typ i przedział wartości dla atrybutu: NAZWA VARCHAR 2(100) złożone reguły poprawności atrybutu: CHECK(PLEC IN (‘K’ ‘M’)) Dynamika wartości: o kolejność poprawnych wartości: kawaler żonaty wdowiec Projektowanie schematów relacyjnych 35

PODSUMOWANIE • • • Encje reprezentują obiekty modelowanego miniświata. Atrybuty encji dzielimy na: § proste (atomowe); § złożone; § wielowartościowe. Związki między encjami charakteryzują się: § stopniem: związki unarne, binarne, ternarne; § typem asocjacji: 1: 1 , 1: N , N: M; § przynależnością: opcjonalna i obowiązkowa. Projektowanie schematów relacyjnych 36

PODSUMOWANIE • Istnieje wiele notacji dla diagramów ER: § notacja podstawowa; § notacja Chena; § notacja Oracle. • Hierarchia encji: § encje nadklasy i podklasy; § związki wykluczające się, związki nadklas i podklas. Projektowanie schematów relacyjnych 37

Projekt logiczny bazy danych – przykład Wybór fragmentu świata Ø Baza danych jest modelem pewnego fragmentu otaczającego nas świata rzeczywistego. Ø Fragment ten nazywany jest obszarem analizy. PRZYKŁAD: Jeżeli np. interesuje nas uproszczony model sprzedaży artykułów spożywczych to można ów model przekształcić na diagram związków encji i na jego podstawie przeanalizować, czy baza danych będzie poprawnie odzwierciedlać zdarzenia zachodzące w świecie rzeczywistym (i to zanim baza zostanie wykonana, co zmniejsza koszty produkcji oprogramowania). Projektowanie schematów relacyjnych 38

Projekt logiczny bazy danych – przykład Poznanie obszaru analizy Zanim powstanie diagram, należy poznać obszar analizy. Ä W tym celu przeprowadza się wywiady z odbiorcami bazy danych, z ekspertami, analizuje się przepisy prawne itp. Założenia: Klient może kupić wiele towarów. Może też zamówić sobie dostawę do domu, ale wtedy musi podać swój dokładny adres oraz imię i nazwisko i najlepiej numer telefonu. W takim wypadku płaci przy odbiorze towaru, a gdy kupuje w sklepie - płaci przy wyjściu. Każdy klient jest obsłużony przez jakiegoś pracownika, kasjera lub dostawcę. Projektowanie schematów relacyjnych 39

Projekt logiczny bazy danych – przykład Wyodrębnienie istotnych obiektów Spróbujmy wyodrębnić z tego krótkiego opisu istotne obiekty funkcjonujące w świecie rzeczywistym. Ä W tym celu można posłużyć się diagramem Venna Ä Diagram Venna to rysunek obiektów świata rzeczywistego. Zauważmy, że w podanym opisie pojawiają się (przynajmniej) następujące obiekty: klienci, pracownicy, zamówienia i towary. Można wyróżnić w tym modelu więcej obiektów, ale utrudniłoby to zarówno jego przedstawienie jak i zrozumienie. Projektowanie schematów relacyjnych 40

Projekt logiczny bazy danych – przykład Diagram Venna v Obiekty odrysowujemy na diagramie Venna i obiekty tej samej klasy grupujemy w zbiory (tu 4 zbiory: klientów, pracowników, zamówień i towarów). v Pomiędzy poszczególnymi obiektami rysujemy linie, które symbolizują zależności tych obiektów zachodzące w świecie rzeczywistym. Projektowanie schematów relacyjnych 41

Diagram Venna – przykład Zależności pomiędzy towarami a zamówieniami: poprawną sytuacją w świecie rzeczywistym jest • Czy Analizując dalej związki między klientami, a zamówieniami klienta, który nie składał żadnego zamówienia? • znajomość okazuje się, że KAŻDE zamówienie dotyczy przynajmniej (ale tym razem od strony zamówień) – okazuje się, że dane jednego towaru, ale może też dotyczyć wielu towarów • zamówienie jest składane przez najwyżej jednego klienta Z pozoru wydaje się, że to błędna sytuacja: kto podawałby (np. "zamówienie 301"), i że mogą być zamówienia takie, że klient jest nieznany. swoje dane osobowe, a nic nie zamawiał (na diagramie • "Mariusz Białek")? z kolei towar może być zamawiany wielokrotnie w różnych zamówieniach (np. "pizza"), • • Podobne zależności występują pomiędzy pracownikami, Jednak okazuje się, że taka sytuacja może mieć miejsce, gdy • a zamówieniami: dany pracownik może obsługiwać wiele ale też może istnieć towar, który nie był nigdy zamawiany firma zakupi dane osobowe potencjalnych klientów (np. osób zamówień, ale dane zamówienie MUSI być obsłużone (np. dopiero się pojawił w sprzedaży lub jest zbyt drogi, aby mieszkających w okolicy). przez jednego pracownika. był kupiony - tu: "truskawki w cieście" i "papryka zielona"). Projektowanie schematów relacyjnych 42

Projekt logiczny bazy danych – przykład v Podczas konwersji ü ü q zbiory obiektów przekształcane są na encje, a zależności pomiędzy obiektami na związki encji. Przyjmuje się, że nazwa encji jest rzeczownikiem w liczbie pojedynczej (nie jest to jednak obowiązkowe), a tabeli w liczbie mnogiej. o Z tego powodu na powyższym diagramie w prostokątach symbolizujących encje pojawiły się nazwy: "klient", "pracownik", "zamówienie", "towar". o Pomiędzy encjami pojawiły się specjalnie oznakowane kreski, które symbolizują związki encji. Projektowanie schematów relacyjnych 43

Projekt logiczny bazy danych – przykład Klient Zamówienie składa jest składane przez dotyczy Towar jest składnikiem jest obsługiwane przez obsługuje Pracownik Czytając te związki widzimy, że: 1. 2. 3. 4. 5. 6. Jeden klient może złożyć wiele zamówień Każde zamówienie może być złożone przez maksymalnie jednego klienta Każdy pracownik może obsłużyć wiele zamówień Każde zamówienie musi być obsłużone przez jednego pracownika Każde z zamówień dotyczy przynajmniej jednego towaru Każdy towar może być składnikiem wielu zamówień Projektowanie schematów relacyjnych 44

Projekt logiczny bazy danych – przykład v Diagram związków encji – związki wielowartościowe Nie istnieje taki RDBMS, który obsługuje związki wiele do wielu, a taki właśnie związek zachodzi pomiędzy towarem, a zamówieniem. } Związki te muszą zostać usunięte z diagramu w wyniku zastąpienia ich dwoma związkami jeden do wielu i encją przejściową. Ä Operacja ta może zostać wykonana automatycznie, gdyż istnieją odpowiednie narzędzia do projektowania, które zrobią to automatycznie, ale nadają one niezrozumiałe nazwy tworzonym encjom przejściowym i potrafią też robić błędy. Projektowanie schematów relacyjnych 45

Projekt logiczny bazy danych – przykład Ø Diagram związków encji po eliminacji związków wielo-wielowartościowych encja przejściowa Klient Zamówienie składa jest składane przez Szczegół jest składnikiem jest obsługiwane przez obsługuje Pracownik Projektowanie schematów relacyjnych dotyczy należy Towar 46

Projekt logiczny bazy danych – przykład v Diagram związków encji – związki wielowartościowe W tym wypadku została dodana encja "szczegół zamówienia„ i dwa związki jeden do wielu, które należy czytać: 1. Każde zamówienie musi posiadać przynajmniej jeden szczegół zamówienia 2. Każdy szczegół zamówienia musi być składnikiem jednego zamówienia 3. Każdy szczegół zamówienia musi dotyczyć jednego towaru 4. Każdy towar może należeć do wielu szczegółów zamówienia. Projektowanie schematów relacyjnych 47

Projekt logiczny bazy danych – przykład v Określenie atrybutów encji Po wykonaniu diagramu (już bez związków wiele do wielu) określa się jeszcze jakie atrybuty powinna posiadać każda z encji (czyli określamy cechy obiektów ze świata rzeczywistego). o Dodatkowo określa się, czy podanie wartości do danego atrybutu jest wymagane (NOT NULL), czy nie (NULL). Ä Ważną sprawą jest też opisanie znaczenia zarówno encji jak i ich atrybutów. Projektowanie schematów relacyjnych 48

Projekt logiczny bazy danych – przykład Encja: Opis: Atrybut KLIENT Klienci firmy i ich adresy. Wymagany Klucz Opis Identyfikator klienta NOT NULL PRIMARY KEY Identyfikator klienta. Klucz podstawowy. Nazwisko NOT NULL Nazwisko klienta. Imię NOT NULL Imię klienta. Ulica i numer domu NOT NULL Adres klienta - oprócz ulicy i numeru domu jest tu podawany także numer mieszkania (o ile jest potrzebny). W szczególnych przypadkach adresem jest skrzynka pocztowa. Miasto NOT NULL Nazwa miasta, w którym mieszka klient. Kod pocztowy NOT NULL Kod pocztowy do adresu klienta. Zastosowano tu znaczne uproszczenie względem świata rzeczywistego - adres jest krajowy. Telefon kontaktowy NULL Numer telefonu, pod którym najłatwiej zastać klienta. Jest to uproszczenie względem świata rzeczywistego - telefonów może być wiele i nie jest to jedyny rodzaj kontaktu Projektowanie schematów relacyjnych 49

Projekt logiczny bazy danych – przykład Encja: PRACOWNIK Opis: Pracownicy, ich pensje i kto nimi zarządza (zostanie dodane później). Docelowo posiadać będzie klucz obcy (ID_SZEFA jest w związku z ID_PRACOWNIKA) Atrybut Wymagany Klucz Opis Identyfikator pracownika NOT NULL PRIMARY KEY Identyfikator pracownika. Klucz podstawowy. Nazwisko NOT NULL Nazwisko pracownika. Imię NOT NULL Imię pracownika. Ulica i numer domu NOT NULL Adres pracownika - oprócz ulicy i numeru domu jest tu podawany także numer mieszkania (o ile jest potrzebny). W szczególnych przypadkach adresem jest skrzynka pocztowa. Miasto NOT NULL Nazwa miasta, w którym mieszka pracownik. Kod pocztowy NOT NULL Kod pocztowy do adresu pracownika. Zauważ uproszczenie względem świata rzeczywistego - adres jest krajowy. Telefon kontaktowy NULL Kod pocztowy do adresu pracownika. To jest uproszczenie względem świata rzeczywistego - adres jest krajowy. Pensja NOT NULL Pensja pracownika. To jest uproszczenie względem świata rzeczywistego - brak szczegółowej informacji o dochodach. Identyfikator szefa NULL FOREIGN KEY Obecnie będzie dodawany. Znaczenie wyjaśnione będzie podczas zajęć. Użycie tego atrybutu nie wynika z diagramu związków encji. Projektowanie schematów relacyjnych 50

Projekt logiczny bazy danych – przykład Encja: Opis: Atrybut ZAMÓWIENIE Informacja o złożeniu zamówienia. Wymagany Klucz Opis Identyfikator zamówienia NOT NULL PRIMARY KEY Identyfikator zamówienia. Klucz podstawowy. Identyfikator klienta NULL FOREIGN KEY Kto składał zamówienie. Klucz obcy w związku z identyfikatorem klienta encji klient. Jeżeli jest NULL, to oznacza, że nie znamy klienta, który robił zakupy. Identyfikator pracownika NOT NULL FOREIGN KEY Kto przyjmował zamówienie. Klucz obcy w związku z identyfikatorem pracownika encji PRACOWNIK. Data zamówienia NOT NULL Data złożenia zamówienia. Domyślnie dzisiaj. Data opłacenia NULL Data opłacenia zamówienia (większa lub równa niż data złożenia). Nie każdy płaci gotówką. Znane są inne formy płatności: przelew bankowy lub przekaz pocztowy. Jeżeli data opłacenia jest NULL, to identyfikator klienta musi być podany. Projektowanie schematów relacyjnych 51

Projekt logiczny bazy danych – przykład Encja: TOWAR Opis: Towary sprzedawane przez firmę. Tu jest informacja o cenie towaru - znaczne uproszczenie względem rzeczywistego świata. Atrybut Wymagany Klucz Opis Kod kreskowy NOT NULL PRIMARY KEY Identyfikator towaru. Klucz podstawowy. Jest to tzw. UPC (Universal Product Code) - każdy produkt posiada swój unikalny kod kreskowy. Nazwa NOT NULL Nazwa towaru. Cena brutto NOT NULL Cena towaru. Projektowanie schematów relacyjnych 52

Projekt logiczny bazy danych – przykład Encja: Opis: Atrybut SZCZEGÓŁ ZAMÓWIENIA Poszczególne pozycje zamówień - jaki (i ile) towar został zakupiony. Wymagany Klucz Opis Identyfikator zamówienia NOT NULL PRIMARY KEY, FOREIGN KEY Wraz z atrybutem Kod kreskowy tworzy klucz podstawowy. Jest też kluczem obcym w związku z identyfikatorem zamówienia encji ZAMÓWIENIE. Kod kreskowy NOT NULL PRIMARY KEY, FOREIGN KEY Wraz z atrybutem Identyfikator zamówienia tworzy klucz podstawowy. Jest też kluczem obcym w związku z atrybutem kod kreskowy encji TOWAR. Ilość NOT NULL Ile sprzedano towaru (sztuk lub kilogramów). Tu nie będziemy przechowywali ułamków (gramy, dekagramy) w ramach uproszczenia. Projektowanie schematów relacyjnych 53

Wirtualne projektowanie bazy danych • • Projektując bazy danych warto skorzystać z bezpłatnego narzędzia o nazwie DBDesigner. Program ten umożliwia nie tylko wizualne projektowanie baz danych ale także synchronizację modelu bazy danych z serwerem. Diagramy tworzone w programie DBDesigner prezentują strukturę bazy danych w znacznie bardziej przejrzysty sposób niż jakikolwiek opis słowny. Narzędzie to jest rozpowszechniane na licencji GNU GPL, a zatem jest całkowicie bezpłatne zarówno do użytku domowego jak i zastosowań komercyjnych Projektowanie schematów relacyjnych 54