А.С. Дерябин А.Н. Быковский, Воронежский государст-венный педагогический университет

М.В. Ярошенко

КОМПЛЕКС МОДЕЛЕЙ ЭТАЛОННОЙ ОБЪЕКТНО-

РЕЛЯЦИОННОЙ СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ

COMPLEX OF MODELS OF BENCHMARKING OBJECT RELATIONAL SYSTEM MANAGEMENTS DATABASES

Представлен комплекс моделей, позволяющий разносторонне моделировать и

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

Comlex of models allowing versatile to model and to study various aspects of function

benchmarking object relational system managements databases is presented.

После создания концепции эталонной автоматизированной системы (АС) в смысле эталонной модели защищённой автоматизированной системы (ЭМЗАС) [1] воз-никла научная проблема применения этой концепции к различным классам программ-ного обеспечения. Применение концепции к системам управления базами данных (СУБД) даёт эталонную СУБД, функции которой в эталонной АС относятся к трём со-седним уровням ЭМЗАС : прикладному (№ 9), менеджерскому (№ 8) и информацион-ному (№ 7). Эталонная СУБД призвана служить эталоном для перспективных СУБД критического применения, которыми можно считать СУБД следующего (третьего) по-коления, призванные преодолевать проблемы, присущие традиционным реляционным и объектным СУБД. Поддерживая произвольные запросы подобно традиционным ре-ляционным, но не объектным СУБД, они должны справляться со всеми проблемными для реляционных СУБД разновидностями данных, поддерживаемыми объектными сис-темами: мультимедийные, биологические, финансовые данные, данные временных ря-дов, инженерного проектирования, автоматизации делопроизводства и т.д. В настоящее время не существует общепринятого мнения насчёт облика таких СУБД, но большин-ство специалистов и крупных поставщиков приняли в качестве аксиомы необходимость эволюционного развития систем, а именно совершенствования реляционных систем для включения в них положительных средств объектной технологии.

Этот подход приводит к трактовке СУБД третьего поколения как объектно-реляционных СУБД. Вопрос об их облике концептуально прояснился после выхода книги [2], называемой Третьим манифестом. Она носит «предписывающий» характер, содержит строгие, формальные и подробные технические предложения для выбора на-правлений развития СУБД и предлагает абстрактный план проектирования будущих СУБД и их языка на основе реляционной модели. Авторы книги считают, что в объект-но-реляционной СУБД необходимо обеспечить просто надлежащую поддержку типов данных. Задаваясь вопросом: «Как включить надлежащую поддержку типов данных в реляционную модель?», они дают глубоко научно обоснованный ответ, замечательный по своей концептуальной простоте и однозначности — эта поддержка уже существует в форме доменов, фактически являющихся типами. Теория типов и реляционная модель в определённой степени независимы. Реляционная модель не предписывает поддержку

конкретных типов, кроме логического, а лишь предусматривает поддержку некоторых (неопределённых) типов, требуя, чтобы атрибуты отношений имели некоторый тип.

Для появления объектных функциональных возможностей в реляционных сис-темах нужно не вносить что-то в реляционную модель, а лишь в полной мере её реали-зовать, чего так явно недостаёт в современных системах SQL. Искомое сближение ре-ляционных и объектных технологий должно основываться на реляционной модели как фундаменте всей современной технологии баз данных. Эта модель даёт теоретические предпосылки достижения подлинной как физической (через механизм автоматической навигации), так и логической (через механизм реляционных представлений) независи-мости от данных, хотя современные коммерческие продукты имеют здесь серьёзные недостатки. Объектно-реляционная система должна представлять собой просто реляци-онную систему, полностью поддерживающую реляционную модель, а существующие системы должны развиваться в направлении своего расширения в сторону включения полной поддержки типов, в частности пользовательских. Облик эталонной СУБД мож-но определить как эталонной объектно-реляционной СУБД — СУБД с архитектурой, удовлетворяющей концепции эталонной АС в смысле ЭМЗАС и с функциональным на-полнением объектно-реляционной СУБД в смысле [2].

Реляционная модель данных должна использоваться при моделировании эталон-ной объектно-реляционной СУБД в своей наиболее передовой версии [2, 3], основан-ной на классических фундаментальных понятиях типа, значения, переменной и опера-тора, состоящей из следующих пяти компонентов.

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

2. Генератор типов отношений и соответствующая интерпретация для сгенери-рованных типов отношений.

3. Возможность определения переменных отношения для указанных сгенериро-ванных типов отношений.

4. Операция реляционного присваивания для присваивания реляционных значе-ний указанным переменным отношения.

5. Неограниченный набор общих реляционных операторов (реляционная алгебра) для получения значений отношений из других значений отношений.

Являясь моделью данных, реляционная модель ничего не говорит о реализации. Поэтому база данных только воспринимается пользователем реляционной системы в виде набора таблиц как логических, а не физических структур, и может использовать любую физическую структуру памяти (последовательный файл, индексирование, хэ-ширование, цепочку указателей, сжатие и т.п.) при наличии возможности отображать эти структуры в виде логических таблиц. Таблицы (отношения) есть абстракция спосо-ба физического хранения данных, скрывающая от пользователя все нюансы реализации на уровне физической памяти (размещение, упорядочение и префиксы хранимых запи-сей, кодировка хранимых данных, хранимые структуры доступа, такие как индексы и т.д.). В терминологии ANSI/SPARC термин «логическая таблица» относится к одинако-во реляционным концептуальному и внешнему уровням. Но реляционная теория, опре-деляя лишь представление базы данных пользователю, вообще не может определить внутренний (физический) уровень, а только требует полной реализации выбранной фи-зической структурой существующей логической структуры.

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

В роли модели хранения выступает объектная модель. Находясь ближе к физи-ческим структурам (менее абстрактна и потому более зависима от данных), чем реля-ционная модель, она не является моделью данных как таковой. Подходящая объектная модель полностью лежит в рамках теории типов данных и обеспечивает возможность расширения типов. Поэтому все понятия и концепции объектной модели имеет смысл понимать лишь в расширительных трактовках классических понятий и концепций тео-рии типов. В частности, понятие «классы объектов» эквивалентно понятию «типы дан-ных», разница лишь в расширившейся трактовке. Действительно, передовые объектные представления (например, в языке программирования C#) стирают всякое различие ме-жду классами и типами, любой тип представляет собой класс и любой класс есть тип. Следовательно, изменяемые и неизменяемые объекты эквивалентны переменным и их значениям соответственно. Переменные экземпляра относятся не к объектной модели, а к её реализации, причём объекты должны обрабатываться исключительно методами, которые можно рассматривать как частный случай операторов. Сообщения эквивалент-ны вызовам операторов. Инкапсуляция класса есть механизм обеспечения скалярности типа, в результате данный класс может рассматриваться с точки зрения реляционной модели как скалярный тип. Конструкторы (деструкторы) создают (удаляют) перемен-ные, а поскольку реляционная модель предусматривает лишь один вид переменных — переменные отношения, то единственный допустимый конструктор (деструктор) — это оператор создания (удаления) переменной отношения. Поддержка иерархии классов, с которой связаны такие понятия, как наследование, полиморфизм, перегрузка, переоп-ределение и т.д., в объектной модели представляет собой составляющую поддержки самих классов.

На роль модели опосредованного отображения между физическим и логическим уровнями до последнего времени подходящего кандидата не находилось, в силу чего на практике использовалось непосредственное отображение, не позволяющее полностью реализовать потенциал реляционной модели. Но недавно появившаяся модель TransRe-lational™ (сокращенно модель TR), разработанная Стивом Тареном, несмотря на отсут-ствие пока общего признания, может заполнить этот теоретический пробел. За неиме-нием других сопоставимых моделей подобного рода её можно применять к эталонной объектно-реляционной СУБД.

Модель TR используется в качестве средства реализации реляционной модели данных. Она также является абстрактной моделью данных, но находится на более низ-ком уровне абстракции, ближе к структурам физической памяти. Модель TR совместно с реляционной и объектной моделями легко интегрируется с концепцией эталонной АС в смысле ЭМЗАС по причине удачной уровневой декомпозиции модели TR, абсолютно совместимой с уровневой декомпозицией ЭМЗАС. Реализованная с использованием модели TR СУБД может рассматриваться на трех уровнях абстракции: верхнем (реля-ционном или пользовательском), среднем (файловом или разадресации) и нижнем (таб-личном). На верхнем уровне данные представлены отношениями, составленными из кортежей и атрибутов, на нижнем — таблицами TR, состоящими из строк TR и столб-цов TR, пересекающихся в ячейках TR. Средний уровень является перенаправляющим — отношения верхнего уровня отображаются на файлы TR среднего уровня, а те уже на таблицы TR нижнего уровня. Файлы TR состоят из записей TR и полей TR, соответст-вующих кортежам и атрибутам верхнего уровня. Файлы TR, таблицы TR и переменные отношения абстрагируют физически хранимые данные, но файлы TR ближе перемен-ных отношения к физическому уровню и дальше таблиц TR. В отличие от неупорядо-ченности кортежей и атрибутов реляционной модели, записи TR и строки TR упорядо-чены сверху вниз, а поля TR и столбцы TR — слева направо. Выбираемый произвольно конкретный вариант упорядочения файла TR характеризует просто различные его вер-

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

Хранимая форма записи TR состоит из двух логически различимых частей — множества значений полей и множества данных, их связующих. В системах с непо-средственным отображением связующая информация задаётся по принципу физиче-ской близости, а в модели TR эти две части хранятся в разных таблицах TR: значения полей — в таблице значений полей, а связующая информация — в таблице реконст-рукции записей. Такое разделение является основным источником многочисленных преимуществ, которые способна предоставить модель TR.

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

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

Файловый уровень TR естественным образом соответствует менеджерскому уровню ЭМЗАС, а табличный и реляционный уровни TR — интерфейсам сопряжения менеджерского уровня с информационным и прикладным уровнями ЭМЗАС соответст-венно. Это простое и естественное соответствие является ключевым фактором успеш-ной реализуемости излагаемого здесь подхода, в соответствии с которым для построе-ния эталонной объектно-реляционной СУБД необходим комплекс из пяти моделей, приведенный в таблице. Количество моделей есть сумма количества уровней ЭМЗАС и сопряжений между ними для СУБД, т.е. 5=3+2. Модели пронумерованы по порядку возрастания уровня ЭМЗАС и идентифицированы посредством аббревиатур от кратких англоязычных названий.

№п/п

Иденти-фикатор

Полное название

Уровень ЭМЗАС

Уровень ANSI /

Уровень TR

Компоненты модели

модели модели SPARC

1.

ODM от “Object Data Model”

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

Информа-ционный уровень

Физический (внутренний) уровень

—

Хранимые файлы, хранимые записи, хранимые поля

2.

TRTM от “TransRe-lational Tables Model”

Табличная TR модель опосредо-ванного отображе-ния данных

Интерфейс сопряжения информа-ционного и менеджер-ского уров-ней

Отображение концептуаль-ный — внут-ренний

Таблич-ный уро-вень

Таблицы TR (табли-цы значений полей, таблицы реконструк-ции записей), строки TR, столбцы TR, ячейки TR

3.

TRFM от “TransRe-lational Files Model”

Файловая TR модель опосредо-ванного отображе-ния данных

Менеджер-ский уро-вень

Отображение концептуаль-ный — внут-ренний

Файло-вый уро-вень

Файлы TR, записи TR, поля TR

4.

RDM от “Relational Data Mo-del”

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

Интерфейс сопряжения менеджер-ского и прикладно-го уровней

Логический (концепту-альный + внешний уровень)

Реляци-онный уровень

Отношения, кортежи, атрибуты, переменные отношения (базовые переменные отноше-ния для концептуаль-ного уровня и реляци-онные представления для внешнего уровня)

5.

OMM от “Object Methods Model”

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

Приклад-ной уро-вень

Физический (внутренний) уровень

—

Статические методы, динамические мето-ды

Важно, что все модели чётко отнесены к определённым или никаким уровням

или межуровневым сопряжениям по всем трём имеющим отношение к данной теме уровневым декомпозициям: ЭМЗАС, ANSI/SPARC, TR. Лишь в двух случаях модель не относится ни к какому уровню по какой-либо из них — это две модели (ODM и OMM), не относящиеся ни к какому уровню TR. Это объясняется тем, что обе модели относят-ся к физическому уровню ANSI/SPARC, а он выходит за пределы действия уровней TR, целиком относящихся к логическому уровню и отображению концептуальный—внутренний ANSI/SPARC.

Модель TR, являющаяся моделью опосредованного отображения данных между физическим и логическим уровнями, целиком относится к отображению концептуаль-ный—внутренний архитектуры ANSI/SPARC. Собственная уровневая декомпозиция модели TR разбивает её на две модели : файловая TR модель опосредованного отобра-жения данных (TRFM), относящаяся к файловому уровню TR и соответствующая ме-неджерскому уровню ЭМЗАС, и табличная TR модель опосредованного отображения данных (TRTM), относящаяся к табличному уровню TR и соответствующая интерфейсу сопряжения информационного и менеджерского уровней ЭМЗАС. Реляционный уро-вень TR непосредственно относится не к модели TR, а к реляционной модели данных (RDM).

Объектная модель хранения декомпозирована на две модели : объектная модель хранения данных (ODM), соответствующая информационному уровню ЭМЗАС, и объ-ектная модель хранения методов (OMM), соответствующая прикладному уровню ЭМ-ЗАС. Так как объектная модель хранения относится к физическому уровню AN-SI/SPARC, то к нему же относятся и обе модели, получившиеся в результате декомпо-зиции. Можно отметить интересную деталь — эти две модели, будучи отнесёнными к одному и тому же (физическому) уровню ANSI/SPARC, соответствуют не только не одному и тому же, но даже не двум соседним уровням ЭМЗАС (информационному для ODM и прикладному для OMM). Это кажущееся противоречие отражает тот факт, что и информационный, и прикладной уровни ЭМЗАС в определённом смысле реализуют менеджерский уровень, представляющий данные абстрактно с точки зрения пользова-теля. Информационный уровень скрывает детали реализации пассивного аспекта абст-рактных данных (хранение информации), потому он и ниже менеджерского. А при-кладной уровень скрывает детали реализации активного аспекта абстрактных данных (инкапсуляция методов), потому он и выше менеджерского.

Таким образом, предложен комплекс из пяти фактически известных моделей функционирования объектно-реляционной СУБД, представленный в форме, дающей все предпосылки его использования при построении именно эталонной объектно-реляционной СУБД. Чтобы реализовать эти предпосылки, необходимо придать объект-но-реляционной СУБД соответствующую концепции эталонной АС в смысле ЭМЗАС архитектуру, в рамках которой изолировать программную среду данного функциональ-ного наполнения с удовлетворением всей совокупности подходящим образом заданных требований к её субъектному наполнению.

ЛИТЕРАТУРА

1. Информационная безопасность и защита информации в экономических ин-

формационных системах [Текст] : учеб. пособие / А.С. Дубровин, М.Г. Матвеев, Е.А. Рогозин, В.И. Сумин.— Воронеж: Воронеж. гос. технол. акад., 2005. — 292 с.

2. Date C.J. Foundation for Object/Relational Databases: The Third Manifesto (2d edition) / C.J. Date, H. Darwen. — Reading, Mass.: Addison-Wesley, 2000.

3. Дейт К.Дж. Введение в системы баз данных [Текст]: пер. с англ. / К. Дж. Дейт. — 8-е изд. — М.: Издательский дом «Вильямс», 2005. — 1328 с.