7_数据库设计

简介: 7_数据库设计

[TOC]

一、数据库设计

  • 关系型数据库建议在E-R模型的基础上,我们需要根据产品经理的设计策划,抽取出来模型与关系,制定出表结构,这是项目开始的第一步
  • 在开发中有很多设计数据库的软件,常用的如power designer,db desinger等,这些软件可以直观的看到实体及实体间的关系
  • 设计数据库,可能是由专门的数据库设计人员完成,也可能是由开发组成员完成,一般是项目经理带领组员来完成
  • 现阶段不需要独立完成数据库设计,但是要注意积累一些这方面的经验

二、三范式

  • 经过研究和对使用中问题的总结,对于设计数据库提出了一些规范,这些规范被称为范式(Normal Form)
  • 目前有迹可寻的共有8种范式,一般需要遵守3范式即可。

2.1 第一范式

  • 第一范式(1NF):强调的是列的原子性,即列不能够再分成其他几列。

    -- 考虑这样一个表:【联系人】(姓名,性别,电话) 
    -- 如果在实际场景中,一个联系人有家庭电话和公司电话,那么这种表结构设计就没有达到 1NF。
    -- 要符合 1NF 我们只需把列(电话)拆分,即:【联系人】(姓名,性别,家庭电话,公司电话)。
    -- 1NF 很好辨别,但是 2NF 和 3NF 就容易搞混淆。

image-20221020223013795.png

2.2 第二范式

  • 第二范式(2NF):首先是 1NF,另外包含两部分内容,一是表必须有一个主键
  • 二是没有包含在主键中的列必须完全依赖于主键,而不能只依赖于主键的一部分。(非主键列全部依赖于主键)
-- 考虑一个订单明细表:【OrderDetail】(OrderID,ProductID,UnitPrice,Discount,Quantity,ProductName)。 
-- 因为我们知道在一个订单中可以订购多种产品,所以单单一个 OrderID 是不足以成为主键的,主键应该是(OrderID,ProductID)。
-- 显而易见 Discount(折扣),Quantity(数量)完全依赖(取决)于主键(OderID,ProductID),
-- 而 UnitPrice,ProductName 只依赖于 ProductID。所以 OrderDetail 表不符合 2NF。不符合 2NF 的设计容易产生冗余数据。

-- 可以把【OrderDetail】表拆分为【OrderDetail】(OrderID,ProductID,Discount,Quantity)和【Product】(ProductID,UnitPrice,ProductName)来消除原订单表中UnitPrice,ProductName多次重复的情况。

image-20221020223036532.png

2.3 第三范式

  • 第三范式(3NF):首先是 2NF,另外非主键列必须直接依赖于主键,不能存在传递依赖。即不能存在:非主键列 A 依赖于非主键列 B,非主键列 B 依赖于主键的情况。
-- 考虑一个订单表【Order】(OrderID,OrderDate,CustomerID,CustomerName,CustomerAddr,CustomerCity)主键是(OrderID)。 
-- 其中 OrderDate,CustomerID,CustomerName,CustomerAddr,CustomerCity 等非主键列都完全依赖于主键(OrderID),所以符合 2NF。
-- 不过问题是 CustomerName,CustomerAddr,CustomerCity 直接依赖的是 CustomerID(非主键列),而不是直接依赖于主键,它是通过传递才依赖于主键,所以不符合 3NF。 

-- 通过拆分【Order】为【Order】(OrderID,OrderDate,CustomerID)和【Customer】(CustomerID,CustomerName,CustomerAddr,CustomerCity)从而达到 3NF。 *

第二范式(2NF)和第三范式(3NF)的概念很容易混淆,区分它们的关键点在于,
2NF:非主键列是否完全依赖于主键,还是依赖于主键的一部分;
3NF:非主键列是直接依赖于主键,还是存在传递依赖。

image-20220721011036559.png

image-20220721011334360.png

三、E-R模型

  • E表示entry,实体,设计实体就像定义一个类一样,指定从哪些方面描述对象,一个实体转换为数据库中的一个表。
  • R表示relationship,关系,关系描述两个实体之间的对应规则,关系的类型包括包括一对一、一对多、多对多。
  • 关系也是一种数据,需要通过一个字段存储在表中。

3.1 一对一

一对一:在任何表中添加一个字段都可以,用它存储另一个表的主键值。

image-20220721224441839.png

3.2 一对多

一对多:在表B多中创建一个字段,用它存储表A的主键值。

image-20220721224458704.png

3.3 多对多

多 对 多:新建一张表C,这个表只有两个字段,一个用于存储A的主键值,一个用于存储B的主键值。(学生和科目)

image-20220721224513127.png

四、逻辑删除

  • 对于重要数据,并不希望物理删除,一旦删除,数据无法找回
  • 删除方案:设置isDelete的列,类型为bit,表示逻辑删除,默认值为0
  • 对于非重要数据,可以进行物理删除
  • 数据的重要性,要根据实际开发决定

五、扩展阅读

目录
相关文章
|
6月前
|
存储 人机交互 数据库
如何数据库设计?
本文介绍了数据库设计的四种方法和基本步骤。直观设计法依赖设计者经验,规范设计法(如新奥尔良法)遵循软件工程原理,分为需求分析、概念设计、逻辑设计和物理设计四个阶段。计算机辅助设计法借助软件工具,自动化设计法则通过人机会话自动生成数据库。设计步骤包括需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库实施和运行维护。需求分析是关键,概念结构设计是基础,逻辑和物理设计涉及数据模型转换和存储优化,而运行维护是持续改进的过程。
130 0
如何数据库设计?
|
6月前
|
存储 数据处理 数据库
为什么要进行数据库设计?
本文探讨了数据库设计的核心概念,包括满足用户的信息和处理需求,以及所需的知识背景,如计算机科学、数据库原理、软件工程和应用领域知识。设计内容分为结构设计(概念、逻辑和物理设计)和行为设计(应用程序设计)。强调了结构设计与行为设计的紧密关联,并指出数据库设计是跨学科的综合性技术,重视管理和基础数据的重要性。
73 0
为什么要进行数据库设计?
|
7月前
|
关系型数据库 MySQL 数据库
数据库设计
数据库设计
62 1
|
7月前
|
存储 缓存 关系型数据库
数据库设计优化
数据库设计优化
91 3
|
存储 数据库
数据库设计三大范式
数据库设计三大范式
|
存储 SQL 数据采集
一文带你了解数据库设计基础
什么是数据库设计? 数据库设计(Database Design)是指对于一个给定的应用环境,构造最优的数据库模式,建立数据库及其应用系统,使之能够有效地存储数据,满足各种用户的应用需求(信息要求和处理要求)。在数据库领域内,常常把使用数据库的各类系统统称为数据库应用系统。
2783 0
一文带你了解数据库设计基础
|
存储 关系型数据库 数据库
数据库设计之三大范式
数据库设计之三大范式
101 0
|
关系型数据库 数据库
浅谈数据库设计之三大范式
范式是“符合某一种级别的关系模式的集合,表示一个关系内部各属性之间的联系的合理化程度”。很晦涩吧?实际上你可以把它粗略地理解为一张数据表的表结构所符合的某种设计标准的级别。
164 0
|
存储 Java 数据库
数据库设计 | 学习笔记
快速学习数据库设计
138 0
数据库设计 | 学习笔记
|
存储 SQL 安全
数据库设计中的14个技巧
. 原始单据与实体之间的关系   可以是一对一、一对多、多对多的关系。在一般情况下,它们是一对一的关系:即一张原始单据对 应且只对应一个实体。在特殊情况下,它们可能是一对多或多对一的关系,即一张原始单证对应多个实 体,或多张原始单证对应一个实体。这里的实体可以理解为基本表。明确这种对应关系后,对我们设计 录入界面大有好处。
147 0