数据库设计---入门

1.     数据库设计的概述

1.1.   数据库设计是什么

  所谓的数据库设计就是根据需求文档的描述将需求转成数据库的存储结构的过程.

  在数据库设计的流程上,我们通常根据需求,画出数据的ER图.然后在通过ER图生成数据库的建库脚本.(Entity Relational)

ER图,所谓的ER图就是数据库关系图

为什么我们使用ER图来实现数据库设计的设计呢?

1.可见即可得.使用ER图可以通过图形的方式展示表与表直接的关系

2.可以根据设置的数据库,方便生成不同的数据库的SQL建库脚本

3.可以快速的生成数据库文档

1.2.   为什么需要数据库设计

软件开发都是分别从页面设计和数据库设计开始的.

创建项目的数据库是项目开发必须的阶段.

2.     数据库设计基础理论(重点)

2.1.   数据库设计的步骤

数据库设计的步骤是根据需求的描述:

第一步:标识表

第二步:标识表的字段

第三步:标识表与表之间的关系

2.2.   标识表注意事项

我们在标识表的时候,可以将表分为实体表和业务表.

所谓的实体表:就是记录需求中描述为一个对象(名词)的表.如:用户,商品,订单,管理员,角色等

所谓的业务表:就是记录在需求中描述为一个业务行为的表:收藏,关注,等 (大部分是中间表)

虽然没有强制的规定先标识实体表还是业务表,但我们通常在标识表时会先标识实体表,再标识业务表.

因为业务表一般是用于标识实体表与另一个实体的多对多的关系的.

2.3.   标识字段注意事项

标识字段,在数据库设计中,尽量符合数据库设计的三大范式原则.

--三大范式,就是用于数据库设计,标识字段的时候使用的!!!。

2.3.1.    三大范式

1.第一范式:确保标识的字段的原子性,字段的概念分得不能再分。如:姓名可以分为姓和名。

--所谓的概述分的不能再分,就是说这个概念会在出现两种以上的情况的了。因为,姓名,中国人的姓名是 :姓+名,外国有些国家:名 + 姓。意味着姓名这个概念有两种情况,所以可以在分成姓和名。所以违反三大范式!!

2.第二范式:确保标识的字段与表有依赖的关系,在用户表定义一个商品价格

--所谓的字段与表有依赖关系,必须字段是表概述的属性。 表概念的XXX

3.第三方范式:确保标识的字段与表有直接依赖的关系,用户表,用户类型的名称

数学上:A依赖B,B依赖于C,我们认为A依赖于C。但在数据库设计里面,如果出现这种情况就违反了第三范式了!

三大范式解决了什么问题呢?

使用三大范式的原则标识的数据库字段,保证了字段在数据库表中的唯一性.从而避免了数据库的数据的冗余.

--user表

 

--usertype表

 

--需求查询用户以及类型,程序员不知道以哪个类型字段为准!!

 

数据冗余会导致,数据增删改查都有可能出现数据异常

是否数据库字段的标识就一定要完成符合三大范式呢?

其实数据库设计,只是为了不要出现过多的数据库冗余的数据,建议尽量在数据库设计的时候符合三大范式..

但在系统实现中:根据性能的要求和业务逻辑的要求,是可以出现少量的数据冗余的。但记得在数据库设计文档说明原因!!!

2.3.2.    示例-性能的要求出现的冗余数据

我们很多系统都要记录日志.而日志里面,必须要包括用户的信息.如果严格按照三大方式.日志的用户信息必须是从用户表中获得,日志每天都会出现巨量的数据。如果关联用户表查询,整理日志,会导致用户表的访问大大被拖慢。

所以,我们会将用户的信息直接写在日志表里面。在日志表中写用户的的信息,明显违反了第二范式,基于查询的性能的需要,一般日志表的用户信息是冗余。

2.3.3.    示例-业务逻辑的要求出现的冗余数据

我们在订单中有一个商品的价格.而这个商品的价格直接就是订单的字段.并不是商品表里面商品的价格.明显违反了第三范式.

但业务上,由于订单的商品的价格不能随着着商家修改了商品价格而修改.所以像这种需求下,必须要给订单表一个冗余的商品价格字段。

2.4.   标识表与表之间的关系

2.4.1.    表与表之间的关系

表与表之间的关系包括有:

1.一对一

2.一对多

3.多对一

4.多对多

数据库表与表的关系,就是也需求描述的从属关系。

问题:表与表之间的关系,是谁决定的?

答:需求决定的!!!

如: 板块与版主的关系是什么?

答:表与表之间的关系是由需求的决定的。板块与版主的关系,在没有确定需求之前是无法确定的。

 

2.4.2.    一对一

  一对一的关系,一般出现在,主表和从表之间记录是一一对应的情况。

  如再设计中,有一个学生表和学生身份表,需求上一个学生只有一个身份。意味着一个学生对应一个身份,所以是一对一关系。

 

  当两个表的关系是一对一的时候,外键可以在两个表的任何一方都可以实现连接表找到对应的数据.但是实际设计中一般遵守现实逻辑中的从属关系来定表的从属关系..

  如: 用户表和用户详细信息表的关系是一对一的关系. 现实逻辑中,我们认为用户的信息是属于用户的. 所以用户表为主表, 用户信息是外键表.

  一对一的表设计特征:外键表的主键就是关联表的外键!外键表的主键和外键是重叠的!!

2.4.3.    一对多/多对一

  两个表的一对多的关系:

  主键表为一的一方,外键表为多的一方.

  表的主从关系是通过由需求本身决定的.

 

2.4.4.    多对多

  表的多对多的关系,在关系型数据库中,表是不支持一个字段存储一个集合的值的。

  所以关系型数据库本身表之间是没有多对多的关系的,多对多的关系是业务逻辑的要求。

  数据库设计遇到表之间多对多的关系会使用是一个中间表来记录两个表多对多的关系.

  注意:如果遇到多对多,必须拆分一个中间表!!!!

3.     小结(重点)

  1. 数据库设计就是建立项目的表结构
  2. 基于数据的复杂性,一般数据库数据库是先画ER图的。
  3. 数据库设计的步骤是:标识表,标识字段,标识表与表之间关系

  标识表,先标识实体表,在标识业务表

  实体表(名词,没有行为)

  业务表(包括业务动作,一般就是一个中间表)

  标识字段,必须要求理解三大范式

  为什么需要三大范式,避免数据的冗余,导致数据的异常。

  数据库设计总体上要符合三大范式,但是基于业务需求和性能要求,有时候可以有少许的冗余

  数据设计冗余,设计者必须要说明原因

  标识表与表之间的关系

  1. 有哪些表与表之间关系,一对多,多对一,一对一,多对多
  2. 表与表之间的关系是由需求决定,讨论表之间的关系前,必须要先确定需求
  3. 关系数据库是不能直接支持多对多的业务关系的,如果出现多对多必须要拆分一个中间表,原因是数据库里面的字段不能存储一个集合数据。

原文地址:https://www.cnblogs.com/maigy/p/10798560.html

时间: 2024-07-31 11:20:50

数据库设计---入门的相关文章

SpringSecurity 3.2入门(8)自定义权限控制数据库设计

SET FOREIGN_KEY_CHECKS=0; -- ---------------------------- -- Table structure for t_system_authority_info -- ---------------------------- DROP TABLE IF EXISTS `t_system_authority_info`; CREATE TABLE `t_system_authority_info` ( `id` int(11) NOT NULL AU

Java精品高级课,架构课,java8新特性,P2P金融项目,程序设计,功能设计,数据库设计,第三方支付,web安全,视频教程

36套精品Java架构师,高并发,高性能,高可用,分布式,集群,电商,缓存,性能调优,设计模式,项目实战,P2P金融项目,大型分布式电商实战视频教程 视频课程包含: 高级Java架构师包含:Spring boot.Spring  cloud.Dubbo.Elasticsearch,Redis.ActiveMQ.Nginx.Mycat.Spring.MongoDB.ZeroMQ.Git.Nosql.Jvm.Mecached.Netty.Nio.Mina.java8新特性,P2P金融项目,程序设计,

15套java互联网架构师、高并发、集群、负载均衡、高可用、数据库设计、缓存、性能优化、大型分布式 项目实战视频教程

* { font-family: "Microsoft YaHei" !important } h1 { color: #FF0 } 15套java架构师.集群.高可用.高可扩 展.高性能.高并发.性能优化.Spring boot.Redis.ActiveMQ.Nginx.Mycat.Netty.Jvm大型分布 式项目实战视频教程 视频课程包含: 高级Java架构师包含:Spring boot.Spring  cloud.Dubbo.Redis.ActiveMQ.Nginx.Mycat

数据库设计指南

如果把企业的数据比做生命所必需的血液,那么数据库的设计就是应用中最重要的一部分.有关数据库设计的材料汗牛充栋,大学学位课程里也有专门的讲述.不过,就如我们反复强调的那样,再好的老师也比不过经验的教诲(体验决定深度.知识决定广度).所以我们最近找了些对数据库设计颇有造诣的专业人士给大家传授一些设计数据库的技巧和经验.我们的编辑从收到的130 个反馈中精选了其中的60 个最佳技巧,并把这些技巧编写成了本文,为了方便索引其内容划分为5个部分: 第1 部分- 设计数据库之前 这一部分罗列了12个基本技巧

高级架构程序设计,功能设计,数据库设计,第三方支付,web安全视频教程

36套精品Java精品高级课,架构课,java8新特性,P2P金融项目,程序设计,功能设计,数据库设计,第三方支付,web安全,高并发,高性能,高可用,分布式,集群,电商,缓存,性能调优,设计模式,项目实战,大型分布式电商实战视频教程 视频课程包含: 高级Java架构师包含:Spring boot.Spring  cloud.Dubbo.Elasticsearch,Redis.ActiveMQ.Nginx.Mycat.Spring.MongoDB.ZeroMQ.Git.Nosql.Jvm.Mec

数据库设计又一个新思路

==========================================聊天记录很有价值,以下是全部聊天记录========================================= 码妖][广州]老衲(424469013) 10:09:28服务器上定义好 数据库的各个表 主键 约束 外键 视图等[码妖][广州]老衲(424469013) 10:10:07客户端 依照服务器上的样板 自动 增加 或 删除 ,各个表字段 主键 外键 视图等[码妖][广州]老衲(424469013

数据库设计时不得不违背三范式的情景

1.在进销存系统中,订单信息中关联到好多其他的基本信息,比如:客户,付款方式,货运方式等,这些信息是有专门表进行维护的,在下订单时也是用下拉框选择的,但在保存订单信息时,不能只记录所谓的外键ID,而是应该同时记录名称等其他的信息. 这是因为订单不能因为没有了客户ID或是付款方式ID而不知道客户与付款方式了.对于订单这种客观存在的事物,是具有一定的历史性质的,因此在设计时应该与其他的关联信息可以“断开”,这也就是保证了订单的独立性. 摘自:http://www.cnblogs.com/tongtk

从零开始编写自己的C#框架(9)——数据库设计与创建

对于千万级与百万级数据库设计是有所区别的,由于本项目是基于中小型软件开发框架来设计,记录量相对会比较少,所以数据库设计时考虑的角度是:与开发相结合:空间换性能:空间换开发效率:减少null异常......当然不同的公司与项目要求不同,初学者要学会适应不同的项目开发要求,使用本框架开发时,必须严格按照本章节的要求来设计数据库,不然可能会产生不可控的异常. 从零开始编写自己的C#框架 数据库设计规范   文件状态: [√] 草稿 [  ] 正式发布 [  ] 正在修改 文件标识: C#框架 当前版本

数据库设计的三大范式

数据库设计的三大范式 为了建立冗余较小.结构合理的数据库,设计数据库时必须遵循一定的规则.在关系型数据库中这种规则就称为范式.范式是符合某一种设计要求的总结.要想设计一个结构合理的关系型数据库,必须满足一定的范式. 在实际开发中最为常见的设计范式有三个: 1.第一范式 第一范式是最基本的范式.如果数据库表中的所有字段值都是不可分解的原子值,就说明该数据库表满足了第一范式. 第一范式的合理遵循需要根据系统的实际需求来定.比如某些数据库系统中需要用到"地址"这个属性,本来直接将"