好的设计依赖于标准化三范式
对数据库表的设计好坏的评价,应该只以标准化的三个范式来评价,即看一个表是否完成符合三大范式的要求
而不能看表当中列的多少,即使有很多属性也不能代表这个设计不好,更不能因为属性很多就考虑将一个本来可能设计的还好的表进行拆分,如果原来的表符合三范式的话,这种拆分就一定会产生不良设计的表(主要是依赖传递)
如何区分外键和依赖传递
关于外键和依赖传递的关系
给定一个表其中的一个属性,要确定它是外键,或者是依赖传递,可以看这么几点,注意这个属性本身必须满足一定条件,即需要是另一个表的主键
1. 如果属性是外键的话,这个属性不可能完全依赖于表的主键,即不可能对应一个不同的表的主键而有特定的值,可能出现不同的主键有同样值的这个属性。
事实上,可以这么理解,外键的字面意思就是说这个属性不是这个表中主键完全决定的,而是作为这个表和其他表之间通信的一个接口,连接到另外一个表当中。只是告诉我们这个主键对应的这一行值原来是连接到另一个表的那个主键的那一行值上面去的。
2. 如果属性是依赖传递的话,就和外键完全不一样,即这个属性完全依赖于主键,主键一旦发生变化,这个属性的值也一定会有一个变化,可以算的上是独立的一一对应的。
当属性决定于主键时,如果这个属性还是另外一个表的主键,那么另外一个表的属性可以看成是依赖这个属性,同时传递依赖于本表的主键,这个明显违反第三范式
因此,不管是检查表之间关系,还是需要对表进行拆分的时候,都需要认真找到外键,认真思考一下他们之间的关系,看到底是外键还是传递依赖。如果是传递依赖的话,建议一定要把这两个表合并才行。
3. 简单的说,就是看属性是否完全决定于主键,如果一个属性完全决定于主键的话(一个主键决定一个属性值),那么就是传递依赖,如果一个属性不决定于主键的话(几个主键可能有同一属性值),那么就是外键
注意确定外键很有作用,可以提前发现不标准的表设计,因此,在决定一个表关系设计之前,需要在确定一下外键,或者说明确好每个表之前的关系
同时,不要随意做出一个变化的决定,需要在变化之前想好这个变化的影响,比如将表拆分的时候,需要考虑拆分之后的表是否有传递依赖
Subscribe to:
Post Comments (Atom)

No comments:
Post a Comment