コラム

最低限知っておきたいER図の書き方

2016-01-25

RM STAFF

WRITER:

RM STAFF

こまめに仕様をドキュメントにまとめたい!そんな時どうする?

 

こんにちは、リッチメディアで何でも屋となりつつある社内最古参のエンジニアのTodaと申します。

 

関係者皆様のおかげで、リッチメディアのサービスも順調に成長・拡大をしていますが、

各開発メンバーのサービスの全体像の把握が必ずしも追いついているわけではありません。

 

shutterstock_262267121

 

そして、社内のエンジニアだけでなく、新卒、中途入社のエンジニアの皆様への

サービスの仕様共有もスピーディに行いたいので、こまめに仕様をドキュメントにまとめたいところです。

 

そこで、突然ですが、財布の中に以下のようなレシートを入れっぱなしにしていませんか?

 

レシート

 

このレシートは実は、私がコンビニでおにぎりや飲料などの朝食を購入した際のレシートです。

今回はこのレシートという身近な素材を元にして、Cacooを利用しER図(図1)を作成してみました。

ということで、今回のblogのお題はER図です。

 

【図1】 

er

ER図(Entity Relationship Diagram)とは

 

エンティティと言われるデータのまとまりとエンティティの中の属性(アトリビュート)、

その関連(リレーションシップ)を図で表したものをいいます。(図2参照)

 

【図2】

er2

 

属性洗い出し

 

まずエンティティの中に入る属性情報を洗い出していきます。

図1のER図には、注文明細の消費税率はレシート自体に記載は無いのですが、

属性としては必要なのか、商品の在庫数は必要なのかどうかというところまで洗い出していきます。

 

属性を洗い出すに当たって、このような、レシートを読むだけでは洗い出すことができない業務ルールを把握するために、その業務のことを理解している人へのヒアリングが必要です。

時に、将来利用されるであろうことをエンジニアが想定して属性をあらかじめ追加したくなることもありますが、属性が利用されなかった時に属性を削除する方が手間なのでやめておきましょう。

 

 

エンティティ洗い出し

 

属性情報を洗い出したら、その属性情報を複数のエンティティにまとめてみましょう。

 

==================================================

  • レシートの合計や商品の購入日時のエンティティ
  • レシートの明細のエンティティ
  • レシートに記載された商品や在庫のエンティティ
  • レシートの最後に記載されたSuicaなどの決済手段のエンティティ
  • レシートに記載されたSuica決済履歴のエンティ

==================================================

 

本来ならば、在庫エンティティや入出庫エンティティ、価格の履歴エンティティなど

もっと多くのエンティティがあるはずなのですが、今回は割愛します。

ただし実際の業務では、それらのエンティティが必要になるのかどうか、

どのような順序でエンティティの中の属性情報が作成、更新されるのかどうか、

業務の関係者に業務フローのヒアリングが必要です。

 

関連情報洗い出し

 

そして今回は、エンティティの関連情報を鳥の足のようなIE表記を用いて描画してみました。

まず、エンティティ同士が1対0以上の関連の例として、図3の注文とSuica決済履歴のエンティティの関連を元に説明してみます。

 

まず、商品の購入を受け付け、注文情報を作成した時に、Suicaの決済履歴情報は商品の購入者がSuicaで支払いを済ませることによって、Suica決済履歴情報のエンティティ内に作成されます。ただし、Suicaではなく現金で支払いを済ませた場合は、Suicaの決済履歴情報は作成されることはありません。

その業務ルールを表すために、注文側の関連には棒線1本、Suica決済履歴情報側の関連には円と鳥の足のようなものを記載します。この記載によって、注文エンティティに注文情報が1つある場合、Suica決済履歴エンティティにはその注文情報に関連したSuica決済履歴の情報が『0以上』あることを読み取ることが出来るようになります。

 

 

【図3】

図3

 

次に、エンティティ同士が1対1以上の関連の例を、図4の注文と注文明細のエンティティの関連で説明してみます。

 

まず、注文があった場合、商品の購入情報を記載する注文詳細情報が必ず注文詳細エンティティに作成されます。その業務ルールを表すために、注文側の関連には棒線1本、注文詳細情報側の関連には棒線と鳥の足のようなものを記載します。この記載によって、注文エンティティに注文情報が1つある場合、その注文の情報に関連した注文詳細の情報が注文詳細エンティティに必ず『1つ以上』あることを読み取ることが出来るようになります。

 

【図4】

図4

 

普段業務でよく使う1対0以上、1対1以上の関連の他に1対1、あるいは多対多などの関連もあります。

ですので、それらの関連を業務のデータ作成ルールに応じて適切に使い分け、ER図を作成できるようにしましょう。

 

最後に

今回は最低限知っておきたいER図の書き方を紹介しました。

サービスが大きくなるにつれて、このようにサービス運用で必要な情報を整理し、普段は特定の機能しか見ていない他の開発チームメンバーと、サービスで取り扱っている情報の『全体像』を一目で共有しやすくしてみてはいかがでしょうか?

 

プログラミングは頭の中で描いている創造物をリアルに具現化する事ができる手段であり、

インターネットを通じて多くのユーザに社会貢献できる手段だなと感じこの道に進もうと思いました。

 

リッチメディアではプログラミングが好きで、

チーム全体でサービスを開発していきたいという想いを持ったエンジニアを募集しています。

 

一緒に最高の作品を創り上げていきませんか?

 

20150901_仲間募集KV

 

[参考文献]
http://d.hatena.ne.jp/simply-k/20100706/1278417587

https://thinkit.co.jp/free/tech/31/2/1.html

http://www.atmarkit.co.jp/ait/articles/0909/11/news098.html

 

【関連記事】

キュレーションメディアを支える技術[サーバサイド編]

WordPress以外のCMSも使ってみよう!Drupalとは?

DSP実務者にオススメ!代表的なDSPの使いやすさを比較してみました