ちょっと前のブログで、ER図を書くのに、通論をおさえておき、帳票などを見て、その通論にあるものないものをチェックして、それを付け足すと早いと書いた。
その通論を導くのに、統一伝票って書いたけど、普通の人はやってられないと思う。ので、こんなかんじ！っていうのを、こっそり書いてみた。
教科書ガイド的なもんなんで、こっそり見てね！
小売など、消費者に対して、製品やサービスを提供する（いわゆる、ビジネス とう こんしゅーまーのBtoC）の場合、正規系の大きなイベントは、以下の３つ。
（１）注文（受注）
（２）受け渡し
（３）支払い
なお、イベントとは、２つの判別法がある。
１つは、はぶさんの書かれていた、「～する」といえるもの
（例：受注する、注文する、支払いする（支払う））、
もうひとつは、佐藤正美（男性です）氏の方法で、「日時の属性をもてるもの」
（例：受注日、注文日、支払日OK）
この２つは、たいてい一致する
（一致しないものもある。 例：お茶 お茶する○ お茶日X：言葉があいまいだから）
このほかに、細かいイベントとして、請求書発行などがあるが、はじめは、正規系だけで考え、ほかに必要なイベントが出てきたら、付け加える。
異常系として、キャンセル／返品（返金）処理があるが、これは、正規系が決まらないとできないので、今回のせつめいからは、のぞく
各イベントに対し、お店側の人間と、客側の人間がいる。したがって、エンティティは、
受注者 -- 注文 -- 発注者
送り主 -- 受け渡し -- 受取人
支払先 --- 支払い -- 支払い者
と、そのイベントで取引される「モノ＝商品」と、それに対応する「おかね」となるはずだが、
ここで、エンティティをまとめる際
（１）同一人物（同一カテゴリ）の場合、わざわざ、わけなくていい
（２）１対１で行われるイベントに対して（特に同時に行われるような一連の処理）、
わざわざ、エンティティをわけなくてもよい。
という特徴（傾向？サボり方）がある。
また、匿名なものの場合や明らかに自明な情報は、システムに入ってこない。
その場合もエンティティがかかれないことがある。
さらに、そのシステムにおいて、関心のないエンティティ（お金とか）は、かかれない。
この性質を使うと、実際には、以下のようになる。
＜＜飲食店や、お店の物売り＞＞
注文と受け渡し、支払いが同時に行われる。
したがって、分析結果が注文だけという形で書かれるケースもある。
→この場合、エンティティ名は、「販売」のほうが、いいかもしれない。
同時に行われない場合、エンティティを分けるケースもあるが、分けないで、注文エンティティの中にかかれることもある（お弁当の指定時刻受け渡しの場合、注文エンティティの中に指定時間とかかれることもある）。
顧客に関しては、（ラーメン屋さんで、自分の名前を名乗らないように）匿名である場合がある（というか多い）この場合、顧客のエンティティを書かなくっても、問題はない。
お店に関しては、自明なので、エンティティを書かないケースも多いが、（注文を受けた、受け渡した）担当者を記入することもある（レジなど）。
たいていのケースは、
顧客＝発注者＝受取人＝支払い者であり、
お店＝受注者＝送り主＝支払い先である。
そのため、エンティティは、お店と、顧客しか出てこない
さらに、顧客が匿名の場合、顧客エンティティが、お店が自明な場合は、お店エンティティがかかれないこともある。その一方。受け渡しに関し、お店側の従業員名や、レジ番号が書かれることがある。
これらをまとめると、エンティティは、以下のケースを標準とし、場合によって、省略されることとなる。
お み せ － 販売（注文） － お客
｜ ｜ ｜
従業員 レジ 注文明細（＝注文ー商品対応表）
｜
商 品
・レジのかわりに、飲食店だと、テーブルになったりする（テーブル番号）
・商品は、さらに、いろんなエンティティがつく
・商品の代わりにお金をうけとるわけだが、お金をエンティティとすることは少なく、その情報は、販売（注文）の中に入る。
＜＜通販／ECサイトなど＞＞
注文、受け渡し、支払いがわかれるが、実際には、注文書の中に、受取人が違う場合の、受取人の場所を書かせたり、支払い方法を書いたりするので、販売というエンティティで１つにまとめてもかまわない。ただし、商品の分納や、支払いの分割を認めている場合には、エンティティを分けたほうが無難。
注文の場合は、お店なので、省略されることもある。
顧客が省略される可能性はかなり低い（届け先がわからない）。
受取人は、省略されることもある。支払人は、省略されるケースとされないケースがある。
（口座名義人の話とか、会社が支払うケースとか）
支払い方法によっては、お店と、支払先が異なるので（支払先は、銀行とか）これが分かれることがあるが、送り主は、お客に明示しない（佐川か、ヤマトかセイノーか、いわないこともおおい）ので、エンティティとして出現しないことが多いとおもう。
これらをまとめると、エンティティは、以下のケースを標準とし、場合によって、省略されることとなる。
お み せ － 販売（注文） － お客
｜
注文明細（＝注文ー商品対応表）
｜
商 品
｜
納品明細（＝納品ー商品対応表）
｜
納品（受け渡し） － （送付先）
支払先 － 支払 － （支払う人）
なお、支払先は、クレジットカード会社、銀行などに分かれる場合もある。
注文と受け渡し（納品）商品がまったく同じの場合には、納品明細はないが、分納の場合は、かならず（といっていいかな）ある。
支払う人、送付先は、お客と同じビジネスモデルの場合は、これらのエンティティはあらわれない。
納品（受け渡し）と、支払は、本来、販売にリレーションがひかれるが、絵の都合で引けなかったので、ひいてあるとおもってください。
＜＜その他：一般的な考え方＞＞
一般的には、つぎのように考えていく
（１）イベントについて：
注文、受け渡し、支払いが、同時に起こる、もしくは一連のながれであり、
１対１に対応されるか？
→１対１なら、１つのエンティティでもかまわない。
１対１でなければ、分けたほうが無難
（２）各イベントに対する登場人物に関して：
お店側の人間と、客側の人間にわかれる。
このとき、おなじ人は、省略可能。
（３）イベントにおいて、その登場人物間を介してやり取りされるもの：
ふつう、お金と商品、サービスだが、お金は省略される（金額以外の情報はあまり必要でないから）、ただし、これが商品券、チケットの場合は、そのエンティティは生成されることもある。
商品のリソースと、注文のイベントを結びつけるため、商品ー注文対応表としての注文明細が発生する。
なお、受け渡しと注文を沸けた場合、受け渡しー商品対応表としての、納品物明細が発生することもある。納品物明細と、注文明細は、かならずしも同じとは限らない（分納）
さらに支払いエンティティを分けた場合は、支払い（うけとり）金額は必要だが、商品との明細はつけないほうがいい（つけると、物と金の関係が切りにくい）
こんなかんじで考えていき、どの標準を使うかきめて、あとは帳票から、一致するところ、しないところを確認する。しないところは、本当に必要ないのか、たまたま抜けているのかを確認する。
その後、標準的な属性の分析に入る。この属性にも、通論がある。
その通論は、覚えていたら今度。。
アクセス
トータル
ランキング
