物理的なデータベース設計

データベースの物理設計は、不要なデータの冗長性を回避してデータ保全性を保証する一方で、パフォーマンスを最適化します。物理設計時に、エンティティーを表に、インスタンスを行に、属性を列に変換します。

データベースの論理設計を完了したら、物理設計に移行します。共同で作業する人達と一緒に、物理設計に影響する多くの決定を行う必要があります。この一部を以下にリストします。

物理表へのエンティティーの変換方法
物理表の列に使用する属性
キーとして定義する表の列
表に対して定義する索引
表に対して定義するビュー
表の非正規化方法
多対多の関係の解決方法
ハッシュ・アクセスを活用できる設計

物理設計時に、論理設計中に選択した名前を簡略化します。例えば、従業員を識別する列名を、EMPLOYEE_NUMBER から EMPNO に簡略化できます。 Db2 for z/OS® では、カラム名とテーブル名を、カラム名は最大30バイト、テーブル名は最大128バイトという物理的な制約に合うように省略する必要があります。データベースオブジェクト名の規約および規則の詳細については、「SQLにおける命名規約」および「SQLにおける識別子」を参照してください。

物理設計を構築する作業は、終わることのない作業です。時間の経過に応じて、パフォーマンスと、データベースのデータ保全性の特性を絶えずモニターする必要があります。多くの要因によって、物理設計を定期的に改善することが必要になります。

Db2では、ALTER SQL ステートメントを使用して多くの設計のキー属性を変更することができます。例えば、36 カ月分相当のデータを保管できるようにパーティション化表を設計すると想定します。後で、84 カ月分相当のデータを保持するように、設計を拡張する必要があることが分かりました。新しい設計に対応するために、現行の 36 カ月分のパーティションに追加または循環させることができます。

この説明の以降の部分では、データベースの物理設計の構築および改善に役立つ価値ある情報の一部を記載してあります。しかし、この作業には一般的に、この入門レベルの情報を読んでいるほとんどの人が持っているよりも多くの Db2 の経験が必要となります。