21.2. Некоторые аспекты технологии поддержки принятия решений

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

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

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

. Столбцы чаще всего используются в сочетаниях.

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

Ключи часто содержат временной компонент (глава 22).

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

В базе данных, как правило, интенсивно применяется индексация.

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

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

Сложность булевых выражений. Запросы поддержки принятия решений часто включают сложные выражения в предложении WHERE. Эти выражения сложно записывать, в них непросто разбираться и также трудно их выполнять. (В частности, классические оптимизаторы не всегда правильно обрабатывают подобные запросы, поскольку они проектируются для весьма ограниченного числа стратегий доступа.) Типичные проблемы вызывают запросы, в которых содержится значение времени. Современные системы обычно не предоставляют удовлетворительной поддержки, например, для таких запросов, когда требуются строки с максимальным значением временной метки в заданный период времени (глава 22). Если в

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

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

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

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

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

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

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

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

21.3. Проектирование базы данных поддержки принятия решений

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

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

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

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

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