Skip to content
难度基础(★)
建议时长45分钟

3.3.1 概念设计阶段概述

本课核心知识点整理
本课核心知识点手绘流程图(SVG)

本节导学

概念结构设计是下午数据库设计题的地基。它暂时不讨论“表怎么建、外键怎么放、索引怎么选”,而是先把现实业务抽象成一个稳定的语义模型:有哪些对象、对象有哪些特征、对象之间怎样发生业务联系。

这一步最常用的工具是 E-R 模型。E 是 Entity,表示实体;R 是 Relationship,表示联系。所以 E-R 图本质上是在画“业务世界中的对象及其关系”,而不是在画某个 DBMS 的物理结构。

概念设计解决的问题

需求分析阶段得到的是用户语言,例如“学生可以选课,教师讲授课程,选课时记录成绩”。这些话适合沟通,却不能直接变成高质量数据库。概念设计要把它翻译为更严谨的模型:

需求语言概念模型语言后续逻辑设计可能对应
学生、教师、课程实体或实体集关系模式/表
学号、姓名、课程名属性字段/列
学生选修课程联系外键或独立联系表
选课成绩联系的属性联系表中的属性
一个学生可选多门课联系多重度主外键约束、关系表设计

概念设计的关键价值是“先稳定语义,再选择实现”。同一个 E-R 模型可以转换为关系数据库,也可以作为其他数据模型设计的依据;如果一开始就按某个表结构思考,很容易把当前 DBMS 的限制误当成业务事实。

E-R 模型的三个核心构件

实体:业务中需要被单独区分的对象

实体是现实世界中能够区别于其他事物的对象或事件。多个具有相同属性结构的实体构成实体集。例如“张三”是一个学生实体,“学生”是实体集。

判断实体时不要只看名词,而要看它是否需要独立管理。比如“地址”在普通学生信息系统里可能只是学生的属性;在物流系统里,如果要维护地址、配送区域、经纬度、服务范围,它就可能上升为实体。

属性:描述实体或联系的特征

属性描述某个对象或某个业务联系的特征。字幕中特别强调:属性不仅可以属于实体,也可以属于联系。

例如“学生选修课程”是一个联系,“成绩”“选课时间”并不属于单独的学生,也不属于单独的课程,而属于“某学生选某课程”这一事实。因此它们是联系的属性。下午题中如果忽略这一点,后面转换关系模式时经常会把字段放错位置。

联系:实体之间或实体内部的业务关系

联系可以发生在两个不同实体集之间,也可以发生在同一实体集内部。例如“职工管理职工”是实体内部的递归联系;“学生选修课程”是两个实体集之间的联系;“供应商给项目供应零件”可能是三个实体集共同参与的三元联系。

图形符号背后的语义

考试不一定要求画得特别美观,但要认识基本符号,并知道符号背后的含义:

E-R 元素常见图形表示应理解为
实体矩形一类可区分、可管理的对象
属性椭圆对实体或联系的描述项
联系菱形实体间发生的业务关系
连接线线段属性归属或实体参与联系
特殊化/泛化圆圈、分叉、双线等父类实体与子类实体之间的继承式分类

这张图不是为了装饰,而是为了让“语义”在团队中可讨论。比如“成绩”连在“选修”联系上,就明确表示成绩依赖于学生和课程的组合;如果连在学生上,就变成学生天然有一个成绩,语义会错误。

mermaid
flowchart LR
  S["学生"] --- R{"选修"}
  C["课程"] --- R
  R --- G(["成绩"])
  S --- SID(["学号"])
  C --- CID(["课程号"])

与其他设计阶段的边界

概念设计最容易和逻辑设计混淆。可以用“是否已经进入表结构”来划线:

阶段主要问题典型产物是否依赖具体 DBMS
需求分析用户到底要管理什么业务数据流、需求说明
概念设计业务对象和联系是什么E-R 图、概念模型
逻辑设计如何转换为数据模型关系模式、主键、外键较少依赖
物理设计如何存得快、查得快索引、分区、存储结构强依赖

因此看到“实体、属性、联系、E-R 图”,优先判断为概念设计;看到“关系模式、主键、外键、规范化”,优先判断为逻辑结构设计;看到“索引、存储路径、文件组织”,优先判断为物理设计。

做题路线

  1. 先识别题干问的是设计阶段还是模型元素。若关键词是 E-R 图,基本落在概念设计。
  2. 再看是否出现“独立于 DBMS”。概念模型强调面向现实世界,不绑定具体数据库产品。
  3. 若题目给了业务叙述,不要急着建表,先找实体、属性、联系和联系多重度。
  4. 特别注意联系属性。凡是依赖“两个或多个实体共同发生的一件事”的属性,通常应放在联系上。

例题

单选
抽取实体、属性和联系,并形成 E-R 图,属于:
单选
概念设计阶段常用的模型是:

自查要点

  1. 概念设计为什么不直接建表?
  2. E-R 图表达哪些要素?
  3. 概念设计和逻辑设计的分界是什么?