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

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

CC BY
140
55
Поделиться
Ключевые слова
MODEL. / BENCHMARKING OBJECT RELATIONAL SYSTEM MANAGEMENTS DATABASES. / МОДЕЛЬ. / ЭТАЛОННАЯ ОБЪЕКТНО-РЕЛЯЦИОННАЯ СИСТЕМА УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Дерябин1 Андрей Сергеевич1, Быковскийn Александр Николаевичn, Ярошенкоn Максим Викторовичn

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

Похожие темы научных работ по компьютерным и информационным наукам , автор научной работы — Дерябин1 Андрей Сергеевич1, Быковскийn Александр Николаевичn, Ярошенкоn Максим Викторовичn

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

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и

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

А.С. Дерябин А.Н. Быковский, М.В. Ярошенко

Воронежский государственный педагогический университет

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

COMPLEX OF MODELS OF BENCHMARKING OBJECT RELATIONAL SYSTEM MANAGEMENTS DATABASES

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

Comlex of models allowing versatile to model and to study various aspects offunction 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#) стирают всякое различие между классами и типами, любой тип представляет собой класс и любой класс есть тип. Следовательно, изменяемые и неизменяемые объекты эквивалентны переменным и их значениям соответственно. Переменные экземпляра относятся не к объектной модели, а к её реализации, причём объекты должны обрабатываться исключительно методами, которые можно рассматривать как частный случай операторов. Сообщения эквивалентны вызовам операторов. Инкапсуляция класса есть механизм обеспечения скалярности типа, в результате данный класс может рассматриваться с точки зрения реляционной модели как скалярный тип. Конструкторы (деструкторы) создают (удаляют) переменные, а поскольку реляционная модель предусматривает лишь один вид переменных — переменные отношения, то единственный допустимый конструктор (деструктор) — это оператор создания (удаления) переменной отношения. Поддержка иерархии классов, с которой связаны такие понятия, как наследование, полиморфизм, перегрузка, переопределение и т.д., в объектной модели представляет собой составляющую поддержки самих классов.

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

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

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

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

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

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

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

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

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

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

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

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

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

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

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

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

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), соответствующая прикладному уровню ЭМЗАС. Так как объектная модель хранения относится к физическому уровню 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. Дейт К.Дж. Введение в системы баз данных [Текст ]: пер. с англ. / К. Дж. Дейт.

— В-е изд. — М.: Издательский дом «Вильямс», 2005. — 132В с.