30分間データモデリング 〜ER図を描こう！〜：データベースエンジニアへの道（2）（1/4 ページ）
本連載は、ITシステム開発の現場でプログラミングやSQLのコーディングを行っているエンジニア（データベース利用者）が、データ管理者（DA）やデータベース管理者（DBA）へステップアップするための第一歩として有効な基礎知識を紹介する（編集局）
はじめに
今回は、「データベースエンジニアになるための必須知識」の1つであるER図（entity-relationship diagram）を取り上げます。
システム開発におけるER図の位置付けについては、前回の記事「真のデータベースエンジニアを目指そう！」でご紹介したので、今回は、実際にER図を描く場面を想定し、RDBMSに実装するまでのプロセス（思考過程）を疑似体験してもらうことで、ER図を描くために必要な最低限の知識を身に付けていただこうと考えています。
では、早速始めましょう！
こちらの記事もお勧め
連載「ゼロからのデータモデリング入門」
- 第1回 「歴史的問題」からデータモデルを考える
- 第2回 信頼性の高いデータの管理・供給のためのDOA
- 第3回 データベース設計の有用性とフィットギャップ分析
- 第4回 データベース設計はいつ、何をポイントに行うか
- 第5回 システム企画に役立つ概念データモデル作成の基本
- 第6回 基本設計で作るべき「論理データモデル」の考え方
- 第7回 物理データモデル作成のポイントは“森→木→森”
- 第8回 ビジネス視点のデータモデリング
- 第9回 データモデル正規化の目的と役割
- 第10回 ビジネスの変化に強いデータモデルを作る
- 第11回 論理設計から動くシステムへ
- 最終回 データモデリングは「できるところ」から始めよう
お題はオンラインショップの商品購入
実際の業務で、何もシステムが存在しないところからER図を作成することはまれでしょう。おそらく、既存システムのリプレイスや拡張の際に、「すでにある画面や帳票からデータを収集して、ER図を作成すること（ボトムアップアプローチ）」が多いと思われます。
そこで、今回は、すでにシステムが稼働しているという想定で、皆さんにとって身近な「オンラインレコードショップの商品購入画面」（図1）のER図を作成します。
ER図を描き上げるまでのプロセスは4つ
ER図を描き上げるまでには、4つのプロセスがあります（図2）。
では、各プロセスの詳細を順に見ていきましょう。
業務ルールを把握しよう
まずは、業務ルールを把握しましょう。ここではまず図1から把握できることを整理します。なお、図1にある吹き出しは、前画面（「注文画面」）において、どんな入力項目が選択可能であるのかを補足しています。
よって、次のようなことが把握できます。
- この画面は、顧客が注文を行う過程の「注文確認画面」である。
- 1人の顧客は、1回の注文で、複数の商品を注文できる。
- 注文の前に、顧客の情報（住所を含む）は、前もって登録されている。
- 発送方法を「即発送」「10日間だけの取り置き」の2つから選択できる。
- 配送先（届け先名称、郵便番号、住所、電話番号）を指定できる。特に指定がない場合は、登録済みの顧客の住所が指定される。
- 支払方法を「代金引換」「クレジットカード」の2つから選択できる。
- 配送日時を指定できる。その際、「時間帯」と「日付」の指定ができる。
実際には、画面だけでは読み取れないところもあります。そのような場合は、このシステムを設計・開発した担当者からヒアリングを行う必要もあるでしょう。
さぁ、これで、図1から読み取れる業務ルールは把握できました。取りあえず、下準備はOKといったところです。
エンティティを抽出しよう
では、早速図1からエンティティを抽出していきましょう。
エンティティとは？
人（誰が）……取引先、組織、担当者、部署、顧客、従業員など
物（何を）……商品、製品在庫、資源、成果物、倉庫など
金……価格、現金、消費税、通貨など
時間……カレンダー、工場稼働日、基準日程計画、世代管理
やりとり・活動・行為（どうする）……受注、発注、出荷、承認、値引き、出庫、入庫など
ある目的を持って同じようなデータを集め、その目的を明確に表す名前を付けたもの。
図1には、「商品」「発送について」「お客様情報」「お届け先」「お支払い方法」「お届け希望指定」という6つのカテゴリが見て取れます。
画面表示上の分かりやすさのために、同じようなデータを1カ所に集め、カテゴリでまとめて扱うことは自然です。一方、エンティティは「ある目的を持って同じようなデータを集めたもの」です。つまり、このカテゴリをエンティティとしてとらえることができます。というわけで、素直に画面表示上のカテゴリ（分類）をエンティティとしてしまいましょう。
各エンティティの名称は、「目的を明確に表現できるような短くて分かりやすい名称」にします（表1）。
また、カテゴリの中にある項目は、エンティティでは「属性」と呼ばれます。例えば「商品」カテゴリの中の「商品名」「フォーマット」「単価（税込）」などは、「商品」エンティティの属性になります。
属性とは、エンティティが持つ情報で、エンティティの性質や特性を表現するもの。
さぁ、これでエンティティが取りあえず抽出できました。
Copyright © ITmedia, Inc. All Rights Reserved.