标识对象（实体－Entity）
标识数据库要管理的关键对象或实体 对象
标识每个实体的属性（Attribute） 对象属性
标识对象之间的关系（Relationship） 对象间关系
E-R（Entity－Relationship）实体关系图
1客户 --- N订单 ---- M产品
将各实体转换为对应的表，将各属性转换为各表对应的列
标识每个表的主键列，需要注意的是：没有主键的表添加ID编号列，它没有实际含义，用于做主键或外键，在表之间建立主外键，体现实体之间的映射关系
表---主键---外键(Relationship)
仅有好的RDBMS并不足以避免数据冗余，必须在数据库的设计中创建好的表结构
Dr E.F.codd 最初定义了规范化的三个级别，范式是具有最小冗余的表结构。这些范式是：
第一范式(1st NF －First Normal Fromate)
第一范式的目标是确保每列的原子性
如果每列都是不可再分的最小数据单元（也称为最小的原子单元），则满足第一范式（1NF）
A:ID ADDRESS B： ID COUNTRY CITY
1 中国北京市 1 中国 北京
第二范式(2nd NF－Second Normal Fromate)
如果一个关系满足1NF，并且除了主键以外的其他列，都依赖与该主键，则满足第二范式（2NF）
第二范式要求每个表只描述一件事情
A: 字段 例子 B 字段 例子
orders orders
订单编号 001 订单编号 001
产品编号 A001 订购日期 2000-9-2
订购日期 2000-9-2 Products
价格 $29 产品编号 A001
价格 $29
第三范式(3rd NF－ Third Normal Fromate)
如果一个关系满足2NF，并且除了主键以外的其他列都不传递依赖于主键列，则满足第三范式（3NF）
假设某建筑公司要设计一个数据库。公司的业务规
则概括说明如下：
公司承担多个工程项目，每一项工程有：工程号、工程名称、施工人员等
公司有多名职工，每一名职工有：职工号、姓名、性别、职务（工程师、技术员）等
公司按照工时和小时工资率支付工资，小时工资率由职工的职务决定（例如，技术员的小时工资率与工程师不同）
公司定期制定一个工资报表，如图-1所示
工程号 工程名称 职工号 姓名 职务 小时工资率 工时 实发工资
A1 花园大厦 1001 齐光明 工程师 65 13 845.00
1002 李思岐 技术员 60 16 960.00
1004 葛宇宏 律师 60 19 1140.00
小计 2945.00
A2 立交桥 1001 齐光明 工程师 65 15 975.00
1003 鞠明亮 工人 55 17 935.00
小计 1910.00
A3 临江饭店 1002 李思岐 技术员 60 18 1080.00
1004 葛宇洪 技术员 60 14 840.00
小计 1920.00
一张表描述了多件事情，如下图所示：
项目工时信息表
工程号 工程名称 职工号 姓名 职务 小时工资率 工时
|__工程信息____| |______|_____|_________|
员工信息
工程号 工程名称 工程表
职工号 姓名 职务 小时工资率 员工表 满足第三范式吗?
工时依赖职务，职务依赖职工号，存在多存依赖；
工程号 职工号 工时 项目工时表
工程号 工程名称 工程表
职工号 姓名 职务 员工表
职务 小时工资率 职务表
工程号 职工号 工时 项目工时表
为满足某种商业目标，数据库性能比规范化数据库更重要
通过在给定的表中添加额外的字段，以大量减少需要从中搜索信息所需的时间
通过在给定的表中插入计算列（如成绩总分），以方便查询
进行规范化的同时，还需要综合考虑数据库的性能。
小结
在需求分析阶段，设计数据库的一般步骤为：
收集信息
标识对象
标识每个对象的属性
标识对象之间的关系
在概要设计阶段和详细设计阶段，设计数据库的步骤为：
绘制E-R图
将E-R图转换为表格
应用三大范式规范化表格
为了设计结构良好的数据库，需要遵守一些专门的规则，称为数据库的设计范式 。
第一范式（1NF）的目标：确保每列的原子性。
第二范式（2NF）的目标：确保表中的每列，都和主键相关
第三范式（3NF）的目标：确保每列都和主键列直接相关，而不是间接相关
阅读(1317) | 评论(0) | 转发(0) |
