Review 4 | Entity-Relationship Model
实体-联系模型(Entity-Relationship Model)是一种概念模型,使用ER图描述现实世界的实体(Entity)以及实体之间的联系(Relationship)
实体用以描述现实世界中可以区分的对象,实体所具有的特征称为实体的属性(Attribute)。实体之间存在着各种联系
下面这个 University Schemas 非常经典
Database Modeling
entity
实体 entity 是一个存在着的对象,而且能够与其它对象区分
实体通过其拥有的属性进行描述
实体集 entity set 是一堆类型和性质相同的实体
实体的鉴定是根据情况需要讨论的
对于正常人来说,一群蚂蚁里面的一个蚂蚁,没有名字,没有可相互区分的相貌,没有性格,从信息关系角度是不可区分的,所以不能作为实体
如果对于一个生物学家,可以对每个蚂蚁进行标记,那就可以作为实体
数据库很多知识是很贴近实际生活的,很多概念都是常识性的,不要太拘泥于理论概念的确定
A database can be modeled as
- a collection of entities
- relationship among entities
Attributes
Attribute types:
- Simple (简单)/ composite(复合)
- Single-valued(单值) / multivalued(多值)
- Derived(派生)
- 可以根据其它属性计算出来,即,由其它属性决定
- Example:
age
<-date_of_birth
Composite Attributes
复合与多值不一样哈,前者是有多个儿子,每个儿子有自己的值,而后者是其本身有很多值
比如 姓名
,可以单纯放一个字符串,也可以将其分为几个儿子,比如 姓氏
, 名
,字
,号
儿子也可以作为复合属性继续拆分为多个儿子
Redundant Attributes
???????????????
E-R Diagram
一个方框是一个实体集,包含多个实体,实体之间的关系用菱形框表示。
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.
Cardinality Constraints
ER图里实体集与关系之间的连线种类表示不同的关系,这里牵涉到 Mapping Cardinality Constraints
基数约束,有一对一,一对多,多对一,多对多四种,反映不同实体的关系情况
我们需要表示两种性质,实体的关系是单还是多,是实体集全部实体都参与还是可能由参与即可
在ER图里用 线 来描述这个所谓的 Cardinality Constraints
- 有单箭头表示单,无箭头表示多
- 箭头始终指向实体哈,被指向的就是单
- 注意无箭头线会有
(possibly 0)
的情况
- 单线表示实体集可能会存在实体有这个关系,双线表示一一对应,即实体集的每一个实体至少参与一次这个关系的组成
- 单线叫 Partial participation, 双线叫 Total participation
关系属性与度
我们目前的ER图都是二度(degree)的关系,即两两一个关系
关系是可以带属性的,例如:
很明显,关系的属性就是两实体的共同属性,为了简化就交给了关系
当然也有三度关系
Roles
一个实体可能会以不同的身份参与同一个关系的组成,比如预修课和主课都来自 course:
这里的连线就是多对多,因为一门课可能有好几门预修课,一门课可能是好几门主课的预修课
是单线不是双线的原因是,一门主课不一定有预修课,一门课不是任何课的预修课
Complex Attributes in ER Diagram
缩进是复合,大括号是多值
Reduction to Relational Schemas
看看怎么把ER图转化为关系模式
实体集转化
强实体直接转换,弱实体将所依赖的强实体的 primary key 拿过来当成自己的主键
例如:
强实体直接:course(course_id, title, credits)
弱实体:section (course_id, sec_id, semester, year )
关系转化
直接把两端实体集的 primary key 拿过来作为自己的key,和自己的属性组合,没属性就只留key
但是有情况可以进一步化简
其实key一样的schema原则上都可以合并,与是否完全参与没关系,可以设置NULL
many-to-many
没法化简,只能单独给关系弄一个 schema,其它的关系集可以单独弄schema尝试优化整合
Many-to-one relationship sets that are total on the many-side
化简方式为,单
的一侧把自己的key交给 多
的实体集作为对方的新属性,不用给关系单独弄一个schema
这样弄是因为,对于 多
的实体集,每个 tuple 都有且只有和对方一个属性有关系,那就直接作为新属性咯
Composite and Multivalued Attributes
复合属性把儿子保留,把爸爸杀了,把爸爸的名字组合进儿子的名字,让大家知道他们都是一个爸
例如一个组合属性:
- name
- first_name
- last_name
直接改成:
- name_first_name
- name_last_name
如果本来就不会有歧义,可以不用加前缀,没人关乎你爸是谁
多值属性从实体中拆分出来,单独作为一个新的schema,并加入原来的主键,与多值属性共同组成主键
Design Issues
ER图设计很灵活,一千个人有一千张ER图,我们有什么设计经验
两种常见错误
表示关系有两种方式:
- 显式的:直接画菱形框
- 隐含的:两个方框有相同的属性
下图错就错在两种方式都用了,且表达的是同一个关系
还有一个我还没看过的例子:
这是想要记录学生每次作业的分数
这是一个多值属性,拆开来就没办法转换了
上面两图是可能的改正结果
下面的都是一些权衡问题,没有标准答案,需要根据具体情况具体回答
Use of entity sets vs. attributes
一个属性是否该拆出来作为单独的实体?
上图将电话号码作为关系,将一张表进行了拆分
- 利:表达更多的属性、支持一对多关系
- 比如不仅储存字符串,还储存int类型的,这样系统打电话更方便
- 弊:表和对应的关系多了,复杂了
Use of entity sets vs. relationship sets
在之前的ER图中,takes是作为关系本设计的:
但是也可以按照下面的方式设计为实体:
我们应该尽量设计为关系,但是如果这个关系需要经常发生操作,那就用实体
Placement of relationship attributes
关系的属性要不要合并到实体里面去呢?
放到实体的话有个问题,就是一对多、多对多的情况下就有点麻烦了
Extended ER Features
略,下次再看