数据库里的E-R图是什么？

实体--联系图（entity-relation），用来反映现实世界中实体之间的联系的图形。E-R图中包括的元素主要有：实体（矩形框内写上实体名表示）、属性（用短横线连接实体，椭圆内写上属性名表示）、联系（短横线连接不同的实体，在菱形框内写上联系名）、联系的类型（联系连接不同实体的线上标示出来联系的类型），联系的类型主要有1:1、1:n、m:n三种类型。\x0d\x0a1:1表示联系两端的实体相互间都是1:1的联系，如：一个学校有一个校长，一个校长在一个学校里任职；则校长和学校之间就是一对一的联系。\x0d\x0a1：n表示联系两端的实体之间是一对多的联系，如：一个班级有很多学生，一个学生只能属于一个班级，则班级和学生实体之间就是一对多的联系；\x0d\x0am:n表示联系两端的实体之间是多对多的联系，如：一个学生可以学习很多课程，一门课可以被很多同学学习，则学生和课程之间就是多对多的联系。

班级（班级号，班级名）主码：班级号

学生（学号，姓名，性别，年龄）主码：学号

课程（课程号，课程名）主码：课程号

班级组成（班级号，学号）主码：班级号，学号；其中班级号参照班级关系主码，学号参照学生关系主码

学生选课（课程号，学号，学期，成绩）主码：课程号，学号；其中课程号参照课程关系主码，学号参照学生关系主码的学号

差不多就这样，希望可以帮你

E-R图的组件有很多，但概括起来说，可分为以下四种：

线段：用于将实体、关系相连接

对于双矩形、双菱形、双椭圆、双线段等等一些组件，可以不用去管，通常用以上四种组件就可以表达清楚实体及实体间的关系。

从E-R图向关系模式转化 数据库的逻辑设计主要是将概念模型转换成一般的关系模式，也就是将E-R图中的实体、实体的属性和实体之间的联系转化为关系模式。在转化过程中会遇到如下问题：

(1)命名问题。命名问题可以采用原名，也可以另行命名，避免重名。

(2)非原子属性问题。非原子属性问题可将其进行纵向和横行展开。

(3)联系转换问题。联系可用关系表示。 1、标识实体：

通常有用户、角色这两个实体。

2、标识关系：

用户与角色间为多对多的互相拥有关系。

3、标识实体、关系的属性:

不仅仅是实体有属性，关系同样也有属性，这些属性在实体间建立关系时才会存在。

有时属性太多，无法在图上一一列出，可以用表格，在后面的步骤中这个表格同样会用到，如下： 实体 属性 描述 … 用户 性别

年龄

电话

… 男/女

多大了

联系方式

… … 4、确定属性域：

属性域就是属性的取值范围。

这时，可以用表格将属性的数据类型、数据长度、取值范围及是否可为空、简单/复合、单值/多值、是否为派生属性等域信息定义出来。

这个过程，事实上包含了逻辑结构设计中的数据类型、NULL、CHECK、DEFAULT等信息。 实体 属性 描述 数据类型及长度 是否可为空 用户 性别

年龄

电话

… 男/女

多大了

联系方式

… 1字节的短整形或布尔型

1字节的短整形

20字节的字符型或长整形

… NO

NO

YES 5、确定键：键就是可用于标识实体的属性，有：主键、唯一键、外键。 实体 属性 描述 键 用户 用户编号

性别

年龄

电话

… 男/女

多大了

联系方式

… 主键 6、实体的特化/泛化：

也就是面向对象模型中父类和子类的概念，这是个可选的步骤。举个例子，用户中大部分人都是普通员工，但有一小部分是从事销售的，销售人员

有个负责区域的属性，如果将这个属性放在用户实体中，如右图：

这时我们会发现，除了销售人员外，其他非销售人员这个属性全都不存在，这就是特化的过程。可以另建一个销售人员的实体来泛化用户实体，如右图：

这样就完成了对用户实体的泛化，泛化的过程也就是抽出实体间公共属性的过程，但通常，除非特化的部分太多，才会考虑将一个实体抽象成两个

1对1关系的实体，所有这个步骤是可选的。

7、检查模型：

（1）检查冗余

首先检查实体：1对1关系的实体中有没有非外键的重复属性，或者就是同一个实体；

其次检查关系：有没有通过其他关系也可以得到的重复属性；

当然有时，需要考虑时间维度，因为有些属性是有时效性的，也就是虽然是同一个属性，但不同的时间表示的却是不同的内容，这一点在后面的逻辑结构设计中会提到，这并不是真正的冗余。

（2）检查业务

检查当前的E-R模型是否满足当前业务的场景。可以从某个实体开始，沿着当前E-R模型的各个节点去模拟业务场景。尤其需要和《需求规格说明书》去做校验。

到这里，也就完成了E-R模型建立的全过程，有时，对于比较复杂的E-R模型，一张图可能显得太过局促，可以建立全局、局部E-R模型图，以便于查看和分析。

---