前回、概要を説明しましたが、今回はデータ設計で感心した部分をご紹介したいと思います。

データタイプ

データタイプの定義

まず、プロジェクト内において「データタイプ」を定義します。
以下、例です。

これはデータの抽象化設計になります。（設計者の腕の見せ所になると思います。）

この例では、型や桁数を後回しにしています。
(業務要件により、型や桁数が変わると言うことに柔軟に対応できると考えてもらって結構です。)

そして、テーブル設計を具体的に進める際は、テーブルの各項目に「データタイプ」を紐づけます。

よくある問題

顧客へのヒアリングが十分でなく、金額に関わる項目を全て8桁でテーブル設計したとします。
しかし、設計を進めて行くと、次のようなケースが出現します。

・単価は6桁あれば十分、帳票に出力する都合上8桁は多すぎる。
・単価も売価と原価があり売価は6桁、原価は5桁である。
・月別売上の金額は10桁必要。

このようなことがあると、全テーブルの金額に関わる項目を見直さなければなりません。
変更漏れがないように対応を進めようとするとかなりの労力を割きますよね。

データタイプを作る

先ほどの「金額」をデータタイプでいくつか作っておくと便利です。
「売価」、「原価」、「売単価」、「仕入単価」、「合計金額」などに分けて定義すると良いと思います。
データタイプの定義にも漏れや不足があるかもしれませんが、全く考慮していないと、考慮して設計した場合では後戻りの工数が大きく異なります。

例えば、「金額」のデータタイプ一つだけを作って、全てのテーブルの金額に関する項目に紐づけた場合、新たにデータタイプを複数作って紐づけのし直しが必要になります。

しかし、「売価」、「原価」、「売単価」、「仕入単価」、「月別合計金額」を事前に作っていると影響が少なく済みます。
例えば「合計金額」は「月別合計金額と年別合計金額の2種類あった」場合です。
この場合、「合計金額」データタイプを使ったテーブル項目を見直せばよいだけです。

まとめ

設計初期において効果があるだけでなく、運用を進めて行く中で業務の変化による設計変更にも強いです。 売価の金額不足した場合、全てのテーブルの売価を見直すのではなく、「売価」のデータタイプを修正すれば、全てのテーブル定義に反映されます。

変更に強い設計を進めることができるため生産性を高くできると思います。