データ ソースとバインド (Analysis Services - 多次元データ)

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

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

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

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

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

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

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

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

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

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

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

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

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 です。これはデータ マイニングの入れ子になったテーブルに使用されます。この場合は、バインドを提供する入れ子になったテーブルの親列を指定する必要があります。