軟件水平考試（中級）軟件設計師下午

（應用技術）試題模擬試卷第1套

一、必答題（本題共18題，每題1.0分，共18分。）

某基于微處理器的住宅系統(tǒng)，使用傳感器（如紅外探頭、攝像頭等）來檢測各種意外

情況，如非法進入、火警、水災等。房主可以在安裝該系統(tǒng)時配置安全監(jiān)控設備

（如傳感器、顯示器、報警器等），也可以在系統(tǒng)運行時修改配置，通過錄像機和電

視機監(jiān)控與系統(tǒng)連接的所有傳感器，并通過控制面板上的鍵盤與系統(tǒng)進行信息交

互。在安裝過程中，系統(tǒng)給每個傳感器賦予一個編號（即ID）和類型，并設置房主密

碼以啟動和關閉系統(tǒng)，沒置傳感器事件發(fā)生時應自動撥出的電話號碼。當系統(tǒng)檢測

到一個傳感器事件時.，就激活警報，撥出預置的電話號碼，并報告關于位置和檢測

到的事件的性質等信息。住宅安全系統(tǒng)頂層數(shù)據(jù)流圖和第0層數(shù)據(jù)流圖如圖12-3

m12-3住宅安全系統(tǒng)段3：數(shù)據(jù)流圖

用戶配置請求

和圖1-4所示。W12-5住宅安全系及第I星數(shù)密洸圖

1、在圖12-3中，數(shù)據(jù)流圖（住宅安全系統(tǒng)項層圖）中的A和B分別是什么？

標準答案：A：傳感器。B：報警器。

知識點解析：此題和以往試題有所不同，以往都給定了完整正確的頂層圖，現(xiàn)在頂

層圖不完整，可以通過題目說明信息及頂層圖來分析頂層圖并解答問題。題目中提

到了“房主可以在安裝該系統(tǒng)時配置安全監(jiān)控設備（如傳感器、顯示器、報警器

等）“，在頂層圖中這3個名詞都沒有出現(xiàn)。但仔細觀察，可以看出“電視機”實際上

就是“顯示器”，因為它接收TV信號并輸出。其他妁幾個實體都和“傳感器"、“報

警器''沒有關聯(lián)。又因為A中輸出“傳感器狀態(tài)”到“住宅安全系統(tǒng)”，所以A應填

“傳感器”。B接收“告警類型”，所以應填“報警器”。

2、在圖12-4中，數(shù)據(jù)流圖（住宅安全系統(tǒng)第。層DFD圖）中的數(shù)據(jù)存儲“配置信息”

會影響圖中的哪些加工。

標準答案：4.監(jiān)控傳感器。5.顯示信息和狀態(tài)。

知識點解析：首先，毫無疑問“4監(jiān)控傳感器”用到了配置信息文件，這一點可以在

加工4的細化圖中看出。同時由于輸出到“5顯示信息和狀態(tài)”的數(shù)據(jù)流是“檢驗ID

信息”，所以"5顯示信息和狀態(tài)”也用到了配置信息文件。

3、如圖12-5所示，將數(shù)據(jù)流圖（加工4的細化圖）中的數(shù)據(jù)流補充完整，并指明加

工名稱、數(shù)據(jù)流的方向（輸入輸出）和數(shù)據(jù)流名稱.

標準答案：補充的數(shù)據(jù)流如表12-6所示。

?12-4樸先的效據(jù)猊

,加工名稱效嘉潭的方向敷據(jù)漉名林

4.1顯示格式輸出傳黑器數(shù)點

4.4讀傳感器輸入傳感器狀毒

4.5撥號泊出電話撥號

知識點解析：暫無解析

4^請說明邏輯數(shù)據(jù)流圖（LogicalDataFlowDiagram）和物理數(shù)據(jù)流圖（PhysicalData

FlowDiagram）之間的主要區(qū)別。

標準答案：物理數(shù)據(jù)流圖關注的是系統(tǒng)中的物理實體，以及一些具體的文檔、報告

和其他輸入/輸出硬拷貝。物理數(shù)據(jù)流圖用做系統(tǒng)構造和實現(xiàn)的技術性藍圖。邏

輯數(shù)據(jù)流圖強調參與者所做的事情，可以幫助設計者決定需要哪些系統(tǒng)資源、為了

運行系統(tǒng)用戶必須執(zhí)行的活動、在系統(tǒng)安裝之后如何保護和控制這些系統(tǒng)。邏輯數(shù)

據(jù)流圖是物理數(shù)據(jù)流圖去掉了所有的物理細節(jié)后得到的變換形式，邏輯數(shù)據(jù)流圖被

用做系統(tǒng)分析的需求分析階段的起點。

知識點解析：本題是一道分層數(shù)據(jù)流圖的題。解答此類問題最關鍵的一點就是要細

心，把題目看清，不要丟掉任何一個條件。還有就是解題有一定的技巧，從一些常

規(guī)的入口作為突破口，會事半功倍。現(xiàn)在就利用分層數(shù)據(jù)流圖的數(shù)據(jù)流的平衡原則

（即父圖和子圖（加工圖）的一致性）來解題。子圖是其父圖中某一部分內部的細節(jié)圖

（加工圖）。它們的輸入輸出數(shù)據(jù)流應該保持一致。就像看到地上有只螞蟻有6條細

細的腿，中間是一個小黑點，想看得更清楚一些就拿個放大鏡看。這時，能看到它

的頭、觸角、身體和比較粗的腿，但是看到的一定還是6條腿，不是7條，也不是

3條。子圖也是如此，在上一級中有幾個數(shù)據(jù)流，它的子圖也一定有同樣的數(shù)據(jù)

流，而且它們的輸送方向是一致的（也就是說原圖有3條進的數(shù)據(jù)流、2條出的，子

圖同樣也是）。用這一條原則可以輕松地解決問題3。在0層圖中，“4監(jiān)控傳感器”

模塊有1條輸入數(shù)據(jù)流“傳感器狀態(tài)”和3條輸出數(shù)據(jù)流“電話撥號”、“傳感器數(shù)據(jù)”

和“告警類型”。但在加工4的細化圖中，只看到了輸出數(shù)據(jù)流“告警類型”。所以很

快就知道此加工圖少了“傳感器狀態(tài)”、“電話撥號”、“傳感器數(shù)據(jù)”這3條數(shù)據(jù)流。

加工4的結構非常清晰，所以只需把這3條數(shù)據(jù)流對號入座即可：“電話撥號”應是

“4.5撥號”的輸出數(shù)據(jù)流：“傳感器狀態(tài)”應是作為“4.4讀傳感器”處理的輸入數(shù)

據(jù)流：“傳感器數(shù)據(jù)”應該是經“4.1顯示格式”處理過的數(shù)據(jù)流，所以作為“4.1顯

示格式''的輸出數(shù)據(jù)流。

閱讀下列說明和圖，回答問題1?問題4,將解答填入答題紙的對應欄內。【說

明】某學校開發(fā)圖書管理系統(tǒng)，以記錄圖書館藏圖書及其借出和歸還情況，提供

給借閱者借閱圖書功能，提供給圖書館管理員管理和定期更新圖書表功能。主要功

能的具體描述如下：（1）處理借閱。借閱者要借閱圖書時，系統(tǒng)必須對其身份（借閱

者ID）進行檢查。通過與教務處維護的學生數(shù)據(jù)庫、人事處維護的職工數(shù)據(jù)庫中的

數(shù)據(jù)進行比對，以驗證借閱者ID是否合法，若合法，則檢查借閱者在逾期未還圖

書表中是否有逾期未還圖書，以及罰金表中的罰金是否超過限額。如果沒有逾期未

還圖書并且罰金未超過限額，則允許借閱圖書，更新圖書表，并將借閱的圖書存入

借出圖書表，借閱者歸還所借圖書時，先由圖書館管理員檢查圖書是否缺失或損

壞，若是，則對借閱者處以相應罰金并存入罰金表；然后，檢查所還圖書是否逾

期，若是，執(zhí)行“處理逾期”操作；最后，更新圖書表，刪除借出圖書表中的相應記

錄。（2）維護圖書。圖書館管理員查詢圖書信息；在新進圖書時錄入圖書信息，存

入圖書表；在圖書丟失或損壞嚴重時，從圖書表中刪除該圖書記錄。（3）處理逾

期。系統(tǒng)在每周一統(tǒng)計逾期未還圖書，逾期未還的圖書按規(guī)則計算罰金，并記入罰

金表，并給有逾期未還圖書的借閱者發(fā)送提醒消息。借閱者在借閱和歸還圖書時，

若罰金超過限額，管理員收取罰金，并更新罰金表中的罰金額度?，F(xiàn)采用結構化

方法對該圖書管理系統(tǒng)進行分析與設計，獲得如圖12-8所示的項層數(shù)據(jù)流圖和圖

12-9所示的0層數(shù)據(jù)流圖。

n12-9。層數(shù)據(jù)流圖

5、使用說明中的詞語，給出圖12-8中的實體E1-E4的名稱。

標準答案：E1：借閱者。E2：圖書管理員。E3/E4：學生數(shù)據(jù)庫/職工數(shù)據(jù)庫。

知識點解析：本問題要求給出圖12-8中的實體E1?E4的名稱。這個需要從題目中

的描述和該圖來獲得。題目中有信息描述：“借閱者要借閱圖書時，系統(tǒng)必須對其

身份（借閱者ID）進行檢查”，結合頂層數(shù)據(jù)流圖可知，E1為借閱者；另外，根據(jù)題

目描述“圖書館管理員查詢圖書信息、；在新進圖書時錄入圖書信息、，存入圖書表；

在圖書丟失或損壞嚴重時，從圖書表中刪除該圖書記錄“，結合圖，可以知道E2

是圖書館管理員，再結合描述“借閱者要借閱圖書時，系統(tǒng)必須對其身份（借閱者

ID）進行檢查。通過與教務處維護的學生數(shù)據(jù)庫、人事處維護的職工數(shù)據(jù)庫中的數(shù)

據(jù)進行比對，以驗證借閱者ID是否合法”和頂層數(shù)據(jù)流圖可知，E3和E4應該是學

生數(shù)據(jù)庫和職工數(shù)據(jù)庫，這兩者的位置可以互換。

6、使用說明中的詞語，給出圖12-9中的數(shù)據(jù)存儲D1?D4的名稱。

標準答案：D1：圖書表。D2：借出圖書表。D3：逾期未還圖書表。D4：罰金

表。

知識點解析：本問題考查數(shù)據(jù)存儲的確定。根據(jù)題目的描述“圖書館管理員查詢圖

書信息；在新進圖書時錄入圖書信息，存入圖書表；在圖書丟失或損壞嚴重時，從

圖書表中刪除該圖書記錄“，結合。層數(shù)據(jù)流圖可知D1為圖書表；根據(jù)題目描述

“如果沒有逾期未還圖書并且罰金未超過限額，則允許借閱圖書，更新圖書表，并

將借閱的圖書存入借出圖書表，“，再結合0層數(shù)據(jù)流圖可知D2為借出圖書表，

并旦確實生成病歷至病歷文件的數(shù)據(jù)流和日志文件至生成病歷的數(shù)據(jù)流；根據(jù)題目

描述“系統(tǒng)在每周一統(tǒng)計逾期未還圖書，逾期未還的圖書按規(guī)則計算罰金，并記入

罰金表”，再結合0層數(shù)據(jù)流圖我們可知D4為罰金表。在確定了上面三個存儲

后，題目中還剩下逾期未還圖書表，很顯然，D3就是逾期未還圖書表。

7、在DFD建模時，需要對有些復雜加工（處理）進行進一步精化，繪制下層數(shù)據(jù)流

圖。針對圖12-9中的加工“處理借閱”，在1層數(shù)據(jù)流圖中應分解為哪些加工?（使用

說明中的術語）

標準答案：檢查借閱者身份或檢查借閱者ID；檢查逾期未還圖書；檢查罰金是否

超過限額；借閱圖書；歸還圖書。

知識點解析：本題主要考查加工的分解。對于求解這類問題，主要根據(jù)題目的描述

來進行，0層圖中加工“處理借閱''在題目的描述中，其處理過程為：先檢查借閱者

的身份，如果身份合法，則檢查借閱者是否有逾期未還圖書及罰金表中的罰金是否

超過限額，如果沒有，則允許借閱讀書，然后是歸還圖書。因此0層圖中的加工

“處理借閱”可以細分為1層圖中的若干個加工，其分別是：檢查借閱者的身份，檢

查逾期未還圖書，檢查罰金是否超過限額，借閱讀書及歸還圖書等加工。

8、說明（在DFD建模時，需要對有些復雜加工（處理）進行進一步精化）中繪制1

層數(shù)據(jù)流圖時要注意的問題。

標準答案：保持父圖與子圖平衡.父圖中某加T的輸入輸出數(shù)據(jù)流必須與它的子圖

的輸入輸出數(shù)據(jù)流在數(shù)量和名字上相同。如果父圖的一個輸入（或輸出）數(shù)據(jù)流對應

于子圖中幾個輸入（或輸出）數(shù)據(jù)流，而子圖中組成這些數(shù)據(jù)流的數(shù)據(jù)項全體正好是

父圖中的這一個數(shù)據(jù)流，那么它們仍然算是平衡的。

知識點解析：本題考查數(shù)據(jù)流圖（DFD）的應用，是一種比較傳統(tǒng)的題目。本題主要

考查根據(jù)上層數(shù)據(jù)流圖繪制下層數(shù)據(jù)流圖時的注意事項。其主要就是要保持父圖與

子圖間的平衡，具體有：父圖中某加工的輸入輸出數(shù)據(jù)流必須與它的子圖的輸入輸

出數(shù)據(jù)流在數(shù)量和名字上相同；如果父圖的一個輸入（或輸出）數(shù)據(jù)流對應于子圖中

幾個輸入（或輸出）數(shù)據(jù)流，而子圖中組成這些數(shù)據(jù)流的數(shù)據(jù)項全體正好是父圖中的

這一個數(shù)據(jù)流，那么它們仍然算是平衡的。

閱讀下列說明和圖，回答問題1至問題3。【說明】某會議策劃公司為了方便客

戶，便于開展和管理各項業(yè)務活動，需要構建一個基于網絡的會議預定系統(tǒng)。

【需求分析】（1）會議策劃公司設有受理部、策劃剖和其他部門。部門信息包括部

門號、部門名稱、部門主管、電話和郵箱號。每個部門有多名員工處理部門的日常

事務，每名員工只能在一個部門工作。每個部門有一名主管負責管理本部門的事務

和人員。（2）員工信息包括員工號、姓名、部門號、職位、聯(lián)系方式和工資。其

中，職位包括主管、業(yè)務員、策劃員等。業(yè)務員負責受理會議申請。若申請符合公

司規(guī)定，則置受理標志并填寫業(yè)務員的員工號。策劃部主管為已受理的會議申請制

定策劃任務，包括策劃內容、參與人數(shù)、要求完成時間等。一個己受理的會議申請

對應一個策劃任務，一個策劃任務只對應一個已受理的會議申請，但一個策劃任務

可由多名策劃員參與執(zhí)行，且一名策劃員可以參與多項策劃任務。（3）客戶信息包

括客戶號、單位名稱、通信地址、所屬省份、聯(lián)系人、聯(lián)系電話、銀行賬號。其

中，一個客戶號唯一標設一個客戶。一個客戶可以提交多個會議申請，但一個會議

申請對應唯一的一個客戶號。（4）會議申請信息包括申請?zhí)?、開會日期、會議地

點、持續(xù)天數(shù)、會議人數(shù)、預算費用、會議類型、酒店要求、會議室要求、客房類

型、客房數(shù)、聯(lián)系人、聯(lián)系方式、受理標志和業(yè)務員的員工號等?？头款愋陀泻廊A

套房、普通套房、標準間、三人間等，且申請?zhí)柡涂头款愋蜎Q定客房數(shù)。【概念

模型設計】根據(jù)需求階段收集的信息，設計的實體聯(lián)系圖和關系模式（不完整）如圖

13-1所示。圖”.I不完整的實體聯(lián)系圖和關系模式【關系模式設計】

部門（部門號，部門名稱，主管，電話，郵箱號）員工（員工號，姓名，（a）,聯(lián)系方

式，工資）客戶（客戶號，單位名稱，通信地址，所屬省份，聯(lián)系人，聯(lián)系電話，銀

行賬號）會議申請（（b）,開會日期，會議地點，持續(xù)天數(shù)，會議人數(shù)，預算費用，

會議類型，酒店要求，會議室要求，客房數(shù)，聯(lián)系人，聯(lián)系方式，受理標志，員工

號）策劃仟務（（c）,策劃內容，參與人數(shù)，要求完成時間）執(zhí)行策劃（d）,實際完成時

問）

9、根據(jù)問題描述，補充5個聯(lián)系、聯(lián)系的類型，完善圖13?1的實體聯(lián)系圖。

標準答案：本題的完整的實體聯(lián)系圖和關系模式如圖13-6所示。

圖1軍6試題I的參考答案圖

知識點解析：問題1考查考生對ER模型的理解。本題主要考查根據(jù)題目描述補充

完整ER圖。在解答本問題時，需要注意將題目描述與已給出的圖進行對照分析。

在題目中有“業(yè)務員負責受理會議申請”，這說明業(yè)務員與會議申請之間有聯(lián)系，聯(lián)

系的名稱可直接取題目中的“受理”一詞。同時，由于題目中有“若申請符合公司規(guī)

定，則置受理標志并填寫業(yè)務員的員工號“，這說明一個申請只由一個員工受理，

但一個員工卻可以受理多項業(yè)務，也就是說業(yè)務員與會議申請之間是1：n的關

系。與此同時，通過常設加題目描述，可以意識到一個問題：對于會議申請只表明

了受理人員，而誰來提出申請，并未直接說明。縱觀系統(tǒng)全局，可以看出會議是由

客戶申請的。所以客戶也與會議申請有聯(lián)系，這種聯(lián)系類型也是I：n。從“一個已

受理的會議申請對應一個策劃任務，一個策劃任務只對應一個己受理的會議申請，

但一個策劃任務可由多名策劃員參與執(zhí)行，且一名策劃員可以參與多項策劃任

務。''可以得知，策劃任務與策劃員之間存在“執(zhí)行”的聯(lián)系，而且這種聯(lián)系是n：m

的。從“每個部門有多名員工處理部門的口常事務，每名員工只能在一個部門工

作?！笨梢钥闯?，部門與員工之間存在聯(lián)系，聯(lián)系類型是1：n。從“每個部門有一

名主管負責管理本部門的事務和人員。''可以看出，主管這個角色與部門之間存在

聯(lián)系，由于每個部門只有1名主管，而1名主管也只能負責1個部門的工作，所以

他們之間的聯(lián)系是1：1的。

10、根據(jù)實體聯(lián)系圖，將關系模式中的空（a）?（d）補充完整（1個空缺處可能有多個

數(shù)據(jù)項）。對會議申請、策劃任務和執(zhí)行策劃關系模式，用下劃線和樣分別指出各

關系模式的主鍵和外鍵。

標準答案：（a）部門號，職位（b）申請?zhí)?，客房類型，客戶號⑹申請?zhí)?，員工號（d）

申請?zhí)枺瑔T工號關系模式為：會議申請（申請?zhí)?，客房?客戶號#,開會口期，

會議地點，持續(xù)天數(shù)，會議人數(shù)，預算費用，會議類型，酒店要求，會議室要求，

客房數(shù)，聯(lián)系人，聯(lián)系方式，受理標志，員工號#）策劃任務（申請?zhí)枴?員工號

#,策劃內容，參與人數(shù)，要求完成時間）執(zhí)行策劃（申請?zhí)?,員工號#,實際完

成時間）

知識點解析：當完成問題1的分析之后，問題2就很好解決了。其解題步驟的第一

個環(huán)節(jié)，應是看題目已經給出的信息。例如，第⑶空要求補充員工關系，而題目

中已經說明“員工信息包括員工號、姓名、部門號、職位、聯(lián)系方式和工資”，此

時，只要把缺失的“部門號，職位”填入即可。但有時，這一招并不能完全解決問

題，如第（b）空，從題目的描述”會議申請信息包括申請?zhí)?、開會日期、會議地點、

持續(xù)天數(shù)、會議人數(shù)、預算費用、會議類型、酒店要求、會議室要求、客房類型、

客房數(shù)、聯(lián)系人、聯(lián)系方式、受理標志和業(yè)務員的員工號等?！笨梢缘弥?，關系模

式缺了申請?zhí)柵c客房類型，但補充這些是否足矣?不行，還缺了屬性，即客戶號，

因為問題1中，已經分析了系統(tǒng)業(yè)務邏輯，應是由客戶提出申請，所以需要記錄客

戶號。接下來分析會議申請的主鍵與外鍵。在會議申請這個關系模式中，由于存

在“客房類型有豪華套層、普通套房、標準間、三人間等，且申請?zhí)柡涂头款愋蜎Q

定客房數(shù).”的情況，所以有函數(shù)依賴：（申請?zhí)枺蛻纛愋停┮唬究蛻魯?shù)。同時其他

所有屬性都依賴于（申請?zhí)?，客戶類型）。所以（申請?zhí)?，客戶類型）是本關系模式的

主鍵。而會議申請中的客戶號是相對于客戶關系的外鍵，員工號是相對于員工關系

的外鍵。（c）與（d）的內容補充，也需要進行分析才能得出結論，正是由于從題目中

有“個己受理的會議申請對應一個策劃任務，一個策劃任務只對應一個己受理的會

議申請，但一個策劃任務可由多名策劃員參與執(zhí)行，且一名策劃員可以參與多項策

劃任務”，這說明“策劃任務”與“執(zhí)行策劃”都與會議申請有關，所以這兩個關系

中，也需要有申請?zhí)?。在策劃任務關系模式中申請?zhí)柲艽_定員工號（因為策劃部主

管為已受理的會議申請制定策劃任務，所以有確定的關系），也能確定策劃內容，

參與人數(shù)，要求完成時間。所以申請?zhí)柺侵麈I。同時，由于申請?zhí)柵c員工號在其他

關系中充當主鍵，所以它們也是外鍵。在執(zhí)行策劃關系中，由于“一個策劃任務可

由多名策劃員參與執(zhí)行，且一名策劃員可以參與多項策劃任務”，所以必須要（申請

號，員工號）這個組合屬性才能充當主鍵。同時這兩個屬性也是外鍵。

11、請說明關系模式,、會議申請”存在的問題及解決方案。

標準答案：會議申請存左數(shù)據(jù)冗余及數(shù)據(jù)修改的不一致性問題，應該將關系模式分

解為如下兩個模式：會議申請1（申請?zhí)枺蛻籼?，開會口期，會議地點，持續(xù)天

數(shù)，會議人數(shù)，預算費用，會議類型，酒店要求，會議室要求，聯(lián)系人，聯(lián)系方

式，受理標志，員工號）。會議申請2（申請?zhí)?，客房類型，客房?shù)）。

知識點解析?：本題考查數(shù)據(jù)庫相關知識，涉及的知識點包括：ER模型、關系模

式、主鍵、范式。問題3要求分析關系模式“會議申請”存在的問題及解決方案。

分析關系模式的問題，往往需要從關系模式的規(guī)范程度入手，規(guī)范程度不高的模

式，可能出現(xiàn)：插入異常、修改異常、刪除異常、數(shù)據(jù)冗余等問題。在問題2的

分析中，已經提到了會設申請關系的主鍵是：（申請?zhí)枺蛻纛愋停?。但同時存在：

申請?zhí)?＞開會日期、申請?zhí)栆?會議地點依賴關系，這就導致了部分依賴的產生。

這使得數(shù)據(jù)冗余、修改異常等問題產生。解決的辦法就是拆分。把（申請?zhí)枺蛻?/p>

類型，客戶數(shù)）拆分為一個新表，而另一個表中去除客戶類型與客戶數(shù)，將申請?zhí)?/p>

定義為主鍵。

某賓館擬開發(fā)一個賓館客房預訂子系統(tǒng)，主要是針對客房的預訂和入住等情況進行

管理?！拘枨蠓治鼋Y果】（1）員工信息主要包括員工號、姓名、出生年月、性別、

部門、崗位、住址、聯(lián)系電話和密碼等信息。崗位有管理和服務兩種。崗位為“管

理”的員T可以更改（添加、刪除和修改員工表中的本部門員T的崗位和密碼,要求

將每一次更改前的信息保留；崗位為“服務”的員工只能修改員工表中本人的密碼，

且負責多個客房的清理等工作。（2）部門信息主要包括部門號、部門名稱、部門負

責人、電話等信息；一個員工只能屬于一個部門，一個部門只有一位負責人。（3）

客房信息包括客房號、類型、價格、狀態(tài)等信息。其中類型是指單人間、三人間、

普通標準間、豪華標準間等；狀態(tài)是指空閑、入住和維修。（4）客戶信息包括身份

證號、姓名、性別、單位和聯(lián)系電話。（5）客房預訂情況包括客房號、預訂日期、

預訂入住日期、預訂入住天數(shù)、身份證號等信息。一條預訂信息必須且僅對應一位

客戶，但一位客戶可以有多條預訂信息。【概念模型設計】根據(jù)需求階段收集的

信息，設計的實體聯(lián)系圖（不完整）如圖13-3所示。

圖13?3試題3實體聯(lián)系圖【邏輯結構設計】

邏輯結構設計階段設計的部分關系模式（不完整）如下。員工（（4）,姓名，出生年

月，性別，崗位，住址，聯(lián)系電話，密碼）權限（崗位，操作權限）部門（部門號，部

門名稱，部門負責人，電話）客房（（5）,類型，價格，狀態(tài)，入住日期，入住時

間，員工號）客戶（（6）,姓名，性別，單位，聯(lián)系電話）更改權限（員工號，（7）,密

碼，更改日期，更改時間，管理員號）預訂情況（（8）,預訂日期，預訂入往日期，

預訂入住天數(shù)）

12、根據(jù)問題描述，填寫圖13-3中的（1）?（3）處聯(lián)系的類型。聯(lián)系類型分為一對

、?對多、多對多。

標準答案：（l）n或m或（2）n或m或*。（3）n或m或*。

知識點解析：（1）按常規(guī)來說，一個員工只能屬于一個部門，一個部門只有一個負

責人，所以部門與員工之間的關系是一對多的關系，所以（1）應該填寫n。（2）由于

一條預訂信息必須僅對應一個客戶，但一個客戶可以有多條預訂信息，所以客戶與

預訂信息之間是一對多的關系。需要注意：題目要求的是客戶與客房之間的預訂信

息，一位客戶可以預訂多個客房，而一個客房在不同的時間也可以被多個客戶預

訂，所以客戶與客房的預訂關系是多對多的。故（2）和（3）都應填寫n。

13、補充圖13-3中的聯(lián)系并指明其聯(lián)系類型。

標準答案：員工到權限的聯(lián)系，聯(lián)系類型m：1。

知識點解析：由圖可知需要增加的是員工與權限的關系，因為“管理員''和“服務員”

都屬于“員工”。一類員工（如服務員A,服務員B,…，服務員N）使用同一權限，

所以員工與權限之間是多對一的關系。

14、根據(jù)需求分析結果和圖13-3所示，將邏輯結構設計階段生成的關系模式中的

空（4）?（8）補充完整（注：一個空可能需要填多個屬性）。

標準答案：（4）員工號，部門號。（5）客房號。（6）身份證號。（7）崗位。（8）客房號，

身份證號。

知識點解析：（1）由需求分析結果第⑴條可知，員工信息主要包括員工號、姓名、

出生年月、性別、部門、崗位、住址、聯(lián)系電話和密碼等信息。即員工信息包括員

工本身的信息和他所在的部門信息，員工本身最具代表性的信息就是員工號，而部

門在該系統(tǒng)中是一個關系，所以在此處要記錄部門的相關信息，只需記錄部門號即

可，其余的相關信息可以通過部門號查詢來獲得。（2）由需求分析結果第⑶條可

知，客房信息包括客房號、類型、價格、狀態(tài)等信息。顯然（5）空應填寫“客房

號（3）由需求分析結果第（4）條可知，客戶信息包括身份證號、姓名、性別、單

位和聯(lián)系電話。顯然（6）空應填寫“身份證號”。（4）崗位有管理和服務兩種，崗位為

“管理”的員工可以更改（添加、刪除和修改）員工表中的本部門員工的崗位和密瑪，

要求將每一次更改前的信息保留。所以“更改權限”這個關系模式是指崗位為“管理”

的員工可以更改員工表中本部門員工的崗位和密碼?！案那暗男畔ⅰ卑ㄔ搯T工所

涉及的全部信息。該關系中已經記錄了“員工號”，從員工號可查詢獲得該員工的所

有個人信息和部門信息，同時記錄了員工的密碼及本次修改的時間、操作和管理

員。仔細觀察不難發(fā)現(xiàn)，該關系中唯一缺少的是崗位的信息，向本系統(tǒng)的設計是由

崗位確定該員工的權限的，因此第⑺空應填寫：崗位。（5）由需求分析結果第（5）條

可知，客房預訂情況包話客房號、預訂□期、預訂入住口期、預訂入住天數(shù)、身份

證號等信息。顯然第（8）空應填寫“客房號、身份證號”。

15、若去掉權限表，并將權限表中的操作權限屬性放在員工表中（仍保持管理和服

務崗位的操作權限規(guī)定），則與原有設計相比有什么優(yōu)缺點（請從數(shù)據(jù)庫設計的角度

進行說明）？

標準答案：優(yōu)點：如果合為一個表，可以只查一次表就能得出鹵位和操作權限信

息，加快了查找速度。缺點：如果合為一個表，則崗位、操作權限將多次重復出

現(xiàn)，會產生冗余數(shù)據(jù)和增加數(shù)據(jù)庫存儲顯。

知識點解析：本題考查數(shù)據(jù)庫設計。涉及的考點有概念模型設計（E-R圖的補充）和

邏輯模型設計。下面具體分析試題。本題考查考生對數(shù)據(jù)庫規(guī)范化的理解。去掉

權限表后的缺點：去掉雙限表后，權限字段就得添加到員工表中，員工表中有很多

員工記錄，而同一類員工的權限都相同，權限數(shù)據(jù)卻要多次重復存儲，顯然有大量

的數(shù)據(jù)冗余。同時，此時若要對權限字段進行更新，很有可能產生更新異常，若某

一崗位的員工全部離職，將導致權限數(shù)據(jù)的丟失（刪除異常）。去掉權限表的優(yōu)點：

獲取某一員工權限數(shù)據(jù)時，不必再將員工表與權限表進行連接查詢，可以提高存儲

速度。

閱讀下列說明，回答問題1至問題3,將解答填入答題紙的對應欄內?！菊f明】

某物流公司為了整合上游供應商與下游客戶，縮短物流過程，降低產品庫存，需要

構建一個信息系統(tǒng)以方便管理其業(yè)務運作活動。【需求分析結果】（1）物流公司包

含若干部門，部門信息包括部門號、部門名稱、經理、電話和郵箱。一個部門可以

有多名員工處理部門的三常事務，每名員工只能在一個部門工作。每個部門有一名

經理，只需負責管理本部門的事務和人員。（2）員工信息包括員工號、姓名、職

位、電話號碼和工資；其中，職位包括：經理、業(yè)務員等。業(yè)務員根據(jù)托運申請負

責安排承運貨物事宜，例如：裝貨時間、到達時間等。一個業(yè)務員可以安排多個托

運申請，但一個托運申請只由一個業(yè)務員處理。（3）客戶信息包括客戶號、單位名

稱、通信地址、所屬省份、聯(lián)系人、聯(lián)系電話、銀行賬號，其中，客戶號唯一標識

客戶信息的每一個元組。每當客戶要進行貨物托運時，先要提出貨物托運申請。托

運申請信息包括申請?zhí)枴⒖蛻籼?、貨物名稱、數(shù)量、運費、出發(fā)地、目的地。其

中，一個申請?zhí)枌ㄒ坏囊粋€托運申請；一個客戶可以有多個貨物托運申請，但

一個托運申請對應唯一的一個客戶號?！靖拍钅Ｐ驮O計】根據(jù)需求階段收集的信

息，設計的實體聯(lián)系圖和關系模式（不完整）如圖13-5所示。

代貶申回部C

［員工—I

I百一I業(yè)務員

圖35試題5用實體聯(lián)系圖【關系模式設計】部門（部門號，

部門名稱，經理，電話，郵箱）員工（員工號，姓名，職位，電話號碼，工資，（a））

客戶（（b）,單位名稱，通信地址，所屬省份，聯(lián)系人，聯(lián)系電話，銀行賬號）托運

申請（（c）,貨物名稱，數(shù)量，運費，出發(fā)地，目的地）安排承運，（（d）,裝貨時間，

到達時間，業(yè)務員）

16、根據(jù)問題描述，補充4個聯(lián)系、聯(lián)系的類型，以及實體與子實體的聯(lián)系，完善

圖13-5中的實體聯(lián)系圖。

標準答案：實體聯(lián)系圖如圖13-10所示。

圖1340試冊5問題1參考答案圖

知識點解析：本題主要考查根據(jù)題目描述補充完整E-R圖。在本題中，根據(jù)題目

描述“一個部門可以有多名員工處埋部門的日常事務，每名員JL只能在一個部門JL

作”，可以知道部門與員工間存在一對多的聯(lián)系“屬于”；根據(jù)題目描述“每個部門有

一名經理，只需負責管理本部門的事務和人員”可以知道，經理與部門之間存在一

對一的管理聯(lián)系；然后根據(jù)題目描述“業(yè)務員根據(jù)托運申請負責安排承運貨物事

宜，一個業(yè)務員可以安排多個托運申請，但一個托運申請只由一個業(yè)務員處理”可

知，在業(yè)務員和托管申請之間存在一個1對多的安排承運的聯(lián)系；而根據(jù)題目描述

“每當客戶要進行貨物托運時，先要提出貨物托運申請。其中，一個申請?zhí)枌?/p>

一一的一個托運申請；一個客戶可以有多個貨物托運申請，但一個托運申請對應唯

一的一個客戶號”可以，客戶和托運申請之間存在一個1對多的申請聯(lián)系。另外，

不管是業(yè)務員還是經理，他們都是員工，因此業(yè)務員和經理是員工實體的子實體。

17、根據(jù)實體聯(lián)系圖，將關系模式中的空（a）?（d）補充完整。分別指出部門、員工

和安排承運關系模式的主鍵和外鍵。

標準答案：問題2實體圖各項說明如表13-9所示。

>15-9成及S問超2套考答案用豪

(a)部門號

(b)客戶號

(c)申博號.客戶號

(d)申請?zhí)?/p>

篇門主鍵：部門號外鍵：般理

員工主鍵：員工號外鍵：部門號

安排承運主鍵：申請?zhí)柾饨。簶I(yè)務員

知識點解析?：該問題要補充完整各關系模式中缺失的屬性并給出各關系模式的主

鍵。要補充各關系模式缺失的屬性應該根據(jù)題目的描述和E-R圖轉換為關系模式

的轉換原則來完成。a空是要我們補充員工信息關系模式所缺失的屬性，根據(jù)題目

的描述，員工信息包括員工號、姓名、職位、電話號碼和工資，而這些已經存在于

員工關系模式中了，但是根據(jù)E-R轉換的原則，我們知道部門與員工之間存在一

對多的聯(lián)系，而這個聯(lián)系沒有轉換為獨立的關系模式，因此，需要將聯(lián)系的屬性和

1端關系模式的主鍵放到多端當中來作為外鍵，因此a空應填屬性“部門號”。其中

員工關系模式的主鍵為員工號，而外鍵為部門號。b空是要補充客戶關系模式所缺

失的屬性，根據(jù)題目的描述，客戶信息包括客戶號、單位名稱、通信地址、所屬省

份、聯(lián)系人、聯(lián)系電話、銀行賬號。因此b空應該填“客戶號”這個屬性。c空是要

補充托運申請關系模式所缺失的屬性。根據(jù)題目描述托運申請信息包括申請?zhí)?、?/p>

戶號、貨物名稱、數(shù)量、運費、出發(fā)地、目的地。再結合E-R圖分析可得出c空應

該填“申請?zhí)枺蛻籼枴?。d空是要補充安排承運關系模式所缺失的屬性。安排承運

是有聯(lián)系轉換而來的一個關系模式，其中包含的屬性應該包括其本身的屬性和聯(lián)系

兩端實體關系模式的主鍵，應該可知d空應該填“申請?zhí)枴保鴺I(yè)務員的主鍵就是屬

性“業(yè)務員”。這個關系模式的主鍵應該是申請?zhí)?，而外鍵是業(yè)務員，因為業(yè)務員是

業(yè)務員關系模式的主鍵，其實就是員工號。同樣的道理，對于部門關系模式，其

主鍵為部門號，而外鍵為“經理”。

18、若系統(tǒng)新增需求描述如下：為了數(shù)據(jù)庫信息的安全性，公司要求對數(shù)據(jù)庫操

作設徨權限管理功能，當員工登錄系統(tǒng)時，系統(tǒng)需要檢查員工的權限。權限的設在

人是部門經理。為滿足上述需要，應如何修改（或補充）圖13-5中的實體聯(lián)系圖，請

給出修改后的實體聯(lián)系圖和關系模式。

標準答案：實體聯(lián)系圖如圖13-11所示。

■"一I業(yè)務員依及丁：至$：,-r|\

圖mu試BH問題3令考答案圖關系模式：權限（員工號,權

限，設置人）或權限（員工號,權限，部門經理）

知識點解析：本題考查數(shù)據(jù)庫概念結構設計、概念至邏輯結構轉換等內容。此類

題目要求考生認真閱讀題目，根據(jù)題目的需求描述，給出實體間的聯(lián)系。根據(jù)本

題描述“為了數(shù)據(jù)庫信息的安全性，公司要求對數(shù)據(jù)庫操作設置權限管理功能，當

員工登錄系統(tǒng)時，系統(tǒng)需要檢查員工的權限。權限的設置人是部門經理?！本涂梢?/p>

知道，應該有一個實體“權限”，而這個實體與部門經理之間存在一種一對多的聯(lián)

系，其中部門經理端為一端。

軟件水平考試（中級）軟件設計師下午

（應用技術）試題模擬試卷第2套

一、必答題（本題共13題，每題1.0分，共13分。）

閱讀下列說明和圖，回答問題1至問題3,將解答填入答題紙的對應欄內?！菊f

明】某房屋租賃公司欲建立一個房屋租賃服務系統(tǒng)，統(tǒng)一管理房主和租賃者的信

息，從而快速地提供租賃服務。該系統(tǒng)具有以下功能.（1）登記房主信息…對于每

名房主，系統(tǒng)需登記其姓名、住址和聯(lián)系電話，并將這些信息寫入房主信息文件。

（2）登記房屋信息。所有在系統(tǒng)中登記的房屋都有一個唯一的識別號（對于新增加的

房屋，系統(tǒng)會自動為其分配一個識別號）。除此之外，還需登記該房屋的地址、房

型（如平房、帶陽臺的樓房、獨立式住宅等）、最多能夠容納的房客數(shù)、租金及房屋

狀況（待租賃、已出租）。這些信息都保存在房屋信息文件中。一名房主可以在系統(tǒng)

中登記多個待租賃的房屋。（3）登記租賃者信息。所有想通過該系統(tǒng)租賃房屋的租

賃者，必須首先在系統(tǒng)中登記個人信息，包括：姓名、住址、電話號碼、出生年月

和性別。這些信息都保存在租賃者信息文件中。（4）租賃房屋。已經登記在系統(tǒng)中

的租賃者.可以得到一份系統(tǒng)提供的待租賃房屋列表.一口和賃者從中找到合適的

房屋，就可以提出看房請求。系統(tǒng)會安排租賃者與房主見面。對于每次看房，系統(tǒng)

會生成一條看房記錄并將其寫入看房記錄文件中。（5）收取手續(xù)費。房主登記完房

屋后，系統(tǒng)會生成一份費用單，房主根據(jù)費用單繳納相應的費用。（6）變更房屋狀

態(tài)。當租賃者與房主達成租房或退房協(xié)議后，房主向系統(tǒng)提交變更房屋狀態(tài)的請

求。系統(tǒng)將根據(jù)房主的請求，修改房屋信息文件。數(shù)據(jù)流題圖1-1和題圖1-2分別

給出了該系統(tǒng)的頂層數(shù)據(jù)流圖和0層數(shù)據(jù)流圖。

題圖1?1頂層數(shù)據(jù)流圖

題圖1-20層數(shù)據(jù)流圖

1、使用說明中給出的詞匯，將數(shù)據(jù)流題圖1-1中⑴?(4)處的數(shù)據(jù)流補充完整。

標準答案：(I)費用單⑵待租賃房屋列表(3)看房請求(4)變更房屋狀態(tài)請求

知識點解析：本題考查的是分層數(shù)據(jù)流圖，該題型每年必考，是需要重點掌握的內

容。解題的兩大原則是：數(shù)據(jù)平衡原則，系統(tǒng)功能描述與數(shù)據(jù)流圖的一致性原

則。首先根據(jù)數(shù)據(jù)平衡原則分析如下。在。層圖中，與“房主”相關的數(shù)據(jù)流有5

條。根據(jù)數(shù)據(jù)平衡原則，頂層圖應有與之對應的數(shù)據(jù)流，但“費用單”數(shù)據(jù)流在頂層

圖中找不到，所以空⑴處應是“費用單”數(shù)據(jù)流。通過比較頂層圖和。層圖中與外

部實體“租賃者”相關的數(shù)據(jù)流可以發(fā)現(xiàn)，山現(xiàn)在。層圖中的數(shù)據(jù)流“待租賃房屋列

表''是頂層圖中沒有的，且與空(2)處的數(shù)據(jù)流方向一致。由此可以判定，空(2)處的

數(shù)據(jù)流就是“待租賃房屋列表”。而頂層圖中的數(shù)據(jù)流“租賃者信息”卻是0層圖中沒

有的。這樣就找到了0層圖中缺失的一條數(shù)據(jù)流：租賃者信息，它的起點是“租賃

者”，終點是加工“登記租賃者信息其次根據(jù)系統(tǒng)功能描述與數(shù)據(jù)流圖的一致性

原則分析如下。由于空（4）處缺失的數(shù)據(jù)流是一條輸入數(shù)據(jù)流，從說明中可以看

出，只有功能（6）“當租賃者與房主達成租房或退房協(xié)議后，房主向系統(tǒng)提交變更房

屋狀態(tài)的請求”所描述的數(shù)據(jù)流沒有在“房主”與系統(tǒng)之間體現(xiàn)出來。因此可以確

定，空（4）處缺失的數(shù)據(jù)流就是“變更房屋狀態(tài)請求:相應地，可以確定，在0層

圖中缺失的其中一條數(shù)據(jù)流也是它，其起點是“房主”，終點是“變更房屋狀態(tài)''這個

加工。由于說明中與“租賃者”相關的功能“一旦租賃者從中找到合適的房屋，就可

以提出看房請求“未在圖中體現(xiàn)出來，這樣就能確定空（3）處的數(shù)據(jù)流應該是“看房

請求”。而0層圖中也沒有出現(xiàn)這條數(shù)據(jù)流。所以，0層圖中缺失的第3條數(shù)據(jù)流

就是“看房請求”，它的起點是“租賃者”，終點是加工“安排租賃者看房由說明的

描述可以得知，本系統(tǒng)中的數(shù)據(jù)存儲有：房主信息文件、房屋信息文件、租賃者信

息文件、看房記錄文件。下面就可以根據(jù)相應的加工對號入座了。顯然，空（5）處

為房主信息文件；空（6）處為租賃者信息文件；空⑺處為房屋信息文件；空（8）處為

看房記錄文件。

2、使用說明中給出的詞匯，將數(shù)據(jù)流圖題圖1-2中的（5）?⑻補充完整。

標準答案：（5）房主信息文件（6）租賃者信息文件（7）房屋信息文件（8）看房記錄又件

知識點解析：暫無解析

3、數(shù)據(jù)流程圖題圖1-2中缺失了三條數(shù)據(jù)流，請指出這三條數(shù)據(jù)流的起點、終點

和數(shù)據(jù)流名稱。

標準答案：（1）起點：房主終點：變更房屋狀態(tài)數(shù)據(jù)流名稱：變更房屋狀態(tài)請求

⑵起點：租賃者終點：登記租賃者信息數(shù)據(jù)流名稱：租賃者信息（3）起點：租賃者

終點：安排租賃者看房數(shù)據(jù)流名稱：看房請求

知識點解析：暫無解析

閱讀下列說明，回答問題1至問題4,將解答填入答題紙的對應欄內?！菊f明】某

汽車維修站擬開發(fā)一套小型汽車維修管理系統(tǒng)，對車輛的維修情況進行管理。（1）

對于新客戶及車輛，汽車維修管理系統(tǒng)首先登記客戶信息，包括：客戶編號、客戶

名稱、客戶性質（個人、單位）、折扣率、聯(lián)系人、聯(lián)系電話等信息；還要記錄客戶

的車輛信息，包括：車牌號、車型、顏色、車輛類別等信息。一個客戶至少有一臺

車?？蛻艏败囕v信息如題表2-1所示。

題表2?1客戶及車輛信息

客戶編號GS0051客戶名稱X*公司客戶性質單位

折扣率95%聯(lián)系人楊浩東聯(lián)系電話82638779

車牌號?色車型車■類別

*?0765白色帕薩特微型車

（2）記錄維修車輛的故障信息。包括：維修類型（普通、加急）、作業(yè)分類（大、中、

小修）、結算方式（自付、三包、索賠）等信息。維修廠的員工分為：維修員和業(yè)務

員。車輛維修首先委托給業(yè)務員。業(yè)務員對車輛進行檢查和故障分析后，與客戶磋

商，確定故障現(xiàn)象，生成維修委托書，如題表2-2所示。區(qū)（3）維修車間根據(jù)維

修委托書和車輛的故障現(xiàn)象，在已有的維修項目中選擇并確定一個或多個具體維修

項目，安排相關的維修工及工時，生成維修派工單。維修派工單如題表2-3所示。

(4)客戶車輛在車間修理完畢后，根據(jù)維修項目單價和維修派工單中的工時計算車

輛此次維修的總費用，-記錄在委托書中。根據(jù)需求階段收集的信息，設計的實體

聯(lián)系圖(見題圖2-1)和關系模式(不完整)如下所示。題圖2-1中業(yè)務員和維修工是員

工的子實體?！靖拍罱Y構設計】【邏輯結構設計】客戶((5),折扣率，聯(lián)系

人，聯(lián)系電話)車輛(車牌號，客戶編號，車型，顏色，車輛類別)委托書

((6),維修類型，作業(yè)分類，結算方式，進廠時間，預計完工時間，登記日

期，故障描述，總費用)維修項目(維修項目編號，維修項目，單價)派工單

((7),工時)員工((8),工種，員工類型，級別)

4、根據(jù)問題描述，填寫題圖2-1中(1)?(4)處聯(lián)系的類型。聯(lián)系類型分為一對一、

一對多和多對多三種，分別使用1：1、1：n或1：*、m：n或*:*表示。

標準答案：(l)n或m或*(2)1(3)n或m或*(4)n或m或*

知識點解析：由維修委吒書的故障描述、維修類型、作業(yè)分類可知，一臺車可能有

多個故障，對應多個維修委托書，所以空(1)處為*；由題目中“維修車間根據(jù)維修

委托書和車輛的故障現(xiàn)象，在已有的維修項目中選擇并確定一個或多個具體維修項

目，安排相關的維修工及工時，生成維修派工單”，很明顯，一份委托書包含了一

個或多個維修項目，而每個維修項目可以由多個維修工來完成，每一個維修工又可

以完成多個維修項目，所以空(2)處為1,空(3)處和空(4)均為*。

5、補充題圖2.1中的聯(lián)系并指明其聯(lián)系類型。聯(lián)系名可為：聯(lián)系1,聯(lián)系

2,.......o

標準答案：完整的實體聯(lián)系圖如下圖所示。

客戶業(yè)務員-e-員「維修「

知識點解析：需要補充車輛和客戶之間以及委托書和業(yè)務員之間的聯(lián)系。由“一個

客戶至少有一臺車”可知，客戶和車輛之間是“擁有”聯(lián)系，且是一對多的聯(lián)系：由

“業(yè)務員對車輛進行檢查和故障分析后，與客戶磋商，確定故障現(xiàn)象，生成維修委

托書”可知，業(yè)務員與委托書之間是“委托聯(lián)系，且一名業(yè)務員可以受理多份委托

書，而一份委托書由一名業(yè)務員來生成。

6、根據(jù)題圖2-1和說明，將邏輯結構設計階段生成的關系模式中的空(5)?⑻補充

完整。

標準答案：(5)客戶編號，客戶名稱，客戶性質(6)委托書編號，客戶編號，車牌

號，業(yè)務員編號或委托書編號，車牌號，業(yè)務員編號(7)委托書編號，維修工編

號，維修項目編號(8)員工編號，員工姓名

知識點解析：本問題又是補充邏輯結構設計題，幾乎每年都考，這類題目只要仔細

看需求分析結果或者仔細觀察題目中已知的表，很容易就能做出，關鍵是需要細

心，不要漏掉什么屬性。根據(jù)客戶及車輛信息表可知，客戶關系應包括客戶編號、

客戶名稱、客戶性質、折扣率、聯(lián)系人等屬性，主鍵顯然為客戶編號；而車輛關系

應包括車牌號、客戶編號、車型、顏色、車輛類別等屬性，主鍵為車牌號。根據(jù)維

修委托書表可知，委托書關系應包括委托書編號、車牌號、客戶編號、業(yè)務員編

號、維修類型等屬性，其主鍵為委托書編號。根據(jù)維修派工單可知，派工單關系應

包括委托書編號、維修項目編號、維修工編號、工時等屬性，主鍵是委托書編號、

維修項目編號和維修工編號。根據(jù)實體聯(lián)系圖可知，員工包括業(yè)務員和維修工，他

們共有的屬性是員工編號、員工姓名、工種、員工類型、級別等，主鍵為員工編

號。

7、根據(jù)問題描述，寫出客戶、委托書和派工單這三個關系的主鍵。

標準答案：客戶主鍵：客戶編號委托書主鍵：委托書編號派工單主鍵：委托書編

號，維修項目編號，維修工編號

知識點解析：暫無解析

閱讀下列說明和圖，回答問題1至問題3,將解答填入答題紙的對應欄內?！菊f

明】某圖書管理系統(tǒng)的主要功能如下0（1）圖書管理系統(tǒng)的資源目錄中記錄著所有

可供讀者借閱的資源，每項資源都有一個唯一的索引號。系統(tǒng)需登記每項資源的名

稱、出版時間和資源狀態(tài)（可借閱或已借出）。（2）資源可以分為兩類：圖書和唱

片。對于圖書，系統(tǒng)還需登記作者和頁數(shù)：對于唱片，還需登記演唱者和介質類型

（CD或者磁帶）。（3）讀者信息保存在圖書管理系統(tǒng)的讀者信息數(shù)據(jù)庫中，記錄的信

息包括：讀者的識別碼和讀者姓名。系統(tǒng)為每個讀者創(chuàng)建了一個借書記錄文件，用

來保存讀者所借資源的相關信息。現(xiàn)采用面向對象方法開發(fā)該圖書管理系統(tǒng)。識

別類是面向對象分析的第一步。比較常用的識別類的方法是尋找問題描述中的名

詞，再根據(jù)相關規(guī)則從這些名詞中刪除不可能成為類的名詞，最終得到構成該系統(tǒng)

的類.題表3-1給出了說明中出現(xiàn)的所有名詞C

題表軍1圖書管理系統(tǒng)中的名詞

圖書管理系統(tǒng)資源目錄讀者資源

索引號系統(tǒng)名稱出版時間

資源狀態(tài)圖書唱片作者

頁數(shù)演唱者介質類型CD

磁帶讀者信息讀者信息數(shù)據(jù)庫識別碼

姓名借書記錄文件信息

---------通

過對題表3-1中的名詞進行分析，最終得到了題圖3-1所示的UML類圖（類的說明

見題表3-2)。

颼表3?2類說明

類名說明

LibrarySystem圖書管理系統(tǒng)

BorrowerDB保存讀后信息的數(shù)據(jù)庫

Catalogitem資源口水中保存的每項登源

Borrower讀者

Borroweritems為每個讀M創(chuàng)建的借書記錄文件

8、題表3-2所給出的類并不完整，根據(jù)說明和題表3-1,將題圖3-1中的(a)~(c)處

補充完整。

標準答案：(a)資源目錄；(b)圖書；⑹唱片

知識點解析：本題主要考查UML中的類圖設計，3個問題都是對類圖的元素進行

補充。類圖的設計是根據(jù)系統(tǒng)的功能需求而來的，所以解題的關鍵在于對“系統(tǒng)功

能說明”的理解。下面將通過對“系統(tǒng)功能說明”的分析，來解答試題。由“圖書管

理系統(tǒng)的資源目錄中記錄著所有可供讀者借閱的資源”和“資源可以分為兩類：圖書

和唱片”可知，一個資源目錄中對應著多個可供讀者借閱的資源，這些資源分為圖

書類與唱片類，所以⑶為資源目錄，(b)和(c)分別為圖書和唱片，同時空(1)處為

1,空(2)處為0..*o(所有可供讀者借閱的資源數(shù)有可能為0,即還未錄入任何資

源的狀態(tài)。)由“每項資源都有一個唯一的索引號。系統(tǒng)需登記每項資源的名稱、

出版時間和資源狀態(tài)”可知，資源目錄中的每項資源，即類圖中的Calalogltem,有

索引號、名稱、出版時間和資源狀態(tài)這4個關鍵屬性。山”對于圖書，系統(tǒng)還需登

記作者和頁數(shù)；對于唱片，還需登記演唱者和介質類型(CD或者磁帶)”可知，圖書

有作者和頁數(shù)2個關鍵屬性，唱片有演唱者和介質類型2個關鍵屬性。Borrower

代表讀者，而Borrower3ms為借刊記錄文件，同時系統(tǒng)功能說明中有“系統(tǒng)為每個

讀者創(chuàng)建了一個借書記錄文件，用來保存讀者所借資源的相關信息-所以它們之

間的關系應為1對1：即空(5)處和空(6)處均為lo

9、根據(jù)說明中的描述，給出題圖3.1中的類Catalogltern以及(b)、(c)處所對應的

類的關鍵屬性(使用題表3?1中給出的詞匯)，其中，Calalogltem有4個關鍵屬性；

(b)、(c)處對應的類各有2個關鍵屬性。

標準答案:Catalogitem的屬性:索引號、名稱、出版時間、資源狀態(tài)圖書的屬

性：作者、頁數(shù)唱片的屬性：演唱者、介質類型

知識點解析：暫無解析

10、識別關聯(lián)的多重度是面向對象建模過程中的一個重要步驟。根據(jù)說明中給出的

題圖3<1UML類圖

標準答案：(1)1(2)0..*(3)1(4)0..*(5)1(6)1或者0..1

知識點解析：暫無解析

11、閱讀下列說明、圖和C代碼，將應填入(n)處的字句寫在答題紙的對應欄內。

【說明】一般的樹結構常采用孩子一兄弟表示法表示，即用二叉鏈表作樹的存儲

結構，鏈表中節(jié)點的兩個鏈域分別指向該節(jié)點的第一個孩子節(jié)點和下一個兄弟節(jié)

點。例如，題圖4-l(a)所示的樹的孩子一兄弟表示如題圖4-l(b)所示。

題圖4?1樹及其孩子-兄弟表示示意圖函數(shù)

LevelTraVerse。的功能是對給定樹進行層序遍歷。例如，對題圖4-1所示的樹進行

層序遍歷時，節(jié)點的訪問次序為：DBAEFPCo對樹進行層序遍歷時使用了隊

列結構，實現(xiàn)隊列基本操作的函數(shù)原型如下表所示。

函數(shù)原型說明

voidlnitQueue(Queue*Q)初始化隊列

BoollsEmpiy(QueueQ)判斷隊列是否為空，若是則返回TRUE,否則返回FALSE

voidEnQueue(Queue?Q,TreeNodep)元素入隊列

voidDeQueue(Queue*Q,TreeNode*p)元素出隊列

Bool>Stalus類型定義如下：lypedefenum{FALSE=O,TRUE=1}Bool；typedef

enum{OVERFLOWS,UNDERFLOW。1,ERROR=0,OK=1}Status;樹的二叉鏈

表節(jié)點定義如下：typcdcfstructNodc{chardata；StructNode樂firstchiid,

*nextbrother;}Node,*TreeNode；【函數(shù)】StatusLevelTraverse(TreeNoderoot)

{/*層序遍歷樹，樹采用孩子一兄弟表示法，root是樹根節(jié)點的指針*/Queue

tempQ；TreeNodeptr,brOthcrptr；if(!root)returnERROR；InitQucue(&tempQ)；

(1);brotherptr=root->nextbrother；while(bro(herptr){EnQueue(&tempQ,

brotherptr);(2)；)/*end-while*/while((3))((4)；printf(''%c\

t’‘，ptr->data)；if((5))continue；(6);brothcrptr=ptr->firstchiid->

nextbrolher；whi1e(brotherptr){EnQueue(&tempQ,brotherptr)；(7);)/*end-

while*/)/*end-while*/returnOK;)/*LeveITraverse*/