本連載は、ITシステム開発の現場でプログラミングやSQLのコーディングを行っているエンジニア(データベース利用者)が、データ管理者(DA)やデータベース管理者(DBA)へステップアップするための第一歩として有効な基礎知識を紹介する(編集局)
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
今回は、「データベースエンジニアになるための必須知識」の1つであるER図(entity-relationship diagram)を取り上げます。
システム開発におけるER図の位置付けについては、前回の記事「真のデータベースエンジニアを目指そう!」でご紹介したので、今回は、実際にER図を描く場面を想定し、RDBMSに実装するまでのプロセス(思考過程)を疑似体験してもらうことで、ER図を描くために必要な最低限の知識を身に付けていただこうと考えています。
では、早速始めましょう!
実際の業務で、何もシステムが存在しないところからER図を作成することはまれでしょう。おそらく、既存システムのリプレイスや拡張の際に、「すでにある画面や帳票からデータを収集して、ER図を作成すること(ボトムアップアプローチ)」が多いと思われます。
そこで、今回は、すでにシステムが稼働しているという想定で、皆さんにとって身近な「オンラインレコードショップの商品購入画面」(図1)のER図を作成します。
ER図を描き上げるまでには、4つのプロセスがあります(図2)。
では、各プロセスの詳細を順に見ていきましょう。
まずは、業務ルールを把握しましょう。ここではまず図1から把握できることを整理します。なお、図1にある吹き出しは、前画面(「注文画面」)において、どんな入力項目が選択可能であるのかを補足しています。
よって、次のようなことが把握できます。
実際には、画面だけでは読み取れないところもあります。そのような場合は、このシステムを設計・開発した担当者からヒアリングを行う必要もあるでしょう。
さぁ、これで、図1から読み取れる業務ルールは把握できました。取りあえず、下準備はOKといったところです。
では、早速図1からエンティティを抽出していきましょう。
人(誰が)……取引先、組織、担当者、部署、顧客、従業員など
物(何を)……商品、製品在庫、資源、成果物、倉庫など
金……価格、現金、消費税、通貨など
時間……カレンダー、工場稼働日、基準日程計画、世代管理
やりとり・活動・行為(どうする)……受注、発注、出荷、承認、値引き、出庫、入庫など
ある目的を持って同じようなデータを集め、その目的を明確に表す名前を付けたもの。
図1には、「商品」「発送について」「お客様情報」「お届け先」「お支払い方法」「お届け希望指定」という6つのカテゴリが見て取れます。
画面表示上の分かりやすさのために、同じようなデータを1カ所に集め、カテゴリでまとめて扱うことは自然です。一方、エンティティは「ある目的を持って同じようなデータを集めたもの」です。つまり、このカテゴリをエンティティとしてとらえることができます。というわけで、素直に画面表示上のカテゴリ(分類)をエンティティとしてしまいましょう。
各エンティティの名称は、「目的を明確に表現できるような短くて分かりやすい名称」にします(表1)。
また、カテゴリの中にある項目は、エンティティでは「属性」と呼ばれます。例えば「商品」カテゴリの中の「商品名」「フォーマット」「単価(税込)」などは、「商品」エンティティの属性になります。
属性とは、エンティティが持つ情報で、エンティティの性質や特性を表現するもの。
さぁ、これでエンティティが取りあえず抽出できました。
Copyright © ITmedia, Inc. All Rights Reserved.