规范化关系模式设计
2014-10-02 09:52
204 查看
第一范式
存在非主属性对码的部分依赖关系 R(A,B,C) AB是码 C是非主属性 B-->C B决定C C部分依赖于B
第一范式
定义:如果关系R 中所有属性的值域都是单纯域,那么关系模式R是第一范式的
那么符合第一模式的特点就有
1)有主关键字
2)主键不能为空,
3)主键不能重复,
4)字段不可以再分
例如:
StudyNo | Name | Sex | Contact
20040901 john Male Email:kkkk@ee.net,phone:222456
20040901 mary famale email:kkk@fff.net phone:123455
以上的表就不符合,第一范式:主键重复(实际中数据库不允许重复的),而且Contact字段可以再分
所以变更为正确的是
StudyNo | Name | Sex | Email | Phone
20040901 john Male
kkkk@ee.net 222456
20040902 mary famale
kkk@fff.net 123455
第二范式
存在非主属性对码的传递性依赖 R(A,B,C) A是码 A -->B ,B-->C
定义:如果关系模式R是第一范式的,而且关系中每一个非主属性不部分依赖于主键,称R是第二范式的。
所以第二范式的主要任务就是
满足第一范式的前提下,消除部分函数依赖。
StudyNo | Name | Sex | Email | Phone | ClassNo | ClassAddress
01 john Male
kkkk@ee.net 222456 200401 A楼2
01 mary famale
kkk@fff.net 123455 200402 A楼3
这个表完全满足于第一范式,
主键由StudyNo和ClassNo组成,这样才能定位到指定行
但是,ClassAddress部分依赖于关键字(ClassNo-〉ClassAddress),
所以要变为两个表
表一
StudyNo | Name | Sex | Email | Phone | ClassNo
01 john Male
kkkk@ee.net 222456 200401
01 mary famale
kkk@fff.net 123455 200402
表二
ClassNo | ClassAddress
200401 A楼2
200402 A楼3
第三范式
不存在非主属性对码的传递性依赖以及部分性依赖 ,
StudyNo | Name | Sex | Email | bounsLevel | bouns
20040901 john Male
kkkk@ee.net 优秀 $1000
20040902 mary famale
kkk@fff.net 良 $600
这个完全满足了第二范式,但是bounsLevel和bouns存在传递依赖
更改为:
StudyNo | Name | Sex | Email | bouunsNo
20040901 john Male
kkkk@ee.net 1
20040902 mary famale
kkk@fff.net 2
bounsNo | bounsLevel | bouns
1 优秀 $1000
2 良 $600
这里我比较喜欢用bounsNo作为主键,
基于两个原因
1)不要用字符作为主键。可能有人说:如果我的等级一开始就用数值就代替呢?
2)但是如果等级名称更改了,不叫 1,2 ,3或优、良,这样就可以方便更改,所以我一般优先使用与业务无关的字段作为关键字。
一般满足前三个范式就可以避免数据冗余。
存在非主属性对码的部分依赖关系 R(A,B,C) AB是码 C是非主属性 B-->C B决定C C部分依赖于B
第一范式
定义:如果关系R 中所有属性的值域都是单纯域,那么关系模式R是第一范式的
那么符合第一模式的特点就有
1)有主关键字
2)主键不能为空,
3)主键不能重复,
4)字段不可以再分
例如:
StudyNo | Name | Sex | Contact
20040901 john Male Email:kkkk@ee.net,phone:222456
20040901 mary famale email:kkk@fff.net phone:123455
以上的表就不符合,第一范式:主键重复(实际中数据库不允许重复的),而且Contact字段可以再分
所以变更为正确的是
StudyNo | Name | Sex | Email | Phone
20040901 john Male
kkkk@ee.net 222456
20040902 mary famale
kkk@fff.net 123455
第二范式
存在非主属性对码的传递性依赖 R(A,B,C) A是码 A -->B ,B-->C
定义:如果关系模式R是第一范式的,而且关系中每一个非主属性不部分依赖于主键,称R是第二范式的。
所以第二范式的主要任务就是
满足第一范式的前提下,消除部分函数依赖。
StudyNo | Name | Sex | Email | Phone | ClassNo | ClassAddress
01 john Male
kkkk@ee.net 222456 200401 A楼2
01 mary famale
kkk@fff.net 123455 200402 A楼3
这个表完全满足于第一范式,
主键由StudyNo和ClassNo组成,这样才能定位到指定行
但是,ClassAddress部分依赖于关键字(ClassNo-〉ClassAddress),
所以要变为两个表
表一
StudyNo | Name | Sex | Email | Phone | ClassNo
01 john Male
kkkk@ee.net 222456 200401
01 mary famale
kkk@fff.net 123455 200402
表二
ClassNo | ClassAddress
200401 A楼2
200402 A楼3
第三范式
不存在非主属性对码的传递性依赖以及部分性依赖 ,
StudyNo | Name | Sex | Email | bounsLevel | bouns
20040901 john Male
kkkk@ee.net 优秀 $1000
20040902 mary famale
kkk@fff.net 良 $600
这个完全满足了第二范式,但是bounsLevel和bouns存在传递依赖
更改为:
StudyNo | Name | Sex | Email | bouunsNo
20040901 john Male
kkkk@ee.net 1
20040902 mary famale
kkk@fff.net 2
bounsNo | bounsLevel | bouns
1 优秀 $1000
2 良 $600
这里我比较喜欢用bounsNo作为主键,
基于两个原因
1)不要用字符作为主键。可能有人说:如果我的等级一开始就用数值就代替呢?
2)但是如果等级名称更改了,不叫 1,2 ,3或优、良,这样就可以方便更改,所以我一般优先使用与业务无关的字段作为关键字。
一般满足前三个范式就可以避免数据冗余。
相关文章推荐
- 关系数据库设计理论(5) 关系模式的规范化
- 第三章 关系模式的规范化设计
- Dot Net设计模式—适配器、桥接与外观三模式之间的关系
- 设计模式与泡mm的关系之visitor访问者模式及再思考
- 设计模式与泡mm的关系之state状态模式及再思考
- 设计模式与泡mm的关系之Observer观察者模式及再思考
- 设计模式与泡mm的关系之iterator迭代模式及再思考
- 设计模式与泡MM的关系
- 设计模式与泡mm的关系之template method模版方法模式及再思考
- 设计模式与泡mm的关系之Proxy代理模式及代理模式的再思考
- 设计模式与泡mm的关系之Memento备忘模式及再思考
- 论.NET反射、委托技术与设计模式关系
- 设计模式与泡mm的关系之Builder生成器模式及Builder模式的再思考
- 关系数据库设计的规范化与非规范化之争
- 设计模式与泡mm的关系之Decorator装饰者设计模式及装饰者设计模式的再思考
- [收藏]论.NET反射、委托技术与设计模式关系
- 设计模式与泡mm的关系之singleton及singleton的再思考
- 设计模式与泡mm的关系之Adapter适配器模式及适配器模式的再思考
- 设计模式与泡mm的关系之Command命令模式及再思考
- 设计模式与泡mm的关系之Mediator中介者模式及再思考