みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 (優しく回答しましょう)
You are not logged in.
Pages: 1
以下のようなファイルとフィールドがあるとします。
[ファイルA]
A主キーフィールド
B外部キーフィールド
[ファイルB]
B主キーフィールド
A外部キーフィールド
ファイルAとBに対してリレーションシップを結び、ファイルAに対して新
規レコードを作ると、自動的にファイルBにも新規レコードを作るという
スクリプトを作ろうと思いました。
まず1つ質問なんですが、通常1つのファイル上に2つのテーブルがあった
場合はリレーションシップグラフは1つで済みますが、ファイルが別々の
場合はそれぞれリレーションシップグラフを同じ条件で作る必要がありま
すか?
A主キーフィールド---[=]--→B外部キーフィールド
ちなみに、私はファイルAだけにリレーションシップグラフを作り、スク
リプトを作ろうとした時に問題が発生しました。
1 新規レコード/検索
2 コピー[選択;ファイルA::A主キーフィールド]
3 貼り付け[選択;ファイルB::外部キーフィールド]
ここまで作りましたが、ファイルBの新規レコードに対して貼り付けしな
ければならないのでファイルBに対して新規レコードを作ろうとしました
が、別ファイルに対する[新規レコード/検索]というスクリプトステップ
が存在してないんですね・・・。
さて、長々書きましたが、最初に書いている通りファイルAに対して新規
レコードを作ると、自動的にファイルBにも新規レコードが作れるように
するにはどうしたら良いでしょうかという事です。
では、宜しくお願いします。
Offline
本来でしたら、1テーブルで処理するべきでしょうね。
同じキーのレコードを、あえて複数のファイルに作るのに、明確に説明できますか。
明確な理由があるのでしたら、リレーション越しにレコードを作成すればいいです。
フィールド設定[ファイルB::外部主キー ; 主キー]
だけでいいです。
ですが、酢冷苅のフィールドが存在し、ファイルAからそれを入力しますね。その時点で自動的にレコードは作られますので、その操作は本来は不要なものです。
Offline
ファイルが別々の場合でも、リレーションを行うのは実際にそのリレーションを使用するファイル(ファイルA)のみでOKです。
リレーション時に「このリレーションシップを使用して、このテーブルでのレコードの作成を許可」にチェックを付けておけば、
特に新規レコードを作るステップは必要なく、リレーション先の何かのフィールドに値を入れようとすると自動的にレコードが作られます。
今回の例であれば、リレーション先のBテーブルのいずれかのフィールドに何かデータを入れようとしたときに
A主キーフィールド---[=]--→B外部キーフィールド
のリレーション条件の元に、Bテーブルの外部キーフィールドに A主キーフィールドの値が入っているレコードがあるか?が調べられ
無い場合は自動でレコードが作られ、そのレコードの外部キーフィールドに A主キーフィールドの値が入れられます。
Shinさん
お世話になります。
本来でしたら、1テーブルで処理するべきでしょうね。
同じキーのレコードを、あえて複数のファイルに作るのに、明確に説明できますか。
実は、元々全く別の用途として作っていたモノなんですが、良く考えると
入力する部分が共通しているのが多かったので今回のような質問になりま
した。最終的には統合した方が良いのでしょうか?
イマイチ良く分かってないのが、考え方によってファイルは1つで複数の
テーブルを持った方が良いと言われる方と、1テーブルで1ファイルと言わ
れる方がおられるのですが、結局どっちが良いのか良く理解しておりませ
ん。そういうのもあり、別々のファイルでの取り扱いはどうすれば良いか
と思って伺いました。
フィールド設定[ファイルB::外部主キー ; 主キー]
だけでいいです。
なるほど、これですとファイルをまたいでのコピペなんてしなくても大丈夫ですね。
ですが、酢冷苅のフィールドが存在し、ファイルAからそれを入力しますね。その時点で自動的にレコードは作られますので、その操作は本来は不要なものです。
やはり不要なんですよね?!このリレーションシップを使用して、このテ
ーブルでの作成を許可にチェックいれているのですが、上手く挙動せず、
私なりに調べて見るとポータルで新規レコードを作成出来るとかいてあっ
たので、ポータルでないとダメなのかと諦めていました。
ちなみに、酢冷苅のフィールドというのは、外部フィールドの事ですよね?!
ありがとうございます。
Offline
mkkさん
回答ありがとうございます。
ファイルが別々の場合でも、リレーションを行うのは実際にそのリレーションを使用するファイル(ファイルA)のみでOKです。
なるほど、あくまでもリレーションを使用する側に対して必要なんですね。
逆に、このようにファイルを二つにする場合というのはあるのでしょうか?
私の場合、たまたま別の用途で使っていたのですが、同じ項目を入れる事
が多く、二度手間になると思って今回の質問に至りました。
リレーション時に「このリレーションシップを使用して、このテーブルでのレコードの作成を許可」にチェックを付けておけば、
特に新規レコードを作るステップは必要なく、リレーション先の何かのフィールドに値を入れようとすると自動的にレコードが作られます。
そうですよね?!この挙動が上手く行かず、これが上手く挙動しなかった
のでこのような質問をしたのですが、何か私自身がこの挙動の意味をちゃ
んと理解してなかったような気がします・・・。
今回の例であれば、リレーション先のBテーブルのいずれかのフィールドに何かデータを入れようとしたときに
この件がどうしても上手く行きません・・・。まず、リレーション先のB
テーブルのいずれかのフィールドに何かデータを入れようとした時という
のは、まだ新規レコードが作ってない状態ですよね?!
例えば、Aファイルには1レコード、Bファイルにも1レコードづつあるとし
ます。今からAファイルの2レコード目を入力し、その内容をBファイルの2
レコード目に反映させたい、すなわちAファイルの2レコード目を作った後、
自動的にBファイルの2レコード目を作って、BファイルのB外部キーフィー
ルドにA主キーフィールドの値を入れたいのですが、元々あるBファイルの
1レコードに対して何か入力すると、リレーション条件を元にBファイルに
自動的に2レコード目が作られるという認識で良かったでしょうか?
これですと、上手くBファイルに新規レコードが作れなかったので困って
います。何かリレーション自体に問題ありますか?
Offline
> 別の用途として作っていたモノなんですが、
なら、仕方ありませんね。そおうちにファイルの統合を考えてもいいかと思います。
> 入力する部分が共通しているのが多かった
この、共通する部分を1テーブルにする、という考え方がいいのでは。その項目の変更があれば、別ファイルにも反映させたいでしょ。
ファイルとテーブルの関係は、私は次のように考えています。
アクセス権セットとアカウントの関係で、テーブルの置き場所を決めます。例えば、会社組織ですと、部課にと役職によってアクセス権を分類できますね。別にクラブがあったとして、その組織では全く異なるアクセス権になります。例えば、営業部長が平メンバーで、平社員がチームリーダーだったり。この場合にはアクセス権セットの設定がひじょうに面倒で、1ファイルで作ることが実質困難ですので、会社用に1ファイル、クラブ用に1ファイルにします。それ以外にも、バックアップの頻度(マスターテーブルなどは、通常はバックアップは頻回でなくていいです)、ファイルそのものの編集改変などの都合に合わせていきます。ファイルを増やすと、アカウントの管理が面倒になるので、できるだけ増やさない方が、のちのちは得だと思います。
Offline
Shinさん
回答ありがとうございます。
やはりファイルは出来る限り1つが良いという考え方ですね。
確かに、今回の問題は正直2つのファイルに対して無理矢理リレーションを組むという発想になってしまったので悩んでいたんですが、統合すればより簡単に管理は可能ですね。
また、アクセス権によってファイルを分けるという発想はなかったです。
なるほど、それは非常に参考になります。
ちなみに、途中で出てきましたが、マスターテーブルは別ファイルの方が良いのでしょうか?
Offline
ファイルの統合も、分離モデルのような構造を経由すれば、手間は少なくて済みます。
とりあえず、実データのテーブルのみを統合していきます。実際には、テーブルを丸ごとインポートするのみです。その上で、全部のファイルのリレーションマップの中で、そのオカレンスが紐づいているデータソースを変更していきます。これば完了すれば、元のテーブルを廃棄(念のために、使わない状態)にします。レイアウトやスクリプトの移動も、少しずつ行っていけばいいでしょう。
マスターテーブルの管理は、その規模によるでしょう。例えば、郵便番号ファイルは全国ですと数十万レベルになると思いますが、これでしたら別ファイルにした方がいいのかもしれません。(バックアップもそれなりに時間をとりますし)
数十レコード程度の小さなマスターテーブルのみでしたら、実運用ファイルの中にあっても、影響は少ないのでは。
Offline
Shinさん
なるほど、正直統合すると便利かと思いつつ、面倒だし大変かと思いましたが、そのように考えると別に問題無いですね。
で、今考えてみると、今回のファイルを別々にしていたのは、ファイルAの中で複数の取引先に対してのレコードがあるのに対して、ファイルBはその複数の取引先に対して1社だけに対してのテーブルだったので別々にしておりました。
また、ファイルAはあくまでも現状では私だけしか使ってないのですが、そちらに改良を重ねたファイルA"というAppを現在作っており、そちらは他の者も使うように考えております。
と考えると、やはりファイルBは私しか使用しないので、別々のファイルにしておくのが良さそうですね。
ただ、統合したとしても、私しか使えないようにアクセス権を変えてやれば良いかと思ったりもしております。
少し悩んでみます。
ありがとうございます。
Offline
開発中は、別ファイルの方がいいかもしれませんが、実運用ではファイル数が増えると管理の手間が増えますので、私は統合してしまいます。制限をかけたければ、アクセス権で済む話です。
Offline
逆に、このようにファイルを二つにする場合というのはあるのでしょうか?
ファイルを2つにして使うことは私はないですね。
管理が複雑になったりするのでできるだけまとめています。
元々あるBファイルの1レコードに対して何か入力すると、リレーション条件を元にBファイルに
自動的に2レコード目が作られるという認識で良かったでしょうか?
基本的に認識は合っていると思いますが、上記の部分だけ少し違うかなと思われます。
元々あるBファイルの1レコードに対して何か入力 ではないのです
Bファイルのレコードを探しに行ったとき、リレーション条件に合うレコードがない場合に自動で新規レコードが作られます。
例えばですが、Aファイルにレコードが1つあり
[Aファイル]
主キー
00001
の状態で、Bファイルにも同様に対応するレコードがある状態とします。
この状態でAファイルにレコードを追加します。
[Aファイル]
主キー
00001
00002
となりますね。
今開いているレイアウトのテーブルオカレンスが[Aファイル]だったとして、このレイアウトで00001のレコードが選択されていると、
リレーション先のBファイルの1レコード目と繋がっている状態です。
この状態で[Aファイル]-[Bファイル]のリレーションを使ってBファイルのレコードに書き込みをすると、1レコード目の内容が書きかわります。
次にこのレイアウトで00002のレコードが選択されている場合ですが、
リレーション先のBファイルには、対応するレコードが無い状態です。
この状態で[Aファイル]-[Bファイル]のリレーションを使ってBファイルのレコードに書き込みをしようとすると、
対応するレコードがないため、新たにレコードが作られ、2レコード目にデータが入力されます。
リレーションには問題なさそうなので、レイアウト上でAファイルの2レコード目(Aファイルで新規作成したレコード)が選択されている状態で
スクリプトを動かしているかを確認してみてはいかがでしょうか。
Shinさん
やはり現時点ではそのまま進めて、完成したら統合します。
個人的にはファイルは1つが良いと思っていたので、これでスッキリしました。
ありがとうございます。
Offline
mkkさん
何度やっても上手く出来ないと思ってた時に気付きました。
A主キーフィールド---[=]--→B外部キーフィールド
こちらですが、正しくは
A主キーフィールド(ファイルA)---[=]--→A外部キーフィールド(ファイルB)
でした。これはそんなに問題ないですよね。
しかし問題はこの後でして、再度ファイルAとBのフィールドを確認すると、
[ファイルA]
A主キーフィールド
B外部キーフィールド
[ファイルB]
B主キーフィールド
A外部キーフィールド
となっておりますが、要はファイルAに入力したものがファイルBにも反映したいので、以下のようになります。
[ファイルA]
A主キーフィールド
B外部キーフィールド
A1フィールド
A2フィールド
[ファイルB]
B主キーフィールド
A外部キーフィールド
::A1フィールド
::A2フィールド
ここで問題なのは、mkkさんがおっしゃってた
ファイルが別々の場合でも、リレーションを行うのは実際にそのリレーションを使用するファイル(ファイルA)のみでOKです。
という事だったんですが、ここで私は根本的に間違っていますか?!
リレーションを使用するファイルというのは、この場合はもしかしてファイルBという事になりますか?
そうでないと、「::A1フィールド」のように参照できませんもんね?!
そこで新たに、ファイルBに対して以下のリレーションを作りました。
A主キーフィールド(ファイルA)---[=]--→A外部キーフィールド(ファイルB)
で、ファイルBに対して[=]をクリックし、
このリレーションシップを使用し、このテーブルのレコードの作成を許可
にチェックを入れました。
で、後はmkkさんがおっしゃってた手順で進めたのですが、全く新たにレコードが作られ気配がございません・・・。
一体、何が原因なんでしょうか?
長文で申し訳ないです。
Offline
説明が抽象すぎて理解しづらいですが、、
リレーション定義はレコードを参照する側で定義します。
今回の場合、
テーブルAでレコードを作り、その照合でテーブルBのレコードを作るのですから、
テーブルAで定義する必要があります。
また、
テーブルBでテーブルAを参照して、値を得たいのですから、
テーブルBで定義する必要があります。
主キー、外部キーと書かれていますが、
リレーションの照合は互いに一つのフィールドなのでは?
リレーションを使って関連テーブルの関連レコードを作るのに
フィールド設定[ファイルB::外部主キー ; 主キー]
これができるのは、テーブルBに関連レコードがないことが必須です。
もっと具体的な例で質問されれば正しい回答が得られると思いますよ。
Offline
mkkさん
自己レスです。
やはり、私が根本的に間違っている事に気付きました。
[ファイルA]
A主キーフィールド
B外部キーフィールド
A1フィールド
A2フィールド[ファイルB]
B主キーフィールド
A外部キーフィールド
::A1フィールド
::A2フィールド
これが間違いですよね・・・。
正しくは、
[ファイルA]
A主キーフィールド
B外部キーフィールド
::A1フィールド
::A2フィールド[ファイルB]
B主キーフィールド
A外部キーフィールド
A1フィールド
A2フィールド
としたら、ちゃんと新規レコードが作られました!!
正直、完全にリレーションを理解してなかったようで、この挙動を見てようやく理解出来ました。
Shinさん、mkkさん、本当にありがとうございます。
Offline
チポさん
お世話になります。
入れ違いで申し訳ないです。
実は既に解決しておりました。
リレーション定義はレコードを参照する側で定義します。
今回の場合、
テーブルAでレコードを作り、その照合でテーブルBのレコードを作るのですから、
テーブルAで定義する必要があります。また、
テーブルBでテーブルAを参照して、値を得たいのですから、
テーブルBで定義する必要があります。
私自身、先ほど自分で間違いに気付くまで、この事が未だに理解出来ていませんでした。
まさに、これを真逆に考えていたようです。
回答頂いたので、改めて自身の間違いに気付かされました。
ありがとうございます。
Offline
Pages: 1
[ Generated in 0.009 seconds, 9 queries executed - Memory usage: 593.64 KiB (Peak: 630.18 KiB) ]