Лекции по "Информационные системы"

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

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

Хранилища данных

Термин  data warehouse чаще всего переводится на русский язык как "хранилище данных" или "информационное хранилище".

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

Традиционный термин "хранилище данных" и новаторский - "склад данных" – можно использовать как синонимы.

Целью построения корпоративного хранилища данных является

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

W. Inmon, автор концепции хранилищ данных, определяет такие хранилища как:

1. предметно-ориентированные,
• Означает кросс-функциональный срез данных. Все собранные данные, относящиеся к объекту исследования, равноправны в хранилище независимо от их происхождения. Это кардинально отличается от СОД – где данные подобраны в соответствии с требованиями конкретных приложений
2. интегрированные,
• подразумевает согласование, унификацию и стандартизацию данных, т.е. приведение их к общему знаменателю
3. неизменчивые,
• однажды загруженные данные никогда не меняются. Только две операции: начальная загрузка и чтение.
4. поддерживающие хронологию
• данные хронологически структурированы и отражают историю
• !!!! Ранее архивация не актуальных данных. Теперь (стоимость хранения резко уменьшилась) фактически неограниченное число состояний объекта в процессе существования. Ретроспективный анализ.
• Два вида хронологии: событийная история (из OLAP) и набор изменений сущности – объектов (люди, подразделения, оборудование). Типичная ошибка при проектировании хранилища – отсутствие объектной истории

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

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

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

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

1. Время обработки запросов к распределенному хранилищу значительно превышает соответствующие показатели для централизованного хранилища.
1. Кроме того, структуры баз данных СОД, рассчитанные на интенсивное обновление записей, в высокой степени нормализованы, поэтому в аналитическом запросе к ним требуется объединение большого числа таблиц, что также приводит к снижению быстродействия.
2. Интегрированный взгляд на распределенное корпоративное хранилище возможен только при выполнении требования постоянной связи всех источников данных в сети. Любая временная недоступность хотя бы одного из источников может либо сделать работу информационно-аналитической системы (ИАС) невозможной, либо привести к ошибочным результатам.
3. Выполнение сложных аналитических запросов к таблицам СОД потребляет большой объем ресурсов сервера БД и приводит к снижению быстродействия СОД, что недопустимо (время выполнения операций в СОД часто весьма критично).
4. Различные СОД могут поддерживать разные форматы и кодировки данных. В таком случае цель - формирование единого непротиворечивого взгляда на объект управления - может не быть достигнута.
5. Часто на один и тот же вопрос может быть получено несколько вариантов ответа, что может быть связано с:
1. не синхронностью моментов обновления данных,
2. отличиями в трактовке отдельных событий, понятий и данных,
3. изменением семантики данных в процессе развития предметной области,
4. ошибками при вводе,
5. утерей фрагментов архивов и т. д.
6. Главным же недостатком следует признать практическую невозможность обзора длительных исторических последовательностей, ибо при физическом отсутствии центрального хранилища доступны только те данные, которые на момент запроса есть в реальных БД связанных СОД.
1. Основное назначение СОД - оперативная обработка данных, поэтому они не могут позволить себе роскошь хранить данные за длительный (более нескольких месяцев) период; по мере устаревания данные выгружаются в архив и удаляются из транзакционной БД.
2. Что касается аналитической обработки, для нее как раз наиболее интересен взгляд на объект управления в исторической ретроспективе.

Таким образом, хранилище данных функционирует по следующему сценарию.

• 1) По заданному регламенту в него собираются данные из различных источников - баз данных систем оперативной обработки.
• 2) В хранилище поддерживается хронология: наравне с текущими данными хранятся исторические данные с указанием времени, к которому они относятся.
• 3) В результате необходимые доступные данные об объекте управления собираются в одном месте, приводятся к единому формату, согласовываются и, в ряде случаев, агрегируются до минимально требуемого уровня обобщения.

Облегченным вариантом корпоративного хранилища данных могут быть витрины данных (Data Mart), то есть тематические БД, содержащие информацию, относящуюся к отдельным аспектам деятельности организации.

• Концепция витрин данных была предложена Forrester Research в 1991 году. При этом главная идея заключалась в том, что витрины данных содержат тематические подмножества заранее агрегированных данных, по размерам гораздо меньшие, чем общекорпоративное хранилище данных, и, следовательно, требующие менее производительной техники для поддержания.
• В 1994 году М. Demarest предложил объединить две концепции и использовать хранилище данных в качестве единого интегрированного источника для многочисленных витрин данных.

Типовая архитектура хранилища данных приведена на рис.1. Она содержит следующие компоненты:

• 1) Источники данных (data sources), т.е. места, из которых пополняется хранилище. Они могут быть как
• внутренними источниками (базы данных приложений или унаследованных систем),
• внешними источниками (например, позаимствованные у других организаций или полученные в Internet).
• 2) Извлечение, очистка и загрузка (extract, transformation and loading) - набор средств загрузки данных, как правило, в сочетании с дополнительной обработкой:
• проверкой данных на чистоту, консолидацией, форматированием, фильтрацией и пр.
• 3) Буферный накопитель (staging area). Это временное место хранения данных, которые уже извлечены, но еще не помещены в хранилище.
• 4) Интегрированное хранилище (integrated warehouse) представляет собой ядро всей системы - один или несколько серверов БД, реализующих выбранную структуру хранилища .
• 5) Инструменты доступа к данным (data access tools) - обеспечивают непосредственное общение пользователя с данными хранилища, направленное на поддержку принятия решений.
• Поддержка принятия управленческих решений на основе накопленных данных может выполняться в трех базовых сферах:
• Сфера детализированных данных (Relation Space). Поддержка принятия решений здесь достигается за счет поиска наиболее полной информации об интересующих информационных объектах, а также выявления связей между ними.
• Сфера агрегированных показателей (Aggregation Space). Целью данной сферы является комплексный взгляд на собранную информацию, ее обобщение и агрегация, гипер-кубическое представление и многомерный анализ. Все это является задачами систем оперативной аналитической обработки данных (OLAP).
• Сфера закономерностей (Influence Space). Главными задачами здесь являются поиск функциональных и логических закономерностей в накопленной информации, построение моделей и правил, которые объясняют найденные аномалии и/или (с определенной вероятностью) прогнозируют развитие некоторых процессов. Интеллектуальная обработка производится методами интеллектуального анализа данных (ИАД, Data Mining).

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

• 10.1.1. Проектирования хранилища;
• 10.1.2. Проработки механизмов пополнения хранилища новыми данными из внешних источников;
• 10.1.3. Выбор, настройка и/или создание программного обеспечения - инструментов конечного пользователя.