CREATE DATABASE

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

CREATE DATABASE [IF NOT EXISTS] データベース名 DICTIONARY_PATH '辞書パス名' [DATA_PATH 'データパス名'] [; 'データパス名']...] [NO_REFERENTIAL_INTEGRITY] [BOUND] [REUSE_DDF] [DBSEC_AUTHENTICATION] [DBSEC_AUTHORIZATION] [V1_METADATA | V2_METADATA] [ENCODING <'コードページ名' | 'CPコードページ番号' | DEFAULT>]

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

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

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

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

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

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

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

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

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

データパス名は、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 がデータベースと関連付けられます。

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

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

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

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

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

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

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

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

エンコードのサポートは、データベースコードページとクライアントエンコードに分割されました。この 2 種類のエンコードは、別個のものですが相互に関係しています。詳細については、『Advanced Operations Guide』のデータベースコードページとクライアントエンコードを参照してください。

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

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

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

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

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

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

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

Linux および macOS では、dbmaint ユーティリティの man ページを参照すると、使用できるコードページ名とコードページ番号の一覧が表示されます。この例については、『Zen 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 に設定します。