Базы данных. Краморенко Н.В. - 77 стр.

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

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

       Темпоральные БД
       Обычные БД хранят мгновенный снимок модели предметной области. Любое изменение в
момент времени t некоторого объекта приводит к недоступности состояния этого объекта в
предыдущий момент времени. Самое интересное, что на самом деле в большинстве развитых СУБД
предыдущее состояние объекта сохраняется в журнале изменений, но возможности доступа со
стороны пользователя нет.
       Конечно, можно явно ввести в хранимые отношения явный временной атрибут и
поддерживать его значения на уровне приложений. Более того, в большинстве случаев так и
поступают. Недаром в стандарте SQL появились специальные типы данных date и time. Но в таком
подходе имеются несколько недостатков: СУБД не знает семантики временного поля отношения и не
может контролировать корректность его значений; появляется дополнительная избыточность
хранения (предыдущее состояние объекта данных хранится и в основной БД, и в журнале
изменений); языки запросов реляционных СУБД не приспособлены для работы со временем.
       Существует отдельное направление исследований и разработок в области темпоральных БД.
В этой области исследуются вопросы моделирования данных, языки запросов, организация данных
во внешней памяти и т.д. Основной тезис темпоральных систем состоит в том, что для любого
объекта данных, созданного в момент времени t1 и уничтоженного в момент времени t2, в БД
сохраняются (и доступны пользователям) все его состояния во временном интервале [t1,t2].
       Исследования и построения прототипов темпоральных СУБД обычно выполняются на основе
некоторой реляционной СУБД. Темпоральная СУБД - это надстройка над реляционной системой.
Конечно, это не лучший способ реализации с точки зрения эффективности, но он прост и позволяет
производить достаточно глубокие исследования.




                                              78