はじめに
前回、「必要なデータは現場で管理させる」という投げかけをさせていただきましたが、「データをユーザーの手元で管理させていいのか？」「ユーザーのデータを社内で共有するためにデータベースに吸い上げるよりも、データベースサーバー内のデータをユーザーの手元にコピーさせる方が多いのではないか」と感じた方も多かったことでしょう。
そこで今回は、Oracle内に存在するデータをFileMakerに取り込むことを考えてみます。
フロントエンドツールとしてのFileMaker
ODBCでつないで、単なるフロントエンドのツールとして利用するだけであれば、FileMakerである必要はありません。開発ツールとしてのFileMakerの良さだけでなく、データベースとしてのFileMakerの機能を活かすべきです。
つまり、「社内で共有する必要のあるデータ」はOracle内で管理し、「一担当者、つまり特定の人しか必要としないデータ」をFileMakerで管理することにしましょう。
一担当者が管理するデータと言っても、個人のPCの中にデータベースを作るわけではありません。FileMakerも、クライアント／サーバーのシステムを構築することができます（詳細は、製品紹介ページを参照のこと）。従って、FileMakerデータベースは個人のPCではなくサーバー上で管理しましょう。
その上で、データがどこにあるのか（OracleなのかFileMakerなのか）、データの混在を意識せずに利用できる環境構築を考えてみます。
なお、「全部Oracleで管理してしまえばよいではないか、一担当者しか必要としないのにデータベース化する必要のあるデータなんてあるの？」という声もあるでしょう。
ここでいう「一担当者」とは、「物理的に一人の」というわけではなく、「その業務に携わる限られた人」という意味です。会社で扱うデータである以上、担当者が風邪で休んだら、どこにどの情報が管理されているのか分からない、というのでは困ります。だからと言って、共有ファイルサーバーの利用を許可すると、エンドユーザーは何でもファイルサーバーに置きたがり、サーバーがパンク寸前という話もよく聞きます。
今回想定するデータベースの用途
前回、研修実施会社のデータを例にしたので、その続きで考えて見ましょう。
研修会社は、OracleやMicrosoftなどのベンダー研修を実施する際、ベンダーから研修テキストを仕入れます。そして、バージョンが新しくなれば古いテキストをベンダーに返品します。研修テキストが買取りでない場合、研修実施会社は、手元に何冊在庫を持っていようが返品してしまえば済むので、倉庫にスペースがある限り、何冊でも在庫しておけばよいでしょう。
しかし、ベンダー側としては、返品されるとマイナス計上しなければいけなくなり、迷惑な話です。従って、適正在庫を持ってくれるよう、テキストの在庫管理を強制することになります。
そうなると、研修管理業務を行っている担当者は、入出庫、在庫の管理をする必要があります。データベースにうってつけの仕事ではないでしょうか？
「現在、何冊在庫があり、申し込み人数によっていくつ追加発注すればよいか……」
しかし、研修テキストの在庫管理を、全社員が利用するデータベースに持つ必要があるでしょうか？ 研修業務を行っている担当者、およびその部署の人たちが共有できれば十分でしょう。また、研修提供ベンダーとの棚卸が済んでしまえば、そのデータは削除して構わないはずです。データの保存期間は3ヶ月または6ヶ月、長くて1年くらいなものです。
さらに、Oracleで管理しているデータのように、｢ミッションクリティカル｣だと言って、データベースを停止することなくバックアップ運用を考える必要もないでしょう。データベースの規模から想定しても、FileMakerのデータベースサーバーはOS含めたディスクごとバックアップをとるという運用で十分だと考えられます。
しかし、研修コースのマスター管理は、Oracleで行います。社外（一般）に公開して受講申し込みを募る必要がありますし、最新バージョンのコースがリリースされたら、Oracle内のデータを更新して、社外（一般）に実施スケジュールを公開する必要もあるでしょう。
そこで、今回はまず｢データベースサーバー内のデータをユーザーの手元にコピーさせる｣、つまりOracleからFileMakerにデータをインポートして使う部分を紹介します。
