ParadoxからInterBaseへの移行

この記事は、ParadoxからInterBaseへ移行する際のポイントをまとめた2000年に作成された文書を転載したものです。

はじめに

デスクトップデータベースからフル機能を装備したSQLデータベースサーバーに移行するのにはデータベース管理者が考慮しなければならないことが数多くあります。しかし、移行することによって得られる数多くの利点も存在します。あなたのデータベース構築の既存の知識と経験をさらに発展させていくことにより、ディスクトップデータベースを段階を追ってSQLデータベースサーバーへと移行させていくことができるでしょう。

InterBaseはテーブルの容易な管理、データベース構造の容易な作成・運用などさまざまな直感的に理解しやすい優位性を持った製品です。Paradoxテーブルの構造はアプリケーションによって論理的なデータのメンテナンスが合理的に行われます。この優れた機能により古いものから新しいものへとデータの一部は書き換えられていきます。

このドキュメントでは以下の内容について説明します。

移行の目的
既存のツールによりデータを移行する方法
ParadoxテーブルのプロパティとInterBaseデータベースの機能との対応
クライアントアプリケーションがどのようにデータベースサーバーと通信するか

カルチャーショック

Paradoxを通してInterBaseのデータベースを考えることが最初の障害になります。しかし、現在のデータベースアプリケーション構造の一部分をInterBaseの機能に置き換えていくことができます。InterBaseが提供するクライアント／サーバーのパラダイムはParadoxの開発者にとって新しくそして意味のある概念を持っています。

まず、InterBaseとParadoxではデータベース構造がまったく異なります。InterBaseのデータベースは通常、テーブル、インデックス、データの整合性、トリガー、プロシージャなどの定義および値は一つのファイルから構成されます（例、employee.gdb）。一方、Paradoxのデータベースはインデックス（employee.xg0）、整合性検査（employee.val）、BLOB（employee.mb）とそれらとリンクするテーブル（employee.db）という複数のファイルに分割されています。

続いての大きな違いはコードとデータの分割です。Paradoxでは、データファイル（Paradoxテーブル）、レポート、フォーム、スクリプトなどが存在する一つまたは複数の作業ディレクトリという概念があります。それらのディレクトリはワークション上またはファイルサーバー上におかれます。クライアント／サーバーの性質を持つInterBaseでは、テーブルはサーバー上にのみ存在します。その他のすべてのファイルはクライアントにおかれます。Paradoxの作業ディレクトリとしてリモートサーバーのディレクトリを特定することができないので、InterBaseのデータベースに接続するParadoxアプリケーションはBorland Database Engine（BDE）のエリアスを通じてInterBaseのテーブルにアクセスする必要があります。

ビジネスルールまたは整合性制約という概念もあります。ParadoxもInterBaseもまったく異なる実装を使用しますが、同じようなビジネスルールが使用できます。各DBMSは参照の整合性、一次キー、必須項目、初期項目値などをサポートしています。InterBaseではこれ以外にもトリガーやParadoxなどのクライアントアプリケーションから離れて大量のデータ操作を行うストアドプロシージャなどをサポートしています。

最後に、ライブデータの概念があります。Paradoxでは変更の前にアプリケーションがレコードロックを必要とするペシミステックロックスキーマをサポートしています（ロックを行うためにはpdoxusrs.netファイルが必要となります）。InterBaseでは現在のデータベース状態のスナップショットからロックなしにクライアントよりレコードの変更を可能にするオプティミステックロックスキーマをサポートしています。このスナップショットがInterBaseのマルチジェネレーションアーキテクチャによって管理されるトランザクションスタンプを通じでデータのロックをコントロールします。

移行の目的

InterBaseのデータベースサーバーの使用はディスクトップデータベースと比べて以下のような利点を提供します。

ODBCドライバまたはInterBaseのAPIを直接コールすることによりさまざまなソフトウェアパッケージを構築できます。
すべてのケースにおいて、各テーブルごとのレコード数、レコードサイズ、同時接続ユーザーなどの制限が大幅に緩和されます（制限が取り除かれます）。
洗礼されたロックメカニズムが使用できます。pdoxusrs.netの問題から開放されます。
さまざまなプラットフォーム、オペレーションシステム、バージョンで使用することができます。また、それらのプラットフォームに移行することが可能です。
ロールバック処理、コミット処理を提供するトランザクション処理はより安定した環境を提供するディスクベースの書き込み方法により管理されています。Paradoxではpdoxusrs.netとともにメモリ上にて読み込み、書き込み処理が実行されます。停電またはシステムクラッシュなどの状況が発生すると、Paradoxではデータの欠落または破壊という結果を招くことがあります。
InterBaseのマルチジェネレーションアーキテクチャはデータの競合を減らすレコードバージョンニングスキーマをサポートしています。Paradoxは一つのレコードのインスタンスしか扱えず、また、ロックファイルであるpdoxusrs.lckを通じてロックを管理します。
InterBaseではほんのわずかですがデータベース管理者としての知識が必要となります。アプリケーションのデザイン、現在の使用しているデータベースの知識はデータベースサーバーのコンセプトを考慮することで、それらの知識は生かされまた発展させていくことが可能となります。
InterBaseでは初期導入時のハードディスク容量はサーバー側10MB、クライアント側はInterBaseのクライアントドライバとライブラリを入れて2MBとほんのわずかなフットプリントで使用できます。

ParadoxテーブルからInterBaseデータベースへの移行

ParadoxとInterBaseではコアになるテーブルリレーション、インデックスなどのデータベースの原理が異なっています。表１では、Paradoxテーブルの各プロパティとInterBaseスキーマに置き換えた場合についてリストアップされています。

表1．どのようにParadoxテーブルのプロパティを移行するか

テーブルプロパティ	移行の問題
データ型*	ほとんどのParadoxのデータ型はInterBaseのデータ型と一致します。ただし、カウンタ型、日付時間型、論理型、BCD型などはそのままで一致するInterBaseのデータ型はありません。
Picture構文	整合性検査を使用することでテーブルベースのPicture構文と同じ機能を持つことができます。また、Picture構文はParadoxフォームのデータフィールドのプロパティとして移行することができます。
テーブル参照	CHECK制約を利用することで入力しようとしているデータが他のテーブルの列に含まれているかどうかを判断することができます。
参照の整合性	CHECK制約と外部キーをあわせて使用することでParadoxの参照の整合性と同じ機能になります。
妥当性検査	CHECK制約により新規入力のデータが満たす条件を作成できます。
キー*	InterBaseではキーは一次キーと呼ばれます。InterBaseの一次キーの値にNULLを含めることはできません。
2次インデックス*	InterBaseではパフォーマンスを向上させるために大量のデータを追加する前にインデックスを非アクティブにするなどのオプションがあります。その後、インデックスをアクティブにすることでインデックスを再構築することができます。InterBaseは大文字・小文字を区別するインデックスはサポートされていませんが、同じような結果をもたらす文字コード順を使用することができます。
パスワードセキュリティ	InterBaseは実際のデータベースとは別にセキュリティデータベースを管理しています。SQL標準のGRANT構文を使用することで、ユーザーにデータベースへの権利を追加できます（権利を外すときはREVOKE構文を使用します）。パスワードはParadoxのような追加機能ではありません。
テーブル言語	特定のテーブルに言語情報を設定することができます。InterBaseではデータベースに対してデフォルトの言語情報を指定することができ、また、各テーブルの列についても言語情報を設定することができます。これらの機能によりさまざまな文字コード順を使用することができます。

ParadoxのテーブルコピーまたはData Migration Wizardを使用することで自動的にInterBaseにあったプロパティに変換されます。

複雑なテーブル構造を持つParadoxテーブルをInterBaseのデータベースに移行するためには相当な作業を伴うことになるでしょう。たとえば、基本的なSQLコマンドによりデータベース構造などのメタデータを変更する方法についてなどの知識が必要となります。Delphi、C++ Builderにはそれらのメタデータの処理を行えるデータベースエクスプローラというツールが含まれています（図－１）。Paradoxの再構築ユーティリティではInterBaseのメタデータを変更することはできませんが、SQLファイルの実行を行うことでそれらのメタデータを変更することができます。ほとんどの場合、フロントエンドアプリケーションは手をつけずにすみます。フォームやレポートに使用したいテーブルをリンクするデータモデルを使用できますし、ObjectPALのコードの変更を最低限で済ますことができるでしょう。

図１.データベースエクスプローラを利用してInterBaseのインデックス定義を参照

移行フェーズのアプローチ

IT部門によって行われる移行プロジェクトが必要とされる開発フェーズでは開発とテストが段階的に発生します。データベースとアプリケーションをシームレスに移行させることが最終的なゴールとなります。ここでは移行フェーズの考え方について説明します。実際に次のフェーズに移る前に移行の手順を再検討してみてください。

フェーズ１：データの移行

すべてのデータベースにおいて最も重要なことはデータをどのように移行するかということです。ParadoxテーブルをInterBaseのデータベースに移行する方法は３種類あります。ここでは、もっとも簡単な方法から順番に書かれています。

Paradoxのコピーユーティリティ：Paradoxの[ツール｜ユーティリティ｜コピー]を使用することにより、Paradoxのデータ型といくつかのテーブルプロパティを対応するInterBaseのデータ型とプロパティに変換することができます。InterBaseデータベースはあらかじめ作成しておく必要があり、BDEのエリアスを設定しておく必要があります。 Data Migration Wizard:Delphi、C++ Builderなどに付属するData Migration Wizardによりヘタロジアスな形式からなるデータと列構造を移行することができます。InterBaseデータベースはあらかじめ作成しておく必要があり、BDEのエリアスを設定しておく必要があります。外部ファイル：InterBaseはParadoxが簡単にエクスポートできるような固定長からなる外部ファイルのインポート・クエリをサポートしています。BLOBデータについてはプログラムを作成することにより別のファイルに書き出す必要があります。この方法はデータのみを移行する方法で、テーブル構造などの情報は移行できません。

フェーズ２：セキュリティの設定

表１で簡単に書かれているように、InterBaseとParadoxではまったく異なるセキュリティの実装がされています。InterBaseのセキュリティデータベースであるISC4.GDBはサーバーのデータベースをユーザーがどのようにアクセスできる権限を持っているかの情報を管理しています。初心者の場合、どのような方法であれInterBaseサーバーにアクセスする前にデータベースのユーザー名とパスワードのログを記録しておきます。初めてInterBaseを使用する開発者がマニュアルに記載されているデフォルトのユーザー名とパスワードを使用してテスト目的で使用した場合でも、運用する直前にパスワードだけでも変更するだけで有効な手段だといえます。InterBaseのパスワードはデータベース単位ではなく、サーバー単位となります。パスワード情報は暗号化され、ネットワーク上に生のパスワードの文字列が流れるようなことはありません。データベースの権限はInterBaseに付属するコマンドラインツールであるGSEC.EXEを利用することで設定することができます。または、SQL構文であるGRANTまたはREVOKEコマンドを使用することでも設定できます。一方、Paradoxでは暗号化されたパスワードは各テーブル（*.DB）によって管理されます。Paradoxにはデータベースのセキュリティを集中的に管理する方法がなく、複数のパスワードの使用または共通パスワードの使用が必要となります。

ParadoxのセキュリティをInterBaseに移行するためのアプローチの一つとして表２のような権限の比較を使用する方法もあります。InterBaseが提供するセキュリティ（ロール、ストアドプロシージャ、トリガー、ビューなど）を理解するために、InterBaseのスキーマとParadoxのセキュリティがどのように適合するか再評価してみるのもいいかもしれません。

表２．権限の比較

Paradox	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	ユーザーの属するグループに権限を設定

注:Paradoxのテーブル、権限はテーブルごとに設定が必要。InterBaseではセキュリティデータベースで集中管理する。

テーブルへのアクセスを制限するもう一つの方法として、複数のテーブルの特定の列とデータをベースとして一つの仮想テーブルとして表示させるビューという方法もあります。ビューについても更新可能なビューと読み取りのみのビューの２種類があります。

フェーズ３：ビジネスルールの構築

SQLデータベースサーバーを効果的に使用する方法はクライアントが扱いやすいデータ処理のコードや参照の整合性を行うビジネスルールを管理することです。表１に書かれているテーブルのプロパティを除くと、Paradoxでは開発者がデータ操作に関するルーチンをクライアントアプリケーションとして開発する必要があります。データ操作を行う処理をクライアントアプリケーションに追加するたびに、ビジネスルールの変更や整合性の変更を行うたびに、クライアントアプリケーションを再コンパイルする必要があります。また、クライアントアプリケーションを再配布するたびに、さまざまなバージョンを管理していく必要が発生します。クライアントアプリケーションに書かれたビジネスルールはデータベースへのアクセスを必要としますので、パフォーマンスを低下させる可能性があります。表３ではビジネスルールや制約を作成できるInterBaseの機能がまとめられています。

表３．クライアントを軽くするためのInterBaseの機能

機能	説明
文字セット	文字セットは列に入力される文字列のシンボルとして定義されます。文字セットはデータベース全体に対して、または特定のテーブルの列に対して設定することができます。ソート順は文字がどのようにソートされるかを特定します。InterBaseはParadoxがサポートするソート順をサポートしています。
Check制約	Check制約は列定義の一部であり、入力または更新されたデータが指定された範囲内であるか、特定されているデータと一致しているかどうかを検証します。同じ行のデータに対して、または他のテーブルのデータに対して条件を設定することができます。
計算項目	計算項目は実行時に計算される項目です。Paradoxではフォームまたはレポート内に設定される機能として計算項目があります。
ドメイン	ドメインはテーブル作成時に使用される列のテンプレートとして提供されます。いつくかの継承されたドメイン定義は各列の定義によってオーバライドすることができます。
例外	例外はストアドプロシージャまたはトリガーで発生するエラーメッセージに名前をつけたものです。例外が発生すると、エラーメッセージが返され、呼び出されたプロシージャやトリガーは中断されます。
ジェネレータ	ジェネレータはユニークで連続的な数値を作り出すメカニズムです。名づけられたジェネレータごとにユニークな数値が作成されますので、一つのテーブルで複数のジェネレータを使用することができます。トリガーとともに使用することで、追加または更新された行にジェネレータで作成されたユニークな数値を代入することができます。Paradoxにはカウンタ型というジェネレータによく似たデータ型がありますが、一つのテーブルに対して１つのユニークな数値しか作り出すことができません。複数のユニークな値が必要な場合はクライアントアプリケーションのコードによって作成する必要があります。
参照の整合性	InterBaseの参照の整合性はParadoxの参照の整合性の機能とほとんど似ています。外部キーは対応する参照テーブルの行に対応される値が含まれているかどうかを検証します。InterBaseとParadoxの参照の整合性が異なる点としてはカスケード削除のサポートをしているかどうかです。Paradoxのケースではクライアントアプリケーションのコードでこの機能をサポートします。InterBaseの参照の整合性の場合は、更新または削除だけを制限するのか、あるいはデフォルトの値としてまたはNULLとして扱うかなどの指定ができます。
セキュリティ	表２で説明したように、InterBaseの権限はGRANTまたはREVOKEというSQL構文を使用することで実現されます。権限はテーブルごと、ビューごと、ビューまたはテーブルの列ごと、ストアドプロシージャごとに設定することができます。InterBaseのセキュリティはオブジェクトの作成者（オーナー）だけがGRANTの権限を持っています。それ以外の人がアクセスするためには権限を設定する必要があります。
ストアドプロシージャ	ストアドプロシージャはSQL文、制御文、エラー処理からなるInterBaseのストアドプロシージャ・トリガーの言語で書かれたデータベースに対してグローバルで使用できるプログラムです。クライアントアプリケーションから直接実行することができます。ストアドプロシージャには、パフォーマンス(サーバー上で実行されるため）、容易なメンテナンス（サーバー上に管理されているため）、再利用性（複数のアプリケーションで使用可能なため）などの利点があります。
トリガー	トリガーは指定されたテーブルまたはビューに対して行の追加、更新、削除などのアクションが発生したときに実行されるInterBaseのストアドプロシージャ・トリガー言語で書かれたルーチンです。
ユーザー定義関数	ユーザー定義関数（UDF)はC,Delphi,Perlなどで書かれたカスタマイズまたは特定された処理です。UDFは通常、ストアドプロシージャやトリガーが使用できない状況や処理を最も効果的に行う場合に使用されます。UDFはクライアントから呼び出すこともサーバーサイドでSQLコマンドで呼び出すこともできます。
ビュー	ビューは特定のクライアントアプリケーションの問い合わせに対して列とデータのサブセットを提供するものです。Paradoxではクライアントサイドでフィルターまたはレポートを使用することで同じような機能が実現できます。ビューは複数のテーブルから構成でき、または更新可能なビューや読み取りのみのビューが作成できます。ビューはデータのコピーではありません。

フェーズ４：システムの保守

データベースは複数のユーザーからのさまざまなトランザクション処理を扱います。データベース管理者としてあなたはシステムが安定して運用し、データの保全を実現しなければなりません。データベースのライフサイクルを考え、すべてをコントロール可能な状態に保っておく必要があるでしょう。

もっとも重要なことはデータベースのバックアップです。Paradoxのデータベース管理者なら、すべての人がシステムを終了した後、他の場所にデータをコピーしておくことでバックアップを行うことができます。これはシステムのアイドル時間である深夜などに行われることになるでしょう。InterBaseはGBAKと呼ばれるデフォルトでデータベースを圧縮されたファイルへのコピーをトランザクションベースで行うバックアップのユーティリティを提供しています。GBAKの処理自体がライブなデータベースへの一つのトランザクションとして実現されています。GBAKの処理はコマンドラインツールであるGBAK.EXEまたはGUIベースのServer Manager（図２）を利用することで行えます。GBAKはローカルサーバーに対しても、リモートサーバーに対しても行うことができます。必要なことといえば、ローカルであれリモートであれ、InterBaseサーバーが稼動していることです。

図２．InterBaseのGBAK処理

バックアップに続いてデータベース管理の重要な項目はデータベースの検査です。Paradoxの場合ではテーブル修復ユーティリティを使用することになるでしょう。InterBaseのデータベースの検査はコマンドラインツールであるGFIX.EXEまたはServer Manager（図３）で行えます。

図３．InterBaseのデータベース検査

もう一つのInterBaseに実装されている保守機能としてはシャドウがあります。シャドウデータベースは特定のトランザクションの状態におけるデータベースのまったくのコピーです。InterBaseのサーバーエンジンは自動的にメインデータベースへのトランザクションを複製することにより実現しています。メインのデータベースがなんらかのトラブルを生じた場合、単純にシャドウデータベースのファイル名を変更するだけでデータベースを復旧することができます。CREATE SHADOWコマンドを実行することにより、シャドウデータベースを作成することができます。

Windows NTのATコマンドまたはUNIXのcronコマンドを使用することにより、データベースのバックアップ処理を自動化することができます。また、Interbase.logを参照することにより、サーバーにどのような問題が発生したかを調べることができ、このログの内容をクライアントアプリケーションで利用することで、問題が発生したときにデータベースの検査を自動的に実現することが可能となります。

移行チェックリスト

下のアイテムはParadoxのテーブルをInterBaseに移行するときに考慮したほうがいいと思われる内容を書き出したものです。実際に移行の際には各アプリケーションごとに考慮しなければならないことを洗い出してみる必要があるでしょう。

列の名称、データ型、長さは正しいか？一次キーを設定しているか？
設定されているインデックスは利用されているか？SHOW PLANオプションを実行して、InterBase Windows ISQLツールで下のようなSQL文を実行することで使用されているかどうかを調べることができます。
例：SELECT * FROM <テーブル名> WHERE <インデックスの列名>=<特定の値>
データベースの管理者が接続できるか？特定のユーザーがデータベースに接続できるか？ROLEは問題ないか？ユーザーは必要なデータおよびプロシージャにアクセスできるか？
参照の整合性はうまく動いているか？
CHECK制約は働いているか？
データベース、テーブル、列への文字セットは正しく設定されているか？
指定された条件でトリガーは動いているか？
ストアドプロシージャは正しく結果を返すか？適切に動いているか？クライアントアプリケーションはエラーを処理できるか？
クライアントのインタフェースはInterBaseの概念にあっているか？たとえば、トランザクションのコミット処理時、"EndEdit"コマンドのような処理を行っているか？
クライアントアプリケーションはサーバーのエラーに対応しているか？
エラーなしにデータベースのバックアップおよびリストアが可能か？
エラーなしにデータベースの検査（GFIX）が終了するか？
すべてのシナリオにおいてアカウントを正しく管理できているか？
テスト運用時、Interbase.logに異常終了などの報告がされていないか？

著者：James Arias-La Rheir　Client/Server Support Engineer, InterBase Software Corporation（当時）