Informal Design Guidelines for Relational Databases

GUIDELINE 1

各司其职,每个表有相应表名,各部分分开,不要混在一起,用foreign key连接

Bottom Line: Design a schema that can be explained
easily relation by relation. The semantics of attributes
should be easy to interpret.

不这样做的缺点:

  1. 浪费空间(矩阵相乘,大很多,造成大量冗余)
  2. 造成异常(Anomaly)

    • 更新异常(Update Anomaly)
    • 插入异常(Insert Anomaly)
    • 删除异常(Delete Anomaly)

更新异常(Update Anomaly)

例如:有如下table
EMP_PROJ (Emp#, Proj#, Ename, Pname, No_hours)
如果我想要更改一个project name, 有同时1000个人在这个项目工作,那么需要遍历整个表,更新1000条信息,才能完成任务。

插入异常(Insert Anomaly)

例如:有如下table
EMP_PROJ (Emp#, Proj#, Ename, Pname, No_hours)
假设Emp#和Proj#是主键,不可为空
如果我想要插入一个新项目,未来项目,但是现在没有空余人手来做,那么我无法插入这个项目,因为没有Emp#
同样原因,我们无法插入一个没事儿干的员工

删除异常

例如:有如下table
EMP_PROJ (Emp#, Proj#, Ename, Pname, No_hours)
如果说我需要删除一个项目,且恰巧有员工仅在这一个项目下工作,那么结果就是把员工和项目一起全删了
同样,也无法删员工,项目没了

GUIDELINE2

不要有异常

GUIDELINE3

如果表中出现了很多NULL的tuple, 那么你最好想想,怎样把有很多NULL的attribute单独做成另一个表,以节省空间,并避免异常
同时,不要直接写入另一个表的primary key, 而是做一个单独的对应表,因为如果直接引入primary key,还是会有很多null,相反,做一个对应表,因为数据量不大,对应表会很小

例如:有如下table

EMP(Emp#, Ename, Address, office#, office_name)
因为只有少数人有独立办公室,所以大部分人的office#和office_name将是NULL。

此时,如果单独建一个表,变成这样
EMP(Emp#, Ename, Address, office#)
Office(office#, office_name)
虽然会减少一部分,但是office#依然会有大量的NULL

那么,
EMP(Emp#, Ename, Address)
EMP_OFFICE(Emp#, office#)
Office(office#, office_name)
建立对应表之后,数据将不会有null

GUIDELINE 4

Natural Join不能产生Spurious(假的) Tuples, 也就是不能产生不存在的,不正确的,多余的行
table N 和 table M, natural join, 不要产生 NxM 或者 多于真正存在的记录的数量,比如工号不能对应到不存在的名字上,如果工号和名字在两个不同的table里

Function Dependency

Last modification:June 18th, 2020 at 10:34 pm
如果觉得我的文章对你有用,请随意赞赏