|
|
СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ #04-05/98
|
|
Современный уровень развития аппаратных и программных средств с некоторых пор сделал возможным повсеместное ведение баз данных оперативной информации на всех уровнях управления. В процессе своей деятельности промышленные предприятия, корпорации, ведомственные структуры, органы государственной власти и управления накопили большие объемы данных. Они хранят в себе большие потенциальные возможности по извлечению полезной аналитической информации, на основе которой можно выявлять скрытые тенденции, строить стратегию развития, находить новые решения.
В последние годы в мире оформился ряд новых концепций хранения и анализа корпоративных данных:
Обзору этих концепций, а также доказательству их взаимодополняемости в деле поддержки принятия управленческих решений, посвящена настоящая статья.
В области информационных технологий всегда сосуществовали два класса систем [16, С. 49]:
На первых стадиях информатизации всегда требуется навести порядок именно в процессах повседневной рутинной обработки данных, на что и ориентированы традиционные СОД, поэтому опережающее развитие этого класса систем вполне объяснимо.
Системы второго класса √ СППР √ являются вторичными по отношению к ним. Часто возникает ситуация, когда данные в организации накапливаются с ряде несвязанных СОД, во многом дублируя друг друга, но не будучи никак согласованы. В таком случае достоверную комплексную информацию получить практически невозможно, несмотря на ее кажущийся избыток.
Целью построения корпоративного хранилища данных является интеграция, актуализация и согласование оперативных данных из разнородных источников для формирования единого непротиворечивого взгляда на объект управления в целом. При этом в основе концепции хранилищ данных лежит признание необходимости разделения наборов данных, используемых для транзакционной обработки, и наборов данных, применяемых в системах поддержки принятия решений. Такое разделение возможно путем интеграции разъединенных в СОД и внешних источниках детализированных данных в едином хранилище, их согласования и, возможно, агрегации. W. Inmon, автор концепции хранилищ данных [42], определяет такие хранилища как:
наборы данных, организованные с целью поддержки управления╩, призванные выступать в роли ╚единого и единственного источника истины╩, обеспечивающего менеджеров и аналитиков достоверной информацией, необходимой для оперативного анализа и поддержки принятия решений.
Концепция хранилищ данных предполагает не просто единый логический взгляд на данные организации, а действительную реализацию единого интегрированного источника данных. Альтернативным по отношению к этой концепции способом формирования единого взгляда на корпоративные данные является создание виртуального источника, опирающегося на распределенные базы данных различных СОД. При этом каждый запрос к такому источнику динамически транслируется в запросы к исходным базам данных, а полученные результаты на лету согласовываются, связываются, агрегируются и возвращаются к пользователю. Однако, при внешней элегантности, такой способ обладает рядом существенных недостатков.
Таким образом, хранилище данных функционирует по следующему сценарию. По заданному регламенту в него собираются данные из различных источников √ баз данных систем оперативной обработки. В хранилище поддерживается хронология: наравне с текущими хранятся исторические данные с указанием времени, к которому они относятся. В результате необходимые доступные данные об объекте управления собираются в одном месте, приводятся к единому формату, согласовываются и, в ряде случаев, агрегируются до минимально требуемого уровня обобщения.
Облегченным вариантом корпоративного хранилища данных могут быть витрины данных (Data Mart), то есть тематические БД, содержащие информацию, относящуюся к отдельным аспектам деятельности организации. Концепция витрин данных была предложена Forrester Research в 1991 году [15]. При этом главная идея заключалась в том, что витрины данных содержат тематические подмножества заранее агрегированных данных, по размерам гораздо меньшие, чем общекорпоративное хранилище данных, и, следовательно, требующие менее производительной техники для поддержания. В 1994 году M. Demarest [32] предложил объединить две концепции и использовать хранилище данных в качестве единого интегрированного источника для многочисленных витрин данных. В таком варианте корпоративная информационно-аналитическая система имеет трехуровневую структуру:
Рассмотренная концепция ориентирована исключительно на хранение, а не на обработку корпоративных данных. Она не предопределяет архитектуру целевых аналитических систем, а только создает поле деятельности для их функционирования, концентрируясь на требованиях к данным. Таким образом, она оставляет свободу выбора во всем, что касается:
Для того чтобы существующие хранилища данных способствовали принятию управленческих решений, информация должна быть представлена аналитику в нужной форме, то есть он должен иметь развитые инструменты доступа к данным хранилища и их обработки.
По критерию режима анализа данных информационно-аналитические системы подразделяются на две категории [11, 15]:
Очень часто ИАС, создаваемые в расчете на непосредственное использование лицами, принимающими решения, оказываются чрезвычайно просты в применении, но жестко ограничены в функциональности. Такие статические СППР [15, С. 55], или Информационные системы руководителя (ИСР) [13, С. 73] √ (Executive Information Systems, EIS) [45, С. 4] √ содержат в себе предопределенные множества запросов и, будучи достаточными для повседневного обзора, неспособны ответить на все вопросы к имеющимся данным, которые могут возникнуть при принятии решений2. Результатом работы такой системы, как правило, являются многостраничные отчеты, после тщательного изучения которых у аналитика появляется новая серия вопросов; однако, каждый новый, непредусмотренный при проектировании такой системы, запрос должен быть сначала формально описан, передан программисту, закодирован и только затем выполнен. Время ожидания в таком случае может составлять часы и дни, что не всегда приемлемо. Таким образом, внешняя простота статических СППР, за которую активно борется большинство заказчиков информационно-аналитических систем, оборачивается катастрофической потерей гибкости.
Динамические СППР, напротив, ориентированы на обработку нерегламентированных, неожиданных (ad hoc) запросов аналитиков к данным. Наиболее глубоко требования к таким системам рассмотрел E. F. Codd в статье [31], положившей начало концепции OLAP. Работа аналитиков с этими системами заключается в интерактивной последовательности формирования запросов и изучения их результатов, каждый из которых может породить потребность новой серии запросов. Данная работа посвящена проектированию именно динамических СППР.
Но динамические СППР могут действовать не только в области оперативной аналитической обработки (OLAP); поддержка принятия управленческих решений на основе накопленных данных может выполняться в трех базовых сферах [55].
Некоторые авторы [55] выделяют в отдельную область анализ отклонений (например, в целях отслеживания колебаний биржевых курсов). В качестве примера может быть приведен статистический анализ рядов динамики [4]. Чаще, однако, этот тип анализа относят к области закономерностей.
 |
| Рис. 1. Полная структура корпоративной ИАС. |
Полная структура ИАС, построенной на основе хранилища данных, показана на рис. 1. В конкретных реализациях отдельные компоненты этой схемы часто отсутствуют. Настоящая работа в первую очередь посвящена системам оперативной аналитической обработки и в некоторой степени √ средствам интеллектуального анализа данных. Поэтому в оставшейся части данной главы будут подробно рассмотрены концепции OLAP и ИАД. Такие вопросы как автоматизация сбора данных в хранилище из внешних источников, их согласование, очистка данных, поддержание целостности хранилища, реализация инструментов поиска детализированных данных, несмотря на их несомненную важность, подробно рассматриваться не будут, так как выходят за рамки темы работы.
Следует отметить, что средства аналитической обработки √ как OLAP, так и ИАД √ могут использовать в качестве исходного материала для анализа любые данные, в том числе базы отдельных СОД. Но наибольшего эффекта можно добиться при анализе корпоративного хранилища данных, содержащего максимально полный объем актуальных и исторических сведений обо всех аспектах деятельности объекта управления и ситуации вокруг него.
В основе концепции оперативной аналитической обработки (OLAP) лежит многомерное представление данных. Термин OLAP ввел E. F. Codd в 1993 году [31]. В своей статье он рассмотрел недостатки реляционной модели, в первую очередь невозможность ╚объединять, просматривать и анализировать данные с точки зрения множественности измерений, то есть самым понятным для корпоративных аналитиков способом╩, и определил общие требования к системам OLAP, расширяющим функциональность реляционных СУБД и включающим многомерный анализ как одну из своих характеристик.
Следует заметить, что Кодд обозначает термином OLAP многомерный способ представления данных исключительно на концептуальном уровне. Используемые им термины √ ╚Многомерное концептуальное представление╩ (╚Multidimensional conceptual view╩), ╚Множественные измерения данных╩ (╚Multiple data dimensions╩), ╚Сервер OLAP╩ (╚OLAP server╩) √ не определяют физического механизма хранения данных (термины ╚многомерная база данных╩ и ╚многомерная СУБД╩ не встречаются ни разу). Однако в большом числе публикаций аббревиатурой OLAP обозначается не только многомерный взгляд на данные, но и хранение самих данных в многомерной БД [16, 2] (это в принципе неверно, поскольку сам Кодд в [31] отмечает, что ╚Реляционные БД были, есть и будут наиболее подходящей технологией для хранения корпоративных данных. Необходимость существует не в новой технологии БД, а, скорее, в средствах анализа, дополняющих функции существующих СУБД и достаточно гибких, чтобы предусмотреть и автоматизировать разные виды интеллектуального анализа, присущие OLAP╩). Такая путаница приводит к противопоставлениям наподобие ╚OLAP или ROLAP╩, что, вообще говоря, некорректно, поскольку ROLAP (реляционный OLAP) на концептуальном уровне поддерживает всю определенную термином OLAP функциональность. Поэтому более предпочтительным кажется использование для OLAP на основе многомерных СУБД специального термина MOLAP, как это и сделано в [14, 24].
 |
| Рис. 2. Измерения и направления консолидации данных. |
По Кодду, многомерное концептуальное представление (multi-dimensional conceptual view) является наиболее естественным взглядом управляющего персонала на объект управления. Оно представляет собой множественную перспективу, состоящую из нескольких независимых измерений, вдоль которых могут быть проанализированы определенные совокупности данных. Одновременный анализ по нескольким измерениям данных определяется как многомерный анализ. Каждое измерение включает направления консолидации данных, состоящие из серии последовательных уровней обобщения, где каждый вышестоящий уровень соответствует большей степени агрегации данных по соответствующему измерению. Так, измерение Исполнитель может определяться направлением консолидации, состоящим из уровней обобщения ╚предприятие √ подразделение √ отдел √ служащий╩. Измерение Время может даже включать два направления консолидации √ ╚год √ квартал √ месяц √ день╩ и ╚неделя √ день╩, поскольку счет времени по месяцам и по неделям несовместим. В этом случае становится возможным произвольный выбор желаемого уровня детализации информации по каждому из измерений. Операция спуска (drilling down) соответствует движению от высших ступеней консолидации к низшим; напротив, операция подъема (rolling up) означает движение от низших уровней к высшим (рис. 2).
3.1. Требования к средствам оперативной аналитической обработкиКодд определил 12 правил, которым должен удовлетворять программный продукт класса OLAP (табл. 1).
| Таблица 1. Правила оценки программных продуктов класса OLAP | |
| Многомерное концептуальное представление данных (Multi-Dimensional Conceptual View) | Концептуальное представление модели данных в продукте OLAP должно быть многомерным по своей природе, то есть позволять аналитикам выполнять интуитивные операции ╚анализа вдоль и поперек╩3 (╚slice and dice╩), вращения (rotate) и размещения (pivot) направлений консолидации. |
| Прозрачность (Transparency) | Пользователь не должен знать о том, какие конкретные средства используются для хранения и обработки данных, как данные организованы и откуда берутся. |
| Доступность (Accessibility) | Аналитик должен иметь возможность выполнять анализ в рамках общей концептуальной схемы, но при этом данные могут оставаться под управлением оставшихся от старого наследства СУБД, будучи при этом привязанными к общей аналитической модели. То есть инструментарий OLAP должен накладывать свою логическую схему на физические массивы данных, выполняя все преобразования, требующиеся для обеспечения единого, согласованного и целостного взгляда пользователя на информацию. |
| Устойчивая производительность (Consistent Reporting Performance) | С увеличением числа измерений и размеров базы данных аналитики не должны столкнуться с каким бы то ни было уменьшением производительности. Устойчивая производительность необходима для поддержания простоты использования и свободы от усложнений, которые требуются для доведения OLAP до конечного пользователя. |
| Клиент √ серверная архитектура (Client-Server Architecture) | Большая часть данных, требующих оперативной аналитической обработки, хранится в мэйнфреймовых системах, а извлекается с персональных компьютеров. Поэтому одним из требований является способность продуктов OLAP работать в среде клиент-сервер. Главной идеей здесь является то, что серверный компонент инструмента OLAP должен быть достаточно интеллектуальным и обладать способностью строить общую концептуальную схему на основе обобщения и консолидации различных логических и физических схем корпоративных баз данных для обеспечения эффекта прозрачности. |
| Равноправие измерений (Generic Dimensionality) | Все измерения данных должны быть равноправны. Дополнительные характеристики могут быть предоставлены отдельным измерениям, но поскольку все они симметричны, данная дополнительная функциональность может быть предоставлена любому измерению. Базовая структура данных, формулы и форматы отчетов не должны опираться на какое-то одно измерение. |
| Динамическая обработка разреженных матриц (Dynamic Sparse Matrix Handling) | Инструмент OLAP должен обеспечивать оптимальную обработку разреженных матриц. Скорость доступа должна сохраняться вне зависимости от расположения ячеек данных и быть постоянной величиной для моделей, имеющих разное число измерений и различную разреженность данных. |
| Поддержка многопользовательского режима (Multi-User Support) | Зачастую несколько аналитиков имеют необходимость работать одновременно с одной аналитической моделью или создавать различные модели на основе одних корпоративных данных. Инструмент OLAP должен предоставлять им конкурентный доступ, обеспечивать целостность и защиту данных. |
| Неограниченная поддержка кроссмерных операций (Unrestricted Cross-dimensional Operations) | Вычисления и манипуляция данными по любому числу измерений не должны запрещать или ограничивать любые отношения между ячейками данных. Преобразования, требующие произвольного определения, должны задаваться на функционально полном формульном языке. |
| Интуитивное манипулирование данными (Intuitive Data Manipulation) | Переориентация направлений консолидации, детализация данных в колонках и строках, агрегация и другие манипуляции, свойственные структуре иерархии направлений консолидации, должны выполняться в максимально удобном, естественном и комфортном пользовательском интерфейсе. |
| Гибкий механизм генерации отчетов (Flexible Reporting) | Должны поддерживаться различные способы визуализации данных, то есть отчеты должны представляться в любой возможной ориентации. |
| Неограниченное количество измерений и уровней агрегации (Unlimited Dimensions and Aggregation Levels) | Настоятельно рекомендуется допущение в каждом серьезном OLAP инструменте как минимум пятнадцати, а лучше двадцати, измерений в аналитической модели. Более того, каждое из этих измерений должно допускать практически неограниченное количество определенных пользователем уровней агрегации по любому направлению консолидации. |
Набор этих требований, послуживших фактическим определением OLAP, достаточно часто критиковался. Так, в [16] говорится, что в рамках 12 требований смешаны:
С другой стороны, по утверждению самого Кодда, ни один из имеющихся в настоящее время на рынке продуктов оперативного анализа данных не удовлетворяет полностью всем выдвинутым им требованиям. Поэтому 12 правил следует рассматривать как рекомендательные, а конкретные продукты оценивать по степени приближения к идеально полному соответствию всем требованиям.
3.2. Классификация продуктов OLAP по способу представления данныхВ настоящее время на рынке присутствует около 30 продуктов, которые в той или иной степени обеспечивают функциональность OLAP (по данным iaci?iiai Web-сервера http://www.olapreport.com/ на февраль 1998 года). Обеспечивая многомерное концептуальное представление со стороны пользовательского интерфейса к исходной базе данных, все продукты OLAP делятся на три класса по типу исходной БД.
Помимо перечисленных средств существует еще один класс √ инструменты генерации запросов и отчетов для настольных ПК, дополненные функциями OLAP и/или интегрированные с внешними средствами, выполняющими такие функции. Эти довольно развитые системы осуществляют выборку данных из исходных источников, преобразуют их и помещают в динамическую многомерную БД, функционирующую на клиентской станции конечного пользователя. Для работы с небольшими, просто организованными базами эти средства подходят наилучшим образом. Основными представителями этого класса являются BusinessObjects одноименной компании [50], BrioQuery компании Brio Technology [17, С. 34] и PowerPlay компании Cognos [17, С. 34-35].
3.2.1. Многомерный OLAP (MOLAP)В специализированных СУБД, основанных на многомерном представлении данных, данные организованы не в форме реляционных таблиц, а в виде упорядоченных многомерных массивов:
Использование многомерных БД в системах оперативной аналитической обработки имеет следующие достоинства.
С другой стороны, имеются существенные ограничения.
Следовательно, использование многомерных СУБД оправдано только при следующих условиях.
Непосредственное использование реляционных БД в качестве исходных данных в системах оперативной аналитической обработки имеет следующие достоинства.
О недостатках ROLAP-систем уже говорилось при перечислении преимуществ использования многомерных баз данных. Это, во-первых, ограниченные возможности с точки зрения расчета значений функционального типа, а во-вторых √ меньшая производительность. Для обеспечения сравнимой с MOLAP производительности реляционные системы требуют тщательной проработки схемы БД и специальной настройки индексов. Но в результате этих операций производительность хорошо настроенных реляционных систем при использовании схемы ╚звезда╩ вполне сравнима с производительностью систем на основе многомерных баз данных.
Описанию схемы звезды (star schema) и рекомендациям по ее применению полностью посвящены работы [39, 61, 48]. Ее идея заключается в том, что имеются таблицы для каждого измерения, а все факты помещаются в одну таблицу, индексируемую множественным ключом, составленным из ключей отдельных измерений. Каждый луч схемы звезды задает, в терминологии Кодда, направление консолидации данных по соответствующему измерению (например, Магазин √ Город/район √ Регион).
В общем случае факты имеют разные множества измерений, и тогда их удобно хранить не в одной, а в нескольких таблицах; кроме того, в различных запросах пользователей может интересовать только часть возможных измерений. Но при таком подходе при большом числе независимых измерений необходимо поддерживать множество таблиц фактов, соответствующих каждому возможному сочетанию выбранных в запросе измерений, что приводит к неэкономному использованию внешней памяти, увеличению времени загрузки данных в БД схемы звезды из внешних источников и сложностям администрирования. Для решения этой проблемы авторы работы [38] предлагают специальное расширение для языка SQL (оператор ╚GROUP BY CUBE╩ и ключевое слово ╚ALL╩)5, а авторы [39, 48] рекомендуют создавать таблицы фактов не для всех возможных сочетаний измерений, а только для наиболее полных (тех, значения ячеек которых не могут быть получены с помощью последующей агрегации ячеек других таблиц фактов базы данных).
В сложных задачах с многоуровневыми измерениями имеет смысл обратиться к расширениям схемы звезды √ схеме созвездия (fact constellation schema) [61, С. 10-11] и схеме снежинки (snowflake schema) [61, С. 13-15]. В этих случаях отдельные таблицы фактов создаются для возможных сочетаний уровней обобщения различных измерений. Это позволяет добиться наилучшей производительности, но часто приводит к избыточности данных.
В любом случае, если многомерная модель реализуется в виде реляционной базы данных, следует создавать длинные и ╚узкие╩ таблицы фактов и сравнительно небольшие и ╚широкие╩ таблицы измерений. Таблицы фактов содержат численные значения ячеек гиперкуба, а остальные таблицы определяют содержащий их многомерный базис измерений.
Ориентация на представление многомерной информации с помощью звездообразных реляционных моделей позволяет избавиться от проблемы оптимизации хранения разреженных матриц, остро стоящей перед многомерными СУБД (где проблема разреженности решается специальным выбором схемы). Хотя для хранения каждой ячейки в таблице фактов используется целая запись (которая помимо самих значений включает вторичные ключи √ ссылки на таблицы измерений), несуществующие значения могут просто не быть включены в таблицу фактов, то есть наличие в базе пустых ячеек исключается. Индексирование обеспечивает приемлемую скорость доступа к данным в таблицах фактов.
Окончание в следующем номере.
Л.И. Щавелёв
Leonid@iname.com
http://www/polytech.ivanovo.su/~leonid
|
|