IEにoffice2010のリボンをつけてほしい！

左の図はOFFICE2010（EXCEL）の画面。
図の赤枠内のようにリボン部のアイコンが伸展/圧縮すると便利！
※IEにも、是非この機能をつ付けて、ほしい！
/~atom() - February 14, 2011

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

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:データー・ベースレコードの更新処理

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

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

My Program Source

　左の図は、Windowsの画面からマウス操作イベントを受け取り処理をするVisual Basic．NETのプログラムです。

　前掲と比較の対象には、なりませんが、Program Sourceの違いは、直感的に、おわかりになるでしょうか？参考まで．．

~atom() - 2010/07/20 6:59

半自動化した不可読性の怪獣の正体！？

今日は、海の日也！

これが、現在世界中でもっとも多く使われているというプログラム・ソースコードの正体になる。怪獣になる。

システムというのは、統制を取らないと、この様に無惨な仕事の結果となる。（面白い・金になるでは、収集が着かない。整然としているのは、表向きだけになる。）
現代っ子プログラマは、ほんとうに気の毒になる。
ただ、プログラマとて知っていて黙っている男は、決して戦争の悲惨さを語ろうとしない、慈善家にも等しい。忙しく、手に負えないではなく、問題認識としてのエントリだけでもほしい。それが、民主主義の基本だと、信じている。（ほんとは、気になってはいるとか？　）・お願いだから！

それは、実際に、社会のポリシーは、常に不用意な残業代の支払いを拒否する。また、あなたの奥さんや子供が、現実に扱っているソースが如何に難解かに興味はなく、予定通りの将来設計を望んでいる。（それは、ウチの娘に聞いてほしい。）
暗黙の反響．．．場合によって、システムとは何かという再度・論議が必要か？という議論の方も気になる。~atom()。。。