第3章 CRM系统概念模型设计

第3章：CRM系统概念模型设计——识别核心实体与全局ER图

好，咱们进入正题。概念模型设计，说白了就是画一张“业务地图”。你想想看，CRM系统再复杂，核心也就是那几样东西：客户是谁、谁在跟进、卖什么、怎么卖、钱怎么收。今天我就带你把这五个核心实体拎清楚，再把它们之间的关系理明白。

3.1 核心实体识别：CRM的“五脏六腑”

我在做第一个CRM项目时，犯过一个低级错误——把“客户”和“联系人”混在一个表里。结果呢？一个公司有5个对接人，数据冗余得一塌糊涂。后来我学乖了，实体拆分一定要遵循“业务独立性”原则。

咱们逐一来看这五个核心实体：

实体名称	业务含义	典型属性（举例）
客户（Customer）	购买产品或服务的组织/个人	客户ID、公司名称、行业、规模、客户等级
联系人（Contact）	客户组织内的具体对接人	联系人ID、姓名、职位、手机、邮箱、微信
商机（Opportunity）	潜在的销售机会，有金额和阶段	商机ID、预计金额、销售阶段、预计成交日期
订单（Order）	已成交的销售单据	订单ID、订单金额、下单时间、支付状态
产品（Product）	可销售的商品或服务	产品ID、产品名称、单价、库存量、产品分类

我的经验之谈： 客户和联系人一定要分开。一个客户可以有多个联系人，一个联系人也可以属于多个客户（比如顾问公司）。这是典型的“多对多”关系，需要中间表来解耦。

3.2 实体间关系定义：谁跟谁“有一腿”

实体识别完了，接下来就是连线。我习惯用“业务流”来推导关系——从客户到订单，中间经历了什么？

3.2.1 客户 ↔ 联系人

关系类型： 多对多（N:M）
业务解释： 一个客户有多个联系人（销售、技术、采购），一个联系人可能同时对接多个客户（比如渠道商）。
实现方式： 建立中间表 customer_contact，字段包括客户ID、联系人ID、角色（如“决策者”）、是否主联系人。

避坑指南： 我曾经在一个项目中，直接把联系人ID作为客户表的外键。结果客户换了对接人，我得改整张表。后来改成中间表，灵活多了。

3.2.2 客户 ↔ 商机

关系类型： 一对多（1:N）
业务解释： 一个客户可以有多个商机（比如同时谈三个项目），但一个商机只能属于一个客户。
实现方式： 在商机表中添加 customer_id 外键。

3.2.3 商机 ↔ 订单

关系类型： 一对一（1:1）或一对多（1:N）
业务解释： 一个商机最终可能转化为一个订单（标准情况），也可能拆成多个订单（比如分期交付）。
实现方式： 在订单表中添加 opportunity_id 外键，允许为空（商机未转化时）。

注意： 商机和订单之间不是强制关系。有些订单可能来自老客户直接复购，没有经过商机阶段。所以外键要允许NULL。

3.2.4 订单 ↔ 产品

关系类型： 多对多（N:M）
业务解释： 一个订单包含多个产品，一个产品出现在多个订单中。
实现方式： 建立中间表 order_item，字段包括订单ID、产品ID、数量、单价、折扣。

3.3 绘制全局ER图

好了，关系都理清了。现在咱们把这些实体和关系画成一张ER图。我一般用“矩形表示实体，菱形表示关系，椭圆表示属性”这种经典画法。

下面我用文字描述一下这张图的布局，你可以照着画：

+----------------+       +------------------+
|    客户        |       |     联系人       |
| (Customer)     |       | (Contact)        |
+----------------+       +------------------+
        | 1                      | N
        |                        |
        | N                      | M
        +-----------+-----------+
                    |
            +-------v-------+
            | 客户联系人关系 |
            | (中间表)      |
            +---------------+

        +----------------+
        |     商机       |
        | (Opportunity)  |
        +----------------+
                | 1
                |
                | N
        +----------------+
        |     订单       |
        | (Order)        |
        +----------------+
                | N
                |
                | M
        +----------------+
        |   订单明细     |
        | (OrderItem)    |
        +----------------+
                | M
                |
                | 1
        +----------------+
        |     产品       |
        | (Product)      |
        +----------------+

核心关系总结：

客户 ↔ 联系人：多对多（通过中间表）
客户 ↔ 商机：一对多（客户ID在商机表中）
商机 ↔ 订单：一对一或一对多（商机ID在订单表中）
订单 ↔ 产品：多对多（通过订单明细表）

3.4 设计时的几个“坑”

嗯，这里我要多说几句。概念模型设计阶段，很多人容易犯这几个毛病：

过度设计： 一开始就把所有可能的属性都加进去。我建议先只加核心属性，后面迭代再补充。
忽略历史： 比如客户等级变了，旧数据怎么办？我习惯加一个 valid_from 和 valid_to 字段做“缓慢变化维”。
关系搞反： 比如把商机和订单搞成“订单属于商机”，其实应该是“商机可能产生订单”。方向错了，后面SQL写起来特别别扭。

一个小技巧： 画ER图时，先用便利贴把实体写在上面，然后在地板上摆来摆去。我团队现在还在用这个土办法，比任何建模工具都直观。

3.5 本章小结

概念模型设计，说白了就是“先画骨架，再填血肉”。今天咱们把客户、联系人、商机、订单、产品这五个核心实体认清了，关系也理清了。下一章，咱们就要把这些概念模型转成物理模型——也就是真正的数据库表结构。

到时候我会给你看具体的建表SQL，以及我踩过的那些索引坑。嗯，敬请期待。

📚 课程目录