Put.pdf

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 obiekto-

wym. 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ą pod-

stawę 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 po-

prawnoś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 przechowywa-

nia 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 jed-

norodnych krotek,

– nieadekwatność – reprezentacja istniejących obiektów i zachodzących zdarzeń w bazie da-

nych 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 roz-

wój obiektowych języków programowania przyczyniły się do skierowania poszukiwań w kie-

runku modelu obiektowego, który z jednej strony ma lepiej odzwierciedlać rzeczywistość

i być łatwiejszy w implementacji i eksploatacji, z drugiej ma wychodzić naprzeciw technolo-

gii 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 obiektowym 1 .

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 zda-

rzeniach, umożliwi rejestrację tych obiektów i zdarzeń oraz pozwoli na efektywną manipu-

lację danymi, ich wyszukiwanie i prezentację. W procesie projektowania relacyjnej bazy da-

nych 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ą me-

chanizmy znane z obiektowych języków programowania: klasy i obiekty, dziedziczenie, en-

kapsulacja, specyfikacja, agregacja, itp. Niezależnie od tego, czy baza danych zostanie stwo-

rzona 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

Są także systemy obiektowo-relacyjne łączące w sobie elementy modelu relacyjnego i obiektowego.

2 W teorii relacyjnych baz danych wyróżnia się sześć postaci normalnych.

wszystkich obiektach oraz klasę potomną dziedziczącą atrybuty klasy nadrzędnej i zawiera-

jącą dodatkowe atrybuty, które ze względu na ich specyfikę w przypadku niektórych obiek-

tó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ą wszyst-

kie 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 rzeczywis-

tym. 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 ta-

belami, 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 atry-

butami, 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 obiektowy 3 :

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 O 2 .

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ą opisy-

wane 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 re-

kordu w tabeli B. Obydwa będą miały tę samą wartość w polach będących kluczami podsta-

wowymi 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 atry-

butów, zostanie zarejestrowany w postaci rekordu w tabeli A.

W modelu obiektowym rejestracja faktu posiadającego wyłącznie k atrybutów wyma-

gać 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 ska-

sowania 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 jednostop-

niowa – 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 dwu-

stopniowa: 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 frag-

mencie 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ć opisy-

wanym 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 zare-

jestrowanemu w tabeli podstawowej.

W modelu obiektowym fakt opisywany przez m atrybutów jest obiektem klasy potom-

nej, 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 prze-

pisaniem k atrybutów opisujących fakt po zmianie – operacja taka będzie więc dwustop-

niowa.

Zmiana właściwości faktu w drugą stronę (z opisywanego przez k atrybutów na opisy-

wany przez m atrybutów) wymaga wykonania podobnej operacji: usunięcia obiektu klasy ma-

cierzystej 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 rze-

czywistoś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 danych 4 :

– 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 rela-

cyjnym należy użyć podzapytania albo złączeń: wewnętrznego (do wybrania faktów opisywa-

nych przez m atrybutów) lub zewnętrznego (do wybrania wszystkich faktów).

Odpowiednie zapytania w języku SQL przedstawiają się następująco 5 :

– wyszukiwanie faktów opisywanych przez wszystkie m atrybutów – połączenie wewnętrz-

ne 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:

W rozważaniach pominięto problem selekcji danych.

5 Zapytania napisano w standardzie SQL-92.

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: