Разработка базы данных из предметной области "Предприятие", страница 6

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

Каждый объект класса имеет идентификатор объекта, который используется для однозначного определения данного объекта в системе. Идентификатор назначается системой и не зависит от состояния объекта.

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

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

Схема новой базы данных:

Рисунок 7.1.1

7.2 Скрипты метамодели

CREATE TABLE  "ATTRIBUTES"

   ( "ATTR_ID" NUMBER(20,0) NOT NULL ENABLE,

      "OBJECT_TYPE_ID" NUMBER(20,0) NOT NULL ENABLE,

      "NAME" VARCHAR2(100),

       PRIMARY KEY ("ATTR_ID") ENABLE

   );

CREATE TABLE  "OBJECT_TYPES"

   ( "OBJECT_TYPE_ID" NUMBER(20,0) NOT NULL ENABLE,

      "NAME" VARCHAR2(100),

      "DESCRIPTION" VARCHAR2(1000),

       PRIMARY KEY ("OBJECT_TYPE_ID") ENABLE

   );

CREATE TABLE  "OBJECTS"

   ( "OBJECT_ID" NUMBER(20,0) NOT NULL ENABLE,

      "OBJECT_TYPE_ID" NUMBER(20,0) NOT NULL ENABLE,

      "NAME" VARCHAR2(100),

       PRIMARY KEY ("OBJECT_ID") ENABLE,

       CONSTRAINT "O_OT_ID" FOREIGN KEY ("OBJECT_TYPE_ID")

        REFERENCES  "OBJECT_TYPES" ("OBJECT_TYPE_ID") ON DELETE CASCADE ENABLE

   );

CREATE TABLE  "PARAMS"

   ( "OBJECT_ID" NUMBER(20,0) NOT NULL ENABLE,

      "ATTR_ID" NUMBER(20,0) NOT NULL ENABLE,

      "TEXT_VALUE" VARCHAR2(1000),

      "NUMBER_VALUE" NUMBER(20,0),

       CONSTRAINT "PAR_ATTR_ID" FOREIGN KEY ("ATTR_ID")

        REFERENCES  "ATTRIBUTES" ("ATTR_ID") ENABLE,

       CONSTRAINT "PAR_OBJ_ID" FOREIGN KEY ("OBJECT_ID")

        REFERENCES  "OBJECTS" ("OBJECT_ID") ENABLE

   );

commit;

7.3 Триггеры

      Переделывая имеющийся уже триггер для метамодели приходится столкнутся с таким понятием как мутирование таблиц.Каждый, кто начинает работать с СУБД Oracle, рано или поздно сталкивается с проблемой мутирования. Что же это такое и как с ним бороться ? Предположим у нас есть таблица, в которой есть строчный триггер. В теле триггера написан запрос, который выполняет манипуляции (select, insert, update, delete) с данными текущей таблицы. Либо этот триггер запускает процедуру, которая обращается к текущей таблице. Типичный пример - добавилась строка, программист хочет, чтобы триггер подсчитал некоторые статистические данные.

       Описанная выше ситуация на практике невозможна. При срабатывании строчного триггера, выполняющего любые манипуляции с данными текущей таблицы, будет сгенерировано исключение ORA-04091: table is mutating, trigger/function may not see it.