よろしくお願いします。
事件管理ソフトの前に、簡単な見積システムなんかを作ってみます。
データベースの構造を知る上で、てっとり早く簡単に理解がしやすいからです。
まずはFileMakerの無料評価版をダウンロードします。
買うのなら、ちょっと高いけどFileMaker Pro Advancedをお勧めします。
理由はスクリプトデバッガとデータビューアがついてるからです。
テーブルインポート、カスタム関数が使えるのもいいですね。
僕は１４のAdvancedで作ります。
データベース（以下DB）は、通常SQLとPHPなど、データベースとアプリを分離して開発しますが、FileMakerは、何も考えずに、これひとつで開発できますので、プロじゃなくても非常に早く簡単に目的にたどり着けます。分離開発は、FileMakerにもExecuteSQL関数がありますので、やってやれないこともないのですが、開発の仕方を間違えると、遅く、使えないシステムになってしまうこともありますので、素直にそのまま使用する事をお勧めします。
---- それでは始めますね ---
新規ソリューションから ファイル名「Test1」を作り
テーブルを作っていきます。
・見積
・見積明細
・商品マスタ
・得意先
日本語ですよ。
日本人なら日本語がいいに決まってるじゃないですか。
テーブルを作ったら、各テーブル毎にデータを入れるためのフィールドを設定していきます。
見積（テーブル）には
・伝票No（テキスト）
・得意先No（テキスト）
・日付 （日付）
同じく
見積明細（テーブル）
・伝票No（テキスト）
・商品No（テキスト）
・商品名（テキスト）
・単価（数字）
・数量（数字）
・金額（計算） ＝単価×金額
商品マスタ（テーブル）
・商品No（テキスト）
・商品名（テキスト）
・単価（数字）
得意先（テーブル）
・得意先No（テキスト）
・得意先名（テキスト）
を作ります。
ファイルを作った時に勝手にできたTest1のテーブルは放置してください。
次はリレーションです。
得意先（テーブル）の得意先Noから
見積（テーブル）の得意先Noをドラッグして線で繋げます。
見積（テーブル）の伝票Noから、見積明細（テーブル）の伝票Noまでドラッグして
線で繋げ、レコードの作成許可と、一緒に削除の２か所にチェックを入れます。
見積明細（テーブル）の商品Noから、商品マスタ（テーブル）の商品NOまで
ドラッグして線で繋げます。
テーブルは文字通り仕事の机と同じで、
田中さんの机と、佐藤さんの机を、あるKeyで結び同時に仕事をする事と似ています。
このとき、田中さんが作ったデータと、佐藤さんが作ったデータは、合わさって見えるのですが、データはしっかりと別々の机で保管されています。この関係をリレーション（関係）と呼び、
これができるデータベースをリレーショナル・データベースと呼びます。
primary key (主キー）や外部キーについては、今回は省きます。
見積明細（テーブル）の商品名フィールドと単価フィールドを商品マスタ（テーブル）の同じ名称のフィールドからルックアップさせてデータを保管させます。
データの正規化と冗長性については後程説明します。
見積（テーブル）の伝票Noをオプションでシリアル番号を設定します。
１+１でも、0001+１でも、自由でいいです。
同じように、日付フィールドを作成日にチェックします。
得意先（テーブル）の得意先Noもシリアル設定をします。
商品マスタ（テーブル）の商品Noもシリアル設定します。
※ 見積（テーブル）と見積明細（テーブル）は伝票Noで照合されていますが、
見積明細（テーブル）側の伝票Noはシリアル設定をしてはいけません。
見積明細（テーブル）の伝票No以外のデータが入力され確定された時点で
自動的に見積（テーブル）側の伝票Noが生成されます。
見積（テーブル）のレイアウト画面を開き、見積明細（テーブル）のポータルを作ります。
田中さんの机の上で、佐藤さんの机が見えるような状態（不思議ですね～）
ポータルにフィールドを追加します。
このとき、明細の伝票Noは省いて結構です。
こんな感じになりますが、全部同じ幅だと変ですので、フィールドの幅と書式を設定します。
数字フィールドは右寄せ、小数点以下、３桁区切りなどを設定します。
見積（テーブル）に得意先（テーブル）の得意先名フィールドを置きます。
あれ？と思うでしょう。
見積（テーブル）側に得意先名フィールドを作って、さっきと同じようにルックアップさせて
データを保管させなくてもよいのかと・・・・。
それでもOKなんです。
でも、あえて、見積（テーブル）とキーで結んだ得意先（テーブル）から得意先名を参照させることにしました。
実は、なぜ見積システムを作るのかは、これを説明したかったからなんです。
先程の見積明細(テーブル）の商品名や単価もルックアップさせずに、キーによって参照させることによってデータを表示させることが可能です。（これが正規化です）
なぜ、そうしなかったのか・・・
一つには、参照させて表示させる事は、この見積（テーブル）画面で、マスタ側のデータも変更できてしまう！ということです。
そこに不具合が生じるか否かを、使用者側の用途によって決定させなくてはいけません。
例えば、見積もりの場合、明細（テーブル）ポータル上で商品マスタにある名称や単価が操作（参照して表示）できれば、まるで学習機能かのようで便利ではありますが、過去の取引データの変化が取得できません。
８月１５日 りんご １００円
９月１１日 りんご １０１円
という単価の変化を明細で取得したいのに、正規化したいがために、商品マスタを参照させ過去のデータまで
８月１５日 りんご １０１円
９月１１日 りんご １０１円
に上書きされてしまったら、取引の変化が分かりません。
見積もりや売上請求、仕入・買掛など、相手と取引する業務では、「過去と現在に変化があって当然」と決定されれば、ルックアップさせて、データを保管させ、あえて冗長させる手段をとります。
いやいや、過去データよりも、どんどんマスタ・データを参照させて上書き（正規化）させれば、データも更新され「楽なんだ」と考える場合は、過去の明細単価まで一斉に変わってしまいます。
もう、これは開発者より、使用者が決めなくてはいけません。
見積書という概念で考えると、得意先名が伝票入力時に変更される事は考えられないので正規化でいいのだと考えます。一方、明細内の商品単価は、原料の値上げや、諸事情などで今回の取引上の単価が変わるなど日常起こりうることです。
マスタ側のデータはそのままで、明細上で単価変更が出来き、過去の取引金額の変化が分かった方が良いでしょう。
見積ならまだしも売上請求で過去の明細データが変わってしまったら、ソフトウエアとは言えないものになってしまいます。
リレーションといっても、なんでもかんでも正規化すると、実際の業務に支障をきたす場合がありますので、現場実務を考慮して判断しなくてはいけません。
また、メンテナンスなど、ファイルが壊れ、NOと名称を合わせるのが大変な場合、ルックアップされてデータが保管されていれば、「０００３番はリンゴ」というデータが確認できますが、正規化された場合は、NOがなんの商品なのか分からなくなる可能性もあります。
（だからといって、なんでもルックアップも止めましょう）
さてさて、見積（テーブル）の合計フィールドをSum関数を使って、
見積明細（テーブル）の金額を指定します。
まぁ、見栄えの問題でもありますが、ポータルをクリックし、代替の行状態にチェックを入れます。
インスペクタで、各フィールドの入力しなくてよいものを選び、ブラウズモードを外します。
入力するフィールドに色を付けてみます。
レイアウトモードにして、レイアウトメニューからタブ順の設定を行います。
キーボード操作で次のフィールドに移れるのは便利ですね。２分でできます。
（最近クラウドを使ったWebでの業務アプリが増えてきましたが、FileMakerでは、このタブ順でキーボード操作を設定するのは便利ですよね、Webソフトでは下手するとEnterキーを押すたびに送信したりして使い物にならなくないですか？最近ではjqueryのイベントなど使ってコードを書けるようにはなりましたが、何日もかかりますし、開発が嫌になります。実際、現場実務でのWebソフトは、まだちょっと処理も遅く駄目っすね～）
必要のない箇所の番号は削除します。
TabキーとEnterキーで次のフィールドに移るように設定します。
これで、非常に簡単で簡易的な見積システムが完成です。
得意先（テーブル）と商品マスタ（テーブル）にデータを入れて
実際に操作してみましょう。
消費税の設定やデータのコミット（確定）は後日、説明します。
今回はスクリプトを一切使っておりません。
ダウンロード
（今回の分）
