《sql 语言艺术》 概要

http://www.oreilly.com/catalog/artofsql （原书）
http://www.oreilly.com.cn/book.php?bn=978-7-121-05834-9 (中文版)
  数据库技术是企业信息化开发的基础。在制造业信息化领域从业多年，自己对这块知识却一直零碎杂乱，应该理顺思路，为架构设计的目标建立基础。
       此书以明确应用原则，讨论各种SQL应用场景，利于实践。
第一章 制定计划：为性能而设计
程序首要目标：满足业务需求。设计SQL支持关系模型（表内不同字段间存在”关系“）。
关系就是表，不同字段联系在一起定义关系。
关系理论的关键原理：关系不包含重复数据，且记录之间没有顺序。
总结：建模是业务需求具体化的过程。
规范化的重要性--使混沌变得有序。
满足第三范式3NF。
真正的风险是数据的不一致性，难于编写的数据输入控制代码、性能、BUG以及模型无法演进，
规范化会增加上述风险几率。
松散、不同类型的信息组织，便于运用的数据模型，步骤：
第一步：确保原子性（属性）。无法再分割，仅把原子性属性定义为表中的字段。
如果where子句中必须引用属性的一部分，说明不属性未达到原子性级别，丧失两个优点：
1高效搜索能力，因常规索引以具有原子性的值作为键（全文索引不能实时更新）。
2由数据库保证的数据正确性，使用函数检查 将 复杂难维护。
还必须精通字符串函数，要避免多值塞进同一个字符串中。
原则上如果组织数据，实际上取决于如果使用数据。必须考虑业务需求，因为它决定原子级的地址属性，根据业务需求分析适用性。
下一步是确定唯一标识各记录的主键（复合键常见）。尽量使用实际意义的主键，而不是序列数（键的技术代用品）。
一旦所有属性都具有原子性、具确定了键，数据就符合1NF。
第二步：检查对键的完全依赖性
属性不是键确定行所特有的，属性部分依赖于键（复合键）。
影响：
数据冗余，公共属性会被重复保存，两个问题：
一。冗余数据容易引起数据不一致，修改更费时。
二。浪费存储空间。
查询性能，全表扫描
为消除键的部分依赖性，必须建立新表，新表的键都是原始表的键的一部分。
去除只依赖部分键的属性后，表就符合2NF。
第三步：检查属性独立性
除主键所包含的属性外，不能根据任何其他属性确还一个属性的值。此数据集满足3NF。
必须对2NF的数据集中的每一对属性检查，确定3NF。
不符合3NF的风险和2NF相同。
3NF重要原因：
合理规范化的模型可应