畢業都好多年了 ，大學這教育也太老化了吧 ，每年都是出這么個題來考學生，創新一下會si人的我估計.....
還是勞駕自己開發吧，別對不起你媽交給你的學費！學點對自己沒壞處的！
答案：已刪除！
對於這些話。這位師兄或師姐，允許我這么稱呼你。雖然你的出發點是好的，但是我實在忍不住要說一下。你知道些什麼。既然你說這些教育太老化，每年都是這些題。那麼自己開發，然後就對得起老媽的學費，話說對不對得起我自己知道。我求這份報告並不代表我就是要全抄，我也沒說我一點都不去做。而且。你知道我們課程設計這兩周怎麼過的。web作業要交，弄一個大系統。然後軟體工程五份文檔（每份文檔基本上都要花一星期的實際來弄），然後17周考軟體工程。剛考完。18周考Java.這兩周是課程設計設計，完了。19周還要考計算機組成原理。交這個報告。我們弄web作業幾乎都要熬好幾個通宵來弄。加上還有資料庫的實驗報告以及java的實驗報告。我不認為要一份課程設計報告有什麼錯？你有的話就想發就發。而且你似乎是沒有的。那麼勞駕你不要對我說對不起老媽的學費。對不對得起我自己知道，我媽也知道。OK？雖然你的出發點不知道是不是好的。但是對我來說不需要。。。不然還要網路知道來幹嘛。。。。嗯~沒有，看到你的評論我有點火大。所以一不小心就打了那麼長。況且怎麼都好。就算最後沒得交也好。我也覺得沒關系。。。好了~睡覺了。呼呼~
⑵ 100分高分求sql語言的資料庫實驗報告...
以下是日期的查詢
簡單的例子
select
*
from
View_Change
where
Wname='AAAA'
select
*
from
View_Change
where
Updatetime>'2007-10-13'
下面是統計
select
Wno,Count(Wnum)
as
統計
from
View_Change
where
Updatetime>'2007-10-13'
group
by
Wno
如果改為復雜點點的統計的話
select
Wno,Count(Wnum)
as
統計
from
View_Change
where
Updatetime>='2008-01-01'
and
Updatetime<'2009-01-01'
and
Wno=1
and
Type='出庫'
group
by
Wno
ftp://220.184.188.33/
裡面的幾個文檔案就是創建的過程
我也好久沒做過了
都忘記了
大部分都是企業管理器內做的
⑶ sql資料庫課程設計報告
網路即時通信系統是為用戶開發研製的，用戶是系統的最終使用者和評價者，所以在網路通信系統的開發設計的過程中，我們樹立了從用戶的尋求出發，面向用戶，一切為了用戶的觀念，在分析與設計系統的前期，為了保證系統的功能的完善多次尋求周圍同學和老師的意見，了解他們的要求，依照功能完善，界面美觀，操作簡單的原則進行設計 。
嚴格按階段進行
系統的開發設計是一項較大的工程，所以應該將整個系統的開發設計過程劃分為若干階段，相應的階段又要分為若干個不同的步驟，每個階段和步驟都要有明確的工作任務和目標。這種有序的組織安排，條例清楚、層次分明，便於計劃的制定和控制，並且為後續工作的進行奠定了堅實的基礎，提高了工作效率和質量。
採用系統的觀點處理
在系統分析階段，在對原系統進行全面調查和分析的基礎上，構造系統的最佳邏輯模型，使用戶對將來完整系統的輪廓有個初步的了解和認識，以便及時和用戶進行交流和探討，不斷提高系統的完善性。在此基礎上進行系統的物理實現和設計，切實完成邏輯模型的具體功能。邏輯設計和物理實現二者是相輔相成、密不可分的，這樣使系統的設計更加穩妥合理。
整個系統的設計主要採用快速原形法
快速原形法是信息系統設計的一個重要方法。它是根據用戶提出的需求，由用戶和開發者共同確定系統的基本要求和主要功能，並在一個較短的時間內建立一個實驗性的、簡單的信息系統模型，通過用戶不斷提出的意見和建議，對模型進行不斷的修改和完善，直到用戶比較滿意為止，以便形成一個相對穩定、較為理想的管理信息系統。該方法的主要優點。
1.脈絡清楚，所有問題都圍繞一個模型展開，使彼此之間聯系緊密。
2.有助於發現用戶需求，通過對原形和用戶接觸，能夠啟發開發人員去挖掘問題，從而不斷的修正、完善，最終得到一個理想的系統。
3.系統開發效率高，此方法的開發周期短、使用靈活、容易修改，這對於管理體制不夠穩定的系統更加適合。
4.系統的可擴展性好，由於此方法是在原型應用中不斷發展完善和修改的，所以有較強的擴展性。
在進行代碼設計時，遵循了以下原則。
唯一性：在本系統中，每一個代碼都和系統中的每一個對象唯一確定。
標准性：主要體現在對程序文件名命名和對數據文件命名的標准化上，遵循簡單扼要，方便適用的原則。一目瞭然，無重復現象。為了系統維護人員便於進行系統維護，使用了統一的標准。
合理性：系統中代碼設計與編碼對象的分類相適應，以使代碼對編碼對象的分類據有標志作用。
簡單性：在設計過程中採用Code-Behind代碼分離，使資料庫操作代碼和前端調用代碼分離，頁面修改容易。
適應性：在代碼設計過程中，代碼反映了編碼對象的特點，便於識別和記憶，使系統維護人員容易了解和掌握，便於進行維護工作。
系統總體功能結構
網路通信系統包含以下主要功能。
用戶注冊；用戶登錄；
查找好友；查看好友資料；
添加好友；
刪除好友；
發送消息；
發送文件.
資料庫表主要用來存放用戶的注冊信息和用戶的好友資料，可利用兩張資料庫表來 存放用戶信息和用戶好友的資料。包括用戶的號碼，昵稱，密碼，在線與否，ip地址，資料，頭像號，性別，E-mail和籍貫等信息。其中，用戶昵稱和密碼是必需的欄位；在線與否是由系統自動設置的；其餘的信息是可選的欄位。
課題整體以JAVA為平台，採用Eclipse開發工具，並使用SQL Server 2000管理資料庫數據開發而成的基於Socket的集中式網路通信系統，系統採用客戶機/伺服器（C/S）的模式設計，是一個三層C/S結構，資料庫伺服器、應用程序伺服器端 、應用程序客戶端。系統採用C/S結構，可以將任務合理分配到客戶機端和伺服器端 ，從而降低了系統的通信開銷。
客戶層。
客戶層是應用程序的用戶介面部分，它擔負著用戶與應用間的對話功能，用於檢查用戶的輸入數據，顯示應用的輸出數據，為了直觀的進行操作，客戶層需要使用圖形用戶介面，若聊天用戶變更，系統只需改寫顯示控制和數據檢查程序即可，而不會影響其他兩層。
服務層。（功能層）
服務層相當於應用的本體，它是將具體的業務處理邏輯編入程序中。在應用設計中，必須避免在表示層和功能層之間進行多次的數據交換，這就需要盡可能進行一次性的業務處理達到優化整體設計的目的。
數據層
數據層是DBMS，本系統使用了Microsoft 公司的SQL Ssever2000資料庫伺服器來管理數據。SQL Ssever2000能迅速的執行大量數據的更新和檢索，因此，從功能層傳送到數
據層的要求一般都使用SQL語言。
⑷ sql 資料庫設計報告 最少20頁怎麼寫啊
我不知道你是否用過powerdesigner這個工具，這個工具有個文檔生成功能，只要你把資料庫建模建好，一鍵導出，很方便，不過用英文版，導出的都是英文。。而且，裡面的內容實在是有點冗餘。
⑸ 求一份SQL server資料庫課程設計報告
2.2需求分析
（1）需求分析的任務
需求分析的任務是通過詳細調查現實世界要處理的對象（組織、部門、企業等），充分了解原系統（手工系統或計算機系統）工作概況，明確用戶的各種需求，用通俗的話來講，就是分析了解用戶關心什麼，用戶需要什麼樣的結果，然後在此基礎上分析和設計新系統的資料庫。
需求分析的重點是調查、收集與分析用戶在數據管理中的信息要求、處理要求、安全性與完整性要求。
信息要求
是指用戶需要從資料庫中獲得信息的內容與性質。由用戶的信息要求可以導出數據要求，即在資料庫中需要存儲哪些數據。
處理要求
是指用戶要求完成什麼處理功能，對處理的響應時間有什麼要求，處理方式是批處理還是聯機處理。
安全性與完整性要求
一是指用戶對系統和數據有什麼安全性要求，如不同級別的用戶具有什麼操作許可權和使用哪些數據；二是對數據的輸入和存儲的什麼要求，如數據的長度和范圍、數據的有效性、一致性和唯一性等。
確定用戶的最終需求其實是一件很困難的事，這是因為一方面用戶缺少計算機知識，開始時無法確定計算機究竟能為自己做什麼，不能做什麼，因此無法一下子准確地表達自己的需求，他們所提出的需求往往不斷地變化。另一方面設計人員缺少用戶的專業知識，不易理解用戶的真正需求，甚至誤解用戶的需求。因此設計人員必須與用戶不斷深入地進行溝通和交流，才能逐步得以確定用戶的實際需求。
（2）需求分析的基本步驟
1．調查與初步分析用戶的需求，確定系統的功能邊界
⑴首先調查組織機構情況
⑵然後調查各部門的業務活動情況
⑶協助用戶明確對新系統的各種要求
⑷確定新系統的結構和功能邊界，確定哪些功能由計算機完成或將來由計算機完成，哪些活動由人工完成。
常用的調查方法有：
⑴跟班作業
⑵開調查會
⑶請專人介紹
⑷詢問
⑸問卷調查
⑹查閱記錄
2．生成數據字典
1）數據項條目：數據項是不可再分的數據單位，它直接反映事物的某一特徵。
2）數據結構條目：反映了數據之間的組合關系。
3）數據流條目：數據流是數據結構在系統內傳輸的路徑。
4）數據文件條目：數據文件是數據項停留或保存的地方，也是數據流的來源和去向之一。
5）處理過程條目。
(3) 案例分析：教學管理系統資料庫的需求分析
用戶的需求具體體現在各種信息的提供、保存、更新和查詢上，這就要求資料庫的結構能充分滿足各種信息的輸出和輸入。需求分析階段主要是收集基本數據，確定數據結構及數據處理的流程，組成一份詳盡的數據字典，以便為後面的概念設計和邏輯設計打下基礎。
2．3概念結構設計
概念結構設計是對收集來的信息和數據進行分析整理，確定實體、屬性及聯系，形成獨立於計算機的反映用戶觀點的概念模型。概念設計的重點在於信息結構的設計，它是整個資料庫系統設計的關鍵。
（1）概念結構設計的目標和任務
概念結構設計的目標是產生反映系統信息需求的資料庫概念結構，即概念模式。概念結構是獨立於DBMS和使用的硬體環境的。在這一階段，設計人員要從用戶的角度看待數據以及數據處理的要求和約束，產生一個反映用戶觀點的概念模式，然後再把概念模式轉換為邏輯模式。
概念模型的表示方法很多，其中最著名、最常用的表示方法為實體-聯系方法，這種方法也稱為E-R模型方法，該方法採用E-R圖描述概念模型。
E-R圖提供了表示實體、屬性和聯系的方法，它由以下三個組件構成：
實體---用矩形表示，矩形框內寫明實體名。
屬性---用橢圓形表示，並用無向邊將其與相應的實體連接起來。
聯系---用菱形表示，菱形框內寫明聯系名，並用無向邊分別與有關實體連接起來，同時在無向邊旁標上聯系的類型（1:1、1:n或m:n）。
例如教學管理系統中的學生實體與課程實體的E-R圖如下圖表示：
（2）概念結構設計的過程
●數據抽象
概念結構是對現實世界的一種抽象，所謂抽象就是對實際的人、事、物和概念進行加工處理，抽取所關心的共同特性，用各種概念精確的加以描述，組成某種模型。
在需求分析中，已初步得到了有關各類實體、實體間的聯系以及描述它們性質的數據元素，統稱數據對象。
在這一階段中，首先要從以上數據對象中找出：系統有哪些實體？每個實體有哪些屬性？哪些實體間存在聯系？每一種聯系有哪些屬性？然後就可以做出系統的局部E-R模型和全局E-R模型。
● 局部E-R模型設計
局部E-R模型設計是從數據流圖出發確定實體和屬性，並根據數據流圖中表示的對數據的處理、確定實體之間的聯系。
設計局部E-R圖的步驟是：
1．確定實體類型和屬性
實體和屬性之間沒有嚴格的區別界限，但對於屬性來講，可以用下面的兩條准則作為依據：
1）作為屬性必須是不可再分的數據項，也就是屬性中不能再包含其他的屬性。
2）屬性不能與其他實體之間具有聯系。
2．確定實體間的聯系
依據需求分析結果，考察任意兩個實體類型之間是否存在聯系，若有，則確定其類型（一對一，一對多或多對多）。
3．畫出局部E-R圖
確定了實體及實體間的聯系後，可用E-R圖描述出來。形成局部E-R圖之後，還必須返回去徵求用戶意見，使之如實地反映現實世界，同時還要進一步規范化，以求改進和完善。每個局部E-R圖必須滿足：
（1）對用戶需求是完整的。
（2）所有實體、屬性、聯系都有惟一的名字。
（3）不允許有異名同義、同名異義的現象。
● 全局E-R模型的設計
各個局部E-R模型建立好後，還需要對它們進行合並，集成為一個整體的數據概念結構，即總E-R圖。在合並全局E-R模型時，應注意檢查和消除屬性、命名的沖突及數據冗餘。
（3）案例分析：教學管理系統資料庫的概念結構設計
通過上面的需求分析，就可以進行資料庫的概念結構設計，先對現實當中的人、事、物和概念進行抽象的加工處理，抽取所關心的共同特性，用各種概念進行描述，從中找出能夠滿足用戶需求的各種實體，以及它們之間的關系，並用實體-聯系圖表示出來(即畫出E-R圖)，為後面的邏輯結構設計打下基礎。
1、確定實體及其屬性
經過對人工進行的教學管理系統的業務調查，得知系統主要涉及以下幾個實體：
● 學生實體：屬性主要包括班級名稱、學號、姓名、性別、出生日期、民族、政治面貌、來源地、入學成績、學生類別、電話、備注等。
● 教師實體：屬性主要包括教師號、教師姓名、性別、出生日期、所在系、職稱
● 班級實體：屬性主要包括系部名稱、班級號、班級名稱、班主任、學生人數、備注等。
● 系部實體：屬性主要包括系號、系部名稱、班級數等。
● 課程實體：屬性主要包括課程號、課程名、考核方式、學分、學時數等。
2、確定實體之間的聯系
2．4 邏輯結構設計
（1）邏輯結構設計的目標和任務
邏輯結構設計的目標就是把概念結構設計階段設計好的E-R圖轉換為特定的DBMS所支持的數據模型(即層次、網狀、關系模型之一)，並對其進行優化。
概念模型向邏輯模型的轉換過程分為3步進行：
（1）把概念模型轉換為一般的數據模型。
（2）將一般的數據模型轉換成特定的DBMS所支持的數據模型。
（3）通過優化方法將其轉化為優化的數據模型。
(2) 概念模型轉換為一般的關系模型
1．實體的轉換規則
將E-R圖中的每一個常規實體轉換為一個關系，實體的屬性就是關系的屬性，實體的碼就是關系的碼。
2．實體間聯系的轉換規則
1）一個1：1聯系可以轉換為各自獨立的關系模式，也可以與任意一端所對應的關系模式合並。
2）一個1 : n聯系可以轉換為各自獨立的關系模式。
3）一個m : n聯系轉換為一個關系模式。轉換的方法為：與該聯系相連的各實體的碼以及聯系本身的屬性均轉換為關系的屬性，新關系的碼為兩個相連實體碼的組合
(3) 案例分析：教學管理系統資料庫的邏輯結構設計
邏輯結構設計的任務是把概念結構設計階段設計好的E-R圖轉換為特定的DBMS所支持的數據模型(即層次、網狀、關系模型之一)，並對其進行優化，得到滿足用戶要求和系統功能需求的關系模式。
1、 E-R模型轉換為關系模式
將E-R模型轉換成初始關系模式的一般規則是：系統中各個實體轉換為對應的關系模式；實體之間多對多的聯系也轉換為關系模式。
根據轉換規則，可以將系部、班級、學生、教師、課程五個實體轉換成與之對應的五個關系模式；而將學生與課程兩者之間多對多的選修關系以及教師、班級和課程三者之間多對多的開課關系也轉換為關系模式。
2、關系模式的設計
根據上述的轉換結果，在對關系模式中數據進行規范化處理後，得到了符合第三範式的關系模式如下：
學生：{學號、姓名、性別、出生日期、民族、政治面貌、來源地、入學成績、學生類別、班級名稱、電話、備注}
班級：{班級號、班級名稱、班主任、學生人數、系部名稱、備注}
系部：{系號、系部名稱、班級數}
教師：{教師號、教師姓名、性別、出生日期、所在系、職稱}
課程：{課程號、課程名、考核方式、學分、學時數}
選修：{學號、課程號、成績}
開課： {教師號、班級名稱、課程號、開課學期、授課地點}
每個關系模式中帶下劃線的屬性或屬性的組合表示主鍵、帶雙波浪線的屬性表示與之關聯的表的外鍵。
根據系統功能需求，數據採用SQL Server 2000所支持的實際數據模型，也就是資料庫的邏輯結構。啟動SQL Server 2000，創建一個資料庫命名為:jxgl。該資料庫中各個數據表的結構如下面各個表格所示。每個表格對應於資料庫中的一個表。
3、將關系模式轉換為資料庫中的表
按照關系數據模型的結構，將關系模式轉換為關系資料庫中的數據表，轉換的規則是：一個關系模式轉換為一個數據表，關系模式中的每個屬性轉換為數據表中的一個列。同時設置表中各個列的名稱、數據類型、數據寬度以及數據規則，得到如下幾個表：
學生表(student)
列名 類型 寬度 規則
班級名稱 CHAR 20 內容取自班級信息表的班級名稱
學號 CHAR 10 主鍵、長度為10個字元
姓名 CHAR 8
性別 CHAR 2 非空、只能取「男」或「女」
出生日期 DATETIME
民族 CHAR 4 假定只能取以下之一：漢、壯、白、回、苗、滿、其它
政治面貌 CHAR 4 只能取以下之一：黨員、團員、群眾
來源地 CHAR 10
入學成績 INT
學生類別 CHAR 10 假定只能取以下之一：本科、大專（普）、大專（業）、中專、技校、函授、其它
電話 CHAR 11
備注 CHAR 10
註：(1)該表存放全校所有學生的基本信息，每個學生產生一條記錄。
(2)學號的前4位表示年級，第5--8位表示班級號(其中第5-6位表示系號, 第7-8位表示系內班級號)，最後兩位是班內的學生編號，在輸入記錄內容時應加以區分。
班級表(class)
列名 類型 寬度 規則
系部名稱 CHAR 10 非空、內容取自系部信息表的系部名稱
班級號 CHAR 4 非空、長度為4個字元
班級名稱 CHAR 20 主鍵
班主任 CHAR 8
學生人數 INT
備注 CHAR 10
註：(1)該表存放全校所有班級的信息，每個班級產生一條記錄。
(2)班級號的前2位表示系號，後兩位為系內的班級編號，在輸入記錄內容時應加以區分。
系部表(department)
列名 類型 寬度 規則
系號 CHAR 2 非空、長度為2個字元
系部名稱 CHAR 10 主鍵
班級數 INT
註：該表存放某校所有的系部信息，每個系部產生一條記錄。
教師表(teacher)
列名 類型 寬度 規則
教師號 CHAR 4 主鍵、長度為4個字元
姓名 CHAR 8
性別 CHAR 2 非空、只能取「男」或「女」
出生日期 DATETIME
職稱 CHAR 6 只能取以下之一：教授、副教授、講師、助教、其他
所在系 CHAR 20 非空、外鍵(內容取自系部表的系部名稱)
課程表(course)
列名 類型 寬度 規則
課程號 CHAR 4 主鍵、長度為4個字元
課程名 CHAR 20
考核方式 CHAR 4 假定只能取以下之一：考試、考查、其他
學分 INT 非空
學時數 INT
註：該表存放某校所有的課程信息，每門課產生一條記錄。
成績表(SC)
列名 類型 寬度 規則
學號 CHAR 8 主鍵、內容取自學生信息表的學生姓名
課程號 CHAR 20 主鍵、內容取自課程信息表的課程名稱
成績 INT
註：該表存放某校所有學生的成績信息，每個學生學習每門課程產生一條記錄。
開課信息表(tcc)
列名 類型 寬度 規則
教師號 CHAR 4 主鍵、內容取自教師信息表的教師號
課程號 CHAR 4 主鍵、內容取自課程信息表的課程號
班級號 CHAR 4 主鍵、內容取自班級信息表的班級號
開課學期 CHAR 20
授課地點 CHAR 20
註：該表存放某校開設課程的信息，每個教師教授某個班級的某門課產生一條記錄。
2. 5 物理設計
資料庫的物理設計目標是在選定的DBMS上建立起邏輯設計結構確立的資料庫結構，這一過程也稱為資料庫的物理實現。它主要包括兩項工作：
一是根據資料庫的結構、系統的大小、系統需要完成的功能及對系統的性能要求，決定選用哪個資料庫管理系統。目前，資料庫產品市場上比較好的產品有：Microsoft SQL Server、Oracle、IBM DB/2，SYBASE等。
二是根據選用的資料庫管理系統的資料庫實現方法來建立用戶資料庫，即創建所需要的資料庫、表及其他資料庫對象。
本系統選用的DBMS是SQL Server 2000，並在該系統上創建用戶資料庫jxgl以及下屬的7個用戶表：student、class、department、teacher、course、sc、tcc，各個表的結構按2.4節第3點各表給出的具體內容設定。
2. 5 實訓二
以小組討論的形式，完成人事工資管理系統用戶資料庫的設計，要求個人寫出用戶資料庫設計的文檔（包括資料庫的需求分析、概念設計、邏輯設計和物理設計，表達方法可參考本章相應內容的案例分析部分），每個小組上交一份本系統用戶資料庫包括的數據表。
第三章 資料庫的數據完整性設計
3．1數據完整性的基本概念及內容
正確創建資料庫後，需要考慮數據的完整性、數據的安全性等要求。數據的完整性主要指數據的正確性、有效性、相容性，強制實施數據完整性可以確保資料庫中的數據的質量。
進行數據完整性設計主要考慮以下幾個方面的內容：
1)表名惟一；
由系統強制實施控制。
2)列名惟一；()
由系統強制實施控制。
3)數據行惟一；
通過設置主鍵約束或觸發器來實施控制。
4)列值非空；
通過設置非空約束來實施控制。
5)列值惟一性
通過設置惟一約束或惟一索引來實施控制。
6)列值滿足一定的條件
通過設置檢查約束或觸發器來實施控制。
7)數據的一致性和有效性
通過設置外鍵約束或觸發器來實施控制。
至於具體要對資料庫的哪一個表的哪一項數據進行什麼樣的數據完整性設計，還應根據用戶的需求來考慮和確定。
3．2 數據完整性的分類與實現方法
在SQL Server關系資料庫中，數據完整性分為以下三類：
1. 域完整性
域完整性是指一個列的輸入有效性，是否允許空值。實現域完整性的方法主要有：限制數據類型（通過設定列的數據類型）、限定格式（通過CHECK約束和規則）或可能值的范圍（通過 FOREIGN KEY 約束、CHECK 約束、DEFAULT定義、NOT NULL定義和規則）以及程序控制。
2. 實體完整性
實體完整性是指保證表中所有的行唯一。實現實體完整性的方法主要有：索引、UNIQUE約束、PRIMARY KEY約束或 IDENTITY屬性以及程序控制。
3. 參照完整性
參照完整性也叫引用完整性。參照完整性確保主鍵（被引用表）和外鍵（引用表）之間的參照關系。它涉及兩個或兩個以上表數據的一致性維護。如student表(稱為引用表、參照表或子表)的class_id列就是參照class表(稱為被引用表、被參照表或父表)的外鍵。參照完整性可以實現以下兩種控制：
(1)存在外鍵時，被參照表中的這一行不能被刪除，主鍵值也不能改變 (以student和class表的「班級名稱」列為例說明)。
(2)若在被參照表中不存在包含相應主鍵的行時，一個外鍵值不能插入參照表中(MsgBox "添加記錄成功！", vbOKOnly + vbInformation, "提示"
End Sub
Private Sub Command5_Click()
rs.Close
Unload Me
End Sub
Private Sub Form_Load()
rs.CursorLocation = adUseClient ' 設置在客戶端創建游標
rs.CursorType = adOpenKeyset '設置游標類型為鍵集類型
rs.LockType = adLockOptimistic '設置打開記錄集時的鎖定類型為樂觀鎖，在執行UPdate方法前不鎖定編輯的數據
rs.Open "select * from teacher", cnn
'在表格上顯示class表的記錄內容
Set DataGrid1.DataSource = rs
DataGrid1.Refresh
'將表格上的數據與文本框或下拉列表框綁定
Set Text1.DataSource = rs
Text1.DataField = "教師號"
Set Text2.DataSource = rs
Text2.DataField = "姓名"
Set Combo1.DataSource = rs
Combo1.DataField = "所在系"
Set Text3.DataSource = rs
Text3.DataField = "出生日期"
Set Text4.DataSource = rs
Text4.DataField = "從教日期"
Set Combo2.DataSource = rs
Combo2.DataField = "性別"
Set Combo3.DataSource = rs
Combo3.DataField = "職稱"
Set Combo4.DataSource = rs
Combo4.DataField = "政治面貌"
Set Combo5.DataSource = rs
Combo5.DataField = "學歷"
Set Text7.DataSource = rs
Text7.DataField = "家庭住址"
Set Text5.DataSource = rs
Text5.DataField = "聯系電話"
Set Text6.DataSource = rs
Text6.DataField = "備注"
'下拉列表框提供班級名稱
Combo1.Clear
rs1.Open "select 系部名稱 from department", cnn
While Not rs1.EOF()
Combo1.AddItem Trim(rs1.Fields("系部名稱"))
rs1.MoveNext
Wend
rs1.Close
End Sub
對其餘幾個表的數據進行增、刪、改操作的窗體的設計方法與上述類擬。
⑹ SQL實訓設計資料庫和設計報告
For
a
description
of
your
SQL
training
and
design
report
design
database，
還有別的要求么,可以與我們聯系,
給我留一個你的問題和Email,
有可能幫你，不過絕對救急,
請用BaiHi為我留言,
此回復針對所有來訪者和需求者有效,
ES:\\
⑺ sql資料庫設計
一、資料庫設計過程
資料庫技術是信息資源管理最有效的手段。資料庫設計是指對於一個給定的應用環境，構造最優的資料庫模式，建立資料庫及其應用系統，有效存儲數據，滿足用戶信息要求和處理要求。
資料庫設計中需求分析階段綜合各個用戶的應用需求（現實世界的需求），在概念設計階段形成獨立於機器特點、獨立於各個DBMS產品的概念模式（信息世界模型），用E-R圖來描述。在邏輯設計階段將E-R圖轉換成具體的資料庫產品支持的數據模型如關系模型，形成資料庫邏輯模式。然後根據用戶處理的要求，安全性的考慮，在基本表的基礎上再建立必要的視圖（VIEW）形成數據的外模式。在物理設計階段根據DBMS特點和處理的需要，進行物理存儲安排，設計索引，形成資料庫內模式。
1. 需求分析階段
需求收集和分析，結果得到數據字典描述的數據需求（和數據流圖描述的處理需求）。
需求分析的重點是調查、收集與分析用戶在數據管理中的信息要求、處理要求、安全性與完整性要求。
需求分析的方法：調查組織機構情況、調查各部門的業務活動情況、協助用戶明確對新系統的各種要求、確定新系統的邊界。
常用的調查方法有： 跟班作業、開調查會、請專人介紹、詢問、設計調查表請用戶填寫、查閱記錄。
分析和表達用戶需求的方法主要包括自頂向下和自底向上兩類方法。自頂向下的結構化分析方法（Structured Analysis，簡稱SA方法）從最上層的系統組織機構入手，採用逐層分解的方式分析系統，並把每一層用數據流圖和數據字典描述。
數據流圖表達了數據和處理過程的關系。系統中的數據則藉助數據字典（Data Dictionary，簡稱DD）來描述。
數據字典是各類數據描述的集合，它是關於資料庫中數據的描述，即元數據，而不是數據本身。數據字典通常包括數據項、數據結構、數據流、數據存儲和處理過程五個部分(至少應該包含每個欄位的數據類型和在每個表內的主外鍵)。
數據項描述＝｛數據項名，數據項含義說明，別名，數據類型，長度，
取值范圍，取值含義，與其他數據項的邏輯關系｝
數據結構描述＝｛數據結構名，含義說明，組成:｛數據項或數據結構｝｝
數據流描述＝｛數據流名，說明，數據流來源，數據流去向，
組成:｛數據結構｝，平均流量，高峰期流量｝
數據存儲描述＝｛數據存儲名，說明，編號，流入的數據流，流出的數據流，
組成:｛數據結構｝，數據量，存取方式｝
處理過程描述＝｛處理過程名，說明，輸入:｛數據流｝，輸出:｛數據流｝,
處理:｛簡要說明｝｝
2. 概念結構設計階段
通過對用戶需求進行綜合、歸納與抽象，形成一個獨立於具體DBMS的概念模型，可以用E-R圖表示。
概念模型用於信息世界的建模。概念模型不依賴於某一個DBMS支持的數據模型。概念模型可以轉換為計算機上某一DBMS支持的特定數據模型。
概念模型特點：
(1) 具有較強的語義表達能力，能夠方便、直接地表達應用中的各種語義知識。
(2) 應該簡單、清晰、易於用戶理解，是用戶與資料庫設計人員之間進行交流的語言。
概念模型設計的一種常用方法為IDEF1X方法，它就是把實體-聯系方法應用到語義數據模型中的一種語義模型化技術，用於建立系統信息模型。
使用IDEF1X方法創建E-R模型的步驟如下所示:
2.1 第零步——初始化工程
這個階段的任務是從目的描述和范圍描述開始，確定建模目標，開發建模計劃，組織建模隊伍，收集源材料，制定約束和規范。收集源材料是這階段的重點。通過調查和觀察結果，業務流程，原有系統的輸入輸出，各種報表，收集原始數據，形成了基本數據資料表。
2.2 第一步——定義實體
實體集成員都有一個共同的特徵和屬性集，可以從收集的源材料——基本數據資料表中直接或間接標識出大部分實體。根據源材料名字表中表示物的術語以及具有「代碼」結尾的術語，如客戶代碼、代理商代碼、產品代碼等將其名詞部分代表的實體標識出來，從而初步找出潛在的實體，形成初步實體表。
2.3 第二步——定義聯系
IDEF1X模型中只允許二元聯系，n元聯系必須定義為n個二元聯系。根據實際的業務需求和規則，使用實體聯系矩陣來標識實體間的二元關系，然後根據實際情況確定出連接關系的勢、關系名和說明，確定關系類型，是標識關系、非標識關系（強制的或可選的）還是非確定關系、分類關系。如果子實體的每個實例都需要通過和父實體的關系來標識，則為標識關系，否則為非標識關系。非標識關系中，如果每個子實體的實例都與而且只與一個父實體關聯，則為強制的，否則為非強制的。如果父實體與子實體代表的是同一現實對象，那麼它們為分類關系。
2.4 第三步——定義碼
通過引入交叉實體除去上一階段產生的非確定關系，然後從非交叉實體和獨立實體開始標識侯選碼屬性，以便唯一識別每個實體的實例，再從侯選碼中確定主碼。為了確定主碼和關系的有效性，通過非空規則和非多值規則來保證，即一個實體實例的一個屬性不能是空值，也不能在同一個時刻有一個以上的值。找出誤認的確定關系，將實體進一步分解，最後構造出IDEF1X模型的鍵基視圖（KB圖）。
2.5 第四步——定義屬性
從源數據表中抽取說明性的名詞開發出屬性表，確定屬性的所有者。定義非主碼屬性，檢查屬性的非空及非多值規則。此外，還要檢查完全依賴函數規則和非傳遞依賴規則，保證一個非主碼屬性必須依賴於主碼、整個主碼、僅僅是主碼。以此得到了至少符合關系理論第三範式的改進的IDEF1X模型的全屬性視圖。
2.6 第五步——定義其他對象和規則
定義屬性的數據類型、長度、精度、非空、預設值、約束規則等。定義觸發器、存儲過程、視圖、角色、同義詞、序列等對象信息。
3. 邏輯結構設計階段
將概念結構轉換為某個DBMS所支持的數據模型（例如關系模型），並對其進行優化。設計邏輯結構應該選擇最適於描述與表達相應概念結構的數據模型，然後選擇最合適的DBMS。
將E-R圖轉換為關系模型實際上就是要將實體、實體的屬性和實體之間的聯系轉化為關系模式,這種轉換一般遵循如下原則：
1）一個實體型轉換為一個關系模式。實體的屬性就是關系的屬性。實體的碼就是關系的碼。
2）一個m:n聯系轉換為一個關系模式。與該聯系相連的各實體的碼以及聯系本身的屬性均轉換為關系的屬性。而關系的碼為各實體碼的組合。
3）一個1:n聯系可以轉換為一個獨立的關系模式，也可以與n端對應的關系模式合並。如果轉換為一個獨立的關系模式，則與該聯系相連的各實體的碼以及聯系本身的屬性均轉換為關系的屬性，而關系的碼為n端實體的碼。
4）一個1:1聯系可以轉換為一個獨立的關系模式，也可以與任意一端對應的關系模式合並。
5）三個或三個以上實體間的一個多元聯系轉換為一個關系模式。與該多元聯系相連的各實體的碼以及聯系本身的屬性均轉換為關系的屬性。而關系的碼為各實體碼的組合。
6）同一實體集的實體間的聯系，即自聯系，也可按上述1:1、1:n和m:n三種情況分別處理。
7）具有相同碼的關系模式可合並。
為了進一步提高資料庫應用系統的性能，通常以規范化理論為指導，還應該適當地修改、調整數據模型的結構，這就是數據模型的優化。確定數據依賴。消除冗餘的聯系。確定各關系模式分別屬於第幾範式。確定是否要對它們進行合並或分解。一般來說將關系分解為3NF的標准，即：
表內的每一個值都只能被表達一次。
•?表內的每一行都應該被唯一的標識（有唯一鍵）。
表內不應該存儲依賴於其他鍵的非鍵信息。
4. 資料庫物理設計階段
為邏輯數據模型選取一個最適合應用環境的物理結構（包括存儲結構和存取方法）。根據DBMS特點和處理的需要，進行物理存儲安排，設計索引，形成資料庫內模式。
5. 資料庫實施階段
運用DBMS提供的數據語言（例如SQL）及其宿主語言（例如C），根據邏輯設計和物理設計的結果建立資料庫，編制與調試應用程序，組織數據入庫，並進行試運行。 資料庫實施主要包括以下工作：用DDL定義資料庫結構、組織數據入庫 、編制與調試應用程序、資料庫試運行
6. 資料庫運行和維護階段
資料庫應用系統經過試運行後即可投入正式運行。在資料庫系統運行過程中必須不斷地對其進行評價、調整與修改。包括：資料庫的轉儲和恢復、資料庫的安全性、完整性控制、資料庫性能的監督、分析和改進、資料庫的重組織和重構造。
建模工具的使用
為加快資料庫設計速度，目前有很多資料庫輔助工具（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 圖表
ER 圖表和數據字典可以讓任何了解資料庫的人都明確如何從資料庫中獲得數據。ER圖對表明表之間關系很有用，而數據字典則說明了每個欄位的用途以及任何可能存在的別名。對SQL 表達式的文檔化來說這是完全必要的。
5) 定義標準的對象命名規范
資料庫各種對象的命名必須規范。
2. 表和欄位的設計（資料庫邏輯設計）
表設計原則
1) 標准化和規范化
數據的標准化有助於消除資料庫中的數據冗餘。標准化有好幾種形式，但Third Normal Form（3NF）通常被認為在性能、擴展性和數據完整性方面達到了最好平衡。簡單來說，遵守3NF 標準的資料庫的表設計原則是：「One Fact in One Place」即某個表只包括其本身基本的屬性，當不是它們本身所具有的屬性時需進行分解。表之間的關系通過外鍵相連接。它具有以下特點：有一組表專門存放通過鍵連接起來的關聯數據。
舉例：某個存放客戶及其有關定單的3NF 資料庫就可能有兩個表：Customer 和Order。Order 表不包含定單關聯客戶的任何信息，但表內會存放一個鍵值，該鍵指向Customer 表裡包含該客戶信息的那一行。
事實上，為了效率的緣故，對表不進行標准化有時也是必要的。
2) 數據驅動
採用數據驅動而非硬編碼的方式，許多策略變更和維護都會方便得多，大大增強系統的靈活性和擴展性。
舉例，假如用戶界面要訪問外部數據源（文件、XML 文檔、其他資料庫等），不妨把相應的連接和路徑信息存儲在用戶界面支持表裡。還有，如果用戶界面執行工作流之類的任務（發送郵件、列印信箋、修改記錄狀態等），那麼產生工作流的數據也可以存放在資料庫里。角色許可權管理也可以通過數據驅動來完成。事實上，如果過程是數據驅動的，你就可以把相當大的責任推給用戶，由用戶來維護自己的工作流過程。
3) 考慮各種變化
在設計資料庫的時候考慮到哪些數據欄位將來可能會發生變更。
舉例，姓氏就是如此（注意是西方人的姓氏，比如女性結婚後從夫姓等）。所以，在建立系統存儲客戶信息時，在單獨的一個數據表裡存儲姓氏欄位，而且還附加起始日和終止日等欄位，這樣就可以跟蹤這一數據條目的變化。
欄位設計原則
4) 每個表中都應該添加的3 個有用的欄位
•?dRecordCreationDate，在VB 下默認是Now()，而在SQL Server 下默認為GETDATE()
•?sRecordCreator，在SQL Server 下默認為NOT NULL DEFAULT USER
•?nRecordVersion，記錄的版本標記；有助於准確說明記錄中出現null 數據或者丟失數據的原因
5) 對地址和電話採用多個欄位
描述街道地址就短短一行記錄是不夠的。Address_Line1、Address_Line2 和Address_Line3 可以提供更大的靈活性。還有，電話號碼和郵件地址最好擁有自己的數據表，其間具有自身的類型和標記類別。
6) 使用角色實體定義屬於某類別的列
在需要對屬於特定類別或者具有特定角色的事物做定義時，可以用角色實體來創建特定的時間關聯關系，從而可以實現自我文檔化。
舉例：用PERSON 實體和PERSON_TYPE 實體來描述人員。比方說，當John Smith, Engineer 提升為John Smith, Director 乃至最後爬到John Smith, cio 的高位，而所有你要做的不過是改變兩個表PERSON 和PERSON_TYPE 之間關系的鍵值，同時增加一個日期/時間欄位來知道變化是何時發生的。這樣，你的PERSON_TYPE 表就包含了所有PERSON 的可能類型，比如Associate、Engineer、Director、CIO 或者CEO 等。還有個替代辦法就是改變PERSON 記錄來反映新頭銜的變化，不過這樣一來在時間上無法跟蹤個人所處位置的具體時間。
7) 選擇數字類型和文本類型盡量充足
在SQL 中使用smallint 和tinyint 類型要特別小心。比如，假如想看看月銷售總額，總額欄位類型是smallint，那麼，如果總額超過了$32,767 就不能進行計算操作了。
而ID 類型的文本欄位，比如客戶ID 或定單號等等都應該設置得比一般想像更大。假設客戶ID 為10 位數長。那你應該把資料庫表欄位的長度設為12 或者13 個字元長。但這額外占據的空間卻無需將來重構整個資料庫就可以實現資料庫規模的增長了。
8) 增加刪除標記欄位
在表中包含一個「刪除標記」欄位，這樣就可以把行標記為刪除。在關系資料庫里不要單獨刪除某一行；最好採用清除數據程序而且要仔細維護索引整體性。
3. 選擇鍵和索引（資料庫邏輯設計）
鍵選擇原則：
1) 鍵設計4 原則
•?為關聯欄位創建外鍵。
•?所有的鍵都必須唯一。
•?避免使用復合鍵。
•?外鍵總是關聯唯一的鍵欄位。
2) 使用系統生成的主鍵
設計資料庫的時候採用系統生成的鍵作為主鍵，那麼實際控制了資料庫的索引完整性。這樣，資料庫和非人工機制就有效地控制了對存儲數據中每一行的訪問。採用系統生成鍵作為主鍵還有一個優點：當擁有一致的鍵結構時，找到邏輯缺陷很容易。
3) 不要用用戶的鍵(不讓主鍵具有可更新性)
在確定採用什麼欄位作為表的鍵的時候，可一定要小心用戶將要編輯的欄位。通常的情況下不要選擇用戶可編輯的欄位作為鍵。
4) 可選鍵有時可做主鍵
把可選鍵進一步用做主鍵，可以擁有建立強大索引的能力。
索引使用原則：
索引是從資料庫中獲取數據的最高效方式之一。95%的資料庫性能問題都可以採用索引技術得到解決。
1) 邏輯主鍵使用唯一的成組索引，對系統鍵（作為存儲過程）採用唯一的非成組索引，對任何外鍵列採用非成組索引。考慮資料庫的空間有多大，表如何進行訪問，還有這些訪問是否主要用作讀寫。
2) 大多數資料庫都索引自動創建的主鍵欄位，但是可別忘了索引外鍵，它們也是經常使用的鍵，比如運行查詢顯示主表和所有關聯表的某條記錄就用得上。
3) 不要索引memo/note 欄位，不要索引大型欄位（有很多字元），這樣作會讓索引佔用太多的存儲空間。
4) 不要索引常用的小型表
不要為小型數據表設置任何鍵，假如它們經常有插入和刪除操作就更別這樣作了。對這些插入和刪除操作的索引維護可能比掃描表空間消耗更多的時間。
4. 數據完整性設計（資料庫邏輯設計）
1) 完整性實現機制：
實體完整性：主鍵
參照完整性：
父表中刪除數據：級聯刪除；受限刪除；置空值
父表中插入數據：受限插入；遞歸插入
父表中更新數據：級聯更新；受限更新；置空值
DBMS對參照完整性可以有兩種方法實現：外鍵實現機制（約束規則）和觸發器實現機制
用戶定義完整性：
NOT NULL；CHECK；觸發器
2) 用約束而非商務規則強制數據完整性
採用資料庫系統實現數據的完整性。這不但包括通過標准化實現的完整性而且還包括數據的功能性。在寫數據的時候還可以增加觸發器來保證數據的正確性。不要依賴於商務層保證數據完整性；它不能保證表之間（外鍵）的完整性所以不能強加於其他完整性規則之上。
3) 強制指示完整性
在有害數據進入資料庫之前將其剔除。激活資料庫系統的指示完整性特性。這樣可以保持數據的清潔而能迫使開發人員投入更多的時間處理錯誤條件。
4) 使用查找控制數據完整性
控制數據完整性的最佳方式就是限制用戶的選擇。只要有可能都應該提供給用戶一個清晰的價值列表供其選擇。這樣將減少鍵入代碼的錯誤和誤解同時提供數據的一致性。某些公共數據特別適合查找：國家代碼、狀態代碼等。
5) 採用視圖
為了在資料庫和應用程序代碼之間提供另一層抽象，可以為應用程序建立專門的視圖而不必非要應用程序直接訪問數據表。這樣做還等於在處理資料庫變更時給你提供了更多的自由。
5. 其他設計技巧
1) 避免使用觸發器
觸發器的功能通常可以用其他方式實現。在調試程序時觸發器可能成為干擾。假如你確實需要採用觸發器，你最好集中對它文檔化。
2) 使用常用英語（或者其他任何語言）而不要使用編碼
在創建下拉菜單、列表、報表時最好按照英語名排序。假如需要編碼，可以在編碼旁附上用戶知道的英語。
3) 保存常用信息
讓一個表專門存放一般資料庫信息非常有用。在這個表裡存放資料庫當前版本、最近檢查/修復（對Access）、關聯設計文檔的名稱、客戶等信息。這樣可以實現一種簡單機制跟蹤資料庫，當客戶抱怨他們的資料庫沒有達到希望的要求而與你聯系時，這樣做對非客戶機/伺服器環境特別有用。
4) 包含版本機制
在資料庫中引入版本控制機制來確定使用中的資料庫的版本。時間一長，用戶的需求總是會改變的。最終可能會要求修改資料庫結構。把版本信息直接存放到資料庫中更為方便。
5) 編制文檔
對所有的快捷方式、命名規范、限制和函數都要編制文檔。
採用給表、列、觸發器等加註釋的資料庫工具。對開發、支持和跟蹤修改非常有用。
對資料庫文檔化，或者在資料庫自身的內部或者單獨建立文檔。這樣，當過了一年多時間後再回過頭來做第2 個版本，犯錯的機會將大大減少。
6) 測試、測試、反復測試
建立或者修訂資料庫之後，必須用用戶新輸入的數據測試數據欄位。最重要的是，讓用戶進行測試並且同用戶一道保證選擇的數據類型滿足商業要求。測試需要在把新資料庫投入實際服務之前完成。
7) 檢查設計
在開發期間檢查資料庫設計的常用技術是通過其所支持的應用程序原型檢查資料庫。換句話說，針對每一種最終表達數據的原型應用，保證你檢查了數據模型並且查看如何取出數據。
三、資料庫命名規范
1. 實體（表）的命名
1) 表以名詞或名詞短語命名，確定表名是採用復數還是單數形式，此外給表的別名定義簡單規則（比方說，如果表名是一個單詞，別名就取單詞的前4 個字母；如果表名是兩個單詞，就各取兩個單詞的前兩個字母組成4 個字母長的別名；如果表的名字由3 個單片語成，從頭兩個單詞中各取一個然後從最後一個單詞中再取出兩個字母，結果還是組成4 字母長的別名，其餘依次類推）
對工作用表來說，表名可以加上前綴WORK_ 後面附上採用該表的應用程序的名字。在命名過程當中，根據語義拼湊縮寫即可。注意，由於ORCLE會將欄位名稱統一成大寫或者小寫中的一種，所以要求加上下劃線。
舉例：
定義的縮寫 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；
表 Depart和Employee;存在多對多的關系；則關聯表命名為R_Dept_Emp
2. 屬性（列）的命名
1) 採用有意義的列名，表內的列要針對鍵採用一整套設計規則。每一個表都將有一個自動ID作為主健,邏輯上的主健作為第一組候選主健來定義,如果是資料庫自動生成的編碼，統一命名為：ID;如果是自定義的邏輯上的編碼則用縮寫加「ID」的方法命名。如果鍵是數字類型，你可以用_NO 作為後綴；如果是字元類型則可以採用_CODE 後綴。對列名應該採用標準的前綴和後綴。
舉例：銷售訂單的編號欄位命名：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) 小心保留詞，要保證你的欄位名沒有和保留詞、資料庫系統或者常用訪問方法沖突
5) 保持欄位名和類型的一致性，在命名欄位並為其指定數據類型的時候一定要保證一致性。假如數據類型在一個表裡是整數，那在另一個表裡可就別變成字元型了。
⑻ SQL Server資料庫課程設計報告----醫院管理資料庫設計思路
我覺得至少還缺少「科室表」。
科室表：科室號，科室名
病房表：科室號，房間號，床位號，床位收費標准
醫生表：醫生號，科室號，姓名，性別，職稱。
病人表：姓名，性別，年齡，單位，住址，身份證號，國別，電話，科室號，入院日期，入院診斷，病歷號，病人類別號（自費、醫保、農合等），醫保號，出院診斷，出院日期。
⑼ SQL的資料庫課程設計
這話說的，這語氣跟我項目經理交代工作給我一模一樣啊
⑽ 求SQL資料庫實驗報告
*****系實驗（上機）報告
課程名稱 資料庫系統基礎
實驗名稱 數據查詢與存儲過程
學號 33
學生姓名 嘻習喜戲
成績
年 月 日
序號 5 實驗名稱 SQL數據查詢
實驗目的：
熟練掌握SQL SELECT 語句，能夠運用該語句完成各種查詢。
實驗內容：
用SQL SELECT 語句完成下列查詢：
1． 查詢客戶表中的所有記錄。
2． 從訂購單表中查詢客戶號信息（哪些客戶有訂購單）。
3． 查詢單價在20元以上（含）的產品信息。
4． 查詢單價在20元以上（不含）的產品名稱為牛奶的產品信息。
5． 查詢單價在20元以上（不含）的產品名稱為牛奶或德國乳酪的產品信息。
6． 查詢有2003年7月訂購單的客戶名稱、聯系人、電話號碼和訂單號信息。
7． 查詢有德國乳酪訂貨的客戶的名稱、聯系人和電話號碼信息。
8． 查詢有德國乳酪訂購需求的訂單名細記錄。
9． 查詢所有訂購數量（即訂單名細中每個訂購項目的數量）都在10個以上的訂購單的信息。
10． 找出和德國乳酪同等價位的所有產品信息。
11． 查詢單價范圍在10元到30元范圍內的產品信息（使用BETWEEN…AND）。
12． 從客戶表中查詢出客戶名稱中有「公司」二字的客戶信息（使用LIKE運算符）。
13． 從客戶表中查詢出客戶名稱中沒有「公司」二字的客戶信息（使用NOT LIKE運算符）。
14． 按產品的單價升序列出全部產品信息。
15． 先按產品名稱排序，再按單價排序列出全部產品信息。
16． 從產品表中查詢共有幾種產品。
17． 從訂購名細表中查詢德國乳酪的訂購總數。
18． 計算德國乳酪所有訂購的總金額。
19． 求所有訂購單的平均金額，在查詢結果中列出訂購單的個數和平均金額。
20． 求每個訂購單訂購的項目數和總金額。
21． 求每個客戶包含了德國乳酪訂購的訂單號及其最高金額和最低金額。
22． 求至少有兩個訂購項目的訂購單的平均金額。
23． 找出尚未最後確定訂購單（即訂購日期為空值的記錄）的有關客戶信息（客戶的名稱、聯系人和電話號碼）和訂單號。
24． 找出在2000年1月1日之後簽訂的訂購單的客戶信息（客戶的名稱、聯系人和電話號碼）、訂單號和訂購日期。
25． 列出每類產品（相同名稱）具有最高單價的產品信息（產品號、名稱、規格說明和單價，提示：使用內外層互相關嵌套查詢）。
26． 確定哪些客戶目前沒有訂購單（使用謂詞NOT EXISTS）。
27． 查詢目前有訂購單的客戶的信息（使用謂詞EXISTS）。
28． 查詢符合條件的產品信息，要求該產品的單價達到了任意一款產品名稱為牛奶的單價的一半（使用ANY或SOME量詞）。
29． 查詢符合條件的產品信息，要求該產品的單價大於任何一款產品名稱為牛奶的單價（使用ALL量詞）。
30． 設計如下的連接操作，並分析各自的特點：
•廣義笛卡兒積
•內連接
•外連接
•左連接
•右連接
•全連接
掌握存儲過程的創建命令，按照題目要求創建存儲過程，理解存儲過程的作用。
（1） 建立存儲過程。查詢單價范圍在x元到y元范圍內的產品信息。
（2） 建立存儲過程。查詢在某年某月某日之後簽訂的訂購單的客戶信息（客戶的名稱、聯系人和電話號碼）、訂單號和訂購日期。
（3） 建立存儲過程。將某產品的訂購日期統一修改為一個指定日期。
（4） 建立存儲過程。刪除沒有簽訂單的客戶信息。
實驗要求：
用SELECT語句完成本次實驗，並提交上機報告。
（1） 掌握存儲過程的創建命令，按照實驗內容的要求創建存儲過程，理解存儲過程的作用。
（2） 用CREATE PROCEDURE和EXECUTE 語句完成本次實驗，並提交上機報告。
實驗准備(本實驗預備知識和為完成本實驗所做的准備)：
仔細閱讀課本第五章關於SQL的數據查詢功能的內容
實驗過程(實驗的操作過程、遇到的問題及其解決辦法或未能解決的問題)：
用SQL SELECT 語句完成以上30題查詢
實驗總結(總結本次實驗的收獲、未解決的問題以及體會和建議等)：
熟練掌握SQL SELECT 語句，能夠運用該語句完成各種查詢
附錄（SQL語句）：
--1． 查詢客戶表中的所有記錄。
select * from 客戶
--2． 從訂購單表中查詢客戶號信息（哪些客戶有訂購單）
select 客戶號from 訂單where 訂單號!=null
--3． 查詢單價在元以上（含）的產品信息。
select *from 產品where 單價> 20 or 單價=20
--4． 查詢單價在元以上（不含）的產品名稱為牛奶的產品信息。
select *from 產品where 單價>20 and 產品名稱='牛奶'
－－． 查詢單價在元以上（不含）的產品名稱為牛奶或德國乳酪的產品信息
select *from 產品where 單價>20 and (產品名稱='牛奶'or 產品名稱='德國乳酪')
--6． 查詢有年月訂購單的客戶名稱、聯系人、電話號碼和訂單號信息
select 客戶名稱,聯系人, 電話,訂單號from 客戶,訂單where (year(訂購日期)=2003 and month (訂購日期)=7)and (訂單.客戶號=客戶.客戶號)
--7． 查詢有德國乳酪訂貨的客戶的名稱、聯系人和電話號碼信息。
select 客戶名稱,聯系人, 電話from 客戶
where
(客戶號= (select 客戶號from 訂單where(訂單號 =(select 訂單號from 訂單明細
where 產品號= ( select 產品號from 產品where 產品名稱= ' 德國乳酪' )))))
--8． 查詢有德國乳酪訂購需求的訂單名細記錄。
select * from 訂單明細where (數量!=null and 產品號=(select 產品號from 產品where 產品名稱= '德國乳酪'))
--9． 查詢所有訂購數量（即訂單名細中每個訂購項目的數量）都在個以上的訂購單的信息。
select * from 訂單where (訂單號in (select 訂單號from 訂單明細where (數量>10)))
--10． 找出和德國乳酪同等價位的所有產品信息。
select * from 產品where (
--11． 查詢單價范圍在元到元范圍內的產品信息（使用BETWEEN…AND）。
select * from 產品where (單價between 10 and 30)
--12． 從客戶表中查詢出客戶名稱中有「公司」二字的客戶信息（使用LIKE運算符）
select * from 客戶where 客戶名稱like '%公司%'
--13． 從客戶表中查詢出客戶名稱中沒有「公司」二字的客戶信息（使用NOT LIKE運算符）。
select * from 客戶where 客戶名稱not like '%公司%'
--14． 按產品的單價升序列出全部產品信息。
select *from 產品order by 單價
--15． 先按產品名稱排序，再按單價排序列出全部產品信息。
select * from 產品order by 產品名稱,單價
--16． 從產品表中查詢共有幾種產品。
select count ( distinct 產品名稱) as 產品總數from 產品
--17． 從訂購名細表中查詢德國乳酪的訂購總數
select sum (數量) as '訂購乳酪數量'
from 訂單明細
where 產品號in(select 產品號from 產品where 產品名稱='德國乳酪')
--18． 計算德國乳酪所有訂購的總金額
declare @a money
select @a=(select 單價from 產品where 產品名稱='德國乳酪')
declare @b int
select @b=(select sum (數量) as '訂購乳酪數量'
from 訂單明細
where 產品號in(select 產品號from 產品where 產品名稱='德國乳酪'))
declare @c int
select @c=@a*@b
select @c as 總金額
--19． 求所有訂購單的平均金額，在查詢結果中列出訂購單的個數和平均金額。
select 訂單均值= avg(單價*數量) ,訂單個數=count ( 訂單號)
from 訂單明細,產品
where 產品.產品號=訂單明細.產品號
--20． 求每個訂購單訂購的項目數和總金額。
select 訂單號, count (產品.產品號) as 項目數,sum(數量*單價) as 總金額
from 產品,訂單明細
where (產品.產品號=訂單明細.產品號)
group by 訂單號
--21．求每個客戶包含了德國乳酪訂購的訂單號及其最高金額和最低金額
select 客戶.客戶號,產品.產品號,數量*單價as 總金額
from 客戶,訂單,訂單明細,產品
where 客戶.客戶號=訂單.客戶號and 訂單.訂單號=訂單明細.訂單號and 訂單明細.產品號=產品.產品號and
產品名稱='德國乳酪'
order by 客戶號
compute max(數量*單價),min (數量*單價) by 客戶號
--22．求至少有兩個訂購項目的訂購單的平均金額
select 訂單號,avg(數量*單價),count(產品.產品號)
from 訂單明細,產品
where 訂單明細.產品號=產品.產品號
group by 訂單號
having count(產品.產品號)>=2
--23．找出尚未最後確定訂購單（即訂購日期為空值的記錄）的有關客戶信息
-- （客戶的名稱、聯系人和電話號碼）和訂單號
select 客戶名稱,聯系人,電話,訂單明細.訂單號
from 客戶, 訂單明細,訂單
where(客戶.客戶號= 訂單.客戶號) and 訂購日期=null
--24．找出在年月日之後簽訂的訂購單的客戶信息
--（客戶的名稱、聯系人和電話號碼）、訂單號和訂購日期
select 客戶名稱,聯系人,電話,訂單號,訂購日期
from 客戶,訂單
where 客戶.客戶號=訂單.客戶號
and year(訂購日期)>1996 and month(訂購日期)>4 and day(訂購日期)>2
--25．列出每類產品（相同名稱）具有最高單價的產品信息
--（產品號、名稱、規格說明和單價，提示：使用內外層互相關嵌套查詢）
select A.產品號, A.產品名稱, A.規格說明, A.單價
from 產品A
where 單價= (SELECT MAX(單價)
FROM 產品B
WHERE A.規格說明= B.規格說明)
--26．確定哪些客戶目前沒有訂購單（使用謂詞NOT EXISTS）
select *
from 客戶
where not exists (select* from 訂單where 客戶號=訂單.客戶號)
--27．查詢目前有訂購單的客戶的信息（使用謂詞EXISTS）
select *
from 客戶
where exists (select* from 訂單where 客戶號=訂單.客戶號)
--28．查詢符合條件的產品信息，要求該產品的單價達到了任
--意一款產品名稱為牛奶的單價的一半（使用ANY或SOME量詞）
select *
from 產品a
where(單價>any(select 單價/2 from 產品b where b.產品名稱='牛奶'))
--29．查詢符合條件的產品信息，要求該產品的單價大於任何
-- 一款產品名稱為牛奶的單價（使用ALL量詞）
select *
from 產品a
where(單價>all(select 單價from 產品b where b.產品名稱='牛奶'))
--30．設計如下的連接操作，並分析各自的特點：
-- •廣義笛卡兒積
SELECT *
FROM 客戶CROSS JOIN 訂購單
WHERE 客戶.客戶號= 訂購單.客戶號
-- •內連接
SELECT *
FROM 客戶INNER JOIN 訂購單
ON 客戶.客戶號= 訂購單.客戶號
-- •外連接
-- •左連接
SELECT *
FROM 客戶LEFT JOIN 訂購單
ON 客戶.客戶號= 訂購單.客戶號
-- •右連接
SELECT *
FROM 客戶RIGHT JOIN 訂購單
ON 客戶.客戶號= 訂購單.客戶號
-- •全連接
SELECT *
FROM 客戶FULL JOIN 訂購單
ON 客戶.客戶號= 訂購單.客戶號
說明：
1. 上機報告上傳到211.68.36.251的資料庫文件夾中的上傳目錄
2. 文件名的命名規則為：學號+姓名+實驗+序號。如：9724101汪偉的第二次上機報告名為：9724101汪偉實驗2
3. 封面由學生填寫；
4. 正文的實驗名稱、實驗目的、實驗內容、實驗要求已經由教師指定；
5. 實驗准備由學生在實驗或上機之前填寫；
6. 實驗過程由學生記錄實驗的過程，包括操作過程、遇到哪些問題以及如何解決等；
7. 實驗總結由學生在實驗後填寫，總結本次實驗的收獲、未解決的問題以及體會和建議等；
8. 將相關的語句粘貼到附錄中。
你自己改改吧。想要word原版的話再說一聲。