Page History
...
| Table of Contents | ||
|---|---|---|
|
粒度
| Styleclass | ||
|---|---|---|
| ||
親子構造を持つ業務データベースにおいて、粒度の相違は珍しいことではありません。たとえば、受注システムにおいて、個々の製品レベルでなく、その注文全体に対してのみ送料を計算できるというような場合です。そのようなケースでも、デザイナーはまず、すべてのデータを最も低いレベルに落として扱うことを考えます。操作上は上位レベルに存在するものとして扱うものを含めて、すべてのレコードが実は下位のレベルに存在するよう、下の図のようにデータの親子関係の平準化に努めます。この作業はアロケーティング（配分）と呼ばれます。親レベルのデータを下位の子レベルに配分することで、一般的に要求される、製品そのものを含むすべての受注データを、あらゆる角度でスライスし、切り刻み、また上位のレベルのデータに組み上げることが可能になります。親子構造を持つ業務データベースにおいて、粒度の相違は珍しいことではありません。例えば、受注システムにおいて、個々の製品レベルではなく、注文全体にのみ送料を適用できるとします。このような場合、設計者はまず、すべてのデータを最も低いレベルまで落とし込んでください。以下の図に示されるように、業務上は上位の親レベルとして扱うデータも含めて、すべてのロウ（行）を子レベルに落とし込んで扱うことにより、親子関係の平準化に努めます。この処理は、アロケーティング（配分）と呼ばれます。一般的に求められる、製品を含むすべての受注データを、あらゆる角度から掘り下げ、まとめるためには、親レベルのデータを子レベルに配分することが重要になります。
送料や他のヘッダーレベルのデータをうまく配分することができない場合、それらは注文全体に対して集約されたテーブルに含まれることになります。個々の高水準テーブルには利便性から生じた固有のデータが存在しますが、そうでないものに関しては、できるだけ下位に配分するようにします。こうした配分がなされていないと、製品がヘッダーレベルのテーブルで特定されえず、ヘッダーレベルから製品などのデータを検索することができなくなってしまいます。データを最も低いレベルに割り当てることができれば、この問題は生じません。送料や他のヘッダーレベルのデータをうまく配分することができない場合は、注文全体の集約テーブルに含めなくてはいけません。個々の高レベルファクトテーブルには、固有のユーザビリティーの問題があるため、可能な限り、配分へのアプローチをしてください。配分をしない場合は、ヘッダーファクトテーブル内で製品を特定することができないため、製品ごとにヘッダーファクトを検索することができなくなります。最も低いレベルまで、データを配分することができれば、この問題は解消されます。
また、1つのテーブルの中で複数の要約レベル（たとえば、注文とその詳細のデータ）を混在させてはいけません。より高水準のデータを配分するか、要約レベルの違うデータを取り扱う2つのテーブルを作る必要があります。配分は優れたアプローチであり、財務管理やビジネスチーム（データウェアハウスチームを除きます）は、まずこれに労力を傾注するべきです。単一のファクトテーブル内で、データの粒度（例えば、注文と注文ライン）を混在させてはいけません。その代わりに、高レベルのデータをより詳細なレベルにするか、粒度を制御するために、ファクトテーブルをふたつに分けてください。配分は推奨されるアプローチであり、ファイナンスやビジネスチーム（データウェアハウスチームではなく）が、先陣を切って注力するのが最適です。
インデックス
| Styleclass | ||
|---|---|---|
| ||
トランザクションのためのインデックスが、データベースシステムの主要なキーから構築されている一方で、レポート作成のためのインデックスは、複数の多次元的な属性から構築されています。これは、基幹データベースのサイズと複雑さに応じて、データアーキテクチャ戦略の全体を決定する要求と衝突を生み出します。その結果として、レポート作成を最適化するためには、基幹テーブルからデータを抽出し、データマートやOLAPキューブの形式でレポーティングに適したテーブルに投入しなくてはいけません。
外部結合
| Styleclass | ||
|---|---|---|
| ||
たとえば、以下の結合は動作します：例えば、以下の場合は動作します。
CASE_PARTIES inner join CASE STAGES outer join TEAMSが、以下は動作しません：
しかし、以下の場合は動作しません。
TEAMS outer join CASE_PARTIES inner join CASE STAGESこうした複雑な結合を必要とする場合には、仮想テーブルや、SQLビュー、あるいはデータベース内のハードコード化されたビューを使わなければならないかもしれません。上の例は単純なカッコの挿入で解決しますが、たとえば以下のような複雑な結合を定義することはできません：
このような複雑な結合が必要な場合は、仮想テーブル、SQLビュー、またはデータベース上に直接定義されたビューを使用しなくてはいけません。上記のビューは、単純にカッコを挿入するだけで動作するようになりますが、Yellowfinでは、例えば以下のような複雑な結合を定義することはできません。
A inner join B outer join (C inner join D) outer join E outer join (F inner join G outer join H)
| horizontalrule |
|---|
| Styleclass | ||
|---|---|---|
| ||