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

Хранилище данных предприятия (EDW или DW) или оперативный склад данных(ODS)?

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

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

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

Подведем итоги различий между ODS и DW:

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

Методы проектирования хранилищ данных

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

Билл Инмон - Подход к проектированию хранилищ данных “сверху вниз”

Билла Инмонхж иногда называют также «отцом хранилищ данных»; его методология проектирования основана на подходе “сверху вниз” и определяет хранилище данных в соответствии со следующими принципами:

• Предметная ориентация. Данные в хранилище классифицируются на основе области, которую они описывают, следовательно, являются «предметными».
• Интегрированность. Данные интегрируются из различных источников и унифицируются по именам, измерениям, классификации для использования в хранилище данных, которое  обеспечивает консолидированное представление данных предприятия, следовательно является интегрированным решением.
• Неизменяемость. Как только данные будут интегрированы \ загружены в хранилище данных, их можно будет только читать. Пользователи не смогут вносить изменения в данные, что делает данные неизменяемыми.
• Хронологичность. Наконец, данные хранятся в течение длительных периодов времени, количественно определяемых в годах, и имеют дату и временную метку, и поэтому они описываются как хронологические.

Билл Инмон увидел необходимость интегрировать данные из разных OLTP-систем в централизованный репозиторий (называемый хранилищем данных) по принципу «сверху вниз». Билл Инмон представил хранилище данных в центре «Корпоративной информационной фабрики» (CIF), которое обеспечивает логическую структуру для предоставления возможностей бизнес-аналитики (BI) и управления бизнесом.

Этот сверху-вниз дизайн обеспечивает высококонвертированное пространственное представление данных через витрины данных, поскольку все витрины данных загружаются из централизованного хранилища (DW). Проектирование «сверху вниз» также оказалось гибким для поддержки изменений в бизнесе, поскольку оно рассматривает организацию в целом, а не каждую функцию или бизнес-процесс организации.  Создание новых витрин мерных данных в отношении данных, расположенных в хранилище данных, является относительно простой задачей. Несмотря на такие преимущества, существует и ряд проблем, связанных с подходом «сверху вниз»: поскольку он представляет собой очень крупный, широкомасштабный проект, поэтому первоначальные затраты на внедрение хранилища данных с использованием такой методологии значительны. Кроме того, проходит немало времени, прежде чем конечные пользователи начинают испытывать первоначальные преимущества решения, Помимо прочего,  методология «сверху вниз» часто бывает негибкой и не реагирующей на меняющиеся потребности отдела или бизнес-процессов (проблема для сегодняшней динамично меняющейся среды) на этапе реализации.

Ральф Кимбалл - Подход к проектированию хранилища данных “снизу вверх”

Ральф Кимбалл - известный автор по вопросам хранения данных. Его методология дизайна называется многомерным моделированием или методологией Кимбалла. Она фокусируется на восходящем подходе, подчеркивая важность быстрого доступа пользователей к хранилищу данных. По его мнению, хранилище данных - это копия транзакционных данных, специально структурированных для аналитических запросов и отчетности и функционирования системы поддержки принятия решений.  Согласно его методологии, сначала создаются  витрины данных  - для предоставления отчетов и аналитических возможностей для конкретных бизнес-процессов, а в дальнейшем эти витрины данных могут в конечном итоге объединяться вместе для создания всеобъемлющего хранилища корпоративных данных. Подход «снизу вверх» сосредоточен на каждом бизнес-процессе в один момент времени, поэтому инвестиции возвращаются так же быстро, как создается первый файл данных. Но, в случае не слишком тщательного планирования и чрезмерной концентрации на отдельном бизнес-процессе, вы рискуете не получить общую картину  хранилища данных предприятия (если вы потеряли некоторые измерения или создали избыточные измерения).

Подход «снизу вверх» Ральфа Кимбалла предлагает создать бизнес-матрицу, которая должна содержать все общие элементы, используемые витринами данных, такие как согласованные или общие измерения, определенные для предприятия в целом. Благодаря этому, пользователь может проектировать и разрабатывать решения, которые поддерживают анализ в бизнес-процессах для перекрестных продаж.

No Comments