一般にデータベース関連のアプリケーションを作成する場合、データベースの構造（「スキーマ」と呼ばれる）をあらかじめきちんと検討しておく。つまり、どんなテーブルがあり、どんなカラム（「フィールド」と呼ばれることもあるが、一連の記事ではOpenBaseの用語に従ってカラムと呼ぶ）が必要で、どんなリレーションを取るかということをあらかじめきちんと定義しておくである。実はこの部分での設計の難しさはもちろんあるわけで、それだけで大きなトピックとなってしまうが、一連の原稿ではそこまでは触れないことにする。しかしながら、この種のデータベースアプリケーションの構築をこれからやろうとしている方は、データベース設計に関する書籍は必ず熟読されることをお勧めする。特にファイルメーカーProになれている人は、ある意味では「試行錯誤すること」が当たり前になっているかもしれない。もちろん、OpenBaseやWebObjectsでの開発で試行錯誤することは不可能ではないし、Webページの生成部分では試行錯誤はいくらでもできる。しかしながら、データベース設計においては可能な限りきちんとしたものを最初から構築し、設計内容をあまり試行錯誤していじるようなことはしない方がいい。そうした使い方にはあまり向いていない面もある。
OpenBaseで使うデータベースの定義は、OpenBaseManagerというアプリケーションを使って行うのが便利だろう。/Applications/OpenBaseフォルダに、OpenBaseManagerというアプリケーションがあるのでダブルクリックして起動する。
◇OpenBaseManagerを起動する
OpenBaseManagerの中心になるウインドウは次のような小さなものだ。設定を行えば、別のマシンで稼動しているOpenBaseに接続して、そちらのマシンで定義されたデータベースの管理もできるが、ここでは開発で使っているローカルのマシンにあるデータベースをまずは利用するので、ここでは「localhost」という項目があるのに注目してもらいたい。このウインドウは階層リストだが、最上位の階層は「マシン」である。つまり、localhostという使っているこのマシンでOpenBaseが稼動しているということがとりあえずこれで分かるということだ。
◇OpenBaseManagerのウインドウに見えるlocalhost
では、localhostの項目の左にある三角形をクリックして、下位の項目を表示してみよう。ここで、CompanyやWOMovieなどの新たに出てきた項目は、このマシンで定義されているデータベースである。データベースの名前が一覧されているのである。データベース名の左側にある丸い部分は、そのデータベースが動いているかどうかを示している。白丸は動いていないデータベースで、緑丸は動いていないデータベースである。なお、手動でデータベースを動かしたりとめたりするのは、項目を選択して右上にあるSTARTないしはSTOPのボタンをクリックすれば良い。いずれにしても、「データベースは1つ1つが動く、動かないという状態を取る」ということがポイントになる。
◇localhostにあるデータベースの一覧を表示した
まず、こうしたデータベースがどこにあるかを確認しておこう。Finderを使って/Library/OpenBase/Databasesフォルダを見てもらいたい。このフォルダにはフォルダがさらにあるのだが、各フォルダの名前は、OpenBaseManagerで見えているデータベースの名前と一致している。つまり、このフォルダにあるのがデータベースの実体である。さらに1つのデータベースフォルダの中身を見ておくと、いくつかのファイルがあるが、テーブルごとにファイルが別々といった雰囲気はないようだ。一方、blobsというフォルダがあり、BLOB（Binary Large Object Binary）つまり画像などの大きなバイナリデータはフォルダにいろいろ分割して保存するのだなと思うわけだ。いずれにしても、データベースの実体はここにある。移動やバックアップのポイントとして押さえておきたい。
次に、実行プロセスを見てみよう。ProcessViewerだと見えない情報があるので、ここではTerminalを起動して、ウインドウの横幅を広げて、「ps aux|grep OpenBase」とコマンドを入力する。プロセス一覧を表示し、そこからOpenBaseという文字列を含むデータだけを取り出すのである。その結果、OpenBase関連でもいくつものプロセスが起動されているのが分かる。特に、以下のリストでの5、6行目に注目してもらいたい。引数として、WOBug、WOMoviesを指定してOpenBaseというプロセスが稼動している。これは、前のOpenBaseManagerのリストにもあったように、稼動しているデータベースの名前に一致する。すなわち、データベース1つ1つについてプロセスを起動し、そのプロセスごとにデータベース処理をしているというのがOpenBaseの動作であることが分かるということだ。
◇OpenBase関連のプロセスを見てみると、データベースがそれぞれ個別のプロセスとなる
ではここで新しいデータベースを定義してみよう。OpenBaseManagerのウインドウで、右下にある「＋」マークのアイコンがある。これがデータベースを新たに定義する機能を呼び出すボタンであるので、それをクリックする。
◇データベースを新たに作成するボタン
すると、次のようなダイアログボックスが表示される。まず、Database Nameはもちろん、識別可能なデータベース名をつける。ここでは空白などを入れないでアルファベットだけの名前にしておくのが無難だ。ここでは「Address」とキータイプした。Run on Hostは開発マシンにデータベースを作成するのでlocalhostのままでいい。Port Numberも特別な意図がないのなら-AUTOMATIC-のままでいいだろう。さらに4つのチェックボックスがあるが、最初のものは稀同時にこのデータベースを自動的に起動するかどうかを指定するものである。毎回起動するのも面倒なら、このチェックを入れておけばよい。暗号化や変更通知、レプリケーションキーの設定もあるが、これらはOpenBaseに精通してから考えればよいだろう。
そして、重要なのがInternal Encodingの設定だ。日本語の選択肢が3つ見えているが、ここではEUC JAPANESEを選択することにしよう。
◇作成するデータベースの名前やエンコードを選択する
ところで、EUCが使われる理由であるが、データベース処理では最終的にテキストのSQLステートメントになるということがある。SQLステートメントでは文字列をダブクォーテーションあるいはシングルクォーテーションで括る。ところがJISコードの日本語文字列だと、2バイトコードの後半の文字で、ASCIIコードのダブルクォーテーションなどとダブル文字が出てきてしまう。SHIFT-JISだと、2バイトコードの後半で、バックスラッシュや大カッコのキャラクタと同じコードのものがある。従って、たとえばJISコードを使ったとすると、あたかも文字列の中に文字列を囲うためのダブルクォートがあるようにデータベースエンジンは思ってしまって間違えたSQLステートメントだと思うのである。つまり、日本人として2バイトコードで解釈してほしいと思っても、データベースエンジン側が1バイトずつ解釈してしまうということで、SHIFT-JISもJISも文字によってはトラブルが出るのが明白だということだ。もっとも、SQLプロセッサが完全に2バイトコード対応であればそうした心配も無用なのであるが、オープンソースの世界も含めてそうした傾向にはないのは周知の事実だ（OpenBaseManagerが英語であるところからも容易に想像できる〜チップヒントは日本語だけど…）。一方、EUCコードであれば、2バイトコードの前半も後半も80H以上のコードなので、ASCIIキャラクタとはバッティングしないのである。だから、そうしたコードがSQLステートメントに割り込む限りは、1バイト的に解釈しても問題は出ないということだ。理論的にはUTF-8も同じように日本語が英語の文字列のキャラクタにかぶることはない。もっとも、このとき、80H以上のコードはそのままデータベースから取り出したり書き込んだりができないといけない。たとえば、8ビット目などをマスクしてしまうような動作とかがデータベースエンジンで行われていればお手上げなのである。ちなみに、OpenBaseでは「日本語対応」をうたっているだけにこうした不手際はないだろうが、SHIFT-JISやJISでの稼動実績がないので、とりあえず今回はもっとも確実なEUCを選んでデータベースを作ることにしよう。
（続く）