系统分析师5-数据库特训专题

2024-08-28 09:36

本文主要是介绍系统分析师5-数据库特训专题,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

文章目录

  • 1 数据库设计概述
  • 2 规范化与反规范化
    • 2.1 规范化
    • 2.2 反规范化
    • 2.3 案例分析例题1
  • 3 数据库索引与视图的应用
    • 3.1 数据库索引
    • 3.2 数据库视图
    • 3.3 案例分析例题2
  • 4 分布式数据库系统
  • 5 数据库分区分表分库
    • 5.1 案例分析例题3
  • 6 分布式事务增补
    • 6.1 案例分析例题4
  • 7 NoSQL
  • 8 附录:思维导图

1 数据库设计概述

  • 数据库设计关注的问题:性能、数据一致性、安全
    在这里插入图片描述
  • 数据库性能优化
    在这里插入图片描述
  • 数据库设计流程
    在这里插入图片描述

2 规范化与反规范化

2.1 规范化

在这里插入图片描述思考:范式级别提升带来了什么负面影响?

规范化理论是以模式分解的方式进行提升;
规范化程度越高,表的粒度越小,但是会增加多表联合查询,查询性能非常差。

2.2 反规范化

  • 进行反规范化之前,要先做规范化
    在这里插入图片描述
  • 反规范化技术手段及说明
    在这里插入图片描述
  • 反规范化的优缺点
    在这里插入图片描述
  • 数据同步:物化视图可以解决一致性问题

2.3 案例分析例题1

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

【问题1]】(8分)
系统需要管理供应商和货物等信息,具体包括供应商姓名、地址以及货物名称、价格等,供应商可以提供0~n种货物,其公司地址也可能发生变化。请以供应商关系模式supplier(name,address,product,price)为例,解释不规范的关系模式存在哪些问题。
【问题2】(6分)
应用开发小组认为张工的规范化设计虽然解决了未规范化关系模式带来的问题,但实际实现功能时会造成系统性能的下降,请解释其原因。
【问题3】(5分)
请解释逆规范化方法,说明其优缺点。
【问题4】(6分)
针对该信息系统中核心销售数据处理的特点,如采用关系表水平分割的逆规范化方法,请给出具体的解决方案,并说明该方案存在的问题。

答案:
【问题1】(8分)
(1)数据冗余︰关系模式中多次重复记录了同一供应商的地址。
(2)插入异常:如果还未确定一个供应商有哪些货物,只是想添加一个供应商的地址信息,则会产生产品与价格均为空的记录。
(3)修改异常:当修改一个供应商的地址时,需要将多条记录同时更新,若未同时更新,则数据产生不一致
(4)删除异常:当删除一个供应商的货物时,其地址信息被一并删除。
【问题2】(6分)
数据库规范化的过程,实际是对数据表的不断拆分,以达到更高的规范程度。这样处理,带来的问题是∶系统中大量查询不能通过单表完成,而需要将多表进行连接查询,所以表拆分得越多,查询性能也就越差。
【问题3】(5分)
规范化设计后,数据库设计者希望牺牲部分规范化来提高查询性能,这种从规范化设计的回退方法称为反规范化技术。
逆规范化方法优点:提高统计、查询效率。
逆规范化方法缺点:增加了数据冗余,浪费存储空间,增、删、改操作的效率降低,可能导致数据不一致,可能产生添加、修改、删除异常。
【问题4】(6分)
解决方案:将各省的数据存放于各省分公司。该方案主要问题:
(1)在于总公司进行全国数据统计时,需要从各省服务器调取数据,效率较低。(2)执行应用功能时需要动态选择分公司的数据库表,增加了应用程序的复杂度。

3 数据库索引与视图的应用

3.1 数据库索引

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

  • 数据库索引示例
    在这里插入图片描述

  • B+树索引示例
    在这里插入图片描述

3.2 数据库视图

  • 视图(View)并不在数据库中实际存在,而是一种虚拟表。
  • 数据库视图示例
    在这里插入图片描述
  • 视图的优点
    在这里插入图片描述
  • 视图不影响性能,既不提升性能,也不降低性能
  • 物化视图
    在这里插入图片描述

3.3 案例分析例题2

某软件企业开发一套类似于淘宝网上商城业务的电子商务网站。该系统涉及多种用户角色,包括购物用户、商铺管理员、系统管理员等。

在数据库设计中,该系统数据库的核心关系包括:
产品(产品编码,产品名称,产品价格,库存数量,商铺编码)
商铺(商铺编码,商铺名称,商铺地址,商铺邮箱,服务电话)
用户(用户编码,用户名称,用户地址,联系电话)
订单(订单编码,订单日期,用户编码,商铺编码,产品编码,产品数量,订单总价)

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

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

【问题2】(8分)
为解决该视图查询性能比较差的问题,张工建议为该数据建立单独的商品当天货物销售、存货情况的关系表。但李工认为张工的方案造成了数据不一致的问题,必须采用定的手段来解决。
1)说明张工方案是否能够对该视图查询性能有所提升,并解释原因。
2)解释说明李工指出的数据不一致问题产生的原因。

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

答案:
【问题1】
视图是虚表,是从一个或几个基本表(或视图)中导出的表,在系统的数据字典中仅存放了视图的定义,不存放视图对应的数据。
视图的优点:
1、视图能简化用户的操作
2、视图机制可以使用户以不同的方式查询同一数据
3、视图对数据库重构提供了一定程度的逻辑独立性
4、视图可以对机密的数据提供安全保护
查询性能较差的原因是视图中“日销售产品数量”需要针对订单表做统计分析,订单表中有数量庞大的历史销售记录,所以这种操作极为耗时。
【问题2】
1)张工方案能够对该视图查询性能有所提升,因为这样做能极大减少统计分析的数据量,对小数据量进行统计,性能是能得以保障的。
2)由于当日订单数据既存储在订单表中,又存储在单独的当天货物销售、存货情况表中。同一数据存储了两份,一旦出现修改,未同步修改,则会造成数据不一致。
【问题3】
应用程序实现:在进行订单的添加、修改、删除操作时,从应用程序中,控制对两个数据表都进行相关操作,以保障数据的一致性。
触发器实现:在应用程序中,只对订单表进行操作。但写触发器,当订单表发生变化时,把当日订单内容同步更新到当天货物销售、存货情况表中。
物化视图实现:建立“当天货物销售、存货情况”的物化视图,物化视图会把相应的数据物理存储起来,而且在订单表发生变化时,会自动更新。

4 分布式数据库系统

  • 分布式数据库逻辑结构
    在这里插入图片描述
  • 分布式数据库的透明性分类

在这里插入图片描述

  • 两阶段提交协议2PC
    在这里插入图片描述

5 数据库分区分表分库

  • 数据库分区分表分库示例
    在这里插入图片描述

  • 分区和分表的异同
    在这里插入图片描述

  • 分区的常见方式
    在这里插入图片描述

  • 分区的优点
    在这里插入图片描述

5.1 案例分析例题3

阅读以下关于数据管理的叙述,在答题纸上回答问题1至问题3。
【说明】
某全国连锁药店企业在新冠肺炎疫情期间,紧急推出在线口罩预约业务系统。该业务系统为普通用户提供口罩商品查询、购买、订单查询等业务,为后台管理人员提供订单查询、订单地点分布汇总、物流调度等功能。该系统核心的关系模式为预约订单信息表。
推出业务系统后,几天内业务迅速增长到每日10万多笔预约订单,系统数据库服务器压力剧增,导致该业务交易响应速度迅速降低,甚至出现部分用户页面无法刷新、预约订单服务无响应的情况。为此,该企业紧急成立技术团队,由张工负责,以期尽快解决该问题。

【问题1】(9分)
经过分析,张工认为当前预约订单信息表存储了所有订单信息,记录已达到了百万级别。系统主要的核心功能均涉及对订单信息表的操作,应首先优化预约订单信息表的读写性能,建议针对系统中的SQL语句,建立相应索引,并进行适当的索引优化。
针对张工的方案,其他设计人员提出了一些异议,认为索引过多有很多副作用。请用100字以内的文字简要说明索引过多的副作用。
【问题2】(10分)
作为团队成员之一,李工认为增加索引并进行优化并不能解决当前问题,建议采用物理分区策略,可以根据预约订单信息表中“所在城市”属性进行表分区,并将每个分区分布到独立的物理磁盘上,以提高读写性能。常见的物理分区特征如表4-1所示。李工建议选择物理分区中的列表分区模式。
请填补表4-1中的空(a) ~(d)处,并用100字以内的文字解释说明李工选择该方案的原因。
在这里插入图片描述【问题3】(6分)
在系统运行过程中,李工发现后台管理人员执行的订单地址信息汇总等操作,经常出现与普通用户的预约订单操作形成读写冲突,影响系统的性能。因此李工建议采用读写分离模式,采用两台数据库服务器,并采用主从复制的方式进行数据同步。请用100字以内的文字简要说明主从复制的基本步骤

分析:
问题1:从以下角度进行解答:空间上;开销上;优化评估;统计;索引相互影响
问题2:(a)属性的离散值;(b)周期数据;©能力强;(d)均匀
问题3:中继日志
答案:
【问题1】
索引过多的副作用有:
(1) 过多的索引会占用大量的存储空间;
(2) 更新开销,更新语句会引起相应的索引更新;
(3) 过多索引会导致查询优化器需要评估的组合增多;
(4) 每个索引都有对应的统计信息,索引越多则需要的统计信息越多;
(5) 聚集索引的变化会导致非聚集索引的同步变化;
(6) 增加运维工作量,导致运维困难。
【问题2】
(a) 属性的离散值
(b) 周期性数据/周期数据
(c ) 能力强
(d) 均匀
李工建议根据预约订单所在城市进行表分区,而所在城市属性为离散值,根据所在城市属性建立列表分区,也方便不同城市处理自己的数据,方便数据管理,方便按城市汇总数据。
【问题3】
主从复制的基本步骤:
(1)主服务器将所做修改通过自己的I/O线程,保存在本地二进制日志中;
(2)从服务器上的I/O线程读取主服务器上面的二进制日志,然后写入从服务器本地的中继日志;
(3) 从服务器上同时开启一个SQL thread,定时检查中继曰志,如果发现有更新则立即把更新的内容在本机的数据库上面执行一遍。

6 分布式事务增补

  • 两阶段提交协议2PC
    在这里插入图片描述
  • 两阶段提交协议活动图
    在这里插入图片描述
  • 两阶段提交协议对故障的恢复
    在这里插入图片描述
    例题1
    分布式数据库系统中的两阶段提交协议(Two Phase Commit Protocol,2PC协议)包含协调者和参与者,通常有如下操作指令。满足2PC的正常序列是()
    ①协调者向参与者发prepare消息;②参与者向协调者发回ready消息
    ③参与者向协调者发回abort消息;④协调者向参与者发commit消息
    ⑤协调者向参与者发rollback消息
    A ①②④
    B ①②⑤
    C ②③④
    D ②③⑤

分析:
如果是正常提交序列为:①②④;
如果是异常回滚序列为:①③⑤;
答案:选A

例题2
分布式事务的执行可能会涉及多个站点上的数据操作,在两阶段提交协议中,当事务Ti的所有读写操作执行结束后,事务Ti的发起者协调器Ci向所有参与Ti的执行站点发送< prepare Ti>的消息,当收到所有执行站点返回的< ready Ti>消息后,Ci再向所有执行站点发送< commit Ti>消息。若参与事务Ti执行的某个站点故障恢复后日志中有< ready Ti>记录,而没有< commit Ti>记录,则( )。
A 事务Ti已完成提交,该站点无需做任何操作
B 事务Ti已完成提交,该站点应做REDO操作
C 事务Ti未完成提交,该站点应做UNDO操作
D 应向协调器询问以决定Ti的最终结果

分析:
没有< commit Ti>记录说明事务没有提交,在事务没有提交的情况下,还要再询问协调者到底做不做,因此应向协调器询问以决定Ti的最终结果
正确选项:D。

6.1 案例分析例题4

题干:阅读以下关于微服务架构中的数据管理的叙述,在答题纸上回答问题1至问题3。
【说明】
某大型电商平台构建了一个在线B2B商店系统。该系统采用微服务架构,将系统功能分解为多个松散耦合且可独立部署的较小组件或服务。最终设计的系统包括了电商系统中常见的服务:客户服务、订单服务、支付服务等,其中:
1、客户服务负责对客户相关的信息进行管理和维护;
2、订单服务负责对订单信息的管理和维护;
3、支付服务负责对在线支付功能和信息的管理和维护等。
为了确保微服务之间的松耦合,每个服务都有自己的数据,其中,订单服务使用了NoSQL数据库,客户服务和支付服务使用了关系数据库。
李工认为由于不同服务使用了各自的不同数据库,使得跨服务操作可能存在数据不一致。比如订单与支付的数据一致性问题,系统通过订单服务在本地NoSQL数据库中创建订单记录,同时在支付服务的关系数据库中创建支付记录,且必须保证订单记录和支付记录的一致性,该问题在系统构建时需要考虑。

【问题1】(7分)
李工建议采用两阶段提交协议(2PC)来解决服务数据的一致性问题。请用200字以内的文字简要说明2PC;说明2PC是否能解决该问题,并简要解释原因。
【问题2】(8分)
王工建议采用分布式数据管理方案,用事件驱动架构来解决服务数据的一致性问题,在订单服务和支付服务之间通过可靠的消息队列实现事件的传递,其基本操作步骤如下,请填写其中的空白处。
(1)订单服务接收订购请求,创建一个订单,该记录状态为(a) ,发布一个“创建订单”事件;(2)(b)接收“创建订单”事件,记录©,发布一个“支付完成”事件;
(3)订单服务接收“支付完成”事件,修改订单记录状态为(d) 。
【问题3】(10分)
李工提出王工的方案会有数据库更新和发布事件的原子性问题,例如订单服务创建订单记录和友布“创建订单”事件需要原子性保障,否则会出现数据不一致状态。
王工认为可以使用本地事务发布事件的方法来解决该问题。请给出使用本地事务发布事件的基本方法,并说明该方法的缺点。

答案:
【问题1】
1、两阶段提交协议2PC经常用来管理分布式事务。
(1)2PC包含协调者和参与者两类站点,只有协调者才拥有提交或撤销事务的决定权,而其他参与者各自负责在其本地数据库中执行写操作,并向协调者提出撤销或提交事务的意向。
(2)2PC分为两个阶段:表决阶段和执行阶段。
①表决阶段,目的是形成一个共同的决定。协调者给所有参与者发送“准备提交”消息,并进入等待状态,所有参与者给与回复“建议提交”或“建议撤销”。只要有一个结点选择撤销,则整体事务撤销,否则,执行该事务。
②执行阶段,目的是实现这个协调者的决定。根据协调者的指令,参与者或者提交事务,或者撤销事务,并给协调者发送确认消息。
2、两阶段提交协议2PC不能解决当前问题。
(1)分布式数据库遵循的是CAP原则,会在一定程度上牺牲一致性。()大多数NoSQL 数据库并不支持2PC。
(3)分布式两阶段提交协议2PC一般针对的对象在逻辑上是一个整体,对某一个整体事务需要在多个物理节点上执行时,进行表决和执行,对多个数据库的不同服务并不是很合适。
【问题2】
(a)未支付 (b)支付服务 (c )支付信息 (d)已支付
【问题3】
使用本地事务发布事件:
由一个独立进程来发布事件。具体来说,就是在存储业务实体状态的数据库中,使用一个事件表来充当消息队列。应用启动一个(本地〉数据库事务,更新业务实体的状态,在事件表中插入一个事件,并提交该事务。一个独立的消息发布线程或进程查询该事件表,将事件发布到消息代理,并标注该事件为已发布。
缺点:
由于开发者必须牢记发布事件,因此有很大可能出错。此外这一方法对于某些使用NoSQL数据库的应用是个挑战,因为NosQL本身交易和查询能力有限。

7 NoSQL

  • NoSQL (Not-only sQL)∶不仅仅只是SQL,泛指非关系型的数据库。
  • 关系数据库和NoSQL的对比
    在这里插入图片描述
  • NoSQL分类
    在这里插入图片描述
  • NoSQL分类及优缺点
    在这里插入图片描述

8 附录:思维导图

在这里插入图片描述

这篇关于系统分析师5-数据库特训专题的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1114395

相关文章

Spring Security基于数据库验证流程详解

Spring Security 校验流程图 相关解释说明(认真看哦) AbstractAuthenticationProcessingFilter 抽象类 /*** 调用 #requiresAuthentication(HttpServletRequest, HttpServletResponse) 决定是否需要进行验证操作。* 如果需要验证,则会调用 #attemptAuthentica

不懂推荐算法也能设计推荐系统

本文以商业化应用推荐为例,告诉我们不懂推荐算法的产品,也能从产品侧出发, 设计出一款不错的推荐系统。 相信很多新手产品,看到算法二字,多是懵圈的。 什么排序算法、最短路径等都是相对传统的算法(注:传统是指科班出身的产品都会接触过)。但对于推荐算法,多数产品对着网上搜到的资源,都会无从下手。特别当某些推荐算法 和 “AI”扯上关系后,更是加大了理解的难度。 但,不了解推荐算法,就无法做推荐系

基于人工智能的图像分类系统

目录 引言项目背景环境准备 硬件要求软件安装与配置系统设计 系统架构关键技术代码示例 数据预处理模型训练模型预测应用场景结论 1. 引言 图像分类是计算机视觉中的一个重要任务,目标是自动识别图像中的对象类别。通过卷积神经网络(CNN)等深度学习技术,我们可以构建高效的图像分类系统,广泛应用于自动驾驶、医疗影像诊断、监控分析等领域。本文将介绍如何构建一个基于人工智能的图像分类系统,包括环境

水位雨量在线监测系统概述及应用介绍

在当今社会,随着科技的飞速发展,各种智能监测系统已成为保障公共安全、促进资源管理和环境保护的重要工具。其中,水位雨量在线监测系统作为自然灾害预警、水资源管理及水利工程运行的关键技术,其重要性不言而喻。 一、水位雨量在线监测系统的基本原理 水位雨量在线监测系统主要由数据采集单元、数据传输网络、数据处理中心及用户终端四大部分构成,形成了一个完整的闭环系统。 数据采集单元:这是系统的“眼睛”,

MySQL数据库宕机,启动不起来,教你一招搞定!

作者介绍:老苏,10余年DBA工作运维经验,擅长Oracle、MySQL、PG、Mongodb数据库运维(如安装迁移,性能优化、故障应急处理等)公众号:老苏畅谈运维欢迎关注本人公众号,更多精彩与您分享。 MySQL数据库宕机,数据页损坏问题,启动不起来,该如何排查和解决,本文将为你说明具体的排查过程。 查看MySQL error日志 查看 MySQL error日志,排查哪个表(表空间

嵌入式QT开发:构建高效智能的嵌入式系统

摘要: 本文深入探讨了嵌入式 QT 相关的各个方面。从 QT 框架的基础架构和核心概念出发,详细阐述了其在嵌入式环境中的优势与特点。文中分析了嵌入式 QT 的开发环境搭建过程,包括交叉编译工具链的配置等关键步骤。进一步探讨了嵌入式 QT 的界面设计与开发,涵盖了从基本控件的使用到复杂界面布局的构建。同时也深入研究了信号与槽机制在嵌入式系统中的应用,以及嵌入式 QT 与硬件设备的交互,包括输入输出设

JAVA智听未来一站式有声阅读平台听书系统小程序源码

智听未来,一站式有声阅读平台听书系统 🌟&nbsp;开篇:遇见未来,从“智听”开始 在这个快节奏的时代,你是否渴望在忙碌的间隙,找到一片属于自己的宁静角落?是否梦想着能随时随地,沉浸在知识的海洋,或是故事的奇幻世界里?今天,就让我带你一起探索“智听未来”——这一站式有声阅读平台听书系统,它正悄悄改变着我们的阅读方式,让未来触手可及! 📚&nbsp;第一站:海量资源,应有尽有 走进“智听

【专题】2024飞行汽车技术全景报告合集PDF分享(附原数据表)

原文链接: https://tecdat.cn/?p=37628 6月16日,小鹏汇天旅航者X2在北京大兴国际机场临空经济区完成首飞,这也是小鹏汇天的产品在京津冀地区进行的首次飞行。小鹏汇天方面还表示,公司准备量产,并计划今年四季度开启预售小鹏汇天分体式飞行汽车,探索分体式飞行汽车城际通勤。阅读原文,获取专题报告合集全文,解锁文末271份飞行汽车相关行业研究报告。 据悉,业内人士对飞行汽车行业

【区块链 + 人才服务】可信教育区块链治理系统 | FISCO BCOS应用案例

伴随着区块链技术的不断完善,其在教育信息化中的应用也在持续发展。利用区块链数据共识、不可篡改的特性, 将与教育相关的数据要素在区块链上进行存证确权,在确保数据可信的前提下,促进教育的公平、透明、开放,为教育教学质量提升赋能,实现教育数据的安全共享、高等教育体系的智慧治理。 可信教育区块链治理系统的顶层治理架构由教育部、高校、企业、学生等多方角色共同参与建设、维护,支撑教育资源共享、教学质量评估、

软考系统规划与管理师考试证书含金量高吗?

2024年软考系统规划与管理师考试报名时间节点: 报名时间:2024年上半年软考将于3月中旬陆续开始报名 考试时间:上半年5月25日到28日,下半年11月9日到12日 分数线:所有科目成绩均须达到45分以上(包括45分)方可通过考试 成绩查询:可在“中国计算机技术职业资格网”上查询软考成绩 出成绩时间:预计在11月左右 证书领取时间:一般在考试成绩公布后3~4个月,各地领取时间有所不同