一、设计问题
由于不同的人从不同 的角度考虑问题，设计出的 E-R 就会有着不同的差别，因此要注意以下几个问题
信息重复：表中数据存在重复的信息，或使用相同含义不同字表述的类型，
更新异常：由于冗余的信息在进行更新时未全部进行更新，会导致数据出现错误，称为更新异常
插入异常：无法表示某些信息，如同一个宾馆的标间出现了不同的价格，导致插入时出现异常
删除异常：在删除某一行记录时，导致将房间类型表中的某一类型也删除掉了，称为删除异常
二、规范设计
1、三大范式
在进行数据设计时，制定的一些规则，称为数据库设计范式 ，遵守这些规则将创建出良好的数据库，如经常听到的数据库三大范式
（1）、第一范式
第一范式（Normal From,1NF）的目标是确保每列的原子性。
如果每列（或属性）的都是不可再分的最小数据单元（或最小的原子单元）则满足第一范式
如：地址列 可以拆分为国家 ，省，市，县（区），镇，村（街道办事处）等几个 部分
（2）、第二范式
第二范式（2NF）在第一范式的基础上更近一步，目标是确保表中的每列都和主键相关。
如果一个关系满足第一范式，并且除了主键以外，其他主键都全部依赖该主键则满足第二范式
如：订单详细表中有（订单详细编码，订单详细名，订单编号，订单名，订单类型，商品编码，商品名，商品单价，商品数量等）
其中可以看出
订单详细名 → 订单详细编码
订单名，订单类型 → 订单编号
商品名，商品单价，商品数量 → 商品编码
其中 → 符号代表依赖，由于上述只有部分列依赖于主键，违背了第二 范式 可以对其进行拆分成 订单详细表，订单表，商品表三个表，通过主外键进行相互关联
（3）、第三范式
第三范(3NF)是在第二范式的基础上更近一步，第三范式的目标是确保每列都和主键列直接相关，而不是间接相关
如果一个关系满足第二范式，并且除了主键以外的其他列都只能依赖主键列，列与列之间不存在相互依赖关系，则满足第三范式
借助数学中的Armstrong 公理来判定，如 A、B、C、D 中是表中的四个列
其中A 为主键， B → A(B依赖A),C → A,D → A 如果其中还有，B → C,C → D 从这两个还可以推导出 B → D,此时虽然满足第二范式，但是不满足第三范式
只有 当 A 为主键时，有且只有 B → A(B依赖A),C → A,D → A ，这三个依赖时才满足第三范式。
在现实的话如：商品表中有（商品编号，商品名，商品类型，商品规格，商品单价）
其中虽然 商品名，商品类型，商品规格，商品单价 都依赖 主键商品编号，但是 商品规格，商品单价 依赖于商品类型
由于不同类型的商品的 规格 和 单价不同
因此还可以将其分为商品表和商品类型表，这样才满足第三范式
2、数据库事务的四大特性：（ACID）
原子性( Atomicity )：指的是事务是一个不可分割的工作单位，要不全部成功，要不全部回滚
一致性( Consistensy )：事务在执行前后数据库处于一致性。（如：AB之间转账，A少100，B必须要增加100）
隔离性( Isolation )：多个用户并发访问数据库时，一个用户的事务不能被其他用户的事务所干扰，多个并发事务之间数据要相互隔离
持久性( Durability )：指一个事务一旦被提交，他对数据库的影响是永久性的。
三、规范化和性能的关系
由于项目对于最终的用户来说，客人最关心的是方便清晰的数据结果，因此在设计数据库时，设计人员和客户对数据库的设计规范化与性能之间存在一定的矛盾。
如上为了满足数据库三大范式， 数据操作性能也随之受到了影响，毕竟查询一个表和查询 多个表的性能是不一样的，因此在实际设计时，既要考虑三大范式，避免数据的冗余和各种数据操作异常；又要考虑数据库的访问性能。可以使用的小操作有：为了减少表之间的连接，提高数据库性能，允许适当的冗余列
如：金额列存在不满足数据库设计的第三范式，因为金额可以通过单价乘以数量得到，但是增加后可以提过数据的处理速度，加快访问速度，便于直观展示，相对而言是一个比较好的冗余（对其形容 比较高级的说法叫以空间换取时间），但是，不要轻易 违反数据库设计的规范化原则。如果处理不好，可能会适得其反，使应用程序运行速度更慢。