一个让所有人抓狂的数据需求
2023年7月，某新能源车企的CEO在战略会上抛出一个问题：
"我们的客户生命周期价值（CLV, Customer Lifetime Value）是多少？哪些客户最值得投资？"
数据团队接到需求后，花了整整两周时间，结果发现：
- 工单系统有客户消费数据，但没有客户基础信息
- CRM系统有客户基础信息，但消费数据不完整
- 会员系统有积分数据，但和工单对不上
- 财务系统有收款数据，但没有客户ID
四个系统，数据完全打不通。团队加班加点人工整合数据，最后给出的报告误差高达40%，CEO大怒。
什么是数据建模？为什么它如此重要？
数据建模（Data Modeling）= 用结构化的方式描述业务实体、属性和关系
通俗理解：
就像建房子需要先画设计图，数据建模就是给数据画设计图。
- 定义有哪些"实体"（客户、车辆、工单）
- 每个实体有哪些"属性"（客户姓名、车辆VIN码）
- 实体之间有什么"关系"（一个客户拥有多辆车）
没有数据模型的后果：
- 数据孤岛：每个系统都有自己的数据，无法关联
- 重复录入：同一个客户在不同系统要录入多次
- 数据不一致：客户信息在A系统是这样，B系统是那样
- 分析困难：想做个简单的客户分析，要从5个系统取数
售后业务的核心实体识别
实体识别的黄金原则
什么是实体？
实体是业务中独立存在、具有唯一标识的事物。
识别实体的三个标准：
- 独立性：能独立存在，不依赖其他实体
- 唯一性：有唯一标识（ID）
- 持久性：需要长期保存
售后业务的五大核心实体
实体1：客户（Customer）
业务定义：购买或使用本品牌汽车的个人或企业
核心属性：
客户实体 (Customer)
主键: customer_id (客户ID)
基础信息:
- customer_name: 客户姓名
- phone_number: 手机号（唯一约束）
- email: 邮箱
- id_card: 身份证号（脱敏存储）
- customer_type: 客户类型（个人/企业）
- register_date: 注册日期
会员信息:
- member_level: 会员等级（普通/银卡/金卡/白金）
- member_status: 会员状态（正常/冻结/注销）
- points_balance: 积分余额
统计信息:
- total_vehicles: 拥有车辆数
- total_visits: 历史到店次数
- total_spending: 历史消费总额
- last_visit_date: 最后到店日期
- avg_visit_interval: 平均到店间隔（天）
真实案例：客户实体缺失导致的营销失败
某品牌发现VIP客户流失率高达30%。调查发现，根本原因是没有统一的客户实体：
- 客户张三在上海店消费了¥80,000
- 又在杭州店消费了¥60,000
- 系统认为是两个客户，各消费¥80,000和¥60,000，都不是VIP
- 实际上是一个客户消费了¥140,000，早就应该是顶级VIP
结果：这个客户没收到VIP待遇，感觉不被重视，转投竞争对手。
实体2：车辆（Vehicle）
业务定义：本品牌销售的每一台汽车
核心属性：
车辆实体 (Vehicle)
主键: vin (车辆识别代号，17位)
基础信息:
- vehicle_model: 车型（Model 3/Model Y）
- vehicle_color: 车身颜色
- production_date: 生产日期
- delivery_date: 交付日期
- license_plate: 车牌号
所有权信息:
- current_owner_id: 当前车主ID（外键→Customer）
- purchase_date: 购买日期
- purchase_price: 购车价格
保修信息:
- warranty_start_date: 保修开始日期
- warranty_end_date: 保修到期日期
- warranty_type: 保修类型（基础保修/延保）
使用信息:
- current_mileage: 当前里程（km）
- total_maintenance_count: 累计保养次数
- total_repair_count: 累计维修次数
- last_service_date: 最后维保日期
设计亮点：VIN码作为主键
VIN码（Vehicle Identification Number）是全球唯一的车辆身份证，用它做主键有巨大优势：
✅ 全球唯一：不会重复
✅ 不可更改：车牌可以换，VIN码不能换
✅ 信息丰富：VIN码本身包含车型、生产地、年份等信息
✅ 行业标准：所有系统都认VIN码
真实案例：车牌号作主键的灾难
某品牌早期用车牌号做主键，结果发生了：
- 客户换车牌后，系统认为是新车，历史记录全丢失
- 二手车过户后，新车主看到了前车主的所有隐私信息
- 临时牌照车辆无法录入系统
后来花了半年时间，才全部切换到VIN码。
实体3：服务中心（Service Center）
业务定义：提供售后服务的物理门店
核心属性：
服务中心实体 (Service_Center)
主键: store_id (门店ID)
基础信息:
- store_name: 门店名称
- store_code: 门店编码（如HD-SH-001）
- store_type: 门店类型（直营/授权）
- store_status: 运营状态（营业中/装修中/已关闭）
位置信息:
- region_code: 所属区域（华东/华南/华北）
- province: 省份
- city: 城市
- address: 详细地址
- latitude: 纬度
- longitude: 经度
运营信息:
- opening_date: 开业日期
- business_hours: 营业时间
- phone_number: 门店电话
- manager_name: 店长姓名
资源信息:
- service_bays_count: 工位数量
- technician_count: 技师人数
- service_advisor_count: 服务顾问人数
- floor_area: 门店面积（㎡）
设计亮点：编码规则的重要性
门店编码采用[区域]-[城市]-[序号]格式，带来巨大便利：
HD-SH-001：一眼看出是华东区-上海-001号店- SQL查询时可以按前缀筛选：
WHERE store_code LIKE 'HD-%'（华东区所有门店） - 便于区域统计和对比分析
实体4：员工（Employee）
业务定义：在服务中心工作的员工
核心属性：
员工实体 (Employee)
主键: employee_id (员工工号)
基础信息:
- employee_name: 姓名
- position: 岗位（服务顾问/技师/店长）
- employment_date: 入职日期
- employment_status: 在职状态（在职/离职）
技能信息:
- skill_level: 技能等级（初级/中级/高级/专家）
- certifications: 资质证书列表
- specialties: 专长领域（动力系统/电气系统）
组织关系:
- store_id: 所属门店（外键→Service_Center）
- manager_id: 直属主管（外键→Employee，自关联）
- department: 所属部门
绩效信息:
- monthly_target: 月度目标产值
- ytd_achievement: 年度累计产值
- customer_satisfaction: 客户满意度评分
设计亮点：自关联实现组织层级
manager_id字段指向employee_id，实现了组织层级关系：
-- 查询某员工的所有下属
SELECT e2.*
FROM employees e1
JOIN employees e2 ON e1.employee_id = e2.manager_id
WHERE e1.employee_id = 'EMP001';
-- 查询某员工的汇报链
WITH RECURSIVE reporting_chain AS (
SELECT employee_id, employee_name, manager_id, 1 AS level
FROM employees
WHERE employee_id = 'EMP123'
UNION ALL
SELECT e.employee_id, e.employee_name, e.manager_id, rc.level + 1
FROM employees e
JOIN reporting_chain rc ON e.employee_id = rc.manager_id
)
SELECT * FROM reporting_chain;
实体5：服务工单（Service Order）
业务定义：客户一次完整的售后服务记录
核心属性：
服务工单实体 (Service_Order)
主键: work_order_no (工单号)
关联关系:
- customer_id: 客户ID（外键→Customer）
- vin: 车辆VIN（外键→Vehicle）
- store_id: 服务门店（外键→Service_Center）
- service_advisor_id: 服务顾问（外键→Employee）
- technician_id: 维修技师（外键→Employee）
时间信息:
- create_time: 创建时间
- appointment_time: 预约时间
- arrival_time: 到店时间
- workshop_in_time: 进站时间
- repair_complete_time: 维修完成时间
- delivery_time: 交车时间
业务信息:
- order_type: 工单类型（保修维修/付费维修/保养）
- order_status: 工单状态（待接车/维修中/已完工/已取消）
- fault_codes: 故障代码列表（JSON格式）
- service_items: 服务项目列表（JSON格式）
- mileage_in: 进站里程
金额信息:
- labor_fee: 工时费
- parts_fee: 配件费
- other_fee: 其他费用
- total_amount: 总金额
- payment_method: 支付方式
- payment_status: 支付状态
质量信息:
- quality_check_result: 质检结果（通过/不通过）
- customer_feedback: 客户反馈
- satisfaction_score: 满意度评分（1-5分）
设计亮点：时间戳的完整性
工单记录了完整的时间链：
创建 → 预约 → 到店 → 进站 → 维修完成 → 质检完成 → 交车
这样可以计算：
- 客户等待时长 = 进站时间 - 到店时间
- 维修时长 = 维修完成时间 - 进站时间
- 交车周期 = 交车时间 - 到店时间
每个时间差都是重要的运营指标。
今日实战练习
请尝试画出你们公司售后业务的实体关系图（ER图, Entity-Relationship Diagram）：
- 列出5-8个核心实体
- 标注每个实体的主键
- 画出实体之间的关系线
- 标注关系的基数（一对一、一对多、多对多）
自查清单：
- 每个实体都有明确的业务定义？
- 每个实体都有唯一的主键？
- 实体之间的关系清晰吗？
- 有没有遗漏重要的业务实体？
- 有没有冗余的实体（可以合并）？
下一页预告：我们将深入讲解实体之间的关系设计，特别是一对多、多对多关系的处理，以及如何用外键保证数据完整性。