開発対象となるアプリケーションの帳票を，一目見さえすれば，必要なテーブル構成は一瞬で思い浮かぶスキル

発対象となるアプリケーションの帳票を，一目見さえすれば，必要なテーブル構成は一瞬で思い浮かぶスキル
を身につけたいのですが、私にはできません。

どのような観点、手順、方法で思い浮かぶ事ができるのでしょうか

ノウハウを教えてください。

サイトの紹介でもかまいません。初心者でもわかるように教えて頂けると助かります

No.1 回答者： kmee 回答日時： 2023/07/16 11:03

方法は一つではないので、あくまで私の考えとして。

(1)パターンを覚える。
(2)分析する癖を付ける。
(3)自分が手と紙と鉛筆でやるなら、どうするだろうか、考えてみる。
その内容をできるだけ厳密かつ具体的に言語化してみる。
(4)データベースに格納した方がいいことと、データベースで計算した方がいいことと、プログラム中で処理した方がいいことを分ける。
それぞれにメリットデメリットがあるので、他の条件等を元に判断する。
(5)「データベースの正規化」を考える。


(1) よくあるパターンを覚える。
そのまま使えなくても、少しの手直しで使えることも多い。
やってはいけない「アンチパターン」も覚える。

「覚える」といっても、丸暗記しろ、ということではない。
そんなものがあったなぁ、と必要なときに思い出せる程度で十分。
あとは、実際に使うときにマニュアル等を読めばいい。


(2) 分析は、他の全ての内容に関係してきます。
「私にはできません。」
なんでできないのですか? それを考えたことありますか?
「何故できないのか」を分析することで、効果的な解決策がわかるかもしれません。

帳票も、分析が必要です。
そこに書いてある文字列は何なのか。
全部で共通なのか?請求先毎に共通なのか?明細行は?...


(3)「自分でやるなら」がわからないと、他人であるコンピュータに教えることなどできません。


(4) 例えば。請求データの場合
取引日,単価,数量,合計金額,税率,消費税額,合計税込金額
くらいのデータが思い浮びます。
合計金額は 単価 * 数量 で求められるので、列として用意する必要はありません。
ですが、帳票を出す度に計算が発生するかもしれないそんな方法よりも、予め単価 * 数量の結果を「合計金額」列に入れておいた方がパフォーマスがいいかもしれません。

(5)
https://ja.wikipedia.org/wiki/%E9%96%A2%E4%BF%82 …

正規化を知らないのと、知っていてあえて正規化しないのとではまったく違ってきます。

まずは正規化を考慮していないテーブルを考えて、それを正規化する、というのもデザイン手法の一つです。

例えば、請求書なら、まずは1枚の全ての欄を列にしたテーブル
行1品名,行1単価,行1数量,行1合計金額,....
行2品名,行2単価,行2数量,行2合計金額,....
を考えて、それを正規化していけば
・請求先、商品等のマスタテーブル
・請求書伝票、請求書明細等のテーブル
とありがちな構成になっていくと思います。