A. 簡述資料庫應用系統的設計步驟
資料庫設計的基本步驟：
1、系統需求分析與設計。
2、概念結構分析與設計。
3、邏輯結構分析與設計。
4、物理結構分析與設計。
5、系統實施。
6、系統維護。
(1)活動管理資料庫設計擴展閱讀：
資料庫設計技巧：
1、原始文件與實體的關系
它可以是一對一，一對多，多對多的關系。一般來說，它們是一對一的關系：一個原始文檔只對應於一個實體。在特殊情況下，它們可以是一對多或多對一關系，即一個原始文檔對應於多個實體，或者多個原始文檔對應於一個實體。
這里的實體可以理解為基本表。在對應關系明確後，對輸入介面的設計非常有利。
2、主鍵和外鍵
一般來說，實體不能既沒有主鍵也沒有外鍵。在E－R圖中，葉中的實體可以定義主鍵或不定義主鍵（因為它沒有子代），但它必須有外鍵（因為它有父項）。
主鍵和外鍵的設計在全局資料庫的設計中起著重要的作用。當全球資料庫的設計完成後，一位美國資料庫設計專家說：「鑰匙無處不在，只有鑰匙。」。這是他資料庫設計的經驗，也體現了他對信息系統核心（數據模型）高度抽象的理念。
因為：主鍵是一個高度抽象的實體。主鍵和外鍵的配對表示實體之間的連接。
3、基本表的屬性
基本表不同於中間表和臨時表，因為它具有以下四個特點：
原子性。基本表中的欄位不可分解。
原始主義。基本表中的記錄是原始數據（基本數據）的記錄。
演繹的。所有輸出數據都可以從基本表和代碼表中的數據導出。
穩定。基本表的結構比較穩定，表中的記錄要長期保存。
在了解基本表的性質之後，在設計資料庫時，可以將基本表與中間表和臨時表區分開來。
B. 《資料庫》設計某企業計劃開發一個進銷存管理信息系統，替換原來的人工系統。
這個工程量大哦·
以上功能速達已經有現成的了，而且非常成熟了……
C. 請簡要的敘述一下資料庫的主要設計過程
一、資料庫設計過程
資料庫技術是信息資源管理最有效的手段。
資料庫設計是指：對於一個給定的應用環境，構造最優的資料庫模式，建立資料庫及其應用系統，有效存儲數據，滿足用戶信息要求和處理要求。
資料庫設計的各階段：
A、需求分析階段：綜合各個用戶的應用需求(現實世界的需求)。
B、在概念設計階段：形成獨立於機器和各DBMS產品的概念模式(信息世界模型)，用E-R圖來描述。
C、在邏輯設計階段：將E-R圖轉換成具體的資料庫產品支持的數據模型，如關系模型，形成資料庫邏輯模式。然後根據用戶處理的要求，安全性的考慮，在基本表的基礎上再建立必要的視圖(VIEW)形成數據的外模式。
D、在物理設計階段：根據DBMS特點和處理的需要，進行物理存儲安排，設計索引，形成資料庫內模式。
1. 需求分析階段
需求收集和分析，結果得到數據字典描述的數據需求(和數據流圖描述的處理需求)。
需求分析的重點：調查、收集與分析用戶在數據管理中的信息要求、處理要求、安全性與完整性要求。
需求分析的方法：調查組織機構情況、各部門的業務活動情況、協助用戶明確對新系統的各種要求、確定新系統的邊界。
常用的調查方法有： 跟班作業、開調查會、請專人介紹、詢問、設計調查表請用戶填寫、查閱記錄。
分析和表達用戶需求的方法主要包括自頂向下和自底向上兩類方法。自頂向下的結構化分析方法(Structured Analysis，簡稱SA方法)從最上層的系統組織機構入手，採用逐層分解的方式分析系統，並把每一層用數據流圖和數據字典描述。
數據流圖表達了數據和處理過程的關系。系統中的數據則藉助數據字典(Data Dictionary，簡稱DD)來描述。
2. 概念結構設計階段
通過對用戶需求進行綜合、歸納與抽象，形成一個獨立於具體DBMS的概念模型，可以用E-R圖表示。
概念模型用於信息世界的建模。概念模型不依賴於某一個DBMS支持的數據模型。概念模型可以轉換為計算機上某一DBMS支持的特定數據模型。
概念模型特點：
(1) 具有較強的語義表達能力，能夠方便、直接地表達應用中的各種語義知識。
(2) 應該簡單、清晰、易於用戶理解，是用戶與資料庫設計人員之間進行交流的語言。
概念模型設計的一種常用方法為IDEF1X方法，它就是把實體-聯系方法應用到語義數據模型中的一種語義模型化技術，用於建立系統信息模型。
作者: 小靈, 出處:論壇, 責任編輯: 李書琴, 2007-09-27 15:17
本文詳細解析了資料庫設計過程、設計技巧以及總結了資料庫命名規范……
2.1 第零步——初始化工程
這個階段的任務是從目的描述和范圍描述開始，確定建模目標，開發建模計劃，組織建模隊伍，收集源材料，制定約束和規范。收集源材料是這階段的重點。通過調查和觀察結果，業務流程，原有系統的輸入輸出，各種報表，收集原始數據，形成了基本數據資料表。
2.2 第一步——定義實體
實體集成員都有一個共同的特徵和屬性集，可以從收集的源材料——基本數據資料表中直接或間接標識出大部分實體。根據源材料名字表中表示物的術語以及具有 「代碼」結尾的術語，如客戶代碼、代理商代碼、產品代碼等將其名詞部分代表的實體標識出來，從而初步找出潛在的實體，形成初步實體表。
2.3 第二步——定義聯系
IDEF1X模型中只允許二元聯系，n元聯系必須定義為n個二元聯系。根據實際的業務需求和規則，使用實體聯系矩陣來標識實體間的二元關系，然後根據實際情況確定出連接關系的勢、關系名和說明，確定關系類型，是標識關系、非標識關系(強制的或可選的)還是非確定關系、分類關系。如果子實體的每個實例都需要通過和父實體的關系來標識，則為標識關系，否則為非標識關系。非標識關系中，如果每個子實體的實例都與而且只與一個父實體關聯，則為強制的，否則為非強制的。如果父實體與子實體代表的是同一現實對象，那麼它們為分類關系。
2.4 第三步——定義碼
通過引入交叉實體除去上一階段產生的非確定關系，然後從非交叉實體和獨立實體開始標識侯選碼屬性，以便唯一識別每個實體的實例，再從侯選碼中確定主碼。為了確定主碼和關系的有效性，通過非空規則和非多值規則來保證，即一個實體實例的一個屬性不能是空值，也不能在同一個時刻有一個以上的值。找出誤認的確定關系，將實體進一步分解，最後構造出IDEF1X模型的鍵基視圖(KB圖)。
2.5 第四步——定義屬性
從源數據表中抽取說明性的名詞開發出屬性表，確定屬性的所有者。定義非主碼屬性，檢查屬性的非空及非多值規則。此外，還要檢查完全依賴函數規則和非傳遞依賴規則，保證一個非主碼屬性必須依賴於主碼、整個主碼、僅僅是主碼。以此得到了至少符合關系理論第三範式的改進的IDEF1X模型的全屬性視圖。
2.6 第五步——定義其他對象和規則
定義屬性的數據類型、長度、精度、非空、預設值、約束規則等。定義觸發器、存儲過程、視圖、角色、同義詞、序列等對象信息。
3. 邏輯結構設計階段
將概念結構轉換為某個DBMS所支持的數據模型(例如關系模型)，並對其進行優化。設計邏輯結構應該選擇最適於描述與表達相應概念結構的數據模型，然後選擇最合適的DBMS。
將E-R圖轉換為關系模型實際上就是要將實體、實體的屬性和實體之間的聯系轉化為關系模式,這種轉換一般遵循如下原則：一個實體型轉換為一個關系模式。實體的屬性就是關系的屬性。實體的碼就是關系的碼。
數據模型的優化，確定數據依賴，消除冗餘的聯系，確定各關系模式分別屬於第幾範式。確定是否要對它們進行合並或分解。一般來說將關系分解為3NF的標准，即：
表內的每一個值都只能被表達一次。
表內的每一行都應該被唯一的標識(有唯一鍵)。
表內不應該存儲依賴於其他鍵的非鍵信息。
作者: 小靈, 出處:論壇, 責任編輯: 李書琴, 2007-09-27 15:17
本文詳細解析了資料庫設計過程、設計技巧以及總結了資料庫命名規范……
4. 資料庫物理設計階段
為邏輯數據模型選取一個最適合應用環境的物理結構(包括存儲結構和存取方法)。根據DBMS特點和處理的需要，進行物理存儲安排，設計索引，形成資料庫內模式。
5. 資料庫實施階段
運用DBMS提供的數據語言(例如SQL)及其宿主語言(例如C)，根據邏輯設計和物理設計的結果建立資料庫，編制與調試應用程序，組織數據入庫，並進行試運行。 資料庫實施主要包括以下工作：用DDL定義資料庫結構、組織數據入庫 、編制與調試應用程序、資料庫試運行 ，(Data Definition Language(DDL數據定義語言)用作開新數據表、設定欄位、刪除數據表、刪除欄位，管理所有有關資料庫結構的東西)
●Create (新增有關資料庫結構的東西，屬DDL)
●Drop (刪除有關資料庫結構的東西，屬DDL)
●Alter (更改結構，屬DDL)
6. 資料庫運行和維護階段
在資料庫系統運行過程中必須不斷地對其進行評價、調整與修改。內容包括：資料庫的轉儲和恢復、資料庫的安全性、完整性控制、資料庫性能的監督、分析和改進、資料庫的重組織和重構造。
7. 建模工具的使用
為加快資料庫設計速度，目前有很多資料庫輔助工具(CASE工具)，如Rational公司的Rational Rose，CA公司的Erwin和Bpwin，Sybase公司的PowerDesigner以及Oracle公司的oracle Designer等。
ERwin主要用來建立資料庫的概念模型和物理模型。它能用圖形化的方式，描述出實體、聯系及實體的屬性。ERwin支持IDEF1X方法。通過使用 ERwin建模工具自動生成、更改和分析IDEF1X模型，不僅能得到優秀的業務功能和數據需求模型，而且可以實現從IDEF1X模型到資料庫物理設計的轉變。ERwin工具繪制的模型對應於邏輯模型和物理模型兩種。在邏輯模型中，IDEF1X工具箱可以方便地用圖形化的方式構建和繪制實體聯系及實體的屬性。在物理模型中，ERwin可以定義對應的表、列，並可針對各種資料庫管理系統自動轉換為適當的類型。
設計人員可根據需要選用相應的資料庫設計建模工具。例如需求分析完成之後，設計人員可以使用Erwin畫ER圖，將ER圖轉換為關系數據模型，生成資料庫結構;畫數據流圖，生成應用程序。
二、資料庫設計技巧
1. 設計資料庫之前(需求分析階段)
1) 理解客戶需求，包括用戶未來需求變化。
2) 了解企業業務類型，可以在開發階段節約大量的時間。
3) 重視輸入(要記錄的數據)、輸出(報表、查詢、視圖)。
4) 創建數據字典和ER 圖表
數據字典(Data Dictionary，簡稱DD)是各類數據描述的集合，是關於資料庫中數據的描述，即元數據，不是數據本身。(至少應該包含每個欄位的數據類型和在每個表內的主外鍵)。
數據項描述: 數據項名，數據項含義說明，別名，數據類型，長度，取值范圍，取值含義，與其他數據項的邏輯關系
數據結構描述: 數據結構名，含義說明，組成:[數據項或數據結構]
數據流描述: 數據流名，說明，數據流來源，數據流去向， 組成:[數據結構]，平均流量，高峰期流量
數據存儲描述: 數據存儲名，說明，編號，流入的數據流，流出的數據流，組成:[數據結構]，數據量，存取方式
處理過程描述: 處理過程名，說明，輸入:[數據流]，輸出:[數據流]，處理:[簡要說明]
ER 圖表和數據字典可以讓任何了解資料庫的人都明確如何從資料庫中獲得數據。ER圖對表明表之間關系很有用，而數據字典則說明了每個欄位的用途以及任何可能存在的別名。對SQL 表達式的文檔化來說這是完全必要的。
5) 定義標準的對象命名規范
資料庫各種對象的命名必須規范。
作者: 小靈, 出處:論壇, 責任編輯: 李書琴, 2007-09-27 15:17
本文詳細解析了資料庫設計過程、設計技巧以及總結了資料庫命名規范……
2. 表和欄位的設計(資料庫邏輯設計)
表設計原則
1) 標准化和規范化
數據的標准化有助於消除資料庫中的數據冗餘。標准化有好幾種形式，但Third Normal Form(3NF)通常被認為在性能、擴展性和數據完整性方面達到了最好平衡。簡單來說，遵守3NF 標準的資料庫的表設計原則是：「One Fact in One Place」即某個表只包括其本身基本的屬性，當不是它們本身所具有的屬性時需進行分解。表之間的關系通過外鍵相連接。它具有以下特點：有一組表專門存放通過鍵連接起來的關聯數據。
2) 數據驅動
採用數據驅動而非硬編碼的方式，許多策略變更和維護都會方便得多，大大增強系統的靈活性和擴展性。
舉例，假如用戶界面要訪問外部數據源(文件、XML 文檔、其他資料庫等)，不妨把相應的連接和路徑信息存儲在用戶界面支持的表裡。如果用戶界面執行工作流之類的任務(發送郵件、列印信箋、修改記錄狀態等)，那麼產生工作流的數據也可以存放在資料庫里。角色許可權管理也可以通過數據驅動來完成。事實上，如果過程是數據驅動的，你就可以把相當大的責任推給用戶，由用戶來維護自己的工作流過程。
3) 考慮各種變化
在設計資料庫的時候考慮到哪些數據欄位將來可能會發生變更。
4) 表名、報表名和查詢名的命名規范
(採用前綴命名)檢查表名、報表名和查詢名之間的命名規范。你可能會很快就被這些不同的資料庫要素的名稱搞糊塗了。你可以統一地命名這些資料庫的不同組成部分，至少你應該在這些對象名字的開頭用 Table、Query 或者 Report 等前綴加以區別。如果採用了 Microsoft Access，你可以用 qry、rpt、tbl 和 mod 等符號來標識對象(比如 tbl_Employees)。用 sp_company 標識存儲過程，用 udf_ (或者類似的標記)標識自定義編寫的函數。
欄位設計原則：
1) 每個表中都應該添加的3 個有用的欄位。
dRecordCreationDate，在SQL Server 下默認為GETDATE()
sRecordCreator，在SQL Server 下默認為NOT NULL DEFAULT USER
nRecordVersion，記錄的版本標記;有助於准確說明記錄中出現null 數據或者丟失數據的原因
時效性數據應包括「最近更新日期/時間」欄位。時間標記對查找數據問題的原因、按日期重新處理/重載數據和清除舊數據特別有用。
2) 對地址和電話採用多個欄位
描述街道地址就短短一行記錄是不夠的。Address_Line1、Address_Line2 和Address_Line3 可以提供更大的靈活性。還有，電話號碼和郵件地址最好擁有自己的數據表，其間具有自身的類型和標記類別。
3) 表內的列[欄位]的命名規則(採用前綴/後綴命名)、採用有意義的欄位名
對列[欄位]名應該採用標準的前綴和後綴。如鍵是數字類型：用 _N 後綴;字元類型：_C 後綴;日期類型：_D 後綴。再如，假如你的表裡有好多「money」欄位，你不妨給每個列[欄位]增加一個 _M 後綴。
作者: 小靈, 出處:論壇, 責任編輯: 李書琴, 2007-09-27 15:17
本文詳細解析了資料庫設計過程、設計技巧以及總結了資料庫命名規范……
假設有兩個表：
Customer 和 Order。Customer 表的前綴是 cu_，所以該表內的子段名如下：cu_name_id、cu_surname、cu_initials 和cu_address 等。Order 表的前綴是 or_，所以子段名是：
or_order_id、or_cust_name_id、or_quantity 和 or_description 等。
這樣從資料庫中選出全部數據的 SQL 語句可以寫成如下所示：
Select * From Customer, Order Where cu_surname = "MYNAME" ;
and cu_name_id = or_cust_name_id and or_quantity = 1
在沒有這些前綴的情況下則寫成這個樣子(用別名來區分)：
Select * From Customer, Order Where Customer.surname = "MYNAME" ;
and Customer.name_id = Order.cust_name_id and Order.quantity = 1
第 1 個 SQL 語句沒少鍵入多少字元。但如果查詢涉及到 5 個表乃至更多的列[欄位]你就知道這個技巧多有用了。
5) 選擇數字類型和文本類型的長度應盡量充足
假設客戶ID 為10 位數長。那你應該把資料庫表欄位的長度設為12 或者13 個字元長。但這額外占據的空間卻無需將來重構整個資料庫就可以實現資料庫規模的增長了。
6) 增加刪除標記欄位
在表中包含一個「刪除標記」欄位，這樣就可以把行標記為刪除。在關系資料庫里不要單獨刪除某一行;最好採用清除數據程序而且要仔細維護索引整體性。
7) 提防大小寫混用的對象名和特殊字元
採用全部大寫而且包含下劃符的名字具有更好的可讀性(CUSTOMER_DATA)，絕對不要在對象名的字元之間留空格。
8) 小心保留詞
要保證你的欄位名沒有和保留詞、資料庫系統或者常用訪問方法沖突，比如，用 DESC 作為說明欄位名。後果可想而知!DESC 是 DESCENDING 縮寫後的保留詞。表裡的一個 SELECT * 語句倒是能用，但得到的卻是一大堆毫無用處的信息。
9) 保持欄位名和類型的一致性
在命名欄位並為其指定數據類型的時候一定要保證一致性。假如欄位在表1中叫做「agreement_number」，就別在表2里把名字改成 「ref1」。假如數據類型在表1里是整數，那在表2里可就別變成字元型了。當然在表1(ABC)有處鍵ID，則為了可讀性，在表2做關聯時可以命名為 ABC_ID。
10) 避免使用觸發器
觸發器的功能通常可以用其他方式實現。在調試程序時觸發器可能成為干擾。假如你確實需要採用觸發器，你最好集中對它文檔化。
作者: 小靈, 出處:論壇, 責任編輯: 李書琴, 2007-09-27 15:17
本文詳細解析了資料庫設計過程、設計技巧以及總結了資料庫命名規范……
3. 選擇鍵和索引(資料庫邏輯設計)
參考：《SQL優化-索引》一文
4. 數據完整性設計(資料庫邏輯設計)
1) 完整性實現機制：
實體完整性：主鍵
參照完整性：
父表中刪除數據：級聯刪除;受限刪除;置空值
父表中插入數據：受限插入;遞歸插入
父表中更新數據：級聯更新;受限更新;置空值
DBMS對參照完整性可以有兩種方法實現：外鍵實現機制(約束規則)和觸發器實現機制用戶定義完整性：
NOT NULL;CHECK;觸發器
2) 用約束而非商務規則強制數據完整性
採用資料庫系統實現數據的完整性。這不但包括通過標准化實現的完整性而且還包括數據的功能性。不要依賴於商務層保證數據完整性;它不能保證表之間(外鍵) 的完整性所以不能強加於其他完整性規則之上。如果你在數據層確實採用了約束，你要保證有辦法把更新不能通過約束檢查的原因採用用戶理解的語言通知用戶界面。
3) 強制指示完整性
在有害數據進入資料庫之前將其剔除。激活資料庫系統的指示完整性特性。這樣可以保持數據的清潔而能迫使開發人員投入更多的時間處理錯誤條件。
4) 使用查找控制數據完整性
控制數據完整性的最佳方式就是限制用戶的選擇。只要有可能都應該提供給用戶一個清晰的價值列表供其選擇。這樣將減少鍵入代碼的錯誤和誤解同時提供數據的一致性。某些公共數據特別適合查找：國家代碼、狀態代碼等。
5) 採用視圖
為了在資料庫和應用程序代碼之間提供另一層抽象，可以為應用程序建立專門的視圖而不必非要應用程序直接訪問數據表。這樣做還等於在處理資料庫變更時給你提供了更多的自由。
6) 分布式數據系統
對分布式系統而言，在你決定是否在各個站點復制所有數據還是把數據保存在一個地方之前應該估計一下未來 5 年或者 10 年的數據量。當你把數據傳送到其他站點的時候，最好在資料庫欄位中設置一些標記，在目的站點收到你的數據之後更新你的標記。為了進行這種數據傳輸，請寫下你自己的批處理或者調度程序以特定時間間隔運行而不要讓用戶在每天的工作後傳輸數據。本地拷貝你的維護數據，比如計算常數和利息率等，設置版本號保證數據在每個站點都完全一致。
7) 關系
如果兩個實體之間存在多對一關系，而且還有可能轉化為多對多關系，那麼你最好一開始就設置成多對多關系。從現有的多對一關系轉變為多對多關系比一開始就是多對多關系要難得多。
8) 給數據保有和恢復制定計劃
考慮數據保存策略並包含在設計過程中，預先設計你的數據恢復過程。採用可以發布給用戶/開發人員的數據字典實現方便的數據識別同時保證對數據源文檔化。編寫在線更新來「更新查詢」供以後萬一數據丟失可以重新處理更新。
9) 用存儲過程讓系統做重活
提供一整套常規的存儲過程來訪問各組以便加快速度和簡化客戶程序代碼的開發。資料庫不只是一個存放數據的地方，它也是簡化編碼之地。
本文詳細解析了資料庫設計過程、設計技巧以及總結了資料庫命名規范……
5. 其他設計技巧
1) 避免使用觸發器
觸發器的功能通常可以用其他方式實現。在調試程序時觸發器可能成為干擾。假如你確實需要採用觸發器，你最好集中對它文檔化。
2) 使用常用英語(或者其他任何語言)而不要使用編碼
在創建下拉菜單、列表、報表時最好按照英語名排序。假如需要編碼，可以在編碼旁附上用戶知道的英語。
3) 保存常用信息
讓一個表專門存放一般資料庫信息非常有用。在這個表裡存放資料庫當前版本、最近檢查/修復(對Access)、關聯設計文檔的名稱、客戶等信息。這樣可以實現一種簡單機制跟蹤資料庫，當客戶抱怨他們的資料庫沒有達到希望的要求而與你聯系時，這樣做對非客戶機/伺服器環境特別有用。
4) 包含版本機制
在資料庫中引入版本控制機制來確定使用中的資料庫的版本。時間一長，用戶的需求總是會改變的。最終可能會要求修改資料庫結構。把版本信息直接存放到資料庫中更為方便。
5) 編制文檔
對所有的快捷方式、命名規范、限制和函數都要編制文檔。
採用給表、列、觸發器等加註釋的 資料庫工具。對開發、支持和跟蹤修改非常有用。
對資料庫文檔化，或者在資料庫自身的內部或者單獨建立文檔。這樣，當過了一年多時間後再回過頭來做第2 個版本，犯錯的機會將大大減少。
6) 測試、測試、反復測試
建立或者修訂資料庫之後，必須用用戶新輸入的數據測試數據欄位。最重要的是，讓用戶進行測試並且同用戶一道保證選擇的數據類型滿足商業要求。測試需要在把新資料庫投入實際服務之前完成。
7) 檢查設計
在開發期間檢查資料庫設計的常用技術是通過其所支持的應用程序原型檢查資料庫。換句話說，針對每一種最終表達數據的原型應用，保證你檢查了數據模型並且查看如何取出數據。
三、資料庫命名規范
1. 實體(表)的命名
1) 表以名詞或名詞短語命名，確定表名是採用復數還是單數形式，此外給表的別名定義簡單規則(比方說，如果表名是一個單詞，別名就取單詞的前4 個字母;如果表名是兩個單詞，就各取兩個單詞的前兩個字母組成4 個字母長的別名;如果表的名字由3 個單片語成，從頭兩個單詞中各取一個然後從最後一個單詞中再取出兩個字母，結果還是組成4 字母長的別名，其餘依次類推)
對工作用表來說，表名可以加上前綴WORK_ 後面附上採用該表的應用程序的名字。在命名過程當中，根據語義拼湊縮寫即可。注意：將欄位名稱會統一成大寫或者小寫中的一種，故中間加上下劃線。
作者: 小靈, 出處:論壇, 責任編輯: 李書琴, 2007-09-27 15:17
本文詳細解析了資料庫設計過程、設計技巧以及總結了資料庫命名規范……
舉例：
定義的縮寫 Sales: Sal 銷售;
Order: Ord 訂單;
Detail: Dtl 明細;
則銷售訂單明細表命名為：Sal_Ord_Dtl;
2) 如果表或者是欄位的名稱僅有一個單詞，那麼建議不使用縮寫，而是用完整的單詞。
舉例：
定義的縮寫 Material Ma 物品;
物品表名為：Material, 而不是 Ma.
但是欄位物品編碼則是：Ma_ID;而不是Material_ID
3) 所有的存儲值列表的表前面加上前綴Z
目的是將這些值列表類排序在資料庫最後。
4) 所有的冗餘類的命名(主要是累計表)前面加上前綴X
冗餘類是為了提高資料庫效率，非規范化資料庫的時候加入的欄位或者表
5) 關聯類通過用下劃線連接兩個基本類之後，再加前綴R的方式命名,後面按照字母順序羅列兩個表名或者表名的縮寫。
關聯表用於保存多對多關系。
如果被關聯的表名大於10個字母，必須將原來的表名的進行縮寫。如果沒有其他原因，建議都使用縮寫。
舉例：表Object與自身存在多對多的關系,則保存多對多關系的表命名為：R_Object;
作者: 小靈, 出處:論壇, 責任編輯: 李書琴, 2007-09-27 15:17
本文詳細解析了資料庫設計過程、設計技巧以及總結了資料庫命名規范……
2. 屬性(列)的命名
1) 採用有意義的列名
表內的列要針對鍵採用一整套設計規則。每一個表都將有一個自動ID作為主健,邏輯上的主健作為第一組候選主健來定義;
A、如果是資料庫自動生成的編碼，統一命名為：ID
B、如果是自定義的邏輯上的編碼則用縮寫加「ID」的方法命名，即「XXXX_ID」
C、如果鍵是數字類型，你可以用_NO 作為後綴;
D、如果是字元類型則可以採用_CODE 後綴
E、對列名應該採用標準的前綴和後綴。
舉例：銷售訂單的編號欄位命名：Sal_Ord_ID;如果還存在一個資料庫生成的自動編號，則命名為：ID。
2) 所有的屬性加上有關類型的後綴
注意，如果還需要其它的後綴，都放在類型後綴之前。
注: 數據類型是文本的欄位，類型後綴TX可以不寫。有些類型比較明顯的欄位，可以不寫類型後綴。
3) 採用前綴命名
給每個表的列名都採用統一的前綴，那麼在編寫SQL表達式的時候會得到大大的簡化。這樣做也確實有缺點，比如破壞了自動表連接工具的作用，後者把公共列名同某些資料庫聯系起來。
3. 視圖的命名
1) 視圖以V作為前綴，其他命名規則和表的命名類似;
2) 命名應盡量體現各視圖的功能。
4. 觸發器的命名(盡量不使用)
觸發器以TR作為前綴，觸發器名為相應的表名加上後綴，Insert觸發器加'_I'，Delete觸發器加'_D'，Update觸發器加'_U'，如：TR_Customer_I，TR_Customer_D，TR_Customer_U。
5. 存儲過程名
存儲過程應以'UP_'開頭，和系統的存儲過程區分，後續部分主要以動賓形式構成，並用下劃線分割各個組成部分。如增加代理商的帳戶的存儲過程為'UP_Ins_Agent_Account'。
6. 變數名
變數名採用小寫，若屬於片語形式，用下劃線分隔每個單詞，如@my_err_no。
7. 命名中其他注意事項
1) 以上命名都不得超過30個字元的系統限制。變數名的長度限制為29(不包括標識字元@)。
2) 數據對象、變數的命名都採用英文字元，禁止使用中文命名。絕對不要在對象名的字元之間留空格。
3) 小心保留詞，要保證你的欄位名沒有和保留詞、資料庫系統或者常用訪問方法沖突
4) 保持欄位名和類型的一致性，在命名欄位並為其指定數據類型的時候一定要保證一致性。假如數據類型在一個表裡是整數，那在另一個表裡可就別變成字元型了。
D. 資料庫設計是指設計資料庫管理系統嗎
不是；前者是設計應用，後者是設計軟體怎麼開發。
資料庫設計(Database Design)是指對於一個給定的應用環境，構造最優的資料庫模式，建立資料庫及其應用系統。
使之能夠有效地存儲數據，滿足各種用戶的應用需求（信息要求和處理要求）。在資料庫領域內，常常把使用資料庫的各類系統統稱為資料庫應用系統。
資料庫管理系統(Database Management System)是一種操縱和管理資料庫的大型軟體，用於建立、使用和維護資料庫，簡稱DBMS。
它對資料庫進行統一的管理和控制，以保證資料庫的安全性和完整性。用戶通過DBMS訪問資料庫中的數據，資料庫管理員也通過dbms進行資料庫的維護工作。
它可使多個應用程序和用戶用不同的方法在同時或不同時刻去建立，修改和詢問資料庫。
大部分DBMS提供數據定義語言DDL（Data Definition Language）和數據操作語言DML（Data Manipulation Language）。
供用戶定義資料庫的模式結構與許可權約束，實現對數據的追加、刪除等操作。
(4)活動管理資料庫設計擴展閱讀：
資料庫設計是建立資料庫及其應用系統的技術，是信息系統開發和建設中的核心技術。
由於資料庫應用系統的復雜性，為了支持相關程序運行，資料庫設計就變得異常復雜，因此最佳設計不可能一蹴而就。
而只能是一種「反復探尋，逐步求精」的過程，也就是規劃和結構化資料庫中的數據對象以及這些數據對象之間關系的過程。
需求分析：
調查和分析用戶的業務活動和數據的使用情況，弄清所用數據的種類、范圍、數量以及它們在業務活動中交流的情況，確定用戶對資料庫系統的使用要求和各種約束條件等，形成用戶需求規約。
需求分析是在用戶調查的基礎上，通過分析，逐步明確用戶對系統的需求，包括數據需求和圍繞這些數據的業務處理需求。
在需求分析中，通過自頂向下，逐步分解的方法分析系統，分析的結果採用數據流程圖(DFD)進行圖形化的描述。
概念設計：
對用戶要求描述的現實世界(可能是一個工廠、一個商場或者一個學校等)，通過對其中諸處的分類、聚集和概括，建立抽象的概念數據模型。
這個概念模型應反映現實世界各部門的信息結構、信息流動情況、信息間的互相制約關系以及各部門對信息儲存、查詢和加工的要求等。
所建立的模型應避開資料庫在計算機上的具體實現細節，用一種抽象的形式表示出來。
以擴充的實體—（E-R模型）聯系模型方法為例，第一步先明確現實世界各部門所含的各種實體及其屬性、實體間的聯系以及對信息的制約條件等。
從而給出各部門內所用信息的局部描述(在資料庫中稱為用戶的局部視圖)。第二步再將前面得到的多個用戶的局部視圖集成為一個全局視圖，即用戶要描述的現實世界的概念數據模型。
資料庫管理系統是一種操縱和管理資料庫的大型軟體，用於建立、使用和維護資料庫，簡稱 DBMS。它對資料庫進行統一的管理和控制，以保證資料庫的安全性和完整性。
資料庫管理系統是一個能夠提供數據錄入、修改、查詢的數據操作軟體，具有數據定義、數據操作、數據存儲與管理、數據維護、通信等功能，且能夠允許多用戶使用。
另外，資料庫管理系統的發展與計算機技術發展密切相關。而且近年來，計算機網路逐漸成為人們生活的重要組成部分。
為此，若要進一步完善計算機資料庫管理系統，技術人員就應當不斷創新、改革計算機技術，並不斷拓寬計算機資料庫管理系統的應用范圍，從而真正促進計算機資料庫管理系統技術的革新。
技術特點：
（1）採用復雜的數據模型表示數據結構，數據冗餘小，易擴充，實現了數據共享。
（2）具有較高的數據和程序獨立性，資料庫的獨立性有物理獨立性和邏輯獨立性。
（3）資料庫系統為用戶提供了方便的用戶介面。
（4）資料庫系統提供4個方面的數據控制功能，分別是並發控制、恢復、完整性和安全性。
資料庫中各個應用程序所使用的數據由資料庫系統統一規定，按照一定的數據模型組織和建立，由系統統一管理和集中控制。
（5）增加了系統的靈活性。
參考資料來源：網路-資料庫設計
網路-資料庫管理系統
E. 資料庫設計步驟求解
資料庫設計步驟：1規劃 2需求分析 3概念設計 4邏輯結構設計 5資料庫的物理設計 6資料庫的實現 7資料庫的運行與維護
第一步，規劃。規劃階段的主要任務是進行建立資料庫的必要性及可行性分析。如系統調查（即對企業全面調查，畫出組織層次圖，以了企業組織結構），可行性分析，確定DBS（資料庫系統）的總目標和制定項目開發計劃。
第二步，需求分析。需求分析階段應該對系統的整個應用情況作全面的、詳細的調查，確定企業組織的目標，收集支持系統總的設計目標的基礎數據和對這些數據的要求，確定用戶的需求，並把這些要求寫成用戶和資料庫設計者都能夠接受的需求分析報告。這一階段的工作只要有，分析用戶活動，產生業務流程圖；確定系統范圍，產生體統范圍圖；分析用戶活動涉及的數據，產生數據流程圖；分析系統數據，產生數據字典。
第三步，概念設計。概念設計的目標是產生反應企業組織信息需求的資料庫概念結構,即設計出獨立與計算機硬體和DBMS（資料庫管理系統）的概念模式。E-R模型是主要設計工具。
第四步，邏輯結構設計。其目的是把概念設計階段設計好的全局E-R模式轉換成與選用的具體機器上的DBMS所支持的數據模型相符合的邏輯結構（包括資料庫模式和外模式）。
第五步，資料庫的物理設計。對於給定的數據模型選取一個最適合應用應用環境的物理結構的過程。資料庫的物理結構主要指資料庫的存儲記錄格式、存儲記錄安排和存取方法，完全依賴於給定的硬體環境赫爾資料庫產品。
第六步，資料庫的實現。該階段主要有3項工作：1建立實際資料庫結構 2裝入試驗數據對應用程序進行調試 3裝入實際數據，進入試運行狀態。
第七步，資料庫的運行與維護。資料庫系統的正式運行，標志著資料庫設計與應用開發工作的結束和維護階段的開始，該階段有4項任務：1維護資料庫的安全性與完整性 2監測並改善資料庫運行性能 3根據用戶要求對資料庫現有功能進行擴充 4及時改正運行中發現的系統錯誤。
其實裡麵包含有其他的知識，我沒列出來，例如E-R圖繪制方法，SQL，還有會涉及關鍵字，外鍵，視圖，表，模式等，如果是想自學的話，我推薦一本書《資料庫原理及應用》，這是我學資料庫時的教材，有疑問，可以hi我，我盡我所能回答你吧。
F. 資料庫課程設計實例
資料庫課程設計
題目：小型超市管理系統
1、項目計劃
1.1系統開發目的
（1）大大提高超市的運作效率；
（2）通過全面的信息採集和處理，輔助提高超市的決策水平；
（3）使用本系統，可以迅速提升超市的管理水平，為降低經營成本， 提高效益，增強超市擴張力， 提供有效的技術保障。
1.2背景說明
21世紀，超市的競爭也進入到了一個全新的領域，競爭已不再是規模的競爭，而是技術的競爭、管理的競爭、人才的競爭。技術的提升和管理的升級是超市業的競爭核心。零售領域目前呈多元發展趨勢，多種業態：超市、倉儲店、便利店、特許加盟店、專賣店、貨倉等相互並存。如何在激烈的競爭中擴大銷售額、降低經營成本、擴大經營規模，成為超市營業者努力追求的目標。
1.3項目確立
針對超市的特點，為了幫助超市解決現在面臨的問題，提高小型超市的競爭力，我們將開發以下系統：前台POS銷售系統、後台管理系統，其中這兩個子系統又包含其它一些子功能。
1.4應用范圍
本系統適應於各種小型的超市。
1.5 定義
（1）商品條形碼：每種商品具有唯一的條形碼，對於某些價格一樣的商品，可以使用自定義條形碼。
（2）交易清單：包括交易的流水賬號、每類商品的商品名、數量、該類商品的總金額、交易的時間、負責本次收銀的員工號。
（3）商品積壓：在一定時期內，遠無法完成銷售計劃的商品會造成積壓。
（4）促銷：在一定時期內，某些商品會按低於原價的促銷價格銷售。
庫存告警提示：當商品的庫存數量低於庫存報警數量時發出提示。
（5）盤點：計算出庫存、銷售額、盈利等經營指標。
1.6 參考資料
《資料庫原理及設計》 陶宏才編 清華大學出版社
《SQL Server 2000 實用教程》范立南編 清華大學出版社
《SQL Server 2000 編程員指南》李香敏編 北京希望電子出版社
《輕松搞定 SQL Server 2000 程序設計》Rebecca M.Riordan編
《軟體工程規范》Watts S.Humphrey編 清華大學出版社
《軟體工程理論與實踐》 Shari Lawrence Pfleeger編 清華大學出版社
《軟體需求分析》 Swapna Kishore編 機械工業出版社
《軟體工程思想》 林銳編
2、邏輯分析與詳細分析
2.1系統功能
（1）、零售前台（POS）管理系統，本系統必須具有以下功能：
商品錄入：根據超巿業務特點制定相關功能，可以通過輸入唯一編號、掃描條形碼、商品名稱等來實現精確或模糊的商品掃描錄入。該掃描錄入方法可以充分保證各種電腦操作水平層次的人員均能准確快速地進行商品掃描錄入。
收銀業務：通過掃描條形碼或者直接輸入商品名稱（對於同類多件商品採用一次錄入加數量的方式）自動計算本次交易的總金額。在顧客付款後，自動計算找零，同時列印交易清單（包括交易的流水賬號、每類商品的商品名、數量、該類商品的總金額、交易的時間、負責本次收銀的員工號）。如果顧客是本店會員並持有本人會員卡，則在交易前先掃描會員卡，並對所購物品全部實行95折優惠，並將所購物品的總金額累計到該會員的總消費金額中。 會員卡的有效期限為一年，滿一年未續卡者，該會員卡將被注銷。
安全性：OS登陸、退出、換班與操作鎖定等許可權驗證保護；斷電自動保護最大限度防止意外及惡意非法操作。
獨立作業：有的斷網收銀即在網路伺服器斷開或網路不通的情況下，收銀機仍能正常作業
(2)、後台管理系統，本系統必須具備以下功能
進貨管理： 根據銷售情況及庫存情況，自動制定進貨計劃（亦可手工制定修改），可以避免盲目進貨造成商品積壓。 按計劃單有選擇性地進行自動入庫登記。 綜合查詢列印計劃進貨與入庫記錄及金額。
銷售管理： 商品正常銷售、促銷與限量、限期及禁止銷售控制。 綜合查詢各種銷售明細記錄、各地收銀員收銀記錄以及交結賬情況等。 按多種方式統計生成銷售排行榜，靈活察看和列印商品銷售日、月、年報表。
庫存管理： 綜合查詢庫存明細記錄。 庫存狀態自動告警提示。如庫存過剩、少貨、缺貨等。軟體為您預警，避免庫存商品積壓損失和缺貨。 庫存自動盤點計算。
人員管理： 員工、會員、供貨商、廠商等基本信息登記管理。 員工操作許可權管理。 客戶銷售許可權管理。
（3）系統結構
系統總體結構
模塊子系統結構
功能描述：商品錄入子系統要求能快速錄入商品，因此必須支持條形碼掃描。
功能描述：收銀業務子系統能計算交易總額，列印交易清單，並根據會員卡打折。
功能描述：進貨管理子系統可以根據庫存自動指定進貨計劃，進貨時自動等級，以及提供查詢和列印計劃進貨與入庫記錄的功能。
功能描述：銷售管理子系統可以控制某商品是否允許銷售，查詢每種商品的銷售情況並產生年、月、日報表，同時可以生成銷售排行榜。
功能描述：庫存管理子系統提供查詢庫存明細記錄的基本功能，並根據庫存的狀態報警，以及自動盤點計算。
功能描述：人員管理子系統提供基本信息登記管理，員工操作許可權管理，客戶銷售許可權管理的功能。
2.2、流程圖
前台管理系統
頂層DFD圖
第0層DFD圖
第1層DFD圖
2.3、戶類型與職能
（1）、員工（營業員）：
通過商品條形碼掃描輸入商品到購買清單
操作軟體計算交易總金額
操作軟體輸出交易清單
對會員進行會員卡掃描以便打折
（2）、：超市經理
操作軟體錄入商品，供貨商，廠商
操作軟體制定進貨計劃
查詢列印計劃進貨與入庫記錄
操作軟體控制商品銷售與否
查詢列印銷售情況
操作軟體生成銷售排行榜
查詢庫存明細記錄
根據軟體發出的庫存告警進行入貨
操作軟體進行盤點計算
（3）、總經理：
基本信息登記管理
員工操作許可權管理
客戶銷售許可權管理
2.4、統開發步驟
確定參與者和相關的用況
為每個用況設計過程
建立順序圖，確定每個腳本中對象的協作
創建類，確定腳本中的對象
設計, 編碼, 測試, 集成類
為過程編寫系統測試案例
運行測試案例，檢驗系統
2.5、系統環境需求
系統模式
本系統採用C/S模式作為開發模式
硬體環境
伺服器端：
高性能的計算機一台，
普通的雙絞線作為連接。
客戶端： 普通的計算機或者工作站，
普通的雙絞線作為連接。
軟體環境
伺服器端：安裝SQL Server 2000的伺服器版本，
安裝windows 2000伺服器版本，
配置了諾頓等必須的防毒軟體。
客戶端： 安裝SQL Server2000的伺服器版本，
安裝了VB等可視化開發工具軟體，
安裝windows2000伺服器版本。
2.6、系統安全問題
信息系統盡管功能強大，技術先進，但由於受到自身體系結構，設計思路以及運行機制等限制，也隱含許多不安全因素。常見因素有：數據的輸入，輸出，存取與備份，源程序以及應用軟體，資料庫，操作系統等漏洞或缺陷，硬體，通信部分的漏洞，企業內部人員的因素，病毒，「黑客」等因素。因此，為使本系統能夠真正安全，可靠，穩定地工作，必須考慮如下問題：為保證安全，不致使系統遭到意外事故的損害，系統因該能防止火，盜或其他形式的人為破壞。
系統要能重建
系統應該是可審查的
系統應能進行有效控制，抗干擾能力強
系統使用者的使用許可權是可識別的
3、基於UML的建模
3.1語義規則
用例模型（use cases view）（用例視圖）的基本組成部件是用例（use case）、角色(actor)和系統(system)。用例用於描述系統的功能，也就是從外部用戶的角度觀察，系統應支持哪些功能，幫助分析人員理解系統的行為，它是對系統功能的宏觀描述，一個完整的系統中通常包含若干個用例，每個用例具體說明應完成的功能，代表系統的所有基本功能（集）。角色是與系統進行交互的外部實體，它可以是系統用戶，也可以是其它系統或硬體設備，總之，凡是需要與系統交互的任何東西都可以稱作角色。系統的邊界線以內的區域（即用例的活動區域）則抽象表示系統能夠實現的所有基本功能。在一個基本功能（集）已經實現的系統中，系統運轉的大致過程是：外部角色先初始化用例，然後用例執行其所代表的功能，執行完後用例便給角色返回一些值，這個值可以是角色需要的來自系統中的任何東西。
UML：是一種標準的圖形化建模語言，它是面向對象分析與設計的一種標准表示；它不是一種可視化的程序設計語言而是一種可視化的建模語言；不是工具或知識庫的規格說明而是一種建模語言規格說明是一種表示的標准；不是過程也不是方法但允許任何一種過程和方法使用它。
用例（use case）：
參與者（actor）：
3.2、UML模型
3.21、系統UML模型
3.22、子系統UML模型
（1）零售前台（POS）管理系統用例視圖
（2）後台管理系統用例視圖
3.3、系統實現圖
4、超市銷售系統概念設計文檔
（1）、系統ER圖
（2）、系統ER圖說明
1) 商店中的所有用戶（員工）可以銷售多種商品，每種商品可由不同用戶（員工）銷售；
2) 每個顧客可以購買多種商品，不同商品可由不同顧客購買；
3) 每個供貨商可以供應多種不同商品，每種商品可由多個供應商供應。
（3）、視圖設計
1) 交易視圖(v_Dealing)——用於查詢交易情況的視圖；
2) 計劃進貨視圖(v_PlanStock)——用於查詢進貨計劃的視圖；
3) 銷售視圖(v_Sale)——用於查詢銷售明細記錄的視圖；
4) 入庫視圖(v_Stock)——用於查詢入庫情況的視圖。
5、邏輯設計文檔
（1）、系統關系模型
a) 商品信息表（商品編號，商品名稱，價格，條形碼，促銷價格，促銷起日期，促銷止日期，允許打折，庫存數量，庫存報警數量，計劃進貨數，允許銷售，廠商編號，供貨商編號）
b) 用戶表（用戶編號，用戶名稱，用戶密碼，用戶類型）
c) 會員表（會員編號，會員卡號，累積消費金額，注冊日期）
d) 銷售表（銷售編號，商品編號，銷售數量，銷售金額，銷售日期）
e) 交易表（交易編號，用戶名稱，交易金額，會員卡號，交易日期）
f) 進貨入庫表（入庫編號，入庫商品編號，入庫數量，單額，總額，入庫日期，計劃進貨日期，入庫狀態）
g) 供貨商表（供貨商編號，供貨商名稱，供貨商地址，供貨商電話）
h) 廠商表（廠商編號，廠商名稱，廠商地址，廠商電話）
（2）、系統資料庫表結構
資料庫表索引
表名 中文名
MerchInfo 商品信息表
User 用戶表
Menber 會員表
Sale 銷售表
Dealing 交易表
Stock 進貨入庫表
Provide 供貨商表
Factory 廠商表
商品信息表(MerchInfo)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
MerchID int 4 P Not null 商品編號
MerchName Varchar 50 Not null 商品名稱
MerchPrice Money 4 Not null 價格
MerchNum Int 4 Not null 庫存數量
CautionNum Int 4 Not null 庫存報警數量
PlanNum Int 4 null 計劃進貨數
BarCode Varchar 50 Not null 條形碼
SalesProPrice Money 4 促銷價格
SalesProDateS Datetime 8 促銷起日期
SalesProDateE Datetime 8 促銷止日期
AllowAbate Int 4 Not null 允許打折
AllowSale Int 4 Not null 允許銷售
FactoryID Varchar 10 F Not null 廠商編號
ProvideID Varchar 10 F Not null 供貨商編號
用戶表(User)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
UserID varchar 10 P Not null 用戶編號
UserName Varchar 25 Not null 用戶名稱
UserPW Varchar 50 Not null 用戶密碼
UserStyle Int 4 Not null 用戶類型
會員表(Menber)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
MemberID Varchar 10 P Not null 會員編號
MemberCard Varchar 20 Not null 會員卡號
TotalCost Money 4 Not null 累積消費金額
RegDate Datetime 8 Not null 注冊日期
銷售表(Sale)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
SaleID Varchar 10 P Not null 銷售編號
MerChID Varchar 10 F Not null 商品編號
SaleDate Datetime 8 Not null 銷售日期
SaleNum Int 4 Not null 銷售數量
SalePrice Money 4 Not null 銷售單額
交易表(Dealing)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
DealingID Varchar 10 P Not null 交易編號
DealingPrice Money 4 Not null 交易金額
DealingDate Money 4 Not null 交易日期
MemberID Varchar 10 會員卡號
UserName Varchar 10 F Not null 用戶名稱
入庫紀錄表(Stock)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
StockID Varchar 10 P Not null 入庫編號
MerchID Varchar 10 F Not null 入庫商品編號
MerchNum Int 4 Not null 入庫數量
MerchPrice Money 4 Not null 單額
TotalPrice Money 4 Not null 總額
StockDate Datetime 8 Datetime 入庫日期
PlanDate Datetime 8 Datetime 計劃進貨日期
StockState Int 4 Not null 入庫狀態
供貨商表(Provide)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
ProvideID varchar 10 P Not null 供貨商編號
ProvideName Varchar 50 Not null 供貨商名稱
ProvideAddress Varchar 250 供貨商地址
ProvidePhone Varchar 25 供貨商電話
廠商表(Provide)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
FactoryID varchar 10 P Not null 廠商編號
FactoryName Varchar 50 Not null 廠商名稱
FactoryAddress Varchar 250 廠商地址
FactoryPhone Varchar 25 廠商電話
6、物理設計文檔
/*----------創建資料庫----------*/
create database SuperMarketdb
on primary
(
name=SuperMarketdb,
filename='C:\Program Files\Microsoft SQL Server\MSSQL\Data\SuperMarketdb.mdf',
size=100MB,
maxsize=200MB,
filegrowth=20MB
)
log on
(
name=SuperMarketlog,
filename='C:\Program Files\Microsoft SQL Server\MSSQL\Data\SuperMarketdb.ldf',
size=60MB,
maxsize=200MB,
filegrowth=20MB
)
go
/*----------創建基本表----------*/
use [SuperMarketdb]
go
/*創建交易表*/
CREATE TABLE Dealing (
DealingID int identity(1,1) Primary key ,
DealingDate datetime NOT NULL ,
DealingPrice money NOT NULL ,
UserName varchar(25) NULL ,
MemberCard varchar(20) NULL
)
GO
/*創建廠商表*/
CREATE TABLE Factory (
FactoryID varchar(10) Primary key ,
FactoryName varchar(50) NOT NULL ,
FactoryAddress varchar(250) NULL ,
FactoryPhone varchar(50) NULL
)
GO
/*創建會員表*/
CREATE TABLE Member (
MemberID varchar(10) Primary key ,
MemberCard varchar(20) NOT NULL ,
TotalCost money NOT NULL ,
RegDate datetime NOT NULL
)
GO
/*創建商品信息表*/
CREATE TABLE MerchInfo (
MerchID int identity(1,1) Primary key ,
MerchName varchar(50) Unique NOT NULL ,
MerchPrice money NOT NULL ,
MerchNum int NOT NULL ,
CautionNum int NOT NULL ,
PlanNum int NOT NULL ,
BarCode varchar(20) Unique NOT NULL ,
SalesProPrice money NULL ,
SalesProDateS datetime NULL ,
SalesProDateE datetime NULL ,
AllowAbate int NOT NULL ,
AllowSale int NOT NULL ,
FactoryID int NOT NULL ,
ProvideID int NOT NULL
)
GO
/*創建供應商表*/
CREATE TABLE Provide (
ProvideID varchar(10) Primary key ,
ProvideName varchar(50) NOT NULL ,
ProvideAddress varchar(250) NULL ,
ProvidePhone varchar(25) NULL
)
GO
/*創建銷售表*/
CREATE TABLE Sale (
SaleID int identity(1,1) Primary key ,
MerChID int NOT NULL ,
SaleDate datetime NOT NULL ,
SaleNum int NOT NULL,
SalePrice money NOT NULL
)
GO
/*創建入庫表*/
CREATE TABLE Stock (
StockID int identity(1,1) Primary key ,
MerchID int NOT NULL ,
MerchNum int NOT NULL ,
MerchPrice money NULL ,
TotalPrice money NULL ,
PlanDate datetime NULL ,
StockDate datetime NULL,
StockState int NOT NULL
)
GO
/*創建用戶表*/
CREATE TABLE User (
UserID varchar(10) Primary key ,
UserName varchar(25) NOT NULL ,
UserPW varchar(50) NOT NULL ,
UserStyle int NOT NULL ,
)
GO
/*----------創建表間約束----------*/
/*商品信息表中廠商編號、供應商編號分別與廠商表、供應商表之間的外鍵約束*/
ALTER TABLE MerchInfo ADD
CONSTRAINT [FK_MerchInfo_Factory] FOREIGN KEY
(
[FactoryID]
) REFERENCES Factory (
[FactoryID]
),
CONSTRAINT [FK_MerchInfo_Provide] FOREIGN KEY
(
[ProvideID]
) REFERENCES Provide (
[ProvideID]
)
GO
/*銷售表中商品編號與商品信息表之間的外鍵約束*/
ALTER TABLE Sale ADD
CONSTRAINT [FK_Sale_MerchInfo] FOREIGN KEY
(
[MerChID]
) REFERENCES MerchInfo (
[MerchID]
) ON DELETE CASCADE
GO
/*入庫表中商品編號與商品信息表之間的外鍵約束*/
ALTER TABLE Stock ADD
CONSTRAINT [FK_Stock_MerchInfo] FOREIGN KEY
(
[MerchID]
) REFERENCES MerchInfo (
[MerchID]
) ON DELETE CASCADE
GO
/*----------創建索引----------*/
/*在交易表上建立一個以交易編號、交易日期為索引項的非聚集索引*/
CREATE nonclustered INDEX IX_Dealing ON Dealing(DealingID, DealingDate)
GO
/*在商品信息表上建立一個以商品編號為索引項的非聚集索引*/
CREATE nonclustered INDEX IX_MerchInfo ON MerchInfo(MerchID)
GO
/*在銷售表上建立一個以銷售編號、銷售日期為索引項的非聚集索引*/
CREATE nonclustered INDEX IX_Sale ON Sale(SaleID, SaleDate)
GO
/*在入庫表上建立一個以入庫編號、入庫日期、商品編號為索引項的非聚集索引*/
CREATE nonclustered INDEX IX_Stock ON Stock(StockID, StockDate, MerchID)
GO
/*----------創建視圖----------*/
/*創建用於查詢交易情況的視圖*/
CREATE VIEW v_Dealing
AS
SELECT DealingDate as 交易日期,
UserName as 員工名稱,
MemberCard as 會員卡號,
DealingPrice as 交易金額
FROM Dealing
GO
/*創建用於查詢進貨計劃的視圖*/
CREATE VIEW v_PlanStock
AS
SELECT Stock.StockID as SID,
MerchInfo.MerchName as 商品名稱,
MerchInfo.BarCode as 條形碼,
Factory.FactoryName as 廠商,
Provide.ProvideName as 供貨商,
Stock.MerchNum as 計劃進貨數量,
Stock.PlanDate as 計劃進貨日期
FROM Stock,MerchInfo,Provide,Factory
Where Stock.MerchID = MerchInfo.MerchID
and Provide.ProvideID=MerchInfo.ProvideID
and Factory.FactoryID=MerchInfo.FactoryID
and Stock.StockState=0
GO
/*創建用於查詢銷售明細記錄的視圖*/
CREATE VIEW v_Sale
AS
SELECT MerchInfo.MerchName as 商品名稱,
MerchInfo.BarCode as 條形碼,
MerchInfo.MerchPrice as 商品價格,
Sale.SalePrice as 銷售價格,
Sale.SaleNum as 銷售數量,
Sale.SaleDate as 銷售日期
FROM Sale INNER JOIN
MerchInfo ON Sale.MerChID = MerchInfo.MerchID
GO
/*創建用於查詢入庫情況的視圖*/
CREATE VIEW v_Stock
AS
SELECT MerchInfo.MerchName as 商品名稱,
MerchInfo.BarCode as 條形碼,
Factory.FactoryName as 廠商,
Provide.ProvideName as 供貨商,
Stock.MerchPrice as 入庫價格,
Stock.MerchNum as 入庫數量,
Stock.TotalPrice as 入庫總額,
Stock.StockDate as 入庫日期
FROM Stock,MerchInfo,Provide,Factory
Where Stock.MerchID = MerchInfo.MerchID
and Provide.ProvideID=MerchInfo.ProvideID
and Factory.FactoryID=MerchInfo.FactoryID
and Stock.StockState=1
GO
7、小結
和傳統管理模式相比較，使用本系統，毫無疑問會大大提高超市的運作效率，輔助提高超市的決策水平，管理水平，為降低經營成本， 提高效益，減少差錯，節省人力，減少顧客購物時間，增加客流量，提高顧客滿意度，增強超市擴張能力， 提供有效的技術保障。
由於開發者能力有限，加上時間倉促，本系統難免會出現一些不足之處，例如：
本系統只適合小型超市使用，不能適合中大型超市使用；
超市管理系統涉及范圍寬，要解決的問題多，功能復雜，實現困難，但由於限於時間，本系統只能做出其中的一部分功能；
對於以上出現的問題，我們深表歉意，如發現還有其它問題，希望老師批評指正。
G. 教你輕松掌握數據倉庫的規劃和構建策略
教你輕松掌握數據倉庫的規劃和構建策略
數據倉庫作為決策支持系統（DSS）的基礎，具有面向主題的、集成的、不可更新的、隨時間不斷變化的特性。這些特點說明了數據倉庫從數據組織到數據處理，都與原來的資料庫有很大的區別，這也就需要在數據倉庫系統設計時尋求一個適合於數據倉庫設計的方法。在一般的系統開發規劃中，首先需要確定系統的功能，這些系統的功能一般是通過對用戶的需求分析得到的。從數據倉庫的應用角度來看，DSS分析員一般是企業中的中高層管理人員，他們對決策支持的需求不能預先做出規范的說明，只能給設計人員一個抽象地描述。
這就需要設計人員在與用戶不斷的交流溝通中，將系統的需求逐步明確，並加以完善。因此數據倉庫的開發規劃過程實際上是一個用戶和設計人員對其不斷了解、熟悉和完善的過程。 數據倉庫的開發應用規劃是開發數據倉庫的首要任務。只有制定了正確的數據倉庫規劃，才能使組織主要力量有序地實現數據倉庫的開發應用。在數據倉庫規劃中一般需要經歷這樣幾個過程：選擇實現策略、確定數據倉庫的開發目標和實現范圍、選擇數據倉庫體系結構、建立商業和項目規劃預算。 當數據倉庫規劃完成後，需要編制相應的數據倉庫規劃說明書，說明數據倉庫與企業戰略的關系，以及與企業急需處理的、范圍相對有限的開發機會，重點支持的職能部門和今後數據倉庫開發工作的建議，實際使用方案和開發預算，作為數據倉庫實際開發的依據。
1、選擇數據倉庫實現策略
數據倉庫的開發策略主要有自頂向下、自底向上和這兩種策略的聯合使用。自頂向下策略在實際應用中比較困難，因為數據倉庫的功能是一種決策支持功能。這種功能在企業戰略的應用范圍中常常是很難確定的，因為數據倉庫的應用機會往往超出企業當前的實際業務范圍，而且在開發前就確定目標，會在實現預定目標後就不再追求新的應用，是數據倉庫喪失更有戰略意義的應用。由於該策略在開發前就可以給出數據倉庫的實現范圍，能夠清楚地向決策者和企業描述系統的收益情況和實現目標，因此是一種有效的數據倉庫開發策略。該方法使用時需要開發人員具有豐富的自頂向下開發系統的經驗，企業決策層和管理人員完全知道數據倉庫的預定目標並且了解數據倉庫能夠在那些決策中發揮作用。
自底向上策略一般從某個數據倉庫原型開始，選擇一些特定的為企業管理人員所熟知的管理問題作為數據倉庫開發的對象，在此基礎上進行數據倉庫的開發。因此，該策略常常用於一個數據集市、一個經理系統或一個部門的數據倉庫開發。該策略的優點在於企業能夠以較小的投入，獲得較高的數據倉庫應用收益。在開發過程中，人員投入較少，也容易獲得成效。當然，如果某個項目的開發失敗可能造成企業整個數據倉庫系統開發的延遲。該策略一般用於企業洗碗對數據倉庫的技術進行評價，以確定該技術的應用方式、地點和時間，或希望了解實現和運行數據倉庫所需要的各種費用，或在數據倉庫的應用目標並不是很明確時，數據倉庫對決策過程影響不是很明確時使用。
在自頂向下的開發策略中可以採用結構化或面向對象的方法，按照數據倉庫的規劃、需求確定、系統分析、系統設計、系統集成、系統測試和系統試運行的階段完成數據倉庫的開發。而在自底向上的開發中，則可以採用螺旋式的原型開發方法，使用戶可以根據新的需求對試運行的系統進行修改。螺旋式的原型開發方法要求在較短的時間內快速的生成可以不斷增加功能的數據倉庫系統，這種開發方法主要適合於這樣一些場合：在企業的市場動向和需求無法預測，市場的時機是實現產品的重要組成部分，不斷地改進對與企業的市場調節是必需的；持久的競爭優勢來自連續不斷地改進，系統地改進是基於用戶在使用中的不斷發現。 自頂向下和自底向上策略的聯合使用具有兩種策略的優點，既能快速的完成數據倉庫的開發與應用，還可建立具有長遠價值的數據倉庫方案。但在實踐中往往難以操作，通常需要能夠建立、應用和維護企業模型、數據模型和技術結構的、具有豐富經驗的開發人員，能夠熟練的從具體（如業務系統中的元數據）轉移到抽象（只基於業務性質而不是基於實現系統技術的邏輯模型）；企業需要擁有由最終用戶和信息系統人員組成的有經驗的開發小組，能夠清楚地指出數據倉庫在企業戰略決策支持中的應用。
2、確定數據倉庫的開發目標和實現范圍
為確定數據倉庫的開發目標和實現范圍，首先需要對企業管理者等數據倉庫用戶解釋數據倉庫在企業管理中的應用和發展趨勢，說明企業組織和使用數據來支持跨功能系統的重要性，對企業經營戰略的支持，以確定開發目標。在該階段確認與使用數據倉庫有關的業務要求，這些要求應該只支持最主要的業務職能部門，將使用精力集中在收益明顯的業務上，使數據倉庫的應用立即產生效果，不應該消耗太多的精力在各個業務上同時鋪開數據倉庫的應用。
在確定開發目標和范圍以後，應該編制需求文檔，作為今後開發數據倉庫的依據。 數據倉庫開發的首要目標是確定所需要信息的范圍，確定用戶提供決策幫助時，在主題和指標域需要哪些數據源。這就需要定義：用戶需要什麼數據？面向主題的數據倉庫需要什麼樣的支持數據？為成功地向用戶提交數據，開發人員需要哪些商業知識？哪些背景知識？這就需要定義整體需求，以文件的形式整理現存的記錄系統和系統環境，對使用數據倉庫中數據的候選應用系統進行標識、排序，構造一個傳遞模型，確定尺度、事實及時間標記演算法，以便從系統中抽取信息且將他們放入數據倉庫。通過信息范圍確定可為開發人員提供一個良好的分析平台，和用戶一起分析哪些信息是數據倉庫需要的，進行商業活動需要什麼數據。開發人員可以和用戶進一步定義需要，例如數據分級層次、聚合的層次、載入的頻率以及需要保持的時間表等。 數據倉庫開發的另一個重要目標是確定利用哪些方法和工具訪問和導航數據？雖然用戶都需要存取並且檢索數據倉庫的內容，但是所存取的粒度有所不同，有的可能是詳細的記錄，有的可能是比較概括的記錄或十分概括的記錄。用戶要求的數據概括程度不同，將導致數據倉庫的聚集和概括工具的需求不同。
數據倉庫還有具有一定功能來訪問和檢索圖表、預定義的報表、多維數據、概括性數據和詳細記錄。用戶從數據倉庫中獲得信息，應該有電子表格、統計分析器和支持多維分析的分析處理器等工具的支持，以解釋和分析數據倉庫中的內容，產生並且驗證不同的市場假設、建議和決策方案。為將決策建議和各種決策方案向用戶清楚地表達出來，需要利用報表、圖表和圖像等強有力的信息表達工具。 數據倉庫開發的其他目標，是確定數據倉庫內部數據的規模。在數據倉庫中不僅包含當前數據，而且包含多年的歷史數據。數據的概括程度決定了這些數據壓縮和概括的最大限度。如果要讓數據倉庫提供對歷史記錄進行決策查詢的功能，就必須支持對大量數據的管理。數據的規模不僅直接影響決策查詢的時間，而且還將直接影響企業決策的質量。
在數據倉庫的開發目標中，還有：根據用戶對數據倉庫的基本需求，確定數據倉庫中數據的含義；確定數據倉庫內容的質量，以確定使用、分析和建議的可信級別；哪種類型的數據倉庫可以滿足最終用戶的需求，這些數據倉庫應該具有怎樣的功能；需要哪些元數據，如何使用數據源中的數據等。 數據倉庫的開發目標多種多樣，十分復雜，需要開發人員和用戶在開發與使用的過程中不斷交互完善。因此，在規劃中需要確定數據倉庫的開發范圍。使開發人員能夠根據需求和目標的重要性逐步進行，並且在開發中吸取經驗教訓，為數據倉庫在企業中的全部實現提供技術准備。因此，在為數據倉庫確定總體開發方向和目標以後，就必須確定一個有限的能夠很快體現數據倉庫效益的使用范圍。在考慮數據倉庫苦的應用范圍時，主要從使用部門的數量和類型、數據源的數量、企業模型的子集、預算分配以及開發項目所需的時間等角度分析。
在分析這些因素時，可從用戶的角度和技術的角度兩方面進行。 從用戶的角度應該分析哪些部門最先使用數據倉庫？是哪些人員為了什麼目的使用數據倉庫？以及數據倉庫首先要滿足哪些決策查詢？因為這些決策查詢往往確定了關於數據維數、報表的種類，這些因素都將確定數據倉庫定義時所需要的數量關系。查詢的格式越具體，越容易提供數據倉庫的維數、聚集和概括的規劃說明。 從技術角度分析，應該確定數據倉庫中元資料庫的規模，數據倉庫的元資料庫是存儲數據倉庫中數據定義的模型。數據定義存儲在倉庫管理器的目錄中，可以作為所有查詢和報表工具構造和查詢數據倉庫的依據。元資料庫的規模直接表示了數據倉庫中必須管理的數據規模。通過對元資料庫規模的管理，實際上就確定了數據倉庫中所需要管理的數據規模。
3、數據倉庫的結構選擇
數據倉庫的結構可以進行靈活的選擇，可將組織所使用的各種平台進行恰當的分割，把數據源、數據倉庫和最終用戶使用的工作站分割開來進行恰當的設計。
（1）數據倉庫的應用結構
基於業務處理系統的數據倉庫 在這種結構中，將運作的數據用於無需修改數據的只讀應用程序中。具有這種結構的數據倉庫元資料庫是一種虛庫，而不是數據倉庫自身的元數據。在數據倉庫元資料庫的直接指導下，對數據倉庫的查詢就是簡單的從資料庫中抽取數據。
單純數據倉庫
利用在數據倉庫中的數據源凈化、集成、概括和集成等操作，將數據源從業務處理系統中傳輸進集中的數據倉庫，各部門的數據倉庫應用只在數據倉庫中進行。這種結構經常發生在多部門、少用戶使用數據倉庫的情況下。這里的集中僅僅是邏輯上的，物理上可能是分散的。
單純數據集市
數據集市是指在部門中使用的數據倉庫，因為企業中的各個職能部門都有自己的特殊需要，而統一的數據倉庫可能不能滿足這些部門的特殊要求。這種體系結構經常發生在個別部門對數據倉庫的應用感興趣，而組織中其他部門卻對數據倉庫的應用十分冷漠之時，由熱心的部門單獨開發式所採用。
數據倉庫和數據集市
企業各部門擁有滿足自己需要的數據集市，其數據從企業數據倉庫中獲取，而數據倉庫從企業各種數據源中收集和分配。這種體系結構是一種較為完善的數據倉庫體系結構，往往發生在組織整體對數據倉庫應用感興趣之時所採用的體系結構。
（2）數據倉庫的技術平台結構 單層結構
單層結構主要是在數據源和數據倉庫之間共享平台，或者讓數據源、數據倉庫、數據集市與最終用戶工作站使用同一個平台。共享一個平台可以降低數據抽取和數據轉換的復雜性，但是共享平台在應用中可能遇到性能和管理方面的問題，這種體系結構一般在數據倉庫規模較小，而組織的業務系統平台具有較大潛力之時所採用。
客戶/伺服器兩層結構
一層為客戶機，一層為伺服器，最終用戶訪問工具在客戶層上運行，而數據源、數據倉庫和數據集市位於伺服器上，該技術機構一般用於普通規模的數據倉庫。
三層客戶/伺服器結構
基於工作站的客戶層、基於伺服器的中間層和基於主機的第三層。主機層負責管理數據源和可選的源數據轉換；伺服器運行數據倉庫和數據集市軟體，並且存儲倉庫的數據；客戶工作站運行查詢和報表運用程序，且還可以存儲從數據集市或數據倉庫卸載的局部數據。在數據倉庫稍具規模，兩層數據倉庫結構已經不能滿足客戶的需求，要講數據倉庫的數據存儲管理、數據倉庫的應用處理和客戶端應用分開之時，可以採用這種結構。
多層式結構
這是在三層機構基礎上發展起來的數據倉庫結構，在該結構中從最內數據層到最外層的客戶層依次是：單獨的數據倉庫存儲層、對數據倉庫和數據集市進行管理的數據倉庫服務層、進行數據倉庫查詢處理的查詢服務層、完成數據倉庫應用處理的應用服務層和面向最終用戶的客戶層。體系層次可能多達五層，這種體系結構一般用於超規模數據倉庫系統。
4、數據倉庫使用方案和項目規劃預算
數據倉庫的實際使用方案與開發預算，是數據倉庫規劃中最後需要確定的問題。因為數據倉庫主要用於對企業管理人員的決策支持，確保其實用性是十分重要的，因此需要讓最終用戶參與數據倉庫的功能設計。這種參與是通過用戶的實際使用方案進行的，使用方案是一個非常重要的需求模型。實際使用方案必須有助於闡明最終用戶對數據倉庫的要求，這些要求有的只使用適當的數據源就可以得到基本滿足，而有的卻需要來自企業外部的數據源，這就需要通過使用方案將這些不同的要求聯系起來。 實際使用方案還可以將最終用戶的決策支持要求與數據倉庫的技術要求聯系起來。因為當用戶確定最終要求後，為元資料庫的范圍確定一個界限。還可以確定所需要的歷史信息的數量，當根據特定的用戶進行數據倉庫的規劃時，就可確定最終用戶所關心的維度（時間、方位、商業單位和生產企業），因為維度與所需要的概括操作有明顯的關系，必須選擇對最終用戶有實際意義的維度，如：「月」、「季度」、「年」等。最後，還可以確定數據集市/數據倉庫的結構需要，使設計人員確定採用單純數據倉庫結構，還是單純的數據集市結構或者是兩者相結合的結構。
在實際使用開發方案確定後，還需要對開發方案的預算進行估計，確定項目的投資數額。投資方案的確定可以依據以往的軟體開發成本，但是這種預算的評估比較粗糙。另一種方法是參照結構進行成本評估，也就是說，將數據倉庫實際使用方案所確定的構件進行分解，根據各個構件的成本進行預算估算。數據倉庫的構件包含在數據源、數據倉庫、數據集市、最終用戶存取、數據管理、元數據管理、傳輸基礎等部分中，這些構件有的在企業原有信息系統中已經具備，有的可以選擇商品化構件，有的則需要自我開發。根據這些構件的不同來源，可以確定比較准確的預算。 在完成數據倉庫規劃後，就需要編制數據倉庫開發說明書，說明系統與企業戰略目標的關系，以及系統與企業急需處理的范圍相對有限的開發機會，所設想的業務機會的說明以及目標任務概況說明、重點支持的職能部門和今後工作的建議。數據倉庫項目應有明確的業務價值計劃開始，在計劃中需要闡明期望取得的有形和無形的利益。無形利益包含利用數據倉庫使決策完成得更快更好等利益。
業務價值計劃最好由目標業務主管來完成，因為數據倉庫是用戶驅動的，應該讓用戶積極參與數據倉庫的建設，在規劃書中要確定數據倉庫開發目標的實現范圍、體系結構和使用方案及開發預算。
H. SQL Server 資料庫設計
SQL Server 系統資料庫在安裝軟體時自動創建，用於協助系統共同完成對資料庫的操作；也是資料庫運行的基礎；
1，master資料庫
是SQL Server 2012的核心資料庫，如果損壞則資料庫軟體無法運行，主要包含如下主要信息：
1）所有用戶登陸名和用戶ID所屬角色
2）資料庫存儲路徑
3）伺服器中資料庫的名稱和相關信息
4）系統配置設置， SQL Server 初始化信息
2，model資料庫
在創建資料庫時，總是以一套預定義的標准為模板進行創建的。以model資料庫為模板來創建其他資料庫。且model資料庫是tempdb資料庫的基礎。
3，tempdb資料庫
它是一個臨時資料庫，用來存儲用戶建立的臨時表和臨時存儲過程，存儲用戶定義的全局變數值。它存在於SQL Server會話期間，會話結束，則關閉tempdb資料庫，且資料庫丟失。
4，msdb資料庫
用於代理計劃警報和作業
SQL Server 資料庫存儲文件
資料庫文件是由數據文件和事務日誌文件組成。
1，資料庫文件指資料庫中用來存儲資料庫數據和資料庫對象的文件，一個資料庫只能由一個主資料庫文件，擴展名為 .mdf
2, 次資料庫文件包含除主資料庫文件外的所有數據文件，一個資料庫可以沒有次資料庫文件，也可以由多個，擴展名為 .ndf
3, 日誌文件由一系列日誌記錄組成，它記錄了存儲資料庫的更新情況等事務日誌信息，用戶對資料庫進行的插入，刪除，更新都會記錄在日誌文件中。資料庫發生損壞時可根據日誌文件分析出錯原因，或者數據丟失時，使用事務日誌恢復資料庫。每個資料庫至少要有一個日誌文件。
SQL Server 資料庫創建，使用T-SQL語言創建：
使用T-SQL語言刪除資料庫：
SQL Server 資料庫遷移：
方法1：「分離/附加」資料庫，即把資料庫文件（.MDF）和對應的日誌文件（.LDF）拷貝到其它磁碟上作備份，然後把這兩個文件再拷貝到任何需要這個資料庫的系統之中。
分離資料庫就是將某個資料庫從SQL Server資料庫列表中刪除，使其不再被SQL Server管理和使用，但該資料庫的文件（.MDF）和對應的日誌文件（.LDF）完好無損。分離成功後，就可以把該資料庫文件（.MDF）和對應的日誌文件（.LDF）拷貝到其它磁碟中作為備份保存。
分離之前，設置資料庫為單個用戶，並記住該資料庫所在路徑。
「任務」—「分離」
然後分離資料庫頁面選中「更新統計信息」復選框。若「消息」列中沒有顯示存在活動連接，則「狀態」列顯示為「就緒」；否則顯示「未就緒」，此時必須勾選「刪除連接」列的復選框。分離後資源管理器中資料庫消失
將需要附加的資料庫文件和日誌文件拷貝到某個已經創建好的文件夾中。
右擊資料庫對象，並在快捷菜單中選擇「附加」命令，打開「附加資料庫」窗口。
添加—選擇需要附件的資料庫的.MDF文件。「附件為」資料庫名稱可修改。
I. 請問商品活動管理資料庫該怎麼去設計，就是商品有時打折促銷贈送禮品會用到的，我有一個積分規則表，商品
商品表
某化妝品
某電器
某服裝
積分類別表
化妝品積分
普通積分
積分規則表
商品 --> 積分類別 開始時間 結束時間 x系數
化妝品 化妝品積分 2011-1-1 2011-1-29 2 [比如這個是雙倍積分]
化妝品 化妝品積分 2011-1-30 2011-2-10 0 [比如促銷期間不積分]
化妝品 化妝品積分 2011-2-11 2099-12-31 2 [促銷結束後恢復積分]
服裝 普通積分 2011-1-1 2099-12-31 1
會員卡類別
無卡客戶
普通會員卡
金卡
折扣
商品 會員卡類別 開始時間 結束時間 折扣
某化妝品 無卡客戶 2011-1-30 2011-2-10 0.9 [此期間9折]
某化妝品 普通會員卡 2011-1-30 2011-2-10 0.8 [此期間8折]
某化妝品 金卡 2011-1-30 2011-2-10 0.7 [此期間7折]
就給個例子,僅供參考.
J. 資料庫設計主要包括哪幾部分，分別包括哪些內容
資料庫設計主要包括需求分析、概念結構設計、邏輯結構設計、物理結構設計、資料庫的實施和資料庫的運行和維護，具體內容如下：
1、需求分析
內容：調查和分析用戶的業務活動和數據的使用情況，弄清所用數據的種類、范圍、數量以及它們在業務活動中交流的情況，確定用戶對資料庫系統的使用要求和各種約束條件等，形成用戶需求規約。
2、概念設計
內容：對用戶要求描述的現實世界，通過對其中諸處的分類、聚集和概括，建立抽象的概念數據模型。這個概念模型應反映現實世界各部門的信息結構、信息流動情況、信息間的互相制約關系以及各部門對信息儲存、查詢和加工的要求等。
3、邏輯設計
內容：主要工作是將現實世界的概念數據模型設計成資料庫的一種邏輯模式，即適應於某種特定資料庫管理系統所支持的邏輯數據模式。與此同時，可能還需為各種數據處理應用領域產生相應的邏輯子模式。這一步設計的結果就是所謂「邏輯資料庫」。
4、物理設計
內容：根據特定資料庫管理系統所提供的多種存儲結構和存取方法等依賴於具體計算機結構的各項物理設計措施，對具體的應用任務選定最合適的物理存儲結構(包括文件類型、索引結構和數據的存放次序與位邏輯等)、存取方法和存取路徑等。
5、驗證設計
內容：收集數據並具體建立一個資料庫，運行一些典型的應用任務來驗證資料庫設計的正確性和合理性。一般，一個大型資料庫的設計過程往往需要經過多次循環反復。當設計的某步發現問題時，可能就需要返回到前面去進行修改。
6、運行與維護設計
內容：在資料庫系統正式投入運行的過程中，必須不斷地對其進行調整與修改。除了關系型資料庫已有一套較完整的數據範式理論可用來部分地指導資料庫設計之外，尚缺乏一套完善的資料庫設計理論、方法和工具，以實現資料庫設計的自動化或互動式的半自動化設計。
(10)活動管理資料庫設計擴展閱讀：
重要性
1、有利於資源節約
對計算機軟體資料庫設計加以重視不僅可減少軟體後期的維修，達到節約人力與物力的目的，同時還有利於軟體功能的高效發揮。
2、有利於軟體運行速度的提高
高水平的資料庫設計可滿足不同計算機軟體系統對於運行速度的需求，而且還可充分發揮並實現系統功能。計算機軟體性能提高後，系統發出的運行指令在為用戶提供信息時也將更加快速有效，軟體運行速度自然得以提高。
3、有利於軟體故障的減少
加強資料庫設計可有效減少軟體故障的發生幾率，推動計算機軟體功能的實現。