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

Комплекс моделей эталонной объектно-реляционной системы управления базами данных Текст научной статьи по специальности «Компьютерные и информационные науки»

CC BY
276
122
i Надоели баннеры? Вы всегда можете отключить рекламу.
i Надоели баннеры? Вы всегда можете отключить рекламу.
iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
i Надоели баннеры? Вы всегда можете отключить рекламу.

Текст научной работы на тему «Комплекс моделей эталонной объектно-реляционной системы управления базами данных»

А.С. Дубровин,

кандидат технических наук, Воронежская государственная технологическая академия

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На роль модели опосредованного отображения между физическим и логическим уровнями до последнего времени подходящего кандидата не находилось, в силу чего на практике использовалось непосредственное отображение, не позволяющее полностью реализовать потенциал реляционной модели. Но недавно появившаяся модель TransRelational™ (сокращенно модель 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/SPARC, TR. Лишь в двух случаях модель не относится ни к какому уровню по какой-либо из них — это две модели (ODM и OMM), не относящиеся ни к какому уровню TR. Это объясняется тем, что обе эти модели относятся к физическому уровню ANSI/SPARC, а он выходит за пределы действия уровней TR, целиком относящихся к логическому уровню и отображению концептуальный

— внутренний ANSI/SPARC.

№ п/п Идентификатор модели Полное название модели Уровень ЭМЗАС Уровень ANSI / SPARC Уровень TR Компоненты модели

1 ODM (Object Data Model) Объектная модель хранения данных Информационный уровень Физический (внутренний) уровень — Хранимые файлы, хранимые записи, хранимые поля

2 TRTM (TransRelational Tables Model) Табличная ТЯ модель опосредованного отображения данных Интерфейс сопряжения информационного и менеджерского уровней Отображение концептуальный — внутренний Табличный Таблицы ТЯ (таблицы значений полей, таблицы реконструкции записей), строки ТЯ, столбцы ТЯ, ячейки ТЯ

3 TRFM (TransRelational Files Model) Файловая ТЯ модель опосредованного отображения данных Менеджерский уровень Отображение концептуальный — внутренний Файловый Файлы ТЯ, записи ТЯ, поля ТЯ

4 RDM (Relational Data Model) Реляционная модель данных Интерфейс сопряжения менеджерского и прикладного уровней Логический (концептуальный + внешний уровень) Реляцион- ный Отношения, кортежи, атрибуты, переменные отношения (базовые переменные отношения для концептуального уровня и реляционные представления для внешнего уровня)

5 OMM (Object Methods Model) Объектная модель хранения методов Прикладной уровень Физический (внутренний) уровень — Статические методы, динамические методы

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

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

Объектная модель хранения декомпозирована на две модели: объектная модель хранения данных (ODM), соответствующая информационному уровню ЭМЗАС, и объектная модель хранения методов (OMM), соответствующая прикладному уровню ЭМЗАС. Так как объектная модель хранения относится к физическому уровню ANSI/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 с.

i Надоели баннеры? Вы всегда можете отключить рекламу.