ACCESSを使用してシステムを構築しているのですが、テーブル間のリレーションシップについて疑問があります。

リレーションシップを設定することにより、データベースの整合性を得ることができますが、その他のメリットはあるのでしょうか?
ある文献では検索時間の短縮になるとあったのですが、本当なのでしょうか?
通常の表結合クエリーと参照整合性以外の違いはどのようなものでしょうか?

回答をお願いします。

このQ&Aに関連する最新のQ&A

A 回答 (1件)

リレーションを設定することにより、INDEXが作成される場合があるため、検索時間が短縮されることもあります。



通常の結合クエリとリレーションの違いは、参照整合性に尽きると思います。データベースの設計をしっかり行えば、「このテーブルには、このようなデータがあってはいけない」というような、決まりが必要になります。それを、すべて気にしながらプログラムのコーディングするのは大変です。そこで、データの整合性は、できるだけデータベースに任せてしまおうというのが参照整合性です。(または、制約です。空文字不可とかありますよね)
ですから、データの整合性などは一切アプリケーションで行う場合は、リレーションは必要なくなります。メリットもないと私は思います。
    • good
    • 0
この回答へのお礼

回答ありがとうございます。
一対一のリレーションシップの場合にはINDEXが作成されることがあるようですね。
やはり参照整合性をACCESSに任せられると言うことがメリットということですか・・・
今回のシステムは整合性をプログラムで行うことになりそうですので、リレーションシップは不必要ですね。
参考意見とさせていただきます。

お礼日時:2002/01/19 21:17

このQ&Aに関連する人気のQ&A

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!

関連するカテゴリからQ&Aを探す

このQ&Aを見た人が検索しているワード

このQ&Aと関連する良く見られている質問

Qリレーションの設定って意味あるのですか?

すみません、素朴な疑問です!

リレーションってプログラミング上どんな意味(利点)があるのでしょうか?

たとえば、下記のようにテーブル2つあり、PC種別コードで1:多で
リレーションが設定されていたとします。

■顧客テーブル     ■PCテーブル
氏名 PC種別コード   PC種別コード PC種別名
========    ============
田中 1        1      デスクトップ
佐藤 2        2      ノートブック
伊藤 2 

下記のようにフォーム上で表示する時、
氏名 所有PC種別名
==========
田中 デスクトップ
佐藤 ノートブック
伊藤 ノートブック

所有PC種別名は、リレーションの設定とはまったく無関係に
プログラミングで引っ張ってきませんか?
たとえば、PC種別コードをキーにDlookup関数を使ったりして。
あれ?SQLのSelect文で記述すれば勝手にキーを判断し結合して持ってきてくれるのですかね~?

まったくの基本中の基本の質問をして申し訳ありません。
どなたかこの素朴な疑問を解決してください。
よろしくお願い致します。

すみません、素朴な疑問です!

リレーションってプログラミング上どんな意味(利点)があるのでしょうか?

たとえば、下記のようにテーブル2つあり、PC種別コードで1:多で
リレーションが設定されていたとします。

■顧客テーブル     ■PCテーブル
氏名 PC種別コード   PC種別コード PC種別名
========    ============
田中 1        1      デスクトップ
佐藤 2        2      ノートブック
伊藤 2 

下記のように...続きを読む

Aベストアンサー

>リレーションってプログラミング上どんな意味(利点)があるのでしょうか?

事プログラミングに関しては、リレーションを設定していなくてもすべての事が問題なく出来ます。
開発の途中などは、リレーションの為に テストデータの作成や削除等ちょっとした操作に影響するので まったく設定せずに行うこともあります。
プログラミング上と言うよりも、データベースの管理上データを矛盾無く管理するのに役だちます。
テーブル間の関連付けにより、
・矛盾したデータの入り込みを防げる
・関連した項目の連鎖更新によりデータの整合性を保てる
・関連した項目によりレコードの連鎖削除ができデータの整合性を保てる

プログラミングと言う表現とはずれますが、クエリの作成画面でリレーションを設定しているテーブルを複数配置した場合 設定している結合の情報が静的に設定されます。

QACCESS:参照整合性がとれない

私は、『提案フォーム』と『管理フォーム』(同様に、提案/管理テーブルも作成)を作り、『提案フォーム』に記入した内容を『管理フォーム』の同じコードのレコードに自動で書き込みたい(反映したい)と思いましたが、未入力のままで、自動書き込みはできませんでした。

『提案テーブル/フォーム』(関連テーブル)
 *コード(オートナンバー型) 
 *提案年月日
 *カテゴリ 
 *提案内容

『管理テーブル/フォーム』(主テーブル)
 *コード(オートナンバー型)
 *提案年月日
  更新年月日 
 *カテゴリ
 *提案内容
  改善内容
  改善過程
   ・
   ・
   ・

試みた方法1)自動結合:クエリの作成
『管理テーブル』から『提案テーブル』と同じ項目を削除し、『管理テーブル』と『提案テーブル』の全項目を
選択したクエリを作った。

試みた方法2)手動結合:リレーションシップを設定する
『管理テーブル』の「コード」と『提案テーブル』の「コード」を結合線で結び、参照整合性の欄にチェックをした。ちなみに、「フィールドの連鎖更新」や「レコードの連鎖削除」にチェックを入れると”「Invalid field definition "コード" in definition of index or relatiionship.」(なぜに英語?!)というエラーメッセージが出てきたので、チェックマークをつけられなかった。


上記の2方法とも『提案フォーム』から入力した内容が『管理フォーム』に自動書き込み(反映)されませんでした。恐らく、『管理テーブル』がオートナンバー型であり、『提案フォーム』で自動入力したコードが『管理テーブル』のレコードの新規作成にあたるために、その段階ではまだ、コードが存在していないことが、原因かと思われるのですが、ハッキリとした原因や解決法は分かりません。

解決法の分かる方がいらっしゃいましたら、宜しくお願いします。

私は、『提案フォーム』と『管理フォーム』(同様に、提案/管理テーブルも作成)を作り、『提案フォーム』に記入した内容を『管理フォーム』の同じコードのレコードに自動で書き込みたい(反映したい)と思いましたが、未入力のままで、自動書き込みはできませんでした。

『提案テーブル/フォーム』(関連テーブル)
 *コード(オートナンバー型) 
 *提案年月日
 *カテゴリ 
 *提案内容

『管理テーブル/フォーム』(主テーブル)
 *コード(オートナンバー型)
 *提案年月日
  更新年月日...続きを読む

Aベストアンサー

提案テーブルの内容を全自動で管理テーブルに書き込むのは、Accessにトリガ機能が無いため、不可能です。

したがって、フォームの中で機能を作りこむ必要があります。
先にデータが追加されるのが提案テーブルなのであれば、管理テーブルの「コード」はオートナンバでなく、長整数型などにしておく方が良いでしょう。

提案テーブルに追加する処理の中で、追加クエリを実行するか、VBAでInsert文を実行することで実現するしかありません。

ただ、なぜ提案テーブルと管理テーブルが必要なのかがよくわからないのですが。
管理テーブルに提案テーブルの内容は全て書かれているようですので、管理テーブルだけにして、提案テーブルは選択クエリの形で持っておけば、データは完全に一致しますし、フォームでもテーブルをベースにするのではなく、選択クエリをベースにすればすむので、もし理由が無いのであれば、これをお勧めします。

Qファイルメーカーの再帰定義/リレーション機能について教えて

ファイルメーカーの再帰定義とはどういう事なのか教えてくれませんか?
リレーションのデータの取込みの際、再帰定義と表示されデータがリレーションできないのです。詳しくはファイルが「受注」「発注」「仕入れ」「請求書」と4つありまして、そのフィールド(商品等)を4つのファイル全部にリレーションさせたいのですが、「受注」→「発注」→「仕入れ」まではデータを読込めたのですが、再帰定義と表示されその先の「請求」ファイルまでリレーションできません。どうすればリレーションできるのかも併せて教えて頂けませんか?宜しくお願いします。

Aベストアンサー

「再帰定義」とは計算式の間違いなどでエラーメッセージとして出てきます。どういうことかというと、AフィールドにBフィールドのデータを引用するにあたって、実はBフィールドはAフィールドのデータを何らかの形で引用していたため定義ができない、というような感じの意味です。
4つファイルのリレーションの場合、何か共通の1つのキーで他の3つにリレーションするのは良いのですが、「受注」→「発注」→「仕入れ」とデータがリレーションされた段階でこの3つのファイルのいずれかが「請求書」のデータを引用していると思われます。
この辺を考慮して再度ファイル定義をよく見直して下さい。
回答が遅かったのでもう既に解決していれば幸いです。

Q参照整合性制約と外部キー

FOREIGN KEYは、外部キー制約になるのでしょうか?
FOREIGN KEYは、参照整合制約になるのでしょうか?

参照整合制約は、FOREIGN KEYで、その制約を成り立たせるために、外部キーがあるとおもっているのですが間違ってないでしょうか?

ご教授お願いします。

Aベストアンサー

「外部キー制約」と「参照整合制約」は同じものと考えて良いと思いますよ。
実現方法に注目しているか、実現する内容に注目しているかの差でしょうか。
「タプル」を「行」や「レコード」と言うことも有りますが、それと同じようなことかと。

また「参照整合制約を成り立たせるために外部キーがある」という認識も合っていますよ。

Qリレーションの表示方法

MySQL4.1でテーブルを15つ作成して
リレーションを組みました。
でも本当に関連付けれたか心配なんですが
リレーションがちゃんとできているかを
確認するにはどうしたらいいですか?

Aベストアンサー

こんにちは。
MySQL4.1を触ったことがないので、勘違いをしているかもしれませんが、
アクセスみたいにリレーションを視覚的に組めるんですか?
確か3系とかではそんなことはできなかったので、SQL文の生成の段階でリレーションを組んでいましたが!!!
テーブル構造として作ったってことかな???
リレーションが組めているのであれば、そのリレーションを使ったSQL文を作ってデータを確認してみたら、関連付けができているかどうか、確認できます。

QDBアプリケーションの設計方針 (参照整合性、外部キーなどの制約はDDLで定義すべき?)

標記の件でご意見を伺いたく投稿します。
データベースにおいて、参照整合性、外部キーなど、レコードの整合性を守るのに不可欠な要素が
いくつかありますが、これらをDDLで定義するのと、フロントエンドのアプリケーションで実装する
のと、どちらが望ましいでしょうか?

世間で普及している教本等では、DDLで定義することになっているようですが、この辺りをきちんと
作り込んだ経験がありません。理由は以下の通りです。

(1) 制約でガチガチに縛ってしまうと、テストデータの作成に難儀する。
→ Access の場合、アプリケーションの画面が影も形もない段階で、テーブルのデータシート
ビューから直接データを投入できるが、制約で縛るとこの手軽さが失われてしまう。
(トリガを書けば、データは投入できるが、何だか余分な作業が増えて損をしたような気がする)

(2) データの整合性は保証できるものの、制約に違反した場合のエラーメッセージがユーザー
フレンドリーではない。

結局、アプリケーションで、エラーを事前に開始するか、またはエラーメッセージをユーザー
向けの文言に書き換える処理が必須となる。

DDLで制約を定義しても、アプリケーション実装の作業負担は軽くならない。


そんな訳で、主キー、規定値以外の制約をDDLで実装した経験は殆どありません。
Accessの場合、ド素人でもデータベースを直接GUIから操作できるので、設計者の意図に反して
データの整合性が損なわれるリスクはありますが、総合的に見て、DDLで制約を定義するメリット
を私はあまり感じません。

一般的にはどうなのでしょうか?
専門家の皆様のご意見をお待ちしております。

初心者ですので、わかりやすくご指導頂けると幸いです。(笑)

標記の件でご意見を伺いたく投稿します。
データベースにおいて、参照整合性、外部キーなど、レコードの整合性を守るのに不可欠な要素が
いくつかありますが、これらをDDLで定義するのと、フロントエンドのアプリケーションで実装する
のと、どちらが望ましいでしょうか?

世間で普及している教本等では、DDLで定義することになっているようですが、この辺りをきちんと
作り込んだ経験がありません。理由は以下の通りです。

(1) 制約でガチガチに縛ってしまうと、テストデータの作成に難儀する。
→ Ac...続きを読む

Aベストアンサー

>そんな訳で、主キー、規定値以外の制約をDDLで実装した経験は殆どありません。

業務の種類によって対応はまちまちですが、
私も主キー、規定値、サイズくらいですかね。

>結局、アプリケーションで、エラーを事前に開始するか、またはエラーメッセージをユーザー
向けの文言に書き換える処理が必須となる。

これも同意です。
アプリのほうでメッセージ出して、なおかつ通常のメッセージボックスはダメという要求が多い。
結局作りこむことになるのが現状

なおかつ、現在個人情報保護法等もあり、
データフィールドを個別に暗号化処理するようにしてしまったので、
基本の制約は意味を成さなくなってしまいました、

暗号化込みのデータベースが出ればまた使うかもしれないですが・・・

なので、最近に限って言えばほとんど使っていません。

QFileMaker pro 11 リレーション本

FileMaker Pro 11で専門学校の学生管理DBを作成しています。
初心者のため、リレーションをどうやればよいか、よくわかりません。

現在使用中の本は
「FileMaker Pro11 スーパーリファレンス」(ソーテック社)のみです。

リレーションについて、「新リレーションで極める FileMaker」という本しかアマゾンで見当たらないのですが、2008年に出版された本で、バージョン9までの対応のようです。
この本は、バージョン11でも十分に対応できる内容なのでしょうか?
もし、問題ないようでしたら購入したいのですが、どなたか使っていらっしゃる方がおられましたら、教えてください。

また、他にPro11対応のリレーションについて詳しく学べるサイトや本がありましたら教えていただけると助かります。

Aベストアンサー

リレーションだけの本もあるのですか・・・
リレーションの基本はVer.7からほとんど変わっていないと思いますけど、
11(持ってないけど)ではポータルフィルターとか有るようですね。
リレーションのどんなところが判らないのですか?
市販本で解決するのかな。

Qクエリーからクエリーを呼ぶことって?

クエリーから別のクエリーを呼ぶことってできますか?
よろしくお願いします。

Aベストアンサー

不可能ではありませんが、出来ないものもあります。
自身を使った選択クエリ、作成・更新・削除クエリはできません。

Q[Access2000]リレーションが設定されたレコードが必要

ACCESS2000

1対1でリレーションを設定しています。
T_マスター
T_内容

ID→ID 参照整合性ON 連鎖OFF 結合の種類「2」

新しいレコードをT_マスターに追加しようと
すると、
「リレーションが設定されたレコードが必要」
とエラーメッセージが出ます。

T_マスターにはレコードが追加されるようなんですが、T_内容にはレコードが追加されないようで
そのためエラーが発生するようです。

このエラーを解消するためにはどのような
リレーションの設定をすればよろしいでしょうか?

Aベストアンサー

>新しいレコードをT_マスターに追加しようとすると「リレーションが設定されたレコードが必要」とエラーメッセージが出ます。
1対1でリレーションでこのメッセージがでるのはテーブルにリレーションの結合する同じキーが無いレコードをリレーションテーブルに保存しようとした場合にでます。

「T_マスターに追加しようとすると・・」でるということはT_マスターはテーブル側ではなくリレーションテーブルになっている可能性があります。
しかし「T_マスターにはレコードが追加されるよう・・」というのは矛盾があります。「T_マスターに追加しようとすると」ではなくT_内容に保存しようとした際にでるのではないでしょうか?
T_マスターにキーがなければT_内容に入力できません。(T_マスターがテーブルでT_内容がリレーションテーブルの場合)

まず結合の種類を確認してください。
T_マスターがテーブルでT_内容がリレーションテーブル

QAccess のリレーションシップで一部一致

いつもお世話になっています。

Accessでクエリを作成するにあたり、リレーションシップを設定したいのですが、
一致させるフィールドが「123456/S1234とS1234」,「S001234とS1501234E」,「5678と5678」など、
完全一致するものと一部一致するものが混在しています。

一部一致のものでも、どれと一致させるかを判断することはできるのですが、
この状態では通常のリレーションシップは設定できませんか?

設定できないならば、一度加工して完全一致したテーブルを作成し、
それとリレーションシップをVBAで設定するしかないでしょうか?

Aベストアンサー

一致条件を判断する関数をVBAで作成すれば可能ですが、

「S001234とS1501234E」が一致するということは、1234 が一致しているということですが、前者の一部と後者の一部の一致も許可するということですよね。

だとすると、「S001234」は一つ前のデータ例「S1234」とも一致するし、「S1501234E」は同じく「123456/S1234」とも一致するということになりますね。

これでは、一致する条件が緩すぎて、複数の組み合わせが多数できてしまい使い物にならないと思いますが。

もう少し厳密な条件定義が必要ですね。

また、関数で一致条件を定義するとインデックスの機能が使えませんので、レコード件数が多いと処理が重くなります。

加工して完全一致になるフィールドを作成する方法をとることをお勧めましす。

どちらにしても現状の条件ではどうにもなりません。


人気Q&Aランキング

おすすめ情報