健身場館信息管理系統(tǒng)數(shù)據(jù)庫設計_(3).doc

健身場館信息管理系統(tǒng)數(shù)據(jù)庫設計健身場館信息管理系統(tǒng)數(shù)據(jù)庫設計學院：軟件學院專業(yè)：軟件工程年級： 2010級姓名： 杜娟學號：1291410067版本變更記錄版本號修改人修改時間備注1杜娟2012.05.052杜娟2012.05.143杜娟2012.05.234杜娟2012.06.04目錄1 需求分析21.1 編寫目的21.2 項目背景21.3 業(yè)務流程31.4 系統(tǒng)功能51.4.1總體系統(tǒng)功能圖如下：51.4.2 會員管理功能圖51.4.3 員工管理功能圖61.4.4 健身房管理功能圖61.4.5 會員卡管理功能圖71.4.6 統(tǒng)計功能圖71.5 數(shù)據(jù)庫流圖81.6 數(shù)據(jù)字典102 概念結構設計122.1分e-r圖122.2總er圖133 邏輯結構設計144物理結構設計145 數(shù)據(jù)庫邏輯設計原則175.1命名規(guī)范175.1.1表屬性規(guī)范185.1.2 索引195.1.3 視圖195.1.4 存儲過程195.1.5 觸發(fā)器195.1.5序列195.1.7 變量195.2模式規(guī)范化205.3表設計205.3.1表屬性規(guī)范205.4 視圖設計215.5 表分區(qū)設計215.6索引設計225.7 sql編寫225.7.1 字符類型數(shù)據(jù)225.7.2 復雜sql225.7.3 insert語句225.7.4 高效性225.7.5 完整性236 開發(fā)環(huán)境236.1 硬件接口236.2 軟件接口231 需求分析1.1 編寫目的此健身房信息管理系統(tǒng)數(shù)據(jù)庫設計是為了說明健身房信息管理系統(tǒng)的數(shù)據(jù)庫設計以及其結構情況，用于開發(fā)人員進行項目的設計與實現(xiàn)，同時也為后續(xù)的數(shù)據(jù)庫維護工作提供了良好的使用說明，更重要的是可以作為未來系統(tǒng)升級時的重要參考資料。1.2 項目背景伴隨著科學技術的飛速發(fā)展，計算機在業(yè)務管理應用中的普及度也越來越高，利用計算機實現(xiàn)健身房管理是勢在必行的。對于大中型健身房來說，合理利用計算機支持企業(yè)高效率的完成日常事務，是適應現(xiàn)代管理制度需求的必要條件，同樣，這也適用于小型健身房企業(yè)。計算機管理所無法比擬的優(yōu)點是檢索速度快、可靠性高、存儲容量大、保密性好、成本低等。20世紀末，健身行業(yè)開始走入中國。作為一種新型的健康消費方式，他給中國人帶來新鮮和刺激的同時，也成為中國經(jīng)濟發(fā)展的一個增長點，尤其受到民營資本的青睞。由于健身行業(yè)與商業(yè)零售業(yè)不同，他是提高民族素質(zhì)不可或缺的一個產(chǎn)業(yè)，所以國家政策也在不斷加大扶持力度。雖然說相對于美國健身行業(yè)60年的發(fā)展史，中國的健身行還處于初步發(fā)展時期，但此時，他卻以強勁的發(fā)展勢頭為中國的健康產(chǎn)業(yè)開辟了一條新的領域，并給中國健身市場帶來了新鮮的活力和極大的變化。據(jù)統(tǒng)計，目前全國健身房每年以1000家的速度遞增。除了中體倍力具有國營北京外，其余幾乎全是民營資本，也就是說民營資本在整個健身房產(chǎn)業(yè)占了90%的份額。中國的健身市場隨著市場的優(yōu)勝劣汰會更趨于合理。隨著健康生活主題的提倡，人們會更加關注生活的質(zhì)量和身體的健康，所以健身行業(yè)的前景充滿了光明。健身行業(yè)企業(yè)面對前所未有的挑戰(zhàn)和機遇，是被動應付還是主動出擊，關鍵取決月企業(yè)的核心競爭力，而原始的管理經(jīng)營模式下，信息是不通暢的，遲緩的，經(jīng)過不斷的摸索和總結，越來越多的經(jīng)營管理者都已強烈的意識到，只有應用先進的信息技術，才能幫助企業(yè)獲得比過去更為持久、有效的市場競爭力，以應對市場的競爭和變革。在健身場館火爆的形式下，健身行業(yè)的現(xiàn)狀：隨著經(jīng)濟水平的提高，健身必然成為人們主要的生活方式之一，其市場潛力無可限量，健身行業(yè)可謂是“錢”途無量。但是在啟動時，又沒有一個標準化的管理方向。健身房管理不是簡單的租塊場地，擺些器材，請幾個教練就行了，他對專業(yè)的要求很高，對公司管理要求也很高。健身房管理的問題，是一個健身企業(yè)如火熱長遠發(fā)展、取得最大收益的問題。只有在正確的管理戰(zhàn)略方針的指導下，之后的戰(zhàn)術方法才能確保科學性、有效性和效益型。健身房作為健身服務企業(yè)，隨著自身規(guī)模的不斷擴大，客戶數(shù)量增多，出于更好的對客戶進行管理和服務，提高員工工作效率，降低管理成本等多方面的考慮，有必要通過現(xiàn)代化科技手段，建立完善的客戶自動化管理系統(tǒng)，以取代現(xiàn)有的手工操作，讓公司原有的電腦設備能夠更好的發(fā)揮作用，并通過自動化的客戶管理方法，提升健身房檔次，方便服務客戶，擴大企業(yè)規(guī)模。1.3 業(yè)務流程一個健身場館擁有若干個健身房，每個健身房可以擁有多種器材，每種器材的品種達上百種。健身館信息管理記錄了器材的分布狀況、購買日期以及維護狀態(tài)，能夠更好地管理器材。每個健身房的訓練項目不是固定的，教練也不固定，大多為外聘教練。每個訓練項目由不同的教練教授，每個教練只教授一種訓練項目。健身館需要辦理會員卡或者以訪客的身份登記之后，才可以進入，每個健身房收費不同，可以選擇只在健身房自由鍛煉，也可以選擇自費有教練指導的訓練項目。每個健身房有固定人員，負責管理或者清潔健身房。業(yè)務流程圖如下：（1）會員 圖1.3.1 會員業(yè)務流程圖（2） 管理員圖1.3.2 管理員業(yè)務流程圖1.4 系統(tǒng)功能對于客戶管理，健身房管理系統(tǒng)首先需要為每一位客戶建立盡可能詳細的客戶檔案，將客戶手中的會員卡重的會員資料和系統(tǒng)內(nèi)客戶資料統(tǒng)一起來?？蛻裘看蝸硐M，只要進行刷卡，系統(tǒng)就能查找客戶的健身歷史材料，并記錄下來客戶的健身時間，次數(shù)，有效期。客戶能夠方便的查詢自己健身的統(tǒng)計資料，以便作出相應的健身計劃調(diào)整。對于老客戶繼續(xù)參加健身的，系統(tǒng)可以輕易識別。1.4.1總體系統(tǒng)功能圖如下：圖1.4.1 總體系統(tǒng)功能圖1.4.2 會員管理功能圖 會員的管理模塊為：會員信息管理，消費管理模塊。管理員可以對會員的信息和消費項目進行統(tǒng)計管理，便于對會員的管理。圖1.4.2 會員管理功能圖1.4.3 員工管理功能圖 員工管理模塊分為：考勤管理，工資管理?？记诠芾砑葘T工的工作時間進行考察并與員工的工資掛鉤。圖1.4.3 員工管理功能圖1.4.4 健身房管理功能圖 健身房管理模塊分為：項目編制，課程管理，上課管理。項目編制既對項目進行制定和刪除，課程管理既對項目的時間進行制定，上課管理即對健身房所進行的項目。圖1.4.4 健身項目管理功能圖1.4.5 會員卡管理功能圖 會員卡管理模塊分為：會員卡充值，會員卡辦理，會員卡補辦，會員卡掛失。圖1.4.5 會員卡管理功能圖1.4.6 統(tǒng)計功能圖 統(tǒng)計功能模塊分為：會員消費統(tǒng)計，員工業(yè)績統(tǒng)計，營業(yè)統(tǒng)計。通過三個板塊館主可以知道健身館的盈利虧損，對健身館進行一定的調(diào)整。圖1.4.6 統(tǒng)計管理功能圖1.5 數(shù)據(jù)庫流圖使用結構化分析方法，確定系統(tǒng)的數(shù)據(jù)主要是會員、會員卡、員工、教練和健身項目，對數(shù)據(jù)的操作主要有員工修改、會員卡修改、員工修改、教練修改、健身項目，可以確定系統(tǒng)的處理邏輯和流程，得到如下所示的系統(tǒng)數(shù)據(jù)流圖。圖1.5.1 健身場館第一層流程圖圖1.5.2 第二層數(shù)據(jù)流圖1圖1.5.3 第二層數(shù)據(jù)流圖225圖1.5.4 第二層數(shù)據(jù)流圖31.6 數(shù)據(jù)字典（1）數(shù)據(jù)項（以消費編號為例）數(shù)據(jù)項名：消費編號含義說明：唯一標識每個消費單別名：消費單編號類型：字符型長度：12取值含義：前四位標識消費的年份，五、六位標識消費的月份，七、八位標識消費的日期，后五位標識消費的編號。如20120516 00001表示在2012年5月16日消費了1號消費品。（2）數(shù)據(jù)結構數(shù)據(jù)結構名：消費單含義說明：是消費管理子系統(tǒng)的主體數(shù)據(jù)結構，定義了每張消費單的基本信息組成：消費編號，消費卡標號，消費年月，開始消費時間，結束消費時間，教練編號（3）數(shù)據(jù)流數(shù)據(jù)流名：消費單說明：顧客消費的最終結果（4）數(shù)據(jù)項（已消費編號為例）數(shù)據(jù)項名：消費編號含義說明：唯一標識每個消費單別名：消費單編號類型：字符型長度：13取值含義：前四位標識消費的年份，五、六位標識消費的月份，七、八位標識消費的日期，后五位標識消費的編號。與其他數(shù)據(jù)項的邏輯關系：前八位與消費年份相匹配（5）數(shù)據(jù)結構數(shù)據(jù)結構名：消費單含義說明：是消費管理子系統(tǒng)的主體數(shù)據(jù)結構，定義了每張消費單的基本信息組成：消費編號，消費卡標號，消費年月，開始消費時間，結束消費時間，教練編號（6）數(shù)據(jù)流數(shù)據(jù)流名：消費單說明：顧客消費的最終結果數(shù)據(jù)流來源：編過號的消費單數(shù)據(jù)流去向：確認組成：消費編號，消費卡標號，消費年月，開始消費時間，結束消費時間，教練編號（7）數(shù)據(jù)存儲數(shù)據(jù)存儲：消費單表說明：記錄消費的基本情況流入數(shù)據(jù)流：編過號的消費單流出數(shù)據(jù)流：確認組成：消費編號，消費卡標號，消費年月，開始消費時間，結束消費時間，教練編號存取方式：隨機存取2 概念結構設計2.1分e-r圖圖2.1.1 分e-r圖1圖2.1.2 分e-r圖2圖2.1.3 分e-r圖3 2.2總er圖圖2.2.1 總e-r圖3 邏輯結構設計關系模式：健身場館（健身場館編號，場館名稱，館主姓名，電話，地址，會員人數(shù)，教練人數(shù)，員工人數(shù)）健身房（健身房編號，健身房名稱，健身場館編號）教練（教練編號，教練姓名，性別，電話，職稱，工時，工資，健身項目編號）員工（員工編號，工作人員姓名，性別，電話，職稱，工時，工資，健身房編號）健身項目（健身項目編號，健身項目名稱，會員人數(shù)，教練人數(shù)，健身房編號）會員（會員編號，會員姓名，性別，電話，消費時間，會員等級，教練編號，健身項目編號）會員卡（會員卡編號，日期，會員編號）器材（器材編號，器材名稱,健身項目編號）消費單（消費單編號，消費時間，教練編號，會員姓名，健身房編號，健身項目編號）健身項目-會員（健身項目編號，會員編號，消費單編號）健身房-健身項目（健身房編號，健身項目編號，健身項目類別）教練-會員（教練編號，會員編號，健身項目編號）4物理結構設計 “健身場館”表結構字段名稱字段類型字段長度索引類型備注z_id整形10主鍵健身場館編號z_name字符8場館名稱z_pname字符8館主姓名z_phone字符10電話z_adress字符40地址z_num整形20會員人數(shù)l_num整形20教練人數(shù)y_num整形20員工人數(shù)表1表2“健身房”表結構字段名稱字段類型字段長度索引類型備注j_id整形10主鍵健身房編號j_name字符8健身房名稱z_id字符10外鍵健身場館編號表3“教練”表結構字段名稱字段類型字段長度索引類型備注l_id整形10主鍵教練編號l_name字符8教練姓名l_sex字符5性別l_phone字符10電話l_job字符20職稱l_time字符30工時l_money字符30工資p_id整形30外鍵健身項目編號表4“員工”表結構字段名稱字段類型字段長度索引類型備注y_id整形10主鍵員工編號y_name字符8工作人員姓名y_sex字符5性別y_phone字符10電話y_job字符20職稱y_time字符30工時y_money整形30工資j_id整形10外鍵健身房編號表5“健身項目”表結構字段名稱字段類型字段長度索引類型備注p_id整形10主鍵健身項目編號p_name字符8健身項目名稱h_num字符20會員人數(shù)l_num字符20教練人數(shù)j_id字符10外鍵健身房編號表6“會員”表結構字段名稱字段類型字段長度索引類型備注h_id整形10主鍵會員編號h_name字符8會員姓名h_sex字符5性別h_phone字符10電話h_time字符20消費時間h_grade整形30會員等級j_id整形30外鍵教練編號p_id整形30外鍵健身項目編號表7“會員卡”表結構字段名稱字段類型字段長度索引類型備注k_id整形10主鍵會員卡編號k_date日期8日期h_id整形20外鍵會員編號表8“器材”表結構字段名稱字段類型字段長度索引類型備注q_id整形10主鍵器材編號q_name字符8器材名稱p_id整形10外鍵健身項目編號表9“統(tǒng)計”表結構字段名稱字段類型字段長度索引類型備注t_id整形10主鍵統(tǒng)計編號t_date時間8統(tǒng)計時間t_huiyuan雙精度10會員消費額t_yuangong字符型20員工業(yè)績值t_ymoney雙精度20員工工資t_all雙精度30總體營業(yè)額5 數(shù)據(jù)庫邏輯設計原則5.1命名規(guī)范命名應該使用英文單詞，避免使用拼音，特別不應該使用拼音簡寫。命名不允許使用中文或者特殊字符。英文單詞使用對象本身意義相對或相近的單詞。選擇最簡單或最通用的單詞。不能使用毫不相干的單詞來命名。當一個單詞不能表達對象含義時，用詞組組合，如果組合太長時，采用用簡或縮寫，縮寫要基本能表達原單詞的意義。表名、字段名、視圖名長度應限制在20個字符內(nèi)(含前綴)。命名不允許使用sql保留字。5.1.1表屬性規(guī)范表名采用camel樣式命名，命名格式為表名。示例：tickettype表名以英文單數(shù)命名，不采用復數(shù)方便更好的使用orm工具生成符合編程規(guī)范的代碼。示例：使用product而不是products字段名字段名稱命名采用英文單詞或縮寫，英文單詞只來自于具體業(yè)務定義，盡量表達清楚含義。同一個字段名在一個數(shù)據(jù)庫中只能代表一個意思。不同的表用于相同內(nèi)容的字段應該采用同樣的名稱，字段類型定義。命名格式為大寫字母_英文單詞。示例：h_name字段名稱前不要加上表名前綴,比如用戶表user包含一個用戶名字段,建議采用name,不建議采用h_name形式。 對于表示字符型的字段數(shù)據(jù)類型建議使用varchar,(oracle為varchar2)，而不是char，建議數(shù)據(jù)類型盡量采用如下幾基本類型。ms sql數(shù)據(jù)類型oracle數(shù)據(jù)類型字符varcharvarchar2整數(shù)intnumber(10)帶小數(shù)的數(shù)字decimal (p , s )number (p , s )日期datetimedate布爾型bitnumber(1)二進制數(shù)據(jù)varbinary(max)blob文本數(shù)據(jù)varchar(max)clob如無特別需要，避免使用大對象數(shù)據(jù)庫類型，如oracle的blob，clob等，sql server的 varchar(max) 和 varbinary(max)等。5.1.2 索引前綴為ix+索引名稱。示例：ixh_id5.1.3 視圖視圖名稱采用pascal樣式命名（以下的對象命名樣式一樣）。命名格式為view+ 視圖名稱。示例：viewstation5.1.4 存儲過程前綴為proc(為了兼容sql server, oracle的函數(shù)前綴也采用proc)。按業(yè)務操作命名存儲過程。5.1.5 觸發(fā)器前綴為trig 。命名格式為 前綴 + 表名 + 觸發(fā)器名+操作方式(insert、update等)。5.1.5序列前綴為seq 。按業(yè)務屬性命名。(序列為oracle特有的對象類型)。5.1.7 變量普通變量前綴為var 。 存放字符、數(shù)字、日期型等變量。示例：varname游標變量前綴為cur 。存放游標記錄集。記錄型變量前綴為rec。 存放記錄型數(shù)據(jù)。表類型變量前綴為tab 。 存放表類型數(shù)據(jù)。5.2模式規(guī)范化如無性能上的必須原因，應該使用關系數(shù)據(jù)庫理論，達到較高的范式，避免數(shù)據(jù)冗余,但是如果在數(shù)據(jù)量上與性能上無特別要求，考慮到實現(xiàn)的方便性可以有適當?shù)臄?shù)據(jù)冗余，但基本上要達到3nf。5.3表設計每個表在創(chuàng)建時候，必須指定所在的表空間，不要采用默認表空間以防止表建立在系統(tǒng)表空間上導致性能問題。對于事務比較頻繁的數(shù)據(jù)表，必須存放在用戶自己創(chuàng)建的表空間中（對oracle數(shù)據(jù)庫而言）。表的大小對查詢的速度影響較大。有時為了提高數(shù)據(jù)庫性能，把常用的屬性和很少使用的屬性分成兩個表，可提高常用查詢的速度。5.3.1表屬性規(guī)范主鍵外鍵關聯(lián)對于關聯(lián)兩個表的字段，一般應該分別建立主鍵、外鍵。實際是否建立外鍵，根據(jù)對數(shù)據(jù)完整性的要求決定。為了提高性能，對于數(shù)據(jù)量比較大的要求對外健建立索引。對于有要求級聯(lián)刪除屬性的外鍵，必須指定on delete cascade 或通過對應程序來實現(xiàn)。null值采用camel樣式命名，命名格式為表名。check條件 對于字段有檢查性約束，要求指定check規(guī)則。觸發(fā)器 觸發(fā)器是一種特殊的存儲過程，通過數(shù)據(jù)表的dml操作而觸發(fā)執(zhí)行，起作用是為確保數(shù)據(jù)的完整性和一致性不被破壞而創(chuàng)建，實現(xiàn)數(shù)據(jù)的完整約束。觸發(fā)器事務屬性的選擇時候，對表操作的事務屬性必須與應用程序事務屬性保持一致，以避免死鎖發(fā)生。盡量避免使用觸發(fā)器。5.4 視圖設計每個表在創(chuàng)建時候，必須指定所在的表空間，不要采用默認表空間以防止表建立在系統(tǒng)表空間上導致性能問題。對于事務比較頻繁的數(shù)據(jù)表，必須存放在用戶自己創(chuàng)建的表空間中（對oracle數(shù)據(jù)庫而言）。視圖是虛擬的數(shù)據(jù)庫表，在使用時要遵循以下原則：（1）從一個或多個庫表中查詢部分數(shù)據(jù)項；（2）為簡化查詢，將復雜的檢索或字查詢通過視圖實現(xiàn)；（3）提高數(shù)據(jù)的安全性，只將需要查看的數(shù)據(jù)信息顯示給權限有限的人員；（4）視圖中盡量避免嵌套使用視圖；除特殊需要，避免類似select * from tablename 而沒有檢索條件的視圖；5.5 表分區(qū)設計當表數(shù)據(jù)是分段的數(shù)據(jù)，且比較多，查詢時明顯感覺到數(shù)據(jù)很慢時，可考慮創(chuàng)建分區(qū)表。分區(qū)功能通過改善可管理性、性能和可用性，從而為各式應用程序帶來了極大的好處。通常，分區(qū)可以使某些查詢以及維護操作的性能大大提高。此外，分區(qū)還可以極大簡化常見的管理任務。比如，表數(shù)據(jù)是以年為分隔，對于當年的數(shù)據(jù)的操作需要添加、修改、刪除和查詢，而對于往年的數(shù)據(jù)，幾乎不需要操作，或者操作往往只限于查詢，那可考慮使用分區(qū)表。5.6索引設計對于查詢中需要作為查詢條件的字段，可以考慮建立索引。最終根據(jù)性能的需要決定是否建立索引。對于復合索引，索引字段順序比較關鍵，把查詢頻率比較高的字段排在索引組合的最前面。對于簇集索引(clustered index)和非簇集索引(nonclustered index)的選擇問題，一般在經(jīng)常排