读《SQL语言艺术》设计

    设计，一个很有趣的命题。也许有人会问：“数据库设计符合3个范式不就OK了？”
    是的，数据库设计的确要符合3个范式。时下面向对象分析设计如火如荼，ORM 的重要更是不言而喻，但是又有多少人能分清数据库设计和实体对象的区别呢？
    所能看到的经常是，将实体对象和数据库设计混为一谈的例子。一个实体类对应一张表，或将数据库设计完全搬到实体类中。在开发过程中发现实体类中却什么就直接补充到数据库中做冗余。以至于更新数据是连带的做大量的同步更新操作。程序遍的异常复杂，开发变得苦不堪言，系统维护更是不可想象。

    说道数据库设计，就不得不能提到“关系”这个词。究竟数据库中的关系指的是什么呢？也许又有人会说：“这有什么好讲的，关系就是‘1对1’、‘1对N’， 表与表之间的关系”
    真的就这么简单吗？就从 3个范式说起吧。
    1NF 主要说的是“原子性”的问题。每每提到原子性，很多人都会误解为原子性表达了绝对“不可再分”的概念。事实上没有绝对的“不可再分”，“不可再分”是一个相对的概念，须要明确观察角度（设计的粒度）。书中举了一组很形象的例子：
    对将军来说，一个团就是具有原子性的战斗单位；但指挥那个团的上校要负责更小一级的营或连，所以团对于他来说不具有原子性。 对于汽车经销商来说，一辆汽车是具有原子性的信息单元；但对于汽车修理工来说，一辆汽车根本不具有原子性，而是又更低一级的大堆零件组成的，这些零件才是他们眼里具有原子性的数据项。
    2NF  主要说的是“对键的完全依赖”的问题。这个范式可以有效避免数据的冗余。很多人都认为我们现在所处的年代，是一个存储设备非常便宜的年代，不需要为了节省一点点空间而考虑数据库的冗余。数据冗余带来的麻烦主要体现 数据备份与恢复、查询性能、数据一致性 等方面。
    数据备份与恢复，书中描述了下面的场景：
    如今存储设备很便宜，看似不必太在意空间的问题，但其实不然：首先，需要存储的实际数据量本身在增长；另外，数据常需要镜像；而且，数据可能需要备份到灾难恢复站点的磁盘上，在那里需要再次镜像；还有，数据库会有很多个复本作为开发数据库。所以，看似一个字节的冗余，通常也都是四五倍的浪费，浪费量非常惊人。除了上述存储空间的代价外，数据冗余还会给数据恢复带来更严重的问题。当“系统非计划停机”时，唯一的解决方案就是根据备份来恢复数据库，而此时双倍的数据量意味着双倍的恢复时间，这在某些场合成本非常高，若是医院数据库，甚至会危及生命。
    查询性能，扫描数据量更大的表，需要更多的时间，这个观点应该是毋庸置疑的。对于有数据库方面工作经验的人们来说，全表扫描往往是最佳方案。
    数据一致性自不必多说，需要更多的 pdate 同步数据。
    3NF 主要说的是“属性独立性”的问题。我们在设计中经常会引入一些可以由其他属性推导或计算出来的属性作为冗余，尽管这些冗余符合 1NF 和 2NF 但他仍然存在和 2NF 相同的风险。
    通过对三个范式的叙述，我们会发现在设计表的时候，关系早已融入其中。属性与属性的关系才是关系型数据库对关系理解的真谛。

（未完，待续）