Kopia BD14

Bazy danych
© Andrzej Łachwa, UJ, 2013 [email protected] www.uj.edu.pl/web/zpgk/materialy
14/15
PYTANIA NA EGZAMIN LICENCJACKI
78. Relacyjny model baz danych.
79. Zależności funkcyjne, klucze i algorytm obliczania domknięć.
W praktyce, w przypadku konkretnej bazy danych, nie jest zwykle możliwe (ani potrzebne), by projektant określił wszystkie zależności funkcyjne na etapie analizy świata danych. Projektant bazy danych określa więc tylko zależności funkcyjne ewidentne z punktu widzenia semantyki modelowanego świata (nazwijmy je pierwotnymi), a następnie oblicza się w sposób zautomatyzowany
te zależności, które wynikają z pierwotnych.
Wprowadza się dwa pojęcia: pojęcie domknięcia F+ zbioru zależności funkcyjnych F oraz pojęcie domknięcia X+ zbioru atrybutów X względem F. Domknięcie F+ to zbiór zależności pierwotnych (tworzących zbiór F) oraz zależności, które można wywniosować z tamtych. Każda taka nowa zależność musi mieć tę własność, że będzie spełniona dla każdego zbioru danych spełniającego zależności ze zbioru F.
Jak zbudować F+?
W 1974 W. Armstrong wykazał, że minimalnym zbiorem reguł wnioskowania potrzebnych do zbudowania domknięcia jest zbiór złożony z reguły zwrotności (R1), reguły zwiększania (R2) i reguły przechodniości (R3). W literaturze są one zwane aksjomatami Armstronga. W praktyce używa się również wtórej reguły: reguły dekompozycji (R4).
Systematyczny sposób budowania domknięcia F+ zbioru zależności funkcyjnych F polega na tym, że dla każdej zależności funkcyjnej X→Y tworzy się X→X+ gdzie X+ to domknięcie zbioru X względem zbioru zalezności F. Wszystkie utworzone w ten sposób zależności X→X+ tworzą domnknięcie F+.
Należy tu pamiętać, że w teorii relacyjnych baz danych litery występujące po prawej i po lewej stronie zależności funkcyjnej mogą oznaczać dowolny atrybut bądź zbiór atrybutów.
Pozostaje pytanie, jak utworzyć domknięcie X+ zbioru X względem
zbioru F?
Algorytm obliczania domknięcia
X+ := X
repeat
old X+:= X+
for each zależność funkcyjna Y→Z w F do
if old X+VY then old X+:= X+UZ;
until (X+ = old X+);
Dwa zbiory zależności funkcyjnych E i F są równoważne jeżeli mają
takie same domknięcia: E+=F+. Od projektanta bazy danych wymagamy zatem, by rozpoznał dowolny zbiór pierwotnych zależności funkcyjnych, ale taki, którego domknięcie obejmie wszystkie zależności funkcyjne. Różni projektanci mogą zaproponować różne zbiory zależności pierwotnych, ale muszą być one w powyższym sensie równoważne. Por. R.Elmasri, str. 330‐337
80. Normalizacja baz danych; warunek bezstratnego złączenia; pierwsza, druga i trzecia postać normalna, postać normalna Boyce’a‐Codda.
Proces normalizacji relacyjnej bazy danych ma na celu usunięcie redundancji i wyeliminowanie anomalii. Polega on na rozkładaniu pojedynczych schematów relacji na mniejsze, które mają odpowiednie właściwości.
Rozkłady te muszą gwarantować możliwość nieaadytywnego złączenia i w zasadzie powinny zachowywać zależności. To pierwsze określa się również jako warunek bezstratnego złączenia.
Polega on na tym, że dla każdej relacji opartej na danym schemacie naturalne złączenie rzutów tej relacji na podschematy jest równe tej relacji (w złączeniu tym nie pojawiają się żadne nowe krotki). Nazwa warunku bierze się stąd, że rozkład niespełniający tego warunku może prowadzić do zmiany zawartości informacyjnej dzielonej w taki sposób relacji, czyli do utraty właściwej informacji.
Rozkłady do 2NF i do 3NF gwarantują możliwość nieaadytywnego złączenia jeżeli są wykonywane według określonych zasad związanych z usuwaniem zależności częściowych i zależności tranzytywnych. W szczególności schemat, który jest w 1NF a nie jest w 2NF, zawiera zależności częściowe. Jego prawidłowy rozkład
polega na utworzeniu podschematów złożonych z atrybutów występujących w zależnościach częściowych oraz podschematu zawierającego klucz i ewentualnie atrybuty nieuwzględnione w utworzonych już podschematach. Schemat, który jest w 2NF ale
nie jest w 3NF, zawiera zależności tranzytywne. Jego prawidłowy rozkład polega na utworzeniu dla każdej zależności tranzytywnej X→Y→Z (nieprymarnych atrybutów Z) podschematu złożonego z atrybutów YZ, a na koniec podschematu złożonego z klucza i atrybutów nieuwzględnionych w utworzonych już podsche‐
matach.
Taki sposób rozkładu spełnia warunek bezstratnego złączenia, a jednocześnie gwarantuje zachowanie wszystkich zależności funkcyjnych.
Rozkłady do wyższych postaci normalnych nie gwarantują zachowania zależności, więc muszą być wykonywane z dużą ostrożnością. 81. Złączenia wewnętrzne i zewnętrzne, algorytmy realizacji złączeń.
Zob. Elmasri: R.15.3‐15.6
82. Transakcje i zasady ACID; poziomy izolacji.
Z transakcjami związane są blokady dostępu i poziomy izolacji.
Transakcja może zakładać blokady na elementy danych, zmieniać swoje blokady i zdejmować swoje blokady. Blokada do odczytu (read lock, shared lock) pozwala na współużytkowanie tego elementu danych przez inne transakcje. Blokada pełna (odczytu i zapisu, na wyłączność, read‐write lock, exclusive lock) nie pozwala
na dostęp do elementu danych innym transakcjom. Transakcja może rozszerzyć blokadę, zawęzić blokadę i znieść blokadę.
Transakcja jest zgodna z protokołem blokowania dwufazowego jeżeli występują dwie fazy. W pierwszej transakcja może zakładać i rozszerzać blokady. W drugiej transkacja może zawężać i znosić blokady, ale nie może już ani rozszerzać ani zakładać nowych blokad. Jeżeli każda transakcja w harmonogramie jest zgodna z opisanym protokołem, to harmonogram jest szeregowalny.
Mechanizm blokad prowadzi do tworzenia kolejek transakcji oczekujących na możliwość założenia blokady, a to może doprowadzić do powstawania zakleszczeń. Musimy więc stosować
różne protokoły zapobiegania zakleszczeniom. Poziom izolacji to ustalona przez programistę cecha transakcji. Poziom ten określa się przy użyciu instrukcji ISOLATION LEVEL <X>, gdzie <X> może przyjąć cztery wartości.
Serializable – to zwykle poziom domyślny. Gwarantuje, że dane odczytywane to dane utworzone wyłącznie przez zatwierdzone transakcje oraz że wartość żadnej danej odczytywanej lub zapisywanej przez daną transakcję nie zostanie zmieniona przez inną transakcję do momentu zakończenia danej transakcji. Innymi słowy system zarządzania transakcjami nie dopuści do odczytów zmodyfikowanych, odczytów niepowtarzalnych i fantomów. Nie jest to dokładnie to samo co szeregowalność!
Repeatable read – możliwe wystąpienie fantomów.
Read Committed – możliwe wystąpienie fantomów i odczytów niepowtarzalnych
Read Uncommitted – możliwe wszystkie naruszenia.
83. Więzy integralności referencyjnej i klucze obce.
84. b‐drzewa – definicja, algorytm wyszukiwania w b‐drzewie. Zob. Elmasri: R.14. Struktury indeksowe dla plików
TABELA POŁĄCZEŃ
Rozważmy typowy przykład związku binarnego wiele do wielu oraz odpowiadającego mu schematu złożonego z 3 tabel.
M
N
CREATE TABLE Chłopcy (ImięCh VARCHAR(30) PRIMARY KEY);
CREATE TABLE Dziewczyny (ImięD VARCHAR(30) PRIMARY KEY);
CREATE TABLE Pary (ImięCh VARCHAR(30), ImięD VARCHAR(30));
Do tabeli Pary możemy wstawić przykładowe wiersze:
(Adam, Anna)
(Adam, Barbara)
(Karol, Barbara)
(Adam, Celina)
(Adam, Anna)
Teraz wprowadzamy więzy integralności. Po pierwsze, nie chcemy dopuszczać wierszy typu (Adam, NULL) czy (NULL, Celina).
CREATE TABLE Pary (
ImięCh VARCHAR(30) NOT NULL,
ImięD VARCHAR(30) NOT NULL); Po drugie, chcemy aby chłopcy i dziewczyny były wybierane z tabel odpowiadającym typom encji Chłopcy i Dziewczyny. Po trzecie, gdybyśmy chcieli poprawić pisownię imienia w którejś z tabel łączonych, to zmiana ta powinna zostać odzwierciedlona w tabeli połączeń.
Po czwarte, gdybyśmy chcieli usunąć z bazy jakąś osobę (encję), to wszystkie pary zawierające imię tej osoby również powinny być usunięte. CREATE TABLE Pary (
ImięCh VARCHAR(30) NOT NULL
REFERENCES Chłopcy (ImięCh)
ON UPDATE CASCADE
ON DELETE CASCADE,
ImięD VARCHAR(30) NOT NULL
REFERENCES Dziewczyny (ImięD)
ON UPDATE CASCADE
ON DELETE CASCADE); Po piąte, chcemy zapobiegać powtarzającym się informacjom (w naszym zestawie danych wiersz 1 i wiersz 5).
CREATE TABLE Pary (
ImięCh VARCHAR(30) NOT NULL
REFERENCES Chłopcy (ImięCh)
ON UPDATE CASCADE
ON DELETE CASCADE,
ImięD VARCHAR(30) NOT NULL
REFERENCES Dziewczyny (ImięD)
ON UPDATE CASCADE
ON DELETE CASCADE,
PRIMARY KEY (ImięCh, ImięD)); Po szóste', chcemy by chłopak mógł być w kilku parach, a każda dziewczyna tylko w jednej!
CREATE TABLE Pary (
ImięCh VARCHAR(30) NOT NULL
REFERENCES Chłopcy (ImięCh)
ON UPDATE CASCADE
ON DELETE CASCADE,
ImięD VARCHAR(30) NOT NULL UNIQUE
REFERENCES Dziewczyny (ImięD)
ON UPDATE CASCADE
ON DELETE CASCADE,
PRIMARY KEY (ImięCh, ImięD)); Po szóste'', chcemy by dziewczyna mogła być w kilku parach, a każda chłopak tylko w jednej! I wreszcie po siódme, ograniczmy się do związków monogamicznych.
CREATE TABLE Pary (
ImięCh VARCHAR(30) NOT NULL UNIQUE
REFERENCES Chłopcy (ImięCh)
ON UPDATE CASCADE
ON DELETE CASCADE,
ImięD VARCHAR(30) NOT NULL UNIQUE
REFERENCES Dziewczyny (ImięD)
ON UPDATE CASCADE
ON DELETE CASCADE,
PRIMARY KEY (ImięCh, ImięD)); Mamy tu tzw. klucze zagnieżdżone i klucz nadmiarowy.
MODELOWANIE HIERARCHII KLAS
W wielu projektach występują klienci‐osoby i klienci‐firmy. Wygodnie jest modelować tę sytuację jako związek klasy KLIENCI z podklasami OSOBY i FIRMY.
CREATE TABLE Klienci (
id CHAR(5) PRIMARY KEY,
typ CHAR(1) NOT NULL CHECK(typ IN('O', 'F')),
staż TINYINT UNSIGNED NOT NULL DEFAULT 0,
obroty DECIMAL(5,2),
…,
UNIQUE (id, typ));
Jakie ograniczenia wprowadzić w podklasach?
CREATE TABLE Osoby (
id CHAR(5) PRIMARY KEY,
typ CHAR(1) DEFAULT 'O' NOT NULL CHECK (typ='O'),
UNIQUE (id, typ)
FOREIGN KEY (id, typ)
REFERENCES Klienci(id, typ)
ON UPDATE CASCADE
ON DELETE CASCADE
…... );
CREATE TABLE Firmy (
id CHAR(5) PRIMARY KEY,
typ CHAR(1) DEFAULT 'F' NOT NULL CHECK(typ='F'),
UNIQUE (id, typ) …....
Teraz można to wszystko ukryć w widokach:
CREATE VIEW NasiKlienci (Id, Staż, Obroty, …)
AS (SELECT Id, Staż, Obroty … FROM Klienci);
CREATE VIEW OsobyFizyczne (Id, Tytuł, Imię, Nazwisko …)
AS (SELECT Id, Tytuł, Imię, Nazwisko … FROM Osoby);
CREATE VIEW OsobyPrawne (Id, Nazwa, FormaPrawna, …)
AS (SELECT Id, Nazwa, FormaPrawna, … FROM Firmy);
ADRES IP W JĘZYKU SQL
VARCHAR(15) NOT NULL CHECK …
'63.246.173.210'
INTEGER
'127.0.0.1' to 2130706433
oktet1 TINYINT UNSIGNED NOT NULL,
oktet2 TINYINT UNSIGNED NOT NULL,
oktet3 TINYINT UNSIGNED NOT NULL,
oktet4 TINYINT UNSIGNED NOT NULL
63
246
173
210