Relacyjne Bazy Danych wykład V

1opr. Lech Banachowski, Jan Wierzbicki

Relacyjne Bazy Danychwykład V


Jakość schematu bazy danych

Pożądane cechy modelu danych

Następujące cechy modelu danych trzeba zapewnić na samym

początku procesu projektowania, pozostając w ścisłym kontakcie

z użytkownikami: •poprawność modelu - to co jest w modelu jest zgodne z

rzeczywistością; •istotność każdego elementu modelu dla funkcjonowania firmy

(organizacji); •pełność modelu - gwarancja, że żaden element modelu danych -

istotny dla funkcjonowania firmy (organizacji), nie został

pominięty.


Po skonstruowaniu modelu danych:

•użytkownicy powinni rozumieć utworzony model danych i po

dokładnym przeanalizowaniu wszystkich szczegółów, biorąc za

to odpowiedzialność, zatwierdzić go; •projektant bazy danych traktuje uzgodniony z użytkownikami

model danych jako wierne odzwierciedlenie rzeczywistości i dla

tego modelu buduje bazę danych i aplikację bazy danych.


NormalizacjaPostulat normalizacji daje się wyrazić w następujący sposób:

Każdy fakt przechowywany w bazie danych powinien być wyrażalny w niej tylko na jeden sposób.•Informacja o przedmiocie powinna być zapisana tylko w jednym

miejscu, a nie przy każdym studencie, który uczęszcza na zajęcia

z tego przedmiotu. •Jeśli w bazie danych zapisujemy informację o rodzicach każdej

osoby, nie ma już potrzeby zapisywać informacji o dziadkach,

gdyż ta informacja daje się wyprowadzić z informacji o

rodzicach.


•Jeśli w modelu firmy lotniczej Pasażer i Pracownik to dwie

odrębne encje, to jedna osoba może figurować w bazie danych -

raz jako pasażer, a raz jako pracownik firmy lotniczej. Wówczas

dane dotyczące takiej osoby (np. adres zamieszkania) będą

zapisane w dwóch różnych miejscach.


Dlaczego niektóre schematy tabel są złe?Problem złych schematów tabel zaprezentujemy na dwóch

przykładach. Klucz główny tabel będzie zaznaczany pogrubioną

czcionką.

Przykład 1

Dostawcy = {Nazwa_dostawcy, Adres, Nazwa_towaru,

Cena}


Nazwa_dostawcy Adres Nazwa_towaru

Cena

Kowalski Wiolinowa 7 Telewizor 1500

Kowalski Wiolinowa 7 Radio 500

Jaworski Mozarta 5 Telewizor 1800

Jaworski Mozarta 5 Komputer 5000

Kowalski Wiolinowa 7 Baterie 5

MarciniakWarszawska 140

Magnetowid 1000


Oto zestaw wad łatwych do zidentyfikowania w przedstawiony

schemacie.

1. Redundancja: adres dostawcy powtarza się dla każdego

dostarczanego towaru.

2. Anomalie przy modyfikacji: uaktualniony adres w jednym

wierszu pozostaje niezmieniony w innych.

3. Anomalie przy wstawianiu: trudno wstawić dostawcę bez

towarów; towar wchodzi w skład klucza - nie może być NULL.

4. Anomalie przy usuwaniu: usuwając informacje o wszystkich

towarach dostarczanych przez dostawcę (który może zmienić

profil produkcji) usuwamy informację o samym dostawcy


Przyczyna: złączenie w jednej encji dwóch różnych rodzajów

obiektów (encji):

•Dostawcy = {Nazwa_dostawcy, Adres} •Towary = {Nazwa_dostawcy, Nazwa_towaru, Cena}

Poprawienie schematu polega na rozbiciu początkowego schematu

na dwie tabele każda reprezentująca osobny typ obiektów czyli

odpowiednio dostawców i towary.


Przykład 2 Pracownicy = {Id_prac, Nazwisko, Nazwa_uczelni, Adres}

Id_prac

Nazwisko Nazwa_uczelni Adres

101 Kowalski PJWSTK Koszykowa 86

123 Kalinowski WSI Zamiany 15

109 Jaworski WSI Zamiany 15

102 Makowski PJWSTK Koszykowa 86

105 Rudziak WSI Zamiany 15


Znowu możemy zaobserwować podobne wady jak poprzednio

mimo, że tym razem klucz główny jest jednoelementowy.

1. Redundancja: adres uczelni powtarza się dla każdego

zatrudnionego w niej pracownika.

2. Anomalie przy modyfikacji: uaktualniony adres uczelni w

jednym wierszu pozostaje niezmieniony w innych.

3. Anomalie przy wstawianiu: trudno wstawić uczelnię bez

pracownika; Id_prac stanowi klucz i nie może być NULL.

4. Anomalie przy usuwaniu: usuwając wszystkich pracowników

usuwamy uczelnię.


Przyczyna: złączenie w jednej encji dwóch różnych rodzajów

obiektów (encji):

•Pracownicy = {Id_prac, Nazwisko, Nazwa_uczelni} •Uczelnie = {Nazwa_uczelni, Adres}

Poprawienie schematu polega na rozbiciu początkowego

schematu na dwie tabele każda reprezentująca osobny typ

obiektów czyli odpowiednio pracowników i uczelnie.


Dany jest schemat Przychodnia = {Pacjent, Choroba, Lekarz, Karta, Wpis, Adres}. Zachodzą następujące reguły:

1. Każdy pacjent ma kartę.2. Na każdej karcie jest zapisany adres. 3. Na karcie znajdują się wpisy.4. Wpis na karcie dotyczy choroby.5. Wpis na karcie jest dokonywany przez lekarza.


Wyjaśnienie złych schematów za pomocą pojęć zależności

częściowych i przechodnich między atrybutami tabeli

(1) Dla schematu tabeli

Dostawcy = {Nazwa_dostawcy, Adres, Nazwa_towaru,

Cena}•kluczem jest para atrybutów: Nazwa_dostawcy i

Nazwa_towaru, •Adres zależy od części klucza mianowicie od atrybutu

Nazwa_dostawcy.


Mówimy, że wartość atrybutu Adres zależy częściowo od klucza:

Nazwa_dostawcy -> Adresa samą zależność nazywamy zależnością częściową. Po

przeniesieniu atrybutów: Nazwa_dostawcy i Adres do osobnej

encji, atrybut Nazwa_dostawcy staje się kluczem a zależność

częściowa "Nazwa_dostawcy -> Adres" staje się zależnością od

całego klucza.


(2) Dla schematu tabeli:

Pracownicy = {Id_prac, Nazwisko, Nazwa_uczelni, Adres}•kluczem jest atrybut Id_prac, •Adres zależy od innego atrybutu Nazwa_uczelni, który nie jest

kluczem.

Mówimy w takim przypadku, że wartość atrybutu Adres zależy

przechodnio od klucza:

Nazwa_uczelni -> Adresa samą zależność nazywamy zależnością przechodnią. Po

przeniesieniu atrybutów: Nazwa_uczelni i Adres do osobnej encji,

atrybut Nazwa_uczelni staje się kluczem a zależność częściowa

"Nazwa_uczelni-> Adres" staje się zależnością od całego klucza.


Reasumując, istnienie zależności częściowych i przechodnich wskazuje, że schemat tabel ma niepoprawne właściwości. Poprawne są tylko zależności funkcyjne od całego klucza.


Formalny model relacyjnych baz danych•Relacja jest abstrakcyjnym, matematycznym pojęciem

zawierającym w sobie istotę modelu relacyjnego. Relacyjna baza

danych to zbiór relacji. •Tabela jest konkretną reprezentacją relacji – jedna relacja ma

wiele różnych reprezentacji za pomocą tabel. •W relacji kolejność wierszy i kolejność kolumn są nieistotne. •Dwa wiersze w tabeli zawierające te same wartości są uznawane

za identyczne to znaczy za ten sam element relacji.


Przykład relacji - Loty

Numer

Skąd Dokąd Odlot Przylot

83 Warszawa Moskwa 11:30 13:43

84 Moskwa Warszawa 15:00 17:55

109 Warszawa Nowy Jork 09:50 16:52

213 Warszawa Frankfurt 11:43 12:45

214 Frankfurt Warszawa 14:20 15:29

115 Nowy Jork Warszawa 18:12 07:10

515 Nowy Jork Frankfurt 22:00 09:15

516 Frankfurt Nowy Jork 13:20 19:15

711 Warszawa Tokio 18:00 09:10


Moglibyśmy zmienić kolejność wierszy w tabeli. Moglibyśmy

zmienić kolejność kolumn w tej tabeli. I nie miałoby to

znaczenia dla relacji będącej zawartością obu tabel. Będzie to

ciągle ta sama relacja.

Schematem relacji nazywamy listę

R = {A1, A2, ...., An} gdzie A1, A2, ...., An są atrybutami

(nazwami kolumn).

Na przykład,

Loty = {Numer, Skąd, Dokąd, Odlot, Przylot}

Pracownik = {Idprac, Imie, Nazwisko, Iddept, Zarobki,

Stanowisko}

Departament = {Iddept, Nazwa, Miejsce}


Dziedzina atrybutu

Każdemu atrybutowi A przyporządkowana jest dziedzina

oznaczana przez Dom(A) - zbiór dopuszczalnych wartości. Np.

Dom(Numer) = NUMBER(3)

Dom(Skąd) = CHAR(15)

Dom(Dokąd) = CHAR(15)

Dom(Odlot) = CHAR(5)

Dom(Przylot) = CHAR(5)


Dziedzina relacji

Dziedziną relacji o schemacie R = {A1, A2,..., An} nazywamy sumę

dziedzin wszystkich atrybutów relacji

Dom(R) = Dom(A1) + Dom(A2) + .. + Dom(An)

gdzie + oznacza tutaj operację sumowania zbiorów.

Definicja relacjiRelacją o schemacie R = {A1, A2,..., An} nazywamy skończony

zbiór r = {t1, t2,...,tm} odwzorowań

ti: R -> Dom(R)

takich, że dla każdego j, 1 <= j <= n,

ti(Aj) należy do dziedziny Dom(Aj)

Każde takie odwzorowanie t nazywa się krotką (lub wierszem).


Przykład krotki (elementu relacji)

Krotka odpowiada wierszowi (rekordowi) w tabeli. Można ją

formalnie określić przez podanie wartości dla poszczególnych

atrybutów np.

t(Numer) = 83, t(Skąd) = "Warszawa", t(Dokąd) = "Moskwa",

t(Odlot) = "11:30", t(Przylot) = "13:43"

Graficznie:

Numer Skąd DokądOdlot

Przylot

83Warszawa

Moskwa

11:30 13:43


Operacja ograniczenia krotki

Ograniczeniem krotki t relacji r o schemacie R do zbioru

atrybutów X z R nazywamy odwzorowanie będące ograniczeniem

t do zbioru atrybutów X

t|X: X -> Dom(R)

to znaczy t|X(x)=t(x) dla x w X a dla x w R-X wartość t|X(x) jest

nieokreślona.

Na przykład, gdy

X = {Skąd, Dokąd},

to dla krotki t z poprzedniego przykładu

t|X (Skąd)="Warszawa", t|X (Dokąd) = "Moskwa"

Graficznie: Skąd Dokąd

Warszawa Moskwa


Zależność funkcyjna

Relacja r o schemacie R = {A1, A2,..., An} spełnia zależność

funkcyjną

X -> Y (X, Y - podzbiory R)

jeśli dla każdych dwóch krotek t, u relacji r zachodzi warunek:

jeśli t|X = u|X to t|Y = u|Y

tzn. w ramach krotek relacji r wartości atrybutów zbioru X

determinują jednoznacznie wartości atrybutów zbioru Y.

W przykładowej relacji Loty, wartości atrybutu Numer

jednoznacznie identyfikują cały lot a więc w szczególności

jednoznacznie identyfikują wartości wszystkich atrybutów tej

relacji:

Numer -> {Skąd, Dokąd, Odlot, Przylot}


Przykład relacji z zależnościami funkcyjnymi między jej

atrybutami mianowicie relację Znaki Zodiaku o schemacie

{Id, Imię, Nazwisko, DzienUrodzenia, ZnakZodiaku}

Id

Imię Nazwisko DzienUrodzenia ZnakZodiaku

1 Agnieszka Kowalska 23.01 Wodnik

2 Mariusz Malewicz 1.04 Baran

3 Krzysztof Zalewski 23.04 Byk

4 Ilona Zawadzka 13.04 Baran5 Marek Walicki 31.07 Lew6 Roman Gerlich 5.09 Panna7 Sylwia Frymus 13.04 Baran


Mamy do czynienia z zależnością funkcyjną

DzieńUrodzenia -> ZnakZodiakuto znaczy, temu samemu dniu urodzenia odpowiada zawsze ten

sam znak zodiaku.

W rzeczywistości mamy tutaj do czynienia z czymś więcej,

mianowicie ze znaną funkcją f: DzieńUrodzenia -> ZnakZodiaku

przyporządkowującą dniu urodzenia znak zodiaku. Jednak ta

funkcja nie daje się wyrazić za pomocą funkcyjnej zależności w

sensie podanej powyżej definicji.


Identyfikacja zależności funkcyjnych

W procesie projektowania dla każdego schematu relacji

identyfikujemy zbiór spełniających ją zależności funkcyjnych

(zależny od konkretnego zastosowania).

Na przykład dla relacji Loty identyfikujemy następujący zbiór

zależności funkcyjnych między jej atrybutami:

Numer -> {Skąd, Dokąd, Odlot, Przylot} {Skąd, Dokąd, Odlot} -> {Numer, Przylot} {Skąd, Dokąd, Przylot} -> {Numer, Odlot}Uwaga: często jest stosowana skrócona forma zapisu polegająca

na opuszczaniu przecinków i nawiasów klamrowych:

Numer -> Skąd Dokąd Odlot Przylot Skąd Dokąd Odlot -> Numer Przylot


Nadklucz relacji

Nadkluczem relacji r o schemacie R = {A1, A2,..., An} nazywamy

dowolny zbiór atrybutów X z R taki, że zachodzi zależność

funkcyjna X -> R

- inaczej mówiąc, wartość każdego atrybutu ma być

jednoznacznie zdeterminowana przez wartości atrybutów zbioru

X. Jednym z nadkluczy jest zawsze zbiór wszystkich atrybutów R.


Klucz relacjiKluczem relacji r o schemacie R = {A1, A2,..., An} nazywamy każdy minimalny nadklucz (nie zawierający w sobie żadnego innego nadklucza),tzn. zbiór atrybutów X jest kluczem jeśli wartość każdego atrybutu w R jest jednoznacznie zdeterminowana przez wartości atrybutów zbioru X i żaden podzbiór zbioru X nie ma już tej własności. Zawsze istnieje co najmniej jeden nadklucz - całe R, stąd wynika, że istnieje co najmniej jeden minimalny nadlucz czyli klucz a może być kluczy więcej jak to pokazuje przykład relacji Loty. Zależności funkcyjne schematu Loty określają trzy klucze: {Numer} {Skąd, Dokąd, Odlot} {Skąd, Dokąd, Przylot}


Klucze i klucz główny

Wyróżniony klucz nazywa się kluczem głównym. Wchodzące w

jego skład atrybuty są podkreślane lub pogrubiane.

Dla relacji Loty wybieramy jako klucz główny klucz Numer:

Loty = {Numer, Skąd, Dokąd, Odlot, Przylot}

Dany jest schemat Przychodnia = {Pacjent, Choroba, Lekarz, Karta, Wpis, Adres}. Zachodzą następujące reguły:1. Każdy pacjent ma kartę.2. Na każdej karcie jest zapisany adres.3. Na karcie znajdują się wpisy.4. Wpis na karcie dotyczy choroby.5. Wpis na karcie jest dokonywany przez lekarza.


Dla schematu identyfikujemy następujące zależności funkcyjne:

1. Pacjent -> Karta

2. Karta -> Adres

3. Wpis -> Karta

4. Wpis -> Choroba

5. Wpis -> Lekarz

Jedynym kluczem jest para atrybutów: Pacjent i Wpis.


Znaczenie zależności funkcyjnych

Zależność od czegokolwiek innego niż klucz wprowadza

wewnętrzną zależność między atrybutami tabeli. Powoduje

możliwość determinowania wartości jednych atrybutów przez

inne (redundancję). Pokazuje to tabelka dla zależności X-> Y:

X ... Y...

x ... y ... x ... ? ...

...Jeśli X nie jest nadkluczem, to przedstawiona w tabelce sytuacja oznacza redundancję. Wartość w polu oznaczonym przez "?" jest już jednoznacznie zdeterminowana – musi to być y. Natomiast gdy X jest nadkluczem, to przedstawiona sytuacja jest niemożliwa. Nie mogą być dwa różne wiersze z tą samą wartością klucza.


"Złe" zależności funkcyjne - zależności nie od klucza

Zależność funkcyjna X -> Y jest zależnością od klucza jeśli

zbiór atrybutów X jest nadkluczem.

Zależność funkcyjna X -> Y jest zależnością nie od klucza jeśli

1. jest nietrywialna tzn. zbiór Y nie jest podzbiorem X,

2. nie jest zależnością od klucza.


Są dwa typy zależności nie od klucza:

1. częściowe - od części klucza,

2. przechodnie - od czegokolwiek nieporównywalnego z

kluczem.

W schematach Dostawcy i Pracownicy występują zależności nie

od klucza, odpowiednio:

• Nazwa_dostawcy -> Adres_dostawcy

(zależność częściowa)• Uczelnia -> Adres

(zależność przechodnia)


Dany jest schemat Przychodnia = {Pacjent, Choroba, Lekarz, Karta, Wpis, Adres}. Dla tego schematu zidentyfikowaliśmy następujące zależności funkcyjne:

1. Pacjent -> Karta 2. Karta -> Adres 3. Wpis -> Karta 4. Wpis -> Choroba 5. Wpis -> Lekarz Jedynym kluczem jest para atrybutów:

Pacjent i Wpis.


Zależności funkcyjne:

1. Pacjent -> Karta

2. Wpis -> Karta

3. Wpis -> Choroba

4. Wpis -> Lekarz

są zależnościami częściowymi (zależnościami od części klucza).

Natomiast zależność

Karta -> Adres jest zależnością przechodnią (od klucza).


Metoda eliminowania „złych” zależności polega na

wprowadzeniu dla zależności (częściowej lub przechodniej)

osobnej tabeli i usunięciu atrybutu stojącego po prawej stronie tej

zależności z oryginalnego schematu.

(1) Dla schematu dostawców dodajemy schemat tabeli

{Nazwa_dostawcy, Adres} i usuwamy z oryginalnego

schematu atrybut Adres: {Nazwa_dostawcy, Nazwa_towaru, Cena}.


2) Dla schematu pracowników dodajemy schemat tabeli

{Nazwa_uczelni, Adres} i usuwamy z oryginalnego

schematu atrybut Adres: {Id_prac, Nazwisko, Nazwa_uczelni}.


Najlepiej, aby każda zależność funkcyjna określała pojedyńczy schemat tabeli.

{Pacjent, Karta}

{Karta, Adres}

{Wpis, Karta, Choroba, Lekarz}


Postać normalna Boyce’a-Codda Relacja o schemacie R znajduje się w postaci normalnej Boyce'a-

Codda jeśli nie zawiera zależności nie od klucza tj. dla każdej

zależności X -> A w schemacie relacji R (gdzie X podzbiór R, A

atrybut w R) zachodzi albo

1. A należy do X (zależność trywialna), albo

2. X jest nadkluczem.

Jeśli schemat relacji znajduje się w postaci normalnej Boyce'a-

Codda, nie można w tabeli przewidzieć jednych wartości w

oparciu o inne, chociaż jak to będzie pokazane dalej nie mamy

gwarancji, że nie będzie innego rodzaju redundancji niż zależność

funkcyjna.


Przykłady schematów w postaci normalnej Boyce'a-Codda:

(1) R = {Id_prac, Nazwisko, Funkcja, Stanowisko}, F: Id_prac -> Nazwisko Funkcja Stanowisko (2) R = {Numer, Skąd, Dokąd, Odlot, Przylot}

F: Numer -> Skąd Dokąd Odlot Przylot Skąd Dokąd Odlot -> Numer Przylot Skąd Dokąd Przylot -> Numer Odlot


Schemat nie dający się sprowadzić do postaci normalnej Boyce’a-

Codda

Nie każdy schemat tabeli da się sprowadzić do zbioru schematów

tabel w postaci normalnej Boyce’a-Codda - bez utraty zawartych

w tabelach informacji i z zachowaniem zależności funcyjnych. Na

przykład schematem takim jest MUK = {Miasto, Ulica, Kod} z

zależnościami:

{Miasto, Ulica} -> Kod Kod -> MiastoSą dwa klucze: •{Miasto, Ulica} •{Kod, Ulica}


Ze względu na zależność Kod -> Miasto schemat MUK nie

jest w postaci normalnej Boyce'a-Codda. Tego schematu nie

daje się rozłożyć z zachowaniem zależności funkcyjnych (bo

jedna z zależności funkcyjnych obejmuje wszystkie atrybuty).

Atrybut kluczowy jest to atrybut wchodzący w skład jednego z

kluczy tabeli.


Trzecia postać normalnaRelacja o schemacie R znajduje się w trzeciej postaci normalnej

jeśli wszystkie zależności nie od klucza są między atrybutami

kluczowymi, tj. dla każdej zależności X -> A w schemacie relacji R

(gdzie X podzbiór R, A atrybut w R) zachodzi albo

1. A należy do X (zależność trywialna), albo

2. X jest nadkluczem, albo

3. A jest atrybutem kluczowym.


W trzeciej postaci normalnej wykluczony jest więc przypadek zależności: X -> Agdzie A jest atrybutem nie-kluczowym, X nie jest nadkluczem, X nie zawiera A. Takich więc zależności należy poszukiwać w celu przekształcenia schematu relacji według "złej" zależności na dwie relacje. Na przykład zależność funkcyjna "Kod -> Miasto" w schemacie MUK wskazuje, że schemat MUK nie jest w postaci normalnej Boyce’a-Codda ale jest w trzeciej postaci normalnej bo atrybut Miasto jest atrybutem kluczowym – należy do jednego z kluczy {Miasto, Ulica}. Natomiast następujący schemat R, nie jest w trzeciej postaci normalnej. R = {A,B,C,D}, F = AB -> C; B -> D; BC -> AKluczami są AB i BC. Istnieje zależność B -> D a D nie jest atrybutem kluczowym.


Zależności wielowartościowe (czwarta postać normalna)

Nr_stud

PrzedmiotSport

100 Bazy danych Tenis

100 Bazy danych Biegi

100 Systemy informacyjne Tenis

100 Systemy informacyjne Biegi

200 Bazy danych Boks


Schemat relacji jest w postaci normalnej Boyce’a-Codda bo

jedynym kluczem są wszystkie trzy atrybuty) a w tabeli jest

redundancja i możliwe są anomalie!

W relacji R = {Nr_stud, Przedmiot, Sport} mamy do czynienia z tak

zwanymi zależnościami wielowartościowymi:

Nr_stud ->> Przedmiot; Nr_stud ->> SportSchemat relacji jest w czwartej postaci normalnej jeśli nie ma w

nim zależności wielowartościowych. Powyższy schemat R nie jest

więc w czwartej postaci normalnej.

Aby wyeliminować zależności wielowartościowe rozkładamy R na

dwie relacje o schematach:

{Nr_stud, Przedmiot} i {Nr_stud, Sport}.


Zależności złączeniowe (piąta postać normalna)Zależność złączeniowa jest uogólnieniem zależności

wielowartościowej w tym sensie, że jej eliminacja polega na

rozbiciu relacji na więcej niż dwie relacje.

Rozważmy relację między dostawcami, produktami i projektami.

Nazwa_dostawcy Nazwa_produktu Nazwa_projektu

Kowalski Stal WenusKowalski Srebro MarsKowalski Stal MarsJankowski Stal MarsJankowski Papier WenusJankowski Stal WenusMisiak Srebro Neptun


zasadę biznesową:jeśli (1) dostawca X dostarcza produkt Y,(2) dostawca X pracuje dla projektu Z,(3) projekt Z używa produktu Yto(4) dostawca X dostarcza produkt Y dla projektu Z.Przy tych zasadach zapis informacji w tabeli jest redundantny boskoro(1) Kowalski jest dostawcą stali (dostarcza dla projektu Wenus),(2) Kowalski pracuje dla projektu Mars (dostarcza srebro),(3) projekt Mars używa stali (od dostawcy Jankowskiego)to redundantna jest już informacja, że:(4) Kowalski dostarcza stali dla projektu Mars (pokolorowany wiersz w tabelce).


Rozwiązanie problemu eliminacji zależności złączeniowych

Rozwiązaniem problemu jest podział relacji na trzy relacje:

(1) Dostawcy-produkty,

(2) Dostawcy-projekty,

(3) Projekty-produkty.

Podział na tylko dwie relacje jest niewystarczający!

W relacjach (1)-(3) nie ma już redundancji, a ich złączenie daje

wyjściową relację.

Sytuacja uległaby zmianie gdybyśmy chcieli przechowywać

informację o ilości zamówionych produktów w danym projekcie u

konkretnego dostawcy. Wówczas rozbicie na trzy relacje nie byłoby

możliwe.


Granice normalizacjiNormalizacji nie doprowadza się czasem do końca, np:

(1) gdy stosuje się replikacje danych;

(2) gdy funkcje na danych preferują nieznormalizowane

schematy relacji np. gdy przy każdym wypisywaniu informacji o

towarze załączamy także adres dostawcy.

Jeśli tak postępujemy, to musimy się liczyć ze wszystkimi

konsekwencjami pozostawienia nieznormalizowanej tabeli i

dlatego wszystkie zależności nie od klucza muszą być

sprawdzane przy każdej modyfikacji bazy danych i wszystkie

pozostające anomalie muszą mieć przygotowane specjalne

traktowanie (np. przy użyciu dodatkowych tabel do obsługi

anomalii wstawiania i usuwania)


W trakcie pracy nad modelem danych i schematem bazy danych

projektant musi zwracać uwagę na wiele aspektów takich jak

poprawność, istotność, pełność modelu danych, jak również na to

aby schemat bazy danych nie prowadził do redundancji danych

oraz anomalii przy wstawianiu, usuwaniu i aktualizacji danych. Są

przypadki, kiedy dopuszcza się pewien stopień redundancji – ale

jest to wówczas decyzja świadoma, której towarzyszą

zabezpieczenia przed wystąpieniem anomalii przy wykonywaniu

operacji na danych


poprawność modelu danych - to co jest w modelu jest zgodne z rzeczywistością.istotność modelu danych - każdy element modelu jest istotny.pełność modelu danych - żaden element modelu danych - istotny dla funkcjonowania firmy (organizacji), nie został pominięty.normalizacja - każdy fakt przechowywany w bazie danych jest wyrażalny w niej tylko na jeden sposób.anomalie - tracenie informacji, podatność na brak spójności lub nie możliwość wykonania operacji na danych spowodowane złym schematem bazy danych.schemat relacji - lista atrybutów relacji.relacja - matematyczny obiekt (zbiór krotek) będący abstrakcją tabeli w relacyjnej bazie danych.krotka - matematyczny obiekt (odwzorowanie) będący abstrakcją wiersza w relacyjnej bazie danych.


zależność funkcyjna - zależność wartości jednych atrybutów od innych. Oznaczenie X -> Y co czytamy X determinuje Y.nadklucz - zbiór atrybutów, których wartości jednoznacznie determinują wartości pozostałych atrybutów relacji.klucz - minimalny zbiór atrybutów, których wartości jednoznacznie determinują wartości pozostałych atrybutów relacji.zależność częściowa - zależność wartości atrybutu od części klucza.zależność przechodnia - zależność wartości atrybutu od czegokolwiek nieporównywalnego z kluczem.postać normalna Boyce’a-Codda - jedyną nietrywialną zależnością każdego atrybutu jest zależność od nadklucza. Inaczej mówiąc, oznacza brak zależności nie od klucza.postać normalna - trzecia - dopuszczona jest zależność atrybutu od części klucza o ile atrybut jest atrybutem kluczowym (należącym do jednego z kluczy relacji).


Koniec wykładu V

Documents

Relacyjne Bazy Danych wykład V