一、實體與表對應關係
表<=>實體，字段<=>屬性。
二、表與表的關係(實體間的關係)：一對一、一對多、多對多
一對一：一條記錄只對應其他表中的一條記錄有關係
學生基本信息表t_student，成績表t_studentScore含有一個外鍵studentId。基本信息表中的studentId和成績表中的studentId就是一對一的關係。
一對多：A表一條記錄對應B表中多條記錄有關係，B表的記錄不被A表記錄共享(有關係)。
班級表和學生表，一個班級有多個學生，對班級來說就是一對多的關係。
多對多：A表一條記錄和B表多條記錄有關係，B表的一條記錄也和A表的多條記錄有關係(互相共享)。
學生表和科目表，學生可以選擇多個科目，每個科目可以被多個學生選擇。
三、基本表的完整性
(1)原子性。字段是不可再分解的。
(2)原始性。記錄是原始數據(基礎數據)的記錄。
(3)穩定性。結構是相對穩定的,表中的記錄是要長期保存的。
(4)演繹性。由基本表與代碼表中的數據,可以派生出所有的輸出數據。
四、其他常用表
1.中間表
中間表是針對多對多關係的。就比如做公交查詢系統，裏面有兩個表，分別是車站表t_busstation、線路表t_road，根據常識，一個站有多個線路經過，而每個線路又有多個車站，怎麼才能將兩個表聯繫起來呢，如果是一對一，一對多，我們一個表， 兩個表就可以將他們實現了。但是多對多呢，這樣我們就必須藉助中間表用來連接兩個表。一般中間表只有一個自增主鍵+兩個表的主鍵。中間表是沒有屬性的因爲它不是一個基本表。
2.臨時表
臨時表是那些以#號開頭爲名字的數據表，它主要是用來存放臨時數據的，當用戶斷開連接但沒有清除臨時表裏的數據時，系統會自動把臨時表裏的數據清空。臨時表是放在系統數據庫 tempdb中的，而不是當前數據庫。
臨時表分兩種：本地臨時表和全局臨時表。
a.本地臨時表
本地臨時表是以#開頭的，只對當前的數據庫用戶可見，而其他的用戶是不可見的。當數據庫實例斷開後當然也就丟失了數據了，不管是顯式清空還是系統回收。
b.全局臨時表
以“##”開頭的，而且是對所有的用戶都是可見，當你斷開數據庫實例連接時，只要還有別的系統項目在引用它，連着數據庫，那麼數據就存在，只有當別的系統也全部斷開連接時，系統纔會清除全局臨時表的數據。
建立臨時表的語句:
本地臨時表：
create table #student
(
studentID int ,
studentName nvarchar (40),
classID int
)
全局臨時表：
create table ##student
(
studentID int ,
studentName nvarchar (40).
classID int
)
也可以用SQL語句完成：
select * from employee into #student
五、三大範式
第一範式：如果每列(或者每個屬性)都是不可再分的最小數據單元(也稱爲最小的原子單元),則滿足第一範式.比如一個工人的基本信息表，裏面有工人的工號，性別，年齡，這些屬性都是不可分割的，所以這個表就符合了第一範式。
第二範式： 就是在第一範式的基礎上延伸，使之表裏的每個字段都與主鍵發生關係。假如一個關係滿足第一範式,並且除了主鍵以外的其它字段,都依賴於該主鍵,則滿足第二範式.
例如:訂單表(訂單編號、產品編號、定購日期、價格、……)，"訂單編號"爲主鍵，"產品編號"和主鍵列沒有直接的關係，即"產品編號"列不依賴於主鍵列，這個列我們就可以把它刪除。
第三範式：在第二範式的基礎上更進一步，也就是爲了實現表裏的列都與主鍵列直接相關，不是間接相關。這個我們可以用“Armstrong 公理”中的傳遞規則來推理。
定義：
設U是關係模式R 的屬性集，F 是R 上成立的只涉及U 中屬性的函數依賴集。若X→Y 和 Y→Z在R 上成立，則X →Z 在R 上成立。因此我們就來看在網上搜索到的例子：例如:訂單表(訂單編號，定購日期，顧客編號，顧客姓名，……)，初看該表沒有問題，滿足第二範式，每列都和主鍵列"訂單編號"相關，再細看你會發現"顧客姓名"和"顧客編號"相關，"顧客編號"和"訂單編號"又相關，最後經過傳遞依賴，"顧客姓名"也和"訂單編號"相關。爲了滿足第三範式，應去掉"顧客姓名"列，放入客戶表中。
這裏其實就是爲了說明數據庫的表裏步要出現冗餘，在顧客表裏已經有了"顧客姓名"了，而在訂單表裏就別出現了，而直接根據顧客編號相關聯就可以，否則造成資源浪費。
三大範式延伸：
第一範式：1NF是對屬性的原子性約束，要求屬性具有原子性，不可再分解；
第二範式：2NF是對記錄的惟一性約束，要求記錄有惟一標識，即實體的惟一性；
第三範式：3NF是對字段冗餘性的約束，即任何字段不能由其他字段派生出來，它要求字段沒有冗餘。
其實在設計數據庫的時候我們最多的要遵循的就是第三範式，但是並不是越滿足第三範式數據庫就設計的越完美，這種錯誤是錯誤的。有時候增加點冗餘相反的會提高訪問速率，因此在實際的設計過程中應降低對範式的要求。
以前對數據冗餘並不是很瞭解，在百度知道里的定義是這樣的：在一個數據集合中重複的數據稱爲數據冗餘. 但是不是說我們表的主鍵在其他表裏重複出現就是冗餘，這不是，而是爲了連接兩個表。只有非鍵字段就是既不是主鍵外鍵等約束的鍵如果重複出現，就會形成數據冗餘。數據冗餘也包括重複性冗餘和派生冗餘。比如工人表裏有"基本工資"，"獎金"兩列，然後還有一個"總工資"的列，這個總工資就是派生冗餘。低級的重複性冗餘一定要避免，杜絕，但是像派生冗餘還是提倡的因爲它能提高訪問的效率。
四：數據庫設計中具體要注意的幾點；
1.凡是用戶輸入的不能作爲主鍵；
這點大概都知道，主鍵是唯一的，一般不能讓客戶做任何操作；
2.凡是有業務意義的不能作爲主鍵；
既然是具有業務意義，客戶隨時都有可能提出這個業務，要求修改業務，也會有變動的可能！
3.除非確定是有必要的字段，其他都允許爲空；
設計數據庫時，約束簡單點最好，約束多則在系統中開發時要注意的就多，開發效率相對會底，因爲系統是可以通過驗證輔助完成這些約束的！
4.不能缺少時間或日期字段；
有時間是永遠前進，時間的用處很多，打個很簡單的比方，在用戶表中我們有一個用戶創建的時間，在吧項目交個客戶後使用一段時間，客戶提出新的需求，
比如說：要搞一個週年慶活動，每個滿5個月的用戶都獎勵200代金卷，等等。在這時我們如國有時間字段，那就很容易加上這個業務，但要是沒有呢？
將會如何？修改數據庫？公司的利益會受到嚴重的打擊；
5. 業務的時效（時間有效）性；
6.數據的採集寧濫毋缺
這點非常重要，這就是數據庫設計者的後瞻能力了，也就是說我們能在用戶還沒有提出一些新的需求是，已經把數據都採集好了，就等客戶提出需求
很輕鬆的搞定一些業務；有了數據什麼都不怕；但有些人也會問，我們前期就把沒有用到的數據存進去，後期可以利用也就罷了，如果沒有利用到呢？
是不是很浪費空間；其實這個問題，我可以這樣回答，絕大多數公司在很多方面都是以空間換取時間的；（相信大家都明白！比如在web中使用的AJAX技術)
7.外鍵字段需要維護或變更，就需要表來維護，如果字段簡單，不需要經常變更的，可以直接是程序維護;
這點我就不在贅述；
個人總結：
事物的屬性對應表的屬性，將一張表看作一個事物。如，書的屬性有價格、重量、等等。(一般表都有Id來區分每條記錄)
作者：zEthan
來源：CSDN
原文：https://blog.csdn.net/ethan_10/article/details/80810314
版權聲明：本文爲博主原創文章，轉載請附上博文鏈接！