数据库系统概念实践习题部分答案（未必翻译完全）

最新推荐文章于 2024-08-27 09:47:54 发布

清润胖大海

最新推荐文章于 2024-08-27 09:47:54 发布

阅读量8.4k

点赞数 18

分类专栏：数据库系统概念文章标签： E-R模型数据库设计事务管理并发控制冲突可串行化

本文链接：https://blog.csdn.net/qq_38336763/article/details/111997979

版权

数据库系统概念专栏收录该内容

3 篇文章 11 订阅

订阅专栏

文章目录

数据库设计和E-R模型
事务管理

数据库设计和E-R模型

为车辆保险公司构建一个E-R图，它的每个客户有一辆或多辆车，每辆车关联零次或任意次视图的记录。每张保险单为一辆或多辆车保险，并与一个或多个保费支付相关联。每次支付只针对一个特定的事件，具有关联的到期日和缴费日。

答：

在这里插入图片描述

考虑一个用于记录学生在不同开课(section)的不同考试中所得成绩的数据库

1.为数据库构造一个E-R图，其中，将考试建模为实体并使用一个三元联系。

2.构造另一个E-R图，其中，只用students和section间的二元联系。保证在特定students和section对之间只存在一个联系，而且你可以表示出学生在不同考试中所得成绩。

在这里插入图片描述

设计一个E-R图用于跟踪记录你最喜欢的球队的成绩。你应该保存打过的比赛，每场比赛的比分，每场比赛的上场队员以及每个队员在每场比赛中的统计数据。总的统计数据应该被建模成派生属性。（不是基本属性而是可以被计算出的属性）

在这里插入图片描述

考虑一个E-R图，相同的实体集出现数次，且它的属性重复出现多次。为什么这样的冗余是应精良避免的不良设计？

答：因为这样容易出现不一致错误。

E-R图可视为一个图，下面这些术语对于一个企业模式的结构意味着什么?

1.图是非连通的。2.图是有环的。

答:1.如果一对实体集中有路径的存在，那怕是间接的，我们也说它们是相连。在一个企业模式中，如果图是非连通的，则代表这两个部分是完全独立的。

2.有环的至少两个实体集之间就有多种方面的相互关联，而无环每一对实体集之间的路径就只有一个独特的关系。

一个弱实体集总可以通过往自己的属性中加入其标识实体集的主码属性而变成一个强实体集。概括一下如果我们这么做会产生怎样的冗余？

答：弱实体集的主键可以从它与强实体集的关系得到。如果我们添加主键属性
到弱实体集，它们将同时存在于实体集和关系集，而且它们将会是是相同的。因此，会有冗余。

考虑一个关系，例如sec_course，产生于多对一的联系sec_course。在这个关系上创建的主码约束和外码约束是否强制实施多对一的基数约束？为什么。

在这里插入图片描述

答：在这个例子中，section的主键由course_id、sec_id、semester、year组成，这也是sec_course的主键，而course_id是sec_course的外键，这些约束保证了一节课只能对应于一门课程，因此多对一的基数约束是被保证了的，但是全参与约束不能保证。

假设advisor联系是一对一的。为了确保执行一对一基数约束，在关系advisor上需要哪些额外的约束?

答：除了声明s_ID为advisor的主键外，我们还声明i_ID为advisor的超码，这可以在SQL中对i_ID使用unique约束来实现。

考虑实体集A和B之间多对一联系R，假设从R生成的关系和A生成的关系合并了。在SQL中，参与外码约束的属性可以为空。解释如何使用SQL上的not null约束来强制实施A在R中的全部参与约束。

答：首先R中的外键B应该是not null，这样确保A中没有元组在R中但是没有联系上B中任何的值。例如a是A中的一个没有在R中的元组，这表示当A和R合并的时候，对应的联系B的外键是null，这是不被允许的。

在SQL中，外码约束只能参照被参照关系上的主码属性，或者其他用unique约束声明为超码的属性。这导致多对多联系（或者一对多联系的“一”方）上的全部参与约束在从该联系创建的关系上无法用关系上的主码、外码以及非空约束强制实施。1.解释一下为什么2.解释如果使用复杂check或者断言来强制实时全部参与约束。

答：1.因为无论是多对多联系还是一对多联系的"一"方，联系集和实体集都无法合并。SQL目前没有办法去保证存在实体集的主键的一个值在多对多联系集上也同样出现，对于一对多联系的“一”那方也是如此。

2.Let the relation R be many-to-one from entity A to entity B with a and b as their respective primary keys, repectively. We can put the following check constraints on the “one” side relation B:

constraint total_ part check (b in (select b from A));

set constraints total_part deferred;

Note that the constraint should be set to deferred so that it is only checked at the end of the transaction; otherwise if we insert a b value in B before it is inserted in Athe above constraint would be violated, and if we insert it in Abefore we insert it in B, a foreign key violation would occur.