ACCESSの初心者質問(テーブル設計)

質問

こんにちは。表題の件アドバイスいただければ幸いです。
ユーザからの問合せ管理システムを作っていますが、その中で
カテゴリの項目群があります。（親、子、孫の3階層です）

フォームの中で。大カテゴリ（親）＞中カテゴリ（子）、小カテゴリ（孫）の順に絞り込んでいくのですが、カテゴリのテーブルを以下のように作成しました。（テーブル名：項目名）
大カテゴリ：大カテゴリ
中カテゴリ：中カテゴリ、大カテゴリ
小カテゴリ：小カテゴリ、中カテゴリ
中カテゴリ、小カテゴリを絞り込む際、それぞれ、上位カテゴリの値を参照して絞り込んでいきます。
ここからが質問です。

大カテゴリ、中カテゴリ、小カテゴリ　の項目を
1.問いあわせ管理テーブルの中に作るべきか
それとも、
2.「問合せ管理番号、大カテゴリ、中カテゴリ、小カテゴリ　」と、カテゴリテーブルを独立させて作り、メインの問合せ管理テーブルとリレーションをはるべきか

前者を選択して作っていたところ、ACCESSの達人のユーザから
　「お前はなんて無駄なことをしてるんだ、正規化しなさい。
　データベースの教科書を読んで理解できるまでは使うな」
と言われました。

悩んだ末、考えたのが
大、中、小のカテゴリをひとつのテーブルにし、組み合わせ番号をキーとして、「問合せ管理テーブル」にキー項目を入れる、というやり方です。パフォーマンスはあがりましたが、フォーム上での
大＞中＞小の絞込みの方法が分かりません。
（大、中、小のクエリを作って、フォームに取り込む、という方法をとってみましたが、うまくいきませんでした。）

おそらく、基本的な正規化の理解ができていないため、右往左往しているのでしょう。どなたかアドバイスいただければ幸いに存じます。

回答No.3

nag0720 · ベストアンサー

＞最初「達人」からは「重複がないからコード化しなくていいのでは」といわれ、コード化しませんでしたが、やはり不安なのでこの週末にコード化しました。

コード化にはメリットもありますがデメリットもあります。
メリットについては分かっていると思いますので、デメリットを簡単に説明します。

いったんコード化するとそのコード体系は簡単には変えられないという問題があります。
コード化する分類が固定したものならいいのですが、頻繁に変動する場合は、将来を予測してコード体系を決める必要があります。例えばコードの桁数を２桁にしていたのに分類数が増えたために３桁にしなければならなくなったとき、影響するプログラムやデータファイルをすべて調べて修正する必要がでてきます。
また、コードの追加は簡単ですが、もう使わないからといってコードを削除する場合は注意が必要になります。
そのコードを使っているデータファイルがある場合は簡単には削除できません。
そのため、不要になったコードを削除できず、処理に時間がかかったり、選択リストに本来必要のないカテゴリーが出てきて選択操作に手間がかかったりなど無駄な処理をしてしまう恐れがでてきます。

もしかしたら、「達人」はそのへんも考えて「コード化しなくていい」と言ったのかもしれませんのでコード化する場合はよく考えてください。
それはそれとして、コード化する場合の注意点を述べます。
「達人」が言っているとおりデータに重複がない場合またはあっても重複の程度が少ない場合はコード化する必要がありません。
ただ今回の場合は、大分類、中分類に重複があるとして、コード化してみます。（大カテゴリという言葉が使いづらいので大分類と書きます）

通常、大分類、中分類、小分類とある場合は次の３つのテーブルに分けます。

大分類テーブル（項目名）
　　　大分類コード(CODE1)
　　　大分類名　　(NAME1)
中分類テーブル（項目名）
　　　大分類コード(CODE1)
　　　中分類コード(CODE2)
　　　中分類名　　(NAME2)
小分類テーブル（項目名）
　　　大分類コード(CODE1)
　　　中分類コード(CODE2)
　　　小分類コード(CODE3)
　　　小分類名　　(NAME3)

例えば、
大分類テーブル
　　CODE1　NAME1
　　　　a　　　　動物
　　　　b　　　　魚介類
中分類テーブル
　　CODE1　CODE2　NAME1
　　　　a　　　　　a　　　　猫
　　　　a　　　　　b　　　　犬
　　　　b　　　　　c　　　　魚
小分類テーブル
　　CODE1　CODE2　CODE3　NAME3
　　　　a　　　　　a　　　　　b　　　　シャム猫
　　　　a　　　　　b　　　　　a　　　　チワワ
　　　　b　　　　　c　　　　　c　　　　イワシ

選択リストに作成するデータは、
大分類選択リストは、大分類テーブルのデータ全部
中分類選択リストは、中分類テーブルの中から、選択された大分類コードのデータ全部
小分類選択リストは、小分類テーブルの中から、選択された大分類・中分類コードのデータ全部

こんな感じで分かりますでしょうか。

お礼

具体的なアドバイスありがとうございます。コード化のデメリットについてと言う点を念頭に置き、仕切りなおして進めたいと思います。

結論
問合せ履歴管理テーブルへ持たせるデータは、「小分類（カテゴリ）テーブル」のみでよい。
小カテゴリの属性「中カテゴリ」「大カテゴリ」のデータは、問合せ履歴管理テーブルへは入れず、リレーションを利用してクエリで参照する
大、中、小カテゴリテーブルは、リレーションにて参照整合性を維持する

回答No.2

nag0720

書いていることがよく分かりません。
テーブルを複数作成してそれぞれを関連させるには、項目のコード化が必要です。（正規化する上では必須です）

＞（テーブル名：項目名）
＞大カテゴリ：大カテゴリ
＞中カテゴリ：中カテゴリ、大カテゴリ
＞小カテゴリ：小カテゴリ、中カテゴリ

この小カテゴリ、中カテゴリと書いているのはカテゴリコードのことなのか、カテゴリ名のことなのか、それとも両方なのか。

また、検索項目の指定の仕方は？
名称の手入力なのか、リストからの選択なのか。
リストからの場合は、中カテゴリ、小カテゴリはそれぞれ絞り込まれたリストになっているのか。

問合せ管理テーブルってなに？
問合せする際の中間テーブルのことなのか、問合せ結果のテーブルのことなのか、それとも、問合せの履歴を管理するテーブルのことなのか。
それによっても構造や必要項目が変わってきます。

問合せ管理番号ってなに？
組み合わせ番号ってなに？

もう少し整理して、他の人にも分かる言葉で具体的に質問しましょう。

補足

ありがとうございます。
＞問合せ管理テーブルってなに？
エンドユーザ（お客様）からの質問や問い合わせ（インシデント）を
管理するシステムです。okwebみたいなものです。
問い合わせ管理番号は個々の問い合わせレコードに付与するキー項目（ユニーク）です。

＞小カテゴリ、中カテゴリと書いているのはカテゴリコードのことなの＞か、カテゴリ名のことなのか
カテゴリ名のことです。入力フォーム上からは、
大カテゴリ、中カテゴリ、小カテゴリ　の順に、リストから選択します。
中、小カテゴリは上位カテゴリで絞り込んだ結果の対象だけが表示されます。最初「達人」からは「重複がないからコード化しなくていいのでは」といわれ、コード化しませんでしたが、やはり不安なのでこの週末にコード化しました。

組み合わせ番号：カテゴリ（大、中、小）の組み合わせのパターンそれぞれにコード番号を付与しようという発想から考えた項目です。
　例）コードaba：動物、犬、チワワ
　　　　　　aab：動物、猫、シャム猫
　　　　　　bcc：魚介類、魚、イワシ
abcの例で言うと、大カテゴリ（動物）、中カテゴリ（犬）、小カテゴリ（チワワ）です。それぞれにはアルファベットのコードを付与します。
もうひとつのデーブル構成案は以下のように考えています。
中、小のカテゴリの二項目（-*）には、上位カテゴリのコードを付与
　　　　大カテゴリ[2](a,b) /*動物、魚介類*/
中カテゴリ[2](a-a,b-a,c-b)　/*猫、犬、魚*/
　　　　小カテゴリ[3](a-b,b-a,c-c) /*チワワ、シャム猫、イワシ*/
上位カテゴリコードはカテゴリを絞り込み表示する際に、参照

さらに、問い合わせ履歴管理のテーブルの「キー項目」（問い合わせ管理番号）＋
大カテゴリ、中カテゴリ、小カテゴリ　のテーブルを、別個に生成させようと思います。
＜テーブルA＞
問い合わせ管理番号、ユーザ名、質問内容、日付、担当者
＜テーブルB＞
問い合わせ管理番号、大カテゴリ、中カテゴリ、小カテゴリ

テーブルAとテーブルBは、問い合わせ管理番号でリレーションされている

他に不明点がありましたらご指摘ください

回答No.1

lv4u

>>　「お前はなんて無駄なことをしてるんだ、正規化しなさい。
　データベースの教科書を読んで理解できるまでは使うな」
と言われました。

とりあえず、データベースの教科書は読みましたか？
ここに質問するまえに、ACCESSの達人さんの指示に従いましょう。

お礼

ありがとうございます。

「達人」の方は業務の介入権限がないので、あまり深入りさせることはできないです。その方の業務を阻害するので、、。また、納期も近いのであまり時間をかけるわけにもいきません。

データモデリング入門（根本和史）を読み、リレーションと、正規化については学習あつましたが、理想的には第三正規化まで進めるべきとのこと、それに従うと、カテゴリと問い合わせ番号のテーブルは分離したほうがよいかな？という気がいたします。