データ・モデリングとは

データ・モデリングの目的は、システム内で使用および保存されているデータの種類、これらのデータ型間の関係、データをグループ化して整理する方法、およびその形式と属性を示すことです。

データ・モデルはビジネス・ニーズを中心に構築されます。ルールと要件は、ビジネス利害関係者からのフィードバックを通じて事前に定義されるため、新しいシステムの設計に組み込んだり、既存のシステムの反復に適応させたりすることができます。

データはさまざまな抽象化レベルでモデル化できます。このプロセスは、利害関係者やエンド・ユーザーからビジネス要件に関する情報を収集することから始まります。次に、これらのビジネス・ルールをデータ構造に変換し、具体的なデータベース設計を作成します。データ・モデルは、ロードマップ、アーキテクトの青写真、または設計内容のより深い理解を促す正式な図に例えることができます。

データ・モデリングでは、標準化されたスキーマと正式な手法を使用します。これにより、組織全体、あるいは組織を超えて、データ・リソースを定義および管理するための共通の、一貫性のある、予測可能な方法が提供されます。

データ・モデルは、ビジネス・ニーズの変化とともに進化する生きた文書であることが理想的です。これらのモデルは、ビジネス・プロセスのサポートとITアーキテクチャーとストラテジーの計画において重要な役割を果たします。データ・モデルは、ベンダー、パートナー、同業他社と共有できます。

他の設計プロセスと同様、データベースと情報システムの設計は、高度な抽象化レベルから始まり、徐々に具体的かつ明確になります。データモデルは一般的に、抽象化の度合いに応じて３つのカテゴリに分類できます。このプロセスは概念モデルから始まり、論理モデルへと進み、物理モデルで完了します。各タイプのデータ・モデルについては、後続セクションで詳しく説明します。

これらはドメイン・モデルとも呼ばれ、システムに含まれるもの、システムが構成される方法、関与するビジネス・ルールについての全体像を提供します。概念モデルは通常、プロジェクトの初期要件を収集するプロセスの一環として作成されます。通常は、エンティティー・クラス（データ・モデルで表現するビジネスにとって重要なものの種類を定義）、その特性と制約、エンティティー・クラス間の関係、および関連するセキュリティーとデータ整合性の要件が含まれます。表記法はどれも通常は単純です。

これらは抽象度が低く、検討中のドメイン内の概念と関係についてより詳細な情報を提供します。いくつかの正式なデータ・モデリング表記法システムの1つに従います。これらは、データ・タイプやそれに対応する長さなどのデータ属性を示し、エンティティー間の関係を定義します。論理データ・モデルでは、技術的なシステム要件は指定されません。この段階は、アジャイルや DevOps の実践においては省略されることがよくあります。論理データ・モデルは、高度に手続き的な実装環境や、データ・ウェアハウスの設計やレポート・システムの開発など、本質的にデータ指向のプロジェクトに役立ちます。

これらは、データがデータベース内で物理的にどのように保管されるかについてのスキーマを提供します。そのため、抽象性が最も低いものですエンティティ間の関係を示す関連付けテーブル、およびそれらの関係を維持するために使用される主キーと外部キーなど、リレーショナル・データベースとして実装できる最終的な設計が得られます。物理データモデルには、パフォーマンス調整を含むデータベース管理システム（DBMS）固有のプロパティを含めることができます。

データ・モデリングは性質上、利害関係者にデータ処理やストレージを厳密に細部まで評価することを促します。データ・モデリング技術には、データを表すためにどのシンボルを使用するか、モデルがどのように配置されるか、およびビジネス要件をどう伝達するかを規定するさまざまな規則があります。すべてのアプローチは、反復的に実行される一連のタスクを含む形式化されたワークフローを提供します。そのワークフローは一般的に次のようなものになります。

1. エンティティーを特定します。データ・モデリングのプロセスは、モデル化するデータ・セットに表されているモノ、イベント、概念を特定することから始まります。各エンティティーは一貫性があり、かつ他のすべてのエンティティーから論理的に分離されている必要があります。
2. 各エンティティーの主要なプロパティーを特定します。各エンティティー・タイプは、属性と呼ばれる1つ以上の一意のプロパティーを持つため、他のすべてのエンティティー・タイプと区別できます。たとえば、「顧客」と呼ばれるエンティティーには、名、姓、電話番号、挨拶などの属性があり、「所在地」と呼ばれるエンティティーには、都市、州、国または地域、郵便番号が含まれる場合があります。
3. エンティティー間の関係を特定します。データ・モデルの初期の草案では、各エンティティと他のエンティティとの関係の性質が規定されます。上記の例では、各顧客は特定の住所に「居住」しています。そのモデルが「注文」と呼ばれるエンティティーを含むように拡張されると、各注文は特定の所在地に出荷され、さらにその所在地に請求されます。これらの関係は通常、統一モデリング言語（UML）によって文書化されます。
4. 属性をエンティティに完全にマッピングします。これにより、モデルにビジネスでのデータの使用方法が反映されます。いくつかの正式なデータ・モデリング・パターンが広く使用されています。オブジェクト指向の開発者は、分析パターンや設計パターンを適用することがよくありますが、他のビジネス・ドメインの利害関係者は他のパターンを採用する場合があります。
5. 必要に応じてキーを割り当て、冗長性を減らす必要性と性能要件のバランスを取る正規化の度合いを決定します。正規化とは、データ・モデル（およびそれらが表すデータベース）を編成するための手法であり、キーと呼ばれる数値識別子をデータのグループに割り当てて、データを繰り返さずにそれらの関係を表現します。たとえば、顧客それぞれにキーが割り当てられている場合、顧客名のテーブルでこの情報を繰り返すことなく、そのキーを所在地と注文履歴の両方にリンクすることができます。正規化するとデータベースに必要なストレージの量が減る傾向がありますが、クエリ性能に影響を及ぼす場合があります。
6. データ・モデルを完成させ、検証します。データ・モデリングは反復的なプロセスであり、ビジネス・ニーズの変化に応じて繰り返し、改良する必要があります。

データ・モデリングはデータベース管理システムとともに進化し、企業のデータ・ストレージのニーズが高まるにつれてモデル・タイプの複雑さも増しています。ここでは、いくつかのモデル・タイプを紹介します。

• 階層型データ・モデルは、1対多の関係をツリーのような形式で表します。このタイプのモデルでは、各レコードには、1つ以上の子テーブルにマッピングされる単一のルートまたは親があります。このモデルは、1966年に導入されたIBM Information Management System（IMS）に実装され、特に銀行業務で急速に使用されるようになりました。このアプローチは、最近開発されたデータベース・モデルに比べて効率的ではありませんが、拡張マークアップ言語（XML）システムや地理情報システム（GIS）では今でも使用されています。
• リレーショナル・データ・モデルは、 1970 年に IBM の研究者 EF Codd によって最初に提案されました。これらは現在でも、エンタープライズ・コンピューティングで一般的に使用されているさまざまなリレーショナル・データベースに実装されています。リレーショナル・データ・モデリングでは、使用されるデータ・ストレージの物理的特性を詳細に理解する必要はありません。その中で、データ・セグメントはテーブルを使用して明示的に結合されるため、データベースの複雑さが軽減されます。

リレーショナル・データベースでは、データ管理に構造化照会言語（SQL）が採用されることがよくあります。これらのデータベースは、データの整合性を維持し、冗長性を最小限に抑えるのに効果的です。これらは、販売時点管理システムや他のタイプのトランザクション処理によく使用されます。

• エンティティ関係（ER）データ・モデルは、正式な図を使用してデータベース内のエンティティ間の関係を表現します。データベース設計の目標を伝える視覚的なマップを作成するために、データ・アーキテクトはいくつかのERモデリング・ツールを使用します。
• オブジェクト指向データ・モデルは、オブジェクト指向プログラミングとして注目を集め、1990年代半ばに人気が高まりました。ここで使用する「オブジェクト」は、現実世界の実体を抽象化したものです。オブジェクトはクラス階層にグループ化され、主要な機能が関連付けられています。オブジェクト指向データベースはテーブルを組み込むことができますが、より複雑なデータ関係をサポートすることもできます。このアプローチは、マルチメディア・データベースやハイパーテキスト・データベースだけでなく、その他のユースケースでも使用されています。
• 次元データモデルは ラルフ・キンボールによって開発され、データウェアハウスにおける分析目的のデータ検索速度を最適化するために設計されました。リレーショナル・モデルやERモデルでは効率的なストレージを重視する一方、次元モデルでは冗長性が高くなり、レポートや検索のための情報が見つけやすくなります。このモデリングは通常、OLAPシステム全体で使用されます。

一般的な2つの次元データ・モデルはスター・スキーマです。ここではデータがファクト（測定可能な項目）とディメンション（参照情報）に編成され、各ファクトが星型のパターンで関連するディメンションに囲まれています。もう 1 つはスノーフレーク・スキーマです。スター・スキーマに似ていますが、関連するディメンションの追加レイヤーが含まれており、分岐パターンをより複雑にします。

データ・モデリングにより、開発者、データ・アーキテクト、ビジネス・アナリスト、その他の利害関係者は、データベースやデータ・ウェアハウス内のデータ間の関係を表示し、理解することが容易になります。さらに、以下の機能も可能です:

• ソフトウェアとデータベース開発におけるエラーを削減します。
• 企業全体のドキュメンテーションとシステム設計の一貫性を向上させます。
• アプリケーションとデータベースの性能を向上させます。
• 組織全体のデータ・マッピングを容易にします。
• 開発者とビジネス・インテリジェンス・チームの間のコミュニケーションを改善します。
• 概念、論理、物理レベルでのデータベース設計のプロセスを容易にし、高速化します。

現在、複数のデータ・モデリング、ダイアグラム作成、視覚化ツールなど、数多くの商用およびオープンソースのコンピューター支援ソフトウェア・エンジニアリング（CASE）ソリューションが広く使用されています。以下にそうした例を一部ご紹介します。

• erwinデータ・モデラーは、情報モデリングのための統合DEFinition（IDEF1X）のデータ・モデリング言語に基づくデータ・モデリング・ツールで現在、次元アプローチを含む他の表記法をサポートしています。
• Enterprise Architectは、エンタープライズ情報システムとアーキテクチャ、およびソフトウェア・アプリケーションとデータベースのモデリングをサポートするビジュアル・モデリングおよび設計ツールです。これは、オブジェクト指向の言語と標準に基づいています。
• ER/Studioは、現在最も一般的ないくつかのデータベース管理システムと互換性のあるデータベース設計ソフトウェアです。リレーショナル・データ・モデリングとディメンション・データ・モデリングの両方をサポートしています。
• 無料のデータ・モデリング・ツールには、Open ModelSphereなどのオープンソース・ソリューションが含まれています。