Wprowadzenie do baz danych
Literatura
M. Muraszkiewicz, H. Rybiński: Bazy danych. Warszawa, 1993. J. D. Ullman: Systemy baz danych. WNT, Warszawa 1988.
Pojęcie bazy danych
Czym jest baza danych
pamięć trwała danych (persistant data)
określona struktura i reguły integralności
Cele użytkowania b.d.
niezawodność zapisu
integralność danych
sprawność zapytań
wygodne interfejsy
wielodostęp
zabezpieczenia dostępu
System zarządzania bazą danych (DBMS)
izoluje programy od reprezentacji fizycznej
słownik danych
język opisu danych
extended dictionary
mechanizmy dostępu:
język zapytań i manipulacji danymi
optymalizacja dostępu
mechanizmy ochrony:
autoryzacja dostępu
ochrona spójności
mechanizmy do odtwarzania po awarii
wielodostęp i dostęp przez sieć
zarządzanie transakcjami
klient-serwer
mechanizmy dla rozproszonych b.d.
narzędzia do budowy interfejsów:
narzędzia do zapytań interakcyjnych
dostęp z języków 3GL
specjalizowane narzędzia 4GL
Przykładowe zastosowania baz danych
systemy finansowo-księgowe
systemy rezerwacji (np. lotniczej)
systemy wspomagające zarządzanie
CAD (Computer Aided Design)
GIS (Geographical Information Systems)
Składniki działającego systemu b.d.
struktura danych
reguły integralności
dane
aplikacja:
formularze
raporty
programy przetwarzające
zapytania ad-hoc
Języki dostępu
budowa:
proceduralne
nieproceduralne
typ dostępu:
nawigacyjne (rekord bieżący)
zwracające struktury (np. tabele)
Alternatywy dla b.d.
systemy plikowe (flat files):
sekwencyjne (SAM)
indeksowo-sekwencyjne (ISAM)
z dostępem bezpośrednim
język Cobol
Modele baz danych
Podział zadań w projektowaniu b.d.
użytkownik -- odbiorca systemu
analityk
projektant
programista
administrator b.d. (DBA)
Model zewnętrzny
opisuje ¶wiat z punktu widzenia użytkowników b.d.
może istnieć wiele modeli zewnętrznych tej samej rzeczywistości
nie musi być związany z konkretnym modelem danych
Model pojęciowy (konceptualny)
tworzony przez analityków
opisuje świat w kategoriach konkretnego modelu danych
abstrahuje od szczegółów implementacji
odpowiada na pytanie "co?" a nie "jak?"
Model logiczny
tworzony przez projektantów b.d.
opisuje projekt struktury w kontekście konkretnej implementacji
model struktury zgodny z modelem danych, a nie z ich fizyczną reprezentacją
może zawierać parametry dotyczące reprezentacji fizycznej, np.:
partycjonowania danych
alokacji pamięci
Reprezentacja fizyczna
tworzona przez SZBD
izolowana od aplikacji przez SZBD
zarządzana przez administratora
Modele danych
Model hierarchiczny
Cechy podstawowe
struktura danych ma postać drzewa
węzły -- typy opisywanych obiektów
łuki -- związki typu ojciec-syn
drzewo jest uporządkowane, tj. na każdym poziomie kolejność węzłów jest określona
opis obiektu (rekord) zbudowany z pól zawierających dane opisujące obiekt
związki zrealizowane jako wskaźniki
Przykład
Hierarchiczna struktura danych
Języki obsługi
o charakterze nawigacyjnym
operacje typu:
GET LEFTMOST typ WHERE warunek
GET NEXT typ
Ograniczenia
nie ma związków typu n-m (np. oddziały pomieszane w kilku budynkach)
tylko jeden rodzaj związku między dwoma typami obiektów
dodatkowe związki
(np. pracownik-budynek):
dodatkowe drzewa hierarchii
odsyłacze do rekordów "oryginału"
Znaczenie praktyczne
system IBM IMS (1978)
bardzo wielkie dane zgromadzone
poprzednik użyty w programie Apollo
nowych projektów nie robi się
Model sieciowy
Cechy podstawowe
struktura danych ma postać grafu (sieci)
wierzchołki grafu -- typy obiektów
łuki w grafie -- wiązania między typami
opis obiektu (rekord) zbudowany z pól zawierających dane opisujące obiekt
reprezentacja wiązań (wskaĽniki):
odesłanie bezpo¶rednie (jednowart.)
odesłanie inwersyjne (wielowart.)
wiązanie codasylowe
Realizacja wiązań -- model DBTG CODASYL
rekordy powiązane stanowią kolekcję (set)
jeden rekord nadrzędny
wiele rekordów podrzędnych
kolekcja realizowana jako lista zamknięta
brak bezpo¶redniej reprezentacji
wiązań n-m
Języki obsługi
języki manipulowania -- nawigacyjne
CODASYL: język definiowania danych pozwala określić sposób automatycznego włączania rekordów do kolekcji
Przykłady
Więzy i ich realizacja w CODASYL
Sposób realizacji wiązania m-n
Znaczenie praktyczne
system IDS (General Electric)
obecnie raczej nie używany
Model relacyjny
Cechy podstawowe
dane zawarte w tabelach
tabele składają się z kolumn
liczba kolumn i typy -- stałe
liczba wierszy zmienna
wiersze nie mają tożsamości innej niż wynikająca z zawartości kolumn
związki pomiędzy wierszami tabel -- zdefiniowane poprzez zależności między wartościami wybranych kolumn, tzw. kluczy (nie ma wskaźników)
z punktu widzenia teorii model można opisać algebrą relacji między zbiorami atrybutów
Języki obsługi
nieproceduralne: SQL, Sequel, QUEL, QBE
proceduralne: xBase
Znaczenie praktyczne
model dominujący w zastosowaniach komercyjnych
przykłady SZBD: Oracle, Informix, Sybase, Ingres, DB2, Progress, Gupta, Access, dBase, Paradox
Przykład
Przykładowy schemat danych -- związek 1-n
# Id * Nazwa * Id
departamentu oddziału
... ... ...
# Id * Nazwisko * o Stanowisko * Id
pracownika Imię departamentu
... ... ... ... ...
Realizacja relacyjna
Ograniczenia
brak bezpośredniej reprezentacji
związków n-m
dla trudniejszych problemów
-- bardzo wiele tabel
mało naturalna reprezentacja danych
ograniczona podatność na zmiany
trudne operowanie na złożonych obiektach -- dane rozproszone w wielu tabelach
brak złożonych typów danych
model mało wygodny dla zastosowań
CAD, GIS itp.
Model obiektowy (object-oriented)
Cechy podstawowe
obiekt w bazie reprezentuje obiekt w świecie zewnętrznym
typ obiektowy (klasa):
definicja złożonego typu danych (może zawierać inne typy obiektowe lub ich kolekcje)
procedury (metody) i operatory do manipulowania tymi danymi
tożsamość obiektu jest niezależna od zawartości danych
dziedziczenie (inheritance):
strukturalne: potomek dziedziczy strukturę danych
behawioralne: potomek dziedziczy metody i operatory
Cechy dodatkowe
enkapsulacja: wnętrze obiektu dostępne jedynie w sposób w nim zdefiniowany
polimorfizm: tak samo nazwane metody i operatory działają swoiście w zależności od klasy obiektu
Przykład
Model obiektowy -- zawieranie i dziedziczenie
Zalety modelu
dość naturalna reprezentacja świata
łatwość działania na złożonych obiektach
duża podatno¶ć na zmiany
Znaczenie praktyczne
w zastosowaniach naukowych lub eksperymentalnych
przykłady systemów: GemStone, O2
przewidywana ewolucja baz relacyjnych w kierunku obiektowo-relacyjnych
Relacyjne bazy danych
Literatura
C. Delobel, M Adiba: Relacyjne bazy danych. WNT, Warszawa 1989. M. Muraszkiewicz, H. Rybiński: Bazy danych. AOW, 1993. W. Harris: Bazy danych nie tylko dla ludzi biznesu. WNT, 1994. K. Subieta: Ingres. AOW PLJ, 1994. Wellesley Software: SQL. Język relacyjnych baz danych. WNT. M. Gruber: SQL. Helion, 1996. Ulka Rodgers: Oracle. Przewodnik projektanta baz danych. WNT, 1995. J. Gnybek: Oracle łatwiejszy niż przypuszczasz. Helion, 1996. R. Barker: CASE*Method. Modelowanie związków encji. WNT, 1996.
Podstawy teoretyczne modelu relacyjnego
Pojęcie relacji
rozważamy model pojęciowy
cechy rzeczywistości opisane są w atrybutach
schemat relacji to zbiór nazw atrybutów:
warto¶ci atrybutów należą do dziedzin:
relacja na schemacie S to podzbiór iloczynu kartezjańskiego dziedzin atrybutów:
relacja jest zbiorem krotek:
zbiór krotek może być reprezentowany jako tabela:
kolumny odpowiadają nazwom atrybutów
wiersze odpowiadają krotkom
Relacyjna baza danych
schemat relacyjnej bazy danych jest zbiorem schematów relacji
relacyjna baza danych jest zbiorem relacji spełniających warunki integralności dla każdej relacji i między relacjami
Klucze
klucz relacji K = zbiór atrybutów, które jednoznacznie wyznaczają krotkę:
gdzie ki[K] oznacza podkrotkę zawierającą tylko atrybuty z klucza K
klasyfikacja kluczy:
klucze wła¶ciwe: żaden podzbiór wła¶ciwy klucza wła¶ciwego nie jest kluczem
klucz główny: jeden z kluczy wła¶ciwych relacji, wybrany do identyfikowania krotek
klucze wykrywa się analizując opisywany ¶wiat, a nie dostępne dane!
przykład:
id pracownika jest kluczem
nazwisko nie jest kluczem
nazwisko + imię + data urodzenia + imię ojca -- jest kluczem
Operacje na relacjach
Selekcja
selekcja = wybór krotek (wierszy):
gdzie w jest warunkiem selekcji
selekcja jest komutatywna:
Projekcja (rzut)
projekcja = wybór atrybutów (kolumn):
gdzie S' jest podzbiorem schematu S
projekcja jest wzajemnie komutatywna z selekcją:
o ile warunek selekcji ma sens po projekcji, tj. dotyczy tylko atrybutów wybranych w projekcji
Operacje teoriomnogo¶ciowe
dotyczą relacji opartych na identycznych schematach:
suma
iloczyn
różnica
Złączenie
operacja na dwóch relacjach -- podzbiór iloczynu kartezjańskiego dwóch relacji:
gdzie w jest warunkiem złączenia
krotki złączenia stanowią sklejenie (konkatenację) krotek relacji złączanych
rodzaje złączeń:
równo¶ciowe -- warunek równo¶ciowy
naturalne -- równo¶ciowe i nazwy atrybutów zgodne
Rachunki relacji
algebra relacji -- oparta na w/w operacjach
rachunek predykatów -- okre¶la się schemat relacji wynikowej i kwalifikatory (predykaty) okre¶lające warunki
rachunek krotek
rachunek dziedzin
algebra relacji prowadzi do języków proceduralnych
rachunek predykatów prowadzi do języków deklaratywnych
Zależno¶ci semantyczne w relacyjnej bazie danych
Ograniczenia integralno¶ci
¶wiat rzeczywisty opisują tylko te z możliwych relacji, które spełniają zależno¶ci semantyczne istniejące w modelowanym ¶wiecie
zależno¶ci w b.d. modeluje się jako tzw. ograniczenia integralno¶ci (integrity constraints)
zależno¶ci semantyczne wykrywa się analizując opisywany ¶wiat, a nie dostępne dane!
Rodzaje zależno¶ci
ograniczenia dotyczące atrybutu
obowiązkowo¶ć
ograniczenia warto¶ci
ograniczenia dotyczące jednej relacji
funkcyjne (functional dependency)
wielowarto¶ciowe (multivalued )
zależno¶ci między relacjami
referencyjne -- zgodno¶ć warto¶ci wybranych atrybutów
Zależno¶ci funkcyjne
zbiór atrybutów Y jest zależny funkcyjnie od zbioru X gdy z każdą konfiguracją warto¶ci atrybutów z X jest związana co najwyżej jedna konfiguracja warto¶ci z Y:
przykład:
imię zależy funkcyjnie od id pracownika
id nie zależy funkcyjnie od imienia
imię nie zależy funkcyjnie od nazwiska
aksjomaty Armstronga -- pozwalają znaleĽć nowe zależno¶ci funkcyjne na podst. już znalezionych:
-- zwrotno¶ć
-- rozszerzenie
-- przechodnio¶ć
każdy atrybut i cały schemat zależą funkcyjnie od klucza
zależno¶ć tranzytywna A od X:
Zależno¶ci wielowarto¶ciowe
zbiór atrybutów Y jest zależny wielowarto¶ciowo od zbioru X gdy z każdą konfiguracją warto¶ci atrybutów z X jest związany zbiór konfiguracji warto¶ci z Y niezależnie od warto¶ci pozostałych atrybutów:
gdzie
(znaczy to, że można wymienić czę¶ci krotek: X i Y z k1 i resztę z k2)
najważniejsze własno¶ci:
relacja RS daje się rozłożyć w sposób odwracalny na dwie: RXY i RXZ
istnieje odpowiednik aksjomatów Armstronga dla zależno¶ci wielowarto¶ciowych
przykład:
podręczniki nie zależą od wykładowców
nie ma zależno¶ci funkcyjnych
zachodzą zależno¶ci
i
(zawsze para!)
można zamienić czę¶ci krotek ZP i W
można rozłożyć na: ZW, ZP
Zajęcia Wykładowca Podręcznik
Normalizacja
Redundancja
redundancja polega na powtarzaniu
wady redundancji:
anomalie
konieczno¶ć utrzymania spójno¶ci kopii
marnowanie miejsca
Anomalie
rodzaje:
istnienia
wstawiania
usuwania
modyfikacji
przykład:
Imię Nazwisko Nr depart. Nazwa
depart.
Rozkład relacji i normalizacja
redundancję usuwa się przez rozkład relacji
rozkład odwracalny: można odwrócić przez naturalne złączenie
rozkład relacji powinien doprowadzić do tzw. postaci normalnej
rozkład relacji nie powinien powodować utraty zależno¶ci istniejących w relacji pierwotnej
Pierwsza postać normalna
relacja jest w 1NF gdy wszystkie atrybuty są atomowe -- prostych typów
1NF jest wymogiem dla rachunku relacyjnego, a więc i języków zapytań
kontrprzykłady:
atrybut tablicowy
zbiór
Uwaga: Dalej będzie mowa jedynie o relacjach spełniających 1NF
Druga postać normalna
relacja jest w 2NF gdy każdy atrybut niekluczowy (nie należący do klucza wła¶ciwego) jest zależny funkcyjnie od całego klucza wła¶ciwego
przyczyną braku 2NF jest zwykle błędne połączenie danych
kontrprzykład: spis przepustek
nazwisko zależy funkcyjnie od id prac., czyli od fragmentu klucza
rozkład IB, IN doprowadza do 2NF
# Id prac. # Budynek Nazwisko
Trzecia postać normalna
relacja jest w 3NF gdy
jest w 1 NF i
każdy atrybut niekluczowy jest bezpo¶rednio zależny funkcyjnie od całego klucza wła¶ciwego
możliwe przypadki naruszenia 3NF:
naruszenie 2NF
istnienie zależno¶ci tranzytywnej (a więc niebezpo¶redniej) od klucza wła¶ciwego
przyczyną braku 3NF jest zwykle błędne połączenie danych
3NF jest zazwyczaj wystarczająca dla usunięcia praktycznie ważnych anomalii
każdy schemat można doprowadzić do 3NF zachowując:
zależno¶ci
odwracalno¶ć rozkładu
kontrprzykład
jest 2NF, bo klucz jest jednoatrybutowy
zależno¶ć tranzytywna: I S P
(pensja zależy funkcyjnie od stanowiska)
rozkład INS, IP doprowadza do 3NF
# Id Nazwisko Stanowisko Pensja
prac.
Postać normalna Boyce-Codda
relacja jest w BCNF gdy każda nietrywialna zależno¶ć funkcyjna jest zależno¶cią od klucza (niekoniecznie wła¶ciwego)
w BCNF zależno¶ci tranzytywne nie istnieją w ogóle
nie każdy schemat można doprowadzić do BCNF z zachowaniem zależno¶ci
kontrprzykład: relacja w 3NF z anomaliami:
istnieją tu klucze: MU, UK
(nazwy ulic mogą się powtarzać w różnych miastach, zakładamy że nazwy miast się nie powtarzają)
występują zależno¶ci:
anomalie: usuwając ulicę możemy utracić informację o mie¶cie
schemat jest w 3NF: brak atrybutów niekluczowych
schemat nie jest w BCNF: K nie jest kluczem
schemat jest nierozkładalny do BCNF bez utraty zależno¶ci
Miasto Ulica Kod
najczę¶ciej zależno¶ci prowadzące do braku BCNF nie są istotne z punktu widzenia projektu
Czwarta postać normalna
relacja jest w 4NF gdy je¶li każda nietrywialna zależno¶ć wielowarto¶ciowa jest zależno¶cią od klucza (niekoniecznie wła¶ciwego)
schemat doprowadza się do 4NF przez rozkład
kontrprzykład:
istnieją zależno¶ci
i
nie ma zależno¶ci funkcyjnych
jest więc BCNF
występuje nadmiar informacji: powtórzone dane podręczników i wykładowców
rozkład ZW, ZP doprowadza do 4NF
Zajęcia Wykładowca Podręcznik
Związki między postaciami normalnymi
4NF => BCNF => 3NF => 2NF => 1NF
Projektowanie schematów relacyjnych
Model pojęciowy
Cele modelowania pojęciowego
precyzyjne okre¶lenie zakresu projektu
modelowanie informacji:
niezbędnej dla działania organizacji
niezależnie od implementacji
wg okre¶lonego modelu danych
Diagramy związków encji (ERD)
elementy:
encje
atrybuty encji
związki
unikalne identyfikatory
ważne są konwencje!
Przykład diagramu ERD
Encje
model rzeczy, osób itp.:
o których chcemy przechowywać informacje
które mają tożsamo¶ć
nazwa: rzeczownik w l.poj., wielkie litery
Przykłady:
produkt (towar), przedmiot
osoba, pracownik, klient
dokument, pozycja dokumentu
Atrybuty
okre¶lają cechy rzeczy, osób itp.:
identyfikują
opisują
podają ilo¶ci
klasyfikują
są prostego (atomowego) typu
muszą mieć precyzyjne nazwy
Przykłady:
kod towaru, nazwa
nr identyfikacyjny, imię, nazwisko, adres
cena, warto¶ć, rodzaj płatno¶ci
Rodzaje atrybutów
obowiązkowe (*)
opcjonalne (o)
Związki
pokazują zależności między encjami
powinny być obustronnie nazwane
nie zapisuje się sposobu realizacji
Cechy związków
opcjonalność:
obowiązkowy
opcjonalny
stopień:
jeden (1)
wiele (n)
transferowalno¶ć
związki rekurencyjne
Poprawność związków
związki 1-1 są podejrzane
związki obustronnie obowiązkowe są podejrzane
związki rekurencyjne muszą być obustronnie opcjonalne
związki n-m powinny zostać rozbite:
Związek n-m i jego rozbicie
Identyfikacja encji
Unikalne identyfikatory
każda encja powinna posiadać przynajmniej jeden unikalny identyfikator
możliwe składniki:
atrybuty
związki
atrybuty i związki
pierwotny UID:
identyfikuje wszystkie wystąpienia encji
wszystkie składniki obowiązkowe
przykład: numer id pracownika
wtórne UID:
do celów kontrolnych
składniki mogą być opcjonalne
przykłady: PESEL, nazwisko+imię+data urodzenia+imię ojca
Pożądane cechy pierwotnego UID
niezmienno¶ć
łatwo¶ć wyznaczenia warto¶ci
czytelno¶ć
niewielka złożono¶ć
Przykłady
UID faktury: atrybuty
UID pozycji: związek + atrybut (sequence in parent)
UID lokalizacji: tylko związki
Typowe konstrukcje
Master - detail
typowa struktura dokumentu:
nagłówek
pozycje
związek obowiązkowy po stronie detail
UID detalu: związek + atrybut (najczę¶ciej sequence in parent)
Struktura master - detail: faktura-pozycja
Klasyfikacja: faktura-płatno¶ć
Słownik: pozycja-towar
Słowniki
stosuje się by uniknąć powtarzania danych
przykłady: spis klientów, spis towarów
Klasyfikacja
encję dla klasyfikacji stosuje się, gdy:
klasyfikacja ma być ograniczona
słownik klasyfikacji ma być zmienny
przykłady: rodzaje płatno¶ci, grupy towarów, kolory
kontrprzykłady: dni tygodnia, płeć
¦ledzenie zmienno¶ci
do ¶ledzenia zmienno¶ci atrybutu tworzy się dodatkową encję
nie należy używać konstrukcji z atrybutami: warto¶ć1, warto¶ć2, warto¶ć3,...
Zapis zmian stanowiska pracownika
Związki wykluczające się
zapisuje się za pomocą konwencji "łuku"
łuk może być:
obowiązkowy: jeden związek zachodzi
opcjonalny: zachodzi jeden lub żaden
Związki wykluczające się (łuk obowiązkowy)
Drzewo
stosowane np. do opisu hierarchii
modelowane jako związek rekurencyjny obustronnie opcjonalny
Związek rekurencyjny -- hierarchia
Graf
stosowany np. do opisu struktur materiałowych: składnik--produkt
może być reprezentowany przez związek rekurencyjny n-m
reprezentacja ostateczna:
węzły -- encja "pierwotna"
łuki -- dodatkowa encja
dwa związki 1-n
Reprezentacje grafu materiałów:
w postaci związku rekurencyjnego n-m
i w postaci dwóch encji
Lista
nie stosuje się wskaĽników
pozycje listy oznacza się numerami kolejnymi
Projekt logiczny
Cele projektowania logicznego
zaprojektowanie:
struktur danych
ograniczeń integralno¶ci
obudowy proceduralnej (wyzwalacze)
perspektyw
rozwiązań dla przetwarzania rozproszonego
bierze się pod uwagę konkretny SZRBD
Przekształcenie modeli pojęciowy logiczny
encje tabele
nazwy tabel -- w liczbie mnogiej
usuwamy znaki narodowe z nazw obiektów b.d.
atrybuty kolumny
typy z SZRBD
obowiązkowo¶ć więzy not null
pierwotne UID klucze główne
wtórne UID ograniczenia unikalno¶ci
związki klucze obce:
kolumny
ograniczenia
obowiązkowo¶ć klucz not null
nietransferowalno¶ć klucz niezmienny
Ograniczenia integralno¶ci
Ograniczenia deklaratywne i proceduralne
deklaratywne:
wykonywane przez serwer b.d.
dotyczą wszystkich operacji
dotyczą wszystkich wierszy (statyczne)
wykonanie bezbłędne i zoptymalizowane
proceduralne:
wykonywane przez serwer (dotyczą wszystkich operacji) lub aplikację (dotyczą tylko operacji tej aplikacji)
dotyczą tylko zmienianych danych (dynamiczne)
kod może zawierać błędy
należy dążyć do ograniczeń:
deklaratywnych
po stronie serwera b.d.
Rodzaje ograniczeń deklaratywnych
kolumny: not null, check (in-line)
wiersza: check
tabeli: primary key, unique
referencyjne: foreign key
Wyzwalacze (triggers)
procedury rezydujące w serwerze b.d.
automatycznie wyzwalane przez:
wstawienie wiersza
usunięcie wiersza
modyfikację okre¶lonych kolumn
służą do:
wymuszania nietypowych reguł integralno¶ci (bussiness rules)
nietypowych zabezpieczeń dostępu
¶ledzenia zmian w b.d. (audit)
wymuszania integralno¶ci referencyjnej w rozproszonych b.d.
nietypowej replikacji danych
Klucze
Klucz główny (primary key)
funkcja: jednoznaczne identyfikowanie wiersza tabeli
budowa:
ogr. deklaratywne primary key
dla UID z atrybutów -- odpowiednie kolumny
dla UID zawierającego związki -- kolumny odpowiednich kluczy obcych
wszystkie kolumny klucza głównego muszą być obowiązkowe (not null)
pożądane cechy:
niezmienno¶ć
mała długo¶ć (wydajno¶ć!)
sztuczne klucze główne:
klucz numeryczny
mechanizm do generowania unikalnych numerów (tzw. sekwencja)
z kluczem głównym jest z reguły związany indeks unikalny
Klucze obce
funkcja: realizują związki
budowa:
dodatkowe kolumny klucza obcego odpowiadające kolumnom wskazywanego klucza głównego
ogr. deklaratywne foreign key
sposób obsługi kasowania/modyfikacji wskazywanego klucza głównego:
restrykcja
kaskada
reprezentacja łuku:
dwa osobne klucze obce opcjonalne
dodatkowy warunek wykluczania (ograniczenia check lub wyzwalacz)
należy rozważyć zdefiniowanie indeksu dla klucza obcego
Realizacja więzów: klucz obcy
Etapy projektowania logicznego
Kolejno¶ć czynno¶ci
przekształcenie modelu pojęciowego
poprawki (np. usunięcie znaków narodowych i spacji z nazw)
denormalizacja
uzupełnianie modelu logicznego:
indeksy
wyzwalacze
perspektywy
projektowanie rozproszone
projektowanie fizyczne (przestrzenie tabel, parametry alokacji, klastry itp.)
implementacja (kod DDL)
czynno¶ći pomocnicze
szacowanie rozmiaru b.d.
opracowanie strategii administrowania
(np. kopie zapasowe)
Perspektywy
zapamiętane w b.d. definicje zapytań
stanowią "widok" na tabele
można ich używać tak jak tabel
(niektóre są tylko read-only!)
zastosowanie:
ułatwienie powtarzających się zapytań
zabezpieczenie dostępu
Indeksy
służą do szybkiego wyszukiwania i sortowania danych
budowa:
oparte na kolumnie lub złożeniu kolumn (tzw. kluczu indeksowania)
wewnątrz zwykle B-drzewo
(drzewo zrównoważone)
wykorzystanie:
indeks pozwala wyszukiwać według początku klucza indeksowania
indeks unikalny (unique) zapewnia niepowtarzalno¶ć klucza indeksowania
przykład:
CREATE INDEX prc_i ON pracownicy (nazwisko,imie,data_urodzenia);
przyspiesza wyszukanie wg: nazwiska, nazwiska+imienia, nazwiska+imienia_daty
nie przyspiesza wyszukiwania wg: imienia+nazwiska, imienia, daty itp.
okoliczno¶ci stosowania:
dane używane często do wyszukań i złączeń, o dobrej selektywno¶ci
klucze obce
klucze unikalne
Denormalizacja
stosuje się dla znaczącego poprawienia wydajno¶ci
elementy:
wprowadzenie redundantnych danych
wprowadzenie kodu zapewniającego spójno¶ć
Typowe przypadki denormalizacji:
przechowywanie agregatów (sumy, ¶rednie):
Przechowywanie agregatów: ostatni stan
pre-join:
Pre-join: kopia nazwy klienta
po¶redni klucz obcy:
Po¶redni klucz obcy: pracownicy-oddziały
nie każdy przypadek przechowywania wyników obliczeń jest denormalizacją!
Implementacja modelu logicznego
instalacja SZRBD i utworzenie bazy danych
tworzenie struktur danych:
elementy projektu przekształca się w odpowiednie zdania DDL (Data Definition Language), umieszczane w skryptach
tworzy się schemat użytkownika-wła¶ciciela obiektów struktury
uruchamia się skrypty tworzące strukturę
tworzy się konta użytkowników i nadaje się im uprawnienia dostępu
tworzy się synonimy
wykonuje się kopię rezerwową (backup)
wprowadza się dane (np. przez import)
opracowanie i wdrożenie strategii wykonywania kopii rezerwowych
opracowanie i uruchomienie aplikacji
strojenie:
aplikacji
bazy danych