标签：联系 -- 软考 数据库 公告 员工 部门 编号 接收

例：【说明】

某企业拟构建一个高效、低成本、符合企业实际发展需要的办公自动化系统。工程师小李主要承担该系统的公告管理和消息管理模块的研发工作。公告管理模块的主要功能包括添加、修改、删除和查看公告。消息管理模块的主要功能是消息群发。

小李根据前期调研和需求分析进行了概念模型设计，具体情况分述如下：

【需求分析结果】

(1)该企业设有研发部、财务部、销售部等多个部门，每个部门只有一名部门经理，有多名员工，每名员工只属于一个部门，部门信息包括：部门号、名称、部门经理和电话，其中部门号唯一确定部门关系的每一个元组。

(2)员工信息包括：员工号、姓名、岗位、电话和密码。部门号员工号唯一确定员工关系的每一个元组；岗位主要有经理、部门经理、管理员等，不同岗位具有不同的权限。一名员工只对应一个岗位，但一个岗位可对应多名员工。

(3)消息信息包括：编号、内容、消息类型、接收人、接收时间、发送时间和发送人。其中（编号，接收人）唯一标识消息关系中的每一个元组。一条消息可以发送给多个接收人，一个接收人可以接收多条消息。

(4)公告信息包括：编号、标题、名称、内容、发布部门、发布时间。其中编号唯一确定公告关系的每二个元组。一份公告对应一个发布部门，但一个部门可以发布多份公告；一份公告可以被多名员工阅读，一名员工可以阅读多份公告。

 

【概念模型设计】

 

根据需求分析阶段收集的信息，设计的实体联系图（不完整）如图2-1所示：

【逻辑结构设计】

根据概念模型设计阶段完成的实体联系图，得出如下关系模式（不完整）：

部门((a)，部门经理，电话)

员工(员工号，姓名，岗位号，部门号，电话，密码）

岗位(岗位号，名称，权限）

消息((b)，消息类型，接收时间，发送时间，发送人）

公告((c)，名称，内容，发布部门，发布时间）

阅读公告((d)，阅读时间)

 

【问题1】

 

根据问题描述，补充四个联系，完善图2-1所示的实体联系图。联系名可用联系1、联系2、联系3和联系4代替，联系的类型分为1:1、1:n和m:n（或1:1、1:*和*：*）。

 

【问题2】

 

(1)根据实体联系图，将关系模式中的空(a)～(d)补充完整。

 

(2)给出“消息”和“阅读公告”关系模式的主键与外键。

 

【问题3】

 

消息和公告关系中都有“编号”属性，请问它是属于命名冲突吗？用100字以内文字说明原因。

解析：

【问题1】注意，求的是补充联系，需要完善联系图，要把联系也写出来。

 

 

【问题2】①

(1)(a)部门号，名称

(b)编号，内容，接收人

(c)编号，标题

(d)公告编号，员工号(注：编号，员工号也正确)

②消息关系模式的主键：编号，接收人

 

外键：接收人、发送人【注意：非主属性也是可以做外键的，这点要小心】

 

阅读公告关系模式的主键：公告编号，员工号

 

外键：公告编号，员工号

 

 

【问题3】 

答：不冲突，消息和公告关系中都有“编号”属性，但是它们不属于命名冲突。因为这两个属性分别属于两个不同的关系模式，可以通过“关系名.属性名”区别’即可以用“消息.编号”和“公告.编号”来区别。

 

标签：联系,--,软考,数据库,公告,员工,部门,编号,接收
来源： https://www.cnblogs.com/yansunda/p/14803834.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。