ついに、実際の業務に使用するシステムの開発にかかります。 「ネジゲージ管理」ソフトを何とか作れただけの知識しかありませんが、 とりあえず作りながら理解していくことにします。
普通は、システム開発には ある程度の設計図 が必要になるのでしょうが、一人開発である（面倒）なので、直感で作っていく事にしましょう。
現在使用している 紙の「部品台帳」は部品毎に図面や購入・販売履歴が記載されており、バインダーに綴じられています。 すべての部品の過去の履歴と共に綴じられていますので、分厚いバインダー（片手で持つのは結構ツライ）が ２０冊以上が棚に 置かれているのです。
これをデータベースに収めてシステム化していくのですから、これだけでも膨大な作業であると感じます。 ただ、ケーワイ商会としての中心業務は加工部品専門商社として、図面を元に加工業者に発注して、検査し販売するという業務になりますので、 「台帳」が命綱 です。 これをまず作らない事には、今後の受注・発注・販売のシステム化に繋がらない為、初めに取り掛かるしかありません。
では、データベースを作成していくうえで必須なのは、他のデータと決して被る事のないユニークな値である[フィールド]がある事です。 図面番号等は顧客が定めた文字情報であり、また顧客によっては図面番号といった物すらなく、品名しか記載されていない物もあり「ユニークな値」でありません。
ここでは、自社でのみ使用する ID を設定する必要があるでしょう。 決して他と被る事のないID は、新規の[レコード] を作成する時に自動的に割り振られるよう設定しました。
IDは、直感ですが ７桁で ５から始まるようにしました。 5000000 から、新規のレコードを作成する毎に、自動的に１づつ増えていき、同じIDでは作成できないように設定してあります。
ここで新たな直観ですが、いきなり台帳のレコードを作成するのではなく、２段階にする方が良い気がしてきました。
まずは、製品を登録する際に、 販売先と、図番・品名を登録します。
これにより「部品マスタ」が作成され、 「ID」が生成されます。
なぜそうした方が良いかと思ったのは、マスタを登録しても販売履歴が発生しない場合があったり、図番の取得のみだったりする場合もあると予想した事や、何より 台帳 のみでは、うっかり台帳のレコードを消してしまった場合、復旧が難しいのではないかと考えたからです。 また、今後 アセンブリで使用する部品（部署が違う物の管理）台帳として使用する事も考え、2段階の方法をとる事にしました。
[部品マスタ] で、最低限の情報を登録し IDを取得
↓
[台帳作成ボタン]を押す
↓
同じIDで台帳が作成され、 各種詳細情報が登録可能になる。
といった構成にする事にしました。
この選択が、今後大きく 良い結果につながったと思います。
詳細にシステムの設計・構想を練ってはいませんが、 普段、部品販売とアセンブリ業務全体を経験した中での判断でした。
本格的にデータベースの構築へ
さて、ここからが本格的なデータベース構築 への参戦です！
データベースの構成で、「テーブル」と呼ばれる 年賀状データベースで言うところの、私の年賀状ファイル全データの中にある「レコード」 年賀状データの住所禄 1件 その中の「フィールド」氏名・住所を入力できる部分 で構成されますが、全く別のテーブルの中にあるフィールドの内容を連動して表示する機能「リレーションシップ」の理解が必須であるようです。 この概念はデータベースを扱った事のない私にとっても理解しづらい部分であったのですが、最初に購入したFileMakerの本にリレーションについて記載されていましたので、繰り返し読んでみました。
なんとなくの理解ですが、実際にFileMakerで試行錯誤を繰り返しているうちに、ある程度把握する事ができました。
つまり、リレーションシップでつながったテーブル間では、レコード内に表示されるフィールドの内容がリンクするのです。 このリレーションシップを利用する事により、データベースの情報がつながっていき、 [部品マスタ] で登録した [ID]を入力すると、図番や品名等の情報が表示される、データベースの中核である機能です。
エクセルでVLOOKUP 等の関数がありますが、それよりもさらに幅広い利用方法があり、リレーションシップを使いこなす事がデータベースを制するといっても過言ではありません。
また、のちに理解したのですが、他のテーブルのデータを参照するリレーションシップの機能の一部で、ルックアップという物もありました。 二つの大きな違いは、リレーションシップだと、参照元のデータを変更すると、参照したデータの表示も変更されますが、ルックアップだと、ルックアップを行った時点での参照元のデータが表示されますので、後から参照元のデータを変更しても表示内容は変わらないという事です。
すこしややこしくなってきますが、また年賀状ソフトに例えるならば、結婚して名前が変わった女性がいたとします。 山田 花子さんが、 田中花子さんに変わったときに、データベースを修正します。 これにより、今後作成する年賀状は 田中 花子さん宛になりますが、過去に作成した年賀状の記録まで 田中さんになっては困ります。 過去の年賀状は、あくまで山田さんに送ったものですから、変わらないようにしなければなりません。
このように、連動して変更したい部分と、発行時の情報を参照し、あとから変わってほしくない部分とで使い分ける必要があります。
当社では、部品の発注などは、図面が更新され図面番号が新しくなっても、過去の注文書情報は変わってほしくありませんので、発注を管理するシステムの図面表記は「ルックアップ」を使用する必要があるのです。