スタースキーマ

今日、レポートと分析はコアビジネスとほぼ同じくらい重要です。レポートは、ライブデータから作成できます。多くの場合、このアプローチは、大量のデータを持たない中小企業にとってはうまくいきます。しかし、物事が大きくなったとき、またはデータの量が劇的に増加し始めたときは、運用システムとレポートシステムを分離することを検討するときが来ました。

基本的なデータモデリングに取り組む前に、関連するシステムの背景が必要です。システムは、運用システムとレポートシステムの2つのカテゴリに大別できます。運用システムは、オンライントランザクション処理（OLTP）と呼ばれることがよくあります。レポートおよび分析システムは、オンライン分析処理（OLAP）と呼ばれます。 OLTPシステムはビジネスプロセスをサポートします。これらは「ライブ」運用データを処理し、高度に正規化されており、ユーザーの操作に非常に迅速に対応します。一方、OLAPシステムの主な目的は分析です。これらのシステムは要約されたデータを使用します。これは通常、スタースキーマのような非正規化されたデータウェアハウス構造に配置されます。（非正規化とは何ですか？簡単に言えば、パフォーマンスを向上させるために冗長なデータレコードがあります。続きを読む。）

システムについて少し理解できたので、データウェアハウスとその断片およびプロセスの調査を始めましょう。

データウェアハウスとデータマート

データウェアハウス（DWH） は、データ分析とレポートで使用するための情報を保存するために使用されるシステムです。 データマート 単一の部門または個々のユーザーが必要とする情報を格納するために使用されるデータウェアハウスの領域です。（DWHを建物と考え、データマートを建物内のオフィスと考えてください。）

なぜデータマートが必要なのですか？関連するすべてのデータは、会社のDWH内に保存されます。ただし、ほとんどのユーザーは、販売、生産、ロジスティクス、またはマーケティングに関連するデータなど、特定のデータのサブセットにのみアクセスする必要があります。データマートは、セキュリティの観点（不要なアクセスを制限する）とユーザーの観点（混乱させたり、無関係なデータを無理やり通過させたりしたくない）の両方の観点から重要です。

データウェアハウスとデータマートの関係には、2つの異なるアプローチがあります。

トップダウン ：データマートはデータウェアハウスから作成されます。（これは、「データウェアハウスの父」であるBill Inmonが、ウェアハウスは3NFにあるべきであるという考えとともに同意するものです。）
ボトムアップ ：データマートが最初に作成され、次にデータウェアハウスに結合されます。（このアプローチは、データウェアハウスであり次元モデリングの専門家であるラルフキンボールが提唱しているものに近いものです。）

ETLプロセス 定期的に「新しい」データをOLAPシステムに追加するために使用されます。 ETLは、Extract、Transform、Loadの略です。名前が示すように、1つ以上の運用データベースからデータを抽出し、ウェアハウス構造に合うように変換して、データをDWHにロードします。

次元モデリング データウェアハウス設計の一部である、は、ディメンションモデルの作成につながります。関連するテーブルには2つのタイプがあります：

ディメンションテーブル 保存するデータを説明するために使用されます。例：小売業者は、特定の購入に関与した日付、店舗、および従業員を保管したい場合があります。各ディメンションテーブルは独自のカテゴリ（日付、従業員、店舗）であり、1つ以上の属性を持つことができます。各店舗について、都市、地域、州、国のレベルでその場所を保存できます。日付ごとに、年、月、日、曜日などを保存できます。これは、階層に関連しています。ディメンションテーブルの属性の一覧。

スタースキーマでは、通常、一部の属性が同じレコード内の他の属性のサブセットであることがわかります。この冗長性は、パフォーマンスの向上という名目で意図的に行われています。日付、場所、販売代理店のディメンションを使用して、データを集計（ETLプロセスの変換部分）してDWH内に保存できます。 寸法モデリングでは、適切な寸法を定義し、適切な造粒を選択することが非常に重要です。
ファクトテーブル 関連するディメンションテーブル内の値に基づいて集計された、レポートに含めるデータが含まれます。ファクトテーブルには、ディメンションテーブルを参照する値と外部キーを格納する列のみがあります。すべての外部キーを組み合わせると、ファクトテーブルの主キーが形成されます。たとえば、ファクトテーブルには、連絡先の数と、これらの連絡先から生じた売上の数を格納できます。

この情報が揃ったら、スタースキーマデータモデルを掘り下げることができます。

スタースキーマ

スタースキーマ DWHで使用される最も単純なモデルです。ファクトテーブルはスキーマの中央にあり、その周りにディメンションテーブルがあるため、おおよそ星のように見えます。これは、ファクトテーブルが5つのディメンションテーブルで囲まれている場合に特に顕著です。スタースキーマの変形ムカデスキーマ 、ファクトテーブルが多数の小さなディメンションテーブルに囲まれている場合。

スタースキーマは、データマートで非常に一般的に使用されています。それらをトップダウンのデータモデルアプローチに関連付けることができます。 2つのスタースキーマ（データマート）を分析し、それらを組み合わせて1つのモデルを作成します。

スタースキーマの例：販売

売上レポートは、今日最も一般的なレポートの1つです。前述したように、ほとんどの場合、ライブシステムから売上レポートを生成できます。ただし、データやビジネスの規模によってこれが煩雑になる場合は、プロセスを合理化するためにデータウェアハウスまたはデータマートを構築する必要があります。スタースキーマを設計した後、 ETL プロセスは、運用データベースからデータを取得し、データをDWHに適した形式に変換して、データをウェアハウスにロードします。

上記のモデルには、1つのファクトテーブル（明るい赤の色）と5つのディメンションテーブル（水色の色）が含まれています。モデルのテーブルは次のとおりです。

fact_sales –このテーブルには、ディメンションテーブルへの参照と2つのファクト（価格と販売数量）が含まれています。 5つの外部キーすべてが一緒になってテーブルの主キーを形成することに注意してください。
dim_sales_type –これは、「type_name」という1つの属性のみを持つ販売タイプのディメンションテーブルです。」。
dim_employee –これは、基本的な従業員属性（氏名と生年月日）を格納する従業員ディメンションテーブルです。
dim_product –これは、製品名と製品タイプの2つの属性（主キー以外）のみを持つ製品ディメンションテーブルです。
dim_time –このテーブルは時間ディメンションを処理します。主キーの他に5つの属性が含まれています。最下位レベルのデータは、日付別の売上です（action_date ）。 action_week 属性はその年の週の番号です（つまり、1月の最初の週には1が付けられ、12月の最後の週には52が付けられます）。actual_month およびactual_year 属性には、販売が発生した暦の月と年が格納されます。これらはaction_dateから抽出できます属性。 action_weekday 属性には、販売が行われた日の名前が格納されます。
dim_store –これは店舗のディメンションです。各店舗について、店舗が所在する都市、地域、州、国を保存します。ここで、スタースキーマが非正規化されていることがはっきりとわかります。

スタースキーマの例：供給注文

以下に示すこのモデルと販売モデルの間には多くの類似点があります。

このモデルは、発注履歴を保存することを目的としています。 1つのファクトテーブルと4つのディメンションテーブルがあります。ディメンションテーブルdim_employee 、dim_product およびdim_time 販売モデルとまったく同じです。ただし、次の表は異なります。

fact_supply_order –発注された注文に関する集約データが含まれています。
dim_supplier –は、dim_storeと同じ方法でサプライヤデータを格納するディメンションテーブルです。販売モデルにデータを保存しました。

スタースキーマの長所と短所

スタースキーマを使用することには多くの利点があります。ファクトテーブルは、1つの関係によって各ディメンションテーブルに関連付けられており、ディメンションテーブルを説明するために追加のディクショナリは必要ありません。これにより、クエリが簡素化され、クエリの実行時間が短縮されます。 OLTPシステムから直接同じレポートを作成することもできますが、クエリははるかに複雑になり、システムの全体的なパフォーマンスに影響を与える可能性があります。次の販売モデルのサンプルクエリは、2016年にベルリンの店舗で販売されたすべての電話タイプの製品タイプの数量を返します。

SELECT 
  dim_store.store_address,
  SUM(fact_sales.quantity) AS quantity_sold

FROM 
  fact_sales
  INNER JOIN dim_product ON fact_sales.product_id = dim_product.product_id
  INNER JOIN dim_time ON fact_sales.time_id = dim_time.time_id
  INNER JOIN dim_store ON fact_sales.store_id = dim_store.store_id

WHERE 
  dim_time.action_year = 2016
  AND dim_store.city = 'Berlin'
  AND dim_product.product_type = 'phone'

GROUP BY 
  dim_store.store_id,
  dim_store.store_address

スタースキーマの最大の欠点は冗長性です。各ディメンションは個別のディメンションテーブルに保存されるため、非正規化が発生します。この例では、都市は国に属する地域または州に属しています。その関係を原則としてデータベースに保存しませんが、継続的に繰り返します。これは、より多くのディスクスペースを消費し、データの整合性のリスクがあることを意味します。

ギャラクシースキーマ

以前の2つのモデルは、販売部門用と供給部門用の2つのデータマートと見なすことができます。それぞれは、1つのファクトテーブルといくつかのディメンションテーブルのみで構成されています。必要に応じて、これら2つのデータマートを1つのモデルに組み合わせることができます。いくつかのファクトテーブルを含み、いくつかのディメンションテーブルを共有するこのタイプのスキーマは、ギャラクシースキーマと呼ばれます。。ディメンションテーブルを共有すると、データベースのサイズを減らすことができます。特に、共有ディメンションに多くの可能な値がある場合はそうです。理想的には、両方のデータマートでディメンションが同じ方法で定義されます。そうでない場合は、両方のニーズに合うように寸法を調整する必要があります。

2つのデータマートの例から構築された銀河スキーマを以下に示します。

スタースキーマは、データウェアハウスを編成するための1つのアプローチです。これは非常に単純で、データマートで最も頻繁に使用されます。ディスク容量について心配する必要がなく、データの整合性に十分注意を払っている場合は、スタースキーマが最初で実行可能な最良の選択です。そうでない場合は、別のアプローチを検討する必要があります。 1つはスノーフレークスキーマです。これについては、今後の記事で説明します。