前に、佐藤正美氏のデータ収集の方法と、正規化の手法では違いがでるというケースを書いたけど、それについて書くのと、きのう、トップダウンアプローチについて書いたけど、具体的に書いていないので、今回は、それもふくめて、書いてみたいと思います。
■考える内容
ターンアラウンド伝票というものについて考えて見ます。
これは、受注時に、伝票を書くと、カーボンが後ろに入っているので、いっぺんに納品書などもかけてしまうものです。
なんでターンアラウンド伝票って言うかって言うと、この伝票、納品先に行き、納品伝票とかが切り取られて、また帰ってくる（ターンアラウンドしてくる）ので、ターンアラウンド伝票と呼ばれます。
このターンアラウンド伝票の仕様については、業界ごとに決まっていて、統一伝票と呼ばれます。
さて、今回は、統一伝票そのものを考えるのではなく、佐藤氏の以下のページ
３Ｐ形式の伝票
http://www.sdi-net.co.jp/FAQ117.htm
で取り上げられている３Ｐ伝票について考えて見ましょう。つまり、
受注伝票には
｛受注番号、顧客番号、品目番号、受注数、受注日｝
出荷伝票には
｛出荷番号（受注番号と同じ）、顧客番号、品目番号、受注数、出荷日｝
請求伝票には
｛請求書番号（受注番号と同じ）、顧客番号、品目番号、受注数、請求日、請求金額｝
が書かれているとします。ここで、受注番号、顧客番号、品目番号のところには、下にカーボンが入っていて、まったく同じ値が書き込まれます。
また、受注番号がかかれるところに、出荷伝票では出荷番号、請求伝票では請求番号と書かれているため、受注番号、出荷番号、請求番号は、まったく同じ番号になるものとします。
なお、今回は特注品で、１受注品目１枚の伝票とします
■佐藤氏の方法の場合
これについては、さきほどのところ
３Ｐ形式の伝票
http://www.sdi-net.co.jp/FAQ117.htm
に書かれているので、こちらを参照してください。
■ボトムアップアプローチでは
帳票をもとにエンティティを作成する、ボトムアップアプローチでは、以下のようになります。
●第一正規形で
品目番号、受注数、
が繰り返しになるので、これを切り出します。
受注伝票には
｛受注番号、顧客番号、受注日｝
受注明細
｛受注番号、明細番号、品目番号、受注数}
となります。出荷、請求でも同じなのですが、逆に言うとおなじなんで、省略します。
●第二正規形で
結局、受注番号をキーとして、出荷や請求の名前も連動して動いてしまうので、
受注伝票には
｛受注番号、顧客番号、受注日、出荷日、請求日、請求金額｝
受注明細
｛受注番号、明細番号、品目番号、受注数}
ということになります。出荷伝票や、請求伝票は、受注テーブルを検索してつくることになります。
■トップダウンアプローチ（１：見たままを書く）
では、トップダウンアプローチで、みたままを各方法だとどうなるか。
みたままでいうと、伝票は３枚あるのですから、３つ独自のエンティティということになります。そーするとテーブルは３つ＋第一正規形で分離した明細です。
受注エンティティ
｛受注番号、顧客番号、品目番号、受注数、受注日｝
出荷エンティティ
｛出荷番号（受注番号と同じ）、出荷日｝
請求エンティティ
｛請求書番号（受注番号と同じ）、請求日、請求金額｝
受注明細エンティティ
｛受注番号、明細番号、品目番号、受注数}
の形になります。
このとき、受注明細と、出荷明細、請求明細のエンティティが一緒なので、まとめていますが、実際に、この伝票で言っているのは、書き始めるときに、一緒（カーボンコピーするから）っていうだけで、その後、書き換えられるかもしれません。なので、まとめられるかどうかは、あとでヒアリングしてみないといけません。
■トップダウンアプローチ（業界標準から考える）
まず、受注と出荷、請求というのは独立したエンティティと考えるのが普通です。
というか、そもそも、受注と出荷は１：１になるとは（業界によっては）限りません。
受注残処理というのがあって、受注した商品が在庫にない場合、とりあえず、現在ある在庫分だけを払い出し、あとからのこりの分の商品を送るというものです（一部の業界では、受注残処理はなく、在庫分だけを払い出し、残りはキャンセルとなる場合もあります）。
この場合、１つの受注に対して、出荷はＮ、請求は不明となります（請求は、請求日が〆日をまたがない場合、Ｎ個にわけても１個で請求の場合もあるし、分ける場合もあります。またぐ場合、かりにいっぺんに払ったとしても（未着分も含め）、会計上は、納品した分が売上、受注残分は、前受金と分かれます）。
まず、そこから聞くことになりますが、受注残がある場合でも、無い場合でも、以下のテーブルにしておけば安全ではあります（標準的には、このような構造になります）
受注エンティティ
｛受注番号、顧客番号、品目番号、受注数、受注日｝
受注明細エンティティ
｛受注番号、明細番号、品目番号、受注数}
出荷エンティティ
｛出荷番号、受注番号、出荷日、納品場所｝
出荷明細エンティティ
｛出荷番号、明細番号、品目番号、受注数}
請求エンティティ
｛請求書番号、受注番号、請求日、請求金額｝
請求明細エンティティ
｛請求書番号、明細番号、品目番号、受注数、（請求時）単価}
受注時に出荷、請求のデータが作られますが、その後、受注残があるときのためなどで、受注分割されてもいいように、受注１に対し、出荷Ｎ，請求Ｍのレコードが作れるようにします（出荷－請求対応が必要な場合はＮ：Ｍになってしまうので、対応表が新規に必要になります）。
なお、納品先と受注元が違う場合があるので、出荷エンティティの納品場所を入れています。請求明細エンティティに、単価が入っているのは、商品（品目）のマスタからとってきても、受注から請求の間に、商品の単価が変わってしまうと、受注時の単価がわからない＝請求金額もわからないため、受注時に、単価を保存しておきます。
■もし、業界知識が無いと→大幅変更は、必至
このように、業界知識があれば、受注残は？とか、納品場所と受注先は同じ？とか、気が付き、ヒアリングのときに、「現場に」聞くことができます（偉い人は、こーいうとき、理想論を言って、よくわかんないときがある）。
で、もし、これ、ボトムアップアプローチのように、まとめちゃった後で、受注残があって、テーブル分けないといけなくなったら・・・どーなりますう？？
いきなりテーブル増えちゃうんだよ、アクセス方法変わっちゃうよ（＠＿＠！）
っていうことで、大幅開発変更っていうことになります。
（いや、作り直しをしたほうが早いんじゃないかあ。。）
今後、そういった話から、現在の開発の諸相を点描していってみたいとおもいます。
アクセス
トータル
ランキング
