Расширенные ОРБД. 
Базы данных

К расширенным ОРБД относится СУБД Informix Universal Server [41,42]. С помощью этой разновидности ОРБД решают две группы задач: 1) хранение в БД данных большого объема; 2) трансформация реляционной модели (собственно БД) в объектно-реляционную модель данных.

Обсудим состояние решения этих задач.

Задача 1. Первоначально графические базы данных создавались так: отдельно формировались графические файлы, а в столбцах СУБД были лишь ссылки на эти файлы. Это требовало от программиста знания не только БД, но и системы файлов. В связи с этим в состав СУБД были первоначально введены «простые большие объекты» (рис. 8.6) TEXT и BYTE с объемом до 1 Гбайт.

Вскоре выяснилось, что и такая размерность поля порой недостаточна, и были созданы интеллектуальные большие объекты Binary Large Object (BLOB) и CLOB размером до 4 Тбайт. Работа с такими объектами возможна только «по частям», для чего пришлось создать специальные дополнительные технологии.

Рис. 8.6. Большие объекты.

Задача 2. Идею расширения (системы данных) удобно иллюстрировать на примере [41] программы (среда Delphi, язык Object Pascal):

unit polimor_;

interface.

uses.

Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,.

StdCtrls;

type.

TForml = class (TForm).

Editl: TEdit;

Edit2: TEdit;

GroupBoxI: TGroupBox;

RadioButtonl: TRadioButton;

RadioButton2: TRadioButton;

Label 1: TLabel;

Label2: TLabel;

Button1:TButton;

Button2:TButton;

procedure Button 1Click (Sender: TObject);

procedure Button2Click (Sender: TObject);

private.

{ Private declarations}.

public.

{Public declarations}.

end;

type.

TPerson=class.

fname:string;{имя}.

constructor Create (name:string);

function info: string; virtual;

end;

TStud=class (TPerson).

fgrrinteger; {номер группы} constructor Create (name:string;gr:integer); function infoistring; override;

end;

TProf=class (TPerson).

fdep:string; {название кафедры}.

constructor Create (name:string;dep:string);

function info: string; override;

end;

const.

SZL=10; // размер списка.

var.

Forml: TFormt;

List: array[1 .SZL] of TPerson; // список.

n:integer; // кол-во людей в списке.

implementation.

{$R*.DFM}.

constructor TPerson. Create (name:string);

begin.

fname:=name;

end;

constructor TStud. Create (name :string ;gr: integer);

begin.

inherited create (name);

fgr:=gr;

end;

constructor TProf. create (name:string; dep: string);

begin.

inherited create (name);

fdep:=dep;

end;

function TPerson. lnfo:string;

begin.

result:=fname;

end;

function TStud. lnfo:string;

begin.

result:=fname+'гр .' +lntT oStr (fgr);

end;

function TProf. lnfo:string;

begin.

result:=fname+'каф .'+fdep;

end;

procedure TForml. Button1Click (Sender: TObject);

begin.

if n<=SZL then begin.

if Radiobutton 1.Checked.

then // создадим объект TStud.

List[n]: =TStud.Create (Edit1.Text, StrTolnt (Edit2.Text)).

else.

List[n]: =TProf.Create (Edit1.Text, Edit2. Text);

n:=n+1;

end.

else ShowMessage ('Список заполнен!');

end;

procedure TForml. Button2Click (Sender: TObject);

var.

i: integer;

st: string;

begin.

for i:=1 toSZL do.

if list[i] NIL then st:=st+list[i]. info+# 13;

ShowMessage ('Список'+# 13+st);

end;

end.

Из нее видно, что классы «Студент» (TStud) и «Профессор» (TProi) являются производными от класса «Личность» (TPerson). В качестве методов доступа к ним выступают функции TStud.Info.string, TProf.Info.string и TPerson.lnfo.string соответственно.

Язык программирования Object Pascal редко используется для формирования объектно-ориентированной модели базы данных. Чаще для этих целей применяют языки С++ и SQL.

Покажем на примерах использование языка SQL3 в СУБД Informix Universal Server.

В SQL3 используются те же типы данных, что и в SQL2. Однако SQL3 оперирует не таблицами, как SQL2, а объектами. В качестве таких объектов выступают новые (абстрактные) типы данных и система таблиц, образующих иерархию.

А. Абстрактные типы данных (рис. 8.7). Абстрактные типы данных, получившие в последнее время название «типы данных, определяемые пользователем» [2], — типы, задающие характеристики [3], но не реализации, наследуемые подтипом. Они непосредственно не порождают экземпляров.

В иерархии типов участвуют (рис. 8.7) ROW (неименованные строки), ROW TYPE (именованные строки), SET (неупорядоченный набор одного типа без повторения данных), MULTISET (то же, что и SET, с возможностью повторения данных), LIST (упорядоченный набор неуникальных данных одного типа, фактически — одномерный массив). Разнородные структуры добавляют каждый раз по одной строке к предыдущей строке, тогда как однородные структуры могут добавлять по нескольку строк к каждой предыдущей строке.

Рис. 8.7. Новые абстрактные типы данных Использование новых типов рассмотрим на системе таблиц, показанных на рис. 8.8. Иерархия требует множественного наследования. Поскольку оно не реализовано в рамках СУБД Informix Universal Server, ограничимся рассмотрением части иерархии, обведенной на рис. 8.8 пунктиром.

Рис. 8.8. Иерархия абстрактных типов данных и таблиц Речь должна пойти о построении типов данных, их заполнении и обновлении. Первоначально покажем использование типа данных ROW для элементов иерархии «Деканат», «Группа», «Студент», «Кафедра». Для иллюстрации в каждом структурном элементе используем только по два поля, а названия таблиц и полей выполним на русском языке.

CREATE ROW TABLE Деканат (.

Шифр_деканата integer,.

Название varchar (15),.

Группа ROW (.

Шифр_группы varchar (8),.

Название_группы varchar (5),.

Студент ROW (Шифр_студента varchar (8),.

Фамилия varchar (15)),.

Кафедра ROW (.

Шифр_кафедры integer,.

Название_кафедры varchar{50)).

);

Выборка данных осуществляется следующим образом.

SELECT шифр_деканата, группа. название_группы, группа.студент.фамилия.

FROM Деканат.

WHERE группа. название_группы='И5';

Заполнение (вставка) в такую структуру проводится так:

INSERT INTO Деканат.

VALUES (1/ПТИО',.

ROW ('И-99', 'И4',

ROW ('И-99/15', 'Петров')),.

ROW (1, 'ИиУС'));

В типе данных ROW структура строки (записи) каждый раз должна определяться отдельно. Это не позволяет использовать структуру ROW многократно.

Такую возможность предоставляет именованная запись ROW TYPE. В этом случае предыдущая структура «Деканат» задается иначе.

Первоначально формируются именованные записи.

CREATE ROW TYPE Студент_TYРЕ (.

Шифр_студента varchar (8),.

Фамилия varchar (15).

);

CREATE ROW TYPE Гpyппa_TYPE (.

Шифр_группы varchar (8),.

Название_группы varchar (5),.

Студент Студент_ТУРЕ.

);

CREATE ROW TYPE Кафедра_TYPE (.

Шифр_кафедры integer,.

Название_кафедры varchar (50).

);

Из именованных записей составляется структура «Деканат» .

CREATE ROW TABLE Деканат (.

Шифр_деканата integer,.

Название varchar (15),.

Г руппа Гpyппa_TYPE,.

Кафедра Кафедра TYPE.

);

При этом сформируется таблица с нелинейной структурой (табл. 8.1).

Таблица 8.1

Сформированная таблица «Учебный процесс»

Можно таблицу построить и другим способом.

CREATE ROW TYPE Деканат_ТУРЕ (.

Шифр_деканата integer,.

Название varchar (15),.

Группа Гpynna_TYPE,.

Кафедра Кафедра_ТУРЕ.

);

и.

CREATE TABLE Деканат OF TYPE Деканат_ТУРЕ;

Последняя таблица получила название типизированной. Заметим, что при вставке в тип ROW проблем не возникает:

INSERT INTO Деканат.

VALUES (','ПТИО',.

ROW ('И-99', 'И4',.

ROW ('И-99/15',.

'Петров'):Студент_ТУРЕ):Группа_Туре,.

ROW (1, 'ИиУС'):Кафедра_ТУРЕ);

где знак: обозначает перевод записи в элемент ROW.

Операторы заполнения ROW TYPE сложнее, чем ROW, и требуют написания хранимых процедур или функций. Например, список групп в деканате формируется следующим образом:

CREATE FUNCTION Список_групп (Деканат.ГpyппaTYPE).

RETURNS (varchar (8), varchar (5)) AS.

RETURN (группа.Шифр_группы, Группа. Название_группы).

END FUNCTION;

Рис. 8.9. Иерархия абстрактных типов данных (наследование) Таблицу «Преподаватель» на рис. 8.8 временно заменим на таблицу «Работающий», подразумевая, что преподаватель одновременно и преподаватель, и (научный) сотрудник (рис. 8.9).

CREATE ROW TYPE адрес_ТУРЕ (.

Город varchar (15),.

Улица varchar (15),.

Дом integer,.

Корпус integer,.

Квартира integer.

);

CREATE ROW TYPE Работающий_ТУРЕ (.

Шифр_работающего integer,.

Фамилия varchar (15),.

Адрес адрес_ТУРЕ.

);

В составе «Работающий» имеются подчиненные ему элементы «Преподаватель» и «Сотрудник». Тогда иерархия подчинения (наследования) типов данных формируется так:

CREATE ROW TYPE Преподаватель_ТУРЕ (.

Дисциплина varchar (20),.

Вид_занятий varchar (10),.

UNDER Работающий TYPE;

CREATE ROW TYPE Сотрудник_???(.

Шифр_работы varchar (5),.

Название работы varchar (40),.

UNDER Работающий_TYРЕ;

Тогда типизированные таблицы имеют вид:

CREATE TABLE Преподаватель OF TYPE Преподаватель_ТУРЕ;

CREATE TABLE Сотрудник OF TYPE Сотрудник_ТУРЕ;

Два последних определения могут включать и внешние ключи.

Фактически сформирована система таблиц. Она отличается тем, что заполнение таблиц идет автономно. Если заполняются поля в таблице «Сотрудник», то одноименные поля в таблице «Работающий» не заполняются.

Б. Иерархия таблиц. Указанное заполнение порой неудобно и потому используют наследование не абстрактных типов данных, а таблиц, которые связывают так:

CREATE TABLE Преподаватель.

OF TYPE Преподаватель_ТУРЕ.

UNDER Работающий;

CREATE TABLE Сотрудник.

OF TYPE Сотрудник_ТУРЕ.

UNDER Работающий;

В этом случае таблицы становятся вложенными (рис. 8.10).

Если создать запрос.

SELECT * FROM Работающий;

то будут выданы поля как объекта «Работающий», так и объектов «Преподаватель» и «Сотрудник» .

Для получения данных только из определенной таблицы (например, «Сотрудник») необходимо создать запрос.

SELECT * FROM ONLY (Сотрудник);

Аналогично и с процедурами обновления.

Рис. 8.10. Пример вложенной таблицы.

DELETE FROM ONLY (Сотрудник).

WHERE Шифр_работы=254;

До сих пор использовались (см. рис. 8.6) разнородные структуры. Однако таблицы могут быть пополнены и однородными структурами (коллекциями).

Добавим к таблицам «Сотрудник» и «Преподаватель» коллекции:

а) участие сотрудника в научных темах:

ALTER TABLE Сотрудник.

ADD Проект SET (integer);

б) учебные пособия преподавателя:

ALTER TABLE Преподаватель.

ADD Пособия MULTISET (ROW (.

Название varchar (30),.

Год_издания integer).

);

Заметим, что MULTISET состоит из наборов ROW.

Тогда таблица «Преподаватель» получает новый вид (табл. 8.2).

Таблица 8.2

Новая таблица «Преподаватель»

Отметим также, что коллекция — понятие гибкое. Она может быть полем записи и в то же время записи могут играть роль элементов коллекции.

Запросы к коллекциям могут быть составлены лишь в простейших случаях. Запрос на выборку для таблицы «Преподаватель» имеет вид.

SELECT шифр_работающего, фамилия, Пособия.Название.

FROM Преподаватель WHERE 1999 IN (Пособия);

Вставка может осуществляться таким оператором.

INSERT INTO Преподаватель.

VALUES (', 'Иванов', 1, 'преподаватель',.

ROW ('CПб', 'Московский', 137, 2, 118),.

ROW ('Информатика', 'лекция'),.

«MULTISET{ROW ('A1', 1996),.

ROW ('AZ, 1997),.

ROW ('A4', 1997)}");

Следует отметить, что в СУБД Informix Universal Server введен новый тип переменной COLLECTION, в которой в процессе работы программы (хранимой процедуры) могут храниться значения данных.

Для более сложных запросов требуется использовать хранимые процедуры, возможно, с циклами.

С помощью хранимых процедур формируются и необходимые дополнительные методы, поскольку в СУБД Informix Universal Server нет механизма превращения хранимых процедур в методы. Таким образом, язык SQL3 обладает значительно большими возможностями по сравнению с языком SQL2.

В то же время разработчиков БД, видимо, настораживает более сложная структура объектов и, главное, методов. Кроме того, SQL3 характеризуется неполнотой операторов: часть операторов разработчику приходится создавать самому в рамках хранимых процедур, для чего необходимо хорошо знать язык SQL2.

Названные обстоятельства и инерционность привычного, широко распространенного реляционного мышления объясняют, по всей видимости, тот факт, что расширенные ОРБД не нашли пока масштабного применения.

Вместе с тем широкое распространение получила гибридная разновидность ОРБД, являющаяся серьезным усовершенствованием реляционных БД.

Расширенные ОРБД — серьезный шаг в направлении объектноориентированных баз данных. Сфера применения таких ОРБД будет, по мнению авторов, расти. Они формируют средства как для революционного перехода к ООБД, так и для постепенного, эволюционного движения в будущее баз данных.

Чтобы понять перспективы развития ОРБД, следует оцепить их достоинства и недостатки К достоинствам следует отнести [2]:

• • устранение ряда недостатков реляционных БД (см. § 8.1);
• • повторное использование компонентов;
• • использование накопленных знаний по реляционным БД.

К недостаткам ОРБД возможно отнести:

• • усложнение структуры БД и частичную утрату простой обозримости результатов, как в реляционных БД;
• • сложность построения абстрактных типов данных и методов, связывающих типы в иерархию;
• • менее широкий набор типов связей, определяемых языком программирования SQL, чем в объектно-ориентированных БД;
• • менее продуманный, отлаженный и стандартизованный набор типов данных, чем в ООБД.

ОРБД, по-видимому, будут существовать еще достаточно долго, чему есть по меньшей мере два объяснения.

• 1. Быстрое накопление с помощью ОРБД опыта, который можно использовать при создании ООСУБД.
• 2. Необходимость иметь средства для постепенного эволюционного «перевода» многочисленных реляционных БД в разряд ООБД, за которыми, видимо, будущее.