Skip to content

Review 4 | Entity-Relationship Model

:material-circle-edit-outline: 约 2015 个字 :material-clock-time-two-outline: 预计阅读时间 7 分钟

实体-联系模型(Entity-Relationship Model)是一种概念模型,使用ER图描述现实世界的实体(Entity)以及实体之间的联系(Relationship)

实体用以描述现实世界中可以区分的对象,实体所具有的特征称为实体的属性(Attribute)。实体之间存在着各种联系

下面这个 University Schemas 非常经典

image-20240401133055044

Database Modeling

entity

实体 entity 是一个存在着的对象,而且能够与其它对象区分

实体通过其拥有的属性进行描述

实体集 entity set 是一堆类型和性质相同的实体

实体的鉴定是根据情况需要讨论的

对于正常人来说,一群蚂蚁里面的一个蚂蚁,没有名字,没有可相互区分的相貌,没有性格,从信息关系角度是不可区分的,所以不能作为实体

如果对于一个生物学家,可以对每个蚂蚁进行标记,那就可以作为实体

数据库很多知识是很贴近实际生活的,很多概念都是常识性的,不要太拘泥于理论概念的确定

A database can be modeled as

  • a collection of entities
  • relationship among entities

Attributes

Attribute types:

  1. Simple (简单)/ composite(复合)
  2. Single-valued(单值) / multivalued(多值)
  3. Derived(派生)
    • 可以根据其它属性计算出来,即,由其它属性决定
    • Example: age <- date_of_birth

Composite Attributes

复合与多值不一样哈,前者是有多个儿子,每个儿子有自己的值,而后者是其本身有很多值

比如 姓名,可以单纯放一个字符串,也可以将其分为几个儿子,比如 姓氏

儿子也可以作为复合属性继续拆分为多个儿子

Redundant Attributes

???????????????

E-R Diagram

image-20240401133344572

一个方框是一个实体集,包含多个实体,实体之间的关系用菱形框表示。

Primary Key

实体集里面打下划线的属性就表示主键

主键是区分实体和关系的关键,我们接下来讨论ER图上有的玩意儿都有什么样的主键

(Identifying)Entity sets

就我们之前认知里的主键,不废话了

Relationship sets

由两个实体的主键组合而成,这个很显然,因为两个实体集各自的实体参与一个关系组成,肯定两边都要一起区分

Weak entity sets

ER图上的双重菱形叫Identifying relationship(标识性联系) ,表示有弱实体集参与的关系

弱实体集,比较重要的新概念,是没有主键的实体集

拥有主键的实体我们确切来说应该叫 identifying entity set(标识性实体集),弱实体集的的存在依赖于标识性实体集,即这个弱鸡实体集合的每一个实体都需要抱别人大腿才能存在,不然就会灰飞烟灭

和外键所在的外表相似

显然,我们必须给弱实体集一条双线来一一对应他们的大腿,单箭头指向大腿实体集

所有ER图上的 double diamond 肯定是一对多的关系

弱实体集的 discriminator (分辨符,or partial key) 可以理解为弱实体集里的 “主键”,能区分的前提是他们已经找到大腿了,用这个什么 dashed line 标识

The discriminator (分辨符,or partial key) of a weak entity set is the set of attributes that distinguishes among all the entities of a weak entity set when the identifying entity they depend is known.

image-20240403181127578

Cardinality Constraints

ER图里实体集与关系之间的连线种类表示不同的关系,这里牵涉到 Mapping Cardinality Constraints

基数约束,有一对一,一对多,多对一,多对多四种,反映不同实体的关系情况

image-20240401143001929

image-20240401143028035

我们需要表示两种性质,实体的关系是单还是多,是实体集全部实体都参与还是可能由参与即可

在ER图里用 线 来描述这个所谓的 Cardinality Constraints

  • 有单箭头表示单,无箭头表示多
    • 箭头始终指向实体哈,被指向的就是单
    • 注意无箭头线会有 (possibly 0) 的情况

image-20240401143202792

image-20240401143215042

image-20240401143220794

image-20240401143229095

  • 单线表示实体集可能会存在实体有这个关系,双线表示一一对应,即实体集的每一个实体至少参与一次这个关系的组成
    • 单线叫 Partial participation, 双线叫 Total participation

image-20240401143521566

关系属性与度

我们目前的ER图都是二度(degree)的关系,即两两一个关系

image-20240401142238254

关系是可以带属性的,例如:

image-20240401142310790

很明显,关系的属性就是两实体的共同属性,为了简化就交给了关系

image-20240401142300504

当然也有三度关系

image-20240401142558262

Roles

一个实体可能会以不同的身份参与同一个关系的组成,比如预修课和主课都来自 course:

image-20240401142416809

这里的连线就是多对多,因为一门课可能有好几门预修课,一门课可能是好几门主课的预修课

是单线不是双线的原因是,一门主课不一定有预修课,一门课不是任何课的预修课

Complex Attributes in ER Diagram

缩进是复合,大括号是多值

image-20240401142826987

Reduction to Relational Schemas

看看怎么把ER图转化为关系模式

实体集转化

强实体直接转换,弱实体将所依赖的强实体的 primary key 拿过来当成自己的主键

例如:

image-20240403202246343

强实体直接:course(course_id, title, credits)

弱实体:section (course_id, sec_id, semester, year )

关系转化

直接把两端实体集的 primary key 拿过来作为自己的key,和自己的属性组合,没属性就只留key

但是有情况可以进一步化简

其实key一样的schema原则上都可以合并,与是否完全参与没关系,可以设置NULL

many-to-many

没法化简,只能单独给关系弄一个 schema,其它的关系集可以单独弄schema尝试优化整合

image-20240403202721569

Many-to-one relationship sets that are total on the many-side

化简方式为, 的一侧把自己的key交给 的实体集作为对方的新属性,不用给关系单独弄一个schema

这样弄是因为,对于 的实体集,每个 tuple 都有且只有和对方一个属性有关系,那就直接作为新属性咯

image-20240403202849255

Composite and Multivalued Attributes

复合属性把儿子保留,把爸爸杀了,把爸爸的名字组合进儿子的名字,让大家知道他们都是一个爸

例如一个组合属性:

  • name
    • first_name
    • last_name

直接改成:

  • name_first_name
  • name_last_name

如果本来就不会有歧义,可以不用加前缀,没人关乎你爸是谁

多值属性从实体中拆分出来,单独作为一个新的schema,并加入原来的主键,与多值属性共同组成主键

image-20240403204110536image-20240403204118147image-20240404144538982

Design Issues

ER图设计很灵活,一千个人有一千张ER图,我们有什么设计经验

两种常见错误

表示关系有两种方式:

  • 显式的:直接画菱形框
  • 隐含的:两个方框有相同的属性

下图错就错在两种方式都用了,且表达的是同一个关系

image-20240404145535719

还有一个我还没看过的例子:

image-20240404145737820

这是想要记录学生每次作业的分数

这是一个多值属性,拆开来就没办法转换了

image-20240404145940419

上面两图是可能的改正结果

下面的都是一些权衡问题,没有标准答案,需要根据具体情况具体回答

Use of entity sets vs. attributes

一个属性是否该拆出来作为单独的实体?

image-20240404150349077

上图将电话号码作为关系,将一张表进行了拆分

  • 利:表达更多的属性、支持一对多关系
    • 比如不仅储存字符串,还储存int类型的,这样系统打电话更方便
  • 弊:表和对应的关系多了,复杂了

Use of entity sets vs. relationship sets

在之前的ER图中,takes是作为关系本设计的:

image-20240404150955651

但是也可以按照下面的方式设计为实体:

image-20240404150615330

我们应该尽量设计为关系,但是如果这个关系需要经常发生操作,那就用实体

Placement of relationship attributes

关系的属性要不要合并到实体里面去呢?

image-20240404151436159

放到实体的话有个问题,就是一对多、多对多的情况下就有点麻烦了

Extended ER Features

略,下次再看