Wykład 3

Bazy danych 2
Wykład 3
Metodologia projektowania baz danych
(projektowanie fizyczne)
Projektowanie fizyczne
- przegląd krok po kroku
1.
2.
Wybór systemu zarządzania bazą danych (BDMS)
WyraŜenie logicznego modelu danych w docelowym BDMS
a) Zaprojektowanie relacji w systemie
b) Zaprojektowanie danych pochodnych
c) Zaprojektowanie więzów ogólnych
3. Projektowanie reprezentacji fizycznej
a) Analiza transakcji
b) Wybór optymalnej reprezentacji plików
c) Utworzenie indeksów
d) Oszacowanie wymaganej pamięci dyskowej
4. Projektowanie perspektyw uŜytkowników
5. Projektowanie mechanizmów ochrony bezpieczeństwa
Wybór BDMS
Projektant powinien wiedzieć:
1. Jak utworzyć relacje bazowe
2. Czy system umoŜliwia definiowanie kluczy głównych, obcych i
alternatywnych
3. Czy system umoŜliwia definiowanie warunku „wymagana
obecność danych”
4. Czy system umoŜliwia definiowanie dziedzin
5. Czy system wspiera więzy integralności referencyjnej
6. Czy system umoŜliwia definiowanie więzów ogólnych
Projektowanie relacji
Do opisu relacji uŜywamy rozszerzonej wersji DBDL
Domain
Domain
Domain
Domain
Domain
Domain
NumerNieruchomości
Ulica
Miasto
TypNieruchomości
NieruchomośćPokoje
NieruchomośćCzynsz
Domain NumerWłaściciela
Domain NumerPracownika
Domain NumerBiura
łańcuch o zmiennej długości, maks. dł 5
łańcuch o zmiennej długości, maks. dł 25
łańcuch o zmiennej długości, maks. dł 25
jeden znak, wartość ze zbioru ‘B’, ‘C’, ‘F’
liczba całkowita, z przedziału 1-15
wartość walutowa, z przedziału 0,00999,99
łańcuch o zmiennej długości, maks. dł 5
łańcuch o zmiennej długości, maks. dł 5
łańcuch o stałej długości, dł 4
Nieruchomość(
nieruchomośćNr
NumerNieruchomości
NOT NULL
ulica
Ulica
NOT NULL
miasto
Miasto
NOT NULL
typ
TypNieruchomości
NOT NULL DEFAULT ‘F’
pokoje
NieruchomośćPokoje
NOT NULL DEFAULT 4
czynsz
NieruchomośćCzynsz
NOT NULL DEFAULT 600
właścicielNr
NumerWłaściciela
NOT NULL
pracownikNr
NumerPracownika
NOT NULL
biuroNr
NumerBiura
NOT NULL
kaucja
NieruchomośćCzynsz
NOT NULL
PRIMARY KEY (nieruchomośćNr)
ALTERNATE KEY (ulica, miasto)
FOREIGN KEY (pracownikNr) REFERENCES Personel(pracownikNr) ON
UPDATE CASCADE ON DELETE SET NULL
FOREIGN KEY (właścicielNr) REFERENCES WłaścicielPrywatny(właścicielNr)
and WłaścicielInstytucjonalny(właścicielNr) ON UPDATE
CASCADE ON DELETE NO ACTION
DERIVED kaucja
(czynsz*0,1)
Projektowanie relacji
Sposób implementacji relacji bazowych jest uzaleŜniony od
moŜliwości oferowanych przez docelowy DBMS
Projekt relacji powinien być w pełni udokumentowany wraz
z informacjami o przyczynach wyboru konkretnych
rozwiązań
Projektowanie danych pochodnych
Z punktu widzenia fizycznego projektu bazy danych wybór
między reprezentacją atrybutu pochodnego w bazie danych a
jego wyliczaniem przy kaŜdym odwołaniu do niego jest
zawsze kompromisem pomiędzy róŜnymi celami.
NaleŜy oszacować:
Koszt związany z przechowywaniem danych pochodnych
w bazie i zapewnieniem ich zgodności z danymi, na
podstawie których są wyznaczane;
Koszt wyliczenia wartości atrybutów pochodnych przy
kaŜdym odwołanie do nich
Ostateczny wybór powinien słuŜyć zapewnieniu maksymalnej
wydajności systemu.
Projektowanie danych pochodnych
(przykład)
Projektowanie więzów ogólnych
Sposób zaprojektowania więzów ogólnych jest zaleŜny od DBMS.
Zakres wbudowanych w DBMS funkcji, które umoŜliwiają
definiowanie więzów ogólnych, jest bardzo zróŜnicowany.
Niektóre systemy umoŜliwiają zapewnienie więzów za pomocą
standardowych poleceń SQL, w innych konieczne jest
zastosowanie wyzwalaczy wymuszających spełnienie określonych
więzów.
W standardzie SQL moŜemy realizować więzy ogólne za pomocą
klauzuli CHECK
WyróŜnia się dwa sposoby stosowania ograniczenia CHECK
Ograniczenie na poziomie kolumny – ograniczenie to dotyczy
tylko i wyłącznie danej kolumny
Ograniczenie na poziomie tabeli – ograniczenie dotyczące
kilku kolumn tabeli
Projektowanie więzów ogólnych
Przykłady ograniczenie na poziomie kolumny
CREATE TABLE products
( product_no integer,
name text,
price numeric CHECK (price > 0) );
Ograniczeniom moŜna nadawać nazwy, ułatwia to odwoływanie do nich
CREATE TABLE products
( product_no integer,
name text,
price numeric CONSTRAINT positive_price CHECK (price > 0) );
Projektowanie więzów ogólnych
Przykłady ograniczenie na poziomie tabel
CREATE TABLE products
( product_no integer,
name text,
price numeric CHECK (price > 0),
discounted_price numeric,
CHECK (discounted_price > 0),
CONSTRAINT valid_discount CHECK (price > discounted_price) );
Standard SQL dopuszcza tworzenie podzapytań w klauzuli CHECK
CHECK (NOT EXISTS (SELECT pracownikNr
FROM Nieruchomość
GROUP BY pracownikNr
HAVING COUNT(*)>100))
Projektowanie reprezentacji fizycznej
CEL: wybór sposobu reprezentacji relacji i krotek w
pamięci zewnętrznej
Na ocenę wydajności systemu wpływa szereg czynników:
Przepustowość transakcyjna – określa liczbę transakcji, które
mogą zostać przetworzone w ustalonej jednostce czasu
Czas reakcji – jest to czas potrzebny na realizację jednej
transakcji
Zapotrzebowanie na pamięć zewnętrzna – parametr ten określa
rozmiar pamięci zewnętrznej zajmowanej przez pliki bazy danych
Analiza transakcji
CEL: Zrozumienie sposobu działania transakcji występujących w
projekcie oraz analiza najwaŜniejszych z nich
Pytania:
Które transakcje są często wykonywane i mają istotny wpływ
na wydajność systemu
Które transakcje są kluczowe dla działania instytucji
W jakich godzinach/dniach tygodnia występuje szczyt odwołań
do bazy danych
Informacje te wykorzystujemy do ustalenia, w których
komponentach bazy danych mogą występować problemy
obniŜające wydajność systemu
Na podstawie tych danych wybierzemy organizację plików i
indeksów
Analiza transakcji (przykład)
Analiza transakcji (przykład)
Analiza transakcji (przykład)
Analiza transakcji
Po przeanalizowaniu istotnych transakcji, analizujemy dokładniej kaŜdą z
nich – musimy ustalić
• Relacje i atrybuty do których odwołuje się transakcja oraz typ odwołania
•Dla transakcji modyfikującej naleŜy ustalić modyfikowane atrybuty –
te atrybuty nie powinny występować w strukturach dostępu do danych
(indeksach)
• Wszystkie atrybuty wykorzystywane w predykatach (w SQL warunki
umieszczone w klauzuli WHERE)
•Atrybuty te naleŜy traktować jako kandydatów do umieszczenia w
strukturach ułatwiających dostęp do danych
Analiza transakcji
Dla zapytań, atrybuty występujące w złączeniu dwóch lub większej liczby
relacji
Te atrybuty równieŜ mogą być kandydatami do umieszczenia w
strukturach ułatwiających dostęp do danych
Przewidywana częstotliwość wykonywania transakcji
Wymagania dotyczące sposobu wykonania transakcji
Atrybuty wykorzystywane w jakichkolwiek predykatach krytycznych
lub w predykatach bardzo często wykonywanych transakcji powinny
mieć większy priorytet przy wyborze elementów struktur
ułatwiających dostęp do danych
Wybór reprezentacji plików
Celem tego kroku jest wybór optymalnej organizacji
plików dla kaŜdej relacji, o ile umoŜliwia to docelowy
DBMS.
WyróŜnia się kilka róŜnych metod organizacji plików:
Sterty
Pliki haszowane
B+ - drzewa
klastry
JeŜeli system nie umoŜliwia wyboru organizacji plików, to krok
ten moŜna pominąć.
Wybór indeksów
Definicja: Indeks jest to struktura danych umoŜliwiająca szybszy
dostęp do konkretnych rekordów w pliku, a tym samym
przyspieszenie realizacji zapytań.
Indeks w bazie pełni podobną rolę jak skorowidz (indeks) w
ksiąŜce. Jest on strukturą pomocniczą, stowarzyszoną z
sekwencyjnym plikiem danych, w którym poszukiwanymi
elementami są rekordy lub grupy rekordów.
Indeks jest złoŜony z rekordów - kaŜda jego pozycja zawiera
jedną z wartości klucza wyszukiwania oraz jeden lub więcej
adresów (numerów rekordów) pod którymi moŜna znaleźć
poszukiwaną wartość.
Indeks jest posortowany według pola indeksującego,
odpowiadającego kluczowi wyszukiwania (jeden lub więcej
atrybutów)
Wybór indeksów
Do głównych typów indeksów nalezą:
Indeks główny – plik danych jest uporządkowany według pola
porządkującego, które jest kluczem relacji; pole indeksujące
jest równe polu porządkującemu relacji, jego wartości w
poszczególnych rekordach są unikalne
Indeks grupujący – plik danych jest uporządkowany według
pola nie będącego kluczem relacji, które jest teŜ polem
indeksującym; jednej wartości pola indeksującego moŜe
odpowiadać więcej niŜ jeden rekord; wykorzystane w tym
indeksie pole nazywa się atrybutem grupującym
Indeks pomocniczy – indeks zdefiniowany na podstawie pola,
które nie jest uŜywane przy wyznaczaniu porządku rekordów
w bazie
Wybór indeksów
Wskazówki dotyczące tworzenia „listy poŜądanych indeksów”
NaleŜy utworzyć indeks dla klucza głównego (jeśli nie robi tego
DBMS)
Jeśli często występują odwołania do klucza obcego, warto
utworzyć dla niego indeks (jeśli nie robi tego DBMS).
NaleŜy utworzyć indeks pomocniczy dla kolumn, które nie są
kluczami głównymi ani kluczami obcymi, ale mogą być uŜywane
w złoŜonych powiązaniach
NaleŜy utworzyć indeksy pomocnicze dla atrybutów intensywnie
wykorzystywanych w:
Kryteriach selekcji
ORDER BY
GROUP BY
Innych operacjach wymagających sortowania
Wybór indeksów
Wskazówki dotyczące tworzenia „listy poŜądanych indeksów”
Nie naleŜy indeksować małych relacji
NaleŜy unikać indeksowania często modyfikowanego atrybutu
bądź relacji
Nie jest wskazane indeksowanie atrybutu słuŜącego realizacji
zapytań, których wynikiem jest istotna frakcja krotek w relacji
(>25%)
NaleŜy unikać indeksowania atrybutów składających się z
długich łańcuchów
Wybór indeksów
Z utrzymywaniem i uŜywaniem indeksów wiąŜe się dodatkowy
koszt, na który składa się m.in.:
Koszt dodania nowego rekordu indeksowego do kaŜdego
indeksu pomocniczego przy kaŜdym dodaniu krotki do relacji;
Koszt modyfikacji indeksów pomocniczych wynikający z
odpowiednich modyfikacji krotek w relacji;
Wzrost rozmiaru pamięci dyskowej;
MoŜliwość obniŜenia wydajności na etapie optymalizacji
zapytań, będąca wynikiem rozwaŜania przez optymalizator
uŜycia kaŜdego z indeksów
Przy dodawaniu indeksów pomocniczych naleŜy rozwaŜyć, czy ten
dodatkowy koszt zostanie zrekompensowany poprzez uzyskaną
dzięki indeksowi poprawę wydajności.
Wybór indeksów
Indeksy tworzymy w SQL za pomocą polecenia
CREATE [ UNIQUE ] INDEX name ON table [ USING method ]
(column1 [ASC|DESC], column2 [ASC|DESC|,……..)
gdzie
name – nazwa indeksu
table – nazwa tabeli
method – nazwa metody organizacji pliku indeksu,
Column1, column2, .. – nazwy kolumn tabeli, tworzą
klucz indeksu; powinny być wymienione w kolejności od
najbardziej do najmniej znaczących
ASC|DESC – porządek kolumny rosnący|malejący
Wybór indeksów
Przykład
CREATE TABLE test2 ( major int, minor int, name varchar );
Utworzymy indeks dla kolumn major i minor
CREATE INDEX test2_mm_idx ON test2 (major, minor);
Oszacowanie rozmiaru pamięci dyskowej
Podstawą szacowania są informacje:
o rozmiarze krotki
liczbie krotek w relacji
NaleŜy oszacować maksymalny rozmiar danych w bieŜących
warunkach
NaleŜy uwzględnić moŜliwość rozrostu bazy danych
Projektowanie perspektyw uŜytkowników
Perspektywa jest relacja wirtualną, która nie musi istnieć
fizycznie w bazie danych, ale moŜe być wyliczona w kaŜdej
chwili na Ŝądanie uŜytkownika.
Czasami perspektywy mogą być przechowywane w bazie
danych w postaci tabeli tymczasowej tworzonej w momencie
pierwszego odwołania do perspektywy
RozróŜniamy róŜne typy perspektyw
Perspektywa pozioma – ogranicza dostęp do wybranych
wierszy jednej lub wielu tabel
Perspektywa pionowa – ogranicza dostęp do wybranych
kolumn jednej lub wielu tabel
Perspektywy oparte na grupowaniu
Projektowanie perspektyw uŜytkowników
Zalety perspektyw
NiezaleŜność danych – perspektywa moŜe reprezentować
spójny i niezmienny obraz struktury bazy danych pomimo zmian
dokonywanych w tabelach bazowych (pomimo dodawania i
usuwania kolumn, zmiany związków, dzielenia tablic, zmiany ich
struktury i nazwy)
Poprawa bezpieczeństwa – kaŜdy uŜytkownik moŜe otrzymać
uprawnienia do bazy danych poprzez niewielki zbiór perspektyw,
które zawierają potrzebne mu dane
Uproszczenie zapytań
Wygoda – uŜytkownik widzi tylko tyle ile potrzebuje
Dostosowanie do uŜytkownika
Projektowanie perspektyw uŜytkowników
Wady perspektyw
Ograniczona moŜliwość modyfikacji – pewnych danych nie
moŜna modyfikować poprzez perspektywy
Ograniczenia struktury – jeśli tworzona była perspektywa ze
wszystkich kolumn tabeli i dodaliśmy nowe kolumny, to nie będą
one występowały w perspektywie
Wydajność – korzystanie z perspektyw moŜe spowodowac
spadek wydajności
Projektowanie mechanizmów ochrony
bezpieczeństwa
Zakres mechanizmów ochrony bezpieczeństwa oferowanych
przez systemy zarządzania bazą danych jest zróŜnicowany
Relacyjne DBMS zasadniczo dostarczają dwa poziomy
ochrony bezpieczeństwa
ochronę systemu – stanowią mechanizmy kontroli dostępu i
uŜytkowania bazy danych na poziomie systemu, takie jak
nazwy uŜytkowników i hasła
ochronę danych – stanowią mechanizmy dostępu i
uŜytkowania obiektów bazy danych (relacji i perspektyw) do
których uŜytkownicy są uprawnieni