2011上半年數(shù)據(jù)庫系統(tǒng)工程師考試真題及答案

2011上半年數(shù)據(jù)庫系統(tǒng)工程師考試真題及答案-下午卷試題一某醫(yī)院欲開發(fā)病人監(jiān)控系統(tǒng)。該系統(tǒng)通過各種設(shè)備監(jiān)控病人的生命特征，并在生命特征異常時向醫(yī)生和護理人員報警。該系統(tǒng)的主要功能如下:本地監(jiān)控：定期獲取病人的生命特征，如體溫、血壓、心率等數(shù)據(jù)。格式化生命特征：對病人的各項重要生命特征數(shù)據(jù)進行格式化，然后存入日志文件并檢查生命特征。檢查生命特征：將格式化后的生命特征與生命特征范圍文件中預(yù)設(shè)的正常范圍進行比較。如果超出了預(yù)設(shè)范圍，系統(tǒng)就發(fā)送一條警告信息給醫(yī)生和護理人員。維護生命特征范圍：醫(yī)生在必要時(如，新的研究結(jié)果出現(xiàn)時)添加或更新生命特征值的正常范圍。提取報告：在醫(yī)生或護理人員請求病人生命特征報告時，從日志文件中獲取病人生命特征生成特征報告，并返回給請求者。生成病歷：根據(jù)日志文件中的生命特征，醫(yī)生對病人的病情進行描述，形成病歷存入病歷文件。查詢病歷：根據(jù)醫(yī)生的病歷查詢請求，查詢病歷文件，給醫(yī)生返回病歷報告。生成治療意見：根據(jù)日志文件中的生命特征和病歷，醫(yī)生給出治療意見，如處方等，并存入治療意見文件。查詢治療意見：醫(yī)生和護理人員查詢治療意見，據(jù)此對病人進行治療?，F(xiàn)采用結(jié)構(gòu)化方法對病人監(jiān)控系統(tǒng)進行分析與設(shè)計，獲得如圖1-1所示的頂層數(shù)據(jù)流圖和圖椅征擔(dān)占『治行成虻病人?？叵到y(tǒng)洎療息匝1-2所示的0層數(shù)據(jù)流圖。明1-1吸層數(shù)據(jù)流叫牛暗持征住命恃征葩囹椅征擔(dān)占『治行成虻病人?？叵到y(tǒng)洎療息匝1-2所示的0層數(shù)據(jù)流圖。明1-1吸層數(shù)據(jù)流叫牛暗持征住命恃征葩囹治療恩虬瀏1狒述特征州告M求/沿序意見流求魏擊課村精狂報告請*/洎療意埋儲求【問題1】使用說明中的詞語，給出圖1-1中的實體E1E3的名稱。E1：病人E2:護理人員E3:醫(yī)生本問題考查頂層DFD。頂層DFD一般用來確定系統(tǒng)邊界，將待開發(fā)系統(tǒng)看作一個加工，因此圖中只有唯一的一個處理和一些外部實體，以及這兩者之間的輸入輸出數(shù)據(jù)流。題目要求根據(jù)描述來確定圖中的外部實體。分析題目中的描述，并結(jié)合已經(jīng)在頂層數(shù)據(jù)流圖中給出的數(shù)據(jù)流進行分析。從中可以看出，與系統(tǒng)的交互者包括病人、醫(yī)生和醫(yī)護人員。其中，本地監(jiān)控定期獲取病人的生命特征，病人是生命特征數(shù)據(jù)來源，醫(yī)生和護理人員會得到相關(guān)報告的結(jié)果，如請求病人生命特征報告，并獲得相關(guān)報告。醫(yī)生還需要在必要時添加或更新生命特征范圍。對應(yīng)圖1-1中數(shù)據(jù)流和實體的對應(yīng)關(guān)系，可知E1為病人，E2為護理人員，E3為醫(yī)生。使用說明中的詞語，給出圖1-2中的數(shù)據(jù)存儲D1D4的名稱。D1：生命特征范圍文件 D2:日志文件D3：病歷文件D4:D3：病歷文件解析：本問題考查0層DFD中數(shù)據(jù)存儲的確定。根據(jù)說明中的描述：（2）格式化生命特征：對病人的各項重要生命特征數(shù)據(jù)進行格式化，然后存入日志文件并檢查生命特征（4）維護生命特征范圍：醫(yī)生在必要時（如，新的研究結(jié)果出現(xiàn)時）添加或更新生命特征值的正常范圍；（6）生成病歷：根據(jù)日志文件中的生命特征，醫(yī)生對病人的病情進行描述，形成病歷存入病歷文件；（8）生成治療意見：根據(jù)日志文件中的生命特征和病歷，醫(yī)生給出治療意見，如處方等，并存入治療意見文件。因此，D1為生命特征范圍文件，D2為日志文件，D3為病例文件，D4為治療意見文件?！締栴}3】圖1-2中缺失了4條數(shù)據(jù)流，使用說明、圖1-1和圖1-2中的術(shù)語，給出數(shù)據(jù)流的名稱及其起點和終點。解析：本問題考查0層DFD中缺失的處理和數(shù)據(jù)流。從說明中的描述及圖1-2可知，本地監(jiān)控之后要對重要生命特征存儲日志文件進行格式化，所以在本地監(jiān)控和格式化生命特征之間缺少了數(shù)據(jù)流重要生命特征；檢查生命特征是對格式化后的生命特征進行檢查，所以在格式化生命特征和檢查生命特征之間缺少了數(shù)據(jù)流格式化后的生命特征;根據(jù)曰志文件中的生命特征，醫(yī)生對病人的病情進行描述，形成病歷存入病歷文件?！締栴}4】說明實體E1和E2之前可否有數(shù)據(jù)流，并解釋其原因。E1和E3之間不可以有數(shù)據(jù)流，因為數(shù)據(jù)流的起點和終點中必須有一個是加工（處理）。解析：本問題考查繪制DFD時的注意事項。在DFD中，每條數(shù)據(jù)流的起點和終點之一必須是加工（處理）。本題中，醫(yī)生和護理人員根據(jù)查詢到的治療意見對病人進行治療屬于系統(tǒng)之外的行為，所以兩個實體之間不可以有數(shù)據(jù)流。試題二某法院要開發(fā)一個訴訟案件信息處理系統(tǒng)，該信息系統(tǒng)的部分關(guān)系模式如下：職工（職工編號，姓名，崗位）律師（律師編號，姓名）被告（被告編號，姓名，地址）案件（案件編號，案件類型，案件描述，被告，律師，主審法官，立案日期，狀態(tài)，結(jié)案日期，結(jié)案摘要）審理（審理編號，案件編號，審理日期，摘要）有關(guān)關(guān)系模式的屬性及相關(guān)說明如下：（1） 職工關(guān)系模式的崗位有“法官”、“書記員”和“其他”。（2） 訴訟立案后，即在案件關(guān)系中插入一條相應(yīng)記錄。案件關(guān)系模式的狀態(tài)有“待處理”、“審理中”、“結(jié)案”和“撤銷”，一個案件開始立案時其案件狀態(tài)為“待處理”。（3） 案件關(guān)系模式的案件類型有“偷竊”、“縱火”等。（4） 一個案件自立案到結(jié)案的整個過程由一位法官和一位律師負責(zé)，一個案件通常經(jīng)過一次到多次審理?！締栴}1】假設(shè)案件編號唯一標(biāo)識一個案件，且立案日期小于等于結(jié)案日期。請將如下創(chuàng)建案件關(guān)系的SQL語句的空缺部分補充完整。案件賣型VAbCHAB（10}t窒件描述林配昭民{2C-Q）r立案日蛔DATE,盛告VARCHAR0REFEFEHCES橢告【被言煽號.律■師VABCBAR【6】REFEFENCE3津附t律辯編號L主審卷往VftKCHAB碩Cb）,狀告VAUCKAfa〈6} DEFAULT書處理*耕案日期ETE,紡翼摘要"KC日RH rW3（a） PRIMARYKEY或NOTNULLUNIQUE（b） REFERENCES職工（職工編號）（c） CHECKVALUESIN（'待處理'，’審理中'，’結(jié)案'，’撤銷’）（d） CHECK（立案日期＜二結(jié)案日期）本問題考查SQL中的數(shù)據(jù)定義語言DDL和完整性約束。完整性約束包括三類：實體完整性、參照完整性和用戶定義的完整性。實體完整性約束規(guī)定關(guān)系的主屬性不能取空值，關(guān)系模型中以主碼作為唯一性標(biāo)識；參照完整性約束規(guī)定若屬性（或?qū)傩越M）A是關(guān)系R上的主碼，B是關(guān)系S上的外碼，A與B相對應(yīng)（來自相同的域），則B取值為空或者來自于R上的某個A的值；用戶定義的完整性約束是針對具體的數(shù)據(jù)庫應(yīng)用而定義的，它反映該應(yīng)用所涉及的數(shù)據(jù)必須滿足用戶定義的語義要求。（a） 考查實體完整性約束，案件編號是案件關(guān)系模式的主碼，用關(guān)鍵字PRIMARYKEY或者NOTNULLUNIQUE表示。（b） 考查參照完整性約束，主審法官屬性參照職工關(guān)系模式中的職工編號屬性，由于這兩個屬性名稱不同，因此用REFERENCES職工（職工編號）表示，此處不能省略職工編號。（c） 、（d）考查用戶定義的完整性約束。（c）是在狀態(tài)屬性上定義列級約束，用CHECKVALUESIN（'待處理’，’審理中’，’結(jié)案'，’撤銷’）表示。（d）在立案日期和結(jié)案日期上定義約束，用CHECK（立案日期＜二結(jié)案日期）表示?！締栴}2】請完成下列查詢的SQL語句。（1）查詢當(dāng)前待處理的訴訟案件，顯示案件的案件編號、立案日期、被告姓名、被告地址、案件描述、律師姓名和主審法官姓名。SELECT案件堀蟲立案日期.被豈姓乳整被傳蛀名.也址班鼓告地虬案辨描述.律棘.姓名KS博師姓名， FHQM WHERE案件.被告■被苦.枚告褊兮A"案件，律師―彈㈱,律郵編號AND ；（2）查詢2009年立案的各類案件數(shù)，并按案件數(shù)降序排序。（日期格式舉例：2009年1月1日表示為01-JAN-2009,2009年12月31日表示為31-DEC-2009）SELECTcountA8遂件茹『ROW案件WHSRE ⑴） 曰groupar類型（3）查詢立案次數(shù)超過5次的被告姓名和地址。SELECT姓札地址rcoihnt{*)from案件，馥告TOC\o"1-5"\h\z眄昨H) -GROUPBY 〔Q <1(5 ~(e)職工.姓名AS主審法官姓名案件，被告，律師，職工(關(guān)系模式的順序無關(guān))案件.主審法官=職工.職工編號(h)立案日期BETWEEN'01-JAN-2009'AND'31-DEC-2009'或者立案日期＞='01-JAN-2009'AND立案日期＜='31-DEC-2009，ORDERBY案件數(shù)DESC(j)案件.被告二被告.被告編號(k) 姓名，地址HAVINGcount(*)＞5本問題考查SQL中的數(shù)據(jù)操作語言DML?？疾閯e名和連接查詢條件。(e)處考核別名定義，用AS關(guān)鍵字，且別名根據(jù)題干給出，應(yīng)填“職工.姓名AS主審法官姓名”；(f)處考查該查詢涉及到的關(guān)系模式，此處應(yīng)涉及到案件、被告、律師和職工4個關(guān)系模式，在FROM子句中關(guān)系模式是順序無關(guān)的；(g)處考核案件關(guān)系模式和職工關(guān)系模式的連接條件，即“案件.主審法官二職工.職工編號”?？疾槿掌趯傩圆Σ樵兘Y(jié)果進行分組和排序。(h)處主要考核日期作為條件屬性的語法，題干中已經(jīng)給出日期格式的提示。在兩個日期之間的時間的語法可以用BETWEEN-AND…，也可以用〉二???＜二，因此，此處可以填“立案日期BETWEEN'01-JAN-2009'AND'31-DEC-2009'”或者“立案日期＞=,01-JAN-2009'AND立案日期＜='31-DEC-2009'”；(i)處考核查詢結(jié)果的排序，用“ORDERBY案件數(shù)DESC”表示，其中的DESC關(guān)鍵字不能省略。在ORDERBY子句中，若不用表示升序的關(guān)鍵字ASC或表示降序的關(guān)鍵字DESC表示，則默認為升序排序。考查對查詢結(jié)果進行分組，并指定滿足條件的分組才能輸出。(j)處考核兩個關(guān)系模式的連接關(guān)系，應(yīng)填“案件被告二被告.被告編號”；(k)處考核分組，此處填“姓名，地址”不能僅填姓名或者地址；(1)處考核分組條件，用HAVING關(guān)鍵字，應(yīng)填"HAVINGcount(*)〉5”。當(dāng)插入一個審理記錄時，檢查案件的狀態(tài)，若狀態(tài)為“未處理”，則將其修改為“審理中”。下面是用觸發(fā)器實現(xiàn)該需求的SQL語句，請將空缺部分補充完整.CREATETRIGGER AFT隴3) CifiW聘REFERENCINGn&urawASnrawFOREACHEWWHEN，未處理”-(SELECT就志PROM案牌WHERE策件編號=ntow.S件墉號｝aEGINUPDATE.案件En) @WHERE ⑹iEND(m)INSERT(n)SET狀態(tài)二'審理中’ (o)案件編號=nrow.案件編號本問題考查觸發(fā)器。觸發(fā)器是一個能由系統(tǒng)自動執(zhí)行對數(shù)據(jù)庫修改的語句。一個觸發(fā)器由事件、條件和動態(tài)三部分組成：事件即對數(shù)據(jù)庫的插入、刪除和修改等操作。觸發(fā)器在這些事件發(fā)生時，將開始工作；條件是指觸發(fā)器將測試條件是否成立，若成立就執(zhí)行相應(yīng)的動作，否則就什么也不做;動態(tài)是指若觸發(fā)器測試滿足預(yù)定的條件，那么就由數(shù)據(jù)庫管理系統(tǒng)執(zhí)行這些動作。本題首先定義觸發(fā)器的事件，即對審理關(guān)系模式插入后激活觸發(fā)器。接下來定義觸發(fā)器的動作，即修改案件關(guān)系模式的狀態(tài)為“審理中”，測試條件為若該案件原來狀態(tài)為“待處理”需要關(guān)聯(lián)的兩個關(guān)系模式是案件和審理。試題三【說明】某服裝銷售公司擬開發(fā)一套服裝采購管理系統(tǒng)，以方便對服裝采購和庫存進行管理。【需求分析】采購系統(tǒng)需要維護服裝信息及服裝在倉庫中的存放情況。系統(tǒng)按服裝的銷售種類記錄服裝信息。服裝信息主要包括：服裝編碼、服裝描述、服裝類型、銷售價格、尺碼和面料，其中，服裝類型為銷售分類，服裝按銷售分類編碼。倉庫信息主要包括：倉庫編碼、倉庫位置、倉庫容量和庫管員。系統(tǒng)記錄庫管員的庫管員編碼、姓名和級別。一個庫管員可以管理多個倉庫，每個倉庫有一名庫管員。一個倉庫中可以存放多類服裝，一類服裝可能存放在多個倉庫中。當(dāng)庫管員發(fā)現(xiàn)有一類或者多類服裝缺貨時，需要生成采購訂單。一個采購訂單可以包含多類服裝。每類服裝可由多個不同的供應(yīng)商供應(yīng)，但具有相同的服裝編碼。采購訂單主要記錄訂單編碼、訂貨日期和應(yīng)到貨日期，并需詳細記錄所采購的每類服裝的數(shù)量、采購價格和對應(yīng)的多個供應(yīng)商。系統(tǒng)需記錄每類服裝的各個供應(yīng)商信息和供應(yīng)情況。供應(yīng)商信息包括：供應(yīng)商編碼、供應(yīng)商名稱、地址、企業(yè)法人和聯(lián)系電話。供應(yīng)情況記錄供應(yīng)商所供應(yīng)服裝的服裝類型和服裝質(zhì)量等級。一個供應(yīng)商可以供應(yīng)多類服裝，一類服裝可由多個供應(yīng)商供應(yīng)。庫管員根據(jù)入庫時的服裝質(zhì)量情況，設(shè)定或修改每個供應(yīng)商所供應(yīng)的每類服裝的服裝質(zhì)量等級，用以作為后續(xù)采購服裝時，選擇供應(yīng)商的參考標(biāo)準。【概念模型設(shè)計】根據(jù)需求階段收集的信息，設(shè)計的實體聯(lián)系圖(不完整)如圖3-1所示?！具壿嫿Y(jié)構(gòu)設(shè)計】根據(jù)概念模型設(shè)計階段完成的實體聯(lián)系圖，得出如下關(guān)系模式(不完整):庫管員（ ,.⑴一一一.姓名，級別）倉庫信息（ ⑵ ，倉犀位置.倉庫容量）服裝（服裝編碼,服裝描述，服裝類型，尺碼，面料，銷售價格）供應(yīng)商（ ⑶ 「供應(yīng)商名稱，地址「聯(lián)系電話,企業(yè)法人）供應(yīng)情況（ ⑷一■阪裝質(zhì)量等圾）采購訂單（—〔5） >果購訂單明細c w>【問題1】補充圖3-1中的聯(lián)系和聯(lián)系的類型。本問題考查數(shù)據(jù)庫的概念結(jié)構(gòu)設(shè)計，題目要求補充完整實體聯(lián)系圖中的聯(lián)系和聯(lián)系的類型。根據(jù)題目的需求描述可知，一個庫管員可以管理多個倉庫，每個倉庫有一名庫管員。所以，倉庫實體和庫管員實體之間存在“管理”聯(lián)系，聯(lián)系的類型為多對一（*:1）。根據(jù)題目的需求描述可知，一個倉庫中可以存放多類服裝，一類服裝可能存放在多個倉庫中。所以，倉庫實體和服裝實體之間存在“存放”聯(lián)系，聯(lián)系的類型為多對多（*:*）。根據(jù)題目的需求描述可知，一個采購訂單可以包含多類服裝，每類服裝可由多個不同的供應(yīng)商供應(yīng)。所以，采購訂單實體與服裝實體和供應(yīng)商實體三者之間存在“采購”聯(lián)系，三者之間聯(lián)系的類型為多對多對多（*:*:*）。根據(jù)題目的需求描述可知，一個供應(yīng)商可以供應(yīng)多類服裝，一類服裝可由多個供應(yīng)商供應(yīng)。所以，供應(yīng)商實體和服裝實體之間存在“供應(yīng)”聯(lián)系，聯(lián)系的類型為多對多（*:*）?！締栴}2】根據(jù)圖3-1，將邏輯結(jié)構(gòu)設(shè)計階段生成的關(guān)系模式中的空（1） （6）補充完整。對所有關(guān)系模式，用下劃線指出各關(guān)系模式的主鍵。（1）倉庫編碼，庫管員編碼供應(yīng)商編碼，服裝編碼訂單編碼，訂貨日期，應(yīng)到貨日期訂單編碼，服裝編碼，供應(yīng)商編碼，數(shù)量，采購價格解析：根據(jù)實體聯(lián)系圖和需求描述，倉庫信息主要包括：倉庫編碼、倉庫位置、倉庫容量和庫管員。對于“倉庫信息”關(guān)系模式，由于倉庫實體與庫管員實體有多對一聯(lián)系，需記錄對應(yīng)的庫管員，并且需補充屬性倉庫編碼。因此，“倉庫信息”關(guān)系模式，需補充屬性“倉庫編碼”和“庫管員編碼”。根據(jù)實體聯(lián)系圖和需求描述，供應(yīng)商信息包括：供應(yīng)商編碼、供應(yīng)商名稱、地址、企業(yè)法人和聯(lián)系電話。所以，對于“供應(yīng)商”關(guān)系模式，需補充屬性“供應(yīng)商編碼”。根據(jù)實體聯(lián)系圖和需求描述，“供應(yīng)情況”關(guān)系模式需記錄供應(yīng)商和服裝的多對多聯(lián)系，即一個供應(yīng)商可以供應(yīng)多類服裝，一類服裝可由多個供應(yīng)商供應(yīng)。所以，對于“供應(yīng)商”關(guān)系模式，需補充屬性“供應(yīng)商編碼”和“服裝編碼”。根據(jù)實體聯(lián)系圖和需求描述，采購訂單主要記錄訂單編碼、訂貨日期和應(yīng)到貨日期。所以，對于“采購訂單”關(guān)系模式需補充屬性：訂單編碼，訂貨日期，應(yīng)到貨日期。由于采購訂單還需詳細記錄所采購的每類服裝的數(shù)量、采購價格和對應(yīng)的多個供應(yīng)商。因此，“采購訂單明細”關(guān)系模式，需記錄采購訂單實體與服裝實體和供應(yīng)商實體三者之間存在的多對多對多聯(lián)系。對于“采購訂單明細”關(guān)系模式，需補充屬性“訂單編碼，服裝編碼，供應(yīng)商編碼，數(shù)量，采購價格”?！締栴}3】如果庫管員定期需要輪流對所有倉庫中的服裝質(zhì)量進行抽查，對每個倉庫中的每一類被抽查服裝需要記錄一條抽查結(jié)果，并且需要記錄抽查的時間和負責(zé)抽查的庫管員。請根據(jù)該要求，對圖3-1進行修改，畫出修改后的實體間聯(lián)系和聯(lián)系的類型。解析：本問題考查的是數(shù)據(jù)庫的概念結(jié)構(gòu)設(shè)計，根據(jù)新增的需求增加實體聯(lián)系圖中的實體的聯(lián)系和聯(lián)系的類型。根據(jù)問題描述，多個庫管員需對每個倉庫中的每一類被抽查服裝記錄一條抽查結(jié)果。則須在庫管員實體與倉庫實體和服裝實體三者之間的存在“抽查”聯(lián)系，聯(lián)系的類型是多對多對多（*:*:*）。試題四某學(xué)校擬開發(fā)一套校友捐贈管理系統(tǒng)，以便對校友的捐贈資金進行管理?！拘枨蠓治觥啃Ｓ芽梢韵?qū)W校提出捐贈申請，說明捐贈的金額、捐贈類型和使用方式。捐贈類型包括一次性捐贈和周期性捐贈。捐贈的使用方式分為兩種：一種用于資助個人，即受益人為多名學(xué)生或老師，主要用于獎學(xué)金、獎教金和助學(xué)金等；另一種用于資助捐贈項目，即資助已有的捐贈項目和設(shè)立新的捐贈項目，主要用于改善教學(xué)設(shè)施、實驗室建設(shè)和設(shè)備購買等。捐贈項目由捐贈理事建立，一個捐贈項目可以涉及多個受益單位，每個單位在該項目中有確定的受益比例。由捐贈理事為項目中的每個單位指定一個項目負責(zé)人，并指定每個單位受益比例。每個單位的受益比例是指在一個捐贈項目中的每個單位所應(yīng)得的金額占該捐贈項目總受益金額的比例。一個捐贈項目可以由多個捐贈來資助，一個捐贈也可以資助多個捐贈項目。由捐贈理事將一個捐贈的捐贈金額分配給所資助的多個捐贈項目，并指定給每個捐贈項目的具體的捐贈金額。初步設(shè)計了校友捐贈信息數(shù)據(jù)庫，其關(guān)系模式如圖4-1所示。粳;足5息（校友瞑號，姓名，工作尊位，粗務(wù)，穌,屈畿.入學(xué)年費，身粽證號）人?受拄人所在單位，受薩入案型，膈g使用說明）摘孺項目（項巨醐*項目名稼.超止時因）艱目受罐悄次］股目編號，受—也負貿(mào)人?受拄比例?捐神I埼引理自壹益值舶）圖牛1校友捎隧信息敷據(jù)庫罪系模式關(guān)系模式的主要屬性、含義及約束如表4-1所示。<4-1主要同性，含覽及幼束雇性含紫耘鄒r金件項目煽號唯一標(biāo)識某個掬贈項目博啟捐se的受益人由林受■人類型分辦學(xué)生、ttff墅盜金鼬每個受益人具體啊到的捐尚金額 _髡益比例目中每個捐陷單位網(wǎng)御到的現(xiàn)目幫牌尊盤斷的比例項目受益金額a十捐陸中分配垮二速S8瑣目的具怫逾額【問題1】對關(guān)系“校友信息”，請回答以下問題：（1） 列舉出所有候選鍵的屬性。（2） 關(guān)系“校友信息”可達到第幾范式，用60字以內(nèi)文字簡要敘述理由?！靶Ｓ丫幪枴焙汀吧矸葑C號”。“校友信息”關(guān)系模式可以達到第二范式，不滿足第三范式。由于“校友信息”關(guān)系模式的主鍵是“校友編號”，但又包含函數(shù)依賴：班級一院系，入學(xué)年份不滿足第三范式的要求，即存在非主屬性對碼的傳遞依賴。解析：本問題考查非主屬性和第三范式。根據(jù)“校友信息”關(guān)系模式可知，“校友編號”和“身份證號”都是校友信息的決定因素，因此都是候選鍵的屬性。根據(jù)第三范式的要求：每一個非主屬性既不部分依賴于碼也不傳遞依賴于碼。根據(jù)“校友信息”關(guān)系模式，其中存在以下函數(shù)依賴：班級一院系，入學(xué)年份而由于“校友信息”關(guān)系模式的主鍵是“校友編號因而，存在非主屬性對碼的傳遞依賴。所以，“校友信息”關(guān)系模式可以達到第二范式，但不滿足第三范式?！締栴}2】對關(guān)系“捐贈信息”，請回答以下問題：⑴針對“捐贈信息”關(guān)系，用100字以內(nèi)文字簡要說明會產(chǎn)生什么問題。把“捐贈信息”分解為第三范式，分解后的關(guān)系名依次為：捐贈信息1，捐贈信息2,……列出“捐贈信息”關(guān)系修正后的各關(guān)系模式的主鍵?！熬栀浶畔ⅰ标P(guān)系不滿足第二范式，即非主屬性不完全依賴于碼。會造成：插入異常、刪除異常和修改復(fù)雜(或修改異常)。分解后的關(guān)系模式如下：捐贈信息1(捐贈編號，捐贈校友，捐贈時間，捐贈金額，捐贈類型，使用方式)捐贈信息2(受益人身份證號，受益人姓名，受益人所在單位，受益人類型)捐贈信息3(捐贈編號，受益人身份證號，受益金額，使用說明)(1)修正后的主鍵如下：捐贈信息1(捐贈編號，捐贈校友，捐贈時間，捐贈金額，捐贈類型，使用方式)捐贈信息2(受益人身份證號，受益人姓名，受益人所在單位，受益人類型)捐贈信息3（捐贈編號，受益人身份證號，受益金額，使用說明）解析：本問題考查第二范式和第三范式。根據(jù)第三范式的要求：非主屬性不完全依賴于碼。根據(jù)“捐贈信息”關(guān)系模式，可知其碼為（捐贈編號，受益人身份證號），而又存在部分函數(shù)依賴：捐贈編號一捐贈校友，捐贈時間，捐贈金額，捐贈類型，使用方式。受益人身份證號一受益人姓名，受益人所在單位，受益人類型。所以，捐贈信息”關(guān)系不滿足第二范式，會造成：插入異常、刪除異常和修改復(fù)雜（或修改異常）。因為存在部分函數(shù)依賴，因此對“捐贈信息”進行分解，分解后的關(guān)系模式如下：捐贈信息1（捐贈編號，捐贈校友，捐贈時間，捐贈金額，捐贈類型，使用方式）捐贈信息2（受益人身份證號，受益人姓名，受益人所在單位，受益人類型）捐贈信息3（捐贈編號，受益人身份證號，受益金額，使用說明）其中，“捐贈信息1”關(guān)系的函數(shù)依賴為：捐贈編號一捐贈校友，捐贈時間，捐贈金額，捐贈類型，使用方式?！熬栀浶畔?”關(guān)系的函數(shù)依賴為：受益人身份證號一受益人姓名，受益人所在單位，受益人類型。“捐贈信息3”關(guān)系的函數(shù)依賴為：捐贈編號，受益人身份證號一受益金額，使用說明。這三個關(guān)系中的每一個非主屬性既不部分依賴于碼也不傳遞依賴于碼，因此滿足第三范式的要求?！締栴}3】對關(guān)系“項目受益情況”，請回答以下問題：（1）關(guān)系“項目受益情況”是不是第四范式，用100字以內(nèi)文字敘述理由。⑵把“項目受益情況”分解為第四范式，分解后的關(guān)系名依次為：項目受益情況1，項目受益情況2，……（1）“項目受益情況”關(guān)系模式，不滿足第四范式。（2）分解后的關(guān)系模式如下：項目受益情況1（項目編號，受益單位，受益比例）項目受益情況2（項目編號，捐贈編號，項目受益金額）本問題考查的是第四范式。根據(jù)“項目受益情況”關(guān)系模式可知，其碼為：項目編號，受益單位，捐贈編號。而又存在部分函數(shù)依賴：項目編號，受益單位一受益比例項目編號，捐贈編號一項目受益金額項目編號一受益單位，受益比例項目編號一捐贈編號，項目受益金額同時，可以根據(jù)第四范式的要求：不允許有非平凡且非函數(shù)依賴的多值依賴。而在“項目受益情況”關(guān)系模式中存在如下的多值依賴：項目編號一受益單位，受益比例項目編號一捐贈編號，項目受益金額因此，“項目受益情況”關(guān)系模式不滿足第四范式。因為存在多值依賴，因此對“項目受益情況”進行分解，分解后的關(guān)系模式如下：項目受益情況1（項目編號，受益單位，受益比例）項目受益情況2（項目編號，捐贈編號，項目受益金額）其中：“項目受益情況1”關(guān)系的函數(shù)依賴為：項目編號，受益單位一受益比例。“項目受益情況2”關(guān)系的函數(shù)依賴為：項目編號，捐贈編號一項目受益金額。這兩個關(guān)系不存在多值依賴，因此滿足第四范式的要求。試題五某網(wǎng)上商品銷售系統(tǒng)的業(yè)務(wù)流程如下：將客戶的訂單記錄(訂單號，客戶ID,商品ID,購買數(shù)量)寫入訂單表；將庫存表(商品ID，庫存量)中訂購商品的庫存量減去該商品的購買數(shù)量。針對上述業(yè)務(wù)流程，完成下列問題：【問題1】假設(shè)庫存量有大于等于0的約束，可能出現(xiàn)如下情況：當(dāng)訂單記錄寫入訂單表后，修改庫存表時因違法約束而無法執(zhí)行，應(yīng)如何處理？(100字以內(nèi))將寫訂單記錄和修改庫存表作為一個完整的事務(wù)來處理，當(dāng)修改庫存表無法執(zhí)行時，回滾事務(wù)，則會撤銷寫入的訂單記錄，數(shù)據(jù)庫保持一致。解析：本問題考查事務(wù)的基本概念。對于現(xiàn)實中的一項業(yè)務(wù)，相對應(yīng)的數(shù)據(jù)庫更新操作應(yīng)作為一個完整的事務(wù)，要么全做要么全不做。銷售業(yè)務(wù)對應(yīng)的寫入訂單記錄和更新庫存表應(yīng)作為一個事務(wù)，當(dāng)出現(xiàn)故障(違反約束)而無法完成時，應(yīng)回滾事務(wù)?！締栴}2】引入如下偽指令：將商品A的訂單記錄插入訂單表記為I(A);讀取商品A的庫存量到變量x，記為x=I(A);變量x值寫入商品A中的庫存量，記為W(A,x)。則客戶i的銷售業(yè)務(wù)偽指令序列為：Ii(A)，xi=Ri(A)，xi=xi-aiWi(A,xi).其中ai為商品的購買數(shù)量。假設(shè)當(dāng)前庫存量足夠，不考慮發(fā)生修改后庫存量小于0的情況。若客戶1、客戶2同時購買同一種商品時，可能出現(xiàn)的執(zhí)行序列為：I1(A)，I2(A)，x