前回は、システム企画の段階で作成する「概念データモデル」、開発の基本設計で作成する「論理データモデル」、そして詳細設計で作成する「物理データモデル」について簡単にご紹介しました。今回は、システム企画段階で作成する「概念データモデル」について解説します。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
概念データモデルは、システム化対象範囲にある業務プロセスをモデル化したもので、これを見ただけで企業のビジネス活動が分かるという大きなメリットがあります。図1の販売活動に焦点をあてた概念データモデルを例に、この企業の販売活動を読み解いてみましょう。
概念データモデルは「ハイレベルエンティティ」(図1緑色枠)、「識別子」(図1青色枠)、「リレーションシップ」(図1赤色枠)の3つから構成されます。
まず、概念データモデルは企画段階で作成するものであるため、システム化対象範囲にあるデータ群を簡易的なレベルで表します。このデータ群が「ハイレベルエンティティ」(本稿ではエンティティと略記します)です。
これらエンティティを顧客コードや商品番号のような「xxコード」、「xx番号」という「識別子」から捕捉します。
イベント系エンティティ、リソース系エンティティ
エンティティには、活動そのものを表す「イベント」系と、活動を実施するうえで必要な「リソース」系という2種類があります。図1では、背景色が白い「顧客」や「商品」はリソース系、背景色が黄色の「訪問(コード)」や「案件(コード)」がイベント系のエンティティになります。
それらのエンティティ間を業務ルールで表したものがリレーションシップです。
ここで例に挙げた企業では、顧客ごとに担当営業がアサインされているため、顧客エンティティと担当者エンティティ間にリレーションシップが定義されています。
また、担当者が顧客にアポイントをとって訪問するというイベント(行為)が発生するので、顧客、担当者、訪問の3つのエンティティ間にリレーションシップが定義されています。
つまり、「事業部ごとに担当者を設け1人の担当者は複数のアカウント(顧客)を持つ」や「複数の事業部から同一アカウントに対して訪問を行ってもいい」といったビジネスルールはすべて、このリレーションシップの線の書き方(表記方法)により表すことができます。
このようにビジネス活動をモデルで表現できるため、
担当者 「同じお客さまに何人も行って嫌がられませんか……?」
マネージャ 「何を言っている! 1社に多面的にアプローチすることでお客様の課題を捉えることができるのだ!!」
といったようなコミュニケーションをユーザー部門ととることができるのです。
概念データモデルは、販売だけに特化するというように、業務単位ごとに作成できますが、ほかのビジネス活動(製造、物流、サービスなど)を作成して、おのおのを統合することにより企業全体のモデルを作成することもできます。図2は、「販売」機能分野全体における概念データモデルの例です。
「販売」機能分野には、「販売計画」、「販売促進」、「販売活動」、「販売管理」などの機能がありますが、この概念データモデルをみると、それぞれの機能で利用されるデータ群と、関連するデータがどこで生まれどこに流れていくかを全体的に把握することができます。
例えば、「販売管理」システムを再構築することになった場合、前後の販売機能とどのようなデータが連携しているかなどが一目で分かるため、システム化対象範囲の検証と要件定義の内容との整合性検証を行うことができます(機能分野や機能については後で説明します)。
Copyright © ITmedia, Inc. All Rights Reserved.