中瀬といいます。

自分は正規化する・しないの観点として、
・カラムの参照結果が見る時期によって変化するものかどうか
・カラムを用意する事によって、そのカラムが利用されるか
をポイントにしてます。

なので商品購入の際の商品名・単価・数量までは必ず必要な情報
であり、合計・小計・消費税額等はデータ登録時から暫くは固定
かもしれないですが、将来消費税率が変更するかもしれないと
いう状況もありえるのでこれらもテーブルのカラムとして保持する
ようにしてます。

またデータの入出力時の画面への出力数とDBへのカラム数は必ず
しも一致する必要はないわけで、住所の場合
画面上は
・郵便番号
・都道府県
・市区町村
・その下（番地など）
のように分割しても、テーブル上は郵便番号と住所として纏めて
も構わないと思ってます。
（もっともこの住所の情報を使って絞り込みを行いたいというので
あれば分割したままでもよいかもしれませんし、今であれば郵便番号
で絞り込む事も可能ですが）

自分は画面入力用に
・都道府県
・市区町村
のテーブルを持ち、実際住所を格納する際は○○県△△市☆☆町XX
番地のように１つのカラムに収めていました。


<200909180232.AA01376@xxxxxxxxxx> の、
   "[mysql 15024] Re: DBをどこまで正規化すべきか？" において、
   "n.futami@xxxxxxxxxx (二見)"さんは書きました：

> 二見と申します、初めまして
> 
> 下記の件
> 恐らく参考書には、一旦最低限な項目に絞ってみる
> という正規化の事が書いてあるんじゃないかと思います
> 
> 一旦全て正規化して考え、逆正規化の様な事を行い
> 自分が良くＳｅｌｅｃｔする単位に欲しいカラムを用意する事が
> 当方は重要だと思ってます
> 
> 例えば伝票（下記でいう受注履歴）と明細（同注文明細）なんて言い方をしますが
> １明細の小計を明細ＤＢの１カラムに格納するなど私は必要だと思いますし
> 伝票には消費税や合計金額のカラムが有ることも当然だと思っています
> 
> 中にはお店側の計算方法が変わったりしますので
> 途中から計算が変わった場合など、計算式で求めている場合は対応が面倒です
> 　＃消費税の計算が、四捨五入から切り捨てになったとか
> 　　明細単位に消費税を積み上げていたが、購入金額の総合計に消費税を掛けるようになったとか
> 法律の改正で変わる事も有り得なくもないと思います
> 
> また、下記の例で言うと
> 同じ商品番号で単価が変わってしまう商品などが有る場合は
> 当然売った時の単価を明細側に持っておく必要が有るかと思いますし
> 管理画面等で商品の単価を変えれるなら持っておいたほうが無難かも知れません
> 
> この先段階的に消費税が上がることも考えられますので
> 先のことを考慮しながら設計できると良いと思います
> 
> また、郵便番号の件は少々別の話で
> ＤＢ側のカラムを加工して検索するとインデックスを使えなくなったりしますので
> 検索用の項目もアリかなと思います
> 　＃コレは実際に大量のデータで試してみると良いかも
> 
> 余り参考になりませんが
> ＤＢ設計がんばってください
> 
> 以上、宜しくお願い致します
> 
> わたせさんが［2009/09/18 00:00:57］に出された
> 題名「[mysql 15022] DBをどこまで正規化すべきか？」に付いての返信です
> ---------------Original Message-------------------------
> 
> >プログラム歴は結構長いですが、ＳＱＬはかなり初心者です。
> >
> >ＤＢの設計をしているのですが、参考書などには必ず正規化の事が載っています。
> >たとえばその中で、「計算で求められる事を項目にしない」ってのがあります。
> >「導出フィールドの削除」って書いてあります。
> >『商品単価×数量で合計が求められるから、合計の項目は不要』というヤツです。
> >で、私が持っている本を読むと確かにそう書いてあるのですが、
> >必ずしもそれが正しいのだろか？と疑問に思っています。
> >
> >例えば、数種類のジャムの販売のＤＢを作る場合、
> >顧客テーブル、受注履歴テーブル、注文明細テーブル、商品テーブル
> >を考えたとします。
> >受注履歴は、１販売毎に１レコード。
> >その受注ＩＤを持つ注文明細テーブルが複数あり、それが商品テーブルＩＤと
> >数量を持つとします。
> >
> >■具体的には
> >２種類のジャムを、それぞれ２個、１個買ったとすると…
> >・受注テーブル１件(受注ID)
> >001
> >・注文明細が２件(受注ID,明細ID,商品ID,数量)
> >001,01,A,2
> >001,02,B,1
> >・商品テーブル(商品ID,名前,単価)
> >A,りんごジャム,100
> >B,いちごジャム,70
> >だと、受注ID=001の合計額は
> >100*2+70=170円となります。
> >
> >これが、数千レコード分を一覧表で出そうとすると、全て単価×数量を
> >計算しないと出せないワケですよね。
> >しかし、受注テーブルに合計があれば、簡単に出せます。
> >ＳＱＬ文を書いてしまえば、簡単も複雑も関係ないでしょうが、
> >これって、ＤＢのサイズを優先するか、ＳＱＬの実行時間を優先するか？
> >って事で選ぶので良いのでしょうか？
> >
> >当然、注文明細を操作した場合は、受注テーブルの金額を書き直す事を
> >厳守する必要がありますし、商品単価も変更しないという前提が必要ですが。
> >（商品単価は今後の価格改定の可能性を考えると、注文明細に覚えこまして
> >しまうべきなんですよね？）
> >
> >本を読んでると、正規化は正義のような書き方をしているような感じもしますが、
> >本来しなくてもいいようなレベルの事でも、本では説明をする為に、正規化を
> >しているような気がするのです。
> >例えば、上記のようなテーブル例の場合はどうなんでしょうか？
> >私は、受注テーブルに合計を覚えるほうが良いと思うのですが…
> >
> >消費税なんかも悩ましいところです。
> >計算で出せますが、今後税率が変わった場合、レコードの作成時期によって
> >税率を変えるのはかなり非効率だと思うのですが。
> >そうなると、小計、税額、合計を覚える必要があるって事になりますよね？
> >
> >なんだか、１つの質問で長々と書いてしまいましたが、どなたかアドバイスお願
> >いします。
> >
> >
> >他にも、郵便番号を123-456と覚えていた場合、
> >2345や12-345の文字列で検索した場合でも類似として検索できるように、
> >表示用フィールド('123-456')と検索用フィールド('123456')の
> >両方を覚えて、検索するときは数字のみにした値を、検索用フィールド
> >に対して検索させています。
> >確かに、検索するたびにSQLで'-'を抜いたフィールドを作る事も可能だと
> >思いますが、検索用フィールドを常に別で持つのは、古いＤＢの
> >考え方なのでしょうか？
> >
> >-- 
> >わたせ <watase@xxxxxxxxxx>
> >
> >
> >
> 
> ※部署名が変わりました
> -------------------------------------------------------
>   DNP DIGITALCOM
> 　システムソリューション本部
>   プロジェクトマネジメント室　第２ＰＭグループ
> 　　　二見　修康
> 
>   〒141-8001
>     品川区西五反田3-5-20 ＤＮＰ五反田ビル5Ｆ
> 
>     TEL 03-6431-6324 内線 6324
>     FAX 03-6431-6193 携帯 080-2022-6984
> 　  Mail: n.futami@xxxxxxxxxx
> 
> 
> 


--------------------------
中瀬　浩昭

h_nakase@xxxxxxxxxx
http://cmssvr.sytes.net/
--------------------------