数据库设计

数据库设计是将业务对象转换为数据库对象(表，视图，存储过程，函数等)的过程;包括

6个阶段:. 需求分析, 概念结构设计, 逻辑结构设计, 物理结构设计,数据库实施及数据库运行维护；

概念结构设计的工具：

     E-R 图； entity-relationship diagraml;独立于DBMS;

逻辑结构设计是将E-R图转换为关系模型; 支持某种DBMS;

两个栗子，送给大家；

1.学生成绩管理系统;

2.商城销售信息；

1.学生成绩管理系统， 收集以下信息;

     1. 学生:   学号 ,  姓名 ,  总学分;

     2. 课程: 课程号,  课程名 ,学分;

E-R图设计:   一个学生对应多个课程，  一个课程对应多个学生；

       学生与课程关系是多对多;根据套路，必须建立关系表，通过关系表将一个多对多

关系，转换为两个一对多关系;

学生通过选课产生成绩，关系表就叫做成绩表(我感觉叫学分明细表也行）吧 ， 学生表中的一条记录对应成绩表中的多条记录,

课程表中的一条记录对应成绩表中的多条记录.  没毛病吧，老铁！

E-R 图；

逻辑结构;

 student( sno,sname,tc ); 主表

course(cno,cname,credit);主表

score(sno,cno,grade);sno,cno构成联合主键;从表，受主表约束,删除记录时，先删除从表中的记录，再删除主表中的记录，

2；

在商场销售系统中，收集到以下信息(主要的)

顾客信息: 顾客号，姓名，电话;

订单信息: 订单号, 总金额;

商品信息: 商品号,商品名称,单价;

该业务系统有一下规则:

规则一，   一个顾客可拥有多个订单, 一个订单对应一个顾客; (entity, relationship:一对多);

规则二,   一个订单对应多种商品, 一种商品对应多个订单(多对多);

 老规矩,  订单与商品之间， 增加一个关系表,这个表叫什么鬼名字了？，那就叫订单明细表,

很明显订单明细表应该有个数量属性(联系属性:由联系产生的属性)，某个订单某种商品的数量;对吧！！

E-R图;

 

Customer(Cno,Name,Tel);

Order(Ono,TMoney);

Produce(Pno,PName,Price);

OrderProduce(Ono,Pno,Number);

。。。。。。。。

终结:

 主表与从表(外键表)是相对来说的, 从表受到主表的约束(外键约束),主表的主键在从表中充当外键；

E-R图转为关系模式;

一对一的关系实体： 任选一方作主表,另一方作从表,

一对多的关系实体:   一的一方作主表,多一方作从表,

 多对多(m : n)的关系实体:    添加一个关系表,将一个多对多，转换为两个一对多关系,

关系表添加 m方 和  n方 的主键，充当外键,并且将两个外键设置为联合主键;

添加关系表具有的属性(如上面的成绩表中的分数, 订单明细表中的数量);

so easy to happy;