|
このセクションでは、DDF Builder での作業に関する概念的な情報を提供します。以下のセクションがあります。
DDF Builder で作業を開始する前に、このマニュアルで使用している用語についてもう一度確認してください。用語には、リレーショナル データベース モデルでのみ使用されるものもあれば、トランザクショナル データベース モデルに関するものもあります。DDF Builder はトランザクショナル データからリレーショナル テーブル定義を作成するよう設計されているため、これら 2 つのモデルを一つの場所で一緒に用います。トランザクショナル モデルで使用される用語がリレーショナル モデルでは異なる意味になることもあるため、ここでの情報は役に立ちます。次の表に、このマニュアルで使用される用語を示します。
DDF Builder でセキュリティが有効なデーターベースを扱う場合は、DDF Builder でそのファイルを開く前にすべてのセキュリティを無効にしておくことをお勧めします。セキュリティを無効にできなかった場合、DDF Builder では呼び出しが実行されるたびに安全なログインとパスワードを要求します。呼び出しごとにこの要求があると、テーブル定義の作成や変更に必要な回数によっては作業効率の低下を招く恐れもあります。
DDF Builder は Pervasive PSQL v9.x 以上のバージョンでサポートされます。Scalable SQL v4.00 以上で作成された DDF は Btrieve データ ファイル v6.x 以上と一緒にサポートされます。
Scalable SQL v3.xx 以前のバージョンで作成された DDF がある場合は、それを DDF Builder で開く前に変換しておく必要があります。
この手順については、「レッスン 1 - v3.00 の DDF を使った作業」を参照してください。
DDF Builder ではバージョン 6.x のファイルをサポートしますが、バージョン 6.x より前に作成されたファイルはサポートしません。Btrieve v5.x 以前に作成された Btrieve データ ファイルがある場合は、それを DDF Builder で開く前にリビルドしておく必要があります。
この手順については、「レッスン 2 - v6.x より前のファイル形式での作業」を参照してください。
Btrieve ファイルに関連付けられている既存のテーブル定義を開く場合、DDF Builder では一連の比較とチェックを行います。これらの比較とチェックによってエラーが検出されると、DDF Builde はテーブル定義に対して一定の調整を行うことがあります。テーブル定義に対する変更は定義エラー ビューに記録されます。
メモ
DDF Builder では必ず元のテーブル定義を保持するので、DDF Builder で行った変更がテーブル定義に自動的に保存されてしまうことはありません。変更されたテーブル定義または元のテーブル定義のどちらかを別名で保存すれば両方の定義を保持できます。
DDF Builder が行う変更の評価と可能性を理解できるよう、DDF Builder がたどる手順を見てみましょう。
まず、DDF Builder は Btrieve ファイルを調べて、レコード長、インデックス、インデックス セグメントなど適切な内容を分析します。次に、DDF Builder は既存の DDF を開き、その DDF に含まれる情報を見て Btrieve ファイルと比較します。双方の内容が互いに一致するかしないか、体系的に比較されます。
DDF Builder では、Btrieve ファイルで見つかった内容を基準にしてエラーや問題を検出および修正します。次の例でわかりやすく説明します。
1 つのキーを含む Btrieve ファイルがあります。テーブル定義にはこれに対応するインデックスがありません。DDF Builder では Btrieve ファイルを変更することはできないので、この Btrieve ファイルで定義されているキーがインデックスとしてテーブル定義へ引き継がれます。
この種の状況を処理する場合の情報については、「レッスン 6 - インデックスの不一致」を参照してください。
Btrieve ファイルには総レコード長が 120 バイトで定義されているレコードがありますが、テーブル定義では 100 バイト分しか定義されていませんでした。DDF Builder では Btrieve レコードを変更できないので、テーブル定義の方に、割り当てられていない 20 バイトの列を追加します。
この種の状況を処理する場合の情報については、「レッスン 8 - レコード長の不一致」を参照してください。
Btrieve ファイルのキーには、テーブル定義内の対応する SQL インデックスのフラグ設定と一致しないフラグがあります。前の例と同様、DDF Builder では Btrieve ファイルを変更できないので、テーブル定義の SQL インデックスにおけるフラグ設定は Btrieve ファイルのフラグ設定と一致するよう変更されます。
この種の状況を処理する場合の情報については、「レッスン 5 - ファイル/フィールド フラグの不一致」を参照してください。
メモ
第 3 章の 「DDF Builder チュートリアル」では、DDF Builder で作業時に発生する可能性があるさまざまな状況に対応する手順を提供します。
DDF Builder ではすべての問題を修正することはできません。DDF Builder で検出され修正される問題については、テーブル定義エラーを参照してください。
DDF Builder は既存のテーブル定義に対して推奨する変更を行いますが、その変更を保持するよう要求されたり、あるいは元のテーブル定義を破棄するよう要求されることはありません。
変更した定義または元の定義のどちらかを別名で保存すれば、両方の定義を保存しておくことができます。DDF Builder によって行われた変更を受け入れる場合、変更したテーブル定義か元のテーブル定義のどちらかを別名で保存できます。
DDF Builder によって行われた変更を拒否する場合、元のテーブル定義は元の名前で保持されます。
テーブル定義エディターは、テーブル定義のビュー、作成および変更に使用するいくつかの情報ページで構成されます。テーブル定義エディターには以下のページがあります。
[テーブル]ページはテーブル定義の作成や変更時に大半の作業を行うページです。この[テーブル]ページには、未加工データ ビューとグリッド データ ビューがあります。
未加工データ ビューでは Btrieve ファイルのデータを ASCII と 16 進数表示で見ることができます。このビューにはレコード長、オフセットおよびフィールド サイズも表示されます。
また、未加工データ ビューでは列、ヌル インジケーターの判断や、不明なフィールドやバイトを特定するために必要なビジュアル インジケーターも提供します。
ヒント
未加工データ ビューで使用されるビジュアル インジケーターの詳細については、未加工データ ビューでのフィールド属性を参照してください。
グリッド データ ビューは、Pervasive PSQL Control Center の SQL Editor に見られるグリッド ウィンドウ ビューの機能に似ています。
インデックスに使用されるフィールドはサイズや型を変更することができません。フィールド名のみグリッド データ ビューで変更できます。インデックスの追加、インデックスの削除、またはその他のインデックス情報の変更を行うには、Btrieve Maintenance ユーティリティを使用して Btrieve ファイルを直接変更する必要があります。
ヒント
グリッド データ ビューで使用されるビジュアル インジケーターの詳細については、グリッド データ ビューでのフィールド属性を参照してください。
[インデックス]ページでは、DDF Builder が Btrieve ファイルで検出したインデックスとインデックス セグメントを見ることができます。このページからインデックスやインデックス セグメントを追加したり変更したりすることはできません。[インデックス]ページで可能なのはインデックス名の変更のみです。[テーブル]ページでインデックス フィールド名を変更した場合、その変更は[インデックス]ページでリアルタイムに反映されそのフィールド名が更新されます。
メモ
インデックスの名前付けに必要な手順については、「インデックスの名前を付ける」を参照してください。
オルタネート コレーティング シーケンス(ACS)ファイルを使用する Btrieve ファイルで作業する場合、その ACS ファイルは作業対象の Btrieve ファイルと同じディレクトリにあり、拡張子は .ALT(UPPER.ALT
や LOWER.ALT
など)である必要があります。
[プレビュー]ページでは、現在のテーブル定義を使用して書式設定されたファイルのデータを見ることができます。テーブル定義を変更すると、それに応じてこのプレビューも変わります。
[プレビュー]ページは読み取り専用なので、このページに表示される情報を編集することはできません。ただし、このページの下部にある矢印ボタンを使ってレコードを移動することはできます。
[統計情報]ページでは、テーブル定義エディター で開いたファイルの Btrieve ファイル統計情報が表示されます。このページに表示される情報は、Btrieve Maintenance ユーティリティでこのファイルに対して生成された統計情報レポートで報告される情報と同じです。
[SQL ビュー]ページでは、テーブル定義の作成や変更を反映した SQL ステートメントが表示されます。テーブル定義を変更すると、その基となる SQL ステートメントは[SQL ビュー]ページで直ちに更新されます。
このページの情報は読み取り専用なので、このページ上で内容の変更を行うことはできません。必要であれば、ステートメントを選択してコピーし別の場所で使用してください。
注意
Pervasive 辞書システム オブジェクトへの参照が含まれるステートメントは再利用しないでください。これらのオブジェクトは X$<テーブル名> という書式で簡単に特定され、所有者から再利用を禁止するコメントが記述されています。
Pervasive.SQL 2000(v7.5)より前の Pervasive.SQL および Scalable SQL のバージョンでサポートしていたのはレガシー ヌルのみです。レガシー ヌルを使用するファイルは DDF Builder で認識されますが、DDF Builder で作業する場合は、このタイプのヌルを処理するために必要なアクションはありません。
Pervasive.SQL 2000 では真のヌルに対するサポートが追加されました。真のヌルについては、フィールドの先頭にあるバイトで、ヌル インジケーター バイトとしても知られています。これは、該当する列にヌル値の可否を指定するために用いられます。
DDF Builder でレコード フィールドを定義する場合、レコード内にヌル値を許可するフィールドがあるかどうかを知っていることが重要です。なぜなら、レコードの一部分でヌル値を許可することにした場合、1 バイトが余分にフィールドへ追加されるからです。ファイルは Btrieve ファイルであるため、レコードでヌル値が許可される部分は、ヌル インジケーター バイトを使用することで指定されます。ヌル インジケーター バイトは、テーブル定義エディターの未加工データ ビューでフィールドまたは列の直前のバイトに該当します。[ヌル]チェック ボックスが選択されると、ヌル インジケーター バイトがアクティブになり、そのヌル インジケーター バイト分を確保するためフィールドのサイズは自動的に 1 バイト削減されます。
メモ
Pervasive.SQL 2000 より前に作成されたファイルで作業する場合、ヌルはほとんど問題になりません。
DDF Builder でヌルを許可するフィールドを作成する際は、フィールドのサイズとヌル インジケーター用に必要な 1 バイトを考慮する必要があります。これはヌル値が可能なフィールドのサイズを 25 バイトにするつもりでれば、実際は 26 バイトとして定義し、1 バイト分をヌル インジケーター用に確保することを意味します。フィールドに対してヌル値を許可するよう指定すると、そのフィールドのサイズは自動的に DDF Builder によって 1 バイト削減されます。
メモ
ヌル値を許可する列とヌル値を許可しない列での作業例については、チュートリアル 1 の例で 「未加工データ ビューでヌル値を許可する列を作成する」と「グリッド データ ビューでヌル値不可の列をヌル値を許可する列に変更する」を参照してください。
|