こんにちはゲストさん。会員登録(無料)して質問・回答してみよう!

解決済みの質問

ACCESSのクエリの考え方

お世話になります。

現在、アクセスを参考書片手に取り組んでいます。参考書の通りに進んでいたのですが、
クエリのことで悩んでいます。
自分なりの理解なのですが…、テーブルにあるデーターを会議などの資料のために
いろんな条件で抽出したりしないかぎりは、別にクエリを作成しなくてもいい、
(要するに、「こういう条件のデーターが欲しい!」って時以外は、基本的には
テーブルへのデーター入力だけでOKで、クエリは別に必要ない)
という認識で正しいでしょうか?
参考書がやたらとクエリを作成させたがるために、よく分からなくなっています。
下記が、アクセスの目的ですが、自分的にはフォームは扱いやすくする必要が
あると思うのですが、いまいちクエリの必要性がわからないのです。

―――目的―――
・顧客情報・商品情報・顧客ごとの見積・問い合わせを、 社員(10名程度)で
 共有したいため。(現在は各々が紙にて管理)
・データーはNASかサーバーにアクセスのデーターを入れて、各々のPCから
 閲覧・書き込みができるようにする予定。
・共有したい情報(「顧客情報」「商品情報」「見積情報」「問い合わせ情報」「クレーム情報」)は
 テーブルにて作成。
・入力・閲覧がしやすいように、フォームについては作成予定。
・見積書などはアクセスでは作成しない。

投稿日時 - 2008-01-16 16:45:03

QNo.3685454

困ってます

質問者が選んだベストアンサー

クエリが要るのは、以下の4つのマスタと1つのテーブルを用いるような場合です。

顧客情報マスタ=顧客コード、顧客氏名、顧客住所
担当者情報マスタ=担当者コード、担当者氏名
仕入情報マスタ=仕入コード、仕入れ先名、仕入れ先住所
商品情報マスタ=商品コード、商品名、単価、在庫数、仕入れ先コード
売上テーブル=売上年月日、商品コード、販売数、顧客コード、担当者コード

ここで、売上表を印刷する場合、売上年月日、商品名、販売数、顧客氏名、担当者名、仕入れ先名を印刷するとします。

必要なのは売上年月日、商品名、販売数、顧客氏名、担当者名、仕入れ先名ですが、それぞれは別のマスタにあります。

そこで、1つのテーブルと4つのマスタを「それぞれのコードが一致する物同士で結び付けたクエリ」で結合し、そのクエリを印刷用レポートのレコードソースにします。

ここで「売上テーブルにコードを入れないで、直接、顧客名や商品名を入れれば良いじゃないか。そしたらマスタは要らないし、テーブル1つで済む」と思うでしょう。

では「今日から、この商品の仕入れ先の社名が変わります」って事になったら?

売上テーブルにある該当商品のレコードを、全部書き換えなきゃなりません。レコード数が数件であれば書き換えも楽でしょうが、数万件あったら?

更新クエリで自動的に該当の物だけ書き換える方法もありますが、仕入れ先名称を打ち込む際に間違って「有)●●商事」が「有)●●商会」になっていたら更新クエリを使っても更新されません。

これが「マスタとテーブルが別になっている構造」だと、仕入情報マスタの該当する1レコードのみを書き換えれば、印刷結果の全件が自動的に新しくなります。

例えば、
仕入コード、仕入れ先名、仕入れ先住所
---------------------
00013、有)●●商事、××県○○市

仕入コード、仕入れ先名、仕入れ先住所
---------------------
00013、株)●●商事、××県○○市
に書き換えるだけでOKです。

このように「クエリは、テーブル内にある『コード』から、マスタを参照する為に使う」のです。

実名や実住所をテーブルに直接に入力せず、マスタに登録してコードで参照するのは「変更を容易くする」のと「誤入力を防ぐため」です。

投稿日時 - 2008-01-16 17:39:09

お礼

詳しい説明をありがとうございます。
おかげで、なんとなくですけど、クエリの必要性がわかってきました。

>クエリは、テーブル内にある『コード』から、マスタを参照する為に使う
この一言で、クエリの必要性がわかったような気がします。
まだまだですけど、これから勉強していきます。
ありがとうございました。

投稿日時 - 2008-01-16 23:31:51

このQ&Aは役に立ちましたか?

0人が「このQ&Aが役に立った」と投票しています

回答(6)

ANo.6

#5でのご回答で出てますが、俗にいうと、アクセスではエクセルでやるシート表作成を、2つ3つのファイルに分けることが多いし、発生時点的にも別ファイルになったりする。
人に関する情報ファイル(テーブル)(例えば職員番号と氏名、職員番号と所属部署コード、所属部署コードと所属部書名、職員の毎月の計数ファイル(毎月データが作成されると)結果として別ファイルになる)など。
すると
それらをクエリで結合しないと、内容を見る立場からは、見にくい。ですからレコード選択とは別にクエリを使います。
(2)もうひとつ、クエリは選択クエリだけではないということです。

投稿日時 - 2008-01-16 21:33:33

お礼

ありがとうございます。

>それらをクエリで結合しないと、内容を見る立場からは、見にくい
確かに、今自分が作っているものでは、紙台帳よりはマシだけど…っていう
レベルになっていると思います。
もっと、見やすく、分かりやすくするために、クエリが必要になるわけですね。

皆さんのおかげで、ほんとになんとなくですが、クエリの必要性がわかって
きました。仕事の片手間で、なかなか勉強が進みませんが、頑張ってやて
みたいと思います。

ありがとうございました!

投稿日時 - 2008-01-16 23:45:58

ANo.5

データベースにも歴史があり、時代と共に進化しています。現在の主流は「リレーショナルデータベース」です。アクセスもこれに該当します。

関係データベース(リレーショナルデータベース)
http://ja.wikipedia.org/wiki/%E9%96%A2%E4%BF%82%E3%83%87%E3%83%BC%E3%82%BF%E3%83%99%E3%83%BC%E3%82%B9


リレーショナルデータベースでは、テーブルを正規化します。まず、「正規化」のメリットを学んで下さい。正規化はテーブル設計において、重要な要素です。

http://www.kogures.com/hitoshi/webtext/db-seikika/index.html


正規化すれば、テーブルは複数に分かれます。テーブルが複数に分かれれば、それを結合するのにクエリが必要になってきます。

正規化しない場合は、一昔前の「カード型データベース」と同様の処理になります。この場合、クエリは不要かもしれません。しかし、時代の流れに逆行する行為ですので、お勧めできません。

------------------------------------------------------------
>クエリの必要性がわからないのです。

必要性を感じてから、覚えても遅くはないと思います。クエリが活躍するのは主に出力の段階です。

テーブルを作り、入力フォームを作り、データを蓄積した後は、出力です。テーブルを正規化している場合、出力の際にクエリが必要になってきます。

クエリは条件で抽出する以外にも、用途はあります。
・複数のテーブルを結合する(これが重要!)
・集計を行う(これはExcel等でも可能)

実際にシステムを作ってみれば、クエリの重要性が分かってくると思います。

------------------------------------------------------------
>見積書などはアクセスでは作成しない。

帳票は作らないにしても、何らかの出力はある筈です。一覧表を出力(画面上や印刷)、CSVファイルを出力、など。

入力だけで、出力の無いシステムは、考えられません。(^^;

------------------------------------------------------------
まとめ:
リレーショナルデータベースでは、テーブルを正規化します。
正規化された複数のテーブルを結合する際に、クエリが活躍します。

投稿日時 - 2008-01-16 19:17:33

お礼

ありがとうございます。

なかなか奥が深く、自分の知識がまだまだだなぁって痛感しております。
まずは、リレーショナルデーターベースについて学んで、それにあったデーターベースを
作らないといけないですね。
その後に正規化をして、クエリを有効に使うというわけですね。

少人数の会社なため、仕事の合間にやっているため、なかなか大変です。
もっと勉強して、それなりのものを作れるように頑張ります。

投稿日時 - 2008-01-16 23:42:45

>クエリは必要不可欠じゃないのでは・・・

クエリは必須ツールです。
理由は、テーブルとフォームが1対1というのは極めて稀だからです。
これは、カード型データベースまがいの設計を志向しなきゃ当然の現象。
設計がリレーショナルデータベースの特徴を帯びれば帯びるほどにクエリは必須に。

<クエリゼロでも当然にOK>

UNIXのRDBではクエリを利用しなかったように記憶しています。
10数年前の話なので大分怪しいが、全て SQL文を自分で書いていたと思います。
ですから、SQL文自作主義に徹すればクエリも不要に。

<SQL文自作主義の決定的問題点>

ところで、SQL文を自分で書く場合、それはプログラム中に埋め込むことに。
そうなればコードのメンテナンスがとても大変に。
この問題を解決するには、SQL文を外部で定義することが課題に。
「どうせなら、SQL文そのものを作成し記録するシステムを」でクエリの誕生に。
まあ、このように強いニーズを背景に誕生したクエリ。
「利用すべき場合には利用したが良い」と思いますよ。

>顧客情報、商品情報、見積情報、問い合わせ情報。

まあ、エクセルないしカード型データベースの発想で管理しようとしているんじゃ・・・。
それじゃ、クエリ無用論も当然ですね。
SQL文自作主義を掲げてのクエリ無用論なら理解できます。

投稿日時 - 2008-01-16 17:52:23

お礼

>エクセルないしカード型データベースの発想で管理しようとしているんじゃ・・・
すみません…。たぶん、エクセルのようなイメージだったので、おっしゃっている
カード型データベースの発想になっていたと思います。

みなさんのおかげでデーターベースのイメージがつかめてきましたが、
なかなか奥が深く、まだまだ勉強不足です…。
これから勉強してきたいと思います。
ありがとうございました。

投稿日時 - 2008-01-16 23:38:11

ANo.2

>という認識で正しいでしょうか?
クエリの機能の一部しか認識していませんね

>テーブルへのデーター入力だけでOKで、
テーブルへのデータ入力もテーブルに直接入力するようなことはしません
>・入力・閲覧がしやすいように、フォームについては作成予定。
こうするにはクエリが必要です

リレーショナルデータベースではひとつの仕事を複数のテーブルで表現します
個々のテーブルは人間がみて見やすい形のものではありません
人が見やすいあるいは人の役にたつ形にテーブルを加工するにはクエリが必須です
クエリを使わないデータベースは考えられないですね

投稿日時 - 2008-01-16 17:23:03

お礼

>クエリの機能の一部しか認識していませんね
そうなんです。自分でもそう思います。
エクセルを長く使っていたために、データーベースというものを
理解しきれていないんです。

>クエリを使わないデータベースは考えられないですね
そうなんですか。なかなか難しいですね。おいおい
勉強していきたいと思います。
ありがとうございました。

投稿日時 - 2008-01-16 23:27:44

ANo.1

こんにちわ。

>要するに、「こういう条件のデーターが欲しい!」って時以外は、基本的には
テーブルへのデーター入力だけでOKで、クエリは別に必要ない)
という認識で正しいでしょうか?

正しいです。
クエリを使えば便利な局面は多いですが、無くても別に構いません。
では頑張ってください。

投稿日時 - 2008-01-16 16:56:59

お礼

ありがとうございます。
他の方の回答を見て、なんとなくデーターベースとは何たるかが
分かったような気がします。たぶん…。
エクセルを長く使っていたために、いまいちエクセルベースで
考えてしまいます。
これから勉強していきたいと思います。

投稿日時 - 2008-01-16 23:26:07

あなたにオススメの質問