数据库设计

需求分析
概念设计和概念模型
- E-R方法
逻辑设计与逻辑模型
- 逻辑模型的实体
- 实体中的属性
- 主键、外键、索引之间的关系
- 实体间的关系
- 范式（Normal Form）
- 逻辑模型建设注意事项
物理设计和物理模型
- 同一概念在不同阶段的名称
- 物理模型反范式处理
- 建立物理化命名规范
- 表的物理化
- 字段的物理化
- 索引的创建和使用
- 使用建模软件
- 物理模型产出物
数据库设计案例

需求分析

需求分析的意义

需求分析阶段主要是收集信息并进行分析和整理，为后续阶段提供充足信息。

是整个数据库设计的基础。有了确定的需求，我们才能确定存储哪些类型的数据，从而设计数据库。
最困难，也可能最耗时的阶段。需求分析没做好，会导致整个数据库重新设计返工。
贯穿整个软件工程周期。需求分析不仅仅是起步必做的，在后面可能有需求变更，可能增加需求，这种情况难度甚至更大，这需求起步阶段分析更加严格。

需求分析阶段需要：

了解现有系统的运行概况。
确定新系统的功能要求。
收集能够实现目标的基础数据及相关的业务流程。

需求分析阶段的任务
对用户业务行为和流程进行调查：

了解用户对新系统的期望和目标。
了解目前现存系统的主要问题。
系统调研、收集和分析需求，确定系统开发范围：
信息调研：确定所设计的数据库系统用到的所有的信息，明确信息来源，方式，数据格式和内容。
处理需求：把用户的业务功能需求转化成需求说明，定义要设计的数据库系统的功能点。
了解并记录在安全性和完整性方面的要求。
编写需求分析报告：
用户需求规格说明书
数据字典

需求分析阶段的方法
需求分析的重点是梳理清楚用户的“信息流”和“业务流”。

业务现状：包括业务方针政策，组织机构，业务过程等。
信息源流：数据的源头、流向和重点，各种数据的产生、修改的过程和频率，以及数据和业务的处理关系。
外部要求：数据保密性要求，查询响应时间要求，输出报表要求等。

需求调查的方法，包括但不限于：

查看现有系统的设计文档，报告；
和业务人员座谈；
问卷调查；
采集样本数据（如果条件允许）。

数据字典
数据字典是对数据的描述，不是数据本身。包括：

数据项
数据项名称，含义，数据类型，长度，取值范围，单位，与其他数据项逻辑关系等。
是逻辑设计阶段模型优化的依据。
数据结构
数据结构反映了数据项之间的组合关系。一个数据结构可以由若干数据项和数据结构混合组成。
数据流
在系统内的传输路径。包括数据来源，流向，平均流量，高峰期流量等。
数据存储
数据存储拼读，保留时间长度，数据存取方式。
处理过程
数据处理过程的功能及处理要求。功能是指处理过程用来做什么，要求包括单位时间内处理多少事务，多少数据量，时间响应要求等。

概念设计和概念模型

概念设计的任务

分析用户提出的需求，对用户需求进行综合、归纳和抽象，形成一个独立于具体数据库管理系统的概念层次抽象模型，即为概念数据模型。

概念模型的主要特点

能真实、充实地反映现实世界，包括事物和事物之间的关系，是现实世界的真实模型。
易于理解，可以和不熟悉数据库的用户进行讨论。
易于更改，当应用环境和应用要求改变时可以对概念模型进行修改和扩充。
易于向关系数据模型转换。

E-R方法

1976年P.P.S.Chen提出了实体-联系（Entity-Relationship）方法，即E-R方法，是构建概念模型常用的方法之一。
E-R方法使用的工具称为E-R图。

E- R图在概念设计阶段使用的比较广泛，用E-R模型表示的数据库概念非常直观，易于用户理解，E-R图主要由实体、属性和联系三个要素构成。

实体：
具有公共性质并且可以相互区分的现实世界对象的集合，例如:老师，学生,课程都是实体。实体中每个具体的记录值，如学生实体中每个具体的学生，称之为实体的一一个实例。

属性：
描述实体性质或特征的数据项。
属于一个实体的所有实例都具有相同的性质。
这些性质和特征就是属性，比如学生的学号、姓名和性别等。

联系：
描述实体内部以及实体之间的联系。
联系使用菱形框表示。
实体之间的联系通常分为三类:

一对一联系(1:1): 例如一个班级有一个班主任。
一对多联系(1:n):例如一个班级有n个学生组成。
多对多联系(m:n):例如学生选修课程。一个学生可以选修多门课程，一门课程也可以被多个学生选修。

这里推荐一下个人设计ER图使用的工具

微软office带的Visio
ProcessOn（网页）

逻辑设计与逻辑模型

逻辑设计

这个阶段是将概念模型转化为具体的数据模型的过程。
按照概念设计阶段建立的基本E-R图，按选定的目标数据模型（层次、网状、关系、面向对象），转换成相应的逻辑模型。
对于关系型数据库来说，这种转换要符合关系数据模型的原则，得到的就是逻辑数据模型。
这个阶段主要的工作就是确定关系模型里面的属性和码（或者说主键）。
比较常用的方式是使用E-R设计工具，IDEF1x方法来进行逻辑模型建设，常用的ER图表示法包括IDEF1x，IE模型的Crow’s foot，UML类图方式等。

逻辑模型的实体

独立型实体(Independent Entity)
直角矩形表示。不依赖于其他实体，可以独立存在。
依赖型实体(Dependent Entity)
圆角矩形表示。必须依赖于其它实体而存在。

依赖型实体中的主键必须是独立实体主键的一部分或者全部。

实体中的属性

主键(Primary Key)
识别实体实例唯一性的属性或属性组。

可选键
能识别实体实例唯一性的其他属性或者属性组。

外键
两个实体发生关联，一个实体的外键是另外一个实体的主键。也可以把主键实体称为父实体，拥有外键的实体称为子实体。

非键属性
实体里面除主键和外键属性外的其他属性。

派生属性
一个字段可以被统计出来或者从其它字段推导出来的字段。

主键、外键、索引之间的关系

实体间的关系

关系是描述实体间如何发生关联
一本书“包括”若干个章节。
“包括”就是这两个实体之间的关系。
关系是有方向性的。

关系基数(Cardinality)
反映两个或多个实体间关系的业务规则。

IDEF1x中基数的图例

基数的不同反映了不同的关系

识别性关系(ldentifying relationship)
发生在独立型实体和依赖型实体之间。
子实体的实例唯一性的识别与父实体相关联。
父实体的主键属性成为子实体的主键属性。

非识别性关系(non-identifying relationship)
口子实体不需要与父实体的关系就可以确定实例唯一-性。

嵌套关系(Recursive relationship)
父实体和子实体为同一个实体，形成递归或者嵌套的关系。
实体的主键也成为自身的外键。

子类关系(Subtype relationship)
子类实体和所属父实体的关系。
完全子类关系：所属父实体的每个实例都能够与子类群的一-个实体实例相关联。
不完全子类关系：所属父实体的每个实例不一定都与子类群相关联。

范式（Normal Form）

在数据库设计的时候要满足的设计规范,满足不同程度的要求为满足不同的范式；把属性放置在正确的实体的这个过程称为范式化(normalization)。

范式化的意义:
减少数据冗余。
提供良好的可扩展性。
消除数据更新时候可能产生的数据不一致情况。

范式之间的关系:
满足最低要求的叫第一范式，记为1NF。
在第一范式满足进一步要求的为第二范式，2NF。
以此类推。
一个低一级范式的关系模式通过模式分解(Schema Decomposition)可以转换为若干个高一级范式的关系模式的集合。

值域
定义一个属性取值的有效范围
在值域里面的值都是合法数据。
值域体现了规则。

第一范式（1NF）

第二范式（2NF）

第三范式（3NF）

一句话总结3NF：要有主键，依赖于整个主键，只能依赖主键

逻辑模型建设注意事项

1. 建立命名规则

命名规则的意义：

统一命名，避免歧义。
防止冗余的实体或者属性产生。
有利于工作中不同角色的人员之间通过规范的命名和属于进行交流。
便于使用。

实体和属性的命名建议：

实体名称：分类域大写+实体描述词（全称，首字母大写）。
属性名称：使用全称，首字母大写，一些约定俗称的空格缩写。
避免英语和拼音的混用。
如果是缩写，一定是英语的缩写，避免使用拼音缩写。

2. 按照设计流程设计逻辑数据模型

3. 确定实体和属性

定义实体的主键（PK）；
定义部分非键属性（Non-Key Attribute）；
定义非唯一属性组；
添加相应的注释内容。

4. 确定实体与实体之间的关系

通过外键来体现；
决定实体之间是否是可识别的关系；
确定关系的基数属于1:1，1:n还是n:m。

5. 补充实体的非键值属性

按照3NF的规则，判定添加的属性是否符合3NF的设计原则；
如果新增属性违法3NF，需要进行实体拆分，确定新的实体和关系；
添加注释。

物理设计和物理模型

物理设计

在用户确定的逻辑模型基础上，以数据库系统运行效率，业务操作效率，前端应用效率等因素为出发点对模型进行调整。
面向物理实施过程的具体细节。
最终目的是转化为目标数据库的可部署的定义语言（DDL）。
工作内容，包括但不限于
实体非正则化处理；
表和字段的物理命名；
确定字段的类型，长度，精度，大小写敏感等属性；
增加逻辑模型中不存在的物理对象：索引，约束，分区等。

同一概念在不同阶段的名称

物理模型反范式处理

从性能和应用需求出发
物理模型是以性能为出发点，支持应用需求，兼顾数据库物理限制。
CPU无限快，内存无限多，存储无限大，带宽无限宽，还有必要反范式处理么？
有限的资源，有限的硬件条件提出了物理模型反范式化的需求。
反范式处理需要适度而行
对于特定配置的硬件系统，在满足应用功能目标和性能指标的前提下，适度进行。
带来数据冗余问题。
有可能会导致数据不一致问题。

反范式示例
增加冗余列，避免频繁发生表关联操作（Join）

增加冗余列，利用repeating group来减少SQL的复杂度。
在前端报表应用中为了便于报表展示而采用用纵横转换。

增加派生列，减少函数计算。

反范式常见手段

增加重复组（repeating groups）
预关联（pre-joins）
派生字段
建立汇总表或临时表
表拆分（水平拆分或垂直拆分）

影响：并非对所有处理过程都能带来性能提升，有些负面影响需要综合考虑进行平衡。反范式会降低数据模型的灵活性。带来数据不一致的风险。

维护数据完整性
反范式处理后增加了数据冗余性，需要一定的管理措施来维护数据完整性。

批处理维护
批处理维护是指对复制列或派生列的修改积累一定的时间后，运行一批处理作业或存储过程对复制或派生列进行修改，这只能在对实时性要求不高的情况下使用。
应用逻辑
在应用实现过程中，在同一事务中对所有涉及的表进行增、删、改操作。
风险较大，容易遗漏，特别是在需求变化时，不易于维护。
触发器
实时处理性高。
但对于数据库压力较大，尤其是高并发环境，触发器数量需要严格控制。

建立物理化命名规范

建立命名规范，对实体进行物理化命名

根据数据库物理特性进行命名；
名称有效字符的范围（避免使用非法字符出现在名称中）；
避免使用物理数据库的保留关键字；
命名尽量采用富有意义、易于记忆、描述性强、简短及具有唯一性的英文词汇，不准采用拼音。
指定项目组范围内统一的命名规则，并严格遵守。
名称缩写要达成约定。

对象命名规范示例

表的物理化

进行反范式化操作
决定是否要分区
对于大表要进行分区，减少IO扫描量，加速范围查询。
决定是否要拆分历史表和当前表。
历史表是冷数据，可以放在低速存储上；当前表是热数据，使用高速存储。
历史表可以使用压缩方法减少占用的存储空间。

字段的物理化

选择合适的类型，考虑以下因素：

尽量使用短字段的数据类型。
长度较短的数据类型不仅可以减小数据文件的大小，提升IO性能；同时也可以减小相关计算时的内存消耗，提升计算性能。
比如对于整型数据，如果可以用smallint就尽量不用int，如果可以用int就尽量不用bigint。
要注意不能盲目的用小的数据类型及数据长度，要考虑周全，千年虫就是一个教训。
使用一致性的数据类型
表关联列尽量使用相同的数据类型。如果表关联列数据类型不同，数据库必须动态地转化为相同的数据类型进行比较，这种转换会带来一定的性能消耗。
选择高效数据类型。

字段的约束

DEFAULT默认约束
如果能够从业务层面补全字段值，就不建议使用DEFAULT约束，避免数据加载时产生不符合预期的结果。
NOT NULL非空约束
给明确不存在NULL值的字段加上NOT NULL约束。
UNIQUE唯一约束
如果确定该字段是唯一的，就添加该约束，比如身份证号，电话号码
PRIMARY KEY主键约束
主键 = 唯一 + 非空
如果加了主键，该字段就不用加唯一和非空了
CHECK检查约束
检查约束因为对于数据质量提出了要求，不满足约束的数据在插入数据表会导致SQL失败。

索引的创建和使用

可以增加索引的情况

在经常需要搜索查询的列；
在作为主键的列上创建索引，强制该列的唯一性；
在经常使用连接的列上创建索引；
在经常根据范围进行搜索的列上创建索引；
在经常需要排序的列上创建索引；
在经常使用WHERE子句的列上创建索引。

索引建多了，会有负面影响

占用更多的空间；
插入基表数据的效率会下降。

删除无效的索引，避免空间浪费

使用建模软件

使用建模软件来进行逻辑建模和物理建模：

功能强大而丰富；
正向生成DDL，反向解析；
在逻辑模型和物理模型中自由切换使用视图；
全面满足建模中的各种需求，高效进行建模。

物理模型产出物

物理数据模型；
物理模型命名规范；
物理数据模型设计说明书；
生成DDL建表语句。

数据库设计案例

场景说明

可提取的属性列表

正则化处理 - 消除重复组情况

正则化处理 - 消除依赖部分主键

正则化处理 - 消除传递性依赖

3NF模型 - 数据示例

物理模型 - 数据类型和长度

物理模型 - 反范式化

物理模型 - 索引选择

Java数据库篇_01 数据库设计基础(华为云学习笔记)相关推荐

1.Hadoop的安装和使用（华为云学习笔记，Spark编程基础，大数据）
此笔记为第一篇,学校开放华为云平台,帮助我们学习有关大数据方面相关知识的学习笔记,因为是云平台,是已经搭建好linux环境了,使用的是Ubantu.精心整理,自学笔记,如有什么问题,请耐心指正 Had ...
华为云学习笔记-弹性云服务器
什么是弹性云服务器? 弹性云服务器(Elastic Cloud Server,ECS)是由CPU.内存.操作系统.云硬盘组成的基础的计算组件.弹性云服务器创建成功后,您就可以像使用自己的本地PC或物理 ...
7.读写HBase数据（华为云学习笔记，Spark编程基础，大数据）
读写HBase数据 ① 在hbase-shell中使用命令创建HBase数据库: ② 使用Spark读写HBase数据库中的数据. 实验原理 -> HBase HBase是一个高可靠.高性能.面 ...
2.Scala的安装和使用方法（华为云学习笔记，Spark编程基础，大数据）
Scala的安装和使用方法 ① 在Linux系统中安装Scala: ② 使用Scala REPL: ③ 编译打包Scala程序代码. 实验原理-> Scala Scala于2004年1月公开发布 ...
3.Spark的安装（华为云学习笔记，Spark编程基础，大数据）
Spark的安装 ① 在Linux系统中安装Spark: ② 运行Spark自带实例. 实验原理 -> Spark Apache Spark 是专为大规模数据处理而设计的快速通用的计算引擎.Sp ...
2.安装组件客户端程序（华为云学习笔记，HCIP，大数据）2022.6.6
实验拓扑图大数据开发机大数据数据节点大数据管理节点大数据控制节点安装组件客户端程序在FusionInsight HD中,大多数组件都提供了命令行客户端,此实验指导用户如何下载单个组件和所有 ...
1.FI管理页面的登录及环境介绍(华为云学习笔记，HCIP，大数据)2022.6.6
实验拓扑图大数据开发机(Ubantu) 大数据数据节点大数据管理节点大数据控制节点 FI管理页面的登录及环境介绍此实验指导用户如何登录 FusionInsight HD 的 web 管理界面, ...
Java数据库篇1——数据库配置
Java数据库篇1--数据库配置 1.数据库数据库(DataBase) 就是存储和管理数据的仓库本质是一个文件系统, 还是以文件的方式,将数据保存在电脑上 2.数据库的优点存储方式优点缺点 ...
Java数据库篇7——数据库设计
Java数据库篇7--数据库设计 1.第一范式列不可再分每一列属性都是不可再分的属性值,确保每一列的原子性两列的属性相近或相似或一样,尽量合并属性一样的列,确保不产生冗余数据 2.第二范式属性 ...

Java数据库篇_01 数据库设计基础(华为云学习笔记)