Концепции построения и реализации информационных систем

Введение

В области информационных технологий, всегда существовали два  взаимодополняющих друг друга направления  развития:

• Системы, ориентированные на операционную обработку данных - системы обработки данных (СОД).
• Системы, ориентированные на анализ данных - системы поддержки принятия решений (СППР).

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

На первых этапах автоматизации  требовалось и требуется навести  порядок именно в процессах повседневной рутинной обработки (переработки) данных, на что и ориентированны традиционные СОД. Более того, системы СППР являются в определенном смысле вторичными, по отношению к ним. Здесь возможна аналогия с производством. Любая продукция, прежде чем попасть на склад и быть отгружена потребителю, должна быть сначала произведена. И прежде чем заниматься анализом данных, необходимо эти данные иметь (произвести). А именно, это и является одной из функций СОД.

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

Именно на разрешение этого  противоречия - отсутствие информации при наличии и даже избытке  и нацелена концепция Хранилищ Данных (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 инструментарий: