Ответ: да, но.
Измерение в SSAS имеет отношения между атрибутами, которые могут использоваться рядом полей для фильтрации среза. Эти отношения могут быть иерархическими (более одного уровня - один атрибут может иметь родительский элемент и дочерние элементы). Вы также можете установить пути сверления (называемые иерархиями в SSAS), которые действуют как атрибуты, но имеют ориентированную развертку.
Для того, чтобы для этого вам нужно иметь ключи, доступные в базе данных, которые живут строго иерархически (т. е. ключи не могут иметь нечеткие отношения, когда у ребенка может быть более одного родителя). Обратите внимание, что это не вся история, но это довольно близко к реальности на данный момент.
Эти иерархии могут быть построены из плоской структуры данных системой или представлены с помощью снежинки с отношениями, отмеченными в представлении исходного источника данных (DSV являются частью метаданных куба и может быть используется для массажа данных способом, похожим на представления базы данных).
Снежинка - это схема 3NF-ish (она не обязательно должна быть 3NF - вы можете сгладить ее части на практике), которая имеет только отношения 1: M. SSAS может поддерживать несколько других структур измерения, таких как parent-child (отношения родитель-потомок с рекурсивным самосоединением) и измерения M: M (отношения M: M - именно то, что они звучат). Размеры этого типа более сложны, но могут быть вам полезны.
Если у вас есть ключи в исходных данных, которые могут иметь эквивалентную семантику данных для снежинки, то вы можете заполнить свой куб через серию представлений базы данных в исходной системе, которые представляют базовые данные в достаточно снежинке, как формат для измерений куба (я на самом деле делал это несколько раз). Схемы, которые сильно используют синтетические ключи, с большей вероятностью будут хорошо работать для этого.
Если ваш поставщик или другие пользователи не позволяют добавлять представления в исходную базу данных, вы можете использовать представление источника данных. У DSV могут быть виртуальные таблицы, называемые «именованными запросами», которые заполняются из запроса к базе данных.
Таблицы фактов соединяются с размерами. В SSAS2005 + вы можете присоединиться к различным таблицам фактов в разных зернах в пределах измерения. Обычно я не использовал бы это для использования в хранилище данных, но эта функция может быть полезна, если вы пытаетесь использовать исходные данные, не массируя их слишком сильно.
Если это не сработает, вам вполне может понадобиться написать процесс ETL, чтобы заполнить схему звездочки или снежинки.
Несколько условии, что:
Кубики могут быть сделаны для работы в режиме реального времени, когда они просто выдать запрос к базовым данным. Это создает риск создания неэффективных запросов к исходным данным, поэтому не рекомендуется, если вы не уверены, что знаете, что делаете.
По сравнению с (i), вы, вероятно, не сможете использовать кубы в качестве источника данных для экранов в своем приложении. Если вам нужно рассчитать средние значения для того, что пользователь хочет увидеть на экране, вам, вероятно, придется вычислить его в хранимой процедуре за экраном.
Если вы сделаете это, настройте реплицированную базу данных и заполните куб от этого. Периодически обновляйте эту базу данных, поэтому ваш процесс ETL может выполняться из внутреннего согласованного набора данных. Если вы запустите из живой базы данных, вы рискуете, что некоторые из элементов будут заполнены позже, что зависит от записей, которые были созданы после выполнения соответствующего процесса.
У вас может быть ситуация, когда вы запускаете размерную нагрузку, а затем вводите новые данные в систему. Когда загружается загрузка таблицы фактов, теперь она содержит данные, зависящие от данных измерений, которые не были загружены. Это разрушит куб и приведет к сбою процесса загрузки. Пакетное обновление реплицированной базы данных для запуска загрузки ETL или куба позволит смягчить эту проблему.
Если у вас нет возможности реплицируемой базы данных, вы можете настроить более слабые политики для отсутствия данных.
Если ваши основные производственные данные имеют значительные проблемы с качеством данных, они будут отражаться в кубах. GIGO.