|
Pervasive PSQL は、リレーショナル インターフェイスとトランザクショナル インターフェイスの両方を介して同一データへの同時アクセスをサポートするように設計されていますが、リレーショナル(SQL)データベース アーキテクチャの機能によって、リレーショナル アクセスを妨げるものがあります。たとえば、参照整合性(RI)のようなリレーショナル アクセスを制限するように設計された機能は、データ整合性という点では Btrieve アクセスも制限します。
整合性の設定、バウンド データベース、ODBC/SQL セキュリティ、トリガー、参照整合性、およびオーナー ネームなどの機能をトランザクショナル(Btrieve)アプリケーションが使用するデータベースに実装するには、あらかじめこれらの機能について完全に理解している必要があります。ほとんどの場合、一挙両得のデータベース アクセスを得られますが、セキュリティ、参照整合性、およびトリガーはアクセスやオペレーションに制約を設けるため、一部の Btrieve オペレーションは、それらの実装によって制限されたり妨害されたりする場合があります。
整合性の設定、バウンド データベース、セキュリティ、トリガー、または参照整合性を使用している場合には、データまたはファイルへの Btrieve アクセス時、そのデータに設定されているバインドおよび制約に違反すると、Btrieve アクセスが制限されたりアクセスできなくなったりすることがあります。トリガーと RI は主として Btrieve API を介したデータの操作能力を制限します。
セキュリティとオーナー ネームは、適切なアカウント、アクセス権、およびパスワードを持たないデータへのアクセスまたは操作能力を制限する場合があります。これらの機能について考えられるさまざまな組み合わせはたくさんあるので、最も一般的な組み合わせのみを以下に一覧表示します。
(1)データベースにバウンド データベースが設定されているかどうかに関係なく、データベース エンジンは、データ ファイルにトリガーある場合、外部キーがある場合、あるいは外部キーで参照される主キーがある場合には、自動的にデータ ファイルをバウンドとしてスタンプします。バウンド データベースやファイルの詳細については、バウンド データベースを参照してください。
(2)テーブルにトリガーを追加すると、Btrieve インターフェイスはトリガーの実行を引き起こすあらゆるオペレーションについて、そのファイルへのアクセスが妨げられます。トリガーは Btrieve インターフェイスを介したデータベース操作には作用しないため、このロックアウト動作によってデータの一貫性が保持されます。詳細については、バウンド データベースと整合性の設定を参照してください。
(3)データベースまたはファイルがセキュリティで保護されている場合、ユーザーがそのファイルに対する権限(リレーショナル ユーザー名とパスワード、または有効な Btrieve オーナー ネーム)を持っているのであれば、アクセスは許可されます。セキュリティで保護されたデータベース内にあるがオーナー ネームが設定されていないファイルには、Btrieve ユーザーはアクセスできません。Btrieve オーナー ネームが既に設定されているファイルにリレーショナル セキュリティを最初に設定するとき、Master ユーザーがオーナー ネームを使ってユーザーにリレーショナル権限を付与する必要があります。詳細については、Pervasive PSQL セキュリティを参照してください。
(4)テーブルに参照整合性制約が含まれており、そのデータベースで整合性の設定が有効になっている場合、制約に違反する Btrieve および SQL 操作は共に行えません。このメカニズムにより、アクセス方法に関係なくデータの整合性が保たれます。
名前付きデータベースに[整合性の設定]属性を指定しない場合、データベース エンジンは参照整合性、トリガー、セキュリティ規則のいずれも強制しません。名前付きデータベースに[整合性の設定]属性を指定すると、データのアクセスに使用する方法とは無関係に、MicroKernel はデータベースの定義済みセキュリティ、参照整合性(RI)およびトリガーを設定できます。MicroKernel は以下のようにこれらの規則を設定します。
バウンド ファイルに複数の制約が存在する場合、アクセス レベルは最大限の制約または制約の組み合わせに従います。たとえば、ファイルに INSERT トリガーと UPDATE トリガーが定義されている場合、Btrieve ユーザーは読み取り専用および削除アクセスのみが行えます。
「整合性の設定」が直接「バウンド データベース」に関連付けられていません。データベースは整合性の設定なしでバインドされるか、データベースはバインドされずに整合性の設定を設定されます。
名前付きデータベースに「バインド」属性を指定した場合、そのデータベースの DDF およびデータ ファイルはほかのデータベースとは関連付けることができません。また、バウンド データ ファイルを、データベース内の複数のテーブル定義と関連付けることもできません。新しいテーブルまたは DDF をバウンド データベースに追加すると、データベース エンジンが自動的に新しいオブジェクトのバインドを行います。この動作により、予測できない動作やデータ整合性を壊すことになる矛盾を防ぎます。たとえば、同じデータベース内の 2 つの異なるテーブル定義に同じデータ ファイルを使用した場合、一方のテーブルに RI 規則を定義し、もう一方には定義しないでおくことができます。この場合、RI 規則を持たないテーブルに行を挿入することは、もう一方のテーブルの RI 規則に違反することになります。データ ファイルと DDF をバインドすることによりこのような矛盾を防ぎます。
DDF および データ ファイルは、個々にバインドできます。データ ファイルにトリガーがある場合、外部キーがある場合、または外部キーで参照される主キーがある場合、データベース エンジンは自動的にそのデータ ファイルをバインド データ ファイルとして特徴付けます。これらのファイルは別のデータベースと共有できず、複数のテーブル定義に関連付けられることもできません。
データ ファイルがバインドされていることは、そのデータ ファイルへの Btrieve アクセスには直接影響しません。ただし、バインドされたファイルには Btrieve アクセスを制限するほかの制約があることがあります。
データベースへの「整合性の設定」および「バウンド データベース」設定の使用法については、データベースの新規作成 GUI リファレンスを参照してください。
|