アドオン/正規化の編集

比較や演算などの操作において''望ましい性質を持たない形のものを望ましい形（正規形）に変形させること''を指し、規格化やnormalizationとも呼ぶ。

具体的には、[[ユニコード>SAPの構成/ユニコード]]やRDBMSがこれに属する。

* 概要 [#s3572210]
基本的にSAPで語られるのはデータの正規化と考えて差し支えなく、以降はこれを主題とする。
[[テーブル>SAPのオブジェクト/テーブル]]設計にあたっては、''必ず意識すること''。

** 第一正規化 [#f3eb6239]
繰返部分を複数のレコードに分割し、排除すること。''キー項目で揃える''というイメージ。
第一正規化をした結果を第一正規形と呼ぶ。

ここで言うキー項目は主キーとも呼ばれ、要は「コレが決まればデータが一意となる」という項目のこと。
例えば[[得意先コード>得意先マスタ]]が分かれば名称や住所は一意となり、この関係を関数従属と呼ぶ。
主キー全てで一意となる関係を完全関数従属、主キーの一部で一意となる関係を部分関数従属、[[品目マスタ]]から[[基本ビュー>品目マスタ/基本ビュー]]の[[品目グループ>品目マスタ/品目グループ]]が割り出せるなど主キーから間接的に一意となる関係を推移関数従属と呼ぶ。

** 第二正規化 [#ad5556b0]
部分関数従属する項目を分離することを指し、その結果を第二正規形と呼ぶ。

** 第三正規化 [#g3615aab]
主キー以外のキーに関数従属する項目を分離することを指し、その結果を第三正規形と呼ぶ。

* 正規化の是非 [#ge693d07]
主にアドオンテーブルの項目定義となるわけだが、正規化という概念が自分自身に定着すると、正規化されていないものが許せなくなる。美しくないものと認識してしまうようになる。

これはシステム屋として必ずしも悪いことではないのだが、「正規化をしない」ことにも理由はあり、大きくは２つ。

** テーブルアクセスが増加する [#j8f4483f]
キー同士での紐付けを行い、各所で多重にデータを保持しないことで不整合を発生させないようにするわけだが、逆に言うと一意となった項目を取得するためには色々な関連テーブルを検索しなければならなくなるということ。

DBアクセスが増えるデメリットはあっても、良いことはあまりない。
実例を挙げれば、BSEGにロジ伝票やそこから追いかけることができる項目が何故存在するのか？ということ。

** その時点のデータのスナップショットとして [#h94c33c9]
ある事例では組織項目の名称をいちいちアドオントランテーブルに保存していて、何でそんなことをしなければならないのか？と不思議に思ったこともあるが、正体がこれ。

具体的に言うと、例えば請求書などの外部帳票について、相手先の社名が変更したり住所が移転したりということはある話で、発行元の自社組織名が過去は違ったなんてことは枚挙に暇がない。

マスタで履歴管理すればいいじゃん？という声もありそうだが、マスタの内容を提案させて伝票で打ちかえるなんてことは日常茶飯事なわけで、そういったマニュアル入力も含めて「その時点での処理を再現可能なスナップショットとしてのデータ」という役割はある。

~
~
CENTER:【スポンサードリンク】
#htmlinsert(amazon_book_sap_system_implement)
~
~
----
#pcomment(reply)

タイムスタンプを変更しない