データ分析と標準化

• ＥＲ図では、エンティティ間に「関係があるか無いか」を考えるのが 第一である。現実世界的に見て関係がありそうか無さそうか、 という曖昧な概念ではなく、構築しようとしている「システム」に於いて、 関係する属性が実際にあるか否か、ということである。 社員と顧客は、実世界では密接に関係があっても、 データベース上の「社員」と「顧客」に共通する属性が無ければ 直接的には関係が無い。 一般には、システム上の関係スキーマ
  関係名 (属性名1, 属性名2, ... ,属性名n)
  で、関係名をエンティティを捉え、共通属性があるものの間には 「関係がある」と判断して良い。
• 「関係があるか無いか」について、全てのエンティティ間を 時間をかけて丹念に調べれば、ＥＲ図は書ける。 (10個のエンティティがあったら、
  1-2,1-3,1-4,...,1-10,2-3,2-4,....,2-10,......,9-10
  と、45通りの組み合わせについて、一つ一つ、関係があるか 無いかを判断していくわけである。 慣れないうちは、こういう地道なチェックをした方が良い。)
  一方で、それぞれの関係のカーディナリティについてだが、 これは難しい。 単純に、1対1か、1対nか、n対nかを調べ、n対nのものは、 関係エンティティを間に挟んでn対1、1対nの関係に分割する、 というような分析をするのに役立つが、 何が1対1で、何が1対nなのか、現実的な例で 少し慣れておいた方が良い。
  
  • 部(1)-課(n)、課(1)-社員(n) ……こういうのは分かりやすい。
  • ランク(1)-商品(n) ………ある一つのランクコード(Ｂ級、Ａ級、特級などの うちの一つ)に属する商品は複数ある。一方、ある商品は、 必ず、ある一つのランクに対応する。これもまぁ分かりやすい。 外部キーの関係になるわけだ。
  • 発注(n)-商品(n) ………一回の「発注」で、いくつもの商品を 同時に発注できるので、ある「発注」に対して、対応する「商品」 は複数ある。逆に、ある一つの商品に注目した時には、 同じ商品が昨日の「発注」にも、今日の「発注」にも現れているかも しれないので、対応する「発注」は複数になる。 これではコンピューターで扱いづらいので、
    発注(1)-発注明細行(n)、発注明細行(n)-商品(1) ………のような 関係エンティティを間に挟む。
• 具体例はこちら

◆初心者向け注意点

• 表結合
  幾つかの表を結合して参照する時、 「どちらかの表に無い行(フィールド)は選択されない」 ことに注意する。 当たり前のことだが、例えば、「１０個未満しか売れなかった商品の一覧」 を求めようとしてＳＱＬを書く時に、 販売実績データを元にして一覧を求めようとすると、 「１個も売れていない商品」については実績が無く、 一覧に入ってこないことになる。
• マスタの有効期間
  商品コードの再利用、人事マスタにおける異動など、 マスタが更新されるような場合には、 過去のトランザクションデータとの整合性は取れなくなる。 あるシステムでの、キー項目のコード設計に着目し、 「システムを通じて一意」なのか、「１年で再利用されることもある」なのか、 よく確かめること。 もし、再利用を前提としたコードがあるなら、非正規化して、 将来に渡って残したいマスタの項目を実績データの中に重複して持たせた方が 良い場合もある。
• 主キーと候補キー
  「候補キー」とは、その行(フィールド)を一意に識別する列 または列の組み合わせのことである。 「主キー」は、候補キーの性質を持ち、 更に非ＮＵＬＬ制約、つまり必ず値が存在する、という制限を持つものである。 候補キーや主キーというのは列(タプル)の制約条件であって、 インデックスに対応しているか否かとは関係が無いので注意。 (大抵は主キーに対してインデックスを張るので、よく混乱する。)
  「候補キー」の正確な定義はこちら。