非正規化

パフォーマンス向上のため、正規化されたテーブルの結合を事前に行い、あえて冗長性を持たせるデータベース設計手法。テーブル結合の処理コストを削減できるが、データの冗長性による更新時の不整合リスクが増す。

性能向上を目的として、正規化されたテーブルにあえて冗長性を導入する手法。結合処理の削減のためにテーブルを統合したり、集計値を保持する導出列を追加したりする。更新異状のリスクとトレードオフになる。

正規化した表を、検索の性能を高める目的で、あえて結合したり、冗長な列や集計値を持たせたりすること。表の結合の処理を減らして問合せを速くできるが、同じデータを複数箇所で持つため、更新時に不整合が起きないよう管理する必要がある。

スタースキーマのディメンションテーブルをさらに正規化し、階層ごとに別のテーブルに分割したデータモデル。形が雪の結晶に似ることからこう呼ぶ。データの重複が減って更新時の不整合が起きにくいが、集計時の結合が増えて問合せが複雑になり、性能が落ちやすい。

表のデータを行単位ではなく列単位にまとめて格納するデータベース。集計に必要な列だけを読めばよく、同じ列には似た値が並ぶため圧縮率も高いので、大量の行を対象にした分析処理（OLAP）に向く。1行ずつの挿入や更新は行指向より不利で、データウェアハウス向けの製品やクラウドのDWHサービスに多く採用されている。

概念データモデルを、採用するデータベースの方式（関係データベースなら表・列・主キー・外部キー）に沿って表し直したデータモデル。正規化によってデータの重複と更新時異状を取り除き、データ型や制約を定める。どの記憶装置にどう格納するかといった物理的な事項には立ち入らない。

属性の組Xが決まれば属性Yが一意に決まり（X→Y）、かつXのどの真部分集合からもYが決まらない関数従属。例えば、{受注番号, 商品番号}→数量で、受注番号や商品番号の片方だけでは数量が決まらない場合が当たる。第2正規形は、非キー属性がすべての候補キーに完全関数従属している状態である。

複数の属性からなる候補キーの一部だけで、非キー属性が決まってしまう関数従属。例えば、{受注番号, 商品番号}がキーの表で、商品番号だけから商品名が決まる場合が当たる。部分関数従属があると同じ商品名が何度も現れて更新時異状の原因になるので、第2正規形への正規化で別の表に分離する。

X→Y、Y→Zが成り立ち、YからXが決まらないときに、XからZがYを介して間接的に決まる関数従属。例えば、社員番号→部署コード→部署名の関係で、部署名が社員番号に推移的に従属する場合が当たる。非キー属性が他の非キー属性に従属している状態なので、第3正規形への正規化で部署の表を分離する。