Министерство образования Российской Федерации Московский Государственный Институт Электроники и Математики Кафедра электронно-вычислительной аппаратуры объектно-ориентированные субд

Название	Министерство образования Российской Федерации Московский Государственный Институт Электроники и Математики Кафедра электронно-вычислительной аппаратуры объектно-ориентированные субд
Дата конвертации	26.10.2013
Размер	201.57 Kb.
Тип	Документы
источник

Содержание

Моделирование групп объектов в СУБД Oracle 10
Реляционная или объектная модель данных ? Реляционная модель
Объектно-ориентированная модель
База данных
Рис. 1. Фрагмент БД с объектом-целью
Объекты в СУБД Oracle.
Хранимые объекты
CREATE TYPE address_typ AS OBJECT (zip CHAR(6),location VARCHAR2(200))
Проверим описания созданных объектов
INSERT INTO emp VALUES ('Allen',1002,10,NEW address_typ('123456', 'Boston 123... '))
Создание таблицы объектов
Ссылки на объект
COLUMN ref FORMAT A90COLUMN value FORMAT A40
SELECT * FROM dept
COLUMN deref(addr) FORMAT A40
Методы объектов
CREATE TYPE BODY employee_typ ISMEMBER FUNCTION days_at_company RETURN NUMBER ISBEGINRETURN TRUNC(SYSDATE-hiredate);END;END
Виртуальные объекты
ALTER TYPE employee_typ DROP ATTRIBUTE (home)
CREATE VIEW emp_ov OF employee_typWITH OBJECT IDENTIFIER (empno) ASSELECT e.ename, e.hiredate, e.deptno, e.empno FROM emp e
...
Полное содержание

Министерство образования Российской Федерации

Московский Государственный Институт Электроники и Математики

Кафедра электронно-вычислительной аппаратуры

ОБЪЕКТНО-ОРИЕНТИРОВАННЫЕ СУБД

д.т.н. профессор Зарудный Д.И.

Москва 2004

Оглавление 2

Введение 3

Реляционная или объектная модель данных ? 3

Реляционная модель 3

Объектно-ориентированная модель 4

Объекты в СУБД Oracle. 5

Хранимые объекты 6

Создание таблицы объектов 7

Ссылки на объект 8

Методы объектов 9

Виртуальные объекты 9

^ Моделирование групп объектов в СУБД Oracle 10

Таблицы хранимых и синтезированных объектов 10

Коллекции 11

Вложенные таблицы 11

Работа в PL/SQL 12

Массивы типа VARRAY 12

Преобразования коллекций 13

Заключение 14

Список используемой литературы 14

1."Моделирование групп объектов в Oracle", Владимир Пржиялковский. www.citforum.ru 14

Введение

Начнем с ключевого вопроса: а зачем они вообще нужны, объектные базы данных? Ведь есть много хорошо зарекомендовавших себя реляционных баз, которые можно использовать. Ответ весьма прост: да, все верно, но реляционные базы пригодны для вполне определенного и ограниченного круга задач. В основном это задачи, связанные с обработкой хорошо структурированной информации. Задачи, данные которых хорошо отображаются на реляционные структуры и реляционные отношения, а также задачи, решение которых сводится к выборке данных из базы с последующей обработкой и обновлением.

Если же встречаются неструктурированные данные: текст, изображение, музыка, вообще, любые данные, требующие специфической обработки. Если есть задача, в которой присутствуют данные с многомерными связями. Если в решении прикладной задачи не обойтись без создания пользовательских типов данных, то объектным базам данных нет альтернативы.

Объектная СУБД идеально подходит для интерпретации сложных данных, в отличие от реляционных СУБД, где добавление нового типа данных достигается ценой потери производительности или за счет резкого увеличения сроков и стоимости разработки приложений. На наш взгляд, адаптация традиционных технологий для новых требований, которые диктуются необходимостью поддерживать мультимедиа, ИНТЕРНЕТ может быть более затратным путем, чем приобретение и внедрение продуктов и технологий, которые изначально созданы, чтобы удовлетворить все требования к средствам современного информационного бизнеса.
^

Реляционная или объектная модель данных ?

Реляционная модель

Реляционная модель данных предложена сотрудником фирмы IBM Эдгаром Коддом и основывается на понятии отношение (relation).

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

Таблица имеет строки (записи) и столбцы (колонки). Каждая строка таблицы имеет одинаковую структуру и состоит из полей. Строкам таблицы соответствуют кортежи, а столбцам — атрибуты отношения.

С помощью одной таблицы удобно описывать простейший вид связей между данными, а именно деление одного объекта (явления, сущности, системы и проч.), информация о котором хранится в таблице, на множество подобъектов, каждому из которых соответствует строка или запись таблицы. При этом каждый из подобъектов имеет одинаковую структуру или свойства, описываемые соответствующими значениями полей записей. Например, таблица может содержать сведения о группе обучаемых, о каждом из которых известны следующие характеристики: фамилия, имя и отчество, пол, возраст и образование. Поскольку в рамках одной таблицы не удается описать более сложные логические структуры данных из предметной области, применяют связывание таблиц.

Физическое размещение данных в реляционных базах на внешних носителях легко осуществляется с помощью обычных файлов.

Достоинство реляционной модели данных заключается в простоте, понятности и удобстве физической реализации на ЭВМ. Именно простота и понятность для пользователя явились основной причиной их широкого использования. Проблемы же эффективности обработки данных этого типа оказались технически вполне разрешимыми.

Основными недостатками реляционной модели являются следующие: отсутствие стандартных средств идентификации отдельных записей и сложность описания иерархических и сетевых связей.
^

Объектно-ориентированная модель

В объектно-ориентированной модели при представлении данных имеется возможность идентифицировать отдельные записи базы. Между записями базы данных и функциями их обработки устанавливаются взаимосвязи с помощью механизмов, подобных соответствующим средствам в объектно-ориентированных языках программирования.

Стандартизованная объектно-ориентированной модель описана в рекомендациях стандарта ODMG-93 (Object Database Management Group — группа управления объектно-ориентированными базами данных). Реализовать в полном объеме рекомендации ODMG-93 пока не удается. Для иллюстрации ключевых идей рассмотрим несколько упрощенную модель объектно-ориентированной БД.

Структура объектно-ориентированной БД графически представима в виде дерева, узлами которого являются объекты. Свойства объектов описываются некоторым стандартным типом (например, строковым — string) или типом, конструируемым пользователем (определяется как class).

Значением свойства типа string является строка символов. Значение свойства типа class есть объект, являющийся экземпляром соответствующего класса. Каждый объект-экземпляр класса считается потомком объекта, в котором он определен как свойство. Объект-экземпляр класса принадлежит своему классу и имеет одного родителя. Родовые отношения в БД образуют связную иерархию объектов.

Пример логической структуры объектно-ориентированной БД библиотечного дела приведен на рис. 2.10.

Здесь объект типа БИБЛИОТЕКА является родительским для объектов-экземпляров классов АБОНЕНТ, КАТАЛОГ и ВЫДАЧА. Различные объекты типа КНИГА могут иметь одного или разных родителей. Объекты типа КНИГА, имеющие одного и того же родителя, должны различаться по крайней мере инвентарным номером (уникален для каждого экземпляра книги), но имеют одинаковые значения свойств isbn, удк, название и автор.

Логическая структура объектно-ориентированной БД внешне похожа на структуру иерархической БД. Основное отличие между ними состоит в методах манипулирования данными.

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

Создание и модификация БД сопровождается автоматическим формированием и последующей корректировкой индексов (индексных таблиц), содержащих информацию для быстрого поиска данных.

Рассмотрим кратко понятия инкапсуляции, наследования и полиморфизма применительно к объектно-ориентированной модели БД.

Инкапсуляция ограничивает область видимости имени свойства пределами того объекта, в котором оно определено. Так, если в объект типа КАТАЛОГ добавить свойство, задающее телефон автора книги и имеющее название телефон, то мы получим одноименные свойства у объектов АБОНЕНТ и КАТАЛОГ. Смысл такого свойства будет определяться тем объектом, в который оно инкапсулировано.

Наследование, наоборот, распространяет область видимости свойства на всех потомков объекта. Так, всем объектам типа КНИГА, являющимся потомками объекта типа КАТАЛОГ, можно приписать свойства объекта-родителя: isbn, удк, название и автор. Если необходимо расширить действие механизма наследования на объекты, не являющиеся непосредственными родственниками (например, между двумя потомками одного родителя), то в их общем предке определяется абстрактное свойство типа abs. Так, определение абстрактных свойств билет и номер в объекте БИБЛИОТЕКА приводит к наследованию этих свойств всеми дочерними объектами АБОНЕНТ, КНИГА и ВЫДАЧА. Не случайно поэтому значения свойства билет классов АБОНЕНТ и ВЫДАЧА, показанных на рисунке, будут одинаковыми — 00015.

Полиморфизм в объектно-ориентированных языках программирования означает способность одного и того же программного кода работать с разнотипными данными. Другими словами, он означает допустимость в объектах разных типов иметь методы (процедуры или функции) с одинаковыми именами. Во время выполнения объектной программы одни и те же методы оперируют с разными объектами в зависимости от типа аргумента. Применительно к нашей объектно-ориентированной БД полиморфизм означает, что объекты класса КНИГА, имеющие разных родителей из класса КАТАЛОГ, могут иметь разный набор свойств. Следовательно, программы работы с объектами класса КНИГА могут содержать полиморфный код.

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

^ БАЗА ДАННЫХ
БИБЛИОТЕКА class БИБЛИОТЕКА goal			БИБЛИОТЕКА
			свойство тип значение
			район string Невский АБОНЕНТ class КАТАЛОГ class ВЫДАЧА class билет abs номер abs
БИБЛИОТЕКА
билет string номер string дата string

^ Рис. 1. Фрагмент БД с объектом-целью

Основным достоинством объектно-ориентированной модели данных в сравнении с реляционной является возможность отображения информации о сложных взаимосвязях объектов. Объектно-ориентированная модель данных позволяет идентифицировать отдельную запись базы данных и определять функции их обработки.

Недостатками объектно-ориентированной модели являются высокая понятийная сложность, неудобство обработки данных и низкая скорость выполнения запросов.

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

В следующей главе мы рассмотрим реализацию объектного подхода в СУБД Oracle.
^

Объекты в СУБД Oracle.

В СУБД Oracle, начиная с версии Oracle 8.0i, появилась возможность хранения неатомарных (нескалярных) значений в поле таблицы, а именно объекта в смысле объектного подхода (в рамках так называемой “объектно-реляционной модели” Oracle). Некоторые существенные пробелы этой первой реализации были устранены в версии 9. Примеры ниже используют возможности версии 9.2.

Сразу надо предостеречь от преувеличений достоинств объектного подхода в базах данных вообще. Ни табличная организация (часто вольно называемая “реляционной” применительно к конкретным СУБД), ни объектная не являются универсально “хорошими”, и что имеются свои достоинства и недостатки у одной и у другой.

В целом объектная реализация в Oracle традиционна для объектного подхода вообще. В основе лежит понятие объекта как совокупности свойств (атрибутов), причем действия с объектом регламентируются формулируемым набором методов (процедур или функций). Тип объекта задается сохраняемым в БД объектом TYPE.
^

Хранимые объекты

- Простой пример:

Рассмотрим схему БД, где хранятся данные о сотрудниках и отделах. Будем работать в схеме SCOTT, из которой на время нужно удалить таблицы EMP и DEPT (позже мы их восстановим).

Предположим, что и те, и другие имеют адреса: сотрудники - домашний, а отделы – юридический. Адрес имеет несколько полей (например, “индекс”, “район”, “населенный пункт”, “место”). В традиционной табличной реализации есть два способа промоделировать наличие адреса:

- включить одинаковые группы полей в таблицы сотрудников и отделов;
- создать отдельную таблицу адресов и включить в таблицы сотрудников и отделов ссылки на нее.

Первое решение неудобно тем, что адрес теряет свою идентичность: неудобно, например, сравнивать адреса, особенно в разных таблицах. Второе решение искусственно, если только не считать адреса самостоятельными объектами моделирования.

Объектные возможности последних версий Oracle дают возможность более приемлемой альтернативы. Для описания адреса создадим тип (здесь и далее предполагается использование в качестве рабочего инструмента SQL*Plus):

^ CREATE TYPE address_typ AS OBJECT (
zip CHAR(6),
location VARCHAR2(200));

Воспользуемся этим типом для описания сотрудников и отделов:

CREATE TABLE dept (
dname VARCHAR2(50),
deptno NUMBER CONSTRAINT pk_dept PRIMARY KEY,
addr address_typ);

CREATE TABLE emp (
ename VARCHAR2(50),
empno NUMBER CONSTRAINT pk_emp PRIMARY KEY,
deptno NUMBER CONSTRAINT fk_emp REFERENCES dept,
home address_typ);

^ Проверим описания созданных объектов:

DESCRIBE address_typ
DESCRIBE dept
DESCRIBE emp

Пример заведения сотрудников и отделов:

INSERT INTO dept VALUES (
'Sales',
10,
address_typ('123456', 'Boston 123... '));

INSERT INTO emp VALUES (
'Smith',
1001,
10,
address_typ('123333', 'Boston 567... '));

Здесь выражение ADDRESS_TYP('123333', 'Boston 567... ') означает обращение к конструктору объекта, то есть к функции, автоматически создаваемой СУБД при заведении нового типа для возможности создавать новые объекты этого типа с нужными значениями атрибутов. Понятие конструктора общепринято в объектном подходе. В приведенных предложениях INSERT простановку адреса можно оформить чуть иначе, добавив, в соответствии с духом объектного подхода, ключевое слово NEW перед обращением к конструктору:

^ INSERT INTO emp VALUES (
'Allen',
1002,
10,
NEW address_typ('123456', 'Boston 123... '));

Проверка:

COLUMN dname FORMAT A20
COLUMN ename FORMAT A20
COLUMN addr FORMAT A40
COLUMN home FORMAT A40

SELECT * FROM dept;

SELECT * FROM emp;

Другие примеры:

SELECT ename, home FROM emp;

SELECT e.ename, d.dname FROM emp e, dept d WHERE e.home = d.addr;

SELECT e.ename, e.home.zip FROM emp e;

UPDATE emp
SET home = address_typ('123457', 'Boston 777... ')
WHERE ename = 'Allen';

UPDATE emp e SET e.home.zip = '123458' WHERE ename = 'Allen';
^

Создание таблицы объектов

Если адрес интересует нас как самостоятельная сущность, а не атрибут прочих сущностей, созданный для адреса тип можно использовать для создания таблиц объектов:

CREATE TABLE addr_list1 OF address_typ;

CREATE TABLE addr_list2 OF address_typ;

Таблицы объектов в Oracle было бы точнее называть списками объектов, так как это всегда таблицы ровно из одного столбца объектного типа.

Заполнение данными происходит как и ранее:

INSERT INTO addr_list1 VALUES
(NEW address_typ('123456', 'Boston 123... '));

или

INSERT INTO addr_list1 VALUES
(address_typ('123458', 'Boston 123... '));

INSERT INTO addr_list2 VALUES
(address_typ('123333', 'Boston 567... '));

Просмотр:

COLUMN location FORMAT A30

SELECT * FROM addr_list1;

SELECT VALUE(a) FROM addr_list1 a;

SELECT e.ename, e.home
FROM addr_list1 a, emp e
WHERE VALUE(a) = e.home;

(Функция VALUE специально придумана для возвращения значений объектов, а не атрибутов объектов по отдельности).
^

Ссылки на объект

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

^ COLUMN ref FORMAT A90
COLUMN value FORMAT A40

SELECT REF(a) ref, VALUE(a) FROM addr_list1 a;

Теперь можно поменять описание таблицы, например, DEPT, чтобы она заимствовала адреса отделов из имеющегося списка, а не хранила вместе со своими данными:

ALTER TABLE dept DROP (addr);

ALTER TABLE dept ADD (addr REF address_typ SCOPE IS addr_list1);

^ SELECT * FROM dept;

UPDATE dept d
SET d.addr =
(SELECT REF(a)
FROM addr_list1 a
WHERE VALUE(a)= address_typ('123458', 'Boston 123... '))
WHERE d.deptno = 10;

SELECT * FROM dept;

Фраза SCOPE IS при определении типа как ссылки на существующий объект необязательна, но позволяет фактически ссылаться только на объекты какой-нибудь объектной таблицы.

Раскрытие ссылки делается с помощью специальной функции DEREF:

^ COLUMN deref(addr) FORMAT A40

SELECT d.dname, DEREF(addr) FROM dept d;

Однако при обращении к нижележащим атрибутам раскрытие может выполняться и неявно (неявное преобразование типов, присутствующее в Oracle-диалекте SQL):

SELECT d.dname, d.addr.zip FROM dept d;

вместо более правильного

SELECT d.dname, DEREF(d.addr).zip FROM dept d;

^

Методы объектов

Выше было рассмотрено определение типа, содержащее описание атрибутов (“свойств”). Создадим тип сотрудников, в котором определен еще и метод:

CREATE TYPE employee_typ AS OBJECT (
ename VARCHAR2(50),
hiredate DATE,
deptno NUMBER,
home REF address_typ,
MEMBER FUNCTION days_at_company RETURN NUMBER);

Для описания тела метода-функции необходимо создать тело типа (аналогия пакет – тело пакета в PL/SQL):

^ CREATE TYPE BODY employee_typ IS
MEMBER FUNCTION days_at_company RETURN NUMBER IS
BEGIN
RETURN TRUNC(SYSDATE-hiredate);
END;
END;
Создадим таблицу объектов-сотрудников:

DROP TABLE emp;

CREATE TABLE emp OF employee_typ;

INSERT INTO emp VALUES (
'Scott',
SYSDATE,
10,
(SELECT REF(a) FROM addr_list1 a
WHERE VALUE(a) = address_typ('123458', 'Boston 123... ')));

Пример обращения к методу:

COLUMN home.location FORMAT A20

SELECT e.ename, e.home.location, e.days_at_company() FROM emp e;

^

Виртуальные объекты

Переводить в существующей БД табличные описания данных в объектные не всегда возможно, а иногда и не нужно. В силу разных обстоятельств может оказаться удобной имитация объектов на основе данных, хранимых в традиционных таблицах. Тогда к одним и тем же данным можно обращаться и через объектный интерфейс, и через табличный. Достигается это с помощью виртуальных объектов (object views), которых можно так назвать по аналогии с виртуальными таблицами (views).

Для примера вернем описания и наполнение традиционным таблицам схемы SCOTT: EMP и DEPT.

@?/sqlplus/admin/demobld

sqlplus scott/tiger

(Сценарий demobld.sql выводит нас из SQL*Plus).

Упростим для примера описание типа EMPLOYEE_TYP:

^ ALTER TYPE employee_typ DROP ATTRIBUTE (home);

ALTER TYPE employee_typ ADD ATTRIBUTE (empno NUMBER);

CONNECT scott/tiger

ALTER TYPE employee_typ COMPILE;

Построим таблицу виртуальных объектов типа EMPLOYEE_TYP по исходным данным, хранящимся в EMP:

^ CREATE VIEW emp_ov OF employee_typ
WITH OBJECT IDENTIFIER (empno) AS
SELECT e.ename, e.hiredate, e.deptno, e.empno FROM emp e;

По своему поведению виртуальные объекты ничем не отличаются от первичных. Проверка (“объектного доступа” к табличным данным):

^ SELECT e.ename, e.days_at_company () FROM emp_ov e;

SELECT VALUE(e) FROM emp_ov e;

SELECT REF(e) FROM emp_ov e;

UPDATE emp_ov e SET e.ename = INITCAP(e.ename)
WHERE e.empno = 7934;

SELECT ename FROM emp_ov;

Возможность выполнения традиционных DML-операторов над базовыми таблицами, естественно, сохраняется:

UPDATE emp SET ename = UPPER(ename) WHERE empno = 7934;

SELECT ename FROM emp;
^

Моделирование групп объектов в СУБД Oracle

В предыдущей главе говорилось о том, как в Oracle можно создавать и хранить отдельные объекты. В жизни этого недостаточно, и требуется иметь возможность моделировать группы объектов: наборы адресов, списки сотрудников и т. д.

Такая возможность предусматривалась, например, в сетевой модели данных, исторически предшествовавшей реляционной, и проектировалась в виде расширения реляционной создателем последней Э. Коддом (в силу ряда причин это расширение было проигнорировано разработчиками промышленных "реляционных" СУБД). Здесь будут рассмотрены возможности моделирования групп объектов, реализованные в Oracle последних версий (8, 9, 10).
^

Таблицы хранимых и синтезированных объектов

Первая возможность моделирования групп из объектов в Oracle известна по предыдущей статье: это таблицы "исконных" объектов (object tables) и таблицы "виртуальных", или "синтезированных" объектов (object views). Исконные объекты хранятся как самостоятельные сущности в БД, а синтезированные дают только видимость объектов (по потребительским свойствам почти не отличимую от истинных объектов) на основе данных, хранимых в обычных или объектных таблицах.

И те и другие позволяют иметь в БД неупорядоченные списки объектов. Ниже приводится пример создания двух списков сотрудников, проживающих в Москве и Ленинграде. Принадлежность сотрудников отделам задается специальной таблицей:

DROP TYPE employee_typ FORCE;
DROP TABLE e_moscow;
DROP TABLE e_leningrad;
DROP TABLE employment;

^ CREATE TYPE employee_typ AS OBJECT (
    ename    VARCHAR2(50),
    job      VARCHAR2(10))
/
CREATE TABLE e_moscow OF employee_typ;

CREATE TABLE e_leningrad OF employee_typ;

INSERT INTO e_moscow VALUES (
    'Scott',
    'Manager');
...

INSERT INTO e_leningrad VALUES (
    'Smith',
    'Salesman');
...

CREATE TABLE employment (
       dname VARCHAR2(50),
        employee REF employee_typ);

INSERT INTO employment VALUES (
       'Operations',
       (SELECT REF(m) FROM e_moscow m WHERE m.ename = 'Scott'));
...

Этот способ, однако, не лишен своих ограничений. Например, по данным таблицы EMPLOYMENT нельзя понять, проживает ли сотрудник в Москве или Ленинграде. Нельзя переселить сотрудника из Москвы в Ленинград (можно только удалить его из одной таблицы и создать в другой объект с теми же атрибутами) и так далее.

Коллекции

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

В Oracle они могут быть двух видов: вложенные таблицы и массивы типа VARRAY.
^

Вложенные таблицы

Термин, выбранный для этого вида коллекций кажется не совсем удачным. Речь на самом деле идет о моделировании не таблиц, а списков. В отличие от предыдущего примера построим таблицу DEPARTMENTS с перечнем отделов, причем в строке о каждом отделе будем хранить список сотрудников. Предварительно, однако, нужно будет создать тип для такого поля-списка:

CREATE TYPE employee_nlist_typ AS TABLE OF employee_typ
/
CREATE TABLE department (
dname VARCHAR2(20),
emps employee_nlist_typ)
NESTED TABLE emps STORE AS emps_nt_tab;

Фраза NESTED TABLE - чисто техническая. Она обязана тому, что физически Oracle будет хранить в поле EMPS не список объектов-сотрудников, а список их системных идентификаторов, присвоенных при помещении самих сотрудников в специально создаваемую для таблицы DEPARTMENT служебную таблицу. Таким образом при использовании вложенных таблиц значения элементов хранимых списков физически всегда хранятся в специальной отдельной таблице, которой мы обязаны придумать название. В таком решении есть своя логика, так как для этой специальной таблицы мы можем указать собственные характеристики хранения и некоторые другие вещи.

Вот как можно заполнить таблицу отделов:

^ INSERT INTO department VALUES (‘

'Operations', employee_nlist_typ (

employee_tip ('Scott', 'Manager'),

employee_tip ('Smith', 'Salesman')

)

);

в отделе Operations теперь два сотрудника.

COLUMN emps FORMAT A60 WORD

SELECT * FROM department;

По терминологии предыдущей главы сотрудники в таблице DEPARTMENT - "объектные атрибуты". Другой способ смоделировать ситуацию "сотрудники-отделы" с помощью коллекции - воспользоваться списком ссылок на сотрудников, реально существующих в собственных таблицах.

^

Работа в PL/SQL

Вот как можно работать со вложенными таблицами в PL/SQL:

DECLARE
    ee employee_nlist_typ;
BEGIN
    SELECT emps INTO ee FROM department WHERE dname = 'Operations';
    DBMS_OUTPUT.PUT_LINE(ee(1).ename);
    DBMS_OUTPUT.PUT_LINE(ee(2).ename);
END;
/

В этом примере для упрощения использованы предпосылки о том, что:

- a. отдел с названием 'Operations' всего один

- b. сотрудников в нем - [по крайней мере] двое.
^

Массивы типа VARRAY

Массивы типа VARRAY потребительски во многом похожи на вложенные таблицы, но имеют и ряд существенных технических и внешних отличий. Например, они обязаны иметь ограничение на максимальное число элементов в конкретных массивах, наподобие типу VARCHAR2. Еще они не требуют для хранения данных служебной таблицы, наподобие вложенной таблицы. Есть и другие отличия. Фирма Oracle советует использовать вложенные таблицы, если нужно хранить неупорядоченные списки и VARRAY, если нужно хранить упорядоченные.

Пример использования для группировки сотрудников коллекции VARRAY может выглядеть так:

^ CREATE TYPE employee_vlist_typ AS VARRAY(20) OF employee_typ
/
CREATE TABLE department1 (
        dname             VARCHAR2(15),
        emps              employee_vlist_typ
        );

Этим типом мы запретили отделам иметь более 20-и сотрудников.

Добавление нового отдела делается как и для вложенных таблиц:

INSERT INTO department1 VALUES (
    'Operations',
    employee_vlist_typ (
       employee_typ ('Scott', 'Manager'),
       employee_typ ('Smith', 'Salesman')
       )
    );

Приведенный выше код на PL/SQL для массива сотрудников VARRAY проработает так же.
^

Преобразования коллекций

Как и следовало бы ожидать от СУБД Oracle, плотная, а не поверхностная работа с коллекциями в качестве средства моделирования групп объектов требует знания большого числа "деталей". Здесь не место разъяснять их все, но одну важную для коллекций возможность стоит привести. Имеется в виду разворачивание коллекции в список строк, столь привычный для традиционной работы.

Для того, чтобы посмотреть список сотрудников отдела 'Operations' в более привычном виде, следует воспользоваться специальной функцией TABLE:

SELECT * FROM TABLE(SELECT emps FROM department);

К аргументу функции TABLE (это вложенный SELECT) есть одна настоятельная просьба: возвращать одну и только коллекцию. Наши данные это обеспечивают, а иначе вложенный SELECT нужно было бы подправить.

Аналогичный пример для массива VARRAY:

SELECT ename FROM TABLE(SELECT emps FROM department1);

Замечательно, что это преобразование решает задачу и изменения списка средствами SQL:

INSERT INTO TABLE(SELECT emps FROM department)
VALUES ('Allen', 'Salesman');

SELECT * FROM TABLE(SELECT emps FROM department);

(Эта возможность не сработает, однако, для массива VARRAY, который в БД ведет себя, по сути, как скаляр, допуская изменение поля-списка как единого, уже сформированного целого).

Если бы возможность такого преобразования отсутствовала, добавить сотрудника в отдел или удалить можно было бы только программным способом, проще всего в PL/SQL.

Естественно, никто не мешает осуществить и массовую вставку:

INSERT INTO TABLE(SELECT emps FROM department)
SELECT ename, job FROM emp;

Для обратного преобразования, из таблицы в коллекцию, потребуется более сложная конструкция:

SELECT
^ CAST (MULTISET(SELECT ename, job FROM emp) AS employee_nlist_typ)
FROM DUAL;

Однако такое преобразование на практике менее востребовано.

Заключение

Несмотря на то, что объектные базы существуют более десятка лет, это направление в СУБД считается новым и ставит перед исследователями множество теоретических проблем. Ключевой, конечно же, теория объектной модели данных. И даже не столько теория, сколько приемлемый по сложности математический аппарат для работы с объектами. Ведь почему реляционные обрели такую популярность? Оттого, что реляционная модель интуитивно понятна, а ее математическое описание довольно несложно.

В то же время в последнее десятилетие окрепла и набрала силу тенденция применения объектных средств проектирования и разработки. Реакцией производителей реляционных СУБД на возрастающую популярность объектных технологий стало появление объектно-реляционных баз данных, так называемых универсальных серверов. Это - половинчатое решение, диктуемое чисто рыночными интересами. Ядро универсального сервера (Informix, Oracle, DB2), несмотря на существование объектных расширений, и возможностей добавления новых типов данных, остается ориентированным на работу с реляционными данными, что отрицательно сказывается на производительности, вынуждая СУБД всякий раз производить сборку/разборку объектов при обмене с хранилищем. Еще один существенный недостаток объектно-реляционных баз заключается в том, что добавлений новых типов данных - это по сути расширение ядра сервера. Это модификация тщательно отлаженного, оптимизированного механизма, последствия такой операции трудно просчитываются.

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

Эксперты не рекомендуют пытаться применять объектные подходы только по причине, что кто-то их превозносит или использует. Маловероятно, что вы получите хорошую отдачу, не затратив на процесс своего постижения определенных денег и времени и не освоив альтернативную модель программирования. Без этого вы попросту украсите своей работой ландшафт незаконченных проектов.
^

Список используемой литературы

"Моделирование групп объектов в Oracle", Владимир Пржиялковский. www.citforum.ru
"Объекты в Oracle – это очень просто ", Владимир Пржиялковский. www.citforum.ru
"Объектные СУБД на российских просторах", Кантонистов Юрий Алексеевич. Научно-производственный центр "Интелтек Плюс", www.inteltec.ru
"Объектные СУБД: состояние и перспективы", Андреев А.А., к.т.н. доцент МГТУ им. Н.Э.Баумана,
Березкин Д.В., к.т.н., исполнительный директор НПЦ “Интелтек Плюс”,
Кантонистов Ю.А., разработчик. Научно-производственный центр "Интелтек Плюс", www.inteltec.ru

Добавить документ в свой блог или на сайт

	Министерство образования Российской Федерации Московский Государственный Институт Электроники и Математики Кафедра электронно-вычислительной аппаратуры объектно-ориентированные субд		Московский государственный институт электроники и математики Кафедра электронно-вычислительной аппаратуры
	Московский Государственный Институт Электроники и Математики (Технический университет) Кафедра «Электронно-Вычислительной Аппаратуры» Московский Государственный Институт Электроники и Математики (Технический университет)		Московский государственный институт электроники и математики (Технический университет) Кафедра «электронно-вычислительной аппаратуры» Запрос Выборка данных из таблицы по условию, наложенному, на столбец «nomer dogovora» 11
	Наполнение эл библиотеки кафедры электронными книгами Московский институт электроники и математики кафедра электронно-вычислительной аппаратуры		Создание архитектурного проекта с помощью пакета Autocad Московский институт электроники и математики кафедра электронно-вычислительной аппаратуры
	Исследование новейших разработок в области отображающих устройств Московский институт электроники и математики кафедра электронно-вычислительной аппаратуры		Московский государственный институт электроники и математики Кафедра электронно-вычислительной аппаратуры Домашняя работа по дисциплине «Основы теории управления» Поиск передаточной функции системы (эквивалентного звена) с помощью эквивалентных преобразований
	Создание архитектурного проекта с помощью Выполнили: студенты группы с-55 Тимошенко Михаил Московский институт электроники и математики кафедра электронно-вычислительной аппаратуры		Создание фотореалистичных изображений с помощью редактора 3d studio max выполнили: студенты группы с-55 Соколов Сергей Московский институт электроники и математики кафедра электронно-вычислительной аппаратуры

Оглавление