導言：作為寫作愛好者，不可錯過為您精心挑選的10篇概念結構設計原則，它們將為您的寫作提供全新的視角，我們衷心期待您的閱讀，并希望這些內容能為您提供靈感和參考。

篇1

一、建筑結構抗震概念設計

概念設計（ConceptualDesign）屬初步設計階段。國內外歷次大地震及風災的經驗教訓使人們越來越認識到建筑物概念設計階段中結構概念設計的重要性，尤其是結構抗震概念設計對結構的抗震性能將起到決定性的作用。

1.1 結構的規則性

簡單的平、立面圖形是方形或圓形的，而復雜的圖形是有凹角的，容易造成有應力集中或變形集中的薄弱環節。抗震設計能做到平、立面簡單當然是較理想的，但實際工作中，建筑的平、立面出現凹角是經常的，比較現實的做法是要求建筑體型規則一些，規則的意思是有一定的對抗震有利的要求，也允許帶有一定限度區的復雜性質。區分規則與不規則的界限很難劃定。我國的高層建筑結構設計規程給出了一些劃分原則：

1）豎向規則指沿建筑物豎向的建筑造型和結構布置比較均勻，剛度、承載力和傳力途徑沒有太大變化，從而可以限制結構在某一層或極少數幾層出現敏感的薄弱部位。這些部位一旦出現，將產生過大的應力集中或過大的變形，從而容易導致結構過早的坍塌。

2）平面規則指建筑平面比較規則，平面內結構布置比較均勻，使建筑物的分布質量和地震慣性力能以比較短和直接的途徑進行傳遞，并使質量分布和結構剛度協調，以限制質量和剛度間的偏心。平面規則，布置均勻有利于防止薄弱的子結構過早破壞、倒塌，能使地震作用在各個子結構間重分布，增加結構的贅余度數量，發揮整個結構耗散地震能量的作用。

3）設計時可在以下幾個方面進行處理：盡可能滿足建筑豎向均勻性。均勻性問題存在于建筑的豎向布置中，無論是幾何圖形還是樓層剛度變化，其規則勻稱應該是立面設計中優先考慮的。布置不均勻的結果產生了剛度、強度的突變，引起豎向的應力集中或變形集中，以致在中小型地震中損壞，在大震時倒塌。但是，要使結構做到完全均勻性，在實際設計中也有一定的困難。均勻性問題表現如下：其一，豎向收進問題。豎向收進是常見的建筑處理方式，結構上產生的問題是在凹角處應力集中。由于房屋的不同部分其振動特征不同，所以在收進處的橫隔（樓蓋或屋面板）產生應力突變，為此，在抗震設計時，可考慮幾種處理方法：限制收進尺寸；當設置防震縫有利時，可設縫把復雜的體型劃分成若干簡單、規則的獨立單元，分割后的建筑體型應是均衡的，不致過分細高；不設縫時應進行較細致的空間動力分析；對剛度突變的構件采取加強措施。其二，柔性層框架。建筑上往往因底層需要開敞或任意層需要大的空間，使結構處于上下不連續狀況，產生豎向剛度突變，特別是柔性底層建筑，在歷次大地震中，震害都很普遍，甚至完全倒塌。分析研究表明，這類構件的應力和變形集中是非常嚴重的，所以在抗震設計時應力求避免，底層應盡可能配置具有相當強韌性的構件以承受大的側移。其三，同一層間的柱子剛度不同。建筑上由于空間需要或由于藝術構思，使得同一層間柱子的剛度差異較大，通常在剛性較大的柱子上產生較大的內力。為此設計時宜從抗震的角度重新安排結構系統，以使剛度盡量均衡。

1.2 結構的剛度和延性

在地震作用下，一味地追求結構的強度并不可取，結構的延性是非常重要的，結構主要靠延性來抵抗較大地震作用下的非彈性變形。結構水平方向的剛度應能使結構抵抗任何方向的水平地震作用，并有助于減少結構的變形。結構還應具有足夠的抗扭剛度和抵抗扭轉振動的能力。由于現有的抗震設計計算不考慮地震地面運動的扭轉分量，所以在概念設計中還應注意提高結構的抗扭剛度和抵抗扭轉振動的能力。結構的延性是指結構吸收地震能量后的變形能力。延性好的結構能吸收較多的地震能量，能經受住較大的變形。增加結構的延性，能削弱地震反應，提高結構抵抗地震的能力。結構對延性的需求與地震力降低系數是相適應的。地震力降低系數的大小決定了設計地震力取值的大小，從而決定了對延性要求的大小。用于承載力設計的地震作用可以取到小震水平，當更大的地震來臨時，則靠結構的延性去抵抗。所以，我們并不采用設防烈度地震作用力來進行結構承載力設計，而需要把設防烈度地震力降低一個系數，稱為地震力降低系數。

地震力降低系數對設防烈度地震作用的整體降低實際上決定了結構的屈服水準和對結構延性需求的大小。地震力降低系數取得越大，設計地震作用就取得越小；地震力降低系數取得越小，設計地震作用就取得越大。在同一個設防烈度下，地震力降低系數取為中等，地震作用也為中等，因而對延性提出的要求也為中等。這樣，地震力降低系數的大小實際上就決定了設計地震力取值的大小，從而決定了對延性要求的大小。

二、 建筑結構選型的原則

2.1影響建筑結構選型的因素

作為單體的建筑物具有統計性差、影響因素多的特點，并且其各因素間的相互作用較大，具體表現在結構方案上不僅僅取決于力學分析，而是應該從環境、經濟以及安全使用等因素進行綜合考慮，因此該種綜合決策十分復雜，在選型過程中應分清因素的主次，同時應考慮到這些因素具有層次性和耦連性以及各因素對選型的影響具有一定的模糊性等，一般在建筑選型過程中除了對建筑美學考慮外其他方面主要應考慮：環境條件指場地條件、風壓、設防烈度等；方案特征、指建筑高度、高寬比、長寬比以及建筑的平面和立面體型等。

2.2結構選型的原則

安全性。各類建筑結構選型及平面、豎向布置應符合規范要求，不可出現嚴重不規則的結構單元，對于體型復雜結構不規則的建筑應通過調整建筑方案或設防震縫等形式以滿足規范要求；各種結構建筑高低能反映出其承載能力及抗風抗震能力，因此各種結構選型應在最大適用高度范圍內選擇；通用建筑材料木材的腐爛和蟲蛀、鋼結構的銹蝕、砌體材料的風化等都可能對結構安全造成威脅，因此對各類建筑應根據其材質來充分考慮其有足夠的耐久性以滿足結構安全。

先進性。建筑物的先進性主要是指在結構體系中應盡量推廣成熟的新結構、新技術、新材料新工藝，以利于加快建設速度，推動建筑行業工業化、現代化并確保工程質量，因各種結構均有其適用范圍，因此在進行結構選型時應根據其功能來決定結構類型。

2.3結構體系選擇

鋼筋混凝土結構體系。該種結構形式可以合理利用鋼筋及混凝土兩種材料的受力性能特點，并方便就地取材、工程造價較低、耐火性及耐久性較好、結構造型靈活、整體性能好等優點，但其也具有自重大，構件截面大、抗裂性能差以及修復及不強等。施工難度大等。

鋼結構體系。其具有構件截面小、自重輕、抗震性能好和建設周期短等優點，但其材料較昂貴、且易于腐蝕、防火性較差以及施工技術復雜等，鋼結構的結構體系主要有框架、框架-支撐、筒體以及懸掛體系等多種形式。

篇2

風能作為一種清潔、廉價的可再生資源，是現代能源發展的主要方向，其全世界蘊藏總量達到目前全球能源消耗總量的40倍，這在一定程度上推動了風電裝備的發展。為了提高風力發電效率、降低發電成本，風電機組正面向增加單機功率、減輕整機質量和提高機組可靠性的方向發展。風電齒輪箱是連接葉輪與發電機之間的重要傳動裝置，是風電機組的核心部件，其功能是改變轉速和傳遞扭矩。現有風電機組增速齒輪箱主要采用NGW行星輪系與平行軸輪系相結合的結構布局，由于其自身體積和齒輪強度的限制，難以滿足大兆瓦機組的設計要求［1］。目前，行星傳動結構設計方法對齒輪箱零件結構與形狀等的設計仍停留在粗放式設計階段，使得齒輪箱的結構粗糙、體積大、質量大，造成齒輪箱性能不佳和成本高。特別是在大功率齒輪箱的結構設計中，這種保守而又粗放式的設計方法難以滿足大兆瓦風電齒輪箱的高功率密度、高可靠性和低成本的要求。如何設計合理的齒輪箱結構及參數，使每個零件的性能都得到充分發揮，成為各大企業的研究重點［2］。目前風電齒輪箱箱體的結構優化的相關文獻較少，其他箱體的研究較多［3－7］。ShouwenYao對汽車的變速箱進行了以動態響應為目標的拓撲優化設計，根據優化結果重新建立CAD模型，校核分析表明變速箱的動態性能有所提高。WeiChao在考慮制造約束的條件下，基于SIMP優化理論對大型船用齒輪箱進行拓撲優化設計，通過比較，新方案減重7．8％，達到了輕量化目的。郭曉偉分別使用Workbench平臺和支持向量機的方法對風電齒輪箱箱體進行尺寸優化，結果表明支持向量機方法具有較高可信度，質量減輕550kg。本課題提供的結構優化方法引入拓撲優化理論，模型化設計不再使用類比設計，拓撲優化設計能夠在給定的設計域中得到滿足邊界條件的輕量化結構。結合優化結果和概念設計原則，得到規整的概念結構模型。結構詳細設計對概念結構模型的關鍵尺寸實施基于響應面法的尺寸優化設計，并進一步完成結構的工藝特征以便于加工制造，從而得到結構的詳細模型。

1增速齒輪箱傳動方案介紹

大型風電齒輪箱主要傳動方案分為兩大類：NGW串聯傳動方案與封閉式功率分流傳動方案。NGW串聯傳動方案的主要優點為傳動比大、結構簡單，但存在功率串行、各級承擔功率相同的缺點，這就要求隨著風電機組功率的增大，齒輪箱體積必須隨之增大，導致齒輪制造成本與吊裝成本增加。封閉式功率分流傳動方案彌補了NGW串聯傳動方案的缺點，其各級承擔功率為總功率的一部分，大大降低了各級齒輪所承擔的載荷，可以顯著地降低齒輪箱的質量。封閉式功率分流齒輪箱采用兩級行星傳動、一級平行軸的三級傳動結構（如圖1所示）。第一級為行星架固定的NGW構型，由內齒圈輸入，太陽輪輸出；第二級為差動輪系，由行星架和內齒圈共同輸入，太陽輪輸出；第三級為一定軸輪系，由大齒輪輸入，小齒輪輸出。

2增速齒輪箱箱體概念結構優化設計

概念結構設計是基于變密度法對模型化設計產生的初始幾何模型進行拓撲優化計算，獲得在極限工況下風電齒輪箱零件的最優材料分布規律，根據優化結果進行概念結構設計。2．1齒輪箱整體力學模型建立增速齒輪箱箱體結構優化模型，首先需要確定齒輪箱箱體結構的約束與載荷條件，因此根據齒輪箱機構簡圖，建立齒輪箱整體力學模型（如圖2所示）。2．2箱體幾何模型和網格劃分根據增速齒輪箱傳動構型，確定齒輪箱初始幾何模型。以其中中間傳遞扭矩的構件7（內齒圈）為例說明結構設計過程。齒輪箱內齒圈由齒輪箱內軸承支撐整體回轉運動，其初始幾何模型如圖3所示。網格劃分之前需要分割實體。實體分割主要有兩個目的：一是分割出非設計區域和設計區域；二是分割出載荷施加區域，方便施加載荷。利用Hypermesh軟件實現網格劃分。由于齒輪嚙合實時變化，實際加載時作簡化處理，即在內齒圈分度圓接觸線進行等效加載，因此對輪齒面上分割出分度圓接觸線以利于施加載荷。劃分完網格的齒輪箱輸入結構如圖4所示，其中紅色部分為設計區域（優化區域），綠色部分為非設計區域（非優化區域）。2．3載荷和約束根據圖2中齒輪箱整體受力模型，齒輪箱內齒圈主要受行星輪6所提供的徑向力和切向力。在網格模型上施加載荷（如圖5所示）。內齒圈與第一級太陽輪軸（構件1）通過過盈連接傳遞動力，這里作簡化處理，對聯接盤凸緣內圓面進行全約束處理，施加約束的模型如圖6所示。2．4優化參數設置概念模型設計中需要設置一些必要的參數，包括設計變量、成員尺寸、模式組、優化響應、優化約束、優化約束、優化輔助選項等（見表1）。2．5密度結果云圖選取單元密度閥值為0．5，得到最終的拓撲密度云圖（如圖7所示）。分析云圖可得材料總體分布為周向斜筋分布，符合受力特征。考慮到制造工藝，得到設計概念模型（如圖8所示）。

3增速齒輪箱箱體尺寸優化設計

尺寸優化設計應用響應面法對模型中的關鍵尺寸進行最優設計，如壁厚、大的圓角和肋的厚度等。首先確定設計變量及其變化范圍，選用試驗設計方法生成樣本點，然后通過最小二乘法進行二次多項式響應面的擬合，響應面擬合完成后，需要計算響應面的擬合程度評價指標，再選用優化方法對響應面進行尋優，最后將最優結果作為設計點進行驗證。3．1建立參數驅動的三維模型創建參數化的三維模型，使軟件可以對模型進行參數化自動修改。對齒輪箱箱體結構設置具體可變尺維軟件設計模塊建立關鍵尺寸參數驅動三維模型（如圖9所示），各尺寸均可在一定范圍內變化，通過尺寸優化設計可以確定最佳的尺寸組合方案。3．2關鍵尺寸的靈敏度分析通過分析關鍵尺寸對位移、應力、總質量的影響程度，為之后選擇最優解提供數據支持。齒輪箱箱體結構設置具體可變尺寸（L1，R1，R2，R3，R4）的變化范圍見表2。基于ANSYSWorkbench優化設計平臺對上述模型進行材料屬性定義、網格劃分、施加邊界條件等前處理操作，提交作業求解。通過軟件DesignExplorer模塊，采用中心組合方法給出27組設計點。對這些設計點進行求解，利用響應面法可得設計變量對總位移、等效應力、質量的靈敏程度（如圖10所示）由圖10可見：尺寸L1對箱體等效應力影響最大，尺寸R3對箱體等效應力的影響可以忽略不計；尺寸R3對箱體總移影響最大，尺寸L1對箱體總移影響最小；尺寸R2，R3和R4對箱體質量影響較大。在確定最優方案時需綜合考慮尺寸對等效應力、總移、質量的綜合影響。3．3尺寸優化設計為了獲得候選設計點，需要結合靈敏度分析，綜合考慮剛度、質量等因素，確定最優解。針對齒輪箱箱體結構設置總質量最小、最大總移不大于0．3和最大等效應力不大于100MPa，指定優化評定準則為總質量最小、最大總移不大于0．3和最大等效應力不大于100MPa，利用ANSYSWorkBench進行優化設計，得到3個較優設計方案（見表3）。由表3可知：3種方案的VonMises應力和最大變形相差極小，因此確定以質量最小為評價原則，選定方案一為最終設計方案。對相關尺寸進行圓整后，重新在ANSYS中進行建模計算，可得其最大VonMises應力和總移云圖（如圖11和圖12所示）。由圖11和圖12可見：最大VonMises應力為90．438MPa，屈服強度為650MPa，安全因子大于1．1，滿足要求。對比初始結合模型與輕量化幾何模型，優化后質量降低0．8t，說明該方法有效地降低了齒輪箱的質量。

篇3

1 系統的功能結構設計

1.1 系統目標設計

系統開發的總體任務是實現企業物資設備管理的系統化、規范化和自動化,從而達到企業倉庫庫存管理效率的目的。

1.2 開發設計思想

庫存管理的物資主要是企業生產中所需要的各種設備、原材料及零部件。進貨時經檢查合同確認為有效托收后,進行驗收入庫,填寫入庫單,進行入庫登記。企業各個部門根據所需要的物資設備總額和部門生產活動需要提出物資需求申請。計劃員根據整個企業的需求開出物資設備出庫單,倉庫管理員根據出庫單核對發放設備、原材料及零部件。有些設備使用完畢需要及時歸還入庫,填寫還庫單。根據需要按照月、季、年進行統計分析,產生相應報表。

1.3 數據庫設計

數據庫設計一般包含6個階段:需求分析,概念結構設計,邏輯結構設計,物理設計,數據庫實施以及數據庫運行和維護。數據庫設計分為數據庫結構設計和數據庫行為設計。數據庫結構設計包括概念結構設計,邏輯結構設計和物理結構設計。行為設計包括設計數據庫的功能組織和流程控制。數據庫結構設計過程是在數據庫需求分析的基礎上,逐步形成對數據庫概念、邏輯、物理結構的描述。概念結構設計的結果是形成數據庫的概念模式,用語義層模型描述,如E-R模型。邏輯結構設計的結果是形成數據庫的邏輯模式與外模式,用結構層模型描述,如基本表、視圖等。物理結構設計的結果是形成數據庫的內模式,用文件級術語描述。如數據庫文件或目錄、索引等。

2 系統功能實現

2.1 系統平臺選擇

(1)開發環境

本設計采用ASP(Active Server Page,動態服務器主頁)+SQL(Structured Query Language,結構化查詢語言)作為開發環境。

(2)開發工具

本設計采用Dreamweaver 網站開發工具和SQL Server 2000數據庫開發工具。Dreamweaver在多媒體方面頗有建樹的Macromedia公司推出的可視化網頁制作工具,它與Flash、Fireworks合在一起被稱為網頁制作三劍客,這三個軟件相輔相承,是制作網頁的最佳選擇。SQL Server是Micrcoft公司在原來和Sybase公司合作的基礎上打包出的一款面向高端的數據庫系統。推出后,迅速占領了的數據庫應用市場。經過更新換代,它已發展到了SQL Server 2000,它具有高性能、功能強、安全性好、易操作、易維護等優點,定位于Internet背景下,基于Windows 2000的數據庫的應用,為用戶的Web應用提供了一款完善的數據管理和數據分析解決方案。

2.2 各功能模塊的設計實現

(1)界面設計

界面作為用戶熟悉、操作和閱讀的窗口,是相當重要的,好的界面可以提高系統的友善性,因此,界面在系統開發中的地位是不容忽視的。本系統開發界面遵循如下設計原則:文本格式整齊、色彩搭配和諧、版面劃分合理、網站導航清晰、網頁風格統一。

(2)通用模塊的設計

本設計中包含一些通用模塊,這些模塊以文件的形式保存,可以在其他文件中使用#include語句包含這些模塊,使用其中的定義功能。下面具體給大家介紹一下:

(1)關聯文件conn.asp:功能是實現到數據庫的連接,因為在很多網頁中都有連接數據庫的操作,所以把它保存在conn.asp中,這樣可以避免重復編程。

(2)系統主頁面及登陸程序頁面文件 default.asp:它的功能是判斷當前用戶是否是管理用戶(即保存在表admin中的用戶),如果不是,則跳轉至Login.asp,要求用戶登錄;如果是,則不執行任何操作,直接進入包含它的網頁。

(3)用戶管理模塊文件index.asp:功能是顯示庫存管理系統主頁面信息。

(4)注冊用戶文件newuser.asp:注冊用戶分為兩種,一種是個人用戶,另一種是企業用戶,在編輯用戶信息或者職位信息等情況下,需要通過身份驗證。

總之,庫存管理系統對于單位的決策者和管理者來說都至關重要,所以庫存管理系統應該能夠為用戶提供充足的信息和快捷的查詢手段。使用計算機對庫存信息進行管理,具有著手工管理所無法比擬的優點。例如:檢索迅速、查找方便、可靠性高、存儲量大、保密性好、壽命長、成本低等。這些優點能夠極大地提高庫存管理的效率,也是企業的科學化、正規化管理,與世界接軌的重要條件。

參考文獻

[1] 屈喜龍,朱杰.《ASP + SQL Server 開發動態網站》.機械工業出版社,2006年3月.

[2] 黃雷.《ASP + SQL Server 項目開發實踐》.中國鐵道出版社,2006年6月.

[3] 曹珩龍.《ASP/數據庫開發》.人民郵電出版社,2004年7月.

篇4

中圖分類號:G642 文獻標識碼:B

1引言

“數據庫”課程是信息管理及計算機類專業的主干課程。但“數據庫”課程抽象、實踐性強,部分學生在學完該課程后總是一頭霧水,對很多概念仍然似懂非懂。親身經歷告訴我這不完全是學生方面的原因,其中關鍵的原因是在有限的學時內對所學知識缺乏有效的實踐檢驗環節,學習只能依靠陳述式記憶,不能上升到程序式記憶高度,只能局部理解知識點,沒有一條實踐的主線對知識點的貫通,自然對課程不能很好的把握。文章首先通過引入了數據庫設計的特點及其教學難點,然后結合信息系統開發及多年教學工作給出了一種基于案例為主線的數據庫設計及結果驗證方法,最后部分對全文進行了總結。

2數據庫設計的特點及教學難點分析

根據王珊等人的總結,數據庫設計的特點主要有兩點:其一,數據庫建設的基本規律是“三分技術,七分管理,十二分基礎數據”;其二,數據庫設計是結構設計和行為設計的相結合。

2.1三分技術,七分管理,十二分基礎數據

“三分技術,七分管理,十二分基礎數據”,說明在數據庫設計中,技術是十分重要的,但除了技術之外更重要的還有管理和基礎數據的準備。管理一部分是指對數據庫建設本身這個大項目的管理,另一個隱藏含義是指企業的管理流程規范化、制度化、成熟化,后續課程“管理信息系統”將要解決該問題。它說的是數據庫建設與企業的業務管理密切相關,如果企業的業務流程沒有規范化、經常在變,那么任何人不可能設計出滿足這個企業的數據庫。“十二分基礎數據”則強調了基礎數據在數據庫建設中的地位和作用,基礎數據的準備直接影響到數據庫的表結構以及用戶使用的方便性,甚至是數據的一致性。例如,在圖書館管理系統給讀者辦證功能中,考慮輸入每個讀者的專業信息時,由于一個學校的專業是相對固定但又可能會有變動的情況,所以在設計圖書館數據庫時就有必要建立一個“專業”數據表,維護學校的專業信息,在需要輸入“專業”信息的地方,不是讓用戶輸入,而是直接將“專業”表中的數據顯示給用戶供用戶選擇,這樣不但方便了用戶的使用,而且可以防止用戶輸入造成的數據不一致的現象。 2.2結構設計和行為設計的相結合

由教材,數據庫設計是指對于一個給定的應用環境,構造最優的數據庫模式,建立數據庫及其應用系統,使之能夠有效地存儲數據,滿足各種用戶的應用需求,包括信息要求和處理要求。簡單地說就是指設計出的數據庫(結構設計)要滿足系統所有處理(行為設計)所涉及的數據存取操作。數據流程圖和數據字典詳細的描述了應用系統的行為(處理)以及所涉及的數據,結構設計的任務就是要為這些所涉及的數據提供一個良好的數據組織方式,所以結構設計是必須與行為設計為前提的,行為設計直接影響到結構設計,兩者是相輔相成的。例如,在OA的文件審核中,如果每個文件只需要一個人審核時,那么直接在文件信息表中增加“是否審核”、“審核人”和“審核意見”等屬性就可以滿足要求,但如果審核是固定流程:文件――主管審核――財務審核――副總經理審核――總經理審核,那么至少需要增加一個審核表(審核表中有所審文件、審核人、是否審核、審核意見等屬性)即可以處理,更進一步,如果審核流程不固定,有的文件只需要主管審核就可以,

作者簡介:劉智(1977-),男,江西高安人,講師,博士研究生,主要研究方向為信息融合,數據庫。

有的文件必須有財務審核……相應的數據庫設計就越來越復雜了。所以說結構設計必須和行為設計相結合。

從數據庫設計的特點可以看出數據庫設計是以實踐為基礎的,離開了實踐,數據庫課程的教學沒有任何意義。說過,實踐是檢驗真理的唯一標準,既然來源于實踐就經得起實踐的檢驗,檢驗是為了讓學生從實踐中來,到實踐中去,真正體會數據庫的內涵與實質,避免空對空的學習。

3案例教學及驗證方法

鑒于理論課時的限制,只有在教學過程中充分安排好數據庫課程教學的各個環節,理論課程階段學好數據庫基本原理及設計的方法,數據庫課程設計環節讓學生獨立完成系統簡單需求分析、數據庫設計任務并對完成的設計進行簡單的驗證。驗證是關鍵,讓學生深刻體會設計出的數據庫(結構設計)能否滿足用戶的數據處理要求(行為設計),從而消除學生需求分析和數據庫設計脫節的現象,舉一反三,加深理解。基于案例為主線的數據庫設計及結果檢驗方法簡單過程如下。

(1) 針對具體應用,確定系統邊界及功能,通過企業業務流程分析,最終得到系統需求――數據流程圖和數據字典

數據流程圖是從計算機視角描繪系統的邏輯模型,只描繪數據流在系統中的流動和處理情況,是邏輯系統的圖形表示。數據流程圖具有對復雜客觀流程的高度抽象性(在圖中去掉了具體的組織結構、工作場所、物質流等,只剩下信息和數據存儲、流動、使用以及處理等抽象數據)和概括性(把系統對各種業務的處理過程聯系起來考慮,形成一個總體,可反應數據流之間的概括情況);而數據字典是對數據流圖的進一步補充,圖1給出了借書過程的數據流圖(圖中正方形表示外部實體,圓角矩形表示處理,右開口矩形表示數據存儲,帶箭頭線段表示數據流)。數據流圖和數據字典(篇幅限制,省略圖1所對應的數據字典)描述了系統所有處理要求和信息要求,根據處理要求和信息要求能夠抽象出實體及其實體間的聯系,從而得到系統的概念結構。

圖1讀者借書數據流圖

(2) 根據需求分析,逐步得到系統的總E-R圖,得到系統的概念結構設計

很多學生由于沒有完全掌握數據庫設計的本質,認為概念結構完全是一個多余的中間層次。其實不然,概念結構能夠清晰的反映實體和實體之間的聯系類型,邏輯結構雖然也能通過外碼引用反映數據之間的聯系,但它很不直觀,不具有易理解性的特點,所以數據庫設計往往先得到概念結構,然后轉換成邏輯結構。圖2給出了圖書館借還書系統的簡單E-R圖(只列出了實體的主要屬性)。

圖2圖書館借還書簡單E-R圖

(3) 根據E-R圖到關系模式的轉換規則將概念結構轉化為關系模式,并進行優化,得到數據庫的邏輯結構,即最終的數據庫表結構

圖2所示的E-R圖轉換成關系模式并進行優化后得到以下數據庫表(帶下劃線的是主碼,斜線是外碼):

圖書(ISBN,書名,作者,出版社……);

書目(條碼號,ISBN,借書室,狀態),其中書目狀態有“已借出”,“在庫可借”,“庫本”;

借書室(編號,名稱,簡介);

借書證(卡號,條碼號,學號,姓名,性別,年齡,專業,類別,狀態),其中借書證狀態有“正常”,“注銷”,“掛失”;

借書記錄(借書序號,書目條碼號,借書證條碼號,借書日期,應還日期,還書日期,狀態),其中狀態有“已還”,“未還”。

(4) 根據系統功能劃分及需求分析,簡單設計出每個功能的界面,標注出界面每個按鈕的流轉情況及功能

界面設計的首要原則是讓用戶使用方便,以簡潔、清晰為主,同一個界面盡量不要實現過多的功能,同時界面設計的好壞也直接影響到實現的難易。以學生借書過程為例,設計出圖3和圖4所示界面。

圖3借書界面(掃描借書證)

圖4圖書館借書界面設計示意圖

(5) 驗證所設計數據庫的合理性

針對第4步的每個界面,使用SQL語言詳細說明,界面中數據的來源及每個按鈕操作所涉及數據的去向。例如,針對第4步給出的讀者借書過程界面設計,圖書管理員進入系統后停留在圖3所示頁面,當讀者遞給管理員借書證和要借的書籍時,系統執行以下操作,其中對讀者借書過程的數據存取詳細說明(也可以用通俗的文字進行描述)

/*begin

管理員使用條碼機輸入條碼號(TiaoMa) 點擊“確定”按鈕;

“SELECT 卡號,學號,姓名,類別,狀態 FROM 借書證 WHERE 條碼號=TiaoMa”,返回所有記錄;

If 沒有記錄返回

Msg(“非法讀者”);

Else if 返回多條記錄

Msg(“多個借書證條碼號相同!”);

Else

取出該記錄各分量依次賦給變量CN(卡號),

SNO(學號),SNAME(姓名),TYPE(類型),STATUS(狀態);

if(STATUS =“注銷” or STATUS =“掛失”)

Msg(“借書證已注銷或掛失,不能借書!”);

Else

{

重定向到圖4所示界面;

將CN(卡號),SNO(學號),SNAME(姓名),TYPE(類型)等學生信息顯示在相應位置;

“SELECT 書目條碼號,ISBN,書名,借書日期,應還日期FROM 圖書,書目,借書記錄 WHERE書目.ISBN=圖書.ISBN and 書目.條碼號=借書記錄.書目條碼號 and 借書證條碼號=TiaoMa and 狀態=‘未還’”;

將查詢結果顯示在借書記錄列表并得到借書記錄數(BQTY);

}

管理員使用條碼機輸入條碼號(BookTiaoMa)點擊“確定”按鈕;

根據讀者類型TYPE得出可同時借書冊數(QTY);

If BQTY < QTY

{

Insert into 借書記錄 values

(SerialNo,BookTiaoMa,TiaoMa,Borrowdate,Backdate,’未還’);

Update 書目 set 狀態=’已借出’ where 條碼號=BookTiaoMa;

}

Else

Msg(“已達到最大借書數量!”);

/*end

(6) 如果在前兩步某些功能實現不了或不好實現,那么有可能是所對應數據流圖存在的不合理地方,或者數據庫設計不滿足數據流程圖的某些數據要求,返回第一或第二步對某些不合理地方重新考慮

界面設計及其說明其實就是系統詳細設計的一部分,是數據流圖所展現功能的詳細化、具體化。對于初學者,設計界面和對功能進行詳細說明,或許有一定的難度,但它結合行為設計展現了所實現系統的最細節的部分,只有深入實踐,才能真正體會數據庫技術的本質。

4結束語

篇5

中圖分類號：TP391文獻標識碼：A文章編號：1009-3044(2012)17-4043-03

Database Design in the Hotel Management System

TAN Qian-fang

(Hunan Food and Drug Vocational College，Changsha 410016,China)

Abstract：In the process of building information management system, pay more attention on realization, Contempt on design is a common problem with technology developers, especially the standardization of back-end database design is easily overlooked. This will lead to the eventual realization of the system data processing capacity is limited, inefficient, data management, maintenance and post-update difficul? ties. The article strictly follow normalized database design ideas, with the typical business hotel management system for business logic to ex? plain the main steps in the information systems development process, database design and methods.

Key words: information system; hotel management; database; programing

在信息管理系統的設計和開發過程中，數據庫設計是其中最為重要的環節之一。設計規范、良好的數據庫不僅能帶來系統數據處理效率的極大提升，更重要的是在系統正式運行后能大大簡化后期的數據更新維護工作，提高系統的可擴展性。目前大多數酒店提供的服務多種多樣，規模大小也各不相同，較為典型的酒店服務業務一般都包括飲食、住宿和娛樂等方面，下面該文從這些典型的酒店業務邏輯出發，分析和探討數據庫的設計方案。

1數據庫需求分析

數據庫設計的第一步是做好需求分析。在此階段需要準確了解和分析用戶的具體需求，包括數據需求和處理需求，這是整個數據庫設計過程的基礎，也是最困難、最耗費時間的一步。

1.1數據流圖分析

典型的酒店管理一般包括飲食部門、住宿管理部門、娛樂管理部門和經理部門，下面簡要分析各部門的業務邏輯。

飲食部門是酒店基本部門之一，所提供服務的特點是實時性強、持續時間短、強調效率。此處需要重點處理的信息是與飲食有關的財務數據，一方面便于定期的賬目匯總，另一方面也便于及時向酒店管理層匯報。

住宿管理部門也是酒店基本部門之一。其主要職責包括：（1）布置房間設施、分類、編號、制定收費標準、分配服務人員；（2）登記旅客信息，記錄其入住、退房時間；（3）統計各類房間的客滿程度；（4）處理本部門的財務信息。

娛樂部門需要處理的業務主要包括：（1）制定收費標準，分配負責人；（2）收入支出財務處理等。經理部門的功能是必不可少的。主要職責有：（1）員工管理；（2）部門劃分；（3）各部門的財務核算；（4）酒店營業收益的定期核算。從上面各個部門的業務分析可以看出，不同部門都有財務處理的需求，因此歸總設計一個統一的“財務子系統”。而飲食部門因為所需要的業務功能都已包含在“財務子系統”中，故而去掉該功能模塊。最終設計酒店信息管理系統分為四個子模塊：經理子系統、財務子系統、住宿子系統和娛樂子系統。根據前面對業務邏輯的詳細分析，畫出各子系統的數據流圖，例如圖1所示為財務子系統的數據流圖。

1.2數據字典設計

數據字典是數據庫中各類數據描述的集合，需要設計人員對所開發系統的實際情況進行詳細的數據收集和數據分析才能得到。數據字典內容一般包括數據項、數據結構、數據流、數據存儲和數據處理過程。下面列舉幾例：

數據項如：員工號（編號：1，數據項名稱：員工號，說明部分：整數類型，有唯一性）

數據結構如：員工信息（編號：1，數據結構名：員工信息，屬性：包括員工號、姓名、性別、年齡、工齡、級別、部門、職務、備注）

數據流如：員工基本信息（編號：1，數據流名：員工基本信息，輸入：招新員工，輸出：員工信息）

數據存儲如：員工信息（數據存儲名：員工信息，輸入數據流：員工基本信息，輸出數據流：工資結算）

處理過程如：招新員工（處理過程名：招新員工，輸入數據流：終端，輸出數據流：員工基本信息）

……

2數據庫概念結構設計

數據庫概念結構設計常用方法有自底向上和自頂向下兩種。該文采用自底向上的設計方法，即首先定義各局部應用的概念結構，然后將它們集成，得到全局概念結構。

2.1局部概念結構設計

下面以財務管理子系統為例，分析子系統的功能，設計局部概念結構，并且對該局部概念結構進行合理優化調整。

圖2財務管理子系統E-R圖

財務管理子系統的功能為：首先對各部門上交的收支情況進行匯總，得出各部門的收益情況；然后在此基礎上進行整體匯總，得到整個酒店的收益信息；最后將酒店的收益情況下發給各個部門，公開賬目。根據該分析，得到描述財務管理子系統概念結構的E-R模型如圖2所示。

E-R模型調整的準則：（1）現實世界中的事物能作為屬性對待的盡量作為屬性對待；（2）屬性中不具有需要描述的信息，即屬性是不可分的數據項，不再包含其他信息。根據原則分析，員工應對應一個領導關系，但為了簡便起見，就用員工的“等級”屬性來表達員工之間的領導關系。

2.2數據視圖集成

完成各子系統的分E-R圖設計及優化之后，接下來需要將所有的分E-R圖綜合集成為一個總的E-R圖。由于本系統中各分E-R圖的規模較小，所以合成過程采用了一次集成方式。

整個過程分兩步進行：第一步：合并。將各分E-R圖合并生成初步E-R圖，解決各分E-R圖間可能存在的屬性沖突、命名沖突或結構沖突。第二步：修改和重構。消除不必要的冗余，生成基本E-R圖。

由于本系統涵蓋的內容比較少，基本不存在冗余的現象，所以初步E-R圖就是基本E-R圖，不必再進行調整。

3數據庫邏輯結構設計

3.1生成關系模式

根據E-R圖向關系模式的映射法則，可以將2.2中得到的系統總體E-R圖轉換為一組關系模式。轉換過程簡單描述如下：

一個實體直接轉換為一個關系模式，如：

員工(員工號,姓名,性別,年齡,工齡,級別,部門號,職務,備注)；

工資(員工號,等級,實際工資,基本工資,出勤工資)；

……

實體與實體之間的一對一聯系或一對多聯系可以直接合并到實體所對應的關系模式中，而實體之間的多對多聯系則必須轉換為一個單獨的關系模式。根據這兩條原則，對系統總體E-R圖中的所有聯系進行轉換。

工資和員工之間的1：1聯系與員工實體所對應的關系模式合并；

員工和部門之間的n：1聯系與員工實體所對應的關系模式合并；

……

客房和訂單之間n : m的預約聯系轉化為：預約（訂單號,客房號,始定時間,結束時間）；顧客和房間之間n : m的住宿聯系轉化為：住宿（顧客號,房間號碼,住宿時間）

3.2關系模式優化

將E-R模型轉換為關系模式后，還應該根據關系規范化理論對所有關系模式進行優化，以得到更為科學合理的關系模式。一般而言，在函數依賴的范疇之內，關系模式達到3NF或BCNF層次即可。下面對3.1中的關系模式進行分析：

（1）在顧客關系模式“顧客(顧客編號、級別、姓名、年齡、性別、證件號碼、證件名稱、所選項目、使用時間、備注)”中，因為“使用時間”對于顧客的必要性不強，且該屬性在別的關系中可以查詢得到，所以將“使用時間”屬性刪除。分析可得，“顧客”關系模式屬于BCNF。

（2）在總賬關系模式“總賬(總賬編號、部門號、財務狀況編號、收入、支出、凈利、日期、經手人號、備注)”中，“凈利”屬性可以根據收入和支出計算得到，并且不需要經常性的查詢，所以將該屬性刪除。該關系模式也屬于BCNF。

（3）在財務狀況關系模式“財務狀況（財務狀況編號、時期、總收入、總支出、凈利潤）”中，雖然“凈利潤”也可以通過計算得到，但由于在這一項上查詢比較頻繁，如果每次查詢都計算，必然使得系統性能降低，故保留下來。

（4）在員工關系模式“員工(員工號、姓名、性別、年齡、工齡、級別、部門號、職務、備注)”中，用戶查詢時，一般只需查詢自己所屬單位的員工信息，故可將其按部門水平分解為三個模式，以提高查詢效率。

負責人員(員工號、姓名、性別、年齡、工齡、級別、部門號、職務、備注)；

服務人員(員工號、姓名、性別、年齡、工齡、級別、部門號、職務、備注)；

經手人員(員工號、姓名、性別、年齡、工齡、級別、部門號、職務、備注)；

3.3用戶子模式設計

得到優化后的總體邏輯結構后，還應該根據局部應用需求，結合具體的DBMS特點，設計用戶的子模式。設計過程如下：

（1）因為經理對于員工的次要信息不會經常關注，因此將員工信息中最主要的內容映射過來，在經理子系統上設立員工關系子模式。

員工(員工號、姓名、級別、部門號、職務、部門經理、實際工資)；

（2）因為酒店員工經常使用的只有客房的主要信息，所以在住宿子系統上設立客房關系子模式。

客房（客房號、位置、設備、收費標準、管理人員號、狀態）；

（3）因為酒店管理人員對于顧客的情況管理經常使用的只有部分信息，所以在經營管理子系統上設立顧客關系子模式。

顧客（顧客編號、住宿號、姓名、級別、應收款、使用時間、備注）

4物理結構設計

4.1存儲結構設計

通過對典型酒店中的信息處理需求進行分析，可以得到如下需求特點：飲食、住宿、娛樂三大部門的數據不僅經常需要查詢，而且更新速度快；各個部門信息要求共享的較多，如員工信息、來客信息等，但財務信息一般不共享；經理部門有一定的特殊職能，如匯總財務信息、級聯刪除辭退員工等。針對這些特點，設計如下：

首先要確定數據庫的存放位置。為了提高系統性能，根據應用情況將數據按照易變部分和穩定部分、經常存取部分和存取頻率較低的部分分別在兩個磁盤上存放。經常存取部分包括員工、工資、客房、款項、折扣規則、項目、顧客等；而信息存取頻率較低的部分包括部門、賬單、訂單、總賬、財務狀況等。同時考慮到本系統是多用戶的，為了提高效率，數據庫的備份的數據和日志文件將保存在磁帶中。

然后要確定系統配置。酒店管理系統需要的微機數量和規模都不必太大，但在系統設計時應考慮到酒店的發展需求，在選擇硬件設備、服務器操作系統、數據庫時都考慮到能夠逐步擴展。本酒店管理系統選用了Windows XP操作系統，后臺數據庫選用目前應用最多的ORACLE 10g。由于涉及到酒店的財務管理，數據的完整性和安全性顯得尤其重要，為了保障系統安全穩定運行，需要每天進行數據備份。數據備份需要嚴格按照制定的備份與故障恢復策略進行，并落實備份登記和檢查措施。

4.2存取路徑設計

首先確定數據的存取方式。對飲食、住宿、娛樂三個子系統的各個關系最經常的操作是查找，假設現有n個住宿房間的信息，如果采取順序查找，平均查找n/2次；建立B+樹索引，則平均查找次數為B+樹的層數log2n+1，所以選擇B+樹作為索引，具體設計如下：

（1）對經常在查詢中出現的關系碼建立索引。包括員工、工資、部門、客房、款項、折扣規則和財務狀況等關系。

（2）對經常需要進行連接操作的關系碼建立索引。包括員工號、客房號和部門號等。

（3）對于更新頻率很高的關系模式，不宜在其上定義索引。包括顧客、訂單和賬單等。

4.3設計評價及說明

上述設計對時間效率，空間效率，維護代價和用戶的實際需求做出了較好的權衡。實際方案還需要根據酒店管理的真實環境，以時間效率和用戶需求為根本，進一步優化和完善。

5結束語

該文依據關系數據庫設計的原則和步驟，結合典型的酒店管理的實際情況，設計了酒店信息管理系統所需的數據庫。設計方案科學合理，考慮了實際的業務邏輯需求，對同類信息系統開發中數據庫設計工作具有較高的參考價值。

參考文獻：

[1]王珊,薩師煊.數據庫系統概論[M].北京:高等教育出版社,2006:34-67.

[2]楊東青,馬秀莉等譯.數據庫系統概念[M].北京:機械工業出版社,2007:27-60.

[3]毛國君.高級數據庫原理與技術[M].北京:人民郵電出版社,2002:43-52.

[4] Jeffrey D.Ullman,Jenifer Widom.A First Course in Database Systems[M].北京:機械工業出版社2008:23-27.

[5]王建設,張金娜.酒店管理系統的設計與實現[J].計算機與現代化，2011(1):91-93.

[6]白雪峰,賀春林.酒店餐飲管理系統的設計與實現[J].電腦知識與技術,2010(6):1281-1282.

[7]于侃侃.數據庫原理與應用課程教學改革探討[J].無線互聯科技，2011(9):41-43.

篇6

中圖分類號：TP311.52 文獻標識碼：A 文章編號：1007-9416（2013）05-0168-02

系統設計是整個開發過程中的關鍵，關系到系統的最后實現和功能能否滿足用戶的需求，主要完成系統的總體結構的設計并根據需求分析結果合理科學地劃分系統的功能模塊，進行功能模塊的設計，在此基礎進行系統數據庫的設計。

1 系統結構的劃分

本系統采用多層的系統體系架構，在三層體系結構中里面的每一層都完成不同的功能，這樣在系統進行設計的時候可以清晰明了每一層的任務和目標，可以提高系統開發速度和效率，可以說采用分層結構是目前主流的設計模式，具有許多優點，在本系統中的三層結構劃分具體如圖1所示。

本系統的開發遵循J2EE規范，采用由Web服務器、應用服務器和后臺數據庫形成的S/A/D三層結構，完全的Web應用方式，客戶端要適應工E5.0以上版本或Netscape6.0以上版本的瀏覽器，所有的客戶端只需要通過瀏覽器進行操作，不需要安裝任何其他的軟件；服務器層要適應主流的Web服務器、應用服務器和主流中間件，數據庫層要采用主流數據庫技術。該系統設計結構按照J2EE的結構模型進行設計。從業務層面看，系統分為三層結構：用戶界面層；應用服務層和數據層。

2 功能模塊設計

學籍管理包括五個模塊，它們分別是學生信息管理模塊、注冊管理模塊、學籍管理模塊、繳費管理模塊、學生成績管理模塊、畢業管理模塊。模塊功能圖如圖2所示。

各個模塊的功能如下：

（1）學生信息管理模塊。包括“導入學生綜合信息”、“生成學號”、“學號及密碼查詢”、“學號分配原則”、“在籍學生統計”、“在籍學生信息”。在學生信息管理模塊中主要完成的是學生從入學開始最初始的信息，這些學生的基本數據信息直接從招生獲取，然后進行相關的管理工作，在本系統中主要是在招生工作結束之后，從招生系統中導入數據到數據庫中的dec_student_info數據表，這樣的數據就具有權威性和一致性。

（2）注冊管理模塊。點擊欄目列表中的“注冊”按鈕，打開學生注冊管理頁面，用戶可用掃描槍掃描學生條形碼或直接輸入學生標識號進行查找，即可查看該學生的繳費注冊情況，系統將顯示該學生的信息，包括顯示學生的學號、姓名、系部、專業、注冊狀態、繳費方式等.在“注冊”欄目模塊中，點擊“高級查詢”頁面標簽，可對學生的繳費注冊情況進行高級查詢，并可對已繳費的學生以及已辦理綠色通道或緩繳學費的學生進行注冊登記。學生信息的高級查詢條件包括學生的身份證號、學號、考號、姓名、年級和學期，輸入查找條件值，點擊“查詢”按鈕后，查詢結果將顯示在學生信息列表中。點擊“刷新收費信息”按鈕可刷新學生的收費信息。查詢出學生信息后，對已繳費的學生以及已辦理綠色通道或緩繳學費的學生可進行注冊登記。在學生信息列表中點選所要進行注冊的學生，然后點擊列表下方的“注冊”按鈕，即可完成對該學生的注冊登記，注冊后該學生在學生信息列表中的“注冊情況”將顯示為“已注冊”。

（3）繳費管理模塊。包括“繳費標準”、“學費統計”、“打印收據”和“報名資費統計表”。繳費標準設置了各年各個教學點下的專業層次的學雜標準以及這些學費的分教學點與遠程教育學校的分配比率和書費預交標準。如果分教學點該年沒有注冊的學生，則不能進行設置。該功能只有管理員可以維護，學生能查詢到自己教學點、自己所報專業的“繳費標準”。

（4）學生成績管理。

學生成績錄入，學生成績修改，學生成績統計，學生成績查詢。

學生成績錄入。以班級為單位，錄入各科目的期末成績。

總分及名次。以班級為單位，計算學生的總分及名次。

成績備份。以班級為單位，將學生的成績保存到備份數據庫中。

（5）畢業管理模塊。當學生畢業后，學生信息轉移至備份數據庫中，系統的基本數據庫中需要刪除學生信息。該功能主要進行成批地刪除學生信息，如連續學號區段的多位學生信息刪除，整個班級的刪除，在學生信息刪除前，以學號區段或班級為單位保存到備份數據庫。

3 數據庫的分析與設計

根據前面的分析，在數據庫設計階段其中最重要的工作是數據庫的概念結構的設計，即是對前面數據庫調研的相關數據進行分析，在此基礎上轉換為數據模型，并不是實際的數據庫存儲，另外開發人員所經過加工抽象和設計的模型必須反映應用的實際客觀情況，例如數據模型中的實體-關系圖（E-R圖），在做E-R圖設計的時候，首先要全面的了解清楚應用單位的數據實體有哪些，這些實體的屬性以及實體之間的關系如何等；接著需要將前面分析創建的部分視圖進行組合集成到一個全局的視圖中，最后形成該應用部門的概念數據模型。

對于學生信息管理，我們可以將學生實體抽象出來，學生屬于學校可以將學校作為一個實體，學生所屬專業和畢業信息都將可以作為一個實體。（圖3）

邏輯結構設計就是把概念結構設計階段設計好的基本E-R圖轉換為與選用DBMS產品所支持的數據模型相符合的邏輯結構。設計邏輯結構一般分為3步進行：（1）將概念結構轉換為一般的關系、網狀、層次模型；（2）將轉換來的關系、網狀、層次模型向特定DBMS支持下的數據模型轉換；（3）對數據模型進行優化。

將E-R圖轉換為關系模型實際上就是要獎實體型、實體的屬性和實體型之間的聯系轉換為關系模式，這種轉換一般遵循如下原則：一個實體型轉換為一個關系模式。實體的屬性就是關系的屬性，實體的碼就是關系的碼。對于實體型間的聯系則有以下不同的情況：

將概念結構設計階段設計好的基本E-R圖轉換為關系模型，如下所示：（1）學生（學號，專業號，院系號，姓名，性別，出生日期，身份證號，入學時間，政治面貌，家庭住址，籍貫，郵政編碼，民族），此為學生實體對應的關系模式。（2）教師（教工號，姓名，性別，職稱，所屬院系，電話），此為老師實體對應的關系模式。（3）畢業（畢業證編號，學號，姓名，性別，身份證號，所屬院系，入學時間，已修學分，需修學分），此為畢業實體對應的關系模式。（4）課程（課程號，課程名，學分），此為課程實體對應的關系模式。（5）系（系號，系名稱），此為系實體對應的關系模式。（6）選修（學號，課程號，成績），此為選修關系對應的關系模式。（7）授課（課程號，教工號，課時），此為老師授課關系對應的關系模式。（8）開設（專業號，課程號），此為專業開設課程關系對應的關系模式。將生成的概念模型通過單擊PowerDesigner11工具菜單欄上的Tools選項，再選擇Generate Physical Data Model選項，就可以轉換為物理模型.

篇7

中圖分類號：TP311 文獻標識碼：A 文章編號：1007-9599　（2012）　19-0000-02

數據庫設計的好壞將直接對系統的效率以及實現的效率產生影響，好的數據庫設計對網站的發展具有決定性的作用。下面主要對網站管理系統數據庫設計進行分析。

1 數據庫設計需求分析及建設流程

隨著網絡的不斷發展，人們越來越多的通過網絡來了解所需的信息，網絡化一方面加強了各方面的聯系，通過網站全面宣傳企業等；另一方面，銷售網站的也在近幾年來迅速發展，成為了近幾年來新增網站的主力，網絡銷售也越來越受到人們的歡迎；另外還有工作性質的網站。從目的上看主要是宣傳，銷售，政務工作等。

需求分析通常是和系統調查結合在一起，通過調查收集資料，然后進行分析。系統調查的基本方法有：（1）收集企業資料。如企業組織機構、管理模式、部門職責與業務流程、業務規劃、各種報表和單證等。（2）個別訪談。主要針對企業特定人員，如高層主管、業務骨干等，目的是了解信息系統開發背景、目標，企業發展及對信息系統的要求等涉及系統全局性的信息。（3）填寫調查表。對所有參與信息系統處理和未來系統的使用者，調查他們當前對信息處理和使用的方法以及對未來系統的要求等信息。（4）跟班參與和觀察。對于一些關鍵環節、或無法了解清楚的處理環節和管理崗位，系統開發人員通過跟班體驗、親自參與和觀察，來準確了解所需要的信息。（5）開調查會：舉行由開發人員、部門經理和業務管理人員代表等參加的會議，了解當前的信息處理模式和信息需求。

必須準確了解并清晰表達系統開發所需的全部信息。不可能通過一次調查就把所有需求弄清楚，需要綜合使用各種方法進行多次調查。但無論采用何種方法，調查前都要認真準備，事先有調查提綱或設計調查表，調查后仔細分析調查結果，撰寫調查報告。系統調查是一個和信息系統未來用戶溝通的過程，涉及不同部門、不同層次的業務人員和管理者。調查者需要具備良好的與他人特別是非專業人員溝通的能力。對系統調查獲得的各種資料信息，可以編制詳細的匯總清單，并和用戶一道對信息的準確性和完整性進行審核。

其具體的建設流程是：

（1）程序及數據庫開發：建立高質量的電子商務網站需要對網站建設、用戶需求、數據庫設計進行深入細致的分析。

（2）數據庫開發步驟：需求分析系統功能模塊設計程序編輯應用開發測試驗收交付客戶

（3）數據庫開發工具：

數據庫　SQL　SERVER、MY　SQL、ORACLE。

操作系統　WIN　NT、Linux。

開發語言JAVA、ASP、PHP、JSP。

（4）維護功能：為了保證網站正常工作，網站維護是必要的。但是遠水救不了近火，誰也不能保證網站在故障的時候網站維護人員能夠及時維護，這就要求在設計的時候要增加自主維護功能。有了軟件維護功能，哪怕是簡單的備份功能，也能夠在突發事件中將數據損失降到最低點。

2 數據庫設計的原則

在數據庫系統開發設計的時候應該盡量考慮全面，尤其應該考慮用戶的各種需求，避免浪費不必要的人力、物力和財力。表是包含數據庫中所有數據的數據庫對象。表定義為列的集合，每行代表唯一的一條記錄，每列代表記錄中的一個域。表存儲在數據庫文件中，有相應權限的用戶都可以對其進行操作。表和列的命名要遵循標識符的規定，必須為每列指定數據類型，列的數據類型決定了數據的取值范圍和存儲格式。

3 具體案例

下面以一種銷售網站為例進行分析，某手機銷售網站的具體需求信息如下：

3.1 功能需求分析

（1）前臺商店功能

此功能是用于客戶瀏覽界面，及對購物的流程顯示

商品分類檢索。商品的類別由店主自行在網店管理系統中設定。支持商品分類檢索。

首頁推薦商品和特價商品、排行榜商品。管理員可在商城管理系統中設定一些重要的商品，作為首頁推薦商品。這些商品直接在首頁出現。同樣，也可以設定部分商品為首頁推薦的特價商品及首頁排行榜商品。

購物車：購物車功能主要是指的用戶選中商品之后，點擊“購買”按鈕，商品會自動到購物車里，而且用戶購買的數量也可以自主的調節。

訂單生成：用戶確認購買購物車內的商品之后，點擊“訂單確認”就進入了訂單詳情的頁面，此頁面會讓用戶確定商品的同時，選擇快遞方式和交易方式等。

訂單查詢：網站會員可以通過查詢功能，隨時查詢商品信息，也可以查詢購買后的商品情況，例如快遞情況等。另外用戶也可以查詢到購買歷史。

輔助功能：包括會員資料修改，密碼修改，用戶缺貨登記，缺貨登記處理，發貨或缺貨通知等等。

商品評論：用戶對網站或者某一件商品進行評論或者評價，網站管理員對用戶的評論可以進行管理操作。

（2）后臺商城管理功能

管理員管理：后臺管理商品和處理訂單，幫助用戶修改密碼，群發郵件等。

商品類別管理：添加，刪除，修改商品分類。

分類商品管理：在不同的類別下管理商品，包括商品上傳，修改和刪除等功能。商品資料包括：商品名稱，品牌，產地（生產商），市場價，優惠價，商品詳細介紹等

會員管理：修改、刪除會員資料等，查看會員訂單信息、會員訪問信息。

處理訂單：付款確認、商品出貨、訂單查詢，可以根據需要設定員工權限處理相關項：如送貨員只具有商品出貨權限、財務只具有付款確認權限。

進銷存功能：進貨開進貨單，其它費用支出開支出單。查看每日、每月、每年營業統計。查詢商品庫存數量。

配送方式、付款方式：配送方式支持運費可以分為買家支付以及賣家承擔，買家支付時可以有平郵，快遞之分，平郵快遞單位價格由發貨地價格決定。付款方式具有很強的擴展性，集成了西部在線支付功能。支持網銀在線支付（根據情況需要修改）

3.2 數據庫概念結構設計

設計好數據項和數據結構之后，就可以開始設計滿足用戶需求的各種實體，以及他們之間的各種關系，為后面的邏輯結構設計做準備。這些實體包含各種具體的信息，通過相互作用來形成數據的流動。數據庫設計是指對一個給定的應用環境，構造最優的數據庫模式，建立數據庫及其應用系統，有效存儲數據，滿足用戶要求和處理要求。數據庫結構設計的好壞將直接對應用系統的效率及實現效果產生影響。

設計數據庫系統時首先充分了解各個方面的需求，包括現有的及將來可能增加的需求。由于本系統面向的對象有3個，即普通用戶，會員和管理員，所以在數據庫需求分析中就要考慮三方面因素。

3.3 數據庫邏輯結構設計

數據庫的概念結構設計結束后，就可以將上面的數據庫概念結構轉換為ACCESS所支持的實際數據模型，即數據庫的邏輯結構。

參考文獻：

[1]劉海寧，王經雨.網站管理的幾種形式及應用實踐[J].首都醫科大學學報（社科版），2008.

篇8

中圖分類號：TU3文獻標識碼： A

所謂的結構概念設計就是指用與結構設計相關的理論指導實踐的設計工作。而如果在設計的時候，如果缺乏理論的指導，那么建筑在結構設計上就變成了個人的主觀設計，而不是理論層面接受的設計。當然在結構設計的時候，其理論應該是科學的合理的，符合現行社會和經濟發展的，而且在設計的過程中，先進理論和先進工具的應用也是必須要考慮到的，不能出現落伍的情況。

一、結構概念設計的內涵

1.方案選擇的合理性

設計方案的選擇是十分重要的，不僅關系到以后工程的質量和結構，還影響著人們的居住。在結構方案的選擇上，要遵守科學、合理、發展的原則，而且由于很多種因素都對設計方案造成影響，所以設計出來的方案就是多種多樣的。方案設計出來了，又面臨著合理的選擇上，方案選擇的不好，日后發生的后果不堪設想，所以應該進行認真的分析比較，選取的方案既要科學合理，又要經濟，所以方案的選擇很重要。在對設計方案的可行性進行選擇的時候，要對建設地及施工材料等進行全面的分析，保證每一個環節的科學合理，還要有專業人士對各種影響設計的因素進行評估分析，選擇出科學合理的結構概念設計方案。

2.結構簡圖的科學性

結構概念設計首先要有科學專業的理論作為支撐，而且一般情況下利用結構設計簡圖對結構概念設計的合理性進行評估。在結構簡圖的選擇上，要遵照安全和準確的原則，選取合理的簡圖。因為如果選取的簡圖不夠科學，那么相應的結構概念設計也會出現相應的錯誤，甚至對工程的質量問題造成巨大的影響。所以說，結構設計簡圖在制作時應該做到精確、科學，使出現的誤差也在可控范圍內，應該進行嚴格的審查，保證簡圖的質量。

3.對計算的結果進行準確分析

隨著社會和經濟的發展，信息技術被廣泛的應用，特別是在數字的計算等方面設計出種類繁瑣的計算軟件，可是各計算軟件在計算的結果上確實各不相同，讓使用者也不知道哪個是正確的，所以在工程的設計中計算工作經常出現混亂。在進行設計時，軟件的選擇很重要，應該對各個軟件進行系統化分析，根據工程的實際情況和設計的原理等，選擇適合的軟件，確保計算結果科學準確。

二、建筑結構設計中概念設計的具體應用

1.抗震設計工作中概念設計的應用

在對建筑結構進行抗震設計工作時，通常情況下，設計人員都是在確定了砼的等級以及初始尺寸后，計算出結構的實際剛度，之后依據剛度的計算結構還可以推斷出地震力，從而得到需要配筋的數量。由于結構的剛度、地震力以及配筋的數量這三者是成正比例關系，那么結構的剛度越大，推斷出的地震力就越大，需要配筋的數量就越多，同樣的如果配筋的數量越多，那么結構的剛度就越強，所產生的地震力就越大。可見，如果只是盲目的增加了配筋的數量，實際上也是加劇了地震力的效果，其在抗震設計工作中是無法起到積極的效果的。而如果能在抗震設計工作中應用到概念設計，便可以進一步地拓展設計思路，應用降低作用效應的創新思路，從而取得理想的抗震設計效果。

2.電算分析中概念設計的應用

現階段，全球都已經進入到了信息時代，計算機技術已經應用到我國的各行各業中，同樣的在建筑行業中，計算機技術也得到了廣泛的應用。從實際的效果來看，計算機技術確實減輕了設計人員的工作負擔，然而在很多因素的影響下，計算機軟件本身卻也是存在著一定的缺陷的，不同的軟件，其具體的缺陷情況也是有所區別的。所以，如果沒有采用合適的計算機計算軟件，那么對其計算結果會產生極大的影響，所以也應將概念設計應用到電算分析工作中，借助于計算機技術得到了相應的結果后，設計人員應根據自身的實際經驗以及專業知識，對電算結果進行及時地判斷，從而保證計算結果的可靠性和真實性。

3.方案選擇中概念設計的應用

在選擇建筑結構的設計方案時，為保證所選擇方案的合理性和經濟性，也應較好的應用概念設計的思想。具體來說，選擇基礎設計方案時，應綜合的考慮施工現場的地質條件、施工條件、荷載分布情況以及結構類型等因素，確定最優的基礎設計方案。設計地基基礎時，應根據前期得到的實地勘察報告進行設計工作，如果未得到勘察報告，那么設計人員就應收集相關的資料，全面地掌握施工現場的地質情況。只有具備的完整的信息，才能保證設計工作的合理和準確。

三、概念設計應用中所需要注意的重點

1.根據實際的建筑要求，選擇合理的建筑設計結構方案

在實際的建筑工程中，對建筑的設計要求是很高的。概念設計要求工程設計師不僅要有豐富且合理的想象力，還要結合實際情況，對建筑工程的地理環境、施工條件、材料供應能力等綜合情況進行分析，結構框架必須明確抗震節點分析、應力、總體的布局結構等具體方面。選擇最佳的結構設計方案。例如在利用概念設計對建筑結構的抗震設計中，必須要精確把握建筑材料的性能，對可預測的及不可預測的因素進行分析，重視整體的概念設計理念，利用概念設計對建筑物采取一定的隔震措施，減小在發生地震或者不可抗力的因素對建筑物所帶來的重大打擊，降低對建筑物的破壞。

2.不可盲目定論，選擇恰當的計算簡圖

計算簡圖是設計師進行建筑結構設計計算的基礎，是維護建筑結構安全的保證，所以要求建筑設計師必須切合實際，根據建筑結構的實際情況及具體要求，選擇恰當的計算簡圖，在保證有足夠精確的建筑結構數據的基礎之上，利用數據進行概念結構設計，遵循在建筑建構設計中所必須要注意的原則，比如建構延伸性原則和強柱弱梁的原則。在進行建筑結構設計中，依據恰當的建筑設計簡圖，避免發生因為建筑結構設計的不合理而導致的樓層破壞等問題，這樣才能設計出完美的建筑。

3.不過分依賴計算機，正確分析計算結果

在我國目前的建筑結構設計計算中，設計師普遍利用計算機進行計算，可是由于計算機軟件的種類繁多，各種軟件自身的不健全或是各種缺陷，導致了運用不同的軟件所帶來的結果的差異化。這就要求設計師要結合具體情況，利用自身的專業技能水平和豐富的經驗，認真分析計算機軟件的計算結果，進行反復的比較和審核，輸入正確的計算參數，選擇出最合理的計算結果。概念設計理念為建筑設計行業帶來了極大的便利，深入的把握概念設計理念，靈活的運用到建筑結構設計中，才能使建筑結構設計更加人性化、科學化、理想化。

綜上所述，在建筑結構設計中，為了確保設計方案的科學性和實用性，設計人員應根據建筑的概念來進行結構設計，不僅要根據相關概念和設計技術進行設計，還需要結合個人設計實踐經驗，設計出一套適用于施工的建筑結構設計方案，才能確保建筑施工順利進行。

參考文獻：

篇9

中圖分類號：TP311.13 文獻標識碼：A 文章編號：1007-9416（2017）01-0188-01

數據庫系統是信息化應用系統的核心組成部分。在很多應用系統中，因為數據庫設計不合理、不規范，導致系統出現操作異常、性能降低、空間浪費，甚至是系統崩潰等嚴重現象。如何避免數據庫系統出現這些不良現象，在數據庫設計時實現規范化是至關重要的。設計項目數據庫時，應該基于項目本身實際需求，從數據庫設計的各個階段出發，設計合理規范的數據庫系統，數據庫設計包括概念結構設計、邏輯結構設計和物理結構設計，本文將主要考慮邏輯結構設計過程中的規范化，從范式、命名、約束等主要方面進行規范化的設計和檢查。

1 設計滿足范式要求

為了設計結構清晰合理、數據較少冗余的數據庫，避免出現修改、插入和刪除數據時出現異常，在數據庫設計時必須遵循一定的規則，在關系型數據庫中，這種規則稱為范式。目前，關系數據庫有六種范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、Boyce-Codd范式（BCNF）、第四范式（4NF）和第五范式（5NF）。這六種范式有著各自不同規則要求，但最低的、最基本的要求是第一范式。根據應用系統的實際需求不同，在設計相應數據庫時應滿足不同的范式要求。但不是滿足范式越多越好，而應根據應用系統訪問數據的情況和數據庫存儲的數據記錄情況而定，一般情況下，滿足第三范式就可以了。

2 命名滿足規范化

在數據庫邏輯結構設計時，不管是為數據庫對象（如數據表、視圖等）命名，還是為數據表中的字段命名，都需要遵循一定的命名規則。在項目中，規范化數據庫對象或字段命名時，要遵循如下幾個原則：

（1）采用的命名規則應是行業認可的共性規則，不建議違背此規則而自成體系，特立獨行。如當用字母命名時，應用常用易懂的英文單詞或英文單詞的組合，而不應使用偏僻難懂，日常使用率極低的單詞來命名，也不應使用漢語拼音來命名。（2）在遵循命名共性規則的前提下，可以有自己的命名風格。但同一個項目中應保持一致的命名風格，不要這幾個對象用這種命名風格，而另幾個對象用其他的命名風格，否則，給人以雜亂無章的感覺，影響命名的規范化程度。（3）要使用“見名知意”的單詞或單詞縮寫，單詞意思要明確、清晰，縮寫時應使用大家都能理解的，不會產生歧義的縮寫方式，最好是常見的縮寫方式。例如數量的縮寫應使用“Qty”，而不建議使用“Qua”。另外，對于縮寫建議有相應的注釋說明。（4）不要使用全數字和特殊符號（下劃線除外，如？、%、&等），如名稱不應為諸如“123”、“5”、“8？”之類。名稱的第一個字符應為英文字母。（5）不應使用數據庫系統的保留關鍵字。如名稱不應使用“create”、“table”、“join”等，這些關鍵字在數據庫系統中有特定的含義。（6）禁止使用帶空格的名稱。需要使用多個單詞組合的時候，中間不應有空格，如“order date”。

3 約束滿足規范化

篇10

中圖分類號：G712 文獻標識碼：A 文章編號：1672-5727（2013）08-0100-03

隨著計算機在各行各業的普及應用，數據庫技術已成為各種應用系統開發的重要基礎平臺和核心技術。因此，《數據庫原理與應用》成為高職高專計算機專業一門非常重要的主干課程。

依據高職高專“實用為主，夠用為度”的教學原則，該課程主要由數據庫原理、設計和應用三個部分組成，重點是數據庫設計和數據查詢語句。

目前，高職高專《數據庫原理與應用》教材在內容編排上一般都是先原理、后設計、再應用，孤立數據庫設計與數據庫原理各知識點的關聯，抽象且不易理解。盡管教師花費不少課時講解，學生仍普遍反應原理抽象，大都不能深刻領會理論對實踐的指導作用。在學生以后的系統開發實踐中，對數據庫設計這一環節常常無從下手，茫然無措。實踐證明，學生要想真正掌握如何做，還應知道必要的“為什么”。只有學好必要的數據庫基本理論知識，學生在日后的開發及應用中才能應對自如。

教師感覺原理難教，學生感覺原理難學。由此，市場上甚至出現了不少跳過原理直接以一個數據庫管理系統平臺講應用的高職教材，也引發許多關于數據庫課程教學的討論并屢見于期刊中，但都局限于討論該課程的教學手段與教學方法，對如何重點解決“數據庫原理內容教學難”的問題鮮有討論。

針對這一情況，筆者通過多年的數據庫教學經驗，摸索并總結出：采用案例教學法，以數據庫設計為主線，通過數據庫設計的幾個環節來穿插講授數據庫原理中的各知識點。把原來抽象學習的一些理論，變成數據庫設計實踐中適時的需要和指導，加深學生對原理的理解，同時也提高學生分析問題和解決問題的能力，取得了一定的教學效果。

數據庫原理教學設計方案包括三個部分，即明確重要知識點，教學過程設計，教學課時分配。

明確重要知識點

依據高職教育“實用為主、夠用為度”的原則，《數據庫原理與應用》這門課程的原理部分學生需要重點掌握的幾個知識點是：DB（數據庫）、DBMS（數據庫管理系統）、DBS（數據庫系統）、關系數據結構、關系的完整性規則、E-R圖、關系規范化理論。

教學過程設計

如何串講數據庫原理的各知識點，變抽象為生動，把數據庫理論變成實踐過程中適時的需要和指導，使學生能夠理解和接受，是本文探討的重點內容。通過多年的教學實踐，下面給出一套數據庫原理與應用的教學過程設計：采用案例教學法，以數據庫設計為主線，通過數據庫設計的幾個環節來穿插講授數據庫原理各知識點。

內容簡介 開發信息管理系統大體分為前臺與用戶的交互界面及后臺相關數據的管理，前臺與用戶的交互界面由高級語言來完成。本課程的學習內容是后臺的數據管理技術。通過學習，要掌握后臺數據庫管理系統管理數據的特點及數據庫的設計方法，學完原理后還要通過一個具體的數據庫管理系統（如SQL Server2005）平臺詳細介紹數據庫原理的應用。

教學案例 選取的教學案例最好能貼近學生實際的學習生活，便于學生理解記憶，縮短教學情境與實際情境的差距，讓學生清楚地認識到這些知識在實際數據庫應用系統開發中的用處，同時也可以引導學生在理論與實際結合中理解知識，培養學生分析、解決實際問題的能力。本文以設計一個簡單的“學生成績管理系統”的后臺數據庫“學生成績”作為教學案例。

設計數據庫 隨著計算機硬件技術的飛速發展及數據管理的發展，數據管理的技術經歷了人工管理、文件系統及數據庫系統三個階段。介紹各階段數據管理技術的特點，需要重點介紹目前數據庫階段數據管理技術的特點，接下來就可以過渡到講授數據庫的一些基本概念，給出數據庫、數據庫管理系統、數據庫系統等術語的定義。通過學習，使學生明白通過數據庫管理系統來管理數據是比較優越的，所以要為“學生成績管理系統”設計一個后臺數據庫。該數據庫的設計需六個步驟：需求分析、概念結構設計、邏輯結構設計、物理設計、數據庫的實施和數據庫的運行及維護。通過前三個階段講解數據庫原理的有關知識，掌握數據庫設計的方法。

1.需求分析。詳細調查與分析“學生成績管理系統”的業務與數據處理需求，收集系統需要處理的信息：學生姓名、性別、出生日期、所在班級、選修課名稱、課程學分、選修課程成績。給出實體與屬性的概念：標識對象（實體），標識每個對象需要存儲的詳細信息（屬性）。

2.概念結構設計。本階段的任務是把需求分析的結果用E-R圖描繪出來。先給出主碼的概念（能唯一標識實體集中個體的屬性或屬性的集合），通過學號與姓名的區別來說明其唯一性的特征。給出實體之間的關系（舉例說明三種關系：1：1，1：N，M：N），最后用E-R圖來描述實體及實體間的聯系。介紹E-R圖中實體、屬性及聯系的表示方法。通過前面需求分析，得到“學生成績”數據庫的E-R圖（如圖1所示）。最后需要向學生強調一下E-R圖與后面具體采用什么樣的數據庫管理系統無關。

3.邏輯結構設計。先回憶數據庫的概念，強調數據庫是有一定組織結構的數據集合，由此給出常用的三種數據模型：層次模型、網狀模型、關系模型，介紹幾種當今流行的商用數據庫管理系統，告訴學生它們都是關系型的，重點了解關系模型的特點。邏輯結構設計階段的任務就是要把概念結構設計得到的結果（E-R圖）轉換成關系數據模型（若干個關系模式構成）。接下來詳細講解E-R圖轉換成關系模型的轉換規則（分為實體與聯系的轉換）。依據轉換規則得到“學生成績”數據庫的關系模型如下：

學生（學號，姓名，性別，出生日期，所在班號）

課程（課程編號，課程名稱，學分）

選課（學號，課程編號，成績）

班級（班號，班級名稱）

應通過選課關系說明主碼有時由屬性的集合構成。然后詳細講解關系數據模型的三個部分：關系數據結構、關系的完整性規則和關系操作。一個關系模式的數據結構就是一張二維表，介紹二維表的若干性質；介紹關系的完整性規則（舉例說明外碼的概念）；介紹常用的關系操作（選擇、投影和連接）。

關系規范化理論是學生學習數據庫原理時最難理解的部分。可通過評估關系模式的優劣，引出關系規范化理論內容的講解，舉例說明一個不良關系模式存在數據冗余和插入、刪除、更新異常問題，原因是一個關系模式中包羅萬象，而屬性間存在著各種依賴關系；給出部分依賴和傳遞依賴的概念，然后再列出第一范式（1NF）、第二范式（2NF）和第三范式（3NF）的概念。告訴學生一個簡單的系統可以采用“一事一地”（“事”指實體或聯系，“地”指關系）的直觀設計方法。

教學課時分配

通過多次教學實踐，提供數據庫原理部分各知識點的課時分配表（如表1），以供參考。

本文針對數據庫原理知識抽象、不易講解的特點，采用以數據庫設計為主線，通過數據庫設計的幾個環節來穿插講授數據庫原理各知識點的方法，給出了一套數據庫原理的教學設計方案。多年的教學實踐證明，高職高專學生一樣可以把數據庫原理學好。學好原理，不僅能解決數據庫設計的難題，更能得心應手地運用，為今后從事信息系統的開發及相關工作打下堅實的基礎。

參考文獻：

[1]薩師煊.數據庫系統概述[M].北京：高等教育出版社，2000.

[2]周慧.數據庫應用技術（SQL Server2005）[M].北京：人民郵電出版社，2009.

[3]北京阿博泰克北大青鳥信息技術有限公司. SQL Server數據庫設計與高級查詢[M].北京：科學技術文獻出版社，2008.

[4]喻勇，王群，劉向陽.《數據庫原理及應用》課程教學改革初探[J].中國水運，2008，8（12）：103-104.

[5]王向輝，崔魏，徐俊立.基于CDIO的數據庫課程教學改革方案研究[J].計算機教育，2011（2）：38-41.

[6]劉芳.高職院校“數據庫原理及應用”課程教學改革的研究與實踐[J].職業教育研究，2007（1）：99-100.