Tabela 1.1. Przykładowa baza danych BIBLIOTEKA JEDNORODNA

Relacyjna baza danych

Zarządzanie prostą, jednorodną bazą danych zawierającą jedną tabelę nie wymaga zgłębiania teorii baz danych. Jednak większość przydatnych baz danych jest znacznie bardziej złożona niż baza przedstawiona wyżej. Prawdziwe bazy danych często posiadają setki tysięcy lub nawet miliony rekordów zawierających ściśle ze sobą powiązane dane. Właśnie w takich sytuacjach korzystanie z systemu zarządzania bazami danych ma sens. Przykładem może być - Biblioteka Kongresu USA - kolekcja ponad 16 milionów książek. Z powodów, które wkrótce staną się jasne, jedna tabela to po prostu za mało dla tak dużej bazy danych.

Nadmiarowość danych

Baza danych składająca się tylko z jednej tabeli zawiera zwykle powtarzające się, tj. nadmiarowe dane. Niektóre dane muszą się powtarzać, ale chodzi o to, by usunąć jak najwięcej powtarzających się danych.
Bez trudu można dostrzec obecność zbytecznych danych w tabeli BIBLIOTEKA JEDNORODNA (tabela 1.1). Na przykład nazwa i numer telefonu wydawnictwa Big House powtarza się sześć razy, a numer telefonu Shakespeare'a powtarza się trzy razy. Aby usunąć z bazy możliwie najwięcej zbytecznych danych, trzeba podzielić dane na wiele tabel.

Oto w jaki sposób można podzielić oryginalną bazę danych BIBLIOTEKA_ JEDNORODNA na cztery oddzielne tabele.

• Tabela KSIĄŻKI (tabela 1.2), w której każda książka ma własny rekord.
• Tabela AUTORZY (tabela 1.3), w której każdy autor ma własny rekord.
• Tabela WYDAWNICTWA (tabela 1.4), w której każde wydawnictwo ma własny rekord.
• Tabela KSIĄŻKA/AUTOR (tabela 1.5). Cel utworzenia tej tabeli zostanie wyjaśniony za chwilę.

Tabela 1.2. Tabela KSIĄŻKI bazy danych BIBLIOTEKA_JEDNORODNA

Tabela 1.3. Tabela AUTORZY bazy danych BIBLIOTEKA_JEDNORODNA

Tabela 1.4. Tabela WYDAWNICTWA bazy danych BIBLIOTEKA_JEDNORODNA

Tabela 1.5. Tabela KSIĄŻKA/AUTOR bazy danych BIBLIOTEKA_JEDNORODNA

Uwaga, teraz nazwa i numer telefonu wydawnictwa Big House występują tylko raz w bazie danych (w tabeli WYDAWNICTWA), podobnie jak numer telefonu Shakespeare'a (w tabeli AUTORZY). Oczywiście baza danych nadal zawiera powtarzające się dane. Na przykład informacja WydID pojawia się w kilku miejscach bazy danych. Jak wspomniano wcześniej, nie można wyeliminować wszystkich powtarzających się danych z jednoczesnym zachowaniem relacji między danymi.

Aby zdać sobie sprawę z korzyści wypływających z redukcji powtarzających się danych osiągniętych dzięki utworzeniu czterech tabel, wyobraźmy sobie, że baza danych zawiera też adres każdego wydawnictwa. W takiej sytuacji tabela 1.1 musiałaby mieć nową kolumnę zawierającą 14 adresów - większość z nich spowodowałaby zwiększenie ilości powtarzających się danych. Natomiast czterotabelowa baza danych potrzebowałaby tylko jednej nowej kolumny (w tabeli WYDAWNICTWA) zawierającej trzy różne adresy.

Aby lepiej zrozumieć tę różnicę, rozważmy przykład bazy danych Biblioteki Kongresu zawierającej 16 milionów książek. Załóżmy, że baza danych zawiera książki 10 000 różnych wydawnictw. Kolumna adresu wydawnictwa w jednorodnej bazie danych zawierałaby 16 milionów adresów, natomiast kolumna adresu wydawnictwa w relacyjnej bazie danych wymagałaby tylko 10000 adresów. Jeżeli przeciętny adres zawiera 50 znaków, użycie relacyjnej bazy danych zaoszczędziłoby:
(16 000 000 - l0 000) * 50 = 799 milionów znaków
Przy założeniu, że każdy znak to 2 bajty (jak w Unicode, wykorzystywanym przez Microsoft Access), JEDNORODNA baza danych marnuje około 1,6 GB pamięci na same tylko adresy.
Problem zbytecznych danych jest wystarczającym powodem do tego, by przekonać projektanta do unikania jednorodnych baz danych. Jednak z tym rodzajem baz danych wiążą się inne problemy.

Problemy z wartościami złożonymi

Niektóre książki w naszej bazie danych posiadają wielu autorów. W takiej sytuacji w jednorodnej bazie danych mamy do wyboru trzy opcje:

• Możemy umieścić wielu autorów w wielu wierszach -jeden wiersz dla każdego autora, jak uczyniono to w tabeli BIBLIOTEKA_JEDNORODNA (tabela 1.1) z książkami Balloon i Main Street.
• Możemy umieścić wielu autorów w wielu kolumnach w jednym wierszu -jedna kolumna dla jednego autora.
• Możemy umieścić nazwiska wszystkich autorów w jednej kolumnie tabeli.

W przypadku rozwiązania wielowierszowego problem polega na tym, że wszystkie dane o książce trzeba powtórzyć tyle razy, ilu jest autorów książki - oczywisty przypadek nadmiarowych danych. Z kolei w przypadku rozwiązania wielokolumnowego musimy zgadywać, ile kolumn autorów możemy kiedykolwiek potrzebować. Rozwiązanie to marnuje dużo pustych pól, gdy chodzi o książki posiadające tylko jednego autora, ponadto jest trudne w implementacji.

Trzecia opcja polega na umieszczeniu nazwisk wszystkich autorów w jednej komórce, co może powodować problemy innego typu. Na przykład trudniej znaleźć w bazie danych pojedynczego autora, a co gorsza, w jaki sposób stworzyć alfabetyczną listę autorów znajdujących się w tabeli?

Anomalie powstałe podczas uaktualniania

Aby w bazie danych BIBLIOTEKA_JEDNORODNA (tabela 1.1) uaktualnić np. numer telefonu wydawnictwa, należy dokonać zmian w każdym wierszu zawierającym ten numer. Jeżeli pominiemy któryś wiersz, wystąpi problem nazywany anomalią powstałą podczas uaktualniania i tabela przestanie być wiarygodna.

Anomalie powstałe podczas wstawiania danych

Kolejne problemy pojawią się, kiedy do bazy danych BIBLIOTEKA_JEDNORODNA (tabela 1.1) będziemy chcieli dodać informacje o wydawnictwie, o którego książkach nic jeszcze nie wiemy. Moglibyśmy dodać nowy wiersz do istniejącej tabeli i umieścić wartości NULL w trzech kolumnach związanych z wydawnictwem, ale może to wywołać problemy (NULL jest wartością, która ma wskazywać brakującą lub nieznaną wartość pola). Na przykład dodanie kilku takich wydawnictw oznacza, że kolumna ISBN, która powinna zawierać niepowtarzalną wartość, będzie zawierać kilka wartości NULL. Jest to anomalia powstała podczas wstawiania danych.

Anomalie powstałe podczas usuwania danych

Jeżeli usuniemy wszystkie książki związane z określonym wydawnictwem, utracimy również wszystkie informacje o tym wydawnictwie. Jest to anomalia powstała podczas usuwania danych. Przedstawiona tu lista potencjalnych problemów powinna nas przekonać, że stosowanie bazy danych zawierającej jedną tabelę nie jest najlepszym pomysłem. W dobrze zaprojektowanej bazie danych dane powinny być umieszczone w kilku tabelach, między którymi należy ustanowić relacje. Ponieważ relacje są opisywane poprzez tabele, taka baza danych jest określana mianem relacyjnej bazy danych.

Zapobieganie utracie danych

Projektując relacyjną bazę danych, musimy zadbać o to, by dane zostały umieszczone w wielu tabelach w taki sposób, aby nie utracić żadnych informacji. Gdybyśmy na przykład nie utworzyli w poprzednim przykładzie tabeli KSIĄŻKA/AUTOR (tabela 1.5), nie byłoby możliwe określenie autorów poszczególnych książek. Na dobrą sprawę, tabela KSIĄŻKA/AUTOR istnieje tylko po to, aby zachować relację książka-autor.

Utrzymywanie integralności relacyjnej

Modyfikując dane w bazie, musimy utrzymywać integralność różnych relacji między tabelami. Jeżeli na przykład chcemy usunąć wydawnictwo z bazy danych, nie wystarczy usunąć go z tabeli WYDAWNICTWA, ponieważ zerwałoby to referencję do tego wydawnictwa w tabeli KSIĄŻKI.

Tworzenie widoków (kwerend)

W przypadku umieszczenia danych w kilku tabelach utworzenie różnych widoków danych staje się trudniejszym zadaniem. Np. aby zobaczyć listę wszystkich wydawnictw wydających książki w cenie poniżej 10 zł, musielibyśmy zebrać dane z kilku tabel. Chodzi o to, że po umieszczeniu danych w oddzielnych tabelach często musimy zadać sobie trud złożenia danych ponownie w całość, aby uzyskać ich ogólny widok.

Podsumowanie

Aby uniknąć wystąpienia nadmiarowych danych i rozmaitych anomalii, należy tworzyć bazy danych zawierające wiele tabel powiązanych ze sobą relacjami. Jednak używanie relacyjnych baz danych powoduje pewne problemy: w jaki sposób zaprojektować tabele, aby nie doszło do utraty danych i w jaki sposób złożyć dane z wielu tabel w jedną całość, aby utworzyć różne widoki tych danych?