E-mail:
Пароль:
Забыли пароль?

Универсальная схема хранения объектного представления данных в реляционной СУБД

Универсальная схема хранения объектного представления данных в реляционной СУБД

Конференция «Корпоративные базы данных '2003»

Дмитрий Коваль

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

В настоящее время существует и разрабатывается большое число информационных систем поддержки принятия решений (Decision Support System). В многочисленных статьях обсуждаются проблемы подхода к проектированию [1], проблема выбора СУБД [2,3,4], проблема выбора средств разработки [5] подобных систем. Но, на наш взгляд, недостаточно внимания уделяется вопросам построения универсальных схем хранения данных в информационных системах.

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

В статье предложен метод создания универсальной схемы хранения объектного представления данных, использование которого позволило бы создать на основе РСУБД Хранилище Данных [10]. Универсальность данного метода заключается в единообразном представлении данных в виде объектов, вне зависимости от способа хранения этих данных в РСУБД. В зависимости от конкретной задачи, можно реализовать разные способы хранения данных в РСУБД, имеющие следующие особенности:

  • предоставление пользователю расширенных возможностей для работы с данными;

  • минимизация времени выполнения пользовательских запросов.

Такой подход обеспечивает системе необходимую гибкость и возможность использования внешних по отношению к системе данных.

Наиболее просто и логично можно представить такую схему хранения данных в терминах модели «объект-качество» [11].

Современная объектная концепция (СОК) содержит существенные логические ограничения. В частности, СОК не различает вещи (сущности, которые сравниваются как переменные, например люди, страны, автомобили и т.д.) и значимые сущности (сущности, которые сравниваются как значения, например имя, дата рождения, вес и т.д.) и для того, чтобы описать их, предлагает использовать одну и ту же абстракцию, называемую «объект». Абстракция «объект» адекватно описывает вещи – во всяком случае, когда речь идет о сравнении информации, так как две абсолютно одинаковые вещи все равно являются разными вещами. Для значимых сущностей такая аналогия отсутствует.

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

Принципы сравнения качеств:

  • между собой могут сравниваться значения только одного и того же качества;

  • единственным способом сравнения качеств является сравнение их значений: качества, описываемые одинаковыми значениями, являются одинаковыми и никак иначе не отличаются друг от друга;

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

Это позволяет утверждать, что понятие «качество» обладает реляционной природой [11]. Качество (тип) есть ни что иное, как отношение, а значения качества являются кортежами этого отношения. Структура этого типа описывается схемой соответствующего отношения. Информация, описывающая любой реальный объект, может быть представлена как множество кортежей различных отношений.

Значение качества и значение качественного атрибута объекта – это не одно и тоже, даже когда речь идет об одном и том же качестве (типе) Q. Значение качества – это кортеж отношения. Значение же качественного атрибута – это множество таких кортежей и его можно рассматривать как значение отношения Q.

Любому атрибуту объекта ставится в соответствие два имени, которые можно обозначить как «качественное» и «структурное». «Качественное» имя – имя качественного типа (Q) – показывают, как вещи могут взаимодействовать с окружающим миром. «Структурное» имя – имя атрибута объекта (S) – объясняет, почему и как конкретная вещь обладает этими способностями к взаимодействию.

Пусть существует конечное множество D доменов {D1,D2,…,Dn}, и множество Q определенных на D отношений

(1)

Пусть существует домен DS (DS I D), содержащий значения, которые можно рассматривать как уникальные имена атрибутов DS = {S1, S2, .... Sm}. Каждому имени Si ставится в соответствие подмножество si отношения Qj, которое можно назвать доменом Qj = dom(si), 1<=i <=m, Qj I Q.

Схемой класса С называется конечное подмножество DS, C = {Si | Si I DS} (Si – имя атрибута класса С). Тогда класс c со схемой C – это конечное множество отображений {o 1, o 2, ..., o k } из C в Q, причем каждое отображение o I с должно удовлетворять следующему ограничению: o(s i ) Q i . Такие отображения o назовем объектами. То есть объектом о класса c называется множество {s i :S i | s i является именованным (имеющим имя S i ) подмножеством соответствующего Q j, s i Q j }.

Поскольку D S можно рассматривать как объединение всех схем классов C (D S = C 1 E C 2 E .... E C m, где m – число классов существующих в системе), то множество всех объектов всех классов O=c 1 E c 2 E .... E c m можно рассматривать как множество отображений из домена D S в то же самое множество Q. Каждому такому отображению соответствует определенное значение – уникальный объектный идентификатор O ID (O ID « D OID ), следовательно, O можно рассматривать как подмножество прямого произведения D OID, D S и Q:

(2)

При использовании выражения для Q эта формула преобразуется в выражение:

(3)

Из последней формулы видно, что множество O является реляционной системой. Каждому значению качества Q i со схемой [D 1,...,D n ], входящему в атрибут s j объекта o k соответствует кортеж отношения R i со схемой [D OID :OID, S, D 1,...,D n ]. Каждому качеству Q i ставится в соответствие отношение R i, содержащее значения всех атрибутов этого качества, принадлежащих всем существующим в системе объектам. Любой набор данных представленный в виде О (множество объектов) может быть сохранен в виде R (множество отношений).

Таким образом, уровень хранения является полностью реляционным и описывается в терминах доменов и отношений.

В базовую систему типов большинства РСУБД входят только простые (не составные) типы ( char, byte, integer, real, double, date и т.д.). В связи с этим, удобно в качестве базовой системы типов информационно-аналитической системы (ИАС), основанной на реляционной СУБД, принять базовые типы РСУБД. При отсутствии составных типов формулу (3) можно переписать в таком виде:

(4)

где D AttrID – домен, содержащий уникальные идентификаторы атрибутов ( D S ), D ObjID – домен, содержащий уникальные идентификаторы объекта класса, в который входит атрибут; D ValueID – домен, содержащий идентификаторы значений качества (является первичным ключом отношения R i ); D Value – домен, содержащий значения качества.

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

(5)

В этой формуле отсутствует атрибут D AttrID отношения R m и уникальное имя атрибута объекта неявно содержится в названии отношения R m.

В ситуации, когда атрибуты объекта представляют собой не группу повторения (не являются многозначными), а являются атомарными (однозначными), для получения всех атрибутов объекта необходимо выполнить n SQL -запросов, выбирая данные из всех отношений R i (i=1,.., n ), где n – число атрибутов класса объекта. В этом случае все атрибуты класса, в состав которого входят только однозначные атрибуты, удобно хранить в одном отношении:

(6)

Для однозначных атрибутов значения атрибутов совпадают со значениями качеств (точнее, каждому значению атрибута соответствует одно значение качества) и хранятся в кортежах отношения R m. Идентификатор объекта O bj ID k одновременно является уникальным идентификатором для всех однозначных атрибутов объекта. В каждом кортеже отношения R m находятся значения нескольких атрибутов объекта, которые хранятся в атрибутах отношения R m и идентифицируются при помощи названий этих атрибутов. То есть в этом случае имена атрибутов класса неявно содержатся в названиях атрибутов D i отношения R m. При такой структуре хранения информации получение всех однозначных атрибутов объекта возможно с помощью выполнения единственного SQL -запроса.

В общем случае, когда в состав объектов входят и однозначные, и многозначные атрибуты, формулы (4), (5) и (6) преобразуются в выражение:

(7)

Приведенные в формуле (7) способы хранения объектов в настоящее время реализованы в ИАС НЕВОД® 3.5.

Схема, поясняющая структуру хранения данных в системе, приведена ниже.

Структура хранения данных в ИАС НЕВОД® 3.0

Как видно из схемы, все однозначные атрибуты класса хранятся в одном отношении. Следует также отметить, что уникальный идентификатор объекта OID является сложным и состоит из двух частей: из идентификатора класса объекта и уникального идентификатора объекта внутри класса.

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

Таким образом, предложенный метод позволяет создать информационную систему по принципу Хранилища Данных, накапливающую данные произвольной предметной области. Однако существует множество моделей, достигающих данной цели. Рассмотренный же метод обеспечивает большее быстродействие полученной системы. Увеличение скорости ввода и чтения данных, а также выполнения поисковых заданий, связано с введением специального способа хранения однозначных атрибутов объектов.

Литература

[1] Зиндер Е. З. Проектирование баз данных: новые требования, новые подходы // СУБД. – 1996. – №3.

[2] Сахаров А. А. Концепции построения и реализации информационных систем, ориентированных на анализ данных // СУБД. – 1996. – № 4.

[3] Андреев А.М., Березкин Д.В., Кантонистов Ю.А. Выбор СУБД для построения информационных систем корпоративного уровня на основе объектной парадигмы // СУБД. – 1998. – №4-5.

[4] Шринивасан В., Чанг Д. Т. Долговременное хранение объектов в объектно-ориентированных приложениях // Открытые системы. – 1999. – №3.

[5] Артемьев В. И. Обзор способов и средств построения информационных приложений // СУБД. – 1996. – № 5-6.

[6] Андреев А.М., Березкин Д.В., Кантонистов Ю.А. Выбор СУБД для построения информационных систем корпоративного уровня на основе объектной парадигмы // СУБД. – 1998. – №4-5.

[7] Гвозденко А. Рынок СУБД: рокировка без изменения позиции? // Компьютерное Обозрение. – 2002. – №20.

[8] Елманова Н., Федоров А. Oracle и Microsoft SQL Server : прошлое, настоящее и будущее. Рынок СУБД в 1999-2001 годах // http :// www. nwsta. com / Soft / subd / ormic. php

[9] Резниченко А. Мировой рынок СУБД (2001 год) // http :// www. dialog -21. ru / full _ digest. asp ? digest _ id =17606

[10] Inmon. W. H. Building The Data Warehouse (Second Edition). – NY, NY: John Wiley & Sons. – 1996. – 401p.

[11] Григорьев Е. Модель «объект – качество» (2001 год) // http :// www. citforum. ru / database / articles / moq. shtml


Возврат к списку

ѕрокрутить вверх