1。在一條街上，有5座房子，噴了5種顏色。
2。每個房子里住著不同國籍的人。
3。每個人喝著不同的飲料，抽不同品牌的香煙，養不同的寵物。
問題是：誰養魚？
提示：
1、英國人住紅色房子。
2、瑞典人養狗。
3、丹麥人喝茶。
4、綠色房子在白色房子左面。
5、綠色房子主人喝咖啡。
6、抽Pall Mall香煙的人養鳥。
7、黃色房子主人抽Dunhill香煙。
8、住在中間房子的人喝牛奶。
9、挪威人住第一間房。
10、抽Blends香煙的人住在養貓的人隔壁。
11、養馬的人住抽Dunhill香煙的人隔壁。
12、抽Blue Master的人喝啤酒。
13、德國人抽Prince香煙。
14、挪威人住藍色房子隔壁。
15、抽Blends香煙的人有一個喝水的鄰居。
**以下內容為網上收集后整理而成,如有錯誤或描述不準確的地方或是別的請多指教.
當你使用Tomcat作為Web Server的時候，是不是會想過這樣的一個問題：如何利用Tomcat建立多個Web應用 呢？
要實現這一點是很簡單的,也有多種方法。(以下說明使用%tomcat_home%代表Tomcat安裝目錄)。
一.首先介紹一下Tomcat及server.xml.
Tomcat服務器是由一系列的可配置的組件構成,tomcat的組件可以在%tomcat_home%/conf/server.xml文件中進行配置,每個Tomcat組件和server.xml文件的一種配置元素對應.
主要分為4類:
1.頂層類元素:包括<Server>和<Service>,他們位于整個配置文件的頂層.
<Server>元素代表整個Catalina Servlet 容器,由org.apache.catalin.Server接口定義.<Server>包含一個或多個<Service>元素.
<Service>元素由org.apache.catalin.Service 接口定義.<Service>包含一個<Engine>元素,及一個或多個<Connector>元素.多個<Connector>元素共享一個<Engine>元素.
2.連接器類元素
連接器類代表了介于客戶與服務之間的通信接口,負責將客戶的請求發送給服務器,并將服務器的響應結果傳遞給客戶.
<Connector>元素由org.apache.catalin.Connector 接口定義.代表了與客戶程序實際交互的組件,它負責接收客戶請求,以及向客戶返回響應結果.
3.容器類元素
容器類元素代表處理客戶請求并生成響應的組件.包括<Engine> <Host>和<Context>.
<Engine>元素由org.apache.catalin.Engine 接口定義.每個<Service>只能包含一個<Engine>元素,<Engine>元素處理在同一個<Service>中的所有<Connector>元素收到的客戶請求.
<Host>元素由org.apache.catalin.Host 接口定義.一個<Engine>元素中可以包含多個<Host>元素.每個<Host>元素定義了一個虛擬主機,她可以包含一個或多個Web 應用.
<Context>元素由org.apache.catalin.Context 接口定義.代表了運行在虛擬主機上的一個Web 應用.一個<Host>元素可以包含多個<Context>元素
4.嵌套類元素
嵌套類元素代表了可以加到容器中的組件,如<Logger> <Realm>和<Value>.
關于server.xml的更多信息,可以參考Tomcat的文檔:/webapps/tomcat-docs/config/index.html
樣例:
<Server>
<Service name="Catalina">
<Connector acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true" port="8080" redirectPort="8443" maxSpareThreads="75" maxThreads="150" minSpareThreads="25"/>
<Connector port="8009" protocol="AJP/1.3" protocolHandlerClassName="org.apache.jk.server.JkCoyoteHandler" redirectPort="8443"/>
<Engine defaultHost="localhost" name="Catalina">
<Host appBase="webapps" name="localhost">
<Logger className="org.apache.catalina.logger.FileLogger" prefix="localhost_log." suffix=".txt" timestamp="true"/>
</Host>
<Logger className="org.apache.catalina.logger.FileLogger" prefix="catalina_log." suffix=".txt" timestamp="true"/>
<Realm className="org.apache.catalina.realm.UserDatabaseRealm"/>
</Engine>
</Service>
</Server>
二.建立多個Web應用方法:
1.通過配置多個<Context>元素(這是最為普遍的方法)
在<Host>下配置多個<Context>元素
<Context path="app1" docBase="E:/workspace/app1/WebRoot" debug="0" reloadable="true"></Context>
<Context path="app2" docBase="E:/workspace/app2/WebRoot" debug="0" reloadable="true"></Context>
然后通過 主機名:端口/應用名 訪問,如: http://localhost:8080/app1 或 http://localhost:8080/app2
2.通過配置多個<Host>元素
在<Engine>下配置多個<Host>元素
<Host appBase="webapps" name="192.168.1.110">
<Context path="" docBase="E:/workspace/app1/WebRoot" debug="0" reloadable="true"></Context>
</Host>
<Host appBase="webapps" name="192.168.1.114">
<Context path="" docBase="E:/workspace/app2/WebRoot" debug="0" reloadable="true"></Context>
</Host>
然后通過 主機名:端口 訪問,如: http://192.168.1.110:8080 或 http://192.168.1.114:8080
需要注意的是這樣需要機器連接到局域網上.
3.通過配置多個<Service>元素(多端口 多應用)
在<Server>下配置多個<Service>元素
<Service name="Catalina">
<Connector acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true" port="8080" redirectPort="8453" maxSpareThreads="75" maxThreads="150" minSpareThreads="25"/>
<Connector port="8019" protocol="AJP/1.3" protocolHandlerClassName="org.apache.jk.server.JkCoyoteHandler" redirectPort="8453"/>
<Engine defaultHost="localhost" name="Catalina">
<Host appBase="webapps" name="localhost">
<Context path="" docBase="E:/workspace/app1/WebRoot" debug="0" reloadable="true"></Context>
</Host>
<Realm className="org.apache.catalina.realm.UserDatabaseRealm"/>
</Engine>
</Service>
<Service name="Catalina2">
<Connector acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true" port="8090" redirectPort="8453" maxSpareThreads="75" maxThreads="150" minSpareThreads="25"/>
<Connector port="8019" protocol="AJP/1.3" protocolHandlerClassName="org.apache.jk.server.JkCoyoteHandler" redirectPort="8453"/>
<Engine defaultHost="localhost" name="Catalina">
<Host appBase="webapps" name="localhost">
<Context path="" docBase="E:/workspace/app2/WebRoot" debug="0" reloadable="true"></Context>
</Host>
<Realm className="org.apache.catalina.realm.UserDatabaseRealm"/>
</Engine>
</Service>
定義了兩個Service分別是Catalina和Catalina2,偵聽的端口分別是8080和8090
然后通過 主機名:端口 訪問,如: http://localhost:8080 或 http://localhost:8090
返回數據庫總結目錄
| 數據類型 |
參數 |
描述 |
| char(n) |
n=1 to 2000字節 |
定長字符串，n字節長，如果不指定長度，缺省為1個字節長（一個漢字為2字節） |
| varchar2(n) |
n=1 to 4000字節 |
可變長的字符串，具體定義時指明最大長度n，
這種數據類型可以放數字、字母以及ASCII碼字符集(或者EBCDIC等數據庫系統接受的字符集標準)中的所有符號。
如果數據長度沒有達到最大值n，Oracle 8i會根據數據大小自動調節字段長度，
如果你的數據前后有空格，Oracle 8i會自動將其刪去。VARCHAR2是最常用的數據類型。
可做索引的最大長度3209。 |
| number(m,n) |
m=1 to 38
n=-84 to 127 |
可變長的數值列，允許0、正值及負值，m是所有有效數字的位數，n是小數點以后的位數。
如：number(5,2)，則這個字段的最大值是99,999，如果數值超出了位數限制就會被截取多余的位數。
如：number(5,2)，但在一行數據中的這個字段輸入575.316，則真正保存到字段中的數值是575.32。
如：number(3,0)，輸入575.316，真正保存的數據是575。 |
| date |
無 |
從公元前4712年1月1日到公元4712年12月31日的所有合法日期，
Oracle 8i其實在內部是按7個字節來保存日期數據，在定義中還包括小時、分、秒。
缺省格式為DD-MON-YY，如07-11月-00 表示2000年11月7日。 |
| long |
無 |
可變長字符列，最大長度限制是2GB，用于不需要作字符串搜索的長串數據，如果要進行字符搜索就要用varchar2類型。
long是一種較老的數據類型，將來會逐漸被BLOB、CLOB、NCLOB等大的對象數據類型所取代。 |
| raw(n) |
n=1 to 2000 |
可變長二進制數據，在具體定義字段的時候必須指明最大長度n，Oracle 8i用這種格式來保存較小的圖形文件或帶格式的文本文件，如Miceosoft Word文檔。
raw是一種較老的數據類型，將來會逐漸被BLOB、CLOB、NCLOB等大的對象數據類型所取代。 |
| long raw |
無 |
可變長二進制數據，最大長度是2GB。Oracle 8i用這種格式來保存較大的圖形文件或帶格式的文本文件，如Miceosoft Word文檔，以及音頻、視頻等非文本文件。
在同一張表中不能同時有long類型和long raw類型，long raw也是一種較老的數據類型，將來會逐漸被BLOB、CLOB、NCLOB等大的對象數據類型所取代。 |
blob
clob
nclob |
無 |
三種大型對象(LOB)，用來保存較大的圖形文件或帶格式的文本文件，如Miceosoft Word文檔，以及音頻、視頻等非文本文件，最大長度是4GB。
LOB有幾種類型，取決于你使用的字節的類型，Oracle 8i實實在在地將這些數據存儲在數據庫內部保存。
可以執行讀取、存儲、寫入等特殊操作。 |
| bfile |
無 |
在數據庫外部保存的大型二進制對象文件，最大長度是4GB。
這種外部的LOB類型，通過數據庫記錄變化情況，但是數據的具體保存是在數據庫外部進行的。
Oracle 8i可以讀取、查詢BFILE，但是不能寫入。
大小由操作系統決定。 |
返回數據庫總結目錄
表A MySQL 數據類型
|
數據類型
|
描述
|
字節
|
推薦使用
|
|
SMALLINT
|
整數，從-32000到 +32000范圍
|
2
|
存儲相對比較小的整數。
比如: 年紀，數量
|
|
INT
|
整數，從-2000000000 到 +2000000000 范圍
|
4
|
存儲中等整數
例如: 距離
|
|
BIGINT
|
不能用SMALLINT 或 INT描述的超大整數。
|
8
|
存儲超大的整數
例如: 科學/數學數據
|
|
FLOAT
|
單精度浮點型數據
|
4
|
存儲小數數據
例如:測量，溫度
|
|
DOUBLE
|
雙精度浮點型數據
|
8
|
需要雙精度存儲的小數數據
例如:科學數據
|
|
DECIMAL
|
用戶自定義精度的浮點型數據
|
變量;取決于精度與長度
|
以特別高的精度存儲小數數據。
例如:貨幣數額，科學數據
|
|
CHAR
|
固定長度的字符串
|
特定字符串長度(高達255字符)
|
存儲通常包含預定義字符串的變量
例如: 定期航線，國家或郵編
|
|
VARCHAR
|
具有最大限制的可變長度的字符串
|
變量; 1 + 實際字符串長度 (高達 255 字符)
|
存儲不同長度的字符串值(高達一個特定的最大限度).
例如:名字，密碼，短文標簽
|
|
TEXT
|
沒有最大長度限制的可變長度的字符串
|
Variable; 2 +聽 actual string length
|
存儲大型文本數據
例如: 新聞故事，產品描述
|
|
BLOB
|
二進制字符串
|
變量；2 + 實際字符串長度
|
存儲二進制數據
例如:圖片，附件，二進制文檔
|
|
DATE
|
以 yyyy-mm-dd格式的日期
|
3
|
存儲日期
例如:生日，產品滿期
|
|
TIME
|
以 hh:mm:ss格式的時間
|
3
|
存儲時間或時間間隔
例如:報警聲，兩時間之間的間隔，任務開始/結束時間
|
|
DATETIME
|
以yyyy-mm-ddhh:mm:ss格式結合日期和時間
|
8
|
存儲包含日期和時間的數據
例如:提醒的人，事件
|
|
TIMESTAMP
|
以yyyy-mm-ddhh:mm:ss格式結合日期和時間
|
4
|
記錄即時時間
例如：事件提醒器，“最后進入”的時間標記
|
|
YEAR
|
以 yyyy格式的年份
|
1
|
存儲年份
例如:畢業年，出生年
|
|
ENUM
|
一組數據，用戶可從中選擇其中一個
|
1或 2個字節
|
存儲字符屬性，只能從中選擇之一
例如:布爾量選擇，如性別
|
|
SET
|
一組數據，用戶可從中選擇其中0，1或更多。
|
從1到8字節;取決于設置的大小
|
存儲字符屬性，可從中選擇多個字符的聯合。
例如:多選項選擇，比如業余愛好和興趣。
|
對于一個完整的列表和詳細描述，可以查看MySQL manual。你也可以閱讀文章Choosing the Right Type for a Column。
現在的程序員找工作不太容易，而我招聘程序員也不太容易，雙方的需求總是有著很大的差距。來面試的人里面有一半是剛剛畢業或者剛剛參加XX計算機培訓出來的，對于Asp.net編程的理解，就是打開Visual studio，新建一個頁面，拖拖控件，雙擊一個按鈕寫一下SQL操作的代碼，僅此而已。
以前我在面試的時候喜歡問他們有沒有學過設計模式，有沒有看過敏捷編程，知不知道測試驅動開發，喜歡上什么樣的網站，知不知道現在互聯網領域流行什么。后來我就不怎么問了，因為沒有一個人答的出來。當然，這些東西對于一個程序員崗位來說并不是必須的，但是我們是一個互聯網公司，而且是個小型的互聯網公司。首先你必須要了解這個行業，才有可能有自己的想法。要了解它，就必須熱愛它。如果只是因為自己學了編程這個東西，而不得不來找一份寫代碼的工作，那么我可以假設，你除了完成我告訴你的功能函數，是不會為公司提出什么建設性的意見和想法的。
退一步講，即使你喜歡的并不是互聯網，你也沒想過創業，但是要想做好一份工作，你首先要喜歡這份工作本身。如果你喜歡編程，喜歡寫代碼所帶來的美好的感覺，那么你應該時刻關注著這個領域的新的動向，和更高層次的要求。我當然不是說你應該去學習所有新出來的技術和語言，語言其實并不重要，重要的編程的思想本身。了解設計模式的人所做出來的程序架構，一定比從沒聽說過設計模式的人要好的多。雖然我們在實際工作中也沒有要求一定要使用測試驅動開發的模式，但是知道這些概念，意味著你喜歡編程這份工作，意味著你時刻在關注著這個行業，而不是只是為了上班的時候完成老板的任務，下班以后就連看都懶的看電腦一眼。
好的工作狀態是需要熱情的，更好的工作狀態是需要激情的。
國內都說程序員的工作只能在30歲以前做，這句話有幾個基本前提：首先，大部分IT公司不夠大，只能以最小的成本解決最根本的需求，人過30，對待遇的要求當然不能跟剛出校門的學生比，而學生經過一段時間的培訓，在工作上完全能夠滿足公司的要求，所以，公司不會養一群年紀大的程序員。其次，編碼這種工作，本身是無聊之極的，所以公司需要的是有相當有創意的員工，敢于打破原有的思考習慣，以特殊的角度看世界，這一點，30歲以上的人是比較難做到的。在同一個領域做的時間越長，思維就越容易僵化，越不敢輕易的打破傳統。再者，外人看IT業都是高薪行業，如果過了30歲事業還沒有起色，基本他也做不下去了。另外，程序員是個很累的活，不但是重腦力勞動，而且是重體力勞動，過了30歲以后身體狀況下滑，身體也很難承受的住。最后，程序員創業是最容易的，技術基本不需要成本，弄臺服務器，或者更簡單的租個空間，自己花一兩個月的人力成本，一個網站就起來了，在這個全民創業的大環境下，能忍受誘惑的人，不多。
那么，如果到了30歲，創業也沒有成功，自己的公司又沒有上市或者被收購，自己還是一個普普通通的打工者，那怎么辦呢？其實放遠了看，大部分人在四五十歲或者一直到退休，也就是拿著兩三千塊錢的工資，一直這樣默默無聞的做下去，而在互聯網這個躁動的行業，人們似乎已經很難接受這種現狀了。因此，你需要提前給自己找好出路。
首先，如果你真的對編程充滿激情，你愿意在某一個方向深鉆下去，成為該領域數一數二的專家，那是最好不過了。中國現在真正缺少的就是這一類人，但是，前提是你可以解決自己的溫飽問題，不用因為老板的干涉而每次將自己的活在不完美的狀態下丟在一旁。
其次，因為項目經驗的積累，你的能力足以領導多人的團隊，進行溝通協調和管理，那么，你可以做一個部門經理或者項目經理，你只需要解決10%最核心的問題，其它的大可以交給團隊里精力充沛的年輕人去做。
再次，如果你覺得自己在編程方面并沒有太高的天分，再做下去也很難達到下一個高度，那么你可以轉行去做實施或者銷售。有開發背景的人做軟件實施的時候可以更清晰的看到問題所在，不用跟后面的開發團隊扯皮，小的問題還可以幫用戶當場解決，博得用戶的好感。做銷售也一樣，可以迅速的理解用戶的需求背后隱藏的東西，并在開發難度和用戶的預算之間找到平衡點，省的簽下了單子回去再被開發人員罵，功能開發不出來回來再被客戶罵。
如果你覺得由于某些原因（比如太內向），自己連實施和銷售也做不了，那或許你還可以去某個中小學謀個一官半職，畢竟，你跟那些學校的老師比起來，有真材實料的多了。
如果你連這個也做不了……我也不知道你還能做什么了，也許，網游就是你的精神棲息地。
本文來源：http://ilikes.blog.sohu.com/
返回數據庫總結目錄
關系數據庫設計之時是要遵守一定的規則的。尤其是數據庫范式 現簡單介紹1NF（第一范式），2NF（第二范式），3NF（第三范式）和BCNF，另有第四范式和第五范式留到以后再介紹。 在你設計數據庫之時，若能符合這幾個范式，你就是數據庫設計的高手。
第一范式（1NF）：在關系模式R中的每一個具體關系r中，如果每個屬性值 都是不可再分的最小數據單位，則稱R是第一范式的關系。例：如職工號，姓名，電話號碼組成一個表（一個人可能有一個辦公室電話 和一個家里電話號碼） 規范成為1NF有三種方法：
一是重復存儲職工號和姓名。這樣，關鍵字只能是電話號碼。
二是職工號為關鍵字，電話號碼分為單位電話和住宅電話兩個屬性
三是職工號為關鍵字，但強制每條記錄只能有一個電話號碼。
以上三個方法，第一種方法最不可取，按實際情況選取后兩種情況。
第二范式（2NF）：如果關系模式R（U，F）中的所有非主屬性都完全依賴于任意一個候選關鍵字，則稱關系R 是屬于第二范式的。
例：選課關系 SCI（SNO，CNO，GRADE，CREDIT）其中SNO為學號， CNO為課程號，GRADEGE 為成績，CREDIT 為學分。 由以上條件，關鍵字為組合關鍵字（SNO，CNO）
在應用中使用以上關系模式有以下問題：
a.數據冗余，假設同一門課由40個學生選修，學分就 重復40次。
b.更新異常，若調整了某課程的學分，相應的元組CREDIT值都要更新，有可能會出現同一門課學分不同。
c.插入異常，如計劃開新課，由于沒人選修，沒有學號關鍵字，只能等有人選修才能把課程和學分存入。
d.刪除異常，若學生已經結業，從當前數據庫刪除選修記錄。某些門課程新生尚未選修，則此門課程及學分記錄無法保存。
原因：非關鍵字屬性CREDIT僅函數依賴于CNO，也就是CREDIT部分依賴組合關鍵字（SNO，CNO）而不是完全依賴。
解決方法：分成兩個關系模式 SC1（SNO，CNO，GRADE），C2（CNO，CREDIT）。新關系包括兩個關系模式，它們之間通過SC1中的外關鍵字CNO相聯系，需要時再進行自然聯接，恢復了原來的關系
第三范式（3NF）：如果關系模式R（U，F）中的所有非主屬性對任何候選關鍵字都不存在傳遞信賴，則稱關系R是屬于第三范式的。
例：如S1（SNO，SNAME，DNO，DNAME，LOCATION） 各屬性分別代表學號，
姓名，所在系，系名稱，系地址。
關鍵字SNO決定各個屬性。由于是單個關鍵字，沒有部分依賴的問題，肯定是2NF。但這關系肯定有大量的冗余，有關學生所在的幾個屬性DNO，DNAME，LOCATION將重復存儲，插入，刪除和修改時也將產生類似以上例的情況。
原因：關系中存在傳遞依賴造成的。即SNO -> DNO。 而DNO -> SNO卻不存在，DNO -> LOCATION, 因此關鍵遼 SNO 對 LOCATION 函數決定是通過傳遞依賴 SNO -> LOCATION 實現的。也就是說，SNO不直接決定非主屬性LOCATION。
解決目地：每個關系模式中不能留有傳遞依賴。
解決方法：分為兩個關系 S（SNO，SNAME，DNO），D（DNO，DNAME，LOCATION）
注意：關系S中不能沒有外關鍵字DNO。否則兩個關系之間失去聯系。
BCNF：如果關系模式R（U，F）的所有屬性（包括主屬性和非主屬性）都不傳遞依賴于R的任何候選關鍵字，那么稱關系R是屬于BCNF的。或是關系模式R，如果每個決定因素都包含關鍵字（而不是被關鍵字所包含），則RCNF的關系模式。
例：配件管理關系模式 WPE（WNO，PNO，ENO，QNT）分別表倉庫號，配件號，職工號，數量。有以下條件
a.一個倉庫有多個職工。
b.一個職工僅在一個倉庫工作。
c.每個倉庫里一種型號的配件由專人負責，但一個人可以管理幾種配件。
d.同一種型號的配件可以分放在幾個倉庫中。
分析：由以上得 PNO 不能確定QNT，由組合屬性（WNO，PNO）來決定，存在函數依賴（WNO，PNO） -> ENO。由于每個倉庫里的一種配件由專人負責，而一個人可以管理幾種配件，所以有組合屬性（WNO，PNO）才能確定負責人，有（WNO，PNO）-> ENO。因為 一個職工僅在一個倉庫工作，有ENO -> WNO。由于每個倉庫里的一種配件由專人負責，而一個職工僅在一個倉庫工作，有 （ENO，PNO）-> QNT。
找一下候選關鍵字，因為（WNO，PNO） -> QNT，（WNO，PNO）-> ENO ，因此 （WNO，PNO）可以決定整個元組，是一個候選關鍵字。根據ENO->WNO，（ENO，PNO）->QNT，故（ENO，PNO）也能決定整個元組，為另一個候選關鍵字。屬性ENO，WNO，PNO 均為主屬性，只有一個非主屬性QNT。它對任何一個候選關鍵字都是完全函數依賴的，并且是直接依賴，所以該關系模式是3NF。
分析一下主屬性。因為ENO->WNO，主屬性ENO是WNO的決定因素，但是它本身不是關鍵字，只是組合關鍵字的一部分。這就造成主屬性WNO對另外一個候選關鍵字（ENO，PNO）的部 分依賴，因為（ENO，PNO）-> ENO但反過來不成立，而P->WNO，故（ENO，PNO）-> WNO 也是傳遞依賴。
雖然沒有非主屬性對候選關鍵遼的傳遞依賴，但存在主屬性對候選關鍵字的傳遞依賴，同樣也會帶來麻煩。如一個新職工分配到倉庫工作，但暫時處于實習階段，沒有獨立負責對某些配件的管理任務。由于缺少關鍵字的一部分PNO而無法插入到該關系中去。又如某個人改成不管配件了去負責安全，則在刪除配件的同時該職工也會被刪除。
解決辦法：分成管理EP（ENO，PNO，QNT），關鍵字是（ENO，PNO）工作EW（ENO，WNO）其關鍵字是ENO
缺點：分解后函數依賴的保持性較差。如此例中，由于分解,函數依賴（WNO，PNO）-> ENO 丟失了, 因而對原來的語義有所破壞。沒有體現出每個倉庫里一種部件由專人負責。有可能出現 一部件由兩個人或兩個以上的人來同時管理。因此，分解之后的關系模式降低了部分完整性約束。
一個關系分解成多個關系，要使得分解有意義，起碼的要求是分解后不丟失原來的信息。這些信息不僅包括數據本身，而且包括由函數依賴所表示的數據之間的相互制約。進行分解的目標是達到更高一級的規范化程度，但是分解的同時必須考慮兩個問題：無損聯接性和保持函數依賴。有時往往不可能做到既有無損聯接性，又完全保持函數依賴。需要根據需要進行權衡。
1NF直到BCNF的四種范式之間有如下關系：
BCNF包含了3NF包含2NF包含1NF
小結：
目地：規范化目的是使結構更合理，消除存儲異常，使數據冗余盡量小，便于插入、刪除和更新
原則：遵從概念單一化 "一事一地"原則，即一個關系模式描述一個實體或實體間的一種聯系。規范的實質就是概念的單一化。
方法：將關系模式投影分解成兩個或兩個以上的關系模式。
要求：分解后的關系模式集合應當與原關系模式"等價"，即經過自然聯接可以恢復原關系而不丟失信息，并保持屬性間合理的聯系。
注意：一個關系模式結這分解可以得到不同關系模式集合，也就是說分解方法不是唯一的。最小冗余的要求必須以分解后的數據庫能夠表達原來數據庫所有信息為前提來實現。其根本目標是節省存儲空間，避免數據不一致性，提高對關系的操作效率，同時滿足應用需求。實際上，并不一定要求全部模式都達到BCNF不可。有時故意保留部分冗余可能更方便數據查詢。尤其對于那些更新頻度不高，查詢頻度極高的數據庫系統更是如此。
在關系數據庫中，除了函數依賴之外還有多值依賴，聯接依賴的問題，從而提出了第四范式，第五范式等更高一級的規范化要求。在此，以后再談。
各位朋友，你看過后有何感想，其實，任何一本數據庫基礎理論的書都會講這些東西，考慮到很多網友是半途出家，來做數據庫。特找一本書大抄特抄一把，各位有什么問題，也別問我了，自已去找一本關系數據庫理論的書去看吧，說不定，對各位大有幫助。說是說以上是基礎理論的東西，請大家想想，你在做數據庫設計的時候有沒有考慮過遵過以上幾個范式呢，有沒有在數據庫設計做得不好之時，想一想，對比以上所講，到底是違反了第幾個范式呢？
我見過的數據庫設計，很少有人做到很符合以上幾個范式的，一般說來，第一范式大家都可以遵守，完全遵守第二第三范式的人很少了，遵守的人一定就是設計數據庫的高手了，BCNF的范式出現機會較少，而且會破壞完整性，你可以在做設計之時不考慮它，當然在ORACLE中可通過觸發器解決其缺點。以后我們共同做設計之時，也希望大家遵守以上幾個范式。