CREATE DATABASE

CREATE DATABASE ステートメントにより、新しいデータベースを作成します。データベースにログインしているユーザーは誰でも、このステートメントを発行できます（ユーザーはまた、指定の場所でファイルを作成するために、オペレーティングシステムでの権限を持っている必要があります）。

CREATE DATABASE はデータベースのみ作成し、関連するデータソース名（DSN）は作成しません。DSN が必要な場合は、個別に作成する必要があります。『Pervasive PSQL User's Guide』の ODBC データベースアクセスの設定を参照してください。

CREATE DATABASE ステートメントは、サーバー上で最初のデータベースを作成する場合には使用できません。ユーザーは、CREATE DATABASE ステートメントを発行する前にデータベースにログオンしていなければならないからです。そのため、事前に少なくとも 1 つはデータベースが存在している必要があります。

データベース名には、新しいデータベースの名前を指定します。データベース名はサーバー内で一意であり、識別子の規則に従っている必要があります。『Advanced Operations Guide』の識別子の種類別の制限を参照してください。

データベースが存在した場合、IF NOT EXISTS 句を省略していると、エラーが発生します（ステータスコード 2303）。IF NOT EXISTS 句を記述している場合は、エラーは返されません。

辞書パス名は、辞書ファイル（DDF）が存在する物理的な保管場所を指定します。この場所には、CREATE TABLE ステートメントを使用した場合、あるいは Pervasive PSQL Control Center（PCC）を使ってテーブルを作成した場合に、データファイルも保存されます。『Pervasive PSQL User's Guide』の辞書のロケーションを参照してください。

データパス名には、データベースのデータファイルが存在する可能性のある場所を指定します（下記の「メモ」を参照してください）。複数のパス名をセミコロンで区切って指定することができます。

データパス名は、呼び出し元アプリケーションの分析視点からではなく、データベースエンジンの視点から有効であれば、どのようなパスでもかまいません。指定した場所は既に存在している必要があります。CREATE DATABASE ステートメントでディレクトリは作成されません。

データファイルに対し辞書ファイルと同じ場所を使用する場合は、データパス名を省略します。データパス名に空文字列を渡しても、同じ場所を指定することができます。たとえば、DATA_PATH '' という指定は、データパスが空文字列であることを示します。

メモ： CREATE TABLE ステートメントまたは PCC を使用してテーブルを作成した場合、データファイルは指定した最初の辞書パス名に保存されます。辞書パス名を指定していない場合、データファイルは辞書パス名の場所に作成されます。

データパス名は、Distributed Tuning Interface（DTI）を介してテーブルを作成している場合に有用です。DTI 関数の PvAddTable では、データファイルを配置したい場所を指定できます。開発者リファレンス『Distributed Tuning Interface Guide』の PvAddTable() を参照してください。

デフォルトで、データベースエンジンは参照整合性を強要します。NO_REFERENTIAL_INTEGRITY 句を指定すると、データベース内に定義されているトリガーおよび参照整合性は強要されなくなります。

BOUND を指定すると、DDF がデータベースにバインドされます。バウンドデータベースは、データベース名を単一の DDF のセットと関連付けます。この DDF は 1 つのデータファイルのセットしか参照しません。DDF は、既存の DDF か、CREATE DATABASE ステートメントの実行によって作成される DDF のいずれかがバインドされます。

DDF がバインドされると、複数のデータベースでその DDF を使用することも、複数の DDF のセットでデータファイルを参照することもできなくなります。

REUSE_DDF キーワードは、既存の DDF をデータベースと関連付けます。既存の DDF は辞書パス名の場所になければなりません。

REUSE_DDF を省略すると、辞書パス名の場所に DDF が既に存在していない限り、新しい DDF が作成されます。DDF が辞書パス名の場所に存在すれば、新しい DDF が作成される代わりに、既存の DDF がデータベースと関連付けられます。

データベースエンジンは、トランザクショナルインターフェイスで 3 つのセキュリティモデルをサポートしています。

•クラシック。コンピューターへのログインに成功したユーザーは、データファイルに対してユーザーに割り当てられているファイルシステム権限のレベルに従って、データベースコンテンツへのアクセス権を持ちます。ファイルシステム権限はオペレーティングシステムによって割り当てられます。

•データベース。データベースのユーザーアカウントはオペレーティングシステムのユーザーアカウントとは関係ありません。データに対するユーザーのアクセス権は、データベースに設定されているユーザー権限によって決定されます。

•混合。このポリシーは、ほか 2 つのポリシーの側面を持っています。ユーザーはオペレーティングシステムのユーザー名とパスワードを使ってログインしますが、データに対するユーザーのアクセス権はデータベースに設定されているユーザー権限によって決定されます。

セキュリティの完全な説明については、『Advanced Operations Guide』の Pervasive PSQL セキュリティの章を参照してください。

ステートメントにキーワードを含んでいるかいないか		セキュリティモデル
DBSEC_AUTHENTICATION	DBSEC_AUTHORIZATION	クラシック	データベース	混合
省略	省略
含む	含む
省略	含む

リレーショナルインターフェイスでは、メタデータでバージョン 1（V1）とバージョン 2（V2）という 2 つのバージョンをサポートします。メタデータのバージョンは、そのデータベース内のすべてのデータ辞書ファイル（DDF）に適用されます。デフォルトは "メタデータバージョン 1" です。

ほかにも特性はありますが、メタデータバージョン 2 では、多くの識別子名に最大 128 バイトの名前を付けることができ、ビューおよびストアドプロシージャに対する権限が認められています。詳しい説明については、メタデータのバージョンを参照してください。

メタデータバージョン 1 を指定する場合、V1_METADATA キーワードは含めても省略してもかまいません。メタデータバージョン 2 を指定する場合は、V2_METADATA キーワードを含める必要があります。

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

エンコードのサポートは、データベースコードページとクライアントエンコードに分割されました。エンコードの 2 つのタイプは、別個のものですが相互に関係しています（『Getting Started with Pervasive PSQL』のエンコードの相互の影響を参照してください）。

データベースコードページおよびクライアントエンコードは、リレーショナルインターフェイスのみに適用されます。トランザクショナルインターフェイスには影響しません。

コードページは、名前または 'CP' の後にコードページ番号を続けて指定します。いずれも、一重引用符で囲む必要があります。たとえば、有効な名前は 'UTF-8' であり、有効な番号は 'CP1251' です。

Windows および Linux オペレーティングシステムは、共に、OS エンコードと呼ばれるデフォルトのエンコードがあります。デフォルトの OS エンコードは、Windows と Linux では異なります。キーワード DEFAULT を使用すると、サーバーの OS エンコードを指定します。

ENCODING キーワードが指定されていない場合、データベースのデフォルトであるサーバーの OS エンコードになります。

無効なコードページ番号やコードページ名を指定すると、"コードページの値が不正です" というエラーが返されます。

複数のデータベースを使用する SQL ステートメントでは、すべてのデータベースで同じコードページを使用していることを確認する必要があります。そうしないと、文字データが正しく返されません。

メモ：データベースエンジンは、アプリケーションがデータベースに追加するデータおよびメタデータのエンコードを検証しません。エンジンは、すべてのデータが、『Getting Started with Pervasive PSQL』のエンコードの相互の影響で説明されているようにサーバーまたはクライアントのエンコードを使用して入力されるものと想定しています。

複数のデータベースを使用する SQL ステートメント（複数データベースの結合など）では、すべてのデータベースでデータベースコードページが同じであることを確認してください。そうしないと、文字データが正しく返されません。

サポートされるコードページ名とコードページ番号は PCC で一覧表示することができます。PCC を起動して［データベースの新規作成］ダイアログを開きます（『Pervasive PSQL User's Guide』の新規データベースを作成するにはを参照してください）。［データベースコードページ］オプションで、［コードページの変更］をクリックします。表示されるダイアログで［データベースコードページ］をクリックすると、使用できるコードページの一覧が表示されます。

Linux でも、dbmaint ユーティリティを使用して使用できるコードページ名とコードページ番号を一覧表示することができます。この例については、『Pervasive PSQL User's Guide』の dbmaint を参照してください。

次の例は、"inventorydb" という名前のデータベースを作成し、DDF の場所をドライブ D: の "mydbfiles\ddf_location" フォルダーと指定しています。"d:\mydbfiles\ddf_location" には DDF が存在しないため、DDF が新規に作成されます。データファイルも DDF と同じ場所に保存されます。データベースはメタデータバージョン 1 を使用します。

次の例は、"HRUSBenefits" という名前のデータベースがまだ存在していなければ作成します。DDF の場所をドライブ C: の "HRDatabases\US" フォルダーとし、データファイルが存在する可能性のある場所として、C: ドライブの "HRDatabases\US\DataFiles" ディレクトリと、E: ドライブの "Backups\HRUSData" ディレクトリを指定しています（データパスの「メモ」を参照してください）。DDF が DICTIONARY_PATH に存在する場合は、既存の DDF が使用されます。データベースはメタデータバージョン 1 を使用します。

次の例は、"EastEurope" という名前のデータベースを作成します。DDF の場所をドライブ C: の "Europe\DbaseFiles" フォルダーとし、DDF を新規に作成して、それをデータベースにバインドします。また、セキュリティポリシーを「混合」に設定し、メタデータバージョン 2 を使用します。

次の例は、"Region5Acct" という名前のデータベースを作成し、DDF の場所にドライブ D: の "Canada\Region5\Accounting" を指定し、データベースコードページにサーバーで使用されているデフォルトのコードページを設定します。

次の例は、"Region2Inventory" という名前のデータベースを作成し、DDF の場所にドライブ G: の "Japan\Region2" を指定し、データベースコードページ 932 を設定します。

次の例は、"VendorCodes" という名前のデータベースを作成し、DDF の場所にドライブ C: の "Capitol_Equipment\Milling" を指定します。DDF を新規作成してデータベースにバインドします。さらに、セキュリティポリシーを「混合」に設定してメタデータバージョン 2 を使用し、データベースコードページに 1252 を設定します。