はじめに
デスクトップデータベースからフル機能を装備したSQLデータベースサーバーに移行するのにはデータベース管理者が考慮しなければならないことが数多くあります。しかし、移行することによって得られる数多くの利点も存在します。あなたのデータベース構築の既存の知識と経験をさらに発展させていくことにより、デスクトップデータベースを段階を追ってSQLデータベースサーバーへと移行させていくことができるでしょう。
InterBaseはテーブルの容易な管理、データベース構造の容易な作成・運用などさまざまな直感的に理解しやすい優位性を持った製品です。dBASEテーブルの構造はアプリケーションによって論理的なデータのメンテナンスが合理的に行われます。この優れた機能により古いものから新しいものへとデータの一部は書き換えられていきます。
このドキュメントでは以下の内容について説明します。
- 移行の目的
- 既存のツールによりデータを移行する方法
- dBASEテーブルのプロパティとInterBaseデータベースの機能との対応
- クライアントアプリケーションがどのようにデータベースサーバーと通信するか
移行に関する不安感
dBASEを通してInterBaseのデータベースを考えることが最初の障害になります。また、DOS版のdBASEをWindows版に移行するためには、オブジェクト指向の知識とイベント駆動型を理解しなければなりません。dBASE DOSの手続きコマンドに慣れてしまうとなかなかWindows版に移行するのが困難になります。DBASEにとって、DOSからWindowsに移行するにさまざまな障壁がありそのためにシステムの移行が遅れてしまう可能性があります。
dBASEユーザーがDOSからWindowsに移行するのにぶつかる障壁
- 手続き型からイベント駆動型
- 手続き型コマンドからオブジェクト指向ベースの言語体系
- DBFへのネイティブアクセスからBDE経由によるアクセス
- コマンドによる印刷からグラフィカルな印刷ツールによる印刷
このようにWindowsに移行するためにはさまざまな障壁がありますが、一度、Windowsの世界に移行することができれば、dBASE形式からInterBaseに移行することはそれほど難しいものではありません。dBASE 5.1J for Windows, Visual dBASE 5.6J, Visual dBASE 7と最新のバージョンに合わせていくことで、自然にdBASE形式からInterBaseへの移行が行えます。Visual dBASE 7は標準がSQLベースとなりますので、dBASE形式を扱うのとInterBaseを扱うのとの違いは、トリガー、ストアドプロシージャなどのDBMSのみの機能でしょう。また、InterBaseの場合は、検索時に最適なインデックスを選択してくれるクエリーオプティマイザ機能を搭載していますので、どのインデックスを使用すればいいのかを考慮することなしにプログラム開発ができ、テストフェーズに入ったときにWISQLでインデックスを使用しているかを確認するだけですむでしょう。
dBASE形式からInterBaseに移行するときに感じるギャップとしてはまずデータベースの定義の違いでしょう。dBASEは本体(.DBF)、バイナリデータ(.DBT)、インデックス(.MDX)の３つのファイルから構成されます。Visual dBASE 7から使用できるようになったdBASE 7形式では、これらのファイルの中に参照の整合性の定義、プライマリーインデックス、外部キー情報などが含まれます。
dBASEが他のデスクトップデータベースと比較して優れている点としては、マルチプロダクションインデックスの中に最大４７個のインデックスを格納できる点です。また、インデックスタグごとに言語情報を持っていますので異なったソート順でインデックスを作ることができる点です。また、マルチユーザーでロックを行う場合は、テーブルのヘッダー部にロック情報を格納しますので、Paradox形式のファイルのように、pdoxusrs.netの設定や.lckファイルなどに惑わされずにすみます。
InterBaseのデータベースは基本的にテーブル、インデックスの定義とデータ、そしてトリガー、ストアドプロシージャーなどのビジネスルールが一つのファイルに格納されます。データベースサイズが大きくなる場合はあらかじめ、２次ファイルの設定をしておきマルチデータベース形式にしておくのがいいでしょう。
InterBaseはInterBaseのエンジンが使用するすべてのデータをデータベースファイルの中に格納して、処理を行います。この構造によりデータの信頼性もdBASE形式のようなむき出しのファイルに比較して高くなっています。
データベース続いてdBASE形式とInterBaseとの大きな違いは、データ処理を行うエンジンが何であるかということです。
dBASEファイルへのアクセス
dBASEがdBASEテーブルへアクセスする場合、BDEはデータ処理を行うエンジンとして動作します。アプリケーションが呼び出したBDEのAPIに従い、BDEはdBASEのファイルをオープンにデータ処理を行います。
InterBaseへのアクセス
一方、InterBaseへアクセスする場合、BDEはInterBaseクライアントへの処理を仲介するミドルウェアとして動作します。DBASE形式のファイルを扱っている場合とまったく違い、BDEはSQL-Link for InterBaseを通じてデータ処理の要求をInterBaseに送ります。InterBaseはすべてのクライアントからのデータ処理要求を引き受け、データ処理を行います。ｄBASE形式を扱っている場合は、クライアントのCPUでデータ処理を行いますが、InterBaseの場合はInterBaseの稼動するマシンのCPUを使用しますので、クライアント側はビジネスルールの実行のみに専念することができます。
移行の目的
InterBaseのデータベースサーバーの使用はデスクトップデータベースと比べて以下のような利点を提供します。
- ODBCドライバまたはInterBaseのAPIを直接コールすることによりさまざまなソフトウェアパッケージを構築できます。
- すべてのケースにおいて、各テーブルごとのレコード数、レコードサイズ、同時接続ユーザーなどの制限が大幅に緩和されます（制限が取り除かれます）。
- 洗礼されたロックメカニズムが使用できます。
- さまざまなプラットホーム、オペレーションシステム、バージョンで使用することができます。また、それらのプラットホームに移行することが可能です。
- ロールバック処理、コミット処理を提供するトランザクション処理はより安定した環境を提供するディスクベースの書き込み方法により管理されています。停電またはシステムクラッシュなどの状況が発生すると、dBASEではデータの欠落または破壊という結果を招くことがあります。
- InterBaseのマルチジェネレーションアーキテクチャはデータの競合を減らすレコードバージョンニングスキーマをサポートしています。ｄBASEは一つのレコードのインスタンスしか扱えず、また、ロック情報をテーブルのヘッダー部に書きこみことでロックを管理します。
- InterBaseではほんのわずかですがデータベース管理者としての知識が必要となります。アプリケーションのデザイン、現在の使用しているデータベースの知識はデータベースサーバーのコンセプトを考慮することで、それらの知識は生かされまた発展させていくことが可能となります。
- InterBaseでは初期導入時のハードディスク容量はサーバー側10MB、クライアント側はInterBaseのクライアントドライバとライブラリを入れて2MBとほんのわずかなフットプリントで使用できます。
dBASEテーブルからInterBaseデータベースへの移行
dBASEとInterBaseではコアになるテーブルリレーション、インデックスなどのデータベースの原理が異なっています。表１では、dBASEテーブルの各プロパティとInterBaseスキーマに置き換えた場合についてリストアップされています。
表1．どのようにdBASEテーブルのプロパティを移行するか
テーブルプロパティ |
移行の問題 |
データ型* |
ほとんどのdBASEのデータ型はInterBaseのデータ型と一致します。ただし、dBASE ７形式のカウンタ型や日付時間型、論理型などはそのままで一致するInterBaseのデータ型はありません。 |
テーブル参照 |
CHECK制約を利用することで入力しようとしているデータが他のテーブルの列に含まれているかどうかを判断することができます。 |
参照の整合性 |
CHECK制約と外部キーをあわせて使用することでdBASEの参照の整合性と同じ機能になります。 |
妥当性検査 |
CHECK制約により新規入力のデータが満たす条件を作成できます。 |
キー* |
InterBaseではキーは一次キーと呼ばれます。InterBaseの一次キーの値にNULLを含めることはできません。 |
2次インデックス* |
InterBaseではパフォーマンスを向上させるために大量のデータを追加する前にインデックスを非アクティブにするなどのオプションがあります。その後、インデックスをアクティブにすることでインデックスを再構築することができます。InterBaseは大文字・小文字を区別するインデックスはサポートされていませんが、同じような結果をもたらす文字コード順を使用することができます。 |
パスワードセキュリティ |
InterBaseは実際のデータベースとは別にセキュリティデータベースを管理しています。SQL標準のGRANT構文を使用することで、ユーザーにデータベースへの権利を追加できます（権利を外すときはREVOKE構文を使用します）。パスワードはdBASEのような追加機能ではありません。 |
テーブル言語 |
特定のテーブルに言語情報を設定することができます。InterBaseではデータベースに対してデフォルトの言語情報を指定することができ、また、各テーブルの列についても言語情報を設定することができます。これらの機能によりさまざまな文字コード順を使用することができます。 |
|
|
*dBASEのテーブルコピーまたはData Migration Wizardを使用することで自動的にInterBaseにあったプロパティに変換されます。
複雑なテーブル構造を持つdBASEテーブルをInterBaseのデータベースに移行するためには相当な作業を伴うことになるでしょう。たとえば、基本的なSQLコマンドによりデータベース構造などのメタデータを変更する方法についてなどの知識が必要となります。Delphi、C++ Builderにはそれらのメタデータの処理を行えるデータベースエクスプローラというツールが含まれています。ほとんどの場合、フロントエンドアプリケーションは手をつけずにすみます。フォームやレポートに使用したいテーブルをリンクするデータモジュールを使用できますし、コードの変更を最低限で済ますことができるでしょう。
表2.dBASE 5形式とInterBaseのデータ型の対応
dBASE |
InterBase |
備考 |
文字型 |
CHAR
VARCHAR |
CHAR=固定長
VARCHAR=可変長 |
数値型 |
NUMERIC
DECIMAL |
|
浮動型 |
FLOAT
DOUBLE PRECISION |
|
日付型 |
DATE |
|
論理型 |
CHAR |
CHECK制約にて実現
CHECK(FLD1 in ('Y','N','y','n')) |
メモ型 |
BLOB SUB_TYPE 1 |
|
バイナリ型 |
BLOB SUB_TYPE 2 |
|
OLE型 |
BLOB SUB_TYPE 3 |
|
|
|
|
移行フェーズのアプローチ
IT部門によって行われる移行プロジェクトが必要とされる開発フェーズでは開発とテストが段階的に発生します。データベースとアプリケーションをシームレスに移行させることが最終的なゴールとなります。ここでは移行フェーズの考え方について説明します。実際に次のフェーズに移る前に移行の手順を再検討してみてください。
フェーズ１：データの移行
すべてのデータベースにおいて最も重要なことはデータをどのように移行するかということです。dBASEテーブルをInterBaseのデータベースに移行する方法は３種類あります。ここでは、もっとも簡単な方法から順番に書かれています。
- dBASEのコピーを使用：dBASEのCOPY TABLEを使用してテーブルをInterBaseに移行します。InterBaseデータベースはあらかじめ作成しておく必要があり、BDEのエリアスを設定しておく必要があります。
- Data Migration Wizard:Delphi、C++ Builderなどに付属するData Migration Wizardによりヘタロジアスな形式からなるデータと列構造を移行することができます。InterBaseデータベースはあらかじめ作成しておく必要があり、BDEのエリアスを設定しておく必要があります。
- 外部ファイル：InterBaseはdBASEが簡単にエクスポートできるような固定長からなる外部ファイルのインポート・クエリをサポートしています。BLOBデータについてはプログラムを作成することにより別のファイルに書き出す必要があります。この方法はデータのみを移行する方法で、テーブル構造などの情報は移行できません。
フェーズ２：セキュリティの設定
表１で簡単に書かれているように、InterBaseとdBASEではまったく異なるセキュリティの実装がされています。InterBaseのセキュリティデータベースであるISC4.GDBはサーバーのデータベースをユーザーがどのようにアクセスできる権限を持っているかの情報を管理しています。初心者の場合、どのような方法であれInterBaseサーバーにアクセスする前にデータベースのユーザー名とパスワードのログを記録しておきます。初めてInterBaseを使用する開発者がマニュアルに記載されているデフォルトのユーザー名とパスワードを使用してテスト目的で使用した場合でも、運用する直前にパスワードだけでも変更するだけで有効な手段だといえます。InterBaseのパスワードはデータベース単位ではなく、サーバー単位となります。パスワード情報は暗号化され、ネットワーク上に生のパスワードの文字列が流れるようなことはありません。データベースの権限はInterBaseに付属するコマンドラインツールであるGSEC.EXEを利用することで設定することができます。または、SQL構文であるGRANTまたはREVOKEコマンドを使用することでも設定できます。
dBASEのセキュリティをInterBaseに移行するためのアプローチの一つとして表２のような権限の比較を使用する方法もあります。InterBaseが提供するセキュリティ（ロール、ストアドプロシージャ、トリガー、ビューなど）を理解するために、InterBaseのスキーマとdBASEのセキュリティがどのように適合するか再評価してみるのもいいかもしれません。
表２．権限の比較
dBASE |
InterBase |
ノート |
マスターパスワード |
管理者/所有者パスワード |
データベースを作成したユーザーだけが権限の設定が可能 |
補助パスワード |
上記以外のパスワード |
管理者権限と異なるパスワード |
テーブル権限|すべて |
GRANT ALL |
INSERT,DELETE,SELECT,UPDATE,EXECUTE,REFERENCESの権限すべて |
テーブル権限|追加・削除 |
GRANT INSERT
GRANT DELETE |
InterBaseでは２つの別の権限 |
テーブル権限|データ入力 |
GRANT SELECT+
GRANT INSERT+
GRANT UPDATE |
３つの権限を設定することで高い権限を与える |
テーブル権限|更新 |
GRANT UPDATE |
|
テーブル権限|読み取りのみ |
GRANT SELECT |
|
フィールド権限|すべて
フィールド権限|読み取りのみ
フィールド権限|なし |
GRANT UPDATE ＜列名＞
または
GRANT REFERENCES ＜列名＞ |
クライアントアプリケーションからデータブロックを隠すときやビューを使用するときに列レベルの権限が効果を発揮する |
N/A |
GRANT EXECUTE |
ストアドプロシージャの実行に必須 |
N/A |
GRANT REFERENCES |
外部キーが列にアクセスするのに必須 |
N/A |
GRANT ROLE |
ユーザーの属するグループに権限を設定 |
|
|
|
注:InterBaseではセキュリティデータベースで集中管理する。
テーブルへのアクセスを制限するもう一つの方法として、複数のテーブルの特定の列とデータをベースとして一つの仮想テーブルとして表示させるビューという方法もあります。ビューについても更新可能なビューと読み取りのみのビューの２種類があります。
フェーズ３：ビジネスルールの構築
SQLデータベースサーバーを効果的に使用する方法はクライアントが扱いやすいデータ処理のコードや参照の整合性を行うビジネスルールを管理することです。表１に書かれているテーブルのプロパティを除くと、dBASEでは開発者がデータ操作に関するルーチンをクライアントアプリケーションとして開発する必要があります。データ操作を行う処理をクライアントアプリケーションに追加するたびに、ビジネスルールの変更や整合性の変更を行うたびに、クライアントアプリケーションを再コンパイルする必要があります。
また、クライアントアプリケーションを再配布するたびに、さまざまなバージョンを管理していく必要が発生します。クライアントアプリケーションに書かれたビジネスルールはデータベースへのアクセスを必要としますので、パフォーマンスを低下させる可能性があります。表３ではビジネスルールや制約を作成できるInterBaseの機能がまとめられています。
表３．クライアントを軽くするためのInterBaseの機能
機能 |
説明 |
文字セット |
文字セットは列に入力される文字列のシンボルとして定義されます。文字セットはデータベース全体に対して、または特定のテーブルの列に対して設定することができます。ソート順は文字がどのようにソートされるかを特定します。InterBaseはdBASEがサポートするソート順をサポートしています。 |
Check制約 |
Check制約は列定義の一部であり、入力または更新されたデータが指定された範囲内であるか、特定されているデータと一致しているかどうかを検証します。同じ行のデータに対して、または他のテーブルのデータに対して条件を設定することができます。 |
計算項目 |
計算項目は実行時に計算される項目です。dBASEではフォームまたはレポート内に設定される機能として計算項目があります。 |
ドメイン |
ドメインはテーブル作成時に使用される列のテンプレートとして提供されます。いつくかの継承されたドメイン定義は各列の定義によってオーバライドすることができます。 |
例外 |
例外はストアドプロシージャまたはトリガーで発生するエラーメッセージに名前をつけたものです。例外が発生すると、エラーメッセージが返され、呼び出されたプロシージャやトリガーは中断されます。 |
ジェネレータ |
ジェネレータはユニークで連続的な数値を作り出すメカニズムです。名づけられたジェネレータごとにユニークな数値が作成されますので、一つのテーブルで複数のジェネレータを使用することができます。トリガーとともに使用することで、追加または更新された行にジェネレータで作成されたユニークな数値を代入することができます。dBASEにはカウンタ型というジェネレータによく似たデータ型がありますが、一つのテーブルに対して１つのユニークな数値しか作り出すことができません。複数のユニークな値が必要な場合はクライアントアプリケーションのコードによって作成する必要があります。 |
参照の整合性 |
InterBaseの参照の整合性はdBASEの参照の整合性の機能とほとんど似ています。外部キーは対応する参照テーブルの行に対応される値が含まれているかどうかを検証します。InterBaseの参照の整合性の場合は、更新または削除だけを制限するのか、あるいはデフォルトの値としてまたはNULLとして扱うかなどの指定ができます。 |
セキュリティ |
表２で説明したように、InterBaseの権限はGRANTまたはREVOKEというSQL構文を使用することで実現されます。権限はテーブルごと、ビューごと、ビューまたはテーブルの列ごと、ストアドプロシージャごとに設定することができます。InterBaseのセキュリティはオブジェクトの作成者（オーナー）だけがGRANTの権限を持っています。それ以外の人がアクセスするためには権限を設定する必要があります。 |
ストアドプロシージャ |
ストアドプロシージャはSQL文、制御文、エラー処理からなるInterBaseのストアドプロシージャ・トリガーの言語で書かれたデータベースに対してグローバルで使用できるプログラムです。クライアントアプリケーションから直接実行することができます。ストアドプロシージャには、パフォーマンス(サーバー上で実行されるため）、容易なメンテナンス（サーバー上に管理されているため）、再利用性（複数のアプリケーションで使用可能なため）などの利点があります。 |
トリガー |
トリガーは指定されたテーブルまたはビューに対して行の追加、更新、削除などのアクションが発生したときに実行されるInterBaseのストアドプロシージャ・トリガー言語で書かれたルーチンです。 |
ユーザー定義関数 |
ユーザー定義関数（UDF)はC,Delphi,Perlなどで書かれたカスタマイズまたは特定された処理です。UDFは通常、ストアドプロシージャやトリガーが使用できない状況や処理を最も効果的に行う場合に使用されます。UDFはクライアントから呼び出すこともサーバーサイドでSQLコマンドで呼び出すこともできます。 |
ビュー |
ビューは特定のクライアントアプリケーションの問い合わせに対して列とデータのサブセットを提供するものです。dBASEではクライアントサイドでフィルターまたはレポートを使用することで同じような機能が実現できます。
ビューは複数のテーブルから構成でき、または更新可能なビューや読み取りのみのビューが作成できます。ビューはデータのコピーではありません。 |
|
|
フェーズ４：システムの保守
データベースは複数のユーザーからのさまざまなトランザクション処理を扱います。データベース管理者としてあなたはシステムが安定して運用し、データの保全を実現しなければなりません。データベースのライフサイクルを考え、すべてをコントロール可能な状態に保っておく必要があるでしょう。もっとも重要なことはデータベースのバックアップです。dBASEのデータベース管理者なら、すべての人がシステムを終了した後、他の場所にデータをコピーしておくことでバックアップを行うことができます。これはシステムのアイドル時間である深夜などに行われることになるでしょう。InterBaseはGBAKと呼ばれるデフォルトでデータベースを圧縮されたファイルへのコピーをトランザクションベースで行うバックアップのユーティリティを提供しています。GBAKの処理自体がライブなデータベースへの一つのトランザクションとして実現されています。GBAKの処理はコマンドラインツールであるGBAK.EXEまたはGUIベースのServer Manager（図－２）を利用することで行えます。GBAKはローカルサーバーに対しても、リモートサーバーに対しても行うことができます。必要なことといえば、ローカルであれリモートであれ、InterBaseサーバーが稼動していることです。
図２. InterBaseのGBAK処理
バックアップに続いてデータベース管理の重要な項目はデータベースの検査です。dBASEの場合ではテーブル修復ユーティリティを使用することになるでしょう。InterBaseのデータベースの検査はコマンドラインツールであるGFIX.EXEまたはServer Manager（図－３）で行えます。
図３．InterBaseのデータベース検査
もう一つのInterBaseに実装されている保守機能としてはシャドウがあります。シャドウデータベースは特定のトランザクションの状態におけるデータベースのまったくのコピーです。InterBaseのサーバーエンジンは自動的にメインデータベースへのトランザクションを複製することにより実現しています。メインのデータベースがなんらかのトラブルを生じた場合、単純にシャドウデータベースのファイル名を変更するだけでデータベースを復旧することができます。CREATE SHADOWコマンドを実行することにより、シャドウデータベースを作成することができます。
Windows NTのATコマンドまたはUNIXのcronコマンドを使用することにより、データベースのバックアップ処理を自動化することができます。また、Interbase.logを参照することにより、サーバーにどのような問題が発生したかを調べることができ、このログの内容をクライアントアプリケーションで利用することで、問題が発生したときにデータベースの検査を自動的に実現することが可能となります。
移行チェックリスト
下のアイテムはdBASEのテーブルをInterBaseに移行するときに考慮したほうがいいと思われる内容を書き出したものです。実際に移行の際には各アプリケーションごとに考慮しなければならないことを洗い出してみる必要があるでしょう。
- 列の名称、データ型、長さは正しいか？一次キーを設定しているか？
- 設定されているインデックスは利用されているか？SHOW PLANオプションを実行して、InterBase Windows ISQLツールで下のようなSQL文を実行することで使用されているかどうかを調べることができます。例：
- SELECT * FROM ＜テーブル名＞ WHERE ＜インデックスの列名＞=＜特定の値＞
- データベースの管理者が接続できるか？特定のユーザーがデータベースに接続できるか？ROLEは問題ないか？ユーザーは必要なデータおよびプロシージャにアクセスできるか？
- 参照の整合性はうまく動いているか？
- CHECK制約は働いているか？
- データベース、テーブル、列への文字セットは正しく設定されているか？
- 指定された条件でトリガーは動いているか？
- ストアドプロシージャは正しく結果を返すか？適切に動いているか？クライアントアプリケーションはエラーを処理できるか？
- クライアントのインタフェースはInterBaseの概念にあっているか？
- クライアントアプリケーションはサーバーのエラーに対応しているか？
- エラーなしにデータベースのバックアップおよびリストアが可能か？
- エラーなしにデータベースの検査（GFIX）が終了するか？
- すべてのシナリオにおいてアカウントを正しく管理できているか？
- テスト運用時、Interbase.logに異常終了などの報告がされていないか？
