FC2ブログ














スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
[ --/--/-- --:-- ] スポンサー広告 | TB(-) | CM(-)

業務日誌を考える 3

いや〜どうも。

梅雨みたいな天気が続きますね。
夏はやっぱり暑くなくっちゃいけねぇやな。んでもって冷たいビールを、グビ、グビ、クーッっとこういきたいもんだよね。

前回は繰り返しの話をしました。今回はその続きです。

り返しフィールドの落とし穴とは
 ずばり、集計や検索に難があるということです。森田検索、いや検索を例にとってみましょう。
繰り返しフィールの検索って検索をかけた時にそのフィールド内に文言があれば全て拾ってくるんですよ。ちょっとわかりにくいです。今回のケースですと日誌なので1日ごとにデータが増えていきますよね。

のちに井上さんの勤務で半日ってのはいつだっけか?なんてことがあると、じゃあ検索しようって話になります。
検索条件としては名前が「井上」で勤務区分が「半日」のand検索になるのですが、この時、今ケースですと繰り返しフィールド1〜5中の文言がすべて対象になります。ですから、井上さんが通常勤務であっても、誰かが半日勤務をしていればそれも該当として拾ってくるんですよ。

スクリーンショット 5

ところが

スクリーンショット 6

通常、データを二次利用することがほとんどですよね。勤務を調べたり時間外を計算したり、何日有休を取ってるとかって。
二次利用しなくていいって時は繰り返しフィールドは便利なんですが、それ以外は他の方法を使いましょう。

今日はここまでッス。次回は他の方法についてです。


スポンサーサイト
[ 2015/08/29 02:34 ] 業務日誌 | TB(0) | CM(0)

業務日誌を考える 2

いや〜どうも。

8月だというのに肌寒いですね。長袖がちょうどいい、そんな感じです。
今回はフィールドについてをどう用意するか?について考えてみます。

前回レイアウトを紹介しましたが、今回もそれに似たレイアウトを作ってみました。
↓がそれです。
スクリーンショット 2

見た感じはほぼ一緒です。では中身を見てみましょう。
スクリーンショット 3

ここでは必要なフィールドを用意していますが、注目して欲しいのはタイプのところに[5]とあるところです。
これは繰り返しフィールドを使用していることを意味しています。そしてその繰り返し数は5になっています。
レイアウト画面で確認してみましょう。
スクリーンショット 4

各フィールドが縦方向に1〜5まで並んで配置されています。
繰り返しフィールドを使うと簡単に表が作れてしまいますね。便利ですね〜と言いたいところなんですがみなさんご存じのように繰り返しフィールドには落とし穴があるんですね。

続きは次回。
[ 2015/08/28 12:34 ] 業務日誌 | TB(0) | CM(0)

業務日誌を考える 1

いや〜どうも。

だいぶ涼しくなってきましたね。日が沈むと外ではちょっと肌寒いくらいです。
さて、前回までのポケモンはビジネス以外にもホビーに使えるよって話です。企画的にピンとこないので打ち切りにします。

今回からは業務日誌を考えるです。
とくに、業務日誌で必ず記載されるであろう出勤者と時間の部分にターゲットを絞りたいと思います。

下のような感じですね。
スクリーンショット 1

これをどのように構築していくかについて考えていきたいと思います。

今日はここまで。

おかげさまでセミナーの人数も増えて、何とか形になりそうです。
セミナー後の懇親会を楽しみにしています。
[ 2015/08/23 21:53 ] 業務日誌 | TB(0) | CM(0)

FileMakerでポケモン対戦データベース 5

いや〜どうも。

やってみると面白そうだと思ってやってみると意外につまんない企画ってありますね。
この記事もそうでしょうか?挫折しそうです。
でも、前記事もそうですけどFileMakerの基本を押さえているといろんなFileに応用できるんです。そういった意味ではまあ、意義のある記事かなと思っています。今回もそんな基本技をお伝えするつもりです。

ではでは、はじめます。

わし「前回までで対戦用のテーブルが出来ましたね」
伊藤「そうですね」
わし「今回はインターフェイステーブルを作るよ」
伊藤「ほー、インターフェイステーブルですか」
わし「そう、FileMakerっていろんなテーブルがあって、その各々を表示するだけってこともよくあるんですよ」
伊藤「ふーん」
わし「今回はそんなんで、対戦相手のパーティを表示させるためのテーブルをつくります」

フィールドは以下を参考にして下さい。
スクリーンショット 3

で、レイアウトは下を参考に。
スクリーンショット 1

伊藤「うーん、何の変哲もないんですね」
わし「まあ」「強いて言えば新規ボタンに割り付けたスクリプトかな」
伊藤「ほー」
わし「これを利用すると、定期的に繰り返し表示させるようなもの・・・・、うーん業務日誌の実績とかに使えるかな」
伊藤「うーん、今のところイメージがつきませんが」
わし「まあ、のちのちね」

わし「今日はこのテーブルの動作を説明するわね」
伊藤「はい」
わし「下の様にボケ番もしくは“なまえ”のところに入力すると各パラメータが表示されるってわけよ」

スクリーンショット 4


スクリーンショット 5

通常、FileMakerでルックアップ機能を使う時には数字データをリンクさせるのがよいのですが、600を超えるキャラの番号をいちいち覚えてられませんよね。値一覧の表示を下のようにすることも可能ですがやっぱり番号基準なので勝手が悪いです。

スクリーンショット 6

なので、なまえで入力するのが今回の場合は適しています。
だいたい、ポケモンをやり込んでいる人はポケモン名はほぼ覚えていますからね。

わし「名前をクリックするとポップダウンリストから値一覧が表示されるわけ」
伊藤「でも、それだと600を超えるキャラがあいうえお順に並んでいるんで、ラ行やワ行とかにたどり着くのがめんどうですね」
わし「そこでや、最初の1文字を入れるとシュッと絞り込まれるようにするわけや」

スクリーンショット 8

伊藤「あー、これは便利ですね」
わし「これがオートコンプリート機能や」

スクリーンショット 7

伊藤「先輩いろんな事知ってますね」
わし「いや、それほどでも」
伊藤「どこで勉強したんですか?」
わし「FileMaker好きCEの会共催の『ファーストステップ in FileMaker for CE* Vol.1 基本から学ぼう』や」
わし「これは、ええで、基礎からしっかり教えてくれるんでな」
伊藤「ほんとですか?」「そんなに言うんなら今度行ってみようかしら」

今日はここまで。
次回は、ルックアップorフィールド表示です。

[ 2015/08/10 18:28 ] ポケモン | TB(0) | CM(0)

FileMakerでポケモン対戦データベース 4

いや〜どうも。

今日は曇っているおかげでだいぶ暑さが和らいでいますね。
さて、前回はマスターとなるポケモンデータベースが出来上がりました。
今回は相手パーティを登録するためのテーブルをつくります。
こちらのテーブルの役割としてはポケモン名を入力するとそのポケモンの各パラメータが表示されるようにするというものになります。

では、どうぞ。

伊藤「先輩、なにしてんですか?」
わし「ん、これや」
伊藤「あ、ポケモンORASですね」「レートバトルですか」
わし「せや、勝たれへんねん」「レート1430やねん」

伊藤「先制で攻撃した方が圧倒的に有利ですからポケモンのスピードが大事になりますよね」
わし「せやけど、600を超えるキャラのスピードなんかいちいち覚えてられへんで」
伊藤「こんな時はFileMakerなんじゃないですか」「まさにデータベースの世界ですよね」
わし「えっ」
伊藤「相手パーティのパラメータ一覧と自分パーティの比較が出来たら勝率も上がるんじゃないですか」
わし「たしかに」

伊藤「これよかったら使って下さい」「自分が作ったポケモンのデータベースファイルです」
わし「よし、ほんならこのファイルを使って一覧表を作ったろやないか」

わし「まずはこのファイルを見てみよか」

スクリーンショット 7

わし「おー、ええ感じに仕上がっとるやないか」
伊藤「あざーす」

わし「今回はこのファイルを利用して相手パーティの一覧を表示するテーブルを作ろう」
伊藤「うい」
わし「ほんじゃ、テーブルをもう一つ作るで」「テーブル名は対戦としよう」
伊藤「このテーブルはどんな風に使う予定ですか?」
わし「そやな、このほかにも1つテーブルを作ってやな」「そのテーブルに下のように表示させるつもりや」

スクリーンショット 1

伊藤「なるほど、“対戦ID”フィールドでリレーションするんですね」
わし「そう、全体的なイメージはこんな感じ」

スクリーンショット

わし「ほな、いくでー」「フィールドは以下を参考にな」

スクリーンショット 2

ここで少し解説です。
上図のように各フィールドを設定しましたが一番上のIDフィールドは主キーとよばれるものでユニークな数字になります。
このデータベースでは主キーを設けなくても特に支障は無いですが、データベースを作る上で主キーは設ける癖をつけていた方がよいです。
ユニークな値といえばポケ番(ポケモン番号)もそうなんですが、これとは別にデータベースのデータを扱う上という意味で主キー専用のフィールドは設けておいた方がいいです。

話はちょっとそれますが、例えば機器管理台帳を作る時なんかは各装置に管理番号を振りますよね。A-0001なんて感じで。
この番号は当然ユニークな値になるのですがこれを主キーにしてはいけません。何かの事情によりルールが変わってAA-NK001なんて風に管理番号が変わってしまうとデータを扱う上でとっても苦労します。この時、データ管理上の主キーを設けておくと管理番号が変わることで大きな影響を受けることが無くなります。
このような考えはデータを設計する上で非常に大事なことです。また、主キーは特に意味を持たせる必要は無く単純に連番でかまいません。シンプルイズバストということですね。

今日はここまで。逸れた話の方が重要でしたね。

では。

最近、腹の肉がタップン、タップンしてます。酒のせいかな?

あと、セミナーは必ずやります!



[ 2015/08/08 17:24 ] ポケモン | TB(0) | CM(0)







上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。