なんか、昔書こうと思ったネタ。
ただ、そのとき、目次を書いていたかもしれないけど、その目次とは違ってしまうかも知れないですが、ご了承くださいませ。手法は、まったく同じです。
なお、書く必要はないと思いますが、Ａｃｃｅｓｓとは、マイクロソフトのＡｃｃｅｓｓのことで、NetFrontを出している会社のAccessとは、何一つ関係ございません。念のため。
■■ 前提条件
Ａｃｃｅｓｓが使えること（フォーム、レポート、テーブルが作成できる）
ＡｃｃｅｓｓのＶＢＡが書けること
正規化の知識はあってもなくてもＯＫ！
■■ Accessでの一般の開発
まずは、一般的なＡｃｃｅｓｓの開発。
以下の「定期券の作成」を例に説明します。
＜＜例：定期券の作成＞＞
定期券を印刷する。項目は以下のとおり
定期券番号
種別（通勤、通学）
期間（１，３，６）
出発駅
到着駅
経由
開始日
終了日
金額
年齢
性別
発効日
名前
発行駅
●通常の方法
１．ＡｃｃｅｓｓはＲＤＢなので正規化する
駅テーブル
経由テーブル
顧客テーブル
定期券テーブル
に分かれる（なお、この条件だけでは正規化の対象から外れるが、期間テーブルと、種別テーブルも作成可能。さすがに、性別テーブルを作るやつはいないと思うけど）
２．そのテーブルをＪＯＩＮするためのビューを作る（定期券ＶＩＥＷ）
３．帳票を作成する（定期券ＶＩＥＷを参照する）
４．お客さんのＯＫを得る。得られなかったら、１に戻る。
というようになる。
この場合、定期券のように簡単なものならいいけど、複雑なものはすぐに正規化できないし、これは、すでに決まっている定期券をだしているからいいけど、お客さんの帳票を出す場合、これで出来上がってからＯＫをとる。で、もし、仕様変更となったら。。。またＤＢから考え直して。。正規化して（＞＿＜）となり、時間がかかる。
とっさにはできない。
その上、複数帳票あったら、１つの帳票変更により、正規化したＤＢもいろいろ移り、それが、現実的には、他のプログラム（ＶＩＥＷ）にも、問題を派生してしまうかもしんない（論理的には、この影響を受けないのがＤＢの特徴だが、Ａｃｃｅｓｓはうける。理由はあとで説明できたらする。次回になるかも）。
■■ Accessでアジャイル
では、これを、ウィリアムのいたずらならどうするか。
１．上記項目を項目名とし、そのまま１テーブルにしてしまう。
テーブル名：定期券レポートテーブル
→レポートとつけるところがみそ
２．ここからウィザードなどを使って、帳票をつくる
自動的に作った後、きれいにおきかえる。
３．ここでお客さんのＯＫをとる。
だめなら、１にもどるが、、実際は、お客さんのところにパソコンを持っていき
フォームをいじりながら、２で画面イメージを作ってから、１を調整する
→うそつけ（＾＾；）
本当は、お客さんに２の帳票を作っておいてもらって、１のテーブルを
後から作ってる（＾＾；）
４．全部の帳票ができてから、正規化した、テーブルを作成し、
メニューのフォームを作り、
メニューフォームで、この定期券印刷のボタンが押されたら、
・１．のテーブルの内容を削除し
・正規化したテーブルから、データを取り出し、
・１のテーブルに入れ、
・印刷する
ＶＢＡのプログラムを作成する
このプログラムは、だいたい似たような形になるので、製作しやすい
たぶん、みんなのほおけたすがたが、めにうかびます。
はあ、じゃあ、受注票をつくるときは、受注票レポートテーブルを作るの？
そうです
はあ、じゃあ、納品書をつくるときは、納品書レポートテーブルを作るの？
そうです
はあ、じゃあ、ピッキングリストをつくるときは、ピッキングリストレポートテーブルを作るの？
そうです
（注：ピッキングリストとは、空き巣に入るための無用心な家のリストという意味
。。じゃなくって、出荷等する際、出荷先に応じて、今回出荷するものが書いてあって、そのリストに沿って、倉庫からモノを取り出す（ピッキング）するためのリストのこと）
でも、Ａｃｃｅｓｓでの正規化論者は、次の言葉を言ったとたんに詰まる。
はあ、じゃあ、受注票入力フォームをつくるときは、受注票入力フォームテーブルを作るの？
そうです。。。作らないで、あなた、どーやってやる気なんですか？？
■■ Ａｃｃｅｓｓの場合、１フォーム１テーブルにしないと困ることがある
もし、作らないと、ＶＩＥＷをつくり、それとフォームを連結させ、入力することになる。しかし、ここで、困った問題が起こる。このようなつくりにすると、Ａｃｃｅｓｓの場合、ＶＩＥＷから勝手にテーブルに直接追加できてしまったりするのだ。。
ＯＫボタンを押してないのに。。
そりゃーまずいでしょー（＾＾；）
っていうことで、いったんデータをためて、ＯＫボタンを押してから、テーブルに書き出すってするようにしないと、まあ、まずいよね。。
ほら、そーすると、ウィリアムのいたずらが提案した方法になっちゃうのよ。
で、そーすると、フォームが、このようにやるなら、帳票だって、こーやったっていいよね。
つーことで、ウィリアムのいたずらの方式でも、そんなにおかしなことをやっていないことになる。
■■ では、なぜこんな問題が起こるのか？
じゃあ、なんで、こんな問題が起こり、ウィリアムのいたずらが提唱するように、
１フォーム、１レポート１テーブルにして、
お客さんからの合意を取って、テーブルとレポートが完成してから、
正規化したデータベースから、データを取ってくるプログラムを作ったほうが
いいといえるのか？
っていうことだけど、これは、大きな勘違いから起きている。
それは、
ＡｃｃｅｓｓはＲＤＢである
という前提に立っているということだ。
もしそうなら、ＲＤＢなので、まず正規化してテーブルを作ってという流れになる
これに問題はない。
しかし、ほんとーに、ＡｃｃｅｓｓはＲＤＢなのかあ？？
たしかにＲＤＢの機能もあるが、もし、ＲＤＢ以外のものも含んでいたら、その機能を使う分には、正規化理論を適用する必要はない。ＲＤＢでないのだから。。
ということで、ＡｃｃｅｓｓはＲＤＢなのか？という、すんげい昔、「桐はＲＤＢなのか？」というのと、おんなじような話題を展開しようとしているところではあるが、この話をすると、えらい長そうなので、ここで今日のところは、切っておきます。
アクセス
トータル
ランキング
