Page History

...

...

粒度

When designing a view you will have to consider the level of granularity of the view.

It is quite common in parent-child transaction databases to encounter facts of differing granularity. On an order, for example, there may be a shipping charge that applies to the entire order that isn't available at the individual product-level line item in the operational system. The designer's first response should be to try to force all the facts down to the lowest level. We strive to flatten the parent-child relationship so that all the rows are at the child level, including facts that are captured operationally at the higher parent level, as illustrated below. This procedure is broadly referred to as allocating. Allocating the parent order facts to the child line-item level is critical if we want the ability to slice and dice and roll up all order facts by all dimensions, including product, which is a common requirement.

If the shipping charges and other header-level facts cannot be allocated successfully, then they must be presented in an aggregate table for the overall order. We clearly prefer the allocation approach, if possible, because the separate higher-level fact table has some inherent usability issues. Without allocations, we'd be unable to explore header facts by product because the product isn't identified in a header-grain fact table. If we are successful in allocating facts down to the lowest level, the problem goes away.

We shouldn't mix fact granularities (for example, order and order line facts) within a single fact table. Instead, we need to either allocate the higher-level facts to a more detailed level or create two separate fact tables to handle the differently grained facts. Allocation is the preferred approach. Optimally, a finance or business team (not the data warehouse team) spearheads the allocation effort.

...

ビューを設計する場合、そのビューが持つ粒度に関して考慮しなければなりません。 

親子構造を持つ業務データベースにおいて、粒度の相違は珍しいことではありません。たとえば、受注システムにおいて、個々の製品レベルでなく、その注文全体に対してのみ送料を計算できるというような場合です。そのようなケースでも、デザイナーはまず、すべてのデータを最も低いレベルに落として扱うことを考えます。操作上は上位レベルに存在するものとして扱うものを含めて、すべてのレコードが実は下位のレベルに存在するよう、下の図のようにデータの親子関係の平準化に努めます。この作業はアロケーティング（配分）と呼ばれます。親レベルのデータを下位の子レベルに配分することで、一般的に要求される、製品そのものを含むすべての受注データを、あらゆる角度でスライスし、切り刻み、また上位のレベルのデータに組み上げることが可能になります。

送料や他のヘッダーレベルのデータをうまく配分することができない場合、それらは注文全体に対して集約されたテーブルに含まれることになります。個々の高水準テーブルには利便性から生じた固有のデータが存在しますが、そうでないものに関しては、できるだけ下位に配分するようにします。こうした配分がなされていないと、製品がヘッダーレベルのテーブルで特定され得ず、ヘッダーレベルから製品などのデータを検索することができなくなってしまいます。データを最も低いレベルに割り当てることができれば、この問題は生じません。

また、1つのテーブルの中で複数の要約レベル（たとえば、注文とその詳細のデータ）を混在させてはいけません。より高水準のデータを配分するか、要約レベルの違うデータを取り扱う2つのテーブルを作る必要があります。配分は優れたアプローチであり、財務管理やビジネスチーム（データウェアハウスチームを除きます）は、まずこれに労力を傾注するべきです。

インデックス

A common issue when designing a reporting view for an OLTP Database is that the indexes used for managing transactions are inappropriate for report writing.
Whereas an index for transactions may be on the primary key for reporting these may be on multiple dimensional attributes. This can create a conflict of requirements that will determine your overall data architecture strategy depending on the size and complexity of your underlying database. As a result you may have to extract data from your underlying tables into specific reporting tables in the form of a data mart or OLAP cube to ensure optimised reporting.

...

OLTPデータベースに対するレポートビューを設計する場合によく問題になるのは、トランザクションを管理するためのインデックスがレポート作成には使いにくいということです。
トランザクションのためのインデックスがデータベースシステムの基本的なキーから構築されているのに対し、レポート作成のためのそれはより多元的かつ具体的なデータで構築されている必要があります。この問題は基幹データベースのサイズと複雑さとあいまって、データ構築を決定する要件の対立を引き起こしかねません。結果として、より良いレポートを出力するために、基幹データベースのテーブルからデータマートやOLAPキューブの形でデータを引き出す必要が生じるでしょう。 

外部結合（Outer Join）

When creating a join with inner joins the "direction" of the join is not relevant, but when creating an outer join the direction does matter. A join rule in Yellowfin is that an inner join cannot reside on the discretionary end of an outer join.

内部結合（Inner Join） を使った結合では、その「方向」は問題になりません。しかし、外部結合（Outer Join）では方向が問題になります。Yellowfinの結合ルールでは、内部結合（Inner Join）が外部結合（Outer Join）の終端となることはできません。

たとえば、以下の結合は動作します：For example this will work:
CASE_PARTIES inner join CASE STAGES outer join TEAMS

が、以下は動作しません：But this will not work:
TEAMS outer join CASE_PARTIES inner join CASE STAGES

こうした複雑な結合を必要とする場合には、仮想テーブルや、SQLビュー、あるいはデータベース内のハードコード化されたビューを使わなければならないかもしれません。上の例は単純なカッコの挿入で解決しますが、たとえば以下のような複雑な結合を定義することはできません：If you require complex joins like this you may have to use a virtual table, a SQL view or a hard coded view on the database. Even though the view above would only require simple insertion of brackets, Yellowfin does not cater for complex nested joins such as:
A inner join B outer join (C inner join D) outer join E outer join (F inner join G outer join H)