ВУЗ:
Составители:
Рубрика:
83
использоваться (и реально используется в научно-исследовательских лабораториях
компании IBM) как мощное и гибкое средство исследования методов оптимизации
запросов. Конечно, сомнительно, что технология, положенная в основу Starburst, позволит
этой системе конкурировать с такими выполненными в традиционной манере
коммерческими СУБД, как DB2, Oracle, Informix и т.д.
Поддержка исторической информации и темпоральных запросов
Обычные БД хранят мгновенный снимок модели предметной области. Любое
изменение в момент времени t некоторого объекта приводит к недоступности состояния
этого объекта в предыдущий момент времени. Самое интересное, что на самом деле в
большинстве развитых СУБД предыдущее состояние объекта сохраняется в журнале
изменений, но возможности доступа со стороны пользователя нет.
Конечно, можно явно ввести в хранимые отношения явный временной атрибут и
поддерживать его значения на уровне приложений. Более того, в большинстве случаев так
и поступают. Недаром в стандарте SQL появились специальные типы данных date и time.
Но в таком подходе имеются несколько недостатков: СУБД не знает семантики
временного поля отношения и не может контролировать корректность его значений;
появляется дополнительная избыточность хранения (предыдущее состояние объекта
данных хранится и в основной БД, и в журнале изменений); языки запросов реляционных
СУБД не приспособлены для работы со временем.
Существует отдельное направление исследований и разработок в области
темпоральных БД. В этой области исследуются вопросы моделирования данных, языки
запросов, организация данных во внешней памяти и т.д. Основной тезис темпоральных
систем состоит в том, что для любого объекта данных, созданного в момент времени t
1
и
уничтоженного в момент времени t
2
, в БД сохраняются (и доступны пользователям) все
его состояния во временном интервале [t
1
,t
2
].
Исследования и построения прототипов темпоральных СУБД обычно выполняются
на основе некоторой реляционной СУБД. Как и в случае дедуктивных БД темпоральная
СУБД - это надстройка над реляционной системой. Конечно, это не лучший способ
реализации с точки зрения эффективности, но он прост и позволяет производить
достаточно глубокие исследования.
Примером кардинального (но, может быть, преждевременного) решения проблемы
темпоральных БД может служить СУБД Postgres. Эта система была спроектирована и
разработана М.Стоунбрекером для исследований и обучения студентов в университете
г.Беркли, и он безбоязненно шел в ней на самые смелые эксперименты.
Главными особенностями системы управления памятью в Postgres являются, во-
первых, то, что в ней не ведется обычная журнализация изменений базы данных и
мгновенно обеспечивается корректное состояние базы данных после перевызова системы
с утратой состояния оперативной памяти. Во-вторых, система управления памятью
поддерживает исторические данные. Запросы могут содержать временные характеристики
интересующих объектов. Реализационно эти два аспекта связаны.
Основное решение состоит в том, что при модификациях кортежа изменения
производятся не на месте его хранения, а заводится новая запись, куда помещаются
измененные поля. Эта запись содержит, кроме того, данные, характеризующие
транзакцию, производившую изменения (в том числе и время ее завершения), и
подшивается в список к изменявшемуся кортежу. В системе поддерживается уникальная
идентификация транзакций и имеется специальная таблица транзакций, хранящаяся в
стабильной памяти. Таким образом, после сбоев просто не следует обращать внимание на
хвостовые записи списков, относящиеся к незакончившемся транзакциям. Синхронизация
поддерживается на основе обычного двухфазного протокола захватов.
использоваться (и реально используется в научно-исследовательских лабораториях
компании IBM) как мощное и гибкое средство исследования методов оптимизации
запросов. Конечно, сомнительно, что технология, положенная в основу Starburst, позволит
этой системе конкурировать с такими выполненными в традиционной манере
коммерческими СУБД, как DB2, Oracle, Informix и т.д.
Поддержка исторической информации и темпоральных запросов
Обычные БД хранят мгновенный снимок модели предметной области. Любое
изменение в момент времени t некоторого объекта приводит к недоступности состояния
этого объекта в предыдущий момент времени. Самое интересное, что на самом деле в
большинстве развитых СУБД предыдущее состояние объекта сохраняется в журнале
изменений, но возможности доступа со стороны пользователя нет.
Конечно, можно явно ввести в хранимые отношения явный временной атрибут и
поддерживать его значения на уровне приложений. Более того, в большинстве случаев так
и поступают. Недаром в стандарте SQL появились специальные типы данных date и time.
Но в таком подходе имеются несколько недостатков: СУБД не знает семантики
временного поля отношения и не может контролировать корректность его значений;
появляется дополнительная избыточность хранения (предыдущее состояние объекта
данных хранится и в основной БД, и в журнале изменений); языки запросов реляционных
СУБД не приспособлены для работы со временем.
Существует отдельное направление исследований и разработок в области
темпоральных БД. В этой области исследуются вопросы моделирования данных, языки
запросов, организация данных во внешней памяти и т.д. Основной тезис темпоральных
систем состоит в том, что для любого объекта данных, созданного в момент времени t1 и
уничтоженного в момент времени t2, в БД сохраняются (и доступны пользователям) все
его состояния во временном интервале [t1,t2].
Исследования и построения прототипов темпоральных СУБД обычно выполняются
на основе некоторой реляционной СУБД. Как и в случае дедуктивных БД темпоральная
СУБД - это надстройка над реляционной системой. Конечно, это не лучший способ
реализации с точки зрения эффективности, но он прост и позволяет производить
достаточно глубокие исследования.
Примером кардинального (но, может быть, преждевременного) решения проблемы
темпоральных БД может служить СУБД Postgres. Эта система была спроектирована и
разработана М.Стоунбрекером для исследований и обучения студентов в университете
г.Беркли, и он безбоязненно шел в ней на самые смелые эксперименты.
Главными особенностями системы управления памятью в Postgres являются, во-
первых, то, что в ней не ведется обычная журнализация изменений базы данных и
мгновенно обеспечивается корректное состояние базы данных после перевызова системы
с утратой состояния оперативной памяти. Во-вторых, система управления памятью
поддерживает исторические данные. Запросы могут содержать временные характеристики
интересующих объектов. Реализационно эти два аспекта связаны.
Основное решение состоит в том, что при модификациях кортежа изменения
производятся не на месте его хранения, а заводится новая запись, куда помещаются
измененные поля. Эта запись содержит, кроме того, данные, характеризующие
транзакцию, производившую изменения (в том числе и время ее завершения), и
подшивается в список к изменявшемуся кортежу. В системе поддерживается уникальная
идентификация транзакций и имеется специальная таблица транзакций, хранящаяся в
стабильной памяти. Таким образом, после сбоев просто не следует обращать внимание на
хвостовые записи списков, относящиеся к незакончившемся транзакциям. Синхронизация
поддерживается на основе обычного двухфазного протокола захватов.
83
Страницы
- « первая
- ‹ предыдущая
- …
- 81
- 82
- 83
- 84
- 85
- …
- следующая ›
- последняя »
