このドキュメントでは、次のトピックについて説明します。
DBA は、データベース使用の知識とそのパフォーマンスをモニタすることで、機器構成やアプリケーションプラニングについて、データ処理マネージメントの決定に重要な役割を果たすことができます。 DBA は、日々の問題や困難さとともに、ユーザーの短期および長期の要求を知っています。 DBA は Software AG と接触し、DBMS に対する開発予定も知ることができます。 したがって、DBA はこのような議論に参加するべきです。
DBA は、アプリケーション開発プロジェクトに最初から参加すべきです。 DBA は、組織のデータ処理開発計画の観点から、データベースアプローチが正当かどうかを決めるため、初期調査を助けることができます。
データベースプロジェクトの初期段階以後も、DBA は継続してプロジェクト開発に参加すべきです。 新規プロジェクトの追加は特殊な問題を生じる場合があり、DBA は注意深く解決しなければなりません。
既存データの使用変更や新データの追加は、既存システムのパフォーマンス特性を変える可能性があります。 全ユーザーに妥当なサービスを行うためには、物理構造やデータの位置の再設計が必要な場合もあります。
すでに述べたように、DBA は論理データ構造を定義するためにデータ間の関係の公式化と定義を行う責任があります。 これらのデータ構造には、予想できる開発に対する DBA の知識が反映され、他の関連ユーザーの要求が含まれる必要があります。
次の 2 つの主要な観点があります。
既存データの定義と編成
新データの追加
効率良い物理構造にするには、論理関係の解釈や導入についてかなりの専門知識が必要です。 スペース、パフォーマンスおよびコストは、均り合いがとれていなければならず、次に考慮すべき点を示します。
データ構造（論理データフォーマットおよび関係）
ストレージ構造（物理データフォーマットおよび関係）
アクセスメソッド（使用可能な、および使用すべき）
アクセス頻度
必要な物理ストレージ媒体
タイミングに関する配慮
検索方法
解答（およびその背後の理由）は十分にドキュメントにしておくべきです。
DBA は、プロジェクトチームのメンバがユーザーの現在および将来の要求を理解し、認識できるように援助できる理想的な立場にあります。 この場合、ユーザーは最も広い意味で使用しています。 アプリケーションシステムを設計し開発するユーザー部門だけでなく、 組織全体として忘れてはならない他の潜在ユーザーも含んでいます。 また、すでにわかっている将来の開発予定も考慮すべきであり、 場合によっては、DBA は新規アプリケーションの開発全体を統制する必要があります。これは、このような開発が、完了後にはデータベースオペレーションの一部になることもあるからです。
このドキュメンテーションの内容を実行に移せば、DBA はすべてのデータベース活動を調整できるはずです。 DBA は、データベースに対するすべての開発計画にアドバイスする必要があります。また、組織全体を対象とした総合情報システムに向けて、安定した、よく制御された経過をたどるよう保証する必要があります。
一般に、データベースの実際の使用に関するアドバイスをし、DBA の品質管理の職務を遂行するために、DBA は新規プロジェクトの成否の検討段階からはじまり、すべての段階に参画すべきです。
したがって、DBA は、プロジェクトチーム間、現在のユーザー、将来的なユーザーに対して一貫した窓口として機能します。 全ユーザーの利益が最大となるようデータベース設計の心構えを奨励するのがその目的です。
これは、データベース設計の重要な部分です。 新規プロジェクトがデータ分析とファイル設計の段階に入ったら、DBA は新規アプリケーションシステムで使用するデータへのアクセス要求の観点が狭くならないように監督することが重要です。
アクセス要求の分析も行うべき作業です。 組織の要求が変わると（時間とともに必然的に変わるため）、DBA は要求の変更についてのフィードバックを受け取りますが、 新規要求に過度に対応しないよう注意しなければなりません。つまり、そのときだけに必要なことかもしれないからです。 組織のアクセスや処理要求に対する重要度が、少しずつ変化しているときや、目立って変化したときは、その都度、DBA は対応する必要がありますが、そのような対応は関連部門すべてと十分議論した後だけに限定します。
DBA は、プロジェクトチームを援助し（おそらく、データディクショナリを使用し）、次の点を考慮し、適切なデータ取得プログラムのプラニングを行うべきです。
現在のデータの形式と位置
データの収集方法
現在のデータの正確さと完全度
最終的にデータベースに格納する前にデータに行う必要のある変更事項
アプリケーションシステムの導入に関していつまでにデータを収集すべきか 中間の期間をどのように処理するか
このプロセスは、データ収集プログラムで行うこととなります。このプログラムはデータディクショナリに記録するために DBA に情報を提供するとともに、要求される特殊な編集や整合性確認について必要な処理を含みます。
データベース（の一部）の設計は、本来、柔軟性（将来的に新しいニーズが出てきたときに容易に対応できること）と、パフォーマンス（ディスクスペースの有効利用やコンピュータ処理時間）の考察を含みます。
DBA は、プロジェクトチームが柔軟性とパフォーマンスのどちらに優先度を設定するのかを確認しなければなりません。 DBA はアプリケーションの分野で必要な柔軟性（すなわち、計画中のシステムもこのデータを使用する）やパフォーマンスの向上のための設計に関してプロジェクトチームにアドバイスするのに都合の良い地位にあります。 このようなパフォーマンス対柔軟性に対する考察の最終目的は、この一方だけを考慮し、他方を犠牲にするような決定を下すことを防ぐことです。
DBA は、プロジェクトチーム、他の Adabas ユーザー、および Software AG と接触することで、アプリケーションプログラムとデータ構造の設計についてのかなりの知識を漸次得ることができます。 DBA はその地位により、組織全体に適切な情報を流します。 さらに、アプリケーションの設計についてアドバイスします。
DBA 自身は実際にデータベース設計を行わないかもしれませんが、ファイル／レコードの設計やディスクリプタの選択、その他については、プロジェクトチームのメンバにアドバイスできます。 これによりデータベース設計において、他のユーザーの要求を反映させる機会ができます。
DBA は物理データベースの設計が、後のプロジェクトの成功を損うことなく、最初のアプリケーションの論理要求を効率良くサポートできるようにする必要があります。 DBA は、アプリケーションシステムに必要なセキュリティ、完全性およびリカバリ、設計規則や手順を満足させるため Adabas をどのように使用するべきかをアドバイスします。 ある場合、追加のソフトウェアが必要かもしれないし、その場合は DBA がその設計を援助します。 DBA は、データベースのセーブ／リストア、パフォーマンスの測定、データベースの実際の内容の分析等に追加ユーティリティが必要かどうかも考慮します。
この段階では、DBA はデータ分析の最善のアプローチ、Adabas の使用法、論理データ構造の設計方法およびどの設計オプションが最も効果的であるかについても、アプリケーションプロジェクトチームにアドバイスできます。
DBA は、プロジェクトチームが特定のアプリケーションシステムに必要な物理ストレージを決定するときに援助する責任があります。
次のパラメータを考慮すべきです。
格納するデータの量
データの予想増加量
レコードの平均長
ある期間内の追加レコード数と削除レコード数
データの関連（データ構造）
データの表現（内部フォーマット）
圧縮の効果
データに対して使用すべきアクセスメソッド
ストレージ媒体と処理コストを最小にするのか、サービス（スピードとスループットについて）を最大にするのかを十分に比較検討する必要があります。 また、アプリケーションシステムの実装に必要な柔軟性も配慮する必要があります。この要件は将来的に変化する可能性があり、また他のアプリケーションシステムがこのアプリケーションのデータにアクセスする必要がある場合があります。 この場合、必要物理ストレージを最小にすることで柔軟性が失われる場合、将来起こり得る問題点を考慮せずに、この決定を行うべきではありません。 DBA はもちろん、理想的にこの種の情報をプロジェクトチームに提供する位置にあります。
DBA は新規アプリケーションに使用するテストデータベースのタイプについて、プロジェクトチームにアドバイスする必要があります。 テストを支援するために、テストデータベースを設定します。 システムテスト中に DBA 自身のモニタリング、監査、エラー修正および制御の手順でテストしてから、システムの本稼働を開始します。 これらの手順はシステムが本稼動してから設計したのでは遅すぎます。アプリケーションシステムの開発と並行して DBA がこの手順を作成します。
テストデータベースについては、本番データベースと分離し、別のディスクパック、別のデータベースにロードするのが最善の方法です。 これには、次の 2 つの問題があります。
マルチユーザーモードで本番業務と並行してテストを行うことはできません（シングルユーザーモードではこの問題は起きません）。
本番データ（あるいは本番ファイルのいくつかのフィールド）が新システムのテストに必要なこともあります。
1 番目の問題については、ストレージの容量が許せば、Adabas ニュークリアスを 2 つ同時に実行して、1 つの本番用、1 つをテスト作業用に割り当てることで解決できます。
2 番目の問題については、Adabas の ADASAV ユーティリティを使用して本番データベースから必要データをテストパックにコピーすることで解決できます。 この場合、テストデータに対するアクセス権は、テストが始まる前に承認されていなければなりません。
テストデータベースを別に持つことで、システムが本稼動するときのファイル番号でファイルをロードできるし、テストにより本番データベースを破壊することもないという利点が生じます。 既存ファイルにフィールドを追加したり、新規アプリケーションシステム用にディスクリプタを新規に設定する場合、特に重要な考察事項です。
システムテストを行う前に、ファイル変換やデータベース初期化をどのように行うかを決め、必要な特定の変換やセットアッププログラムが全部揃えておきます。 並列運用の方法は十分に配慮する必要があり、ここでも既存システムからの出力と新システムからの出力を比べたり、正当性確認を行ったりするために、特定のプログラムが必要な場合があります。 特定の問い合わせ機能（例えば、Natural）もテストや並列運用を助けるのに必要かもしれません（これらは、テストだけでなく以降の本番運用でも有効なことが多い）。
新規データベースが最終的に実装する前に、システムのあらゆる観点（パフォーマンスと弾力性を含む）が十分かを調べる受け入れテストを実行します。 これらは、並列運用に追加してもいいし、しなくてもかまいません。
新プロジェクトのデータアクセス方法を綿密に制御することは、データベースの既存ユーザーのデータ保全性が損なわれないようにするために必要です。 システムテストについては、データベースへのテスト変更が、実際の運用に使用するデータベースに影響しないように、特別なテストモードが必要である場合があります。
