データ ソースとバインド (ASSL)
キューブ、ディメンション、その他の Microsoft SQL Server 2005 Analysis Services (SSAS) オブジェクトはデータ ソースにバインドできます。データ ソースとは次のいずれかのオブジェクトです。
- リレーショナル データ ソース
- 行セット (またはチャプタ行セット) を出力する SQL Server 2005 Analysis Services (SSAS) パイプライン
データ ソースを表す方法は、データ ソースの種類によって異なります。たとえば、リレーショナル データ ソースは接続文字列によって区別されます。データ ソースの詳細については、「データ ソース (Analysis Services)」を参照してください。
使用しているデータ ソースにかかわらず、データ ソース ビュー (DSV) にはデータ ソースのメタデータが含まれています。したがって、キューブまたは他の Analysis Services オブジェクトのバインドは DSV へのバインドとして表されます。これらのバインドに、論理オブジェクト (ビュー、計算される列、データ ソースに物理的に存在しないリレーションシップなど) へのバインドが含まれる場合もあります。DSV を使用して論理オブジェクトをバインドする機能は、SQL Server 2005 で新たに追加されました。たとえば、Microsoft SQL Server 2000 では、OLAP メジャーがそのデータ ソースとして式を指定しましたが、SQL Server 2005 では、Analysis Services が式をカプセル化する計算される列を DSV に追加し、対応する OLAP メジャーを DVS の列にバインドします。DSV の詳細については、「データ ソース ビュー (Analysis Services)」を参照してください。
データ ソースへのバインド方法は各 Analysis Services オブジェクトによって異なります。また、これらのオブジェクトのデータ バインドとデータ ソースの定義は、データバインド オブジェクト (ディメンションなど) の定義と共にインラインで提供することも、個別の定義セットとして不一致で提供することも可能です。
ディメンションのバインド
ディメンションの各属性は 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 ディメンション ロールの Ordred 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 には拡張オブジェクト参照があります。これはオブジェクト参照に似ていますが、マイナ オブジェクト (たとえばディメンション属性やメジャー グループ属性) の参照も可能です。このオブジェクトは、Process コマンドの Object 要素に特有のフラット形式ですが、<Object></Object> タグはありません。
バインドが指定されている各オブジェクトは <object>ID 形式の XML 要素によって指定されます (たとえば DimensionID)。<object>ID 形式でできるだけ具体的にオブジェクトを指定した後、バインドを指定する要素を指定します。これは通常 Source です。一般に、属性の列バインドの場合のように、Source は DataItem のプロパティです。この場合は、DataItem タグを指定しないで、バインドする列に直接存在するかのように Source プロパティを指定するだけです。
KeyColumns は、KeyColumns コレクション内の順序によって識別されます。たとえば、属性の最初と 3 番目のキー列のみを指定することはできません。2 番目のキー列がスキップされることを示す方法がないからです。不一致バインドでは、ディメンション属性のキー列のすべてが存在する必要があります。
Translations には ID がありませんが、その言語によって意味が識別されます。したがって、Binding 内の Translations にその言語識別子を含める必要があります。
DDL に直接存在しない Binding 内で許容されるもう 1 つの要素は、ParentColumnID です。これはデータ マイニングの入れ子になったテーブルに使用されます。この場合は、バインドを提供する入れ子になったテーブルの親列を指定する必要があります。