FileMakerとOracleとの連携
このように、現場の担当者でもデータ入力用のシステムを容易に開発することができ、そしてそれが自動的にデータベースとして構築されるため、複数のユーザーで同時に利用できるのは魅力的です。しかし、マスターと呼ばれるデータは、社内全体で使用しているデータベースシステムで共通管理したいはずです。つまり、やはりOracleのデータとして扱いたいと思うでしょう。
先述した通り、Oracleには外部表という機能があり、OS上のテキストファイル（フラットファイル）をそのまま読み込むことができます。もう一度言い換えれば、テキストファイルのデータをOracleにローディングして取り込まずに、そのままOS上に置いたまま利用できるのです。
Oracleでの外部表の読み込み
10gでは、外部表に対して、ORACLE_LOADERアクセスドライバとORACLE_DATAPUMPアクセスドライバの2つが用意されています。ORACLE_LOADERアクセスドライバは、フィールド間がカンマ（,）で区切られたいわゆるcsv形式のファイルを読み込むことができます。ただし、そのためにはOracle側で次の準備が必要です。
- 外部表用ディレクトリの作成
- 外部表所有者、利用者に対するアクセス権の付与
「c:\temp」ディレクトリを外部表用ディレクトリ「fm_dir」と名づけ、educユーザーに権限を付与する手順を以下に示します。
-- 外部表用ディレクトリfm_dirの作成 CREATE OR REPLACE DIRECTORY fm_dir AS 'C:\TEMP'; -- 権限付与 GRANT READ ON DIRECTORY fm_dir TO educ;
次に、educユーザーで外部表を作成しましょう。データとなるレコードの区切りは改行で行われ、フィールドの区切りはカンマ（,）で行われているものとします。
CREATE TABLE course (COURSE_ID VARCHAR2(8) , COURSE_NM VARCHAR2(100) ,COURSE_PRIOD NUMBER , COURSE_PRICE NUMBER ,COURSE_TYPE VARCHAR2(30) , COURSE_OUTLINE VARCHAR2(4000) ,COURSE_OBJECT VARCHAR2(100) , COURCE_KNOWLEDGE VARCHAR2(400) ,COURSE_TARGET VARCHAR2(4000) ) ORGANIZATION EXTERNAL (TYPE ORACLE_LOADER DEFAULT DIRECTORY fm_dir ACCESS PARAMETERS (RECORDS DELIMITED BY NEWLINE NOBADFILE NOLOGFILE FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY ' " ') LOCATION ('course.csv'));
FileMakerからのテキストファイルのエクスポート
しかし、もう一つ大事なことがあります。FileMakerに登録したデータをテキストファイルに変換しなければなりません。しかし、これも簡単にできるのです。［ファイル］-［レコードのエクスポート］を選択すると、指定したファイル書式に変換し出力してくれます（図10）。
以上で準備は整いましたので、実際に外部表を検索してみましょう。（図11）
これなら担当者は、マスターとして公開してよい状態になった段階でcsvファイルに変換すればいいし、データを追加/修正中で、まだマスターとして公開したくない場合は、変換せずに以前に提供したcsv形式のファイルを社内で使ってもらえばいいのです。
現場担当者が自らデータベースを構築するメリット
いかがですか？
従来、DB設計者がヒアリングして、表（テーブル）や列（項目）を設計し、画面を作ってシステムを完成させ、現場の担当者に提供してきました。DB設計者は、「この項目のサイズは何バイトにしておけばよいか？」と一つ一つ頭を悩ませ、しかも、その結果定義したサイズも運用と共に不足するような事態が多々あったことでしょう。DB上のサイズ変更は容易にできても、プログラムの修正にはいろいろな障壁があって、すぐには対応できないことが起こりえていました。
しかし、FileMakerでは、そんなことを気にして作成する必要がないことがお分かりいただけたことでしょう。
そして、「FileMakerで新規に画面を作成してください」と言われると抵抗があるかもしれませんが、Excelで運用しているファイルをFileMaker形式に変換するだけで、簡単に基となるDBMSを作れてしまうこともご理解いただけたことでしょう。これであれば、現場の担当者レベルでの修得も容易です。
使い勝手がよければ、DBMSとしての規模は広がって行くでしょうし、現場の担当者や部内のメンバーだけでなく、全社的に活用したいデータが蓄積されていくことでしょう。そうなると、「データは一元管理したい」「管理はSEが行いたい」という思いが当然出てきます。
現場の生のデータを基に、SEが全体のシステムを構築していく
だったら、そこからでよいではないでしょうか？
DB設計者はヒアリングではなく、FileMaker内のデータ定義、画面、帳票をもとに設計すればよいのです。これは、関係者が机上で予測した内容ではなく、生のデータ、実状です。また、これをもとに、設計、開発、構築している間も、現場の担当者は日々の作業を中断することなく、FileMakerというDBMSにデータを蓄積し、活用し続けることができます。
外部表は実際のデータをOracle内に持つわけではないので、現場の担当者が提供するテキストファイルの形式が変われば、外部表を再度作成しなおすだけです。外部表のデータは更新ができない点のみが、普通の表と異なるだけですから、他の表と結合することもできますし、外部表のデータをソースとして（基データとして）、別表を作成することも可能です。
次回予告
しかし、まったく何も無いところからデータを起こすことよりも、既に、Oracle内にマスターデータが存在し、新たなニーズからトランザクションデータが新規に発生する場合もあるでしょう。いえ、このケースの方がむしろ多いのかもしれません。
そこで、次回はこの逆、つまりOracle内のデータをFileMakerからアクセスする方法について考えてみます。
