摘要: 我們開發程序的目的是為了完成業務功能, 理想的情況下程序中的每一條語句都應該是與業務直接相關的, 例如程序中不應該出現連接數據庫, 讀取某個字段等純技術性的操作, 而應該是得到用戶A的基本信息等具有業務含義的操作. dao(data access object)層存在的意。。。。。
閱讀全文
數據庫設計的范式大綱
第一范式:
對于表中的每一行，必須且僅僅有唯一的行值.在一行中的每一列僅有唯一的值并且具有原子性.
第二范式:
第二范式要求非主鍵列是主鍵的子集，非主鍵列活動必須完全依賴整個主鍵。主鍵必須有唯一性的元素,一個主鍵可以由一個或更多的組成唯一值的列組成。一旦創建，主鍵無法改變，外鍵關聯一個表的主鍵。主外鍵關聯意味著一對多的關系.
第三范式:
第三范式要求非主鍵列互不依賴.
第四范式:
第四范式禁止主鍵列和非主鍵列一對多關系不受約束
第五范式:
第五范式將表分割成盡可能小的塊，為了排除在表中所有的冗余.
下面先討論前3個范式：
引言
數據庫的設計范式是數據庫設計所需要滿足的規范，滿足這些規范的數據庫是簡潔的、結構明晰的，同時，不會發生插入
（insert）、刪除（delete）和更新（update）操作異常。反之則是亂七八糟，不僅給數據庫的編程人員制造麻煩，而且面目可憎，可能存儲了 大量不需要的冗余信息。
設計范式是不是很難懂呢？非也，大學教材上給我們一堆數學公式我們當然看不懂，也記不住。所以我們很多人就根本不按照范式來設計數據庫。
實質上，設計范式用很形象、很簡潔的話語就能說清楚，道明白。本文將對范式進行通俗地說明，并以筆者曾經設計的一個簡單論壇的數據庫為例來講解怎樣將這些范式應用于實際工程。
范式說明
第一范式（1NF）：數據庫表中的字段都是單一屬性的，不可再分。這個單一屬性由基本類型構成，包括整型、實數、字符型、邏輯型、日期型等。
例如，如下的數據庫表是符合第一范式的：
而這樣的數據庫表是不符合第一范式的：
|
字段1
|
字段2
|
字段3
|
字段4
|
|
|
|
字段3.1
|
字段3.2
|
|
|
|
|
|
|
很顯然，在當前的任何關系數據庫管理系統（DBMS）中，傻瓜也不可能做出不符合第一范式的數據庫，因為這些DBMS不允許你把數據庫表的一列再分成二列或多列。因此，你想在現有的DBMS中設計出不符合第一范式的數據庫都是不可能的。
第二范式（2NF）：數據庫表中不存在非關鍵字段對任一候選關鍵字段的部分函數依賴（部分函數依賴指的是存在組合關鍵字中的某些字段決定非關鍵字段的情況），也即所有非關鍵字段都完全依賴于任意一組候選關鍵字。
假定選課關系表為SelectCourse(學號, 姓名, 年齡, 課程名稱, 成績, 學分)，關鍵字為組合關鍵字(學號, 課程名稱)，因為存在如下決定關系：
(學號, 課程名稱) → (姓名, 年齡, 成績, 學分)
這個數據庫表不滿足第二范式，因為存在如下決定關系：
(課程名稱) → (學分)
(學號) → (姓名, 年齡)
即存在組合關鍵字中的字段決定非關鍵字的情況。
由于不符合2NF，這個選課關系表會存在如下問題：
(1) 數據冗余：
同一門課程由n個學生選修，"學分"就重復n-1次；同一個學生選修了m門課程，姓名和年齡就重復了m-1次。
(2) 更新異常：
若調整了某門課程的學分，數據表中所有行的"學分"值都要更新，否則會出現同一門課程學分不同的情況。
(3) 插入異常：
假設要開設一門新的課程，暫時還沒有人選修。這樣，由于還沒有"學號"關鍵字，課程名稱和學分也無法記錄入數據庫。
(4) 刪除異常：
假設一批學生已經完成課程的選修，這些選修記錄就應該從數據庫表中刪除。但是，與此同時，課程名稱和學分信息也被刪除了。很顯然，這也會導致插入異常。
把選課關系表SelectCourse改為如下三個表：
學生：Student(學號, 姓名, 年齡)；
課程：Course(課程名稱, 學分)；
選課關系：SelectCourse(學號, 課程名稱, 成績)。
這樣的數據庫表是符合第二范式的，消除了數據冗余、更新異常、插入異常和刪除異常。
另外，所有單關鍵字的數據庫表都符合第二范式，因為不可能存在組合關鍵字。
第三范式（3NF）：在第二范式的基礎上，數據表中如果不存在非關鍵字段對任一候選關鍵字段的傳遞函數依賴則符合第三范式。所謂傳遞函數依賴，指的是如
果存在"A → B → C"的決定關系，則C傳遞函數依賴于A。因此，滿足第三范式的數據庫表應該不存在如下依賴關系：
關鍵字段 → 非關鍵字段x → 非關鍵字段y
假定學生關系表為Student(學號, 姓名, 年齡, 所在學院, 學院地點, 學院電話)，關鍵字為單一關鍵字"學號"，因為存在如下決定關系：
(學號) → (姓名, 年齡, 所在學院, 學院地點, 學院電話)
這個數據庫是符合2NF的，但是不符合3NF，因為存在如下決定關系：
(學號) → (所在學院) → (學院地點, 學院電話)
即存在非關鍵字段"學院地點"、"學院電話"對關鍵字段"學號"的傳遞函數依賴。
它也會存在數據冗余、更新異常、插入異常和刪除異常的情況，讀者可自行分析得知。
把學生關系表分為如下兩個表：
學生：(學號, 姓名, 年齡, 所在學院)；
學院：(學院, 地點, 電話)。
這樣的數據庫表是符合第三范式的，消除了數據冗余、更新異常、插入異常和刪除異常。
鮑依斯-科得范式（BCNF）：在第三范式的基礎上，數據庫表中如果不存在任何字段對任一候選關鍵字段的傳遞函數依賴則符合第三范式。
假設倉庫管理關系表為StorehouseManage(倉庫ID,
存儲物品ID, 管理員ID, 數量)，且有一個管理員只在一個倉庫工作；一個倉庫可以存儲多種物品。這個數據庫表中存在如下決定關系：
(倉庫ID, 存儲物品ID) →(管理員ID, 數量)
(管理員ID, 存儲物品ID) → (倉庫ID, 數量)
所以，(倉庫ID, 存儲物品ID)和(管理員ID, 存儲物品ID)都是StorehouseManage的候選關鍵字，表中的唯一非關鍵字段為數量，它是符合第三范式的。但是，由于存在如下決定關系：
(倉庫ID) → (管理員ID)
(管理員ID) → (倉庫ID)
即存在關鍵字段決定關鍵字段的情況，所以其不符合BCNF范式。它會出現如下異常情況：
(1) 刪除異常：
當倉庫被清空后，所有"存儲物品ID"和"數量"信息被刪除的同時，"倉庫ID"和"管理員ID"信息也被刪除了。
(2) 插入異常：
當倉庫沒有存儲任何物品時，無法給倉庫分配管理員。
(3) 更新異常：
如果倉庫換了管理員，則表中所有行的管理員ID都要修改。
把倉庫管理關系表分解為二個關系表：
倉庫管理：StorehouseManage(倉庫ID, 管理員ID)；
倉庫：Storehouse(倉庫ID, 存儲物品ID, 數量)。
這樣的數據庫表是符合BCNF范式的，消除了刪除異常、插入異常和更新異常。
范式應用
我們來逐步搞定一個論壇的數據庫，有如下信息：
?。?span lang="EN-US">1） 用戶：用戶名，email，主頁，電話，聯系地址
（2） 帖子：發帖標題，發帖內容，回復標題，回復內容
第一次我們將數據庫設計為僅僅存在表：
|
用戶名
|
email
|
主頁
|
電話
|
聯系地址
|
發帖標題
|
發帖內容
|
回復標題
|
回復內容
|
這個數據庫表符合第一范式，但是沒有任何一組候選關鍵字能決定數據庫表的整行，唯一的關鍵字段用戶名也不能完全決定整個元組。我們需要增加"發帖ID"、"回復ID"字段，即將表修改為：
|
用戶名
|
email
|
主頁
|
電話
|
聯系地址
|
發帖ID
|
發帖標題
|
發帖內容
|
回復ID
|
回復標題
|
回復內容
|
這樣數據表中的關鍵字(用戶名，發帖ID，回復ID)能決定整行：
(用戶名,發帖ID,回復ID) → (email,主頁,電話,聯系地址,發帖標題,發帖內容,回復標題,回復內容)
但是，這樣的設計不符合第二范式，因為存在如下決定關系：
(用戶名) → (email,主頁,電話,聯系地址)
(發帖ID) → (發帖標題,發帖內容)
(回復ID) → (回復標題,回復內容)
即非關鍵字段部分函數依賴于候選關鍵字段，很明顯，這個設計會導致大量的數據冗余和操作異常。
我們將數據庫表分解為（帶下劃線的為關鍵字）：
?。?span lang="EN-US">1） 用戶信息：用戶名，email，主頁，電話，聯系地址
（2） 帖子信息：發帖ID，標題，內容
?。?span lang="EN-US">3） 回復信息：回復ID，標題，內容
?。?span lang="EN-US">4） 發貼：用戶名，發帖ID
?。?span lang="EN-US">5） 回復：發帖ID，回復ID
這樣的設計是滿足第1、2、3范式和BCNF范式要求的，但是這樣的設計是不是最好的呢？
不一定。
觀察可知，第4項"發帖"中的"用戶名"和"發帖ID"之間是1：N的關系，因此我們可以把"發帖"合并到第2項的"帖子信息"中；第5項"回復"中的 "發帖ID"和"回復ID"之間也是1：N的關系，因此我們可以把"回復"合并到第3項的"回復信息"中。這樣可以一定量地減少數據冗余，新的設計為：
?。?span lang="EN-US">1） 用戶信息：用戶名，email，主頁，電話，聯系地址
（2） 帖子信息：用戶名，發帖ID，標題，內容
?。?span lang="EN-US">3） 回復信息：發帖ID，回復ID，標題，內容
數據庫表1顯然滿足所有范式的要求；
數據庫表2中存在非關鍵字段"標題"、"內容"對關鍵字段"發帖ID"的部分函數依賴，即不滿足第二范式的要求，但是這一設計并不會導致數據冗余和操作異常；
數據庫表3中也存在非關鍵字段"標題"、"內容"對關鍵字段"回復ID"的部分函數依賴，也不滿足第二范式的要求，但是與數據庫表2相似，這一設計也不會導致數據冗余和操作異常。
由此可以看出，并不一定要強行滿足范式的要求，對于1：N關系，當1的一邊合并到N的那邊后，N的那邊就不再滿足第二范式了，但是這種設計反而比較好！
對于M：N的關系，不能將M一邊或N一邊合并到另一邊去，這樣會導致不符合范式要求，同時導致操作異常和數據冗余。
對于1：1的關系，我們可以將左邊的1或者右邊的1合并到另一邊去，設計導致不符合范式要求，但是并不會導致操作異常和數據冗余。
結論
滿足范式要求的數據庫設計是結構清晰的，同時可避免數據冗余和操作異常。這并意味著不符合范式要求的設計一定是錯誤的，在數據庫表中存在1：1或1：N關系這種較特殊的情況下，合并導致的不符合范式要求反而是合理的。
在我們設計數據庫的時候，一定要時刻考慮范式的要求。
摘要: 大家可能在spring中經?？吹竭@樣的定義：
PROPAGATION_REQUIRED,readOnlyPROPAGATION_REQUIRED
估計有好多朋友還沒有弄清楚里面的值的意思，仔細看完下面應該知道自己什么情況下面應該使用什么樣的聲明。^_^
閱讀全文
Spring也提供了聲明式事務管理。這是通過Spring AOP實現的。
Spring
中進行事務管理的通常方式是利用AOP（面向切片編程）的方式，為普通java類封裝事務控制，它是通過動態代理實現的，由于接口是延遲實例化的，
spring在這段時間內通過攔截器，加載事務切片。原理就是這樣，具體細節請參考jdk中有關動態代理的文檔。本文主要講解如何在spring中進行事
務控制。
動態代理的一個重要特征是，它是針對接口的，所以我們的dao要通過動態代理來讓spring接管事務，就必須在dao前面抽象出一個接口，當然如果沒有這樣的接口，那么spring會使用CGLIB來解決問題，但這不是spring推薦的方式，所以不做討論.
從考慮EJB CMT和Spring聲明式事務管理的相似以及不同之處出發是很有益的。 它們的基本方法是相似的：都可以指定事務管理到單獨的方法；如果需要可以在事務上 下文調用setRollbackOnly()方法。不同之處如下：
不象EJB CMT綁定在JTA上，Spring聲明式事務管理可以在任何環境下使用。 只需更改配置文件，它就可以和JDBC、JDO、Hibernate或其他的事務機制一起工作
Spring可以使聲明式事務管理應用到普通Java對象，不僅僅是特殊的類，如EJB
Spring提供聲明式回滾規則：EJB沒有對應的特性， 我們將在下面討論這個特性。回滾可以聲明式控制，不僅僅是編程式的
Spring允許你通過AOP定制事務行為。例如，如果需要，你可以在事務 回滾中插入定制的行為。你也可以增加任意的通知，就象事務通知一樣。使用 EJB CMT，除了使用setRollbackOnly()，你沒有辦法能 夠影響容器的事務管理
Spring不提供高端應用服務器提供的跨越遠程調用的事務上下文傳播。如 果你需要這些特性，我們推薦你使用EJB。然而，不要輕易使用這些特性。通常我 們并不希望事務跨越遠程調用
回滾規則的概念是很重要的：它們使得我們可以指定哪些異常應該發起自 動回滾。我們在配置文件中，而不是Java代碼中，以聲明的方式指定。因此，雖然我們仍 然可以編程調用TransactionStatus對象的 setRollbackOnly()方法來回滾當前事務，多數時候我們可以 指定規則，如MyApplicationException應該導致回滾。 這有顯著的優點，業務對象不需要依賴事務基礎設施。例如，它們通常不需要引 入任何Spring API，事務或其他任何東西。
EJB的默認行為是遇到系統異常（通常是運行時異常）， EJB容器自動回滾事務。EJB CMT遇到應用程序異常 （除了java.rmi.RemoteException外的checked異常）時不 會自動回滾事務。雖然Spring聲明式事務管理沿用EJB的約定（遇到unchecked 異常自動回滾事務），但是這是可以定制的。
按照我們的測試，Spring聲明式事務管理的性能要勝過EJB CMT。
通
常通過TransactionProxyFactoryBean設置Spring事務代理。我們需
要一個目標對象包裝在事務代理中。這個目標對象一般是一個普通Java對象的bean。當我
們定義TransactionProxyFactoryBean時，必須提供一個相關的 PlatformTransactionManager的引用和事務屬性。 事務屬性含有上面描述的事務定義。
<bean id="petStore"
class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
<property name="transactionManager"><ref bean="transactionManager"/></property>
<property name="target"><ref bean="petStoreTarget"/></property>
<property name="transactionAttributes">
<props>
<prop key="insert*">PROPAGATION_REQUIRED,-MyCheckedException</prop>
<prop key="update*">PROPAGATION_REQUIRED</prop>
<prop key="*">PROPAGATION_REQUIRED,readOnly</prop>
</props>
</property>
</bean>
事
務代理會實現目標對象的接口：這里是id為petStoreTarget的bean。（使用
CGLIB也可以實現具體類的代理。只要設置proxyTargetClass屬性為true就可以。
如果目標對象沒有實現任何接口，這將自動設置該屬性為true。通常，我們希望面向接口而不是
類編程。）使用proxyInterfaces屬性來限定事務代理來代 理指定接口也是可以的（一般來說是個好想法）。也可以通過從 org.springframework.aop.framework.ProxyConfig繼承或所有AOP代理工廠共享 的屬性來定制TransactionProxyFactoryBean的行為。
這里的transactionAttributes屬性定義在 org.springframework.transaction.interceptor.NameMatchTransactionAttributeSource 中的屬性格式來設置。這個包括通配符的方法名稱映射是很直觀的。注意 insert*的映射的值包括回滾規則。添加的-MyCheckedException 指定如果方法拋出MyCheckedException或它的子類，事務將 會自動回滾。可以用逗號分隔定義多個回滾規則。-前綴強制回滾，+前綴指定提交（這允許即使拋出unchecked異常時也可以提交事務，當然你自己要明白自己 在做什么）。
TransactionProxyFactoryBean允許你通過 “preInterceptors”和“postInterceptors”屬性設置“前”或“后”通知來提供額外的 攔截行為?？梢栽O置任意數量的“前”和“后”通知，它們的類型可以是 Advisor（可以包含一個切入點）， MethodInterceptor或被當前Spring配置支持的通知類型 （例如ThrowAdvice， AfterReturningtAdvice或BeforeAdvice， 這些都是默認支持的）。這些通知必須支持實例共享模式。如果你需要高級AOP特 性來使用事務，如有狀態的maxin，那最好使用通用的 org.springframework.aop.framework.ProxyFactoryBean， 而不是TransactionProxyFactoryBean實用代理創建者。
也可以設置自動代理：配置AOP框架，不需要單獨的代理定義類就可以生成類的 代理。
附兩個spring的事務配置例子：
<prop key="add">
PROPAGATION_REQUIRES_NEW, -MyException
</prop>
注：上面的意思是add方法將獨占一個事務，當事務處理過程中產生MyException異?；蛘咴摦惓５淖宇悓⒒貪L該事務。
<prop key="loadAll">
PROPAGATION_SUPPORTS, ISOLATION_READ_COMMITED, Readonly
</prop>
注：表示loadAll方法支持事務，而且不會讀取沒有提交事務的數據。它的數據為只讀（這樣有助于提高讀取的性能）
附A Spring中的所有事務策略
PROPAGATION_MANDATORY
PROPAGATION_NESTED
PROPAGATION_NEVER
PROPAGATION_NOT_SUPPORTED
PROPAGATION_REQUIRED
PROPAGATION_REQUIRED_NEW
PROPAGATION_SUPPORTS
附B Spring中所有的隔離策略：
ISOLATION_DEFAULT
ISOLATION_READ_UNCOMMITED
ISOLATION_COMMITED
ISOLATION_REPEATABLE_READ
ISOLATION_SERIALIZABLE