しいたげられたしいたけ

自助してない奴はいない!

この2週間ほどAccessの復習に追われている

ほとんど忘れていたので「にわか勉強」と言った方が実態に近いかも知れない。
小規模な事業所があって、基幹システムをAccessで構築しているのだが、そのシステムを一人で担当していた社員が「心を病んで」退職してしまったという。
事業所ではあわてて後任の人身御供を一人選び、システムを押しつけようとした。詳しい経緯は省略するが、巡り巡ってその相談が私のところまで来たというわけだ。
退職した前任者が1年がかりで立ち上げたシステムは、他人が見ても理解できないし何より使いづらいので、新規にシステムを構築してもいいとのことであった。
mdbファイルを見せてもらった。絶句した。言いにくいんだけど、その前任者さんは「主キー」とか「(第1〜第3)正規化」とかのデータベース理論の基礎的概念を、全くご存知なかったとしか思えないのである。
Accessを知っている方なら一目瞭然でおわかりいただけるよう、またAccessを知らない方でもなんとなく状況を理解いただけるように、前任者さんの残したmdbファイルのリレーションシップと、後任の人身御供さんとともに四苦八苦しながら再構築しつつある新システムのリレーションシップを、それぞれスケルトンだけ示してみたい。

(↑現行システム)

(↑改良中のシステム)
現行のシステムでは、レポート機能を使って請求書や領収書をプリントアウトしようとするたびに、商品コードと商品名を入力しなければならないという。そして入力した商品名は、その都度テーブルに重複データとして残されていくようになっている(←データベース理論からすると明らかに間違ったシステムなのです)。
一方、後任者さんとともに立ち上げ中のシステムでは、そんなことはない。つかきわめて教科書的なリレーションシップになっているはずだ。つか商用システムであれば、特殊な例外を除いて、基本は「商品テーブル」+「売上テーブル」+「顧客テーブル」というワンパターンに落ち着くはずなのだ(どんな例外があるか、いい例をすぐには思いつけないくらいだ)。
前任者さんというのは、VBAを使ってエクセルのマクロを書きまくっていたりもしていて、かなりのパソコンのスキルを持った人だったらしい。「心を病んだ」という退職の原因がこの基幹システムにあるのかどうかはわからないが、もしそうなら由々しきことである。きわめて残念つか、もったいないことである。特定できないように肝心のところはぼかして書いたつもりだけど、守秘義務違反ギリギリだという自覚はある。しかし弊ブログでも検索で飛んできて参照してくださる方がけっこういらっしゃる(最近では「ウイルスキラー」+「2008年版」が多い)。だから、ひょっとしたら何かの役に立ててくださる方がいるかもしれないので、あえて書いておきます。Accessをいじるのであれば「第1正規化」・「主キー」・「第2正規化」・「第3正規化」という概念を勉強してください。初級システムアドミニストレータ試験にも出てくる初歩のデータベース理論の概念です。初級シスアドはもうすぐ名前が変わるんだったっけ?とにかくそんなに時間はかからないはずです。