データベーススキーマデザイン６種とその使用法

データベースの構築には多くの思考が必要であることは知られています。デベロッパーはデータベースの作成前に、時間をかけてデータベースの内容や、すべてがどのように連動するかを計画しますが、この計画段階は、それでデータベースがその用途に適したデザインになっているかどうかを確認できるため、非常に重要です。

最もよく使われる6つのスキーマとして、以下のユースケースが挙げられます：

1. フラットモデル： 小規模でシンプルなアプリケーションに最適なモデル。
2. 階層モデル： XML や JSON のようなネストされたデータ向け。
3. ネットワークモデル： マッピングや空間データ、ワークフローの描写に便利。
4. リレーショナルモデル： オブジェクト指向プログラミングのアプリケーションに最適。
5. スターモデル： 大規模な一次元データセットの分析向け。
6. スノーフレークモデル： 大規模で複雑なデータセットの分析向け。

データベーススキーマは、デベロッパーがデータベースをどのように構築すべきかを視覚化するための設計図です。プロジェクトにどのような情報フィールドが含まれているかを示す参照ポイントを提供し、データベースの構築中に問題や混乱があれば、デベロッパーはスキーマを参照するだけで、すべての答えが得られるはずです。 

データ管理者は、スキーマを使って、実装のずっと前に潜在的な問題の解決も行います。一旦データベースが実装されると、変更がしにくくなる可能性があるため、これは貴重な時間とコストの節約になります。また、スキーマを選択する際には、全ステークホルダーがプロジェクトのあらゆる側面を十分に検討し、後々大きな変更が必要になる可能性を減らさないといけません。

そこでこのガイドでは、最もよく使われているデータベーススキーマの例を６つに分類し、それぞれのスキーマにまつわる考慮事項や使用例について見ていきます。

正しいスキーマの選択が重要な理由

プロジェクトのために間違ったデータベーススキーマを選択すると、アプリケーションのボトルネックを悪化させ、コストのかかるリファクタリングにつながる可能性があります。例えば、アプリケーションが複数のテーブル JOIN に依存していることに早い段階で気づかなかった場合、ユーザー数とデータ数が一定数に達すると、サービスは最終的に停止してしまいます。

これを解決するには、データを新しいテーブルに移動し、コードを新しいテーブルを指すようにし、適切な結合（JOIN）が必要になります。つまり、変更をテストするための強力なテスト環境（データベースとソースコード）、データの整合性を管理する計画、データベースとソースコードを同時に更新する計画が必要になるということです。

いったんデータベースを新しいスキーマに移行し始めると、後戻りはほとんどできません。なので最初の段階で正しいデータベーススキーマを選択することで、ソフトウェアプロジェクトの全期間を通じて、多くの苦悩や心痛を取り除くことができるのです。

１．フラットモデル

フラットモデル のデータベース構造とは、単一の二次元配列で、各列の要素は同じタイプのデータであり、同じ行の要素は互いに関連しています。

これは、Excel のスプレッドシートのような、単一の無関係なデータベーステーブルだと考えてください。例えばもし少数の従業員で小規模なビジネスを経営していて、その従業員の給与情報だけを保存したいのであれば、単一のフラットなデータモデルで十分です。ちなみにこのモデルは KISS の原則（Keep it simple, stu*id.：シンプルにしておけ）に従っています。

２．階層モデル

階層型データベーススキーマには、データの「ルート」のノードと、そのルートから分岐する「子」のノードを持つ、ツリー状の構造があり、「親」ノードと「子」ノードの間には一対多の関係があります。このタイプのデータスキーマは XML または JSON ファイルに最もよく反映され、エンティティは他のエンティティと共有されないサブエンティティを持つことができます。

階層的なデータベース構造は、分類学の研究のように、入れ子になったデータを保存するのに適しています。

３．ネットワークモデル

ネットワークモデルは、一連のノードと頂点を表すという点では階層モデルに似ていますが、階層モデルとは違い、「多対多」の関係が可能です。理論的な観点から見ると、これはグラフに周期が存在する可能性があるということになります。そしてグラフ内の周期は、同じノードから始まったり、同じノードで終わったりする頂点のパスがあることが示されます。

企業の商品のA地点からB地点への効率的な移動を実現するには、何十億ドルもの資金が必要であり、そのためネットワークモデルの適用方法についての深い理解が欠かせません。空間的な計算を必要とするアプリケーションのほとんどは、ネットワークモデルのデータベース内にデータを保存することで恩恵を受ける可能性が高く、例えば GIS（地理情報システム）というソフトウェアで、ユーザーは地図データを効率的に保存し、分析することができます。

ネットワークモデルは、ワークフローを描写する際にも有用で、特に同じ結果へのパスが複数ある場合に有効です。たとえば、レストラン チェーンの場合、典型的なワークフローは、「サーバーから料理人への何を作るかの指示」です。料理人はチケットに書かれた料理を作り、「注文の品ができました」と知らせたら、サーバーはその皿を手に取り、それが客が頼んだものであることを確認するために最終的な品質保証を行います。このシナリオでは、「料理」と異なるカテゴリーの従業員との間に「多対多」の関係があります。従って、このワークフローはネットワークデータベース構造を使うのが最適です。

４．リレーショナルモデル

リレーショナルデータベースモデルの導入で、データ処理の新時代が切り開かれました。面白いことに、リレーショナルデータベースの発明者である１９７０年代の IBM のエドガー・コッド氏は、「リレーショナル 」の意味について違った定義を持っていました。

ただ、数十年にわたる使用を通じて、プログラミングコミュニティは、リレーショナルデータベースとは何かについて、より普遍的な理解に落ち着きました。つまり、データを関係（つまりテーブル）として格納し、そのデータを操作したり計算したりするために、関係演算子が存在するということです。

このことを念頭に置くと、リレーショナルデータベースは一連のエンティティとして考えるのが最適であり、それぞれのエンティティを別個のものとして考えることが重要です。オブジェクト指向プログラミングのアプローチに従ってソフトウェアを構築するのであれば、各オブジェクトのデータをそれぞれのテーブルとしてデータベースに格納するのがベストでしょう。

リレーショナルデータベースのスキーマの良例を挙げてみましょう： 車をプログラミングする場合、タイヤ、アクスル、エンジン、シート、塗装などのオブジェクトがあるかもしれません。タイヤは車軸に取り付けられ、車軸はエンジンによって回転します。これらの各オブジェクトを独自のテーブルとして表し、適切なエンティティ (タイヤから車軸、車軸からエンジンなど) 間のリンクを持たせることは、データをきちんと保存し、車がどのように動作するかを理解するための最適な方法になります。

リレーショナルデータベースを管理するには、リレーショナルデータベース管理システムを使います。RDBMS についての詳細はこちらの記事（英語）をご覧ください。

５．スタースキーマ

スター型データベーススキーマの例を視覚化すると、物事はもう少し面白くなり始めます。スタースキーマは、データを編成する別の方法であり、大量のデータを保存および分析する場合に最適なデータベースデザインの例の一部になります。 そして スタースキーマが優れている理由の１つに、スタースキーマが「ファクト（事実）」と「ディメンション（次元）」の使用に依存している点が挙げられます。

「ファクト」はビジネス・プロセスを駆動する数値データポイントであり、「ディメンジョン」 はそのファクトの記述です。例えば、車の販売台数を使うと、「ファクト」 テーブルには販売台数に関する情報が含まれ、対応する 「ディメンジョン」テーブルにはそれらの車の色が含まれます。 

スタースキーマの素晴らしいところは、従来のリレーショナルデータベースの上に抽象化されたものであるという点です。つまり、RDBMS があれば、それを使ってデータをスタースキーマデータベースの構造にすることができるというわけです。

関連記事：スノーフレークとスタースキーマの違いと比較

６．スノーフレークスキーマ

スタースキーマはリレーショナル データベースモデルを適応させたものであるため、スノーフレークスキーマはスタースキーマを適応させたものになります。 その名前は、スノーフレークスキーマの ERD（実体関連図）をどのように表現するかに由来しており、ご想像のとおり、スノーフレーク（雪の結晶）のように見え始めます。

スタースキーマと同様に、スノーフレークスキーマには、主なデータポイントとディメンジョンテーブルへの参照を格納する中心ファクトテーブルがあります。ただ、スタースキーマとは違って、スノーフレークスキーマのディメンジョンテーブルは独自のディメンジョンテーブルを持つことができるため、ディメンションの記述範囲が広がります。

先ほどの自動車のデータベーススキーマの例を使って、オペレーション部門が自動車製造に必要なリソースを予測する必要があるとしましょう。営業部門と同じように、どの車が何台売れたかを把握したいはずです。

上記のデータベーススキーマの例では、販売された車の色を示すディメンジョンテーブルがありましたが、オペレーション部門は、色以外の塗料について、ブランド、コスト、塗装回数などを把握したいかもしれません。そうなると、このシナリオでは、色のディメンジョンテーブルが独自のディメンジョンテーブル（塗料のブランド、コスト、塗布回数など）が必要になるため、スノーフレークスキーマが有用です。

Integrate.io によるデータ管理の最適化 

最終的には、新しいデータベースを構成するために、これらのデータベースデザインの例のいずれかを選択することができますが、その際は賢く選択することが極めて重要です。なのでゼロから始める場合は、主要なステークホルダーと時間をかけて話し合い、データベースのサイズと複雑さを評価しましょう。また、保存する情報の種類を検討し、コードを書く前に、データポイントの関係をすべて図面化しておきましょう。

計画段階は、最初は圧倒されるように思えるかもしれませんが、長い目で見れば、数え切れないほどの手直しの時間の節約になり、ビジネスが今後何年も頼りにすることができる強力で信頼性の高いデータベーススキーマへの道へと導いてくれるでしょう。

新しいデータベース構造を計画するとき、データがどのように保存、移動、利用されるかを検討する絶好の機会でもあります。 最も複雑で大規模なデータセットでも処理できる、コード不要のデータ統合パイプラインの構築にサポートが必要な場合は、ぜひ Integrate.io をご利用ください。

Integrate.io では、最先端の ETL/ELT プラットフォームを使って、コード不要のデータパイプラインのデザインおよび実行ができます。詳しくは１４日間の無料トライアルで、実際に動作する様子をぜひご覧ください。