粒度
ビューを設計する場合、そのビューが持つ粒度に関して考慮しなければなりません。親子構造を持つ業務データベースにおいて、粒度の相違は珍しいことではありません。たとえば、受注システムにおいて、個々の製品レベルでなく、その注文全体に対してのみ送料を計算できるというような場合です。そのようなケースでも、デザイナーはまず、すべてのデータを最も低いレベルに落として扱うことを考えます。操作上は上位レベルに存在するものとして扱うものを含めて、すべてのレコードが実は下位のレベルに存在するよう、下の図のようにデータの親子関係の平準化に努めます。この作業はアロケーティング（配分）と呼ばれます。親レベルのデータを下位の子レベルに配分することで、一般的に要求される、製品そのものを含むすべての受注データを、あらゆる角度でスライスし、切り刻み、また上位のレベルのデータに組み上げることが可能になります。
送料や他のヘッダーレベルのデータをうまく配分することができない場合、それらは注文全体に対して集約されたテーブルに含まれることになります。個々の高水準テーブルには利便性から生じた固有のデータが存在しますが、そうでないものに関しては、できるだけ下位に配分するようにします。こうした配分がなされていないと、製品がヘッダーレベルのテーブルで特定されえず、ヘッダーレベルから製品などのデータを検索することができなくなってしまいます。データを最も低いレベルに割り当てることができれば、この問題は生じません。
また、1つのテーブルの中で複数の要約レベル（たとえば、注文とその詳細のデータ）を混在させてはいけません。より高水準のデータを配分するか、要約レベルの違うデータを取り扱う2つのテーブルを作る必要があります。配分は優れたアプローチであり、財務管理やビジネスチーム（データウェアハウスチームを除きます）は、まずこれに労力を傾注するべきです。
インデックス
OLTPデータベースに対するレポートビューを設計する場合によく問題になるのは、トランザクションを管理するためのインデックスがレポート作成には使いにくいということです。トランザクションのためのインデックスがデータベースシステムの基本的なキーから構築されているのに対し、レポート作成のためのそれはより多元的かつ具体的なデータで構築されている必要があります。この問題は基幹データベースのサイズと複雑さとあいまって、データ構築を決定する要件の対立を引き起こしかねません。結果として、より良いレポートを出力するために、基幹データベースのテーブルからデータマートやOLAPキューブの形でデータを引き出す必要が生じるでしょう。
外部結合
内部結合を使った結合では、その「方向」は問題になりません。しかし、外部結合では方向が問題になります。Yellowfinの結合ルールとして、外部結合の終端に内部結合を設定することはできません。たとえば、以下の結合は動作します：
CASE_PARTIES inner join CASE STAGES outer join TEAMS
が、以下は動作しません：
TEAMS outer join CASE_PARTIES inner join CASE STAGES
こうした複雑な結合を必要とする場合には、仮想テーブルや、SQLビュー、あるいはデータベース内のハードコード化されたビューを使わなければならないかもしれません。上の例は単純なカッコの挿入で解決しますが、たとえば以下のような複雑な結合を定義することはできません：
A inner join B outer join (C inner join D) outer join E outer join (F inner join G outer join H)