テーブルの設計 その６”最終チェック”
■ 最終チェックするコト
マスターの設計を終えたら、下記のチェックを行います。
違和感が無ければ、設計としては完了とします。
テーブル名と項目名に違和感が無いか？
計算速度と検索速度は満足できるか？
ま、この２つです。
前回までの設計段階でほぼ完成されているからです。
本来なら、チームで設計してチェックする人がいるのが当たり前ですが、
要件定義～設計～実装～運用 まで全部一人ですからね（汗）
■ テーブル名と項目名に違和感は無いか？
これ、何気に重要です。
なぜって、後から変更するのが出来ないからです。
（いや、時間さえあればできますよ！時間が無限にあれば！）
ですから、名前と内容に違和感が無い事をもう一度考えます。
名前って重要ですよ。
テーブル名とデータの内容
矛盾があると思ったら思い切って書き直しします。
後からテーブル名を変更すると、痛い目をみることに。
設計段階で確定させることが開発スピードを速めるコツになります。
項目名と項目の内容
テーブル名同様に進めます。違和感があれば修正します。
■ 計算速度と検索速度は満足できるか？
所詮は、Access。
所詮は、業務用ＰＣ。
その中でも耐えられるパフォーマンスを出す必要があります。
考えるのは、２つです。
1. 主キーとインデックス
ま、検索、集計する項目は、迷わずインデックスを付けましょう。
ただ、デメリットがあります。
インデックスが多いテーブルに対して、データの追加・変更・削除するとき、時間がかかる。（あまり気にしないが💦）
それより問題になるのは、テーブルのサイズ（ファイル容量）がインデックスの数だけ多くなることです。
テーブルにインデックスを設定しないと速度が向上しない。
インデックスを設定するとファイルサイズが大きくなる。
この２つの問題を解決する方法があります。
ファイル分割
例えば、「マスター系」「トランザクション系」「アプリ系」でファイル分割したり、最悪は、「テーブル、１つに、ファイル、１つ。」にします。
この方法で、ファイル馬鹿デカ問題は回避できます。
今回の事例は、そんなデータが多くなることは無いと思い分割はしていません。
仮にファイル分割する必要が出てきた場合も、さほど問題になりません。
テーブルを張り直すだけですみますから、軽微な問題です。
（※ VBAでDAOを使っていないことが前提になります）
2. バックアップという考え方
ＤＢ設計における「バックアップ」の意味は、もしもの場合のファイルを退避（コピー）して、復旧できるようにする意味ではありません。
ＤＢ設計における「バックアップ」とは、トランザクションデータにマスターデータのコピーする事を意味します。
よく、リレーションシップでマスターデータを読み込むことで、単価情報とか品名を取得できます！
って言いますよね。
ま、イイですよ、小っちゃいＤＢなら。それで。
ただ、この方法は、Accessでシステムを作る場合、非推奨です。
Accessでシステムを作る場合は、その時点のマスターデータをまるまるトランザクションテーブルに保存する方法を推奨します。
この手法を「バックアップ」といいます。
次のようなメリットが出ます。
・トランザクションテーブルの検索速度向上
・ソースコードが簡略化できる
特に、速度向上に大きな期待ができます。
可能であれば、マスターデータを全てトランザクションテーブルに追加してしまうことをお勧めします。
■ テーブルの設計段階は、ここでおしまい
大変長くなりましたが、テーブルの設計としては、６ステップになります。
この手法は、私が長年Accessでシステムを作る過程で、会得したもので、誰から学んだ技術ではないです。
（ま、一部、書籍から取り入れた部分もあります。）
だから、素人が作るシステムの場合に限定して下さい。
テーブルの設計に正解は正直無いと思っています。
が、間違いはあると思います。
失敗しないテーブルの設計 で悩んでいる人が多いのではと思って、
テーブルの設計に関しては、結構厚く記事にした感じです。
ワイの記事からテーブルの設計が出来るようになる人が出てくれればと思います。
余談ですが、私が最後にAccessの書籍を購入したのは、１０年より前の話です。
ADOについて学び買った為に、Accessの書籍を買ったのが最後になります。
ただ、Accessの書籍で、「テーブルの設計」について、詳しく書いてある書籍は少ないと思います。
テーブルの設計が鬼門になって、Accessを諦める人も多いと思っているのもあります。 この件は日記の記事にしようかな（笑）
次も設計段階になります。
ここまで読んでいただき、ありがとうございました。
この記事が気に入ったらサポートをしてみませんか？