データ ソースとバインド (SSAS 多次元)

キューブ、ディメンション、およびその他の Analysis Services オブジェクトは、データ ソースにバインドできます。 データ ソースには、次のいずれかのオブジェクトを指定できます。

• リレーショナル データ ソース。

• 行セット (またはチャプター化された行セット) を出力する Analysis Services パイプライン。

データ ソースを表現する方法は、データ ソースの種類によって異なります。 たとえば、リレーショナル データ ソースは接続文字列によって区別されます。 データ ソースの詳細については、「 多次元モデルのデータ ソース」を参照してください。

使用されているデータ ソースに関係なく、データ ソース ビュー (DSV) にはデータ ソースのメタデータが含まれます。 したがって、キューブまたは他の Analysis Services オブジェクトのバインドは、DSV へのバインドとして表されます。 これらのバインドには、ビュー、計算列、データ ソースに物理的に存在しないリレーションシップなどの論理オブジェクト オブジェクトへのバインドを含めることができます。 Analysis Services は、式を DSV にカプセル化する計算列を追加し、対応する OLAP メジャーを DSV 内のその列にバインドします。 DSV の詳細については、「 多次元モデルのデータ ソース ビュー」を参照してください。

各 Analysis Services オブジェクトは、独自の方法でデータ ソースにバインドされます。 さらに、これらのオブジェクトのデータ バインディングとデータ ソースの定義は、データバインド オブジェクトの定義 (ディメンションなど) を使用してインラインで提供することも、個別の定義セットとしてアウトオブラインで提供することもできます。

Analysis Services データ型

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

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

ディメンション用の結合

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

MeasureGroup、Measures、およびパーティションのバインド

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

• メジャーグループは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

``

注文済み製品で分析する場合、受注製品 on Sales ディメンション ロールの Product 粒度属性は Sales.OrderedProductID にバインドされます。

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

• OLAP の粒度は、ソースの粒度よりも粗くなります。

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

• ディメンション キーは、ディメンション テーブルの主キーと同じではありません。

いずれの場合も、ファクト テーブルに GranularityAttributes が存在するように 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 にバインドされます。

デシジョン サポート オブジェクトからの移行

Decision Support Objects (DSO) 8.0 では、 PartitionMeasures をリバインドできます。 そのため、このような場合の移行戦略は、適切なクエリを構築することです。

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

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

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

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

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

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

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

• 入れ子になっていない各テーブル列は、ケーステーブル上の列またはケーステーブルと関連するテーブルのいずれかに関連付けられています（多対一または1対1の関係に従って）。 DSV は、テーブル間のリレーションシップを定義します。

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

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

OLAP マイニング モデルには DSV に相当するものがありません。 そのため、データ バインディングでは、列とデータ ソースの間であいまいさが解消される必要があります。 たとえば、マイニング モデルは Sales キューブに基づき、列は Qty、Amount、Product Name に基づくことができます。 または、マイニング モデルは Product に基づいて作成でき、列は製品名、Product Color、および Sales Qty の入れ子になったテーブルに基づくことができます。

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

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

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

ライン外バインディング

行外バインディングを使用すると、コマンドの期間中、既存のデータ バインディングを一時的に変更できます。 行外バインディングは、コマンドに含まれるバインドを指し、永続化されません。 行外バインディングは、その特定のコマンドの実行中にのみ適用されます。 これに対し、インライン バインドは ASSL オブジェクト定義に含まれており、サーバー メタデータ内のオブジェクト定義と共に保持されます。

ASSL を使用すると、 Process コマンド (バッチ内にない場合)、または Batch コマンドでアウトオブライン バインディングを指定できます。 Batch コマンドで行外バインディングが指定されている場合、Batch コマンドで指定されたすべてのバインディングによって、バッチのすべてのProcessコマンドが実行される新しいバインディング コンテキストが作成されます。 この新しいバインド コンテキストには、 Process コマンドのために間接的に処理されるオブジェクトが含まれます。

コマンドで行外バインディングを指定すると、指定したオブジェクトの永続化された DDL に含まれるインライン バインドがオーバーライドされます。 これらの処理されたオブジェクトには、 Process コマンドで直接名前が付けられたオブジェクトが含まれる場合もあれば、処理の一部として自動的に開始される他のオブジェクトも含まれる場合があります。

アウトオブライン バインディングは、オプションの Bindings コレクション オブジェクトを処理コマンドと共に含めることで指定されます。 省略可能な Bindings コレクションには、次の要素が含まれています。

行外バインディングに関連するすべての要素は省略可能です。 指定されていない要素の場合、ASSL は永続化されたオブジェクトの DDL に含まれる仕様を使用します。 Process コマンドでのDataSourceまたはDataSourceViewの指定は省略可能です。 DataSourceまたはDataSourceViewを指定した場合、インスタンス化されず、Process コマンドが完了した後も保持されません。

行外バインディング型の定義

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

バインドが指定されている各オブジェクトは、フォーム <object>ID (たとえば、 DimensionID) の XML 要素によって識別されます。 フォーム <object>ID で可能な限りオブジェクトを識別したら、バインディングが指定されている要素を識別します。通常は Source。 注意すべき一般的なケースは、 Source が DataItemのプロパティであり、属性内の列バインドの場合です。 この場合、 DataItem タグは指定しません。代わりに、バインドする列に直接存在するかのように、 Source プロパティを指定するだけです。

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

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

DDL に直接存在しない Binding 内で許可される 1 つの追加要素が ParentColumnID です。これは、データ マイニング用の入れ子になったテーブルに使用されます。 この場合、バインドが提供されている入れ子テーブルにおいて、どの親列かを特定することが必要です。