みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 （優しく回答しましょう）
You are not logged in.
Pages: 1
町内会の当番表を作るとします。
町内会のメンバーのテーブル､登校見守り係のテーブル､下校見守り係のテーブル､ゴミステーション管理係のテーブル・・・と作っていきます。
各係に数人を割当てます。あと一覧テーブルを作ります。
質問ですが､
1 A メンバーのテーブルオカレンス1つから各係にリレーションを張るのがいいか､B メンバーのテーブルオカレンスを各係ごとに作って､各係にリレーションを張るのがいいのか。
2 各係の数人をポータルにするのがいいか､繰り返しフィールドにするのがいいか。
3 各係ごとにテーブルを作るのでなく､1つのテーブルで各係のフィールドを作る方がいいか。(その場合は､以前教えていただいたようにBでテーブルオカレンスを作ります)
4 一覧テーブルにメンバーの外部キーと各係の外部キーフィールドを作って､各係の主キーとリレーションを張ろうとすると､複数のリレーションパスを設定することはできませんと言われます。一覧テーブルのオカレンスを増やして解決するのでいいか。ブイ側のオカレンスを増やす方がいいか。
以上､よろしくお願いします。
Offline
リレーショングラフの作り方は、いろいろな流儀があるらしいのでどれにするかは趣味の範疇だと思います。
テーブルは、どういうフィールドがあるのか、どういうリストが必要なのか、わからないと何とも言えませんが
自分ならメンバーの他は係テーブル1つ（任期、係、氏名）かなあ。これだと係が増えても変更が不要です。
「一覧テーブル」も不要です。
>一覧テーブルにメンバーの外部キーと各係の外部キーフィールドを作って､各係の主キーとリレーションを張ろうとする
これはつまり、同じ情報を「～係」テーブルと「一覧」テーブルの両方に入力する必要があるってことで、あんまりよくないでしょう。
町内会の当番表を作るとします。
1 A メンバーのテーブルオカレンス1つから各係にリレーションを張るのがいいか､B メンバーのテーブルオカレンスを各係ごとに作って､各係にリレーションを張るのがいいのか。
2 各係の数人をポータルにするのがいいか､繰り返しフィールドにするのがいいか。
3 各係ごとにテーブルを作るのでなく､1つのテーブルで各係のフィールドを作る方がいいか。(その場合は､以前教えていただいたようにBでテーブルオカレンスを作ります)
4 一覧テーブルにメンバーの外部キーと各係の外部キーフィールドを作って､各係の主キーとリレーションを張ろうとすると､複数のリレーションパスを設定することはできませんと言われます。一覧テーブルのオカレンスを増やして解決するのでいいか。ブイ側のオカレンスを増やす方がいいか。
以上､よろしくお願いします。
1.AにせよBにせよ多対多のリレーションになる可能性が高いと思います。
himadaneeさんの言うような係テーブル（多対多の中間テーブル）を作るのが望ましいと思います。
2.繰り返しフィールドは使い方によっては便利なものですが、この場合はポータルを利用するのがいいと思います。
3.①係マスタ ②係（中間テーブル） ③町内会メンバー の三つのテーブルが良いと思います。
4.循環参照のリレーションは作成出来ません。(リレーションが環状になっている状態)
メンバーテーブルと係テーブル（係名、日付、氏名）のテーブルだけでいいのでは。
係テーブルを日付で抽出して係で並べれば一覧表が作成できるし、氏名で集計すればメンバーごとの履歴がわかりません。
クロス集計すれば履歴を含めた配置表のようなものも作成できます。その中で係を設定していけば、重複なく入力ができます。
Offline
himadaneeさんの言うような係テーブル（多対多の中間テーブル）を作るのが望ましいと思います。
私の書いたのは、テーブル2つなので中間テーブルではないです。Shinさんの言ってるようなことです。
係に関してどういう情報があるかによりますが、係マスタを作るというのはアリだと思いますが、
ここまでの説明では単に値一覧のソース用途ぐらいしか思いつきません。それだとテーブル3つになっても「多対多」ということにはなりません。
皆様のアドバイスを参考に、試行錯誤しています。ありがとうございます。
メンバーのテーブルオカレンスは複数要るようです。
係のメンバーに名前を入れると、町内会のメンバーにも名前が追加されるようにと、リレーションシップ編集で、このリレーションシップを使用して、レコードの作成を許可としていますが、うまく動作しません。
主キーを、ファイルメーカーのハウスキーピングをそのまま使っているせいかもしれません。
名前を登録するのは、町内会のメンバー表に登録する時だけにした方が､初心者には簡単でしょうか。
使いやすくできたら、過去のデータを取り込もうと思います。
Offline
> メンバーのテーブルオカレンスは複数要るようです
なぜこう考えるのか分かりません。
Shinさんの回答のように二つのテーブルで処理できるでしょう。
Offline
係のメンバーに名前を入れると、町内会のメンバーにも名前が追加されるようにと、リレーションシップ編集で、このリレーションシップを使用して、レコードの作成を許可としていますが、うまく動作しません。
主キーを、ファイルメーカーのハウスキーピングをそのまま使っているせいかもしれません。
同じ情報を複数のテーブルに入れるのは、間違い（ミス）の元です。
「レコードの作成で許可」で自動的に入るのは、リレーションキーだけです。主キーかどうかは特に関係ありません。
「主キー＝関連側外部キー」でリレーションしてる場合は、外部キーを手入力しないでいい、というだけの機能です。（例えばポータルでは外部キーフィールドはポータル内で全部同じ値＝表示しない、でしょうから、配置されてないフィールドに自動的に記入されるということ）
町内会でも同姓同名を考慮しておく必要はあるでしょうから、氏名でなく主キーでリレーションすることになると思いますが、その場合氏名を別のテーブルに自動的に入れるには、ルックアップを設定するか、そもそも氏名のフィールドは他のテーブルには作らないでメンバーテーブルのを配置するか、でしょう。
「係のメンバーに名前を入れると、町内会のメンバーにも名前が追加される」というのは、順番が逆では。係になるまえに町内会のメンバーであるのが前提でしょう。
係のメンバーの外部キーに町内会メンバーの主キーをリレーションさせて、町内会メンバーリストから係のメンバーを入れるようにしても、うまくいかなかったのですが、
さらに、ファイル 管理 値一覧...で 町内会メンバーリストを作り､フィールドの値を使用 とすると、レイアウト作成時に係のメンバーの欄に、町内会メンバーリストから選択できるようになりました。
この解決法が合っているのかわかりません。
クロス集計について勉強します。
ファイルメーカーオンライン講座で、レイアウトの元にテーブルが必要と説かれ、一覧表の元になるテーブルが必要と思っていました。すると循環参照になるので別のオカレンスが必要と思っていました。
まだまだ勉強不足で、上級者の方々には、当たり前のことでもなかなか理解できず､申し訳ありません。
Offline
町内会メンバーテーブルと係テーブル
この二つとして、、、
係テーブルで係を作ってゆくのに、
係テーブルで作業と考えていますよね。
これを町内会メンバーテーブルのリストを見ながら係を作ってゆく。
と考えたらいかがでしょう。
一例ですが、、
メンバーのレコードをクリック
係一覧ドロップダウン表示
それを選択
で係テーブルにレコード作成が自動化できますね。
Offline
チポ様 アドバイスありがとうございます。
メンバーと係､どちらを主にするか､迷う所です。
Offline
Pages: 1
[ Generated in 0.006 seconds, 9 queries executed - Memory usage: 590.66 KiB (Peak: 607.2 KiB) ]