Views: 80
・DB設計
どのシステムでも業務で使用するデータはDBに格納し、
必要なときに必要なデータを取り出せるようにします。
このあたりの考え方は最近のシステムは大体同じような考え方をして作られています。
データの行き着く先はDBであり、取り出し元もDBである。
業務システムの世界では全ての道はDBに通じるのです。
データをどのようにまとめて、どのように配置すればアプリが作りやすく、かつデータ検索の
効率がよくなるのかを設計するのがDB設計です。
DBを設計するにあたり、まずは業務で使用するデータを洗い出す必要があります。
まったくシステム化されていない業務領域をシステム化するのであれば現行業務で使用している
帳票からデータ項目を抽出します。
既にシステム化されている業務領域の場合は、現行システムのDBからデータ項目を抽出します。
また新システムでは新たな機能を追加するのであればその機能を実現させるためのデータも
必要になると考えられますので、あらかじめどのようなデータが発生するのかを想定します。
データ項目を抽出した後は、それらを統合し、テーブルレイアウトに設計してゆきます。
DBの設計は画面やバッチというプログラムの設計と同時に行ってゆきます。
DOA(データオリエンテッドアーキテクチャ)と言う考え方があり、これに準拠する形で
開発をすすめていくことが多いと思います。
DOAとはまずデータ構造を決めてしまえばデータを処理するロジックはなんとでもなるという考え方です。
たしかにテーブルレイアウトが変更されて、項目が増えたりするとその複数のプログラムに影響が発生します。
逆にテーブルレイアウトが確定されていれば、プログラムが変更されても影響範囲はプログラムに
限定されるのでインパクトは少なくなります。
DB設計は画面設計やバッチ設計と並行して行うものですが、なるべく早期に精度が高い
データ構造やテーブルレイアウトを確定させてしまうことが手戻りが発生せず、効率よく開発を行うための
鉄則です。
テーブルはどのように設計したらいいのかというと、一概にはいえませんが
まずはデータの正規化を考えます。データの管理は1箇所で行うようにするのです。
同じデータを複数のテーブルで管理すると、データの内容が変更された場合のメンテナンスが
大変になります。
正規化の考え方についての説明は割愛しますが、第三正規型のあたりまで正規化すれば充分だと思います。
ただし、正規化を進め過ぎると、情報の検索を行うに当たり多数のテーブルを結合させる必要が
出てきます。テーブルの結合が多数発生すると検索コストは大きくなり、パフォーマンスの劣化につながります。
正規化により情報の持ち方を整理しつつ、アプリケーションのパフォーマンスへの影響も考慮することで
最適なDB設計を実現させる必要があります。
・バッチ設計
バッチ設計において考慮することは処理性能を劣化させないための設計です。
大量のデータ処理を行うので、少しでもボトルネックがあるとたちまち処理時間の目標値をオーバーしてしまいます。
夜間バッチの更新処理を行う際は、オンラインからの更新を抑止するため、ユーザはシステムを使うことが出来ません。
バッチの遅延により、ユーザがシステムを使用できなくなり、機械損失を発生させる事は許されないので、少しでも早く処理が終了するように設計を行う必要があります。
処理速度を上げるためには無駄な処理を減らす必要があります。
データ件数の適切な絞込みを行ったり、ファイルI/Oの回数を減らすようにする、
DBアクセスの際には適切な実行計画が選択されるようにする、といった工夫が必要になります。