データベースドキュメンテーションとは、データベースを適切に、効率良く、継続して使用するために必要な手順、標準、指針およびデータベース記述を記録しておくことです。
ドキュメンテーションは、次の人（部門）が使えるものを準備し、それぞれ配布しなければなりません。
エンドユーザー
DBA 部門自体
コンピュータオペレーション部門
アプリケーション開発部門
これらの人（部門）に対して適切なドキュメンテーションを準備し維持するのは、DBA の役割です。 この章では、必要なドキュメンテーションの各種タイプについて説明します。 この一覧は、必ずしもすべてを網羅していません。
このドキュメントでは、次のトピックについて説明します。
特に次の分野で一貫したデータベース制御を設定し、維持します。
データ定義：一貫した方法を採用します。
データ使用法
データベースの特定の部分の所有権と責任
データのアクセスと操作：データベース内のデータのアクセス方法と更新方法の標準は、データ保全性を実現するために不可欠です。 リクエストをコーディングするときの標準手順を設定することで、誤りの確率を減らすことができます。 例えば、キー値の更新については、厳重に制御する必要があります。
データの編集と整合性確認：DBA はデータベース中のデータの品質を一定のレベルに保ち、データが規則どおりであることを保証するための手順を設定しなければなりません。 したがって、DBMS を使用する新規アプリケーションの受け入れテストやシステムにも DBA は参加すべきです。
コンピュータのオペレーション：コンピュータオペレータがデータベースを扱う際の標準の手順を設定するのも DBA の役割です。 この中には、標準バックアップ手順、再スタート／リカバリ手順、およびその他オペレーション方法が含まれます。
データベース環境の標準の設定に従いたくない人がいるかもしれません。 標準の状態、また標準を設定する分野を慎重に検討します。 一般に、新しい標準を設定するには、すべての関係者がそれを提案として受け入れるためだけにも交渉、調整、妥協が必要です。 標準が実用的かどうかを確認する唯一の方法は、実装することです。
どんな標準を設定しても、変更されることがあり得ます。 既存の標準の変更は、新しく標準を設定するときよりも厳重にコントロールしなければなりません。 変更点は、正式に提案し、全関連ユーザーに変更点を伝達する必要があります。 提案した変更に基づき業務を行った後、再吟味し、関連ユーザーと標準とするべきかどうかについて検討します。
DBA は定期的に、データベースの標準の効果を確認し、その標準に従っているかを確認するため、再吟味しなければなりません。 この後、正しい方策を採る必要があります。 また、データベース環境内で業務を行うすべての人に、データベースに対する標準事項の使用を知らせ、十分な教育を行うことを保証するのも、DBA の基本的な役割です。
データベースの導入先によって手順や要件はそれぞれ異なるので、このマニュアルでもデータベース環境に対する特定の標準については言及していません。
データベースの記述は、次の主要分野を満たしていなければなりません。
概念データベース：格納データに関する公式記述およびその固有の論理データ構造の定義です。 DBA は、データ構造を明確に定義する必要があります。このとき、予想される開発に関する DBA の知識、また他の既存ユーザーや潜在ユーザーの要望を反映させます。
データベースの使用：アプリケーションレベルと個々のデータ項目レベルの両方についての情報を格納すべきです。 新規システムが開発されるとき、このドキュメンテーションは重要な役割を果します。 ここに格納すべき情報については、次項で説明します。
実施：データベース中のデータの格納方法です。 データベースの物理格納構造に関するドキュメンテーションです。次の事項を含む必要があります。
実装するデータ構造（論理データフォーマットと関係）。 これらは通常、概念データベースのサブセットです。
ストレージ構造（物理データフォーマットと関係）。Adabas に関しては、フィールド定義テーブル、カップリング関係およびその他固有の関係です。
データ量各：ファイルのレコード件数と平均レコード長です。
予想される増大量：ファイルおよびフィールドサイズ（つまりレコード長）別。
レコードの追加と削除件数：更新実行の平均件数。 追加や削除方法（ユーティリティか、ユーザープログラム）と同様、追加や削除の制限（つまり、ファイル全体にランダムに更新が行われるか、それともある一部に限定しているか）に注意を払うことも大切です。
他に、なぜこの実施方法が選ばれたかも記録すべきです。 この情報は、後日メンテナンス時や新規アプリケーションの設計時に有効であることがわかります。
DBA は、上記のような方法で、データベースを正式に記述し、データディクショナリ中に、この記述を維持するのは（この処理を自動化してもしなくても）、DBA の責任です。 この業務を行うのに必要な全情報を DBA に供給するのにプロジェクトチームが必要です。
データディクショナリは、データの定義、構造、使用法についての情報をもつものです。 実際のデータ自体ではなく、データに関する情報をもっています。 簡単に云うと、データディクショナリは、各データタイプ（項目）の名前、その定義（大きさやタイプ）、使用場所と使用法および他のデータ要素との関連に関する情報をもつものです。
データディクショナリにより、DBA は組織のデータリソースの管理や制御がより良く行えます。 また、データディクショナリの使用経験ユーザーは、プロジェクト管理やシステム設計においてこれが有効なツールであることを認めています。
また、データディクショナリにより、DBA は実際のデータ項目と、データ項目を使用するプログラムを別々に管理できます。 このことにより、実質上データの有効性を高めることができます。 データディクショナリは、データをより有効に使用するのに必要な情報を収集する役割を果たしています。
ディクショナリは、データの定義をすべて含む情報の格納場所であり、データ属性、特性、データ源、使用法および他のデータとの相互関係を含んでいます。 データディクショナリは、次のような情報を提供します。
このデータタイプに適用される整合性テストの種類
このデータタイプを使用するモジュール、プログラム、システムおよびレポート
適用されているセキュリティのレベル、データタイプのアクセス権を有する人、 このデータタイプの更新権を有する人
各種アプリケーション環境でのこのデータタイプの別名
このデータタイプの入力源
このデータタイプの文章記述
Predict（Adabas データディクショナリシステム）により、データディクショナリの設定と更新ができます。
オンラインモードでもバッチモードでも、ディクショナリに対してデータベースに関する情報を格納できます。 Adabas ディクショナリ内のデータの記述には、ファイル、各ファイルに定義されたフィールド、ファイル間の関係に関する情報が含まれます。 使用法に関する記述には、そのデータを使用するシステム、プログラム、モジュールおよびレポートに関する情報の他、データの所有者と使用するユーザーに関する情報が含まれます。 ディクショナリエントリは、次のような情報から成ります。
ネットワーク構造
Adabas データベース
ファイル、フィールド、および相互の関係
所有者と使用者
システム、プログラム、モジュールおよびレポート
フィールド整合性チェック（処理ルール）
標準のデータディクショナリレポートは、次の情報を出力できます。
データディクショナリの全内容
フィールド情報、ファイル情報、相互の関連情報
ファイルごとのフィールド情報
また、ディクショナリは標準の Adabas ファイルなので、Natural から直接ディクショナリデータにアクセスできます。
Adabas データディクショナリシステムの詳細については、Predict のマニュアルを参照してください。
データベースを使用する各アプリケーションには、少なくとも次の情報が記録されていなければなりません。
アプリケーションの特質
アプリケーションの機能に関する記述
使用モード：バッチ／オンライン、シングル／マルチユーザーモード
使用頻度：スケジュールされた標準回数
トランザクションのタイプと量
パフォーマンスに関する事項：許容最小限のレスポンスタイム
ファイルの心要条件
アクセスするファイル
ファイルのアクセス方法（ディスクリプタの使用）
使用するデータ項目（フィールド、サブフィールド、スーパーフィールドなど）
セキュリティ要件
暗号化、パスワードの使用（サイファキー、パスワードは特定ユーザーにのみ使用可能とする）
システム／プログラム／問い合わせの使用を許可されているユーザー
バックアップ必要条件：ファイルバックアップの頻度と内容
再スタート必要条件
どのようなデータベースも概念データベースの一部を実装しているにすぎず（前のセクションを参照）、ユーザーの要求は時とともに変化するので、時が経つにつれて、データベースの新しいアプリケーションが見つかります。 このような新しいアプリケーションは、完全に新規システムとして開発してもよいし、既存システムに追加してもかまいません。このようなアプリケーションは、最初はユーザーの単純な要求として現れます。
DBA は、このような未計画のデータベースの使用を記録しておく手順を設定する必要があります。また、あるアプリケーションが相対的によく使われたり重要になった場合、データベースやデータベース内のファイルの再設計や再編成により、処理効率を上げることができます。 例えば、最初にファイルが顧客番号順にロードされたとします。 その後、ファイルを営業マン番号順に処理するアプリケーションがより重要になった場合、 ほとんどの既存アプリケーションの論理的な処理には影響を与えることなく、ファイルをアンロードし、営業マン番号順にリロードすることができるため、このファイルを使用するすべてのアプリケーションに必要な処理時間は全体的に減らすことができます。
このような計画になかったデータベースの使用や処理優先度の変更は、ユーザーが、このような作業を自分の部門で行うのか、または DBA に依頼して行うのかについての情報を要求してきたときに、記録します。 このような記録は、定期的に DBA が再調査し、関連ユーザーと議論しなければなりません。
新規アプリケーションについては、最初にデータディクショナリを参照し、必要な情報源を判断します。 新規プロジェクトのシステム分析および設計段階で、データ源の記述が行われます。
記録する必要がある情報は次のとおりです。
現在のデータの形式と位置：形式、ファイル、コンピュータのストレージ媒体
データを入手するために使用するアクセス方法
必要な整合性確認や編集方法も含んだ、現在の正確性、完全性およびタイムリー性に関連するデータの用途
データベースに格納する前にデータを修正する必要性があるか
データ使用権を有するエージェント
データ取得コスト
DBA は、データベース中のデータのアクセスや更新処理のすべてについて管理し制御しなければなりません。 そうでないと、データベースに対し意味のある制御や保護が行えません。 制御が十分でないと、データの安全性や完全性に関して重大な問題が起こることになります。
データベースに対する権限と責任は、組織という枠を超えているため、業務単位ごとのデータベース利用、および業務単位間のデータベース利用を対象とする全社的なポリシーを公表する必要があります。 また、このようなポリシーを公表することで、DBA の管理上の制御を高めることになり、ユーザーやデータ処理オペレーション担当者は、データベースに関する手順を理解しやすくなります。
このポリシーには、次のものが含まれます。
DBMS コマンドの使用 - DBMS が提供する各種機能を使用してよいのは誰か、誰が使用してはいけないか
データベース使用 - ユーザープログラムが行うのか、 標準インターフェイス（Natural や SQL など）を使用するのか、 どのようなエラー処理手順を使用するべきか、 問題点は誰にどのような形（例：トラブルレポート）で報告するか
保守および更新手順の責任の所在は誰にあるか
このポリシーは DBA が提案し、すべての関連部門に評価してもらい賛同を得る必要があります。
DBA と関連ユーザーだけがアクセスできるようにするため、ユーザー ID とパスワードに関する情報は、DBA が厳重に保管する必要があります。 このドキュメンテーションとしては、次のものがあります。
サイファキー、パスワードおよびユーザー ID の割り当て手順
サイファキー（DBA はこれを知っている必要がある）、パスワードおよびユーザー ID の実際の割り当て
端末およびデータアクセス手順
各データエンティティに対して、アクセス権を設定する必要があります。 次のことを定義します。
データ所在、データ内容を誰が知る権利があり、また知る必要があるか
誰がデータベースからデータを読むことができ、データに新オカレンスを追加でき、データの値を変更でき、またデータベースからデータを削除できるか
いったん、この権限が設定されたら、データベースセキュリティに違反しないように、適切な制御手順を設定しておくことが重要です。
データベースセキュリティ手順 次のようなデータベース内のデータの物理的保護を記録しておきます。
データベースに対する絶対的な人的制御（コミュニケーションルーム、コンピュータおよび端末へのアクセス、データベースバックアップやログテープの保管）
データエンティティの物理的な分離（ファイルの分離、データベースの分離、部分マウント機能とファイルクラスタ機能の使用）
端末の安全な領域の確保（ロック可能な端末、キーホルダー、専用回線またはダイヤルアップ回線、未使用時のオフライン化）
データベースに関して公表される情報を受け取る権限を有する人
パスワード保護を実装、制御するために、Adabas Security ユーティリティを使用します（詳細については、『Adabas Security Manual』を参照）。 DBA は、このユーティリティを使用できる唯一の担当者です。
DBA は、セキュリティユーティリティ自体、セキュリティに関する全ドキュメンテーションを物理的に保護するための手順を策定する必要があります。
バックアップファイル（Adabas の ADASAV ユーティリティで取得したデータベースまたはファイルのコピー）は、次の情報とともに記録する必要があります。
どのような状態でいつ取得したバックアップデータか
バックアップ可能なデータの識別
含まれるデータ量
データベースをある状態に再設定するのに使用すべきバックアップ機能
データベースバックアップオペレーションの頻度とスケジュール
DBA は、コンピュータオペレーション担当者と打ち合わせて、データベースのバックアップ作業の実行手順を定める必要があります。 データベースバックアップは、データベースが破壊されたり、損傷された場合に、データベースを適切な状態にリストアするために必要なステップです。 すべてのアプリケーションについて、データベース全体をバックアップするかファイルダンプ、リストアの方がよいかを決定する必要があります。
特定のアプリケーションに対してバックアップ手順を作成するときは、『Adabas オペレーションマニュアル』を参照してください。
DBA は次の手順を公式化し監督する責任があります。
障害後の DBMS の再スタート
必要なら最新のチェックポイントまでデータベースをリカバリすることで、データベース保守作業を繰り返す必要がなくなります。
データベース復元の優先度と順番の制御
再スタートとリカバリはデータベース保護の重要な問題であり、 DBA は保護機能を行う標準、手順および規則を設定する必要があります。 この標準や規則が守られるように監督します。 DBMS 導入時に、再スタートやリカバリについて考え設計しておかなければなりません。 後から考えるのでは遅過ぎます。
Adabas の再スタート／リカバリに関しての詳細は、『Adabas オペレーションマニュアル』を参照してください。
DBA はデータベースシステムのパフォーマンスを維持し、向上する役割を継続します。
これを行うため、DBA はシステムのパフォーマンスを監視し、パフォーマンスを改善するために、代りの設計方法を試さねばなりません。 企業内の業務パターンが変るとトランザクションタイプの量も相対比率も、両方とも変化する可能性があります。 したがってパフォーマンスにも影響し、これを防ぐのに設計変更が必要な場合もあります。
より長期に間、業務の負荷の変化を予測し、再設計や設備拡張によりこれらの変化に対応するよう計画を練ることは可能です。
新規ハードウェアやソフトウェアの効果も評価すべきであり、おこり得る変化はコストに見合っていなければならず、長期対策に盛り込むべきです。
DBMS のパフォーマンスの追跡（および計測）は、したがって DBA 機能の重要な部分です。 DBA は、次のような記録を取得し、維持すべきです。
使用するコンピュータリソース（アプリケーションごとの使用頻度も含む）
ある特定のアプリケーションのサービスをどのユーザーが受けるか
レスポンスタイムやコストに関する DBMS の効果
DBA は、また次のことを行うための手順を設定し、ドキュメントする必要があります。
DBMS の使用頻度のモニタリング
DBMS パフォーマンスの管理
データベースの完全性を維持し、かつ効果的サービスレベルを提供することを保証するため、データベース環境を継続してモニタするのは DBA の役割です。 このモニタリングの役割は、さまざまな活動や手順から構成され、パフォーマンスの管理もその 1 つです。
Adabas Online System は、データベースのモニタリングを行ううえで DBA の強力なツールとなります。 詳細については、Adabas Online System のマニュアルを参照してください。
