Банки оперативных данных

Банки оперативных данных представляют собой "предметно-ориентированные, интегрированные, изменчивые, т.е. обновляемые, текущие, или почти текущие, коллекции данных".

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

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

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

Логические системы управления базами данных

В середине 80-х годов в области исследования баз данных сформировалось мощное направление, предметом изучения которого стали системы управления базами данных, основанные на логике.

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

Исследования связей между базами данных и логикой начались еще в конце 70-х годов. Однако интерес к этой теме значительно возрос после публикации в 1984 году работы Рейтера (Reiter). В ней традиционное представление баз данных характеризуется как модельно-теоретическое. Проще говоря, это означает следующее.

1. База данных в любой момент может рассматриваться как набор явно заданных (т.е. базовых) отношений, каждое из которых включает набор явно заданных кортежей.

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

В работе Рейтера наряду с модельно-теоретическим подходом рассматривается более предпочтительная в некоторых отношениях альтернатива — доказательно-теоретическое представление. Особенности этого представления заключаются в следующем.

1.База данных рассматривается как набор аксиом ("основных" аксиом, соответствующих значениям домена и кортежам базовых отношений, а также определенных "дедуктивных" аксиом, которые более подробно описаны ниже).

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

Доказательно-теоретическое представление очень близко к описанию базы данных как набора истинных высказываний.

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

SPX WHERE SPX.QTY > 250

(Здесь SPX — это, конечно, переменная кортежа, принимающая значения из отношения поставок.) В традиционной, т.е. модельно-теоретической, интерпретации необходимо последовательно проверить все кортежи с данными о поставках и оценить для каждого из них результат вычисления формулы QTY > 250. При выполнении этого запроса будут извлечены все кортежи с описанием поставок, для которых данное выражение будет истинным. В противоположность этому при доказательно-теоретической интерпретации кортежи с описанием поставок (а также некоторые дополнительные объекты) рассматриваются как аксиомы некой логической теории. Затем при обработке запроса применяется доказательно-теоретический метод с целью выяснения, для каких возможных значений переменной SPX формула SPX.QTY>250 является логическим следствием аксиом этой теории. Результатом выполнения запроса будут отдельные значения переменной-отношения SPX.

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

Единство представления. Появляется возможность задать единый язык для всей базы данных, согласно которому доменные значения, кортежи базовых отношений, "дедуктивные аксиомы", запросы и ограничения целостности будут представлены одинаковым образом.

Единство действия. Предоставляется единая основа для решения различных задач, включая оптимизацию запросов (особенно — семантическую оптимизацию), обеспечение ограничений целостности, проектирование базы данных (теория зависимостей), доказательство корректности программ и др.

Семантическое моделирование. Появляется твердая основа для построения множества "семантических" расширений основной модели.

Расширенное применение. Наконец, обеспечивается основа для решения таких проблем, с которыми не могут справиться системы на основе классических подходов, например для работы с дизъюнктивной информацией наподобие "Поставщик с номером 'S5' поставляет либо деталь с номером 'Р1', либо деталь с номером 'Р2', но какую именно, точно неизвестно".

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