3、实体关系图(ER图)基础:ER图符号、实体与关系的图形化表示、基数约束

实体关系图(Entity-Relationship Diagram,ERD)是领域建模的核心可视化工具。它用图形化的方式描述业务领域中的实体、实体的属性以及实体之间的关联关系。在搜索索引设计中,ER图帮助我们理清数据源之间的依赖与连接,为后续的文档嵌套与索引结构设计奠定基础。

3.1 ER图核心符号

ER图使用一套标准化的符号体系来表达不同的建模元素。以下是最常用的符号及其含义:

符号 名称 含义 示例
矩形 实体(Entity) 业务领域中可独立存在的事物或对象 用户、订单、商品
椭圆 属性(Attribute) 实体所具有的特征或性质 用户名、价格、创建时间
菱形 关系(Relationship) 实体之间的业务关联 下单、属于、包含
线段 连接线 连接实体与关系,或实体与属性 —
下划线 主键(Primary Key) 唯一标识实体的属性 用户ID
建模提示:在搜索索引场景中,实体通常对应索引中的文档类型,属性对应文档字段。关系则决定了文档是扁平存储还是嵌套存储。

3.2 实体与关系的图形化表示

实体与关系通过连接线组合成完整的ER图。一个基本的ER图结构包含:实体节点、关系节点、属性节点以及连接它们的线段。下面是一个典型的“用户-订单”ER图示例:

用户-订单实体关系图示例 用户-订单实体关系图(ERD) 用户 用户ID 用户名 邮箱 下单 1 订单 N 订单ID 总金额 下单时间 图例说明 矩形=实体 | 椭圆=属性 | 菱形=关系 | 下划线=主键 连接线上标注“1”和“N”表示一对多基数约束
图形化解读:上图展示了一个典型的“用户-订单”一对多关系。一个用户(1)可以下多个订单(N)。在搜索索引设计中,这种关系通常意味着订单文档中会包含用户ID作为外键,或者将订单嵌套在用户文档中。

3.3 基数约束

基数约束(Cardinality Constraint)定义了实体之间参与关系的数量规则。它是ER图中最重要的语义信息之一,直接影响索引结构的设计决策。常见的基数约束类型如下:

基数类型 符号表示 含义 索引设计影响
一对一(1:1) 1 — 1 一个实体A对应唯一一个实体B 可合并为单一文档,或通过外键关联
一对多(1:N) 1 — N 一个实体A对应多个实体B 常用嵌套数组或反向引用(父引用子)
多对多(M:N) M — N 多个实体A对应多个实体B 需引入关联实体,或使用双向嵌套

3.4 基数约束的图形化标注

在ER图中,基数约束通常标注在连接线的两端。常见的标注方式包括“1”、“N”、“M”等符号,以及更精确的“min..max”表示法。下面是一个包含多种基数约束的ER图示例:

基数约束示例图 基数约束示例:多实体关系 部门 包含 1 员工 N 参与 M 项目 N 基数约束总结 部门-员工:1:N(一对多) | 员工-项目:M:N(多对多)
常见误区:在ER图中,基数标注的位置容易混淆。请记住:标注在靠近实体A一侧的基数,表示实体B参与关系时对应的数量。例如,靠近“员工”一侧标注“N”,表示一个部门对应N个员工。

3.5 基数约束的详细分类

除了基本的1:1、1:N、M:N分类,实际建模中还需要考虑参与约束(Participation Constraint),即实体是否必须参与关系:

  • 强制参与(Mandatory):实体必须参与关系,用竖线“|”表示。例如:每个订单必须属于一个用户。
  • 可选参与(Optional):实体可以参与关系,用圆圈“O”表示。例如:一个用户可能没有订单。

结合基数与参与约束,可以形成更精确的约束表达:

约束组合 ER图标注 业务含义 索引设计示例
1..1(强制一对一) 竖线 — 竖线 每个A必须对应唯一一个B 用户与用户档案:合并为同一文档
0..1(可选一对一) 圆圈 — 竖线 每个A最多对应一个B,但可以没有 用户与优惠券:用户文档中可选嵌套
1..N(强制一对多) 竖线 — 竖线 每个A必须对应至少一个B 订单与订单项:订单文档中嵌套数组
0..N(可选一对多) 圆圈 — 竖线 每个A可以对应零个或多个B 用户与评论:用户文档中可选嵌套评论数组

3.6 从ER图到搜索索引的映射思路

ER图中的实体关系直接指导搜索索引的文档结构设计。以下是常见的映射策略:

  • 1:1关系:优先考虑合并为单一文档,减少索引时的跨文档查询。
  • 1:N关系:在“1”端的文档中嵌套“N”端的数组,或使用父引用(Parent Reference)方式。
  • M:N关系:通常需要引入关联实体,在搜索索引中可以使用双向嵌套或独立关联文档。
实战建议:在领域建模阶段,ER图是沟通业务与技术的桥梁。建议先用ER图梳理清楚实体关系,再根据搜索性能需求决定是否进行反范式化或嵌套设计。不要跳过ER图直接设计索引结构,否则容易遗漏关键的业务约束。