正規化?非正規化?
テーブルを設計にするにあたりどの程度まで正規化したら良いか?
というのは設計者の永遠のテーマですね。
正規化はよく第3正規化まで行うのが適切であると言われます。
詳しい正規化についてはこちらを参考にしてください。
http://www.atmarkit.co.jp/fdb/rensai/db_enginer03/db_enginer03_1.html
業務上、よくある要件として下記のようなものがあったとします。
要件1.ある商品に対する予算を年度毎年月毎にデータとして持ちたい。
要件2.帳票や照会画面で出力する場合には年月を横並びとし、データが0でも出力したい。
さて、設計者は下記2パターンを考えるのではないでしょうか?
設計1.主キーを商品コード、年度、年月とする。
設計2.主キーを商品コード、年度とし、年月は12か月分列とする。
<設計1の長所短所>
--長所
・必要な年月のデータのみを持つことができ、更新ロジックが単純。
--短所
・要件2に対応するために複雑なSQLになりやすい。
もしくはアプリケーション側でなんらかの処理を行う必要がある。
そのためパフォーマンスが要件を満たせるかも懸念される。
<設計2の長所短所>
--長所
・要件2を実装するのが簡単になる。
--短所
・列が多くなるため列にアクセスするために同じような列名を羅列する
必要がありアプリケーション上、効率が悪くなる可能性がある。
・データ更新も列名を意識する必要があり、工夫が必要になる。
これら長所、短所を踏まえたうえで設計を行う必要があります。
通常、設計1を選択する場合が多いかと思いますが、データ量や
その他の要件にも左右されるため、柔軟な対応が必要になるでしょう。
分析関数
Oracleでは8iEEからSQL組み込み関数として分析関数が使用可能になりました。
分析関数とはその名の通り、各種分析向きの機能ですが、
通常よくある要件でも大きな力を発揮します。
<8iから使用可能>
AVG
CORR
COVAR_POP
COVAR_SAMP
COUNT
CUME_DIST
DENSE_RANK
LAG
FIRST_VALUE
LAST_VALUE
LEAD
MAX
MIN
NTILE
PERCENT_RANK
RATIO_TO_REPORT
RANK
REGR_(線形リグレッション)関数
ROW_NUMBER
STDDEV
STDDEV_POP
STDDEV_SAMP
SUM
VAR_POP
VAR_SAMP
VARIANCE
<9iから使用可能>
FIRST
LAST
PERCENTILE_CONT
PERCENTILE_DISC
これらの関数についてどのようなものか検証していきたいと思います。
分析関数とはその名の通り、各種分析向きの機能ですが、
通常よくある要件でも大きな力を発揮します。
<8iから使用可能>
AVG
CORR
COVAR_POP
COVAR_SAMP
COUNT
CUME_DIST
DENSE_RANK
LAG
FIRST_VALUE
LAST_VALUE
LEAD
MAX
MIN
NTILE
PERCENT_RANK
RATIO_TO_REPORT
RANK
REGR_(線形リグレッション)関数
ROW_NUMBER
STDDEV
STDDEV_POP
STDDEV_SAMP
SUM
VAR_POP
VAR_SAMP
VARIANCE
<9iから使用可能>
FIRST
LAST
PERCENTILE_CONT
PERCENTILE_DISC
これらの関数についてどのようなものか検証していきたいと思います。
