Паттерн OneInheritancePath–OneTable

Некоторые недостатки предыдущего паттерна компенсируются в результате сериализации таблиц классов по отношениям наследования. В паттерне OneInheritancePath–OneTable каждому конкретному классу соответствует своя таблица <Concrete_Class>_Instances, в столбцы которой отображаются все атрибуты класса, включая наследуемые от родителей.

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

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

Паттерн AllClasses–OneTable

Паттерн AllClasses–OneTable предполагает использование единой таблицы Instances для представления дескрипторов объектов всех классов. В столбцах таблицы хранятся идентификатор объекта и его тип. Контекст использования паттерна связан с представлением атрибутов классов в виде самостоятельных таблиц. В этом случае связь между таблицами экземпляров классов и значений их атрибутов осуществляется через внешние ключи записей объектов (см. раздел 6.4.2.2). Предполагается, что значения атрибутов одного и того же типа хранятся в единой таблице независимо от их вхождения в состав того или иного класса. Тем самым достигается существенная для схемо-независимой стратегии инвариантность реляционной схемы по отношению к прикладным моделям. Связь простого объекта с его классом осуществляется через внешний ключ записи в таблице классов Entities (см. раздел 6.5). Для сложных объектов предусмотрен внешний ключ записи в соответствующей таблице сложных классов Complex_Entities.

 

Паттерн BLOB

Паттерн BLOB также предполагает использование единой таблицы BLOB Instances для представления объектов всех классов. Однако в отличие от паттерна AllClasses–OneTable в данной таблице используется дополнительный столбец для хранения значений атрибутов, упакованных в бинарную или текстовую строку переменной длины. Задача упаковки значений в строку и их распаковки для клиентских приложений ложится непосредственно на промежуточный слой программного обеспечения. Хотя чтение и запись данных объекта осуществляются за одну операцию обращения к таблице, дополнительные расходы приходятся на обработку строк промежуточным слоем. По существу в этом случае BLOB стратегия объединяет в себе паттерны наследования, агрегации и ассоциации.

Возможны разновидности данного паттерна, связанные с различными способами представления строки значений атрибутов как в бинарном формате, так и в одном из текстовых метаформатов. В частности, применительно к метамодели EXPRESS стандарт STEP определяет формат текстового кодирования прикладных данных (ISO-10303-21) и несколько альтернативных способов XML разметки документов (ISO-10303-28), порождаемых соответствующей прикладной моделью данных, специфицируемой на языке EXPRESS.

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

Отображение атрибутов

 

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

Представление простых типов

Соответствие базовых типов языка EXPRESS типам данных в SQL достаточно прозрачно. В таблицу 1 сведены базовые типы EXPRESS и возможные способы их представления в некоторых популярных коммерческих и свободно распространяемых реляционных СУБД.

 

Таблица 1. Соответствие базовых типов EXPRESS и SQL в реляционных СУБД

ЕXPRESS	MySQL	PostgreSQL	Oracle
INTEGER	INTEGER	INTEGER	INTEGER
REAL	REAL, DOUBLE PRECISION	FLOAT8, DOUBLE PRECISION	NUMBER, DOUBLE PRECISION
REAL(n)	FLOAT(n)	NUMERIC(n)	NUMBER(n)
NUMBER	REAL, DOUBLE PRECISION	FLOAT8, DOUBLE PRECISION	NUMBER, DOUBLE PRECISION
BOOLEAN	CHAR(1), TINYINT	CHAR(1), SMALLINT	CHAR(1), INTEGER
LOGICAL	CHAR(1), TINYINT	CHAR(1), SMALLINT	CHAR(1), INTEGER
ENUMERATION	VARCHAR(128), INTEGER	VARCHAR(128), INTEGER	VARCHAR2(128), INTEGER
STRING	TEXT (up to 64K), LONGTEXT (up to 4Gb)	TEXT (about 1Gb)	VARCHAR2(4000), LONG (up to 2Gb)
STRING(n)	VARCHAR(n)	VARCHAR(n)	VARCHAR2(n)
STRING(n) FIXED	CHAR(n)	CHAR(n)	CHAR(n)
BINARY	BLOB (up to 64K), LONGBLOB (up to 4Gb)	BYTEA	LONG RAW (up to 2Gb)
BINARY(n)	VARCHAR(n) BINARY	VARBIT(n)	RAW(n)
BINARY(n) FIXED	CHAR(n) BINARY	BIT(n)	RAW(n)
ENTITY (reference)	VARCHAR(128), FOREIGN KEY	VARCHAR(128), FOREIGN KEY	VARCHAR2(128), FOREIGN KEY

 

Помимо указанных вариантов представления точности числовых значений и ограничений длины строковых и двоичных переменных, важные отличия затрагивают способы представления атрибутов типа BOOLEAN, LOGICAL и ENUMERATION. С точки зрения семантики языка EXPRESS значения этих типов упорядочены, и для них определены операции сравнения. Поэтому, если предполагается реализация запросов с использованием подобных операций, более предпочтительным выглядит представление переменных этих типов как целых чисел. В этом случае функция интерпретации значений в терминах исходной прикладной модели возлагается на промежуточный программный слой, возможно, с использованием словарей метаданных. Значения, представленные в виде символьных строк, интерпретируются непосредственно клиентскими приложениями. Средствами СУБД может контролироваться также и корректность данных, для чего должны быть наложены соответствующие ограничения на область допустимых значений.