博客系統的設計與開發畢業論文(編輯修改稿)

　

【文章內容簡介】 定義會員信息：昵稱：會員的網名描述：描述會員的基本信息定義：會員=用戶帳號+用戶姓名+用戶密碼+用戶職業+用戶郵箱+用戶生日+用戶個性簽名位置：用戶注冊申請表，用戶信息表管理員信息：名稱：管理員姓名描述：系統后臺工作人員定義：管理員=管理員編號+管理員帳號+管理員密碼+管理員權限位置：管理員信息表瀏覽信息：名稱：用戶瀏覽請求描述：每位已登錄會員的瀏覽請求定義：瀏覽信息=鏈接網址+發布人+內容位置：瀏覽信息表評論信息：名稱：評論信息描述：記錄已登錄會員的評論信息定義：會員評論信息=評論人+評論時間+評論內容位置：評論信息表第三章 總體設計 總體設計的任務 總體設計的基本目的就是回答“概括的說，系統應該如何實現？”這個問題，因此總體設計又稱為概要設計或是初步設計。通過這個階段工作將劃分組成系統的物理元素——程序、文件、數據庫、人工過程和文檔等等。總體設計的另一項重要任務是設計微博軟件的結構，也就是要確定系統中每個程序是由哪些模塊組成的，以及這些模塊相互之間的關系。 功能模塊圖 系統總體功能圖微博系統刪除編輯系統管理公告管理留言管理查看和刪除會員資源管理會員管理退出用戶登錄密碼找回選擇話題個人設置廣播收聽找人評論欄目管理查看和刪除廣播文件管理添加公告編輯和刪除公告對會員上鎖設置前臺管理員網站信息設置系統管理員管理系統標簽管理友情鏈接管理查看和刪除留言 系統功能模塊描述1. 用戶登錄模塊該模塊是我們微博系統的首界面，進入該系統時，需要先注冊一個用戶名，然后登錄后進行以后的操作，用戶名唯一。當然，此登陸界面也分為普通用戶登錄以及系統管理員用戶登錄，上述步驟為普通用戶登錄，而系統管理員登陸則有固定的一個系統管理員帳號，登錄后進入系統管理模塊進行對微博系統的維護以及更新。普通用戶登錄，可以在自己的微博中記錄隨時隨地發生在自己的身邊有趣的事情，可以以很多種方式發布廣播等。2. 微博應用設置模塊微博應用設置模塊主要分為四個部分：微博廣播發表功能、微博評論、微博轉發以及微博收藏。微博發表功能：注冊用戶登錄以后進入個人主頁面，然后可以在個人主頁或者在廣播大廳中發表屬于自己的微博。微博評論功能：注冊用戶登錄以后進入個人主頁面，然后可以在廣播大廳模塊中對注冊用戶所關注的用戶進行評論以及回復。 微博轉發功能：注冊用戶登錄以后進入個人主頁面，然后可以在廣播大廳模塊中對注冊用戶關注的用戶所發的微博進行轉發，從而變為自己的微博。微博收藏功能：注冊用戶登錄以后進入個人主頁面，然后可以在廣播大廳模塊中對注冊用戶關注的用戶所發的微博進行收藏，從而使所收藏的微博進入注冊用戶的收藏夾中。3. 友情鏈接模塊友情鏈接模塊主要是注冊用戶登錄進入個人主頁面后尋找自己好友的場所，其內容就是當注冊用戶在其他用戶中點擊了“加粉”之后，該用戶就已經成為了注冊用戶的粉絲，同理如果其他用戶對注冊用戶點擊了“加粉”，那么注冊用戶也成為了其他用戶的粉絲。4. 廣播大廳模塊廣播大廳模塊就是一個集中注冊用戶以及注冊用戶的粉絲所發表的微博的模塊，在廣播大廳模塊中對注冊用戶以及注冊用戶的粉絲的個人主頁進行實時更新，同時還可以對其進行評論、回復、轉發以及收藏微博操作等等。5. 系統管理模塊系統管理模塊主要是系統管理員進行修改以及更新的場所，其功能包含：會員管理，資源管理，系統管理，公告管理，留言管理功能。下面我們將一一介紹。：通過設置，可以把會員設置為前臺管理員，也可以對其進行上鎖和刪除的操作。：管理員可以查看會員所發表的任何內容的廣播，對這些資源進行備份和刪除。：設置網頁頁面顯示的主題，網頁的布局等。：發布公告，告訴會員需要注意什么；也可對公告進行編輯修改和刪除。：查看會員的各種留言，也可以對其進行刪除。 數據庫設計 概念結構設計在概念設計階段中，從用戶的角度看待數據及處理要求和約束，產生一個反映用戶觀點的概念模式。然后再把概念模式轉換成邏輯模式。將概念設計從設計過程中獨立開來，使各階段的任務相對單一化，設計復雜程度大大降低，不受特定DBMS的限制。利用ER方法進行數據庫的概念設計，可分成三步進行：首先設計局部ER模式，然后把各局部ER模式綜合成一個全局模式，最后對全局ER模式進行優化，得到最終的模式，即概念模式。 設計局部ER模式實體和屬性的定義1） 管理員用戶類別（用戶名，密碼，權限，注冊時間等）管理員用戶用戶名密碼權限注冊時間……2）注冊用戶類別（用戶名，密碼，電話，昵稱，注冊時間等）注冊用戶用戶名密碼昵稱注冊時間……2） 站內廣播（名稱，類別，添加時間，發布人，發布人昵稱，是否主帖） 站內廣播廣播名稱廣播類別是否置頂廣播發布人廣播添加時間3） 友情鏈接板塊（名稱，編號，簡介，添加時間）友情鏈接板塊鏈接添加時間鏈接網址鏈接編號鏈接名稱4）評論（標題，內容，添加時間，類別等）評論評論類別評論日期評論內容評論標題實體關系定義：ER模型的“聯系”用于刻畫實體之間的關聯。一種完整的方式是對局部結構中任意兩個實體類型，依據需求分析的結果，考察局部結構中任意兩個實體類型之間是否存在聯系。若有聯系，進一步確定是1:1:N、M:N的關系。還要考察一個實體類型內部是否存在聯系，兩個實體類型之間是否存在聯系，多個實體類型之間是否存在聯系，等等 設計全局ER模式所有局部ER模式都設計好了后，接下來就是把它們綜合成單一的全局概念結構。全局概念結構不僅要支持所有局部ER模式，而且必須合理地表示一個完整、一致的數據庫概念結構。1) 確定公共實體類型 為了給多個局部ER模式的合并提供開始合并的基礎，首先要確定各局 部結構中的公共實體類型。在這一步中我們僅根據實體類型名和鍵來認定公共實體類型。一般把同名實體類型作為公共實體類型的一類候選，把具有相同鍵的實體類型作為公共實體類型的另一類候選。 2) 局部ER模式的合并 合并的原則是：首先進行兩兩合并；先合并那些現實世界中有聯系的局部結構；合并從公共實體類型開始，最后再加入獨立的局部結構。 3) 消除沖突 沖突分為三類：屬性沖突、結構沖突、命名沖突。 設計全局ER模式的目的不在于把若干局部ER模式形式上合并為一個ER模式，而在于消除沖突，使之成為能夠被所有用戶共同理解和接受的同一的概念模型。 4) 全局ER模式的優化 在得到全局ER模式后，為了提高數據庫系統的效率，還應進一步依據處理需求對ER模式進行優化。一個好的全局ER模式，除能準確、全面地反映用戶功能需求外，還應滿足下列條件：實體類型的個數要盡可能的少；實體類型所含屬性個數盡可能少；實體類型間聯系無冗余 微博的全局ER模式如圖所示：1N1N1N1N11博主郵箱帳號密碼昵稱用戶名稱注冊時間型管理員用戶名密碼權限微博廣播發布人評論類別我的微博名稱主頁評論友情鏈接廣播廣播名稱鏈接名稱鏈接地址鏈接編號評論內容評論標題置頂包含發表發布時間1評論日期包含鏈接添加時間設置 數據總體ER圖 邏輯結構設計根據對需求得到的數據結構進行分析，按數據輸入輸出的要求，確定表和表間的關系，并進行驗證、調整、改善、查詢、瀏覽等，使其能夠實現用戶對數據和功能的要求。在邏輯設計中，把需求分析中所得到的ER圖轉換為與數據模型相符合的邏輯結果。以ER圖為主要依據，設計出系統相關的整體邏輯結構（即相關關系模式）。根據分析確定系統要設置如下表：1．用戶信息表（用戶編號，用戶名，昵稱，帳號，密碼，年齡，郵箱，地址，性別，行業，個性資料）2．空間信息表（空間ID，空間狀態，名稱，描述，瀏覽數，注冊時間，日志統計數，類型）3．廣播信息表（廣播ID，廣播標題，來源，格式，發布時間，發布人，類型，）4．評論反饋信息表（評論ID，標題，評論人昵稱，評論時間，評論文章，評論文章的作者，）5．系統分類信息表（分類ID，類型，名稱）6．鏈接信息表（鏈接ID，類型，名稱，網址，添加日期，修改日期，鏈接ip，格式）7．存儲信息表（存儲ID，來源，標題，名稱，存儲日期，位置，資源空間大小，格式） 物理設計下面是微博系統所有表的結構：User用戶表結構如表3—1所示：表3—1 users 用戶表字段類型是否為空是否為主鍵描述User_IDint否是用戶IDUser_CoolNamevarchar(50)否否用戶昵稱User_Namevarchar(50)否否用戶名User_Emailvarchar(50)否否用戶郵箱User_Passvarchar(50)否否用戶密碼User_Photovarchar(50)否否用戶頭像User_Addressvarchar(50)否否用戶地址User_PostCodeint是否郵編User_Telint是否用戶電話User_Sexvarchar(50)否否性別User_Birthdayint是否用戶生日User_HomeWebvarchar(50)否否用戶微博IP網址User_Demovarchar(50)否否微博標題User_SignInDatedatetime否否最近登錄時間 Main page空間信息表結構如表3—2所示：表3—2Main page空間信息表字段類型是否為空是否為主鍵描述Uidint否是用戶IDMainnamevarchar(50)否否微博名稱Descriptionvarchar(250)是否微博描述Viewsint否否微博瀏覽數Lastpostint否否最近發表日志時間Addtimeint否否添加信息時間Message廣播信息表機構如表3—3所示：表3—3Message廣播信息表字段類型是否為空是否為主鍵描述Msg_IDint否是idMsg_Titlevarchar(20)否否標題Msg_Contenttext是否評論Msg_OrderByint否否排序Msg_Sourcevarchar(20)否否來源Msg_AddDatedatetime否否添加信息時間Msg_ModifyTimetext是否修改信息Feedback評論反饋信息表機構如表3—4所示：表3—4Feedback評論反饋信息表字段類型是否為空是否為主鍵描述IDint否是評論idMesNamevarchar(20)否否評論名Contenttext是否評論內容MetUsertypeVarchar(20)否否類型Linkmanvarchar否否評論發布者AddTimeint否否評論發布時間ReplyContenttext是否回應評論內容ReplyTimedatetime否否回應日期ViewFlagint否否視圖標號Uidint否否評論發布者idTag系統分類信息表如表3—5所示：表3—5Tag系統分類信息表字段類型是否為空是否為主鍵描述tag_idInt否是分類idtag_TypeIDenum否否分類類型tag_namevarchar(20)否否分類名稱tag_IsUsevarchar(20)否否發布tag_OrderByint否否排序tag_IPvarchar(15)否否分類ipLink鏈接信息表如表3—6所示：表3—6Link鏈接信息表字段類型是否為空是否為主鍵描述Link_IDint否是idLink_Namevarchar(20)否否名稱Link_Urlvarchar(40)否否網址Link_Typevarchar(50)否否鏈接圖片Link_OpenTypeenum否否打開類型Link_OrderByint否否排序Link_AddTimeint否否鏈接添加時間Link_ModifyTimeint否否修改鏈接時間Link_IPvarchar(15)否否鏈接IPSource存儲信息表如表3—7所示：表3—