データ設計モデルとは

論理データモデルとは？

論理データモデル（Logical Data Model）は、概念データモデルで定義されたビジネスの実体（エンティティ）や関係性をもとに、より技術的・構造的に具体化したデータ設計モデルである。システムに実装する前段階として、正規化やキー設計、データ型の定義を通じて、整合性のあるデータ構造を確立する目的がある。

かつてある医療系スタートアップでは、予約・患者・診療履歴などの情報がスプレッドシートで個別に管理されており、患者情報の整合性が取れないことが大きな課題となっていた。プロジェクトチームはまず概念データモデルを作成したが、実際のシステム化に向けて論理データモデルに落とし込むことで、どの情報をどこまで正規化し、どのような関係性を持たせるかを明確にした。結果として、「患者ID」「予約ID」「診療ID」などをキーに関係付けた明確な構造ができ、データの正確性と拡張性が大幅に向上した。

1. 論理データモデルの目的

概念モデルの精緻化：ビジネス視点のデータ構造を、DBMSに依存しない中立的な形で詳細化する。
システム設計の基礎構築：テーブル化や正規化を通じて、整合性・保守性の高いデータ構造を設計する。
データ品質の確保：データ重複の排除や一貫性のあるルール設計を行うことで、システム全体の品質を高める。

2. 論理モデルで定義される主な要素

エンティティ → テーブル
属性 → カラム（列）
主キー（PK）：各レコードを一意に識別する
外部キー（FK）：他のテーブルと関係性を持たせる
制約（制限）：NOT NULL, UNIQUE, CHECK など
データ型の指定：文字列（VARCHAR）、数値（INT）、日付（DATE）など

例：顧客情報と注文情報を1つのテーブルにまとめていた設計から、それぞれを分離し、顧客IDで関連づける構造に変更することで、データの重複と冗長性を解消した。

3. 正規化と論理モデル

論理モデル作成時には、データの整合性を保つために「正規化」が行われる。

第1正規形（1NF）：繰り返し項目を排除
第2正規形（2NF）：主キーに対する完全従属性を確保
第3正規形（3NF）：推移的従属性を排除

物流会社のケースでは、配送表に「ドライバー名」「担当エリア」「配送車両」などが繰り返し記載されていたため、第1〜3正規形に沿ってテーブルを分割し、「ドライバーID」でリレーションする構造に再設計。これにより、マスタ管理が容易になり、運用時の人的ミスが激減した。

4. 論理モデルの成果物

テーブル一覧（エンティティ→テーブル変換後）
属性一覧（カラム名、データ型、制約条件）
関係図（リレーションシップ定義）
ER図（論理レベルでの詳細なER図）
定義書（各項目の説明、ドメインルールなど）

5. 実際のプロジェクトでの活用例

あるEC企業では、商品・注文・顧客・在庫の4つのエンティティをもとに論理データモデルを作成した。初期の段階では、在庫情報を商品テーブルに直接持たせていたが、正規化により「在庫」テーブルを独立させ、商品IDをキーに関係付ける設計へと変更。これにより在庫履歴の管理や複数倉庫への拡張にも柔軟に対応できる構造となった。

特に現場で評価されたのは、同一商品でも倉庫別に在庫数を管理できるようになった点であり、物流部門との連携が格段にスムーズになった。

6. 概念モデルとの違い

比較項目	概念モデル	論理モデル
対象	業務・ビジネス視点	技術的な構造視点
データ型	抽象的	明確に定義（例：VARCHAR, INT）
制約	表現しないことが多い	NOT NULL, UNIQUE など記述
実装依存	非依存	DBMSには依存しないが、構造は実装を意識