4. 数据模型设计：投研数据分类、实体关系建模、标签体系设计、数据字典规范
数据模型设计，说白了就是给投研平台搭骨架。
我见过太多团队，一上来就写代码，结果数据越存越乱，最后连自己都搞不清「这个字段到底存的是什么」。嗯，今天我们就聊聊怎么把这块地基打牢。
4.1 投研数据分类：先分清楚家里有什么
我个人习惯，先把数据分成三大类。这样后面建模才不会乱。
| 分类 | 说明 | 举例 |
|---|---|---|
| 基础数据 | 相对稳定的底层数据 | 公司信息、行业分类、交易日历 |
| 行情数据 | 高频变动的市场数据 | 日K线、分钟线、实时报价 |
| 投研数据 | 分析师产出的核心数据 | 研究报告、财务预测、估值模型 |
你想想看，如果把行情数据和投研数据混在一起存，查询效率会非常低。我在项目中遇到过，有人把研报的PDF直接塞进数据库的BLOB字段里，结果一张表几十个G，备份一次要两小时。后来我们拆成了文件存储+元数据索引，问题才解决。
核心原则： 按数据更新频率和访问模式分类，不要把所有鸡蛋放在一个篮子里。
4.2 实体关系建模：画清楚谁跟谁有关系
实体关系建模，就是搞清楚「公司」和「研报」之间是什么关系。
我一般用ER图来画。核心实体就这几个：
- 公司（Company）：股票代码、公司名称、行业、上市日期
- 研报（Report）：报告ID、标题、分析师、发布日期、评级
- 财务数据（Financial）：报告期、营收、净利润、EPS
- 标签（Tag）：标签ID、标签名称、标签分类
它们之间的关系是这样的：
这张图看着简单，但实际落地时坑不少。举个例子：一家公司可能被多家券商覆盖，一份研报也可能涉及多家公司（比如行业对比报告）。所以「公司」和「研报」之间其实是多对多的关系，需要一张关联表来解耦。
避坑指南： 我曾经在设计时忽略了「研报版本」这个实体。结果同一份研报更新了三次，数据库里只有一条记录，历史版本全丢了。后来加了版本号字段，才把坑填上。
4.3 标签体系设计：给数据打上「记号」
标签体系，说白了就是给数据贴标签。但怎么贴、贴什么，这里头有讲究。
我建议把标签分成三层：
- 基础标签：行业、板块、市值区间等客观属性
- 业务标签：成长股、价值股、周期股等分析维度
- 行为标签：近期被调研、评级上调、机构重仓等动态信息
为什么要分层？因为不同角色的关注点不一样。研究员可能更关心业务标签，而交易员可能更关注行为标签。分层之后，查询效率会高很多。
设计原则： 标签要「可枚举、可组合、可继承」。比如「消费电子」这个标签，可以继承「电子」和「消费」两个父标签。
4.4 数据字典规范：让每个人说同一种语言
数据字典，就是给每个字段写「说明书」。没有数据字典的数据库，就像没有菜单的餐厅——你永远不知道端上来的是什么。
我一般要求数据字典包含以下内容：
| 字段名 | 类型 | 长度 | 说明 | 示例 |
|---|---|---|---|---|
| stock_code | VARCHAR | 10 | 股票代码，A股用6位数字 | 600519 |
| report_title | VARCHAR | 200 | 研报标题，不含副标题 | 贵州茅台深度研究 |
| rating | ENUM | - | 评级：买入/增持/中性/减持 | 买入 |
| eps_ttm | DECIMAL | 10,4 | 滚动市盈率，保留4位小数 | 2.3567 |
你可能会问：「字段名用中文不行吗？」我的建议是——别。字段名用英文，注释用中文。这样既方便程序调用，也方便人阅读。
注意： 数据字典不是写一次就完事了。每次表结构变更，都要同步更新数据字典。我曾经吃过这个亏——改了字段类型忘了更新文档，结果下游系统解析报错，排查了整整一天。
4.5 小结：数据模型设计的三条铁律
最后，我总结三条经验，供你参考：
- 先分类，后建模：数据分类决定了存储策略，别上来就建表
- 标签要分层：一层标签解决不了所有问题，三层刚刚好
- 字典要活着：数据字典不是摆设，要跟着数据库一起迭代
数据模型设计这块，说白了就是「磨刀不误砍柴工」。前期多花点时间把模型理清楚，后面写代码、做报表、跑模型，都会顺畅很多。嗯，今天就聊到这儿，下一节我们聊聊数据采集和清洗的那些事儿。