Как лучше всего перейти от реляционной базы данных OLTP к кубу OLAP? - PullRequest
11 голосов
/ 23 июня 2009

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

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

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

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

Спасибо

Ответы [ 2 ]

9 голосов
/ 23 июня 2009

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

5 голосов
/ 22 июня 2010

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

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

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

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

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

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

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

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

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

Несколько условий:

  1. Можно заставить кубы работать в режиме реального времени, когда они просто отправляют запрос к базовым данным. Это создает риск создания неэффективных запросов к исходным данным, поэтому не рекомендуется, если вы не уверены, что знаете, что делаете.

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

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

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

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

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

...