この記事では、データベーススキーマとは何か、6つのデータベーススキーマ設計、およびそれらがどのように、なぜ使用されるのかについて説明します。
データベースの構築には、様々な工夫が施されています。構築前には、開発者は何を含むべきか、異なる側面がどのように連動するかを計画します。この計画により、データベースがその用途に必要な設計であることが保証されます。そして、コーディング担当者はスキーマを使用してデータベースの設計を実装します。
データベーススキーマは、開発者がデータベースをどのように構築すべきかを可視化するための設計図です。プロジェクトに含まれる情報のフィールドを示す参照点を提供し、何か問題があった場合、開発者はスキーマを参照して対策を講じます。
また、データ管理者はスキーマを使用して、データベースを実装する前に完全に設計されていることを確認します。なぜなら、一旦データベースを実装すると、変更を加えることは困難だからです。この作業は時間と費用の節約になります。スキーマによって、すべての関係者がプロジェクトのあらゆる側面を十分に検討する事になるので、変更の必要性が低くなります。
これらを解決するためには、データを新しいテーブルに移動し、コードはその新しいテーブルを指すようにし、さらにそれらのテーブルには適切な統合が必要になる可能性が高いです。つまり、変更をテストするための非常に強力なテスト環境（データベースとソースコード）、データの整合性を管理するための計画、データベースとソースコードを同時に更新するための計画が必要になります。
一度、データベースを新しいスキーマに移行し始めると、ほとんど後戻りはできません。
今回取り上げるデータベーススキーマは下記6タイプです。
- フラットモデルは、小型でシンプルなアプリケーションに有効です。
- 階層モデルは、XMLやJSONのようなネストされたデータに有効です。
- ネットワークモデルは、マッピングや空間データ、またワークフローの描写に有効です。
- リレーショナルモデルは、オブジェクト指向プログラミングのアプリケーションを最もよく反映します。
- スタースキーマとスノーフレークスキーマは、大規模なデータセットの分析に適しています。
フラットモデル
フラットモデルスキーマは、各列の要素が同じ種類のデータであり、同じ行の要素が互いに関連する単一の2次元配列です。（KISS原則に従ったものです。）
これは、Excelのスプレッドシートのように、関連性のない1つのデータベーステーブルだと考えてください。もし、あなたが少数の従業員で小さなビジネスを営んでいて、その従業員の給与情報のみを保存したいのであれば、単一のフラットなデータモデルで十分でしょう。
階層モデル
階層モデルは、データの「ルート」ノードと、そのルートから枝分かれした「子ノード」を持つツリー状の構造をしています。親ノードと子ノードの間には、一対多の関係があります。この種のデータスキーマは、XMLファイルやJSONファイルに反映させるのが最適で、エンティティは他のエンティティと共有されないサブエンティティを持つことができます。
階層モデルは、分類学の研究など、入れ子状になったデータを保存するのに適しています。
ネットワークモデル
ネットワークモデルは、一連のノードと頂点を表現する点では階層モデルと同じですが、多対多の関係を許容する点が階層モデルとは違います。理論的には、グラフにサイクルができることを意味します。グラフのサイクルとは、同じノードから始まり、同じノードで終わることができる頂点の経路のことです。
企業は、A地点からB地点まで効率的に商品を移動させるだけのことで何十億ドルもの資金が動くため、ネットワークモデルの適用方法を深く理解することは重要です。空間計算を必要とするアプリケーションのほとんどはネットワークモデルのデータベース内にデータを保存することで恩恵を受けると思われます。GIS（Geographic Information Systems）は、地図データを効率的に保存・分析するためのソフトウェアです。
ネットワークモデルは、ワークフローを描写する際にも有効で、特に同じ結果に至る経路が複数存在する場合に有効です。例えば、レストランチェーンの場合、典型的なワークフローは、サーバーがコックに指示します（何を作るかなど）。
例) ハンバーガーとフライドポテト
料理人は、おいしいハンバーガーと具をすべて用意し、塩気の強いフライドポテトを揚げて、すべてを皿に盛り、カウンターに置きます。サーバーはその皿を手に取り、お客が頼んだものであるかどうか最終的な品質確認をします。その後、お客様の元へ運ばれます。
このシナリオでは、料理と異なるカテゴリーの従業員（厨房側と接客側）の間に多対多の関係があるため、このワークフローはネットワークモデルを使用して構成するのが最適です。
リレーショナルモデル
リレーショナルデータベースは、一連のエンティティとして考えるのが最も適切で、そのうちのいくつかは、ある方法で互いに関連しています。リレーショナルデータベースは、それ自体、具体的な存在として考えることが重要です。
オブジェクト指向プログラミングのアプローチに従ってソフトウェアを構築する場合、各オブジェクトのデータを独自のテーブルとしてデータベースに格納するのが最適です。例えば、自動車をプログラミングする場合、タイヤ、アクセル、エンジン、シート、塗装などのオブジェクトを用意することができます。タイヤは車軸に取り付けられ、車軸はエンジンによって回転し、といった具合です。これらのオブジェクトをそれぞれ専用のテーブルとして表現し、適切なエンティティ間（タイヤから車軸、車軸からエンジンなど）にリンクを張れば、データをきちんと保存し、車の動作を理解するのに最適な方法となるでしょう。
リレーショナルデータベースモデルの導入は、データ処理の新しい時代の到来を告げるものでした。興味深いことに、リレーショナルデータベースの発明者であるIBMのエドガー・コッドは、1970年代に「リレーショナル」の意味を別の定義で捉えていたのです。
スタースキーマ
スタースキーマは、これまでとは異なるデータ整理の方法です。膨大な量のデータを保存し、分析するための優れた設計手法であり、"ファクト "と "ディメンション"の使い方に依存します。
「ファクト」とは、ビジネスプロセスを推進する数値データポイントのことで、「ディメンション」とは、そのファクトの説明のことです。例えば、自動車の販売台数を例にとると、「ファクト」テーブルには販売台数の情報が、対応する「ディメンション」テーブルにはその車の色が格納されることになります。
関連記事：スノフレークスキーマとスタースキーマ
スタースキーマの優れた点は、従来のリレーショナルデータベースを抽象化したものであることです。つまり、RDBMSがあれば、それを使ってデータをスタースキーマに構造化することができるのです。
スノーフレークスキーマ
スタースキーマがリレーショナルデータベースモデルの応用であるように、スノーフレークスキーマはスタースキーマの応用です。その名前は、スノーフレークスキーマのERD（実体相関図）を描くと、雪片（スノーフレーク）のように見えることに由来しています。
スタースキーマと同様、スノーフレークスキーマには、主要なデータポイントと次元テーブルへの参照を格納するセントラルファクトテーブルがあります。スタースキーマとは異なり、スノーフレークスキーマのディメンションテーブルは、独自のディメンションテーブルを持つことができるため、ディメンションの記述範囲を広げることができます。
自動車データベースの設計例で、オペレーション部門が自動車の製造に必要なリソースを予測する必要があるとします。その際、営業部門と同様に、どの車が何台売れているのかを知る必要があります。上記のスタースキーマの例では、販売された車の色を示すディメンションテーブルがありました。しかし、営業部門が知りたいのは、色だけでなく、車種、コスト、色のバリエーションなどです。このような場合、色のディメンションテーブルは、それ自身のディメンションテーブルを必要とするので、スノーフレークスキーマが有用です。
これらのデータベーススキーマの例から、自分のデータ設計プロジェクトを構成するものを選ぶことができます。データベーススキーマのサイズと複雑さは、プロジェクトの規模に大きく依存します。データベースの視覚的なスタイルによって、プログラマーはコードに飛び込む前に、情報とその関係を適切に構造化することができます。
Integrate.ioでスキーマ設計
Integrate.ioは、トップクラスのデータスチュワードであることを売りにしています。
①複雑なアプリケーションから膨大なデータセットの処理
②ローコストでストレスレスのデータベース移行
③最先端のSecurETLプラットフォームでデータパイプラインを設計・実行を可能にします。
当社のソリューションがあなたのデータ統合の課題をどのように解決できるかを我々に相談してみませんか。デモのご予約はこちらより。