27,581
社区成员
发帖
与我相关
我的任务
分享数据库设计心得（系统设计四段式）
小弟在这里献丑了，这是小弟这两三年对数据库设计的一点体会，并经一恩师指点总改证总结出来的，这个并安恩师的法写了一下。
这里面所课的，是从一个比较大的方向出发。还望各位大哥指点
1、数据的确定性
2、数据的流通性
3、数据的事件性
4、时间的迁移性
1、数据的确定性，指所有的数据在后台一定要绝对的确定，是一种广义上的惟一性，
因为数据是不可能做到惟一的，但一定可以做到确定，但要注意，确定与惟一是不一
样的，比如说，一个学生的姓名，在你的后台库里一定是确定的，不能出现二义性，
不管有几种，他应该是确定的。
2、数据必须要有时间迁移性，比如像”学生考勤录入”：要获取学生的姓名，就应该
是传他的学生编号与时间给一存储过程，存储过程必须返回那一时刻学生的信息，比如“转班、退学、休学、或又复学”，都能在时间上体现出来，简单一句来说，你前
台读取数据时都要有时间性
好了，说归说，关键还是设计方法,设计方法是从第三点出发的，即数据的事件
性，比如客户，现在提出功能要求：设计一个系统，能实现学生的考勤信息管理,问：
你该如何进行需求分析，并进而设计这一后台局部模块,第一个当然是需求分析，但
怎么分析才最快最有价值,数据的事件性，即每一个功能模块都应该有一张核心数据
表,而核心数据表一般都是事件表,《核心事件表都是从表》，利用踢出的方法可以最
快的速度建出后台模块 ,针对这一模块就可以设想有一张核心事件表，就称为“考勤
信息明细表” 进而你就要分析，要存储考勤信息需要哪些信息，就要与客户交互，
客户虽然不一定很懂，但他一定懂自己要什么 比如我们可以问，考勤主要存哪些信
息那客户肯定会说类似的话：需要存储考勤的学期、期、任课老师、科目、旷课、迟到什么的，核心事件表最大的特征就是都有事件性：如：某年某月某时间谁发生了什么事 ， 那这个模块的核心表就可以初步定为：学期、日期、节次、科目、任课老师、行为,然后再一个个字段询问是否必需或有没有少的 .
等核心表建完，再根据第一点：数据的确定性来判定字段是否要踢出，再根据数据的流通性来确定其关系，最后根据时间的迁移特征来决定是否要建迁移明细表。
最终用关系演算得出结果：如果一个模块内只包含一个核心事件表，而其余的都是逻辑主表或逻辑从表，那这一模块所任意建出的视图都是合理的。
经过实践证明，这样的方法是可以很快建出健状的后台库，稳定
这里面所课的，是从一个比较大的方向出发。还望各位大哥指点
1、数据的确定性
2、数据的流通性
3、数据的事件性
4、时间的迁移性
1、数据的确定性，指所有的数据在后台一定要绝对的确定，是一种广义上的惟一性，
因为数据是不可能做到惟一的，但一定可以做到确定，但要注意，确定与惟一是不一
样的，比如说，一个学生的姓名，在你的后台库里一定是确定的，不能出现二义性，
不管有几种，他应该是确定的。
2、数据必须要有时间迁移性，比如像”学生考勤录入”：要获取学生的姓名，就应该
是传他的学生编号与时间给一存储过程，存储过程必须返回那一时刻学生的信息，比如“转班、退学、休学、或又复学”，都能在时间上体现出来，简单一句来说，你前
台读取数据时都要有时间性
好了，说归说，关键还是设计方法,设计方法是从第三点出发的，即数据的事件
性，比如客户，现在提出功能要求：设计一个系统，能实现学生的考勤信息管理,问：
你该如何进行需求分析，并进而设计这一后台局部模块,第一个当然是需求分析，但
怎么分析才最快最有价值,数据的事件性，即每一个功能模块都应该有一张核心数据
表,而核心数据表一般都是事件表,《核心事件表都是从表》，利用踢出的方法可以最
快的速度建出后台模块 ,针对这一模块就可以设想有一张核心事件表，就称为“考勤
信息明细表” 进而你就要分析，要存储考勤信息需要哪些信息，就要与客户交互，
客户虽然不一定很懂，但他一定懂自己要什么 比如我们可以问，考勤主要存哪些信
息那客户肯定会说类似的话：需要存储考勤的学期、期、任课老师、科目、旷课、迟到什么的，核心事件表最大的特征就是都有事件性：如：某年某月某时间谁发生了什么事 ， 那这个模块的核心表就可以初步定为：学期、日期、节次、科目、任课老师、行为,然后再一个个字段询问是否必需或有没有少的 .
等核心表建完，再根据第一点：数据的确定性来判定字段是否要踢出，再根据数据的流通性来确定其关系，最后根据时间的迁移特征来决定是否要建迁移明细表。
最终用关系演算得出结果：如果一个模块内只包含一个核心事件表，而其余的都是逻辑主表或逻辑从表，那这一模块所任意建出的视图都是合理的。
经过实践证明，这样的方法是可以很快建出健状的后台库，稳定
...全文
请发表友善的回复…
发表回复
web2f 2009-12-09
- 打赏
- 举报
温固一下下
mengmou 2007-03-15
- 打赏
- 举报
感觉就是E-R理论这些东西啊。
人鱼传说 2007-02-06
- 打赏
- 举报
"存储在表中的数据不得依赖表的任何域"中的域是什么意思哟
Yang_ 2007-02-05
- 打赏
- 举报
Mark
支持ashzs((可以包含中文字符))
支持ashzs((可以包含中文字符))
w75251455 2007-02-05
- 打赏
- 举报
to:netcup(茶杯)
帅哥~~~数据库的6个范式~~~有没有书面的好资料~~可否给些!!!!谢谢啦~~
也感谢楼主........精神可+
帅哥~~~数据库的6个范式~~~有没有书面的好资料~~可否给些!!!!谢谢啦~~
也感谢楼主........精神可+
DelphiStudy 2007-02-05
- 打赏
- 举报
好贴，谢谢楼主和楼上兄弟分享
cn_tigers 2007-02-05
- 打赏
- 举报
3nf的例子去下面可以看到,也是抄的,講得簡單一些.例子詳細一細.
http://blog.sina.com.cn/u/1080235083
http://blog.sina.com.cn/u/1080235083
cn_tigers 2007-02-05
- 打赏
- 举报
基本上用不上4nf,5nf,6nf確實我也沒用到過.轉個貼子給上上樓的.
标准化是IT数据库专业人士的戒律之一，数据建模工程师、数据库管理员和SQL开发者都必须遵守这一戒律。我们很早就了解它的原理和范式。
但是对大部分数据库进行了解发现：它们至多执行了第三范式（3NF）。很少有数据库执行了更高范式，如Boyce-Codd范式（BCNF）、第四范式（4NF）和第五范式（5NF）。那么，为什么大多数数据库设计员没有超出3NF呢？
范式简介
为了回答上述问题，了解3NF、BCNF、4NF和5NF之间的区别很重要。以下为每个范式的准确定义。
第一范式（1NF）
每个表必须有一个首要键，即最少的一组属性，它与每条记录一一对应。通过适当定义键属性和非键属性，删除重复的组（不同记录似乎需要不同次重复的数据种类）。注：每个属性必须包含单独一个值，而非一组值。
第二范式（2NF）
数据库必须满足1NF的所有要求。另外，如果一个表有一个复合键，所有属性必须与整个键相关联。而且，在表的多行之间多余重复的数据被移动一个单独的表中。
第三范式（3NF）
存储在表中的数据不得依赖表的任何域，必须唯一依赖于首要键。数据库必须满足2NF的所有要求。既依赖首要键，又依赖其它域的数据被移动到一个单独的表中。
Boyce-Codd范式（BCNF）
除对一个候选键扩展集(称作一个超级键)存在属性函数依赖外，不存在其它非平凡函数依赖。
第四范式（4NF）
除对一个候选键扩展集存在属性组函数依赖外，不存在其它非平凡多值函数依赖。如果且只有一个表符合BCNF，同时多值依赖为函数依赖，此表才符合第四范式。4NF删除了不必要的数据结构：多值依赖。
第五范式（5NF）
不得存在不遵循键约束的非平凡连接依赖。如果且只有一个表符合4NF，同时其中的每个连接依赖被候选键所包含，此表才符合第五依赖。
单值与多值依赖
我还希望你完全了解两种类型的依赖：单值依赖和多值依赖。
例如，一名仅在组织的一个部门工作的员工就属于单值依赖。这名员工可以在部门之间调动，但不能同时为两个部门工作。
在几乎每个与地址有关的数据库中，你都可以发现多值依赖的例子。通常情况下，在Programmers表中有City、State和Country这些列。这些地址可能为文本，或者在方便查找的情况下，也可能为整数值。City查找城市表、State查找州表、Country查找国家表。这种安排带来无用地址的风险问题，如芝加哥、纽约、加拿大。这是因为这里的依赖是多值依赖。
完全标准化的版本可能会把State列移动到城市表，把country列移动到国家表，在Programmers表中只留下City列。我们可以建立一个连接三个表的查询，并提前执行这个查询，这样用户就可以根据斯普林菲尔德（Springfield）伊利诺斯州（IL）、斯普林菲尔德，马萨诸塞州（MA）和斯普林菲尔德，俄勒冈州（OR）选择合适的城市。
再看一个更复杂的多值依赖实例。某个程序员可能精通几门语言并拥有几项认证。每项认证需要精通一门或几门语言，每门语言又与一项或几项认证有关。当程序员学会了一门新的语言时，她可能有资格拥有一项或几项新的认证。我们如何才能确定哪个程序员有资格获得哪项认证呢？
列表A与B建立所需的表并加入几个样本行。列表C和D为查询表的脚本，查找有资格取得认证的程序员。这两个查询只有在顺序方面有所不同——列表C按认证顺序排列结果，而列表D按程序员顺序排列结果。
我建议你运行列表A和B，并在查看两个查询前研究一下它们。看看你能否找到解决办法，生成有资格取得认证的程序员列表。看了我的解决方案后，想想你自己是否还有更好的方法。
如何才足够标准化？
确实，每个改进步骤都可能影响到总体性能。我看到有些标准化执行到荒谬的程度。在我最近参与的一个项目中，甚至还有一个性别表，好像这个列表随时会发生改变似的！
最终，如何执行标准化要由你自己来做决定，不过在决定之前，最好要全面了解各种范式以及没有执行相关范式的风险。
标准化是IT数据库专业人士的戒律之一，数据建模工程师、数据库管理员和SQL开发者都必须遵守这一戒律。我们很早就了解它的原理和范式。
但是对大部分数据库进行了解发现：它们至多执行了第三范式（3NF）。很少有数据库执行了更高范式，如Boyce-Codd范式（BCNF）、第四范式（4NF）和第五范式（5NF）。那么，为什么大多数数据库设计员没有超出3NF呢？
范式简介
为了回答上述问题，了解3NF、BCNF、4NF和5NF之间的区别很重要。以下为每个范式的准确定义。
第一范式（1NF）
每个表必须有一个首要键，即最少的一组属性，它与每条记录一一对应。通过适当定义键属性和非键属性，删除重复的组（不同记录似乎需要不同次重复的数据种类）。注：每个属性必须包含单独一个值，而非一组值。
第二范式（2NF）
数据库必须满足1NF的所有要求。另外，如果一个表有一个复合键，所有属性必须与整个键相关联。而且，在表的多行之间多余重复的数据被移动一个单独的表中。
第三范式（3NF）
存储在表中的数据不得依赖表的任何域，必须唯一依赖于首要键。数据库必须满足2NF的所有要求。既依赖首要键，又依赖其它域的数据被移动到一个单独的表中。
Boyce-Codd范式（BCNF）
除对一个候选键扩展集(称作一个超级键)存在属性函数依赖外，不存在其它非平凡函数依赖。
第四范式（4NF）
除对一个候选键扩展集存在属性组函数依赖外，不存在其它非平凡多值函数依赖。如果且只有一个表符合BCNF，同时多值依赖为函数依赖，此表才符合第四范式。4NF删除了不必要的数据结构：多值依赖。
第五范式（5NF）
不得存在不遵循键约束的非平凡连接依赖。如果且只有一个表符合4NF，同时其中的每个连接依赖被候选键所包含，此表才符合第五依赖。
单值与多值依赖
我还希望你完全了解两种类型的依赖：单值依赖和多值依赖。
例如，一名仅在组织的一个部门工作的员工就属于单值依赖。这名员工可以在部门之间调动，但不能同时为两个部门工作。
在几乎每个与地址有关的数据库中，你都可以发现多值依赖的例子。通常情况下，在Programmers表中有City、State和Country这些列。这些地址可能为文本，或者在方便查找的情况下，也可能为整数值。City查找城市表、State查找州表、Country查找国家表。这种安排带来无用地址的风险问题，如芝加哥、纽约、加拿大。这是因为这里的依赖是多值依赖。
完全标准化的版本可能会把State列移动到城市表，把country列移动到国家表，在Programmers表中只留下City列。我们可以建立一个连接三个表的查询，并提前执行这个查询，这样用户就可以根据斯普林菲尔德（Springfield）伊利诺斯州（IL）、斯普林菲尔德，马萨诸塞州（MA）和斯普林菲尔德，俄勒冈州（OR）选择合适的城市。
再看一个更复杂的多值依赖实例。某个程序员可能精通几门语言并拥有几项认证。每项认证需要精通一门或几门语言，每门语言又与一项或几项认证有关。当程序员学会了一门新的语言时，她可能有资格拥有一项或几项新的认证。我们如何才能确定哪个程序员有资格获得哪项认证呢？
列表A与B建立所需的表并加入几个样本行。列表C和D为查询表的脚本，查找有资格取得认证的程序员。这两个查询只有在顺序方面有所不同——列表C按认证顺序排列结果，而列表D按程序员顺序排列结果。
我建议你运行列表A和B，并在查看两个查询前研究一下它们。看看你能否找到解决办法，生成有资格取得认证的程序员列表。看了我的解决方案后，想想你自己是否还有更好的方法。
如何才足够标准化？
确实，每个改进步骤都可能影响到总体性能。我看到有些标准化执行到荒谬的程度。在我最近参与的一个项目中，甚至还有一个性别表，好像这个列表随时会发生改变似的！
最终，如何执行标准化要由你自己来做决定，不过在决定之前，最好要全面了解各种范式以及没有执行相关范式的风险。
web2f 2007-02-03
- 打赏
- 举报
呵呵，偶不是在学校里，只是用学校这个例子更好说明，所体现出来的问题
没错，在整设计之时是逃脱不了设计范式，索引的应该等等一些问题
这所提只是从一个大的方向出发，没有讲到细节
没错，在整设计之时是逃脱不了设计范式，索引的应该等等一些问题
这所提只是从一个大的方向出发，没有讲到细节
ashzs 2007-02-03
- 打赏
- 举报
第一次看完的感觉是：不懂。 ：）
再看了几次，dodowen() 说的有道理，楼主是总结出了一套方便自己根据需求快速设计数据库的理论。不错！！但是建议楼主最好用数据库的通用名词进行描述，感觉会更好。
我试着用数据库通用的概念描述一下，看看和楼主想要表达的是不是一致。
楼主的四个方面其实都是可以用数据库ER理论的实体（矩阵框）、联系（菱形框）和属性（椭圆形框）进行描述。
“1、数据的确定性”其实可以归纳为实体和实体的primary key。学生作为一个实体，为了清楚描述其中的某个学生，应该有唯一的属性对其进行标识。楼主说的是学生名（如果不存在重名），也可以是学号。
其它三点，个人感觉应该归纳为联系和属性。联系是描述实体之间的关系。例如考勤表可以看作各个实体的一个联系，因为它是对学生、课程、老师等实体关系的一种联系描述。
而学生的“转班、退学、休学、或又复学”，这其实是学生实体的一个属性（学生状态）；“事件性：如：某年某月某时间谁发生了什么事”其实是考勤表这个联系的一个属性（考勤时间）。楼主在进行系统设计时是以ER理论的联系最为主要突破口，首先确定业务的主需求和流程，归纳成各个联系（如考勤表），然后再以联系需要的信息来确定各个实体（学生表、老师表、课程表...）。
“等核心表建完，再根据第一点：数据的确定性来判定字段是否要踢出，再根据数据的流通性来确定其关系，最后根据时间的迁移特征来决定是否要建迁移明细表。”前半部分其实是在进行实体的规范化（范式理论），后半部分是对于数据过多的时候，进行分表。
“最终用关系演算得出结果：如果一个模块内只包含一个核心事件表，而其余的都是逻辑主表或逻辑从表，那这一模块所任意建出的视图都是合理的。”
这句没明白！如何通过关系演算得出结果？而且能确定是合理的？
其实这里的核心事件表就是一个联系，而只有在业务简单的时候才能出现多个实体只有一种核心联系，在比较复杂的系统中（如ERP的各种业务中）一个业务模块中可能会出现多种核心事件，而这些核心事件之间还有复杂的联系。因此楼主说的情况只能说在业务较简单的系统中比较常见。
看得出楼主是个善于总结和思考的人，谢谢分享经验！
再看了几次，dodowen() 说的有道理，楼主是总结出了一套方便自己根据需求快速设计数据库的理论。不错！！但是建议楼主最好用数据库的通用名词进行描述，感觉会更好。
我试着用数据库通用的概念描述一下，看看和楼主想要表达的是不是一致。
楼主的四个方面其实都是可以用数据库ER理论的实体（矩阵框）、联系（菱形框）和属性（椭圆形框）进行描述。
“1、数据的确定性”其实可以归纳为实体和实体的primary key。学生作为一个实体，为了清楚描述其中的某个学生，应该有唯一的属性对其进行标识。楼主说的是学生名（如果不存在重名），也可以是学号。
其它三点，个人感觉应该归纳为联系和属性。联系是描述实体之间的关系。例如考勤表可以看作各个实体的一个联系，因为它是对学生、课程、老师等实体关系的一种联系描述。
而学生的“转班、退学、休学、或又复学”，这其实是学生实体的一个属性（学生状态）；“事件性：如：某年某月某时间谁发生了什么事”其实是考勤表这个联系的一个属性（考勤时间）。楼主在进行系统设计时是以ER理论的联系最为主要突破口，首先确定业务的主需求和流程，归纳成各个联系（如考勤表），然后再以联系需要的信息来确定各个实体（学生表、老师表、课程表...）。
“等核心表建完，再根据第一点：数据的确定性来判定字段是否要踢出，再根据数据的流通性来确定其关系，最后根据时间的迁移特征来决定是否要建迁移明细表。”前半部分其实是在进行实体的规范化（范式理论），后半部分是对于数据过多的时候，进行分表。
“最终用关系演算得出结果：如果一个模块内只包含一个核心事件表，而其余的都是逻辑主表或逻辑从表，那这一模块所任意建出的视图都是合理的。”
这句没明白！如何通过关系演算得出结果？而且能确定是合理的？
其实这里的核心事件表就是一个联系，而只有在业务简单的时候才能出现多个实体只有一种核心联系，在比较复杂的系统中（如ERP的各种业务中）一个业务模块中可能会出现多种核心事件，而这些核心事件之间还有复杂的联系。因此楼主说的情况只能说在业务较简单的系统中比较常见。
看得出楼主是个善于总结和思考的人，谢谢分享经验！
superdinosaur520 2007-02-03
- 打赏
- 举报
实际中，不是仅仅用范式就能解决
netcup 2007-02-03
- 打赏
- 举报
奶茶?晕!我不产那
web2f 2007-02-03
- 打赏
- 举报
的确，对于大型项目还有考虑的东西会更多
feixiangVB 2007-02-02
- 打赏
- 举报
先顶再慢慢看
hb_gx 2007-02-02
- 打赏
- 举报
感觉是在学校里学的
你所谓的实践是不是在学校里的练习？
你所谓的实践是不是在学校里的练习？
megvin 2007-02-02
- 打赏
- 举报
有道理，不过如果真的要理解，估计我得修炼两年．
xiaoku 2007-02-02
- 打赏
- 举报
茶杯MM or 茶杯兄?请赐教!
xiaoku 2007-02-02
- 打赏
- 举报
呵呵...也许野蛮人讨论哲学 这个本身就有点...
理论的东西我不大懂的!
理论的东西我不大懂的!
netcup 2007-02-02
- 打赏
- 举报
看来野蛮人对哲学和理论性的东西感兴趣。呵呵
xiaoku 2007-02-02
- 打赏
- 举报
呵呵...
喜欢讨论这个!
喜欢讨论这个!
加载更多回复（5）
