2010年10月28日木曜日

リレーションシップと比較演算子

リレーションシップに使える比較演算子のテストをするため以下のテーブルを作成した。


2010年10月26日火曜日

フィールド名の変更

FileMaker のフィールド名は構築後に変更することが出来るようだ。
以下のフィールドを作成し検証した。


インタフェースとデータベース (4) まとめ


インターフェースとデータベースを切り離し、プログラム (FileMaker ではスクリプト) で手続きを記述する方法は FileMaker でも有効な方法。
しかし FileMaker にはもっと短期間で構築できる方法がある。

短期間ということは低工数であり、同時に少ないコード量で案件を実現できることに他ならない。

このあたりの柔軟性こそが FileMaker の特徴と言える。


インタフェースとデータベース (3)

FileMaker らしい設計はどのようなものか考えると次のようなものではないか。
テーブルを1つ作成し、名称を Frontend_and_Data とした。


インタフェースとデータベース (2)

レイアウトを切り替え(ターゲットテーブルを変更し)た後、新規レコードの挿入を行う方法は野暮ったく感じることもあるが、個人的には視認性とメンテナンス製に優れた方法と感じている。
以下はレイアウトの切り替え(ターゲットテーブルの変更)も新規レコードの挿入スクリプトステップも利用しない方法だが、作成者(実際のコーダー)しか理解できない(理解しづらい)構造になっている。


インタフェースとデータベース (1)


値を書き込むだけでなく、データベースの値を取得するため、以下のテーブルを作成した。



インタフェースからデータベースに値を書き込む


フロントエンドとなるインターフェースを作成し、データベースに値を書き込むため、以下のテーブル (tbl_Frontend と tbl_Data) を作成した。

なお今回はスクリプトのみで実装してみる。

フロントエンドより値の読み込み
 ↓
スクリプトによる値の取得
 ↓
データベースへ値の書き込み



2010年10月19日火曜日

入力値の自動化と主キー Primary Key (自然キー Natural key)

レコードの特定や関連付けに 人工キー Artificial key を用いた場合、インポートなどの作業で混乱が予想される。
また、検索条件として、人間がレコードIDを利用するという状況は考えづらいため、人間が理解できる自然キー Natural key を入力値の自動化によって生成してみる。

以下のテーブルを作成した。
ここでは一意 Unique な値を持たせるため、タイムスタンプを利用してみる。
もちろん、複数クライアントの環境ではタイムスタンプが一意 Unique であるとは言えないため、エントリー後半では入力値の自動化を利用した複合キーの生成も行う。


2010年10月15日金曜日

入力値の自動化と主キー Primary Key (人工キー Artificial key)

以下のテーブルを作成し、FileMakerの主キーについて考えてみた。


数字フィールドと書式設定

数字フィールドの書式設定を確認した。
以下のテーブルを作成し、 数字フィールドの初期値を1000とした。

2010年10月14日木曜日

ふりがな挿入先のスクリプトトリガー

ふりがな挿入先にスクリプトトリガーが設定されている場合について検証を行った。

 

ふりがな挿入先の入力値の制限

ふりがな挿入先に入力値の制限が設定されている場合について検証を行った。

 

ふりがな挿入先の計算値自動入力

ふりがな挿入先に計算値自動入力が設定されている場合について検証を行った。


相互にふりがなを設定する(出来ない)

以下のテーフルを作成し、相互に ふりがな を挿入出来るか確認した。


別フィールドに ふりがな を作成する

以下のテーブルを作成し、ふりがなを作成してみた。


2010年10月13日水曜日

入力値の制限

フィールドのバリデーション Validation では意図の有無にかかわらず、予想しない値を入力される。
それを防ぐため入力値の制限でバリデーションを実現する。

以下のフィールドを作成した。



フィールドのバリデーション

オペレータの数だけ入力値に揺らぎが発生する。
例えば「ファイルメーカー」という文字列に対して、「ファイル メーカー」と書く人もいれば、かな入力のオペレータの場合は「ファイルメ-カ-」と書くなど。

これを防ぐために入力値のバリデーション Validation を行う必要がある。
まずは以下のテーブルを作成した。



フィールドタイプとリッチテキストの扱い

リッチテキストの結合は、通常のテキスト結合と同じ要領で行える。
下記のフィールドを作成し、




2010年10月12日火曜日

フィールドと索引

挿入メニューの索引一覧コマンドより下表の索引を確認してみた。
 


テキストフィールドのソート

以下の設定でテキストフィールドのソートを行った。



3次元配列の作成

繰り返しフィールドは筋が悪いように感じたので改めてフィールドのみで3x3x3の3次元配列を作成した。


テキストフィールドの集計

テキストフィールドに縦計をつけ、クロス集計にしようとしたが、集計フィールドの合計として選択できなかった。

 

テキストフィールドの和

繰り返しを設定したテキストフィールドの和が取れる。
計算フィールドを追加し、計算式を Sum ( テキストフィールド ) で、計算結果はテキストとした。
暗黙の了解で型変換が行われているようだ。


数字,日付,時刻,タイムスタンプ,オブジェクトフィールド

テキストフィールド以外の(数字,日付,時刻,タイムスタンプ)フィールドもリッチテキストになるようだ。
どのような構造なのか理解できない。


繰り返しフィールド

テキストフィールドには繰り返し数がある。
繰り返し5個と5レコードを作成したところ、繰り返しのみを利用してテーブルが作成できた。

繰り返しに含まれる物はセル Cell と言うらしい。



テキストフィールド

テキストフィールドにはリッチテキストで保存できる。