前回の再掲になりますが、ここまでに、部署ごとに、その部署での関心ごとについて表にしていきました。ここで、フィールド名をつけるところまでを解説しました。
続いて、この一連の表から、共通の概念を持つデータを抽出します。厳密には、正規化の議論があって、そのルールに基づくという手法もあるのですが、ここでは会社のドメイン、部署のドメインについて、要求分析を通じてだいぶんと理解が深まったという状況をもとに考えてみましょう。
まず、ここでどの表にも「商品名」があります。であれば、商品名を共通化することで何かメリットは生まれないかと言うことを考えます。それぞれの表にも名前をつけることにしますが、加えて、商品名だけを独立させた「商品」と言う表も記述してみました。つまり、「販売明細」「製造管理」「カタログ在庫」いずれも、「商品」にある商品名の文字列を持ってきて表が作れるというものです。こうすれば、販売管理や製造管理において、何度も繰り返し登場する１つの商品名を記述することなく、商品名はシステムの中では商品の中に１箇所登場するだけにすることもできそうです。効率が良くなるかもしれません。
ちなみに、これが「商品マスター」と呼ばれる考え方の1つの理解の仕方です。効率良いことと、修正の確実性ということが言われます。例えば、商品名を間違って記録していたら、それが最初の図のような表の場合、表の中で一括置換をするなど、変更が重い処理になり、また確実に終わりそうにない処理にもなります。マスターで一元的に商品名を管理すると、商品名が違っていても、１箇所直すだけです。しかしながら、商品名の間違いってそんな頻繁にはないでしょうという気もするかもしれません。実際そうですが、実はマスターの役割は確実に変更できるということ以外にさまざまなことがあります。システム内では、データの複製をするような場合が出てきます。要求から、ここのフィールドは複製が必要と判断される箇所は時々出てきます。その場合でも、マスターの内容を複製することで、確実に名前を入力できると言ったこともあります。この辺りは、リレーショナルデータベースの理屈だけでは説明しきれない側面です。ただ、実際にある製造管理によって管理されている個体の商品が、商品テーブルをどのように参照するのかということは、実装上のルールがあって、それは次回に説明したいと思います。
「商品」という存在は、部署によって共通であり、商品名は、どの部署でも同様に利用できるという、ここでは表にまたがって存在するデータの共通性を見つけました。実際には、さらに販売先顧客名が重複しているなどの問題はありますが、それは追々見つけましょう。
ここで、概念が共通という意味では、日付もそうではないかと思いませんか？ もちろん、販売日と製造日は、対象が異なりますが、いずれも、日付という共通の概念ではないかと思うところです。たまたま、この表では同じ日がなかったということです。では、日付を共通化するのかというと、おそらく多くのデータベースでは共通化していないと思われます。これはなぜなのでしょうか？ 日付や時刻はいずれも3つの整数を持つような複合データであり、突き詰めて考えれば複雑そうです。この結論を先に言えば、日付や日付時刻といったデータは、データベースが持つ型として定義されているからです。言い訳っぽい理由になりますが、「商品」という型はありませんが、DATEやTIMESTAMPといった型があり、日付という単独の値、つまり、数値などと同じように扱えるから、多くの場合は別の表に分離しないということです。仮に別の表に分離しても、1フィールドだけです。商品の場合は、ここでは明示していませんが、おそらく商品名だけでなく、販売開始日など、共通の概念として「商品」に紐づく属性がフィールドとして付加されることになるでしょう。つまり、この会社における共通概念の商品を扱うために必要な情報を追加することになります。しかしながら、日付は多分日付だけなのだろうと思われます。
しかし、日付を別の表に分離しないと対処しづらい場合もあります。それは日付以外の情報が入っている場合で、例えば、祝日の管理が挙げられます。また、その会社特有の記念日（創立記念日など）もあります。そうなると、日付にもう少し意味が付加されてしまい、実はそれは「予定表」だったりして、「日付」という概念ではなくなってくるでしょう。予定表の日付ということで、ここでも日付という型があることで、単独フィールドとして扱えるというあたりが日付時刻についての特殊性とも言えます。
このように、とにかく「マスターを作る」というデータは１つの案件内では結構あり、いくらか経験を積めば、大体いい感じに設計できると思います。しかしながら、そこには、表ごとに異なる「商品」と、表を通じて共通の「商品」の概念があって、後者がマスターになるということを理解しておく必要があります。ところで、共通というのは実は抽出時に考えることで、運用上はそこまで厳しくありません。商品の販売単価は、おそらくはここでは営業部門だけが使いたいでしょう。では、それは商品マスターに入れるのかというと、実は入れることが一般的です。これは、他の部門では無視すればいいというのがまずはざっくりとした見方なのですが、より重要な概念があります。単価は、その共通概念である商品１つについて、１つの値が割り当てられる属性であるとみなすことができれば、それは商品マスターのフィールドの一つにすればいいのです。そして、必要な表では使い、不要な表では無視するというのがデータベース利用のポイントになります。ここで、「商品１つについて１つの属性」、つまり、１対１の関係であることをしっかりと考え、確認しておく必要があります。実は、部門午後の表のフィールドは、その表１行の概念に対して、１対１の関係が成り立っているものが並んでいます。作ってある表はちょっと恣意的ではありますが、こうすれば、整理されているとも言えるでしょう。
次回は、分離した表から必要な情報を持ってくるというリレーショナルデータベースの基本的な考え方を説明しましょう。