概述 本文介绍基于机房收费系统 基本遵循三范式的数据库设计。
仅满足最基本功能需求，不包含额外的信息保存。
回顾
关系模式设计的好坏 直接影响到数据冗余度和数据一致性等问题。由此我们有了一个评价指标。即范式。
第一范式：关系模式R的每个关系r的属性值都是不可分的原子值
第二范式：关系模式R是1NF且每个非主属性完全依赖于候选键
第三范式：关系模式R是1NF且每个非主属性都不传递依赖于R的候选键
ER图
ER图转换成关系模式集的算法
步骤一 （实体类型的转换）
将每个实体类型转换成一个关系模式，实体的属性即为关系模型的属性，实体标识符即为关系模式的键。
由此得到学生表 卡表 工作人员表 基本数据表和机器表。由于机器只有一个属性，可与其他合并。
步骤二（联系类型的转换） 根据不同情况做不同的处理。
步骤2.1 二元联系类型的转换
1）若实体间联系是1：1 可在两个实体类型转换成一个关系模式，实体的属性即为关系模式的属性，实体标识符即为关系模式的键。
2）若实体联系是1：N 则在N端实体类型转换成关系模式中加入1端实体类型的键 作为外键和联系类型的属性。
3）若实体间联系是M:N ，则将联系类型也转换成关系模型。其属性为两端实体类型的键（作为外键）加上联系类型的属性，而键为两段实体间的组合。
即得
步骤2.2 一元联系类型的转换
和二元联系类型的转换类似。
步骤2.3（三元联系类型的转换）
1）若实体间联系是1：1：1 可以再三个实体类型转换成三个关系模式中任意一二关系模式的属性中加入另两个关系模式的键（作为外键）和联系类型的属性。
2）若实体间联系是1:1：N 则在N端实体类型转换成关系模式中加入两个1端实体类型的键（作为外键）和联系类型的属性。
3）若实体间联系是M:N:P，则将联系类型也转换成关系模式，其属性为是那段实体类型的键（作为外键）加上联系类型的属性，二键为三端实体键的组合。
由此得到
以上为个人理解，在实际实现中 还会有想的不到的地方稍有修改。有不妥之处 欢迎指导。
原文：http://blog.csdn.net/u010176014/article/details/33321307
