| |
気になった点があります。
>１対１結合なんですが、T発送テーブルに○年お歳暮、○年年賀状・・・とフィールドを追加していく>ので、顧客フィールドのインデックスは重複なしにして結合しましたので１対１となっております。
データベースは、データは縦へ延ばしていくものです。
横へ延ばしていくようなテーブル構成にしてはいけません。
その理由ですが、第一に、各オブジェクトのプロパティには、
フィールド名を使うものがたくさんあります。
フィールドを新設すると、それらのプロパティを再設定しなければならなくなります。
ただ、そういうプロパティはいろいろあり過ぎるので、どのプロパティを再設定すべきかは
直ちにはわかりません。
いろいろと動かしてみて、不具合が出たら直すということにならざるを得ません。
もっとも、そんな悠長なことはしていられません。
結局、クエリ、フォーム、レポートなどを一から作り直すのが最も手っ取り早いということになります。
しかし、フィールドを新設する都度、クエリ等を一から作り直すというのは面倒です。
だから、フィールドをあとで追加するようなテーブルにしてはいけないのです。
第二に、アクセスは、
縦に並んだものの中からある行、つまりレコードを抽出することは得意ですが、
横に並んだものの中からある列、つまりフィールドを抽出することはできません。
上例で、ある顧客について、発送したのはいつだったかなと調べようと思っても、
該当するフィールドを抽出することはできません。
第三に、横へ延ばしていくようなテーブル構成は、データベースとしてルール違反であり、
このデータベースにさらにいろいろな機能を盛り込みたいと思った場合、このルール違反のため、
機能拡大ができなくなる、あるいは無駄に手数を要することになってしまいます。
では、テーブル構成をどうすべきかですが、T発送テーブルは、
発送ID オートナンバー又は長整数型 （主キー）
顧客番号 長整数型
発送年 整数型 「○年お歳暮」における「○年」を格納する
発送事由ID 長整数型
とし、さらにT発送事由を設け
発送事由ID オートナンバー又は長整数型 （主キー）
発送事由 テキスト型 「○年お歳暮」における「お歳暮」を格納する。
とするのがいいと思います。
T発送事由を設けるのは、
テーブル設計では、あるフィールドにおいて同じ値となるレコードが存在する場合は、
そのフィールドを別テーブルにするというルールがあるからです（テーブルの正規化）。
|
|
かるびの
- 14/11/28(金) 0:24 -
![[未読]](./data/access/image/read_icon.gif){kind=icon}
