分析：
数据库设计应遵循三大范式分别为：
第一范式：确保表中每列的原子性（不可拆分）；
第二范式：确保表中每列与主键相关，而不能只与主键的某部分相关（主要针对联合主键），主键列与非主键列遵循完全函数依赖关系（完全依赖）；
第三范式：非主键列之间没有传递函数依赖关系（消除传递依赖）；
详述：
第一范式
需求描述：数据库系统中需要一个实体表，该表用来存储用户信息，其中“地址”这个属性，要求查询到省份、城市和详细地址。
例子：信息如下：
姓名：张红欣；性别：男； 年龄：26岁；年龄：26岁； 联系电话：0378-23459876； 省份：河南省； 城市：开封； 详细地址：朝阳区新华路23号；
姓名：王艳；性别：女；年龄：25；联系电话：021-2348768；省份：贵州省；城市：贵阳市；详细地址：南明区南明区狮峰路6号；
姓名：汪梅；性别：女；年龄：21；联系电话：0571-3876450；省份：浙江省；城市：杭州市；详细地址：滨江区滨康路352号；
针对以上需求，下面分别设计两种类型表格：
第一种表设计：不满足第一范式
tb_userInfo
分析：为什么不满足第一范式？因为region列不具有原子性，能拆分成省份、市和具体地址。
第二种表设计：满足第一范式
tb_userInfo
第二范式
需求描述：设计一个订单信息表，订单有多种商品，将订单编号和商品编号作为联合主键。
第一种表设计：不满足第二范式
分析：订单编号和商品编号作为联合主键，由于商品名称，单位，价格这几列只与商品编号有关，与订单
编号无关，因此与主键（联合主键）无关，违反范式第二原则。
第二种表设计：满足第二范式
分析：把第一种设计表进行拆分，把商品信息分离到另一个表中，把订单项目表也分离到另一个表中。
第三范式
分析：在表中，一个UserID能确定一个UserLevel。这样，UserID依赖于StudentNo和CardNo，而UserLevel又依
赖于UserID，这就导致了传递依赖，3NF就是消除这种依赖。
将以上表格拆分成如下表格，以满足第三范式：
注释，以上内容参考博客网址：
http://www.cnblogs.com/springside-example/archive/2011/10/06/2530207.html
http://www.cnblogs.com/linjiqin/archive/2012/04/01/2428695.html#undefined