Главная » SQL, Базы данных » НЕКОТОРЫЕ ОСОБЕННОСТИ ТЕХНОЛОГИИ ПОДДЕРЖКИ ПРИНЯТИЯ РЕШЕНИЙ

0

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

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

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

физические.

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

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

■     Ключи часто содержат временной компонент (безусловно, поддержка хронологиче ски упорядоченных данных была бы чрезвычайно полезной, как описано в главе 23, но предоставляется редко).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник: Дейт К. Дж., Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом «Вильямс», 2005. — 1328 с.: ил. — Парал. тит. англ.

По теме:

  • Комментарии