ある意味で私の専門分野でもあるので，より詳しく感想を書いていく．いろいろ疑問も書いているが，このような本はいままで全く書かれていなかったという点だけでも，生産管理に携わる人は絶対に読むべき本である，ということは間違いない．
DFDなど設計手法については別の本が詳しいので，そのときに書くことにする．
大胆な用語の使い方
アカデミックな人では絶対に真似ができないと思ったのが，用語をより直感的に翻案し，新たに作られている点である．著者が単に従来の方法を真似するのではなく自分の頭で考えて発想しているから，このようなことができるのだろう．具体例をいくつかあげる．
一次識別子と二次識別子
識別子とはいわゆる「キー」*1を指し，一次識別子とは識別子の中から代表的なもの一つ，二次識別子とはそれ以外の識別子を指す．一見すると主キー(primary key)と主キー以外の候補キー(candidate key)のように思える*2が，微妙な差異がある．
まず，一次識別子は「タプルが削除されるまで変化しないような項目でなければならない」と定められている．一方，主キーは変更を認めている，というよりも，そういうことを考慮に入れていない．ではなぜそういう制約を，あえて著者は入れたのだろうか？おそらく，主キーを変更できるようにした場合，その主キーを参照している外部キー(foreign key)も同時に変更する必要があり，処理が重くなり，そのような項目は主キーとしてはふさわしくないということを経験的に感じておられるからだろう．
一方，二次識別子は変更が許され，ヌルが認められるとされている．ヌルを認めるといった段階で，いわゆる「キー」の概念からははずれてしまう．よって，「一意性はその項目がヌルでないようなタプルの集まりにおいて，という制限付き」になる．私も仕事で設計している上でこのような概念をスキーマ上に定義しようと試みたことがあるが，ヌルを認めてしまっているためユニークな制約が付けられず，簡単ではないので諦めたことがある．
親子関係
これは，アカデミックでは，弱エンティティとその参照元エンティティの関係といえるのだが，親子関係の方がより直感的だろう．一方，外部キーが一次識別子の一部にならない場合は参照関係と呼んでいる．
正規形
一方，少し残念だったのは正規形の説明だった．数式による一般化を行わずに実例と自然言語で説明するのは無理ではないだろうか．なんとなくいいたいことはわかるようなわからないような，曖昧な読後感が残った．ただ，例えばwikipediaの「リレーションの正規化」のような説明は，なれない人には何を言っているかわからないかもしれないが，正規形をそれぞれ説明するなら，私は避けられないと思う．
また，実務で使えるという事に徹するなら，各正規形についてそれぞれ説明する必要はあったのだろうか？例えば，ボイスコッド正規形の定義，つまり「全ての関数従属の決定項が候補キーである」ということだけでいいと思う．４５ページの図４の例にあるような第三正規形からボイスコッド正規形の差は実務では余り意識しなくていい．ここで説明されている分解後の形は十分にボイスコッド正規形であり，だから，場合によっては第三正規形で止めておいてもよい，（とうちのボスの授業では説明がされていた．）著者は図４の分解は不十分であり，図５の分解がボイスコッド正規形である，としているが，これは著者が考えたボイスコッド正規形だとすべきであろう．
また，私はこの分解（分解ではなくて実際は追加している）には賛成できない．４６ページ以降にその例が示されている．図６で異常なタプルが追加されるのを避けるために，著者は作出属性とよばれる導出可能な属性を追加している．整合性維持の観点から，このような導出可能な属性をデータとして持つことはできる限り避け，できる限りミニマルなセットを作るべきだ，と私は考えているので，このような分解には賛成できない*3．この例では，設備という属性を製品エンティティから導出することにより，二次識別子とすることで，制約を作っているが，ビジネスルールなどを含めると，制約はエンティティの関係だけですべて記述できるわけではないので，導出可能な属性を追加してまで記述しようとする必要はないと思う．制約は記述できたが，導出可能な属性を追加することによって，導出元のデータが変更された場合の更新時異常の可能性を発生させているのは，問題ではないだろうか．
プログラミングは些末な問題
と初めのコラムにある．こう書かれてしまうとすごく反発を覚える部分もあるのだが，DOA（データ中心アプローチ）では普通の考え方だ．私もOracleの設計コースの研修を受けたときにそう習ったし，そういう見方で仕事をしたこともある．著者の別の本にもこのような記述があり，読む人によってはこの初めのカラムでこの本を捨ててしまいたくなるかもしれない．オブジェクト指向関連の本などを読むと，DOAへの推進者に対する嫌悪を顕わにするものもあり（というかほとんどそう），ものすごく溝が深いことを感じてしまう．
著者は生産管理という場面においてはデータが中心になると書いているが，なぜそうなのか，生産管理のしくみのどういう部分がデータ中心であり，なぜ実装系技術は些末なのか？ということについては書いていない．だから，反発を感じる人にとって，このコラムを読んでも何ら影響を及ぼさないだろう．実は私も著者とは同じ意見の部分もあるのだけに残念だ．
在庫推移監視方式
生産管理の説明で特徴があるとすれば，在庫推移監視方式という発注方式に関する説明だろう．これは，MRPのように自動的に発注を行うのではなく，在庫の将来的な推移を担当者が判断して発注を行う方式である．実は，MRPを使用していても，品目の情報に自動的に発注をしないというオプションを立てておけば，同様の運用は可能な事が多い．この方式自体は目新しいとは思わなかったが，この方式は決してMRPの管理よりも劣っているというわけではない，という根拠が述べられており，勉強になった．実際のところ，MRPを導入していると称している会社の多くはこのような方式で運用していることが多い．
ただ，気になったのは，確かに，MRPによってオーダーが現実的でないものに自動で変更されてしまうと，大きな問題を発生させるが，単なる勧告（前倒し勧告など）はあくまでも危険を知らせるメッセージにすぎないので，問題はないということである．この勧告に従って，在庫推移を監視し，作業者がオーダーを変更する，一つのトリガになりうると思うので，併用すべきだと私は思う．
- 作者: 渡辺幸三
- 出版社/メーカー: 日本実業出版社
- 発売日: 2002/10/10
- メディア: 単行本
- 購入: 7人 クリック: 50回
- この商品を含むブログ (21件) を見る
