PSI Labs RSS feed

[設計]SQL設計書の書き方

お久しぶりです。shintaniです。

今回はSQLの設計書について書いてみます。
とはいっても「正しいSQLの設計書」などとおこがましいことを言うつもりはありません。
「今までより多少マシなSQLの設計書」という程度に捉えて下さい。

このような帳票があるとします。
WS000000.JPG

これに対して、下記のような詳細設計書(SQL設計書)を書いているプロジェクトが結構あるかと思います
WS000001.JPG

これでは殆どSQL自体を書いているのと変わりません。
テーブル同士の繋がりや絞り込み条件も分かり辛いです。

これに対し、下記は私が以前関わったプロジェクトで作ったSQL設計書です。
(そこでは ”データ取得図” と呼んでいました)
WS000005.JPG

これはE-R図とは異なるものです。
あくまでSQLの結合方法や条件設定などを記述したものです。
この形式のSQL設計書には以下のようなメリットがあります。

---------------------------------------------------------------------------------------

1 図として記述することで書いた当人も理解が深まる
2 テーブル結合、条件などが一目で分かる。結合条件の記述漏れもすぐに分かる。
3 画面、帳票は「ヘッダ」と「データ」部分に分かれることが多いが、それらが1対nで結ばれているかどうか分かる。
4 この形式ならばお客さんもデータ取得の方法が分かりやすい。
  「画面のデータがおかしい」という不具合が出た際、これを見せてすぐに正しいデータの取得方法が分かったことも多い。

---------------------------------------------------------------------------------------

「副問い合わせやUNION ALLとか色々あるだろう!その場合はどうするんだ!?」
という意見もあると思いますが、例えばunion allは下記のように書きました。

【UNION ALLの場合】
WS000006.JPG

ただ分析関数など図オンリーでは対応仕切れないものもあり、
その場合はテーブル結合条件だけ書いてその他は文章で記述しました。

様々なSQLについてこの形式で記述しましたが、殆どの場合で
「仕様書を記述する手間 < 実際にSQLを作成する手間」
が成り立ち、別の人がこれを元に実際のSQLを作成することが出来ました。

今も試行錯誤している途中ですが、それなりに使える設計書ではないかと思います。
参考にして頂ければ幸いです。

ではでは。



【2017/04/23 追記】

GROUP句やソート条件などの書き方について、続きの記事を書きました。
[設計]SQL設計書の書き方(続き)

よろしければこちらもご覧下さい。