ER图中的主要成分是实体类型和联系类型，转换规则就是如何把实体类型、联系类型转换成关系模式。
1. 二元联系转换
规则1.1（实体类型的转换）：将每个实体类型转换成一个关系模式，实体的属性即为关系模式的属性，实体标识符即为关系模式的键。
规则1.2（联系类型的转换）：根据不同的情况做不同的处理。
规则1.2.1（二元联系类型的转换）①若实体间联系是1：1，可以在两个实体类型转换成的两个关系模式中任意一个的属性中加入另一个关系模式的键和联系类型的属性。
②若实体间联系是1：N，则在N端实体类型转换成的关系模式中加入1端实体类型的键和联系类型的属性。
③若实体间联系是M：N，则将联系类型也转换成关系模式，其属性为两端实体类型的键加上联系类型的属性，而键为两端实体键的组合。
规则1.2.2（一元联系类型的转换）：与二元联系类型的转换（规则1.2.1）类似。
规则1.2.3（三元联系类型的转换）：不管联系类型是何种方法，总是将三元联系类型转换成关系模式，其属性为三端实体类型的键加上联系类型的属性，而键为三端实体键的组合。但读者应注意，由于三元联系比较复杂，这样设计出来的关系模式可能有冗余现象，还需用规范化理论进行处理。限于篇幅，此处不再讨论。
2. 三元联系转换
1:1:1可以在三个实体类型转换成的三个关系模式中任意一个关系模式的属性中加入另两个关系模式的键（作为外键）和联系类型的属性
1:1:N在N端实体类型转换成的关系模式中加入两个1端实体类型的键（作为外键）和联系类型的属性
1:M:N将联系类型也转换成关系模式，其属性为M端和N端实体类型的键（作为外键）加上联系类型的属性，而键为M端和N端实体键的组合
M:N:P将联系类型也转换成关系模式，其属性为三端实体类型的键（作为外键）加上联系类型的属性，各实体的键组成关系的键或关系键的一部分。或：三个或三个以上实体间的一个多元联系可以转换为一个关系模式。与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性，各实体的码组成关系的码或关系码的一部分。
7.2.1事务的定义
从用户观点看，对数据库的某些操作应是一个整体，也就是一个独立的工作单元，不能分割。例如，客户认为电子资金转账（从账号A转一笔款到账号B）是一个独立的操作，而在DBS中这是由几个操作组成的。显然，这些操作要么全都发生，要么由于出错（可能账号A已透支）而全不发生。保证这一点非常重要，我们决不允许发生下面的事情：在账号A透支情况下继续转账；或者从账号A转出了一笔钱，而不知去向未能转入账号B中。这样就引出了事务的概念。
定义7.1事务（Transaction）是构成单一逻辑工作单元的操作集合。
DBS的主要意图是执行“事务”。事务是数据库环境中一个逻辑工作单元，相当于操作系统环境中的“进程”概念。一个事务由应用程序中的一组操作序列组成，在程序中，事务以BEGIN TRANSACTION语句开始，以COMMIT语句或ROLLBACK 语句结束。
COMMIT语句表示事务执行成功地结束（提交），此时告诉系统，数据库要进入一个新的正确状态，该事务对数据库的所有更新都已交付实施（写入磁盘）。ROLLBACK语句表示事务执行不成功地结束（应该“回退”），此时告诉系统，已发生错误，数据库可能处在不正确的状态，该事务对数据库的所有更新必须被撤销，数据库应恢复该事务到初始状态。
7.2.2事务的ACID性质
7.2.2事务的ACID性质为了保证数据库中数据总是正确的，我们要求事务具有下列四个性质：
1.原子性（Atomicity）一个事务对数据库的所有操作，是一个不可分割的工作单元。这些操作要么全部执行，要么什么也不做（就效果而言）。
保证原子性是数据库系统本身的职责，由DBMS的事务管理子系统来实现。
2.一致性（Consistency)一个事务独立执行的结果，应保持数据库的一致性，即数据不会因事务的执行而遭受破坏。
确保单个事务的一致性是编写事务的应用程序员的职责。在系统运行时，由DBMS的完整性子系统执行测试任务。
3.隔离性（Isolation)在多个事务并发执行时，系统应保证与这些事务先后单独执行时的结果一样，此时称事务达到了隔离性的要求。也就是在多个事务并发执行时，保证执行结果是正确的，如同单用户环境一样。
隔离性是由DBMS的并发控制子系统实现的。
4.持久性（Durability）一个事务一旦完成全部操作后，它对数据库的所有更新应永久地反映在数据库中。即使以后系统发生故障，也应保留这个事务执行的痕迹。
事务的持久性由DBMS的恢复管理子系统实现的。
上述四个性质称为事务的ACID性质，这一缩写来自四条性质的第一个英文字母。
以下例题仅供参考：
这是一份关于商店商品仓库的ER图。
先看仓库和商品之间是M:N的关系，于是我们首先想到的应该是把联系库存转换为库存实体。
库存 （仓库号，商品号，日期，库存量）
然后是商品实体和仓库实体
商品（商品号，商品名，单价）
仓库（仓库号，仓库名，地址）
除此之外仓库和商品还有一个供应关系，同样是M:N关系：
供应 （仓库号，商品号 ，月份，月供应量）
在上图的商店和仓库之间的关系可能写漏了，但是它们应该也是M:N的关系，一个商店可以被多个仓库供应，一个仓库也可以供应多个商店。上面已经创建了供应实体，现在只需在供应实体中加入商店号即可，也就是商店实体的主键。
供应（仓库号，商品号，商店号 ，月份，月供应量）
商店（商店号，商店名，地址）
总结
至此，转换关系模型也完成了，当然这只是个例子，实际的开发中，我们可能会遇到各式各样奇怪的需求，这就更要求我们做好概念设计的环节，对后来的数据库设计和维护都有好处。ER图的好坏，始终是数据库设计的重要一节。
实体-联系模型（简称E-R模型）是由P.P.Chen于1976年首先提出的。它提供不受任何DBMS约束的面向用户的表达方法，在数据库设计中被广泛用作数据建模的工具。E-R数据模型问世后，经历了许多修改和扩充。
从数据需求分析中分析出系统的实体属性图，需要遵循三范式原则，对实体之间的依赖关系进行了整合，得出系统E-R图。
说明：菱形表示实体之间的关系，用矩形表示实体，用无向直线把菱形与有关实体连接，在直线上标明联系的类型。用椭圆表示实体的属性，并用无向直线把实体与属性联系起来。
1 E-R模型向关系模型的转换规则：
（1）实体类型的转换
将每个实体类型转换成一个关系模式，实体的属性即为关系的属性，实体标识符即为关系的键。
（2）联系类型的转换
1)实体间的联系是1:1
可以在两个实体类型转换成两个关系模式中的任意一个关系模式的属性中加入另一个关系模式的键和联系类型的属性。
2)如实体间的联系是1:N
则在N端实体类型转换成的关系模式中加入1端实体类型转换成的关系模式的键和联系类型的属性。
3)如实体间的联系是M:N
则将联系类型也转换成关系模式，其属性为两端实体类型的键加上联系类型的属性，而键为两端实体键的组合。
2 三元联系转换
1:1:1可以在三个实体类型转换成的三个关系模式中任意一个关系模式的属性中加入另两个关系模式的键（作为外键）和联系类型的属性
1:1:N在N端实体类型转换成的关系模式中加入两个1端实体类型的键（作为外键）和联系类型的属性
1:M:N将联系类型也转换成关系模式，其属性为M端和N端实体类型的键（作为外键）加上联系类型的属性，而键为M端和N端实体键的组合
M:N:P将联系类型也转换成关系模式，其属性为三端实体类型的键（作为外键）加上联系类型的属性，各实体的键组成关系的键或关系键的一部分。或：三个或三个以上实体间的一个多元联系可以转换为一个关系模式。与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性，各实体的码组成关系的码或关系码的一部分。
上图E-R模型向关系模型的结果：
仓库（仓库号#，仓库名，地址）
商店（商店号#，商店名）
商品（商品号#，商品名）
进货（商店号#，商品号#，仓库号#，日期#，数量）
安装（舰艇编号，武器编号）
仓库（仓库编号，仓库名，地址，公司编号）
公司（公司编号，公司名，地址）
职工（职工编号，姓名，性别，仓库编号，聘期，工资）