Pojęcie encji, atrybutu i związku
Przy modelowaniu baz danych można posłużyć się notacją graficzną modelowania danych -
diagramem związków encji (ERD). Jest to model sieciowy, opisujący na wysokim poziomie abstrakcji dane
które są przechowywane w systemie.
Model ERD budowany jest przez analityka. Służy on do zobrazowania w sposób zrozumiały zarówno dla
projektanta, jak i osoby nie mającej wykształcenia informatycznego (np. klienta) obiektów i związków
zachodzących w projektowanej dziedzinie problemowej.
Model ERD nie jest związany z konkretną implementacją systemu (np. na serwerze MS SQL czy Oracle),
choć jego odmiany mogą zawierać informacje specyficzne dla danego języka lub środowiska
implementacyjnego. Staje się on wówczas modelem projektowym
Encja (ang. entity)
Encja jest to coś co istnieje, co odróżnia się od innych, o czym trzeba mieć informację. Zbiory
encji reprezentują zbiór elementów występujących w rzeczywistym świecie i każdy element tego zbioru
musi posiadać następujące cechy:
" każdy element musi być unikalny, jednoznacznie określony, w celu odróżnienia go od pozostałych,
" każdy element musi odgrywać jakąś rolę w projektowanym systemie, nie może zdarzyć się
sytuacji, w której system może działać bez dostępu do danego elementu,
" każdy element powinien być opisany przez odpowiednią liczbę atrybutów.
W diagramach ERD obiekt, encja jest reprezentowany przez prostokąt, a jego nazwa powinna być
rzeczownikiem.
Atrybut (ang. attribute)
Atrybut jest pewną własnością encji, o której chcemy przechowywać informację. Atrybut jest
reprezentowany przez pewną wartość. Na przykład encja Student może mieć atrybut Nazwisko
reprezentowany przez wartość Kowalski.
Wśród atrybutów encji wyróżniamy atrybut lub zbiór atrybutów, którego wartość w sposób jednoznaczny
identyfikuje instancję (egzemplarz) encji. Taki atrybut lub zbiór atrybutów nazywamy kluczem głównym
encji. Klucz głowny oznacza się często na wykresach symbolem PK (ang. Primary Key) umieszczanym
obok nazwy atrybutu.
Rys. 2.5 Przykład definicji kluczy głównych (PK)
Drugim kluczem stosowanym w bazach relacyjnych jest klucz obcy.
Kluczem obcym nazywamy atrybut encji, który wskazuje na klucz główny innej encji. Klucz obcy oznacza
się często na wykresach symbolem FK (ang. Foreign Key) umieszczanym obok nazwy atrybutu.
Rys. 2.6 Przykład klucza obcego (FK1)
Przykład ilustrujący pojęcie klucza obcego pokazano na rysunku 2.6.
Związek (ang. relationship)
Bardzo ważnym elementem w modelu danych są związki pomiędzy encjami i warunki określające
te związku - elementy łączące encje między sobą. Zdecydowana większość związków to powiązania
stopnia drugiego - związki binarne, charakteryzujące się tym, że w związku bierze udział dwóch
uczestników (dwie encje). Mogą występować także związki unarne (encja powiązana z samą sobą), jak
również związki ternarne (z trzema uczestnikami).
W zależności od tego, jakiego typu jest uczestnictwo encji w danym związku, możemy podzielić encje na
słabe lub regularne. Encje słabe charakteryzują się całkowitym uczestnictwem w powiązaniu, to oznacza,
że encja nie może istnieć bez tego powiązania (np. encja Zamówienia nie może istnieć bez powiązania
z encją Klienci). Natomiast uczestnictwo encji regularnych w związku jest tylko częściowe, czyli encja
może istnieć samodzielnie bez powiązania (np. encja Klienci może istnieć bez powiązania z encją
Zamówienia).
Bardzo istotnym czynnikiem określanym przy związkach jest moc powiązania, która definiuje się jako
maksymalną liczbę instancji jednej encji (wystąpień w danej encji), które mogą być powiązane z instancją
innej encji. Ze względu na wartość mocy możemy wyróżnić trzy typy powiązań:
" jeden-do-jeden,
" jeden-do-wiele,
" wiele-do-wiele.
Związki binarne:
Związek jeden-do-jeden (jedno-jednoznaczny)
Jest to najprostszy typ powiązania, występuje wtedy, gdy tylko jedna instancja pierwszej encji jest
powiązana z tylko jedną instancją drugiej encji. Jest to powiązanie wprowadzające dosyć znaczne
ograniczenia, gdyż warunek jeden do jednego musi być zawsze spełniony. Opcjonalnie przy powiązaniu
jeden może występować również opcja żadne, oznaczana graficznie w postaci okręgu.
Rys. 2.7 Związek jeden-do-jeden
Związek jeden-do-wiele (jedno-wieloznaczny)
Najbardziej typowym rodzajem powiązania jest powiązanie jeden-do-wiele, w którym pojedyncza instancja
jednej encji może być połączona z jedną lub wieloma instancjami drugiej encji. Ze względu na swoją
uniwersalność i małą kłopotliwość, ten typ powiązania jest najczęściej stosowany . Opcjonalnie przy
powiązaniu jeden lub wiele może występować również opcja żadne, oznaczana graficznie w postaci
okręgu.
Rys. 2.8 Związek jeden-do-wielu
Związek wiele-do-wiele (wielo-wieloznaczny)
Powiązania tego typu występują równie często jak powiązania jeden do wielu, jednak nie dają się
bezpośrednio implementować w relacyjnych bazach danych. Są one realizowane przy pomocy encji
pośrednich (w modelu relacyjnym są to tabele sprzęgające) powiązanych z encjami pierwotnymi przy
pomocy powiązań jeden do wielu.
W powiązaniu wiele-do-wiele encjami głównymi są encje pierwotne, natomiast encją obcą jest relacja
sprzęgająca, która zwiera klucze główne relacji oryginalnej. Dlatego w powiązaniu jeden-do-wiele
pomiędzy relacjami pierwotnymi, a relacją obcą, po stronie relacji oryginalnej znajduje się strona "jeden"
powiązania jeden-do-wiele a po stronie relacji obcej znajduje się strona "wiele" z tego powiązania. Związki
wiele-do-wiele nie są bezpośrednio implementowane w relacyjnych bazach danych i wymagają
dodatkowych przekształceń.
Rys. 2.9 Związek wiele-do-wielu
Związki unarne
Powiązania tego typu mają tylko jednego uczestnika, czyli relację, która jest powiązana sama ze sobą.
Powiązania są realizowane jest w podobny sposób jak powiązania binarne, z tym że odnosi się to do jednej
encji. Klucz główny tej encji jest dodawany do tejże encji.
Rys. 2.10 Związek unarny
Powiązania unarne tak jak powiązania binarne mogą być różnej mocy. To znaczy mogą występować
powiązania jeden do wielu, które mogą być opcjonalne po stronie "jeden". Ten typ powiązania jest
stosowany przy odwzorowywaniu struktur hierarchicznych.
Powiązania unarne mogą być również realizowane jako powiązania wiele do wielu. Wtedy, podobnie jak
przy powiązaniach binarnych, muszą być modelowane przy użyciu tabeli sprzęgającej.
 Związki ternarne
Są to powiązania w skład których wchodzą trzy związane ze sobą encje. Powiązania te, podobnie jak
powiązania wiele-do-wiele, nie mogą być realizowane bezpośrednio w relacyjnych bazach danych.
Rys. 2.11 Związek ternarny
Związki ternarne nie są bezpośrednio implementowane w relacyjnych bazach danych i wymagają
dodatkowych przekształceń.
Notacje związków
W praktyce spotkasz się z różnymi sposobami reprezentacji graficznej związków (dla przykładu: w
programach służących m.in. do projektowania diagramów ERD takich jak Visio lub Rational Rose możliwe
jest użycie kilku różnych notacji). Bodaj najpopularniejsza jest notacja czysto graficzna. Poniżej
prezentujemy sposób, w jaki za pomocą notacji graficznej można oznaczyć typ powiązania.
Rys. 2.12 Graficzna notacja typów powiązania
Metody przekształcania związków
Związki binarne wiele-do-wiele oraz związki ternarne nie są implementowane w relacyjnych
bazach danych. Dlatego wymagają one pewnych przekształceń. Przykłady takich przekształceń
zaprezentowane są poniżej
Przekształcanie związków wielo-wieloznacznych
Jeśli mamy związek binarny wielo-wieloznaczny, to należy wprowadzić dodatkową encję oraz
dwa nowe związki jednoznaczne. Nowa encja powinna wśród atrybutów zawierać klucze obce odnoszące
się do kluczy głównych dwóch pozostałych encji.
Rys. 2.13 Przekształcanie związków binarnych wielo-wieloznacznych
Przekształcanie związków ternarnych
Przy przekształcaniu związków ternarnych postępujemy podobnie jak w wypadku związków
wielo-wieloznacznych binarnych. Wprowadzamy wówczas dodatkową encję oraz 3 nowe związki
jednoznaczne.
Rys. 2.14 Przekształcanie związków ternarnych
Model relacyjny
Relacje i terminologia związana z modelem relacyjnym
W klasycznym modelu relacyjnym pod pojęciem relacji rozumie się dwuwymiarową tablicę.
Rys. 2.15 Relacja jako dwuwymiarowa tablica
Relacja zdefiniowana jest poprzez tak zwany schemat relacji. Schemat relacji stanowi coś na kształt
definicji tabeli. Składa się on z nazwy relacji oraz zbioru atrybutów relacji.
Określenie schematu relacji wraz z przykładami zapisu relacji pokazane jest na rysunku 2.16.
Rys. 2.16 Określenie schematu relacji i przykłady zapisu
Do definicji schematu relacji często dodaje się jeszcze określenie dziedzin dla poszczególnych atrybutów
relacji.
Schemat relacji można rozumieć jako pustą tabelę ze zdefiniowaną nazwą oraz nagłówkami kolumn.
Kolejnym pojęciem jest krotka (inaczej rekord - ang. tuple lub record). Krotką nazywamy każdy wiersz
relacji, oczywiście z wyjątkiem wiersza nagłówkowego. Krotki mogą być zapisane w postaci
uporządkowanego ciągu albo w postaci zależności funkcyjnych tak jak to jest przedstawione na rysunku.
Pierwszy z tych zapisów wymaga do prawidłowego odczytania krotki znajomości definicji schematu
relacji, jest natomiast znacznie krótszy.
Rys. 2.17 Krotka i jej zapis
Zbiór krotek danej relacji tworzy instancję relacji (ang. recordset). Warto zwrócić uwagę, że schemat
relacji w czasie cyklu życia bazy danych jest w zasadzie niezmienny (lub podlega bardzo rzadkim
zmianom), natomiast instancja relacji może zmieniać się w bazie bardzo często.
W wielu implementacjach systemów baz danych można się spotkać z różnym słownictwem dotyczącym
modeli relacyjnych. Na przykład w polskiej wersji MS Access pod pojęciem relacji rozumie się związek
(choć jak wiadomo, oba pojęcia oznaczają zupełnie co innego), natomiast na określenie relacji stosuje się
pojęcie tabeli (te dwa pojęcia są akurat równoważne). Trzeba się więc mieć na baczności, aby nie pogubić
się w tej plątaninie różnych pojęć stosowanych do określenia różnych rzeczy.
Podstawowe działania na relacjach
Do podstawowych działań, które możemy wykonywać na relacjach należą:
" suma (ang. union),
" różnica (ang. difference),
" przecięcie (ang. engraving),
" iloczyn kartezjański (ang. descartes-product),
" rzut (ang. projection),
" selekcja (ang. selection),
" złączenie (ang. join),
" złączenie teta (ang. teta join).
Omówimy je krótko i zilustrujemy przykładami.
Suma relacji
Sumą relacji nazywamy relację, której instancja jest suma instancji tych relacji.
Rys. 2.18 Przykład sumy relacji
Uwaga: Aby działanie to było wykonalne, oba schematy relacje muszą mieć te same zbiory atrybutów.
 Różnica relacji
Różnicą relacji nazywamy relację, której instancja jest różnicą teoriomnogościową instancji tych relacji.
Rys. 2.19 Przykład różnicy relacji
Uwaga: Aby działanie to było wykonalne, oba schematy relacje muszą mieć te same zbiory atrybutów.
Przecięcie relacji
Przecięciem relacji nazywamy relację, której instancja jest iloczynem teoriomnogościowym instancji tych
relacji.
Rys. 2.20 Przykład przecięcia relacji
Uwaga: Aby działanie to było wykonalne, oba schematy relacje muszą mieć te same zbiory atrybutów.
 Rzutowanie relacji
Wartością rzutu A1,A2,...,An(R) jest relacja, która powstaje z R przez przepisanie wszystkich atrybutów A1,
A2, ..., An. Mówimy wówczas o rzutowaniu relacji w kierunku A1, A2, ..., An. Operacja rzutowania zmienia
schemat relacji.
Rys. 2.22 Przykład rzutowania relacji
Selekcja
W wyniku zastosowania operatora selekcji powstaje nowa relacja, do której należy pewien podzbiór krotek
relacji R spełniający warunek F.
Rys. 2.23 Przykład selekcji
Złączenie
Operacja złączenia polega na połączeniu w pary tych krotek z relacji R oraz S, które mają identyczne
wartości dla określonych atrybutów.
Rys. 2.24 Ilustracja złączenia relacji
Normalizacja
Normalizacja danych jest sformalizowaną procedurą stosowaną podczas projektowania bazy
danych w celu uniknięcia pewnego typu anomalii, do których należą:
" - redundancja,
" - anomalie modyfikacji,
" - anomalie usunięć.
Redundancja jest nieuzasadnioną powtarzalnością danych w kilku krotkach. Skutkiem nadmiernej
redundancji może być zwiększone zapotrzebowanie na pamięć dyskową do przechowywania danych i
wydłużony czas przeszukiwania danych.
Anomalie modyfikacji są również zjawiskiem niepowołanym, ponieważ może się zdarzyć, że wartość
danej zostanie zmodyfikowana w pewnej krotce, a w innej nie.
Podobne anomalia mogą zachodzić przy usuwaniu danych, ta sama wartość może nie być usunięta ze
wszystkich miejsc, w których występuje. Generalnie anomalia te poprzez duplikowanie danych powodują
brak spójności.
Normalizację modelu danych przeprowadza się poprzez bezstratną dekompozycję relacji. Sprowadza się
ona do podziału atrybutów relacji pomiędzy schematy nowych relacji. Następnie następuje połączenie
(powiązanie) nowo powstałych relacji między sobą przy pomocy odpowiednich atrybutów. Reguła
dekompozycji obejmuje również podział krotek relacji wejściowej między nowe relacje. Połączenie między
relacjami powinno być zrealizowane w taki sposób, aby odbyło się bez straty żadnej informacji
Przy normalizacji danych można przekształcić relację do jednej z sześciu postaci normalnych.
Pierwsza postać normalna
Relacja jest w pierwszej postaci normalnej, jeżeli domeny zdefiniowane dla jej atrybutów są skalarne
(atomowe), czyli każdy atrybut krotki musi zawierać pojedynczą wartość (każde pole w tabeli musi
zawierać tylko jeden typ danych i każdy element musi być przechowywany w jednym miejscu).
Rys. 2.27 Przykład relacji nie będącej w pierwszej postaci normalnej
Rys. 2.28 Przykład relacji w pierwszej postaci normalnej
 Druga postać normalna
Relacja jest w drugiej postaci normalnej, jeżeli jest w pierwszej postaci normalnej, a ponadto wszystkie jej
atrybuty zależą od całego klucza głównego, a nie od innych pól tabeli.
Rys. 2.29 Przykład przekształcenia relacji do drugiej postaci normalnej
Trzecia postać normalna
Relacja jest w trzeciej postaci normalnej, jeżeli jest w drugiej postaci normalnej, a ponadto wszystkie
atrybuty niekluczowe są wzajemnie niezależne, czyli istnieje możliwość zmiany jednego pole w tabeli bez
konieczności przeliczania lub zmiany innych pól tejże tabeli.
Rys. 2.30 Przykład przekształcenia relacji do trzeciej postaci normalnej
Postać normalna Boyce'a/Codda
Relacja jest postaci normalnej Boyce'a/Codda wtedy i tylko wtedy, gdy każdy wyznacznik jest kandydatem
na klucz.
Jest to odmiana trzeciej postaci normalnej, dotyczy szczególnego rodzaju relacji, kiedy atrybuty
kandydujące na klucz są: wielokrotne, złożone lub nakładają się na siebie.
Czwarta postać normalna
Relacja jest w czwartej postaci normalnej, jeżeli jest w trzeciej postaci normalnej i nie zawiera
"wielowartościowej zależności" atrybutów.
Piąta postać normalna
Relacja jest w piątej postaci normalnej, jeżeli jest w czwartej postaci normalnej, a jej dekompozycja i
ponowne połączenie nie są operacjami symetrycznymi, nie prowadzą do rekonstrukcji tablicy początkowej.
Trzy pierwsze postaci normalne zostały zawarte w modelu relacyjnym opracowanym przez dr E. F. Codda
w 1970 r. i są często stosowane przy normalizacji danych, natomiast trzy kolejne postaci normalne
wykorzystywane są dosyć rzadko.