多次元テーブル タイプ(深い階層)

提供: ER/Studio Data Architect
移動先: 案内検索

データ モデルのカスタマイズ への移動

多次元モデルでは、各テーブルに[多次元モデル テーブル タイプ]が割り当てられます。このタイプは、エンティティまたはテーブル ボックスの左上隅に表示されるアイコンで識別できます。さらに、テーブルに[テーブル タイプ]を割り当てることができます。このタイプは、テーブル ボックスの下部に表示されます。テーブル タイプの種類が異なっても、データの処理方法は変わりません。テーブル内のデータについての情報をモデルの閲覧者に伝えるために使用します。

AtomicFact.gif

ER Studio Data Architect では、次のような多次元テーブル タイプをサポートします。


[ファクト]

ICON dimension fact.gif 1 つ以上の外部キーがあり、子を持たないテーブルです。

ファクト テーブルに含まれるのは、個々のレコード、つまりデータベース設計の目的となるデータです。ファクト テーブルは、スター スキーマの中心テーブルになります。

ER Studio Data Architect では、ファクト テーブルをさらに次のタイプのいずれかに定義できます。

  • [集計]:  他のテーブルに含まれる詳細データよりも粒度の荒い情報が含まれます。たとえば、小売業務のトランザクション データベースを考えてみます。[Sales_Receipts]ファクト テーブルには個々の売上についての情報が含まれています。[Sales_Monthly]集計テーブルには[Sales_Receipts]テーブルの情報が集計されており、ソフトウェア、ハードウェア、およびサービスの月ごとの総売上のような情報が表されます。集計テーブルを使用すると、レポート作成時にデータにすばやくアクセスできるため、インデックスのようにパフォーマンスを向上させることができます。
  • [アトミック]:  上に説明した[Sales_Receipts]テーブルのように、詳細情報が含まれます。
  • [累積]:  累積的な情報が含まれます。たとえば、販売プロセスが完了するまでにかかった時間などです。これは、受注書の各品目ごとに販売日付から発送日付までの時間が累積されたものです。
  • [スナップショット]:  時間に関連した情報が含まれます。エンティティの有効期間における特定の時点での詳細情報です。たとえば、ある売上のスナップショット情報には、注文の作成日、確定日、出荷日、配達日、および支払い日のような情報が含まれます。


[ディメンション]

ICON dimension dimension.gif ファクト テーブルの親テーブルです。

ディメンション テーブルには、関連したデータ(たとえば、日付、時、分、秒など)のグループが含まれます。ファクト テーブル内では、それらが「時間」のような 1 つのキーで表されます。

ER Studio Data Architect では、ディメンション テーブルをさらに次のタイプのいずれかに定義できます。

  • [固定]:  テーブルの値は固定値であると見なされます。
  • [ディジェネレート]:  ディジェネレート ディメンションは、ファクト テーブルから導出されます。ディジェネレート ディメンションが役立つのは、ファクト テーブルの要素がトランザクション レベルのデータを表しており、システム固有の識別子(たとえば注文番号や請求書番号)を、独自のディメンションに含めることなく管理したい場合です。ディジェネレート ディメンションを使用すると、トランザクション システムを直接参照できます。別のディメンション テーブルを管理するオーバーヘッドはありません。たとえば、サンプル モデルの「受注処理.dm1」では、ディジェネレート ディメンションを作成して、[営業歩合]、[支払明細]、および[受注明細]ファクト テーブルから、それぞれ "歩合ID"、"支払明細ID"、および "受注明細行番" を参照することができます。
  • [複数値]:  複数値ディメンションは、ある属性やカラムが複数値を持つような状況をモデル化するときに役立ちます。たとえば、医療請求書には診断項目があり、そこに複数の値が記載されることがあります。通常、推奨されるモデリング手法では、各項目ごとに 1 つの値をとるようにすべきです。このように複数値が存在するような状況をモデル化するには、複数値テーブルを作成して、複数の診断項目を保存できるようにします。診断項目それぞれには重み付けの数値を設定します。すべての重み付けの数値を合計すると1となるように設定します。この重み付け係数を使用して、ファクト テーブル内の "請求額" を二重にカウントすることなく、レポートを作成できます。

Multi-valued Dimension.gif

  • [不規則]:  不規則ディメンション テーブルでは、テーブル内の少なくとも 1 つのメンバの論理上の親が、そのメンバの真上のレベルには存在しません。不規則ディメンションを使用すると、組織図や部品表など、未確定の深さを持つ階層構造を作成できます。たとえば、ある組織の従業員の一部が、チーム リーダーによって監督されるチームの一員となる場合があります。その他の従業員は直接、部門マネージャの監督下にあります。不規則ディメンションのもう 1 つの例となるモデルを次に示します。ワシントン DC、バチカン市、およびモンテカルロのように、州に属さない都市を示すことができます。

Geography.gif

  • [縮小]:  縮小テーブルは、特定の属性に注目するために、より少ない属性にアタッチされているファクト テーブルのバージョンです。
  • [緩やかに変化する多次元タイプ 0、1、2、3、6]:  緩やかに変化するディメンションは、顧客の収入レベルや収入/借金の比率のような、時間とともに変化する情報を記録します。これらの変化を管理するために最も一般的に使用される方法は次のとおりです。
  • [タイプ 0]:  変化に対して何も処理を行いません。
  • [タイプ 1]:  既存のディメンション メンバ値を上書きします。変更履歴は記録しません。
  • [タイプ 2]:  現在のディメンション メンバを保持して新しい行を作成します。元の行には期限切れとタグ付けします。
  • [タイプ 3]:  毎年など、予測可能なリズムで変化するディメンションに使用されます。すべてのディメンション行には現在のカテゴリ属性があり、それらは上書きすることができます。また、2008 年のカテゴリや 2009 年のカテゴリなど、指定された各年に対する属性もあります。
  • [タイプ 6]:  タイプ 1、2、3 を組み合わせたアプローチです。このタイプのテーブルの変更では、行は上書きされますが、テーブルに追加の日付カラムを含めて、ディメンション内の特定の行が該当する日付範囲を指定することができます。あるいはテーブルに改訂番号を含めることもできます。


[スノーフレーク]

ICON dimension snowflake.gif ディメンション テーブルの親テーブルです。

スノーフレーク テーブルは、ディメンション テーブルの要素が一覧表示される、より正規化された形式を表します。次の例では、ディメンション テーブルの親である 2 つのスノーフレーク テーブルを示しています。サンプル モデルである「受注処理.dm1」には、他にも多くのすぐれた例やスノーフレーク テーブルがあります。

Snowflake.gif

[ブリッジ]

ICON dimension bridge.gif 多対多リレーションシップを実装します。ブリッジ テーブルは、複数値を持つディメンション、または複雑な階層構造をサポートします。ブリッジは、ヘルパー テーブルまたは関連テーブルとも呼びます。ブリッジ テーブルの使用は、複数の 1 対多リレーションシップ、または多対多リレーションシップを実装する唯一の方法です。


[階層型ナビゲーション]

ICON dimension hierarchy navigation.gif 複雑な階層構造、たとえば組織図などをサポートするために使用されます。


[未定義]

ICON dimension undefined.gif その他すべてのテーブルです。このタイプを割り当てることで、テーブルの適切なタイプがまだ未決定であることを示すことができます。たとえば、テーブルが多対多リレーションシップを持つ場合や、テーブルがファクト テーブルとディメンション テーブル両方の親であったりする場合です。


関連項目