OBIEE –スキーマ

スキーマは、データベース全体の論理的な記述です。これには、関連するすべてのデータ項目と集計を含むすべてのタイプのレコードの名前と説明が含まれます。データベースと同じように、DWもスキーマを維持する必要があります。データベースはリレーショナルモデルを使用しますが、DWはスター、スノーフレーク、ファクトコンステレーションスキーマ（ギャラクシースキーマ）を使用します。

スタースキーマ

スタースキーマには、1つのファクトテーブルのみに結合された非正規化形式の複数のディメンションテーブルがあります。これらのテーブルは、分析目的のビジネス要件を満たすために論理的な方法で結合されます。これらのスキーマは、BIレポートツールを使用してレポートを作成するために使用される多次元構造です。

スタースキーマのディメンションには一連の属性が含まれ、ファクトテーブルにはすべてのディメンションと測定値の外部キーが含まれます。

上記のスタースキーマでは、中央にファクトテーブル「SalesFact」があり、主キーを使用して4つのディメンションテーブルに結合されています。ディメンションテーブルはこれ以上正規化されず、このテーブルの結合はDWではスタースキーマと呼ばれます。

ファクトテーブルには、メジャー値-dollar_soldおよびunits_soldも含まれています。

雪片スキーマ

Snowflakesスキーマには、1つのファクトテーブルのみに結合された正規化された形式の複数のディメンションテーブルがあります。これらのテーブルは、分析目的のビジネス要件を満たすために論理的な方法で結合されます。

StarスキーマとSnowflakesスキーマの唯一の違いは、ディメンションテーブルがさらに正規化されることです。正規化により、データが追加のテーブルに分割されます。Snowflakeスキーマの正規化により、情報を失うことなくデータの冗長性が減少するため、保守が容易になり、ストレージスペースを節約できます。

上記のSnowflakesスキーマの例では、ストレージスペースを節約するためにProductテーブルとCustomerテーブルがさらに正規化されています。場合によっては、正規化されたテーブルで行を直接処理する必要があるクエリを実行するときにパフォーマンスが最適化されるため、プライマリディメンションテーブルの行は処理されず、スキーマの正規化されたテーブルに直接送られます。

粒度

テーブルの粒度は、テーブルに格納されている情報のレベルを表します。データの粒度が高いということは、データがトランザクションレベルまたはその近くにあることを意味し、より詳細になります。粒度が低いということは、データの情報レベルが低いことを意味します。

ファクトテーブルは通常、低レベルの粒度で設計されます。これは、ファクトテーブルに格納できる最低レベルの情報を見つける必要があることを意味します。日付ディメンションでは、粒度レベルは年、月、四半期、期間、週、および日である可能性があります。

粒度を定義するプロセスは、2つのステップで構成されます-

• 含まれる寸法の決定。
• 情報の各次元の階層を配置する場所を決定します。

ゆっくりと変化する寸法

ゆっくりと変化するディメンションは、時間の経過とともに属性の値が変化することを意味します。これは、DWの一般的な概念の1つです。

例

AndyはXYZIncの従業員です。彼は2015年7月にニューヨーク市に最初に配置されました。従業員ルックアップテーブルの元のエントリには、次のレコードがあります。

従業員ID	10001
名前	アンディ
ロケーション	ニューヨーク

後日、彼はカリフォルニア州ロサンゼルスに転居しました。XYZ Inc.は、この変更を反映するために、従業員テーブルをどのように変更する必要がありますか？

これは「ゆっくりと変化する次元」の概念として知られています。

このタイプの問題を解決するには3つの方法があります-

解決策1

新しいレコードが元のレコードを置き換えます。古いレコードの痕跡はありません。

ゆっくりと変化する次元では、新しい情報は単に元の情報を上書きします。言い換えれば、履歴は保持されません。

従業員ID	10001
名前	アンディ
ロケーション	カリフォルニア州ロサンゼルス

• Benefit −これは、古い情報を追跡する必要がないため、緩やかに変化するディメンションの問題を処理する最も簡単な方法です。

• Disadvantage −すべての履歴情報が失われます。

• Use −ソリューション1は、DWが履歴情報を追跡する必要がない場合に使用する必要があります。

解決策2

新しいレコードが従業員ディメンションテーブルに入力されます。したがって、従業員のAndyは2人として扱われます。

新しい情報を表すために新しいレコードがテーブルに追加され、元のレコードと新しいレコードの両方が表示されます。新しいレコードは、次のように独自の主キーを取得します-

従業員ID	10001	10002
名前	アンディ	アンディ
ロケーション	ニューヨーク	カリフォルニア州ロサンゼルス

• Benefit −この方法では、すべての履歴情報を保存できます。

• Disadvantage−テーブルのサイズが速くなります。テーブルの行数が非常に多い場合、テーブルのスペースとパフォーマンスが問題になる可能性があります。

• Use − DWが履歴データを保持する必要がある場合は、ソリューション2を使用する必要があります。

解決策3

従業員ディメンションの元のレコードは、変更を反映するように変更されます。

特定の属性を示す2つの列があり、1つは元の値を示し、もう1つは新しい値を示します。現在の値がいつアクティブになるかを示す列もあります。

従業員ID	名前	元の場所	新しい場所	移動日
10001	アンディ	ニューヨーク	カリフォルニア州ロサンゼルス	2015年7月

• Benefits−新しい情報が更新されるため、これによってテーブルのサイズが大きくなることはありません。これにより、履歴情報を保持できます。

• Disadvantage −このメソッドは、属性値が複数回変更された場合にすべての履歴を保持するわけではありません。

• Use −ソリューション3は、DWが履歴変更の情報を保持する必要がある場合にのみ使用する必要があります。

正規化

正規化は、情報を失うことなく、テーブルを冗長性の少ない小さなテーブルに分解するプロセスです。したがって、データベースの正規化は、データベースの属性とテーブルを整理して、データの冗長性（重複データ）を最小限に抑えるプロセスです。

正規化の目的

• 一貫性を向上させるために、特定のタイプのデータ（冗長性/レプリケーション）を排除するために使用されます。

• オブジェクトタイプに対応するテーブルを簡略化された形式で保持することにより、将来の情報ニーズを満たすための最大限の柔軟性を提供します。

• より明確で読みやすいデータモデルを生成します。

利点

• データの整合性。
• データの整合性を強化します。
• データの冗長性と必要なスペースを削減します。
• 更新コストを削減します。
• アドホッククエリへの応答における最大の柔軟性。
• ブロックあたりの行の総数を減らします。

短所

複数の正規化されたテーブルから関連データを取得するには結合を実行する必要があるため、データベース内のクエリのパフォーマンスが低下します。

複数のテーブル間で適切な結合を実行するには、データモデルを理解する必要があります。

例

上記の例では、緑のブロック内のテーブルは、赤のブロック内のテーブルの正規化されたテーブルを表しています。緑のブロックのテーブルは冗長性が低く、情報を失うことなく行数も少なくなっています。