見出し画像

概念データモデリングのワークフロー

以下は、概念データモデリング(Conceptual Data Modeling)を構築するためのフレームワーク的なプロセスと、それぞれのステップごとに対応する考察および例である。ここで述べるモデルは、主にエンティティ・リレーションシップ(ER)モデルなどを想定しているが、UMLクラス図などでも同様の考え方が応用可能である。例としては、オンライン書店(ECサイト)をモデリング対象ドメインとする。

概念データモデリングの全体的なプロセスフレームワーク

  1. ドメイン理解・範囲定義

  2. 主要概念(実体)の抽出

  3. 実体同士の関係性の定義

  4. 実体属性(特性)の抽出・定義

  5. 識別子(主キー)およびユニーク制約の設定

  6. 関係性の多重度(カーディナリティ)・ビジネスルールの考察

  7. モデル全体のレビューと調整

  8. ドキュメンテーションと共有

以下、それぞれのステップについて詳しく見ていく。


1. ドメイン理解・範囲定義

考え方:
まず対象領域(ドメイン)がどのような業務や世界を扱うのかを明確にする。ビジネス要件、対象領域の用語、関係者(ステークホルダー)からのヒアリング、要求仕様などを通じて、モデル化する範囲を決める。この段階では、「何をモデル化するべきか(何を除外するか)」が重要となる。

例:
オンライン書店をモデル化すると決めた場合、以下のような範囲を想定する:

  • 書籍の商品情報(タイトル、著者、価格、在庫数など)

  • 顧客情報(名前、連絡先、支払方法など)

  • 注文や配送に関する情報(注文日、配送先、支払状況、出荷状況など)

図書館管理、電子雑誌サブスクリプション、出版社側の在庫管理システムは今回は範囲外とするといった明確な線引きを行う。


2. 主要概念(実体)の抽出

考え方:
ドメインを表す上で、永続化または管理対象となる「名詞的な存在」を特定する。実体(Entity)は、モデル内で独立して存在が管理できる対象であり、システムにおけるオブジェクト群に対応する。実体を考える際は、ビジネスにおける重要な事物・概念を洗い出す。

例:
オンライン書店の例では、以下が実体候補となる:

  • 顧客(Customer): 書店で買い物を行う人物または組織

  • 書籍(Book): 販売される商品。ISBN、タイトル、著者、価格などの情報を有する

  • 注文(Order): 顧客による購入アクションおよびその結果生成される注文情報(注文日時、合計金額など)

  • 支払(Payment): 注文に対する支払取引。クレジットカード決済情報や支払いステータスなど。

  • 配送(Shipment): 注文された商品を顧客へ送り届けるための配送情報(配送先住所、配送ステータスなど)


3. 実体同士の関係性の定義

考え方:
抽出した実体がどのような関連を持つかを明らかにする。関係(Relationship)は、「AはBを注文する」「顧客は複数の注文を出す」といった動詞的な繋がりで捉える。業務フローやユースケースを参照して、実体間の因果関係や依存関係を明確化する。

例:

  • 顧客(Customer)と注文(Order)は、「顧客は複数の注文を行う」(1対多)

  • 注文(Order)と書籍(Book)は、「1つの注文は複数の書籍アイテムを含む」(多対多、ただし中間エンティティLineItemが必要な場合が多い)

  • 注文(Order)と支払(Payment)は、「1つの注文は1つ以上の支払を伴う場合もあるが、基本的には1対1または1対多」

  • 注文(Order)と配送(Shipment)は、「1つの注文には1回以上の出荷がありうる」(1対多)


4. 実体属性(特性)の抽出・定義

考え方:
各実体ごとに、そのエンティティが保持すべき情報項目(属性)を列挙する。属性(Attributes)は概念モデルでは必ずしも全て洗い出す必要はないが、主要な属性は明確にし、後で詳細化する場合もある。名前、型、意味、必須性などを検討する。

例:

  • 顧客(Customer):

    • 顧客ID(CustomerID)、氏名(Name)、メールアドレス(Email)、電話番号(PhoneNumber)、住所(Address)など

  • 書籍(Book):

    • 書籍ID(BookID)、ISBN、タイトル(Title)、著者(Author)、価格(Price)、在庫数(StockQuantity)

  • 注文(Order):

    • 注文ID(OrderID)、注文日時(OrderDate)、合計金額(TotalAmount)、ステータス(OrderStatus)

  • 支払(Payment):

    • 支払ID(PaymentID)、支払方法(PaymentMethod)、支払日時(PaymentDate)、支払状態(PaymentStatus)

  • 配送(Shipment):

    • 配送ID(ShipmentID)、配送日時(ShipmentDate)、配送状態(ShipmentStatus)、配送先住所(ShipmentAddress)


5. 識別子(主キー)およびユニーク制約の設定

考え方:
各実体を一意に区別するための属性または属性群(主キー)を決定する。これにより、実体インスタンスをユニークに特定できる。また、同一の書籍が重複登録されないようにISBNにユニーク制約を与えるなど、業務的なユニーク性のルールを明確化する。

例:

  • 顧客IDは主キー。Emailにもユニーク制約をかけることで、同じメールアドレスでの重複登録を防ぐ。

  • 書籍IDは内部管理用の主キーとし、ISBNにもユニーク制約を付与(実業務上のユニーク性担保)。

  • 注文ID、支払ID、配送IDもそれぞれのエンティティでの主キーとする。


6. 関係性の多重度(カーディナリティ)・ビジネスルールの考察

考え方:
実体同士の関係において「1対1」「1対多」「多対多」などの多重度を検討する。ビジネスルールによっては、多対多を1対多+中間エンティティで表現する必要がある。また、任意なのか必須なのか(選択性/必須性)も明確にする。

例:

  • 「顧客—注文」の関係は1対多(1人の顧客が複数の注文を行う)

  • 「注文—書籍」の関係は、多対多が自然だが、在庫や単価が注文ごとに異なる可能性があるため「注文—明細行(LineItem)—書籍」の3者関係で表す。LineItemには注文IDと書籍IDを外部キーとして持ち、数量や価格を保持。

  • 「注文—配送」は1対多(1つの注文が複数回の部分出荷を行うことがあり得る)


7. モデル全体のレビューと調整

考え方:
ここまでで作り上げた概念モデルをレビューして、一貫性、冗長性、わかりやすさ、ビジネス要件との整合性をチェックする。関係性が過度に複雑になっていないか、実体や属性の名称がわかりやすいか、抜けや二重定義がないかを確認する。

例:

  • 「顧客」と「注文」の関係において、必須性(「必ず顧客がいなければ注文は存在しない」のか)を明確化。

  • 「支払」と「注文」の関係:支払が行われないと注文は成立しないのか?後払いはあるか?などビジネスルールを再確認。

  • 在庫や価格の更新頻度、リレーションシップの正当性を再考する。


8. ドキュメンテーションと共有

考え方:
完成した概念モデルを、関係者と共有する。ドキュメント化、ビジュアルなER図の提示、用語集の整備などを行い、理解促進と合意形成を図る。概念モデルは後続の論理データモデル、物理データモデルの基盤となるため、正確性と理解容易性が重要。

例:

  • VisioやLucidchartなどのツールでER図を描画し、チームでレビュー。

  • 用語定義書を作成し、顧客、注文、書籍などの概念説明を記述。

  • 要件定義書に概念モデルを添付する。


まとめ

このフレームワークでは、ドメインの理解から始まり、主要実体の抽出、実体間関係の明確化、属性や主キー設定、多重度・ビジネスルールの検証、そして最終的なレビュー・ドキュメンテーションと共有までのプロセスを段階的に示した。この一連のステップを踏むことで、現実世界の事物・プロセスを論理的・構造的に表現した概念データモデルが得られ、それが後続の物理実装(データベーススキーマ設計)の基盤となる。

いいなと思ったら応援しよう!