我们在《数据库设计的三大范式》一节讲解了三大范式,本节主要介绍不使用三大范式会对设计数据库有什么影响,会出现什么问题。
这里可以将三大范式理解为:设计数据库时需要遵循的规则,可以有效的帮助我们建立冗余小且结构合理的数据库。
在概要设计阶段,同一个项目,10 个设计人员可能设计出 10 种不同的 E-R 图。不同的角度可以标识出不同的实体,实体又包括不同的属性,自然就设计出了不同的 E-R图。那么怎样审核这些设计图呢?如何评审出最优的设计方案呢?答案就藏在后面的内容里。
下面以某酒店的客人住宿信息表为例来介绍,该表用于保存酒店提供住宿的客房信息,如表 1 所示。
客人编号 | 姓名 | 地址 | 客房号 | ... | 客房描述 | 客房类型 | 客房状态 | 床位数 | 价格 | 入住人数 |
---|---|---|---|---|---|---|---|---|---|---|
C1001 | 张三 | Addr1 | 1001 | ... | A栋1层 | 单人间 | 入住 | 1 | 128.00 | 1 |
C1002 | 李四 | Addr2 | 2002 | ... | B栋2层 | 标准间 | 入住 | 2 | 158.00 | 2 |
C1003 | 王五 | Addr3 | 2002 | ... | B栋2层 | 标准间 | 入住 | 2 | 168.00 | 2 |
... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... |
C8006 | A1 | Addrm | 8006 | ... | C栋3层 | 总统套房 | 入住 | 3 | 1080.00 | 3 |
C8008 | A2 | Addrn | 8008 | ... | C栋3层 | 总统套房 | 空闲 | 3 | 1080.00 | 0 |
从用户的角度来说,将所有信息放在一个表中很方便,因为这样查询数据库可能会比较容易,但是上述表具有下列问题。
上表中“客房类型”“客房状态”和“床位数”列中有许多重复的信息,如“标准间”“入住”等。信息重复会造成存储空间的浪费及一些其他的问题。比如,不小心输入了“标准间”和“标间”或“总统套房”和“总统套”,那么它们在数据库中将表示四种不同的客房类型。
冗余信息不仅浪费存储空间,还会增加更新的难度。如果需要将“客房类型”修改为“标间”而不是“标准间”,则需要修改所有包含该值的行。如果由于某种原因,没有更新所有行,那么数据库中会出现两种客房类型,一个是“标准间”,另一个是“标间”,这种情况被称为更新异常。
从表 1 中我们会发现 2002 和 2003 客房的居住价格分别是 168 元和 158 元。尽管这两间客房都是标准间类型,但它们的“价格”出现了不同,这样就造成了同一个酒店相同类型的客房价格不同,这种问题被称为插入异常。
在某些情况下,当删除一行时,可能会丢失有用的信息。例如,如果删除客房类型为“1001”的行,就会丢失客房类型为“单人间”的账户的信息,该表只剩下两种客房类型,即“标准间”和“总统套房”。当查询有哪些客房类型时,将会误以为只有“标准间”和“总统套房”两种客房类型,这种情况被称为删除异常。