データ・モデリングとは

データ・モデリングの目的は、システム内で使用、保管されるデータの種類と、それらのデータの種類の間にある関係を示すことです。また、データをグループ化および整理する方法と、そのフォーマットや属性についても説明します。

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

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

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

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

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

概念データ・モデルはドメイン・モデルとも呼ばれ、システムに何が含まれるか、どのように構成されるか、どのビジネス・ルールが関係するかについて、高レベルのビューを提供します。概念モデルは、プロジェクトの初期要件を収集するプロセスの一環として作成されます。

通常、概念データ・モデルには、エンティティー・クラス（データ・モデルで表現することがビジネス上重要な対象の種類を定義するもの）、その特性と制約、それらの間の関係が含まれます。また、関連するセキュリティー要件やデータ保全性要件も含まれます。これらの要素を組み合わせることで、モデル内でデータをどのように構造化し、ガバナンスするかが定義されます。表記法は通常、単純です。

論理データ・モデルは抽象度が低く、検討対象のドメインにおける概念と関係について、より詳細な情報を提供します。いくつかある形式的なデータ・モデリング表記法システムのいずれかに従います。これらの表記法は、データ・タイプや対応する長さなどのデータ属性を示し、エンティティー間の関係を表します。

論理データ・モデルでは、技術的なシステム要件は指定されません。この段階は、アジャイルやDevOpsの実践においては省略されることがよくあります。論理データ・モデルは、手続きが厳密に定められた実装環境や、データウェアハウスの設計、レポート・システムの開発など、本質的にデータ指向のプロジェクトで役立ちます。

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

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

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

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

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

リレーショナル・データベースでは、データ管理に構造化照会言語（SQL）がよく使用されます。これらのデータベースは、データの整合性を維持し、冗長性を最小限に抑えるのに適しています。POSシステムをはじめ、その他の種類のトランザクション処理にもよく使用されます。

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

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

データ・モデリングにより、開発者、データ・アーキテクト、ビジネス・アナリスト、その他の利害関係者は、データベースやデータウェアハウス内のデータ間の関係を把握し、理解しやすくなります。さらに、次のことも可能になります。

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

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

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