数据库设计

Posted acaca

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了数据库设计相关的知识,希望对你有一定的参考价值。

数据库设计
1.软件开发的流程:
立项=>需求分析=>概要设计(数据库设计)=>详细设计=>开发实现=>测试=>交付实施=>运维

2.数据库设计的基本流程:
根据业务的需求找出相应的实体类,然后把这些实体类映射成数据库对象(表),再考虑实体的属性,也就是表格的列,最后考虑实体之间的关系,也就是表格之间的关系。

a.数据设计画图

数据库设计常用的工具:
1.sybase公司,powerDesigner,功能强大,收费
2.ERWIN-Studio,功能比较强大,收费
3.JUDE,日本开发的开源,免费
E-R图(Entity-Relationshiop),实体关系映射图
它的核心就是映射(mapping);【后面具体介绍】
1.实体名,映射成表
2.属性,映射成列名
3.对象标识符,映射成主键约束
4.实体关系,映射成表之间的关秀(外键约束)

映射举例:
实体类 表
名字 user 列名:tbl_user
属性 id 主键:id
属性 name 列名:name
属性 password 列名:password

实体类之间的关系:
一对一 映射成外键
例: 丈夫/妻子类

一对多 映射成外键
例:顾客和订单

多对多 拆分成2个一对多,再映射成外键
例:学生和课程

自关联 映射成外键
例:员工实体类


根据实体类设计表:
外键,引用自己表或者另外的表中的主键,从而产生关联。
主键:特点非空唯一,映射实体中的对象标识,数据库中的通过主键来区分行记录。
一对一:外键可写在任意表中,但是一般写在业务意义的从表中。
例:book书类,bookinfo详细信息类,区分主表和从表

一对多:外键写在表多的一方

多对多:利用中间表,拆分成两个一对多
优势:当你再增加一个属性,两边都不好写,可以在中间表中添加
例:添加分数90,发现学生表不知道哪门课程90,课程表不知谁90
分数:额外列
额外列:必须有对应的实体


d.自关联:引用自身主键作为自己的外键,使表中行记录产生关联关系



注意:
1.外键一般出现在表多的地方,映射具有方向性
2.实体类中没有外键的概念,数据库中才有外键的概念

三大范式:
数据库三大范式,也是数据库设计的准则
是一种数据库设计思想,
可以帮助数据设计人员,
以一种非常好的思路和架构来设计数据库。

1NF:原子性。也就是说表中任何一个列都是唯一的,不可再拆分的。
如:
多数国外项目中,R(id,name,age),其中name可以分为:first_name,last_name。
所有此设计是不符合1NF的,应重新设计为:
R(id,first_name,last_name,age)
如:国内地址一栏,要分为省,市,区,详细地址

注意:原子性也不是拆的越多越好,比如把年龄分成个位和十位,无意义

2NF:在1NF的基础上,不存在非关键列部分依赖于关键列,也就是说所有非关键列部分都必须完全依赖于关键列。
如:
R(id,sname,cname,sore)
值(1,张三,数学,90)
由于以上不管是以哪一列作为关键列,都存在 其他 非关键列 部分依赖于 主关键列,
所以此设计是不符合2NF,应该重新设计为:
R1(sid,sname)存放学生信息的表
R2(cid,cname)存放课程信息的表
R3(sid,cid,score)存放学生与课程考试成绩的中间表




3NF:在2NF的基础上,不存在 非关键列传递函数 依赖于关键列,也就是说,所有的非关键列 都 必须 直接依赖于关键列
如:
如果A依赖于B,B依赖于C,我们就说A传递函数 依赖于C

学生考入某所大学的信息表:
R(sid,sname,uid,uname,uphone,address)

如果以sid作为关键列,sname,uid是直接依赖于sid,
但是uname,uphone,address这三列都是直接依赖于uid,
所以此设计不符合3NF,应重新设计为:
R1(sid,sname,uid)存放学生信息表
R2(uid,uname,uphone,address)存放大学信息的表


 

以上是关于数据库设计的主要内容,如果未能解决你的问题,请参考以下文章

第四章数据库应用系统功能设计与实施

第三章 数据库结构设计

以下哪个设计符合表设计规范

数据库设计的几个建议

数据库设计的步骤都有哪些?

如何进行数据库的设计