DOAデータ中心開発において、テーブルの正規化が重要である。
関数従属性を整理し、正規化することにより更新時異常を防止することができる。
業務の変更によりシステムの再構築が必要となるが、
新たに構築するシステムのテーブルも正規化されているなら、データの移行は簡単になる。
従来と変わらない部分をそのまま転送し、新たに追加された部分の受け皿を用意するだけになる。
一般的に、業務システムへの入力・出力はメモや伝票など非正規化された情報である。
①入力の際に、非正規化情報を正規化するための手続きが必要となる。
②出力の際に、正規化された情報を非正規化するための手続きが必要となる。
業務システムのテーブルの正規化の目的は、更新時異常を未然に防止すること。
将来へのシステム改良に対する、データ移行を容易にすることが目的である。
更新時異常を未然に防止するとは、データベース側に派生、参照、親子関係といった
関連性を用いて構築することで、情報の保管のために然るべき制約を課すことで実現する。
データベースの設計段階で、決定可能な制約をデータモデルとして構築することで、
すべての制約をプログラムで記述する場合に対して、プログラム記述量を大幅に減らすことができる。
プログラムの記述を減らすことは、属人性の排除、システム改変の容易さのため重要である。
プログラムは、動作保障のため記述した内容をテストするための作業が必須となる。
記述量が増えるほど、テストのボリュームも増えることになるので、
プログラムの記述はできるだけ、定型化し、テスト済みのプログラムを再利用する必要がある。
①入力に関しての最重要事項
システムを操作する者の操作をできるだけ省力化することが重要な目的である。
②出力に関しての最重要事項
システムを操作する者、実際の業務を実施する者がミスなく理解しやすい画面、
帳票を出力することが重要な目的である。
業務の最適化と、データベースの正規化は①、②の手順で接続することになる。
インターフェース（項目移送）に関わる部分はケースバイケースであるので、
移送元、移送先の項目を個別に指するプログラムが不可欠になる。
また項目間の演算結果が必要な場合、演算結果を保持する仮想項目、
関連するプログラムも必要である。
DOAを取り入れないシステム開発の場合、非正規化データをテーブルに保管し、
非正規化データに対し演算し、非正規化データとして出力する。
出力データの保存が必要な場合非正規化された情報をテーブルに記録する。
DOAを取り入れない開発の場合、様々な処理が、入り口と出口のPtoP処理となる。
実際の業務システムでは、様々なテーブルに関連する処理が必要なため処理を増やせば増やすほどに
くもの巣のように「がんじがらめ」なシステムになる。
出力に対して、様々にデータが参照される場合、くもの巣よりも、くまで（熊手）を積み重ねたイメージになるだろう。
方法論・設計の手法を持たずにアジャイルするなら「がんじがらめ」繰り返しのアジャイルになる。
データベース、ＲＤＢＭＳを利用したシステムを構築する場合、DOAデータ中心開発を採用し、
然るべき制約のかけられた情報を蓄積し、将来的に変動の少ない情報構造をデータ処理の中心におく。
入力は非正規化さた情報を、正規化しデータベースに登録し、
出力は正規化された情報を、非正規化し表示・印刷する。
内部の正規化されたテーブル群を中心にプログラムされるため、入出力処理がデータベースを中心に
自転車のスポークを放射状につないだようなHUB構造となる。
正規化されたテーブル群の設計書をもとに、編集画面を自動生成するのがXEAD Driverの機能の一つである。
今後の開発としては、３要素分析法で、テーブルを設計する。
テーブルの設計が完了した段階で、編集画面が自動生成されるので、
残る作業は、正規化されていない情報を利用者が使いやすい画面から、
正規化したテーブルに保管するプログラムを作成すること、
正規化されたテーブルを表示・印刷のため非正規化する処理となる。
入出力のプログラムパターンは、経験・業種により蓄積し体系化される、
体系化されることで、マッピング情報をツールを使用し作成、レイアウトできる。
業務システム開発の効率化、自動化を目指そう。
