Dodatek B

74
Wprowadzenie do projektowania baz danych
Dodatek B
Schemat opisowy
Nale y zaprojektowa baz danych dla potrzeb biblioteki uczelnianej. Biblioteka
posiada na stanie ksi ki. Ka da ksi ka posiada swój unikalny numer (sygnatur ), jest
opisana poprzez podanie autora i tytułu. Dodatkowo, nale y przypisa ka dej ksi ce
zbiór słów kluczowych, ułatwiaj cych poszukiwanie. Ka de słowo kluczowe posiada
swój unikalny identyfikator oraz nazw . Nale y przechowywa w bazie równie dane
wypo yczaj cych (nazwiska, adresy). Ka dy wypo yczaj cy posiada swój unikalny
numer. Wypo yczaj cym przypisano ró ne kategorie (student, wykładowca). Kategorie
te wyznaczaj termin zwrotu oraz maksymaln liczb ksi ek do wypo yczenia. Baza
powinna zawiera informacje o wypo yczanych ksi kach, z dat wypo yczenia i dat
zwrotu wł cznie.
Projektowanie
Modelowanie wiata rzeczywistego
Bazy danych s komputerowymi reprezentacjami fragmentów istniej cego wiata
rzeczywistego, który jest przedmiotem zainteresowania u ytkowników baz. wiat
modelowany składa si z obiektów i powi za . Obiekt to składnik rzeczywisto ci, który
jest postrzegany jako istotny przez jednostk lub grup , powi zanie to zwi zek co
najmniej dwóch obiektów.
W projekcie “Biblioteka” mo na wyodr bni nast puj ce obiekty i powi zania:
obiekty: Ksi ki, Wypo yczaj cy; powi zania: Wypo yczenie (zwi zek obiektu
Wypo yczaj cy i obiektu Ksi ka). Obiekty oraz powi zania opisywane s przy pomocy
tzw. atrybutów. Jako atrybuty powi zania przyjmuje si identyfikatory ł czonych
obiektów i ewentualne inne atrybuty opisuj ce dane powi zanie.
Ksi ki - IDKs, TytułKsi ki, AutorKsi ki, IDSK, NazwaSK ,
(IDKs - identyfikator, sygnatura ksi ki, IDSK - identyfikator słowa kluczowego,
NazwaSK - nazwa słowa kluczowego),
Wypo yczaj cy - IDWyp, Nazwisko, Adres, IDK, NazwaK, Termin, Ilo
(IDWyp - identyfikator wypo yczaj cego, IDK - identyfikator kategorii, NazwaK nazwa kategorii wypo yczaj cego, Termin - czas po którym nale y zwróci ksi k ,
Ilo - maksymalna liczba ksi ek),
Wypo yczenie - IDWyp, IDKs, DataWypo yczenia, DataZwrotu.
Dodatek B
75
Relacyjne bazy danych
Zgodnie z teori relacyjnych baz danych ka dy obiekt i powi zanie jest relacj w tzw.
formie dowolnej.
Zestaw relacji rozwa anego problemu w formie dowolnej:
Ksi ki (IDKs, TytułKsi ki, AutorKsi ki, IDSK, NazwaSK),
Wypo yczaj cy (IDWyp, Nazwisko, Adres, IDK, NazwaK, Termin, Ilo ),
Wypo yczenie (IDWyp, IDKs, DataWypo yczenia, DataZwrotu).
I FN
Wyodr bnienie zale no ci funkcjonalnych pomi dzy atrybutami relacji rozwa anego
problemu i wyrysowanie grafu znacznie upraszcza normalizacj schematu bazy danych.
Graf zale no ci funkcjonalnych
Ka da strzałka na poni szym grafie opisuje zale no funkcjonaln pomi dzy
poł czonymi atrybutami.
TytułKsi ki
IDKs
•
NazwaSK
IDSK
AutorKsi ki
DataWypo yczenia
•
DataZwrotu
Nazwisko
IDWyp
IDK
NazwaK
Adres
Termin
Ilo
Zale no ci po rednie zaznaczono liniami przerywanymi, zale no ci funkcjonalne o
dwóch składnikach po lewej stronie strzałki zaznaczono kropkami.
Zale no
IDKs,DataWypo yczenia → IDWyp, DataZwrotu opisuje fakt
wypo yczenia ksi ki przez wypo yczaj cego (przy ograniczeniu, e dana ksi ka nie
b dzie wypo yczana dwa razy tego samego dnia).
IDSK
Zale no IDKs→•← IDSK opisuje zbiór słów kluczo- IDKs
1
1
wych ka dej ksi ki.
1
2
2
1
W celu znormalizowania relacji nale y okre li dla niej klucz, je eli jest to
niemo liwe nale y relacj zdekomponowa na tyle mniejszych relacji ile zawiera ona
ródeł zale no ci funkcjonalnych ( ródłem okre la si te atrybuty, które znajduj si po
lewej stronie strzałki zale no ci funkcjonalnej). Klucz zaznaczany jest w schemacie
relacji przez pokre lenie odpowiednich atrybutów.
Zestaw relacji w I FN
76
Wprowadzenie do projektowania baz danych
Ksi ki (IDKs, IDSK, TytułKsi ki, AutorKsi ki, NazwaSK),
Wypo yczaj cy (IDWyp, Nazwisko, Adres, IDK, NazwaK, Termin, Ilo ),
Wypo yczenie (IDKs, DataWypo yczenia, IDWyp, DataZwrotu),
II FN
W celu zapisania relacji w II FN nale y sprawdzi , czy klucze stanowi ródło
zale no ci funkcjonalnych elementarnych. Je eli atrybuty, które nie wchodz w skład
klucza nie s w zale no ci elementarnej od niego, nale y zdekomponowa relacj na tyle
relacji ile zawiera ona ródeł zale no ci funkcjonalnych elementarnych.
Ksi ki (IDKs, TytułKsi ki, AutorKsi ki),
zdekomponowana relacja
SłowaKluczowe (IDSK, NazwaSK),
Ksi ki
Ksi ki-SłowaKluczowe (IDKs, IDSK) ,
Wypo yczaj cy (IDWyp, Nazwisko, Adres, IDK, NazwaK, Termin, Ilo ),
Wypo yczenie (IDKs, DataWypo yczenia, IDWyp, DataZwrotu).
III FN
Przy transformacji relacji z II FN do III FN nale y sprawdzi , czy klucze stanowi
ródło zale no ci funkcjonalnych bezpo rednich. Je eli tak, to relacja jest w III FN, w
przeciwnym przypadku nale y j zdekomponowa .
Ksi ki (IDKs, TytułKsi ki, AutorKsi ki),
SłowaKluczowe (IDSK, NazwaSK),
Ksi ki-SłowaKluczowe (IDKs, IDSK),
Wypo yczaj cy (IDWyp, Nazwisko, Adres, IDK),
zdekomponowana relacja
Wypo yczaj cy
Kategoria (IDK, NazwaK, Termin, Ilo ),
Wypo yczenie (IDKs, DataWypo yczenia, IDWyp, DataZwrotu).
Praktyka projektowania relacyjnych baz danych pokazuje, e III FN jest w licznych
przypadkach całkowicie wystarczaj ca i niepotrzebna jest dalsza normalizacja schematu
(posta normalna Boyce’a-Codda - BCNF, IV FN, V FN). W opracowaniu tym proces
projektowania struktury bazy zako czono po doprowadzeniu schematów relacji do III
FN. Pocz tkowa posta relacji w formie dowolnej została tak dobrana, aby ka dy etap
normalizacji wprowadzał zmian w strukturze zbioru relacji. Do wiadczony projektant
bazy danych mógłby ju na wst pie wyodr bni obiekty i powi zania odpowiadaj ce
relacjom w III FN.