mysql学习之数据库设计

1 MySql数据库建模过程

需求分析阶段:分析客户的业务和处理需求

概要设计阶段:设计数据库的E-R模型图,确认需求信息的正确和完整

详细设计阶段:应用三大范式审核数据表结构

代码编写阶段:物理实现数据库,编码实现应用

软件测试阶段:....

安装部署:...

2设计数据库的步骤1了解需求:与该系统有关人员进行交流、座谈,充分了解用户需求,理解数据库需要完成的任务

2标识实体:标识数据库要管理的关键对象或实体(名词)

3标识每个实体的属性(名词)

4标识实体之间的关系(动词)

在E-R图中,实体用矩形标识,属性用椭圆形标识,关系用菱形标识

1.一对一:X中的一个实体最对与Y中的一个实体关联,
    并且Y中的一个实体最多与X中的一个实体关联.
    Eg:一个人只有一张身份证.
2.一对多:X中的一个实体可以与Y中的任意数量的实体关联;
    Y中的一个实体最多与X中的一个实体关联.
    Eg:一个班级有多名学生.
3.多对多:X中的一个实体可以与Y中的任意数量的实体关联,反之亦然.
    Eg:学生和课程之间的关系,一个学生可以有多门课程,一门课程可以对应多名学生.
E-R图设计练习

某医院病房计算机管理中心需要如下信息:
    科室:科名、科地址、科电话、医生姓名
    病房:病房号、床位号、所属科室名
    医生:姓名、职称、所属科室名、年龄、工作证号
    病人:病历号、姓名、性别、诊断、主管医生、病房号
其中,一个病房只能属于一个科室,一个科室可以有多个病房,一个医生只属于一个科室,一个科室可以有多名医生,一个医生可负责多个病人的诊治,一个病人的主管医生只有一个。一个病人只能住一间病房,一间病房可以入住多名病人。
完成如下设计:
(1)       设计该计算机管理系统的E-R图
(2)       将该E-R图转换为关系模式结构。

E-R图设计(表设计)  重要!!!

1.如果是1:1的关系:那么将实体转换成表,将任意1端实体的主键拿到另一端实体做外键。

2.如果是1:N的关系:那么将实体转换成表,关系不成表,将1端实体的主键拿到N端实体做外键。

3.如果是M:N的关系:将实体转换成表,关系形成表,同时将两端实体的主键拿过来作为该表的外键,形成复合主键。

数据库设计三大范式

为了建立冗余较小、结构合理的数据库,设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。

范式是符合某一种设计要求的总结。

要想设计一个结构合理的关系型数据库,必须满足一定的范式。

第一范式: 要求表的每个字段必须是不可分割的独立单元

student:name       --违反第一范式

    张小名丨狗娃

student : name old_name  --符合第一范式

    张小名    狗娃

第一范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原子值,就说明该数据库表满足了第一范式。

第一范式的合理遵循需要根据系统的实际需求来定。比如某些数据库系统中需要用到“地址”这个属性,本来直接将“地址”属性设计成一个数据库表的字段就行。但是如果系统经常会访问“地址”属性中的“城市”部分,那么就非要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进行存储,这样在对地址中某一部分操作的时候将非常方便。这样设计才算满足了数据库的第一范式。

第二范式

第二范式: 在第一范式的基础上,要求每张表只表达一个意思。表的每个字段都和表的主键有依赖。

employee(员工):

员工编号 员工姓名 订单名称  --违反第二范式

员工表:员工编号 员工姓名

订单表:订单编号 订单名称  --符合第二范式

第二范式在第一范式的基础之上更进一层。第二范式需要确保数据库表中的每一列都和主键相关,而不能只与主键的某一部分相关(主要针对联合主键而言)。也就是说在一个数据库表中,一个表中只能保存一种数据,不可以把多种数据保存在同一张数据库表中。

比如要设计一个订单信息表,因为订单中可能会有多种商品,所以要将订单编号和商品编号作为数据库表的联合主键,如下表所示。

订单信息表

这样就产生一个问题:这个表中是以订单编号和商品编号作为联合主键。这样在该表中商品名称、单位、商品价格等信息不与该表的主键相关,而仅仅是与商品编号相关。所以在这里违反了第二范式的设计原则。
而如果把这个订单信息表进行拆分,把商品信息分离到另一个表中,把订单项目表也分离到另一个表中,就非常完美了。如下所示。

这样设计,在很大程度上减小了数据库的冗余。如果要获取订单的商品信息,使用商品编号到商品信息表中查询即可。
第三范式

第三范式: 在第二范式基础,要求每张表的主键之外的其他字段都只能和主键有直接决定依赖关系

员工表:员工编号(主键) 员工姓名 部门编号 部门名    --符合第二范式,违反第三范式   (数据冗余高)

员工表:员工编号(主键 )  员工姓名  部门编号  

部门表:部门编号 部门名     ------符合第三范式(降低数据冗余 )

总结:1.为满足某种商业目标,数据库性能比规范化数据库更重要
通过在给定的表中添加额外的字段,以大量减少需要从中搜索信息所需的时间
通过在给定的表中插入计算列(如成绩总分),以方便查询
2.在数据规范化同时,要综合考虑数据库的性能

猜你喜欢

转载自www.cnblogs.com/zzq123/p/9973161.html