データモデリングの勘所
データモデリングという言葉を聞いたことがありますか？これはデータベースやシステム設計で欠かせないスキルの一つであり、実際のビジネスやプロジェクトで高い効率と正確性を求める上で非常に重要です。しかし、「エンティティ」「属性」「リレーションシップ」など、初めてこの領域に触れる方には少々難解な用語や概念が飛び交います。
この記事では、データモデリングに関するチェックポイントで個人的に参考になそうなものをピックアップしたので、実際にデータモデリングを実施する際に参考にしてください
データモデリングとは
データモデリングとは、情報を効率的かつ正確に扱うための「構造」を設計するプロセスです。この構造を設計する作業を総称して「データモデリング」と呼びます。具体的には、データの形状、データ間の関連性、制約条件などを明示的にします。
概念データモデリング
最初に行うのは「概念データモデリング」です。これはビジネス要件や目的に対応した、非常に高度な抽象度のモデルを作成します。主にビジネスステークホルダーとのコミュニケーション用とされ、技術的な詳細は省かれています。
論理データモデリング
次に、具体的なデータ構造を考える「論理データモデリング」があります。この段階では、エンティティや属性、それらの間のリレーションシップを定義します。しかし、まだ具体的なデータベースや技術に依存した形には落とし込まれていません。
物理データモデリング
最後に、「物理データモデリング」が行われます。ここでは実際にデータベースにどのように格納するか、パフォーマンスやセキュリティ等を考慮した具体的な設計が行われます。
モデリングの勘所
データモデリングの入り口として正規化がありますが、詳しい説明は他の記事に譲ります。
イベントエンティティとリソースエンティティを区別しよう
データモデリングにおいて、エンティティを設計する際には「イベントエンティティ」と「リソースエンティティ」を明確に区別することが重要です。
「リソースエンティティ」は、永続的なデータを表現するエンティティです。例えば、ユーザー、商品、会社などがこれに該当します。リソースエンティティは通常、ビジネスにおいて長期的に保持される情報を格納します。
一方で「イベントエンティティ」は、ある特定の瞬間または期間に発生する事象を表現します。例としては、購入履歴、ログイン履歴、エラーイベントなどがあります。イベントエンティティは状態の変化を捉えるために存在します。
どう区別するか？
リソースエンティティは「何であるか」（What）に焦点を当て、イベントエンティティは「何が起こったか」（What happened）に焦点を当てます。この違いを理解することで、適切なエンティティ設計が可能となります。
リソース系: 顧客、商品、従業員など
イベント系: 受注、製造、出荷、請求など
ホモニム、シノニム、エイリアスの問題を解決しよう
データモデリングにおいて、言葉の曖昧性は混乱や誤解を招く要因となります。特に「ホモニム」「シノニム」「エイリアス」の問題は注意が必要です。
ホモニム（同名異義語）
ホモニムとは、同じ名前で異なる意味を持つ言葉のことです。例えば、bankが「銀行」と「土手」の二つの意味を持つように、データモデリングでもこのような問題が生じます。明確な区別を行い、必要に応じて別名をつけることで解決します。
シノニム（同義語）
シノニムは、異なる名前で同じ意味を持つ言葉です。例えば、CustomerIDとClientIDが同じデータを指す場合などです。この問題を解消するには、用語の標準化が有効です。
エイリアス
エイリアスは、同じデータエンティティや属性に対して、システムやコンテキストによって異なる名前が与えられる場合です。エイリアスが存在すると、データの統合や分析が困難になる可能性があります。エイリアスの一覧を作成し、基準となる名前を定めることが解決策となります。
リレーションシップの安全性を検証しよう
安全性検証とは？
安全性検証とは、データモデルのリレーションシップや制約が現実のビジネスロジックに適合しているかを確認するだけでなく、将来的に生じうる変更にも柔軟に対応できるように設計するプロセスです。つまり、変更予測が可能な箇所には、事前に柔軟性を持たせる変更を加えておくことも含まれます。
例えば、納品と請求のエンティティそれぞれに顧客IDを持たせる設計を採用することで、柔軟性を確保し、「納品先と請求先を別々にしたい」といった変更にも対応することが可能というようなことです。
ビジネス要件や技術環境は常に変わる可能性があります。そのような変更に柔軟に対応できるデータモデルを作成することで、長期的な運用が容易になります。
(他の勘所も随時追記していこうと思います。)
Discussion