ACCESSで400以上のフィールドがある場合の作成方法‥

質問

ACCESSでデータベースを作成していますが、入力する項目が計400程度になりそうなことが分かり、
色々調べた結果、テーブルを分けてクエリで結合というのがいいということで、
A（主要情報の入力テーブル。フィールド数200）
B（追記項目や詳細なオプション情報。フィールド数200）
の２テーブルまで作りました。
また、Bテーブルに全く情報を入れない場合もあります。

そこで質問させていただきたいのですが、それらを結合するにあたり、どのように関連付けすればよいのでしょうか？
Bには後でオプション情報を追記することもあるので、Aを入力した時点でBの空テーブルも作成できるようにしたいのです。
ただ、その場合のAとBテーブルの関連付けできる基本情報がないので悩んでおります。

どうぞ宜しくお願い致します。

回答No.7

gungnir7

設計上はもっと細かくテーブルを分けた方がいいような気がします。。。
１つのテーブルで15前後に押さえてテーブル数20～30というのが普通です。
１つのテーブルを巨大にしても項目を探すのが大変であったり、
少しの変更に時間がかかったりと硬直化しがちです。

関連付けは両方のテーブルで同一の項目を用意します。
仮に商品コードというキー項目があったとして、
ＡとＢに商品コードを用意します。

補足

アドバイスありがとうございます。

関連付けるべき項目を作らなければいけないのはこれまでの試行錯誤で分かったのですが、
ないんですね‥関連付けられそうな項目が。。

あるとすれば伝票番号なのですが、それを入力したら主にも副テーブルにも同じ番号が自動で入る方法はなさそうですし、難しいのですかね？やはりある程度は手動でしないと。

ありがとうございます！

回答No.6

noname#60992

皆様が回答されていることをまとめると、
例えばＡにオートナンバーの主ＩＤを作った際に、
ＢにＡのＩＤを入れるフィールドを用意すれば
よいだけです。　これはオートナンバーではなく、
長整数型などにしておき、データを入れる際に、
Ａテーブルとの整合性を保つように作ればよい
わけです。　
ただし、クエリのフィールド数も255なので、
ひとつのフォームの連結フィールドによって
指定できるデータ数は255です。
テーブルの設計はシステム上とても大切なこと
なので、ある程度理解してから事を進めないと、
もう一回作り直したいと思われることが何度も
おきると思われますので、大きなものに取りかかる
前に、しっかりと勉強なさってください。

お礼

> データを入れる際に、Ａテーブルとの整合性を保つように作ればよい
わけです。
確かにそうですね。自分でオートナンバーと同じ番号を入れればよい‥。
しかし入れ忘れたり、後で副テーブルのみを見た時の混乱が心配です。
できればAのデータ入力の時点でBにも同じものが入ればと‥。

とにかくアドバイスありがとうございます！

回答No.5

CHRONOS_0

どうやらテーブルを分けるという意味をよく理解しておられないみたいですね

（１）テーブル内に繰り返しがあるときは別テーブルに分ける
例　質問1、回答1、質問2、回答2、・・・

（２）主キー以外に従属するフィールドは別テーブルに分ける
例　売上ID、売上日、顧客ID、顧客名、顧客電話番号
の顧客名、電話番号

などの正規化規則に則って分けていくのですよ

フィールド数が多すぎる場合は(1)の繰り返しのケースが多いですね

お礼

> フィールド数が多すぎる場合は(1)の繰り返しのケースが多いですね
まさに仰るとおりです。この形ですね。
この（１）の場合の分け方で混乱しております。これを正規化‥できるのでしょうか‥。

とりあえず私のレベルが低いことだけは分かりました。。

回答No.4

m3_maki

> 色々調べた結果、テーブルを分けてクエリで結合というのがいいということで、

クエリにしたところで、
１レコードのフィールド数は 255 まで
という制限があることはご存知ですよね？
ちょっと心配になりました。

補足

知りませんでした‥。ありがとうございます！
しかしながら、クエリは恐らく255までは行かない形で作成できると思います。
勉強になりました。

回答No.3

noname#140971

＜主表＞
ID__フィールド_1__フィールド_2
1___F1_1____________F2_1
2___F1_2____________F2_2

＜従表＞
ID__主表_ID__フィールド_1__フィールド_2
1____2__________S_F1_1_________S_F2_2

＜主表 クエリ＞
ID__主表.フィールド_1__主表.フィールド_2__従表.フィールド_1__従表.フィールド_2
1___F1_1___________________F2_1
2___F1_2___________________F2_2___________________S_F1_1________________S_F2_2

SELECT 主表.ID, 主表.フィールド_1, 主表.フィールド_2, 従表.フィールド_1, 従表.フィールド_2
FROM 主表 LEFT JOIN 従表 ON 主表.ID = 従表.主表_ID;

※こういうテーブル設計になるかと思います。
※問題は、かかる主と従の関係を持つテーブルデータの管理要領が不明なこと。
※しかし、これはリレーショナル・データベースの基本中の基本。
※ヘルプの「Access データベースのリレーションシップについて」を一通り読まれたし。

回答No.2

umeume7777

「主キー」のみでＤＢを更新すればよいのでは？
項目を完全に２分化するのではなく、リレーションの取れる項目を作るのは必須ですよ。

補足

> リレーションの取れる項目を作るのは必須ですよ。
そうなんですよね。分かってはいるのですがどうすればいいのか‥。
Aの主キーをBの主キーにすることなんてできないし、かと言って関連付けられる情報も特にないし‥。

「主キー」のみでDBを更新すると、前述したようにBへの入力が無い時にはBは更新されないし‥。

ともかくアドバイスありがとうございました！

回答No.1

okg00

BにもAと同じ主キーのフィールドを用意すればよいのでは？

補足

オートナンバー型のものをBにも設けましたが、Bテーブルに関する入力が何もない場合、Bのオートナンバーが更新されず、Aとの整合性が取れなくなってしまうのですが‥。

オートナンバーが100番の場合、
Aテーブル情報のみに入力→Aは101へ。Bは100のまま、ということになってしまうのです‥。

仰っている意味と違っていたら申し訳ありません。