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