2 Интегрированность  данных

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

      Если  в четырех разных приложениях  пол клиента кодировался четырьмя различными способами, то в информационном хранилище будет использована единая для всех данных схема кодировки (например, f,m).  
 

3 Инвариантность во  времени

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

      В OLTP-системах информация часто модифицируется как результат выполнения каких-либо транзакций. Временная инвариантность данных в ХД достигается за счет введения полей с атрибутом "время" (день, неделя, месяц) в ключи таблиц. В результате записи в таблицах ХД никогда не изменяются, представляя собой снимки данных, сделанные в определенные отрезки времени. В ХД содержатся как бы моментальные снимки данных. Каждый элемент в своем ключе явно или косвенно хранит временной параметр, например день, месяц или год.  

4 Неразрушаемость  - cтабильность информации

      В OLTP-системах записи могут регулярно  добавляться, удаляться и редактироваться. В ХД, как следует из требования временной инвариантности, однажды загруженные данные теоретически никогда не меняются. По отношению к ним возможны только две операции: начальная загрузка и чтение (доступ). Это и определяет специфику проектирования структуры базы данных для ХД. Если при создании OLTP-систем разработчики должны учитывать такие моменты, как откаты транзакций после сбоя сервера, борьба с взаимными блокировками процессов (deadlocks), сохранение целостности данных, то для DW данные проблемы не столь актуальны - перед разработчиками стоят другие задачи, связанные, например, с обеспечением высокой скорости доступа к данным.  
 
 

5 Минимизация избыточности  информации

      Поскольку информация в DW загружается из OLTP-систем, возникает вопрос, не ведет ли это к чрезмерной избыточности данных? Не обязательно.  И это объясняется следующими причинами:

• при загрузке информации из OLTP – систем в ХД данные фильтруются. Многие из них вообще не попадают в ХД, поскольку лишены смысла с точки зрения использования в системах поддержки принятия решений;
• информация в OLTP-системах носит, как правило, оперативный характер, и данные, потеряв актуальность, удаляются. В ХД, напротив, хранится историческая информация, и с этой точки зрения перекрытие содержимого ХД данными OLTP-систем оказывается весьма незначительным;
• в ХД хранится некая итоговая информация, которая в базах данных OLTP-систем вообще отсутствует;
• во время загрузки в ХД записи сортируются, очищаются от ненужной информации и приводят к единому формату. После такой обработки это уже совсем другие данные.

1.2.3 Взаимное соотношение  концепции Хранилищ  Данных и концепций  анализа данных

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

      То  есть она фактически не затрагивает  и оставляет свободу выбора в вопросах, относящихся:

• к конкретным способам представления данных в целевой БД (например многомерное, реляционное или смешанное);
• режимам анализа данных (статический или динамический).

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

-   традиционный статический анализ  данных;

• динамический интерактивный многомерный анализ данных.

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

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

Таблица 3. Сравнение характеристик статического и динамического анализа.

      У истоков концепции многомерного динамического анализа - OLAP, стоит  основоположник реляционного подхода Э. Кодд [2], сформулировавший 12 основных требований к средствам реализации OLAP.

      Заметим, что у Кодда, термин "OLAP" обозначает исключительно конкретный способ представления  данных на концептуальном уровне - многомерный.

      Однако  исторически сложилось так, что сегодня термин "OLAP" подразумевает не только многомерный взгляд на данные со стороны конечного пользователя, но и многомерное представление данных в целевой БД [33]. Именно с этим связано появление в качестве самостоятельного термина "Реляционный OLAP" (ROLAP).

      Закономерен вопрос, как взаимно соотносятся  концепции: Хранилищ Данных и различные  концепции анализа данных (например, как соотносятся концепция Хранилищ Данных и OLAP/ROLAP)? По-видимому, правильный ответ состоит в том, что формально  обе они говорят об одном и том же: "Что требуется для успешной реализации информационной системы, ориентированной на аналитическую работу с данными". Но, однако, это два различных взгляда.

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

      Взгляд  со стороны специалиста, отвечающего  за реализацию и сопровождение системы (выраженный Б. Инмоном), который также  вполне естественно говорит о  том, что конечной целью Хранилища  Данных является обеспечение информационных потребностей конечных пользователей (менеджеров и аналитиков). Но для него главное - выявление наиболее общих свойств и характеристик данных. Решение вопросов сбора, транспортировки, очистки, согласования и агрегации данных из различных внешних источников.

      Таким образом, формально говоря об одном и том же, эти концепции не конкурируют, а скорее, взаимно дополняют друг друга.

      В то же время эти концепции никак  непосредственно не взаимосвязаны. Хранилище Данных может использоваться исключительно как источник для  регламентированных аналитических сводок и отчетов или для регламентированной статистической обработки, но не для OLAP. А OLAP-инструментарий может быть с успехом использован для непосредственной работы с оперативными данными из традиционной СОД. 
 
 

1.3 Технологии и средства реализации 

1.3.1 Вопросы реализации  Хранилищ Данных

      Аналитические системы всегда предъявляли существенно  более высокие, чем традиционные СОД, требования к аппаратному обеспечению  и программному обеспечению. И, приступая  к построению ХД, следует учитывать необходимость разрешения таких вопросов, как:

1. неоднородность программной среды;
2. распределенность;
3. защита данных от несанкционированного доступа;
4. построение и ведение многоуровневых справочников метаданных;
5. эффективное хранение и обработка очень больших объемов данных.

1 Неоднородность программной  среды

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

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

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