跳至主要內容

高级数据库模型

njrdatabasebackend数据库设计理论大约 6 分钟约 1706 字

数据库建立的过程从设计阶段开始,需要提出并回答存储什么信息,信息元素之间如何关联,假定有什么样的约束,诸如键或者参考的完整性等等。

思考 ---> 高级设计 ---> 关系数据库模式 ---> 关系 DBMS

有几种用符号表达设计的方法。

  • 实体-关系图(E-R 图)
  • UML(统一建模语言)
  • ODL(对象描述语言)

E/R 模型

在「实体-联系(entity-relationship model)」 E/R 模型中,数据的结构使用图形化的方式表达,即「实体-联系图」,用到以下三个主要的元素类型:

  1. 实体集——矩形
  2. 属性——椭圆
  3. 联系——菱形

实体集

实体是某种抽象对象,相似实体的集合形成实体集。E/R 模型是静态的概念,所以尽管实体类似对象类,但是不会像类一样具有方法。

例如,每个电影是一个实体,所有电影的集合构成实体集。

属性

属性是实体具有的性质,比如电影集中可能有电影名或时长等属性。

联系

联系是两个或多个实体集的连接。比如电影 Movies 和影星 Stars 是两个实体集,那么 Stars-in 就是连接 Movies 和 Stars 的联系。

E/R 模型允许连接任意数目的实体集。

实体的三种联系

包含一对一,一对多,多对多三种。

  • 如果 A 到 B 是多对一关系,那么画个带箭头的线段指向 B;
  • 如果是一对一,画两个带箭头的线段;
  • 如果是多对多,画两个不带箭头的线段。
一对多
一对多

提示

箭头表示最多一个。

多路联系

虽然老师可以开设多门课,并且可以教授多名学生,但是对于特定的学生和课程,只有一个老师教授,这就构成了一个三元联系。

三元联系
三元联系

一般只使用二元联系,可以把多元联系转换为二元联系。

二元联系
二元联系

联系中的角色

一个实体在联系出现几次,就要用几条线连接。

下图表示一个课程的先修关系,先修关系出现两个 Course 实体,第一个是先修课程,后一个是后修课程,因此需要用两条线来表示这种关系。

带有角色的联系
带有角色的联系

E/R 模型中的子类

一个实体集中含有一些实体,这些实体有一些共同的属性,可以把这些实体集合成一个父类,然后再把这些实体分成几个子类。

用一个三角形和两条线来连接类和子类,与子类有关的属性和联系都连到子类上,而与父类和子类都有关的连到父类上。

子类
子类

从 E/R 图到关系设计

E/R 图是一种概念模型,而关系模式是一种逻辑模型。

设计原则:

  • 忠实性:实体集和它们的属性应当反映现实
  • 避免冗余:不要重复存储相同的信息
  • 简单性:尽量简化模型,除必要,不添加多余的实体集和联系
  • 选择正确的联系:选择合适的联系类型
  • 选择正确的元素种类:选择合适的实体集和属性

具体步骤:

  • 明确「宏观行为」:数据库是用来做什么的?比如,管理雇员的信息。
  • 确定「实体集」:对于一系列的行为,确定所管理信息所涉及到的主题范围。这将变成 table,比如,雇用员工,指定具体部门,确定技能等级。
  • 确定「联系」:分析行为,确定 tables 之间有何种关系。比如,部门与雇员之间存在一种关系。给这种关系命名。
  • 细化「行为」:从宏观行为开始,现在仔细检查这些行为,看有哪些行为能转为微观行为。比如,管理雇员的信息可细化为:
    • 增加新员工
    • 修改存在员工信息
    • 删除调走的员工
  • 确定「业务规则」:分析业务规则,确定你要采取哪种。比如,可能有这样一种规则,一个部门有且只能有一个部门领导。这些规则将被设计到数据库的结构中。

下面举个例子,需求如下: ACME 是一个小公司,在 5 个地方都设有办事处。当前,有 75 名员工。公司准备快速扩大规模,划分了 9 个部门,每个部门都有其领导。为有助于寻求新的员工,人事部门规划了 68 种技能,为将来人事管理作好准备。员工被招进时,每一种技能的专业等级都被确定。

定义「宏观行为」

ACME 公司的一些宏观行为包括:

  • 招聘员工
  • 解雇员工
  • 管理员工个人信息
  • 管理公司所需的技能信息
  • 管理哪位员工有哪些技能
  • 管理部门信息
  • 管理办事处信息

确定「实体集」和「联系」

可以确定要存放信息的主题领域(表)及其关系,并创建一个基于宏观行为及描述的图表。确定哪些 relationship 是一对多,一对一,及多对多联系。这是一个 E/R 草图,以后会细化。

确定「实体集」和「联系」
确定「实体集」和「联系」

细化宏观行为

以下微观行为基于上面宏观行为而形成:

  • 增加或删除一个员工
  • 增加或删除一个办事处
  • 列出一个部门中的所有员工
  • 增加一项技能
  • 增加一个员工的一项技能
  • 确定一个员工的技能
  • 确定一个员工每项技能的等级
  • 确定所有拥有相同等级的某项技能的员工
  • 修改员工的技能等级

这些微观行为可用来确定需要哪些 tablerelationship

确定业务规则

业务规则常用于确定一对多,一对一,及多对多关系。

相关的业务规则可能有:

  • 现在有 5 个办事处;最多允许扩展到 10 个
  • 员工可以改变部门或办事处
  • 每个部门有一个部门领导
  • 每个办事处至多有 3 个电话号码
  • 每个电话号码有一个或多个扩展
  • 员工被招进时,每一种技能的专业等级都被确定
  • 每位员工拥有 3 到 20 个技能
  • 某位员工可能被安排在一个办事处,也可能不安排办事处