フィールド連鎖の有効性（マスタ・コードの一元性）について

MS-Accessなどで、フィールド連鎖の有効性を主張するのは、妥当なことだと思う。
また、マスタ・コードの一元性を主張するのもユニークという意味では良く分かる。
例えば、社内である商品の単価は一つであるべきである。

しかし、わたしの経験では資材の納入単価と経理上の仕入単価が違ったりして、資材には秘密というのが結構あるが、論外になる。
話を戻して、例えば依存関係から外れている商品マスタを、課長が休日出勤してメンテして別のコピーが持っているとか。
また、オペレータとバックアップ担当の引き継ぎなどを考えると、仕様レベルのプログラムやＳＥが問題を内包し、オペレータに変更の詳細部を告知ししないほうがトラブルが少ない。
そして、ＳＥデザイナは、常に仕様や仕様変更を書き留めるべきである。

マスタのコードは、トランザクション・入力オペレータよりは商品単価の管理は少ない人数でした方が良い。
同じ商品でコードが変われば、ファイルの依存（参照）関係（リレーション）を理解するプログラマがトランザクションのコード付け替えプログラムを走らせると、トラブルが少ない。多分、休日や夜間の仕事になる。

別の人間が依存関係から外れるマスタのセットやバックアップを持っていても対応は可能だし安心になる。
旧コードのトランザクションのデータ・ファイルがストッカーから出て来なくなるのを見計らって、旧コードを削除する。
===

リレーションシップのオプションについて

①参照整合性
②フィールドの連鎖更新
③フィールドの連鎖削除
---
①は、理解できるが、②,③は、このオプションの取り扱ったことが無いので違和感がある。
（何らかの理由で、リレーションシップが切れてるマスタのあった場合、問題ないのか？例えば、過去のバックアップを戻した時、コードに依存する参照関係には注意がいるのではないか？私は、あまり使いたくない。

便利な機能だが、普通はコードは変更したり、削除してはイケナイ。以前のコードはそのまま置いておいた方が良い。また削除する理由にも依るが、削除ではなく、マスタに新しいコードを採番し、トランザクションの方のコード付け替えのメンテ・プログラムを書いた方が、安全策！　管理者は、安易に使わない。要するに、このオプション使い方次第だと思う。良く分からない。）
===

データーベースの正規化

　タイトルのデーターベースの正規化については、Appendixに上げた本に書いてある。Microsoft Access2007用の教本ではあるが、プログラマの素養としてデーターベースのデザインには必須の内容で、特化したアプリケーションの構築に役立つ。この本は、資格取得用の教本で題記のテーマの一般的な事項として簡単で大変分かりやすく書いてある。　
　データーベースの第三の正規化までの記述と、MS-Accessをお持ちの方は、教本の前後の問題の演習をすると、アプリ構築の理解がより一層理解が深まると思う。
//Computer Science Technology JAPAN->atom() 2010/12/19 23:54

《Appendix》
『よくわかるマスター　Microsoft office Specialist Access2007 完全マスターⅠ（公認テキスト）・ＦＯＭ出版』（ISBN978-4-89311-868-4 C3055 \2200E）

データー・ベースレコードの更新処理

TITLE:データー・ベースレコードの更新処理

　先ず更新の為に一つ注意をしておきたいのは、題記のデーター・ベースレコードの更新処理で、更新は｛リード｝→｛アップデート｝と覚えてください。
　よく陥る罠は、同じキーのレコードを更新する場合、同じレコードを｛削除｝→｛追加｝となる。これは間違い。必ず｛リード｝→｛アップデート｝にして下さい。
初心者にこれが多いのは、キーでリードしてキー・アンマッチでエラーとなるのが怖い。
　この場合、リード・アンマッチ（エラー）の時は、レコードは追加になる。また、リード・エラーで無ければ、言い換えると同じキーのレコードがあれば、｛アップデート｝（更新）になる。

《追記》
・ 特に、主キーでリードをかけた時、キーがレコードになくエラーすなわちオペミスとするはまずい。（オペレターのせいではないので、安心してください。ＳＥのデザインが悪い。）
・ また、プログラマは、主キーがレコードに無いときのエラー処理は必ず丁寧に処理をしてください。
・ 後者（レコードの｛削除｝→｛追加｝）のデメリットや、サンプル・ソースなどは機会があれば．．．（言語は要望に応じます。）//