みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 （優しく回答しましょう）
You are not logged in.
Pages: 1
環境
FileMakerPro19&Server
OS:Windows10
すみません。基本的なところだと思いますが、
教えてください。
「発注No」と言うレコードを元に、指示書テーブル(A)と注文詳細テーブル(B)をリレーションし、
Aのレイアウト内にBを配置しています。
また、「JANCODE」と言うレコードを元に、Bと商品詳細テーブル(C)をリレーションしてあります。
Aには、いくつかCと同じ名前のフィールドがあるので、
Aのレイアウト内のBにJANCODEが入力されたら、Cからルックアップさせて入力させたいと思っていますが、
うまくいきません。
根本的に、１対１でないとリレーションは出来ないのでしょうか？
また、上記を行うためにはどのようにすれば良いでしょうか？
宜しくお願い致します。
Offline
ルックアップの必要があるかというところには触れずに。
BとCにリレーションを設定しているとき、ルックアップが利用できるのはBまたはCのフィールドです。
ルックアップが実行されるのはそれぞれの照合フィールドが変更されたときです。
AのフィールドとCのフィールドが同じものを差しているとしても
Bが入力されたときにAのフィールドがBとリレーションしているCの値をルックアップすることはできません。
AとBは一対多の関係と思われますが、即ちAとCも一対多となります。
どのCの値をとるのを正とするのでしょうか？
Offline
> 指示書テーブル(A)と注文詳細テーブル(B)をリレーション
AとBのレコードは 1対多 になるんですよね。
とすれば、
> Aのレイアウト内にBを配置
配置したBテーブルのフィールドは、
関連レコードのうち、最初に照合されたレコードのフィールドになります。
> Aのレイアウト内のBにJANCODEが入力されたら、Cからルックアップ
Aテーブルのフィールドにルックアップで入力ということなら、それは無理でしょう。
Offline
Mozさん、ありがとうございます。
はい、ご心配いただいている所（一対多）は重々承知しております。
Aには、最大20ヶまでBの入力が可能になっています。
Aの１レコードに入力するBの仕様は同じものと言う約束の元に入力をさせます。
具体的なイメージとしては、
注文された商品Bは絵柄が違うだけで、絵柄以外の仕様部分は共通なので、
この20アイテムの中からなら極端な話どのデータを引っ張ってきても「正」なのです。
繰り返しになりますが、
仕様自体はいくらでも種類が存在するのですが、
ことＡの1レコードに対しては入力をする段階で、同じ仕様のアイテム（絵柄の異なる）だけを入力するので、
問題ありません。
（いろいろと入力の制約をしないといけないとは思いますが、ここではいったんそれは置いておいてください）
Offline
チポさん、ありがとうございます。
> 指示書テーブル(A)と注文詳細テーブル(B)をリレーション
＞AとBのレコードは 1対多 になるんですよね。
はい、そうです。とすれば、
> Aのレイアウト内にBを配置
＞配置したBテーブルのフィールドは、
＞関連レコードのうち、最初に照合されたレコードのフィールドになります。
その最初に照合されたCの情報でよりので、それをAにもってきたいのです。> Aのレイアウト内のBにJANCODEが入力されたら、Cからルックアップ
＞Aテーブルのフィールドにルックアップで入力ということなら、それは無理でしょう。
これが結論ですかね（泣）。
Offline
> Aのレイアウト内のBにJANCODEが入力されたら、Cからルックアップさせて入力させたい
B の JANCODE にトリガーを仕掛けて、A のフィールドに設定する、なら作れると思いますが。
でも、その動作の必然性がわかりませんね。
Offline
Shinさん
CとAのリレーションを組んで、そこでやり取りさせるのですね。
やってみます：汗
Aは汎用の製造指示書。
Bは別テーブルにした製造指示されたアイテムの詳細を保存
（どちらかと言えば一過性の商品用で、基本的な仕様は同じで絵柄だけ違うものを20アイテムまで登録可能）
Cは自社商品の商品マスターです。
これまで、AtoBだけを使用してきましたが、
自社商品の生産指示もこれを使用する事になったため、
自社生産依頼の場合は、JANCODEを入力することでCから情報を引っ張ってこようと考えたのです。
ほかに良い方法を思いつけば、やっているのですが、
これくらいしか思いつかなかったもので（汗）。
必然性の説明にはならなかったかもしれませんが、背景はそのような感じです。
Offline
C は、自社製品の詳細を保存 したものでしょうか。
A のテーブルから見ると、自社製品も一過性商品も、同列のものですよね。ですから、その2テーブルが存在することが理論上は間違いです。2テーブルを統合してしまえば、何も考えなくて良いですよ。
Offline
Shinさん
はい、Cは自社製品の詳細を保存した「商品マスター」です。
「商品マスター」ですので、製造情報以外のものも含み、別のファイル、別のテーブルとも連携しています。
Aはあくまで、これをつくれ！とする製造指示をするものなので、
一過性の案件は直打ちで完結させ、自社商品を作らせたいときは必要に応じて、マスターデータを転用して持ってこようとしているわけです。
ですので、２つを統合と言うのはちょっと考えにくいと思ってしまうのですが、、、、
ニュアンス伝わりますでしょうか？
Offline
その事情は最初からわかっていますが、データベースの設計理論とは噛み合いません。
無理矢理、その動きを作ることはできますが、まさに力業でデータをむしり取ってくる、という感じです。
別に、商品マスターの管理番号と、、一過性商品の管理番号を1テーブルで管理させ、、その先はそれぞれ別のテーブルを参照する、という構造は作れるでしょうが、、そのテーブルのメンテナンスが常に必要になります。
Offline
どうも話がかみ合っていないような、、
各テーブルの説明が不足していますよ。
> 指示書テーブル(A)
これは1発注ごとに1レコード
ですよね。
そこで疑問なのが
> Aには、最大20ヶまでBの入力が可能になっています
このフィールド構成がわかりません。
> 注文詳細テーブル(B)
このテーブルがわかりません。
指示書テーブルの詳細で、1発注商品ごとに1レコードで、
指示書テーブルの1レコードに対して、複数の関連レコードがある。
ですか？
として、
テーブルCの商品もここに登録される。
ですか？
ほかにも疑問がありますが、とりあえずここまで、、
Offline
一過性の製品の場合に、テーブルAとテーブルB に、マスター（テーブルC）と同じような製品の情報（サイズ加工など）が、手打ちで入力され、その情報を使ってテーブルAから作成指示を作っていた、
今まで、テーブルAでの作成指示伝票は、一過性製品だけに限っていたが、今回、自社製品（テーブルC）の作成指示も、テーブルA で行うように業務を変更する、
ということなのでは。
> ですので、２つを統合と言うのはちょっと考えにくいと思ってしまうのですが、、、、
どちらも、貴方の会社の製品、というカテゴリーで考えれば同列のもので、製作情報は共通なのでは。それ以外の情報は別にして。
同じテーブルで製品として管理し、一過性商品、自社製品という区分ができるようなフラグを持たせておけが管理できます。
話は違うのですが、常連顧客と一元の顧客をテーブルで管理する時に、別々のテーブルに作りますか？携帯電話の電話番号簿が、お気に入りとそれ以外で別々に検索されるように作ってあれば、どうでしょうか。
Last edited by Shin (2021-07-07 11:40:18)
Offline
多分チポさんと同じ疑問というか･･･。
これって、そもそも
指示書テーブル(A)ー注文詳細テーブル(B)は
発注Ｎｏでリレーションした１レコード同士なのでは？
１対多じゃなく･･･。
> Aには、最大20ヶまでBの入力が可能になっています
ＡのレイアウトにＢ「::JANCODE」が貼り付けてあって
それが繰り返しフィールド[20]
という構造では？
で、１個目の「JANCODE」しかルックアップできないとかっていう感じ？
＞＞指示書テーブル(A)と注文詳細テーブル(B)をリレーション
＞＞AとBのレコードは 1対多 になるんですよね。
＞はい、そうです。
ってあるから違うかもですけど。
Offline
Shinさん、チポさん、さすらいのダンサーさん、
諸々ご説明が足らず申し訳ありません。
この指示書は、「額装商品」の生産指示書でして、
額縁やそこに貼るシールの仕様は同じ、
そして、中身のイラストは20柄までを入力できるようにしています。
注文詳細テーブル（B）は、このイラストに関する部分のデータを入れています。
（繰り返しフィールドではありません）
ちなみに、自社商品の指示書を作る際も、
Ｃからデータをひっぱり、Ｂに転記して、
生産指示の履歴にします。
ご理解いただけましたでしょうか？！汗
不足がありましたら、なんなりとご質問をいただければと思います。
宜しくお願い致します。
Offline
一過性案件では、仕入れた額縁を使う、という話しのようですね。
一過性案件では、JANコードは入力しないのですか。
一過性案件では、同じ商品は1度切りしか使用しないのですか。
その商品についての詳細情報は、今後一切流用使用しないのですか。
Ｃからデータをひっぱり、Ｂに転記するデータ（Aに転記するの間違い？）はたくさんあるのですか。
具体的に、どのような情報を転記したいのですか。
Last edited by Shin (2021-07-09 17:31:59)
Offline
Shinさん
一過性案件でもJANは入力する事がありますが、他社のOEM（他社JAN）なので当社の商品マスターでは管理しません。
一過性案件は必ずしも一度切りではありませんが、その場合は前回の指示書のコピーを行い対応しています。
CからAへは、使用する額縁の型番、サイズ、パッケージ詳細、添付する取説、JANシール、説明書などの有無、添付位置などの情報を、
CからB（Aのポータル表示されている部分）には、絵柄のjpg、額に貼るプレートの画像、絵柄備考の情報を、
それぞれ引っ張ります。
C（自社商品）の比率は全体の10％にも満たない感じです。
現在はルックアップではなく、変数にして、フィールド指定で張り付ける方法も試し始めています（汗）。
Offline
Cの自社製品に対して、絵柄のjpg、額に貼るプレートの画像、絵柄備考の情報は、どのように収納してあるのですか。
OEM製品について、テーブルBの内容も前回と同じですか。
私が設計するなら、OEMについても、C にデータを保存してしまいます。Cのなかで、OEMか自社製品かのフラグを持たせて（JANをみれば一目でわかりますが）、通常はOEMを見せない（自社製品のJANだけを持たせて、裏にCをつないであるテーブルを作ってもいいかも）、という運用にしますね。その構造でしたら、すべての生産製品が一元管理できますし、今の運用と見た目も変わらない運用が可能です。
簡単な構造だけのサンプルです。
https://www.dropbox.com/s/8jjjyjwfmygp1 … 2.zip?dl=0
Offline
Cの自社製品に対して、絵柄のjpg、額に貼るプレートの画像、絵柄備考の情報は、どのように収納してあるのですか。
OEM製品について、テーブルBの内容も前回と同じですか。
https://www.dropbox.com/s/8jjjyjwfmygp1 … 2.zip?dl=0
各オブジェクトフィールドの画像は、外部保存に設定してあります。
OEM製品のテーブルBも同様です。
私が設計するなら、OEMについても、C にデータを保存してしまいます。Cのなかで、OEMか自社製品かのフラグを持たせて（JANをみれば一目でわかりますが）、通常はOEMを見せない（自社製品のJANだけを持たせて、裏にCをつないであるテーブルを作ってもいいかも）、という運用にしますね。その構造でしたら、すべての生産製品が一元管理できますし、今の運用と見た目も変わらない運用が可能です。
簡単な構造だけのサンプルです。
https://www.dropbox.com/s/8jjjyjwfmygp1 … 2.zip?dl=0
はい、私も、「OEMもCにデータを持たせる」という方法考えました。
ただ、これまでの蓄積、他のファイル、テーブルとの連携などの切り替えが面倒くさく思えてしまうのと、
OEMは半数程度JANがないという問題もあります。（まぁそれでも紐づける方法があるんでしょうが）
今、作りこめば作りこむほど、Shinさんがおっしゃる通り無理やり感が出てくるので悩んでいます（汗）。
簡単な構造だけのサンプルです。
https://www.dropbox.com/s/8jjjyjwfmygp1 … 2.zip?dl=0
サンプルまでご用意いただき、ありがとうございます。
その他のカスタムアップ等の開発スケジュールなども考慮しつつ検討させていただきます。
ありがとうございました。
このスレもこれで一旦解決とさせていただきます。
この件の絡みなど新たな問題が出て参りましたら、
またお付き合いいただければ幸いです。
宜しくお願い致します。
Offline
> これまでの蓄積、他のファイル、テーブルとの連携などの切り替えが面倒くさく思えてしまう
自社マスターで一覧するレイアウトと、そこから商品情報を入力する部分だけを、自社マスターJAN と、Cテーブルの関連フィールドに変更すればいいです。それ以外は、ほとんど今のままでいいはずですよ。
JANがなければ、UUIDでも貼り付けておけばいいでしょう、
デフォルトでUUID数字をセットしておき、JANの入力で上書きするようにしておけば、入れ忘れがありません。
Offline
Pages: 1
[ Generated in 0.028 seconds, 9 queries executed - Memory usage: 577.01 KiB (Peak: 613.91 KiB) ]