ユーザーにとって、表というと表計算ソフト、Excelの表を思い出すと思う。
なんで、ＲＤＢのテーブルと、Excelのシートって、だいたい同じイメージになってしまう。つーか、ユーザーでなくても、そうだ（開発の人でもそういう人がいる）
でも、この２つには、決定的なちがいがある。
Excelは、セルの結合ができる。
ＲＤＢは、セルの結合が出来ない。
セルの結合のように、２レコード以上で、同じ値をとる場合は、２つのテーブルにわける。正規化の処理の一部で行う。
この問題は、聞いていると思う。でも、もう一歩突っ込んだ話。
つまり、ユーザーにとって、レコードの最小単位っていうのは、自分が、最小単位だと思ったのが、最小単位なのよ。それより細かく分割できても、セルを結合して、まわりに線をひいてしまえば、いいし。。。
っていうことで、問題がある。
ヒアリングをするとき、ユーザーは、レコードの説明を、「自分が、最小単位だと思っている」ものを、最小単位として説明する。
したがって、ユーザーのヒアリングをもとに、名詞項目を抽出し、（ＥＲ図を作るのをサボって、かつ正規化の作業をはしょって、すぐに）テーブルにしてしまうと。。。
コーディングのときに。。。
おやおや、このレコードのあるところのステータス、２つの値をとることがないか(@_@!)
ってなことになり、テーブル設計しなおしになる。
でも、ユーザーは、気づかない
例を挙げよう
受注のとき、
りんご１００個
みかん９０個
という受注をうけたとする。
自社倉庫は、東京と大阪にある。
このとき、東京倉庫に、りんご１５０個、みかん５０個、大阪倉庫に、みかん５０個あったとする。そうすると、大阪倉庫から東京倉庫にみかん４０個を送ってもらい（これを、倉庫間移動という）、それがついたとき、この受注の出荷をする。
そうすると、みかん９０個のステータスは、２つに分かれて、
みかん 東京倉庫分 ５０個 引当済み
みかん 大阪倉庫分 ４０個 倉庫間移動中
と、２レコードにわかれないと、ステータス管理できない。
ところが、Excelの人にそんな概念はない。受注明細の２行分の商品名を連結して、１行にして、そこに「みかん」と書き、上の行に５０個、下の行に４０個と書いてしまう。
受注明細をさらに分けるという概念はない。
そのため、その後のヒアリングに矛盾がでてくることがある。
ってことを、ユーザーからの話のなかで出てきたのならいいんだけど、
あるプロジェクトマネージャーさんが、どうも気づいてないようだったので、気になって書いてみた。
