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

Применимо к: SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

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

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

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

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

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

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

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

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

Все данные, полученные из источника данных, преобразуются в тип SSAS, указанный в привязке (обычно во время обработки). Ошибка возникает, если преобразование невозможно выполнить (например, String to Int). Sql Server Data Tools обычно задает тип данных в привязке к тому, который лучше всего соответствует типу источника в источнике данных. Например, типы 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. Таким образом, привязки данных должны предоставлять разрешение неоднозначностей между столбцами и источниками данных. Например, модель данных может основываться на кубе продаж, а столбцы могут быть основаны на Количестве, Сумме и Наименовании продукта. Кроме того, модель данных может быть основана на продукции, а столбцы - на названии продукта, цвете продукта и вложенной таблице с количеством продаж.

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

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

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

Автономные привязки

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

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

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

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

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

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

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

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

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

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

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