テーブルによるデータベースの前に、カード型のデータベースで考えてみよう。
全てのカードを区別できるように番号や名前を割り振り目次とする。（目次の重複は不許可）
複数の番号や名前を組み合わせて目次を作成してもよい。
関連のある記録は同一のカードに書くことにする。
この時、カードは目次の順に並べなくてもよいことにする。番号に抜けが有ってもよい。
新しいカードを適当な場所に追加したり、不要なカードを削除してもOK
どんな順番になっていてもデータベースのインデックス機能で高速に検索できると考えておく。
カードを高速に並べ替えることも期待してよい。
インデックス、目次、主キー、複合キー、候補キー、など色々な呼び方がある。
目次は番号でなくてもよい
a-d
1-4
ねずみ-うさぎ
(a-1) ～(c-3)
1つのカードに目次が複数あってもよい。
下の図の上段のカード列は 数字の目次 と 文字の目次 がある。
下の図の下段のカード列の目次は それぞれ上のものと共通である。
次で、これらのカードを目次を合わせて１つのカードにまとめることを考える。
以下のカード列の記録は下のテーブルの形式に書き直すことができる。
ここで目次は 主キー として扱う。
カードの記載事項に見出し（フィールド名）を付けて整理する。
候補キー（主キー）を２つもつテーブルに書き直せた。
その下のテーブルは 複合キー 目次3 によるテーブルの例。
カードの記載内容に繰り返し項目（アやウの箇所）が生じる場合は以下の様に目次（主キー）を工夫してテーブルに変換する。
上の図で、下段の目次1と目次2の複合キーから導かれる項目4の値は 目次１の値が4のところ以外（２や１の値）は図からは見えていない。
同じ目次になるテーブルは1つのテーブルにまとめる。
わざわざ分割する必要はない。
上の図の、下段のテーブルを目次２の番号と目次1の番号で上段のテーブルと纏めるときには値２と４が記録されていないので注意が必要。
デフォルト値を決めておいて一つの表にまとめた際に利用するか、NULL値として空欄で記録することになる。
第３正規形に正規化が必要な例。
項目1から項目2に関数従属があるとする。
候補キー（主キー）から推移的従属が非候補キーの属性の項目2に生じているので第三正規形ではない。
第２正規形に正規化が必要な例。
目次1と目次2の複合キーが候補キー（主キー）のとき、目次2だけに項目1が関数従属するとする。
候補キーに完全従属しない（目次1に無関係に目次2だけで項目1が決まる）属性があるので第2正規形ではない。
さらに、 （○目次２ 項目1）のテーブルには ４ ●● のように正規化前のテーブルでは追加不可能なレコードを記録できるようになる。
ボイス・コッド正規形に正規化が必要な例。
非候補キーの目次2が非候補キーの項目1に関数従属する。
候補キーではない属性からの関数従属（自分自身への関数従属は除いて）が存在するのでボイス・コッド正規形ではない。
第4正規形に正規化が必要な例。
目次1、目次２、目次３の複合キーが主キー。
全てのフィールドが主キーを構成しているので、自動的に全ての属性が候補キーに完全従属する。（自明）
よってボイスコッド正規形であるが、目次1を決定すると目次2と目次3の集合が定まり目次2と目次3は独立であるとすると、目次1に目次2は多値従属している（同様に目次1に目次3も多値従属）。
属性の間に多値従属性が有るので第4正規形ではない。
第５正規形に正規化が必要な例。
目次1、目次２、目次３の複合キーが主キー。
目次1 目次2
と
目次２ 目次３
と
目次1 目次３
の非候補キーを新たに候補キーとするテーブルに情報無損失分解できるので第5正規形ではない。
ここで（目次１ 目次２）テーブル と （目次1 目次３）テーブル を結合すると、元のテーブルには存在しない B 〇 y と B 灰色〇 x のレコードが生成されてしまう。
この不要なレコードは（目次３ 目次２）のテーブルを結合することで除去できる（ 〇 y と 灰色〇 x のレコードは存在していない ）
この様に第5正規形に正規化した際に分割された表全てを結合する必要があることに注意する。