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中可通过触发器解决其缺点。以后我们共同做设计之时，也希望大家遵守以上几个范式。