JP2768433B2 - 物理データベース設計システム - Google Patents
物理データベース設計システムInfo
- Publication number
- JP2768433B2 JP2768433B2 JP3028360A JP2836091A JP2768433B2 JP 2768433 B2 JP2768433 B2 JP 2768433B2 JP 3028360 A JP3028360 A JP 3028360A JP 2836091 A JP2836091 A JP 2836091A JP 2768433 B2 JP2768433 B2 JP 2768433B2
- Authority
- JP
- Japan
- Prior art keywords
- operations
- database
- data
- workload
- design
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/22—Indexing; Data structures therefor; Storage structures
- G06F16/2228—Indexing structures
- G06F16/2272—Management thereof
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99941—Database schema or data structure
- Y10S707/99943—Generating database or data structure, e.g. via user interface
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Stored Programmes (AREA)
- Devices For Executing Special Programs (AREA)
Description
【産業上の利用分野】本発明はデータベースの物理設計
に関する。
に関する。
【従来の技術】データベースシステムは、一般には、そ
れらの物理設計によって自らを最適化しない。つまり、
データベースシステムが、それらのデータ及びオペレー
ションの特別なレイアウト及び記憶特性を自動的に変化
させることはない。ほとんどのシステムはある特徴、即
ち、例えばデータレコードのためのインデックス若しく
はシーケンシャルキー、データ及びプログラムファイル
の予想サイズ、あるいはデータ及びプログラムファイル
の記憶位置の選択等の設定を、ユーザが指定できるとい
った特徴を有する。しかしながら、これらの及び他の特
性を適切に設定するには、一般のユーザは持たない特別
な専門知識を要する。それ故、データベースの専門家に
は、実行時間性能がより良好なものとなるようデータベ
ースの物理設計をよりよく調整することが常に要求され
る。例えば、専門家は、必要となる入力／出力（Ｉ／
Ｏ）数を減少させてメモリ内のデータをより実効的に記
憶することにより、より高いアプリケーションスループ
ット（つまり処理されるトランザクションが多数）とな
るよう改善することができる。これらの改善には、多数
のディスク全体にわたってデータを分割し、最適なデー
タ密度を計算し（つまり、各セクションのデータを含む
のに十分な大きさの記憶エリアを与え）、データファイ
ル内におけるデータの最適な位置を計算することによ
り、中央処理装置（ＣＰＵ）およびディスク記憶装置を
より実効的に利用可能にすることも含まれる。データベ
ースの物理構造を１つあるいは２つ以上のレコードとし
て記憶して、相互に関連したデータ集合の特別な記憶特
性として定義できることに注意すべきである。記憶され
たレコードが基本単位であり、これは１つの論理レコー
ドに対応し、全てのポインタ、レコード長、およびデー
タ部分を表すのに必要な他の識別子を含む。データベー
スの物理構造には、例えばファイルの位置や大きさ、デ
ータベースレコードへのアクセス方法およびキー、デー
タベース内でのレコードの位置が含まれる。驚くことで
はないが、物理構造の設計はデータベース全体の実効率
に重要な影響を持つ。しかしながら、この影響は（同一
の物理構造を有するデータベースの間においても）デー
タベース毎に異なる。例えば、性能に対する物理構造の
影響は、データベースのデータ量（つまり、「データボ
リューム」）に依存して変化する。この影響はまた、シ
ステムの「物理制約」、例えば利用可能な記憶デバイス
数、記憶デバイス上で利用可能なスペースの量、Ｉ／Ｏ
が占めるプレースの量、更に、利用可能なランダムアク
セスメモリ（ＲＡＭ）の量に依存して変化する。また、
この影響はデータベースの「ワークロード」、例えば、
タイプ、頻度、優先順位、データベースオペレーション
のシーケンスに依存して変化する。
れらの物理設計によって自らを最適化しない。つまり、
データベースシステムが、それらのデータ及びオペレー
ションの特別なレイアウト及び記憶特性を自動的に変化
させることはない。ほとんどのシステムはある特徴、即
ち、例えばデータレコードのためのインデックス若しく
はシーケンシャルキー、データ及びプログラムファイル
の予想サイズ、あるいはデータ及びプログラムファイル
の記憶位置の選択等の設定を、ユーザが指定できるとい
った特徴を有する。しかしながら、これらの及び他の特
性を適切に設定するには、一般のユーザは持たない特別
な専門知識を要する。それ故、データベースの専門家に
は、実行時間性能がより良好なものとなるようデータベ
ースの物理設計をよりよく調整することが常に要求され
る。例えば、専門家は、必要となる入力／出力（Ｉ／
Ｏ）数を減少させてメモリ内のデータをより実効的に記
憶することにより、より高いアプリケーションスループ
ット（つまり処理されるトランザクションが多数）とな
るよう改善することができる。これらの改善には、多数
のディスク全体にわたってデータを分割し、最適なデー
タ密度を計算し（つまり、各セクションのデータを含む
のに十分な大きさの記憶エリアを与え）、データファイ
ル内におけるデータの最適な位置を計算することによ
り、中央処理装置（ＣＰＵ）およびディスク記憶装置を
より実効的に利用可能にすることも含まれる。データベ
ースの物理構造を１つあるいは２つ以上のレコードとし
て記憶して、相互に関連したデータ集合の特別な記憶特
性として定義できることに注意すべきである。記憶され
たレコードが基本単位であり、これは１つの論理レコー
ドに対応し、全てのポインタ、レコード長、およびデー
タ部分を表すのに必要な他の識別子を含む。データベー
スの物理構造には、例えばファイルの位置や大きさ、デ
ータベースレコードへのアクセス方法およびキー、デー
タベース内でのレコードの位置が含まれる。驚くことで
はないが、物理構造の設計はデータベース全体の実効率
に重要な影響を持つ。しかしながら、この影響は（同一
の物理構造を有するデータベースの間においても）デー
タベース毎に異なる。例えば、性能に対する物理構造の
影響は、データベースのデータ量（つまり、「データボ
リューム」）に依存して変化する。この影響はまた、シ
ステムの「物理制約」、例えば利用可能な記憶デバイス
数、記憶デバイス上で利用可能なスペースの量、Ｉ／Ｏ
が占めるプレースの量、更に、利用可能なランダムアク
セスメモリ（ＲＡＭ）の量に依存して変化する。また、
この影響はデータベースの「ワークロード」、例えば、
タイプ、頻度、優先順位、データベースオペレーション
のシーケンスに依存して変化する。
【発明の概要】−般的に、本発明は物理データベース設
計装置を特徴とし、これは物理データベース設計を生成
するコンピュータソフトウエアで実行される。本発明
は、データベースにおけるデータの論理構成を表示する
論理スキーマから、前記データベースにデータをどのよ
うに記憶させるのかを特定するデータベースの物理設計
を生成するためのコンピュータシステムによって実行さ
れる方法であり、（ａ）前記コンピュータシステムが前
記論理スキーマを入力として受入れる段階と、（ｂ）前
記コンピュ−タシステムがデータベースのためのワーク
ロード定義を入力として受入れる段階と、但し、前記ワ
ークロードはデータベース上の複数のオペレーションを
含んでおり、前記複数のオペレーションは階層レベルに
配列されており、前記階層レベルの第１レベルにおける
オペレーションは前記レベルの第２レベルからの１つ若
しくは２つ以上のオペレーションを含んでおり、前記ワ
ークロード定義は前記第１レベルにおけるオペレーショ
ンに関する前記ワークロードの特性の明細と第２レベル
におけるオペレーションに関する前記ワークロードの特
性の別個の明細を含んでおり、（ｃ）前記コンピュータ
システムが、一組のエキスパートルールを検索し且つ選
択的に与えて、前記ワークロード定義に基づいて前記デ
ータベースの論理スキーマを前記データベースの前記物
理設計に変換する段階と、を含む。より好ましい実施例
において、設計装置によって発生される物理データベー
ス設計は、リレーショナルデータベースやコダシルデー
タベースであってもよい。この実施例の他の特徴は、設
計装置が、ワークロードの異なるオペレーションを階層
ワークロード制約を正規化することによってデータベー
ス上で比較することにあり、この結果、物理データベー
ス設計を作り出す際に複数のオペレーションを一様に取
り扱うことができる。また、ワークロード階層は、プロ
グラム、プログラム内のトランザクション、トランザク
ション内の要求といった少なくとも３つのレベルを含
む。第４のレベルとしてアプリケーションを設けること
も可能である。この第４レベルは、関連するプログラム
郡を示す。以下に述べる実施例において、ワークロード
定義に含まれる情報には、階層の異なるレベルにおける
オペレーションの重要度、階層の異なるレベルにおける
オペレーションの頻度、トランザクションのアクセスモ
ードおよびロックモードが含まれる。他のタイプの情報
も同様に記憶することができる。最後に、設計装置によ
って発生され改善された物理データベース設計の１つの
要素にレコードプレースメント定義がある。レコード定
義とは、つまり、ワークロードや他の入力に基づくデー
タにとって特に実効的な記憶レイアウトのことである。
設計装置は、入力として例えば以下のものを使用するこ
とができる。（ａ）データベースのためのボリューム定
義。このボリューム定義は揮発性のようなオペレーショ
ンのオカレンス数、オカレンスの最少数および最大数に
関する情報を含む。（ｂ）データベースのための物理制
約定義。この物理制約定義は、データベースに利用可能
なメインメモリのサイズ、データベースのレコードが記
憶されるディスクメモリのサイズ、およびデータベース
のオカレンスユーザの最大数を含む。本発明は、データ
ベースの物理構造の設計を自動化したものであり、本発
明によれば、ユーザはデータベースやそれを用いるあら
ゆるアプリケーションの実効性を改善することができ
る。このため、本発明のシステムは、データボリュー
ム、物理制約、データベースのワークロードに関する情
報を、データベースの物理構造に設計に適用する。デー
タボリュームと物理制約についての情報は、手であるい
は様々なデータベースダンプからの入力によって発生す
ることができる。同様に、ワークロード分析は、手であ
るいは本明細書に組み入れられた本発明と同日に出願さ
れたＰｈｉｌｉｐ Ｋ．Ｒｏｙａｌ によるＳＹＳＴＥ
Ｍ ＡＮＤＭＥＴＨＯＤ ＦＯＲ ＡＰＰＬＩＣＡＴＩ
ＯＮ ＥＶＥＮＴ ＣＯＬＬＥＣＴＩＯＮに述べられて
いるアプリケーションイベントベースコレクタによって
発生することができる。本発明は、記憶スペースを実効
的に使用し、利用可能な記憶スペース全体に渡ってデー
タを分割し、データベースオペレーションのＩ／Ｏオー
バヘッドを減少させるようなデータベースを設計するた
めに使用され得る。例えば、もしワークロード分析によ
り、２つの特定のオブジェクト（つまりデータの一部）
上のオペレーションが連続して度々発生していることが
示されている場合には、それらのオブジェクトへのアク
セスに必要なＩ／Ｏオペレーション数を最少にするた
め、それらのオブジェクトが記憶デバイス上で互いに近
接して配置されるよう指示する。更にシステムは、デー
タベースのワークロードに従ってデータを大きさ順に並
べることもでき、どのようにして「クラスタ」、即ちデ
ータベースファイル内の集合に並べるかを表示する。つ
まり、このシステムは、関連するレコードタイプ、例え
ば、特別なデータベースリクエスト若しくはトランザク
ションによって処理される全てのレコードを、データベ
ースの同一エリアに記憶する。この技術は、応答時間を
遅延させるディスクヘッドの余計な動きを防止するもの
となる。
計装置を特徴とし、これは物理データベース設計を生成
するコンピュータソフトウエアで実行される。本発明
は、データベースにおけるデータの論理構成を表示する
論理スキーマから、前記データベースにデータをどのよ
うに記憶させるのかを特定するデータベースの物理設計
を生成するためのコンピュータシステムによって実行さ
れる方法であり、（ａ）前記コンピュータシステムが前
記論理スキーマを入力として受入れる段階と、（ｂ）前
記コンピュ−タシステムがデータベースのためのワーク
ロード定義を入力として受入れる段階と、但し、前記ワ
ークロードはデータベース上の複数のオペレーションを
含んでおり、前記複数のオペレーションは階層レベルに
配列されており、前記階層レベルの第１レベルにおける
オペレーションは前記レベルの第２レベルからの１つ若
しくは２つ以上のオペレーションを含んでおり、前記ワ
ークロード定義は前記第１レベルにおけるオペレーショ
ンに関する前記ワークロードの特性の明細と第２レベル
におけるオペレーションに関する前記ワークロードの特
性の別個の明細を含んでおり、（ｃ）前記コンピュータ
システムが、一組のエキスパートルールを検索し且つ選
択的に与えて、前記ワークロード定義に基づいて前記デ
ータベースの論理スキーマを前記データベースの前記物
理設計に変換する段階と、を含む。より好ましい実施例
において、設計装置によって発生される物理データベー
ス設計は、リレーショナルデータベースやコダシルデー
タベースであってもよい。この実施例の他の特徴は、設
計装置が、ワークロードの異なるオペレーションを階層
ワークロード制約を正規化することによってデータベー
ス上で比較することにあり、この結果、物理データベー
ス設計を作り出す際に複数のオペレーションを一様に取
り扱うことができる。また、ワークロード階層は、プロ
グラム、プログラム内のトランザクション、トランザク
ション内の要求といった少なくとも３つのレベルを含
む。第４のレベルとしてアプリケーションを設けること
も可能である。この第４レベルは、関連するプログラム
郡を示す。以下に述べる実施例において、ワークロード
定義に含まれる情報には、階層の異なるレベルにおける
オペレーションの重要度、階層の異なるレベルにおける
オペレーションの頻度、トランザクションのアクセスモ
ードおよびロックモードが含まれる。他のタイプの情報
も同様に記憶することができる。最後に、設計装置によ
って発生され改善された物理データベース設計の１つの
要素にレコードプレースメント定義がある。レコード定
義とは、つまり、ワークロードや他の入力に基づくデー
タにとって特に実効的な記憶レイアウトのことである。
設計装置は、入力として例えば以下のものを使用するこ
とができる。（ａ）データベースのためのボリューム定
義。このボリューム定義は揮発性のようなオペレーショ
ンのオカレンス数、オカレンスの最少数および最大数に
関する情報を含む。（ｂ）データベースのための物理制
約定義。この物理制約定義は、データベースに利用可能
なメインメモリのサイズ、データベースのレコードが記
憶されるディスクメモリのサイズ、およびデータベース
のオカレンスユーザの最大数を含む。本発明は、データ
ベースの物理構造の設計を自動化したものであり、本発
明によれば、ユーザはデータベースやそれを用いるあら
ゆるアプリケーションの実効性を改善することができ
る。このため、本発明のシステムは、データボリュー
ム、物理制約、データベースのワークロードに関する情
報を、データベースの物理構造に設計に適用する。デー
タボリュームと物理制約についての情報は、手であるい
は様々なデータベースダンプからの入力によって発生す
ることができる。同様に、ワークロード分析は、手であ
るいは本明細書に組み入れられた本発明と同日に出願さ
れたＰｈｉｌｉｐ Ｋ．Ｒｏｙａｌ によるＳＹＳＴＥ
Ｍ ＡＮＤＭＥＴＨＯＤ ＦＯＲ ＡＰＰＬＩＣＡＴＩ
ＯＮ ＥＶＥＮＴ ＣＯＬＬＥＣＴＩＯＮに述べられて
いるアプリケーションイベントベースコレクタによって
発生することができる。本発明は、記憶スペースを実効
的に使用し、利用可能な記憶スペース全体に渡ってデー
タを分割し、データベースオペレーションのＩ／Ｏオー
バヘッドを減少させるようなデータベースを設計するた
めに使用され得る。例えば、もしワークロード分析によ
り、２つの特定のオブジェクト（つまりデータの一部）
上のオペレーションが連続して度々発生していることが
示されている場合には、それらのオブジェクトへのアク
セスに必要なＩ／Ｏオペレーション数を最少にするた
め、それらのオブジェクトが記憶デバイス上で互いに近
接して配置されるよう指示する。更にシステムは、デー
タベースのワークロードに従ってデータを大きさ順に並
べることもでき、どのようにして「クラスタ」、即ちデ
ータベースファイル内の集合に並べるかを表示する。つ
まり、このシステムは、関連するレコードタイプ、例え
ば、特別なデータベースリクエスト若しくはトランザク
ションによって処理される全てのレコードを、データベ
ースの同一エリアに記憶する。この技術は、応答時間を
遅延させるディスクヘッドの余計な動きを防止するもの
となる。
論理スキーマは、データベースの構造やその要素が互い
にどのように関連しているのかを論理的に表現する。以
下に述べる例は、表の形態で構成されたデータを有する
「リレーショナルデータベース」を仮定する。テーブル
の行はデータの事例を含み、列は同様の属性を持つデー
タの関係を表す。図１の論理スキーマ１４は、データエ
ンティティが関連するレコード及びフィールド構造を定
義するものと考えることが出来る。人事データベースの
論理スキーマ１４の例が表１に示されている。表に示さ
れているように、スキーマは、多数のテーブル、つま
り、ＣＯＬＬＥＧＥＳ、ＤＥＧＲＥＥＳ、ＤＥＰＡＲＴ
ＭＥＮＴＳ、ＥＭＰＬＯＹＥＥＳ、ＪＯＢＳ、ＪＯＢ．
ＨＩＳＴＯＲＹ、ＲＥＳＵＭＥＳ、ＳＡＬＡＲＹ．ＨＩ
ＳＴＯＲＹ、及びＷＯＲＫ．ＳＴＡＴＵＳを含む。各テ
ーブルをレコードデータ構造の定義として考えることが
出来る。各テーブルはまた、多数の列要素を持ってお
り、これらの列要素をレコード内の領域として考えるこ
とが出来る。例えば、ＣＯＬＬＥＧＥＳテーブルは、そ
れらの列要素であるＣＯＬＬＥＧＥ．ＣＯＤＥ、ＣＯＬ
ＬＥＧＥ．ＮＡＭＥ、ＣＩＴＹ、ＳＴＡＴＥ、及びＰＯ
ＳＴＡＬコードを含む。各列要素はそのデータタイプ、
例えば文字、整数、あるいはデータといったデータタイ
プに関連している。列要素の下で「行」を満たすデータ
エンティティを後にそれらのデータタイプによって関連
させることも出来るが、複数のテーブルにそれらが出現
するということによって互いを関連付けることも出来
る。例えば、ＣＯＬＬＥＧＥ．ＣＯＤＥ列要素は、ＣＯ
ＬＬＥＧＥテーブルと、ＤＥＧＲＥＥＳテーブルに現れ
ている。 デーダベースワークロード２２は、上に示したテーブル
や列のデータエンティティで実行されるデータベースト
ランザクションを定義するものであり、人事データベー
スのためのワークロードの例と関連させて以下に記述す
る。 〔データベースワークロードの構造〕 ワークロードは、データベースの操作中にシステムリソ
ースを特定するパラメータである。ワークロードオペレ
ーションの階層構造を表２に示す。例えば表２に例とし
て示されているデータベースワークロード定義２２は、
論理スキーマ１４で定義されたテーブルや列要素のデー
タエンティティにおいて予想されるデータベースオペレ
ーションを記述する。ワークロード２２には、論理スキ
ーマ１４上のオペレーション（つまり、アプリケーショ
ン、プログラム、トランザクション、及びリクエスト）
が階層形態で配列されている。即ち、アプリケーション
は１つまたはそれ以上のプログラムを含み、プログラム
は１つまたはそれ以上のトランザクションを含み、そし
てトランザクションは１つまたはそれ以上のリクエスト
を含む。さらに詳細に言えば、ワークロード２２は、こ
の階層構造において、論理スキーマ１４のどのテーブル
がアクセスされるか、それらのテーブルがどのようにア
クセスされるか（アクセスモード、ロックモード、及び
オペレーション）、どの位の頻度でアクセスされるか
（頻度及びサイクル）、オペレーションを出来るだけ短
時間に達成することがどの位重要であるか（重要度）を
定義する。例えばアクセスモードには、ＲＥＡＤ、ＷＲ
ＩＴＥ、ＵＰＤＡＴＥが含まれ、ロックモードには、Ｓ
ＨＡＲＥＤ、ＥＸＣＬＵＳＩＶＥ、ＰＲＯＴＥＣＴＥＤ
が含まれる。 テーブル内のデータエンティティへのアクセスは、幾つ
かの状態によって定義される。第１に、アクセスモード
ステートメントは、特定の列要素が例えばＲＥＡＤ、Ｗ
ＲＩＴＥ、あるいはＵＰＤＡＴＥオペレーションのオブ
ジェクトであるといったオペレーションタイプを定義す
る。第２に、ロックモードステートメントは、データエ
ンティティを１つ以上のオペレーションによって同時に
アクセスできるかどうか、例えば、列要素がＳＨＡＲＥ
Ｄ、ＥＸＣＬＵＳＩＶＥＶ、あるいはＰＲＯＴＥＣＴＥ
Ｄアクセスを許すかどうかを定義する。例えば、上で示
されたＥＭＰＬＯＹＥＥＳテーブル内のデータエンティ
ティは、ＣＨＥＣＨ．ＤＥＰＴ．ＩＮＦＯトランザクシ
ョンによってアクセスされる。このトランザクション
は、テーブル上のオペレーションのための全てのリクエ
ストをＲＥＡＤ ＯＮＬＹ及びＳＨＡＲＥＤとして定義
する。最後に、テーブル内のデータエンティティを常に
アクセスする列要素がリクエスト内で特定される。例え
ば、表２に示されたリクエストＤＥＰＴＣＯＤＥ．１内
で、テーブルＤＥＰＡＲＴＭＥＮＴＳはＤＥＰＡＥＴＭ
ＥＮＴ．ＣＯＤＥ列要素によってアクセスされる。ワー
クロード特性は、時間（時間、日、週、年等）サイクル
毎のシステムリソースの必要性を決定する。テーブルへ
のアクセス頻度は、テーブル内のデータエンティティが
特定のサイクル時間内にアクセスされる回数、つまり、
時間、日、週、月、３ケ月、１年ごとの回数によって定
義される。もしテーブルが常に特定の列要素によってア
クセスされている場合には、その要素を経由するアクセ
スの頻度は１のサイクル内においてとても高いものとな
る。例えばＥＭＰＬＯＹＥＥＳテーブルは、ＥＭＰＬＯ
ＹＥＥ．ＩＤ列要素によって１日に５０回あるいは１０
０回アクセスされる。一方、もしテーブルが異なる列要
素の内容によってでたらめにアクセスされる場合には、
アクセスの頻度は１のサイクル内においてとても低いも
のとなる。例えば、ＥＭＰＬＯＹＥＥテーブルは、ＡＤ
ＤＲＥＳＳ．ＤＡＴＡ．１列要素によって週にたった１
度だけアクセスされるかもしれない。アプリケーショ
ン、プログラムあるいはトランザクションの重要度は１
から１０までの大きさの等級であり、それは、その動作
が出来るだけ短時間で達成されることがどの位重要であ
るかに対応する。例えば、アプリケーションはかなり重
要なものと考えられのでスコア８という等級をつけてお
り、一方、アプリケーション内のプログラムはとても重
要なものであるかもしれないのでスコア１０という等級
をつけている。幾つかの特定のケースにおいては、ラン
キングが互いに衝突するかもしれないと思われる。例え
ば、従業員の電話番号を調べ、しかも１日に何度も実行
されるようなトランザクションは、週に１度の給料の支
払いのために従業員のアドレスを調べるトランザクショ
ンよりより等級が上であるとはじめは思うかもしれな
い。しかしながら、給料支払いは、他のトランザクショ
ンより等級が勝るものであると考えられるからより高い
等級を付けることが必要である。一般に、重要度の等級
付けは、最後の記憶スキーマ３８、例えばスキーマ内の
臨界アクセスパスの幾つかの細部を決定する。このよう
に、各アプリケーション、プログラム、トランザクショ
ンのための重要度を注意深く選択することにより、ユー
ザはどのようなデータベースが最適であるかということ
を見きわめるワークロード２２を作り出すことが出来
る。なお、「臨界アクセスパス」という用語は、データ
ベースのうち頻繁に使用されることがある部分へ運航す
るために頻繁に使用されることがあるルートを意味す
る。臨界アクセスパスに沿った処理段階やデータ構造は
最適化を行なうのに重要であり、これにより、データベ
ースの操作中にリソース要求（コスト）を減少させるこ
とができる。論理スキーマ上のオペレーションの各タイ
プ、つまり、アプリケーション、プログラム、トランザ
クションおよびリクエストについて以下に記述する。ア
プケーションは、個別のビジネス機能を実行するプログ
ラムの集合である。例えば、上の表２に示された「ＥＭ
ＰＬＯＹＥＥＳ」アプリケーションは、「ＪＯＢＩＮＦ
Ｏ．」のような個々のプログラムを通じて従業員につい
ての情報を検索したり、更新したりする。アプリケーシ
ョンは一般に、アクセスモード、ロックモード、頻度あ
るいはサイクルによっては定義されないことに注意して
もらいたい。なぜなら、それらは関連したプログラムを
集合化するためだけのものだからである。しかしなが
ら、アプリケーションの重要度はアプリケーション内の
プログラムの重要度の関数として特に定義されている。
例えば、ＥＭＰＬＯＹＥＥＳアプリケーションは８とい
う等級を付けられている。次に、プログラム、例えばＪ
ＯＢＩＮＦＯは、特定の機能あるいはタスクを実行して
いるトランザクションの集合である。ワークロード２２
は、実行可能なイメージあるいはデータベースにアクセ
スするコマンド手続き、例えばアプリケーションプログ
ラム、ＶＡＸデータトライブ（Ｄａｔａｔｒｉｅｖ
ｅ）、ＳＱＬ、あるいはＤＢＱ手続き個々のために、別
個の手続きを定義する。各アプリケーションにおいて、
各プログラムのための、頻度、サイクル及び、重要度が
定義される。例えばＪＯＢＩＮＦＯプログラムのサイク
ルは、ＤＡＩＬＹとして定義される。これは、頻度８
０．００、重要度１０である。次に、トランザクション
は、データベース活動を回復することが出来る装置であ
る。例えばＪＯＢＩＮＦＯは、ＣＨＥＣＫ．ＤＥＰＴ．
ＩＮＦＯ、ＣＨＥＣＫ．ＥＭＰＬＯＹＥＥＳ．ＥＸＩＳ
ＴＥＮＣＥ及びＣＨＥＣＫ．ＪＯＢ．ＩＮＦＯを含む。
ＣＨＥＣＫ．ＤＥＰＴ．ＩＮＦＯトランザクションのた
めのアクセスモードはＲＥＡＤ ＯＮＬＹ、ロックモー
ドはＳＨＡＲＥＤ、頻度は１．００、そして重要度は１
０と定義されている。全てのトランザクションが同一の
サイクル、つまりプログラムの１実行、を有していると
いうことに注意してもらいたい。最後に、各トランザク
ションはリクエスト、つまり単一のデータベースアクセ
スの集合である。各アクセスはＳＱＬあるいはＤＭＬの
ようなデータベース言語で書かれている。例えば、表２
を再び参照すれば、ＣＨＥＣＫ．ＤＥＰＴ．ＩＮＦＯト
ランザクション内の第１のリクエストは、ＳＱＬステー
トメント「ＳＥＬＥＣＴ ｃｏｌｕｍｎ．ｌｉｓｔ Ｆ
ＲＯＭ ＤＥＰＡＥＴＭＥＮＴＳ ＷＨＥＲＥ ＤＥＰ
ＡＲＴＭＥＭＴ．ＣＯＤＥ＝”ｌｉｔｅｒａｌ”ＡＮＤ
ＪＯＢ．ＥＮＤ＞”ｌｉｔｅｒａｌ”」によって定義
された「ＤＥＰＴＣＯＤＥ．１」リクエストである。上
のように定義されたワークロード定義２２は、物理デー
タベース３６に入力され、そして最適な物理設計を作り
出すため、エキスパートシステムにより分析される。ワ
ークロード２２上のエキスパートシステムによってなさ
れる分析について、以下に述べる。ワークロード２２の
分析及び特徴は、全ての設計入力が一度は受ける設計処
理の第１段階である。この分析には、処理サイクルに基
づく頻度をアニュアライズし、トランザクション及びリ
クエストのために頻度を正規化し、各リクエストのため
に絶対的な重要度を作り出すという段階が含まれる。物
理データベース設計装置３６内のエキスパートシステム
は、改善されたデータベース設計、つまり最後の記憶構
造３８の細部を決定するため、ワークロードデータ上の
幾つかのオペレーションを実行するモジュールＫＢ．Ａ
ＮＡＬＹＳＩＳを含む。第１に、ＫＢ．ＡＮＡＬＹＳＩ
Ｓは、ワークロード定義２２内の各リクエストの発生を
「アニュアライズ」する。即ち、それは、サイクル毎の
発生回数を、１年毎の発生回数に換算するのである。例
えば、もしサイクルが時間的なものであれば、ＫＢ．Ａ
ＮＡＬＹＳＩＳはその発生回数に、一日毎の時間、一週
毎の日、月毎の週、３月毎の年を掛け算することによっ
てアニュアライズする。第２に、ＫＢ．ＡＮＡＬＹＳＩ
Ｓは実行カウントが正確に比較されるように、トランザ
クション及びリクエストの発生回数を「アニュアライ
ズ」する。これを行うため、ＫＢ．ＡＮＡＬＹＳＩＳは
まず、トランザクションの実行カウントにプログラムの
実行カウントを掛け算することによってトランザクショ
ンの絶対カウントを更新し、そうしてその結果をトラン
ザクションの絶対カウントに割り当てる。その後ＫＢ．
ＡＮＡＬＹＳＩＳはトランザクションの絶対カウントに
リクエストの実行カウントを掛け算することによってリ
クエストの絶対数を更新し、そうしてその結果をリクエ
ストの絶対数に割り当てる。第３に、ＫＢ．ＡＮＡＬＹ
ＳＩＳはワークロード内の全てのリクエストの等級付け
が正確に比較されるよう、リクエストの重要度の等級付
けを正規化する。即ち、各リクエストの重要度が、リク
エストが発生するアプリケーション、プログラム、それ
にトランザクションの重要度に基づいて計算される。各
リクエストの重要度を相対的に計算するため、ＫＢ．Ａ
ＮＡＬＹＳＩＳＨＡ以下のアルゴリズムを使用する。 リクエスト重要度＝リクエスト絶対頻度／ （重要度高バウンド−リクエスト重要度）２ ここで、重要度高バウンド＝アプリケーションマルチプライア＋ プログラムマルチプライア＋ トランザクションマルチプライア＋ リクエストマルチプライア＋１ リクエスト重要度＝アプリケーション重要度 ＊アプリケーションマルチプライア＋ プログラム重要度＊プログラム重要度＋ トランザクション重要度＊トランザクションマルチプライア＋ リクエスト重要度＊リクエストマルチプライア ここでは、いづれのマルチプライアも、 マルチプライア＝１０＊＊（レベル−１）である。 例えば、 アプリケーションマルチプライア＝１０＊＊３＝１０００ プログラムマルチプライア ＝１０＊＊２＝１００ トランザクションマルチプライア＝１０＊＊１＝１０ リクエストマルチプライア ＝１０＊＊０＝１ である。最後に、ＫＢ．ＡＮＡＬＹＳＩＳは、ワークロ
ード定義２２の全てのトランザクションのリクエスト
を、各データエンティテイへの１つのアクセスパス中
へ、ワークロードで定義されたあらゆるアクセスのタイ
プのために結合する。これを行うため、ＫＢ．ＡＮＡＬ
ＹＳＩＳは、全てのリクエストを特別な順序で、例えば
そのソート順の各「ブレイク」によって、つまりｄｅｓ
ｉｇｎ、ｒｅｔｒｉｅｖａｌ．ｍｏｄｅ、ｖｅｒｂ、ａ
ｄｖｅｒｂ、ｏｂｊｅｃｔ、ｓｅｌｅｃｔ．ｔｙｐｅあ
るいはｓｅｌｅｃｔ．ｏｂｊｅｃｔによってソートす
る。ＫＢ．ＡＮＡＬＹＳＩＳはまた、ソート順の各ブレ
イクにおいて重要度を総計する。 〔データボリューム定義の構造〕 リレーショナルデータベースでは、データのリクエスト
は一般に「質問」と呼ばれており、例えばＳＱＬ質問
（例えば標準質問言語）がある。質問、即ちリクエスト
は、検索データが現れる順序を決定するような要素を含
む。異なる要素はサブ順序を含んでもよい。順序及びサ
ブ順序における変更は、一般に、「ブレイク」と呼ばれ
る。ソートブレイクを生じさせることがある。リクエス
トの要素は、リクエストされたデータがどのように選定
されるのかを特定するのに用いるｖｅｒｂ、ａｄｖｅｒ
ｂ（ｖｅｒｂの変形）、ｏｂｊｅｃｔ（データの事例
（リレーショナルテーブルの行））を含むことができ
る。図１のデータボリューム定義２８は、データベース
内のデータ量を記述する。システム１０は、例えばサイ
ズやファイル内のデータベースファイル、エリアの数を
最適化するため、幾つかの方法でこの情報を使用する。
詳しく言えば、データボリュームは、テーブル及び要素
の揮発性と同様に、各テーブル及び列要素の発生の、最
低数、平均数、それに最大数として定義されている。例
えば、従業員データベースは会社の全ての従業員のため
に、１つのＥＭＰＬＯＹＥＥＳテーブルを含むであろ
う。故にＥＭＰＬＯＹＥＥＳテーブル内のデータエンテ
ィティの発生の最少数は従業員数に等しくなる。しかし
ながら、時間が立つと従業員数は変化し得る。この変化
は、ＥＭＰＬＯＹＥＥＳテーブル内のデータエンティテ
ィの発生の平均と最大数で説明される。例えば、もし会
社が従業員の数を２倍にしようと思えば、ＥＭＰＬＯＹ
ＥＥＳテーブル内のデータエンティティの平均及び最大
数がデータボリューム限定内で増加される。更に、少数
のデータベースは静的データ、つまり変化しないデー
タ、を含むので、ユーザはそのシステムに、１から１０
（１というのは安定しているということであり１０とい
うのは変わりやすいということ）までの大きさで、各テ
ーブル及び列要素の揮発性に等級付けすることが出来
る。例えば、ＥＭＰＬＯＹＥＥＳテーブル内のデータエ
ンティティの数は、例えば加算や減算を多量に受ける
と、いくらか変わり得るものであり、８という等級が付
けられている。一方、例えばＣＯＬＬＥＧＥＳテーブル
内のエンティティの数はかなり安定したものであり、２
という等級が付けられている。もしテーブル内のエンテ
ィティ数がデータベース内の他のエンティティの数より
も多かれ少なかれ変化しやすいものである場合には、そ
のテーブルあるいは列要素は一般に揮発性５という等級
が割り当てられる。以下の表３には、人事データベース
のためのボリューム定義の例が示されている。全部の限
定に０オカレンスというデフォルト値と中間範囲の揮発
性である５という等級が割り当てられている。同様に、
各テーブル及び列エントリには、テーブルあるいは列内
のエンティティのオカレンス数を示すための値とその揮
発性が割り当てられている。例えば、ＣＯＬＬＥＧＳテ
ーブル内のデータエンティティのオカレンス数は、１６
という最小値、平均値、最大値と、５という揮発性を有
している。ボリューム事例は、データベースの論理スキ
ーマで定義された各テーブルに対する個々のボリューム
定義（表３）にすぎない。ボリューム定義は一般に、デ
ータ量の最小、平均、最大を記述し、また、データベー
スの各テーブル（行及び列）のデータの揮発性を記述し
ている。 物理データベース設計装置３６への最後の入力、つまり
設計制約定義３４について以下に述べる。 〔設計制約の構造〕 図１の設計制約定義３４は、データベースで使用される
物理リソース上の制約を記述しており、記憶スキーマ３
８を作り出すために使用される。詳しく言えば、これら
の制約はデータベースを一度にアクセスすることができ
るユーザの最大数、データベースに関連するファイルを
記憶するために利用可能な記憶デバイスの数、どのデバ
イスであっても利用することができるスペースの最大
量、データベースを使用しているアプリケーションが利
用可能なメモリの最大量（おおざっぱに言えば、フリー
メモリの量の半分）、更に、アプリケーションによって
使用されるべき利用可能メモリのパーセンテージ、を含
む。例えば、もしシステムメモリの２／３がデータベー
スアプリケーションによって使用され得るのであれば、
利用可能メモリは６７％である。例として、以下の表４
に、人事データベースのための設計制約定義を示す。記
憶デバイス、つまりディスクの数は１０であり、５０人
のユーザにディスク記憶の１００，０００ブロックを与
える。アプリケーションが利用可能な最大量は６４メガ
バイトであり、そのアプリケーションは利用可能メモリ
の９６パーセントを実際に使用する。 〔動作：物理データベース設計装置〕 図２は、設計入力、つまり論理スキーマ１４、ワークロ
ード２２、制約３４及び、データボリューム２８のエン
ター段階を示す。第１に、物理データベース設計装置３
６は、その作業結果を記憶する物理設計を作り出す。こ
のプロセスを開始するため、設計装置３６は論理スキー
マ１４とワークロード２２のファイルネームを入力する
ようユーザに要求し、設計プロセス（段階１００）への
入力として使用する。次に、設計装置３６は論理スキー
マ１４の事例を生成し（段階１０２）、そのスキーマが
ユニークであるか、つまり同一の論理スキーマの事例が
存在せずその物理設計独自の論理スキーマであるか調査
する（段階１０４）。もしスキーマ１４がユニークでな
ければ、設計装置３６はエラーを返す（段階１０６）。
そうでなければ、つまりスキーマがユニークであれば、
デザイナー３６はスキーマ内の各テーブル及び列要素の
ために事例を作る（段階１０８）。次の処理フェーズ
で、設計装置３６は論理スキーマの各テーブル及び列要
素に対するボリューム事例を作り出す（段階１１２）。
設計装置３６は次に、ワークロード２２の事例を生成し
（段階１１４）、そのワークロードがユニークかどう
か、つまりその物理設計独自のワークロードであるかを
チェックする（段階１１６）。もしワークロード２２が
ユニークでなければ、設計装置３６はエラーを返す（段
階１１８）。さもなければ、つまりワークロード２２が
ユニークであれば、設計装置３６はワークロード２２の
各リクエスト、トランザクション、プログラム及び、ア
プリケーションに対する事例を作り出す（段階１２
０）。最後に設計装置３６は論理スキーマのためのテー
ブル及び列要素の事例に対する各リクエスト事例を確認
し、ユーザに不一致を解決するよう指示する（段階１２
２）。今まで設計装置３６への入力について述べてきた
が、次に設計装置３６からの出力について述べる。 〔実行時間パラメータ及び創作パラメータの構造〕 図１の実行時間パラメーター４２及び、創作パラメータ
ー４４は、コマンド手続き、例えば一連のデジタルコマ
ンド言語（ＤＣＬ）コマンドに含まれる。即ち、コマン
ド手続きが実行されたときに現存のデータベースからデ
ータエンティティをアンロードし、データベースの物理
設計を最適化し、そしてデータエンティティを最適化さ
れた設計で構成された新しいデータベース中へ再びロー
ドする。以下の表５は、人事データベースを最適化する
ために使用されるコマンド手続きのファイル例を示して
いる。詳細に言えば、表５（添付書類Ｂ）に示されたコ
マンド手続きは、最適化処理に関する情報をユーザに提
供し、プロセスの様々な段階への入力をユーザが変える
ことを保証しかつ許可する。例えば、データベースが互
いに依存するデータエンティティテーブルを有している
場合、つまり、それらに重複したレコードがあれば、そ
の手続きはユーザに対してロードシーケンスを編集し、
テーブルが適当な順序でロードするよう指示を出す。次
に、手続きは、新たなデータベースを実行するのに必要
なもの、例えば、論理スキーマや現存のデータベースの
テーブルで発見されたデータを一時記憶するのに十分な
スペースをユーザに命令する。最後に、手続きは、デー
タエンティティの記憶がどの様に最適化されるかを知ら
せその最適化を変える機会をユーザに与える。データベ
ースの変更方法に関する記述が、手続きによってユーザ
に一旦付与されると、手続きは現存のデータベースから
データエンティティをアンロードしていく。データエン
ティティがアンロードされた後、記憶スキーマ３８によ
る記憶エリアを生成し、テーブルの記憶マップ、つま
り、データベースのエリアへのテーブルのマッピングを
作る。一旦新たなデータベースが完成されると、古いデ
ータベースからのアンロードされたデータエンティティ
をソートし、ソートされたそれらのデータエンティティ
を新たなデータベースへロードする。実行時間パラメー
タ４２や創作パラメータ４４のコマンド手続きに続く処
理が、更に様々な文章レポートで証明され得る。 〔動作：物理データベース設計装置による設計の生成〕 図３は、設計装置３６に関連するエキスパートシステム
が最適な物理設計を発生するために用いる段階を示すフ
ローチャートである。第１に、設計装置３６は、各デー
タエンティティへのアクセスエントリを決定するため、
アプリケーション、プログラム、トランザクション及
び、リクエストを分析する（段階３０２）。各データエ
ンティティに必要なフェーズを分析した後、設定装置３
６は次にトランザクション及びプログラム内の各リクエ
ストのための重要度を検索し（段階３０４）、そして各
データエンティティへの臨界アクセスを決定する（段階
３０６）。次の処理フェーズで、設計装置３６は臨界ア
クセス方法エンティティを分析し、各データエンティテ
ィに対して所望のアクセスモードとアクセスフィールド
を決定する（段階３０８）。この分析が完了すると、設
計装置３６はその後、個々のユニーク臨界アクセス及び
データエンティティ結合に対するアクセス方法事例を生
成する（段階３１０）。段階３１０の後、設計装置３６
は各データエンティティに対するプレースメント事例を
決定するため臨界アクセスエントリを分析する（段階３
１２）。設計装置はまた、データエンティティ間の相互
関係を決定するために、トランザクション事例（リレー
ショナルデータベースのため）、あるいはリレーション
シップ事例（コダシルデータベースのため）、及びリク
エスト事例を分析する（段階３１４）。一旦分析が完了
すると、設計装置３６は相互に関係したデータエンティ
ティに対するクラスタを生成する（段階３１６）。その
後、最後の処理フェーズにおいて、設計装置３６は記憶
エリア及び記憶マップへのエンティティマップを決定す
るため、クラスタを分析し、記憶エリア、記憶マップ、
記憶分割及び、記憶インデックスの事例を作り出す（段
階３２０）。一旦事例が作り出されると、設計装置３６
はアクセス方法を用いて記憶インデックスを決定し（段
階３２２）、また記憶エリアと記憶マップを決定するた
めクラスタとプレースメントを使用する（段階３２
４）。最後に設計装置３６は、記憶分割を決定するよう
ユーザに指示を出し（段階３２６）、ボリューム、リク
エスト、クラスタ、記憶マップ実例を使用してロードシ
ーケンス事例を作り出す（段階３２８）。 〔動作：物理データベースによる設計の出力〕 図４は、論理スキーマ４０、記憶スキーマ３８及び、創
作パラメータ４４及び実行時間パラメータ４２を作り出
す段階を示すフローチャートである。第１に、設計装置
３６は新しい論理スキーマ４０を作り出す。このため、
設計装置は、論理スキーマ、データエンティティ、属性
及び関連事例にアクセスし、モデル特定データ定義言語
（ｍｏｄｅｌ ｓｐｅｃｉｆｉｃ Ｄａｔａ Ｄｅｆｉ
ｎｉｔｉｏｎ Ｌａｎｇｕａｇｅ）（ＤＤＬ）を作り出
す（段階４００）。第２に、設計装置３６は記憶スキー
マ３８を作り出す。このため、設計装置３６は、レコー
ドフォマット、記憶スキーマ、記憶エリア、記憶マッ
プ、記憶インデックス、及び記憶分割事例にアクセス
し、モデル特定ＤＤＬファイルを作り出す（段階４０
２）。第３に、設計装置３６は創作パラメータ４４を作
り出す。このため、設計装置３６は、記憶エリア、実施
品、及び設計制約の事例にアクセスし、モデル特定創作
コマンドを作り出す（段階４０４）。第４に、設計装置
は実行時間パラメータ４２を作り出す。このため、設計
装置３６は、実行プロダクト、設計制約、記憶エリア及
び、記憶マップの実例にアクセスし、モデル特定実行時
間コマンドを作り出す（段階４０６）。最後に、設計装
置３６は、設計レポートのような様々な文章レポートを
作り出す。このため、設計装置３６は、論理スキーマ、
アクセス方法、プレースメント、クラスタ、記憶スキー
マ、記憶エリア、記憶マップ及び、ロードシーケンスの
事例をアクセスし、各記述をレポートに書きこむ（段階
４１０）。例えばデザイナーレポート４８は、何故シス
テム１０がそのパラメータ及びそれを行ったスキーマ特
定を選んだのかをユーザに説明するのに有用である。レ
ポートはまた、システムが記憶スキーマ３８を発生する
のに適当な入力を使用したかどうかを判断するのにも有
用である。物理データベース設計装置のためのソースコ
ード（添付書類Ｃ、ここで参照として組み入れられてい
る）が、上で述べられたソフトウエアモジュールを実施
する。ＶＡＸで使用されるプログラミング言語はＣバー
ジョン３．０−０３１である。使用されるコンピュータ
はＶＡＸ８８２０であり、それに使用されているオペレ
ーティングシステムはＶＡＸ／ＶＭＳバージョン５．２
である。それらのモジュールはＤＥＣウインドウで実行
される予定であるが、ＤＣＬコマンドラインインターフ
ェイスでも実行可能である。またデータベース設計ルー
ルのリスト及びリレーショナルデータ操作言語、例えば
ＶＡＸ ＳＱＬでコード化されたヒューリスティクは添
付書類Ａに含まれている。
にどのように関連しているのかを論理的に表現する。以
下に述べる例は、表の形態で構成されたデータを有する
「リレーショナルデータベース」を仮定する。テーブル
の行はデータの事例を含み、列は同様の属性を持つデー
タの関係を表す。図１の論理スキーマ１４は、データエ
ンティティが関連するレコード及びフィールド構造を定
義するものと考えることが出来る。人事データベースの
論理スキーマ１４の例が表１に示されている。表に示さ
れているように、スキーマは、多数のテーブル、つま
り、ＣＯＬＬＥＧＥＳ、ＤＥＧＲＥＥＳ、ＤＥＰＡＲＴ
ＭＥＮＴＳ、ＥＭＰＬＯＹＥＥＳ、ＪＯＢＳ、ＪＯＢ．
ＨＩＳＴＯＲＹ、ＲＥＳＵＭＥＳ、ＳＡＬＡＲＹ．ＨＩ
ＳＴＯＲＹ、及びＷＯＲＫ．ＳＴＡＴＵＳを含む。各テ
ーブルをレコードデータ構造の定義として考えることが
出来る。各テーブルはまた、多数の列要素を持ってお
り、これらの列要素をレコード内の領域として考えるこ
とが出来る。例えば、ＣＯＬＬＥＧＥＳテーブルは、そ
れらの列要素であるＣＯＬＬＥＧＥ．ＣＯＤＥ、ＣＯＬ
ＬＥＧＥ．ＮＡＭＥ、ＣＩＴＹ、ＳＴＡＴＥ、及びＰＯ
ＳＴＡＬコードを含む。各列要素はそのデータタイプ、
例えば文字、整数、あるいはデータといったデータタイ
プに関連している。列要素の下で「行」を満たすデータ
エンティティを後にそれらのデータタイプによって関連
させることも出来るが、複数のテーブルにそれらが出現
するということによって互いを関連付けることも出来
る。例えば、ＣＯＬＬＥＧＥ．ＣＯＤＥ列要素は、ＣＯ
ＬＬＥＧＥテーブルと、ＤＥＧＲＥＥＳテーブルに現れ
ている。 デーダベースワークロード２２は、上に示したテーブル
や列のデータエンティティで実行されるデータベースト
ランザクションを定義するものであり、人事データベー
スのためのワークロードの例と関連させて以下に記述す
る。 〔データベースワークロードの構造〕 ワークロードは、データベースの操作中にシステムリソ
ースを特定するパラメータである。ワークロードオペレ
ーションの階層構造を表２に示す。例えば表２に例とし
て示されているデータベースワークロード定義２２は、
論理スキーマ１４で定義されたテーブルや列要素のデー
タエンティティにおいて予想されるデータベースオペレ
ーションを記述する。ワークロード２２には、論理スキ
ーマ１４上のオペレーション（つまり、アプリケーショ
ン、プログラム、トランザクション、及びリクエスト）
が階層形態で配列されている。即ち、アプリケーション
は１つまたはそれ以上のプログラムを含み、プログラム
は１つまたはそれ以上のトランザクションを含み、そし
てトランザクションは１つまたはそれ以上のリクエスト
を含む。さらに詳細に言えば、ワークロード２２は、こ
の階層構造において、論理スキーマ１４のどのテーブル
がアクセスされるか、それらのテーブルがどのようにア
クセスされるか（アクセスモード、ロックモード、及び
オペレーション）、どの位の頻度でアクセスされるか
（頻度及びサイクル）、オペレーションを出来るだけ短
時間に達成することがどの位重要であるか（重要度）を
定義する。例えばアクセスモードには、ＲＥＡＤ、ＷＲ
ＩＴＥ、ＵＰＤＡＴＥが含まれ、ロックモードには、Ｓ
ＨＡＲＥＤ、ＥＸＣＬＵＳＩＶＥ、ＰＲＯＴＥＣＴＥＤ
が含まれる。 テーブル内のデータエンティティへのアクセスは、幾つ
かの状態によって定義される。第１に、アクセスモード
ステートメントは、特定の列要素が例えばＲＥＡＤ、Ｗ
ＲＩＴＥ、あるいはＵＰＤＡＴＥオペレーションのオブ
ジェクトであるといったオペレーションタイプを定義す
る。第２に、ロックモードステートメントは、データエ
ンティティを１つ以上のオペレーションによって同時に
アクセスできるかどうか、例えば、列要素がＳＨＡＲＥ
Ｄ、ＥＸＣＬＵＳＩＶＥＶ、あるいはＰＲＯＴＥＣＴＥ
Ｄアクセスを許すかどうかを定義する。例えば、上で示
されたＥＭＰＬＯＹＥＥＳテーブル内のデータエンティ
ティは、ＣＨＥＣＨ．ＤＥＰＴ．ＩＮＦＯトランザクシ
ョンによってアクセスされる。このトランザクション
は、テーブル上のオペレーションのための全てのリクエ
ストをＲＥＡＤ ＯＮＬＹ及びＳＨＡＲＥＤとして定義
する。最後に、テーブル内のデータエンティティを常に
アクセスする列要素がリクエスト内で特定される。例え
ば、表２に示されたリクエストＤＥＰＴＣＯＤＥ．１内
で、テーブルＤＥＰＡＲＴＭＥＮＴＳはＤＥＰＡＥＴＭ
ＥＮＴ．ＣＯＤＥ列要素によってアクセスされる。ワー
クロード特性は、時間（時間、日、週、年等）サイクル
毎のシステムリソースの必要性を決定する。テーブルへ
のアクセス頻度は、テーブル内のデータエンティティが
特定のサイクル時間内にアクセスされる回数、つまり、
時間、日、週、月、３ケ月、１年ごとの回数によって定
義される。もしテーブルが常に特定の列要素によってア
クセスされている場合には、その要素を経由するアクセ
スの頻度は１のサイクル内においてとても高いものとな
る。例えばＥＭＰＬＯＹＥＥＳテーブルは、ＥＭＰＬＯ
ＹＥＥ．ＩＤ列要素によって１日に５０回あるいは１０
０回アクセスされる。一方、もしテーブルが異なる列要
素の内容によってでたらめにアクセスされる場合には、
アクセスの頻度は１のサイクル内においてとても低いも
のとなる。例えば、ＥＭＰＬＯＹＥＥテーブルは、ＡＤ
ＤＲＥＳＳ．ＤＡＴＡ．１列要素によって週にたった１
度だけアクセスされるかもしれない。アプリケーショ
ン、プログラムあるいはトランザクションの重要度は１
から１０までの大きさの等級であり、それは、その動作
が出来るだけ短時間で達成されることがどの位重要であ
るかに対応する。例えば、アプリケーションはかなり重
要なものと考えられのでスコア８という等級をつけてお
り、一方、アプリケーション内のプログラムはとても重
要なものであるかもしれないのでスコア１０という等級
をつけている。幾つかの特定のケースにおいては、ラン
キングが互いに衝突するかもしれないと思われる。例え
ば、従業員の電話番号を調べ、しかも１日に何度も実行
されるようなトランザクションは、週に１度の給料の支
払いのために従業員のアドレスを調べるトランザクショ
ンよりより等級が上であるとはじめは思うかもしれな
い。しかしながら、給料支払いは、他のトランザクショ
ンより等級が勝るものであると考えられるからより高い
等級を付けることが必要である。一般に、重要度の等級
付けは、最後の記憶スキーマ３８、例えばスキーマ内の
臨界アクセスパスの幾つかの細部を決定する。このよう
に、各アプリケーション、プログラム、トランザクショ
ンのための重要度を注意深く選択することにより、ユー
ザはどのようなデータベースが最適であるかということ
を見きわめるワークロード２２を作り出すことが出来
る。なお、「臨界アクセスパス」という用語は、データ
ベースのうち頻繁に使用されることがある部分へ運航す
るために頻繁に使用されることがあるルートを意味す
る。臨界アクセスパスに沿った処理段階やデータ構造は
最適化を行なうのに重要であり、これにより、データベ
ースの操作中にリソース要求（コスト）を減少させるこ
とができる。論理スキーマ上のオペレーションの各タイ
プ、つまり、アプリケーション、プログラム、トランザ
クションおよびリクエストについて以下に記述する。ア
プケーションは、個別のビジネス機能を実行するプログ
ラムの集合である。例えば、上の表２に示された「ＥＭ
ＰＬＯＹＥＥＳ」アプリケーションは、「ＪＯＢＩＮＦ
Ｏ．」のような個々のプログラムを通じて従業員につい
ての情報を検索したり、更新したりする。アプリケーシ
ョンは一般に、アクセスモード、ロックモード、頻度あ
るいはサイクルによっては定義されないことに注意して
もらいたい。なぜなら、それらは関連したプログラムを
集合化するためだけのものだからである。しかしなが
ら、アプリケーションの重要度はアプリケーション内の
プログラムの重要度の関数として特に定義されている。
例えば、ＥＭＰＬＯＹＥＥＳアプリケーションは８とい
う等級を付けられている。次に、プログラム、例えばＪ
ＯＢＩＮＦＯは、特定の機能あるいはタスクを実行して
いるトランザクションの集合である。ワークロード２２
は、実行可能なイメージあるいはデータベースにアクセ
スするコマンド手続き、例えばアプリケーションプログ
ラム、ＶＡＸデータトライブ（Ｄａｔａｔｒｉｅｖ
ｅ）、ＳＱＬ、あるいはＤＢＱ手続き個々のために、別
個の手続きを定義する。各アプリケーションにおいて、
各プログラムのための、頻度、サイクル及び、重要度が
定義される。例えばＪＯＢＩＮＦＯプログラムのサイク
ルは、ＤＡＩＬＹとして定義される。これは、頻度８
０．００、重要度１０である。次に、トランザクション
は、データベース活動を回復することが出来る装置であ
る。例えばＪＯＢＩＮＦＯは、ＣＨＥＣＫ．ＤＥＰＴ．
ＩＮＦＯ、ＣＨＥＣＫ．ＥＭＰＬＯＹＥＥＳ．ＥＸＩＳ
ＴＥＮＣＥ及びＣＨＥＣＫ．ＪＯＢ．ＩＮＦＯを含む。
ＣＨＥＣＫ．ＤＥＰＴ．ＩＮＦＯトランザクションのた
めのアクセスモードはＲＥＡＤ ＯＮＬＹ、ロックモー
ドはＳＨＡＲＥＤ、頻度は１．００、そして重要度は１
０と定義されている。全てのトランザクションが同一の
サイクル、つまりプログラムの１実行、を有していると
いうことに注意してもらいたい。最後に、各トランザク
ションはリクエスト、つまり単一のデータベースアクセ
スの集合である。各アクセスはＳＱＬあるいはＤＭＬの
ようなデータベース言語で書かれている。例えば、表２
を再び参照すれば、ＣＨＥＣＫ．ＤＥＰＴ．ＩＮＦＯト
ランザクション内の第１のリクエストは、ＳＱＬステー
トメント「ＳＥＬＥＣＴ ｃｏｌｕｍｎ．ｌｉｓｔ Ｆ
ＲＯＭ ＤＥＰＡＥＴＭＥＮＴＳ ＷＨＥＲＥ ＤＥＰ
ＡＲＴＭＥＭＴ．ＣＯＤＥ＝”ｌｉｔｅｒａｌ”ＡＮＤ
ＪＯＢ．ＥＮＤ＞”ｌｉｔｅｒａｌ”」によって定義
された「ＤＥＰＴＣＯＤＥ．１」リクエストである。上
のように定義されたワークロード定義２２は、物理デー
タベース３６に入力され、そして最適な物理設計を作り
出すため、エキスパートシステムにより分析される。ワ
ークロード２２上のエキスパートシステムによってなさ
れる分析について、以下に述べる。ワークロード２２の
分析及び特徴は、全ての設計入力が一度は受ける設計処
理の第１段階である。この分析には、処理サイクルに基
づく頻度をアニュアライズし、トランザクション及びリ
クエストのために頻度を正規化し、各リクエストのため
に絶対的な重要度を作り出すという段階が含まれる。物
理データベース設計装置３６内のエキスパートシステム
は、改善されたデータベース設計、つまり最後の記憶構
造３８の細部を決定するため、ワークロードデータ上の
幾つかのオペレーションを実行するモジュールＫＢ．Ａ
ＮＡＬＹＳＩＳを含む。第１に、ＫＢ．ＡＮＡＬＹＳＩ
Ｓは、ワークロード定義２２内の各リクエストの発生を
「アニュアライズ」する。即ち、それは、サイクル毎の
発生回数を、１年毎の発生回数に換算するのである。例
えば、もしサイクルが時間的なものであれば、ＫＢ．Ａ
ＮＡＬＹＳＩＳはその発生回数に、一日毎の時間、一週
毎の日、月毎の週、３月毎の年を掛け算することによっ
てアニュアライズする。第２に、ＫＢ．ＡＮＡＬＹＳＩ
Ｓは実行カウントが正確に比較されるように、トランザ
クション及びリクエストの発生回数を「アニュアライ
ズ」する。これを行うため、ＫＢ．ＡＮＡＬＹＳＩＳは
まず、トランザクションの実行カウントにプログラムの
実行カウントを掛け算することによってトランザクショ
ンの絶対カウントを更新し、そうしてその結果をトラン
ザクションの絶対カウントに割り当てる。その後ＫＢ．
ＡＮＡＬＹＳＩＳはトランザクションの絶対カウントに
リクエストの実行カウントを掛け算することによってリ
クエストの絶対数を更新し、そうしてその結果をリクエ
ストの絶対数に割り当てる。第３に、ＫＢ．ＡＮＡＬＹ
ＳＩＳはワークロード内の全てのリクエストの等級付け
が正確に比較されるよう、リクエストの重要度の等級付
けを正規化する。即ち、各リクエストの重要度が、リク
エストが発生するアプリケーション、プログラム、それ
にトランザクションの重要度に基づいて計算される。各
リクエストの重要度を相対的に計算するため、ＫＢ．Ａ
ＮＡＬＹＳＩＳＨＡ以下のアルゴリズムを使用する。 リクエスト重要度＝リクエスト絶対頻度／ （重要度高バウンド−リクエスト重要度）２ ここで、重要度高バウンド＝アプリケーションマルチプライア＋ プログラムマルチプライア＋ トランザクションマルチプライア＋ リクエストマルチプライア＋１ リクエスト重要度＝アプリケーション重要度 ＊アプリケーションマルチプライア＋ プログラム重要度＊プログラム重要度＋ トランザクション重要度＊トランザクションマルチプライア＋ リクエスト重要度＊リクエストマルチプライア ここでは、いづれのマルチプライアも、 マルチプライア＝１０＊＊（レベル−１）である。 例えば、 アプリケーションマルチプライア＝１０＊＊３＝１０００ プログラムマルチプライア ＝１０＊＊２＝１００ トランザクションマルチプライア＝１０＊＊１＝１０ リクエストマルチプライア ＝１０＊＊０＝１ である。最後に、ＫＢ．ＡＮＡＬＹＳＩＳは、ワークロ
ード定義２２の全てのトランザクションのリクエスト
を、各データエンティテイへの１つのアクセスパス中
へ、ワークロードで定義されたあらゆるアクセスのタイ
プのために結合する。これを行うため、ＫＢ．ＡＮＡＬ
ＹＳＩＳは、全てのリクエストを特別な順序で、例えば
そのソート順の各「ブレイク」によって、つまりｄｅｓ
ｉｇｎ、ｒｅｔｒｉｅｖａｌ．ｍｏｄｅ、ｖｅｒｂ、ａ
ｄｖｅｒｂ、ｏｂｊｅｃｔ、ｓｅｌｅｃｔ．ｔｙｐｅあ
るいはｓｅｌｅｃｔ．ｏｂｊｅｃｔによってソートす
る。ＫＢ．ＡＮＡＬＹＳＩＳはまた、ソート順の各ブレ
イクにおいて重要度を総計する。 〔データボリューム定義の構造〕 リレーショナルデータベースでは、データのリクエスト
は一般に「質問」と呼ばれており、例えばＳＱＬ質問
（例えば標準質問言語）がある。質問、即ちリクエスト
は、検索データが現れる順序を決定するような要素を含
む。異なる要素はサブ順序を含んでもよい。順序及びサ
ブ順序における変更は、一般に、「ブレイク」と呼ばれ
る。ソートブレイクを生じさせることがある。リクエス
トの要素は、リクエストされたデータがどのように選定
されるのかを特定するのに用いるｖｅｒｂ、ａｄｖｅｒ
ｂ（ｖｅｒｂの変形）、ｏｂｊｅｃｔ（データの事例
（リレーショナルテーブルの行））を含むことができ
る。図１のデータボリューム定義２８は、データベース
内のデータ量を記述する。システム１０は、例えばサイ
ズやファイル内のデータベースファイル、エリアの数を
最適化するため、幾つかの方法でこの情報を使用する。
詳しく言えば、データボリュームは、テーブル及び要素
の揮発性と同様に、各テーブル及び列要素の発生の、最
低数、平均数、それに最大数として定義されている。例
えば、従業員データベースは会社の全ての従業員のため
に、１つのＥＭＰＬＯＹＥＥＳテーブルを含むであろ
う。故にＥＭＰＬＯＹＥＥＳテーブル内のデータエンテ
ィティの発生の最少数は従業員数に等しくなる。しかし
ながら、時間が立つと従業員数は変化し得る。この変化
は、ＥＭＰＬＯＹＥＥＳテーブル内のデータエンティテ
ィの発生の平均と最大数で説明される。例えば、もし会
社が従業員の数を２倍にしようと思えば、ＥＭＰＬＯＹ
ＥＥＳテーブル内のデータエンティティの平均及び最大
数がデータボリューム限定内で増加される。更に、少数
のデータベースは静的データ、つまり変化しないデー
タ、を含むので、ユーザはそのシステムに、１から１０
（１というのは安定しているということであり１０とい
うのは変わりやすいということ）までの大きさで、各テ
ーブル及び列要素の揮発性に等級付けすることが出来
る。例えば、ＥＭＰＬＯＹＥＥＳテーブル内のデータエ
ンティティの数は、例えば加算や減算を多量に受ける
と、いくらか変わり得るものであり、８という等級が付
けられている。一方、例えばＣＯＬＬＥＧＥＳテーブル
内のエンティティの数はかなり安定したものであり、２
という等級が付けられている。もしテーブル内のエンテ
ィティ数がデータベース内の他のエンティティの数より
も多かれ少なかれ変化しやすいものである場合には、そ
のテーブルあるいは列要素は一般に揮発性５という等級
が割り当てられる。以下の表３には、人事データベース
のためのボリューム定義の例が示されている。全部の限
定に０オカレンスというデフォルト値と中間範囲の揮発
性である５という等級が割り当てられている。同様に、
各テーブル及び列エントリには、テーブルあるいは列内
のエンティティのオカレンス数を示すための値とその揮
発性が割り当てられている。例えば、ＣＯＬＬＥＧＳテ
ーブル内のデータエンティティのオカレンス数は、１６
という最小値、平均値、最大値と、５という揮発性を有
している。ボリューム事例は、データベースの論理スキ
ーマで定義された各テーブルに対する個々のボリューム
定義（表３）にすぎない。ボリューム定義は一般に、デ
ータ量の最小、平均、最大を記述し、また、データベー
スの各テーブル（行及び列）のデータの揮発性を記述し
ている。 物理データベース設計装置３６への最後の入力、つまり
設計制約定義３４について以下に述べる。 〔設計制約の構造〕 図１の設計制約定義３４は、データベースで使用される
物理リソース上の制約を記述しており、記憶スキーマ３
８を作り出すために使用される。詳しく言えば、これら
の制約はデータベースを一度にアクセスすることができ
るユーザの最大数、データベースに関連するファイルを
記憶するために利用可能な記憶デバイスの数、どのデバ
イスであっても利用することができるスペースの最大
量、データベースを使用しているアプリケーションが利
用可能なメモリの最大量（おおざっぱに言えば、フリー
メモリの量の半分）、更に、アプリケーションによって
使用されるべき利用可能メモリのパーセンテージ、を含
む。例えば、もしシステムメモリの２／３がデータベー
スアプリケーションによって使用され得るのであれば、
利用可能メモリは６７％である。例として、以下の表４
に、人事データベースのための設計制約定義を示す。記
憶デバイス、つまりディスクの数は１０であり、５０人
のユーザにディスク記憶の１００，０００ブロックを与
える。アプリケーションが利用可能な最大量は６４メガ
バイトであり、そのアプリケーションは利用可能メモリ
の９６パーセントを実際に使用する。 〔動作：物理データベース設計装置〕 図２は、設計入力、つまり論理スキーマ１４、ワークロ
ード２２、制約３４及び、データボリューム２８のエン
ター段階を示す。第１に、物理データベース設計装置３
６は、その作業結果を記憶する物理設計を作り出す。こ
のプロセスを開始するため、設計装置３６は論理スキー
マ１４とワークロード２２のファイルネームを入力する
ようユーザに要求し、設計プロセス（段階１００）への
入力として使用する。次に、設計装置３６は論理スキー
マ１４の事例を生成し（段階１０２）、そのスキーマが
ユニークであるか、つまり同一の論理スキーマの事例が
存在せずその物理設計独自の論理スキーマであるか調査
する（段階１０４）。もしスキーマ１４がユニークでな
ければ、設計装置３６はエラーを返す（段階１０６）。
そうでなければ、つまりスキーマがユニークであれば、
デザイナー３６はスキーマ内の各テーブル及び列要素の
ために事例を作る（段階１０８）。次の処理フェーズ
で、設計装置３６は論理スキーマの各テーブル及び列要
素に対するボリューム事例を作り出す（段階１１２）。
設計装置３６は次に、ワークロード２２の事例を生成し
（段階１１４）、そのワークロードがユニークかどう
か、つまりその物理設計独自のワークロードであるかを
チェックする（段階１１６）。もしワークロード２２が
ユニークでなければ、設計装置３６はエラーを返す（段
階１１８）。さもなければ、つまりワークロード２２が
ユニークであれば、設計装置３６はワークロード２２の
各リクエスト、トランザクション、プログラム及び、ア
プリケーションに対する事例を作り出す（段階１２
０）。最後に設計装置３６は論理スキーマのためのテー
ブル及び列要素の事例に対する各リクエスト事例を確認
し、ユーザに不一致を解決するよう指示する（段階１２
２）。今まで設計装置３６への入力について述べてきた
が、次に設計装置３６からの出力について述べる。 〔実行時間パラメータ及び創作パラメータの構造〕 図１の実行時間パラメーター４２及び、創作パラメータ
ー４４は、コマンド手続き、例えば一連のデジタルコマ
ンド言語（ＤＣＬ）コマンドに含まれる。即ち、コマン
ド手続きが実行されたときに現存のデータベースからデ
ータエンティティをアンロードし、データベースの物理
設計を最適化し、そしてデータエンティティを最適化さ
れた設計で構成された新しいデータベース中へ再びロー
ドする。以下の表５は、人事データベースを最適化する
ために使用されるコマンド手続きのファイル例を示して
いる。詳細に言えば、表５（添付書類Ｂ）に示されたコ
マンド手続きは、最適化処理に関する情報をユーザに提
供し、プロセスの様々な段階への入力をユーザが変える
ことを保証しかつ許可する。例えば、データベースが互
いに依存するデータエンティティテーブルを有している
場合、つまり、それらに重複したレコードがあれば、そ
の手続きはユーザに対してロードシーケンスを編集し、
テーブルが適当な順序でロードするよう指示を出す。次
に、手続きは、新たなデータベースを実行するのに必要
なもの、例えば、論理スキーマや現存のデータベースの
テーブルで発見されたデータを一時記憶するのに十分な
スペースをユーザに命令する。最後に、手続きは、デー
タエンティティの記憶がどの様に最適化されるかを知ら
せその最適化を変える機会をユーザに与える。データベ
ースの変更方法に関する記述が、手続きによってユーザ
に一旦付与されると、手続きは現存のデータベースから
データエンティティをアンロードしていく。データエン
ティティがアンロードされた後、記憶スキーマ３８によ
る記憶エリアを生成し、テーブルの記憶マップ、つま
り、データベースのエリアへのテーブルのマッピングを
作る。一旦新たなデータベースが完成されると、古いデ
ータベースからのアンロードされたデータエンティティ
をソートし、ソートされたそれらのデータエンティティ
を新たなデータベースへロードする。実行時間パラメー
タ４２や創作パラメータ４４のコマンド手続きに続く処
理が、更に様々な文章レポートで証明され得る。 〔動作：物理データベース設計装置による設計の生成〕 図３は、設計装置３６に関連するエキスパートシステム
が最適な物理設計を発生するために用いる段階を示すフ
ローチャートである。第１に、設計装置３６は、各デー
タエンティティへのアクセスエントリを決定するため、
アプリケーション、プログラム、トランザクション及
び、リクエストを分析する（段階３０２）。各データエ
ンティティに必要なフェーズを分析した後、設定装置３
６は次にトランザクション及びプログラム内の各リクエ
ストのための重要度を検索し（段階３０４）、そして各
データエンティティへの臨界アクセスを決定する（段階
３０６）。次の処理フェーズで、設計装置３６は臨界ア
クセス方法エンティティを分析し、各データエンティテ
ィに対して所望のアクセスモードとアクセスフィールド
を決定する（段階３０８）。この分析が完了すると、設
計装置３６はその後、個々のユニーク臨界アクセス及び
データエンティティ結合に対するアクセス方法事例を生
成する（段階３１０）。段階３１０の後、設計装置３６
は各データエンティティに対するプレースメント事例を
決定するため臨界アクセスエントリを分析する（段階３
１２）。設計装置はまた、データエンティティ間の相互
関係を決定するために、トランザクション事例（リレー
ショナルデータベースのため）、あるいはリレーション
シップ事例（コダシルデータベースのため）、及びリク
エスト事例を分析する（段階３１４）。一旦分析が完了
すると、設計装置３６は相互に関係したデータエンティ
ティに対するクラスタを生成する（段階３１６）。その
後、最後の処理フェーズにおいて、設計装置３６は記憶
エリア及び記憶マップへのエンティティマップを決定す
るため、クラスタを分析し、記憶エリア、記憶マップ、
記憶分割及び、記憶インデックスの事例を作り出す（段
階３２０）。一旦事例が作り出されると、設計装置３６
はアクセス方法を用いて記憶インデックスを決定し（段
階３２２）、また記憶エリアと記憶マップを決定するた
めクラスタとプレースメントを使用する（段階３２
４）。最後に設計装置３６は、記憶分割を決定するよう
ユーザに指示を出し（段階３２６）、ボリューム、リク
エスト、クラスタ、記憶マップ実例を使用してロードシ
ーケンス事例を作り出す（段階３２８）。 〔動作：物理データベースによる設計の出力〕 図４は、論理スキーマ４０、記憶スキーマ３８及び、創
作パラメータ４４及び実行時間パラメータ４２を作り出
す段階を示すフローチャートである。第１に、設計装置
３６は新しい論理スキーマ４０を作り出す。このため、
設計装置は、論理スキーマ、データエンティティ、属性
及び関連事例にアクセスし、モデル特定データ定義言語
（ｍｏｄｅｌ ｓｐｅｃｉｆｉｃ Ｄａｔａ Ｄｅｆｉ
ｎｉｔｉｏｎ Ｌａｎｇｕａｇｅ）（ＤＤＬ）を作り出
す（段階４００）。第２に、設計装置３６は記憶スキー
マ３８を作り出す。このため、設計装置３６は、レコー
ドフォマット、記憶スキーマ、記憶エリア、記憶マッ
プ、記憶インデックス、及び記憶分割事例にアクセス
し、モデル特定ＤＤＬファイルを作り出す（段階４０
２）。第３に、設計装置３６は創作パラメータ４４を作
り出す。このため、設計装置３６は、記憶エリア、実施
品、及び設計制約の事例にアクセスし、モデル特定創作
コマンドを作り出す（段階４０４）。第４に、設計装置
は実行時間パラメータ４２を作り出す。このため、設計
装置３６は、実行プロダクト、設計制約、記憶エリア及
び、記憶マップの実例にアクセスし、モデル特定実行時
間コマンドを作り出す（段階４０６）。最後に、設計装
置３６は、設計レポートのような様々な文章レポートを
作り出す。このため、設計装置３６は、論理スキーマ、
アクセス方法、プレースメント、クラスタ、記憶スキー
マ、記憶エリア、記憶マップ及び、ロードシーケンスの
事例をアクセスし、各記述をレポートに書きこむ（段階
４１０）。例えばデザイナーレポート４８は、何故シス
テム１０がそのパラメータ及びそれを行ったスキーマ特
定を選んだのかをユーザに説明するのに有用である。レ
ポートはまた、システムが記憶スキーマ３８を発生する
のに適当な入力を使用したかどうかを判断するのにも有
用である。物理データベース設計装置のためのソースコ
ード（添付書類Ｃ、ここで参照として組み入れられてい
る）が、上で述べられたソフトウエアモジュールを実施
する。ＶＡＸで使用されるプログラミング言語はＣバー
ジョン３．０−０３１である。使用されるコンピュータ
はＶＡＸ８８２０であり、それに使用されているオペレ
ーティングシステムはＶＡＸ／ＶＭＳバージョン５．２
である。それらのモジュールはＤＥＣウインドウで実行
される予定であるが、ＤＣＬコマンドラインインターフ
ェイスでも実行可能である。またデータベース設計ルー
ルのリスト及びリレーショナルデータ操作言語、例えば
ＶＡＸ ＳＱＬでコード化されたヒューリスティクは添
付書類Ａに含まれている。
【図１】本発明による物理データベース設計システムの
構成要素のブロック図。
構成要素のブロック図。
【図２】設計入力をエンターするために必要な段階を示
すフローチャート。
すフローチャート。
【図３】物理構造を発生するために必要な段階を示すフ
ローチャート。
ローチャート。
【図４】創作パラメータ及び実行時間パラメータを出力
して物理構造を実行するのに必要な段階を示すフローチ
ャート。
して物理構造を実行するのに必要な段階を示すフローチ
ャート。
【図５】論理データベーススキーマに適用されるルール
の例。
の例。
───────────────────────────────────────────────────── フロントページの続き (56)参考文献 社団法人情報処理学会編「情報処理ハ ンドブック」（1989−５−30）オーム社 Ｐ．702−710 (58)調査した分野(Int.Cl.6，ＤＢ名) G06F 12/00 G06F 9/06 G06F 9/44
Claims (5)
- 【請求項１】 データベースの物理設計を生成するため
にコンピュータシステムによって実行される方法であっ
て、前記データベースは複数のデータレコードと該デー
タレコードに記憶されたデータにアクセスするための複
数のインデックスレコードとを有している、前記方法に
おいて、 コンピュータシステムのメモリから１組のエキスパート
ルールを検索する段階と、 データベースの論理配列を記述する論理スキーマを入力
として受け入れる段階と、 データベースに記憶されるべきデータの量を記述するデ
ータボリューム定義を受け入れる段階と、 その各々が前記データベースのデータにアクセスするよ
うな複数の第１のオペレーションを定義する段階と、 前記複数の第１のオペレーション中の各第１のオペレー
ションに対する１つの第１のワークロードを特定する第
１のワークロード記述を入力として受け入れる段階と、 前記複数の第１のオペレーション中の所定の第１のオペ
レーションを複数の第２のオペレーションにグループ分
けする段階であって、各第２のオペレーションは少なく
とも１つの第１のオペレーションを有し、各第１のオペ
レーションは少なくとも１つの第２のオペレーションに
グループ分けされている前記段階と、 前記複数の第２のオペレーション中の各第２のオペレー
ションに対する１つの第２のワークロードを特定する第
２のワークロード記述を入力として受け入れる段階と、 前記複数の第２のオペレーション中の所定の第２のオペ
レーションを複数の第３のオペレーションにグループ分
けする段階であって、各第３のオペレーションは少なく
とも１つの第２のオペレーションを有し、各第２のオペ
レーションは少なくとも１つの第３のオペレーションに
グループ分けされている前記段階と、 前記複数の第３のオペレーション中の各第３のオペレー
ションに対する１つの第３のワークロードを特定する第
３のワークロード記述を入力として受け入れる段階と、 データベースの物理設計を生成するために、前記１組の
エキスパートルールを、前記論理スキーマ、前記データ
ボリューム記述、前記第１のワークロード記述、前記第
２のワークロード記述、及び、前記第３のワークロード
記述に適用する段階であって、前記物理設計は、どのよ
うにデータがデータレコードに物理的に記憶されるの
か、及び、どのようにデータレコードがインデックスレ
コードによってアクセスされるのかを特定する段階と、 を備えることを特徴とする方法。 - 【請求項２】 前記複数の第３のオペレーション中の各
第３のオペレーションはコンピュータプログラムであ
り、前記複数の第２のオペレーション中の各第２のオペ
レーションは、回復可能なデータベーストランザクショ
ンであり、前記複数の第３のオペレーションはデータ読
出しオペレーションと、データ書込みオペレーション
と、データ更新オペレーションである請求項１記載の方
法。 - 【請求項３】 前記第１のワークロード記述、前記第２
のワークロード記述、前記第３のワークロード記述は更
に、前記第１のオペレーション、前記第２のオペレーシ
ョン、及び前記第３のオペレーションの相対重要度及び
相対頻度を、それぞれ備えており、更に、 前記第１のオペレーション、前記第２のオペレーショ
ン、及び前記第３のオペレーションの前記相対頻度をア
ニュアライズする段階と、 アニュアライズ後に、前記第１のオペレーションの絶対
重要度および絶対頻度を引き出す段階と、 を備える請求項１記載の方法。 - 【請求項４】 前記複数の第３のオペレーション中の所
定の第３のオペレーションを複数の第４のオペレーショ
ンにグループ分けする段階であって、前記複数の第４の
オペレーション中の各第４のオペレーションは少なくと
も１つの第３のオペレーションを含む前記段階と、 前記複数の第４のオペレーション中の各第４のオペレー
ションのための第４のワークロードを特定する第４のワ
ークロード記述を入力として受け入れる段階と、を更に
備える請求項１記載の方法。 - 【請求項５】 前記第１のワークロード記述を受入れる
段階と、前記第２のワークロード記述を受け入れる段階
と、前記第３のワークロード記述を受け入れる段階は、
更に、事象性能コレクタソフトウェアの出力を入力する
段階を備える請求項１記載の方法。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US48537690A | 1990-02-26 | 1990-02-26 | |
| US485376 | 1990-02-26 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH04217042A JPH04217042A (ja) | 1992-08-07 |
| JP2768433B2 true JP2768433B2 (ja) | 1998-06-25 |
Family
ID=23927915
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP3028360A Expired - Lifetime JP2768433B2 (ja) | 1990-02-26 | 1991-02-22 | 物理データベース設計システム |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US5485610A (ja) |
| EP (1) | EP0444364B1 (ja) |
| JP (1) | JP2768433B2 (ja) |
| CA (1) | CA2037021C (ja) |
| DE (1) | DE69031028T2 (ja) |
Families Citing this family (45)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6003033A (en) * | 1992-02-28 | 1999-12-14 | International Business Machines Corporation | System and method for describing and creating a user defined arbitrary data structure corresponding to a tree in a computer memory |
| US5717918A (en) * | 1994-06-17 | 1998-02-10 | Hitachi, Ltd. | Method for concurrently performing a physical sequential scan of a database into a database buffer which is queued until a preceding scan is completed |
| US5625811A (en) * | 1994-10-31 | 1997-04-29 | International Business Machines Corporation | Method and system for database load balancing |
| US5774714A (en) * | 1995-03-27 | 1998-06-30 | Hewlett-Packard Company | Zone bit recording enhanced video data layout |
| US5675731A (en) * | 1995-09-22 | 1997-10-07 | Sun Microsystems, Inc. | Scatter load for system test |
| US7349892B1 (en) | 1996-05-10 | 2008-03-25 | Aol Llc | System and method for automatically organizing and classifying businesses on the World-Wide Web |
| US6148289A (en) * | 1996-05-10 | 2000-11-14 | Localeyes Corporation | System and method for geographically organizing and classifying businesses on the world-wide web |
| US5778393A (en) * | 1996-05-20 | 1998-07-07 | International Business Machines Corporation | Adaptive multitasking for dataset storage |
| US5999930A (en) * | 1996-08-02 | 1999-12-07 | Hewlett-Packard Company | Method and apparatus for distributed control of a shared storage volume |
| US6317737B1 (en) * | 1996-10-18 | 2001-11-13 | Sagent Technologies, Inc. | Data descriptions in a database system |
| US6016394A (en) * | 1997-09-17 | 2000-01-18 | Tenfold Corporation | Method and system for database application software creation requiring minimal programming |
| US6477571B1 (en) * | 1998-08-11 | 2002-11-05 | Computer Associates Think, Inc. | Transaction recognition and prediction using regular expressions |
| US8321457B2 (en) | 2000-09-08 | 2012-11-27 | Oracle International Corporation | Techniques for automatically developing a web site |
| US6487547B1 (en) | 1999-01-29 | 2002-11-26 | Oracle Corporation | Database appliance comprising hardware and software bundle configured for specific database applications |
| US6865576B1 (en) * | 1999-05-21 | 2005-03-08 | International Business Machines Corporation | Efficient schema for storing multi-value attributes in a directory service backing store |
| US6490590B1 (en) * | 2000-02-14 | 2002-12-03 | Ncr Corporation | Method of generating a logical data model, physical data model, extraction routines and load routines |
| US6898783B1 (en) * | 2000-08-03 | 2005-05-24 | International Business Machines Corporation | Object oriented based methodology for modeling business functionality for enabling implementation in a web based environment |
| US7171455B1 (en) | 2000-08-22 | 2007-01-30 | International Business Machines Corporation | Object oriented based, business class methodology for generating quasi-static web pages at periodic intervals |
| US6684388B1 (en) | 2000-08-22 | 2004-01-27 | International Business Machines Corporation | Method for generating platform independent, language specific computer code |
| US6853994B1 (en) | 2000-08-30 | 2005-02-08 | International Business Machines Corporation | Object oriented based, business class methodology for performing data metric analysis |
| US6694325B2 (en) * | 2000-10-16 | 2004-02-17 | Frank Jas | Database method implementing attribute refinement model |
| US6823342B2 (en) | 2001-05-15 | 2004-11-23 | Vykor, Inc. | Method and system for capturing, managing, and disseminating manufacturing knowledge |
| US7134122B1 (en) | 2001-05-31 | 2006-11-07 | Oracle International Corporation | One click deployment |
| US6978282B1 (en) * | 2001-09-04 | 2005-12-20 | Emc Corporation | Information replication system having automated replication storage |
| US7243108B1 (en) * | 2001-10-14 | 2007-07-10 | Frank Jas | Database component packet manager |
| US6920460B1 (en) | 2002-05-29 | 2005-07-19 | Oracle International Corporation | Systems and methods for managing partitioned indexes that are created and maintained by user-defined indexing schemes |
| US20050038786A1 (en) * | 2003-08-11 | 2005-02-17 | International Business Machines Corporation (Ibm) | Self-configuration of database tables |
| KR100645513B1 (ko) * | 2004-10-15 | 2006-11-15 | 삼성전자주식회사 | 단일테이블을 이용한 성능관리 데이터 처리장치 및 그 방법 |
| US7437080B2 (en) * | 2005-02-03 | 2008-10-14 | Stratalight Communications, Inc. | Optical transmission system having optimized filter wavelength offsets |
| US7447681B2 (en) | 2005-02-17 | 2008-11-04 | International Business Machines Corporation | Method, system and program for selection of database characteristics |
| US20070174346A1 (en) * | 2006-01-18 | 2007-07-26 | Brown Douglas P | Closed-loop validator |
| US7805443B2 (en) * | 2006-01-20 | 2010-09-28 | Microsoft Corporation | Database configuration analysis |
| US7685145B2 (en) * | 2006-03-28 | 2010-03-23 | Microsoft Corporation | Database physical design refinement using a merge-reduce approach |
| US7580941B2 (en) * | 2006-06-13 | 2009-08-25 | Microsoft Corporation | Automated logical database design tuning |
| US20080183764A1 (en) * | 2007-01-31 | 2008-07-31 | Microsoft Corporation | Continuous physical design tuning |
| US8150790B2 (en) * | 2007-01-31 | 2012-04-03 | Microsoft Corporation | Lightweight physical design alerter |
| US9805077B2 (en) * | 2008-02-19 | 2017-10-31 | International Business Machines Corporation | Method and system for optimizing data access in a database using multi-class objects |
| US8140548B2 (en) | 2008-08-13 | 2012-03-20 | Microsoft Corporation | Constrained physical design tuning |
| US20100114976A1 (en) * | 2008-10-21 | 2010-05-06 | Castellanos Maria G | Method For Database Design |
| US8566318B1 (en) * | 2010-09-10 | 2013-10-22 | Giovanni Sacco | Process for physical database design based on transaction workload |
| US8949293B2 (en) | 2010-12-17 | 2015-02-03 | Microsoft Corporation | Automatically matching data sets with storage components |
| US9176902B1 (en) * | 2012-06-27 | 2015-11-03 | Emc Corporation | Data migration techniques |
| US9639562B2 (en) * | 2013-03-15 | 2017-05-02 | Oracle International Corporation | Automatically determining an optimal database subsection |
| US10466936B2 (en) * | 2014-09-26 | 2019-11-05 | Oracle International Corporation | Scalable, multi-dimensional search for optimal configuration |
| JP6148763B2 (ja) * | 2015-06-15 | 2017-06-14 | 株式会社日立製作所 | データ・アクセスを最適化するためにネットワーク・ノードにわたるデータ・ストアの中にデータ・レコードをグループ化するための方法 |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4468732A (en) * | 1975-12-31 | 1984-08-28 | International Business Machines Corporation | Automated logical file design system with reduced data base redundancy |
| US4631664A (en) * | 1983-07-19 | 1986-12-23 | Bachman Information Systems, Inc. | Partnership data base management system and method |
| JPS6077249A (ja) * | 1983-10-04 | 1985-05-01 | Nec Corp | デ−タ構造自動作成装置 |
| JP2602205B2 (ja) * | 1986-01-16 | 1997-04-23 | 株式会社日立製作所 | データベース・アクセス制御方法 |
| US4956774A (en) * | 1988-09-02 | 1990-09-11 | International Business Machines Corporation | Data base optimizer using most frequency values statistics |
| US5014197A (en) * | 1988-09-02 | 1991-05-07 | International Business Machines Corporation | Assignment of files to storage device using macro and micro programming model which optimized performance of input/output subsystem |
| US5159687A (en) * | 1989-11-14 | 1992-10-27 | Caseworks, Inc. | Method and apparatus for generating program code files |
-
1990
- 1990-12-28 DE DE69031028T patent/DE69031028T2/de not_active Expired - Lifetime
- 1990-12-28 EP EP90314392A patent/EP0444364B1/en not_active Expired - Lifetime
-
1991
- 1991-02-22 JP JP3028360A patent/JP2768433B2/ja not_active Expired - Lifetime
- 1991-02-25 CA CA002037021A patent/CA2037021C/en not_active Expired - Lifetime
-
1994
- 1994-08-19 US US08/292,575 patent/US5485610A/en not_active Expired - Lifetime
Non-Patent Citations (1)
| Title |
|---|
| 社団法人情報処理学会編「情報処理ハンドブック」（１９８９−５−３０）オーム社Ｐ．７０２−７１０ |
Also Published As
| Publication number | Publication date |
|---|---|
| EP0444364B1 (en) | 1997-07-09 |
| US5485610A (en) | 1996-01-16 |
| DE69031028D1 (de) | 1997-08-14 |
| CA2037021C (en) | 1995-08-01 |
| DE69031028T2 (de) | 1997-11-20 |
| EP0444364A2 (en) | 1991-09-04 |
| EP0444364A3 (en) | 1992-12-23 |
| JPH04217042A (ja) | 1992-08-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2768433B2 (ja) | 物理データベース設計システム | |
| CN101828182B (zh) | 报告oltp数据的无etl零冗余系统和方法 | |
| US5878426A (en) | Statistical database query using random sampling of records | |
| US5960423A (en) | Database system index selection using candidate index selection for a workload | |
| US7610263B2 (en) | Reusing intermediate workflow results in successive workflow runs | |
| US5758144A (en) | Database execution cost and system performance estimator | |
| US5913207A (en) | Database system index selection using index configuration enumeration for a workload | |
| US6789071B1 (en) | Method for efficient query execution using dynamic queries in database environments | |
| US6801903B2 (en) | Collecting statistics in a database system | |
| US5950186A (en) | Database system index selection using cost evaluation of a workload for multiple candidate index configurations | |
| US5926813A (en) | Database system index selection using cost evaluation of a workload for multiple candidate index configurations | |
| US20030212960A1 (en) | Computer-implemented system and method for report generation | |
| US6704719B1 (en) | Decision tree data structure for use in case-based reasoning | |
| US5913206A (en) | Database system multi-column index selection for a workload | |
| CN110019251A (zh) | 一种数据处理系统、方法及设备 | |
| US5873091A (en) | System for data structure loading with concurrent statistical analysis | |
| EP0801773A1 (en) | Storage plane organization and storage systems based thereon | |
| WO2010058222A2 (en) | Updating data within a business planning tool | |
| CN110795478A (zh) | 一种应用于金融业务的数据仓库更新方法、装置和电子设备 | |
| US7877355B2 (en) | Job scheduling for automatic movement of multidimensional data between live datacubes | |
| WO2002021327A2 (de) | Verfahren und computerprogramm zur erzeugung von dateien für ein datenbanksystem für ein betriebswirtschaftliches anwendungsprogramm | |
| Ceri et al. | Optimization problems and solution methods in the design of data distribution | |
| England et al. | Microsoft SQL Server 2005 performance optimization and tuning handbook | |
| Chao-Qiang et al. | RDDShare: reusing results of spark RDD | |
| US5995960A (en) | Method and system for improving efficiency of programs utilizing databases by exeuting scenarios based on recalled processed information |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090410 Year of fee payment: 11 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100410 Year of fee payment: 12 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110410 Year of fee payment: 13 |
|
| EXPY | Cancellation because of completion of term |