Baza danych z profilu

Podstawowa baza danych typowego systemu gospodarczego obsługuje dużą liczbę prostych operacji przetwarzania danych. Procesy o charakterystyce matematyczno-technicznej, korzystające z mniejszej liczby modułów informacyjnych, przetwarzanych zwartymi, aczkolwiek złożonymi algorytmicznie procedurami, można zatem traktować jako odrębne rozwiązania specjalizowane. Występowanie w systemie różnych typów procesów przetwarzania danych pociąga za sobą konsekwencje organizacyjne dla skojarzonych z nimi zasobów informacyjnych. Mamy bowiem do czynienia z dwoma profilami baz danych: gospodarczym (ekonomicznym) i technicznym (matematycznym).

I tak metody zarządzania bazami drugiego profilu mają charakter bardziej zdeterminowany i dają się dobrze opisywać statycznymi algorytmami typu matematycznego. Natomiast dla baz danych profilu pierwszego odpowiadające im metody zarządzania mają charakter dynamiczny, co ogranicza możliwość ich opisu za pomocą wąsko rozumianych, klasycznych algorytmów typu sekwencyjnego. W tym przypadku celowe jest zastępowanie metod opisu, oferowanych przez uniwersalny aparat matematyczny, metodami heurystyczno-empirycznymi. Opis taki cechuje się relatywizmem, gdyż zasadniczo nie specyfikuje samej metody, a jedynie sposób jej konstruowania.

Profil bazy danych będzie rzutował na specyfikę rozwiązań zastosowanych w jej otoczeniu, np. sprzętowych. Jeśli spojrzymy na ideę komputera sieciowego, to jej rozpowszechnienie się oznaczałoby faktyczną zmianę paradygmatu informatycznego w zakresie przetwarzania danych po stronie użytkownia. Aby odpowiedzieć na pytanie: Dla kogo network computer?, wystarczy porównać bazę danych dla instytucji finansowej (bank), gdzie aspekty komunikacyjno/sieciowe i bezpieczeństwo danych odgrywają rolę pierwszoplanową, z firmą „inżynierską", której potrzebne są wydajne, specjalizowane stanowiska pracy do projektowania wymagającego intensywnego przetwarzania grafiki (CAD).

Obiektowa orientacja

O ile kilka lat temu można było w tym obszarze mówić raczej o obiektowej dezorientacji, dziś sytuacja jest bardziej klarowna. Rok 1993 uważano za przełomowy dla technologii obiektowych baz danych. Wówczas wydawało się, że standardy ODMG-93 (Object Database Management Group) będą odgrywać dla obszaru OZBD (Obiektowo-Zorientowanych Baz Danych) podobną rolę, jak SQL w sferze modeli relacyjnych. Według prognozy Thomasa Artwooda (Object Design) z tamtego okresu, w roku 1997 niemal 3/4 wszystkich sprzedanych baz danych będzie miało charakter obiektowy – wystarczy wyjrzeć z okna, żeby przekonać się, jak jest w rzeczywistości.

Takie twierdzenia były wtedy symptomatyczne, a zaprzeczanie im należało do rzadkości, tymczasem wspomniany wymóg uwzględniania hybrydowości (heterogeniczności) informatyki wskazuje na możliwość koegzystencyjnego istnienia różnych modeli danych obok siebie. Zresztą i teraz historia lubi się powtarzać – wystarczy wskazać na relacyjne nakładki dla baz CODASYL-owskich, a nawet sytuacje odwrotne, kiedy to pod relacyjnym interfejsem projektanta baz danych ukrywano hierarchiczno-sieciowe struktury (!) – łatwo domyślić się, że związane to było ze słabszą wydajnością (performance) relacyjnych baz danych w początkowym okresie ich istnienia. Obecnie także jesteśmy w okresie łączenia paradgmatów obiektowych i relacyjnych w nową jakość.

Konsekwencją przyjętej strategii łączenia osiągnięć technologii obiektowej z relacyjną jest konieczność znalezienia metody, umożliwiającej taką konsolidację. Aktualnie istniejące w tym zakresie metody sprowadzają się do dwóch głównych tendencji:

bezpośrednie zastosowanie obiektowo-zorientowanych baz danych

dodawanie mechanizmów obiektowej orientacji do istniejących systemów baz danych.

W pierwszym przypadku stajemy przed wyborem słabo standaryzowanych systemów pochodzących od niewielkiej grupy małych firm software’owych. Przede wszystkim zaś rozwiązanie takie niezbyt dobrze uwzględnia fakt, iż wiele stosowanych w praktyce systemów baz danych opiera się na modelach relacyjnych lub nawet hierarchiczno-sieciowych. Podejście to, chociaż obiecujące na przyszłość, może być obecnie traktowane jedynie jako możliwy wariant o charakterze specjalnym. W drugim przypadku mamy do czynienia z rozwiązaniem przejściowym, sensownym wszędzie tam, gdzie decydujemy się na proces migracji systemowej do obiektowo-zorientowanych (obiektowych) baz danych. Wariant ten w złagodzonej formie wykazuje wady rozwiązania pierwszego, w szczególności może wymagać dodatkowego oprogramowania.

Zwróćmy uwagę na koncepcyjną różnicę w wariancie drugim, między implementacją własnego oprogramowania (wycinkowość podejścia) a zakupem nowej bazy danych od stabilnego producenta (systemowość). Taka uniwersalna baza danych o charkterze relacyjno-obiektowym ROBD (Relacyjno-Obiektowa Baza Danych) w większym stopniu gwarantuje nam również wielowariantowość i otwartość podejścia, jak też jego heterogeniczność. Lecz wcześniej mówiliśmy, że np. zakup bazy danych determinuje stosowanie określonych standardów, np. poziomu SQL. Decydując się zatem na określone oprogramowanie Informix czy Oracle, możemy czuć się zwolnieni z obowiązku myślenia w kwestii łączenia paradygmatów (?). Jest to rozumowanie poprawne tylko pozornie.