个人总结，仅供参考，欢迎加好友一起讨论
文章目录
架构 - 案例分析 - 数据库设计
| 年份 | 考察内容 | 分值 |
|---|---|---|
| 2022年 | 分布式数据库缓存设计 - 一致性、布隆过滤器 | 25分 |
| 2021年 | 数据库设计 - 规范化与反规范化技术、Redis | 25分 |
| 2020年 | 分布式数据库缓存设计 - Redis | 25分 |
| 2020年 | 数据库设计 - 规范化数据库设计 | 25分 |
| 2019年 | 分布式数据库缓存设计 - 一致性问题和运维 | 25分 |
| 2019年 | Web系统架构设计 - SQL注入攻击 | 7分 |
| 2018年 | 分布式数据库缓存设计 - MemCache和Redis | 25分 |
数据库基础
数据库设计概述
规划（不一定有）：进行建立数据库的必要性及可行性分析，确定数据库系统在企业和信息系统中的地位，以及各个数据库之间的联系。
需求分析：通过调查研究，了解用户的数据和处理要求，并按一定格式整理形成需求说明书。
概念设计：在需求分析阶段产生的需求说明书的基础上，按照特定的方法将它们抽象为一个不依赖于任何数据库管理系统的数据模型，即概念模型。
逻辑设计：将概念模型转化为某个特定的数据库管理系统上的逻辑模型。设计逻辑结构时，首先为概念模型选定一个合适的逻辑模型（通常是关系模型），然后将其转化为由特定DBMS支持的逻辑模型，最后对逻辑模型进行优化。
物理设计：对给定的逻辑模型选取一个最适合应用环境的物理结构，所谓数据库的物理结构，主要是指数据库在物理设备上的存储结构和存取方法。
数据库设计关注的问题：
性能、数据一致性、安全
E-R模型
概念结构设计
案例片段解析：
请根据下图数据流图表示的相关信息，补充完善下方XX建设项目安全预警系统总体E-R图中实体（1）~（6）的具体内容。
参考答案：
（1）项目管理员（2）项目经理（3）项目指标数据
（4）指标参数（5）项目信息（6）事故及影响因素参数
逻辑结构设计
规范化（范式）
思考：范式级别提升带来了什么负面影响?
反规范化技术
| 技术手段 | 说明 |
|---|---|
| 增加派生性列 | 增加派生列指增加的列可以通过表中其他数据计算生成。它的作用是在查询时减少计算量，从而加快查询速度。 例如：已有"单价"和"数量"列，增加"总价"列 |
| 增加冗余列 | 增加冗余列是指在多个表中具有相同的列，它常用来在查询时避免连接操作。 例如：已有"学号"列，增加"姓名"列 |
| 重新组表 | 重新组表指如果许多用户需要查看两个表连接出来的结果数据，则把这两个表重新组成一个表来减少连接而提高性能。 |
| 分割表 | 水平分割，按记录进行分割，把数据放到多个独立的表中，主要用于表数据规模很大或表中数据相对独立或数据需要存放到多个介质上时使用。 垂直分割，对表进行分割，将主键与部分列放到一个表中，主键与其它列放到另一个表中， 在查询时减少 I/0 次数。 |
反规范化的优点：
- 连接操作少，检索快、统计快。
- 需要查的表减少，检索容易。
缺点：
- 数据冗余，需要更大存储空间
- 插入、更新、删除操作开销更大
- 数据不一致，可能产生添加、修改、删除异常。可借助触发器数据同步，应用程序数据同步，物化视图解决。
- 更新和插入代码更难写
数据库事务
|-----|------------------------------------|
| 事务的4个属性（4个特性）： ||
| 原子性 | 操作，操作序列（事务）要么全做，要么全不做 |
| 一致性 | 数据，数据库从一个一致性状态，变到另一个一致性状态 |
| 隔离性 | 执行，一个事务的执行不能被其他事务干扰 |
| 持续性 | 变化，一个事务一旦提交，它对数据库的改变是永久的，即便系统出现了故障 |
并发控制
| 并发产生的问题： |
|---|
| 丢失更新 |
| 不可重复读问题 |
| 读出"脏"数据 |
|-------|-----------------------------------------------------------------|
| 丢失更新 | 两个事务T1和T2同时读入同一数据并修改，T2提交的结果将破坏T1的结果，T1的修改被丢失 |
| 丢失更新 | 对T1加X锁（写锁），那么T2只能在T1解锁后读 |
| 读赃数据 | T1修改了某一个数据，T2读取了同一个数据，T1由于某种原因被撤销，则T2读到的数据就是赃数据 |
| 读赃数据 | 修改时加排他锁，直到事务提交后才释放，读取时加共享锁，读取完释放T1读取数据时加上共享锁后，不允许任何事物操作该数据，只能读取 |
| 不可重复读 | T1读取某一数据，T2读取某一数据，并进行修改，T1为了对读取值进行校对再读取时，得到不同结果 |
| 不可重复读 | T1加X锁（写锁）后，T2对同一数据加X锁（写锁），这样T1的锁解开后，才可以调用T2 |
|--------|----------------------------------------------------------------|
| 一级封锁协议 | 事务T1在修改A之前必须先对其加X锁，直到事务结束才释放 可防止丢失修改 |
| 二级封锁协议 | 在一级封锁协议加上事务T1在读取数据A之前先对其加S锁，读完后即可释放S锁 可防止丢失修改，可防止读脏数据 |
| 三级封锁协议 | 在一级封锁协议加上事务T1在读取数据R之前先对其加S锁，直到事务结束时才释放 可防止丢失修改，可防止读脏数据，防止数据重复读 |
| 两段锁协议 | 分为封锁阶段（扩展）和释放阶段（收缩）。封锁阶段只能加锁、扩展阶段只能解锁 可串行化的，可能发生死锁 |
索引
数据库索引：提升查询效率；降低添加、修改、删除效率；采用B树，B+树等。
索引的优点：
- 通过创建唯一性索引，可以保证数据库表中每一行数据的唯一性
- 可以大大加快数据的检索速度，这也是创建索引的最主要的原因
- 可以加速表和表之间的连接，特别是在实现数据的参考完整性方面特别有意义
- 在使用分组和排序子句进行数据检索时，同样可以显著减少查询中分组和排序的时间
- 通过使用索引，可以在查询的过程中，使用优化隐藏器，提高系统的性能
索引过多的副作用有：
- 过多的索引会占用大量的存储空间
- 更新开销，更新语句会引起相应的索引更新
- 过多索引会导致查询优化器需要评估的组合增多
- 每个索引都有对应的统计信息，索引越多则需要的统计信息越多
- 聚集索引的变化会导致非聚集索引的同步变化
视图
视图是保存在数据库中的SELECT查询，其内容由查询定义，因此，视图不是真实存在的基础表，而是从一个或者多个表中导出的虚拟的表。同真实的表一样，视图包含一系列带有名称的列和行数据，但视图中的行和列数据来自由定义视图的查询所引用的表，并且在引用视图时动态生成。
视图优点如下：
- 视点集中，视图只展示与用户相关的数据。
- 简化操作，在每一次执行相同的查询时，不必重新写查询语句，只要一条简单的查询视图语句即可。
- 定制数据，视图能够实现让不同的用户以不同的方式看到不同或相同的数据集。
- 合并分割数据，在有些情况下，由于表中数据量太大，故在表的设计时常将表进行水平分割或垂直分割，但表的结构的变化却对应用程序产生不良的影响。如果使用视图就可以重新保持原有的结构关系，从而使外模式保持不变，原有的应用程序仍可以通过视图来重载数据。
- 安全性，视图可以作为一种安全机制。通过视图用户只能查看和修改他们所能看到的数据。其它数据库或表既不可见也不可以访问。如果某一用户想要访问视图的结果集，必须授予其访问权限。视图所引用表的访问权限与视图权限的设置互不影响。
物化视图
在物化视图中数据查询结果被物理固化起来，其数据随着原始表变化，同步更新。物化视图也可以称为快照。
物化视图不是传统意义上虚拟视图，是实体化视图，其本身会存储数据。同时当原始表中的数据更新时，化视图也会更新。
存储过程
存储过程（Stored Procedure）是在大型数据库系统中，一组为了完成特定功能的SQL语句集，它存储在数据库中，一次编译后永久有效，用户通过指定存储过程的名字并给出参数（如果该存储过程带有参数）来执行它。
存储过程是数据库所提供的一种数据库对象，通过存储过程定 义一段代码，提供给应用程序调用来执行。 从安全性的角度考虑，更新数据时，通过提供存储过程让第三方调用，将需要更新的数据传入存储过程，而在存储过程内部用代码分别对需要的多个表进行更新，从而避免了向第三方提供系统的表结构，保证了系统的数据安全。
触发器
触发器是一种特殊的存储过程，当数据发生变化时，触发器会产生某种动作。使用触发器有助于强制保持数据库的数据完整性。
数据库性能优化
集中式数据库
- 硬件升级：处理器、内存、磁盘子系统和网络。
- 数据库设计：反规范化技术（逻辑）、数据库分区（物理）。
- 索引优化策略：选择经常查询不常更新的属性、数据量小的不设置索引等。
- 查询优化：建立物化视图或尽可能减少多表查询等。
分布式数据库
- 主从复制、读写分离
- 数据库分片（分表）、分库
- 分布式缓存技术
分布式数据库系统
- 全局外模式：全局外模式是全局应用的用户视图，是全局概念模式的子集，该层直接与用户（或应用程序）交互。
- 全局概念模式：全局概念模式定义分布式数据库中数据的整体逻辑结构，数据就如同根本没有分布一样，可用传统的集中式数据库中所采用的方法进行定义。
- 分片模式：在某些情况下，需要将一个关系模式分解成为几个数据片，分片模式正是用于完成此项工作的。
- 分布模式：分布式数据库的本质特性就是数据分布在不同的物理位置。分布模式的主要职责是定义数据片段（即分片模式的处理结果）的存放节点。
- 局部概念模式：局部概念模式是局部数据库的概念模式。
- 局部内模式：局部内模式是局部数据库的内模式。
分布式数据库管理系统 --- 组成：
- LDBMS
- GDBMS
- 全局数据字典
- 通信管理（CM）
分布式数据库管理系统 --- 结构：
- 全局控制集中的DDBMS
- 全局控制分散的DDBMS
- 全局控制部分分散的DDBMS
分布式数据库特点
|-----|---------------------------------|
| 共享性 | 不同的结点的数据共享 |
| 自治性 | 每个结点对本地数据都能独立管理 |
| 可用性 | 某一场地故障时，可以使用其他场地上的副本而不至于使整个系统瘫痪 |
| 分布性 | 数据分布在不同场地上的存储 |
分布透明性
两阶段提交协议2PC
2PC事务提交的两个阶段：
表决阶段，目的是形成一个共同的决定
执行阶段，目的是实现这个协调者的决定
两条全局提交规则：
只要有一个参与者撤销事务，协调者就必须做出全局撤销决定
只有所有参与者都同意提交事务，协调者才能做出全局提交决定
分区分表分库
| 分区 | 分表 | |
|---|---|---|
| 共性 | 1 都针对数据表 2 都使用了分布式存储 3 都提升了查询效率 4 都降低数据库的频繁I/O压力值 | |
| 差异 | 逻辑上还是一张表 | 逻辑上已经是多张表 |
分区技术
分区并不是生成新的数据表，而是将表的数据均衡分摊到不同的硬盘，系统或是不同服务器存储介质中，实际上还是一张表。
使用分区技术的优点：
- 减少维护工作量。独立管理每个分区比管理单张大表要轻松得多。
- 增强数据库的可用性。如果表的一个或几个分区由于系统故障而不能被使用，那么表其余的分区仍然可以使用；如果系统故障只影响表的一部分分区，那么，只有这部分分区需要修复，这就比修复整张大表耗费的时间少许多。
- 均衡I/O，减少竞争。通过把表的不同分区分配到不同的磁盘来平衡I/O改善性能。分区对用户保持透明。最终用户感觉不到分区的存在。
- 提高查询速度。对大表的查询、增加、修改等操作可以分解到表的不同分区中来并行执行。
数据分区技术一般分为水平分区和垂直分区，数据库中常见的是水平分区。水平分区分为范围分区、哈希分区、列表分区等。
- 范围分区（Range），按数据范围值来做分区。例：按用户编号分区，0-999999映射到分区A；1000000-1999999映射到分区B。
- 哈希分区（Hash），通过对key进行hash运算分区。例，可以把数据分配到不同分区，这类似于取余操作，余数相同的，放在一个分区上。
- 列表分区（List），根据某字段的某个具体值进行分区。例，长沙用户分成一个区，北京用户分成一个区。
| 范围分区 | 哈希分区 | 列表分区 | |
|---|---|---|---|
| 数据值 | 连续 | 连续、离散均可 | 离散 |
| 数据管理能力 | 强 | 弱 | 强 |
| 实施难度与可维护性 | 差 | 好 | 差 |
| 数据分布 | 不均匀 | 均匀 | 不均匀 |
分区的优点：
- 相对于单个文件系统或是硬盘，分区可以存储更多的数据。
- 数据管理比较方便，比如要清理或废弃某年的数据，就可以直接删除该日期的分区数据即可。
- 精准定位分区查询数据，不需要全表扫描查询，大大提高数据检索效率。
- 可跨多个分区磁盘查询，来提高查询的吞吐量。
- 在涉及聚合函数查询时，可以很容易进行数据的合并。
数据库主从复制
这里以MySQL为主，不同数据库是存在差异的
主从数据库结构特点：
- 一般：一主多从，也可以多主多从。
- 主库做写操作，从库做读操作。
步骤
主从复制步骤：
- 主库（Master）更新数据完成前，将操作写binlog日志文件。
- 从库（Salve）打开I/O线程与主库连接，做binlogdump process，并将事件写入中继日志。
- 从库执行中继日志事件，保持与主库一致。
也可以参考下图：
binlog的三种模式
其中binlog有三种模式：
- 基于SQL语句的复制，每一条更新的语句（insert、update、delete）都会记录在binlog中，进而同步到从库的relaylog中，被从库的SQL线程取出来，回放执行。 该模式的优点是binlog的日志量可能会比较少，比如一个涉及行数为1000行的update语句，同步这一个语句，就同步了1000行的数据。缺点是：同步的SQL语句里如果含有绑定本地变量的函数、关键字时，可能造成主从不一致的情况。比如SQL语句中有time函数，如果主从数据库的服务器时间不是精确相等，就会造成结果不一致。
- 基于行的复制，不记录SQL语句，只记录了哪个记录更新前和更新后的数据，可以保证主从之间数据绝对相同。缺点是：1条SQL更新1000行的数据无法再偷懒，必须原原本本同步1000行的数据量。
- 混合复制：以上两种模式的混合，选取两者的优点。对于有绑定本地特性、评估可能造成主从不一致的SQL语句，则自动选用ROW，其他的选择STATEMENT。
主从复制的同步模式
主从同步的同步模式：
- 全同步：当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。优点是：只要不是所有数据库都发生异常，就能保证数据不丢失。缺点是：因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。
- 半同步：主库只需要等待至少一个从库节点从 Binlog 中收到该请求，并保存到 Relay Log 文件即可，主库不需要等待所有从库给主库反馈。优点是：只收到的一个反馈，而不是全部从库完成提交的反馈，节省了很多时间，同时能保证主库发生故障后，至少能从余下的1个从库上找回全部数据。缺点是：降低了可用性，但权衡了可用性和性能，做出取舍。
- 异步：主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理。缺点是：主库如果发生问题，此时主库已经提交的事务可能并没有同步到从库上。可能导致数据丢失或不完整。优点是：处理请求的延迟降到了最低。
主从复制的优点
-
避免数据库单点故障、提高可用性：主服务器实时、异步复制数据到从服务器，当主数据库宕机时，可在从数据库中选择一个升级为主服务器，从而防止数据库单点故障。
-
提高查询效率：根据系统数据库访问特点，可以使用主数据库进行数据的插入、删除及更新等写操作，而从数据库则专门用来进行数据查询操作，从而将查询操作分担到不同的从服务器以提高数据库访问效率。
-
读写分离：设置不同的主/从数据库分别负责不同的操作。让主数据库负责数据的写操作，从数据库负责数据
的读操作。通过角色分担的策略，分别提升读写性能，有效减少数据并发操作的延迟。
NoSQL非关系型数据库
NoSQL，Not-only SQL，泛指非关系型数据库。
与关系型数据库对比
| 关系型数据库模式 | NoSQL | |
|---|---|---|
| 并发支持 | 支持并发，但效率低 | 并发性能高 |
| 存储与查询 | 关系表方式存储，SQL查询 | 海量数据存储，查询效率高 |
| 扩展方式 | 向上扩展 | 向外扩展 |
| 索引方式 | B树，哈希等 | 键值索引 |
| 应用领域 | 通用领域 | 特定应用领域 |
| 数据类型 | 结构化数据，二维表 | 非结构化数据 |
| 事务支持 | 高事务性 | 弱事务性 |
| 成本 | 花费巨大，成本高 | 部署简单，成本低，开源 |
| 查询速度 | 数据存储于硬盘中，SQL查询慢 | 数据存储于缓存中，查询速度快 |
| 存储数据类型 | 只支持基础数据类型，结构化 | 支持基础和对象，集合等非结构化类型 |
| 扩展性 | 多表查询，扩展复杂 | 基于键值对，容易水平扩展 |
| 持久存储 | 支持海量数据存储 | 数据在缓存中，不适用于持久存储 |
| 数据一致性 | 需要事务，强调数据的强一致性 | 不提供、弱事务处理，数据一致性较弱 |
| 数据容量 | 数据有限 | 海量数据 |
| 标准化 | 是 | 否 |
类型
键值Key - Value
键可是一个字符串对象，值可以是任意类型的数据。如整型、字符型、数组、列表、集合等。
列族数据库
分行式存储和列式存储。
文档数据库
图形数据库
缓存技术
常见缓存技术：
MemCache：Memcache是一个高性能的分布式的内存对象缓存系统，用于动态Web应用以减轻数据库负载。Memcache通过在内存里维护一个统一的巨大的hash表，它能够用来存储各种格式的数据,包括图像、视频、文件以及数据库检索的结果等。
Redis：Redis是一个开源的使用ANSIC语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库,并提供多种语言的APl。
Squid：squid是一个高性能的代理缓存服务器，Squid支持FTP、gopher、HTTPS和HTTP协议。
思考：数据库与缓存数据是否有可能不一致？如何解决？
Redis
Redis与Memcache对比
| Memcache | Redis | |
|---|---|---|
| 数据类型 | 简单的Key-Value结构 | 丰富的数据结构 |
| 持久性 | 不支持 | 支持 |
| 分布式存储 | 客户端哈希分片/一致性哈希 | 多种方式，主从，Sentinel，Cluster等 |
| 多线程支持 | 支持 | Redis6.0开始支持 |
| 内存管理 | 私有内存池/内存池 | 无 |
| 事务支持 | 不支持 | 有限支持 |
| 数据容灾 | 不支持，不能做数据恢复 | 支持，可以在做数据恢复 |
Redis分布式存储方案
| 分布式存储方案 | 核心特点 |
|---|---|
| 主从（Master/Slave）模式 | 一主多从，故障时手动切换 |
| 哨兵（Sentinel）模式 | 有哨兵的一主多从，主节点故障自动选择新的主节点 |
| 集群（Cluster）模式 | 分节点对等集群,分slots，不同slots的信息存储到不同节点 |
Redis集群切片方式
| 切片方式 | 核心特点 |
|---|---|
| 客户单分片 | 在客户端通过key的hash值对应到不同的服务器 |
| 中间件实现分片 | 在应用软件和Redis中间，例如：Twemproxy、Codis等，由中间件实现服务到后台Redis节点的路由分派 |
| 客户端服务端协作分片 | 客户端与服务端协作完成分片处理 |
Redis数据分片方案
| 方案 | 分片方式 | 说明 |
|---|---|---|
| 范围分片 | 按数据范围值来做分片 | 例：按用户编号分片，0-999999映射到实例A；1000000-1999999映射到实例B。 |
| 哈希分片 | 通过key进行hash运算分片 | 可以把数据分配到不同实例,这类似于取余操作，余数相同的，放在一个实例上。 |
| 一致性哈希分片 | 哈希分片的改进 | 利于扩展结点，可以有效解决重新分配节点带来的无法命中问题。 |
Redis数据类型
| 类型 | 特点 | 示例 |
|---|---|---|
| String 字符串 | 存储二进制，任何类型数据，最大512MB | 缓存，计数，共享Session |
| Hash 字典 | 无序字典，数组+链表，适合存对象 Key对应一个HashMap，针对一组数据 | 存储、读取、修改用户属性 |
| List 列表 | 双向链表，有序，增删快，查询慢 | 消息队列，文章列表 记录前N个最新登录的用户ID列表 |
| Set 集合 | 键值对无序，唯一 支持交/并/差集操作 | 独立IP，共同爱好，标签 |
| Sorted Set [Zset] 有序集合 | 键值对有序，唯一，自带按权重排序效果 | 排行榜 |
Redis新的3种数据类型：
Bitmaps，位操作字符串
HyperLoglog
Geographic
持久化RDB和AOF
RDB：传统数据库中快照的思想。指定时间间隔将数据进行快照存储。
AOF：传统数据库中日志的思想，把每条改变数据集的命令追加到AOF文件末尾，这样出问题了，可以重新执行AOF文件中的命令来重建数据集。
| 对比 | RDB | AOF |
|---|---|---|
| 备份量 | 重量级的全量备份，保存整个数据库 | 轻量级增量备份，一次只保存一个修改命令 |
| 保存间隔时间 | 保存间隔时间长 | 保存间隔时间短，默认1秒 |
| 还原速度 | 数据还原速度快 | 数据还原速度慢 |
| 阻塞情况 | save会阻塞，但bgsave或者自动不会阻塞 | 无论是平时还是AOD重写，都不会阻塞 |
| 数据体积 | 同等数据体积：小 | 同等数据体积：大 |
| 安全性 | 数据安全性：低，容易丢数据 | 数据安全性：高，根据策略决定 |
淘汰与过期时间
| 淘汰作用范围 | 机制名 | 策略 |
|---|---|---|
| 不淘汰 | noeviction | 禁止驱逐数据，内存不足以容纳新入数据时，新写入操作就会报错。系统默认的一种淘汰策略。 |
| 设置了过期时间的键空间 | volatile-random | 随机移除某个key |
| 设置了过期时间的键空间 | volatile-lru | 优先移除最近未使用的key |
| 设置了过期时间的键空间 | volatile-ttl | ttl值小的key优先移除 |
| 全键空间 | allkeys-random | 随机移除某个key |
| 全键空间 | allkeys-lru | 优先移除最近未使用的key |
Redis常见问题
缓存雪崩
大部分缓存失效，造成数据库崩溃。
解决：
- 使用锁或队列，保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上。
- 为key设置不同的缓存失效时间，在固定的一个缓存时间的基础上 + 随机一个时间作为缓存失效时间。
- 二级缓存，设置一个有时间限制的缓存 + 一个无时间限制的缓存。避免大规模访问数据库。
缓存穿透
查询无数据返回，直接查数据库。
解决：
- 如果查询结果为空，直接设置一个默认值存放到缓存，这样第二次到缓冲中获取就有值了。设置一个不超过5分钟的过期时间，以便能正常更新缓存。
- 设置布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。
缓存预热
系统上线后，将相关需要缓存的数据直接加到缓存系统中。
解决：
- 直接写个缓存刷新页面，上线时手工操作。
- 数据量不大时，可以在项目启动的时候自动进行加载。
- 定时刷新缓存。
布隆过滤器用于快速识别一个元素不在一个集合中，通过一个长二进制向量和一系列随机映射函数来记录与识别某个数据是否在一个集合中。
缓存更新
除Redis系统自带的缓存失效策略，常见采用以下两种：
- 定时清理过期的缓存。
- 当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存。
缓存降级
降级的目的是保证核心服务可用，即使是有损的，而且有些服务是无法降级的（如电商的购物流程等)。
在进行降级之前要对系统进行梳理，从而梳理出哪些必须保护，哪些可降级。
典型例题
例题1
阅读下列说明，回答问题1至问题3，将解答填入答题纸的对应栏内。
【说明】
某企业委托软件公司开发一套包裹信息管理系统，以便于对该企业通过快递收发的包裹信息进行统一管理。在系统设计阶段，需要对不同快递信息的包裹单信息进行建模。其中，邮政包裹如下图所示（截图模糊，请见谅）：
【问题1】
请说明关系型数据库开发中，逻辑数据模型设计过程包含哪些任务？该包裹单的逻辑数据模型中应该包含哪些实体?并指出每个关系模式的主键属性。
参考答案：
逻辑数据模型设计过程包含的任务：
（1）构建系统上下文数据模型，包含实体及实体之间的联系。
（2）绘制基于主键的数据模型，为每个实体添加主键属性。
（3）构建全属性数据模型，为每个实体添加非主键属性。
（4）利用规范化技术建立系统规范化数据模型。
包裹单的逻辑数据模型中包含的实体：
（1）收件人(主键：电话)
（2）寄件人(主键：电话)
（3）包裹单(主键：编号)
【问题2】
请说明什么是超类实体？结合图中包裹单信息，试设计一种超类实体，给出完整的属性列表。
参考答案：
超类实体是将多个实体中相同的属性组合起来构造出的新实体。
用户（姓名、电话、单位名称、详细地址）
【问题3】
请说明什么是派生属性？结合上图中包裹单信息说明哪个属性是派生属性。
参考答案：
派生属性是指某个实体的非主键属性由该实体其他非主键属性决定。
包裹单中的总计是由资费、挂号费、保价费、回执费计算得出，所以是派生属性。
例题2
阅读以下关于数据库设计的叙述，在答题纸上回答问题1至问题3。
【说明】
某医药销售企业因业务发展，需要建立线上药品销售系统，为用户提供便捷的互联网药品销售服务。该系统除了常规药品展示、订单、用户交流与反馈功能外，还需要提供当前热销产品排名、评价分类管理等功能。通过对需求的分析，在数据管理上初步决定采用关系数据库（MySQL）和数据库缓存（Redis）的混合架构实现。
经过规范化设计之后，该系统的部分数据库表结构如下所示：
供应商（供应商ID，供应商名称，联系方式，供应商地址）
药品（药品ID，药品名称，药品型号，药品价格，供应商ID）
药品库存（药品ID，当前库存数量）
订单（订单号码，药品ID，供应商ID，药品数量，订单金额）
【问题1】
在系统初步运行后，发现系统数据访问性能较差。经过分析，刘工认为原来数据库规范化设计后，关系表过于细分，造成了大量的多表关联查询，影响了性能。例如当用户查询商品信息时，需要同时显示该药品的信息、供应商的信息、当前库存等信息。为此，刘工认为可以采用反规范化设计来改造药品关系的结构，以提高查询性能。
修改后的药品关系结构为：
药品（药品ID，药品名称，药品型号，药品价格，供应商ID，供应商名称，当前库存数量）
请用200字以内的文字说明常见的反规范化设计方法，并说明用户查询商品信息应该采用哪种反规范化设计方法。
参考答案：
常见的反规范化技术包括：
（1）增加冗余列：增加冗余列是指在多个表中具有相同的列，它常用来在查询时避免连接操作。
（2）增加派生列：增加派生列指增加的列可以通过表中其他数据计算生成。它的作用是在查询时减少计算量，从而加快查询速度。
（3）重新组表：重新组表指如果许多用户需要查看两个表连接出来的结果数据，则把这两个表重新组成一个表来减少连接而提高性能。
（4）分割表：有时对表作分割可以提高性能。
题目描述中：
用户查询商品信息应该采用：增加冗余列。
用户查询商品信息时，需要显示药品信息（药品表），供应商信息（供应商表），库存信息（库存表），此时查询的是药品表，但表中缺了供应商的信息和库存信息，可以通过增加冗余列的方式把这些信息并过来。以避免连接操作带来的查询性能下降。
【问题2】
王工认为，反规范化设计可提高查询的性能，但必然会带来数据的不一致性问题。请用200字以内的文字说明在反规范化设计中，解决数据不一致性问题的三种常见方法，并说明该系统应该采用哪种方法。
参考答案：
针对反规范化数据不一致问题，可采用的解决方案包括：
（1）触发器数据同步。
（2）应用程序数据同步。
（3）物化视图。
（4）批处理同步。
本系统应该采用触发器数据同步方式。
【问题3】
该系统采用了Redis 来实现某些特定功能（如当前热销药品排名等），同时将药品关系数据放到内存以提高商品查询的性能，但必然会造成Redis和MySQL的数据实时同步问题。
1）Redis的数据类型包括String、Hash、List、Set和ZSet 等，请说明实现当前热销药品排名的功能应该选择使用哪种数据类型。
2）请用200字以内的文字解释说明解决Redis和MySQL数据实时同步问题的常见方案。
参考答案：
1）
热销药品排名适合用：ZSet，即有序集合类型。
2）
①实时同步方案，先查缓存，查不到再从DB 查询，并保存到缓存；更新缓存时先 更新数据库，再将缓存设置过期。
②异步队列方式同步，可采用消息中间件处理。
③通过数据库插件完成数据同步。
④利用触发器进行缓存同步。
例题3
阅读以下关于数据库设计的叙述，在答题纸上回答问题1至问题3。
【说明】
某软件企业开发一套类似于淘宝网上商城业务的电子商务网站。该系统涉及多种用户角色，包括购物用户，商铺管理员，系统管理员等。
在数据库设计中，该系统数据库的核心关系包括：
产品（产品编码，产品名称，产品价格，库存数量，商铺编码）
商铺（商铺编码，商铺名称，商铺地址，商铺邮箱，服务电话）
用户（用户编码，用户名称，用户地址，联系电话）
订单（订单编码，订单日期，用户编码，商铺编码，产品编码,产品数量,订单总价）
不同用户角色也有不同的数据需求，为此该软件企业在基本数据库关系模式的基础上，定制了许多视图。其中，有很多视图涉及到多表关联和聚集函数运算。
【问题1】
商铺用户需要实时统计本商铺的货物数量和销售情况，以便及时补货，或者为商铺调整销售策略。为此专门设计了可实时查看当天商铺中货物销售情况和存货情况的视图，商铺产品销售情况日报表（商铺编码，产品编码，日销售产品数量，库存数量，日期）。
数据库运行测试过程中，发现针对该视图查询性能比较差，不满足用户需求。 请说明数据库视图的基木概念及其优点，并说明本视图设计导致查询性能较差的原因。
参考答案：
视图是一个虚拟表，并不在数据库中以存储的数据值集形式存在。行和列数据来自由定义视图的查询所引用的表， 并且在引用视图时动态生成。
视图优点如下：
- 视点集中，视图只展示与用户相关的数据。
- 简化操作，在每一次执行相同的查询时，不必重新写查询语句，只要一条简单的查询视图语句即可。可见视图向用户隐藏了表与表之间的复杂的连接操作。
- 定制数据，视图能够实现让不同的用户以不同的方式看到不同或相同的数据集。
- 合并分割数据，在有些情况下，由于表中数据量太大，故在表的设计时常将表进行水平分割或垂直分割，但表的结构的变化却对应用程序产生不良的影响。如果使用视图就可以重新保持原有的结构关系，从而使外模式保持不变，原有的应用程序仍可以通过视图来重载数据。
- 安全性，视图可以作为一种安全机制。通过视图用户只能查看和修改他们所能看到的数据。其它数据库或表既不可见也不可以访问。如果某一用户想要访问视图的结果集，必须授予其访问权限。视图所引用表的访问权限与视图权限的设置互不影响。
查询性能较差的原因是视图中"日销售产品数量"需要针对订单表作统计分析，订单表中有数量庞大的历史销售记录，所以这种操作极为耗时。
【问题2】
为解决该枧图查询性能比较差的问题，张工建议为该数据建立单独的商品当天货物销售、存货情况的关系表。但李工认为张工的方案造成了数据不一致的问题，必须采用一定的手段来解决。
1）说明张工方案是否能够对该视图查询性能有所提升，并解释原因。
2）解释说明李工指出的数据不一致问题产生的原因。
参考答案：
1）张工方案能够对该视图查询性能有所提升，因为这样做能极大的减少统计分析的数据量，对小数据量进行统计，性能是能得以保障的。
2）由于当日订单数据既存储在订单表中，又存储在单独的当天货物销售、存货情况表中。同一数据存储了两份， 一旦出现修改，未同步修改，则会造成数据不一致。
【问题3】
针对李工提出的问题，常见的解决手段有应用程序实现，触发器实现和物化视图实现等、 请用300字以内的文字解释说明这三种方案。
参考答案：
（1）程序实现。在订单的增删改操作时，对两张表的都进行相关操作。
（2）触发器实现。如订单发生变化时，通过触发器把当日订单同步到每日货物统计表中。
（3）物化视图。建立"当日销售、存货"物化视图，通过物化视图把相关联的数据关联起来，当订单发生变化时，自动更新，保证数据一致性。
例题4
阅读以下关于系统数据分析与建模的叙述，在答题纸上回答问题1至问题3。
【说明】
某软件公司受快递公司委托，拟开发一套快递业务综合管理系统，实现快递单和物流信息的综合管理。项目组在系统逻辑数据模型设计中，需要描述的快递单样式如下图所示。
下图中是项目组针对该快递单所设计的候选实体及其属性。
【问题1】
数据库设计主要包括概念设计、逻辑设计和物理设计三个阶段，请用200字以内文字说明这三个阶段的主要任务。
参考答案：
（1）概念设计也称为概念结构设计，其任务是在需求分析阶段产生的需求说明书的基础上，按照特定的方法将它
们抽象为一个不依赖于任何DBMS的数据模型，即概念模型。概念模型的表现形式即ER模型。
（2）逻辑设计也称为逻辑结构设计，其主要任务是将概念模型转换为某个特定的DBMS上的逻辑模型。
（3）物理设计也称为物理结构设计，其任务是对给定的逻辑模型选取一个最适合应用环境的物理结构。所谓数据
库的物理结构，主要是指数据库在物理设备上的存储结构和存取方法。
【问题2】
根据快递单样式图，请说明：
1）上图中三个候选实体对应的主属性PK1、PK2和PK3分别是什么？
2）上图中应设计哪些实体之间的联系，并说明联系的类型。
参考答案：
1）
PK1：证件号或联系电话；PK2：编号；PK3：证件号或联系电话。
2）
联系1：寄件人与快递单之间应有联系，联系类型：1:N。或快递单与寄件人之间应有联系，联系类型：N:1。
联系2：收件人与快递单之间应有联系，联系类型：1:N。或快递单与收件人之间应有联系，联系类型：N:1。
【问题3】
在上图中添加实体之间的联系后，该实体联系图是否满足第一范式、第二范式和第三范式中的要求（对于每种范式判定时，假定已满足低级别范式要求）。如果不满足，请用200字以内文字分别说明其原因。
参考答案：
快递单不满足第三范式。因为总计可由前边的保价金额、代收货款、运费、加急费、包装费、保价费等计算得出， 存在传递函数依赖。
例题5
阅读下列说明，回答问题1至问题3，将解答填入答题纸的对应栏内。
【说明】
某集团公司在各省均设有分公司，现欲建立全国统一的销售管理信息系统，以便总公司及时掌握各分公司的销售情况。公司成立专门的项目组进行该系统的研发工作，其中张工负责其中的数据库设计工作。
张工和需求分析小组紧密合作，在设计出数据流图和数据字典的基础上，给出了数据库关系模式和相应的索引设计。同时考虑到未规范化关系模式可能引起的各类数据错误，对关系模式进行了全面的规范化处理,使所有关系模式均达到了3NF或BCNF。
在项目实施过程中，应用开发小组认为该设计方案未考虑应用功能的实际需求。如果严格按照设计方案实施，会对应用系统中整体性能产生较大影响。主要的原因在于进行数据查询时，会产生大量的多表连接操作，影响性能。而设计方案中的索引设计，并不能完全满足数据查询的性能要求。
应用开发小组还认为，该设计方案未考虑到信息系统中核心销售数据处理的特点:各分公司在使用该信息系统时只能操作自己分公司的销售数据，无权操作其它分公司的销售数据;只有总公司有权利操作所有销售数据,以便进行统计分析。
应用开发小组要求，在数据库设计方案中，必须针对实际应用功能的实现来考虑关系模式的规范化，必要时需要采用逆规范化或解除规范化的方法来保证性能要求。
【问题1】
系统需要管理供应商和货物等信息，具体包括供应商姓名、地址以及货物名称、价格等，供应商可以提供0~n种货物，其公司地址也可能发生变化。请以供应商关系模式supplier（name，address，product，price）为例，解释不规范的关系模式存在哪些问题。
参考答案：
（1）数据冗余，关系模式中多次重复记录了同一供应商的地址。
（2）插入异常，如果还未确定一个供应商有哪些货物，只是想添加一个供应商的地址信息,则会产生产品与价格均为空的记录。
（3）修改异常，当修改一个供应商的地址时，需要将多条记录同时更新，若未同时更新,则数据产生不一致。
（4）删除异常，当删除一个供应商的货物时，其地址信息被一并删除。
【问题2】
应用开发小组认为张工的规范化设计虽然解决了未规范化关系模式带来的问题，但实际实现功能时会造成系统性能的下降,请解释其原因。
参考答案：
数据库规范化的过程，实际是对数据表的不断拆分，以达到更高的规范程度。这样处理，带来的问题是：系统中大量查询不能通过单表完成，而需要将多表进行连接查询，所以表拆分得越多，查询性能也就越差。
【问题3】
请解释逆规范化方法，说明其优缺点。
参考答案：
规范化设计后，数据库设计者希望牺牲部分规范化来提高性能，这种从规范化设计的回退方法称为反规范化技术。
逆规范化方法优点：提高统计、查询效率。
逆规范化方法缺点：增加了数据冗余，浪费存储空间，增、删、改操作的效率降低，可能导致数据不一致，可能产生添加、修改、删除异常。
【问题4】
针对该信息系统中核心销售数据处理的特点，如采用关系表水平分割的逆规范化方法，请给出具体的解决方案，并说明该方案存在的问题。
参考答案：
解决方案：将各省的数据存放于各省分公司。
该方案主要问题：
（1）在于总公司进行全国数据统计时，需要从各省服务器调取数据，效率较低。
（2）执行应用功能时需要动态选择分公司的数据库表，增加了应用程序的复杂度。
例题6
阅读以下关于数据库分析与建模的叙述，在答题纸上回答问题1至问题3。
【说明】
某电子商务企业随着业务不断发展，销售订单不断增加，每月订单超过了50万笔，急需开发一套新的互联网电子订单系统。同时该电商希望建立相应的数据中心，能够对订单数据进行分析挖掘，以便更好地服务用户。
王工负责订单系统的数据库设计与开发，初步设计的核心订单关系模式为：orders（order_no，customer_no，order_date，product_no，price，......）。
考虑订单数据过多，单一表的设计会对系统性能产生较大影响，仅仅采用索引不足以解决性能问题。因此，需要将订单表拆分，按月存储。
王工采用反规范化设计方法来解决，给出了相应的解决方案。李工负责数据中心的设计与开发。李工认为王工的解决方案存在问题，建议采用数据物理分区技术。在解决性能问题的同时，也为后续的数据迁移、数据挖掘和分析等工作提供支持。
【问题1】
常见的反规范化设计包括增加冗余列、增加派生列、重新组表和表分割。为解决题干所述需求，王工采用的是哪种方法？请用300字以内的文字解释说明该方法，并指出其优缺点。
参考答案：
王工采用的是表分割方式中的水平分割（分割参数是："月"，不同的月份使用不同的关系表）。
表分割包括水平分割与垂直分割两种形式：
水平分割：按记录进行分割，不同的记录可以分开保存，每个子表的列数相同。分割的条件可能是某列或多
列数据的值，如时间参数。
垂直分割：按进行分割，即把一条记录分开多个地方保存，每个子表的行数相同。把主键和一些行放到一个
表，然后把主键和另外的列放到另一个表中，通过主键进行关联。
王工采用水平分割的优点：水平分割后可以降低在查询时需要读取的数据和索引页数，同时也降低了索引的层数，
提高查询速度。同时，按月存储有利于数据迁移、备份和管理。
缺点：逻辑上破坏了关系概念的完整性，由一个关系变为多个关系，在进行历史数据挖掘和分析时，需要执行集
合并操作，处理起来比单表操作更加复杂。
【问题2】
物理数据分区技术一般分为水平分区和垂直分区，数据库中常见的是水平分区。水平分区分为范围分区、哈希分区、列表分区等。请阅读下表，在（1）～（8）中填写不同分区方法在数据值、数据管理能力、实施难度与可维护性、数据分布等方面的特点。
参考答案：
（1）连续 （2）离散 （3）弱 （4）强 （5）不好 （6）不好 （7）不均匀 （8）均匀
【问题3】
根据需求，李工宜选择物理水平分区中的哪种分区方法？请用300字以内的文字分别解释说明该方法的优缺点。
参考答案：
李工宜选择范围分区方式。
范围分区优点如下：
（1） 分区表可以将表存储到多个表空间内，各个分区维护各自的本地索引，查询语句可以根据索引进行
分区范围查找，提高了查询速度。
（2） 范围分区提供良好的数据迁移、备份和管理能力，利于维护。
（3） 实现容易，而且可以方便地对表的分区进行添加、删除、拆分和合并操作。
范围分区缺点：
（1）随着时间的增加，日期数据发生变化，DBA需要对分区进行维护，以增加新的分区。数
（2） 据在分区上不均匀。可维护性上比较差，所以可以与哈希分区组合应用。
例题7
阅读以下关于数据管理的叙述，在答题纸上回答问题1至问题3。
【说明】
某全国连锁药店企业在新冠肺炎疫情期间，紧急推出在线口罩预约业务系统。该业务系统为普通用户提供口罩商品查询、购买、订单查询等业务，为后台管理人员提供订单查询、订单地点分布汇总、物流调度等功能。该系统核心的关系模式为预约订单信息表。
推出业务系统后，几天内业务迅速增长到每日10万多笔预约订单，系统数据库服务器压力剧增，导致该业务交易响应速度迅速降低，甚至出现部分用户页面无法刷新、预约订单服务无响应的情况。为此，该企业紧急成立技术团队，由张工负责，以期尽快解决该问题。
【问题1】
经过分析，张工认为当前预约订单信息表存储了所有订单信息，记录已达到了百万级别。系统主要的核心功能均涉及对订单信息表的操作，应首先优化预约订单信息表的读写性能，建议针对系统中的SQL语句，建立相应索引，并进行适当的索引优化。
针对张工的方案，其他设计人员提出了一些异议，认为索引过多有很多副作用。请用100字以内的文字简要说明索引过多的副作用。
参考答案：
索引过多的副作用有：
（1）过多的索引会占用大量的存储空间。
（2）更新开销，更新语句会引起相应的索引更新。
（3）过多索引会导致查询优化器需要评估的组合增多。
（4）每个索引都有对应的统计信息,索引越多则需要的统计信息越多。
（5）聚集索引的变化会导致非聚集索引的同步变化。
【问题2】
作为团队成员之一，李工认为增加索引并进行优化并不能解决当前问题，建议采用物理分区策略，可以根据预约订单信息表中"所在城市"属性进行表分区，并将每个分区分布到独立的物理磁盘上，以提高读写性能。常见的物理分区特征如下表所示。李工建议选择物理分区中的列表分区模式。
请填补下表中的空（a）~（d）)处，并用100字以内的文字解释说明李工选择该方案的原因。
参考答案：
（a）属性的离散值 （b）周期性数据/周期数据 （c）能力强 （d）均匀
李工建议根据预约订单所在城市进行表分区，而所在城市属性为离散值，根据所在城市属性建立列表分区，也方便不同城市处理自己的数据，方便数据管理。
【问题3】
在系统运行过程中，李工发现后台管理人员执行的订单地址信息汇总等操作，经常出现与普通用户的预约订单操作形成读写冲突，影响系统的性能。因此李工建议采用读写分离模式，采用两台数据库服务器，并采用主从复制的方式进行数据同步。请用100字以内的文字简要说明主从复制的基本步骤。
参考答案：
主从复制的基本步骤：
（1）主服务器将所做修改通过自己的I/O线程，保存在本地二进制日志中。
（2）从服务器上的I/O线程读取主服务器上面的二进制日志，然后写入从服务器本地的中继日志。
（3）从服务器上同时开启一个SQL thread，定时检查中继日志，如果发现有更新则立即把更新的内容在本机的数据库上面执行一遍。
例题8
阅读以下关于数据管理的叙述，在答题纸上回答问题1至问题3。
【说明】
某软件企业开发了一套新闻社交类软件，提供常见的新闻发布、用户关注、用户推荐、新闻点评、新闻推荐、热点新闻等功能，项目采用MySQL数据库来存储业务数据。系统上线后，随着用户数量的增加,数据库服务器的压力不断加大。为此，该企业设立了专门的工作组来解决此问题。
张工提出对MySQL数据库进行扩展，采用读写分离，主从复制的策略，好处是程序改动比较小，可以较快完成，后续也可以扩展到MySQL集群，其方案如下图所示。
李工认为该系统的诸多功能，并不需要采用关系数据库，甚至关系数据库限制了功能的实现，应该采用NoSQL数据库来替代MySQL，重新构造系统的数据层。
而刘工认为张工的方案过于保守，对该系统的某些功能，如关注列表、推荐列表、热搜榜单等实现困难，且性能提升不大；而李工的方案又太激进，工作量太大，短期无法完成，应尽量综合二者的优点，采用Key-Value数据库 + MySQL数据库的混合方案。
经过组内多次讨论,该企业最终决定采用刘工提出的方案。
【问题1】
张工方案中采用了读写分离，主从复制策略。其中，读写分离设置物理上不同的主/从服务器，让主服务器负责数据的（a）操作，从服务器负责数据的（b）操作，从而有效减少数据并发操作的（c），但却带来了（d）。因此，需要采用主从复制策略保持数据的（e）。
MySQL数据库中，主从复制是通过binary log来实现主从服务器的数据同步，MySQL数据库支持的三种复制类型分别是（f）、（g）、（h）。
请将答案填入（a）~（h）处的空白，完成上述描述。
参考答案：
（a）写 （b）读 （c）锁争用 （d）数据冗余 （e）一致性
（f）基于SQL语句的复制（statement-based replication，SBR）
（g）基于行的复制（row-based replication，RBR）
（h）混合模式复制（mixed-based replication，MBR）
【问题2】
李工方案中给出了关系数据库与NoSQL数据的比较，如下表所示，以此来说明该新闻社交类软件更适合采用NoSQL数据库。请完成下表中的（a）~（d）处空白。
参考答案：
（a）最终一致性 （b）非结构化数据 （c）低事务性/弱事务性 （d）海量数据
【问题3】
刘工提出的方案采用了Key-Value数据库 + MySQL数据库的混合方案，是根据数据的读写特点将数据分别部署到不同的数据库中。但是由于部分数据可能同时存在于两个数据库中，因此存在数据同步问题。请用200字以内的文字简要说明解决该数据同步问题的三种以上方法。
参考答案：
（1）实时同步方案，先查缓存，查不到再从DB查询，并保存到缓存；更新缓存时先更新数据库，再将缓存设置过程期更新缓存。
（2）异步队列方式同步，可采用消息中间件处理。
（3）通过数据库插件完成数据同步。
（4）利用触发器进行缓存同步。
例题9
阅读以下关于Web系统架构设计的叙述，在答题纸上回答问题1至问题3。
【说明】
某公司开发的B2C商务平台因业务扩展，导致系统访问量不断增大，现有系统访问速度缓慢，有时甚至出现系统故障瘫痪等现象。面对这一情况，公司召开项目组讨论会议，寻求该商务平台的改进方案。讨论会上，王工提出可以利用镜像站点、CDN内容分发等方式解决并发访问量带来的问题。而李工认为，仅仅依靠上述外网加速技术不能完全解决系统现有问题，如果访问量持续增加，系统仍存在崩溃的可能。 李工提出应同时结合Web内网加速技术优化系统改进方案，如综合应用负载均衡、缓存服务器、Web应用服务器、分布式文件系统、分布式数据库等。经过讨论，公司最终决定采用李工的思路，完成改进系统的设计方案。
【问题1】
针对李工提出的改进方案，从a～j中分别选出各技术的相关描述和对应常见支持软件填入下表中的（1）~（10）处。
a）保存静态文件，减少网络交换量，加速响应请求
b）可采用软件级和硬件级负载均衡实现分流和后台减压
c）文件存储系统，快速查找文件
d）FastDFS
e）HAProxy
f）JBoss
g）Hadoop Distributed File System(HDFS)
h）Apache Tomact
i）Squid
j）MongoDB
参考答案：
（1）b （2）e （3）a （4）i （5）c
（6）d （7）g （8）f （9）h （10）j
【问题2】
请用100字以内的文字解释分布式数据库的概念，并给出提高分布式数据库系统性能的3种常见实现技术。
参考答案：
分布式数据库是由一组数据组成的，这组数据分布在计算机网络的不同计算机上，网络中的每个节点具有独立处理的能力（称为场地自治），它可以执行局部应用，同时，每个节点也能通过网络通信子系统执行全局应用。
（1）采用数据分片技术，提高访问的局部性，提升系统性能。
（2）采用查询优化技术（包括：全局查询树的变换、副本的选择与多副本的更新策略、查询树的分解、半连接与直接连接） 提高查询速度。
（3）读写分离技术。
（4）负载均衡技术。
（5）分布式缓存技术
【问题3】
针对B2C商务购物平台的数据浏览操作远远高于数据更新操作的特点，指出该系统应采用的分布式数据库实现方式，并分析原因。
参考答案：
可以采用一主多从的主从复制技术进行读写分离。
在本题所涉及到的环境中，浏览操作远远高于数据更新操作，可以在分布式数据库中采用主从复制技术实现读写分离。主数据库负责写操作，从数据库进行读操作，在大数据量访问数据库时，能很大程度上提升性能。
例题10
阅读以下关于分布式数据库缓存设计的叙述，在答题纸上回答问题1至问题3。
【说明】
某企业是为城市高端用户提供高品质蔬菜生鲜服务的初创企业，创业初期为快速开展业务，该企业采用轻量型的开发架构（脚本语言+关系型数据库）研制了一套业务系统。业务开展后受到用户普遍欢迎，用户数和业务数量迅速增长，原有的数据库服务器已不能满足高度并发的业务要求。为此，该企业成立了专门的研发团队来解决该问题。
张工建议重新开发整个系统，采用新的服务器和数据架构，解决当前问题的同时为日后的扩展提供支持。但是，李工认为张工的方案开发周期过长，投入过大，当前应该在改动尽量小的前提下解决该问题。李工认为访问量很大的只是部分数据，建议采用缓存工具MemCache来减轻数据库服务器的压力，这样开发量小，开发周期短，比较适合初创公司，同时将来也可以通过集群进行扩展。然而，刘工又认为李工的方案中存在数据可靠性和一致性问题，在宕机时容易丢失交易数据，建议采用Redis来解决问题。经过充分讨论，该公司最终决定采用刘工的方案。
【问题1】
在李工和刘工的方案中，均采用分布式数据库缓存技术来解决问题。请说明分布式数据库缓存的基本概念。下表中对MemCache和Redis两种工具的优缺点进行了比较，请补充完善表中的空（1）～（6）。
参考答案：
分布式数据库缓存指的是在高并发环境下，为了减轻数据库压力和提高系统响应时间，在数据库系统和应用系统之间增加的独立缓存系统。
（1）丰富/多种数据结构
（2）不支持
（3）客户端哈希分片/一致性哈希
（4）不支持
（5）有，私有内存池
（6）不支持
【问题2】
刘工认为李工的方案存在数据可靠性和一致性的问题，请说明原因。
为避免数据可靠性和一致性的问题，刘工的方案采用Redis作为数据库缓存，请说明基本的Redis与原有关系数据库的数据同步方案。
参考答案：
（1）Memcache没有持久化功能，所以掉电数据会全部丢失，而且无法直接恢复，这存在可靠性问题。
（2）Memcache不支持事务，所以操作过程中可能产生数据的不一致性。
同步方案：
读取数据时，先读取Redis中的数据，如果Redis没有，则从原数据库中读取，并同步更新Redis中的数据。写回时，写入到原数据库中，并同步更新至Redis中。
【问题3】
请给出Redis分布式存储的2种常见方案和Redis集群切片的几种常见方式。
参考答案：
Redis分布式存储的常见方案：
主从模式（Master/Slave），哨兵模式（Sentinel），集群模式（Cluster）
Redis集群切片的常见方式：
（1）客户端分片（2）中间件实现分片（3）客户端服务端协作分片
例题11
阅读以下关于数据库设计的叙述，在答题纸上回答问题1至问题3。
【说明】
某航空公司要开发一个订票信息处理系统，以方便各个代理商销售机票。开发小组经过设计，给出该系统的部分关系模式如下：
航班（航班编号，航空公司，起飞地，起飞时间，目的地，到达时间，剩余票数，票价）
代理商（代理商编号，代理商名称，客服电话，地址，负责人）
机票代理（代理商编号，航班编号，票价）
旅客（身份证号，姓名，性别，出生日期，电话）
购票（购票单号，身份证号，航班编号，搭乘日期，购票金额）
在提供给用户的界面上，其核心功能是当用户查询某航班时，将该航班所有的代理商信息及其优惠票价信息，返回给用户，方便用户购买价格优惠的机票。在实现过程中发现，要实现此功能，需要在代理商和机票代理两个关系模式上进行连接操作，性能很差。为此开发小组将机票代理关系模式进行了扩充，结果为：
机票代理（代理商编号，航班编号，代理商名称，客服电话，票价）
这样，用户在查找信息时只需对机票代理关系模式进行查询即可，提高了查询效率。
【问题1】
机票代理关系模式的修改，满足了用户对代理商机票价格查询的需求，提高了查询效率。但这种修改导致机票代理关系模式不满足3NF，会带来存储异常的问题。
1）请具体说明其问题，并举例说明。
2）这种存储异常会造成数据不一致，请给出解决该存储异常的方案。
参考答案：
不满足3NF会产生函数的传递依赖，造成数据冗余和修改异常等问题。
① 数据冗余，一个代理商会代理多家航班的机票销售业务，在机票代理模式中，该代理商的代理商名称，客服电话就会被存储多次，造成数据的冗余。
② 修改异常，当需要修改该代理商的名称或客服电话时，就要修改所有相应元组中的名称或客服电话，否则就会出现客服电话值不一致的现象，产生修改异常。
【问题2】
在机票销售信息处理系统中，两个代理商的售票并发执行，可能产生的操作序列如下表所示。
假设两个代理商执行之前，该航班仅剩1张机票。
1）请说明上述两个代理商操作的结果。
2）并发操作会带来数据不一致的问题，请具体说明3种问题。
参考答案：
1）2个代理商都成功售出1张票，剩余票数为0。
2）数据库的并发操作会带来一些数据不一致问题。例如，丢失修改、读脏数据和不可重复读等。
① 丢失修改。事务A与事务B从数据库中读入同一数据并修改，事务B的提交结果破坏了事务A提交的结果，导致事务A的修改被丢失。
② 读脏数据。事务A修改某一数据，并将其写回磁盘，事务B读取同一数据后，事务A由于某种原因被撤消，从而导致事务B读到的数据是无效数据。
③ 不可重复读。事务A读取数据后，事务B又修改了该数据，但事务A使用的仍是修改之前的值。因此。事务A与实务B分别得到不同的结果，产生了数据的不一致性。
【问题3】
为了避免问题2中的问题，开发组使用库的读写锁机制，操作序列变为下表所示。
参考答案：
（1）加写锁
（2）加读锁
（3）加写锁
（4）等待
（5）查询剩余票数
（6）加写锁