Реализация концепции темпоральной базы данных средствами реляционной субд



Скачать 185.21 Kb.
Дата22.04.2016
Размер185.21 Kb.
Реализация концепции темпоральной базы данных средствами реляционной СУБД

Порай Д.С., Соловьев Ан.В., Корольков Г.В.


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

1.Введение


При разработке информационных систем часто приходится сталкиваться с требованиями о необходимости хранения не только актуального состояния данных, но и истории их изменения. В настоящее время решением этой задачи занимается отдельное направление в теории баз данных – темпоральные (или временные) базы данных [2]. Основной идеей этого направления является расширение основного объекта реляционной теории – таблицы – таким образом, что она из двумерной становится трехмерной (см. Рисунок 1). В этой модели изменение значения атрибута приводит к появлению нового исторического элемента без уничтожения старого. При этом все старые записи могут быть получены из таблицы, для чего темпоральные базы данных реализуют расширение языка запросов SQL. В настоящее время идет работа над развитием стандарта SQL под названием SQL/Temporal [1]. Однако эта работа продолжается уже несколько лет и результатов пока ждать не приходится.

Рисунок 1. Введение времени в реляционную модель

Одним из важных моментов теории темпоральных баз данных является ответ на вопрос «что такое время»? Событие, отражением которого является новый исторический элемент в базе данных, в реальной жизни часто происходит раньше того момента, когда оператор вводит информацию в базу данных. Получается, что с событием ассоциируется две временные отметки: время в реальной жизни и время внесения изменения в базу данных. Первое понятие называют действительным временем, второе – временем транзакции. Темпоральная СУБД должна хранить в базе данных оба значения времени и позволять делать поиск по обоим значениям.
В данной статье предлагается методика, позволяющая реализовать хранение данных в историческом развитии с применением обычной реляционной СУБД без специальных темпоральных расширений. Методика предполагает следующую последовательность действий:


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

  2. Преобразование схемы базы данных для учета истории изменений.

  3. Преобразование операций над базой данных для учета истории изменений.

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


Интересной особенностью предлагаемого подхода является то, что выполнение всех вышеупомянутых действий позволяет решить еще две важные задачи:

  1. Организация репликации данных между территориально распределенными базами.

  2. Организация протоколирования всех действий пользователей с возможностью просмотра журнала операций администратором системы.

Далее будет предполагаться, что база данных спроектирована с использованием модели «сущность-связь» (Entity-Relationship), иллюстрации приведены в нотации IDEF1X [3].


2.Алгоритм преобразования схемы базы данных


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

2.1.Классификация таблиц базы данных


Первым шагом необходимо разбить все таблицы базы данных на следующие группы:

  1. Редко изменяемые таблицы:

    1. Классификаторы. Они изменяются редко и изменяются централизованно. Для этих таблиц не имеет смысла хранить историю изменения записей.

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

  2. Изменяемые таблицы:

    1. Терминальные таблицы. Это таблицы, на которые нет ссылок из других таблиц.

    2. Нетерминальные таблицы. Это таблицы, на которые есть ссылки из других таблиц.



2.2.Дополнение схемы базы данных служебными таблицами


На втором шаге необходимо ввести в схему базы данных несколько служебных таблиц (см. Рисунок 2, Рисунок 3 и Таблица 1). Каждая из таблиц будет детально рассмотрена далее.

Рисунок 2. Логическая модель служебной части базы данных


Рисунок 3. Физическая модель служебной части базы данных


Таблица 1

Название

сущности


Название

таблицы


Описание

Подразделение

CMNDPT

Таблица подразделений содержит информацию о территориально-распределенных подразделениях организации. Она используется для репликации и синхронизации баз данных подразделений.

Код операции

CMNOPERNMB

Таблица с кодами и названиями операций.

Операция

CMNOPER

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

Операция

обновления



CMNOPERUPD

Таблица содержит информацию об операциях добавления и обновления «редко изменяемых таблиц». Она используется для репликации и синхронизации баз данных подразделений.

Реплицированная операция

CMNRPLOPER

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



2.3.Преобразование таблиц базы данных


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

  1. Редко изменяемые таблицы:

    1. Классификаторы. Данную группу таблиц оставить без изменений.

    2. Таблицы с нарастающим итогом. Таблицу необходимо связать не идентифицирующей связью с таблицей CMNOPER. Т.е. в таблице (но не в первичном ключе) появится атрибут «время операции» (поле OPERTIME), являющийся ссылкой на таблицу CMNOPER.

  2. Изменяемые таблицы:

    1. Терминальные таблицы:

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

      2. Добавить в таблицу атрибуты «дата начала» и «дата окончания» (поля STRDATE и ENDDATE) типа «Дата». Поле ENDDATE при этом должно быть со значением по умолчанию (DEFAULT), равным 3000-01-01 (первое января 3000 года – дата, заведомо превышающая любую дату в базе данных). Эти поля будут хранить действительные даты начала и окончания временного интервала, в который данная запись являлась (или является) актуальной.

      3. Добавить во все индексы на таблицу поле STRDATE в конец списка.

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

    1. Нетерминальные таблицы:

      1. Необходимо сделать парную таблицу.

      2. Связать эту таблицу с основной таблицей идентифицирующей связью.

      3. Связать эту таблицу идентифицирующей связью с таблицей операций. Т.е. в первичном ключе таблицы появится поле OPERTIME, являющееся ссылкой на таблицу CMNOPER.

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

      5. Добавить в эту таблицу поля STRDATE и ENDDATE по аналогии с терминальной таблицей.

      6. Связать основную таблицу не идентифицирующей связью с таблицей операций. Т.е. в таблице (но не в первичном ключе) появится поле OPERTIME, являющееся ссылкой на таблицу CMNOPER.

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



  • Сущность «Договор» – нетерминальная таблица.

  • Сущность «Тип договора» – классификатор.

  • Сущность «Заказ» – терминальная таблица.

  • Сущность «Взнос по договору» ­– таблица с нарастающим итогом.

После преобразования по приведенному алгоритму получится следующая схема базы данных (см. Рисунок 5). Эта схема отличается от оригинальной следующим образом:



  • Сущность «Договор» (нетерминальная таблица) – разбита на две сущности. «Договор» включает в себя первичный ключ и поле «время операции». «Договор - данные» включает в себя поля старой таблицы плюс поля «время операции», «дата начала» и «дата окончания».

  • Сущность «Тип договора» (классификатор) – не изменилась.

  • Сущность «Заказ» (терминальная таблица) – появились новые поля «время операции», «дата начала» и «дата окончания».

  • Сущность «Взнос по договору» ­(таблица с нарастающим итогом) – появилось новое поле «время операции».

Рисунок 4. Пример логической модели до преобразования


Рисунок 5. Пример логической модели после преобразования



2.4.Создание триггеров


В предложенной схеме существенным моментом является корректное заполнение поля ENDDATE в каждой записи таким образом, чтобы в каждый момент времени существовало не более одной записи с данным первичным ключом (в смысле старой схемы). Для реализации механизма заполнения лучше всего подходят триггеры. Триггеры типа AFTER INSERT должны быть написаны для всех таблиц, имеющих поля STRDATE и ENDDATE. Реализация триггера зависит от используемой СУБД, но в целом она должна выглядеть следующим образом:
SET strdate = [Поле STRDATE из новой записи]

SET enddateFlagged = [Поле ENDDATE из новой записи]

SET rrn = [Внутренний идентификатор базы данных

для новой записи]


Ищем старую запись, с которой новая запись пересекается

по времени

SELECT ENDDATE

INTO :enddate

FROM [Таблица]

WHERE

[Условие на первичный ключ] AND



STRDATE <= :strdate AND ENDDATE > :strdate AND

RRN([Таблица]) != :rrn


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

if [Запись нашлась]

then

Элемент добавлен в середину истории

UPDATE [Таблица]

SET ENDDATE = :strdate

WHERE


[Условие на первичный ключ] AND

STRDATE <= :strdate AND ENDDATE > :strdate AND

RRN([Таблица]) != :rrn

else


SELECT MIN(STRDATE)

INTO :enddate

FROM [Таблица]

WHERE [Условие на первичный ключ] AND

STRDATE > :strdate;

if [Запрос вернул NULL]

then

Считаем, что элемент добавлен в конец истории

SET enddate = '3000-01-01'

else

Считаем, что элемент добавлен в 'дырку' или в начало

истории

end if


end if
if strdate <> enddateFlagged

then


Устанавливаем поле ENDDATE новой записи

UPDATE [Таблица]

SET ENDDATE = :enddate

WHERE RRN([Таблица]) = :rrn

else

Если поля STRDATE и ENDDATE у новой записи равны,

то это означает, что выполняется операция по «удалению»

записи. В этом случае триггер не изменяет поля ENDDATE.

Во всех остальных случаях поле ENDDATE приходит со

значением 3000-01-01 и выполняется ветка then данного

оператора if.

end if
В данном примере под [Условием на первичный ключ] понимается условие вида:

F1 = [Значение поля F1 из новой записи] AND

F2 = [Значение поля F2 из новой записи] AND



и т.д.
При этом в него входят все поля из первичного ключа, кроме поля OPERTIME.

3.Операции над данными

3.1.Алгоритм преобразования запросов


Запросы манипуляции данными можно разделить на две категории: запросы на чтение и запросы на изменение данных. Запросы этих двух категорий преобразуются по-разному. Связано это с тем, что запросы на изменение оставляют след в журнале операций, а запросы на чтение – нет. Отказ от протоколирования запросов на чтение связано с тем, что такие запросы выполняются часто, и их протоколирование приведет к слишком серьезной загрузке системы в целом.
Все запросы на изменение данных предваряются вставкой записи в журнал операций (таблицу CMNOPER). При этом поле OPERTIME, являющееся ключом, формируется специальной процедурой по следующему принципу:

  1. В качестве базового значения берется текущее время.

  2. Младшие разряды (миллисекунды) заменяются кодом подразделения, в котором выполняется данная операция.

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

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

3.1.1.Запрос SELECT


Запросы на чтение данных оперируют «действительным временем», т.е. они осуществляют выборку записей, актуальных в определенную дату реальной жизни. Запросы типа SELECT необходимо преобразовать по следующему принципу:

  1. Редко изменяемые таблицы. Запрос сохраняется в оригинальном виде.

  2. Изменяемые таблицы:

    1. Терминальные таблицы. Запрос дополняется условием

AND STRDATE <= CURRENT_DATE AND CURRENT_DATE < ENDDATE

    1. Нетерминальные таблицы. Запрос к таблице заменяется запросом на парную таблицу и дополняется приведенным выше условием.

В случае выборки истории изменений вместо актуальных значений ключевое слово CURRENT_DATE заменяется датой, отражающей действительное время, по состоянию на которую необходимо получить выборку из таблицы.
Выборка записей, актуальных в определенное системное время возможна, но требует существенной перестройки и усложнения SQL запросов. Вместо условия на поля STRDATE и ENDDATE должно быть записано следующее условие:

AND OPERTIME IN

(SELECT MAX(OPERTIME)

FROM [Таблица] T

WHERE

[Таблица].F1 = T.F1 AND



[Таблица].F2 = T.F2 AND

и т.д.


AND OPERTIME < [Искомое время]

)

Следует отметить, что такой запрос выполняется значительно медленнее, чем запрос на действительно время, однако он все же возможен.


3.1.2.Запрос INSERT


Запросы типа INSERT необходимо преобразовать по следующему принципу:

  1. Редко изменяемые таблицы:

    1. Классификаторы. Запрос сохраняется в оригинальном виде. В дополнение текст запроса протоколируется в таблице CMNOPERUPD. Т.е. в таблицу CMNOPERUPD добавляется запись, в которой поле OPERTIME равно времени транзакции, а поле DESCR равно тексту SQL-запроса.

    2. Таблицы с нарастающим итогом. Текст запроса дополняется полем OPERTIME, которое устанавливается в идентификатор операции.

  2. Изменяемые таблицы:

    1. Терминальные таблицы. Текст запроса дополняется полями:

      1. OPERTIME, которое устанавливается в идентификатор операции.

      2. STRDATE, которое устанавливается в действительную дату операции. Поле ENDDATE при этом в запросе не упоминается, оно вычисляется триггером.

    2. Нетерминальные таблицы. Запрос разбивается на два последовательных запроса:

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

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

3.1.3.Запрос UPDATE


Запросы типа UPDATE необходимо преобразовать по следующему принципу:

  1. Редко изменяемые таблицы. Запрос сохраняется в оригинальном виде. В дополнение текст запроса протоколируется в таблице CMNOPERUPD.

  2. Изменяемые таблицы:

    1. Терминальные таблицы. Запрос UPDATE заменяется запросом INSERT, который устанавливает все поля таблицы и еще поля:

      1. OPERTIME, которое устанавливается в идентификатор операции.

      2. STRDATE, которое устанавливается в действительную дату операции. Поле ENDDATE при этом в запросе не упоминается, оно вычисляется триггером.

    2. Нетерминальные таблицы. Запрос UPDATE заменяется запросом INSERT в парную таблицу. Этот запрос полностью аналогичен запросу INSERT в терминальную таблицу, рассмотренному в предыдущем пункте.

3.1.4.Запрос DELETE


Запросы типа DELETE необходимо преобразовать по следующему принципу:

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

  2. Изменяемые таблицы:

    1. Терминальные таблицы. Запрос DELETE заменяется запросом INSERT, который устанавливает все поля таблицы в значения, актуальные на текущую дату, и еще поля:

      1. OPERTIME, которое устанавливается в идентификатор операции.

      2. STRDATE, которое устанавливается в действительную дату операции.

      3. ENDDATE, которое устанавливается равным STRDATE.

    2. Нетерминальные таблицы. Запрос DELETE заменяется запросом INSERT в парную таблицу. Этот запрос полностью аналогичен запросу INSERT в терминальную таблицу, рассмотренному в предыдущем пункте.

3.2.Репликация базы данных


Предложенный способ модификации схемы базы данных позволяет не только дополнить ее функциональностью для хранения истории изменений, но и решить вопрос с репликацией данных. Рассмотрим типичную структуру территориально-распределенной организации (см. Рисунок 6). В данной схеме присутствует центральный офис и некоторое количество офисов, территориально удаленных друг от друга. Это могут быть филиалы, региональные представительства и т.д.

Рисунок 6. Типичная структура территориально-распределенной организации

Каждый офис имеет собственный сервер базы данных, все офисы связаны в иерархию каналами связи. В каждом офисе выполняется определенная обработка данных. Вся информация из нижестоящих подразделений должна передаваться в вышестоящие подразделения. База данных центрального офиса аккумулирует всю информацию организации. Часть информации направляется нисходящим потоком из центрального офиса в подразделения. Фильтрация происходит по принципу «база данных подразделения должна содержать только данные, необходимые для работы данного подразделения».

Пропускная способность каналов позволяет передавать информацию в режиме off line, но она недостаточна для удаленной работы в режиме on line. Кроме того, характеристики каналов позволяют осуществлять обмен текущей информацией, но их недостаточно для ежедневного перекачивания всей базы данных.

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

3.2.1.Посылка пакета


Сохранение измененной части базы данных выполняется процедурой, имеющей примерно следующий вид:

Выгрузка списка операций

INSERT INTO TMPDB.CMNOPER

(SELECT *

FROM CMNOPER

WHERE NOT EXISTS

(SELECT *

FROM CMNRPLOPER

WHERE CMNRPLOPER.OPERTIME = CMNOPER.OPERTIME AND

CMNRPLOPER.DPTCOD = [Подразделение-получатель]

)

)


Выгрузка изменяемых таблиц, таблиц с нарастающим итогом

и таблицы CMNOPERUPD – для каждой таблицы. Порядок выгрузки

значения не имеет.

INSERT INTO TMPDB.[Таблица]

(SELECT [Таблица].*

FROM [Таблица], TMPDB.CMNOPER

WHERE [Таблица].OPERTIME = TMPDB.CMNOPER.OPERTIME

)
Установка пометок о том, что операции были переданы

INSERT INTO CMNRPLOPER

(SELECT OPERTIME, [Подразделение-получатель], CURRENT DATE

FROM TMPDB.CMNOPER

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


3.2.2.Прием пакета


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

Прием данных из пакета.

Запрос должен выполняться для каждой изменяемой таблицы,

таблицы с нарастающим итогом и таблицы CMNOPERUPD.

Запросы должны выполняться в порядке, определяемом ссылочными

ограничениями целостности (FOREIGN KEY).

INSERT INTO [Таблица]

(SELECT *

FROM TMPDB.[Таблица]

)

После этой процедуры должны быть выполнены все SQL-запросы, пришедшие в таблице TMPDB.CMNOPERUPD, полученные в порядке увеличения OPERTIME:



SELECT DESCR

FROM TMPDB.CMNOPERUPD

ORDER BY OPERTIME

После этого должны быть установлены пометки о том, что пакет получен:

INSERT INTO CMNRPLOPER

(SELECT OPERTIME, [Подразделение-отправитель], CURRENT DATE

FROM TMPDB.CMNOPER

)

3.2.3.Частичная выгрузка


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

3.3.Просмотр журнала операций


Предлагаемый подход позволяет реализовать еще одну функциональную возможность, которая часто бывает необходимой в информационных системах – возможность просмотра журнала операций в удобном виде с возможностью фильтрации и поиска записей. Для этого в системе необходимо создать два представления (VIEW) следующего вида.
Представление CMNPRT1 является промежуточным. Оно сопоставляет

идентификатору операции OPERTIME значения ключевых полей

таблиц, которые были затронуты данной операцией.

В данном примере это [номер договора] и [номер заказа]
CREATE VIEW CMNPRT1 AS

(SELECT


CMNOPER.OPERTIME, CMNOPER.REALDATE, CMNOPERNMB.NAME,

CASE


WHEN [Договор].[номер договора] IS NOT NULL

THEN [Договор].[номер договора]

WHEN [Договор-данные].[номер договора] IS NOT NULL

THEN [Договор-данные].[номер договора]

WHEN [Взнос по договору].[номер договора] IS NOT NULL

THEN [Взнос по договору].[номер договора]

WHEN [Заказ].[номер договора] IS NOT NULL

THEN [Заказ].[номер договора]

и т.д.

END AS [номер договора],



[Взнос по договору].[сумма],

[Заказ].[номер заказа]

и т.д.

FROM CMNOPER



JOIN CMNOPERNMB ON CMNOPER.OPERNMB=CMNOPERNMB.OPERNMB

LEFT JOIN [Договор] ON CMNOPER.OPERTIME=[Договор].OPERTIME

LEFT JOIN [Договор-данные] ON

CMNOPER.OPERTIME=[Таблица2].OPERTIME

LEFT JOIN [Взнос по договору] ON

CMNOPER.OPERTIME=[Взнос по договору].OPERTIME

LEFT JOIN [Заказ] ON CMNOPER.OPERTIME=[Заказ].OPERTIME

и т.д.


);
Представление CMNPRT является основным. Оно сопоставляет идентификатору операции OPERTIME ключи и содержательные поля

таблиц, которые были затронуты данной операцией.

В данном примере такими полями являются поля [описание]

из таблиц [Договор-данные] и [Заказ].


CREATE VIEW CMNPRT AS

(SELECT


CMNPRT1.OPERTIME, CMNPRT1.REALDATE, CMNPRT1.NAME,

CMNPRT1.[номер договора], [Договор-данные].[описание],

CMNPRT1.[сумма],

CMNPRT1.[номер заказа], [Заказ].[описание],

и т.д.

FROM CMNPRT1



LEFT JOIN [Договор-данные] ON

CMNPRT1.[номер договора]=[Договор-данные].[номер договора]

LEFT JOIN [Заказ] ON

CMNPRT1.[номер договора]=[Заказ].[номер договора] AND

CMNPRT1.[номер заказа]=[Заказ].[номер заказа]

и т.д.


WHERE

[Договор-данные].STRDATE <= CMNPRT1.REALDATE AND

CMNPRT1.REALDATE < [Договор-данные].ENDDATE AND

[Заказ].STRDATE <= CMNPRT1.REALDATE AND

CMNPRT1.REALDATE < [Заказ].ENDDATE AND

и т.д.


);
Из созданного таким образом представления CMNPRT клиентская программа может делать выборку записей непосредственно для показа администратору:

SELECT *


FROM CMNPRT

ORDER BY OPERTIME


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

4.Опыт применения


Описанный подход был успешно применен для большей части таблиц базы данных при создании информационной системы для одного из негосударственных пенсионных фондов. Система реализована на платформе AS/400 с использованием СУБД DB2/400. Опыт показал, что применение методики приводит к усложнению базы данных (за счет появления парных таблиц) и усложнению запросов. Система в целом требует более тщательного тестирования, поскольку наиболее частая ошибка потери в запросе фильтрации по времени (STRDATE <= CURRENT_DATE AND CURRENT_DATE < ENDDATE) проявляется только при наличии в данной конкретной таблице более одного исторического элемента.

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


5.Заключение


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

6.Литература


  1. Айзенберг Эндрю, Мелтон Джим. Стандартизация SQL: следующие шаги // Открытые системы, 1999, №11-12.

  2. Саймон А.Р. Стратегические технологии баз данных: менеджмент на 2000 год: Пер. с англ. / Под ред. и с пред. Когаловского – М.: Финансы и статистика, 1999.

  3. Integration Definition for Information Modeling (IDEF1X). Federal Information Processing Standard (FIPS). Publication 184. December 1993.








База данных защищена авторским правом ©bezogr.ru 2016
обратиться к администрации

    Главная страница