注意代价高的关系

发布：2018-07-19 18:58:59 浏览：3304

注意数据模型中的关系。在设计数据模型时，添加表和列时，或者编写查询时，要从长远角度考虑实体间的关系如何影响性能和可扩展性的情形。在设计数据模型时，要考虑到将来的数据库分割和其他可能的数据需求。在实现了数据模型后，才发现它有问题，此时修复的成本很高，可能是设计阶段修复它的成本的100倍。事先考虑好，仔细策划数据模型。要采用范式，考虑将来可能如何分割数据库及应用可能有哪些需求。

在生活中，除非我们是受虐狂，否则都会努力建立和维护平衡的关系。理想情况下，我们在关系中投人的与我们得到的基本一样多。当段人际关系倾斜向某个人了，那么另一方就会不高兴，从而重新评估这段关系，可能就此结束它。虽然本书不是讲人际关系的，但在人际关系中存在的付出=回报的等式同样适用于数据库中的关系。

数据库关系是由数据模型决定的，而数据模型抓住了数据的基数和参照完整性规则。要理解这是如何实现的，以及为什么它如此重要，就需要理解构建数据模型需要的基础步骤，这些步骤将生成数据定义语言DDL)的可，即表和列。虽然这一流程有很多变体，但对于关系模型来说，第一步通常都是定义实体

实体可以是独立存在的任何东西，如物理对象、事件或概念。实体之间可以存在关系，实体和关系都可以具有描述它们的属性。打个比方，实体就是名词，关系就是动词，修饰实体的属性就是形容词，修饰关系的属性就是副词。

实体可以是某个事物的实例，例如客户的订单，可以具有订单ID和总价这样的属性。把同种类型的实体集合起来就形成了实体集。在数据库中，实体相当于表中的一行，而实体集相当于表。描述实体特有属性的是表的主键。主键通过唯一标识实体的实例实现了实体完整性。外键描述实体间关系的特有属性。外键把不同实体集中的两个实体关联在起，从而实现了弓引用完整性。最常用的实体、关系和属性的图解表示法是实体关系图(ERD)。ERD展示了实体集间的基本关系，是一对一对多还是多对多

一旦定义和映射了实体、关系和属性，设计数据模型就剩下最后一步了:规范化。规范化数据模型的主要目的是，确保存储数据的方式允许在保证数据完整性的情况下对数据进行插入、更新选择和删除的操作傾即CRUD，CreateReadUpdateDelete)不规范的数据模型具有高度的数据冗余，这意味着数据完整性问题的风险更大。范式是逐级构建的，这意味着满足第二范式的数据库也必须满足第一范式。下面的补充说明介绍了最常见的范式。如果一个数据库至少满足第三范式，就可以认为它是规范的。

范式

下面是数据库中常用的范式。满足高级范式表明必须满足低级范式。通常，如果数据库满足第三范式，我们就说它是规范的。

口第一范式。按照Codd的定义，表最初应该表示一个关系且表中没有重复的分组。虽然Codd详细定义了“关系”，但是“重复的分组”这个概念仍然引起了争议。争论的内容有是否允许表中存在表，是否允许域为空。最重要的概念是能够创建一个主关键字。

口第二范式。所有非主关键字域都不能只依赖于组合关键字的部分。

口第三范式。所有非主关键字城必须依赖于主关键字。Boyce-Cod范式。每个决定因素都是候选的关键字。

口第四范式。一种记录类型中不存在多值依赖。

口第五范式。表中的每个非平凡连接依赖都是由候选主关键字决定的。

口第六范式。不存在非平凡连接依赖。

前三种范式的简便记忆法是“1-一主关键字，2一完整的主关键字3一只能依赖于主关键字”。

你可能已经想到了，实体间的关系会对数据存储、提取和更新的有效性产生巨大的影响。由于这些关系定义了如何分割和共享数据库，所以它们在扩展中也扮演着重要的角色。假设我们想根据订单确确认服务对数据库进行Y轴分割，那么如果订单实体与其他实体关系紧密，那么这种分割就可能造成问题。在分割之后再试图理清这种关系网很困难。在设计阶段多花费点儿时间，在分割数据库时就只需要花费原来的1/10甚至1/100的精力。

对于扩展性来说，数据关系的最后一个关键点是在查询中如何连接表。当然，这不仅是由数据模型定义的，也是由在应用中创建报表和新页面的开发人员定义的。这里我们不是要详细介绍优化查询的步骤，要说的是新的查询都应该由熟悉数据模型且能力根强的DBA申貸，在把们投入到生产环境之前，还要分析性能方面的特征。

你可能已经注意到了，在通过规范化提高数据完整性的愿望和在数据库中使用的关系程度之间是有关系的。采用的范式越高，在创建表时的关系越多，对重复的值这种情况尤其如此。在数据库设计方面，几年前被当作原则使用的东西(即采用的范式越高越好)，现在大型交易系统设计时，都要进行权衡了。这种权衡与风险和成本、成本和质量、时间和成本等之间的权衡是相似的，即一方的下降通常会导致另一方的上升。通常，要提高可扩展性，我们会降低采用的范式。

因为要连接表，所以SQL査询很慢，可以采用以下几种方法解决。首先是对查询进行调优。如果这种方法无效，另一种方法是创建视图、物化视图、摘要表等，可以对连接进行预处理。还有一种方法是不要在査询中进行连接，而是把数据集读到应用中，在应用的内存中进行连接。虽然这种方法比较复杂，但在数据库中进行连接通常是最难扩展的，而该方法把连接移出了数据库，放在应用服务器层上，那么用更多的商用硬件进行水平扩展会更容易一些。最后一个办法是追溯到业务需求上。通常，我们的业务合作伙伴会提出不同的解决方案，在解释时会说，现有的请求报表的方法需要增加10%的硬件，而删除一行会减小报表的复杂度，而得到的网站设计业务价值基本是相同的。