通常のデータベースアプリケーション開発サイクルとその中での DBA の役割を検討する前に、DBA はユーザーがデータベースに何を求めているのかを理解する必要があります。 ユーザーという言葉は、最も広い意味で、ユーザーマネージメントおよび人、データ処理マネージメント、コンピュータオペレーション、プログラミング、システム、ソフトウェアサポートおよび DBA の部門を包含しています。
DBA とユーザー部門間の関係はデリケートであり、特に、あるユーザーがデータベース環境でない場合よりも明らかに低いレベルのサービスを受けたり、労力が余計にかかった場合がそうです。
DBA は、組織の全体としての発展を計り、（そのポリシーをサポートする）公明正大な偏りのない権限を持つとユーザーが感じられるようにしなければなりません。
DBA は長期計画と長期にわたるユーザー要求の両方に注意を払わねばなりません。 DBA は、ユーザー間や、特定ユーザーと企業プラン間に起きた問題の調停を行わなければなりません。
新規アプリケーション開発の間は、DBA はプロジェクトグループとエンドユーザーの仲立ちをする必要があります。
このドキュメントでは、次のトピックについて説明します。
ユーザー（プログラマやエンドユーザー）との連絡は、DBA の仕事の中でも、最も重要であり、最もデリケートです。
エンドユーザーの要求（通常は検索要求に関する）に応えて、DBA は本番データベースについてのドキュメンテーションをチェックし（特に論理データ構造）、この要求を直ちに扱えるかを調べます。
その基本的な結果としては、次の 4 種類があり得ます。
現時点で要求に応えることができない
この場合、DBA は要求を記録し、一定の間隔で見直して状況（ニーズ）が変化したかどうかを確認する必要があります。
ワンタイムリクエストの準備
Natural を使用し、既存データベースからの要求を最小限の労力で満足させることができる場合があります。 DBA の部門が実際に要求を満足させるアプリケーションを作成するか（ユーザー部門にその能力がある場合がある）、プログラマがアプリケーションを作成するかに関係なく、重要な点は、DBA
がデータベース情報に対する要求の解決策を定義することです。
新しいアプリケーションプログラムの作成
アプリケーションを定期的に実行します。 DBA はプログラムを指定し、プログラムの作成とテストについてプログラママネージャと交渉します。
既存のアプリケーションの変更
もちろんアプリケーションシステムの責任者との交渉（要求を出した人と異なるとき）を含みます。変更はシステムのパフォーマンスや柔軟性に影響するからです。
エンドユーザーの要求は結果がどうであれ、十分にドキュメントにしておくべきです。 このような要求事項の議論は DBA にフィードバックする最も有効な情報の 1 つであり、エンドユーザーに対する教育により、十分効果が上ったか、上らなかったかを示しています。
通常データ処理部門からの要求は次のものです。
| 教育 | DBA は、要求者がどの教育をいつ必要としているかを決める必要があります。 このような教育はすぐには提供できないことをデータ処理マネージメントに気付かせる必要があり、 あらかじめ適切な教育プランを立てておくべきです。 |
| 情報 | DBA は、要求者に知らせる必要があり、その情報を得る権利のある場合、それを満足させる必要があります。 これらの質問のいずれかに対する解答が通常の状態から引き出せるとき、既存の標準や手段に一時的または長期的に調整を行う必要がある場合もあります。 |
| 問題 | DBA は解答を知っているか、または Software AG に問題を問い合わせる必要があるかどちらかです。 後者の場合、DBA は、できるだけその問題についてのドキュメンテーションを作成すべきです。 |
| 援助 | これは、いろいろな場合があります。 DBA は、要求されている援助を提供するのは DBA の責任であることを保証しなければなりません。 |
DBA は、データベースのアクセスや更新に対する管理、制御を行わなければなりません。 DBA はユーザーとともに、データベースの各項目に対するアクセス権を設定しなければなりません。 これらのアクセス権や更新権のほとんどは、データを使用するアプリケーションシステムの設計時にはっきりし、データ項目は正しく保護されます。 突発的な要求が起こった場合、ユーザーは DBA と相談すべきです。 このときデータベースドキュメンテーションを参照し、DBA はユーザー要求を満たす最善の方法をアドバイスできます。 さらに、その要求が存在すること自体がデータベース使用に関する DBA のモニタリングの有効な入力情報となります。
データベースに対するアクセス要求は（アプリケーションシステムの一部でも突発的な要求でも）データベースのユーザービューまたはサブスキーマと考えられます。 その内容、セキュリティ、アクセス／操作モードのすべてを相談し記録しておく必要があります。
場合のよっては、アクセス要求はアプリケーションシステムの境界を超えることがあり得ます。 この場合、DBA はデータ項目のアクセス権についてデータ所有者と相談する必要があります。
ドキュメンテーションの標準には、アプリケーションプログラムと DBMS との通常のインターフェイス方法の記述を含む必要があります。 次に示すように、2 つのアプローチのいずれかが使用できます。
ホストプログラミング言語からの Adabas ダイレクトコール
アクセスモジュールへのサービスコール
いずれのアプローチが採用されても、標準インターフェイスポリシーに固執するのが不適当であり望ましくない場合もあります。 このような場合、事前に DBA に相談し、その許可を得るべきです。
突発的要求を扱うとき、DBA はユーザーに対してどのインターフェイスアプローチを採用すべきかをアドバイスする必要があります。 これは、アプリケーションプログラム（SQL アクセスモジュールの有無は関係ない）、Natural、またはその他です。
DBA はユーザーに対し、データベース標準および制御に従うことで生じる利益について説明し、ユーザーがこれを無視した場合に起こり得る問題について十分に説明しておかなければなりません。
ユーザーと DBA の相互の信頼を深めなければなりません。 DBA の権限が公正であり偏りがなく、DBA の決定が利益をもたらし組織全体のポリシーを支援していると、ユーザーが感じることができなければなりません。
Natural を使用してユーザーにデータベースアクセスを許可している場合、ユーザーに突発的な要求を記録させ、DBA に定期的にこれらの要求事項を知らせるべきです。 DBA がデータベース環境の効果を継続的に保証するのに役立つフィードバック／モニタリング情報の一部となります。
