【DB概論】データベース設計の重要性とデータ中心アプローチ：できるエンジニアになる！ ちょい上DB術・基礎編（5）（1/2 ページ）

デキるエンジニアになるためには、DB技術の基礎は必須です。本連載では、豊富な実例と演習問題で、プロとして恥ずかしくない設計手順を解説します。DB設計のポイントとなる汎用的なケースを紹介しているので、通常の業務とは異なる場合でも応用できる「共通の考え方」を身に付けられます。

[中村才千代，エディフィストラーニング]

※本連載は、中村才千代著『現場で使えるデータベース設計』の第1章 「データベース概論」を、一部修正して転載するものです。

　　　　　　　　　　　　　　　　　第4回へ

　これまで、データベース設計に関する話を中心に説明してきましたが、システム構築の全体工程を見る中で、他の開発工程との関連を見ておきます。

　次の図で、システム構築の際の全体工程の概要を見ることができます。 データベース設計の工程が他の工程とどのように関わっているかを確認します。

図1 システム構築の全体工程（クリックで拡大します）

　システム構築工程の他工程との関係で、特にデータベース設計と関係が深いところを説明します。

　システム化計画でシステム全体の方向性を鳥撤した上で、データベース設計の概念設計に入ります。ここは、トップダウンでシステムの全体像をつかんだ上でデータベースの設計をする重要な工程です。システム化計画で出た企業の経営層の戦略などをインプットにして、将来のシステム像をにらんだ設計を行う必要があります。一方、現行業務に沿った、アプリケーション開発の要件定義、概要設計工程と同期を取りながら、データベースの概念設計を進めていきます。

　方式設計は、データベース設計の物理設計と深く関わっています。物理設計の実装段階で具体的なメモリ要件やディスク構成の最終的な詰めを行いますが、次のようなことは、ユーザー要件と照合してあらかじめ洗い出して検討しておく必要があります。

• システム構成
  • クラスタ化の検討
  • 分散データベースにするか
  • ディスク構成はRAID構成か
• アプリケーションの配置
• ネットワークの帯域幅計算
• バックアップリカバリツールはサードパーティ製品を採用するか
• メモリ要件
• OS、データベースの種類

　また、方式設計段階では情報不足で決定できない部分については、アプリケーション開発工程、データベース開発工程を担当しているグループと随時連絡を取りながら、追加・修正を行っていきます。

　アプリケーション開発の基本設計フェイズ（外部設計）工程と同期を取りながら、データベースの概念設計（詳細設計）を進めていきます。

　アプリケーション開発の基本設計フェイズ（外部設計）工程では、入出力とユーザーインタフエースが決まりますので、ここで業務上扱うべき属性が漏れなく洗い出せるはずです。

　アプリケーション開発の基本設計フェイズ（内部設計）工程と同期を取りながら、データベースの論理設計を進めていきます。

　アプリケーション開発の基本設計フェイズ（内部設計）工程では、ジョブフローおよびプログラム（さらに小さいレベルではモジュール）で使用するフラグ類やコード類の仕様が決まるので、それらのうちデータベースで管理すべき属性を漏れなく洗い出すことができます。また、データベースに発行されるSQLが明確になるため、性能要件を考慮した索引設計を行います。

　アプリケーション開発の詳細設計〜単体テストフェイズ工程と同期を取りながら、データベースの物理設計を進めていきます。

　実際にテーブルを作成し、物理的なディスク上にテーブル類を配置します。

　テスト工程でアプリケーションを実行し、必要に応じてSQLのチューニング、索引の再考、物理的な格納方法の試行を繰り返します。

　テストは、連結テスト、総合テストでも性能テストを繰り返します。データ量の違い、単位時間当たりのトランザクションの量が異なると、異なる結果が出ることは容易に想像できます。なるべく実際に適用される状態に近い状態でテストを繰り返してください。

　標準化という作業が他の工程とは独立しています。大きなレベルでは、設計全般における基本方針の標準化、ドキュメント様式の標準化、非正規化などのルールの標準化などが挙げられます。

　詳細レベルでは、アプリケーションとデータベースに共通で使用する列や表の命名規則、列の桁数やデータ型、共通データ型として定義するドメイン、業界で標準に使われているコード類（商品コードや住所コード）の扱い方について、データベースの中で使用するコード類の設計などを、それぞれに調査、判断するために重要な役割を果たします。

　システム構築の手順は、アプリケーション構築とデータベース構築、インフラ構築が連携をとり合って初めて成功します。各フェイズが設けてあるのは、それぞれのフェイズの終わりで相互に整合性が取れているかどうかの確認作業を行うためです。

　必要に応じて随時連絡はとりあうのは当然ですが、少なくとも各フェイズの最終場面で各工程のアウトプットをつき合わせ、認識に相違がないことを確認して次のフェイズに進んでください。認識の食い違いによって工程の後戻りが発生した場合の時間と費用のロスは、皆さんが想像している以上の損失につながります。