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

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

Реклама:



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


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

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

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


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


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


Москва 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), несмотря на существование объектных расширений, и возможностей добавления новых типов данных, остается ориентированным на работу с реляционными данными, что отрицательно сказывается на производительности, вынуждая СУБД всякий раз производить сборку/разборку объектов при обмене с хранилищем. Еще один существенный недостаток объектно-реляционных баз заключается в том, что добавлений новых типов данных - это по сути расширение ядра сервера. Это модификация тщательно отлаженного, оптимизированного механизма, последствия такой операции трудно просчитываются.

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

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

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

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


  2. "Объекты в Oracle – это очень просто ", Владимир Пржиялковский. www.citforum.ru

  3. "Объектные СУБД на российских просторах", Кантонистов Юрий Алексеевич. Научно-производственный центр "Интелтек Плюс", www.inteltec.ru

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



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


Реклама:

Похожие:

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

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

Министерство образования Российской Федерации Московский Государственный Институт Электроники и Математики Кафедра электронно-вычислительной аппаратуры объектно-ориентированные субд iconМосковский Государственный Институт Электроники и Математики (Технический университет) Кафедра «Электронно-Вычислительной Аппаратуры»
Московский Государственный Институт Электроники и Математики (Технический университет)

Министерство образования Российской Федерации Московский Государственный Институт Электроники и Математики Кафедра электронно-вычислительной аппаратуры объектно-ориентированные субд iconМосковский государственный институт электроники и математики (Технический университет) Кафедра «электронно-вычислительной аппаратуры»
Запрос Выборка данных из таблицы по условию, наложенному, на столбец «nomer dogovora» 11

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

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

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

Министерство образования Российской Федерации Московский Государственный Институт Электроники и Математики Кафедра электронно-вычислительной аппаратуры объектно-ориентированные субд iconМосковский государственный институт электроники и математики Кафедра электронно-вычислительной аппаратуры Домашняя работа по дисциплине «Основы теории управления»
Поиск передаточной функции системы (эквивалентного звена) с помощью эквивалентных преобразований

Министерство образования Российской Федерации Московский Государственный Институт Электроники и Математики Кафедра электронно-вычислительной аппаратуры объектно-ориентированные субд iconСоздание архитектурного проекта с помощью Выполнили: студенты группы с-55 Тимошенко Михаил
Московский институт электроники и математики кафедра электронно-вычислительной аппаратуры

Министерство образования Российской Федерации Московский Государственный Институт Электроники и Математики Кафедра электронно-вычислительной аппаратуры объектно-ориентированные субд iconСоздание фотореалистичных изображений с помощью редактора 3d studio max выполнили: студенты группы с-55 Соколов Сергей
Московский институт электроники и математики кафедра электронно-вычислительной аппаратуры

Разместите кнопку на своём сайте:
Документы


База данных защищена авторским правом ©textedu.ru 2000-2013
При копировании материала обязательно указание активной ссылки открытой для индексации.
обратиться к администрации
Документы