Projektowanie baz danych

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? Wymagania użytkownika jaką funkcjonalność chcemy zaimplementować?

Wyznaczanie priorytetów Wymaganie jest konieczne, jeżeli nie można się bez niego obejść w systemie Wymaganie jest przydatne, jeżeli jego pominięcie nie spowoduje poważnych problemów związanych z realizacją podstawowych zamierzeń Wymaganie jest nieistotne, jeżeli mogą okazać się przydatne w pewnych zastosowaniach, lecz wprowadzenie ich do systemu nie jest warte wysiłku Wymaganie jest zbędne, jeżeli nie wiąże się w żaden sposób z celem projektu

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

Do czego służy modelowanie konceptualne? Eksploracja modelowanej dziedziny Analiza wymagań systemu w formie modelu konceptualnego/analitycznego Opis szczegółowego obiektowego projektu systemu

Ogólne problemy Jak modelować dane niezależnie od implementacji? Jak osiągnąć dobry schemat bazy danych? Efektem modelowania jest nieformalne przedstawienie bazy danych w postaci diagramów

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

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

Dziedziczenie klas Definicja generalizacji: Związek pomiędzy elementem bardziej ogólnym a elementem bardziej szczegółowym. Element szczegółowy jest w pełni spójny z elementem ogólnym, może jednak zawierać dodatkowe informacje. Instancje elementu szczegółowego mogą być wykorzystywane wszędzie tam, gdzie wymagane jest użycie instancji elementu ogólnego. Wskazuje, że obiekt klasy dziedziczącej (podklasy) jest wymienialny z obiektem klasy dziedziczonej (nadklasy).

specjalizacja generalizacja Dziedziczenie Dziedziczenie pozwala na tworzenie drzewa klas. Osoba Osoba Pracownik Pracownik Asystent Adiunkt Docent Profesor Asystent Adiunkt Docent Profesor

Asocjacje (1) Definicja: Asocjacja jest relacją pomiędzy dwoma lub więcej klasami, specyfikującą połączenie pomiędzy instancjami tych klas. Asocjacja pomiędzy dwoma klasami oznacza, że obiekt na jednym końcu asocjacji rozpoznaje obiekty na drugim końcu asocjacji i może im wysyłać wiadomości. Przykład: Pracownik pracuje dla firmy Firma Osoba

Asocjacje (2) Asocjacja może mieć nazwę (pracuje_dla), która wyznacza znaczenie tej asocjacji w modelu pojęciowym opisującym dziedzinę przedmiotową. Czarny trójkąt określa kierunek (czytania) wyznaczony przez nazwę asocjacji. 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.

Role asocjacji (1) Asocjacje mogą być wyposażone w nazwy ról (przy końcach), np. pracodawca i pracownik. W tym przypadku liczność asocjacji oznacza liczność roli. Firma * pracodawca pracuje_dla 1..* pracownik * podwładny Osoba 0..1 szef Role asocjacji są niezbędne, gdy powiązania łączą obiekty tej samej klasy. Można opuszczać nazwę asocjacji, gdy jest oczywista i jest jedyną asocjacją łączącą dwie klasy. Firma 1 1..* Pracownik

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

Identyfikacja klas użytkownika Uwaga skoncentrowana na dziedzinie aplikacyjnej, a nie na szczegółach implementacyjnych Punktem wyjścia może być znalezienie rzeczowników (kandydaci na nazwy klas) oraz czasowników (kandydaci na operacje) na podstawie opisu projektu, specyfikacji przypadków użycia oraz ogólnej wiedzy na temat rozważanej dziedziny projektowej

Identyfikacja klas użytkownika - wskazówki Należy unikać synonimów i nazw o zbliżonym znaczeniu Nazwa klasy powinna być rzeczownikiem lub rzeczownikiem poprzedzonym przymiotnikiem Należy wydzielić i usunąć z dalszych rozważań klasy, które nie mieszczą się z zakresie systemu Należy rozważyć i sprecyzować znaczenie przypisywanej każdej klasie. Jeśli zakres klasy nie jest wyraźnie wydzielony, należy rozważyć połączenie jej z inną (innymi klasami)

Identyfikacja klas użytkownika - wskazówki Należy odróżnić nazwy klas od nazw atrybutów klas. Nazwy klas powinny odnosić się do obiektów reprezentujących niezależne byty, podczas gdy atrybuty odnoszą się do własności charakteryzujących takie obiekty Należy pomijać nazwy, które charakteryzują role pełnione przez klasy w łączących je związkach (będą określone później). Wybrane nazwy klas powinny być niezależne od związków z innymi klasami Należy eliminować klasy, które reprezentują elementy implementacji Należy rozważyć eliminację klas bez operacji Klasy, które odnoszą się do więcej niż jednej abstrakcji (niespójne) powinny być podzielone na kilka klas

Identyfikacja związków pomiędzy klasami Należy unikać związków reprezentujących zależności implementacyjne Związki powinny reprezentować zależności trwałe (niezależne od czasu) Należy unikać związków, które można wyrazić za pomocą istniejących już związków (w przeciwnym razie występuje nadmiarowość) Należy dążyć do związków binarnych (obejmujących dwie klasy) Należy określić liczność charakteryzującą liczbę obiektów poszczególnych klas

Identyfikacja atrybutów Atrybuty powinny opisywać własności obiektów Należy rozpatrywać tylko te atrybuty, które mają sens aplikacyjny; nie należy wprowadzać atrybutów dodatkowych (np. identyfikatory obiektów) Atrybut, który zasadniczo różni się od innych atrybutów danej klasy może sugerować, że klasa jest niespójna i powinna być rozbita na różne klasy Należy rozważyć eliminację klas tylko z jednym atrybutem

Identyfikacja relacji dziedziczenia Należy zwrócić uwagę na klasy o podobnych cechach (atrybutach, związkach, operacjach) i zdefiniować dla nich klasy nadrzędne zawierające wspólne cechy Należy eliminować relacje dziedziczenia gdy podklasa nie jest szczególnym przypadkiem nadklasy

Transformacja modelu logicznego do modelu fizycznego

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

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ę