Obiee-schema
OBIEE –スキーマ
スキーマは、データベース全体の論理的な説明です。 関連するすべてのデータ項目と集計を含む、すべてのタイプのレコードの名前と説明が含まれます。 データベースと同様に、DWはスキーマを維持する必要もあります。 データベースはリレーショナルモデルを使用し、DWはStar、Snowflake、およびFact Constellationスキーマ（Galaxyスキーマ）を使用します。
スタースキーマ
スタースキーマには、1つのファクトテーブルのみに結合される非正規化形式の複数のディメンションテーブルがあります。 これらのテーブルは、分析目的のビジネス要件を満たすために論理的に結合されます。 これらのスキーマは、BIレポートツールを使用してレポートを作成するために使用される多次元構造です。
スタースキーマのディメンションには一連の属性が含まれ、ファクトテーブルにはすべてのディメンションと測定値の外部キーが含まれます。
上記のスタースキーマでは、中央にファクトテーブル「Sales Fact」があり、主キーを使用して4つのディメンションテーブルに結合されています。 ディメンションテーブルはそれ以上正規化されず、このテーブルの結合はDWのスタースキーマとして知られています。
ファクトテーブルには、メジャー値（dollar_soldおよびunits_sold）も含まれています。
雪片のスキーマ
Snowflakesスキーマには、1つのファクトテーブルのみに結合される正規化された形式の複数のディメンションテーブルがあります。 これらのテーブルは、分析目的のビジネス要件を満たすために論理的に結合されます。
スタースキーマとスノーフレークスキーマの唯一の違いは、ディメンションテーブルがさらに正規化されることです。 正規化は、データを追加のテーブルに分割します。 Snowflakeスキーマの正規化により、情報を失うことなくデータの冗長性が削減されるため、保守が容易になり、ストレージスペースを節約できます。
上記のSnowflakesスキーマの例では、ProductおよびCustomerテーブルはストレージスペースを節約するためにさらに正規化されています。 場合によっては、正規化されたテーブルの行を直接処理する必要があるクエリを実行するときにパフォーマンスの最適化も提供されるため、プライマリディメンションテーブルの行は処理されず、スキーマの正規化テーブルに直接送られます。
粒度
テーブルの粒度は、テーブルに格納されている情報のレベルを表します。 データの粒度が高いということは、データがより詳細なトランザクションレベルまたはトランザクションレベルに近いことを意味します。 粒度が低いということは、データの情報レベルが低いことを意味します。
ファクトテーブルは通常、低レベルの粒度で設計されます。 これは、ファクトテーブルに格納できる最低レベルの情報を見つける必要があることを意味します。 日付ディメンションでは、粒度レベルは年、月、四半期、期間、週、および日です。
粒度を定義するプロセスは、2つのステップで構成されます-
- 含めるディメンションを決定します。
- 情報の各次元の階層を配置する場所を決定します。
緩やかに変化する寸法
ゆっくりと変化するディメンションとは、時間の経過とともに属性の値が変化することを指します。 DWの一般的な概念の1つです。
例
AndyはXYZ Inc.の従業員です。 彼は2015年7月にニューヨーク市に初めて居ました。 従業員ルックアップテーブルの元のエントリには、次のレコードがあります-
| Employee ID | 10001 |
| Name | Andy |
| Location | New York |
後日、彼はカリフォルニア州ロサンゼルスに移転しました。 XYZ Inc. この変更を反映するように従業員テーブルを変更しますか？
これは「緩やかに変化する次元」の概念として知られています。
このタイプの問題を解決するには3つの方法があります-
解決策1
新しいレコードは元のレコードを置き換えます。 古いレコードの痕跡はありません。
緩やかに変化する次元、新しい情報は元の情報を単に上書きします。 つまり、履歴は保持されません。
| Employee ID | 10001 |
| Name | Andy |
| Location | LA, California |
- 利点-古い情報を追跡する必要がないため、これは緩やかに変化するディメンションの問題を処理する最も簡単な方法です。
- 欠点-すべての履歴情報が失われます。
- 使用-ソリューション1は、DWが履歴情報を追跡する必要がない場合に使用する必要があります。
解決策2
新しいレコードがEmployeeディメンションテーブルに入力されます。 したがって、従業員のアンディは2人として扱われます。
新しいレコードがテーブルに追加されて、新しい情報が表され、元のレコードと新しいレコードの両方が表示されます。 新しいレコードは、次のように独自の主キーを取得します-
| Employee ID | 10001 | 10002 |
| Name | Andy | Andy |
| Location | New York | LA, California |
- 利点-この方法では、すべての履歴情報を保存できます。
- 短所-テーブルのサイズが速くなります。 テーブルの行数が非常に多い場合、テーブルのスペースとパフォーマンスが問題になることがあります。
- 使用-DWが履歴データを保持する必要がある場合は、ソリューション2を使用する必要があります。
解決策3
Employeeディメンションの元のレコードは、変更を反映するように変更されます。
特定の属性を示す2つの列があります。1つは元の値を示し、もう1つは新しい値を示します。 現在の値がアクティブになるタイミングを示す列もあります。
| Employee ID | Name | Original Location | New Location | Date Moved |
|---|---|---|---|---|
| 10001 | Andy | New York | LA, California | July 2015 |
- 利点-新しい情報が更新されるため、テーブルのサイズは増加しません。 これにより、履歴情報を保持できます。
- 短所-属性値が複数回変更された場合、この方法ではすべての履歴が保持されません。
- 使用-ソリューション3は、DWが履歴の変更情報を保持する必要がある場合にのみ使用してください。
正規化
正規化とは、情報を失うことなく、テーブルをより冗長度の低い小さなテーブルに分解するプロセスです。 そのため、データベースの正規化は、データベースの属性とテーブルを整理して、データの冗長性（データの重複）を最小限に抑えるプロセスです。
正規化の目的
- 特定の種類のデータ（冗長性/複製）を排除して一貫性を改善するために使用されます。
- オブジェクトタイプに対応するテーブルを単純化された形式で保持することにより、将来の情報ニーズを満たすための最大限の柔軟性を提供します。
- より明確で読みやすいデータモデルを生成します。
利点
- データの整合性。
- データの一貫性を強化します。
- データの冗長性と必要なスペースを削減します。
- 更新コストを削減します。
- アドホッククエリへの応答における最大の柔軟性。
- ブロックごとの行の総数を減らします。
デメリット
いくつかの正規化されたテーブルから関連データを取得するために結合を実行する必要があるため、データベースでのクエリのパフォーマンスが低下します。
複数のテーブル間で適切な結合を実行するには、データモデルを理解する必要があります。
例
上記の例では、緑色のブロック内のテーブルは、赤色のブロック内のテーブルの正規化されたテーブルを表しています。 緑色のブロックのテーブルは冗長性が低く、情報を失うことなく行数も少なくなっています。
