理解关系模型的表

2.2.2　理解关系模型的表

假如某个企业需要用数据库保存生产中所用到的零件的信息、提供零件的供应商的信息，以及零件的库存数量。为了实现这一目标，我们有两种方案。方案一是将所有相关的信息放在一个“大表”中，如图2-8所示。方案2则是采用三个小表，分别存储供应商、零件以及零件的库存数量，如图2-9所示。下面，我们来分析一下哪种方案好?

图2-7　关系模型的概念

我们知道，数据库的主要操作有查询和增删改，下面分别从这两个角度来对上述两种方案进行比较。

现在，管理人员想知道从北京机床厂购买了哪些零件，这是一个查询。当采用图2-8的方案时，管理人员如果需要知道从北京机床厂购买了哪些零件，只需要输入“生产厂家=机床配件厂，城市=北京”就马上可以看到查询结果。可见，大表的查询效率很高。

图2-8　使用“大表”存储数据

如图2-9所示，假如采用了小表的方案的话，管理人员首先从“供应商表”中找到了“北京机床厂”;然后，通过公共字段“代号”，在“零件供应表”中找到了在“北京机床厂”所购买零件的编号;接下来，通过公共字段“编号”，管理人员在“零件表”中，找到了从“北京机床厂”所购买的零件信息，即规格为12的铜质螺丝帽和规格为17的铜质螺栓。由于管理人员需要的是完整的信息，因此，最后你还需要把这三个表中的数据组合起来，形成图2-8中阴影部分的形式。

图2-9　关系数据库中的“小表”

可见，小表的方案同样能够满足查询的需求，但是查询起来很麻烦、效率较低。既然大表相比于小表有此查询的优势，为什么在关系数据库中还是采用的小表而不是大表呢?我们还需要看看这两种方案在增加、更新、删除记录方面效果如何。

首先，大表中存在着大量的冗余数据，例如厂家的基本信息、零件的基本信息都可能出现多次。其次，大表还存在着很多缺陷，主要表现在数据“增、删、改”的异常上。

插入异常。假如现在要添加一个新的零件的信息，由于在图2-8这张大表中，关键字是“代号+编号”，根据关键字不能为空的原则，新的零件信息将由于缺乏进货厂家信息(代号)而不能成功地添加。这就是插入异常。

删除异常。假如零件P1以后不再从北京机床配件厂进货，因此需要删掉二者的关联关系。但是，在删除该进货零件与供应商的关联关系的同时，也把零件的基本信息以及库存数量删除了。这就是删除异常。

更新异常。我们可以发现，图2-8中，同一生产厂家、同一零件的信息可能会出现多次，这就造成了冗余。冗余不但浪费存储空间，更严重的是会造成数据的不一致。例如，由于误操作，表中第三行的规格改成了19，这样，同一零件就存在着两种规格，将无法确定该零件的规格到底是多少。这就是更新异常。

小表虽然查询比较繁琐，但是，对数据库来讲，准确的存储数据是第一要务。由于小表可以克服大表存在的“增、删、改”异常的弊端，因此，关系数据模型的小表应当是图2-9中“小表”的形式。

进一步观察图2-9中的三个表，可以发现，供应商表和零件表都是表示单一类型的实体，即这两个表中的每一个字段分别对应着实体的一个属性。而零件供应表则有些特殊，代号、编号分别是供应商和零件这两类实体的一个属性。也就是说，这个表将供应商和零件这两类实体联系起来。

这样，我们就得到了2.2.1结束时提出的问题的答案:在关系模型中，实体之间的联系也是通过表来实现的。在2.5节，你将进一步了解到，不同种类联系的实现方法是有所差别的。m∶n的联系通过表示为一个单独的二维表，就如同图2-9一样，而对于其他两种类型的联系，则只是把联系体现在实体所对应的表中即可。