みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 （優しく回答しましょう）
You are not logged in.
お世話になります。
WIN/Mac
FM12A
シフト表を作成しています。
関連するテーブルは
・〔従業員マスタ〕
・〔月シフト〕
・〔シフトポータル〕
・〔日シフト〕
の４つです。
〔月シフト〕をベースにするTOに、〔シフトポータル〕を表示して、
縦軸に従業員名、横軸に１～３１日を表示するイメージです。
〔シフトポータル〕は、一人・ひと月を１レコードとしています。
日付や、表示するシフトは繰り返しフィールドを３１回で用意。
〔日シフト〕には、「日付」フィールドと「シフト略号」フィールドから、
「日付_シフト略号」フィールドを作成。
★〔シフトポータル〕のレコードに
〔日シフト〕の該当月・人のレコード（最大３１レコード分）の
「日付_シフト略号」をリスト関数で取得したいと考えています。
複数レコードを検索して、そのフィールド値を取得しようとすると、
〔シフトポータル〕のフィールドに持ってくるのは無理でしょうか？
スクリプトで、変数に持たせる？？
でも、それをどうやって、繰り返しフィールドに持っていく？
というところで、混乱状態です。★
その先には、日付から、繰り返し位置番号を指定して、
表示用の繰り返しフィールド（計算フィールド）にデータを渡し、
日付部分を消して表示をさせるイメージです。
長いですが、アドバイスを頂けるとありがたいです。
よろしくお願いいたします。
Offline
所謂、クロス集計ですネ。
随分複雑に考えすぎてDB構成が錯綜してるようです。
極力シンプルな構成のサンプルをアップしましたので、参考下さい。
従業員マスタテーブルの月次シフト管理表から、シフトレコードの新規作成や
既存レコードの削除など操作をクリック一発で出来るようにしてあります。
サンプル「月次シフト表.fmp12」→ http://yahoo.jp/box/SDF5mT
Last edited by Hiro (2013-08-31 01:55:28)
Offline
Hiroさん サンプルを作って頂きありがとうございます。
おっしゃる通り、よくわかっていないから混乱・錯綜しています。
サンプル、本当に勉強になります。
そこで、理解できないでいるのが、
１）スクリプトのなかで、
「Set」で、シフトログ２の従業員IDにg_従業員をいれて、
出勤日にg_出勤日をいれる作業がなくてもいいのは何故でしょうか？
２）シフトログ２とのリレーションで、
シフトログ２側で、
リレーションを利用してレコードの作成を許可はチェックありで、
レコードの削除にチェックがなくて、どうしてレコード削除できるのかな？
よろしくお願いいたします。
Offline
１）スクリプトのなかで、
「Set」で、シフトログ２の従業員IDにg_従業員をいれて、
出勤日にg_出勤日をいれる作業がなくてもいいのは何故でしょうか？
関連先レコードの追加は、任意の関連先フィールドへ値を入れると照合キーフィールド値（今回は2個）はFMが自動代入してくれます。
この事例では、照合キーフィールド2個のみしか無く、止むなくそのうちの一方（たまたま「従業員ID」の方）を代入して新規関連レコードを追加しています。相方キーの「出勤日」は自動代入してくれる便利な仕様を利用しています。
２）シフトログ２とのリレーションで、
シフトログ２側で、
リレーションを利用してレコードの作成を許可はチェックありで、
レコードの削除にチェックがなくて、どうしてレコード削除できるのかな？
関連レコード作成は、参照フィールドが利用できますが、
関連レコード削除は、ポータルなどで対象レコードを特定し削除（「ポータル内の行を削除」）する必要があります。
本事例は、Lookup集計法でポータルを利用し無い為、「関連レコードへ移動；関連レコードのみ表示」でシフトログ２側テーブルへ移動・削除対象レコードを抽出→「対象レコード削除」で処理しています。
※Advanced版は「スクリプトデバッカ」で実行スクリプトのステップ毎解析ができますので、お試し下さい。
Offline
非常にわかりやすい説明を頂きありがとうございました。
追加で質問させてください。
サンプルの月次シフト表では、従業員マスタテーブルがシフトのベーステーブルになっていますが、
従業員マスタとシフト表示部分を別テーブルに分けたいと思っています。
従業員マスタには
・従業員ID
・従業員名
・入社年月日
・退職年月日
フィールドをおき、
月次シフト（シフト表のベーステーブル）
で指定した年月の在籍している社員を検索して、一覧表示して、
そのシフト内容がシフトログテーブルにおさめられるという形にしたいと思っております。
従業員マスタで、
年月指定された月が入社年月日〜退職年月日の間に該当する社員を選択して
同じようにシフト表を作るには、どうしたらいいでしょうか。
月次シフト表上で、年月指定（g）フィールドにスクリプトトリガを設定し、
まず、年月指定フィールドの値を変数に設定し、
従業員マスタの中で絞り込みをしたいのですが、やり方がわかりません。
また、絞り込んだ従業員を、どのように月次シフト表に書き出すのかも、
ポータル？繰り返しフィールド？と錯綜し始めています。
ご教授宜しくお願い致します。
Offline
集計のために別テーブルを作る考えは避けるべきです。
リレーショナルデータベースでは重複したデータはDB整合性の混乱の元になるだけですから。
従業員マスタテーブルでレイアウトを「従業員管理用」と「シフト管理用」レイアウトに分ける方向をお勧めします。
Offline
Hiroさん、ありがとうございます。
従業員管理テーブルでシフトデータを扱うことは、
例えば顧客マスタに、請求データがある様な感じで、
なんとなく、すっきりしないと思ってしまいますが、
DB上で、シフト以外に、従業員マスタを使うことがあっても、
大きな問題はないでしょうか？
実用的なソリューションを作るのが初めてなので、
テーブルをどう分けるのかといったデータモデリングに困っています。
いろいろ考えましたが、考えても見えてこないので、
質問させていただきました。
Offline
従業員管理テーブルでシフトデータを扱うことは、
例えば顧客マスタに、請求データがある様な感じで、
なんとなく、すっきりしないと思ってしまいますが、
DB上で、シフト以外に、従業員マスタを使うことがあっても、
大きな問題はないでしょうか？
従業員マスタテーブルにシフトデータはありません。
シフトデータは、シフトログテーブルにあります。
従業員マスタテーブルの月次シフト管理表レイアウトでは、シフトログテーブルの従業員別関連シフトデータを参照してるだけです。
※データベースの「正規化」に基づく考え方で、DB的に全く問題ないどころか、むしろ正しいDB構成です。
Offline
従業員マスタテーブルにシフトデータはありません。
シフトデータは、シフトログテーブルにあります。
従業員マスタテーブルの月次シフト管理表レイアウトでは、シフトログテーブルの従業員別関連シフトデータを参照してるだけです。※データベースの「正規化」に基づく考え方で、DB的に全く問題ないどころか、むしろ正しいDB構成です。
疑問点があいまいで失礼しました。
月のシフトから、さらに労働時間を集計したりといった、月のシフトとして持たせたいデータもあるので、
顧客/請求書/請求明細 というようなテーブル構成のイメージのように、
従業員マスタとシフトログとの間に、月のシフトという「請求書」に当たるようなテーブルを独立させる方がいいのかな？
という疑問でした。
Offline
データベースをシンプルにする方向であらためて試行錯誤しております。
月次シフトの表示とは別のレイアウトですが、
月ごとに人件費の計算をするレイアウトが必要で、
そこでは、交通費が切符で買った方が安ければ、出勤日数x往復交通費、
定期の方が安ければ定期代を交通費とするような集計も行いたいと思っております。
このような月ごとの集計も発生するという場合は、
テーブル構成はどう考えたらいいでしょうか。
Offline
こんばんは、家内からシフト表の作成の良い方法がない？と質問され検索していました。
シフト表を作成しようとしたらとても使いやすいのが見つける事ができました。
しかし、以下の条件が必要のようでどうやったら良いのか、歯が立ちません。
交代勤務が変則です。
日勤、準夜勤、深夜勤務、休み、当直とかの選択で入力したい。
１か月に準夜勤、深夜勤務を○○回数を超えると、だめですとかアラートを出したい。
１か月の日勤回数＝何日、準夜勤回数＝何日、休み＝何日とかをカウントして表示したい。
このような条件を入れるには、どうやってやったら良いのか、全く見当がつきません。
アドバイスを頂けると幸いです。
ｆｍ12をWinで使用しています。
できれば、iPadで作成できるとなお良いのですが。。。
所謂、クロス集計ですネ。
随分複雑に考えすぎてDB構成が錯綜してるようです。
極力シンプルな構成のサンプルをアップしましたので、参考下さい。
従業員マスタテーブルの月次シフト管理表から、シフトレコードの新規作成や
既存レコードの削除など操作をクリック一発で出来るようにしてあります。サンプル「月次シフト表.fmp12」→ http://yahoo.jp/box/SDF5mT
[ Generated in 0.005 seconds, 7 queries executed - Memory usage: 557.07 KiB (Peak: 577.98 KiB) ]