Access VBA質問箱 IV

当質問箱は、有志のボランティア精神のおかげで成り立っています。
問題が解決したら、必ずお礼をしましょうね。
本サイトの基本方針をまとめました。こちら をご一読ください。

投稿種別の選択が必要です。ご注意ください。
迷惑投稿防止のため、URLの入力を制限しています。ご了承ください。

  新規投稿 ┃ツリー表示 ┃一覧表示 ┃トピック表示 ┃検索 ┃設定 ┃過去ログ ┃ホーム  
1727 / 2272 ﾂﾘｰ ←次へ　｜　前へ→
▼ 【5563】テーブルの作り方 buti 05/7/6(水) 16:27 質問[未読]
【5564】Re:テーブルの作り方 小僧 05/7/6(水) 17:27 発言[未読]
【5567】Re:テーブルの作り方 buti 05/7/6(水) 22:25 質問[未読]
【5569】Re:テーブルの作り方 小僧 05/7/7(木) 10:20 発言[未読]
【5572】Re:テーブルの作り方 buti 05/7/7(木) 11:56 お礼[未読]
【5563】テーブルの作り方
質問  buti  - 05/7/6(水) 16:27 -
引用なし
パスワード
   こんにちは。

ちょっと質問するのも恥ずかしいのですが

テーブル1
ID（主キー）
フィールド1
　　・
　　・
　　・
フィールド120
のようにテーブルのフィールド数が多い場合
ある程度のグループ？に分け

テーブル1　　　　 テーブル2　　　　 テーブル3　　　　 テーブル4
ID（主キー）　　　ID（主キー）　　　ID（主キー）　　　ID（主キー）
フィールド1　　　 フィールド31　　　フィールド61　　　フィールド91　　　
　　・　　　　　　　　・　　　　　　　　・　　　　　　　　・
　　・　　　　　　　　・　　　　　　　　・　　　　　　　　・
フィールド30　　　フィールド60　　　フィールド90　　　フィールド120

のように分けテーブル1のIDにテーブル2〜4のIDをリレーションで結ぶという
ようなテーブルの作り方はＯＫなのでしょうか？

よろしくお願いします
【5564】Re:テーブルの作り方
発言  小僧  - 05/7/6(水) 17:27 -
引用なし
パスワード
   ▼buti さん：
こんにちは。

ご質問の内容は「テーブルの正規化」という事ですね。
Web で検索すると色々出てきますので参照してみて下さい。


テーブルを設計する際には、関連づけられる項目ごとに
テーブルを分ける事が一般的です。

例えば会社の同僚の住所録テーブルを作成するとすると、
会社の情報（社員コード、部署、役職など）と
プライベートな情報（血液型、住所、電話番号など）は別テーブルになります。

会社で昇進や転属があった場合、部署、役職などの変更はあっても
血液型が変わる事はありませんよね？

1つのテーブルに全ての情報を持たせてしまうと、
その人の会社に関するデータを更新したくても
全てのデータを引っ張ってきてしまうので、
あまり効率的ではありません。

逆に「社員番号xxxxのデータを全て見たい」などの場合には
同じIDで結び付けられた社員をテーブル毎に参照しにいくので
この場合は1つの大きなテーブルがあった方が効率が良くなります。

一般的にですが、正規化を進めれば進めるほど
更新は早くなり検索に時間がかかると言われているようです。

適度（これが一番難しいですよね…）な所まで正規化を進めていきましょう。
【5567】Re:テーブルの作り方
質問  buti  - 05/7/6(水) 22:25 -
引用なし
パスワード
   ▼小僧 さん：

こんばんは。返信ありがとうございます。

>ご質問の内容は「テーブルの正規化」という事ですね。
>Web で検索すると色々出てきますので参照してみて下さい。

正規化についてはMS社他のwebでの例題ではなんとなくわかるのですが
自分のテーブルで考えると難しいです(ToT）

一応、T家族、T銀行、T支店、T地区のようにIDを別につけられるものは
出来るだけ分けています。
それでもT会員のフィールドが多いです。

>例えば会社の同僚の住所録テーブルを作成するとすると、
>会社の情報（社員コード、部署、役職など）と
>プライベートな情報（血液型、住所、電話番号など）は別テーブルになります。

この場合は、両方に社員コードを持つと考えて良いのでしょうか？

ちょっと意味合いは違いますが、今回の質問もちょっと似ている？
と（何となく）思います。

>1つのテーブルに全ての情報を持たせてしまうと、
>その人の会社に関するデータを更新したくても
>全てのデータを引っ張ってきてしまうので、
>あまり効率的ではありません。

似たような思いからテーブルを分けてみようかなと思ったわけです。
が、webで見た例題でも今回の質問のように
　テーブル1　ID ------ テーブル2　ID
　テーブル1　ID ------ テーブル3　ID
　テーブル1　ID ------ テーブル3　ID
と一つのIDでいくつものテーブルとつなげているものが見当たりませんでした。
他にもT会員とリレーションで結んでいるものがあるので、実際にはもっと
増えます。

webの例題であまり見かけないことなので、同じIDをそれぞれにもたせて
テーブルを分割する方法はどうなのか？（まずいのか？）という思いから
質問をさせていただきました。

一つのIDでいくつものテーブルとつなげるというのはテーブル作成を行う上では
あまりない事なのでしょうか？

>逆に「社員番号xxxxのデータを全て見たい」などの場合には
>同じIDで結び付けられた社員をテーブル毎に参照しにいくので
>この場合は1つの大きなテーブルがあった方が効率が良くなります。

これは選択クエリで全部参照してしまうという方法で解決できないものなの
でしょうか？

>適度（これが一番難しいですよね…）な所まで正規化を進めていきましょう。

難しいです。正規化。きっとまだ良く理解していないのだ思います。
【5569】Re:テーブルの作り方
発言  小僧  - 05/7/7(木) 10:20 -
引用なし
パスワード
   ▼buti さん：
おはようございます。

>>例えば会社の同僚の住所録テーブルを作成するとすると、
>>会社の情報（社員コード、部署、役職など）と
>>プライベートな情報（血液型、住所、電話番号など）は別テーブルになります。
>
>この場合は、両方に社員コードを持つと考えて良いのでしょうか？

ユニークな（そのテーブルで重複しない）値であれば何でも良いと思います。
例えば「社員名」を両方のテーブルに持たせてリレーションを張ることもできますが、
同姓同名の人がいる可能性は0ではないのでやはり「社員コード」が適当かと思われます。

>一つのIDでいくつものテーブルとつなげるというのはテーブル作成を行う上では
>あまりない事なのでしょうか？

>これは選択クエリで全部参照してしまうという方法で解決できないものなの
>でしょうか？

結局正規化に関しては、「可能」「不可能」の問題ではなくて
「効率的」「非効率的」の問題だと思います。
複雑にテーブルを分割してもSQL や VBA を駆使すれば結果を返す事は可能ですが、
メンテナンスや他の人が使用する事を考えると「正規化をしましょう」という事になるのでしょう。

具体的にbuti さんがどのような業務でどのような運用をされるのかが解らないので
（いや、教えて頂いてもですけど）「これが最適です」というアドバイスができなくて申し訳ないです。
【5572】Re:テーブルの作り方
お礼  buti  - 05/7/7(木) 11:56 -
引用なし
パスワード
   ▼小僧 さん：
こんにちは。

>結局正規化に関しては、「可能」「不可能」の問題ではなくて
>「効率的」「非効率的」の問題だと思います。
>複雑にテーブルを分割してもSQL や VBA を駆使すれば結果を返す事は可能ですが、
>メンテナンスや他の人が使用する事を考えると「正規化をしましょう」という事になるのでしょう。

そうですね。この辺を良く考えて見ることにします。

>具体的にbuti さんがどのような業務でどのような運用をされるのかが解らないので
>（いや、教えて頂いてもですけど）「これが最適です」というアドバイスができなくて申し訳ないです。

とんでもありません。
こちらこそ抽象的な質問にも関わらず回答いただき感謝しております。
小僧さん、ありがとうございました。
  新規投稿 ┃ツリー表示 ┃一覧表示 ┃トピック表示 ┃検索 ┃設定 ┃過去ログ ┃ホーム  
1727 / 2272 ﾂﾘｰ ←次へ　｜　前へ→
ページ：  ┃  記事番号：
1078264
(SS)C-BOARD v3.8 is Free