系统架构设计师 - 案例特训专题 - 数据库设计篇

大家好呀！我是小笙，本章我主要分享系统架构设计师 - 案例特训专题 - 数据库设计篇知识，希望内容对你有所帮助！！

数据库设计篇

数据库设计关注的问题：性能、数据一致性、安全

数据库设计过程

规范化与反规范化 ★★★

规范化 - 范式

反规范化

优点：连接操作少、检索快、统计快、需要查的表减少、检索容易

缺点：数据冗余，需要更大的存储空间；插入、更新、删除操作开销更大；数据不一致（可能产生添加、修改、删除异常）；更新和插入代码更难写

例题

1、某集团公司在各省均设有分公司，现欲建立全国统一的销售管理信息系统，以便总公司及时掌握各分公司的销售情况。公司成立专门的项目组进行该系统的研发工作，其中张工负责其中的数据库设计工作

• 张工和需求分析小组紧密合作，在设计出数据流图和数据字典的基础上，给出了数据库关系模式和相应的索引设计。同时考虑到未规范化关系模式可能引起的各类数据错误，对关系模式进行了全面的规范化处理，使所有关系模式均达到了3NF或BCNF
• 在项目实施过程中，应用开发小组认为该设计方案未考虑应用功能的实际需求。如果严格按照设计方案实施，会对应用系统中整体性能产生较大影响。主要的原因在于进行数据查询时，会产生大量的多表连接操作，影响性能。而设计方案中的索引设计，并不能完全满足数据查询的性能要求
• 应用开发小组还认为，该设计方案未考虑到信息系统中核心销售数据处理的特点：各分公司在使用该信息系统时只能操作自己分公司的销售数据，无权操作其它分公司的销售数据；只有总公司有权利操作所有销售数据，以便进行统计分析
• 应用开发小组要求，在数据库设计方案中，必须针对实际应用功能的实现来考虑关系模式的规范化，必要时需要采用逆规范化或解除规范化的方法来保证性能要求

问题1 系统需要管理供应商和货物等信息，具体包括供应商姓名、地址以及货物名称、价格等，供应商可以提供 0 ~ n 种货物，其公司地址也可能发生变化。请以供应商关系模式 supplier(name,address,product,price) 为例，解释不规范的关系模式存在哪些问题

• 数据冗余：关系模式中多次重复记录了同一供应商的地址
• 插入异常：如果还未确定一个供应商有哪些货物，只是想添加一个供应商的地址信息，则会产生产品与价格均为空的记录
• 修改异常：当修改一个供应商的地址时，需要将多条记录同时更新，若未同时更新，则数据产生不一致
• 删除异常：当删除一个供应商的货物时，其地址信息被一并删除

问题2 应用开发小组认为张工的规范化设计虽然解决了未规范化关系模式带来的问题，但实际实现功能时会造成系统性能的下降，请解释其原因

数据库规范化的过程，实际是对数据表的不断拆分，以达到更高的规范程度。这样处理，带来的问题是：系统中大量查询不能通过单表完成，而需要将多表进行连接查询，所以表拆分得越多，查询性能也就越差

问题3 请解释逆规范化方法，说明其优缺点

规范化设计后，数据库设计者希望牺牲部分规范化来提高性能，这种从规范化设计的回退方法称为反规范化技术
逆规范化方法优点：提高统计、查询效率
逆规范化方法缺点：增加了数据冗余，浪费存储空间，增、删、改操作的效率降低，可能导致数据不一致，可能产生添加、修改、删除异常

问题4 针对该信息系统中核心销售数据处理的特点，如采用关系表水平分割的逆规范化方法，请给出具体的解决方案，并说明该方案存在的问题

解决方案：将各省的数据存放于各省分公司，该方案主要问题：

• 在于总公司进行全国数据统计时，需要从各省服务器调取数据，效率较低
• 执行应用功能时需要动态选择分公司的数据库表，增加了应用程序的复杂度

数据库索引

数据库索引：提升查询效率，降低添加、修改、删除效率。采用B树，B+树等

数据库视图

视图并不在数据库中实际存在，而是一种虚拟表

视图的优点

• 视图能简化用户的操作
• 视图机制可以使用户以不同的方式查询同一数据
• 视图对数据库重构提供了一定程度的逻辑独立性
• 视图可以对机密的数据提供安全保护

物化视图：将视图的内容物理存储起来，其数据随原始表变化，同步更新

例题

1、某软件企业开发一套类似于淘宝网上商城业务的电子商务网站。该系统涉及多种用户角色，包括购物用户、商铺管理员，系统管理员等。在数据库设计中，该系统数据库的核心关系包括：

• 产品（产品编码，产品名称，产品价格，库存数量，商铺编码）
• 商铺（商铺编码，商铺名称，商铺地址，商铺邮箱，服务电话）
• 用户（用户编码，用户名称，用户地址，联系电话）
• 订单（订单编码，订单日期，用户编码，商铺编码，产品编码，产品数量，订单总价）

不同用户角色有不同的数据需求，为此该软件企业在基本数据库关系模式的基础上，定制了许多视图。其中，有很多视图涉及到多表关联和聚集函数运算

问题1 商铺用户需要实时统计本商铺的货物数量和销售情况，以便及时补货，或者为商铺调整销售策略。为此专门设计了可实时查看当天商铺中货物销售情况和存货情况的视图，商铺产品销售情况日报表（商铺编码，产品编码，日销售产品数量，库存数量，日期）。数据库运行测试过程中，发现针对该视图查询性能比差，不满足用户需求。请说明数据库视图的基本概念及其优点，并说明本视图设计导致查询性能较差的原因

视图的基本概念以及优点上述已经提到
查询性能较差的原因是视图中“日销售产品数量”需要针对订单表做统计分析，订单表中有数量庞大的历史销售记录，所以这种操作极为耗时

问题2 为解决该视图查询性能比较差的问题，张工建议为该数据建立单独的商品当天货物销售、存货情况的关系表。但李工认为张工的方案造成了数据不一致的问题，必须采用一定的手段来解决

1. 说明张工方案是否能够对该视图查询性能有所提升，并解释原因

   张工方案能够对该视图查询性能有所提升，因为这样做能极大的减少统计分析的数据量，对小数据量进行统计，性能是能得以保障的

2. 解释说明李工指出的数据不一致问题产生的原因

   由于当日订单数据既存储在订单表中，又存储在单独的当天货物销售、存货情况表中。同一数据存储了两份，一旦出现修改，未同步修改，则会造成数据不一致

问题3 针对李工提出的问题，常见的解决手段有应用程序实现，触发器实现和物化视图实现等，请用300字以内的文字解释说明这三种方案

• 应用程序实现：在进行订单的添加、修改、删除操作时，从应用程序中，控制对两个数据表都进行相关操作，以保障数据的一致性
• 触发器实现：在应用程序中，只对订单表进行操作。但写触发器，当订单表发生变化时，把当日订单内容同步更新到当天货物销售、存货情况表中
• 物化视图实现：建立“当天货物销售、存货情况”的物化视图，物化视图会把相应的数据物理存储起来，而且在订单表发生变化时，会自动更新

数据库分区分表分库

分区分表的区别是在逻辑层面是不是还是同一张表，分库则是在逻辑层面不是同一张库

分区

分区的常见方式

• 范围分区（按数据范围值来做分区）

  

• 哈希分区（通过对 key 进行 hash 运算分区）

  

• 列表分区（根据某字段的某个具体值进行分区）

  

分区的优点

1. 相对于单个文件系统或是硬盘，分区可以存储更多的数据
2. 数据管理比较方便，比如要清理或废弃某年的数据，就可以直接删除该日期的分区数据即可
3. 精准定位分区查询数据，不需要全表扫描查询，大大提高数据检索效率
4. 可跨多个分区磁盘查询，来提高查询的吞吐量
5. 在涉及聚合函数查询时，可以很容易进行数据的合并

分表

分库

分布式数据库 ★★★

• 分布透明性

  • 分片透明性：分不分片，用户感受不到
  • 位置透明性：数据存放在哪里，用户不用管
  • 局部数据模型透明性（逻辑透明）：用户不用关系局部数据模型
  

• 分布式数据库管理系统-组成

  • LDBMS
  • GDBMS
  • 全局数据字典
  • 通信管理(CM)

• 分布式数据库管理系统 - 结构

  • 全局控制集中的 DDBMS
  • 全局控制分散的 DDBMS
  • 全局控制部分分散的 DDBMS

NoSQL ★★★

NoSQL(Not-only SQL：不仅仅只是SQL，泛指非关系型的数据库

其他数据库扩展知识 ★★★

**联邦数据库系统(FDBS)**是一个彼此协作却又相互独立的成员数据库(CDBS)的集合，它将成员数据库系统按不同程度进行集成，对该系统整体提供控制和协同操作的软件

联邦数据库特征

• 分布性
• 异构性
• 自治性
• 透明性

联邦数据库分类

• 紧耦合
• 松耦合

数据库性能优化

集中式数据库优化

• 硬件系统：CPU，内存，I/O(硬盘，阵列)，网络
• 系统软件：参数，如进程优先级，CPU使用权，内存使用
• 数据库设计
  • 表与视图：表的规划，建立物化视图
  • 索引：常查询 - 建索引，常修改 - 避免索引
  • SQL优化：以不相干子查询替代相干子查询，只检索需要的列，用带 IN 的条件子句等价替换 OR 子句，经常提交COMMIT,以尽早释放锁，尽可能减少多表查询
• 应用软件：数据库连接池

分布式数据库优化

通信代价：全局查询树的变换、多副本策略、查询树的分解、半连接与直接连接