前の記事までに、納品書と販売明細が別々の表として記録するという設計方針を説明しました。その時に示した図を再度掲載しますが、ここではさらに「商品」と「顧客」も別の表にしています。
商品を別の表にすることはすでに説明した通りではありますが、この販売管理の枠内でも商品を別にする理由は出てきます。販売においては、1つの商品を、いろいろな会社にいろいろな時期に出荷します。1回の販売と出荷を納品書が表すとすれば、商品と納品書は、１対多の関係になるからです。この時の「１商品」が何者なのかは非常に表現がしずらいです。箱１つ１つではありませんが、かといって大まかな意味での会社の商品でもありません。販売明細の１行に対して、１つの商品が結びつくことになるので、「ロボットいか2号を5個」といったような、個数とセットにした出荷時の内訳の１つを示すデータの構成要素がここでは商品になります。概念として説明は結構大変ではありますが、仕事をしている上ではそんなことに悩んでいる場合ではないので、おそらく多くの方はスルーしているところかと思います。なお、１対多になるのは、商品と納品書ではありません。よく見ると、商品が登場するのは販売明細です。ここは実際のデータがどこにあるかを見極めて、関係のある表が何なのかを判断しないといけません。すなわち、商品と販売明細が１対多になります。販売明細は、１つの納品書では数行ですが、実際に仕事を行うと多数の納品書ができるので、販売明細はそれらの全ての納品書に所属するものが行として追加されたものになります。それが１つの表になります。その表には、１つの商品が多数現れるので、１対多になります。
一見すると、商品と納品書が１対多と思ってしまうところですが、ここまでのところで、商品明細と納品書が多対１であることを分析しています。ということは、１つの商品明細は１つの納品書と結びつくので、商品＞商品明細＞納品書という２段階の関連を考えれば、関係性は１対多と１対１になります。つまり、商品から納品書を見れば１対多であるのですが、それはすでに構築された商品名サイト納品書の関係は無視できない、つまり、この関係性を崩すと、納品書は成り立たないので前提として存在すると考えないといけません。その点でも、感覚的には商品と納品書の直接の関係はありそうではありますが、精密にデータを記録するという意味では直接の関係は考えず、２つの関係があるので、結果的に関係はあるのだけど、設計上の注目点ではないということになります。言い換えれば、２つの関係を保つことで、明細の実現、商品マスターの実現ということができるということです。
なお、図では商品に「単価」も入れました。もし、全ての納品書で、商品が決まれば単価も決まるということなら、このように商品テーブルで単価を記録します。そして、必要になれば参照することで例えば単価と個数の掛け算ができます。一方、商品が決まっても単価は決まらないということなら、単価はむしろ販売明細のフィールドになります。同じ商品でも、700だったり690だったりするという状況です。ただ、現実の案件は、これらの極端な場合とは限らず、その中間だったりします。もっとも、「商品が決まれば単価が決まる」というルールを厳密に行う場合もあったりするので、前者に寄ることはあるかもしれません。このような、商品にあるべきか販売明細にあるべきかという議論は技術的な意味で決まるものではなく、結果的には要求次第ということでもあります。この辺りは別途議論しましょう。
図では「顧客」という表を作りました。これはもうお分かりの通り、１つの顧客に対して、頻繁に販売をするのが普通だから複数の納品書が作られます。つまり、顧客と納品書の関係は１対多となります。また、納品書に複数の会社名が入る、つまり１つの納品書で複数の顧客に出荷するようなことは多分ないでしょうから、やはりそうした制約も１対多の関係の基礎となるでしょう。
さて、ここまでで、販売管理は４つの表に分割しました。前の図で見ている右半分はER図と呼ばれます。こうして設計した内容を表として記述するのはわかりやすいですが、現実世界のシステムでは、多数のフィールドが登場するため、表が横に長くなりすぎて、一覧性は低くなります。なので、「どんなフィールドがあるか」をボックスにまとめて書き、ボックスが１つの表であると表現します。そして、表と表の関連を線を引いて表現します。ER図等はまた改めて検討しますが（なんか、宿題だらけ〜笑）、こういう図を記述することで、設計をコンパクトに示して、全体像を把握しやすくします。もちろん、設計者はこの図を見て、頭の中で表に展開して、データを意図した通りに保持できるかということを常に考えます。それができないと、この図の作図はもちろん、読み取ることもできません。
このように、ER図は、表と表の関係、そして個別の表の内容を定義した極めて集約度の高い設計図なのです。現実の開発では、いきなりこの図がアーキテクトから出てくるかもしれません。実装者はこれを参考にして、間違いなく機能を実装することを求められるということになります。いずれにしても、具体的かつ全体を示すという意味でのモデルとしては非常に役に立つダイアグラムとして認識されています。
ここまでで、表に分解して考えるシリーズを一旦終わらせます。同じように「製造管理」も考えてもいいのですが、引き続いて、「仕様変更」ということを表で考えて、設計に持ち込むことを考えていきます。