Источники данных и привязки (многомерные модели SSAS)

Кубы, измерения и другие объекты в службах Analysis Services могут быть привязаны к источнику данных. Источник данных может быть одним из следующих объектов:

• Реляционный источник данных.

• Конвейер служб Analysis Services, который выводит набор строк (или наборы строк с главами).

Средство выражения источника данных зависит от типа источника данных. Например, реляционный источник данных отличается строкой подключения. Дополнительные сведения о источниках данных см. в разделе "Источники данных" в многомерных моделях.

Независимо от используемого источника данных представление источника данных (DSV) содержит метаданные для источника данных. Таким образом, привязки для куба или других объектов служб Analysis Services выражаются в виде привязок к DSV. Эти привязки могут включать привязки к логическим объектам-объектам, таким как представления, вычисляемые столбцы и связи, которые физически не существуют в источнике данных. Службы Analysis Services добавляют вычисляемый столбец, который инкапсулирует выражение в DSV, а затем привязывают соответствующую меру OLAP к этому столбцу в DSV. Для получения дополнительной информации о представлениях источников данных см. в многомерных моделях.

Каждый объект Analysis Services привязывается к источнику данных собственным образом. Кроме того, привязки данных для этих объектов и определение источника данных можно предоставить либо встроенно в определение связанного объекта (например, измерения), либо в виде отдельного набора определений.

Типы данных служб Analysis Services

Типы данных, используемые в привязках, должны соответствовать типам данных, поддерживаемым службами Analysis Services. В службах Analysis Services определены следующие типы данных:

Все данные, полученные из источника данных, преобразуются в тип SSAS, указанный в привязке (обычно во время обработки). Ошибка возникает, если преобразование невозможно выполнить (например, String to Int). SQL Server Data Tools (SSDT) обычно задает тип данных в привязке к тому, который лучше всего соответствует типу источника в источнике данных. Например, типы SQL, DateTime, SmallDateTime, DateTime2, DateTimeOffset сопоставляются с датой SSAS, а время типа SQL сопоставляется со строкой.

Привязки для измерений

Каждый атрибут измерения привязан к столбцу в dsV. Все атрибуты измерения должны поступать из одного источника данных. Однако атрибуты могут быть привязаны к столбцам в разных таблицах. Связи между таблицами определяются в dsV. В случае, если существует более одного набора связей с одной и той же таблицей, может потребоваться ввести именованный запрос в DSV, чтобы он служил таблицей-псевдонимом. Выражения и фильтры определяются в DSV с помощью именованных вычислений и именованных запросов.

Привязки для групп мер, мер и разделов

Каждая группа мер имеет следующие привязки по умолчанию:

• Группа мер привязана к таблице в dsV (например, MeasureGroup.Source).

• Каждая мера привязана к столбцу в этой таблице (например, Measure.ValueColumn.Source).

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

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

Источник данных по умолчанию должен быть определен в DSV, тем самым предоставляя сведения о схеме, включая сведения о связях. Любые дополнительные таблицы или запросы, указанные на уровне секционирования, не должны быть указаны в DSV, но они должны иметь ту же схему, что и таблица по умолчанию, определенная для группы мер, или, по крайней мере, они должны содержать все столбцы, используемые атрибутами мер или детализации. Подробные привязки для каждого атрибута измерения и детализации нельзя переопределить на уровне секции, и предполагается, что они относятся к тем же столбцам, что и для группы мер. Таким образом, если секция использует источник данных, который фактически имеет другую схему, запрос, определенный для секции, TableDefinition должен привести к той же схеме, что и схема, используемая группой мер.

Атрибуты гранулярности группы измерений

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

Sales(RequestedDate, OrderedProductID, ReplacementProductID, Qty)

Product(ProductID, ProductName,Category)

``

Relation: Sales.OrderedProductID -> Product.ProductID

Relation: Sales.ReplacementProductID -> Product.ProductID

``

Если вы анализируете через упорядоченный продукт, то для роли "Упорядоченный продукт в измерении продаж", атрибут уровня детализации продукта будет привязан к Sales.OrderedProductID.

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

• Степень детализации OLAP крупнее, чем степень детализации в источнике.

• Промежуточная таблица пересекает таблицу фактов и таблицу измерений.

• Ключ измерения не совпадает с первичным ключом в таблице измерений.

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

Например, в тех же примерах таблиц, что и выше, если степень детализации была по категории, то можно представить представление о продажах:

SalesWithCategory(RequestedDate, OrderedProductID, ReplacementProductID, Qty, OrderedProductCategory)

SELECT Sales.*, Product.Category AS OrderedProductCategory

FROM Sales INNER JOIN Product

ON Sales.OrderedProductID = Product.ProductID

``

В этом случае категория GranularityAttribute привязана к SalesWithCategory.OrderedProductCategory.

Переход с объектов поддержки принятия решений

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

Аналогичным образом невозможно повторно привязать атрибуты измерения в секции, хотя DSO 8.0 также позволяет повторно привязывать эти атрибуты. Стратегия миграции в этих случаях заключается в определении необходимых именованных запросов в DSV, чтобы те же таблицы и столбцы существовали в DSV для разделов так же, как таблицы и столбцы, используемые для размерности. В таких случаях может потребоваться внедрение простой миграции, при которой предложение From/Join/Filter сопоставляется с одним именованным запросом, а не со структурированным набором связанных таблиц. Поскольку DSO 8.0 позволяет переназначать размеры секции даже при использовании одного и того же источника данных, миграция также может потребовать нескольких DSV для одного источника данных.

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

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

Привязки для моделей интеллектуального анализа данных

Модель данных для анализа может быть реляционной или OLAP. Привязки данных для реляционной модели интеллектуального анализа данных значительно отличаются от привязок для модели интеллектуального анализа данных OLAP.

Привязки для модели реляционного интеллектуального анализа данных

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

• Каждый негнездовой столбец таблицы связан со столбцом в основной таблице или таблице, связанной с основной таблицей (следуя отношению многие-к-одному или один-к-одному). DSV определяет связи между таблицами.

• Каждый вложенный столбец таблицы привязан к исходной таблице. Затем столбцы, принадлежащие вложенной таблице, привязаны к столбцам в этой исходной таблице или таблице, связанной с исходной таблицей. (Опять же, связь следует принципу "многие ко одному" или "один к одному".) Связи модели добычи данных не предоставляют путь к соединению к вложенной таблице. Вместо этого связи, определенные в DSV, предоставляют эти сведения.

Привязки для модели интеллектуального анализа данных OLAP

Модели интеллектуального анализа данных OLAP не имеют эквивалента DSV. Таким образом, привязки данных должны осуществлять разрешение неоднозначностей между столбцами и источниками данных. Например, модель интеллектуального анализа данных может основываться на кубе продаж, а столбцы могут быть основаны на Количество, Сумма и Название продукта. Кроме того, модель интеллектуального анализа данных может основываться на продукте, а столбцы могут основываться на имени продукта, цвете продукта и вложенной таблице с параметром Sales Qty.

В модели интеллектуального анализа данных OLAP привязки данных соответствуют следующим правилам:

• Каждый несвязанный столбец таблицы привязан к измерению куба, атрибуту измерения этого куба (указывая CubeDimension для разрешения неоднозначности в случае ролей измерения) или атрибуту в измерении.

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

Внестрочные привязки

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

ASSL позволяет указывать внестрочные привязки либо в команде Process, если она не находится в пакете, либо в команде Batch. Если в команде Batch указаны внестрочные привязки, все привязки, указанные в команде Batch, создают новый контекст привязки, в котором выполняются все команды Process пакета. Этот новый контекст привязки включает объекты, которые косвенно обрабатываются из-за Process команды.

При указании внестроковых привязок в команде они переопределяют встроенные привязки, содержащиеся в сохраняемом DDL для указанных объектов. Эти обработанные объекты могут включать объект, напрямую упомянутый в команде Process, или они могут включать другие объекты, которые автоматически инициируются как часть процесса обработки.

Привязки вне строки задаются путем включения необязательного Bindings объекта коллекции с командой обработки. Необязательная Bindings коллекция содержит следующие элементы.

Все элементы, относящиеся к привязкам вне строк, являются необязательными. Для любых элементов, не указанных, ASSL использует спецификацию, содержащуюся в DDL сохраняемого объекта. Спецификация DataSource или DataSourceView в команде Process необязательна. Если DataSource или DataSourceView заданы, они не создаются и не сохраняются после завершения команды Process.

Определение типа внешней привязки

В коллекции вне зависимости от строки Bindings, ASSL позволяет собирать привязки для нескольких объектов, каждый из которых является Binding. Каждая из них Binding имеет расширенную ссылку на объект, которая похожа на ссылку на объект, но может ссылаться на дополнительные объекты (например, атрибуты измерения и атрибуты группы мер). Этот объект принимает плоскую форму, типичную для Object элемента в Process командах, за исключением того, что < теги object></Object> отсутствуют.

Каждый объект, для которого указана привязка, определяется XML-элементом идентификатора объекта>формы < (например, DimensionID). После того как вы идентифицировали объект как можно точнее с помощью идентификатора формы <объекта>, необходимо определить элемент, для которого указана привязка, который обычно является Source. Часто отмечают случай, когда Source является свойством DataItem, что характерно для привязок столбцов в атрибуте. В этом случае DataItem тег не указан; вместо этого вы просто указываете свойство Source, как если бы оно было непосредственно привязано к столбцу.

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

Translations, хотя у них нет идентификатора, семантическая идентификация определяется их языком. Translations Поэтому внутри Binding необходимо включить идентификатор языка.

Дополнительный элемент, который разрешен внутри Binding, но не существует непосредственно в DDL, — это ParentColumnID, используемый для вложенных таблиц для интеллектуального анализа данных. В этом случае необходимо определить родительский столбец в вложенной таблице, для которой предоставляется привязка.