这不是什么有点不优点的问题，这主要是个业务需求的问题。 如果业务需求没有明确要求，那么为了管理数据的方便，要根据数据库原理中的数据依赖的拆分原则将数据模式拆分不为3NF或者BCNF，最终一般会形成表的主从结构。
举个例子： 如果学生有号和姓名， student --》sid,sname 课程有课程号和课程名，course -->cid,cname 每个学生的每个课程都有成绩， 如果你将这些信息保存在一个表中,那就是： sid,sname,cid,cname,scorse 完全可以满足业务需要， 那么记录可能就是： sid,sname,cid,cname,score s1,sn1,c1,cn1,100 s2,sn2,c1,cn1,90 s1,sn1,c2,cn2,99 s2,sn2,c3,cn3,95 看起来没有问题，但是当你更新学生姓名（比如：sn2）或者更新学科名称(比如：cn2)时，你就会发现，你必须更新多条记录； 这说明这些数据之间的依赖关系没有分析清楚： 例如：学生姓名和学生学号一对依赖关系，课程编号和课程名是一对依赖关系；而成绩则依赖于学号和课程号； 按照数据库理论说：就是出现了依赖传递，数据不规范，需要进行拆分 按照上面描述，那么可以拆为如下三个表： staudents(sid,sname) 学生表 courses(cid,cname) 课程表 scores(sid,cid,score) 成绩表 这时候，数据依赖关系就被拆为三个，此时数据模式就成为3NF 那么上述问题就不存在了， 此时出现了两个主从结构的表（<指向的表示主表）： students <---- scores course <----- scores 这样拆分的好处是解决了数据依赖的问题，但是但是导致了数据查询需要进行数据表链接，也就是说不连接表，不能一次查询出一个学生的所有信息（个人信息和学科信息、成绩） 如何选择需要你根据实际进行选择，不能说什么就比什么好 。
答：E是唯一的候选码； 对于给定的R,可以将它的属性划分为4类: L类,仅出现在F的函数依赖左部的属性. R类,仅出现在F的函数依赖右部的属性. N类,在F的函数依...详情>>
答：不知道你是不是写错文件名了，pdf?详情>>
答：当电脑的全部组件（包括软件）我们国家都能生产的时候。详情>>
