Меню
Главная
УСЛУГИ
Авторизация/Регистрация
Реклама на сайте
 
Главная arrow Информатика arrow Базы данных
< Предыдущая   СОДЕРЖАНИЕ   Следующая >

Расширенные ОРБД

К расширенным ОРБД относится СУБД 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

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

Шифр деканата

Название деканата

Группа

Студенты

Кафедра

Шифр группы

Название группы

Шифр студента

Фамилия

Шифр кафедры

Название кафедры

1

ПТиО

И-99

И4

И-99/12

Петров

1

ИиУС

1

ПТиО

И-99

И4

И-99/11

Смирнов

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

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

Шифр работающего

Фамилия

Шифр предмета

Вид занятия

Адрес

Пособия

Город

Улица

Дом

Корпус

Квартира

Название

Год издания

28

Петров

1

Лекции

СПб

Кима

21

2

321

А

Б

В

1999

1998

1995

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

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

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. Необходимость иметь средства для постепенного эволюционного "перевода" многочисленных реляционных БД в разряд ООБД, за которыми, видимо, будущее.

 
Если Вы заметили ошибку в тексте выделите слово и нажмите Shift + Enter
< Предыдущая   СОДЕРЖАНИЕ   Следующая >
 
Предметы
Агропромышленность
Банковское дело
БЖД
Бухучет и аудит
География
Документоведение
Журналистика
Инвестирование
Информатика
История
Культурология
Литература
Логика
Логистика
Маркетинг
Медицина
Менеджмент
Недвижимость
Педагогика
Политология
Политэкономия
Право
Психология
Религиоведение
Риторика
Социология
Статистика
Страховое дело
Техника
Товароведение
Туризм
Философия
Финансы
Экология
Экономика
Этика и эстетика