Projektowanie baz danych
Uwagi ogólne Projektowanie baz danych jest częścią tworzenia systemu z bazą danych. Podlega ogólnym zasadom tworzenia projektu.
Przed rozpoczęciem projektowania Modelowanie biznesowe co się dzieje w rzeczywistości, którą implementujemy? Po co? Dla kogo? Wymagania użytkownika jaką funkcjonalność chcemy zaimplementować?
Etapy projektowania bazy danych konceptualne (bez odniesienia do SZBD) zapisanie informacji o projekcie w standardowej notacji ER (diagramy Chena lub UML) niezależnej od docelowego SZBD. logiczne (dla SZBD konkretnego typu, np. relacyjnego lub obiektowego) podział danych na struktury dostępne w SZBD. fizyczne (dla konkretnego SZBD) zdefiniowanie dziedzin, relacji, indeksów, perspektyw, użytkowników z uprawnieniami itp.
Modelowanie konceptualne
Ogólne problemy Jak modelować dane niezależnie od implementacji? Jak osiągnąć dobry schemat bazy danych?
Co powinniśmy osiągnąć? Porozumienie dotyczące schematu bazy danych przed podjęciem decyzji o implementacji. Powinniśmy wiedzieć: Jakie jednostki(encje) modelować Jak jednostki (encje) są powiązane nawzajem Jakie są ograniczenia w modelowanej dziedzinie. Powinniśmy osiągnąć dobry projekt Efektem modelowania jest nieformalne przedstawienie bazy danych w postaci diagramów
Model Chena
Model Chena Jednostka (ang. Entity) obiekt, encja; Atrybuty (ang. Attributes) Związki (ang. Relationship)
Diagramy Chena zbiór encji Encja - zbiór jednorodnych elementów, o skończonej, regularnej strukturze, które można wyróżnić w zagadnieniu rzeczywistym. Pracownik Firma Stanowisko Oddział
Diagramy Chena atrybuty Atrybut - cecha encji. Encja ma ustaloną liczbę atrybutów. Dla każdego atrybutu określamy typ jego wartości oraz ewentualne ograniczenia nałożone na te wartości (zakres, format itp.) Imię Nazw Regon Nazwa Pracownik DataUr Firma Kapitał
Diagramy Chena Osoba Pesel Nazwa Płeć DataUr Tytuł Imię Drugie Imię Nazwisko Encje mogą być proste lub złożone
Diagramy Chena - klucze Klucz minimalny podzbiór atrybutów encji pozwalający jednoznacznie wyznaczyć encję; Rodzaje kluczy: Klucz kandydujący dowolny klucz zbioru encji; Klucz główny wybrany jeden klucz spośród kandydujących; Klucze alternatywne klucze kandydujące oprócz głównego; Podział kluczy: Klucz złożony: {Nazwisko, Imie, DataUr} Klucz prosty: {PESEL}, {NIP}, Klucz sztuczny: {OsID}
Diagramy Chena - klucze Każdy typ jednostki musi posiadać klucz. Klucz oznaczany jest przez podkreślenie. Regon Nazwa Firma Kapitał
Diagramy Chena związki Związek określamy pomiędzy zbiorami encji. Funkcyjny (1-n) 1 n Firma ma Oddział Wieloznaczny (n-m) Pracownik n ud m Firma Jednoznaczny (1-1) Kraj 1 ma 1 Stolica
Diagramy Chena atrybuty związku Związek może mieć atrybuty Samochód n 1 ma Osoba datazak cena Firma n Ud m Osoba datazat płaca
Diagramy Chena związki k-arne Możliwe są związki pomiędzy >2 zbiorami encji. Grupa Przedmiot ma Sala termin Wykładowca
Diagramy Chena związki rekurencyjne Związek pomiędzy encjami tego samego zbioru. Definiując taki związek określamy rolę każdej z encji w związku. jest podwładnym OSOBA podległość jest przełożonym
Diagramy Chena związki hierarchiczne PRACOWNIK ZESPÓŁ isa kieruje MANAGER Premia Data
Większy przykład OSOBA isa isa poprzedza 0..1 1..* STUDENT PRACOWNIK następstwo KURS * 1 isa następuje_po zapisany zawiera PROFESOR 1..* 1..* WYKŁAD * prowadzi 1
Podsumowanie procesu tworzenia modelu konceptualnego 1. określ zbiory encji; 2. określ związki pomiędzy zbiorami encji i ich rodzaj; 3. określ atrybuty encji i związków (uwaga na atrybuty redundantne); 4. wyznacz dziedziny atrybutów i ich ograniczenia; 5. wyznacz klucze kandydujące i wybierz klucze główne; 6. określ więzy ogólne;
Diagramy klas
Klasa- części składowe Nazwa klasy Atrybuty klasy Metody klasy
Klasa - przykład Trzy rodzaje pól: nazwa klasy, atrybuty klasy oraz metody klasy. Możliwe są różne poziomy szczegółowości. Pracownik Nazwisko DataUr PESEL Pracownik Firma Nazwa Regon Adres Firma
specjalizacja generalizacja Dziedziczenie klas Dziedziczenie pozwala na tworzenie drzewa klas. Osoba Osoba Pracownik Pracownik Asystent Adiunkt Docent Profesor Asystent Adiunkt Docent Profesor
Asocjacje Asocjacja może mieć nazwę (pracuje_dla), która wyznacza znaczenie tej asocjacji w modelu pojęciowym opisującym dziedzinę przedmiotową. Firma 1 pracuje_dla 1..* Osoba Asocjacje mogą być wyposażone w oznaczenia liczności. Liczność oznacza, ile obiektów innej klasy może być powiązane z jednym obiektem danej klasy.
Atrybuty asocjacji klasy asocjacyjne Plik * dostępny dla * Użytkownik Prawo dostępu dostęp { dostęp oznacza: czytanie lub czytanie-pisanie} kieruje szef 0..1 Osoba nazwisko pesel adres * pracownik 1..* zatrudnia 0..1 Zatrudnienie zarobek stanowisko Firma nazwa adres Ocena wydajności ocena
Kiedy stosować atrybuty asocjacji? Zalecane jest, by przypisywać do klasy tylko te atrybuty, które są dla tej klasy stabilne. Osoba nazwisko pesel adres 1..* pracuje_w 0..1 Zatrudnienie zarobek stanowisko Firma nazwa adres Forma nie zalecana, mniej elastyczna: np. po zmianie powiązania na wiele-do-wielu trzeba zmieniać położenie atrybutów. Osoba nazwisko pesel adres zarobek stanowisko 1..* pracuje_w 0..1 Firma nazwa adres
Przykładowy diagram klas Osoba poprzedza zapisany_na 1..* 0..1 Kurs * 1 zawiera następuje_po Student Pracownik Profesor prowadzi 1 1..* 1..* Wykład *
Budowa modelu obiektowego Poszczególne kroki podczas tworzenia modelu konceptualnego Identyfikacja klas użytkownika Identyfikacja związków Identyfikacja atrybutów Identyfikacja relacji dziedziczenia
Transformacja modelu konceptualnego do modelu relacyjnego
Przejście na model relacyjny Transformacja modelu logicznego do fizycznego polegać będzie na przeniesieniu klas oraz związków do odpowiednich tabel bazodanowych Podstawowe problemy przy przechodzeniu na model relacyjny: nie ma możliwości przechowywania wielu wartości jednego atrybutu, każda tabela musi byc wyposażona w unikalny klucz, powiązania muszą być zaimplementowane jako tabele/relacje z kluczami obcymi, nie można zagnieżdżać danych, występują ograniczenia na rozmiar krotek, wartości elementarne i typy danych, brak dziedziczenia i wielodziedziczenia, Dodatkowo należy uwzględnić: cechy ilościowe (charakterystyka ilościowa danych i procesów), unikanie redundancji w danych (normalizacja), wymagania użytkowe: czas odpowiedzi, utylizacja pamięci (denormalizacja). Przejście na model relacyjny nie może być całkowicie automatyczne.
Podstawowe informacje Zasadniczo można rozważać konwertowanie klas do tabel bazy danych nie zawsze jednak jest to możliwe. Przeszkody: np. brak obsługi dziedziczenia. Atrybuty klasy są konwertowane na kolumny tabeli przypadek najprostszy Nie wszystkie atrybuty są trwałe niektóre są używane do obliczeń tymczasowych. Wtedy nie są mapowane. Jeśli atrybuty obiektu są obiektami, wówczas tworzona jest asocjacja pomiędzy nimi: np.: klient posiada adres, który jest bytem złożonym Tabela może zawierać atrybuty, które nie są wyszczególnione w klasie
Odwzorowanie metod/operacji Model relacyjny nie przewiduje specjalnych środków. Najczęściej są one odwzorowane na poziomie programów aplikacyjnych jako procedury napisane w proceduralnych lub obiektowych językach programowania i dedykowane do obsługi pewnej tabeli/tabel w relacyjnej bazie danych. Niekiedy w systemach relacyjnych mogą być odwzorowane w postaci procedur baz danych (w SQL) lub w postaci aktywnych reguł. Odwzorowanie polimorfizmu, przesłaniania, dynamicznego wiązania i hermetyzacji jest w zasadzie niemożliwe. Programista może napisać procedurę, która w środku ma przełączenie jawne na różne przypadki specjalizacji klas.
Rodzaje relacji Rodzaje relacji 1:1 - jeden do jednego 1:N jeden do wielu M:N wiele do wielu
Odwzorowanie asocjacji Dla liczności 1:1 można zaimplementować jako jedną tablelę. Państwo Nazwa Stolica Miasto Państwo IdPaństwa Nazwa Stolica Dla liczności 1:n można zaimplementować jako dwie tabele: (Atrybuty związku na ogół powodują konieczność zastosowania następnej metody.) Pracownik Nazwisko 1..* pracuje_w 1 Firma Nazwa Pracownik IdPrac Nazwisko IdFirmy Firma IdFirmy Nazwa Dla liczności m:n należy zaimplementować jako trzy tabele. Pracownik Nazwisko pracuje_w 1..* * Firma Nazwa Pracownik IdPrac Nazwisko PracFirma IdPrac IdFirmy Firma IdFirmy Nazwa
Trzy metody obejścia braku dziedziczenia Użycie jednej tabeli dla całego drzewa klas poprzez zsumowanie wszystkich występujących atrybutów i powiązań w tym drzewie oraz dodanie dodatkowego atrybutu - dyskryminatora wariantu. B A C A B C dyskr Użycie oddzielnych tabel dla każdej klasy konkretnej. Usunięcie klas abstrakcyjnych i przesunięcie ich atrybutów/powiązań do klas konkretnych. B A C A B A C Użycie tabel dla każdej klasy. Zamiana dziedziczenia na powiązania łączące nadklasę ze wszystkimi podklasami. B A C B A 0..1 C 0..1
Przykład obejścia braku dziedziczenia PIT pojedyncz podatnika Adres PIT Kwota do zwrotu Należny podatek Podstawa opodatkowania Rok PIT małżeństwa Adres męża Adres żony PIT pojedyncz podatnika Adres Kwota do zwrotu Należny podatek Podstawa opodatkowania Rok PIT małżeństwa Adres męża Adres żony Kwota do zwrotu Należny podatek Podstawa opodatkowania Rok dodatkowy atrybut dyskryminator PIT Kwota do zwrotu Należny podatek Podstawa opodatkowania Rok Adres Adres męża Adres żony Rodzaj PIT PIT pojedyncz podatnika Adres PIT Kwota do zwrotu Należny podatek Podstawa opodatkowania Rok PIT małżeństwa Adres męża Adres żony
Zalety i wady każdej z trzech metod Cecha Jedna tabela dla hierarchii Tabela dla klasy konkretnej Tabela dla każdej klasy Łatwość implementacji Prosta Średnia Trudna Łatwość dostępu do danych Prosta Prosta Średnia Łatwość przypisania OID Prosta Średnia Średnia Związanie informacji Bardzo duże Duże Małe Szybkość dostępu Bardzo szybki Szybki Wolny Wspomaganie dla polimorfizmu Słabe Średnie Duże Konsumpcja pamięci Duża Mała Mała
Przejście na model relacyjny; przykłady (1) Klient NazwaKlienta ma InfoDostawy AdresDostawy KlientDostawa (IdKlienta, NazwaKlienta, AdresDostawy) Klient NazwaKlienta posiada 0..1 KartaKredytowa IdKarty TypKarty LimitKarty Klient (Id_Klienta, Nazwa_Klienta) KartaKredytowa (IdKarty, TypKarty, IdKlienta, LimitKarty) Projektant nie zdecydował się na jedną tabelę, gdyż założył, że będzie zbyt dużo wartości zerowych.
Przejście na model relacyjny; przykłady (2) Kobieta NazwiskoKobiety 0..1 0..1 Ślub DataŚlubu Mężczyzna NazwiskoMężczyzny Kobieta( IdKobiety, NazwiskoKobiety ) Mężczyzna( IdMężczyzny, NazwiskoMężczyzny ) Ślub( IdKobiety, IdMężczyzny, DataŚlubu ) Student Nazwisko_Studenta Suma_Pkt_Studenta 1..* Student_Kurs Ocena_semestr Semestr Kurs Nazwa_Kursu Student (Id_Studenta, Nazwisko_Studenta, Suma_Pkt_Studenta) Kurs (Id_Kursu, Nazwa_Kursu) Student_Kurs (Id_Studenta, Id_Kursu, Semestr, Ocena_semestr) *
Przejście na model relacyjny; przykłady (3) Miasto NazwaMiasta LiczbaMieszkM 1..* leży_w Miasto(NazwaMiasta, NazwaWojewództwa, LiczbaMieszkM) Województwo(NazwaWojewództwa, Wojewoda, LiczbaMieszkW) Województwo NazwaWojewództwa Wojewoda LiczbaMieszkW Sprzedaż IdSprzedaży Data * Sprzedawca Nazwisko NrTel Sprzedaż_Sprzedawca NazwaTowaru Ilość Sprzedawca(Nazwisko, NrTel) Sprzedaż(IdSprzedaży, Data) Sprzedaż_Sprzedawca (IdSprzedaży, Nazwisko,NazwaTowaru, Ilość)
Przejście na model relacyjny; przykłady (4) jest_przełożonym Pracownik NazwiskoPrac DataUrodzPrac podległość jest_podwładnym M:N 1:N 1:1 Pracownik (IdPracownika, NazwiskoPrac, DataUrodzPrac) Podległość (IdPracPrzełoż, IdPracPodwład) Pracownik (IdPracownika, NazwiskoPrac, DataUrodzPrac, IdPracPodwład) Pracownik(IdPracownika, NazwiskoPrac, DataUrodzPrac, IdPracPrzełoż)
Przejście na model relacyjny; przykłady (5) Towar Nazwa_Towaru Klient Nazwa_Klienta Sprzedawca Nazwa_Sprzedawcy Sprzedaż Ilość_Towaru Data_Sprzedaży Klient (Id_Klienta, Nazwa_Klienta) Towar (Id_Towaru, Nazwa_Towaru) Sprzedawca (Id_Sprzedwcy, Nazwa_Sprzedawcy) Sprzedaż (Id_Klienta, Id_Sprzedawcy, Id_Towaru, Data_Sprzedaży, Ilość_Towaru)
Normalizacja czy denormallizacja Normalizacja polega na zdekomponowaniu tabeli na dwie lub więcej celem uniknięcia niekorzystnych własności: redundancji w danych oraz związanych z redundancją anomalii aktualizacyjnych. Istnieje 5 postaci normalnych relacji Metodyki oparte na modelu encja-związek i metodyki obiektowe w naturalny sposób prowadzą do znormalizowanych schematów. Podejście top-down oraz tendencja do dekompozycji/separowania pojęć również w naturalny sposób prowadzą do znormalizowanych schematów. Czynniki inne niż zależności funkcyjne mogą okazać się bardziej istotne (wydajność --> denormalizacja).
Należy zapamiętać Klasa jest odwzorowana na tabelę Atrybut klasy jest odwzorowany na kolumnę tabeli Implementacja relacji 1:1 polega na połączeniu atrybutów w jedną tabelę Implementacja relacji 1:N polega na dodaniu klucza obcego do tabeli po stronie wiele Implementacja relacji N:M polega na stworzeniu tabeli asocjacyjnej, która zawiera kombinację kluczy głównych Dziedziczenie można obejść przez agregację, stworzenie jednej wspólnej tabeli lub jednej tabeli dla każdej klasy Osiągnięcie rozsądnego kompromisu między normalizacją a denormalizacją Przy projektowaniu należy brać pod uwagę rozmiar tabel oraz przyrost danych w przyszłości
Dziękuję