Системы поддержки принятия решений

Системы поддержки принятия решений — это системы, которые служат для анализа деловой информации. Их назначение — помочь "выявить тенденции, определить проблемы и предложить... разумное решение". Подобные системы создаются на основе таких теорий, как исследование операций, теория поведения и научная теория управления, а также методы статистической обработки. Первые теоретические работы в этой области появились в конце 40-х и начале 50-х годов, т.е. задолго до того, как компьютеры приобрели широкое распространение. Основной идеей было и по-прежнему остается накопление производственных операционных данных и приведение их к виду, в котором они могли бы использоваться для анализа хода деловых процессов и корректировки делового поведения с целью приведения его в разумное русло. На первых порах степень преобразования данных была почти минимальной — обычно все сводилось к составлению простых итоговых отчетов.

В конце 60-х и начале 70-х годов исследователи Гарвардского университета начали пропагандировать использование компьютеров в процессе выработки решений. Сначала такое использование ограничивалось в основном автоматизацией генерации отчетов, хотя иногда предусматривались и элементарные аналитические возможности. Первые компьютерные системы сначала назывались автоматизированными системами управления, а позже — системами управления информацией. Современный термин таких систем — системы поддержки принятия решений, поскольку все информационные системы, включая, например, систему оперативной обработки транзакций (OLTP), могут или должны считаться "системами управления информацией" (в конечном счете, все они используются и влияют на управление деловыми процессами).

В 70-х годах также велись разработки нескольких языков запросов, и на их основе было создано несколько заказных (внутренних) систем поддержки принятия решений. Они реализовывались с применением средств генерации отчетов, таких как язык RPG, или систем поиска данных, таких как Focus, Datatrieve и NOMAD. Эти системы были первыми из числа тех, которые позволяли соответствующим образом подготовленным конечным пользователям получать непосредственный доступ к банкам данных на компьютере. Иначе говоря, они позволяли пользователям формулировать производственные запросы к банкам данных и выполнять эти запросы, не ожидая помощи от информационно-технологического подразделения.

То, что мы называем банком данных (data store), тогда чаще всего представляло собой просто набор файлов — производственные данные хранились или в отдельных файлах, или в не реляционных базах данных (реляционные системы еще только начинали разрабатываться). И даже в последнем случае данные извлекались из базы данных и копировались в файлы, прежде чем они могли быть обработаны системой поддержки принятия решений. Так продолжалось почти до начала 80-х годов, пока для систем поддержки принятия решений вместо простых файлов не начали использоваться реляционные базы данных. На самом деле поддержка принятия решений, обработка произвольных (ad hoc) запросов и выдача отчетов были первыми практическими задачами, использовавшими реляционную технологию.

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

Поддержка принятия решений не является частью самой технологии баз данных. Это скорее одно из применений данной технологии (хотя и очень важное), или, точнее, несколько видов такого применения, отдельных, но связанных между собой. Перечислим эти виды: хранилища данных (data warehouse), магазины данных (data mart), банки оперативных данных (operational data store), оперативная аналитическая обработка (OLAP — online analytical processing), многомерные базы данных и разработка данных.

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

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

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

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

Ниже приведены характеристики базы данных поддержки принятия решений. Первые три из них — логические, а три оставшиеся — физические.

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

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

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

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

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

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

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

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

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

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

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

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