Funkcjonalność relacyjnej i obiektowej bazy danych po usunięciu z

Funkcjonalność relacyjnej i obiektowej bazy danych
po usunięciu z modelu atrybutów przyjmujących wartości Null
Dariusz Put
Akademia Ekonomiczna w Krakowie
Streszczenie: Jedną z cech dobrego projektu bazy danych jest niewystępowanie wartości
pustych (Null) w żadnym z atrybutów. Aby ten postulat był spełniony, należy niekiedy dokonać
korekty w projekcie, co jest inaczej realizowane w modelu relacyjnym a inaczej w obiektowym. W artykule podjęto próbę porównania wybranych aspektów obiektowej i relacyjnej bazy
danych zaprojektowanych tak, aby atrybuty nie przyjmowały wartości Null.
Abstract: One of the features of a good database project is that there are no null values in
any of the attributes. To obtain such a database it is sometimes necessary to change the
project. The process of such changes is different in relational and object-oriented models. The
article presents an attempt to compare selected aspects of object-oriented and relational
database in which there are no null values in attributes.
I. Wstęp
Bazy danych są wykorzystywane do trwałego przechowywania danych. Stanowią podstawę większości aplikacji, które używają danych zapisanych na trwałe w pamięci komputera.
Prawidłowy projekt bazy danych ma decydujące znaczenie dla efektywności, szybkości i poprawności działania całego systemu.
Po opublikowaniu przez E. F. Codda w 1970 roku teoretycznych podstaw relacyjnego
modelu danych zaczęły powstawać systemy zarządzania bazami danych (SZBD) oparte na
tym modelu. E. F. Codd zdefiniował pojęcie krotki jako jednostki służącej do przechowywania danych oraz relacji jako zbioru krotek. Krytycy modelu relacyjnego wskazują na szereg
jego ograniczeń, zwracając szczególną uwagę na:
– niewielką liczbę typów danych,
– spłaszczenie rzeczywistości – dane są przechowywane w relacjach będących zbiorem jednorodnych krotek,
– nieadekwatność – reprezentacja istniejących obiektów i zachodzących zdarzeń w bazie danych musi być poprzedzona dostosowaniem zapisywanych danych do założeń modelu,
– złożona składnia zapytań wybierających.
Niedogodności te spowodowały, że wielu badaczy podjęło prace nad stworzeniem
modelu, który bardziej adekwatnie odzwierciedlałby rzeczywistość. Powstanie i szybki rozwój obiektowych języków programowania przyczyniły się do skierowania poszukiwań w kierunku modelu obiektowego, który z jednej strony ma lepiej odzwierciedlać rzeczywistość
i być łatwiejszy w implementacji i eksploatacji, z drugiej ma wychodzić naprzeciw technologii obiektowej i być zgodny z obiektowymi językami programowania, co z kolei ma ułatwić
integrację aplikacji bazodanowych z tymi językami. Obecnie istnieją na rynku SZBD oparte
zarówno na modelu relacyjnym jak i obiektowym1.
Jednym z elementów procesu projektowania systemu informacyjnego jest stworzenie
bazy danych, która będzie przechowywała dane o istniejących obiektach i zachodzących zdarzeniach, umożliwi rejestrację tych obiektów i zdarzeń oraz pozwoli na efektywną manipulację danymi, ich wyszukiwanie i prezentację. W procesie projektowania relacyjnej bazy danych wykorzystywane są najczęściej zasady normalizacji – każda kolejna wersja bazy danych
powinna być zgodna z wyższą postacią normalną2. W modelu obiektowym stosowane są mechanizmy znane z obiektowych języków programowania: klasy i obiekty, dziedziczenie, enkapsulacja, specyfikacja, agregacja, itp. Niezależnie od tego, czy baza danych zostanie stworzona w oparciu o model obiektowy, czy relacyjny, musi być w pełni funkcjonalna.
Jedną z zasad, którymi należy się kierować podczas tworzenia projektu bazy danych
jest, aby żaden z atrybutów nie przyjmował wartości pustej (Null). Jeśli na pewnym etapie
projektu okaże się, że ze względu na specyfikę przechowywanych wartości dla niektórych
obiektów lub zdarzeń część atrybutów przyjmuje wartość Null, należy dokonać takich zmian
w projekcie aby był on nadal adekwatny do modelowanej rzeczywistości ale wolny od takich
anomalii.
Aby usunąć z projektu relacyjnej bazy danych atrybuty, które mogłyby przyjmować
wartości puste, należy utworzyć dwie tabele: podstawową oraz tabelę-podzbiór zawierającą
atrybuty opisujące bardziej szczegółowo temat tabeli podstawowej. Tabele te należy połączyć
relacją jeden-do-jednego, gdzie tabela-podzbiór otrzyma status tabeli związanej, i przenieść
do tabeli-podzbioru atrybuty, w których występowałyby wartości puste, gdyby tabela ta nie
istniała, oraz pozostawić w tabeli podstawowej atrybuty, które są charakterystyczne dla
wszystkich obiektów lub zdarzeń.
W modelu obiektowym do rozwiązywania tej klasy problemów wykorzystywany jest
mechanizm dziedziczenia. Tworzy się klasę nadrzędną z atrybutami, które występują we
1
2
Są także systemy obiektowo-relacyjne łączące w sobie elementy modelu relacyjnego i obiektowego.
W teorii relacyjnych baz danych wyróżnia się sześć postaci normalnych.
wszystkich obiektach oraz klasę potomną dziedziczącą atrybuty klasy nadrzędnej i zawierającą dodatkowe atrybuty, które ze względu na ich specyfikę w przypadku niektórych obiektów bądź zdarzeń przyjmowałyby wartość pustą.
W artykule dokonana zostanie próba analizy porównawczej funkcjonalności modelu
relacyjnego i obiektowego po dokonaniu modyfikacji bazy danych wymuszonej potrzebą
uniknięcia występowania wartości pustych niektórych atrybutów. Porównane zostaną wszystkie aspekty bazy danych, tzn.:
– projekt fizyczny,
– manipulowanie danymi (dodawanie, usuwanie, modyfikowanie),
– wyszukiwanie danych.
W bazie danych rejestrowane są obiekty i zdarzenia występujące w świecie rzeczywistym. W modelu obiektowym pojęcie obiektu jest używane w odniesieniu do instancji klasy.
Aby uniknąć niejednoznaczności, w dalszej części artykułu będzie mowa o faktach, które
mają być rejestrowane w bazie danych oraz o obiektach jako instancjach klasy.
W relacyjnym modelu danych termin relacja jest stosowany dwojako: w znaczeniu
zbioru krotek oraz jako połączenie między tabelami. Ponieważ funkcjonuje także pojęcie
tabeli, które – pod pewnymi warunkami – jest tożsame z relacją rozumianą jako zbiór krotek,
w dalszej części artykułu termin relacja będzie używany w znaczeniu połączenia między tabelami, a dla określenia zbioru krotek będzie używane pojęcie tabeli.
II. Projekt fizyczny bazy danych
Załóżmy, że fakty są reprezentowane przez m atrybutów. Ze względu na specyfikę
przechowywanych wartości k spośród m atrybutów istnieje w przypadku każdego faktu,
pozostałe l atrybutów występuje tylko dla niektórych, przy czym k+l=m.
Aby zapobiec występowaniu wartości pustych w bazie danych, w modelu relacyjnym
należy utworzyć dwie tabele: podstawową (nazwijmy ją A), zawierającą k atrybutów oraz
tabelę-podzbiór (B) zawierającą pozostałe l atrybutów. Tabele te należy połączyć relacją
jeden-do-jednego. A będzie tabelą podstawową z kluczem podstawowym o nazwie AKP,
B będzie tabelą związaną z kluczem podstawowym BKP. Kluczem obcym będzie pole BKP
występujące w tabeli B.
Fizyczny model relacyjny przedstawia się następująco:
CREATE TABLE A (
AKP typ_pola atrybuty_pola PRIMARY KEY,
k atrybutów istniejących dla wszystkich faktów);
CREATE TABLE B (
BKP typ_pola atrybuty_pola PRIMARY KEY,
l atrybutów istniejących dla niektórych faktów,
FOREIGN KEY BKP REFERENCES A(AKP));
W przypadku modelu obiektowego należy utworzyć klasę macierzystą (A) z k atrybutami, które istnieją dla każdego faktu i klasę potomną B, która będzie zawierać l atrybutów
istniejących tylko dla niektórych faktów oraz będzie dziedziczyć wszystkie atrybuty klasy A.
Fizyczny model obiektowy3:
CLASS A
TYPE TUPLE (k atrybutów istniejących dla wszystkich faktów)
END;
CLASS B INHERIT A
TYPE TUPLE (l atrybutów istniejących dla niektórych faktów)
END;
3
Wykorzystano składnię języka definicji używaną w systemie O2.
Porównując obydwa rozwiązania należy zauważyć, że model obiektowy jest bardziej
intuicyjny w implementacji: nie wymaga tworzenia kluczy podstawowych oraz łączenia tabel
i ustalania atrybutów tak utworzonej relacji. Baza danych oparta jest na dwóch klasach, z których jedna jest nadrzędna a druga potomna i dziedziczy atrybuty klasy nadrzędnej.
III. Manipulowanie danymi
Dane w tabelach (w modelu obiektowym w obiektach) A i B są powiązane. Należy
więc rozpatrzyć problem funkcjonalności opisywanego fragmentu bazy danych pod kątem
możliwości manipulowania danymi, czyli dopisywania, usuwania i modyfikacji.
1. Dopisywanie danych
W rozważanej sytuacji mogą istnieć dwa rodzaje faktów: takie, które są opisywane
wyłącznie przez atrybuty k i dla których nie występują atrybuty l oraz takie, które są opisywane zarówno przez atrybuty k jak i l. Zauważmy, że nie może wystąpić sytuacja, że fakt jest
opisywany wyłącznie przez atrybuty l.
W modelu relacyjnym fakt charakteryzujący się wszystkimi m atrybutami zostanie
zarejestrowany w postaci dwóch rekordów: jednego w tabeli A oraz odpowiadającego mu rekordu w tabeli B. Obydwa będą miały tę samą wartość w polach będących kluczami podstawowymi tabel (czyli w AKP i w BKP), co będzie jednoznacznie wskazywać, że są ze sobą
powiązane i dotyczą tego samego faktu. Jeśli fakt będzie opisywany wyłącznie przez k atrybutów, zostanie zarejestrowany w postaci rekordu w tabeli A.
W modelu obiektowym rejestracja faktu posiadającego wyłącznie k atrybutów wymagać będzie utworzenia obiektu klasy macierzystej (A), natomiast faktu opisywanego przez
wszystkie m atrybutów utworzenia obiektu klasy potomnej (B).
2. Usuwanie danych
W modelu relacyjnym usunięcie faktu opisywanego przez m atrybutów wymaga skasowania rekordu w tabeli podstawowej i odpowiadającego mu rekordu w tabeli-podzbiorze.
Jeśli w relacji zostanie ustawiona kaskadowa reguła usuwania, operacja będzie jednostopniowa – usunięcie rekordu z tabeli podstawowej pociągnie za sobą automatyczne skasowanie
odpowiadającego mu rekordu z tabeli-podzbioru. Jeśli ze względów bezpieczeństwa w relacji
ustawiona zostanie restrykcyjna metoda usuwania, operacja kasowania danych będzie dwustopniowa: najpierw wymagać będzie usunięcia rekordu z tabeli-podzbioru a potem z tabeli
podstawowej. Usunięcie danych o fakcie opisywanym przez k atrybutów będzie polegało na
skasowaniu jednego rekordu z tabeli A.
W przypadku faktu opisywanego przez m atrybutów usuwanie danych w modelu
obiektowym jest mniej złożone niż w relacyjnym. Operacja polega na usunięciu obiektu klasy
potomnej. Jeśli natomiast fakt jest opisywany przez k atrybutów, należy usunąć obiekt klasy
macierzystej.
3. Modyfikacja danych
Można wyróżnić dwa rodzaje modyfikacji danych zapisanych w rozważanym fragmencie w bazie danych:
– zmiana wartości jednego bądź kilku atrybutów istniejącego faktu,
– zmiana przynależności faktu, który z opisywanego przez m atrybutów może się stać opisywanym przez k atrybutów lub na odwrót.
W pierwszym przypadku operacja zostanie wykonana tak samo dla każdego z modeli.
Drugi wymaga odrębnej analizy.
W modelu relacyjnym, niezależnie od tego, którego typu jest to fakt, najpierw musi
zostać zarejestrowany w tabeli A (k atrybutów). Jeśli jego typ zmieni się na taki, który ma być
opisywany przez m atrybutów, operacja będzie wymagać dodania nowego rekordu do tabeli B
i wypełnienia go dodatkowymi l atrybutami. Jeśli fakt zmieni własności z opisywanego przez
m atrybutów stając się k-atrybutowym, operacja będzie polegała na usunięciu odpowiedniego
rekordu z tabeli B. W modelu relacyjnym zmiana rodzaju faktu jest więc wykonywana na
tabeli-podzbiorze i polega na dodaniu bądź usunięciu rekordu odpowiadającego faktowi zarejestrowanemu w tabeli podstawowej.
W modelu obiektowym fakt opisywany przez m atrybutów jest obiektem klasy potomnej, a opisywany przez k atrybutów obiektem klasy macierzystej. Zmiana własności faktu
z opisywanego przez m atrybutów na opisywany przez k atrybutów może być zarejestrowana
dwojako:
– poprzez przypisanie wartości pustej l atrybutom w obiekcie klasy potomnej, do której
obiekt należy – takie rozwiązanie jest nie do zaakceptowania, gdyż oznacza, iż w bazie
danych będą występowały wartości puste,
– poprzez usunięcie obiektu klasy potomnej i utworzenie obiektu klasy macierzystej z przepisaniem k atrybutów opisujących fakt po zmianie – operacja taka będzie więc dwustopniowa.
Zmiana właściwości faktu w drugą stronę (z opisywanego przez k atrybutów na opisywany przez m atrybutów) wymaga wykonania podobnej operacji: usunięcia obiektu klasy macierzystej i utworzenia obiektu klasy potomnej z jednoczesnym przepisaniem usuniętych k i
dopisaniem nowych l atrybutów. Wykonanie tej operacji tylko na obiekcie klasy potomnej
bez usunięcia obiektu klasy macierzystej doprowadziłoby do niejednoznaczności – w bazie
danych istniałyby dwa obiekty reprezentujące ten sam fakt: jeden klasy macierzystej, drugi
potomnej.
Można wskazać dwie sytuacje, w których opisywane zdarzenie może zaistnieć w rzeczywistości:
– typ każdego faktu jest znany podczas jego rejestracji i nie zmienia się dopóki fakt istnieje
w bazie danych – fakt jest zapisywany w odpowiedniej tabeli (lub tabelach) lub tworzony
jest obiekt odpowiedniej klasy,
– typ faktów może ulegać zmianie i w takiej sytuacji modyfikacja jest bardziej złożona w
modelu obiektowym niż w relacyjnym.
IV. Wyszukiwanie danych
Zakładając, że fakt opisywany przez l atrybutów musi być także opisywany przez k
atrybutów można wyróżnić następujące sytuacje w zakresie wyszukiwania danych4:
– wyszukiwanie faktów opisywanych przez wszystkie m atrybutów,
– wyszukiwanie faktów opisywanych tylko przez k atrybutów,
– wyszukiwanie wszystkich faktów (tych opisywanych przez m atrybutów łącznie z tymi
opisywanymi tylko przez k atrybutów).
W obydwu modelach do uzyskania danych odpowiadających powyższym założeniom
należy utworzyć zapytanie wybierające w języku SQL. Tworząc kwerendę w modelu relacyjnym należy użyć podzapytania albo złączeń: wewnętrznego (do wybrania faktów opisywanych przez m atrybutów) lub zewnętrznego (do wybrania wszystkich faktów).
Odpowiednie zapytania w języku SQL przedstawiają się następująco5:
– wyszukiwanie faktów opisywanych przez wszystkie m atrybutów – połączenie wewnętrzne pomija rekordy z tabeli podstawowej, które nie mają odpowiedników w tabeli związanej:
SELECT *
FROM A INNER JOIN B ON A.AKP=B.BKP;
– wyszukiwanie faktów opisywanych tylko przez k atrybutów – podzapytanie wybiera
wszystkie rekordy z tabeli B, klauzula NOT IN pozostawia tylko te rekordy z tabeli A,
które nie mają odpowiedników w tabeli B:
4
5
W rozważaniach pominięto problem selekcji danych.
Zapytania napisano w standardzie SQL-92.
SELECT *
FROM A
WHERE AKP NOT IN
(SELECT BKP FROM B);
– wyszukiwanie wszystkich faktów – połączenie zewnętrzne wybiera wszystkie rekordy
z tabeli A wraz z odpowiadającymi im rekordami z tabeli B:
SELECT *
FROM A LEFT JOIN B ON A.AKP=B.BKP;
W modelu obiektowym odpowiedź na powyższe pytania można uzyskać wybierając
obiekty należące do klasy macierzystej lub potomnej albo używając klauzuli ONLY dla tabeli
macierzystej. Zapytanie do obiektów klasy macierzystej można tak skonstruować, aby uzyskać wszystkie obiekty tej klasy oraz klas potomnych lub tylko obiekty klasy macierzystej.
Z drugiej strony zapytanie o obiekty klasy potomnej nigdy nie zwróci obiektów klasy macierzystej. Zapytania wybierające dane opisane powyżej przedstawiają się następująco:
– wyszukiwanie faktów opisywanych przez wszystkie m atrybutów – zapytanie wybierające
obiekty należące do klasy potomnej nie uwzględnia obiektów klasy macierzystej:
SELECT *
FROM B;
– wyszukiwanie faktów opisywanych tylko przez k atrybutów – zapytanie wybierające tylko
obiekty klasy A i pomijające obiekty klasy potomnej B:
SELECT *
FROM ONLY A;
– wyszukiwanie wszystkich faktów – zapytanie wybierające obiekty należące zarówno do
klasy A, jak i jej klasy potomnej B:
SELECT *
FROM A;
Należy zauważyć, że w modelu obiektowym zapytanie wybierające dane o wszystkich
faktach zwraca niepełne dane – dla faktów opisywanych przez m atrybutów zapytanie zwróci
tylko k a nie uwzględni pozostałych l. W modelu relacyjnym tabela będąca wynikiem zapytania będzie zawierała wszystkie atrybuty a dla faktów opisywanych tylko przez k atrybutów
kolumny dotyczące pozostałych l zostaną wypełnione wartościami pustymi.
V. Wnioski
W artykule podjęto próbę porównania funkcjonalności relacyjnego i obiektowego modelu bazy danych po wyeliminowaniu wartości pustych, które mogłyby wystąpić ze względu
na istnienie faktów opisywanych przez różną liczbę atrybutów.
Z przeprowadzonej analizy wynika, iż:
1. Obydwa modele są w pełni funkcjonalne w opisywanym zakresie: istnieje możliwość
utworzenie bazy danych, dowolnej modyfikacji danych oraz wyszukiwania.
2. Fizyczny model danych jest prostszy pod względem semantyki w przypadku modelu
obiektowego. Oprócz większej zwięzłości zapisu, nie występują tu relacje i klucze, dzięki
czemu reprezentacja rzeczywistości jest bardziej naturalna.
3. Sposób rejestracji nowych danych jest równie prosty w przypadku obydwu modeli i sprowadza się do utworzenia jednego lub dwóch rekordów w modelu relacyjnym albo utworzenia obiektu klasy macierzystej lub potomnej w modelu obiektowym.
4. Jeśli stan faktów ulega zmianie po ich zapisaniu w bazie danych, rejestracja jest mniej
złożona w modelu relacyjnym – polega na dodaniu bądź usunięciu jednego rekordu w tabeli-podzbiorze. W modelu obiektowym operacja wymaga usunięcia obiektu klasy potomnej (macierzystej), utworzenia obiektu klasy macierzystej (potomnej) i przepisania części
atrybutów z usuwanego do tworzonego obiektu.
5. Usuwanie faktów jest równie proste w obydwu przypadkach, przy czym w modelu relacyjnym poprzez ustawienie odpowiedniej reguły usuwania operacja może być dwustopniowa, co zmniejsza ryzyko przypadkowego usunięcia istotnych danych.
6. Konstruowanie zapytań do bazy danych jest łatwiejsze w modelu obiektowym. Semantyka
zapytań wymaga odwołania albo do obiektów klasy macierzystej albo potomnej. W modelu relacyjnym zapytania są bardziej złożone i wymagają użycia złączeń albo podzapytań.
7. Niektóre zapytania w modelu obiektowym nie są w pełni funkcjonalne. Kwerendy wybierające dane o wszystkich faktach nie uwzględniają atrybutów charakterystycznych tylko
dla niektórych. Pod tym względem model relacyjny jest bardziej funkcjonalny – jedną
kwerendą można uzyskać wszystkie dane znajdujące się w omawianym fragmencie bazy
danych.
8. W świetle przytoczonych rozważań nie można jednoznacznie stwierdzić, iż jeden z modeli lepiej nadaje się do implementacji opisywanego fragmentu rzeczywistości.
Literatura
[1] Beynon-Davies P., Systemy baz danych, WNT, Warszawa, 2003
[2] Date C. J., Wprowadzenie do systemów baz danych, WNT, Warszawa, 2000
[3] Ladanyi H., SQL. Księga eksperta, Helion, Gliwice, 2000
[4] Lausen G., Vossen G., Obiektowe bazy danych, WNT, Warszawa, 2000