第一篇：辦公自動化系統需求分析報告

辦公自動化系統 需求規格說明書

1.引言 1.1 目標

開發網絡辦公系統的市場前景是廣闊的。大型企業需要高層次的網絡辦公自動化，他們往往會選擇大型的軟件公司合作開發，所需的開發費用和維護費用也是非常高的。這些高額的費用并非大多數中小企業所能承受得起的。本系統就是為這些公司制定的。

1.2 參考文獻

?《軟件工程導論》，張海藩，清華大學出版社。?《實用軟件工程》，鄭人杰等，清華大學出版社。

2.總體描述

2.1 用戶類和用戶特性

本OA辦公系統軟件的最終用戶是面向中大型企業的員工和相關管理人員一套軟件，操作人員需要有一定的計算機操作基礎，對于系統管理員不僅要有一定的計算機基礎，還要求有一定的網絡管理經驗。

2.2 運行環境(Operation Environment, OE)OE-1：“辦公自動化系統”的操作將通過如下的Web瀏覽器來完成：Microsoft Internet Explorer版本10.0和11.0，Netspcape Communication版本4.7和Netscape版本8和9。OE-2：“辦公自動化系統”將運行在一個服務器中，該服務器運行當前由公司批準的Red Hat Linux版本和Apache HTTP Server。OE-3：“辦公自動化系統”將允許用戶通過公司內聯網來訪問，如果用戶將被授權在公司的外部穿過防火墻來訪問，那么用戶也可以在家通過Internet來訪問該系統。

2.4 設計和實現的約束條件（constriant）

CO-1:系統的設計、編碼和維護文檔將遵照Process Import Intranet Development Standard(Process Import公司內聯網開發標準)版本1.3。CO-2：系統將采用公司標準的當期Oracle數據庫引擎。CO-3：所有HTML代碼將遵照HTML4.0版本。C0-4：所有腳本都用Perl語言來編寫。

2.5 用戶文檔（User Documentation, UD）

UD-1：系統將提供一個分層的跨鏈接的HTML聯機幫助系統，它描述并演示了所有系統功能。

UD-2：如果是一個新用戶第一次使用該系統，系統可以根據用戶的要求，提供一個聯機幫助，這樣用戶可以使用靜態教程菜單來具體實踐一下如何使用。系統不會將采用這一模板的管理案例存儲到數據庫。

UD-3: 開發期限十一至十二周。

3.系統特性

3.1 員工名錄管理

本系統會將員工的信息錄入到系統數據庫中。其中包括人員履歷、轉正申請、離職申請以及員工一些重大事情的記錄。

3.2 部門管理 上級部門有權對下級部門進行管理，并查看該下級部門人員的信息，以及上級部門對下級部門發布任務、取消任務、撤銷部門、創建部門。

3.3 綜合郵件管理

管理員有權對已經超過規定時限的數據庫中的郵件進行管理,如進行郵件的刪除；對于一些已經刪除的郵件進行恢復等。員工可以對自己寫的郵件進行發送、修改、刪除、保存操作；對收到的郵件進行保存、刪除操作。

3.4 綜合事務管理

綜合事務管理包括行政管理、信息管理、人事管理、車輛管理進行全面的管理。

3.5 工作流管理

幾乎所有的業務過程都是工作流，特別是辦公公文審批流轉處理。每一項工作以流程的形式，由發起者（如文件起草人）發起流程，經過本部門以及其他部門的處理（如簽署、會簽），最終到達流程的終點（如發出文件、歸檔入庫）。

3.6 個人日程管理

個人日程管理中有工作日志、工作計劃、消息提醒、通訊錄。工作日志：基于網絡的工作日志系統，可設為私有，限制，公共三類級別分別供自己，部門領導，全部人員查看。便于個人總結，便于上級檢查工作，便于和同事分享工作經驗，是知識管理挖掘隱性知識的一種手段；用戶可以隨意添加、刪除、修改多個日志，通過翻閱日歷查看任一天的日志也可通過日期，關鍵字等檢索日志。工作計劃：針對自己和領導下達的任務進行布置；布置的具體任務涉及時間、任務查看人、任務完成的標準、任務附件、提醒日期、匯報時限等內容。消息提醒：設置消息提醒功能每當用戶登錄系統時提示窗口。通訊錄：記錄聯系人具體通訊信息，包括我的通訊錄、公共聯系人和內部通訊錄三種類型。

3.7 內部消息服務

內部消息服務將消息在公司內部傳遞，管理員有權對消息進行添加、修改、刪除操作。

3.8 文件檔案管理

對現有檔案進行管理，可以直接增加新的檔案，并對檔案實現添加、刪除和分發查詢、分類存儲等操作。

3.9 云存儲管理

云存儲管理是對云數據庫中內容進行存儲、刪除、備份、修改操作。

4.用例圖

4.1 郵件管理用例圖

4.2 個人日程安排

5.外部接口需求

5.1 用戶界面（User Interfaces, UI）

在用戶界面部分，根據需求分析的結果，用戶需要一個用戶友善界面。在界面設計上，應做到簡單明了、易于操作，并且要注意到界面的布局，應突出的顯示重要以及錯誤信息。外觀上也要做到合理；合理化，考慮到用戶多對Windows風格較熟悉，應盡量向這一方向靠攏。在設計語言上，已決定使用Delphi所提供的可視化組件，向Windows風格靠近。其中服務器程序界面要做到操作簡單，易于管理。在設計上采用下拉式菜單方式，在出錯顯示上可調用Delphi庫中錯誤提示函數。總的來說，系統的用戶界面應做到可靠性、簡單性、易學習和使用。

5.2 硬件接口(Hardware Interfaces, HI)

?處理器型號及內存容量；

?外存容量、聯機或脫機、媒體及其存儲格式。設備的型號及數量 ?數據通信設備的型號和數量 ④輸入及輸出設備的型號和數量 ⑤功能及其他專用硬件

5.3軟件接口（Software Interfaces, SI）

服務器程序可使用Delphi提供的對SQL SERVER 的接口，進行對數據庫的所有訪問。服務器程序上可使用SQL SERVER對數據庫的備份命令，以做到對數據的保存。在網絡軟件接口方面，使用一種無差錯的傳輸協議，采用滑動窗口方式對數據進行網絡傳輸及接受。

6.其他非功能性需求 6.1 性能（PErformance）需求

本項目軟件性能要求如下：

?告警信息從產生到顯示出來的時延不應該大于15秒。?配置信息的更新最大時延為24小時。?性能監控數據時間間隔不超過15分鐘。

④對本軟件系統用戶經常使用的90%操作響應時間小于20秒，對于極少使用的10%操作響應時間應不小于120秒。

⑤ 保證系統并發訪問用戶數>30。

⑥系統數據庫容量應能夠滿足各功能模塊的需要。能滿足告警和性能原始數據、日志信息等半年的存儲容量；告警統計和性能數據一年的存儲容量。

6.2 安全性（SEcurity）需求

系統應該具有對系統自身的管理功能，應實現網管系統自身的完善的維護和管理，需提交標準安裝程序。提供必要的操作維護手冊及技術手冊。當進行版本升級時，提供版本差異的詳細說明。

7.其他需求

7.1 系統的封閉性：用戶的封閉性較好，用戶基本上在提示信息下輸數據。7.2 系統的容錯性：用戶數錯數據都有提示信息，具有較好的容錯性能。7.3 可維護性：新功能的實現僅涉及局部。

第二篇：《辦公自動化系統》技術需求文檔

《辦公自動化系統》技術需求文檔

辦公自動化系統可以加大提高辦公效率，使得實際業務通過網絡流轉，并適用于通用性、靈活性、保密性和標準化等各項原則，現將各項技術要求列舉如下：

1、系統可以整合到其他應用系統或平臺，進行門戶統一管理，實現無縫對接。

2、工作流管理體系，用戶可以自定制自己需要的業務流程和業務OFFICE 文檔模板。

3、可實現嚴格的工作流程跟蹤、監控和催辦。有信息提醒功能。

4、用戶權限管理可以分項分類到各項工作，并可以指定權限到分組或者單個用戶。

5、用戶可以任意定制私人桌面模塊。

6、可以自定義報表

7、文檔流轉過程痕跡保留、留痕查看、手寫批注、電子印章。

8、可以支持手機短信平臺、移動辦公。

9、可以有內部消息的發送傳遞。

10、文件編輯時具有緩存和定時保存功能,避免因為斷網等故障的出現造成錄入數據的丟失。

11、可以實現IP地址使用限制管理。

12、發布環境最好采用TomCat，數據庫平臺可任意選擇。

13、提供數據庫數據備份功能。

服務要求：本系統自完成系統安裝及培訓并經采購方驗收合格之日起，乙方免費質保一年。

第三篇：系統需求分析報告

系統需求分析報告

目錄

目錄.............................................................................................................I

1、項目描述...............................................................................................1 1.1 背景................................................................................................1 1.2研究意義........................................................................................1

2、需求分析...............................................................................................1 2.1功能需求分析................................................................................2 2.1.1 系統管理功能......................................................................2 2.1.2 流量劫持功能....................................................................2 2.2性能需求分析................................................................................2

I

1、項目描述

1.1 背景

隨著網絡的普及，網絡業務應用向深度和廣度不斷發展，方便用戶的同時，也因用戶終端存在網絡安全漏洞或用戶網絡安全意識的疏忽，使得網絡上涉及如：電子商務、在線游戲、DNS授權服務、網銀支付系統、社交網站、論壇、博客、門戶網站等在線業務受到黑客及網絡犯罪份子的攻擊，對個人用戶信息（網銀、支付錢包賬號密碼等）的保密和對國家互聯網信息管理與審計構成嚴重威脅。

1.2研究意義

本項目針對以上問題，主要利用了以下兩種技術：僵尸網絡反制技術及HTTP/HTTPS協議通信的監控技術。

網絡攻擊已嚴重威脅著網絡的安全，及時的發現網絡攻擊并在必要的時候劫持與反制網絡攻擊，成為保障互聯網正常運行、保障在線業務系統正常訪問的重要方法。

2、需求分析

經過與項目委托方多次討論，設計系統的目的是為實現對特定非法用戶Web（HTTP/HTTPS協議）通信進行監控及反制，具體要求實現的功能有：監控系統遠程控制、針對特定非法用戶上網流量劫持、針對特定非法用戶Web通信進行JS腳本注入、獲取非法用戶賬號和密碼、獲取非法用戶訪問某些網站的Cookie。

第 1 頁 2.1功能需求分析

根據監控系統的要求對系統的功能進行分析，明確了系統需要實現的功能。系統的功能結構模塊：系統管理功能、流量劫持功能、監控與反制功能。

2.1.1 系統管理功能

系統管理模塊主要負責系統登錄、系統遠程控制、黑名單庫配置、數據存儲和展示。數據展示包含數據存儲和數據展示，數據存儲負責接收后端和前端JS探針采集的數據并存儲到數據庫，數據展示負責提取數據庫數據并顯示。

2.1.2 流量劫持功能

本文流量劫持指DNS協議劫持，主要由四個部分組成：報文捕獲、協議解析、IP及域名查找匹配、DNS協議欺騙。

2.2性能需求分析

1.DNS流量劫持成功率

為了達到項目委托單位的要求，需要對特定用戶訪問特定網站的流量進行準確監控，同時保證流量劫持的成功率（90%以上）。

2.監控與反制系統并發量

監控與反制系統服務器的并發性能直接決定同時能夠監聽的用戶數。當被監控用戶數過大，監控與反制系統并發處理能力到極大挑戰。

3.系統運行穩定性

第 2 頁 系統穩定性是系統最基本也是最重要的要求，運行穩定性關系到系統能否長時間穩定運行。系統的穩定性體現在：隨著運行時間的增加，系統并不會出現內存泄露、甚至系統崩潰等情況。其中內存泄露可通過內存消耗、CPU使用率指標度量。

第 3 頁

第四篇：工資管理系統需求分析報告

工資管理系統需求分析報告

引言

1.編寫目的

編寫該文檔是為了分析人工管理企業工資的流程，把人工模式抽象為可在計算機上處理的自動模式，對企業工資的科學管理進行分析與總結，便于開發小組成員對系統整體功能的認識，通過該文檔，確定了系統的目的和功能，以及管理的流程和方法，同時也為使用者提供參考。

2.背景

隨著企業的快速發展，企業規模越來越大，在職員工的數量也越來越多，企業工資管理更加的復雜，而工資管理是一項瑣碎、復雜而又十分細致的工作，工資計算、發放、核算的工作量很大，一般不允許出錯，如果實行手工操作，每月發放工資須手工填制大量的表格，這就會耗費工作人員大量的時間和精力，計算機進行工資發放工作，不僅能夠保證工資核算準確無誤、快速輸出，而且還可以利用計算機對有關工資的各種信息進行統計，服務于財務部門其他方面的核算和財務處理，同時計算機具有著手工管理所無法比擬的優點.例如:檢索迅速、查找方便、可靠性高、存儲量大、保密性好、壽命長、成本低等。這些優點能夠極大地提高人事工資資管理的效率,也是企業的科學化、正規化管理,與世界接軌的重要條件。這就對企業工資管理提出了新的要求，用計算機管理系統來管理企業工資已經成為目前的趨勢，使用計算機可以高速，快捷地完成以上工作。在計算機聯網后，數據在網上傳遞，可以實現數據共享，避免重復勞動，規范數據管理行為，從而提高了管理效率和水平。企業工資管理系統便是以計算機為工具，通過對工資管理所需的信息管理，不僅把管理人員從繁瑣的數據計算處理中解脫出來，而且優化了管理體系，使其高效化，簡易化，智能化，也提高了透明度和互動性。

3.功能定義

（1）員工基本信息的添加，修改，刪除，查找和輔助查詢。

（2）工資標準設定功能。具體包括工資，出行費，醫療保險,養老金，水電費，其他費用，補貼，獎金標準的設定。

（3）工資信息瀏覽。

（4）員工工資表創建。

（5）工資調整管理。

（6）工資統計。

為完善系統管理功能，增加工資系統用戶管理功能，包括系統用戶數據的添加，修改和刪除。教職員工為系統普通用戶，只能運行系統個人工資查詢功能；系統管理員則能運行系統所有功能，從而有效保證系統數據的安全性。

4.功能描述

用例模型

順序模型（管理員查詢工資）

活動模型(登陸)

4.1員工基本檔案信息管理功能描述：

凡屬于本部門的員工，都需要對其基本的檔案信息做好記錄存儲處理。以方便高級管理人員時時的了解或查閱其員工基本信息。對員工基本信息的操作包括添加信息、修改信息、查詢信息，同時在數據庫中要形成員工基本信息表。

4.2工資管理功能描述： 工資計算：

在進行工資計算之前，管理員首先應該根據部門的實際業務情況確定好各個部門中所需要的工資項目及分別對工資項目進行計算的方式，然后按照系統工資種類的設定，對每個員工分別依次實際工資項目構成情況，如考勤情況工資、底薪工資、獎懲工資、提成工資、應交所得稅等等項目，錄入相應的工資金額數，再計算出總的應得工資、實得工資的工資項目。在數據的錄入過程中系統會根據用戶 3

誤輸、錯誤輸入智能提示引導用戶錄入數據的正確性。要形成的數據庫中的表為員工工資信息表。

工資統計分析：

對員工工資數據計算完后，同時要將工資信息統計分析，如匯總統計，工資項目明細數據的匯總等，又分為對員工個人工資統計分析、部門工資統計分析、月份工資統計分析、季度工資統計分析、年工資分析統計。

4.3工資查詢功能描述：

在查詢這個模塊里，系統能支持用戶在客戶端按照各種不同的字段名稱進行工資信息的查詢。同時，迅速的響應用戶的查詢請求，不同級別的人系統會根據其權限級別的大小享有不同程度的功能。不同級別的人不能越權進行操作。在查詢過程中，為避免由于在同一時刻里訪問人數過多造成響應緩慢時，每登錄的一個用戶，系統記數器自動加一，當記數大于峰值時，系統彈出對話框提示用戶進行等待，從而有效的避免了系統在查詢過程中快速響應的優點。

4.4系統維護：

用戶在第一次使用系統時，在服務器端需要用戶做系統初始化的處理，包括； 1． 設置工資項目種類、相應工資項目的計算

2．設置系統使用用戶及口令、權限的級別，對公司不同要求用戶授不同權限，可限制一次性訪問數據庫用戶數量。對每個訪問數據庫的登陸用戶有日志記錄。由系統管理員維護。在系統運行過程中，數據庫管理員在系統運行過程中，還可以即使的進行系統數據的更改，如：對員工工資數據的更改，對工資項目計算方式的更改，定期做好系統數據的備份操作、還原、清理等。

5.非功能性需求： 5.1可靠性

1． 可恢復性

如果正在使用時出現故障，為了完成做好的工資記錄，需要嘗試采用本地方案（如存儲和轉發）加以解決。對此需要更深入的分析 2． 長時間運行

每月都要對工資結算，要求系統能夠持續可靠運行，3． 容錯性

當員工不能識別，應能夠給予提示。

5.2可支持性

1．可適應性

不同型號的票據打印機打印的效果可能存在差異，軟件能夠支持市場上主流的票據打印機。2．可配置型

人員的權限會根據企業的變化而調整，系統應該能夠方便配置調整。還存在一些其他的配置要求，如打印格式、查詢項目等，對此需要進一步分析。

5.3可行性

1.評價標準

A.是否消耗太多經費，耗時太長； B.是否功能齊全，運行穩定； C.是否方便管理； D.設置是否靈活；

E.是否具有界面靈活，操作簡單的特點。

6.用例說明

本系統的設計目標是能夠對大型企業員工的基本信息和工資信息進行添加和修改，根據個人信息將工資分為職務工資，職稱工資和其他工資。能夠調整工資標準和員工信息，也能夠調整其他工資項目，根據需要對教職員工基本信息和工資信息的查詢，本系統能夠生成各個月的工資表，能夠打印報表方便保存和管理，還包括對系統的一些基本操作功能，比如為完善系統管理功能，增加工資系統用戶管理功能，系統應該包括系統用戶數據的添加，修改和刪除。員工為系統普通用戶，只能運行系統個人工資查詢功能；系統管理員則能運行系統所有功能，從而有效保證系統數據的安全性，系統應該具有簡單，易用，小巧，經典的特色，應該能夠對企業工資管理進行優化，使其系統化，高效化，智能化。并保證工資管理的準確性，簡易性，為企業財務人員提供便利。

7．系統性能需求分析：

7．1 性能需求

此工資管理系統對工資數據精度的計算能在默認情況之下精確到小數點后3位小數，即是精確到分的計算。但在用戶使用過程中，能自行根據實際情況進行小數計算精度的設定，最大能允許保留小數點后5位的精度。在時間特性上，當用戶發出命令請求時的服務器的響應時間、對數據更新處理、工資數據的查詢檢索等上，同樣要求系統響應時間不會超過0.5秒時間。系統支持多種操作系統的運行環境，多不同操作系統，不同文件格式的磁盤

上的數據均能實現信息的互通，及共享。當服務器移植到其他的系統平臺，如：Linux平臺下時，同樣能和其他的系統進行數據存取同步，不會出現系統之間互不兼容的情況，系統支持多系統之間的互連互通，系統有巨大的強健性。

7．2 運行需求

系統在進行數據的錄入、計算、統計的時候，能將數據精確到小數點后三位小數。系統接收到用戶的操作命令后（如：計算處理、查詢等），能迅速的響應其操作請求，響應時間不超過1秒。在同一時間，系統還提供支持至少10個客戶端進行同一個操作請求的響應。

系統可移植較強，在不同的平臺下運行，均不會影響系統的穩定性。同時，支持在客戶端安裝不同操作系統、瀏覽器版本，均不會影響系統的運行。

7．3安全需求

為保障系統數據的安全性，系統采用訪問控制策略，未授權者不能進入系統。同時，對不同級別的用戶授予不同的使用權限。在系統運行期間，如發生掉電尚未保存數據，或由于操作不當等原因導致系統重啟等，為保證數據的易恢復性，系統提供每隔30秒自動保存數據的機制，讓用戶的數據在發生意外時能最大程度上

得到恢復。同時，系統提供強大的容錯性能，當一臺服務器發生故障時，系統能自動切換到另外一臺服務器上，從而保障服務器能長時間的提供系統的運行支持。在輸入數據時，如果用戶輸入的數據不符合系統的要求，則系統自動提示錯誤信息，并要求用戶重新輸入，直到輸入完全正確時才允許進行下一步的操作。

7．4 系統界面需求

系統開發基于C#的開發，界面直觀、簡潔，人機交互性強。基于表單和彈出式窗口的數據錄入方式，菜單點擊的方式操作。用戶使用時，只要是按照格式和要求填入信息，系統在后臺響應用戶操作過程。讓用戶在最短時間里，不需要經過專門培訓，就可以輕松上手使用。

7．5 其他需求

數據不管是在企業內部之間傳輸，還是公司與分公司之間進行遠程數據傳輸時，防止數據被不法分析任意的修改和破壞，只有對信息解密的人員才能最終讀取數據信息。這樣，能 最大程度的防止數據在傳輸過程的安全保密性。

8.總結

在第一階段總體分析的基礎之上，我們小組進在系統需求過程中，主要是圍繞著系統數據流程圖和數據字典這兩個方面展開文檔的編輯工作。當然，在需求分析過程中，我們對系統的功能需求、性能需求、可靠性等方面做了進一步的描述，這為我們進行下一步設計階段的順利進行做好鋪墊的工作。

第五篇：博客系統需求分析報告

博客管理系統

1.系統需求分析

博客系統分前臺功能和后臺功能兩大部分。前臺主要供用戶注冊，瀏覽，后臺主要供管理員使用，管理員可以對用戶進行管理。

1.1前臺功能分析

博客系統前臺的用戶共分兩類：一類是注冊用戶(正式用戶)，這類用戶有基本的信息，可以對自己的信息進行查看與修改，；另一類用戶是游客（未注冊用戶），他們只能查看、瀏覽注冊用戶的信息。

游客：可以查看注冊用戶的信息。經過注冊可以成為注冊用戶。

注冊用戶：

1、登錄后對可以對個人信息進行查看和修改。

2)博客用戶通過前臺登錄后，對自己的空間進行管理，包括發布自己的網絡日志，分享視頻，分享音樂，邀請好友玩游戲，上傳照片，與相關人員進行交流和溝通以及刪除訪客發表的評論

3）博客用戶登錄后對自己的信息進行修改

非注冊用戶

1)游客通過注冊，登錄進入博客空間發表評論

2)游客不注冊，通過匿名方式對博客空間瀏覽文章，發表評論，查看文章發表人的所有文章

1.2后臺功能分析

博客系統后臺主要是供管理員使用的，管理員可對用戶進行添加、刪除、查詢及修改；對網站的新聞、公告進行管理。

管理員也可以具有不同的權限分為超級管理員和普通管理員，普通管理員具有以上權限，超級管理員除了可以具有以上所有功能外，還可以添加、刪除普通管理員。

2.數據庫設計

2.1數據庫概念結構設計

對博客系統進行分析后，抽象出有關的數據，按照現實世界的事物能作為屬性對待的，盡量作為屬性對待的原則。作為“屬性”，不能再具有需要描述的性質，“屬性”必須是不可分的數據項，不能包含其它的屬性；“屬性”不能與其它實體具有聯系，E-R圖中所表示的聯系是實體與實體的聯系。依照以上準則，可以確定哪些為實體，哪些為屬性，每個實體具有哪些屬性，實體之間存在何種聯系。經分析之后，該系統中包含的實體以及實體之間的聯系如下所示：

實體：管理員實體，用戶實體，文章類型實體、鏈接實體、留言實體、文章實體和評論實體，回復實體，視頻，照片，音樂、游客。

實體間存在的聯系

管理員和用戶實體之間存在多對多的聯系

博客用戶與鏈接之間存在多對多的消息聯系

博客用戶與留言之間多對多的回復聯系

文章類型與文章之間存在一對多的消息聯系

文章與評論之間存在一對多的消息聯系

用戶和游客之間存在一對多的聯系

用戶和視頻之間存在一對多的聯系

用戶和音樂之間存在一對多的聯系

用戶和照片之間存在一對多的聯系

實體的屬性：

留言（留言編號，網友昵稱，日期，標題，內容，個人主頁，回復）管理員（管理員，密碼，權限）博客用戶（用戶號，用戶名，密碼，真實姓名，性別，出生年月，郵箱，電話，單位，城市，地址，注冊時間，積分，用戶等級，安全問題，安全答案）

文章（文章編號，作者，標題，摘要，內容，發表日期，人氣，回復，類型編號，類型名稱，回復數）

文章類型（類型編號，類型名稱）

評論（編號，用戶昵稱，標題，內容，發表時間，文章編號）鏈接（鏈接編號，名稱，地址）

新聞（新聞號，標題，內容，時間）公告（公告號，標題，內容，時間）

視頻（視頻編號，標題，內容，時間）

音樂（音樂編號，標題，內容，時間，歌手名）

照片（照片編號，標題，內容，時間，大小）

游客（游客號，游客名）回復（用戶號，留言號，主題，內容，回復時間）

聯系的屬性：

實體之間關系的E-R圖如圖7-7所示。

2.2數據庫邏輯結構設計

根據系統E-R圖，把實體與實體之間的聯系轉換成關系模型，E-R圖中的每個實體轉換成一個關系模型，實體之間一對多的聯系合并到多方實體對應的關系模型中，把一方的碼與聯系的屬性納入到多方實體對應的關系模型中，為實體之間多對多的聯系創建一個新的關系模型，它包含雙方的碼以及聯系的屬性。具有相同碼的關系模型有些情況下可以考慮把它們合并。在轉換過程中應該按照關系規范化的理論，對關系模型進行優化，減少冗余和數據操作異常，提高查詢速度，在性能與范式之間作出權衡，一般所設計出的關系數據庫達到3NF就基本符合要求。按照

評論（編號，用戶昵稱，標題，內容，發表時間，文章編號）

文章（文章編號，作者，標題，摘要，內容，發表日期，人氣，回復，類型編號，類型名稱，回復數）

文章類型（類型編號，類型名稱）

博客用戶（用戶號，用戶名，密碼，真實姓名，性別，出生年月，郵箱，電話，單位，城市，地址，注冊時間，積分，用戶等級，安全問題，安全答案）

發表（用戶號，文章編號，發表日期）管理（管理員，用戶號，注冊號）留言（留言編號，用戶號，網友昵稱，日期，標題，內容，個人主頁，回復）回復（用戶號，留言編號，主題，內容，回復時間）

鏈接（鏈接編號，名稱，地址）

訪問（用戶號，游客號，訪問量,訪問時間）

公告（公告號，標題，內容，時間）

視頻（視頻編號，用戶號，標題，內容，時間）

音樂（音樂編號，用戶號，標題，內容，時間，歌手名）

照片（照片編號，用戶號，標題，內容，時間，大小）

游客（游客號，游客名）

3功能分析

在其博客管理系統上建立適當的視圖，索引，存儲過程和觸發器，因此我們主要從這四個方面來分析它的功能

A 視圖：視圖是一個虛擬表，其內容由查詢定義。同真實的表一樣，視圖包含一系列帶有名 稱的列和行數據。但是，視圖并不在數據庫中以存儲的數據集合形式存在。.創建某某表的視圖

2、利用cust_view視圖添加一條記錄數據

3、創建視圖sale_item_view，該視圖中包含訂單編號、訂貨日期、產品編號及數量。然后利用該視圖向表中插入數據

4刪除視圖中所有姓“王”的客戶數據

5有兩個基本表employee和sales，創建一個視圖，該視圖包含相同業務員的編號、姓名、訂單號、銷售總金額。

6將上述視圖中訂單號為10001的記錄的銷售金額改為60000。

B 索引：索引用來快速地尋找那些具有特定值的記錄。

普通索引，這是最基本的索引類型，而且它沒有唯一性之類的限制。普通索引可以通過以下幾種方式創建：

創建索引，例如CREATE INDEX <索引的名字> ON tablename(列的列表);

修改表，例如ALTER TABLE tablename ADD INDEX [索引的名字](列的列表);

創建表的時候指定索引，例如CREATE TABLE tablename([...], INDEX [索引的名字](列的列表));

唯一性索引，這種索引和前面的“普通索引”基本相同，但有一個區別：索引列的所有值都只能出現一次，即必須唯一。唯一性索引可以用以下幾種方式創建：

創建索引，例如CREATE UNIQUE INDEX <索引的名字> ON tablename(列的列表);修改表，例如ALTER TABLE tablename ADD UNIQUE [索引的名字](列的列表);

創建表的時候指定索引，例如CREATE TABLE tablename([...], UNIQUE [索引的名字](列的列表));

主鍵：主鍵是一種唯一性索引，但它必須指定為“PRIMARY KEY”。如果你曾經用過AUTO_INCREMENT類型的列，你可能已經熟悉主鍵之類的概念了。

主鍵一般在創建表的時候指定，例如“CREATE TABLE tablename([...], PRIMARY KEY(列的列表));”。但是，我們也可以通過修改表的方式加入主鍵，例如“ALTER TABLE tablename ADD PRIMARY KEY(列的列表);”。每個表只能有一個主鍵。

3存儲過程: 一組為了完成特定功能的SQL 語句集，經編譯后存儲在數據庫中，用戶通過指定存儲過程的名字并給出參數（如果該存儲過程帶有參數）來執行它。

1、利用存儲過程，給employee表添加一條業務部門員工的信息。

2、利用存儲過程從employee、sales、customer表的連接中返回所有業務員的姓名、客戶姓名、銷售金額。

3、創建帶一個輸入參數的存儲過程，實現按員工姓名進行模糊查找，查找員工編號、訂單編號、銷售金額。

4、創建帶兩個輸入參數的存儲過程，查找姓“李”并且職稱為“職員”的員工的員工編號、訂單編號、銷售金額。

3、利用存儲過程計算出訂單編號為10003的訂單的銷售金額。（帶一輸入參數和一輸出參

數）（提示：sales表中的tot_amt應該等于sale_item表中的同一張訂單的不同銷售產品的qty*unit_price之和）

4、創建一存儲過程，根據給出的職稱，返回該職稱的所有員工的平均工資。（帶一輸入參

數和返回值）

4觸發器觸發器對表進行插入、更新、刪除的時候會自動執行的特殊存儲過程。觸發器一般用在check約束更加復雜的約束上面。觸發器和普通的存儲過程的區別是：觸發器是當對某一個表進行操作。諸如：update、insert、delete這些操作的時候，系統會自動調用執行該表上對應的觸發器。SQL Server 2005中觸發器可以分為兩類：DML觸發器和DDL觸發器，其中DDL觸發器它們會影響多種數據定義語言語句而激發，這些語句有create、alter、drop語句。

1、針對employee表寫一個DELETE觸發器，顯示刪除的員工人數。

2、針對employee表寫一個UPDATE觸發器，限制每次工資額的變動不能超過原工資的20%。

3、定義一個觸發器，保證新添加的員工的工資不能超過5000元

4、對sale_item表創建一個觸發器，當插入一條銷售明細記錄時，如果該記錄的產品數量超過5，則顯示“歡迎成為本公司的VIP會員！”

5、針對customer表，定義一觸發器用來保證參照完整性

6、針對sales表，定義一觸發器保證參照完整性(參照customer表)

7.針對employee表，定義一觸發器用來保證實體完整性

8，在customer表上創建一觸發器，用來實現級聯刪除

9、定義一觸發器，保證新添加的員工的工資不能超過5000元

10、創建一個觸發器，只能接受女員工

11，、寫一個允許用戶一次只刪除一條員工記錄的觸發器。