bd.pdf

Model konceptualny

jako wspólna platforma niejednorodnych modeli logicznych

Dariusz Put

Akademia Ekonomiczna w Krakowie

Streszczenie : W artykule omówiono założenia modelu konceptualnego, na podstawie,

którego tworzone są projekty baz danych niezależne od modeli logicznych. Pokazano, jak

model ten może być przekształcony do postaci logicznego modelu relacyjnego i obiektowego.

Omówiono także zagadnienie przygotowania danych zapisanych w relacyjnych bazach

danych dla obiektowo zorientowanych aplikacji oraz zwrócono uwagę na rolę, jaką w takim

przekształceniu może odgrywać uniwersalny model konceptualny.

Abstract : The features of a conceptual model, which is used in designing databases

independent of specific logical models, are discussed in the paper. It is described, how the

conceptual model may be transformed to relational or object-oriented logical model. The

paper discusses also the problem of preparing data stored in relational DBMS for object-

oriented applications and describes the role the universal conceptual model plays in such

a transformation.

I. Wstęp

Już kilka lat po opublikowaniu w 1970 roku przez E. F. Codda [7] podstaw modelu

relacyjnego zaczęły się pojawiać relacyjne systemy zarządzania bazami danych (SZBD).

W modelu tym przyjęto założenie, że dane o faktach, czyli obiektach i zdarzeniach,

przechowywane są w relacjach, które w pojawiających się kolejnych latach rozwiązaniach

praktycznych reprezentowane były (i nadal są) w postaci tabel. Ponieważ odzwierciedlony

w bazie danych fragment rzeczywistości jest zwykle złożony, rejestracja danych dotyczących

jednego faktu wymaga niejednokrotnie dokonania wpisu w wielu tabelach. Naturalna

złożoność faktów musi być przystosowana do założeń modelu relacyjnego i skonwertowana

w taki sposób, aby mogła być zapisana w systemie składającym się z „płaskich” tabel.

W latach osiemdziesiątych XX wieku zaczęły powstawać obiektowe języki

programowania, w których możliwe stało się tworzenie struktur danych na wyższym

poziomie abstrakcji niż w językach strukturalnych, bardziej zbliżonym do modelowanej

rzeczywistości. Istnienie możliwości reprezentacji obiektów w sposób odzwierciedlający ich

naturalną złożoność ułatwiło tworzenie procedur obiektowych i operowanie na faktach

występujących w opisywanym fragmencie rzeczywistości. Koncepcja obiektowych języków

programowania była rozwijana w kolejnych latach – języki te stanowią podstawę dla

zdecydowanej większości tworzonych obecnie aplikacji.

Metodologia obiektowa przyjęła się i jest powszechnie wykorzystywana w dziedzinie

programowania. Jest oczywiste, że aplikacje muszą niejednokrotnie korzystać z danych

zapisanych w systemach bazodanowych. Jednak w zakresie przechowywania danych, mimo

iż podejmowane są prace nad stworzeniem modelu obiektowego, a nawet powstało szereg

obiektowych SZBD 1 , dominujące są nadal systemy relacyjne. Można wskazać, co najmniej

dwie przyczyny takiego stanu:

1. Brak silnych podstaw teoretycznych dla modelu obiektowego.

Od momentu pojawienia się artykułu E. F. Codda cały czas trwają badania nad

modelem relacyjnym. Pojawiają się nowe pomysły i rozwiązania. Język SQL, umożliwiający

praktyczne implementacje baz danych w relacyjnych SZBD, był kilkakrotnie

standaryzowany. Dzięki temu model ten ma silne podstawy teoretyczne. Nie można tego

powiedzieć o modelu obiektowym. Nie opracowano dotychczas powszechnie akceptowanego

standardu, ani nawet modelu nieformalnego, co oznacza, że producenci systemów

implementują w nich własne pomysły i rozwiązania, przez co współdziałanie takich

systemów między sobą a także z aplikacjami tworzonymi w językach obiektowych jest

utrudnione. Problem ten trafnie skomentował C. J. Date [9] pisząc: „ Wiele pojęć ze świata

obiektowego – a przynajmniej opublikowane definicje tych pojęć – jest mocno nieścisłych. Nie

ma prawdziwej zgody, a jest dużo kontrowersji, nawet na najbardziej podstawowym poziomie.

W szczególności, nie ma abstrakcyjnego, formalnie zdefiniowanego ‘obiektowego modelu

danych’, ani nawet zgody, co do modelu nieformalnego w rezultacie tego stanu rzeczy

definicje i wyjaśnienia przedstawione w tej części książki [dotyczącej modelu obiektowego –

przyp. aut.] nie są powszechnie akceptowane i niekoniecznie odpowiadają sposobom

działania realnych systemów obiektowych. Prawie każde wyjaśnienie czy każda definicja

mogłyby być kwestionowane przez innego eksperta z tej dziedziny ” .

2. Ograniczone możliwości konwersji danych z modelu relacyjnego do obiektowego.

Istniejące SZBD to w większości systemy relacyjne. Zaprojektowane

i zaimplementowane bazy danych w znacznej większości działają, więc w tych systemach.

Próba konwersji bazy danych do obiektowego SZBD jest przedsięwzięciem ryzykownym

i zwykle nieefektywnym, gdyż wymaga przebudowy całego, niejednokrotnie bardzo

złożonego i sprawnie działającego systemu oraz utworzenia projektu obiektowego

1 Np. Illustra, O 2 , GemStone, ObjectStore.

179

implementowanego następnie w nie posiadającym podstaw teoretycznych obiektowo

zorientowanym SZBD. Konwersja systemu wymaga nie tylko zmiany sposobu

przechowywania danych, ale także przebudowy lub nawet napisania na nowo aplikacji, które

z tych danych korzystają.

Dane wykorzystywane w procedurach obiektowych są, więc zwykle pobierane

z systemów relacyjnych. Wiąże się z tym szereg problemów i niedogodności zagadnienie to

jest określane w literaturze jako tzw. „niezgodność impedancji”. Można wskazać kilka

sposobów rozwiązania tego problemu:

– konwersja systemu przechowywania danych na obiektowy – co, jak wyżej starano się

uzasadnić, jest trudne w realizacji, wiąże się bowiem z koniecznością przebudowy

systemu, i oznacza zwykle konieczność poniesienia dużych nakładów związanych

z wymianą modelu przechowywania danych, zakupem nowego SZBD oraz utworzeniem

aplikacji, w tym także interfejsu użytkownika,

– operowanie na danych w postaci „płaskich” tabel – oznacza to, że możliwości modelu

obiektowego nie będą w pełni wykorzystane, a w kodzie programu trzeba uwzględnić

różnicę w typach i sposobach reprezentacji danych pomiędzy modelem relacyjnym

(w którym przechowywane są dane) i obiektowym (w którym tworzone jest

oprogramowanie),

– zastosowanie warstwy pośredniej – dane zwracane przez zapytanie są wybierane z rela-

cyjnej bazy danych, w warstwie pośredniej są konwertowane na obiekty i w takiej postaci

przekazywane do procedur napisanych w języku obiektowym.

Ostatnie z zaproponowanych rozwiązań wydaje się najefektywniejsze. Wiąże się

jednak z koniecznością dokonania pewnej modyfikacji systemu i stworzenia mechanizmów

automatycznie konwertujących dane obiektowe na ich relacyjną reprezentację i na odwrót.

Potrzeba takiej konwersji musi być wpisana w projekt systemu.

Jednym z etapów cyklu życia bazy danych (por. rys. 1) jest proces projektowania.

Najpierw tworzony jest projekt konceptualny, niezależny od rozwiązań charakterystycznych

dla jakiegokolwiek modelu logicznego i SZBD. Następnie podejmowana jest decyzja

dotycząca typu zastosowanego modelu logicznego oraz tworzony jest projekt logiczny oparty

na wybranym modelu. Z kolei następuje wybór konkretnego SZBD zgodnego z wybranym

modelem logicznym i tworzony jest projekt fizyczny uwzględniający specyfikę wybranego

SZBD, który następnie jest implementowany w tym systemie.

Wspólną platformę dla różnorodnych modeli logicznych, która może być

wykorzystana do budowy warstwy pośredniej, może stanowić model konceptualny.

W artykule omówiono założenia tego modelu, umożliwiającego zaprojektowanie sposobu

przechowywania danych bez konieczności uwzględniania własności charakterystycznych dla

modeli logicznych. Opisano także modele logiczne: obiektowy i relacyjny i pokazano na

przykładzie praktycznym sposób przekształcenia projektu konceptualnego w logiczny,

uwzględniający specyfikę wybranej metody przechowywania danych.

II. Założenia modelu konceptualnego

Głównym celem konceptualnego modelowania bazy danych jest stworzenie projektu

odzwierciedlającego analizowany fragment rzeczywistości, wolnego od szczegółów, które

umiejscawiałyby go wśród modeli określonej klasy (obiektowych, relacyjnych lub innych)

oraz niezależnego od platformy programowej. Efektem końcowym procesu projektowania

konceptualnego jest identyfikacja zbioru faktów, o których dane mają być przechowywane

w bazie danych oraz związków między tymi faktami. W procesie tym uczestniczy zarówno

projektant, jak i przyszły użytkownik systemu. Na podstawie informacji przekazanych przez

180

przedstawicieli organizacji, dla której przygotowywana jest baza danych (przyszłego

użytkownika) tworzony jest projekt zawierający trzy rodzaje elementów:

fakty, czyli obiekty i zdarzenia o których dane mają być przechowywane w bazie danych,

atrybuty charakteryzujące poszczególne fakty,

typy powiązań między faktami.

Definicja celu

Określenie obszaru

zastosowań

projekt

bazy

danych

Projekt

konceptualny

Projektowanie

aplikacji

Projekt

logiczny

Wybór SZBD

Projekt

fizyczny

Implementacja

Testowanie

Eksploatacja

Konserwacja

Rys. 1. Cykl życia aplikacji bazy danych

(źródło: opracowanie własne na podstawie C. Begg, T. Connolly [2], s. 272).

Projekt jest najczęściej wyrażony w formie graficznej w postaci diagramu związków

encji oraz uzupełniony o opis słowny, w którym informacje zawarte w projekcie graficznym

są szczegółowo scharakteryzowane. Na diagramie fakty są oznaczane zwykle w postaci

prostokątów, atrybuty występują jako elipsy, a związki między faktami są oznaczone liniami

łączącymi prostokąty oraz symbolami umieszczonych obok tych linii, opisującymi typ

związku (por. rys. 2).

W modelu konceptualnym atrybuty mogą być zarówno proste, jak i złożone:

wielowartościowe i segmentowe. Atrybuty złożone są eliminowane w konkretnym modelu

logicznym, a sposób ich reprezentacji jest zależny od typu przyjętego modelu (obiektowy lub

relacyjny).

Na rysunku 2 zaprezentowano przykładowy projekt oparty na modelu konceptualnym.

Wyróżniono pięć faktów Osoba , Pracownik , Student , Wykładowca , Wykład )

charakteryzowanych przez atrybuty, wśród których można wyróżnić zarówno atrybuty proste

(atomowe) takich jest większość, jak i złożone. Atrybutami segmentowymi są Imię

i nazwisko oraz Adres charakteryzujące obiekt Osoba . Jedynym atrybutem

wielowartościowym jest Języki obce opisujący obiekt Pracownik . Obiekty Pracownik

i Student pochodzą od obiektu Osoba (wskazuje na to linia w postaci strzałki skierowanej

181

grotem w stronę faktu nadrzędnego). Charakter związku określony jako {Obowiązkowy, lub}

oznacza, że każdy obiekt Osoba musi być Pracownikiem albo (nigdy i) Studentem . Innymi

słowy, fakt zarejestrowania w bazie danych osoby musi być uzupełniony o wpis określający,

czy osoba ta jest studentem, czy pracownikiem. Związek między Pracownikiem

a Wykładowcą jest {Opcjonalny} , przy czym obiektem nadrzędnym jest Pracownik . Oznacza

to, że można rejestrować pracowników bez konieczności zapisywania wykładowców.

Umieszczenie w bazie danych o wykładowcy wymaga natomiast uprzedniego zarejestrowania

go jako pracownika (każdy wykładowca jest pracownikiem, ale nie każdy pracownik to

wykładowca). Wykładowcy prowadzą Wykłady , charakter związku wskazuje, że ten sam

wykładowca może prowadzić wiele wykładów, a każdy wykład jest prowadzony dokładnie

przez jednego wykładowcę. Między obiektami Student i Wykład istnieje, wielowartościowy

związek dwukierunkowy: student może uczęszczać na wiele wykładów, w jednym wykładzie

Adres

Imię i nazw.

Nr dowodu

Osoba

Jedn. org.

{Obowiązkowy, lub}

Pracownik

Student

0-n

Jęz. obce

Nr grupy

{Opcjonalny}

0-n

Wykładowca

1-1

0-n

Wykład

Tytuł nauk.

Katedra

Nazwa

Licz. godz.

może uczestniczyć wielu studentów.

Rys. 2 . Przykładowy projekt konceptualny (źródło: opracowanie własne).

III . Reprezentacja faktów w logicznym modelu relacyjnym

Wybór modelu relacyjnego za podstawę metody przechowywania danych oznacza, iż

należy przekształcić uniwersalny projekt konceptualny na projekt, w którym dane o faktach są

przechowywane w tabelach, a atrybuty, zgodnie z założeniami modelu relacyjnego, są

atomowe, co niekiedy oznacza konieczność utworzenia dodatkowych tabel i połączeń między

nimi. Projekt logiczny wyrażony w postaci diagramu stanowi w dalszej fazie procesu

podstawę do utworzenia projektu fizycznego i jego implementacji w wybranym relacyjnym

SZBD.

W modelu relacyjnym dane mogą być przechowywane, w zależności od złożoności

faktu, w jednej lub kilku tabelach, przy czym, jeśli wykorzystywanych jest kilka tabel, są one

zwykle połączone relacjami. Przekształcenie faktów występujących w projekcie

konceptualnym na tabele w logicznym projekcie relacyjnym wymaga przeprowadzenia

analizy uwzględniającej rodzaj powiązań występujących między faktami oraz złożoność

charakteryzujących je atrybutów. Dokonując przekształcenia należy zwrócić uwagę na

następujące aspekty:

1. Fakty są jednorodne, wszystkie opisywane przez tę samą liczbę atrybutów i wszystkie

atrybuty są atomowe. W takiej sytuacji jednemu faktowi odpowiada jedna tabela

182

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: