目录
Different attribute types（属性的不同类型）
Relationship (Binary relationship)
Entity-Relationship Model
ER model 是一种普遍的概念数据模型，其中E代表Entities, R代表Relation。
Entity
实体（Entity）是现实世界中有别于其他对象的对象，如一间教室，一位老师，老师的地址。
实体可以用一些属性（attributes）的集合来描述，这些属性的值是用来区分同一个类型的实体与其他实体的。
实体的集合（entity set）就是相同类型实体的集合，所有在这个集合里的实体都有相同的属性，但是属性的值可能会不一样。
ER Diagram
ER model可以用ER diagram图像化的表示出来。
Different attribute types（属性的不同类型）
Simple attribute
这种属性只包含一个值。（黄色虚线圈）
Composite attribute
这种属性包括多个元素。（黄色虚线圈）
Multi-valued attribute
这种属性包含多个值。（用双椭圆表示）
Derived attribute (派生属性)
- 由其他属性计算得来
- eg，年龄可以由生日的数据和现存年份得出。（用虚线椭圆表示）
Key attributes
Key
属性的集合，一个key可以特别地表示一个实体。
Composite Key
两个或多个属性用来表示一个key
eg, 名字和地址各自都不能单独表示某一个雇员，但是它们在一起却可以。
一个实体可能有不止一个key，由此我们有很多种key。
candidate key（候选key）：A minimal set of attributes that uniquely identifies an entity is called a candidate key. 能够表示一个实体的属性们的最小集。这个最小集的含义是，里面的元素可以是多个或一个（如果能有一个那就是这个），如果是多个，那么拆出来的任何一个元素都无法独立地表示一个实体。
这样的候选key有很多个，因此我们需要选出我们地主key（primary key）,同时，我们还可以自己创建新的key。
Relationship (Binary relationship)
关系是几个实体之间的联系。
degree: 参与关系集的实体集的数量（多少个种类的实体），两个种类的实体集之间的关系就是binary or degree two。两个实体集以上的关系很少。
Binary Relationship
一个例子
员工在部门工作
“Work_in”是员工和部门之间的关系
它代表一个员工在多个部门工作，反之亦然。
关系也可以有它对应的属性
Recursive Relationship
关系的实体集不必是不同的
有时候，一个关系可能会包括在同一个实体集里面的两个实体
比如在同一个实体集里面的两个员工
Constraints
描述储存的数据及其限制的model。
二元关系的映射可以分为四种情况：
One-to-many relationship
一个B里的实体可以和最多一个A里的实体有联系
如图：
一个customer可以借多个贷款（loan），而一个loan只能分配给一个customer因此此时loan是是many而customer是one。
关系borrower的key可以是{customer-id, loan-number}，但是我们取这个key里面many的部分，也就是loan-number，它才是candidate key。
Many-to-one relationship
其实就是one-to-many的反过来，对于关系的candidate key的寻找也和上方类似，找many的部分。
One-to-one relationship
- A里面的一个实体最多和B里的一个实体有关系
- B里面的一个实体最多和A里的一个实体有关系
此时关系的key也可以是{customer-id, loan-number}，但是candidate key就可以是两者中的任意一个。
Many-to-many Relationship
- A里面的实体可以与B里面任意数量的实体有关系
- B里面的实体可以与A里面任意数量的实体有关系（反正就是互搞）
- 所以这种关系的映射没有什么限制
此时这种关系key也可以是{customer-id, loan-number}，与此同时也是candidate key，也就是这俩同时存在才能表示这种关系。
我们可以发现在ER-diagram中有个→的符号，这个→的没有箭头的部分对应的是many，有箭头的一端对应的是one，所以在上面的图中因为都是many，所以没有箭头只有短线（投机取巧）。
Participation Constraint
从one-to-many的例子中可以看出来一个customer可以借一些loans。此时可以很自然的提出，是否每一个loan都至少被一个customer借了呢。如果我们假设都被借了，这样的假设就叫做participation constraint（参与约束）。
我们可以把参与者（两个实体）分为两个部分：
- Total：每一个在这个实体集的实体必须至少有一个相关的关系。（此时在ER-diagram图中单线变成双线）
- Partial: 在这个实体集的实体即可以有也可以没有相关的关系。
因此上面的假设成立后，loan就变成了total（每个贷款都要被借），customer就变成了partial（customer又不一定非要借）
Weak Entity/Strong Entity
Strong Entity
- 这种实体可以仅仅由和它有关的独特属性定义。
- eg, 员工由员工ID的属性，这个属性是它自己独特的并且可以单独定义它。
Weak Entity
- 这种实体，就算把它所有独特属性加在一起，也没办法定义它。
eg:
- 假设员工可以给他们的家属购买保险
- 家属的属性有pname（名字）和age
- pname这个属性无法定义一个家属（age不是独特的属性）
- 所以家属是一个弱实体
- 只有考虑到当家属的属性+员工的primary key（此时员工的set称为Identifying entity set）时，才能定义一个家属
- 此时，来自家属这部分的属性称为discriminator（辨别者）或者partial key
如图，identity entity set为employee, discriminator为pname，而dependent的Key为{pname, EmpID}.
如果一个弱实体集W依赖于一个强实体E，我们可以说E owns W, 在上面的例子中，Employee owns Dependent.
Class Hierarchy
有时候，我们会很自然的把一个实体集分为好几个实体集
子集会继承父级的属性，如hourly_emps也会有ID、name、address。
一个类的层次体系可以用两种角度来看
- 一个类被特殊化成子类
- 子类由父类泛化。
在上面的例子中，我们可以指定两种约束
- Overlap constraints
决定两个子类是否允许含有相同的实体。比如一个雇员既可以是hourly_emps又可以是contract_emps吗？（显然不能）
- Covering constraints
决定子类中的实体是否可以包括父类中的所有实体。比如Employee实体肯定要么是hourly_emps要么是contract_emps，所以子类的实体包括了父类中的所有实体。
Non-binary Relationship
Ternary Relationship（三元关系）
比如一个员工在某一个位置的部门工作
总的来说，任意一个非二元关系都可以用二元关系来表示（通过创建一个人工的实体集）