この章では、以下の項目について説明します。

名前付きデータベース（DBname とも呼ばれます）は、論理名を持ち、この名前によって、データベースが実際に存在する場所を知らなくても、そのデータベースを識別することができます。Pervasive PSQL では、すべてのデータベースが名前付きデータベースである必要があります。データベースに名前を付ける際は、その名前を特定の辞書ディレクトリのパスおよび 1 つまたは複数のデータ ファイルのパスに関連付けるようにします。

名前付きデータベースへは、さまざまなアクセス方法で接続されます。たとえば、ODBC アクセスの場合は名前付きデータベースを指すデータ ソース名（DSN）を設定する必要があります。複数の DSN が同じ名前付きデータベースを指すことができます。『SQL Engine Reference』の ODBC データベース アクセスを参照してください。その他のアクセス方法の場合、アプリケーション開発者が、それぞれのアクセス方法の API を使用して名前付きデータベースに接続することができます。Pervasive PSQL ドキュメントの開発者向けガイドを参照してください。

名前付きデータベースを作成する最も簡単な方法は、Pervasive PSQL Control Center を使用することです。『Pervasive PSQL User's Guide』の新規データベースを作成するにはを参照してください。アプリケーション開発者は別のアクセス方法の API を用いて名前付きデータベースを作成することもできます。たとえば、SQL の場合は CREATE DATABASE、DTI の場合は PvCreateDatabase()、ADO.NET の場合は Data Access Application Block を参照してください。

リレーショナル インターフェイスは、バージョン 1（V1）とバージョン 2（V2）という 2 つのバージョンのメタデータをサポートします。 メタデータ バージョン 2 では、多くの識別子に最大 128 バイトの名前を付けることができ、ビューおよびストアド プロシージャを許可し、メタデータ バージョン 2 固有の DDF（データ辞書ファイル）を持つことができます。

『SQL Engine Reference』のメタデータのバージョンを参照してください。

識別子は、データベースの名前、またはデータベース内の列、テーブル、プロシージャやその他名前付きオブジェクトの名前です。識別子は、通常の識別子またはデリミター（区切り記号）付きの識別子として指定されます。

通常の識別子とは、二重引用符で囲まれていない識別子のことです。通常の識別子は大文字または小文字の文字で始まる必要があります。識別子の残りの部分は大文字または小文字の文字、数字、および有効な文字の任意の組み合わせで構成されます。

通常の識別子に予約語を使用することはできません。

通常の識別子は大文字小文字を区別しません。

デリミター付き識別子とは、二重引用符で囲まれた識別子のことです。デリミター付き識別子は、有効な文字から成る任意の文字列と、それを囲む二重引用符で構成されます。

推奨できる使用法ではありませんが、デリミター付き識別子には予約語も使用できます。たとえば、INSERT は通常の識別子としての使用は許可されませんが、"INSERT" はデリミター付き識別子としては許可されます。識別子がキーワードでもある場合は二重引用符で囲む必要があります（たとえば、SELECT "password" FROM my_pword_tbl となります。"password" は SET PASSWORD ステートメントのキーワードなので二重引用符で囲みます）。

上に挙げた全般的な制限以外に、各種の識別子に特有の制限を次の表に一覧表示します。

通常、識別子は一定のスコープ内でユニークである必要があります。つまり、同じ名前を使用する同一タイプのオブジェクトのインスタンスは同一領域内では使用できません。表 2 は、オブジェクト名がどのような領域またはスコープ内でユニークである必要があるかを表します。

既存のアプリケーションで、Btrieve ファイルを作成したり開いたりする際にデータベース名を指定していないアプリケーションをサポートするために、Pervasive PSQL では、トランザクショナル データベース エンジンごとのデフォルト データベースという概念が維持されています。デフォルト データベースは、"DefaultDB" という名前であらかじめ定義されているデータベースです。アプリケーション コードを変更しないで新しいセキュリティ モデルを使うようにするには、Btrieve データ ディレクトリをデフォルト データベースと関連付けてから、それらのディレクトリにあるデータ ファイルへのアクセスを制御するよう、デフォルト データベースでユーザーおよび権限を設定します。

また、データベース エンジンは、クライアント接続ごとの現在のデータベースという概念も理解しています。Btrieve の Login（78）、Create（14）、または Open（0）オペレーションでデータベース名が指定されていない場合、トランザクショナル エンジンは、そのオペレーションは現在のデータベースに関連するものであると見なします。現在のデータベースとは、各クライアントで、一番最近 Login（78）オペレーション（明示的ログイン）が発生したデータベースを指します。クライアント コンピューターが明示的なログイン操作を要求していない場合は、一番最近 Create（14）または Open（0）オペレーション（暗黙ログイン）が発生したデータベースが現在のデータベースとなります。明示的にも暗黙的にもログインが発生していない場合は、前の段落で説明したデフォルト データベースが現在のデータベースとなります。クライアントが明示または暗黙のログインを実行した場合、あるいは最後のファイル ハンドルを閉じることによって "DefaultDB" が現在のデータベースとなった場合には常に、現在のデータベースが変わる可能性があることに注意してください。各クライアントの現在のデータベースは、ほかのクライアントの動作とは関係ありません。

既存のアプリケーションに新しいセキュリティ モデルを構成する最も簡単な方法は、すべての Btrieve データ ディレクトリをデフォルト データベースと関連付け、このデータベース内で PUBLIC グループの権限を設定することです。PUBLIC グループは、データベースのセキュリティを有効にしたとき、Master ユーザーと共に自動的に作成されます。トランザクショナル インターフェイス セキュリティのクイック スタートを参照してください。

すべての Pervasive PSQL データベースは共通のデータ形式を使用します。このファイル形式の共有により、同一データのアクセスにトランザクショナル、リレーショナルなどの異なるアクセス方法を使用することができます。すべてのアクセス方法が機能するために使用するデータベース管理システムは MicroKernel Database エンジン（MKDE）と呼ばれます。

各 Pervasive PSQL データベース テーブルは別個のファイルで、デフォルトで拡張子 MKD を持ちます。ただし、開発者は独自のファイル名拡張子を指定することができます。MicroKernel ファイルはデータとインデックスの両方を持ち、さまざまなタイプのページで構成されます。MicroKernel ファイルは共通のデータ形式でデータを格納します。

各 Pervasive PSQL データベースには、拡張子 DDF のデータ辞書ファイル一式も含まれます。DDF ファイルにはデータベース スキーマが含まれます。メタデータ バージョン 1 と メタデータ バージョン 2 の DDF は異なるファイル名を使用します。『SQL Engine Reference』のシステム テーブルを参照してください。

MKDE は、キー フィールドは別として、データのスキーマにはまったく無頓着です。ただし、参照整合性の規定または SQL 経由のアクセスではスキーマの知識が必要です。

Pervasive PSQL データベースの名前とロケーションは dbnames.cfg という名前のバイナリ ファイルに格納されます。 Pervasive PSQL ファイルのデフォルトの保存場所については、『Getting Started with Pervasive PSQL』の Pervasive PSQL ファイルはどこにインストールされますか？を参照してください。

Pervasive PSQL データベースに関連するすべてのファイルはオペレーティング システムから表示させることができます。表 3 は関連するファイルを要約したものです。

サイズの制限はファイル バージョンやページ サイズ、および 1 ページあたりのレコード数によって異なるため、次の表にまとめました。

データ ファイルの最大サイズは 256 GB です。単一ファイルのサイズが 128 GB を超える場合は、9.5 以上のファイル形式を使用する必要があります。

次の表は、ファイルのレコードに圧縮が設定されていないことを前提にしています。レコード圧縮を使用する場合は、1 ページあたりに格納されるレコードがさらに増えることを考慮してください。『Pervasive PSQL Programmer's Guide』のページ サイズの選択およびファイル サイズの予測を参照してください。

データ ファイルの最大サイズは 128 GB です。単一ファイルのサイズが 64 GB を超える場合は、9.0 以上のファイル形式を使用する必要があります。

次の表は、ファイルのレコードに圧縮が設定されていないことを前提にしています。レコード圧縮を使用する場合は、1 ページあたりに格納されるレコードがさらに増えることを考慮してください。『Pervasive PSQL Programmer's Guide』のページ サイズの選択およびファイル サイズの予測を参照してください。

デフォルトでは、データ ファイルは、オペレーティング システムのファイル セグメントである 2 GB の限界を超えるごとに自動的に分割されます。［セグメント サイズを 2 GB に制限］設定プロパティを使用すると、ファイルを 2 GB のセグメントに分割するか、セグメント化しない 1 つのファイルとするかを指定することができます。セグメント化されていない大きなファイルを使用する利点は、ディスク I/O が効率的であるということです。このため、パフォーマンスの向上が期待できます。

この設定オプションはデータベース エンジンのパフォーマンス チューニング用プロパティの 1 つです。PCC でエンジンの設定にアクセスするにはおよびセグメント サイズを 2 GB に制限を参照してください。

このプロパティはデフォルトでオンに設定されており、以前のリリースと同様 2 GB の限界でファイルはセグメント化されます。このプロパティをオフに設定すると、ファイルは 2 GB の限界を超えて増大します。設定プロパティの追加情報については、ファイル バージョンの自動アップグレードも参照してください。

セグメントされていないファイルは、お使いのオペレーティング システムによって指定されているファイル サイズの制限を受けます。たとえば、FAT32 ファイル システムで［セグメント サイズを 2 GB に制限］の設定をオフにしてサイズの大きなファイルを作成すると、倍の 4 GB ファイルに拡張されます。以前作成したファイルが既にセグメント化されている場合、そのセグメントはファイル上でそのまま残ります。

設定プロパティの［作成ファイルのバージョン］に 9.0 以上が設定されている場合、バージョン 8.x ファイルはそのファイル サイズの限界（64 GB）に達すると自動的にバージョン 9.0 ファイルに変換されます。次の表に、この動作をまとめて示します。

たとえば、バージョン 8.x ファイルでサイズが 5 GB の場合は、既に 2 GB 単位のセグメント化が行われています。このファイルは既にセグメント化されているので、そのセグメントはファイルに存在し続けます。このようなファイルはその後もセグメント化が続行され、自動アップグレードが起こるサイズ 64 GB までそのサイズを増大させることができます。この動作は、ファイルが既にセグメント化されているため、設定プロパティがオンまたはオフのどちらであっても同じです。ファイルのサイズが 64 GB を超えると、バージョン 9.0 ファイルの最大許容サイズ 128 GB に達するまでセグメント化が続けられます。

バージョン 8.x ファイルでサイズが 1.5 GB の場合は、そのサイズを 2 GB まで増大させることができます。設定プロパティがオフの場合、このファイル サイズが 2 GB になった時点で自動アップグレードが起こります。このファイルは非セグメント化ファイルとして、そのサイズをバージョン 9.0 ファイルの最大許容サイズ 128 GB まで増大させることができます。設定プロパティをオンに設定すると、2 GB 単位のファイルのセグメント化が続行され、そのサイズを 64 GB のサイズまで増大させることができます。バージョン 8.x ファイル用の最大許容サイズ 64 GB になった時点で、バージョン 9.0 への自動アップグレードが起こります。ファイルのサイズが 64 GB を超えると、バージョン 9.0 ファイルの最大許容サイズ 128 GB に達するまでセグメント化が続けられます。

［作成ファイルのバージョン］オプションは、データベース エンジンのファイル互換性用プロパティの 1 つです。PCC でエンジンの設定にアクセスするにはを参照してください。

Pervasive PSQL データベースのデータにアクセスする 2 つの主な方法は、トランザクショナルおよびリレーショナル アクセスです。

トランザクショナルでは、アプリケーション プログラムはデータ レコード内を物理的と論理的のどちらの順序に従ってでも自由に移動することができます。トランザクショナル API を使用することで、アプリケーション プログラムは直接制御を備え、開発者はデータの基本構造の知識に基づいてデータ アクセスを最適化することができます。Btrieve は、トランザクショナル データベース エンジンの 1 つです。

リレーショナルとは、データがテーブル、行、列の集まりとして表されるアクセス方法です。リレーショナル モデルは、開発者を基となるデータ構造から切り離し、データを単純な表形式で表します。ODBC はリレーショナル アクセス方法の 1 例です。

単一のアプリケーションが両方のタイプのアクセスを含むこともあります。たとえば、データの追加と変更にはトランザクショナル アクセスを使用し、データの照会およびレポート作成にはリレーショナル アクセスを使用することができます。

アプリケーション プログラムが使用するアクセス方法を知っておく必要があります。これはインストールされる Pervasive PSQL によって異なります。アクセス方法によって設定が異なります。特定のアクセス方法を最適化するために設定をカスタマイズする必要があります。

利用するアプリケーションが使用するアクセス方法を知っていれば、トラブルシューティングも容易になります。たとえば、アプリケーション プログラムが ODBC 経由でリレーショナル アクセスを使用している場合、データベース管理システムではなく ODBC レベルの問題を解決する必要がある可能性があります。

設定のカスタマイズに関する作業とリファレンスについては、設定リファレンスを参照してください。

MKDE は、ローカルおよびクライアント/サーバーの 2 種類の処理モードをサポートします。ローカル モードでデータベースにアクセスするアプリケーションは、ローカルにある MKDE にアクセスします。ローカルの MKDE は、ローカルまたはネットワークのハード ディスクの I/O を実行するワークステーションのオペレーティング システムに要求を出します。

クライアント/サーバー モードでは、共有ファイル サーバー上で実行されるサーバー MKDE を使用します。アプリケーション プログラムがクライアント/サーバー モードでデータベース エンジンにアクセスしているときは、リクエスターがリモート MKDE に接続します。このリクエスターは、オペレーティング システムがサポートするネットワーク プロトコルを使用して、トランザクション レベルのリクエストおよびデータ レコードを、アプリケーション プログラムおよびサーバー MKDE 間で受け渡しします。ファイル I/O 機能は、クライアント/サーバー モードのサーバー MKDE によって完全に処理され、ワークステーションには共有データ ファイルのためのオペレーティング システムのハンドルは割り当てられません。データベース操作は、各ワークステーションに代わってサーバー ベースの MKDE によって実行されます。

処理モードは、アプリケーション プログラムそのものではなく、ワークステーションの設定によって決定されることに注意してください。つまり、アプリケーションはローカルとクライアント/サーバー、どちらのデータベース エンジンにもアクセスできます。アプリケーション プログラムは、ローカル モードからクライアント/サーバー モードに切り替える際に再コンパイルする必要はありません。

ワークグループおよびサーバー エンジンはどちらのモードでも動作します。データベース エンジンと同一マシン上のアプリケーションがエンジンにアクセスする場合、ローカル モードで動作します。データベース エンジンと異なるマシン上のアプリケーションがエンジンにアクセスする場合、クライアント/サーバー モードで動作します。

クライアント/サーバーの設定は、Pervasive PSQL のワークグループおよびサーバー バージョン用にカスタマイズできます。スタンドアロンでもクライアント/サーバーでも、その設定を容易にするための構成の設定プロパティが Pervasive PSQL Control Center（PCC）に含まれています。

クライアント/サーバー通信およびデータベース エンジンの設定に関する作業とリファレンスについては、設定リファレンスを参照してください。

エンコードは文字セットを表す標準規格です。文字データは、コンピューターがデジタル処理できる標準形式に変換する、つまりエンコードする必要があります。エンコードは、Pervasive PSQL データベース エンジン（サーバー）と Pervasive PSQL クライアント アプリケーションとの間で規定する必要があります。互換性のあるエンコードを使用すれば、サーバーとクライアントでデータが正しく変換されます。

エンコードのサポートは、データベース コード ページとクライアント エンコードに分割されています。この 2 種類のエンコードは、別個のものですが相互に関係しています。説明を簡単にするために、データベース コード ページとクライアント エンコードを一緒に説明します。『Getting Started with Pervasive PSQL』のクライアント用のネットワーク通信の設定を参照してください。

『SQL Engine Reference』のDSN と ODBC アドミニストレーターを参照してください。このセクションでは ODBC 接続文字列についても説明しています。

一般的には、アプリケーションは独自のファイルの場所情報を指定します。別の方法として、テキスト ファイル idshosts の情報に基づいてファイル場所のマッピングを指定することができます。

idshosts ファイルは Pervasive PSQL（IDS）の一部でした。IDS はコア製品から取り除かれましたが、idshosts ファイルの設定は依然として可能です。

作成したアプリケーションでは idshosts によるマッピング機能を使用しないという場合は、［IDS の使用］設定をオフにします。あるいは、既に idshosts を使用していたり、この代替方法を使用してファイルの場所をマップしたいと考えている場合には、［IDS の使用］設定をオンにします。IDS の使用を参照してください。

idshosts ファイルを使用する場合は、ファイルにアクセスして内容を読み取る時間が必要となるため、パフォーマンスが低下することに注意してください。

idshosts ファイルは、Windows または Linux クライアント リクエスターでのみ使用できます。クライアントは Windows または Linux 上の Pervasive PSQL サーバーと通信できます。

idshosts ファイル内のエントリの形式については、ファイル自体のコメントを参照してください。コメントにはマッピングの例も提供されています。デフォルトで、Windows プラットフォームの場合には、idshosts ファイルはデータベース クライアントのインストール ディレクトリ下の \bin ディレクトリにインストールされます。Linux の場合には、idshosts ファイルはデータベース クライアントのインストール ディレクトリ下の \etc ディレクトリにインストールされます（例：/user/local/psql/etc）。