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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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