Projektowanie bazy danych

Projektowanie bazy danych

Cel wykładu Umiejętność zamodelowania bazy danych na diagramie

Plan wykładu Cel modelowania konceptualnego i modelu ER Etapy modelowania konceptualnego Model ER (związków encji) Encje i atrybuty Związki i typy związków Związki binarne: 1:1, 1:N, M:N Związki wieloczłonowe i ich właściwości Związki rekurencyjne Związki z uczestnictwem encji zależnych od czasu (zdarzeń) Specjalizacja/generalizacja

Projektowanie aplikacji bazodanowej opis Gromadzenie i analiza wymagań użytkowników dotyczących danych i funkcjonalności (jakie dane i ich powiązania chcemy przechowywać) etap analiza wynik Model konceptualny, wysokopoziomowy (ER) Transformacja modeli konceptualnych do modeli implementacyjnych (decyzje o zbiorze tabel i atrybutów) projektowanie Modele implementacyjne (model relacyjny dla relacyjnej bazy danych) Budowa bazy danych w wybranej technologii i zaimplementowanie Aplikacji (definicja tabel, wprowadzanie danych) implementacja Gotowa baza danych i aplikacja Wdrożenie aplikacji u użytkownika wdrożenie Działająca aplikacja bazodanowa Ciągła administracja i pielęgnowanie systemu utrzymanie

Zasady dobrego projektowania Prawidłowy projekt bazy danych jest bardzo istotny z punktu widzenia jej dalszego użytkowania Dobry projekt to taki, który: minimalizuje rozmiar bazy danych brak redundancji (każda informacja jest przechowywana tylko raz!) zapewnia spójność danych dobieranie właściwych związków zapewnia łatwy dostęp do danych i ich modyfikację (patrz m.in. wykład o normalizacji)

Etapy projektowania Przygotowanie modelu konceptualnego Normalizacja projektu Implementacja reguł integralnościowych

Etapy tworzenia modelu konceptualnego Określenie dokładnego celu, któremu ma służyć baza danych (np. dziennik dla nauczyciela) Określenie wszystkich informacji, które mają znaleźć się w bazie danych (nazwisko, imię, przedmiot, ocena, uwagi, nieobecności,...) Zgromadzenie informacji w encjach (obiektach), które potem znajdą się w bazie danych (Uczeń, Przedmiot, Nauczyciel) Określenie pól (atrybutów) opisujących obiekty (Uczeń - imię, nazwisko) Określenie zbioru wartości atrybutów (ocena - 1, 2, 3, 4, 5,...) Wybranie kluczy podstawowych (Nauczyciel - Pesel) Określenie związków między encjami (Przedmiot - nauczany przez Nauczyciela)

Modele projektowania konceptualnego Diagram związków encji ERD (Entity Relationship Diagram) Język UML (Unified Modeling Language) Język ODL (Object Description Language)

ERD Entity Relationship Diagram Model ER (Entity-Relationship model związków encji) model konceptualny, odwzorowujący obiekty świata rzeczywistego w obiekty w bazie danych Projekt ma postać graficzną zwaną diagramem ER (entityrelationship diagram) lub diagramem związków encji Istnieje procedura (pół)automatycznej transformacji diagramu ER do konkretnej implementacji, na przykład do relacyjnej bazy danych.

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. entity) (po polsku także: jednostka, obiekt), atrybut (ang. attribute), związek (ang. relationship)

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

Diagramy ER notacja Chen a c.d. krotność związku jak czytać: Dany (konkretny) towar może być kupowany przez wielu klientów (ale nie musi być kupiony przez nikogo) Dany (konkretny) klient kupił jeden lub wiele towarów (klientem staje się osoba, która kupiła co najmniej jeden towar)

Przykłady innych notacji

Encja Encja reprezentuje zbiór obiektów świata rzeczywistego (obiekty materialne, niematerialne, zdarzenia, fakty) opisany tymi samymi cechami (atrybutami, własnościami) Konkretny obiekt świata rzeczywistego jest reprezentowany jako wystąpienie encji (instancję encji) Encja posiada unikalną nazwę (rzeczownik w liczbie pojedynczej) Encja posiada zbiór atrybutów, przy czym jeden lub więcej atrybutów powinny stanowić klucz (identyfikator) encji jednoznacznie identyfikujący wystąpienie encji

Encja c.d. Encja może reprezentować: Obiekt materialny: pracownik, książka, samochód, towar Obiekt niematerialny: faktura, projekt, konto, zamówienie Zdarzenie: choroba pracownika, przyznanie nagrody, kontrola Fakt: znajomość języka obcego, stan magazynowy produktu Encja: Wystąpienia encji: Towar Towar Nazwa = DELL Inspiron 1564 i5 Kategoria = notebooki Cena = 2899,00 Towar Nazwa = Logitech OEM PC860 Kategoria = peryferia Cena = 42,90 Nazwa = Canon EOS 7D Kategoria = lustrzanki Cena = 8299,00

Atrybut Encja posiada atrybuty czyli opisujące je szczegółowe własności; wartości atrybutów stanowią główną część danych składowanych w bazie danych 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 Każda encja posiada identyfikator - atrybut lub zbiór atrybutów jednoznacznie identyfikujący wystąpienie encji; pozostałe atrybuty nazywa się deskryptorami

Związek Związek reprezentuje powiązania między obiektami świata rzeczywistego (np. klienci kupują towary, pokój jest przydzielony pracownikowi) Typ związku (kardynalność, liczebność) jeden-do-jeden (1:1) jeden-do-wiele (1:N) wiele-do-wiele (M:N) Stopień związku unarny (binarny rekursywny) binarny ternarny n-arny (wieloczłonowy) Istnienie opcjonalny (nie obowiązkowy) obowiązkowy (obligatoryjne)

Związki binarne obowiązkowe jeden-do-jeden 1:1 Każdy pracownik zajmuje dokładnie jeden pokój (nie ma pracownika bez pokoju) Każdy pokój jest zajmowany przez dokładnie jednego pracownika (nie ma pustych pokoi) pracownik A B C D pokój 1 2 3 4

Związki binarne obowiązkowe jeden-do-wiele 1:N Każdy pracownik zajmuje dokładnie jeden pokój (nie ma pracownika bez pokoju) Każdy pokój jest zajmowany przez jednego lub wielu pracowników (nie ma pustych pokoi) pracownik A B C D pokój 1 2

Związki binarne obowiązkowe wiele-do-wiele N:M Każdy pracownik zajmuje jeden lub wiele pokoi (nie ma pracownika bez pokoju) Każdy pokój jest zajmowany przez jednego lub wielu pracowników (nie ma pustych pokoi) pracownik A B C D pokój 1 2 3 4

Związki binarne opcjonalne jeden-do-jeden jeden-do-wiele wiele-do-wiele

Zadanie Zaproponuj model koncepcyjny schematu z wykorzystaniem encji, atrybutów i związków do przechowywania poniższych danych idosoby Nazwisko Telefony Imię Dzieci 61-848-12-34 Ewa 2000 101 Lipski 607-123-123 Adam 2002 102 Nowak Helena 1999 103 Lipska 607-321-321 104 Kubiak 501-222-333 Ewa 2000 Adam 2002 RokUr

Związki uwagi związek między encjami jest pamiętany jednokrotnie (związek jest jednoznacznie identyfikowany przez wystąpienia encji, które łączy; zatem np. informacja o tym, że dany pracownik zajmuje dany pokój jest przechowywana tylko jeden raz) możliwe jest połączenie encji kilkoma związkami, reprezentującymi kilka różnych zależności, np.: Zakup N N N zamówienie realizacja wysyłka 1 1 1 Data

Związki wieloczłonowe Pracownik pracuje w jednym lub kilku projektach W każdym z nich pełni określoną rolę

Związki wieloczłonowe PRZEDMIOT, NAUCZYCIEL UCZEŃ Z iloma różnymi uczniami związana jest para (przedmiot, nauczyciel)? Inaczej - czy nauczyciel z danego przedmiotu może egzaminować więcej uczniów niż jednego? (TAK, może wielu etykieta N" przy encji UCZEŃ) PRZEDMIOT, UCZEŃ NAUCZYCIEL Z iloma różnymi nauczycielami związana jest para (przedmiot, uczeń)? Inaczej - czy uczeń z danego przedmiotu może zdawać egzamin u więcej niż u jednego nauczyciela? (NIE, co najwyżej u jednego etykieta 1" przy encji NAUCZYCIEL) NAUCZYCIEL, UCZEŃ PRZEDMIOT Z iloma różnymi przedmiotami związana jest para (nauczyciel, uczeń)? Inaczej, czy uczeń u danego nauczyciela może zdawać egzamin z więcej niż z jednego przedmiotu? (NIE, etykieta 1" przy encji PRZEDMIOT) Czy uczeń może powtórzyć egzamin z danego przedmiotu u danego nauczyciela? patrz kolejny slajd

Związki wieloczłonowe ide idp data Egzamin ocena idu Przedmiot Uczeń Nauczyciel idn W poprzednim przykładzie Egzamin identyfikowany jest przez trójkę: (IdP, IdU, IdN) nie można więc pamiętać informacji o kilkukrotnym zdawaniu tego samego przedmiotu przez tego samego ucznia u tego samego nauczyciela (wartość klucza musiałaby się powtarzać, co jest niedopuszczalne). Aby modelować taką sytuację tworzymy encję EGZAMIN posiadającą własny atrybut kluczowy (identyfikator).

Związek unarny (cykliczny)

Związki unarne przykład Reprezentacja struktury drzewiastej w relacyjnej bazie danych (np. szef podwładny; kategoria podkategoria) A B C D Reprezentacja struktury grafowej w relacyjnej bazie danych (np. sieć społecznościowa) C F B A D F

Atrybuty związku Cena towaru różna u różnych dostawców Liczba godzin spędzona nad projektem

Zmienność w czasie W bazie danych najczęściej chcemy przechowywać informacje historyczne, odzwierciedlające zmienność pewnej cechy lub związku wraz z upływem czasu Przykład chcemy przechowywać informacje o zmianach w wykształceniu Brak informacji historycznej: Informacja historyczna: Płeć PESEL Osoba Wykształcenie Nazwisko PESEL Płeć Data Rodzaj Nazwisko Osoba N N Wykształcenie

Encja słaba Encją słabą (ang. weak entity) nazywamy taką encję, której istnienie zależy od istnienia innej encji (jej właściciela). Encje słabe nie mają własnego atrybutu kluczowego. Identyfikowanie ich odbywa się poprzez kombinację wyróżnionego atrybutu (tzw. klucza częściowego) z atrybutami kluczowymi ich właścicieli.

Encja słaba - przykład Identyfikatorem encji Pozycja faktury jest para atrybutów: (numer_f, numer_p) Konsekwencją traktowania Pozycja faktury jako encji słabej jest to, że usunięcie z bazy danych faktury powinno spowodować jednoczesne usunięcie wszystkich związanych z nią pozycji.

Specjalizacja Encje mogą pozostawać względem siebie w zależnościach hierarchicznych: nadtyp typ podtyp przy czym jeden typ może mieć zarówno wiele nadtypów, jak i wiele podtypów. Proces definiowania podtypów dla zadanego typu T nazywamy specjalizacją (proces odwrotny to generalizacja) Przykład: Osoba Student, Absolwent, Pracownik

Specjalizacja c.d. Każda encja w podtypie posiada wszystkie te atrybuty, które posiada w nadtypie. Cechę tę nazywamy dziedziczeniem atrybutów (attribute inheritance). Może ponadto posiadać dodatkowe atrybuty specyficzne. Encja w podtypie reprezentuje ten sam obiekt dziedziny przedmiotowej co encja w nadtypie, stąd też musi posiadać te same wartości atrybutów co odpowiadający mu element nadtypu. Encja dziedziczy także właściwość uczestniczenia w tych typach związkowych, w których uczestniczy nadtyp, ale może także uczestniczyć w typach związkowych specyficznych dla swego podtypu.

Specjalizacja c.d. Rodzaje specjalizacji: Całkowita lub częściowa zależnie od tego czy każda instancja encji nadtypu musi być instancją którejś z encji podtypu (całkowita) czy nie (częściowa) Rozłączna lub nierozłączna zależnie od tego czy podtypy są parami rozłączne, czy nie

Specjalizacja całkowita rozłączna

Specjalizacja całkowita nierozłączna

Specjalizacja częściowa rozłączna

Specjalizacja częściowa nierozłączna

Decyzje projektowe Atrybut czy encja? Problem pracownik może posiadać wiele numerów telefonów

Decyzje projektowe Atrybut czy encja? Problem pracownik może posiadać wiele numerów telefonów Rozwiązanie 1: Rozwiązanie 2:

Decyzje projektowe c.d. Atrybut czy związek Atrybut czy wartość Przynależność atrybutu encja czy związek

Narzędzia do projektowania Przykładowe narzędzia do tworzenia schematów baz danych: DIA Toad Data Modeler SmartDraw Visio Oracle Data Modeler

Przykłady narzędzi DIA

Przykłady narzędzi Visio

Przykłady narzędzi Toad Data Modeler

Przykłady narzędzi Oracle Data Modeler

Przykład Firma Baza danych FIRMA ma umożliwiać zarządzanie danymi pracowników, działów oraz realizowanych projektów. 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. Dział kontroluje wiele projektów, z których każdy ma unikatową nazwę, unikatowy numer oraz jedno miejsce realizacji. Dla każdego pracownika przechowywany jest nazwisko 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. Chcemy również przechowywać informacje o członkach rodziny pracownika.

Przykłady Drzewo hierarchii Znajomi Ankieta Latarnik