而且，一张表中的列不叫作列，叫作属性，感觉上一点也不直观。
不过，现在回过头了翻了翻，觉得这本书不错，对范式有了一些新的理解。
现在研究了面向对象的理论后，才发觉，这种概念上的称呼不仅有助于数据库，而且也有助于对应于数据访问层中的类的设计。
翻书时，参考了一篇叫浅谈数据库设计中的反规范(转贴) 的文章，感觉不错，对数据库的设计又有一个层次上的提升。
在感觉上，用到4NF的数据库设计不多，规范化的结果带来的是编程上的麻烦，实际上，我们在写数据库应用程序的时候，通常在数据库设定了相应的规则约束后，在应用程序中又不得不再写一次规则。
见过一种作法是把所有的数据规则都丢给数据库来做，但我觉得这样不是很好，一是要增加应用程序与数据库之间的通信量，二是数据库的负担本来就重，还要它做这种事，是不是太残忍了？
BCNF的范式可能要能用一些，作为修正的第三范式，不仅避免了数据操作的错误关联，同时在实现上，相对来说，既规范，又得体，还不失大方
。满足BCNF也不是很复杂，也就三点：
所有非主属性对每一个码都是完全函数依赖。
所有的主属性对每一个不依赖它的码，也是完全函数依赖。
没有任何属性完全函数依赖于非码的任何一组属性。
转换一下，说法如下：
每一张表中都要必须要有一个主键（外键），作为标识。
主键作为唯一标识，它的唯一性，并不依赖于任何非主键（外键）列，它的本身就是唯一的。
每一列的组合的唯一性都与主键（外键）的唯一性关联，不会出现在没有主键（外健）的情况下，它还能通过非主键列（外键）来确定唯一性。
在实际中：数据库的表的主键列应该是唯一的，并且用户不能够手工更改的列
。虽然BCNF并不能消除多值依赖，但是在通常的应用中，感觉还是实用。
考虑一下4NF，也只是能够消除平凡多值依赖而已，尽管它能够消除一些看起来令人很不爽
的数据冗余，可个人感觉，好像很麻烦。一昧地消除数据冗余是不合理的
，如果不是因为特殊需求，一昧的消除数据冗余，会造成编码上的复杂，比较更新一个数据时，还要考虑到，更新数据时，是否要更新其它表。这是很麻烦的（这个假设在没有应用数据库本身的功能特性上）部分，而且往往这种情况，是在绝对的情况下出现的。而且规范化的结果往往是造成表的分割的数目的增长，这样也会造成大量、零碎的小表出现，试想，针对每一张表要写一个添加、删除、修改，天呐，什么概念啊要？
