CRM（といっても、RFM分析などの分析用）で利用されるデータベースと、一般の業務で利用されるデータベースでは、内容が違うと思います。
■データベースの内容の違い（正規化RDBと、データウェアハウス）
一般の業務で利用されるデータベースは、正規化を行い、データの重複がないようにします。
CRMの場合は、過去のデータを保持し（これがデータウェアハウスになるんだけど）、そこからデータを処理加工して、場合によってはサマリーデータを作成し、分析しやすい形にして（これがデータマートになる）データベースに読み込みます。
データマートは作る場合と作らない場合がありますが、いずれにしろ、業務系と違い、過去のデータを保存するため、業務系で行ったデータベースの正規化を崩す等、なんらかの処理が必要があります。
たとえば、正規化したDBだと、受注テーブルと、顧客テーブルがあり、受注テーブルには顧客IDが入り、顧客テーブルに住所が入っています。
ここで、ある商品が、東京地域限定販売商品が、どの区で売れているか、３年間の推移を調べるとします。
そのとき、もし上記のテーブルで処理した際に、２年前まで東京に行ったけど、今年、大阪に引っ越した人がいたとしたら。。。
受注明細で該当商品を検索したら、受注データから顧客IDを拾って、顧客テーブルの住所をみるとすると。。
２年前、買ったのは東京で。。なのに、現在の顧客テーブルの住所をみるから、大阪になってしまいますう（＞＿＜！）。統計結果に、購入地「住之江区」とか出てきて、うん？？ってなことになってしまいます（「大阪市港区」なら、東京にも「港区」はあるので、いいかわるいかどうか、わかんないけど、気がつかない ＾＾；）
これに対応するには、データを入れる際に、正規化を崩し、受注データに顧客住所をいれるか、受注データの更新日も主キーにいれ、顧客データの更新日も主キーにいれ、更新ごとにデータを保存し、更新日も考慮してJOINする（のは、相当面倒です）かしないといけません。
■CRMにおいては、トランザクション・排他制御の概念が必ずしも絶対ではない
一般の業務においては、トランザクション・排他制御の概念は、絶対です。
データに矛盾が生じてしまいます。
しかし、CRMの場合、あつかうのは過去のデータなわけです。
過去は変えられません。
たとえば、業務系において住所変更というのは今起こっていることなので、これはトランザクションでちゃんと制御して、それ以降のデータは、新しい住所に配送しないといけません。
しかし、２００７年１月１日に、その人がどこに住んでいたか？という事実は、変えられません（もちろん間違えることはありますが）。ということは、だれが入力しても、２００７年１月１日に、その人の住所は同じ値になるはずです。打ち間違いとかはあるかもしれないけど、何百回、いつだれが更新しても、過去のデータは同じ値です。なら、排他する必要がありません。かならず同じデータなのですから。
トランザクションに関しても、リトライできるなら問題ありません。
異常終了したら、もう一度リトライすればいいんです。
ただ、打ち間違いやりトライがあるので、リトライしても狂わないように、同じデータがあった場合は上書き、違うデータが来たら追加というようにしないといけません。
この性質を利用して、CRMでは、直接業務系のデータベースを参照しない（参照されると、分析のためのバッチが動くことになり、排他上、困ることがある）ということが多いです。
これから、開発方法の違いがあるのですが、それはまた別の機会に。。
アクセス
トータル
ランキング
