Pracownik

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ę
Regon
Nazw
Pracownik
DataUr
Firma
Nazwa
Kapitał
Diagramy Chena
Osoba
Pesel
Tytuł
Nazwa
Imię
Płeć
Drugie
Imię
Encje mogą być proste lub złożone
Nazwisko
DataUr
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
Firma
Nazwa
Kapitał
Diagramy Chena – związki
Związek określamy pomiędzy zbiorami encji.
• Funkcyjny (1-n)
1
n
Firma
Oddział
ma
• Wieloznaczny (n-m)
Pracownik
n
ud
m
Firma
• Jednoznaczny (1-1)
Kraj
1
1
ma
Stolica
Diagramy Chena – atrybuty związku
• Związek może mieć atrybuty
Samochód
n
1
ma
dataZak
n
Firma
Osoba
cena
m
Ud
dataZat
Osoba
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
podległość
OSOBA
jest przełożonym
Diagramy Chena – związki
hierarchiczne
PRACOWNIK
isa
ZESPÓŁ
kieruje
Data
MANAGER
Premia
Większy przykład
OSOBA
isa
isa
poprzedza
1..*
STUDENT
PRACOWNIK
0..1
następstwo
KURS
1
*
isa
następuje_po
zapisany
zawiera
PROFESOR
1
1..*
1..*
WYKŁAD
*
prowadzi
Podsumowanie procesu tworzenia
modelu konceptualnego
1.
2.
3.
4.
5.
6.
określ zbiory encji;
określ związki pomiędzy zbiorami encji i ich rodzaj;
określ atrybuty encji i związków (uwaga na atrybuty
redundantne);
wyznacz dziedziny atrybutów i ich ograniczenia;
wyznacz klucze kandydujące i wybierz klucze
główne;
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
Asystent
Osoba
Osoba
Pracownik
Pracownik
Adiunkt
Docent
Profesor
Asystent
Adiunkt
Docent
generalizacja
specjalizacja
Dziedziczenie pozwala na tworzenie drzewa klas.
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
*
Prawo dostępu
dostęp
dostępny
dla
{ dostęp oznacza:
*
Użytkownik
czytanie lub
czytanie-pisanie}
Osoba
nazwisko
szef
pesel
kieruje 0..1 adres
*
pracownik
Ocena wydajności
ocena
zatrudnia
1..*
0..1
Zatrudnienie
zarobek
stanowisko
Firma
nazwa
adres
Kiedy stosować atrybuty asocjacji?
Zalecane jest, by przypisywać do klasy
tylko te atrybuty, które są dla tej klasy
stabilne.
Osoba
nazwisko
pesel
adres
Osoba
Forma
nie
zalecana,
mniej
elastyczna:
np.
po
zmianie
powiązania na wiele-do-wielu trzeba
zmieniać położenie atrybutów.
nazwisko
pesel
adres
zarobek
stanowisko
pracuje_w
1..*
0..1
Firma
nazwa
adres
Zatrudnienie
zarobek
stanowisko
pracuje_w
1..*
Firma
0..1
nazwa
adres
Przykładowy diagram klas
Osoba
poprzedza
zapisany_na
Student
1..*
Pracownik
0..1
Kurs
*
1
zawiera
Profesor
prowadzi
następuje_po
1..* 1..*
Wykład
*
1
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.)
pracuje_w
Pracownik
Nazwisko 1..*
1
Firma
Nazwa
Pracownik
IdPrac
Nazwisko
IdFirmy
Firma
IdFirmy
Nazwa
Dla liczności m:n należy zaimplementować jako trzy tabele.
Pracownik pracuje_w
Nazwisko
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.
A
A B C dyskr
B
C
A
Użycie oddzielnych tabel dla
każdej klasy konkretnej.
Usunięcie klas abstrakcyjnych i
przesunięcie ich
atrybutów/powiązań do klas
konkretnych.
AB
B
C
A
Użycie tabel dla każdej klasy.
Zamiana dziedziczenia na
powiązania łączące nadklasę ze
wszystkimi podklasami.
AC
A
0..1
B
C
B
0..1
C
Przykład obejścia braku dziedziczenia
PIT
Kwota do zwrotu
Należny podatek
Podstawa opodatkowania
Rok
PIT pojedyncz podatnika
Adres
dodatkowy
atrybut
dyskryminator
PIT małżeństwa
Adres męża
Adres żony
PIT
Kwota do zwrotu
Należny podatek
Podstawa opodatkowania
Rok
Adres
Adres męża
Adres żony
Rodzaj PIT
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
PIT
Kwota do zwrotu
Należny podatek
Podstawa opodatkowania
Rok
PIT pojedyncz podatnika
Adres
PIT małżeństwa
Adres męża
Adres żony
Zalety i wady każdej z trzech metod
Cecha
Jedna tabela
Tabela dla klasy Tabela dla
dla hierarchii konkretnej
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
Mała
Mała
Duża
Przejście na model relacyjny; przykłady (1)
Klient
NazwaKlienta
ma
InfoDostawy
AdresDostawy
KlientDostawa (IdKlienta, NazwaKlienta, AdresDostawy)
Klient
NazwaKlienta
posiada
KartaKredytowa
IdKarty
0..1
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)
0..1 Mężczyzna
0..1
Kobieta
NazwiskoKobiety
NazwiskoMężczyzny
Ślub
DataŚlubu
Kobieta( IdKobiety, NazwiskoKobiety )
Mężczyzna( IdMężczyzny, NazwiskoMężczyzny )
Ślub( IdKobiety, IdMężczyzny, DataŚlubu )
1..*
Student
Nazwisko_Studenta
Suma_Pkt_Studenta
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
1..*
NazwaMiasta
LiczbaMieszkM
leży_w
Województwo
NazwaWojewództwa
Wojewoda
LiczbaMieszkW
Miasto(NazwaMiasta, NazwaWojewództwa, LiczbaMieszkM)
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)
Pracownik
jest_przełożonym
NazwiskoPrac
DataUrodzPrac
jest_podwładnym
podległość
M:N
Pracownik (IdPracownika, NazwiskoPrac, DataUrodzPrac)
Podległość (IdPracPrzełoż, IdPracPodwład)
1:N
Pracownik (IdPracownika, NazwiskoPrac, DataUrodzPrac, IdPracPodwład)
1:1
Pracownik(IdPracownika, NazwiskoPrac, DataUrodzPrac, IdPracPrzełoż)
Przejście na model relacyjny; przykłady (5)
Towar
Nazwa_Towaru
Sprzedawca
Nazwa_Sprzedawcy
Klient
Nazwa_Klienta
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ę