作業:
|
目的
|
|
手順 | |
入力とする成果物: | 結果となる成果物: |
頻度: 反復ごとに 1 回 | |
役割: データベース設計者 | |
ツール メンター: |
ワークフローの詳細: |
この作業で示す手順では、アプリケーションの永続データ設計がリレーショナル データベース管理システム (RDBMS) を使用して実装されることを想定します。参考資料 [DAT99] などの資料で扱われているデータベース用語や、正規化や非正規化などのデータベースに関する概念について読者がよく理解していることを前提としています。
この作業の手順では、参考資料 [NBG01] で述べられている、データベース モデリングのための統一モデリング言語 (UML) のプロファイルについても言及します。また、参考資料 [NBG01] には、UML を使用してデータベースをモデリングし、設計するプロセスについての全般的な説明があります。リレーショナル データベースとオブジェクト モデルの間の関係についての背景情報は、「概念: リレーショナル データベースとオブジェクト指向」を参照してください。
目的 | データベースの論理設計のモデルを定義する |
論理データ モデルの目的は、特定のソフトウェアまたはデータベース実装とは無関係な、主要な論理データ エンティティとエンティティ間の関係を概念化してビューに定義することです。これは一般に、第 3 正規形 (「概念: 正規化」を参照) で行います。第 3 正規形は、冗長性を最小限にし、遷移的な依存関係の排除を保証するデータ モデリング形式です。このようなモデルでは、データを使用するアプリケーションやその性能についてではなく、データを取得するときのデータベースの振る舞いを扱います。論理データ モデルは、「成果物: データ モデル」の一部と見なされており、独立した RUP 成果物ではないことに注意してください。ただし多くの場合、以下のものを対象として独立した論理データ モデルを定義することは重要です。
論理データ モデルを作成する場合、「ガイドライン: データ モデル」で説明されているモデル要素を使用してゼロから作業を開始するか、分析モデルまたは設計モデル内の各永続クラスのエンティティを基に作業を開始することができます。
独立した論理データ モデルを作成しない場合もあります。単独のアプリケーションとして機能するデータベースを設計する場合がその典型的な例です。この場合、データベース設計者が、設計モデル内の一連の永続クラス、またクラス間の関連に基づいて物理データ モデルを作成します。
どちらのアプローチでも、分析と設計のプロセス全体を通じてデータベース設計者と設計者が協力し、「成果物: 設計モデル」内のどのクラスがデータベースに情報を格納する必要があるかを識別することが重要です。「作業: クラスの設計」の「永続クラスの識別」の手順で説明しているように、データベース設計者は設計者と共同で作業して、設計モデル内のどの設計クラスを永続的とみなし、データベース内のテーブルの基になる潜在的な候補とするかを識別します。
目的 | データベースの詳細な物理設計を定義する |
物理データベース設計には、データベースの詳細な物理構造を表現するモデル要素 (テーブル、ビュー、ストアド プロシージャなど) と、データベースの基盤となるデータ記憶領域設計を表現するモデル要素 (スキーマやテーブルスペースなど) が含まれます。これらのモデル要素が一体となってデータベースの物理データ モデルを構成します。この物理データ モデルは「成果物: データ モデル」に含まれており、独立したモデル成果物ではありません。
物理データベース設計の作成は、以下の手順で行います。
目的 | 再利用可能な、ユーザー定義の型を定義する |
データベース設計者は、データベース設計全体を通じて型の標準を推進する目的でドメインを使用できます。ドメインはユーザー定義のデータ型の集合であり、テーブル内の列に適用できます。ドメインには名前を除いた列のプロパティがあります。
目的 | 初期のデータベース テーブルと関係を作成する |
データベース設計者は、「ガイドライン: データ モデル」で説明されている手順で、テーブルとテーブル内の列を使用して物理データ モデルの要素をモデリングします。
論理データ モデルが作成されたら、その論理エンティティを初期のテーブル集合の基礎として使用できます。
また、物理データ モデルをすばやく作成するための別の方法として、設計モデル内の永続クラスを使用し、物理データ モデル内のテーブルを作成するための開始点とすることもできます。データベース設計者は永続クラスをテーブルとして、また永続クラスの属性を列としてそれぞれモデリングします。データベース設計者は、設計モデル内の永続クラス間の関連に基づいて、テーブル間の関係を定義する必要もあります。設計モデルの要素と要素間の関係をデータ モデルの要素と関係にマッピングする方法については、「ガイドライン: リレーショナル データベースのフォワード エンジニアリング」で説明しています。
正規化された論理データ モデルからではなく永続クラスからモデリングを開始している場合、通常は、データの冗長性と非キー フィールドの依存関係を排除する目的で、何らかの正規化を適用する必要があります。データベース正規化について詳しくは、「概念: 正規化」を参照してください。
目的 | プロジェクト全体で使用する標準参照テーブルを定義する |
プロジェクト全体でよく使用されるものに標準のルックアップ テーブル、検証テーブル、または参照テーブルがあります。このようなテーブルのデータへのアクセスは頻繁ですがほとんど変更されることはないので、そのデータには特別の配慮が必要です。設計モデルでは、このようなテーブルには標準の製品コード、都道府県、郵便番号、税率表、市外局番検証表やその他の頻繁にアクセスする情報が含まれる場合があります。金融システムでは、こうしたテーブルには保険コードのリスト、生命保険の格付けカテゴリ、変換レートなどが含まれる場合があります。主に読み取りだけに使用するクラスの設計モデルを参照して、多数のクライアント向けの認証情報を提供します。
参照テーブルが小さい場合、そのテーブルの索引を作成しないでください。テーブルが小さい場合、索引処理を行うと実際にはオーバーヘッドが増える場合があります。サイズが小さく、頻繁にアクセスされるテーブルもメモリ内にとどまり続ける傾向があります。それは、キャッシュ アルゴリズムがしばしば、頻繁にアクセスされるテーブルをデータ キャッシュに保持するからです。
可能であれば、クエリーとトランザクション用の通常の「作業セット領域」だけでなく、すべての参照テーブルをメモリ内に保持できるだけの十分な大きさのデータベース キャッシュを確保します。多くの場合、データベースの性能を向上させる秘訣はディスク入出力を減らすことです。
参照テーブルの構造を定義したら、参照テーブルの配置戦略を決定します。参照テーブルはプロジェクトの開始に近い時期にアクセスされるので、参照値の決定とテーブルのロードは多くの場合、アプリケーション実行期間中の比較的早い時期に行う必要があります。データベース設計者にはデータを取得する責任はありませんが、参照テーブルをいつ、どのようにして最新のものにするかを決める責任があります。
目的 | 固有な項目として識別する 1 つ以上の列を定義する データまたはデータのコレクションの固有性を保証する制約を列に定義する |
固有な項目として識別する 1 つ以上の列です。1 つのテーブルには 1 つの主キーがあります。多くの場合、行のデータを固有に識別するために使用する「自然」キーが存在します (たとえば、参照テーブル内の郵便番号)。ビジネス環境に合わせて変化する可能性のあるデータは主キーに入れるべきではありません。「自然」キーが変化する可能性のある値 (人名など) である場合、データベース設計者は主キー作成時に、特別な意味を持たず、ユーザーが入力しない 1 つの列を作成することが推奨されます。これにより、ビジネスの構造、ルール、環境の変化に対する適応性がより高いデータ構造ができます。
特別な意味を持たず、ユーザーが入力しない列を主キーとして使用することは、データ ウェアハウスの設計において不可欠な概念です。トランザクション システムでは多くの場合、特別な意味を持たず、ユーザーが入力しない列に対して最小限の変更しか生じないため、「自然」主キーの使用を選択します。
ユニーク制約は、列または列のコレクション内のデータが各行内で固有であることを保証します。列にユニーク制約が課せられている場合、指定された列の特定の行のデータは、同じ列のほかの行のデータと異なっていなければなりません。
ユニーク制約が列のグループに対して定義されているとき、その固有性は、ユニーク制約を構成する列集合内のデータ全体に基づくものとなります。特定の列の特定の行のデータが、同じ列のほかの行のデータと異なっている必要はありません。データベース設計者は、ビジネス データの固有性を保証するためにユニーク制約を使用します。
目的 | データベースの整合性を確保する |
制約としても知られているデータ整合性規則は、データの値が定義範囲内にあることを保証します。このような範囲を明確にできれば、データベースはデータ範囲の保証を推進できます (これはアプリケーション内でデータの妥当性のチェックをすべきではないという意味ではなく、単に、アプリケーションが正しく動作しない場合にデータベースが「妥当性確認の最後の手段」として役立つという意味です)。データの妥当性チェック規則が存在していれば、それを推進するデータベース制約を設計しなければなりません。
外部キーは、別のテーブル内の主キーにマッピングする、テーブル内の 1 つ以上の列です。1 つのテーブルに多くの外部キーが存在する場合があり、各外部キーはそれぞれ異なったテーブルにマッピングします。テーブル間のこのマッピング (関係) は多くの場合、親子関係と呼ばれます。子のテーブルには、親テーブル内の主キーにマッピングする外部キーが含まれます。
外部キー制約の定義はクエリー最適化プログラムも使用しており、クエリーの性能の高速化に使用されています。多くの場合、外部キー推進規則では参照テーブルを使用します。
目的 | データベースのデータ構造の性能を最適化する |
リレーショナル データ モデルの場合、初期のマッピングでは通常、クラスからテーブルへの単純なマッピングが行われます。異なるクラスのオブジェクトを同時に取り出す必要がある場合、RDBMS では「テーブル結合」操作を使用し、対象とするオブジェクトに関係する行を取り出します。頻繁にアクセスするデータに対して結合操作を行うと、計算処理量の観点からコストが高くつく場合があります。結合操作のコストを減らす目的には、標準のリレーショナル技法である「非正規化」処理がよく採用されます。
非正規化処理は、複数のテーブルから列を取り出して 1 つのテーブルに結合する操作で、実質的に情報を事前結合することになります。非正規化処理は、コストのかかる更新操作方法の妥協策を反映し、よりコストの低い検索取得操作を実現します。この技法ではまた、非正規化処理されたテーブルで効果的に結合されているオブジェクト群のいずれか 1 つの属性のみを取り出すクエリーを実行した場合、通常なら毎回のクエリーですべての属性が取り出されるため、システムの性能が低下します。アプリケーションが通常すべての属性を必要とするような状況では、性能の著しい改善が見込める可能性があります。
3 つ以上のテーブルを非正規化処理することはまれですが、非結合処理を行った場合、そのクエリーのコストだけでなく、挿入や更新にかかるコストも増大します。処理対象を多くした方が利点が多いという強い説得力のある実証がない限り、非正規化処理の対象テーブルは 2 つまでに制限することをお勧めします。
クラスがネストになっている場合、非正規化処理の必要性は設計クラスから推測できます。ネストされたクラスは、非正規化されたテーブルにマッピングすることができます。
非正規化処理に類似した概念を備えた一部のオブジェクト データベースでは、関連する複数のオブジェクトをクラスタ単位でディスク上にまとめ、1 回の操作で取得できます。使用されている概念は類似したものです。関連する複数のオブジェクトをデータベースから取り出すためにシステムが行わなければならない処理を軽減することによって、オブジェクトの取り出しにかかる時間を短縮します。
場合によっては、データ モデルを最適化することで、性能のボトルネック、モデリング上の欠陥、未完成の設計など設計モデルの問題が判明することがあります。このような場合には、クラスの設計者と問題点を議論し、適切なタイミングで変更依頼を出します。
目的 | 索引処理を使用して効率的なデータ アクセスを提供する データベース ビューを使用して効率的なデータ アクセスを提供する |
テーブル構造を設計したら、データに対して実行するクエリーのタイプを決定しなければなりません。アクセスを高速化するために、データベースに索引を付けます。索引処理される列のデータ値の違いが大きいときは、索引を付けることが最も効果的です。
索引処理についての以下の原則を考慮してください。
索引を使用することのマイナス面は、索引処理自体のコストを無視できないことです。テーブルに索引を増やすほど、挿入や更新の処理にかかる時間が長くなります。索引の使用を検討するときは、以下の点に注意してください。
多くのデータベースでは、選択肢として索引のタイプがいくつか用意されています。最も一般的なものを次に示します。
選択する索引処理のタイプや索引作成のタイミングは、性能を大きく左右する可能性があります。大量なデータのロード処理は、索引なしで実行するのが適切です (これは、索引をいったん削除してからデータをロードし、終わったら索引を再生成するという手順で行うことができます)。その理由は、行が追加されるたびに索引構造の再整理が行われるためです。連続的に行が増えることにより最適な索引構造も変わるため、行が挿入されるたびに索引を再整理してもほとんど無駄になります。索引なしでデータをロードし、完了後まとめて索引を再構築するほうが速くて効率的です。データベースによっては、この処理を自動的に行う大量データ ロード機能を備えている場合があります。
データベース アクセスの性能を最適化するための別の戦略には、ビューの使用があります。データベース ビューは仮想のテーブルであり、独自の独立した記憶領域を持ちません。ただし、呼び出し側プログラム (またはユーザー) にとっては、ビューはテーブルと同様に振る舞います。データベース構造やデータベースのベンダーによっては、ビューはデータの取り出しをサポートし、データを更新する目的にも使用できます。ビューには、単独の SELECT ステートメントを通じてアクセス可能な 1 つ以上のテーブルからのデータが入ります。性能の改善は、データの選択の間に、特に頻繁にクエリーが表示されるテーブルで発生します。データベース内に存在する複数のテーブルまたは大きなテーブルから検索する代わりに、1 つの場所 (ビュー) からデータが取り出されます。
ビューはデータベース セキュリティの面でも重要な役割を果たします。テーブルの一部のデータだけをビューに入れることにより、基本テーブルに含まれている重要なデータへのアクセスを制限することができます。
目的 | データベースの領域割り当てとディスク ページ編成を定義する |
データベース設計者はテーブルスペースを使用して、テーブル、索引、ストアド プロシージャなどに割り当てられる記憶領域の大きさを表現します。1 つ以上のテーブルスペースがデータベースにマッピングされます。データベース設計者はデータ モデル内のテーブルを分析して、テーブルやその他の補助的なデータベース要素を、データベース内の記憶領域全体の中でどのように分散させるかを決定しなければなりません。
データベースに対してテーブルスペースの構造を決定するときは、行、レコード、さらにはテーブル全体に対してもデータベース自体が入出力を行うのではない、という点に注意してください。データベースは実際には、ディスク ブロックに対して入出力を実行します。この理由は簡単です。ブロック入出力操作は通常、システム上のソフトウェアとハードウェアにおいて最適化されます。結果的に、データベースのテーブルと索引の物理編成がシステムの性能に劇的な影響を及ぼすことになります。
データベースの領域割り当てとディスク ページ編成を計画するときは、以下の要因を考慮します。
以下のセクションでは、これらの各要因について説明します。
ディスク ページ密度
ディスク ページの密度は、時間の経過によってデータがどの程度変化すると予想されるかによって変動します。細かく検討しなくても、密度の低いページは時間と共にデータが変化したり追加されたりすることへの対応性に富んでおり、データが一杯に詰まっているデータ ページは、ブロック読み取りで取り出せるデータ量が多いため、読み取り性能に優れています。
ディスク管理を簡単にするため、データベース設計者は変化の程度に応じてテーブルをグループ化することができます。このタイプの編成を行うためには、次の 3 つのグループを作ることから始めるとよいでしょう。
- 動的変化の大きいテーブル
- ある程度動的に変化するテーブル
- ほとんど変化しないテーブル
動的変化の大きいテーブルは空き領域が大量にある (30% 程度) ディスク ページに、ある程度動的に変化するテーブルは空き領域が少ない (15% 程度) ディスク ページに、ほとんど変化しないテーブルはほとんど空き領域がない (5% 程度) ディスク ページにそれぞれマッピングするのが適しています。テーブルの索引に関しても、同様なマッピングを行う必要があります。
ディスク ページの場所
テーブルのグループをマッピングした後で、データベース設計者はディスク ページをどこに配置するかを決定しなければなりません。ここでの目標は、複数の異なるドライブとヘッドに作業負荷を分散させてボトルネックを低減または除去することです。以下のガイドラインを考慮します。
- オペレーティング システム、一時的ファイル、またはスワップ デバイスと同じディスク上にデータを置いてはいけません。これらのドライブには、作業負荷をさらに増加させる以前に、既に十分な負荷がかかっています。
- 同時にアクセスされるデータを異なるドライブに置くようにして、作業負荷を分散します。一部のシステムでは、並列入出力チャネルをサポートします。その場合、データを異なったチャネル上に分散させます。
- 負荷を分散させるためにデータを索引処理する場合、データとは異なるドライブ上に索引を置きます。
- データベース ベンダーのガイドライン文書を参照します。
- 使用する記憶装置のタイプ (RAID-5、RAID-10、SAN、SAN、チャネル付加など) はデータベースの性能に影響を及ぼします。記憶装置の製造元が提供する、性能関連のガイドラインを利用してください。
データベース入出力は一般に、データベースの性能における限定要因です。入出力の分散調整は、反復的かつ実験的なプロセスです。推敲のフェーズでデータベース アクセスの性能のプロトタイピングを行い、物理的、また論理的入出力を監視する適切なインスツルメント化を組み合わせることにより、性能の問題を早めに洗い出すことができ、データベース設計を調整する時間的余裕が生まれます。
ディスク スペース割り当て
永続的な設計メカニズムの特性を活用して、格納しなければならないオブジェクトの数を見積もります。オブジェクトを格納するために必要なディスク スペースは、RDBMS ごとに異なります。ディスク スペースを計算するときは、データの追加による増大分も考慮するようにします。データベースに必要なディスク スペースを見積もるには、まず各テーブルに必要なディスク スペースを見積もり、それからすべてのテーブルを合わせた必要領域を計算します。各 RDBMS 製品のデータベース管理者用マニュアルを参考にして、正確なサイズ見積もりの計算式を判断します。テーブルに必要なスペースを見積もるための一般的な手順は以下のとおりです。
- 平均の行サイズを計算します。この計算には、可変長の列に必要な制御情報だけでなく、レコード レベルの制御情報も含めるようにします。
- ページまたはブロック入出力に適合する行数を計算します。ほとんどのデータベースは完全なレコードだけをページまたは入出力ブロック上に格納するため、この行数は、ページまたは入出力ブロックに適合する整数の行数となるようにします。
- 見積もられた量のデータベース レコードを格納するために必要なページ数または入出力ブロック数を計算します。何らかの負荷要因があれば、レコード数の見積もりにそれを反映する必要があります。
- ページまたは入出力ブロックごとの必要サイズに、ページ数または入出力ブロック数を掛けます。
- 索引のオーバーヘッドが付加されるのであれば加算します。
- テーブルの固定オーバーヘッドがあれば加算します。
テーブル スペースの必要量が定義されたら、以下のことを行います。
- 各テーブルに必要な容量の合計を計算します。
- データベース管理のために一定容量のスペースが必要であればそれを加算します。
- トランザクション ログと監査記録の保存に必要なディスク スペースを加算します。
更新が頻繁に発生する環境では、監査記録の保存のために大量の記憶容量が必要になります。主要な商用データベース管理システムのドキュメントには、サイズ計算に関しての詳細な指示が記載されているのが一般的です。データベースに必要なディスク スペースの見積もりを計算するときは必ず、それらの指示を参照するようにしてください。
目的 | データ アクセス クラスの操作を実装するためにストアド プロシージャまたはトリガを使用するかどうかを決定する |
ほとんどのデータベースは、ストアド プロシージャ機能をサポートしています。ストアド プロシージャは、データベース管理システムのプロセス空間内部で動作する実行可能コードです。ストアド プロシージャを使用すると、ネットワークを介してデータ転送を行う必要なしに、サーバー上でデータベース関連のアクションを実行できます。ストアド プロシージャは、慎重に使用すればシステムの性能を向上させることができます。
一般的に使用されるストアド プロシージャには、実のプロシージャとトリガの 2 種類があります。プロシージャはアプリケーションからの指示で明示的に実行され、通常はパラメータを持ち、明示的な戻り値を返します。一方トリガは、何らかのデータベース イベント (行の挿入、更新、削除など) が発生したときに暗黙的に呼び出され、修正対象の行以外にはパラメータを持たず (暗黙的に呼び出されるため)、明示的な戻り値を返しません。
制約機能を有していないデータベース システムでは、トリガは参照とデータの整合性の推進に使用されることが多くなっています。それ以外の場合では、あるイベントによって別のイベントをトリガ (発生) させる必要があるときに使用される傾向があります。またトリガは、セキュリティ上の目的でトリガ イベントを監査するという使用方法もよくあります。
設計モデル内の設計クラスでは、ストアド プロシージャまたはトリガ機能を使用して実装すべきである操作があるかどうかを調べなければなりません。調査の候補に挙げられるのは次のものです。
データベースの性能の改良は入出力の削減を意味する場合が多いことを覚えておいてください。DBMS サーバー上で計算を実行すると、ネットワーク上で受け渡しされるデータ量は削減されるので、計算はサーバー上で実行するほうがよいのです。
性能の向上のためにデータベースをどのように使用することができるかを話し合うため、設計クラスの設計者と作業を行います。クラスの設計者は操作メソッドを更新して、操作の実装に 1 つ以上のストアド プロシージャを使用できるかどうかの指針を示します。
目的 | データ モデルの品質と整合性を保証する |
この作業全体を通じて継続的に、「チェックポイント: データ モデル」を考慮しながら、作業の完全性と品質を評価する必要があります。さらに、データベース設計者はデータベースの実装済み構造を定期的にレビューし、そのデータ モデルが、データベース側で直接行われたすべての変更と整合性を保っていることを保証しなければなりません。データ モデルとデータベース物理構造の同期をサポートする、データ モデリング ツールをプロジェクトで使用している場合、データベース設計者は定期的に、データ モデルの状態をデータベースに照らし合わせてチェックし、必要に応じて調整を行わなければなりません。
まだ修正される予定のない障害がこの時点で識別されたら、変更依頼に文書化し、最終的にはその不具合に関する責任を誰かに割り当てて解決を委ねる必要があります。
![]() |
この内容は、Applied Information Sciences により作成、または部分的に作成されました。 |
Rational Unified Process
|