Объектное
представление о реляционной модели
Применимость технологии объектно-ориентированного проектирования зависит от возможности перенесения её базовых принципов и понятий на реляционную модель. К таким понятиям относятся: наследование, инкапсуляция и полиморфизм. Следует отметить, что полной поддержки инкапсуляции в предлагаемом решении нет, поскольку нет сокрытия данных, хранимых в базе данных. Собственно поэтому не стоит говорить, что данная методика превращает реляционную модель в объектную. Речь идёт об объектном представлении реляционной модели.
Можно отметить, что приведённый пример прекрасно иллюстрирует процесс наследования. Сущность “ТОВАРЫ” - это суперкласс, а сущности “Молочные продукты” и “Мебель” - его подклассы. Если продолжить аналогию, то заметим, что каждый подкласс должен обладать всеми атрибутами своего класса. Сосредоточив общие атрибуты сущностей в классе “ТОВАРЫ”, мы тем самым определим их для всех его подклассов. Это именно то, что требовалось. Применительно к базам данных можно и нужно усилить данное положение: все атрибуты, индексы и ограничения, определённые на уровне класса, обязательны для всех подклассов, являющихся его наследниками. Например, если на какой-то атрибут класса наложено ограничение уникальности, то он должен быть уникален на уровне всего класса, а не только внутри каждого подкласса. Это положение очень важно для поддержания целостности и непротиворечивости данных, поэтому, наверное, следует прокомментировать его подробнее. Допустим, у нас есть класс a и его подклассы b и g. Предположим, что у класса a есть два атрибута a (integer) и b (date). Атрибут a определён как уникальный в классе a, и на атрибут b наложена проверка (CHECK (VALUE BETWEEN “1/1/1997” AND “1/1/1998”)). Это означает, что если атрибут a принял значение k в одном из отношений b или g, то значение k будет уникальным (единственным) для обоих подклассов b и g. Аналогичные рассуждения можно привести и для атрибута b: ни в подклассе b, ни в подклассе g значение данного атрибута не могут быть вне заданного диапазона. Переопределение атрибутов, индексов и ограничений в подклассах недопустимо! Использование наследования в существующих реляционных базах данных достаточно просто. Давайте вернёмся к нашему примеру. Первоначально магазин специализировался на продаже молочных продуктов, и мы имели в базе данных отношение “Молочные продукты”, при изменении инфологической модели (появлении новой группы товаров “Мебель”), нам следует:
Такой путь выглядит более предпочтительно, чем освоение новых средств, наподобие “постреляционных СУБД”, проектирования новой базы данных, определения схем переноса информации из существующей реляционной базы данных в новую “постреляционную” и, наконец, переписывания всего программного обеспечения. Классы могут быть реальными (ассоциированными с отношением) либо абстрактными (не имеющими ассоциированного отношения). Пока, для простоты изложения, будем считать, что каждый реальный класс ассоциируется с одним отношением, хотя, в общем случае, это ограничение лишает нас некоторых заманчивых возможностей.
Современные реляционные СУБД не имеют механизма инкапсуляции: объединения кода и данных внутри класса. Однако они обладают всеми необходимыми компонентами для его создания. Безусловно, речь идёт о хранимых процедурах. Здесь есть два важных аспекта, первый, описание класса должно включать описание методов (свойств) и процедуры, отвечающей за реализацию объявленного метода в данном классе; второе, процедура должна выполняться в контексте того класса, метод которого с ней ассоциирован. Если выполнение первого требования достаточно тривиально и практически не зависит от используемой РСУБД, то второе условие реализуется с учётом специфики реализации 4GL выбранной РСУБД. Дело в том, что некоторые системы позволяют передавать и использовать в качестве параметров хранимых процедур имена таблиц или их полей, другие этого не допускают. В первом случае можно в качестве контекста передавать имя класса, в котором описан данный метод. Во втором случае потребуется, чтобы контекст (класс) был вложен непосредственно в хранимую процедуру. Различия в реализациях 4GL не должны влиять на приложения, которые работают с базой данных посредством описываемого объектного представления. Не следует недооценивать сути механизма инкапсуляции, ибо благодаря его наличию в системе можно создавать сложные схемы взаимодействия между сущностями, представленными в базе данных. К примеру, на его основе можно разрабатывать расчётные схемы, схемы документооборота, потоков работ и управляющих воздействий, а также многое, многое другое.
Благодаря полиморфизму один и тот же метод (свойство) может иметь различные реализации у подклассов. Полиморфизм реализуется достаточно тривиально: одному и тому же методу ставятся в соответствие различные хранимые процедуры. Абстрактный класс может содержать объявление метода без ассоциированной с ним хранимой процедуры, в отличие от этого, в реальном классе отсутствие хранимых процедур в любом из методов является недопустимым. Роль конструкторов и деструкторов класса выполняют предложения CREATE и DROP, все остальные методы являются виртуальными. Значит, подкласс может переопределить суть любого метода, полученного от класса. Количество, тип и порядок передачи параметров метода подкласса должен соответствовать количеству, типу и порядку передачи параметров у метода класса.
К сожалению не все современные РСУБД имеют механизмы обмена сообщениями. Поэтому, столь важный механизм может быть реализован только факультативно. Обмен сообщениями - это то средство, которое даёт возможность проектировать очень сложные и гибкие системы. Менеджер сообщений позволяет относительно легко распределить выполнение сложного задания по нескольким потокам и/или серверам баз данных. Если выбор сервера баз данных ещё только предстоит, то имеет смысл рассматривать наличие в нём данной функции как один из положительных критериев. |
|||||