Соответствие состояний реализаций исходной и целевой моделей данных

Зыкин С.В.
ОФИМ СО РАН, Омск

Аннотация:

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

In paper the requirements to tool for creation of user applications for working with information resources are considered. This problem is investigated from the viewpoint of conformity establishment of states of a information resource and user representation of this resource, which are described by appropriate models of data.

Проблема использования информационных ресурсов была сформулирована основоположником реляционной модели данных - Е. Коддом с соавторами [1]: "... обладание большой корпоративной БД имеет маленькое значение, если конечные пользователи не имеют возможностей легко синтезировать необходимую информацию из этих запасов (складов) данных". Эта ситуация обусловлена тем, что весь сервис работы с корпоративной БД создается прикладными программистами и, как следствие, необходимая для принятия решения информация к моменту ее получения перестает быть актуальной. Для решения указанной проблемы необходимо создание инструментария, ориентированного на организацию интерфейса между пользовательским представлением данных и корпоративной БД.

Понимание этой проблемы вынуждает разработчиков программного обеспечения информационных систем дополнять свои продукты соответствующим инструментарием. Примером могут служить разработки: MS Access для Windows, Oracle Express, Delphi и т.д. Эти системы обладают широким спектром возможностей: быстрое создание форм для просмотра и редактирования данных, создание отчетов с возможностью расчета интегральных характеристик, вплоть до построения диаграмм, и т.д. Однако, есть принципиальное ограничение: они ориентированы на универсальные (в данном случае реляционные) модели данных. В следствии этого появляются ограничения на редактирование данных, когда приложение работает сразу с несколькими отношениями реляционной схемы данных. Более существенные ограничения возникают, если в приложении требуется структурное преобразование реляционной схемы, например - "семантическая транформация" [6]. Во всех этих случаях неизбежным становится программирование приложений на встроенных языках. Общая тенденция такова: чем больше пользовательская модель данных отличается от исходной универсальной модели, тем больше приходится программировать, либо меньше функциональных возможностей предоставляется пользователю (в крайнем случае только просмотр данных).

Широко распространен и другой подход, когда схема данных информационной системы подгоняется под схему данных пользовательского приложения. Наиболее яркий пример: отказ от нормализации при использовании реляционной модели данных. Этот подход в литературе получил собственное название: "Ветринные технологии". Они позволяют получить быстрый эффект на начальных стадиях функционирования системы, становясь в последствии препятствием создания корпоративной БД.

Сформулируем требования, которым должен удовлетворять инструментарий:
1) быстрое формирование приложения без привлечения языка программирования;
2) сформированное приложение должно содержать функции редактирования данных: дополнение, удаление и модификацию;
3) если представление данных, с которым работает приложение, подлежит длительному хранению, то данные должны автоматически актуализироваться, по крайней мере в момент запуска приложения, поскольку данные в центральной базе данных могут быть изменены другими приложениями;
4) целесообразна реализация ограничений целостности на данные в рамках приложения, что является актуальным в распределенных информационных системах с удаленным доступом, то есть в центральную базу данных из приложения должны поступать корректные данные.

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

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

Модель информационной системы (модель данных) запишем в виде алгебраической системы:

\begin{displaymath}\Omega =<M,D,F,P>,\end{displaymath}

где $М$ - логическая модель (схема) данных; $D$ - совокупность допустимых состоянии базы данных; $F$ - набор операции для модели $М$; $Р$ - совокупность предикатов, ограничивающих допустимые состояния $D$; $M$ и $D$ в совокупности являются носителем системы.

Модель $\Omega$ будем считать исходной, а $\Omega ' = <M',D',F',P'>$ - целевой (пользовательской). Следовательно, необходимо построение преобразования:

\begin{displaymath}\Omega\ \Rightarrow \ \Omega '.\end{displaymath}

В [3] рассмотрен метод построения отображения моделей данных, основанный на свойстве коммутативности. Этот метод в данной работе использован в качестве основы. Предлагается следующая последовательность построения преобразования исходной модели $\Omega$ в целевую $\Omega '$:
1. Формирование схемы целевой модели $\Omega '$.
2. Разработка алгоритма $Alg$ построения (первоначальной загрузки) представления целевой модели и определение условий его применимости для исходной модели.
3. Определение образов ограничений целостности исходной модели для целевой модели.
4. Формирование образов операций преобразования представления целевой модели для исходной модели.
5. Формирование образов операций преобразования представления исходной модели для целевой модели.

Рассмотрим более подробно предложенные шаги построения преобразования.

1. Формирование схемы целевой модели предполагает использование языка описания данных (ЯОД) для фиксации состава и структуры логического уровня целевой модели. Во многом эта проблема решается за счет возможностей выбранной инструментальной системы, в рамках которой предполагается работа с целевой моделью. Способы формирования схемы и требования к ней достаточно широко обсуждались в литературе, например [3,4,5]. Поэтому, в данном случае достаточно ограничиться указанными ссылками.

2. После построения схемы целевой модели необходимо определиться со способом формирования представления целевой модели. Для этого предлагается разработка алгоритма первоначальной загрузки $Alg$, то есть основного алгоритма преобразования сформированного представления исходной модели в первоначально пустое представление целевой модели.

Основой построения преобразования является установление соответствия между допустимыми состояниями $D$ и $D'$. При формировании пользовательской модели либо модели описания информационных ресурсов в большенстве случаев используется только часть данных из представления исходной модели: переходу из одного элементарного состояния целевой модели в другое соответствует только изменение данных в исходной модели (переход в другое состояние), которые участвуют при формировании представления целевой модели. Данные в представлении исходной модели, не участвующие в формировании целевой, могут изменяться произвольным образом, что не приводит к изменению состояния целевой модели. С другой стороны, в реализации целевой модели могут присутствовать специализированные первичные данные пользователя, отсутствующие в реализации исходной модели, либо в реализации модели описания информационных ресурсов присутствуют данные из другой исходной модели. Изменение этих данных переводит целевую модель в другое элементарное состояние, тогда как состояние исходной модели, соответствующее этим состояниям, будет одно.

Определение 1. Совокупность элементарных состояний одной модели, которым соответствует одно состояние другой модели, будем называть обобщенным состоянием. Причем, каждому элементарному состоянию $d_{ij}$ модели $\Omega$ соответствует одно и только одно обобщенное состояние $D'_l$ модели $\Omega '$, и наоборот: каждому элементарному состоянию $d'_{lk}$ модели $\Omega '$ соответствует одно и только одно обобщенное состояние (прообраз) $D_i$ модели $\Omega$.

Из определения 1 следуют свойства:

1) $D_{i}\cap D_{j}=\emptyset$, $D'_{i}\cap D'_{j}=\emptyset$, $i\not= j$.

2) Количество обобщенных состояний исходной модели равно количеству обобщенных состояний целевой модели.

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

При построении $Alg$ можно выделить два подхода.

1) $d'_{l0} =Alg(d_{ij})$ - алгоритм используется только для формирования изначально пустого пользовательского представления данных.

2) $d'_{lk} =Alg(d_{ij})$, $\forall d_{ij}\in D_{i}$, - алгоритм преобразует пользовательское представление независимо от его текущего состояния. Такой подход был реализован в работе [2] при формировании "семантической трансформации", впервые рассмотренной в работе [6].

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

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

3. Для исходной модели данных $\Omega$ может быть задана совокупность ограничений: функциональные и многозначные зависимости, ссылочная целостнось и т.д. [4,5]. Все они в совокупности определяют допустимые состояния данных и переходы между ними для исходной модели $\Omega$. Поскольку алгоритм $Alg$ определяет образы состояний модели $\Omega$ для модели $\Omega '$, то соответствующие образы для ограничений на допустимые состояния и переходы также определяются этим алгоритмом. Образы ограничений целостности должны быть достаточными для выполнения исходных ограничений модели $\Omega$. То есть, для целевой модели $\Omega '$ могут быть заданы более "жесткие" ограничения, если реализация образов ограничений, являющихся необходимыми и достаточными, для модели $\Omega '$ является затруднительной либо невозможной. В крайнем случае ограничением целостности может стать запрет на модификацию определенной группы данных.

4. В процессе работы с моделью $\Omega '$ пользователь формирует последовательность команд $f'_p$, которая переводит модель $\Omega '$ из состояния $d'_{ij}\in D'_{i}$ в состояние $d'_{lk}\in D'_{l}$ Исполняющая среда должна сформировать соответствующую совокупность команд $F_p$, которая необходима для перевода модели $\Omega$ из состояния $d_{ij}\in D_{j}$ в состояние $d_{lk}\in D_{l}$. Указанные преобразования состояний должны удовлетворять условию коммутативности:

\begin{displaymath}d_{ij}\stackrel{F_{p}}{\longrightarrow} d_{lk} \stackrel{Alg}{\longrightarrow} d'_{l0}\end{displaymath}


\begin{displaymath}d_{ij}\stackrel{Alg}{\longrightarrow} d'_{i0} \stackrel{f'_{p}}{\longrightarrow} d'_{l0}.\end{displaymath}

Другими словами, в состояние $d'_{l0}$ можно перейти двумя различными способами, но результат должен быть один и тот же.

5. Модификация состояния модели $\Omega$ может быть выполнена из другого приложения, что потребует изменения состояния модели $\Omega '$. Для этого в первого подхода формирования алгоритма $Alg$ должна быть определена последовательность команд $F'_p$, которая выполнит необходимые преобразования в представлении модели $\Omega '$. Во втором втором подходе достаточно использовать алгоритм $Alg$.

Для второго подхода справедливо следующее утверждение.

Утверждение. Образ $F'_p$ для модели $\Omega '$ операции $f_p$ для модели $\Omega$ определен корректно, если:

\begin{displaymath}F'_{p}(d'_{lk})=Alg(f_{p}(d_{ij})).\end{displaymath}

Это утверждение не требует отдельного доказательства, поскольку оно является следствием требования коммутативности преобразования. Так как $d'_{lk} =Alg(d_{ij})$, то в состояние $f'_{p}(d'_{lk})$ можно перейти двумя различными способами: 1) используя команду $f'_{p}$ для реализации модели $\Omega '$, 2) используя последовательность команд $F_{p}$ для реализации модели $\Omega$ с последующей перезагрузкой измененных данных в реализацию модели $\Omega '$. Требование коммутативности преобразования гарантирует, что результаты будут совпадать.

Аналогичное утверждение нельзя сформулировать для пункта 4, поскольку не предполагается наличие обратного алгоритма $Alg^{-1}$.

Для первого подхода построения алгоритма $Alg$ должно быть справедливо условие коммутативности, аналогичное условию пункта 4.

Литература

1
Codd E.F. , Codd S.B. , Salley C.T. Providing OLAP to User-Analist: An IT Mandate. E.F. - Codd ${\cal E}$ Associates , 1993.

2
Зыкин С.В. Формирование пользовательского представления реляционной базы данных с помощью отображений. - Программирование, N 3, 1999, стр. 70 - 80.

3
Калиниченко Л.А. Методы и средства интеграции неоднородных баз данных. - М.: Наука, 1983. - 423 с.

4
Мейер Д. Теория реляционных баз данных. - М.: Мир, 1987. - 608 с.

5
Ульман Дж. Основы систем баз данных. - М.: Финансы и статистика, 1983. - 334 с.

6
Цаленко М.Ш. Моделирование семантики в базах данных. - М.: Наука, 1989. - 287 с.
Ваши комментарии
[SBRAS]
[Головная страница]
[Конференции]
[СО РАН]

© 2001, Сибирское отделение Российской академии наук, Новосибирск
© 2001, Объединенный институт информатики СО РАН, Новосибирск
© 2001, Институт вычислительных технологий СО РАН, Новосибирск
© 2001, Институт систем информатики СО РАН, Новосибирск
© 2001, Институт математики СО РАН, Новосибирск
© 2001, Институт цитологии и генетики СО РАН, Новосибирск
© 2001, Институт вычислительной математики и математической геофизики СО РАН, Новосибирск
© 2001, Новосибирский государственный университет
Дата последней модификации Saturday, 01-Sep-2001 21:44:09 NOVST