データベース環境の制御や管理を実施できるようにシステムを設定するときに、DBA の全般的な役割を次に示します。
データベース手順と標準の設定
データベース設計の援助
ユーザー教育
データベースシステムに適したアプリケーション選択
データベースドキュメントの維持
データベースの一般的管理
このドキュメントでは、次のトピックについて説明します。
通常のデータ処理（DP）環境と同様に、標準や手順は初期の計画の一部として設定した方が、問題が発生した後に設定するよりも効果的です。 このセクションでは、手順や標準を定義するときに考慮すべき一般事項について述べます。
データベース環境を効果的に制御するために必要な手順は、DBMS を使用するとき、まず最初に設定する必要があります。
これらの手順について、この章で概略を述べます。 多くのインストレーションでは、短時間で DBMS の使用を採用していますが、できるだけ早く運用を開始したいからといって、全プロセスのプラニング（特に、管理手順や制御手順の取り決めと導入）をおろそかにしてはなりません。
これらの手順の導入にあたっては、IS 部門内でも、またユーザーとも、多くの議論（特に、何を採用するか、費用効果の良いものは何かなど）がかわされるでしょう。ある部署で DBMS テクノロジーを最初に使用するアプリケーションは、DBA プロシージャの開発と並行して開発されることになるでしょう。 しかし、組織の IS やユーザーのマネージメントに、これらの手順が必要であることを気付かせ、（議論の後）これらを採用させることが基本です。
手順の設定データ項目をどのように機密保護するかを決めるのは誰でしょうか。 ユーザーというのは、自分の業務にあまりにも密着しており、近視眼的です。 また、アナリストがこのような決定にあたって、組織全体のかかわりあいについて把握できないこともあり得ます。 最終的な決定は DBA が下します。 つまり、DBA とはすべての処理を監視し違反するものをチェックする人です。
DBA はインストレーションで、使用する標準のリカバリ手順を設定しなければなりません。 各アプリケーションが稼動する前にこれらのリカバリ手順が妥当であるかを確認しなければなりません。 つまり、別のアプローチ（例えば、データベースセーブおよびリストアの代りに、ファイルセーブ／リストアを使用するなど）が採用される可能性があるため、この段階でも決定に DBA が関与する必要があります。
このマニュアルの大部分は、データベース環境のガイドラインとして記述されています。 ここで説明している内容は、必ずしもすべてのインストレーションに関係していません。 ガイドラインが標準となるかどうかは、ユーザー／開発者の組織の規模と多様度に応じて異なります。 小さな同一的なユーザーグループは通常、コミュニケーションが十分であるため、広範で厳密に定義された規則の集合を必要としません。
他方、さまざまな分野で構成され、地理的に分散されたユーザーグループは、正しい制御に必要なコミュニケーションが不足する傾向にあります。このようなグループには、データ構造やプログラム開発の不一致を防止するために規則が必要です。 明らかな利点がない限り、規則を好む者はいません。 しかし、標準は一般的な規則です。 標準を定義するときの考慮事項をいくつか次に示します。
標準は簡潔、明白、かつ最小限に維持します。 しかし、標準に曖昧さがある場合は、簡潔な注意書きを添える必要があります。 例えば、Adabas 環境での一時データセットの使用に関する標準には、次の注意書きが必要な場合があります。
一時データセットの使用 作業をリカバリ／再スタートできるように、一時データセットは必ずカタログしてください。 Adabas データベースでは、Adabas Recovery Aid 機能を使用してニュークリアスが自動的にリストア、再スタートされ、失敗したジョブストリームが再構築され、再構築したジョブが再サブミットされます。 一時データセットをカタログしていなかった場合、これらのデータセットは、Adabas Recovery Aid によるジョブストリームの再構築の対象にすることができません。
標準は、少なくとも新たに追加するときには必ず見直し、古いものは削除または更新します。 変更／削除／追加した標準の概要をユーザーに周知します。
特定の制御手順または管理手順が特定のサイトで必要であると思われる場合は、標準として定義する必要があります。
データベースドキュメントの保守はアプリケーション開発プロセスに不可欠な要素として考える必要があります。 このため、DBA は DBMS を使用する新しいシステムの開発に参加する必要があります。 ドキュメント化プロセスでは、ツールとして主にデータディクショナリを使用します。
DBA は、現在のデータベースアプリケーション、今後の予定、データベースの保全性に対する責任に関する幅広い知識を活かして、データベースにデータを入力する各システムが備えるデータ整合性確認手順の設計に参加する必要があります。 このようにすると、データベース内のデータの品質が、確実に許容できるレベルに保たれます。 データディクショナリは、整合性確認の要件のドキュメント化にも使用できます。
プロジェクトチームがデータベース設計を行う際、DBA が行う援助は次のとおりです。
論理設計が、問題を適確に表わしているか。 論理データベース設計は、ある特定の DBMS の制限や機能に制約されないようにします。
物理設計が、処理効率を悪くしないか。 プロジェクトチームは、他に指示がなければ、特定の問題だけに対処しようとします。
将来を考えたとき、 設計に柔軟性があるか。 DBA と組織は、ある程度の期間をかけて、設計内容を練る必要があります。
独立した役割として、DBA は、結果としてできあがったデータベース設計を客観的に評価できる唯一の担当です。 したがって、ときには設計段階にも介入する必要があり、この場合には DBA は疑問点に対して的確に回答します。
システムアナリストや DP リソースマネージャの尽力とは無関係に、ユーザーは DBMS テクノロジーの有益性を過剰評価することがあり得ます。 柔軟性、プログラムとデータの独立性、およびデータ可用性のような議論により、ユーザーが過剰に期待し、創造の自由を錯覚してしまうことがあります。
データベース環境で業務を行うのに関連して、その利点と同様問題点をもユーザーに認識させるのは、DBA の責任です。 DBA は、このような必要性に適したユーザーを対象に、教育内容をよく吟味し練ってから導入に関する教育を行う必要があります。
インストレーションに DBMS が必要な場合、アナリストやプログラマが DBMS を安易に使用してしまう傾向があります。 新規アプリケーションに、突然 DBMS テクノロジーが必要になったように見られます。 誰かが、この状態をしっかりと統括し、DBMS テクノロジーに本当に適したアプリケーションを選択するよう、制御しなければなりません。 この誰かとは、DBA のことです。
DBA は、各アプリケーションに DBMS を使用した場合のプラス面とマイナス面の一覧表を作成する必要があります。 DBMS の機能を検討する段階で（すなわち、多くのコストを費す前に）、この一覧表を作成しなければなりません。 また、提案アプリケーションの分析に当たって、次の点を考慮する必要があります。
DBMS が必要か。
既存の環境を妨げないか。
提案システムは柔軟性があるか。
コストパフォーマンスは良いか。
アプリケーション提案の契機となった問題をすべて分析済みか。
DBA は、データベース関係のすべての権限と責任を有する中心として、新規データベースプロジェクトの選択に寄与する担当です。
次に、DBA が果さなければならない役割の一覧表を示します。
| 設計 | 標準のデータ定義 物理データベース セキュリティ、プライバシー、およびリカバリ手順 サポートソフトウェア（DBMS パッケージにないとき） |
| 選択 | データベース管理システム パフォーマンス測定ツール チューニングエイド |
| 予測 | トランザクション量の変化や新規アプリケーションの効果 |
| 決定 | 検索方法 アクセスメソッド データベース設計 レコード間の関係 データベース使用規則 |
| 教育 | データベース技術についてアナリストやプログラマの教育 データベースの操作手順についてオペレータの教育 |
| 周知徹底 | 設計、ドキュメンテーションなどに対する標準 品質管理 アクセス |
| 組織編成／管理 | データディクショナリの作成と維持 ファイルの変換 完全性、セキュリティ、およびリカバリのベンチマークテスト 受け入れテスト ユーザーへの変更点についての伝達 |
| 計測 | ハードウェアのパフォーマンス ソフトウェアのパフォーマンス データベース使用統計 |
| チューニング | システムパフォーマンス |
