Access ユニオンクエリ グループ化について

質問

一対多でリレーションシップされているテーブルがありますが、
入力を一つのフォームで入力したいので
ユニオンクエリで二つのテーブルを一つのクエリに使用と考えています。
このままフォームを作成すると一側のデータと多側のデータで
被っているデータが表示されます
グループ化のようなことは出来るのでしょうか？

テーブルは企業データTと店データTがあります。
企業側が一、店側が多です。
企業側も店側もフィールド内容はほとんど同じです。
企業側は社名フィールド、店側は店名フィールド程度の違いです。

単独店は店を複数持たないので企業側も店側も同じデータを持っています。（企業データ＝店データ）

単独店は企業側、店側ともにデータ入れてあります。（店側でいらないフィールドは入れていません。役員名など）

内容が同じなのでどちらか片方に入力された場合データをもう片方に移すようなことがしたいのですが、両方のテーブルに同じ単独店のデータを持つ必要はないのでしょうか？

回答No.4

PPancho · ベストアンサー

#1で回答したものです。

あとから質問者さんからテーブル属性情報が出てきたので、
元の自分の回答を見直しました。
#3さんの回答がオーソドックスだと思います。
（そうなっていない某社のERPパッケージツールもありますが。。。）
#3さんの設計どおりなされば、店舗が１店舗だろうが１０００店舗
あろうが[企業テーブル][店テーブル]の２つのテーブルの組み合わせ
だけで出来ると思いますよ。

ということでユニオンクエリーの出番もなくなります。

補足

疑問点はNO3に書いたとおりです。
少し勘違い？をしていました。
サブフォームに店舗側を表示する形になるのですね。
ということは単独店の店側の情報は更新クエリで更新するということになるのですね。

回答No.5

PPancho

sskjさん。別件で恐縮ですが、
既にクローズされている質問QNo.3934665の回答への補足を読みましたが、
ACCESSの日付・時間データは内部ではシリアル値を持っております
CDate関数で変換する際、このシリアル値に変換できなければなりません。
日付式で表すことのできる日付の範囲は、西暦 100 年 1 月 1 日 ～
西暦 9999 年 12 月 31 日です。したがって年に0年を設定すると日付型に変換出来ません。

date(),now()関数等で今日の年を設定、もしくは他の関数と
組み合わせて「今年から○年前の年」等にする必要があります。
本件と併せてご検討ください。

お礼

わざわざありがとうございます。
QNo.3934665の件ですが締め切り後に解決いたしました。

００日は更新クエリでNULLに変換し、NULLの扱いに困っていましたが
以下のような関数で解決いたしました。

生年月日和暦: IIf(nz([生年月日],"")="",Null,IIf(Mid([生年月日],4,2)="",Format(CDate(Left([生年月日],3) & "/" & "01"),"ggge""年　月　日生"""),IIf(Mid([生年月日],6,1)="",Format(CDate(Left([生年月日],3) & "/" & Mid([生年月日],4,2)),"ggge\年m""月　日生"""),Format(CDate(Left([生年月日],3) & "/" & Mid([生年月日],4,2) & "/" & Right([生年月日],2)),"ggge\年m\月d""日生"""))))

回答No.3

CHRONOS_0

A社
　1号店
　2号店
こういう関係は1対多とは言いません、親子関係といいます
1対多というのは商品テーブルと販売テーブルのような関係を言います
販売テーブルは何度も同じ商品を参照するという関係です

で、親子関係の場合
[企業テーブル](企業ID、社名、電話番号、ファックス、住所、郵便番号、URL、資本金、設立、創業、代表者名、代表者生年月日、役員、株主銀行、仕入先、販売先、主力ブランド)　←企業IDが主キー
[店テーブル](企業ID、店ID、店名、電話番号、ファックス、住所、郵便番号、創業代表者名、)　←企業IDと店IDで主キー
のように親の主キーがこの主キーの一部になるような関係になります

>単独店のデータをこの多店舗と同じ企業テーブル、店テーブルに
>入れてよいものかどうか・・・。両方に入れるべきかどうか。
店がひとつしかないものも同じ構造にしたほうが扱いが簡単です
動物分類のひと属ひと科ひとのように階層構造を合わせておいたほうがいいのです

1対多とか、ユニオンクエリとか言葉は知っておられますが意味を取り違えていますよ
もう一度勉強しなおしたほうがいいみたいですね

お礼

勘違いしていました。
サブフォームと更新クエリで問題なさそうですね。
ありがとうございました。

補足

現在のリレーションシップの状況を見てもらうのが一番早いかと
思いますので問題点があればご指摘お願いします。
ttp://upload.jpn.ph/img/u16816.jpg

備考や仕入れ先に関してはこちらの事情でわざとフィールドを別に持たせています。
説明を一部省いた項目もあります。

親子関係については聞き覚えはありますが、私の手持ちの
解説書には記載されていませんでした・・・。

以前のデータベースで使用していた項目で何に使用していたか分からない項目があるのですが、後に消しても問題ありませんよね？

入力フォームの話ですが、企業テーブル、店テーブル別々にフォームを
作成することが出来るのは分かるのですが、企業テーブル、店テーブルを
一つのフォームで同一のフィールド項目を同じボックスで入力できるのでしょうか？
それと、単独店の店側の情報は企業テーブルへの入力時に反映されるようにできるのでしょうか？
それとも個別に更新クエリをしようするのですか？

データレベルという項目があるのですがこれは００なら単独店、１２なら多店舗、１０なら多店舗（企業情報）となっています。

店コードですが、企業テーブルにある単独店の企業コードと店テーブルにある単独店の店コードが同じでも問題ないですよね？

回答No.2

CHRONOS_0

>入力を一つのフォームで入力したいので
>ユニオンクエリで二つのテーブルを一つのクエリに使用と考えています。
ユニオンクエリは追加更新付加のクエリですから入力には使えませんよ

ただ
>一対多でリレーションシップされているテーブルがありますが
ということから判断するとユニオンクエリじゃなく普通の抽出クエリみたいですね

しかし
>企業側も店側もフィールド内容はほとんど同じです。
これをみるとそれも怪しくなってきますね

>このままフォームを作成すると一側のデータと多側のデータで
>被っているデータが表示されます
これも何を言っているのか分からない

どうもテーブル設計が全く分かっておられないようですね

作られたテーブルの詳しい情報をアップしたほうがいいみたいですよ

回答No.1

PPancho

sskjさん
UNIONクエリーを参照するフォームからは新規データの入力が
出来なかった気がします。画面参照もしくは帳票出力のみ

質問に対する直接の答えではありませんが、
通常そのようなＤＢを設計する時には
企業データテーブルには会社の社名、取引条件などを
店データのテーブルには住所連絡先、ローカル条件などを
させる設計をします。
したがって、支店が無くても本店分として
企業データテーブル：店データのテーブル＝１：１にします。
必要ならば店データテーブルに本店にはフラグ（チェックボックス等）を用意します。

しかし、企業データテーブルにもどうしても住所情報を持たせたい
場合は入力フォームの設計では
カード型フォームの設計で
企業データ１件１画面で、１企業に対する支店が明細行で表示される
サブフォームタイプのフォームにして、企業データにデータを
入力したら明細行にもデータが転写れるようにします。
具体的にはVBAコーディングをするか、サブフォームの各入力項目の
初期入力値に参照先の親フォームの項目を指定します。
（ただしこのままノーチェックだと明細行の新規レコードを
　作るたびに企業データの内容と全く同じ支店がたくさん出来るので、　必ず手で上書き修正し、それをしなかった場合は無効にするなどの
　工夫が必要です）

補足

テーブルの話ですが、

　A社　←企業情報
（A社）一号店←店情報
（A社）二号店←店情報
　※多店舗
店をいくつも持っている企業の場合を多店舗と呼んでいます。
単独店と違い、店情報は店情報。
企業情報は企業情報で別の情報です。

B社←企業情報
B店←店情報
※単独店
店を一つしか持たない企業を単独店と呼んでいます。
この場合B社の情報＝B店の情報となります。

多店舗の場合、企業が一、店側が多で問題ないかと思いますが
単独店のデータをこの多店舗と同じ企業テーブル、店テーブルに
入れてよいものかどうか・・・。両方に入れるべきかどうか。

単独店は単独店で別テーブルを用意する良いのか？。
よく分かっていません。

企業側も店側も項目は似ているので同じフォームで入力したいです。
（元の質問）

ここの話で言う企業データ及び店データは以下の項目です。
社名、電話番号、ファックス、住所、郵便番号、URL,資本金
設立、創業、代表者名、代表者生年月日、役員、株主
銀行、仕入先、販売先、主力ブランド

店情報は以下のみです。
店名、電話番号、ファックス、住所、郵便番号、創業
代表者名、