- ベストアンサー
ACCESS ご教授お願いします。
ＡＣＣＥＳＳで、データベースを構想、作成中なのですが・・・ 初歩でつまづいております。 できますれば、ご教授お願いします。 前説ですが、 まず複数の商品を、『商品ＩＤ』としてテーブル登録しています。 例： 『商品ＩＤ』 商品ＩＤ（主キー）／ 商品名 ／ 製造元 ／ 詳細（商品簡易識別） 0001 ／ ノートＫ1Ａ4 ／ コ○ヨ ／ 文具01 0002 ／ ホチキスＫ1 ／ コ○ヨ ／ 文具02 0003 ／ 水銀電池Ｐ2064Ａ ／ パ○ソ ／ 電池02 ・ ・ 上記の『商品ＩＤ』に付加して、 取扱いしている『（販売）部門』（文具・雑貨・書店・日用品等々）を登録したいと 考えているのですが、商品を取扱いする『部門』は１商品に対して複数になる場合があります。 また、増減するものですので、『商品ＩＤ』テーブルに登録しても、うまくいきません。 別テーブルにて『部門ＩＤ』というのを作成し、 『部門ＩＤ』 部門ＩＤ（主キー） ／ 部門名 部01 ／ 文具 部02 ／ 雑貨 部03 ／ 書店 部04 ／ 日用品 ・ ・ というものを作成してみたのですが、肝心の『商品ID』と リンクするイメージが全く沸きません。（T。T）トホホ 各商品が登録増減する『部門』に対して、商品登録状況が わかるような方法はどういった方法ものがあるのでしょうか？ イメージ的にはリレーションシップにて 部門ＩＤ 部門01 ・・+商品0001 ・・+商品0002 ・・+商品0003 となるのでは？と思っているのですが。よろしくお願いします。
- yama_saku
- お礼率62% (5/8)
- その他(データベース)
- 回答数4
- ありがとう数2
- みんなの回答 （4）
- 専門家の回答
質問者が選んだベストアンサー
取扱テーブルを作ったらどうでしょうか。 取扱いテーブル 商品ID ｜ 部門ID 主キー (商品ID + 部門ID) 部01 | 0001 部02 | 0002 部03 | 0001 部03 | 0003 ではダメですか？
その他の回答 (3)
- nda23
- ベストアンサー率54% (777/1415)
肝心なポイント 商品：部門 の関係は１：ｎ、ｎ：１、ｎ：ｎ のどれでしょう？ 関係が分からなくては設計できません。ｎ：ｎの以外ではｎ側から １側を参照するようにして、リレーションシップを構築できます。 ｎ：ｎの場合、設計基準が間違っています。つまり、商品も部門も マスタで、「取り扱い」という別の実運用データがあるということに なります。こういうデータモデルが抜けているのです。目先を凌ぐ ことは既に出ている回答で可能ですが、モデル化を正しく行い、 検討（できれば権威者に見てもらうと良い）したうえで、実現する 手順を守るべきかと思います。
お礼
アドバイスポイントありがとうございます。現時点で構想中なのは 質問時のとおりです。権威者？は「なんでもできるように」と 非常に大まかな回答なので、模索しながら作っているのが現状です。 この後にリンクしてくる、テーブルなども一応考察してはいます。 （動くとかどうかは、まだまだ、お先のお話で・・・） よくよくチェックしようと思います。 とりあえずは、部門と商品の関連付けは、ご返事いただきました 回答にて解決できました。ありがとうございます。
回答は既に出ているようなので、若干アドバイス １．主キー 主キーは「データの二重登録を防ぐ」ために活用しましょう。「商品名」と「製造元」の用に二つ以上のフィールドにまたがって設定することもできます。誤った二重登録は判り難いバグの原因になったり、データの修正に苦労したりします。 ２．リレーションキー 「商品ＩＤ」などを利用しましょう。オートナンバー（型）にしておけば、後はアクセスが面倒を見てくれます。主キーを使うのは避けた方がよいと考えています。例えば「部門名」を「取り扱いテーブルの」関係キーに使うと、部門名が変わったときに困ります。どうしても使いたい場合は「参照整合性制約」を取りましょう。
脇から口出しすることをお許し下さい。No1さんのおっしゃるように 取り扱いテーブルをつくります。ここで部門IDと商品識別名の関係を決めます。たとえば、次のように。 部01 ノート 部02 ほうき 部04 トイレットペーパー 部01 シャーペン 部03 週刊誌 部01 ホッチキス
お礼
お返事おそくなり、申し訳ありません。イメージできなかった 取扱テーブルを作成して、連結することが出来ました。 ありがとうございます。