求助——关于第2.5范式的问题

[totola147]

第三范式：消除非主属性对码的传递依赖 从而避免数据冗余 插入异常 删除异常

--现有表：
create table Student   --学生表
(
ID int identity(1,1) primary key,
userName varchar(20),
collegeName varchar(100),
)

create table DicCollege  --学院表（字典表）
(
ID int identity(1,1) primary key,
collegeName varchar(100),
)

描述：
学生表中，学院名称字段的取值来自下拉选单，不可以自由填值
学院名称的下拉选单的取值来自字典表 DicCollege的collegeName字段值

问题：
1 该数据库结构，属于2NF 还是3NF 抑或 2.5NF
2 如果问题一的答案为2NF 那么该结构 如何会有插入异常或删除异常的情况 请举例
3 该设计是否合理，抑或有更好的方法

解释：
之所以这样设计，是考虑了不满足3NF会有插入异常删除异常情况，于是建立的学院字典表，但又为了避免过多的表连接，所以学院值直接存入学生表的学院名称字段，而不是存学院ID，虽然有数据冗余，但是却避免了表连接，从而有更好的查询性能

[-Tracy-McGrady-]

忙着补考？新年快乐

[totola147]

引用 1 楼 yangsh0722 的回复:

忙着补考？新年快乐

....毕业一年半了

[-Tracy-McGrady-]

那还搞什么2.5范式，什么学生表

[totola147]

引用 3 楼 yangsh0722 的回复:

那还搞什么2.5范式，什么学生表

[-Tracy-McGrady-]

想死的心都有了？

[Kilin_Zhang]

3NF永远是一个美好的梦

[--小F--]

难道没有其他字段了？有时候只是尽量满足范式，但是不需要刻意去追求范式。

[mayuanf]

如果只有student表，是符合3nf规范的。 username和collegename作为student的属性依赖于主键。 但是考虑到college还可能会有其他的属性（就算现在没有也应该考虑未来的需求），所以应该另外维护一张college表。 但是lz的设计是违反3nf的。stu表内不应含有其他表的非主键。 "为了避免过多的表联接"，我不认为多join一个college表会造成过多的表join。何况这种为了避免表联接的设计一定会提高维护成本。建议还是存放collegeid。

[totola147]

引用 8 楼 mayuanf 的回复:

如果只有student表，是符合3nf规范的。 username和collegename作为student的属性依赖于主键。 但是考虑到college还可能会有其他的属性（就算现在没有也应该考虑未来的需求），所以应该另外维护一张college表。 但是lz的设计是违反3nf的。stu表内不应含有其他表的非主键。 "为了避免过多的表联接"，我不认为多join一个co……

“但是考虑到college还可能会有其他的属性（就算现在没有也应该考虑未来的需求），所以应该另外维护一张college表。” 我的方案是中本来就有college表，现在的设计，如果college增加属性对student没有任何影响 我举的这个只是个例子，并不是说生产环境中就只有一个表连接我想省去，而是有非常多的 比如说学生表里有学院ID 社团ID 班级ID 专业ID 。。。。这样的话 如果要查询学生的基本信息，要连接几张表呢 您没有理解我的设计，也没有理解我设计的意图 不过还是感谢您参与讨论

[totola147]

引用 7 楼 fredrickhu 的回复:

难道没有其他字段了？有时候只是尽量满足范式，但是不需要刻意去追求范式。

“没有其他字段了”您是指？ 我写这个只是个例子，并不是真的生产库，生产库中，往往用户表会和很多表关联，如果全都存外键的话，那么查询用户的基本信息会连接很多表 我想知道我这样的设计有没有什么缺陷，这个设计也不是自己想出来的，是从别人的项目中分析学来的，没有经过确定，不敢轻易使用