概述本文介绍基于机房收费系统 基本遵循三范式的数据库设计。
仅满足最基本功能需求。不包括额外的信息保存。
回想
关系模式设计的好坏直接影响到数据冗余度和数据一致性等问题。
由此我们有了一个评价指标。即范式。
第一范式：关系模式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，则将联系类型也转换成关系模式，其属性为是那段实体类型的键（作为外键）加上联系类型的属性，二键为三端实体键的组合。
由此得到
以上为个人理解，在实际实现中还会有想的不到的地方稍有改动。有不妥之处欢迎指导。