数据库系统工程师下午上半年文档格式.docx

数据库系统工程师下午上半年文档格式.docx

《数据库系统工程师下午上半年文档格式.docx》由会员分享，可在线阅读，更多相关《数据库系统工程师下午上半年文档格式.docx（13页珍藏版）》请在冰豆网上搜索。

病人E2：

护理人员E3：

医生

详细解答：

本题考查数据流图（DFD）应用于采用结构化方法进行系统分析与设计，是比较传统的题目，要求考生细心分析题目中所描述的内容。

DFD是一种便于用户理解、分析系统数据流程的图形化建模工具，是系统逻辑模型的重要组成部分。

本问题考查项层DFD。

顶层DFD一般用来确定系统边界，将待开发系统看作一个加工，因此图中只有唯一的一个处理和一些外部实体，以及这两者之间的输入输出数据流。

题目要求根据描述来确定图中的外部实体。

分析题目中的描述，并结合已经在顶层数据流图中给出的数据流进行分析。

从中可以看出，与系统的交互者包括病人、医生和医护人员。

其中，本地监控定期获取病人的生命特征，病人是生命特征数据来源，医生和护理人员会得到相关报告的结果，如请求病人生命特征报告，并获得相关报告。

医生还需要在必要时添加或更新生命特征范围。

对应图10中数据流和实体的对应关系，可知E1为病人，E2为护理人员，E3为医生。

第2题：

使用说明中的词语，给出图1-2中的数据存储D1～D4的名称。

D1：

生命特征范围文件D2：

日志文件D3：

病历文件D4：

治疗意见文件

本问题考查0层DFD中数据存储的确定。

根据说明中的描述：

（2）格式化生命特征：

对病人的各项重要生命特征数据进行格式化，然后存入日志文件并检查生命特征；

（4）维护生命特征范围：

医生在必要时（如，新的研究结果出现时）添加或更新生命特征值的正常范围；

（6）生成病历：

根据日志文件中的生命特征，医生对病人的病情进行描述，形成病历存入病历文件；

（8）生成治疗意见：

因此，D1为生命特征范围文件，D2为日志文件，D3为病例文件，D4为治疗意见文件。

第3题：

图1-2中缺失了4条数据流，使用说明、图1-1和图1-2中的术语，给出数据流的名称及其起点和终点。

本问题考查0层DFD中缺失的处理和数据流。

从说明中的描述及图1-2可知，本地监控之后要对重要生命特征存储日志文件进行格式化，所以在本地监控和格式化生命特征之间缺少了数据流重要生命特征；

检查生命特征是对格式化后的生命特征进行检查，所以在格式化生命特征和检查生命特征之间缺少了数据流格式化后的生命特征；

第4题：

说明实体E1和E3之间可否有数据流，并解释其原因。

E1和E3之间不可以有数据流，因为数据流的起点和终点中必须有一个是加工（处理）。

本问题考查绘制DFD时的注意事项。

在DFD中，每条数据流的起点和终点之一必须是加工（处理）。

本题中，医生和护理人员根据查询到的治疗意见对病人进行治疗属于系统之外的行为，所以两个实体之间不可以有数据流。

试题二

阅读下列说明，回答问题1至问题3，将解答填入对应栏内。

某法院要开发一个诉讼案件信息处理系统，该信息系统的部分关系模式如下：

职工（职工编号，姓名，岗位）

律师（律师编号，姓名）

被告（被告编号，姓名，地址）

案件（案件编号，案件类型，案件描述，被告，律师，主审法官，立案日期，状态，结案日期，结案摘要）

审理（审理编号，案件编号，审理日期，摘要）

有关关系模式的属性及相关说明如下：

（1）职工关系模式的岗位有“法官”、“书记员”和“其他”。

（2）诉讼立案后，即在案件关系中插入一条相应记录。

案件关系模式的状态有“待处理”、“审理中”、“结案”和“撤销”，一个案件开始立案时其案件状态为“待处理”。

（3）案件关系模式的案件类型有“偷窃”、“纵火”等。

（4）一个案件自立案到结案的整个过程由一位法官和一位律师负责，一个案件通常经过一次到多次审理。

第5题：

假设案件编号唯一标识一个案件，且立案日期小于等于结案日期。

请将如下创建案件关系的SQL语句的空缺部分补充完整。

CREATETABLE案件（

案件编号CHAR（6）（a）,

案件类型VARCHAR（10）,

案件描述VARCHAR（200）,

立案日期DATE,

被告VARCHAR（6）REFERENCES被告（被告编号）,

律师VARCHAR（6）REFERENCES律师（律师编号）,

主审法官VARCHAR（6）（b）,

状态VARCHAR（6）（c）DEFAULT´

待处理´

结案日期DATE,

结案摘要VARCHAR（200）,（D）

};

（a）PRIMARYKEY或NOTNULLUNIQUE（b）REFERENCES职工（职工编号）（c）CHECKVALUESIN（´

，´

审理中´

结案´

撤销´

）（d）CHECK（立案日期＜=结案日期）

本题考查SQL语言，是比较传统的题目，要求考生细心分析题目中所描述的内容。

本问题考查SQL中的数据定义语言DDL和完整性约束。

完整性约束包括三类：

实体完整性、参照完整性和用户定义的完整性。

实体完整性约束规定关系的主属性不能取空值，关系模型中以主码作为唯一性标识；

参照完整性约束规定若属性（或属性组）A是关系R上的主码，B是关系S上的外码，A与B相对应（来自相同的域），则B取值为空或者来自于R上的某个A的值；

用户定义的完整性约束是针对具体的数据库应用而定义的，它反映该应用所涉及的数据必须满足用户定义的语义要求。

（a）考查实体完整性约束，案件编号是案件关系模式的主码，用关键字PRIMARYKEY或者NOTNULLUNIOUE表示。

（b）考查参照完整性约束，主审法官属性参照职工关系模式中的职工编号属性，由于这两个属性名称不同，因此用REFERENCES职工（职工编号）表示，此处不能省略职工编号。

（c）、（d）考查用户定义的完整性约束。

（c）是在状态属性上定义列级约束，用CHECKVALUESIN（´

）表示。

（d）在立案日期和结案日期上定义约束，用CHECK（立案日期＜=结案日期）表示。

第6题：

请完成下列查询的SQL语句。

（1）查询当前待处理的诉讼案件，显示案件的案件编号、立案日期、被告姓名、被告地址、案件描述、律师姓名和主审法官姓名。

SELECT案件编号,立案日期,被告.姓名，AS被告姓名,地址AS被告地址,案件描述,律师.姓名AS律师姓名,（e）

FROM（f）

WHERE案件.被告=被告.被告编号AND案件.律师=律师.律师编号AND

（g）;

（2）查询2009年立案的各类案件数，并按案件数降序排序。

（日期格式举例：

2009年1月1日表示为01-JAN-2009，2009年12月31日表示为31-DEC-2009）

SELECT类型，count（*）AS案件数

FROM案件

WHERE（h）d

GROUPBY类型

（i）;

（3）查询立案次数超过5次的被告姓名和地址。

SELECT姓名,地址,count（*）

FROM案件,被告

WHERE（j）d

GROUPBY（k）d

（l）;

（1）（e）姓名AS主审法官姓名（f）案件，被告，律师，职工（关系模式的顺序无关）（g）主审法官=职工.职工编号

（2）（h）立案日期BETWEEN´

01-JAN-2009´

AND´

31-DEC-2009´

或者立案日期＞=´

AND立案日期＜=´

（i）ORDERBY案件数DESC（3）（j）被告=被告.被告编号（k）姓名，地址（l）HAVINGcount（*）＞5

本问题考查SQL中的数据操作语言DML。

（1）考查别名和连接查询条件。

（e）处考核别名定义，用AS关键字，且别名根据题干给出，应填“职工．姓名AS主审法官姓名”；

（f）处考查该查询涉及到的关系模式，此处应涉及到案件、被告、律师和职工4个关系模式，在FROM子句中关系模式是顺序无关的；

（g）处考核案件关系模式和职工关系模式的连接条件，即“案件.主审法官=职工.职工编号”。

（2）考查日期属性并对查询结果进行分组和排序。

（h）处主要考核日期作为条件属性的语法，题干中已经给出日期格式的提示。

在两个日期之间的时间的语法可以用BETWEEN…AND…，也可以用＞…＜=，因此，此处可以填“立案日期BETWEEN´

"

或者“立案日期＞=´

31-DEC.2009´

；

（i）处考核查询结果的排序，用“ORDERBY案件数DESC”表示，其中的DESC关键字不能省略。

在ORDERBY子句中，若不用表示升序的关键字ASC或表示降序的关键字DESC表示，则默认为升序排序。

（3）考查对查询结果进行分组，并指定满足条件的分组才能输出。

（i）处考核两个关系模式的连接关系，应填“案件.被告=被告.被告编号”；

（k）处考核分组，此处填“姓名，地址”，不能仅填姓名或者地址；

（1）处考核分组条件，用HAVING关键字，应填“HAVINGcount（*）＞5”。

第7题：

当插入一个审理记录时，检查案件的状态，若状态为“未处理”，则将其修改为“审理中”。

下面是用触发器实现该需求的SQL语句，请将空缺部分补充完整。

CREATETRIGGER 审理TRIGGERAFTER（m）ON审理

REFERENCINGnewrowASnrow

FOREACHrow

WHEN´

未处理´

=（SELECT状态

WHERE案件编号=nrow.案件编号）

BEGIN

UPDATE案件（n）d

WHERE（o）;

END

（m）INSERT（n）SET状态=´

（o）案件编号=nrow案件编号

本问题考查触发器。

触发器是一个能由系统自动执行对数据库修改的语句。

一个触发器由事件、条件和动态三部分组成：

事件即对数据库的插入、删除和修改等操作。

触发器在这些事件发生时，将开始工作；

条件是指触发器将测试条件是否成立，若成立就执行相应的动作，否则就什么也不做；

动态是指若触发器测试满足预定的条件，那么就由数据库管理系统执行这些动作。

本题首先定义触发器的事件，即对审理关系模式插入后激活触发器。

接下来定义触发器的动作，即修改案件关系模式的状态为“审理中”，测试条件为若该案件原来状态为“待处理”，需要关联的两个关系模式是案件和审理。

试题三

某服装销售公司拟开发一套服装采购管理系统，以方便对服装采购和库存进行管理。

[需求分析]

（1）采购系统需要维护服装信息及服装在仓库中的存放情况。

系统按服装的销售种类记录服装信息。

服装信息主要包括：

服装编码、服装描述、服装类型、销售价格、尺码和面料，其中，服装类型为销售分类，服装按销售分类编码。

仓库信息主要包括：

仓库编码、仓库位置、仓库容量和库管员。

系统记录库管员的库管员编码、姓名和级别。

一个库管员可以管理多个仓库，每个仓库有一名库管员。

一个仓库中可以存放多类服装，一类服装可能存放在多个仓库中。

（2）当库管员发现有一类或者多类服装缺货时，需要生成采购订单。

一个采购订单可以包含多类服装。

每类服装可由多个不同的供应商供应，但具有相同的服装编码。

采购订单主要记录订单编码、订货日期和应到货日期，并需详细记录所采购的每类服装的数量、采购价格和对应的多个供应商。

（3）系统需记录每类服装的各个供应商信息和供应情况。

供应商信息包括：

供应商编码、供应商名称、地址、企业法人和联系电话。

供应情况记录供应商所供应服装的服装类型和服装质量等级。

一个供应商可以供应多类服装，一类服装可由多个供应商供应。

库管员根据入库时的服装质量情况，设定或修改每个供应商所供应的每类服装的服装质量等级，用以作为后续采购服装时，选择供应商的参考标准。

[概念模型设计]

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

[逻辑结构设计]

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

库管员（

（1） ，姓名，级别）

仓库信息（

（2） ，仓库位置，仓库容量）

服装（服装编码，服装描述，服装类型，尺码，面料，销售价格）

供应商（（3） ，供应商名称，地址，联系电话，企业法人）

供应情况（（4） ，服装质量等级）

采购订单（（5））

采购订单明细（（6））

第8题：

补充图3-1中的联系和联系的类型。

本题考查数据库设计，属于比较传统的题目，考查点也与往年类似。

本问题考查数据库的概念结构设计，题目要求补充完整实体联系图中的联系和联系的类型。

根据题目的需求描述可知，一个库管员可以管理多个仓库，每个仓库有一名库管员。

所以，仓库实体和库管员实体之间存在“管理”联系，联系的类型为多对一（*:

1）。

根据题目的需求描述可知，一个仓库中可以存放多类服装，一类服装可能存放在多个仓库中。

所以，仓库实体和服装实体之间存在“存放”联系，联系的类型为多对多（*:

*）。

根据题目的需求描述可知，一个采购订单可以包含多类服装，每类服装可由多个不同的供应商供应。

所以，采购订单实体与服装实体和供应商实体三者之间存在“采购”联系，三者之间联系的类型为多对多对多（*:

*:

根据题目的需求描述可知，一个供应商可以供应多类服装，一类服装可由多个供应商供应。

所以，供应商实体和服装实体之间存在“供应”联系，联系的类型为多对多（*:

第9题：

根据图3-1，将逻辑结构设计阶段生成的关系模式中的空

（1）～（6）补充完整。

对所有关系模式，用下划线指出各关系模式的主键。

（1）仓库编码，库管员编码

（2）供应商编码，服装编码（3）订单编码，订货日期，应到货日期（4）订单编码，服装编码，供应商编码，数量，采购价格

本问题考查数据库的逻辑结构设计，题目要求补充完整各关系模式，并给出各关系模式的主键。

根据实体联系图和需求描述，系统记录库管员的库编码、姓名和级别。

所以，对于“库管员”关系模式，需补充属性“库管员编码”。

根据实体联系图和需求描述，仓库信息主要包括：

对于“仓库信息”关系模式，由于仓库实体与库管员实体有多对一联系，需记录对应的库管员，并且需补充属性——仓库编码。

因此，“仓库信息”关系模式，需补充属性“仓库编码”和“库管员编码”。

根据实体联系图和需求描述，供应商信息包括：

所以，对于“供应商”关系模式，需补充属性“供应商编码”。

根据实体联系图和需求描述，“供应情况”关系模式需记录供应商和服装的多对多联系，即一个供应商可以供应多类服装，一类服装可由多个供应商供应。

所以，对于“供应商”关系模式，需补充属性“供应商编码”和“服装编码”。

根据实体联系图和需求描述，采购订单主要记录订单编码、订货日期和应到货日期。

所以，对于“采购订单”关系模式需补充属性：

订单编码，订货日期，应到货日期。

由于采购订单还需详细记录所采购的每类服装的数量、采购价格和对应的多个供应商。

因此，“采购订单明细”关系模式，需记录采购订单实体与服装实体和供应商实体三者之间存在的多对多对多联系。

对于“采购订单明细”关系模式，需补充属性“订单编码，服装编码，供应商编码，数量，采购价格”。

第10题：

如果库管员定期需要轮流对所有仓库中的服装质量进行抽查，对每个仓库中的每一类被抽查服装需要记录一条抽查结果，并且需要记录抽查的时间和负责抽查的库管员。

请根据该要求，对图3-1进行修改，画出修改后的实体间联系和联系的类型。

本问题考查的是数据库的概念结构设计，根据新增的需求增加实体联系图中的实体的联系和联系的类型。

根据问题描述，多个库管员需对每个仓库中的每一类被抽查服装记录一条抽查结果。

则须在库管员实体与仓库实体和服装实体三者之间的存在“抽查”联系，联系的类型是多对多对多（*:

试题四

某学校拟开发一套校友捐赠管理系统，以便对校友的捐赠资金进行管理。

校友可以向学校提出捐赠申请，说明捐赠的金额、捐赠类型和使用方式。

捐赠类型包括一次性捐赠和周期性捐赠。

捐赠的使用方式分为两种：

一种用于资助个人，即受益人为多名学生或老师，主要用于奖学金、奖教金和助学金等；

另一种用于资助捐赠项目，即资助已有的捐赠项目和设立新的捐赠项目，主要用于改善教学设施、实验室建设和设备购买等。

捐赠项目由捐赠理事建立，一个捐赠项目可以涉及多个受益单位，每个单位在该项目中有确定的受益比例。

由捐赠理事为项目中的每个单位指定一个项目负责人，并指定每个单位受益比例。

每个单位的受益比例是指在一个捐赠项目中的每个单位所应得的金额占该捐赠项目总受益金额的比例。

一个捐赠项目可以由多个捐赠来资助，一个捐赠也可以资助多个捐赠项目。

由捐赠理事将一个捐赠的捐赠金额分配给所资助的多个捐赠项目，并指定给每个捐赠项目的具体的捐赠金额。

初步设计了校友捐赠信息数据库，其关系模式如图4-1所示。

第11题：

对关系“校友信息”，请回答以下问题：

（1）列举出所有候选键的属性。

（2）关系“校友信息”可达到第几范式，用60字以内文字简要叙述理由。

（1）“校友编号”和“身份证号”。

（2）“校友信息”关系模式可以达到第二范式，不满足第三范式。

由于“校友信息”关系模式的主键是“校友编号”，但又包含函数依赖：

班级→院系，入学年份不满足第三范式的要求，即存在非主属性对码的传递依赖。

本题考查数据库理论的规范化，属于比较传统的题目，考查点也与往年类似。

本问题考查非主属性和第三范式。

根据“校友信息”关系模式可知，“校友编号”和“身份证号”都是校友信息的决定因素，因此都是候选键的属性。

根据第三范式的要求：

每一个非主属性既不部分依赖于码也不传递依赖于码。

根据“校友信息”关系模式，其中存在以下函数依赖：

班级→院系，入学年份而由于“校友信息”关系模式的主键是“校友编号”，因而，存在非主属性对码的传递依赖。

所以，“校友信息”关系模式可以达到第二范式，但不满足第三范式。

第12题：

对关系“捐赠信息”，请回答以下问题：

（1）针对“捐赠信息”关系，用100字以内文字简要说明会产生什么问题。

（2）把“捐赠信息”分解为第三范式，分解后的关系名依次为：

捐赠信息1，捐赠信息2，……

（3）列出“捐赠信息”关系修正后的各关系模式的主键。

（1）“捐赠信息”关系不满足第二范式，即非主属性不完全依赖于码。

（2）会造成：

插入异常、删除异常和修改复杂（或修改异常）。

（3）分解后的关系模式如下：

捐赠信息1（捐赠编号，捐赠校友，捐赠时间，捐赠金额，捐赠类型，使用方式）捐赠信息2（受益人身份证号，受益人姓名，受益人所在单位，受益人类型）捐赠信息3（捐赠编号，受益人身份证号，受益金额，使用说明）

（1）修正后的主键如下：

捐赠信息1（<

u>

捐赠编号<

/u>

，捐赠校友，捐赠时间，捐赠金额，捐赠类型，使用方式）捐赠信息2（<

受益人身份证号<

，受益人姓名，受益人所在单位，受益人类型）捐赠信息3（<

捐赠编号，受益人身份证号<

，受益金额，使用说明）

本问题考查第二范式和第三范式。

非主属性不完全依赖于码。

根据“捐赠信息”关系模式，可知其码为（捐赠编号，受益人身份证号），而又存在部分函数依赖：

捐赠编号→捐赠校友，捐赠时间，捐赠金额，捐赠类型，使用方式。

受益人身份证号→受益人姓名，受益人所在单位，受益人类型。

所以，捐赠信息”关系不满足第二范式，会造成：

因为存在部分函数依赖，因此对“捐赠信息”进行分解，分解后的关系模式如下：

捐赠信息1（捐赠编号，捐赠校友，捐赠时间，捐赠金额，捐赠类型，使用方式）捐赠信息2（受益人身份证号，受益人姓名，受益人所在单位，受益人类型）捐赠信息3（捐赠编号，受益人身份证号，受益金额，使用说明）其中，“捐赠信息1”关系的函数依赖为：

“捐赠信息2”关系的函数依赖为：

“捐赠信息3”关系的函数依赖为：

捐赠编号，受益人身份证号→受益金额，使用说明。

这三个关系中的每一个非主属性既不部分依赖于码也不传递依赖于码，因此满足第三范式的要求。

第13题：

对关系“项目受益情况”，请回答以下问题：

（1）关系“项目受益情况”是不是第四范式，用100字以内文字叙述理由。

（2）把“项目受益情况”分解为第四范式，分解后的关系名依次为：

项目受益情况1，项目受益情况2，……

（1）“项目受益情况”关系模式，不满足第四范式。

（2）分解后的关系模式如下：

项目受益情况1（项目编号，受益单位，受益比例）项目受益情况2（项目编