3

Relacyjny model danych

Mimo e omawiane w rozdziale drugim podejcie do projektowania baz danych, oparte na zwizkach
encji i zorientowane obiektowo, s uyteczne i waciwe do opisu struktur danych, to obecnie implementacje
bazy danych prawie zawsze opieraj si na innym sposobie podejcia, nazywanym modelem relacyjnym. Ten
relacyjny model jest najbardziej uyteczny, co wynika z faktu, e bazuje on na jednym pojciu modelowania
danych: na relacji, czyli dwuwymiarowej tabeli, do ktrej wpisuje si dane. W rozdziale 5 przekonamy si, e
wanie model relacyjny jest odpowiedni do wspdziaania z jzykiem zapyta bardzo wysokiego poziomu
SQL (structured query language - strukturalny jzyk zapyta). W jzyku SQL mona zapisywa proste
programy, ktre generujzoone wyniki, operujc na danych zapamitanych w postaci relacji.
Czsto jednak jest atwiej zaprojektowa baz danych w jednym z modeli opisanych w rozdziale 2.
Dlatego naszym podstawowym celem jest poznanie sposobu przeksztacenia projektu zapisanego w jednej z
tamtych notacji do postaci modelu relacyjnego. Potem okae si, e model relacyjny obejmuje rwnie
waciw sobie teori projektowania. Teoria ta bywa czsto nazywana normalizacja relacji i operuje pojciem
zalenoci funkcyjnych", ktre z kolei rozszerza pojcie klucza; klucze w sposb nieformalny ju opisano w p.
2.5.1. Korzystajc z teorii normalizacji, czsto udaje si poprawi relacje opisujce pewien projekt bazy danych.

3.1. Podstawy modeli relacyjnych

Model relacyjny dostarcza tylko jednego sposobu reprezentowania danych: jest nim dwuwymiarowa
tabela, nazywana relacja. Przykad relacji przedstawiono na rys. 3.1. Nazw relacji jest Film i zamierzamy w
niej przechowywa takie same dane, jak w prostej klasie modelu ODL o nazwie Film, ktra bya zdefiniowana
w przykadzie 2.1 na rys. 2.4 oraz powtrzona
3.1. PODSTAWY MODELI RELACYJNYCH I I

na rys. 3.2. Warto przypomnie sobie, e nie bya to ostateczna wersja definicji klasy Film i obejmowaa tylko
atrybuty tytu, rok, dugo i typFilmu.
tytu rok Gwiezdne Wojny 1977 Potne Kaczory 1991 wiat Wayne'a 1992
cllugo
typFihrau
124
kolor
104
kolor
95
kolor
RYSUNEK 3.1 Relacja Film
1) interface Film{
2) attribute string tytu; 3) attribute integer rok;
4) attribute integer dugo;
5) attribute enumeration (kolor, czarno-biay) typFilmu;
};
RYSUNEK 3.2
Opis klasy Film w jzyku ODL

3.1.1. Atrybuty
W nagwku relacji s podane atrybuty. Na rysunku 3.1 atrybutami s: tytu, rok, dugo i typFilmu.
Atrybuty relacji su do nazywania kolumn relacji. Na og atrybuty oddaj znaczenie danych umieszczanych
w kolumnach pod nimi. Na przykad w kolumnie z atrybutem dugo umieszcza si czas trwania (czyli
dugo) poszczeglnych filmw.
Zauwamy, e atrybuty relacji Film z rys. 3.1 odpowiadaj elementom struktury danych definicji ODL z
rys. 2.4, nazywanym tam rwnie atrybutami. Taki sposb dobierania atrybutw relacji jest do powszechny.
Jednak to, e atrybuty relacji maj jakie odpowiedniki w skadnikach modelu encji lub obiektowym modelu
opisu danych, nie musi by obowizujca regu.

3.1.2. Schematy
Nazwa relacji oraz jej zbir atrybutw nazywaj si schematem relacji. Schemat relacji
zapisujemy za pomoc jej nazwy, po ktrej wystpuje lista atrybutw ujta w nawiasy okrge.
Schemat relacji Film z rys. 3.l jest nastpujcy:
Film (tytu, rok, dugo, typFilmu)
I Z 2 3. RELACYJNY MODEL DANYCH

Mimo e atrybuty schematu relacji nie stanowi listy, bowiem s zbiorem, to aby mc opowiada o
relacji, czsto trzeba okreli standardowy" porzdek atrybutw. Std te, jeli gdziekolwiek
wprowadzimy schemat relacji w powyszej postaci, z list atrybutw, to porzdek na licie bdziemy
traktowa wico i przestrzega go wszdzie tam, gdzie trzeba bdzie rysowa relacje lub jej
wiersze.
W modelu relacyjnym projekt skada si z jednego lub kilku schematw relacji. Zbir schematw relacji
projektu jest okrelany schematem relacyjnym bazy danych lub po prostu schematem bazy danych.

3.1.3. Krotki
Wiersze relacji, poza wierszem nagwka, zawierajcym atrybuty relacji, s nazywane knotkami. W krotce
kady atrybut ma swj odpowiednik w postaci skadowej knotki. Na przykad pierwsza z trzech knotek z rys.
3.1 ma cztery skladowe: Gwiezdne Wojny, 1977, 124 oraz kolor, ktre s koljnymi wartociami atrybutw:
tytu, rok, dugo oraz typFilmu. Jeli przedstawiamy wyodrbnion krotk, a nie wskazujemy wiersza relacji,
to jej skadowe oddzielamy przecinkami, a sam krotk ujmujemy w nawiasy. Na przykad:
(Gwiezdne Wojny, 1977, 124, kolor)
jest pierwsz krotk z rys. 3.1. Zauwamy, e jeli knotka wystpuje osobno, nie w tabeli, to nie ma
opisanych atrybutw, zatem trzeba mie jak dodatkow wskazwk, aby okreli, o ktr relacj
chodzi. Dlatego bdziemy stosowa ten sam porzdek wartoci, w ktrym definiuje si atrybuty w
schemacie relacji.
Czsto traktuje si knotki tak jak obiekty, a relacje, tak jakby byy klasami tych obiektw. Na pewno tak
si dzieje z nasz przykadow relacj filmw, kada knotka reprezentuje obiekt typu film. Skadowe knotek i
waciwoci obiektw z klasy opisanej na rys. 3.2 s identyczne. Jednak trzeba sobie zdawa spraw, e obiekty
maj tosamo, a knotki nie. Oznacza to, e w reprezentacji obiektowej filmw mog wystpi dwa obiekty o
takich samych wartociach wszystkich atrybutw, aczkolwiek, jak ju wspomnielimy w przykadzie 2.23, taki
przypadek wrd filmw nie powinien si zdarzy.
Relacje natomiast s zbiorami knotek, a zatem jedna knotka nie moe wystpi w danej relacji wicej ni
jeden raz. Jeli wic relacja suy do przedstawienia obiektw pewnej klasy, to trzeba si upewni, e ma
dostatecznie szeroko okrelony zbir atrybutw, po to by adne dwa obiekty nie miay tych samych wartoci
atrybutw relacji. W przykkadzie 2.23 stwierdzilimy, e nie moe si zdarzy, aby dwa rne filmy miay
identyczny tytu i rok produkcj i. Jednak w najgorszym przypadku moe okaza si potrzebne utworzenie
3.1. PODSTAWY MODELI RELACYJNYCFf I I 3

sztucznego atrybutu, ktry stanowiby o identyfikacji obiektu. Na przykad kademu filmowi mona by
nadawa jednoznaczny numer IdFilmu" oraz doda zdFilmu do zbioru atrybutw naszej przykadowej relacji.

3.1.4. Dziedziny
W modelu relacyjnym kada skadowa kadej relacji musi mie okrelony typ atomowy, tzn. jej typ musi
nalee do typw elementarnych, np. musi by to typ cakowity lub znakowy. Warto atrybutu nie moe by
ani rekordem, ani list, ani tablic, ani zbiorem, ani adn inn struktur, ktr mona podzieli na niniejsze
czci. Wanie to wymaganie sprawia, e atrybuty z notacji ODL nie mog by automatycznie przekadane na
pojedyncze atrybuty relacji. Jeli na przykad atrybut nazwisko w ODL zapisuje si jako struktur:
Struct nazwisko {string pierwsze, string drugie}
to w odpowiadajcej relacji musz zosta uwzgldnione osobno dwa atrybuty: pierwsze i drugie. Obszerniejsze
omwienie tego zagadnienia znajduje si w p. 3.2.2.
Zakada si, e z kadym atrybutem relacji jest powizana dziedzina, czyli pewien okrelony typ
elementarny. Kada skadowa kadej krotki w relacji ma warto, ktra naley do dziedziny odpowiedniej
kolumny. Na przykad w krotkach relacji Film z rys. 3.1 pierwsza skadowa musi mie warto typu string,
druga i trzecia - typu integer, a czwarta musi mie okrelonjednzdwch wartoci: Kolor lub czarno-biay.

3.1.5. Rwnowane sposoby reprezentowania relacji

Jak ju wiemy zarwno schematy, jak i krotki relacji s zbiorami, a nie listami. A zatem porzdek, w jakim
je przedstawimy, nie ma znaczenia. Na przykad trzy krotki z rys. 3.1 moemy przedstawi w dowolnym z
szeciu moliwych porzdkw. Jednak'ze bdzie to cigle ta sama relacja przedstawiona na rys. 3.1.
Ponadto moemy zmienia kolejno atrybutw relacji w dowolny sposb, a sama relacja nie
ulegnie przez to zmianie. Jednak, jeli zmienimy kolejno atrybutw w schemacie relacji, to trzeba
zawsze bra pod uwag, e s one take nagwkami kolumn. A wic, jeli zmieniamy kolejno
atrybutw, to musimy take zmieni odpowiednio kolejno kolumn. Jeli zmienia si pooenie
kolumny w tabeli, to zarazem zmienia si kolejno skladowych w krotkach relacji. W wyniku zmiany
kolejnoci atrybutw musi zatem rwnie zaj waciwa permutacja skadowych krotek.
114
rok
tytul
typFilmu

1991
Pot~ne Kaczory
1992
wiat Wayne'a
1997
Gwiezdne Wojny
RYSUNEK 3,3
Inny ukad relacji Film

kolor
kolor
kolor

3. RELACYJNY MODEL DANYCH

dlugo 104
94 124
Jako przykkad na rys. 3.3 zostaa przedstawiona jedna z wielu relacji, ktre mona otrzyma w wyniku
permutacji wierszy i kolumn na rys. 3.1. Obie relacje mona traktowa jako t sam". A mwic cilej, te
dwie tabele s rnymi obrazami tej samej relacji.
Wynik permutowania atrybutw i kolumn musi by widoczny rwnie w krotkach przedstawianych
osobno, poza tabel.
PRZYKAD 3.1 Krotka
(Gwiezdne Wojny, 1977, 124, kolor)
z rys. 3. I oraz krotka
(1977, Gwiezdne wojny, kolor, 124)
z rys, 3.3 prezentuj ten sam obiekt. Ale tej rwnowanoci jestemy wiadomi wycznie wtedy, kiedy znamy
kolejno atrybutw w odpowiadajcym knotkom relacjach. Zatem zalecamy generalnie, aby ustali kolejno
atrybutw relacji i przestrzega jej tak dugo, jak korzysta si z tej relacji.
0
Formalny zapis knotki
W naszej ksice postanowilimy przedstawia knotki w postaci list, z ustalonym porzdkiem atrybutw w
relacji, jednak istnieje sposb zapisu knotek, ktry pozwala unika takiego ustalonego porzdku atrybutw. O
krotce moemy bowiem myle jako o funkcji przeprowadzajcej atrybuty ze schematu relacji do ich zbiorw
wartoci - do skadowych tych knotek. Na przykad reprezentowana ju dwojako knotka w przykadzie 3.1
moe by przedstawiona jako nastpujca funkcja:
tytu --> Gwiezdne Wojny rok --> 1977
dugo --~ 124 typFilmu --~ kolor
3.1. PODSTAWY MODELI RELACYJNYCH

3.1.6. Instancje relacji

115
Relacja dotyczca filmw nie jest statyczna, zmienia si bowiem w czasie. Zmiany, ktrych naley
oczekiwa, dotycz krotek relacji , na przykad wstawiania nowych krotek w przypadku zapisywania w bazie
danych nowych filmw, zmiany istniejcych krotek w przypadku uzyskania danych korygujcycki istniejce w
bazie wartoci i by moe usuwania krotek opisujcych filmy, ktre z jakich powodw maj znikn z bazy
danych.
Rzadziej natomiast ulega zmianie schemat relacji. Jednak mog wystpi takie sytuacje, w ktrych
okazuje si podane dodanie lub usunicie atrybutw. Zmiany schematu w systemach komercyjnych s
niezwykle kosztowne, jeli w ogle wykonalne, poniewa wwczas kada, spord nawet milionowej liczby
krotek, musi by przepisana, eby doczy lub usun skladowe. W przypadku doczania atrybutu moe si
poza tym okaza niemoliwe okrelenie wartoci nowych skladowych niektrych krotek.
Zbir krotek danej relacji bdziemy nazywa instancj relacji. Na przykad trzy krotki z rys. 3.1 stanowi
pewn instancj relacji Film. Prawdopodobnie relacja Film zmieniaa si ju i bdzie si zmienia w dalszym
cigu. Na przyklad w 1980 roku z pewnoci nie wystpowaly w niej krotki opisujce wiat Wayne'a czy
Kipera. Jednak w konwencjonalnych systemach baz danych udostpnia si tylko jedn wersj kadej relacji:
zbir krotek, ktre s w relacji teraz". Te instancje relacji nazywamy ihstarrcjami biec~cymi.
Schematy i instancje
Nie wolno zapomnie o wanej rnicy midzy schematem relacji a jej instancj. Schemat obejmuje nazw
relacji i jej atrybuty i w zasadzie jest niezmienny. Instancja stanowi zbir krotek relacji i moe czsto ulega
zmianom.
W modelowaniu danych powszechnie korzysta si z rozrnienia schematu i instancji. W rozdziale 2 na
przykad odrnialimy definicj interfejsu w ODL, ktra suya do zdefiniowania struktury klasy obiektw, od
zbioru obiektw tej klasy. Definicja klasy stanowi odpowiednik schematu, a zbir obiektw zdefiniowanej klasy
jest instancj. Analogicznie, zbir encji i opis zwizkw stanowi sposb definiowania schematu w modelu
zwizkw encji, a zbiory encji i zbiory zwizkw tworz instancje schematu zwizkw encji. Warto jednak

pamita o tym, e w fazie projektowania bazy danych jej instancja nie wchodzi do projektu. Staramy si tylko
wyobrazi sobie, jak bd wyglda typowe instancje po zakoczeniu projektu.
I I C) 3. RELACY.TNY MODEL DANYCH

3.1.7. wiczenia do podrozdzia~u 3.1

wiczenie 3.1.1. Na rysunku 3.4 s przedstawione instancje dwch relacji, ktre mog stanowi cz bazy
danych banku. Naley okreli:
a) Atrybuty poszczeglnych relacji. b) Krotki kadej relacji.
c) Skadowe jednej krotki w kadej relacji. d) Schemat kadej relacji.
e) Schemat bazy danych.
Waciw dziedzin dla kadego atrybutu.
g) Inny, rwnowany sposb przedstawienia kadej z relacji.
nrKonta
typ
saldo
12345
oszczdnociowy
12000
23456
rozliczeniowy
1000
34567
oszcz~dnociowy
25
Relacja Konta
Imi
Nazwisko
NrID
konto
Robbie
Banks
901-222
12345
Lena
Hand
805-333
12345
Lena
Hand
805-333
23456
Relacja Klienci
RYSUNEK 3.4
Dwie relacje w bazie danych banku
!! wiczenie 3.1.2. Ile istnieje rnych sposobw (biorc pod uwag rn kolejno atrybutw i krotek) reprezentowania
instancji relacji, jeli skada si ona z:
*a) Trzech atrybutw i trzech krotek, podobnie jak relacja Konta z rys. 3.4? b) Czterech atrybutw i piciu krotek?
c) n atrybutw i m knotek?

3 .2. Od projektw ODL do projektw relacyjnych

Rozwamy proces tworzenia nowej bazy danych, podobnej do naszej bazy danych filmw. Zaczyna si on od fazy
projektowania, kiedy to trzeba okreli zakres i rodzaj przechowywanych danych, powizania midzy rnymi rodzajami
danych, zaoenia dotyczce wizw zarwno klucza, jak
3.2. OD PROJEKTW ODL DO PROJEKTW RELACYJNYCH I I %

i integralnoci referencyjnej. Ta faza moe rozcign si w czasie, poniewa ocenia si rozmaite warianty oraz
podsumowuje rne opinie.
Po fazie projektowania nastpuje faza implementacji w rzeczywistym systemie baz danych. Poniewa
znakomita wikszo komercyjnych systemw baz danych stosuje model relacyjny, wic preferuje si tworzenie
projektu rwnie w modelu relacyjnym, a nie w modelu obiektowym, jak ODL czy zwizkw encji, ktre byy
omwione w rozdziale 2.
Mimo to w praktyce do czsto jest atwiej rozpocz od postaci opisauych w rozdziale 2, utworzy
projekt w tym modelu, a potem przeksztaci go do postaci relacyjnej. Jedna z przyczyn takiego postpowania
ley w braku elastycznoci modelu relacyjnego, ktry zawiera tylko jeden rodzaj elementw - relacje i nie
operuje innymi wygodnymi pojciami (np. zbiorami encji i zwizkw z modelu zwizkw encji), a jest to
znacznie atwiej obsugiwa ju po okreleniu struktury projektu.
W biecym rozdziale zastanowimy si, w jaki sposb przeksztaca modele zapisane w jzyku ODL do
postaci projektw relacyjnych. Z kolei konwersje midzy modelem zwizkw encji a modelem relacyjnym
omwimy w podrozdziale 3.3. Nastpnie powicimy troch uwagi podklasom w podrozdziale 3.4. Poniewa
ujcie podklas (zwizkw isa) jest rne w jzyku ODL i w zwizkach encji, to rwnie ich przeksztacanie do
modelu relacyjnego bdzie si rnio.
Czsto do schematu bazy danych docza si wizy. Wizy z modelu ODL i modelu zwizkw encji, takie
jak klucze i wizy integralnoci, mona take wyrazi w modelu relacyjnym. Wana kategoria wizw,
nazywana zalenociami funkcyjnymi, w modelu relacyjnym bdzie przedstawiona w podrozdziale 3.5.
Omwienie innych rodzajw wizw modelu relacyjnego rozpocznie si od podrozdziau 4.5.

3.2.1. Od atrybutw w jzyku ODL do atrybutw relacji

Na pocztek zamy, e kada klasa bdzie miaa swj odpowiednik w postaci jednej relacji, a w tej
relacji dla kadej waciwoci bdzie okrelony jeden atrybut. Zobaczymy pniej wiele sposobw modyfikacji

tych zaoe, lecz na chwil przyjmijmy najprostszy przypadek, kiedy moemy bezporednio przeksztaci
klasy na relacje, a waciwoci na atrybuty. A oto nasze zaoenia:
1. Wszystkie waciwoci klas zapisuje si jako atrybuty (nie ma ani zwizkw, ani metod).
2. Typy atrybutw stylko atomowe (nie ma ani struktur, ani zbiorw). n
PKZYKAD'. 3.2
Na rysunku 3.2 zosta pokazany przykad klasy, odpowiadajcy przyjtym zaoeniom. Wystpuj tam cztery
atrybuty i nie okrelono adnych innych
I I S 3. RELACYJNY MODEL DANYCH

waciwoci. Kady atrybut ma okrelony typ atomowy: tytu jest napisem, rok i dugo s typu cakowitego, a
typFilmu moe przyjmowa jedn z dwch wartoci.
Tworzymy relacj o takiej samej nazwie jak nazwa klasy, w tym przypadku Film. Relacja ma cztery
atrybuty, po jednym odpowiedniku dla kadego atrybutu klasy. Nazwy atrybutw relacji mog by takie same
jak nazwy odpowiednich atrybutw klasy. Zatem otrzymujemy nastpujcy schemat dla tej relacji:
Film (tytu, rok, dugo, typFilmu)
taki sam jak w p. 3.1.1.
W obiektach klasy s okrelone wartoci dla kadego atrybutu klasy. Kademu obiektowi moe
odpowiada krotka, ktrej skadowe s rwne wartociom poszczeglnych atrybutw obiektu. Wynik takiego
przeksztacenia ju widzielimy. Na rysunku 3.1 przedstawiono bowiem przykad przeksztacenia obiektw
klasy Film do postaci krotek.
0

3.2.2. Atrybuty nieatomowe w klasach

Niestety, nawet jeli wszystkie waciwoci klasy s atrybutami, to przy przeksztacaniu klasy do
postaci relacji mog pojawi si problemy. Ich powodem moe by zoony typ atrybutw w jzyku
ODL, ktre bywaj opisywane strukturami, zbiorami, wielozbiorami lub listami. Natomiast podstawowe
zaoenie modelu relacyjnego stanowi o tym, e typy atrybutw mog by wycznie atomowe, takie
jak liczby lub napisy. Std te istnieje potrzeba okrelenia sposobu przedstawiania nieatomowych
typw atrybutw w postaci relacji.
Reprezentowanie typw wyliczeniowych i dat
W modelu ODL istniej pewne typy atomowe, w praktyce daty i typy wyliczeniowe, ktre nie maj
odpowiednikw w typach atomowych standardowego modelu relacyjnego. Na przykad typ wyliczeniowy, to
jest to tak naprawd zbir odpowiednikw dla pierwszych kilku liczb cakowitych. Zatem na przykad pole typu
wyliczeniowego dla dni tygodnia mona zastpi atrybutem typu integer, a korzysta w krotkach tylko z
wartoci cakowitych od 1 do 6. W alternatywny sposb mona korzysta z atrybutu typu string, a dni tygodnia
przedstawia wartociami Pon", wt" itd. W podobny sposb mona w modelu relacyjnym stosowa typ string
do reprezentowania atrybutw, ktre w modelu ODL maj okrelony typ jako data. W rozdziale S przy
omawianiu relacyjnego jzyka zapyta SQL okae si, e tak samo jak w jzyku ODL mona tam uywa
atrybutw, ktre stypu wyliczeniowego i typu daty.
3.2. OD PROJEKTW ODI, DO PROJEKTW RELACYJNYCFI I g

Struktury takie jak rekordy, ktrych pola s z zaoenia typu atomowego, obsuguje si najatwiej. Po
prostu rozszerza si wwczas definicj struktury, dodajc do relacji po jednym atrybucie dla kadego pola
struktury. Jedyny kopot moe wynika wwczas, gdy dwie struktury w klasie maj jednakowe nazwy pl, i w
takim przypadku trzeba wymyli dla jednego z powstajcych w tej parze atrybutw now nazw po to, by w
relacji mona je byo odrni.
interface Gwiazda { attribute string nazwisko; attribute Struct Adr
{string ulica, string miasto} adres; };
RYSUNEK 3.5
Klasa z atrybutem strukturalnym
PRZYKAD 3,3
Rozwamy wstpn definicj klasy gwiazda z przykadu 2.3, podajemy j ponownie na rys. 3.5. Atrybut
nazwisko jest typu atomowego, ale ju atrybut adres jest struktur o dwch polach: ulica oraz miasto. A wic w
relacji odpowiadajcej tej klasie trzeba utworzy 3 atrybuty. Pierwszy z nich to bdzie nazwisko i odpowiada on
atrybutowi o tej samej nazwie z jzyku ODL. Drugi i trzeci atrybut nazwiemy odpowiednio ulica oraz miasto,
bd one stanowi odpowiedniki dwch pl struktury adres i cznie stanowi opis adresu. Schemat relacji
przedstawia si zatem nastpujco:
Gwiazda (nazwisko, ulica, miasto)
PI-zykad instancji tej relacji z arbitralnie dobranymi krotkami zostal przedstawiony na rys. 3.6.

nazwisko
Carrie Fischer Marle Hamill Harrison Ford
ulica 123 Maple St 456 Oak Rd. 789 Palm Dr.
miasto Hollywood Brentwood Beverly Hills
RYSUNEK 3.6
Relacja reprezentujca gwiazdy
0
Ale to nie struktura typu rekord jest najbardziej skomplikowana wrd typw atrybutw, ktrymi mona
okrela atrybuty w definicjach klas w modelu ODL. Mona budowa wartoci, korzystajc z konstruktorw
typw takich jak: set, bag, array i list. Kady z nich stanowi osobny problem
IZO 3. RELACY.INY MODEL DANYCH

przy migracji do modelu relacyjnego. Szczegowo omwimy tylko konstruktor set, ktry rozpowszechnil si
najbardziej.
Uwagi na temat jakoci danych :-)
Podczas obmylania stosownych przykadw danych osobowych, zdecydowalimy si uywa
wymylonych wartoci adresw i innych atrybutw okrelajcych prywatn sfer ycia gwiazd
filmowych, po to by chroni prywatno ludzi sceny, bowiem bywaj oni nadwraliwi i czsto unikaj
publicznoci.
Jedna z metod reprezentowania zbioru wartoci atrybutu A polega na utworzeniu dla kadej wartoci
odpowiadajcej jej krotki. Taka krotka zawiera wwczas stosowne wartoci wszystkich pozostaych atrybutw
klasy. Na pocztku przeledzimy przykad, w ktrym ta metoda dziaa poprawnie, dopiero potem opiszemy
kryjce si w niej puapki.
PRZYKAD 3.4
Przypumy, e klas Gwiazda zdefiniowano w ten sposb, e kadej gwiedzie jest przypisany zbir adresw.
Definicj klasy mona wwczas zapisa w jzyku ODL, tak jak zrobiono to na rys. 3.7. Zamy ponadto, e
Carrie Fischer posiada rwnie domek na play, a pozostae dwie gwiazdy filmowe, wymienione na rys. 3.6
maj tylko jeden dom. Wwczas zapisujemy dwie krotki, w ktrych atrybut nazwisko ma warto Carrie
Fischer, co jest przedstawione na rys. 3.8. Inne krotki pozostajtakie same jak na rys. 3.6.
interface Gwiazda { attribute string nazwisko; attribute Set<
Struct Adr {string ulica, string miasto} > adres;
);
RYSUNEK 3.7
Gwiazdy ze zbiorami adresw
nazwisko
Carrie Fischer Carrie Fischer Mark Hamill Harrison Ford
RYSUNEK 3.8 Dopuszczenie zbioru adresw
ul ica miasto
123 Maple St. Hollywood 5 Locus Ln. Malibu 456 Oak Rd. Brentwood 789 Palm
Dr. Beverly Hills
D
3.2. OD PRO.IEKTW ODL DO PRO.IEKTW RELACYJNYCH I2I

Trzeba jednak przestrzec przed sytuacjami, gdy taka technika rozszerzenia zbioru na kilka krotek
doprowadza do utworzenia le zaprojektowanych relacji. W podrozdziale 3.7 rozwaymy problemy, ktre mog
wwczas si pojawi, oraz dowiemy si, w jaki sposb przeksztaci schemat bazy danych. Tutaj zastanwmy
si po prostu przez chwil nad mogcymi si pojawi problemami.
Wartoci atomowe: bdy czy waciwoci?
Wydaje si, e model relacyjny rzuca nam kody pod nogi w tych miejscach, gdzie model ODL jest bardziej
elastyczny i dopuszcza opisywanie waciwoci w postaci struktur zoonych. Mona nawet poczu ch totalnego odrzucenia modelu relacyjnego lub potraktowania go jako prymitywnej koncepcji wypartej przez
elegantsze techniki obiektowe, takie jak ODL. Jednak w rzeczywistoci na rynku dominuj systemy baz danych
realizowane w modelu relacyjnym. Jednym z powodw takiego stanu rzeczy jest to, e prostota modelu
relacyjnego umoliwia tworzenie zapyta do baz danych poprzez silne narzdzia jzykw zapyta. W
podrozdziaach 4.1 i 4.2 wprowadzimy abstrakcyjne jzyki programowania, algebr relacji i Datalog.
Waniejsze jest pewnie jednak ich wcielenie w SQL, jzykowym standardzie dostarczanym obecnie w prawie
wszystkich systemach baz danych.
PRZYKAD 3.5

Zamy, e w definicji klasy Gwiazda wystpi dodatkowo atrybut dataUrodzenia, skorzystamy wic z definicji
zapisanej na rys. 3.9. Do rysunku 3.7 doczylimy atrybut dataUrodzenia typu Data, ktry w modelu ODL jest
typem atomowym. A zatem schemat relacji Gwiazda z nowym atrybutem dataUrodzenia wyglda nastpujco:
Gwiazda (nazwisko, ulica, miasto, dataUrodzenia)
Wprowadmy jeszcze jednzmian do danych z rys. 3.8. Poniewa zbir adresw moe by pusty, wic
zamy, e w bazie nie figuruje adres Harrisona Forda. Tak zmodyfikowana relacja zostaa przedstawiona na
rys. 3.10.
interface Gwiazda {
attribute string nazwisko; attribute Set<
Struct Adr {string ulica, string miasto} > adres;
attribute Date dataDrodzenia;
RYSUNEK 3.9.
Zbir adresw i dat urodzenia gwiazd
122 nazwisko Carri.e Fischer Carrie Fischer Marle Hamill
RYSUNEK 3.10 Doczenie dat urodzenia
3. RELACYJNY MODEL DANYCH

ulica miasto dataUYOdzenia 123 Maple St. Hollywood 9/9/99

5 Locus Ln. Malibu 9/9/99 456 Oak Rd. Brentwood 8/8/88
Na rysunku 3.10 znajduj si dwa niekorzystne elementy. Po pierwsze data urodzenia Carrie Fischer
powtarza si w kadej krotce. A zatem relacja zawiera redundancj. Jej nazwisko jest co prawda rwnie
powtrzone, ale nie wytwarza to redundancji, poniewa bez tego nazwiska nie wiedzielibymy, e oba adresy
naley wiza z Carrie Fischer. Rnica polega tu na tym, e nazwisko, powtarzajce si w kadej krotce, jest
kluczem obiektu reprezentowanego w relacji i dlatego musi wystpi we wszystkich krotkach dotyczcych tej
gwiazdy. W przeciwiestwie do tego data urodzenia jest dan o gwiedzie i nie stanowi czci klucza
reprezentowanego obiektu, a zatem powtrzenie tej daty jest redundancj.
Drugi problem polega na tym, e poniewa stowarzyszony z Harrisonem Fordem zbir adresw jest pusty,
wic utracilimy o nim wszelkie dane. W szczeglnoci jego data urodzenia nie pojawi si w relacji, nawet jeli
istnieje obiekt Ford w klasie Gwiazda. Trzeba pamita, e aden z tych dwch problemw nie dyskwalifikuje
naszej metodologii przeksztalcania schematw ODL do postaci relacyjnej. Jednak trzeba dostrzega zagraajce
niebezpieczestwa i poprawia schematy relacyjne za pomoc technik normalizacji, opisanych w podrozdziale
3.7.
0
Jeli w definicji klasy kilka atrybutw zdefiniowano jako kolekcje (bdziemy je nazywa
atrybutami wielowartociowymi), to liczba krotek reprezentujcych jeden obiekt bdzie si mnoy.
Trzeba bowiem tworzy osobne krotki dla kadej kombinacji wartoci ahybutw wielowartociowych,
Powrcimy do tego zagadnienia w p. 3.2.5 w kontekcie zwizkw midzy zbiorami.

3.2.3. Reprezentowanie konstruktorw innych typw

Poza strukturami rekordw oraz zbiorami w definicji klasy w jzyku ODL mona stosowa konstruktory
Bag, Array oraz List. Przy reprezentowaniu wielozbioru (bag), w ktrym dana warto moe wystpowa rz
razy, nie moemy po prostu wprowadzi do relacji n identycznych krotek~. Zamiast
" Scilej, w abstrakcyjnym modelu relacyjnym. ktry opisujemy w biecym rozdziale, nie jest
dopuszczalne, aby w relacji wystpoway identyczne krotki. .ednak w relacyjnych
3.2. OD PROJEKTW ODL DO PROJEKTW RELACYJNYCH 123

tego proponujemy doczy do schematu relacji nowy atrybut licznik, okrelajcy, ile razy dany element
wystpuje w wielozbiorze. Przyjmijmy na przykad, e adres z rys. 3.7 jest wielozbiorem, a nie zbiorem.
Wwczas mona by okreli, e 123 Maple St., Hollywood jest adresem Carrie Fischer dwukrotnie, a z kolei 5
Locust Ln., Malibu jest jej adresem trzykrotnie, stosujc nastpujcy zapis:
nazwisko I ulica
Carrie Fischer 123 Maple St Carrie Fischer 5 Locus Ln.
miasto licznik Hollywood 2 Malibu 3
Lista adresw moe by reprezentowana przez nowy atrybut pozycj a, wskazujcy pozycj w obrbie listy.
Na przykad moemy przedstawi list adresw Carrie Fischer, z adresem w Hollywood na pierwszym miejscu,
w postaci nastpujcej relacji:
nazwisko Carrie Carrie
ulica

Fischer

123 Maple St Fischer 5 Locus Ln.

miasto Hollywood 1 Malibu 2

W kocu macierz adresw, ktra ma ustalon dugo, moe by reprezentowana przez atrybuty
utworzone dla kadej pozycji w macierzy. Jeli zatem adres miaby by tablic zawierajc dwie struktury
miasto-ulica, to jeden obiekt typu Gwiazda byby przedstawiony jako:
nazwisko I ulical
Carrie Fischer 1123 Maple St

rniastol ulica2 miasto2

Hollywood 5 Locus Ln. Malibu

3.2.4. Reprezentowanie relacji jednowartociowych

Zdarza si czsto, e definicja pewnej klasy w ODL zawiera zwizki z innymi klasami w tym modelu. Jako
przykad rozwamy pen definicj klasy Film z rys. 2.6, ktr powtarzamy na rys. 3.l 1.
Najpierw skoncentrujmy uwag na zwizku naleyDo, wicym kady film ze studiem, ktre go
wyprodukowao. Pierwsza myl, jaka si nasuwa, to potraktowanie zwizku tak samo jak atrybutu. Moglibymy
w relacji okreli atrybut lub zbir atrybutw, aby reprezentowa atrybuty obiektw powizanej klasy, podobnie
jak to czynilimy w przypadku, gdy atrybuty w modelu ODL
systemach wyposaonych w SQI_ dopuszcza si powtarzanie si krotek, tzn. w jzyku SQL relacje s
wielozbiorami, a nie zbiorami (patrz podrozdz. 4.6 i ~.4). Jeli liczba krotek zaczyna by znaczca, to jednak
doradzamy korzystanie ze scheanatw opisywanych w biecym rozdziale, nawetjeli rzeczyvisty DBMS
dopuszcza powtarzanie si krotek.
I 24 3. RELACYJNY MODEL DANYCH

miay struktur zoon zbioru lub zbioru struktur. W przypadku zwizku naleyDo, do schematu relacji Film
doczylibymy po jednym atrybucie dla kadej waciwoci klasy studio.
interface Film{
attribute string tytu; attribute integer rok; attribute integer dlugo;
attribute enumeration(kolor, czarno-biay) typFilmu;
relationship Set<Gwiazda> gwiazdy
inverse Gwiazda:: wystpujeW; relationship Studio naleyDo;
inverse Studio:: posiada;
RYSUNL;K 3.1 1
Pena definicja klasy Film
Przy takim podejciu pojawia si jednak kopot polegajcy na tym, e obiekty studio pozostaj rwnie we
wasnym zwizku posiada, ktry definiuje z powrotem zaleno do obiektw klasy Film. Do reprezentowania
tego zwizku w kadej krotce relacji film trzeba by zawrze dane o wszystkich innych filmach
wyprodukowanych przez jego studio. Z kolei dane o kadym z tych filmw obejmuj rwnie dane ich studia,
co skania nas do ponownego wczenia danych o filmach powizanych ze studiem. A zatem taka technika moe
doprowadzi do istotnych komplikacji, jeli uda si j stosowa w praktyce.
Lepsz metod uzyskamy, gdy zastanowimy si, w jaki sposb naprawd obiekty s rozmieszczone w
pamici komputera. Jeli obiekt O~ zawiera dowizanie do innego obiektu O2, to wcale nie tworzymy nowej
kopii obiektu OZ w O~. Na og po prostu okrela si wewntrz Ol warto wskanika pokazujcego na obiekt
O2.
Ale model relacyjny nie zawiera pojcia wskanika ani adnego innego podobnego elementu. Zamiast
tego musimy symulowa efekt, uzyskiwany poprzez wskaniki, zbiorem wartoci definiujcyclo powizany
obiekt. Trzeba nam po prostu zbioru atrybutw powizanej klasy, ktre tworz w niej klucz. Jeli to okrelimy,
to moemy potraktowa zwizek tak, jakby by atrybutem lub atrybutami kluczowymi wskazywanej klasy. T
technik ilustruje nastpny przykad.
` O ile acuch filmw i studia nie wychodzi nigdy poza jedno studio, to ju analogiczne postpowanie w
przypadku zwizku gwiazdy i odwrotnego do zwizku wystpujew prowadzioby od filmu do jego gwiazd, do
wszystkich filmw powizanych z gwiazdami, do wszystkich gwiazd, ktre tam wystpoway, i tak dalej,
bardzo szybko doprowadzajc do koniecznoci uwzgldnienia w jednej krotce prawie wszystkich filmw i
gwiazd umieszczonych w bazie danych.
32. OD PROJEKTW ODL DO PROJEKTW RELACYJNYCH I2S

PRZYKAD 3.6
Zamy, e atrybut nazwa stanowi klucz dla klasy studio. Definicj tej klasy przepisujemy zgodnie z rys. 2.6
interface Studio { attribute string nazwa; attribute string adres;
relationship Set<Film> posiada inverse Film::naleyDo; );

Moemy zmodyfikowa schemat relacji Film z rys. 3.1 tak, aby zostay do niego doczone atrybuty okrelajce
studio waciciela. Arbitralnie nazwiemy ten atrybut nazwastudia. Na rysunku 3.12 zostao przedstawione takie
rozszerzenie o atrybut nazwastudia oraz pewne przykadowe krotki.
tytu~
rok
dugo
typFilmu
nazwaStudia
Gwiezdne Wojny
1977
124
kolor
Fox
Potne Kaczory
1991
104
kolor
Disney
Swiat Wayne'a
1992
95
kolor
Paramount
RYSUNEK 3.12
Relacja Film z nowym atrybutem okreljcym studio waciciela
O

3.2.5. Reprezentowanie zwizkw wielowartociowych

Zwizek gwiazdy z rys. 3.11 przedstawia problem, ktry nie wystpuje w przypadku zwizku naleyDo.
Jeli typem zwizku jest klasa, to mwimy, e zwizek jest jednowartociowy. Zwizek naleyDo, ktrego
typem jest klasa studio, jest zwizkiem jednowartociowym. Jednak jeli typem zwizku jest pewna struktura,
np. kolekcja, zastosowana do klasy, to wwczas mwimy, e zwizek jest wielowartociowy. Zwizek gwiazdy
jest wielowartociowy, poniewa jego typ okrelono jako set<Gwiazda>. Mwic inaczej, kady zwizek typu
jeden do wiele lub wiele do wiele z klasy A do klasy B jest zwizkiem wielowartociowym od A do B.
W celu reprezentowania zwizkw wielowartociowych musimy zastosowa kombinacj dwch technik:
1. Tak jak w przypadku zwizku jednowartociowego, trzeba znale klucz reprezentujcy powizane
obiekty.
2. Tak jak w przypadku atrybutw ze zbiorem wartoci, do reprezentowania obiektw powizanych
trzeba tworzy osobne krotki dla po
I ZG 3. RELACYJNY MODEL DANYCH

szczeglnych wartoci. I tak jak w przypadku atrybutw o typie zbioru, przy tej technice zagadnienie
redundancji pozostaje otwarte, poniewa wartoci innych atrybutw relacji musz si powtarza dla kadego
elementu ze zbioru. Ten problem zostanie rozwizany w podrozdziale 3.7, wic na razie pogodzimy si z takim
stanem rzeczy.
PRZYKAD 3.7
Zamy, e nazwisko jest kluczem w klasie Gwiazda. Wwczas relacj, zaprojektowan dla klasy Film,
moemy rozszerzy, doczajc do niej atrybut o przykadowej nazwie nazwiskoGwiazdy, ktrego wartoci
bd odpowiada nazwiskom poszczeglnych gwiazd. Wwczas jeden film bdzie opisany przez tyle krotek, ile
gwiazd wystpujcych w danym filmie umieszczono w bazie danych. Pewne przykady danych zamieszczono
na rys. 3.13. Wyranie wida ju redundancj, wszystkie pozostae dane o filmie s powtarzane dla kadej
gwiazdy wystpujcej w tym fiknie.
tytu
rok
dlugo
typFilmu nazwaStudia
nazwiskoGwiazdy
Gwiezdne
1977
124
kolor
Fox
Carie
Wojny
Fischer
Gwiezdne
1977
124
kolor
Fox
Mark
Wojny
Hamill
Gwiezdne
1977
124
kolor
Fox
Harrison
Wojny
Ford
Potne
1991
104
kolor
Disney
Emilio
Kaczory
Estevez
wiat
1992
95
kolor
Paramount
Dana
Wayne'a
Carvey
wiat
1992
95
kolor
Paramount
Mike
Wayne'a
Meyers
RYSUNEK 3.13
Relacja Fi lm z danymi gwiazd
O

Moe si rwnie zdarzy, e w klasie wystpi wicej ni jeden zwizek wielowartociowy. Wwczas
liczba powstaych krotek w relacji gwatownie si zwiksza. Zamy, e w klasie C okrelono zwizki
wielowartociowe R,, R2, ..., Rk. Wwczas relacja zaprojektowana dla klasy C ma atrybuty odpowiadajce
wszystkim atrybutom C oraz atrybuty odpowiadajce atrybutom klucza wszystkich zwizkw
jednowartociowych z C. Poza tym musz wystpi atrybuty reprezentujce klucze klas powizanych
zwizkami R,, RZ, ..., Rk.

Zamy, e pewien obiekt o z klasy C jest powizany poprzez zwizek R, z n, obiektami, poprzez
zwizek RZ z n, obiektami i tak dalej. Wwczas dla
3.2. OD PROJEKTW ODL DO PROJEKTW RELACYJNYCH 12%

wszystkich moliwych kombinacji tych obiektw tworzymy po jednej krotce, ktra odpowiada obiektowi o. A
zatem, w wyniku otrzymamy n~ x n2 x ... x nk krotek, ktre trzeba umieci w relacji, jeli chcemy
reprezentowa obiekt o w tym modelu.
PRZYKAD 3.8
Zamy, e w klasie C zdefiniowano zbir jednowartociowych atrybutw X oraz dwa wielowartociowe
zwizki R, i R2. Niechaj te zwizki cz klas C z klasami, ktrych kluczowe atrybuty tworz odpowiednio
zbiory Y i Z. A teraz rozwamy obiekt c klasy C, ktry poprzez zwizek R~ jest powizany z obiektami o
kluczach yJ i y2, a poprzez zwizek Rz z obiektami o kluczach z,, zz oraz z3. Niech x reprezentuje wartoci
obiektu c w zbiorze atrybutw X.
Wwczas obiekt c w relacji utworzonej do reprezentowania klasy C sam jest reprezentowany przez sze
krotek. Moemy je oznaczy symbolicznie w nastpujcy sposb:
(x~ Ya zO (x~ Yo zz) (x~ Yn z3) (x~ Y2~ ~t) (x~ Yz~ z2) (x~Yz~ z3)
Klucze z Y zostay tu poczone w pary z kluczami z Z na wszystkie moliwe sposoby.
0

3.2.6. A gdy nie ma klucza...

W modelu obiektowym, takim jak ODL, dopuszcza si wystpowanie dwch obiektw tej samej klasy z
identycznymi wartociami wszystkich waciwoci. Musimy zatem przygotowa si do rozwizania problemw
takich, jak na przyklad istnienie dwch gwiazd o dokadnie takich samych nazwiskach. Jeli tak si zdarzy, to
oznacza, e sam atrybut nazwisko nie wystarcza jako klucz klasy gwiazda, zatem nie moemy go w tym
charakterze stosowa w krotkach relacji Film. Przypuszczalnie, aby otrzyma klucz, moglibymy dolczy inne
atrybuty gwiazd, ale nigdy nie bdziemy mie gwarancji, e dwie rne gwiazdy filmowe nie majtakich
samych nazwisk i imion, takich samych adresw, nie s urodzone tego samego dnia i tak dalej, bez wzgldu na
rodzaj waciwoci gwiazdy, doczonych do bazy danych.
Jedyne gwarantowane rozwizanie polega na utworzeniu nowego atrybutu, ktry reprezentowaby
identyfikator obiektu" klasy odpowiadajcej relacji. Na przykad, jeli nie bylibymy pewni, e atrybut
nazwisko moe by kluczem gwiazd, to moemy utworzy dla kadej gwiazdy jej numer certyfikatu", ktry
moe stanowi numer czlonkowski w Zwizku Aktorw. Numery certyfikatw s jednoznaczne, poniewa
istnieje centrala, ktra jest odpowiedzialna za ich obsug oraz kontroluje, ktre numery sw uyciu.
I 2 3. RELACYJNY MODEL DANYCH

PRZYK.AD 3.9
Jeli wprowadzimy jednoznaczne numery certyfikatw dla gwiazd i zdefiniujemy klucz gwiazdy w relacji
poprzez ten numer, to relacja Film przyjmie nastpujc posta:
rok I dluQO I tvpFilmu I nazwaStudio I cert#
Gwiezdne Wojny 11977 1124 (kolor IFox 112345 Podajemy tu tylko jedn krotk i zakadamy, e 12 345 jest
numerem cer
tyfikatu Carrie Fisher. Do relacji Gwiazda trzeba rwnie doczy atrybut okrelajcy numer certyfikatu, a
take wszystkie inne dane o gwiedzie, ktre wynikajz definicji klasy Gwiazda zapisanej w jzyku ODL. Na
przykad: -cert# ~ nazwisko ~ ulica ~ miasto ~wyste~ujeW
12345 Carrie Fisher 123 Maple St. Hollywood Gwiezdne Wojny opisuje pewien schemat relacji oraz jedn z
kilku krotek odpowiadajcych Carrie Fisher.
0

3.2.7. Reprezentowanie relacji oraz jej odwrotnoci

W zasadzie przy bezporednim tumaczeniu opisu w modelu ODL na model relacyjny dwukrotnie
reprezentujemy relacj, jeden raz w kadym kierunku. W przykadzie 3.7 przechowywalimy kad gwiazd
filmu w krotce, ktra nosia nazw tego filmu. Gdy projektowalimy relacje dla klasy Gwiazda, to
reprezentowalimy zwizek wystpujeW przez utworzenie tylu krotek dla kadej gwiazdy, w ilu filmach ona
wystpowaa, z podaniem tytulu i roku kadego z filmw w osobnych krotkach (pamitamy przecie, e tytu i
rok razem stanowi klucz filmw).

Jednak zauwamy, e przechowywanie zarwno zwizku gwiazdy, jak i jego odwrotnoci, jest
redundantne. Kady z nich dostarcza bowiem tych samych danych co ten drugi. A zatem moemy w relacji
Gwiazda cakiem pomin zwizek wystepuj eW. Zamiast tego moemy utrzyma wszystkie dane w relacji
Gwiazda, a usun atrybut nazwiskoGwiazdy z relacji Film. W punkcie 3.3.2 opiszemy trzeci metod,
polegajc na tym, e zwizek i jego odwrotno s oddzielane i razem tworz now relacj. Czasami, acz kolwiek nie zawsze, taka metoda jest najwaciwsza. Jednak jeli tak si zdarzy, e oddzielna relacja dla
zwizkw jest najlepszym sposobem, to proces normalizacji, ktry omwimy w podrozdziale 3.7, zmusi nas do
utworzenia jej, nawet jeli sami we wstpnym projekcie relacyjnym tego nie zrobimy.
Zauwamy, e w modelach ODL zarwno zwizek, jak i jego odwrotno s niezbdne, poniewa
zawieraj wskaniki od gwiazd do ich filmw
3.2. OD PROJEKTW ODL DO PRO.tEKTW RELACYJNYCH 129

oraz od filmw do ich gwiazd. Nie mona posugiwa si bowiem wskanikami odwrotnie do ich kierunku,
wiec w przeciwnym razie musiayby powsta wskaniki dwukierunkowe". Lecz zarwno w modelu relacyjnym,
jak i w modelu zwizkw encji, zwizki definiuje si przez powizane wartoci (kluczy). Krotki zawierajce
pary powizanych kluczy, ua przykad tytu i rok dla filmu oraz nazwisko gwiazdy, mona stosowa zarwno do
analizowania zwizku, jak i jego odwrotnoci.
Reprezentowanie zwizkw w jednym kierunku
Jeli binarny zwizek zachodzi midzy dwoma zbiorami encji, to mona wybra jednz relacji, w ktrej
zostanie zapisany zwizek: relacj definiujc ktrykolwiek ze zbiorw encji. Czy ma znaczenie, ktr z nich
wybierzemy? Jeli zwizek jest typu jeden do jeden lub wiele do wiele, to naj prawdopodobniej nie ma to
znaczenia. Ale jeli zwizek jest typu wiele do jeden, to warto wprowadzi zwizek po stronie wiele, tzn. do
tego zbioru encji, w ktrym wiele encji moe by powizanych z jedn encj drugiego zbioru encji. W ten
sposb bowiem uda si nam unikn redundancji.
Na przykad zwizek Posiada midzy Filmami i Studiami jest lepiej umieci w zbiorze Filmy. W ten
sposb po prostu tylko rozszerza si zbir atrybutw filmu o nazw waciwego dla filmu studia i kada krotka
rozszerza si o jedn warto. Gdybymy natomiast doczyli zwizek do relacji Studia, to musielibymy kad
krotk w tej relacji rozszerzy o wiele innych krotek, dodajc dla kadego studia tyle krotek, ile filmw ono
posiada. W wyniku takich dziaa powielilibymy wszystkie inne dane na temat studia tyle razy, ile ma ono
filmw.

3.2.8. wiczenia do podrozdzia~u 3.2

wiczenie 3.2.1. Naley przeksztalci projekty w jzyku ODL z wymienionych poniej wicze do postaci
relacyjnego schematu bazy danych.
*a) wiczenie 2.1.1.
b) wiczenie 2.1.2 (wczajc wszystkie cztery modyfikacje wyspecyfikowane w tamtym
wiczeniu).
c) wiczenie 2.1.3. d) wiczenie 2.1.4. *e) Cwiczenie 2.1.5.
wiczenie 2.1.6.
" Oczywicie nie mona zakada, e dana impementacja ODL bdzie zawieraa wskaniki o podanych
waciwociach, ale moe si zdarzy, e istnieje taka implementac_ja, ktra dla pary zwizkw odwrotnych ma
pojedyncz reprezentacj.
I 3 O 3. RELACYJNY MODEL DANYCH

Wskaniki: waciwoci czy bdy?

Zwizki w modelu ODL s z zaoenia albo wskanikami, albo referencjami od kadego obiektu do
odpowiadajcych obiektw. Taki sposb implementacjijest bardzo wygodny, poniewa szybko mona uzyska
dostp do obiektu powizanego. W porwnaniu z tym w modelu relacyjnym, gdzie obiekty reprezentuje si
przez wartoci ich kluczy, a nie przez wskaniki, nawigacja od obiektu do powizanych z nim wartoci wydaje
si wolniejsza.
Na przykad obiekt Film z przykadu 3.7 obejmowa po jednej krotce dla kadej gwiazdy z tego filmu, w
krotce byo umieszczone wycznie nazwisko gwiazdy, bez adnych innych jej danych. Gdybymy chcieli
znale na przykad adresy gwiazd wystpujcych w wiecie Wayne'a", to trzeba by na podstawie nazwisk
gwiazd w relacji Gwiazda wyszuka wszystkie krotki danej gwiazdy. Dopiero w ten sposb uzyskalibymy ich
adresy.
Mona by zatem pomyle, e brak wskanikw w modelu relacyjnym by czym w rodzaju bdu w tym
modelu. Jednake w praktyce buduje si na relacjach indeksy, ktre umoliwiaj bardzo efektywne poszukiwanie krotek, ktre maj okrelon warto w danej skadowej (patrz: p. 1.2.1 oraz 5.7.7). A wic w praktyce

niewiele si traci przez brak wskanikw. Ponadto, o ile wskaniki s bardzo potrzebne w programach, ktre
dziaaj na danych w pamici operacyjnej, a ich wykonanie trwa nie duej ni uamek sekundy, o tyle w bazach
danych stosuje si zupenie inne metody. Implementacja wskanikw midzy obiektami, ktre istniej latami w
bazie, a mog by przechowywane w sposb rozproszony na rnych urzdzeniach pamici zewntrznych
doczonych do szeroko rozproszonych systemw komputerowych, jest znacznie trudniejsze. Tutaj dopiero
wida, jak silne s argumenty przemawiajce za rozwizaniami stosowanymi w modelu relacyjnym, gdzie nie
uywa si wskanikw.
interface Klient{
attribute Struct nazwisko
{string imi, string nazwisko} nazwisko; attribute Set<
Struct Tel {string typ, int numer}
>telefony; relationship Klient okrelonyPrzez inverse
wprowadzenia; relationship Set<Klient> wprowadzenia; inverse
Studio:: okrelonyPrzez;
KYSUNEK 3.14 Rekordy Klienta
3.3. OD DIAGRAMW ZWIZKW ENCJI DO PROJEKTW RELACYJNYCH 131

wiczenie 3.2.2. Naley przeksztaci opis w jzyku ODL z rys. 2.7 do relacyjnego schematu bazy danych. W
jaki sposb trzy modyfikacje wyspecyfikowane w wiczeniu 2.1.8 wpywaj na posta schematu relacyjnego?
!wiczenie 3.2.3. Na rysunku 3.14 przedstawiono w jzyku ODL definicj klasy klienci. W obiektach tej klasy
przechowuje si zbir rnych rodzajw telefonw (np. domowy, biurowy, fax) oraz zbir doczonych", w
ktrym klient otrzymuje kredyt przy pozyskaniu dla firmy nowych klientw. Naley przeksztaci t
specyfikacj z jzyka ODL do schematu relacyjnego bazy danych.

3.3. Od diagramw zwizkw encji do projektw relacyjnych

Przeksztacanie diagramw zwizkw encji na schemat bazy danych bardzo przypomina przeksztacanie
projektw w jzyku ODL do schematu bazy danych. Jednake w pewnym sensie model zwizkw encji stanowi
posta poredni midzy projektami obiektowym a relacyjnym. Oznacza to, e gdy dysponujemy modelem
zwizkw encji, to unikamy czci cikiego trudu. Dwie istotne rnice polegaj na tym, e:
1. W modelu zwizkw encji zwizki s wyodrbnione jako samoistne pojcie, a nie s elementem skadowym
pojcia klasy. Ta rnica pozwala unikn redundancji pewnego rodzaju, ktre omawialimy w p. 3.2.2,
kiedy zdecydowalimy, eby wczy zwizek wielowartociowy, taki jak gwiazdy, do krotek
reprezentujcych obiekty klasy Film.
2. W modelu ODL dla atrybutw mona okrela zoony typ, np. <set>. Modele zwizkw encji maj bardziej
wywaony charakter i mimo e wartoci strukturalne s w nich zasadniczo dopuszczalne, to nie s to ani
wartoci typu Set, ani inne konstruktory typu kolekcji". Wskutek tego atrybut, ktrego wartoci maj posta
zbioru elementw, takie jak np. zbir adresw gwiazdy omawiany w przykadzie 3.4, zmusza projektanta do
tego, aby w modelu zwizkw encji zbir adresw okrela jako zbir encji oraz utworzy zwizek Mieszkaw, ktry wie gwiazd z jej adresami.
3. W modelu zwizkw encji mona okrela atrybuty zwizkw. W modelu ODL nie istnieje
rwnowane pojcie.
' .lednak istniej takie definicje formalizmu zwizkw encji. w ktrych typy atrybutw traktuje si
podobnie jak w jzyku ODL: dopuszcza si tam i zbiory i kolekcje lub jeszcze prostszy typy.
132

3.3.1. Od zbiorw encji do relacji

3. RELACYJNY MODEL DANYCH

Na pocztku rozwamy zbiory encji, ktre nie s sabe. Modyfikacje, ktre s potrzebne do przeksztacenia
sabych zwizkw encji, wprowadzimy w p. 3.3.3. Dla kadego zbioru encji, ktry nie jest saby, utworzymy
relacj o takiej samej nazwie i z takim samym zbiorem atrybutw. W tej relacji nie bdzie adnych danych
dotyczcych zwizkw, w ktrych dany zbir uczestniczy. Zwizki zostan zdefiniowane przez osobne relacje,
omwimy to zagadnienie w p. 3.3.2.
PRZYKAD 3.10
Rozwamy trzy zbiory encji: Filmy, Gwiazdy oraz Studia z rys. 2.8, ktry odtwarzamy na rys. 3.15. Atrybutami
zbioru eneji Filmy s: tytu, rok, dugo oraz typFilmu. Zatem relacja Filmy wyglda zupenie tak samo jak
relacja Film z rys. 3.1, ktrym rozpoczlimy podrozdzia 3.1.
tytu ) ( rok ) ~nazwisko~ ( adres
Filmy Gwiazdy-w~ ~ Gwiazdy
dugo) ~ typFilmu
nazwa

Posiada
Studia
adres
RYSUNEK 3.15
Diagram E/R bazy danych filmw
O
PRZYKAD 3.11
A teraz rozwamy zbir encji Gwiazdy z rys. 3.15. Tutaj wystpuj dwa atrybuty: nazwisko i adres. A wic
odpowiednia relacja mogaby wyglda nastpujco:
3.3. OD DIAGRAMW ZWIZKW ENCJI DO PROJEKTW RELACYJNYCH I33

>`razwisko adres
Carrie Fisher 123 Maple St., Hollywood Mark Hamill 456 Oak Rd., Brentwood
Harrison Ford 789 Palm Dr, Beverly Hills
Ta relacja przypomina relacj Gwiazda z rys. 3.6, ktr utworzylimy w przykadzie 3.3. Jednak miaa ona trzy
atrybuty, dwa z nich: ulica i miasto reprezentoway struktur adresu. Rnica jest niewielka. Moglibymy
rwnie dobrze zaprojektowa nasz diagram zwizkw encji z rys. 2.8 tak, aby zbir encji Gwiazdy mia osobne
atrybuty ulica i miasto, co uczynioby relacj Gwiazdy identycznz relacjGwiazda z rys. 3.6.
0

3.3.2. Od zwizkw encji do relacji

Zwizki z diagramw encji take przyjmuj posta relacji. Relacja danego zwizku R ma nastpujce
atrybuty:
1. Dla kadego zbioru encji uczestniczcego w R umieszczamy w schemacie relacji odpowiadajcej
R klucze tych zbiorw jako atrybuty tej relacj i.
2. Jeli zwizek ma wasny klucz, to te doczamy jego atrybuty do zbioru atrybutw relacji.
Jeli zbir eucji uczestniczy w zwizku wielokrotnie, to musimy przemianowa atrybuty po to, by unikn
konfliktu nazw. Podobnie, jeli zdarzy si, e te same atrybuty musz wystpi w relacji R, jako jej wasne
atrybuty oraz jako pochodzce ze zbioru uczestniczcego w zwizku, to te nie mona dopuci do powtarzania
si nazw i trzeba dokona przemianowania.
PRZYKAD 3.12
Rozwamy zwizek Posiada z rys. 3.15. Ten zwizek czy ze sob zbiory Filmy i studia. W schemacie relacji
Posiada korzystamy z klucza dla Filmw, czyli atrybutw tytu i rok, oraz z klucza do Studiw, ktrym jest
nazwa. Poniej przedstawiamy schemat relacji:
tui rok nazwaStudia Gwiezdne Wojny 1977 Fox Potne Kaczory 1991 Disney
wiat Wayne'a 1992 Paramount
Atrybut nazwa z relacji studia nazwalimy tutaj nazwaStudia, aby schemat by bardziej zrozumiay.
I34 3. RELACY.INY MODEL DANYCH

Zauwamy, e powyszy zwizek oraz zwizek z przykadu 3.10, ktry utworzylimy dla zbioru encji
Filmy (przedstawiony na rys. 3.1), zawieraj dokadnie te same dane, ktre zawiera zwizek z rys. 3.12,
utworzony w przykadzie 3.6 dla klasy Film, jedynie z pominiciem waciwoci gwiazdy.
0
PRZYKAD 3.13
Postpujc w podobny sposb, mona przeksztaci zwizek Gwiazdy-w z rys. 3.15 do postaci relacji z
atrybutami tytu oraz rok (klucz Filmu) oraz z atrybutem nazwiskoGwiazdy, ktry stanowi klucz do zbioru encji
Gwiazdy. Na rysunku 3.16 pokazano przykad relacji Gwiazdy-W. Zauwamy, e ta relacja oraz rys. 3.16
zawieraj te same dane co rys. 3.13, nie obejmuj one tylko tych atrybutw klasy Gwiazda, ktre nie wchodz w
skad klucza (atrybutw dugo i typFilmu), umieszczone na rys. 3.13.
tytu~
rok
nazwiskoGwiazdy
Gwiezdne Wojny
1977
Carrie Fisher
Gwiezdne Wojny
1977
Mark Hamill
Gwiezdne Wojny
1977
Harrison Ford
Potne Kaczory
1991
Emilio Estevez
wiat Wayne'a
1992
Dana Carvey
wiat Wayne'a
1992
Mike Meyers
RYSUNEK 3.16
Relacja zwizku Gwiazdy-w
Moe si wydawa, e na rys. 3.16 atrybut rok jest redundancyjny. Ale wynika to tylko z faktu, e w tym
przykadzie nazwy filmw nie powtarzaj si. Gdyby tam wystpowao kilka frlmw o tym samym tytule, np.

King Kong", to rok byby istotny na przykad do rozstrzygnicia, ktre gwiazdy wystpujca ktrej wersji
filmu.
0
Zobaczmy, jakie s zalety schematu bazy danych, ktry otrzymamy, zaczynajc od modelu zwizkw encji
w porwnaniu ze schematem bazy przeksztaconym z modelu ODL.
Relacje czciej wystpuj w postaci znormalizowanej ni klasy, co oznacza, e zawieraj mniej redundancji
ni przy bezporedniej transformacji z opisu ODL.
Dwukierunkowy zwizek w modelu ODL zostaje zastpiony pojedyncz relacj, ktra odzwierciedla zwizek
w obu kierunkach.
PRZYKAD 3.14
Rwnie
zwizki
wieloargumentowe
mona
w
atwy
sposb
przeksztaci
w
relacje.
Rozwamy'czteroargumentowy zwizek Kontrakty z rys. 2.12, po
3.3. OD DIAGRAMW ZWIZKW ENCJI DO PROJEKTW RELACYJNYCf~ I3S

wtrzony na rys. 3.17, ktry obejmuje gwiazd, film i dwa studia, pierwsze utrzymujce kontrakt z gwiazd i
drugie, ktre pozyskuje gwiazd do udziau w konkretnym filmie. Zwizek ten jest reprezentowany przez
relacj Kontrakty, ktrej schemat skada si z atrybutw czterech nastpujcych kluczy dla czterech zbiorw
encji:
1. Klucz nazwiskoGwiazdy dla zbioru gwiazd.
2. Klucz zoony z atrybutw tytu oraz rok dla filmu.
3. Klucz studioGwiazdy wskazujcy nazw pierwszego studia, jak pamitamy przyjlimy zaoenie, e nazwa
studio jest kluczem zbioru encji studio.
4. Klucz studioProducenta, ktry stanowi nazw tego studia, ktre produkuje film z udziaem gwiazdy.
Filmy
Kontrakty
Studio ~ ' Studio gwiazdy ) producenta
Studia
RYSUNEK 3.17 Zwizek Kontrakty
Od ODL do relacji
Jak ju wspomnielimy, w wyniku przeksztacenia zwizku z modelu zwizkw encji do schematu relacji
czasami otrzymujemy lepszy schemat relacyjny bazy danych ni w sytuacjach, gdy przeksztacamy zwizki w
ODL do postaci relacji. Jednake nic nie stoi na przeszkodzie, aby z modeli zwizkw encji zapoyczy
technik wydzielania w osobn relacj zwizkw typu wiele do jeden albo wiele do wiele. Pozwoli to wyeliminowa redundancj oraz mnoenie si liczby encji, co dzieje si czasami przy prbach implementowania
zwizku wielowartociowego w jzyku ODL przez definiujce go klasy. Poza tym przypomnijmy ponownie, e
w podrozdziale 3.7 bdzie mona pozna automatyczny sposb naprawienia schematu relacji, otrzymanego
bezporednio z opisu w jzyku ODL.
136
3. RELACYJNY MODEL DANYCI~1

Nazwy atrybutw wprowadzonych do relacji zostay uwanie wybrane, poniewa, jeli jak dotychczas
uywalibymy okrelenia nazwa", to nie byoby jak odrni, czy chodzi o nazw studia producenta, czy o
studio gwiazdy.
0

3.3.3. Zasady postpowania ze sabymi zbiorami encji

Jeli w diagramie zwizkw encji wystpuje saby zbir encji, to trzeba przestrzega trzech rnych zasad:
Relacja odpowiadajca slabemu zbiorowi encji W musi zawiera nie tylko atrybuty W, ale take te atrybuty
kluczy z innych zbiorw enaji, ktre wchodz w skad zbioru W. Te wspomagajce zbiory encji s atwe do
rozpoznania, poniewa uczestnicz wraz z W w zwizkach wiele do jeden, a te zwizki z kolei w diagramie s
oznaczone podwjnym rombem.
Kady zwizek, ktry obejmuje saby zbir encji W, musi korzysta ze wszystkich atrybutw klucza W,
wlezajc w to klucze W pochodzce z innych zbiorw encji, ktre uczestnicz w W.
Jednake, jak si przekonamy pniej, zwizki oznaczane podwjnym rombem, ktre istniej po to, aby
udostpni dla zbioru W atrybuty klucza z waciwych zbiorw encji, wcale nie musz by przekszta cone w
osobn relacj. Atrybuty tych zwizkw zawsze bd bowiem stanowi podzbir sabego zbioru encji W, a tego
typu zwizki nie dostarczaj poza tym adnych innych danych, ich jedyna funkcja polega na odnalezieniu
waciwego klucza dla W.

Oczywicie, przy wprowadzaniu do sabego zbioru eneji tych dodatkowych atrybutw trzeba zachowa
ostrono i nie dopuci do tego, aby jaka nazwa wystpia dwukrotnie. Jeli jest to konieczne, to cz
atrybutw, lub nawet wszystkie, trzeba przemianowa.
numer ~ ( nazwa ) ( adres
Zespoy ~ednostka-~~ Studia
RYSUNEK 3,18
Zespoyjaka przy=kad stabego zbioru encji
3.3. OD DIAGRAMW ZWIZKW ENCJI DO PROJEKTW RELACYJNYCH I3 %

PRZYKAD 3.15
Rozwamy saby zbir encji Zespo~y z rys. 2.27, ktry zamiecilimy ponownie na rys. 3.18. Z tego
diagramu tworzymy trzy relacje o nastpujcych schematach:
Studia (nazwa, adr)
Zespoy (numer, nazwaStudia) Jednostka-w(numer, nazwaStudia, nazwa)
Pierwsza relacja studia jest wynikiem najprostszego przeksztacenia ze zbioru encji o takiej samej nazwie.
Druga relacja zespoy jest odpowiednikiem sabego zbioru encji Zespoty. Atrybutami tej relacji s atrybuty
klucza zbioru Zespo~y. Jeli istniayby w tym zbiorze jeszcze inne atrybuty, to trzeba by je doczy rwnie do
schematu tej relacji. Atrybut w relacji zespoy o nazwie nazwastudia stanowi odpowiednik atrybutu nazwa w
zbiorze encj i Studia.
Trzecia relacja Jednostka-w powstaje ze zwizku o takiej samej nazwie. Jak we wszystkich przypadkach,
tak i tu zwizek encji reprezentujemy w modelu relacyjnym relacj, ktrej schemat zawiera atrybuty kluczy
wszystkich zbiorw encji objtych oryginalnym zwizkiem. W rozwaanym przypadku relacja Jednostka-w
zawiera atrybuty numer oraz nazwaStudia, ktre s kluczem sabego zbioru encji Zespoy oraz atrybut nazwa,
ktry jest kluczem zbioru encji Studia. Zauwamy jednak, e studio o kluczu nazwastudia jest tym samym
studiem, ktrego kluczem jest nazwa, poniewa Jednost ka-w jest zwizkiem wiele do jeden.
Zamy na przykad, e Disney #3 oznacza jeden z zespow w studio Disneya. Zatem w zbiorze
zwizku.7ednostka-w wystpuje para
(Disney #3, Disney)
Para ta w krotce relacji Jednostka-w bdzie reprezentowana nastpujco:
(3, Disney, Disney)
W konsekwencji moemy w relacji Jednostka-w polczy atrybuty nazwastudia i nazwa, co da prostszy
schemat:
Jednostka-w(numer, nazwa)
A teraz wida ju, e mona cakiem pomin relacj Jednostka-w, poniewa jej atrybuty s
podzbiorem atrybutw relacji zespoy.
0
I'R7,YK(,AD 3.16
Rozwamy teraz saby zbir encji Kontrakty z przykadu 2.31 i rys. 2.28 z p. 2.6.1. Powtarzamy ten diagram na
rys. 3.19. Poniej zamieszczamy schemat relacji Kontrakty: