- Вопросы реализации Хранилищ Данных
- Неоднородность программной среды
- Распределенность
- Метаданные
- Роль метаданных в системах Хранилищ Данных
- Вопросы защиты данных
- Большие объемы хранимых данных
"Возможно, самое важное, что дала нам концепция Хранилищ Данных, - это понимание того, что существует два фундаментально различных типа систем: операционные (транзакционные) и информационные (аналитические)".
Введение
В области информационных технологий всегда существовали два взаимодополняющих друг друга направления развития:
- системы, ориентированные на операционную обработку данных - системы обработки данных (СОД);
- системы, ориентированные на анализ данных - системы поддержки принятия решений (СППР).
Но еще до недавнего прошлого, когда говорилось о стремительном вхождении в нашу жизнь информационных технологий и росте числа реализаций информационных систем, прежде всего имелись в виду системы, ориентированные исключительно на операционную обработку данных. И такое опережающее развитие одного из направлений вполне объяснимо.
На первых этапах автоматизации требовалось и требуется навести порядок именно в процессах повседневной рутинной обработки (переработки) данных, на что и ориентированы традиционные СОД. Более того, системы СППР являются в определенном смысле вторичными по отношению к ним. Здесь возможна аналогия с производством. Любая продукция, прежде чем попасть на склад и быть отгруженной потребителю, должна быть сначала произведена. И прежде чем заниматься анализом данных, необходимо эти данные иметь (произвести). А именно это и является одной из функций СОД.
Однако за последние два-три года ситуация существенно изменилась. И это непосредственно связано с тем, что практически в любой организации сложилась хорошо всем знакомая парадоксальная ситуация: информация вроде бы где-то и есть, ее даже слишком много, но она не структурирована, не согласована, разрознена, не всегда достоверна, ее практически невозможно найти и получить.
Именно на разрешение этого противоречия - отсутствие информации при наличии и даже избытке - и нацелена концепция Хранилищ Данных (Data Warehouse). Но концепция Хранилища Данных, хотя и наиболее популярная, далеко не единственная концепция построения аналитических систем. Не менее известны и другие концепции: Information Warehouse, Data Mart, On-Line Analitical Processing (OLAP), Relational On-Line Analitical Processing (ROLAP).
С чем связано появление, параллельное существование и развитие различных концепций построения и реализации аналитических систем? Насколько они взаимно исключают или, наоборот, взаимно дополняют друг друга? Какие проблемы, возникающие при реализации таких систем, неизбежны, а какие могут быть решены за счет правильного выбора средств и стратегии реализации?
Именно ответам на эти вопросы и посвящена данная статья. И хотя эти ответы не всегда могут быть однозначными, уже само понимание проблем, поднимаемых в них, является необходимым условием выбора правильной стратегии и успешной реализации информационной системы, ориентированной на анализ данных (аналитической системы).
Данную работу можно разделить на следующие основные разделы.
- Концепции
- Концепция Хранилищ Данных (рассматриваются основные положения концепции Хранилищ Данных).
- Взаимное соотношение концепции Хранилищ Данных и концепций анализа данных (рассматривается взаимное соотношение концепции Хранилищ Данных и концепций анализа данных; показывается, что эти концепции, являясь взаимно независимыми, в то же время взаимно обогащают и дополняют друг друга).
- Технологии и средства реализации
- Вопросы реализации Хранилищ Данных (рассматриваются технологические аспекты реализации Хранилищ Данных).
- СУБД для аналитических систем.
- Витрины Данных
- Недостающее звено в концепциях построения аналитических систем (рассматривается концепция Data Mart и потенциальные достоинства подхода, предполагающего совместное использование РСУБД и МСУБД в рамках одной аналитической системы).
- Заключение
Концепции
Прежде чем переходить к рассмотрению собственно концепций построения аналитических систем, необходимо сделать небольшое терминологическое (или, если хотите, историческое) отступление. Сегодня используются два основных варианта перевода термина "Data Warehouse": Хранилище Данных и Информационное Хранилище. Однако второй вариант перевода, возможно, более точно отражая смысл концепции, не совсем корректен. Дело в том, что термин "Warehouse" не является изобретением Б. Инмона и используется в информационных технологиях достаточно давно. Еще в 80-х годах фирмой IBM была предложена концепция Information Warehouse. И более корректно оставить термин "Информационное Хранилище" за самостоятельной концепцией, развиваемой фирмой IBM.
Каждый из этих терминов несет самостоятельную смысловую нагрузку, и фирма IBM говорит о том, что Information Warehouse это - Data Warehouse Plus. А теперь попробуйте перевести это утверждение.
Концепция Хранилищ Данных
Сегодня СОД, реализованные на самой различной основе, исправно работают и при этом исправно порождают и пополняют многочисленные многотомные электронные архивы. Основное назначение таких систем - оперативная обработка, и они не могут себе позволить роскошь хранить данные более чем за несколько месяцев. После того как данные устаревают, они выгружаются и вычищаются из операционной БД. А поскольку обычно в любой организации функционирует несколько различных, несвязанных или слабо связанных СОД, выгруженные из них данные, как правило, имеют различную структуру, формат, стандарты представления дат и денежных величин. Для обозначения одних и тех же объектов используются различные кодировки. Обычно в них в явном виде отсутствуют реквизиты, идентифицирующие временной срез, которому они соответствуют, и источники их получения.
В результате огромные архивные массивы, накопленные за годы эксплуатации СОД и содержащие самую разнообразную жизненно важную для организации информацию, остаются невостребованными. Без предварительной доработки и согласования, архивные данные бесполезны и не могут быть непосредственно использованы в задачах анализа.
Но данные, порожденные в результате функционирования корпоративных СОД, - это только часть информации, необходимой для принятия корректного бизнес-решения. Организация живет и функционирует в реальном мире. Включение в аналитическую систему данных из различных электронных статистических сборников (как общедоступных, так и коммерческих), прогнозов развития регионов и областей экономики, законодательной базы позволяет по-новому взглянуть на многие закономерности, выявленные в процессе анализа внутренних данных. И, как показывает практика, любое решение, принятое исключительно на основе внутренних данных, скорее всего, окажется не вполне корректным.
Автором концепции Хранилищ Данных (Data Warehouse) является Б. Инмон, который определил Хранилища Данных [1] как: "предметно-ориентированные, интегрированные, неизменчивые, поддерживающие хронологию наборы данных, организованные для целей поддержки управления", призванные выступать в роли "единого и единственного источника истины", обеспечивающего менеджеров и аналитиков достоверной информацией, необходимой для оперативного анализа и принятия решений.
В основе концепции Хранилищ Данных лежат две основополагающие идеи.
- Интеграция ранее разъединенных детализированных данных в едином Хранилище Данных, их согласование и, возможно, агрегация:
- исторических архивов;
- данных из традиционных СОД;
- данных из внешних источников.
- Разделение наборов данных, используемых для операционной обработки, и наборов данных, применяемых для решения задач анализа.
Наиболее распространенной на сегодня ошибкой является попытка найти в концепции Хранилищ Данных некий законченный рецепт реализации информационной аналитической системы. Тем более, это не некий готовый программный продукт или некое готовое универсальное решение. В этом смысле интересна и показательна оценка Butler Group Co. [2] структуры затрат на реализацию систем Хранилищ Данных, по которой до 50% от стоимости системы составляет стоимость консалтинга и лишь оставшиеся 50% - это стоимость аппаратных, сетевых и программных компонентов. С этой оценкой можно спорить, но она весьма показательна.
Цель концепции Хранилищ Данных - прояснить отличия в характеристиках данных в операционных и аналитических системах (таблица 1), выяснить требования к данным, помещаемым в целевую БД Хранилища Данных (таблица 2), определить общие принципы и этапы ее построения, основные источники данных, дать рекомендации по решению потенциальных проблем, возникающих при их выгрузке, очистке, согласовании, транспортировке и загрузке в целевую БД.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Таблица 1.
Сравнение характеристик данных в информационных системах, ориентированных
на операционную и аналитическую обработку данных.
|
|
|
|
|
|
|
|
|
|
|
|
Таблица 2.
Основные требования к данным в Хранилище Данных.
Предметом концепции Хранилищ Данных служат сами данные. После того как традиционная СОД реализована и начинает функционировать, она становится ровно таким же самостоятельным объектом реального мира, как и любой производственный процесс. А данные, которые являются одним из конечных продуктов такого производства, обладают ровно теми же свойствами и характеристиками, что и любой промышленный продукт: сроком годности, местом складирования (хранения), совместимостью с данными из других производств (СОД), рыночной стоимостью, транспортабельностью, комплектностью, ремонтопригодностью и т. д.
Именно с этой точки зрения и рассматриваются данные в Хранилищах Данных. То есть целью здесь являются не способы описания и отображения объектов предметной области, а собственно данные, как самостоятельный объект предметной области, порожденной в результате функционирования ранее созданных информационных систем.
Для правильного понимания данной концепции необходимо уяснение следующих принципиальных моментов.
- Концепция Хранилищ Данных - это не концепция анализа данных, скорее, это концепция подготовки данных для анализа.
- Концепция Хранилищ Данных не предопределяет архитектуру целевой аналитической системы. Она говорит о том, какие процессы должны выполняться в системе, но не о том, где конкретно и как эти процессы должны выполняться.
- Концепция Хранилищ Данных предполагает не просто единый логический взгляд на данные организации (как иногда это трактуется), а реализацию единого интегрированного источника данных.
Последний пункт достаточно принципиален, поэтому рассмотрим его более детально. Сегодня достаточно популярны решения, предполагающие интеграцию различных СОД на основе единого справочника метаданных (поддерживающего единый логический взгляд на данные организации), но не единого интегрированного источника данных. При этом по каждому новому запросу предполагается динамическая выгрузка данных из различных операционных источников (СОД), их динамическое согласование, агрегация и транспортировка к пользователю.
Очевидно, что для определенных классов приложений это решение вполне корректно. Но следует заранее понимать все накладываемые им ограничения.
Кроме единого справочника метаданных, средств выгрузки, агрегации и согласования данных, концепция Хранилищ Данных подразумевает: интегрированность, неизменчивость, поддержку хронологии и согласованность данных. И если два первых свойства (интегрированность и неизменчивость) влияют на режимы анализа данных (как будет показано ниже, без интегрированной базы данных, в которой используются специализированные методы хранения и доступа, по крайней мере, сегодня трудно говорить о реализации интерактивного динамического анализа), то последние два (поддержка хронологии и согласованность) существенно сужают список решаемых аналитических задач.
Без поддержки хронологии (наличия исторических данных) нельзя говорить о решении задач прогнозирования и анализа тенденций. Но наиболее критичными и болезненными оказываются вопросы, связанные с согласованием данных.
Основным требованием аналитика является даже не столько оперативность, сколько достоверность ответа. Но достоверность, в конечном счете, и определяется согласованностью. Пока не проведена работа по взаимному согласованию значений данных из различных источников, сложно говорить об их достоверности.
Практически в любой организации вопрос о согласованности данных в различных информационных системах стоит чрезвычайно остро. И, нередко, менеджер сталкивается с ситуацией, когда на один и тот же вопрос, различные системы могут дать и обычно дают различный ответ. Это может быть связано как с несинхронностью моментов модификации данных, отличиями в трактовке одних и тех же событий, понятий и данных, изменением семантики данных в процессе развития предметной области, элементарными ошибками при вводе и обработке, частичной утратой отдельных фрагментов архивов и т. д. Очевидно, что учесть и заранее определить алгоритмы разрешения всех возможных коллизий мало реально. Тем более, это нереально сделать в оперативном режиме, динамически, непосредственно в процессе формирования ответа на запрос.
Взаимное соотношение концепции Хранилищ Данных и концепций анализа данных
Как уже было сказано выше, концепция Хранилищ Данных определяет лишь самые общие принципы построения аналитической системы и в первую очередь сконцентрирована на свойствах и требованиях к данным, но не способах их организации и представления в целевой БД и режимах их использования.
То есть она фактически не затрагивает и оставляет свободу выбора в вопросах, относящихся:
- к конкретным способам представления данных в целевой БД (например многомерное или реляционное);
- режимам анализа данных (статический или динамический).
В определенном смысле, концепция Хранилищ Данных, это концепция построения аналитической системы, но не концепция ее использования. Но данные собираются не для того, чтобы храниться, они должны работать. Ответ на вопрос, как наилучшим образом и наиболее полно использовать уже собранные и подготовленные для анализа данные, и дают различные концепции анализа данных:
- традиционный статический DSS;
- OLAP/ROLAP - динамический интерактивный многомерный анализ данных.
Традиционный статический DSS. Всего три-четыре года назад результатом работы любой аналитической системы являлись регламентированные многостраничные отчеты и диаграммы. Но, как правило, после просмотра такого отчета у аналитика появлялся не готовый ответ, а новая серия вопросов. Однако если бы ему захотелось получить ответ на новый, непредусмотренный при проектировании системы вопрос, он мог ждать его часы, а иногда и дни.
Каждый новый запрос в системах, реализуемых на основе традиционных технологий статического анализа данных (таблица 3), должен быть сначала формально описан, передан программисту, запрограммирован и, наконец, выполнен. Но после того, как аналитик, наконец, получал долгожданный ответ, достаточно часто оказывалось, что решение не могло ждать и оно уже принято, или, что еще чаще, произошло взаимное непонимание и получен ответ не на совсем тот вопрос.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Динамическое изменение уровней агрегации и срезов данных. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Таблица 3.
Сравнение характеристик статического и динамического анализа.
Динамический интерактивный многомерный анализ данных (OLAP/ROLAP). У истоков концепции многомерного динамического анализа - OLAP, стоит основоположник реляционного подхода Э. Кодд [3], сформулировавший 12 основных требований к средствам реализации OLAP.
Заметим, что у Кодда, термин "OLAP" обозначает исключительно конкретный способ представления данных на концептуальном уровне - многомерный. Более того, в своей работе он ни разу не использовал термин "Многомерная СУБД".
В этом смысле представляет интерес сам список терминов, используемых Коддом в его работе: "OLAP Server", "Multiple Data Dimension", "Multi-Dimensional Conceptual View", "OLAP Product", "OLAP Tool", "Server component of OLAP Tools" и даже "OLAP Tools Physical Schema", но ни разу ни "Multi-Dimensional DataBase", ни "Multi-Dimensional DBMS".
Однако исторически сложилось так, что сегодня термин "OLAP" подразумевает не только многомерный взгляд на данные со стороны конечного пользователя, но и многомерное представление данных в целевой БД [4]. Именно с этим связано появление в качестве самостоятельного термина "Реляционный OLAP" (ROLAP). Между этими концепциями существует единственное принципиальное различие: что понимать под термином "Server Component of OLAP Tools" - интерфейс к целевой БД или собственно целевую БД.
Закономерен вопрос, как взаимно соотносятся концепции: Хранилищ Данных и различные концепции анализа данных (например, как соотносятся концепция Хранилищ Данных и OLAP/ROLAP)? По-видимому, правильный ответ состоит в том, что формально обе они говорят об одном и том же: "Что требуется для успешной реализации информационной системы, ориентированной на аналитическую работу с данными". Но, однако, это два различных взгляда.
- Взгляд со стороны конечного пользователя (выраженный Э. Коддом), который главным образом сосредоточен на концептуальном уровне представления данных и на выработке методологии анализа данных. При этом он, естественно, говорит о том, что исходные данные могут храниться в различных источниках и должны быть обеспечены эффективные средства для их выборки и транспортировки. Но для него эти процессы вторичны, а главное состоит в том, что конечному пользователю должен быть предоставлен максимально комфортный и эффективный инструментарий визуализации и манипулирования данными - OLAP Tools.
- Взгляд со стороны специалиста, отвечающего за реализацию и сопровождение системы (выраженный Б. Инмоном), который также вполне естественно говорит о том, что конечной целью Хранилища Данных является обеспечение информационных потребностей конечных пользователей (менеджеров и аналитиков). Но для него главное - выявление наиболее общих свойств и характеристик данных. Решение вопросов сбора, транспортировки, очистки, согласования и агрегации данных из различных внешних источников.
Таким образом, формально говоря об одном и том же, эти концепции не конкурируют, а скорее, взаимно дополняют друг друга.
В то же время эти концепции никак непосредственно не взаимосвязаны. Хранилище Данных может использоваться исключительно как источник для регламентированных аналитических сводок и отчетов (то, что Кодд называет статический DSS) или для регламентированной статистической обработки, но не для OLAP. А OLAP-инструментарий может быть с успехом использован для непосредственной работы с оперативными данными из традиционной СОД.
Технологии и средства реализации
Вопросы реализации Хранилищ Данных
Аналитические системы всегда предъявляли существенно более высокие, чем традиционные СОД, требования к аппаратному обеспечению и программному обеспечению. И, приступая к построению аналитической системы, следует понимать, что ее реализация практически невозможна без разрешения таких вопросов, как:
- неоднородность программной среды;
- распределенность;
- защита данных от несанкционированного доступа;
- построение и ведение многоуровневых справочников метаданных;
- эффективное хранение и обработка очень больших объемов данных.
Неоднородность программной среды
Основополагающим отличием Хранилищ Данных от традиционных СОД является то, что они практически никогда не создаются на пустом месте. И почти всегда конечное решение будет разнородным (с точки зрения производителей программных средств, принципов построения, операционных систем).
Основа Хранилищ Данных - не внутренние, как в большинстве традиционных СОД, а внешние источники данных: различного рода информационные системы, электронные архивы, общедоступные и коммерческие электронные каталоги, справочники, статистические сборники. Как правило, сегодня в любой организации реально функционирует множество несвязанных или слабо связанных СОД. В большинстве случаев они создавались в различное время, различными коллективами разработчиков и реализованы на основе различных программных и аппаратных средств. Таким образом, уже сама основа, на которой будет строиться Хранилище Данных, чаще всего уже является крайне не однородной. Добавьте сюда средства выгрузки, транспортировки, реализации целевой БД Хранилища Данных.
Очевидно, что в таких условиях даже говорить об однородности программных средств чрезвычайно сложно. И практически всегда задача построения Хранилища Данных - это задача построения единой, согласованно функционирующей, информационной системы на основе неоднородных программных средств и решений. И уже сам выбор средств реализации Хранилища Данных становится чрезвычайно сложной задачей. Здесь должно учитываться множество факторов, включая взаимную совместимость различных программных компонентов, легкость их освоения и использования, эффективность функционирования, стабильность и даже формы, уровень и потенциальную перспективность взаимоотношений различных фирм производителей.
Распределенность
Хранилища Данных уже по своей природе являются распределенным решением.
В основе концепции Хранилищ Данных лежит физическое разделение узлов, где выполняется операционная обработка, от узлов, в которых выполняется анализ данных. И хотя при реализации такой системы нет необходимости в строгой синхронизации данных в различных узлах (например на основе средств двухфазной фиксации транзакций), средства асинхронной асимметричной репликации данных являются неотъемлемой частью практически любого решения.
Метаданные
Наличие метаданных и средств их представления конечным пользователям - это один из основополагающих факторов успешной реализации Хранилища Данных. Более того, без наличия актуальных, максимально полных и легко понимаемых пользователем описаний данных Хранилище Данных превращается в обычный, но очень дорогостоящий электронный архив.
Первая же задача, с которой сталкиваешься при проектировании и реализации системы Хранилищ Данных, заключается в необходимости одновременной работы с самыми разнородными внешними источниками данных, несогласованностью их структур и форматов, масштабами и количеством архивов, которые должны быть переработаны и загружены. И при построении такой системы разработчику сложно обойтись без высокоуровневых средств описания информационной модели системы. Причем эта модель должна содержать описания не только целевых структур данных в БД Хранилища, но и структур данных в источниках их получения (различных информационных системах, архивах, электронных справочниках и т. д.), правила, процедуры и периодичность их выборки и выгрузки, процедуры и места согласования и агрегации.
Здесь следует сделать несколько замечаний относительно выбора конкретных средств проектирования. Как уже было сказано выше, характерными свойствами аналитической системы, являются:
- разнородность компонентов;
- ориентированность на нерегламентированную работу с данными.
Рассмотрим, как это влияет на выбор и требования к средствам проектирования. С одной стороны, из-за разнородности программных и системных компонентов, образующих Хранилища, и малой доли регламентированных пользовательских приложений, чаще всего результатом проектирования системы будет не готовый к исполнению программный продукт (что является обычным требованием для средств проектирования СОД), а база метаданных, содержащая всестороннее многоуровневое описание целевой информационной системы. С другой стороны, как будет показано ниже, в аналитических системах именно вопросы полноты, актуальности, простоты использования и понимания метаданных приобретают особую актуальность.
О значимости метаданных в информационных системах говорится много. Тем не менее на практике в подавляющем большинстве традиционных СОД их роль, по крайней мере, с точки зрения конечного пользователя, не очень велика. С чем это связано? Для того чтобы ответить на этот вопрос, рассмотрим три основных категории специалистов, работающих с СОД: конечные пользователи, системные администраторы, разработчики.
Конечные пользователи - это наиболее массовый слой специалистов, работающих с СОД. Именно они, в конечном счете, являются основными заказчиками и пользователями системы. Но в случае традиционной СОД, которую можно сравнить с хорошо отлаженным заводским конвейером, именно они, как правило, и не получают никаких преимуществ ни от наличия, ни от отсутствия базы метаданных. Обязанности и функции каждой категории конечных пользователей обычно четко оговорены в соответствующих инструкциях ("Инструкция оператора", "Инструкция пользователя" и т. д.), а всю уточняющую информацию они могут получить с помощью специальных регламентированных подсказок и комментариев.
Более того, обычно предполагается, что чем меньше от пользователя требуется знаний о структурах и потоках данных, взаимосвязях и взаимозависимостях различных программных компонентов, тем лучше реализована информационная система. В таких системах обычно не только не приветствуется, но и даже не допускается возможность свободной импровизации с данными и процедурами их обработки. Здесь преднамеренно не рассматриваются случаи, когда у конечного пользователя возникает необходимость в выполнении нового, заранее непредусмотренного, запроса (выборки), так как этот вид деятельности свойственен аналитической, а не оперативной системе.
Администраторы БД - категория специалистов, основной задачей которых является поддержание СОД в актуальном рабочем состоянии. Их, как правило, интересует не семантика данных, а способы их физического представления и организации. Администратор обычно не работает с конкретными значениями данных, не занимается написанием новых и модернизацией уже существующих прикладных программ. И хотя потребность в наличии и доступности метаданных у этой категории специалистов высока, их обычно вполне устраивают ограниченные описания данных, содержащиеся в традиционных справочниках БД. И даже, несмотря на то что структура описаний в таких справочниках достаточно сложна для понимания, это также не вызывает особых нареканий. Число администраторов обычно невелико, и они, как правило, обладают достаточной квалификацией и опытом работы.
Разработчики - категория специалистов, ответственных за разработку и дальнейшее развитие СОД. Наличие метаданных (данных о данных) является необходимым условием успешной реализации любой СОД. И именно при разработке (модернизации) СОД эта информация формируется и активно используется. Однако формируется, не означает того, что формируется электронный образ общедоступной и общепонятной базы метаданных. Более того, даже если при разработке информационной системы используется CASE-инструментарий:
- результирующие описания, в первую очередь, ориентированы и будут полезны разработчикам, но никак не пользователям и в меньшей степени администраторам системы;
- в процессе эксплуатации СОД изменения в прикладные программы и даже в структуры данных, часто вносятся напрямую, а не через CASE-инструментарий. Поэтому, через непродолжительный промежуток времени, описания данных, сформированные в процессе разработки, перестают соответствовать реальности.
Роль метаданных в системах Хранилищ Данных
Существенно иная ситуация в случае информационных систем, ориентированных на аналитическую работу с данными (таблица 4). Здесь наличие метаданных и средств их представления конечным пользователям является одним из основополагающих факторов успешной реализации системы. Для конечного пользователя база метаданных является тем же самым, что и путеводитель для туриста, попавшего в незнакомый город. Прежде чем сформулировать свой вопрос к системе, менеджер должен понять, какая информация в ней есть, ее актуальность, насколько ей можно доверять и даже сколько времени может занять формирование ответа. Поэтому для конечного пользователя крайне важно и желательно, чтобы в системе содержались не только описания собственно структур данных, их взаимосвязей, предвычисленных уровней агрегации, но и:
- источников получения данных. Аналитику желательно не просто знать о том, какие данные есть в системе, но и источники их получения и степень их достоверности. Например, одна и та же информация может попасть в Хранилище Данных из различных источников. В этом случае пользователь должен иметь возможность узнать, какой источник выбран в качестве основного и каким образом выполнялись согласование и очистка исходных данных;
- периодичности обновления. Пользователю желательно не просто знать, какому моменту времени соответствуют те или иные данные, но и когда они будут обновлены;
- собственников данных. В отличие от традиционных СОД, где пользователь видит только то, что ему разрешено, здесь пользователю будет полезно знать, какие еще данные есть в системе, кто является их собственником и какие шаги он должен предпринять, чтобы получить к ним доступ;
- статистических оценок запросов. Еще до выполнения запроса пользователю желательно иметь хотя бы приблизительную оценку времени, которое потребуется для получения ответа, и представлять, каков будет объем этого ответа.
|
|
|
|
|
|
|
|
|
Таблица 4.
Уровни метаданных в Хранилище Данных.
Вопросы защиты данных
Собрав в одном месте всю информацию об истории развития организации, ее успехах и неудачах, о взаимоотношениях с поставщиками и заказчиками, об истории развития и состоянии рынка, менеджеры получают уникальную возможность для анализа прошлой деятельности, сегодняшнего дня и построения обоснованных прогнозов на будущее. Однако не следует забывать и о том, что, если не обеспечены надлежащие средства защиты и ограничения прав доступа, вы можете снабдить этой информацией и ваших конкурентов.
Одним из первых же вопросов, встающих при обсуждении проекта Хранилища Данных, является вопрос защиты данных. Чисто психологически, многих пугают не столько затраты на реализацию системы Хранилищ Данных (чаще всего есть понимание, что эффект от ее использования будет больше), а то, что доступ к критически значимой информации может получить кто-либо, не имеющий на это права.
В таких системах часто оказывается недостаточно защиты, обеспечиваемой в стандартных конфигурациях коммерческих СУБД (обычно уровень защиты по классу "C2 Orange Book"). Региональный менеджер должен видеть только те данные, которые относятся к его региону, а менеджер подразделения не должен видеть данные, относящиеся ко всей фирме. Но для повышения эффективности доступа к данным, в целевой БД Хранилища Данных все эти данные, как правило, хранятся в виде единой фактологической таблицы. Следствием этого является то, что средства реализации должны поддерживать ограничения доступа не только на уровне отдельных таблиц и их колонок, но и отдельных строк в таблице (класс "B1 Orange Book").
Не менее остро стоят и вопросы авторизации и идентификации пользователей, защиты данных в местах их преобразования и согласования, в процесс их передачи по сети (шифрование паролей, текстов запросов, данных).
Большие объемы хранимых данных
Когда мы говорим о целевой БД Хранилища Данных, то подразумеваем, что это нечто очень большое (таблица 5). Но насколько большое? Согласно данным Meta Group, уже сегодня около половины организаций планируют Хранилища в 100 гигабайт и более. И уже известны реализации систем с терабайтами данных.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Таблица 5.
Классификация Хранилищ Данных в соответствии с объемом целевой БД.
Причем, когда говорится о 100 гигабайтах исходных данных, следует понимать, что реальное дисковое пространство, требуемое для реализации целевой БД, будет несколько больше. Для ответа на вопрос "Насколько больше?", лучше всего посмотреть, что об этом думают сами фирмы-производители СУБД.
Одним из показателей недавно принятого теста TPC-D (новый специализированный тест для систем DSS) является именно соотношение между реальным объемом исходных данных (длина строки таблицы умножается на число строк и так по всем исходным таблицам) и реальным объемом используемого в тесте дискового массива (таблица 6).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Таблица 6.
Соотношение между реальным объемом исходных данных и размером дискового
массива.
Таким образом, средний коэффициент, на который должен умножаться объем исходных данных для оценки реального, необходимого для реализации системы объема дискового пространства, равен 4.87 (для 100 гигабайтных тестов) и имеет тенденцию к возрастанию при увеличении объема исходных данных. Более того, как показывает тест DB2 для Windows NT, для того чтобы получить БД в несколько терабайт, может потребоваться всего несколько сот мегабайт исходных данных.
Естественно, цифры из таблицы 6 не являются догмой. Более того, здесь учитывается не только объем собственно БД, но и пространство под операционную систему, различные временные области, буфера и т. д. С другой стороны, здесь заранее известны структуры данных, объемы и режимы загрузки, фиксировано количество записей в каждой таблице и известно, сколько и откуда записей будет добавляться и удаляться, сколько и каких типов записей будет выбрано для формирования ответа на запрос. Тестируемые фирмы могут заранее и очень точно оценить размеры всех областей. Основным показателем теста является соотношение Цена/Производительность, и сложно предположить, что в конфигурации тестируемых систем было что-то избыточное и лишнее. Поэтому, в реальной жизни, эти коэффициенты могут оказаться не только не меньше, а даже несколько больше.
СУБД для аналитических систем
РСУБД
Сегодня РСУБД стали доминирующим промышленным решением при реализации самых разнообразных СОД. Они обеспечивают приемлемые времена отклика при произвольной выборке отдельных записей и небольших групп записей. А реальные объемы БД, с которыми они умеют работать, превышают сотни гигабайт. Более того, сегодня известны, правда, пока на уровне демонстрационных версий БД с объемом в несколько терабайт. Однако, исходно ориентированные на реализацию систем операционной обработки данных, РСУБД оказались менее эффективными в задачах аналитической обработки. С чем это связано?
Во-первых, из-за наличия достаточно жестких ограничений накладываемых существующей реализацией языка SQL, аналитические запросы получаются весьма громоздкими, а многие функции обработки приходится выносить в заранее написанные пользовательские приложения. И если вопрос о том, что громоздкость конструкций это серьезный недостаток, достаточно спорный (сегодня практически никто не пишет непосредственно на SQL, а соответствующие конструкции автоматически генерируются средствами клиентского инструментария), то ограничения SQL реально существуют, и их так просто не обойти.
Примером такого реально существующего ограничения является предположение о том, что данные в реляционной базе не упорядочены (или, более точно, упорядочены случайным образом). Но выполнение большинства аналитических функций (например построение Прогноза), наоборот, невозможно без предположения об упорядоченности данных. Естественно, при использовании реляционной базы имеется возможность после выборки данных из базы, выполнить их сортировку и затем построить Прогноз. Но это потребует дополнительных затрат времени на сортировку; сортировка должна будет проводиться каждый раз при обращении к этой функции, и, самое главное, такая функция может быть определена и применена только в пользовательском приложении, но не может быть встроенной функцией языка SQL.
Во-вторых, для обеспечения приемлемого времени ответа, при использовании РСУБД, нужно уже на этапе проектирования знать обо всех возможных типах запросов, необходимых срезах и уровнях агрегации данных.
Основой традиционного реляционного подхода является нормализация (декомпозиция) таблиц, подразумевающая устранение избыточности в основных ключах таблиц и устранение транзитивных зависимостей между реквизитами, образующими таблицу. Это позволяет не только минимизировать суммарный объем данных в БД, но и решает проблемы, связанные с различного рода аномалиями, возникающими при удалении и модификации данных в ненормализованных таблицах. И хотя в процессе нормализации утрачиваются и семантические связи, существующие между реквизитами, это не особенно критично для традиционных СОД. Те немногие связи, которые необходимы для реализации конкретного приложения, известны заранее и легко реализуются с помощью механизма внешних ключей. Более критична эта проблема для аналитических систем. Здесь обычно даже нельзя заранее определить, какие связи между различными реквизитами будут применяться более часто, а какие не будут использоваться вообще. Все зависит от неординарности мышления конкретного аналитика, ситуации на рынке, в фирме и многих других факторов.
Но основной недостаток традиционных РСУБД заключался в том, что в качестве основного и часто единственного механизма, обеспечивающего быстрый поиск и выборку отдельных строк в таблице (или в связанных через внешние ключи таблицах), обычно используются различные модификации индексов, основанных на B-деревьях. Но такое решение оказывается эффективным только при обработке небольших групп записей и высокой интенсивности модификации данных в БД. В аналитических системах ввод и выборка данных осуществляется большими порциями. А данные, после того как они попадают в БД, остаются неизменными в течение длительного периода времени. И здесь более эффективным оказывается хранение данных в форме частично денормализованных таблиц, в которых для увеличения производительности могут храниться не только детализированные, но и предварительно вычисленные агрегированные значения, а для навигации и выборки - использоваться специализированные, основанные на предположении о малоизменчивости и малоподвижности данных в БД, методы адресации и индексации. Такой способ организации данных иногда называют предвычисленным, подчеркивая, тем самым, его отличие от нормализованного реляционного подхода, предполагающего динамическое вычисление различного вида итогов (агрегация) и установление связей между реквизитами из разных таблиц (операции соединения).
И все же, по мнению Э. Кодда [3], реляционные базы данных уже стали, и будут оставаться и в будущем, наиболее подходящей технологией для реализации информационных систем уровня предприятия. Главными причинами их неэффективности в аналитических приложениях являются не столько собственно недостатки реляционного подхода, сколько то, что производители РСУБД еще до недавнего времени просто не обращали внимания на рынок аналитических систем.
Но уже сегодня ситуация изменилась. И, пожалуй, главной новацией здесь является то, что сегодня официально признана необходимость и право на существование в реляционной БД таблиц с денормализованной формой - различные модификации схемы организации данных типа звезда. В своем классическом варианте данная схема предполагает наличие одной денормализованной фактологической таблицы (количество строк в этой таблице обычно составляет десятки и сотни миллионов), с которой соотнесено несколько десятков относительно небольших справочных таблиц.
Другое направление развития РСУБД - поиск и реализация новых способов индексации и организации хранения данных, задачей которого является отсеять максимальное количество данных, не удовлетворяющих условиям запроса, еще до считывания их с внешнего накопителя, и одновременно иметь индекс такого размера, чтобы он легко умещался в оперативной памяти (или имел сопоставимый с ней размер).
Примерами таких индексов служат Bitmap-индексы, которые оказываются достаточно эффективными при работе с реквизитами, количество значений которых относительно невелико. Не меньший, если не больший выигрыш, может принести использование различных вариантов горизонтального или вертикального разделения таблиц (данных). Например, разделение одной большой фактологической таблицы на несколько отдельных фрагментов (горизонтальная фрагментация). Такое разбиение может производиться, например, в соответствии с временным интервалом, к которому относятся данные. Каждая из таких подтаблиц (фрагментов) имеет одну и ту же структуру, формат реквизитов, индексы. И каждый из этих фрагментов может обрабатываться независимо (например могут строиться и перестраиваться индексы). В запросе вся таблица может представляться как единое целое, причем фрагменты, не удовлетворяющие условиям выборки, могут быть легко отсечены, еще до момента их считывания с внешнего накопителя.
Другим подходом к повышению производительности является вертикальная фрагментация данных. Предположим, что у нас имеется таблица из 10 000 000 строк, каждая строка состоит из 30 полей (колонок), по 10 символов (байт) каждое. Абстрагируясь от вопросов эффективности или неэффективности хранения данных в конкретной реализации РСУБД, предположим, что объем результирующей БД равен объему исходных данных. В этом случае мы получим БД размером в 3 гигабайта.
В традиционных реализациях РСУБД данные хранятся построчно, и при последовательном просмотре вне зависимости от того, значения из скольких колонок таблицы требуются для формирования ответа на запрос, будут считаны все 3 гигабайта данных. Но в аналитических запросах крайне редко возникает необходимость работы одновременно со всеми колонками таблицы. Именно на этом предположении и основывается механизм вертикальной фрагментации, при использовании которого данные хранятся не построчно, а по столбцам. Таким образом, каждый столбец представляет собой независимый раздел данных и при запросах на чтение может обрабатываться независимо. И если в нашем примере для формирования ответа на запрос потребуются значения из трех столбцов таблицы, нужно будет считать только 300 мегабайт, а не 3 гигабайта данных.
До сих пор мы в основном говорили о достоинствах различных способов повышения эффективности обработки аналитических запросов. Но ни один из этих подходов не является универсальным и равно эффективным во всех ситуациях. Сегодня производители РСУБД находятся на этапе поиска, и ни один из описанных выше механизмов не может быть общепризнан, бесспорен и универсален.
Оптимизаторы обработки запросов со схемой звезда
- Наиболее широко распространенный на сегодняшний день, способ оптимизации запросов типа звезда предполагает построение промежуточной таблицы, являющейся декартовым произведением используемых в запросе справочных таблиц. И только затем выполняется последовательный просмотр, но уже только двух таблиц (фактологической и промежуточной), в процессе которого и отсеиваются все строки, неудовлетворяющие условиям выборки. К сожалению, в ряде случаев такое решение может только, наоборот, увеличить время обработки или вообще сделать выполнение запроса невозможным.
Покажем это на примере. Такой способ оптимизации дает эффект только тогда, когда промежуточная таблица умещается в оперативной памяти. Но это не всегда так. Если запрос ссылается на 10 справочных таблиц, в каждой из которых всего 10 строк длиной в 40 символов, в результате декартова произведения мы получим промежуточную таблицу в 10 млрд. строк. А объем оперативной памяти, необходимый для размещения такой таблицы, составит 400 гигабайт. И это без учета памяти для операционной системы, системных программ СУБД и буфера для просмотра теперь уже ставшей относительно маленькой фактологической таблицы.
Bitmap-индексы
- Бесполезны при малом числе различных значений в индексируемой колонке. Предположим, что индексируется поле "Пол Сотрудника". Здесь мы имеем всего два значения: Мужской/Женский. И если данные не были заранее упорядочены по этому полю, и оно используется в качестве критерия выборки, скорее всего, придется считать всю таблицу. Это связано с тем, что на физическом уровне считывается не отдельная строка, а блок, в котором размещены значения нескольких строк, и вероятность того, что в каждом блоке записаны только строки, относящиеся к мужскому или женскому полу, настолько невелика, что применение Bitmap-индексов только замедлит выполнение запроса.
- Бесполезны при большом (более нескольких сотен) количестве различных значений в индексируемой колонке. В этом случае требуется использование различных вариантов комбинированных методов индексирования (комбинация B-деревьев, битовых массивов и списков идентификаторов записей).
- Как правило, значительно снижают производительность системы при выполнении операций обновления данных.
Горизонтальное разбиение данных
- Разбиение таблицы может производиться только в соответствии со значениями данных одной колонки таблицы.
Например, если в таблице содержится информация о продаже товаров в регионах (50 регионов) за последние 48 месяцев, имеет смысл разбить таблицу или по регионам (каждый фрагмент соответствует определенному региону), или по времени (каждый фрагмент соответствует определенному месяцу). Но каждое из этих решений ускорит обработку лишь определенного фиксированного класса запросов.
Вертикальное разбиение данных
- Эффективно только в том случае, если при выполнении запроса требуется просмотр всего нескольких колонок таблицы, и чем меньше соотношение - "Число колонок в таблице/Число колонок, на которые есть ссылки в запросе", тем менее эффективным оказывается данный метод.
- Методы хранения данных по строкам и по колонкам взаимно исключают друг друга, и решение о том, как будут храниться данные, должно быть принято заранее.
- Не поддерживается транзакционная обработка данных, и очень сильно снижается производительность системы при выполнении операций обновления данных.
Таким образом, сегодня вновь складывается ситуация, от которой, казалось бы, давно и безвозвратно ушли. И вновь на первый план выносится значимость вопросов проектирования базы данных на физическом уровне: "Чтобы гибко формировать запросы и быстро получать результат, необходима гибкая комбинация разных высокоэффективных индексных структур. ...корпорации нуждаются в таких проектировщиках базы данных, которые понимали бы, что в ней находится и как она будет использоваться. Хороший проект базы данных на физическом уровне - это залог высокой производительности" (5). До боли знакомая цитата, но взятая из статьи 1996, а не 1976 года. Вспомним региональные и индексно-последовательные файлы, инвертированные списки, иерархические и сетевые БД.
К тому же от проектировщиков аналитической системы можно и даже нужно требовать, чтобы они понимали - что находится в БД. Но требовать от них того, чтобы они понимали, как она будет использоваться, просто нереально. Это требование хорошо для традиционной СОД, но никак не для системы, предполагающей нерегламентированную аналитическую обработку данных.
МСУБД
Более просто и эффективно аналитические системы реализуются средствами специализированных баз данных, основанных на многомерном представлении данных. В этих системах данные организованы не в виде плоских таблиц (как в реляционных системах), а в виде упорядоченных многомерных массивов - гиперкубов (или поликубов).
Очевидно, что такое решение требует большей суммарной памяти для хранения данных, больших затрат времени при их загрузке и является менее гибким при необходимости модификации структур данных. Но, как уже было сказано выше, в аналитических задачах все это окупается за счет более быстрого поиска и выборки данных, отсутствия необходимости в многократном соединении различных таблиц и многократного вычисления агрегированных значений. И, как правило, среднее время ответа на нерегламентированный аналитический запрос при использовании многомерной СУБД обычно на один-два порядка меньше, чем в случае реляционной СУБД с нормализованной схемой данных.
Казалось бы, все очевидно и выбор однозначен - многомерные БД. Однако не все так просто.
Многомерные базы, в силу чисто исторических причин, "не умеют" работать с большими объемами данных. На сегодняшний день их реальный предел - база объемом в 10-20 гигабайт. И хотя данное ограничение не связано с какими-либо внутренними объективными недостатками многомерного подхода и, скорее всего, является временным, сегодня это так. С чем нельзя не считаться.
К тому же за счет денормализации и предварительно выполненной агрегации 20 гигабайт в многомерной базе, в лучшем случае, эквивалентны не более чем 1 гигабайту исходных данных. По оценкам Кодда [3], для систем, основанных на многомерном представлении данных, это соотношение лежит в диапазоне от 2.5 до 100. И здесь необходимо остановиться на основном недостатке многомерных БД - неэффективному, по сравнению с реляционными БД, использованию внешней памяти. И это уже объективный фактор.
В основе многомерного подхода лежит представление данных в виде многомерных гиперкубов, при этом обычно предполагается, что внутри такого гиперкуба нет пустот. То есть все ячейки куба всегда заполнены. Это связано с тем, что данные в них обычно хранятся в виде множества логически упорядоченных блоков (массивов), имеющих фиксированную длину, причем именно блок является минимальной индексируемой единицей. И хотя в МСУБД, как правило, подразумевается, что блоки, полностью заполненные неопределенными значениями, не хранятся, это обеспечивает лишь частичное решение проблемы. Данные в таких системах хранятся в упорядоченном виде. И неопределенные значения устраняются, и то частично, только в том случае, если мы за счет выбора порядка сортировки сгруппируем их в максимально большие непрерывные группы.
Но такое решение может напрямую вступить в конфликт с тем, что МСУБД работают очень быстро только тогда, когда данные в них заранее отсортированы в том порядке, в котором они должны быть отсортированы в ответе на запрос. Но порядок сортировки, наиболее часто используемый в запросах, может не совпадать с тем, в котором они должны быть отсортированы, для максимального устранения неопределенных (несуществующих) значений. В результате разработчик может оказаться перед трудноразрешимой дилеммой:
- пожертвовать быстродействием, но это одно из главных достоинств и часто одна из основных причин выбора именно МСУБД;
- пожертвовать внешней памятью, но увеличение объема данных также не повышает быстродействие. Кроме того, как уже говорилось, МСУБД в настоящее время не приспособлены для работы с большими объемами данных.
Таким образом, МСУБД однозначно хороши только при выполнении двух требований.
- Уровень агрегации данных в БД достаточно высок, и, соответственно, объем БД не очень велик (не более нескольких гигабайт).
- В качестве граней многомерного куба выбраны достаточно стабильные во времени реквизиты (с точки зрения неизменности их взаимосвязей), и, соответственно, число несуществующих значений относительно невелико.
К сожалению, сегодня отсутствуют официальные сравнительные результаты тестирования производительности систем, реализованных на основе многомерных и реляционных баз данных (некоторые дополнительные аргументы в пользу того и другого подхода приведены в таблице 7), но при этом общая оценка такова: "Производительность хорошо настроенных реляционных систем, при использовании схемы звезда, вполне сравнима с производительностью систем, реализованных на основе многомерных баз данных".
Многомерный подход
Реляционный подход
|
Таблица 7.
Дополнительные аргументы в пользу МСУБД и РСУБД.
Витрины Данных - недостающее звено в концепциях построения аналитических систем
Концепция Витрин Данных (Data Mart) была предложена Forrester Research еще в 1991 году. По мысли авторов, Витрины Данных - множество тематических БД, содержащих информацию, относящуюся к отдельным аспектам деятельности организации, должны были стать реальной альтернативой Информационным Хранилищам (Information Warehouse) фирмы IBM.
- Концепция Витрин Данных имеет ряд несомненных достоинств.
- Аналитики видят и работают только с теми данными, которые им реально нужны.
- Целевая БД Витрины Данных максимально приближена к конечному пользователю.
- Витрины Данных обычно содержат тематические подмножества заранее агрегированных данных, их проще проектировать и настраивать.
- Для реализации Витрин Данных не требуются высокомощная вычислительная техника.
И именно Витрины Данных (или что-то очень близкое к ним) подразумевал Э. Кодд, когда использовал термин "OLAP Server".
Но концепция Витрин Данных имеет и очень серьезные пробелы. По существу, здесь имеется в виду реализация территориально-распределенной информационной системы с мало контролируемой избыточностью, но не предлагается способов для обеспечения целостности и непротиворечивости хранимых в ней данных.
Идея соединить две концепции - Хранилищ Данных и Витрин Данных, по-видимому, принадлежит М. Демаресту (M. Demarest), который в 1994 году в работе "Построение Витрин Данных" [6] предложил объединить две концепции и использовать Хранилище Данных в качестве единого интегрированного источника данных для Витрин Данных.
И сегодня именно такое многоуровневое решение:
- первый уровень - общекорпоративная БД на основе РСУБД с нормализованной или слабо денормализованной схемой (детализированные данные);
- второй уровень - БД уровня подразделения (или конечного пользователя), реализуемые на основе МСУБД (агрегированные данные);
- третий уровень - рабочие места конечных пользователей, на которых непосредственно установлен аналитический инструментарий;
постепенно становится стандартом де-факто, позволяя наиболее полно реализовать и использовать достоинства каждого из подходов:
- компактного хранения детализированных данных и поддержки очень больших БД, обеспечиваемых РСУБД;
- простота настройки и хорошие времена отклика при работе с агрегированными данными, обеспечиваемыми МСУБД.
Реляционная форма представления данных, используемая в центральной общекорпоративной БД, обеспечивает наиболее компактный способ хранения данных. А современные РСУБД уже умеют работать даже с терабайтными базами. И хотя такая центральная система обычно не сможет обеспечить оперативного режима обработки аналитических запросов, при применении новых способов индексации и хранения данных, а также частичной денормализации таблиц, время обработки заранее регламентированных запросов (а в качестве таких можно рассматривать и регламентированные процедуры выгрузки данных в многомерные БД) оказывается вполне приемлемым.
В свою очередь, использование МСУБД в узлах нижнего уровня гарантирует минимальные времена обработки и ответа на нерегламентированные запросы пользователя. Кроме того, в некоторых МСУБД имеется возможность как хранить данные на постоянной основе (непосредственно в многомерной БД), так и динамически (на время сеанса) загрузить данные из реляционных БД (на основе регламентированных запросов).
Таким образом, имеется возможность хранить на постоянной основе только те данные, которые наиболее часто запрашиваются в данном узле. Для всех остальных хранятся только описания их структуры и программы их выгрузки из центральной БД. И хотя, при первичном обращении к таким виртуальным данным, время отклика может оказаться достаточно продолжительным, такое решение обеспечивает высокую гибкость и требует более дешевых аппаратных средств.
Заключение
В заключение хотелось бы остановиться на двух моментах. Во-первых, не следует искать в концепции Хранилищ Данных что-то совершенно принципиально новое, о чем не говорилось и не писалось ранее и чему нельзя найти аналогий в прошлом. Ее реальное значение состоит в том, что Концепция Хранилищ Данных составляет "часть ответа со стороны информационных технологий на вопрос: "Что мы делаем дальше?" И, подобно многим новациям в технологиях, этот термин используется для того, чтобы описать обезоруживающую по своей простоте концепцию, которая имеет потенциал развиться со временем во что-то более сложное и значительное" [7]. И, как было показано выше, уже сегодня можно говорить о том, что появление этой концепции послужило серьезным стимулом для развития внутренней архитектуры современных СУБД, их программного окружения, инструментальных средств конечного пользователя, различных межкорпоративных стандартов.
И, во-вторых. Несмотря на то что стоимость аналитических систем даже сегодня остается достаточно высокой, а методологии и технологии реализации таких систем находятся еще в стадии их становления, уже сегодня экономический эффект, обеспечиваемый ими, существенно превышает эффект от традиционных оперативных систем.
Эффект от правильной организации, стратегического и оперативного планирования развития бизнеса трудно заранее оценить в цифрах, но очевидно, что он в десятки и даже сотни раз может превзойти затраты на реализацию таких систем. Однако не следует и заблуждаться. Эффект обеспечивает не сама система, а люди, с ней работающие. Поэтому не совсем корректны декларации типа: "Система Хранилищ Данных будет помогать менеджеру принимать правильные решения". Современные аналитические системы не являются системами искусственного интеллекта, и они не могут ни помочь, ни помешать в принятии решения. Их цель своевременно обеспечить менеджера всей информацией, необходимой для принятия решения. А какая информация будет запрошена и какое решение будет принято на ее основе, зависит только от конкретного человека.
Литература
1. W.H. Inmon. What is Data Warehouse.
2. Data Warehouse Issues. Butler Group Co., UK.
3. E.F.Codd, S.B.Codd, C.T. Salley, E.F.Codd & Associates. Providing OLAP (On-Line Analytical Processing) to User-Analysts: An IT Mandate. - 1993.
4. А.А. Сахаров. Принципы проектирования и использования многомерных баз данных (на примере Oracle Express Server). - СУБД, # 3, 1996.
5. Herb Edelstein. Битовые массивы ускоряют обработку запросов к информационным хранилищам. - Computerweek, # 28 (234), 1996.
6. Marc Demarest. Building The Data Mart, DBMS, July 1994, v. 7, n. 8, p. 44(7).
7. Data Warehousing. Butler Group Co., UK.
Сахаров Андрей Алексеевич, LVS Group, тел.: 258-41-00, e-mail: Saharov@lvs.msk.su