シリーズ「開発の初めから順番に書いていってみる」の続きです。
今、外部設計の段階で、要求仕様から、詳細設計までの間（ここを外部設計と、ここでは読んでいるわけですが）の手順は、以下の手順で行うと、流れに飛躍がなく説明がつくということを書きました。
（１）入出力の媒体をきめる。 （２）その媒体ごとにフレームワークを決定する。 なければ、入出力方法を決定する。 （３）そのプロセスの起動方法を考える なければ、起動モジュールを考える。 （４）起動モジュールから、（２）の呼出し手順を考える （５）その処理部分をどうするか、考える。 （６）そうすると、細分化された入出力、処理部分ができる。 ここで、あわせたいものは、あわせる （７）処理部分を、ワーカーさんに渡せるまで落とし込む。 |
だけど、実際にやられるのは、こんなかんじだと書きました。
（あ）フレームワークの確認から、全体的なプログラムの書き方を決める （い）画面の設計をする （う）ＤＢの設計をする、（その他外部の設計をする） （え）プログラムを適当に詳細化し、詳細設計に持っていく |
で、前回までで（い）をやりましたので、今回は「（う）ＤＢの設計をする」です。
■ER図から、テーブル定義書をまとめる
とはいえ、実際にER図ができていたとしたら、以下の手順で、テーブル定義書はできます。
（１）エンティティがテーブルとなりますので、
エンティティ名をテーブル名にしてください
エンティティ名が日本語なら適当な英語名を付けてください
（２）エンティティの属性が、テーブルの項目となりますので
属性名を項目名にしてください
属性名が日本語なら適当な英語名を付けてください
主キーの場合、主キーのチェック欄にチェック（ないかもしれない）
外部キー（FK,参照キー）の場合、そのチェック欄にチェック（ないかも）
型をテキトー（いや、適切に）決めてください
NotNullかどうかきめてください。
（３）ER図にはないけど、インデックスを適当に（適切に）はってください。
エンティティが多対多の場合や、テンポラリのテーブル、作業用のテーブル（たとえば、最大件数テーブルなど）がある場合には、エンティティにないテーブルがあることがありますが、たいてい、エンティティはテーブルです。
なお、正規化はおこなっているものとします。
正規化の方法については、
第一正規形
第二正規形
第三正規形
について書いたので、ここでは省略します。
■テーブル定義書から、プログラム、テストデータの自動生成
テーブル定義書は、プログラムやテストデータ、SQL文の自動生成の対象となることがあります。
フレームワークの段階で、フレームワークを利用するかどうかにかかわらず、DBアクセスの方法は決めておくはずです。
この理由は、
（１）方法を統一しておかないと、どこでトランザクションがスタートするかわからず、二重にトランザクションをスタートさせてしまったりする（トランザクションの入れ子は、入れ子どおりに処理されることは保障されていないケースもある）。
（２）もし、パフォーマンスが出なかったとき、DB入出力をいっぺんに直さないといけない。そのため、DBアクセスロジックを散在させたくない。
（３）DBアクセスのパフォーマンスは、SQL文の書き方に依存する部分もあり、このとき、その手法について全員に説明することは困難である。なので、一箇所にまとめて、一部の人たちだけでSQLを書くようにしたい
（４）書き方を決めて、自動生成させて、効率化したい
などなどです。。
で、書き方が決まっているのなら、自動生成できます。
で、ソースコードだけでなく、SQL文のCREATE TABLEなど、テーブル作成も自動生成できます。
テストデータに関しては、テストデータを入れてもらわないとできないので、Excelなどから、テーブル定義に基づき、データを入力してもらい、テストデータのSQLを作成します。
ちなみに、テスト項目も自動生成できるんですけど。。
このように、テーブル定義から、ソース、テーブル作成、テストの各ソース・ドキュメントを自動生成します。
どのようにやるかというのは、それだけで、シリーズができてしまうと思うので、今回は、やめときます。
■そのほかの入出力
そのほかの入出力についても、入出力の種類ごとに、ドキュメントを作ります。
ドキュメントは１種類について、順番があるモノは順番を書いたもの（画面遷移など、メッセージシーケンスもこれ）、それと、それぞれのメッセージなり、フォーマットなり、レイアウトといった入出力内容について書きます。
そして、各入出力は、フレームワークの段階で、どのような形でプログラムするか決めておくべきであり、決まっていれば、多くのケースで、そのドキュメントから、ソースなどが自動生成できるはずです。
ということで、外部入出力全般について説明したこととして、次回は、「（え）プログラムを適当に詳細化し、詳細設計に持っていく」について書きます。
