一、設計問題
由於不同的人從不同 的角度考慮問題，設計出的 E-R 就會有着不同的差別，因此要注意以下幾個問題
信息重復：表中數據存在重復的信息，或使用相同含義不同字表述的類型，
更新異常：由於冗余的信息在進行更新時未全部進行更新，會導致數據出現錯誤，稱為更新異常
插入異常：無法表示某些信息，如同一個賓館的標間出現了不同的價格，導致插入時出現異常
刪除異常：在刪除某一行記錄時，導致將房間類型表中的某一類型也刪除掉了，稱為刪除異常
二、規范設計
1、三大范式
在進行數據設計時，制定的一些規則，稱為數據庫設計范式 ，遵守這些規則將創建出良好的數據庫，如經常聽到的數據庫三大范式
（1）、第一范式
第一范式（Normal From,1NF）的目標是確保每列的原子性。
如果每列（或屬性）的都是不可再分的最小數據單元（或最小的原子單元）則滿足第一范式
如：地址列 可以拆分為國家 ，省，市，縣（區），鎮，村（街道辦事處）等幾個 部分
（2）、第二范式
第二范式（2NF）在第一范式的基礎上更近一步，目標是確保表中的每列都和主鍵相關。
如果一個關系滿足第一范式，並且除了主鍵以外，其他主鍵都全部依賴該主鍵則滿足第二范式
如：訂單詳細表中有（訂單詳細編碼，訂單詳細名，訂單編號，訂單名，訂單類型，商品編碼，商品名，商品單價，商品數量等）
其中可以看出
訂單詳細名 → 訂單詳細編碼
訂單名，訂單類型 → 訂單編號
商品名，商品單價，商品數量 → 商品編碼
其中 → 符號代表依賴，由於上述只有部分列依賴於主鍵，違背了第二 范式 可以對其進行拆分成 訂單詳細表，訂單表，商品表三個表，通過主外鍵進行相互關聯
（3）、第三范式
第三范(3NF)是在第二范式的基礎上更近一步，第三范式的目標是確保每列都和主鍵列直接相關，而不是間接相關
如果一個關系滿足第二范式，並且除了主鍵以外的其他列都只能依賴主鍵列，列與列之間不存在相互依賴關系，則滿足第三范式
借助數學中的Armstrong 公理來判定，如 A、B、C、D 中是表中的四個列
其中A 為主鍵， B → A(B依賴A),C → A,D → A 如果其中還有，B → C,C → D 從這兩個還可以推導出 B → D,此時雖然滿足第二范式，但是不滿足第三范式
只有 當 A 為主鍵時，有且只有 B → A(B依賴A),C → A,D → A ，這三個依賴時才滿足第三范式。
在現實的話如：商品表中有（商品編號，商品名，商品類型，商品規格，商品單價）
其中雖然 商品名，商品類型，商品規格，商品單價 都依賴 主鍵商品編號，但是 商品規格，商品單價 依賴於商品類型
由於不同類型的商品的 規格 和 單價不同
因此還可以將其分為商品表和商品類型表，這樣才滿足第三范式
2、數據庫事務的四大特性：（ACID）
原子性( Atomicity )：指的是事務是一個不可分割的工作單位，要不全部成功，要不全部回滾
一致性( Consistensy )：事務在執行前后數據庫處於一致性。（如：AB之間轉賬，A少100，B必須要增加100）
隔離性( Isolation )：多個用戶並發訪問數據庫時，一個用戶的事務不能被其他用戶的事務所干擾，多個並發事務之間數據要相互隔離
持久性( Durability )：指一個事務一旦被提交，他對數據庫的影響是永久性的。
三、規范化和性能的關系
由於項目對於最終的用戶來說，客人最關心的是方便清晰的數據結果，因此在設計數據庫時，設計人員和客戶對數據庫的設計規范化與性能之間存在一定的矛盾。
如上為了滿足數據庫三大范式， 數據操作性能也隨之受到了影響，畢竟查詢一個表和查詢 多個表的性能是不一樣的，因此在實際設計時，既要考慮三大范式，避免數據的冗余和各種數據操作異常；又要考慮數據庫的訪問性能。可以使用的小操作有：為了減少表之間的連接，提高數據庫性能，允許適當的冗余列
如：金額列存在不滿足數據庫設計的第三范式，因為金額可以通過單價乘以數量得到，但是增加后可以提過數據的處理速度，加快訪問速度，便於直觀展示，相對而言是一個比較好的冗余（對其形容 比較高級的說法叫以空間換取時間），但是，不要輕易 違反數據庫設計的規范化原則。如果處理不好，可能會適得其反，使應用程序運行速度更慢。