Какой лучший подход получить от реляционной базы данных OLTP до куба OLAP?

У меня есть стандартная нормализованная база данных OLTP, и я понял, что мне нужно сделать некоторые сложные запросы, средние значения, стандартные отклонения в разных измерениях в данных.

Итак, я обратился к SSAS и созданию кубов OLAP.

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

Является ли обычная процедура использованием SSIS для выполнения какого-то процесса ETL на моем основном OLTP-БД в другую реляционную БД, которая находится в правильной конфигурации "звезды" с фактами и измерениями, а затем использовать эту БД в качестве источника данных для Кубы OLAP?

Спасибо

Ответ 1

Да, это основная идея. Вы берете свою высоко нормированную базу данных OLTP и де-нормализуете ее на кубы с целью нарезки и обработки данных, а затем представления отчетов об этом. Логическая технология проектирования называется размерным моделированием. Существует тонкая информация о мерном моделировании на Kimball Group. Ralph Kimball книги по теме также превосходны. Если вы хотите узнать больше о самих инструментах BI, ознакомьтесь с виртуальными лабораториями в службах SSIS, анализа и т.д.

Ответ 2

Ответ: да, но.

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

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

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

Снежинка - это схема 3NF-иш (она не обязательно должна быть 3NF - вы можете сгладить ее части на практике), которая имеет только отношения 1: M. SSAS может поддерживать несколько других структур измерения, таких как parent-child (отношения родитель-потомок с рекурсивным самосоединением) и измерения M: M (отношения M: M - именно то, что они звучат). Размеры этого типа более сложны, но могут быть вам полезны.

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

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

Таблицы фактов присоединяются к измерениям. В SSAS2005 + вы можете присоединиться к различным таблицам фактов в разных зернах в пределах измерения. Обычно я не использовал бы это для использования в хранилище данных, но эта функция может быть полезна, если вы пытаетесь использовать исходные данные, не тратя их слишком сильно.

Если это не сработает, вам вполне может понадобиться написать процесс ETL, чтобы заполнить схему звездочки или снежинки.

Несколько оговорок:

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

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

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