Источники данных и привязки (службы Analysis Services — многомерные данные)
Кубы, измерения и другие объекты служб Analysis Services могут быть привязаны к источнику данных. Источником данных может быть один из следующих объектов.
Реляционный источник данных.
Конвейер служб Analysis Services, который выводит набор строк (или разбитые на разделы наборы строк).
Способы выражения источника данных зависит от его типа. Например, реляционный источник данных отличается от других строкой соединения. Дополнительные сведения об источниках данных см. в разделе Источники данных (службы Analysis Services — многомерные данные).
Независимо от используемого источника данных, представление источника данных (DSV) содержит его метаданные. Таким образом, привязки для куба или других объектов служб Analysis Services выражаются привязками к представлению источника данных. Они могут включать привязки к логическим объектам (например представлениям), вычисляемым столбцам и связям, которые физически не существуют в источнике данных. Использование представления источника данных для привязки логических объектов является новой возможностью в SQL Server 2008. Например, в SQL Server 2000 для меры OLAP в качестве источника данных может быть указано выражение. Однако в SQL Server 2005 и SQL Server 2008 в службах Analysis Services можно добавить вычисляемый столбец, который инкапсулирует выражение в представление источника данных, а затем привязать соответствующую меру OLAP к этому столбцу в представлении источника данных. Дополнительные сведения о представлениях источника данных см. в разделе Представления источников данных (службы Analysis Services — многомерные данные).
Каждый объект служб Analysis Services привязывается к источнику данных собственным методом. Кроме того, привязки данных для этих объектов и определение источника данных могут быть встроены в определение связанного с данными объекта (например измерения) или задаваться в виде отдельного набора определений.
Типы данных служб Analysis Services
Типы данных, используемых в привязках, должны соответствовать типам данных, поддерживаемым службами Analysis Services. Для служб Analysis Services определены следующие типы данных.
Тип данных служб Analysis Services |
Описание |
|---|---|
BigInt |
64-разрядное целое число со знаком. Соответствует типу данных Int64 для платформы Microsoft .NET Framework и типу данных DBTYPE_I8 для OLE DB. |
Bool |
Логическое значение. Соответствует типу данных Boolean для платформы .NET Framework и типу данных DBTYPE_BOOL для OLE DB. |
Currency |
Значение валюты в диапазоне от -2 в степени 63 (или -922 337 203 685 477,5808) до (2 в степени 63)-1 (или +922 337 203 685 477,5807) с точностью до одной десятитысячной единицы валюты. Соответствует типу данных Decimal для платформы .NET Framework и типу данных DBTYPE_CY для OLE DB. |
Date |
Значение даты, хранящееся в виде числа с плавающей запятой двойной точности. Целая часть числа равна числу дней, прошедшему с 30 декабря 1899 г., а десятичная часть равна части дня. Соответствует типу данных DateTime для платформы .NET Framework и типу данных DBTYPE_DATE для OLE DB. |
Double |
Число двойной точности с плавающей запятой в диапазоне от -1,79E +308 до 1,79E +308. Соответствует типу данных Double для платформы .NET Framework и типу данных DBTYPE_R8 для OLE DB. |
Integer |
32-разрядное целое число со знаком. Соответствует типу данных Int32 для платформы .NET Framework и типу данных DBTYPE_I4 для OLE DB. |
Single |
Число одинарной точности с плавающей запятой в диапазоне от -3,40E +38 до 3,40E +38. Соответствует типу данных Single для платформы .NET Framework и типу данных DBTYPE_R4 для OLE DB. |
SmallInt |
16-разрядное целое число со знаком. Соответствует типу данных Int16 для платформы .NET Framework и типу данных DBTYPE_I2 для OLE DB. |
TinyInt |
8-разрядное число со знаком. Соответствует типу данных SByte для платформы .NET Framework и типу данных DBTYPE_I1 для OLE DB. |
UnsignedBigInt |
64-разрядное целое число без знака. Соответствует типу данных UInt64 для платформы .NET Framework и типу данных DBTYPE_UI8 для OLE DB. |
UnsignedInt |
32-разрядное целое число без знака. Соответствует типу данных UInt32 для платформы .NET Framework и типу данных DBTYPE_UI4 для OLE DB. |
UnsignedSmallInt |
16-разрядное целое число без знака. Соответствует типу данных UInt16 для платформы .NET Framework и типу данных DBTYPE_UI2 для OLE DB. |
WChar |
Поток символов Юникод, заканчивающийся символом null. Соответствует типу данных String для платформы .NET Framework и типу данных DBTYPE_WSTR для OLE DB. |
Все данные, полученные из источника данных, преобразуются в тип служб SSAS, указанный в привязке (обычно во время обработки). Если выполнить преобразование невозможно, возникает ошибка (например, при преобразовании String в Int). Обычно среда Business Intelligence Development Studio задает для привязки тип данных, более всего соответствующий исходному типу в источнике данных. Например, типам данных SQL Date, DateTime, SmallDateTime, DateTime2, DateTimeOffset сопоставляется тип данных служб SSAS Date, а типу данных SQL Time — тип данных String.
Привязки для измерений
Каждый атрибут измерения привязан к столбцу в представлении источника данных. Все атрибуты измерения должны относиться к одному источнику данных. Тем не менее атрибуты могут быть привязаны к столбцам из разных таблиц. Связи между таблицами определены в представлении источника данных. В случае если в таблице имеется несколько наборов связей, в представлении источника данных необходимо создать именованный запрос, который будет выступать в роли «псевдонима» таблицы. Выражения и фильтры определяются в представлении источника данных с помощью именованных вычислений и запросов.
Привязки для групп мер, мер и секций
Каждая группа мер имеет следующие привязки по умолчанию.
Группа мер привязана к таблице в представлении источника данных (например MeasureGroup.Source).
Каждая мера привязана к столбцу в этой таблице (например Measure.ValueColumn.Source).
Каждое измерение группы мер имеет набор атрибутов гранулярности, определяющих гранулярность группы мер. Каждый такой атрибут должен быть привязан к столбцу или столбцами в таблице фактов, содержащей ключ атрибута. (Дополнительные сведения об атрибутах гранулярности см. далее в этом разделе, в подразделе «Атрибуты гранулярности группы мер»).
Эти привязки по умолчанию можно выборочно переопределить для каждой секции. Для каждой секции можно задать отдельный источник данных, таблицу, имя запроса или критерий фильтра. Самым распространенным методом секционирования является посекционное переопределение таблицы с использованием одного источника данных. Другие методы представляют собой применение разных фильтров к разным секциям и изменение источника данных.
В представлении источника данных необходимо определить источник данных по умолчанию, тем самым предоставив сведения о схеме, включая подробные сведения о связях. Списки дополнительных таблиц или запросов, заданных на уровне секции, приводить в представлении источника данных необязательно, однако они должны иметь ту же схему, что и таблица по умолчанию, определенная для группы мер, или, по крайней мере, должны содержать все столбцы, которые используются мерами или атрибутами гранулярности. Привязки по умолчанию для меры и атрибута гранулярности нельзя переопределить на уровне секции; предполагается, что это те же столбцы, которые определены для группы мер. Поэтому, если секция использует источник данных, относящийся к другой схеме, запрос TableDefinition, определенный для этой секции, должен иметь результаты в той же схеме, что и группа мер.
Атрибуты гранулярности группы мер
Если гранулярность группы мер соответствует гранулярности, известной в базе данных, и имеется прямая связь таблицы фактов с таблицей измерения, атрибут гранулярности нужно привязать только к соответствующему столбцу или столбцам внешнего ключа в таблице фактов. Например, рассмотрим следующую таблицу фактов и таблицу измерения.
Sales(RequestedDate, OrderedProductID, ReplacementProductID, Qty)
Product(ProductID, ProductName,Category)
Relation: Sales.OrderedProductID -> Product.ProductID
Relation: Sales.ReplacementProductID -> Product.ProductID
Если анализируется заказанный продукт для роли Ordered Product измерения Sales, атрибут гранулярности Product будет связан со столбцом Sales.OrderedProductID.
Однако в некоторых случаях атрибуты GranularityAttributes могут не существовать как столбцы в таблице фактов. Например, атрибуты GranularityAttributes могут не существовать в виде столбцов в следующих условиях.
Гранулярность OLAP менее детализирована, чем гранулярность источника.
Между таблицей фактов и таблицей измерения помещается промежуточная таблица.
Ключ измерения отличается от первичного ключа в таблице измерения.
Во всех этих случаях необходимо определить представление источника данных, чтобы в таблице фактов существовал атрибут гранулярности. Для этого можно создать именованный запрос или вычисляемый столбец.
Например, в приведенных выше таблицах из примера, если гранулярность создается по категориям, можно ввести представление Sales, как показано ниже.
SalesWithCategory(RequestedDate, OrderedProductID, ReplacementProductID, Qty, OrderedProductCategory)
SELECT Sales.*, Product.Category AS OrderedProductCategory
FROM Sales INNER JOIN Product
ON Sales.OrderedProductID = Product.ProductID
В этом случае категория атрибута гранулярности привязана к столбцу SalesWithCategory.OrderedProductCategory.
Миграция из объектов DSO
Объекты DSO 8.0 позволяют повторно привязывать PartitionMeasures. Следовательно, стратегией миграции в этих случаях будет создание соответствующего запроса.
Точно так же невозможно повторно привязать атрибуты измерения внутри секции, хотя объекты DSO 8.0 позволяют выполнять такую повторную привязку. В этих случаях стратегия миграции заключается в определении необходимых именованных запросов в представлении источника данных, чтобы в нем имелись те же таблицы и столбцы для секции, которые используются для измерения. В таких случаях может потребоваться простая миграция, в которой предложение From/Join/Filter будет сопоставлено одному именованному запросу, а не структурированному набору связанных таблиц. Поскольку объекту DSO 8.0 позволяют повторно связывать измерения секций, даже если секция использует тот же источник данных, для миграции может также понадобиться несколько представлений источника данных для одного источника данных.
В объектах DSO 8.0 соответствующие привязки могут выражаться двумя разными путями, в зависимости от применения оптимизированных схем: путем привязки к первичному ключу в таблице измерения или к внешнему ключу в таблице фактов. В языке ASSL эти два способа не различаются.
Тот же подход к привязкам применяется даже к секции, источник данных которой не содержит таблицы измерений, потому что привязка выполняется к столбцу внешнего ключа в таблице фактов, а не к столбцу первичного ключа в таблице измерения.
Привязки для моделей интеллектуального анализа данных
Модель интеллектуального анализа данных является или реляционной, или относится к аналитической обработке в реальном времени (OLAP). Привязки данных для реляционной модели интеллектуального анализа данных значительно отличаются от моделей интеллектуального анализа OLAP.
Привязки для реляционной модели интеллектуального анализа данных
Реляционная модель интеллектуального анализа данных основана на связях, определенных в представлении источника данных для разрешения неоднозначности привязки столбцов к различным источникам данных. В реляционной модели интеллектуального анализа данных привязки данных удовлетворяют следующим правилам.
Каждый столбец невложенной таблицы привязан к столбцу в таблице вариантов или в таблице, связанной с таблицей вариантов (в соответствии со связью «многие к одному» или «один к одному»). Представление источника данных определяет связи между таблицами.
Каждый столбец вложенной таблицы привязан к исходной таблице. Затем столбцы, принадлежащие столбцу вложенной таблицы, привязываются к столбцам этой исходной таблицы или таблицы, связанной с исходной. (К тому же привязка соответствует связи «многие к одному» или «один к одному»). Привязки модели интеллектуального анализа данных не предоставляют путь соединения к вложенной таблице. Вместо этого эти сведения предоставляют связи, определенные в представлении источника данных.
Привязки для модели интеллектуального анализа OLAP
Модели интеллектуального анализа OLAP не имеют аналога представлению источника данных. Поэтому привязки данных должны устранять неоднозначность между столбцами и источниками данных. Например, модель интеллектуального анализа данных может быть основана на кубе Sales, а столбцы — на кубах Qty, Amount и Product Name. С другой стороны, модель интеллектуального анализа данных может быть основана на кубе Product, а столбцы — на кубах Product Name, Product Color и вложенной таблице Sales куба Qty.
В модели интеллектуального анализа OLAP привязки данных удовлетворяют следующим правилам.
Каждый столбец невложенной таблицы привязан к мере в кубе, к атрибуту в измерении этого куба (с указанием CubeDimension для разрешения неоднозначности в случае ролей измерения) или к атрибуту в измерении.
Каждый столбец вложенной таблицы привязан к CubeDimension. То есть он определяет способ перехода от измерения к связанному кубу или (в частном случае вложенных таблиц) от куба к одному из его измерений.
Внешние привязки
Внешние привязки — это привязки, которые выполняются в команде и не сохраняются. Они применяются только во время выполнения конкретной команды. В отличие от них встроенные привязки содержатся в определении объекта языка ASSL и хранятся вместе с этим объектом в метаданных сервера.
Язык ASSL позволяет задавать внешние привязки в команде Process, если это не пакет, или в команде Batch. Если внешние привязки указываются в команде Batch, все привязки, заданные в команде Batch, создают новый контекст привязок, в котором выполняются все команды Process пакета. Новый контекст привязок включает объекты, которые обрабатываются неявно вследствие команды Process.
Если внешние привязки заданы в команде, они переопределяют встроенные привязки, содержащиеся в неизменяемых библиотеках DDL для указанных объектов. Эти обрабатываемые объекты могут включать объект, поименованный непосредственно в команде Process, или другие объекты, обработка которых начинается автоматически, как часть общей работы.
Внешние привязки указываются с помощью включения в команду обработки необязательного объекта коллекции Bindings. Необязательная коллекция Bindings содержит следующие элементы.
Свойство |
Количество элементов |
Тип |
Описание |
|---|---|---|---|
Binding |
От 0 до n |
Binding |
Предоставляет коллекцию новых привязок. |
DataSource |
0-1 |
DataSource |
Заменяет DataSource с сервера, который должен был бы использоваться. |
DataSourceView |
0-1 |
DataSourceView |
Заменяет DataSourceView с сервера, который должен был бы использоваться. |
Все элементы, связанные с внешними привязками, являются необязательными. Для всех неуказанных элементов язык ASSL использует спецификацию, содержащуюся в определении DDL сохраняемого объекта. Указание ключевого слова DataSource или DataSourceView в команде Process необязательно. Если указаны DataSource или DataSourceView, экземпляр этих объектов не создается, а сами они не сохраняются после завершения команды Process.
Определение типа внешней привязки
В пределах внешней коллекции Bindings язык ASSL позволяет создавать коллекцию привязок для нескольких объектов Binding. Каждый объект Binding имеет расширенную ссылку на объект, которая напоминает простую объектную ссылку, но может ссылаться также на второстепенные объекты (например атрибуты измерения и атрибуты группы мер). Такой объект принимает плоский вид, типичный для элемента Object в командах Process, за исключением того, что в нем отсутствуют теги <Object></Object>.
Каждому объекту, для которого задана привязка, соответствует XML-элемент в виде <object>ID (например DimensionID). После идентификации объекта, выполненной настолько точно, насколько позволяет идентификатор <object>ID, находится элемент, для которого задана привязка; как правило, это элемент Source. В общем случае элемент Source является свойством объекта DataItem, представляющего собой вариант привязки к столбцу в атрибуте. В этом случае тег DataItem не указывается, вместо этого нужно задать свойство Source, как при непосредственной привязке столбца.
KeyColumns идентифицируются своим порядковым положением в коллекции KeyColumns. Здесь невозможно задать, например только первый и третий ключевой столбец атрибута, поскольку не существует способа указать, что второй ключевой столбец нужно пропустить. Во внешней привязке для атрибута измерения должны присутствовать все ключевые столбцы.
Элементы Translations хотя и не имеют идентификаторов, семантически определяются по языку. Следовательно, элементы Translations внутри объекта Binding должны включать идентификатор языка.
Еще одним элементом, допускающимся в объекте Binding и не существующим непосредственно в библиотеке DDL, является объект ParentColumnID, который используется во вложенных таблицах для интеллектуального анализа данных. В этом случае необходимо идентифицировать родительский столбец вложенной таблицы, для которого предоставляется привязка.