初心者のFileMaker pro Q&A

みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。

1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 (優しく回答しましょう)

ログインしていません。

アナウンス

Claris FileMaker Pro 19 ヘルプ
新しい質問は、新規トピック から投稿して下さい。


#1 2021-11-23 00:22:38

hiroy
ゲストユーザー

双方向にリレーションの表示

いつもおせわになっております、
mac10.15.7
Filemaker Pro19です。

(イベント)〜(イベント販売)〜(お客マスタ)
               〜(商品マスタ)

というリレーションで、『その(イベント)で(お客)に(商品)が売れた』をポータル表示しています。((イベント販売)は中間テーブル)
それと逆方向、お客マスタ側にも『その(お客)は(イベント)で(商品)を買った』を表示させたい、というのが質問です。
商品マスタに価格のフィールドもあるので、「イベント販売合計金爆」、「お客の購入累計額」を表示したいというのが目的になります。


「お客マスタ」〜「イベント販売」〜「イベント」
                〜「商品マスタ」

と、逆向きのT.O.を組んで「お客マスタ」にポータル表示できると考えましたが、うまく行きませんでした(何も表示されない)。
考え方としてはこれであっているのでしょうか?
よろしくお願いします。

#2 2021-11-23 06:59:44

himadanee
ゲストユーザー

Re: 双方向にリレーションの表示

リレーションには「方向」は定義されてないので、「逆向きのT.O.を組んで」は不要です。
逆向きに参照できないのは、片側がグローバルだったり非保存計算だったり(索引がない)フィールドの場合ですが、この場合は該当しそうにありませんが。。。

#3 2021-11-23 09:41:13

Shin
メンバー

Re: 双方向にリレーションの表示

なんか、リレーションの考え方が違うような。
イベントという項目は、おそらくその時点でほぼ固定のものですよね。
販売方法ですが、商品を特定してから(レジに打ち込んでから)顧客を入力、か、顧客を特定してから商品を特定、で作りかたが変わるのですが。
後者だとして、イベントのIDをグローバルフィールドに保存しておき、顧客マスターに持たせます。それと顧客ID で、イベント販売へリレーションを張れば、簡単になるでしょう。
前者でしたら、もう一つ販売テーブルを作り、その中に、イベント販売をポータルで表示させます。商品を特定できれば、販売テーブルに顧客IDを入力する動きになります。
このどちらも、顧客テーブルからイベント販売テーブルへ顧客IDでリレーションすれば、集計できます。

オフライン

#4 2021-11-23 10:40:39

hiroy
ゲストユーザー

Re: 双方向にリレーションの表示

himadaneeさま、

いつもありがとうございます。

himadanee さんの発言:

リレーションには「方向」は定義されてないので、「逆向きのT.O.を組んで」は不要です。

アンカーブイを忠実に行っております、、

himadanee さんの発言:

逆向きに参照できないのは、片側がグローバルだったり非保存計算だったり(索引がない)フィールドの場合ですが、この場合は該当しそうにありませんが。。。

基本的な方向としては間違いはないということですね。
細かな部分の理解が追いついていないので、一つづつ見直してみます。

#5 2021-11-23 10:42:51

hiroy
ゲストユーザー

Re: 双方向にリレーションの表示

shinさま、
いつもありがとうございます。

Shin さんの発言:

なんか、リレーションの考え方が違うような。
イベントという項目は、おそらくその時点でほぼ固定のものですよね。

固定ということか分かりませんが、「イベント」も「お客」も「商品」も先に登録したものから選んで組み合わせる、という感じです。


私の投稿した状況と文字幅が変わって、模式図的に描いたものがわかりづらい表現なっていました。
現状は、(イベント販売)に(お客マスタ)と(商品マスタ)が両方リレーションされています。
(イベント)に配置した(イベント販売)ポータルで「お客」「商品」をポップアップメニューで選べるようになっています。

顧客側からは様々なイベントで購入したトータルの累計購入金額がわかれば良く、(どのイベントで購入したかは知りたいけれど)イベントごとの集計は必要ありません。
とすると、(お客マスタ)側のレイアウトに(イベント販売)ポータルを配置し、そこにリレーションされている「イベント」と「商品」の情報を表示(とその合計を集計)することができると考えたのですが、、

#6 2021-11-23 11:01:57

himadanee
ゲストユーザー

Re: 双方向にリレーションの表示

アンカーブイというのはよく知りませんが、逆向きリレーションを別に定義するなら、全部別のTO名になってるはずですよ。(どれか1つだけは兼用できるが)
ここに同じ名前で書いてしまってるということは、レイアウトで使ってるTO名が間違ってるのでは。

#7 2021-11-23 16:39:16

Shin
メンバー

Re: 双方向にリレーションの表示

そもそも、イベント販売テーブルのフィールド構成はどうなっていますか。

イベントの固定とは、1イベントに対して作業が連続するのか、ということですので、その通りのようですね。
ただ、顧客の購入は、1イベントあたり1商品なのでしょうか、複数になるのでしたら、少し構成を変えないといけないです。

また、イベントレイアウトから始めるのでしたら、顧客名のポータルを表示してポータル行を選択しても、別のポータルへその情報は流用できませんので、別に商品ポータルを作っても、顧客情報は渡せません。これを商品テーブルへ渡すためには、顧客情報をイベントテーブルのグローバルフィールドへ設定しておき、それを含めたリレーションにする必要があります。

アンカーブイは、1レイアウトごとに1リレーションマップを構築するというイメージの方法で、レイアウトが関連付けられているテーブルオカレンスを起点にして、それに関連するTOを紐づけていく、という図を作ります。メンテナンス性はいいのですが、レイアウトを多用すると、マップが多数できてしまい、TOが非常に多く作られてしまい、TO名の規則性を厳格に管理しないと収集がつかなくなることもあると思いますが。
アンカーブイは、何十テーブルを内包するような非常に大きなシステムを構成するには有用なのですが、数テーブル規模のものでしたら、却って面倒かもしれません。将来性を見込して考えられたらいいと思います。

編集者 Shin (2021-11-23 21:31:25)

オフライン

#8 2021-11-23 22:20:37

hiroy
ゲストユーザー

Re: 双方向にリレーションの表示

himadaneeさま、shinさま、

返信ありがとうございます。
何もわからないところからyoutubeでfilemakerを始め、その講師がアンカーブイを推してたので常套なのかと思っていましたがそうでもないのですね。。
何百もテーブルはありませんし(4〜50くらい)、確かにTOは増えてしまっていますが、リレーション図から全体像を確認できるという意味では初心者の理解の助けになっているような気がしています。

himadanee さんの発言:

ここに同じ名前で書いてしまってるということは、レイアウトで使ってるTO名が間違ってるのでは。

アンカーブイににのっとって、TOのつながり順に名前をつけるということをしています。なので間違わないはずなのですが、、

Shin さんの発言:

そもそも、イベント販売テーブルのフィールド構成はどうなっていますか。

イベント販売テーブルには
購入者((お客マスタ)の主キーとリレーション)
商品マスタ管理番号((商品マスタ)の商品マスタ管理番号(商品固有キー)とリレーション)
イベント外部キー((イベント)の主キーとリレーション)
他、購入日などいくつかのフィールドあり。
というフィールドになっています。(という答えで合っていますか?)

Shin さんの発言:

イベントの固定とは、1イベントに対して作業が連続するのか、ということですので、その通りのようですね。
ただ、顧客の購入は、1イベントあたり1商品なのでしょうか、複数になるのでしたら、少し構成を変えないといけないです。

1イベントで1人のお客が複数の商品を購入することもあります。


「イベント販売テーブルには「お客」「イベント」「商品」のつながりの情報が記載されている」という理解でしたので、どこからでも他二つのつながり情報が取り出せると考えていました。
改めて考えると確かに条件が三つあり、多対多対多といえる状態なので、そんな単純ではいかないのかもしれません。

「イベント」から見ると一つのイベントにお客複数、1人のお客に商品複数。
「お客」から見ると(「イベント」は無視して)商品複数。という感じなので、(filemaker的な見方では無く)個人的感覚的にはいけそうなイメージを感じていました。

「お客」に配置した(イベント販売テーブル)のポータルには全く反応がないので、そもそもの構成/設定の問題な感じはしています。

#9 2021-11-24 05:27:40

Shin
メンバー

Re: 双方向にリレーションの表示

非常に荒削りですが、サンプルで動きを見てみてください。一応、アンカーブイ構成にしてあります。
https://www.dropbox.com/s/lw6b2tpm0q113 … 2.zip?dl=0

ちょっと面白い動きを追加してあるので、見てみてください。
まず、イベントごとに商品を絞り込めるようにしてあります。
イベントレイアウトで、対象となる商品をポータルで一覧表示してあります。そこのチェックボックスをチェックすることで、購入リストへレコードを追加できます。ちょうど、焼き肉屋で✔するオーダー用紙の雰囲気です。もちろん、✔を外せば、販売リストからは外れます。

リレーションマップをよく見るとわかるように、アンカーブイ構成すると、全く同じリレーションがあちらこちらに出てきます。それにつれて、同じテーブルのTOが数倍出てきます。この程度のデータベースでしたら、普通にリレーションをはれば、この数分の1程度の大きさになります。どちらがいいのでしょうね。

編集者 Shin (2021-11-27 15:59:29)

オフライン

#10 2021-11-25 00:17:56

hiroy
ゲストユーザー

Re: 双方向にリレーションの表示

shinさま、

返信&サンプルありがとうございます!
イベントレイアウトでの動き、面白いですね。
まだどういう構造でその動きが成り立っているのか、理解できていません(リレーションのXの使い方がいまいち分からないのです、、)が、サンプルを勉強させていただき実装できるようにしたいと思います。

Shin さんの発言:

リレーションマップをよく見るとわかるように、アンカーブイ構成すると、全く同じリレーションがあちらこちらに出てきます。それにつれて、同じテーブルのTOが数倍出てきます。この程度のデータベースでしたら、普通にリレーションをはれば、この数分の1程度の大きさになります。どちらがいいのでしょうね。

この時の「大きさ」はデータのサイズということでしょうか?
勝手に「TOはテーブルのエリアス(影)の様なもので、増やしてもデータの大きさにはさほど影響ない」と考えていました。
(なのでアンカーブイを勧めているのかと、、)
「構成図の貼り紙が貼ってある」くらいに考えていましたが、データの大きさ(や動作)に影響が大きいのだとすると、考えないといけないですね、、

#11 2021-11-25 05:27:39

Shin
メンバー

Re: 双方向にリレーションの表示

大きさとは、リレーションマップとしての大きさやTOの全数の意味です。ファイルの大きさには、ごくわずかしか影響しません。

もし、この構造の裏に、顧客の管理(同居家族の管理やDMなど)、商品管理(入出庫、伝票管理、会計処理)、職員管理(入退職、出勤管理、給与管理)なども含む全社的な大きなシステムが予定されているのでいたら、アンカーブイを推奨するのですが、サンプル程度のものでしたら、厳密なアンカーブイの構造だと、TOが17、リレーションが9になりますが、単に繋ぐだけでしたら、TOが6、リレーションが5で表現できてしまいます。却って煩雑だと思うのですが。

編集者 Shin (2021-11-25 05:29:46)

オフライン

#12 2021-11-26 10:53:33

hiroy
ゲストユーザー

Re: 双方向にリレーションの表示

shinさま、

返信ありがとうございます。
ファイルの大きさの影響は大きくないのですね。(私的にはよかったです)

今回のデータベース、イベント部分のご相談をしましたが、イベント、商品、顧客、納品書請求書、生産など、始めた事業に関連することをみんな紐づけた状態で作成しています。
(どう分割したら良いのかわからず肥大している、というのが正直なところですが、、)
個人事業レベルなので規模的には大きくはないとは思います(テーブルが40くらい)が、各々の入り口からのテーブルのつながりを理解するためにアンカーブイはかなり助けになっている気がしています。
安全性やメンテナンスも考えるとファイルを分割して整理した方が良いのかもしれませんが、、
(余談ですが、知識も素養も全くのゼロの状態からここまでにでこれたのは、shin様初めこちらで回答してくださる皆様のおかげです。改めてこの場を借りてお礼申し上げます。)

#13 2021-11-26 11:03:49

Shin
メンバー

Re: 双方向にリレーションの表示

大規模な構成なのですね。
アンカーブイの最大の欠点が、TO が多くなることです。
リレーションマップの上では、選択した TO とデータソースが同じものを表示したり、隣りあう TO を表示できますし、レイアウトモードでは、そのレイアウトからの関連TOが表示されるのでいいのですが、単にフィールドを選択する際に、どのTOのフィールドかを有機的に探す方法が無いことでしょう。
TOの命名によるしかないのですが、その名前がどんどん長くなるので、それを表示の制限によってみえなくなるので、困りますね。いい解決策があればいいのですが、いつもこれで悩みます。

サンプルにちょっとした思いつきの変更を加えました。
https://www.dropbox.com/s/lw6b2tpm0q113 … 2.zip?dl=0

編集者 Shin (2021-11-28 16:50:47)

オフライン

クィック投稿

メッセージを書いて送信してください。
登録の確認

実在の人物による登録であることを確認します。

Board footer