データ ソースとバインド (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 内のその列にバインドします。 DSV の詳細については、「 多次元モデルのデータ ソース ビュー」を参照してください。

各SQL Server Analysis Services オブジェクトは、独自の方法でデータ ソースにバインドされます。 また、これらのオブジェクトのデータ バインドとデータ ソースの定義は、データバインド オブジェクト (ディメンションなど) の定義と共にインラインで提供することも、個別の定義セットとして不一致で提供することも可能です。

Analysis Services のデータ型

バインドで使用されるデータ型は、SQL Server Analysis Servicesでサポートされているデータ型と一致する必要があります。 SQL Server Analysis Servicesでは、次のデータ型が定義されています。

Analysis Services のデータ型	説明
BigInt	64 ビット符号付き整数。 このデータ型は、Microsoft .NET Framework 内の Int64 データ型と OLE DB 内のDBTYPE_I8データ型にマップされます。
Bool	ブール値です。 このデータ型は、.NET Framework内のブール型と OLE DB 内のDBTYPE_BOOLデータ型にマップされます。
通貨	通貨単位の 1 万分の 1 までの精度を持つ -263 (-922,337,203,685,477.5808) ～ 263-1 (+922,337,203,685,477.5807) の通貨の値です。 このデータ型は、.NET Framework内の Decimal データ型と OLE DB 内のDBTYPE_CYデータ型にマップされます。
Date	倍精度浮動小数点数として保存される日付データです。 整数部分は 1899 年 12 月 30 日からの日数で、小数部分は日の端数です。 このデータ型は、.NET Framework内の DateTime データ型と OLE DB 内のDBTYPE_DATEデータ型にマップされます。
Double	-1.79E +308 ～ 1.79E +308 の範囲の倍精度浮動小数点数です。 このデータ型は、.NET Framework内の Double データ型と OLE DB 内のDBTYPE_R8データ型にマップされます。
Integer	32 ビット符号付き整数。 このデータ型は、.NET Framework内の Int32 データ型と OLE DB 内のDBTYPE_I4データ型にマップされます。
Single	-3.40E +38 ～ 3.40E +38 の範囲の単精度浮動小数点数です。 このデータ型は、.NET Framework内の Single データ型と OLE DB 内のDBTYPE_R4データ型にマップされます。
SmallInt	16 ビット符号付き整数。 このデータ型は、.NET Framework内の Int16 データ型と OLE DB 内のDBTYPE_I2データ型にマップされます。
TinyInt	8 ビット符号付き整数。 このデータ型は、.NET Framework内の SByte データ型と、OLE DB 内のDBTYPE_I1データ型にマップされます。 注: データ ソースに tinyint データ型のフィールドが含まれ、AutoIncrement プロパティが True に設定されている場合、それらのフィールドはデータ ソース ビューで整数に変換されます。
UnsignedBigInt	64 ビット符号なし整数。 このデータ型は、.NET Framework内の UInt64 データ型と OLE DB 内のDBTYPE_UI8データ型にマップされます。
UnsignedInt	32 ビット符号なし整数 このデータ型は、.NET Framework内の UInt32 データ型と OLE DB 内のDBTYPE_UI4データ型にマップされます。
UnsignedSmallInt	16 ビット符号なし整数。 このデータ型は、.NET Framework内の UInt16 データ型と OLE DB 内のDBTYPE_UI2データ型にマップされます。
WChar	Unicode 文字の NULL 終了ストリームです。 このデータ型は、.NET Framework内の String データ型と、OLE DB 内のDBTYPE_WSTRデータ型にマップされます。

データ ソースから受信したすべてのデータは、バインディングで指定された SSAS 型に変換されます (通常は処理中)。 変換を実行できない場合 (たとえば、String から Int への変換など) はエラーが発生します。 SQL Server Data Toolsは、通常、バインディング内のデータ型を、データ ソース内のソースの種類に最も一致するものに設定します。 たとえば、SQL 型 Date、DateTime、SmallDateTime、DateTime2、DateTimeOffset は SSAS 日付にマップされ、SQL 型 Time は String にマップされます。

ディメンションのバインド

ディメンションの各属性は DSV の列にバインドされます。 ディメンションの属性はすべて 1 つのデータ ソースに基づいている必要がありますが、 バインドできるテーブルの列はさまざまです。 テーブル間のリレーションシップは DSV で定義されます。 同じテーブルに対して複数のリレーションシップ セットが存在する場合は、"エイリアス" テーブルとして機能するように DSV に名前付きクエリを導入する必要がある場合があります。 式とフィルターは、DSV で名前付き計算と名前付きクエリを使用して定義されます。

メジャー グループ、メジャー、およびパーティションのバインド

各メジャー グループには次の既定のバインドがあります。

• メジャー グループは DSV のテーブルにバインドされます (たとえば MeasureGroup.Source)。

• 各メジャーはそのテーブルの列にバインドされます (たとえば Measure.ValueColumn.Source)。

• 各メジャー グループのディメンションには、メジャー グループの粒度を定義する 粒度属性 のセットがあります。 これらの各属性を、属性キーが含まれているファクト テーブルの列にバインドする必要があります (粒度属性の詳細については、このトピックの後半の「MeasureGroup 粒度属性」を参照してください)。

これら既定のバインドは、パーティションごとに選択的にオーバーライドできます。 各パーティションは異なるデータ ソース、テーブル名、クエリ名、またはフィルター式を指定できます。 最も一般的なパーティション分割方法では、同じデータ ソースを使用して、パーティションごとにテーブルをオーバーライドします。 その他、パーティションごとに異なるフィルターを適用する方法や、データ ソースを変更する方法もあります。

既定のデータ ソースを DSV で定義して、リレーションシップの詳細などのスキーマ情報を提供する必要があります。 パーティション レベルで指定するその他のテーブルやクエリは、DSV に一覧表示する必要はありませんが、メジャー グループに定義されている既定のテーブルと同じスキーマを含めるか、少なくともメジャーまたは粒度属性で使用される列をすべて含める必要があります。 メジャーと粒度属性ごとの詳細なバインドはパーティション レベルではオーバーライドできません。これらは、メジャー グループに定義されている列と同じ列であると想定されます。 したがって、実際にはパーティションでスキーマの異なるデータ ソースを使用している場合、そのパーティションに定義されている TableDefinition クエリが、メジャー グループで使用しているスキーマと同じスキーマになる必要があります。

MeasureGroup 粒度属性

メジャー グループの粒度がデータベースの既知の粒度と一致し、ファクト テーブルからディメンション テーブルへの直接的なリレーションシップがある場合は、ファクト テーブルの適切な外部キー列に粒度属性をバインドするだけです。 たとえば、次のファクト テーブルとディメンション テーブルについて検討します。

Sales(RequestedDate, OrderedProductID, ReplacementProductID, Qty)

Product(ProductID, ProductName,Category)

``

Relation: Sales.OrderedProductID -> Product.ProductID

Relation: Sales.ReplacementProductID -> Product.ProductID

``

注文製品別に分析する場合、Sales ディメンション ロールの Ordered Product において、Product 粒度属性は Sales.OrderedProductID にバインドされます。

ただし、 GranularityAttributes がファクト テーブルの列として存在しない場合もあります。 たとえば、次のような状況では GranularityAttributes が列として存在しない可能性があります。

• OLAP の粒度がソースの粒度よりも粗い。

• ファクト テーブルとディメンション テーブルの間に中間テーブルが介在する。

• ディメンション キーがディメンション テーブルの主キーと異なる。

このような場合には、ファクト テーブルに GranularityAttributes が存在するように、DSV を定義する必要があります。 たとえば、名前付きクエリや計算列を使用します。

上記と同じサンプル テーブルで、粒度がカテゴリ別であれば、Sales のビューを使用できます。

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 にバインドされます。

Decision Support オブジェクトからの移行

Decision Support オブジェクト (DSO) 8.0 では、 PartitionMeasures を再バインドできます。 したがって、このような場合の移行方法として、適切なクエリを作成します。

同様に、パーティション内でディメンション属性を再バインドすることはできませんが、DSO 8.0 ではこの再バインドも可能です。 このような場合の移行方法として、ディメンションで使用されているテーブルや列と同じものがパーティションの DSV に存在するように、DSV で必要な名前付きクエリを定義します。 場合によっては、構造化された関連テーブル セットではなく、1 つの名前付きクエリに From/Join/Filter 句をマップするという単純な移行方法を採用する必要があります。 DSO 8.0 では、パーティションが同じデータ ソースを使用していても PartitionDimensions を再バインドできるので、移行には同じデータ ソースの複数の DSV が必要になる場合もあります。

DSO 8.0 では、対応するバインドを 2 とおりの方法で表すことができます。つまり、最適化されたスキーマを使用しているかどうかによって、ディメンション テーブルの主キーにバインドするか、ファクト テーブルの外部キーにバインドします。 ASSL では、これらの方法が区別されません。

ディメンション テーブルが含まれていないデータ ソースを使用しているパーティションでも、同じバインド方法が適用されます。これは、ディメンション テーブルの主キー列ではなく、ファクト テーブルの外部キー列にバインドされるためです。

マイニング モデルのバインド

マイニング モデルはリレーショナルまたは OLAP です。 リレーショナル マイニング モデルのデータ バインドは、OLAP マイニング モデルのバインドとは大きく異なります。

リレーショナル マイニング モデルのバインド

リレーショナル マイニング モデルは、DSV で定義されているリレーションシップを利用して、どの列をどのデータ ソースにバインドするかに関するあいまいさを解決します。 リレーショナル マイニング モデルのデータ バインドは、次のルールに従います。

• 入れ子になっていないテーブルの各列は、多対一または一対一のリレーションシップに従って、ケース テーブルまたはケース テーブルに関連するテーブルの列にバインドされます。 DSV はテーブル間のリレーションシップを定義します。

• 入れ子になったテーブルの各列はソース テーブルにバインドされます。 入れ子になったテーブルの列が所有している列は、そのソース テーブルまたはソース テーブルに関連するテーブルの列にバインドされます (この場合もバインドは多対一または一対一のリレーションシップに従います)。マイニング モデルのバインドは、入れ子になったテーブルの結合パスを提供しません。 この情報は、DSV で定義されているリレーションシップによって提供されます。

OLAP マイニング モデルのバインド

OLAP マイニング モデルには DSV に相当するものがありません。 したがって、データ バインドによって、列とデータ ソースの間のあいまいさを排除する必要があります。 たとえば、マイニング モデルが Sales キューブに基づき、列が Qty、Amount、および Product Name に基づくことが可能です。 または、マイニング モデルが Product に基づき、列が Product Name、Product Color、および Sales Qty の入れ子になったテーブルに基づくことも可能です。

OLAP マイニング モデルのデータ バインドは、次のルールに従います。

• 入れ子になっていないテーブルの各列はキューブ上のメジャー、そのキューブのディメンション上の属性 (ディメンション ロールの場合は、あいまいさを排除するために CubeDimension を指定)、またはディメンション上の属性にバインドされます。

• 入れ子になったテーブルの各列は CubeDimensionにバインドされます。 つまり、ディメンションから関連キューブまで、またはキューブからそのディメンションの 1 つまで (入れ子になったテーブルでは一般的ではありません)、移動する方法を定義します。

不一致バインド

不一致バインドを使用すると、コマンドが実行されている間、既存のデータ バインドを一時的に変更することができます。 不一致バインドとは、コマンドに含まれ、持続しないバインドのことです。 不一致バインドは、特定のコマンドの実行中にのみ適用されます。 一方、インライン バインドは 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 に含まれている指定が使用されます。 Process コマンドの DataSource または DataSourceView は省略可能です。 DataSource または DataSourceView が指定されている場合は、インスタンス化されず、 Process コマンドの完了後は持続しません。

不一致バインド型の定義

ASSL では、不一致 Bindings コレクション内で、複数のオブジェクトのバインドのコレクションである、各 Bindingを使用できます。 各 Binding には拡張オブジェクト参照があります。これはオブジェクト参照に似ていますが、マイナー オブジェクト (たとえばディメンション属性やメジャー グループ属性) の参照も可能です。 このオブジェクトは、Object/Object> タグが存在しない点<を除き、Process コマンドの Object>< 要素の一般的なフラットな形式をとります。

バインドが指定されている各オブジェクトは、フォーム <オブジェクト>ID ( DimensionID など) の XML 要素によって識別されます。 フォーム < オブジェクト ID で可能な限り具体的にオブジェクト>を識別した後、バインディングが指定されている要素 (通常は Source) を識別します。 一般に、属性の列バインドの場合のように、 Source は DataItemのプロパティです。 この場合は、 DataItem タグを指定しないで、バインドする列に直接存在するかのように Source プロパティを指定するだけです。

KeyColumns は、 KeyColumns コレクション内の順序によって識別されます。 たとえば、属性の最初と 3 番目のキー列のみを指定することはできません。2 番目のキー列がスキップされることを示す方法がないからです。 不一致バインドでは、ディメンション属性のキー列のすべてが存在する必要があります。

Translationsには ID がありませんが、その言語によって意味が識別されます。 したがって、 Binding 内の Translations にその言語識別子を含める必要があります。

DDL に直接存在しない Binding 内で許容されるもう 1 つの要素は、 ParentColumnIDです。これはデータ マイニングの入れ子になったテーブルに使用されます。 この場合は、バインドを提供する入れ子になったテーブルの親列を指定する必要があります。