软考-系统架构设计师-第八章 数据库设计基础知识

[复制链接]
发表于 2025-7-9 04:57:31 | 显示全部楼层 |阅读模式

8.1 数据库基础概念


  • 数据模子
    数据模子三要素:数据结构、数据操作、数据的约束条件。其中数据的约束条件包括:实体完整性、参照完整性、用户自定义完整性。
  • 数据库三级模式两级映像
    数据库一样寻常采用三级模式,体系结构如下图,系统开发人员需要通过视图层、逻辑层和物理层上个层次上的抽象来降低用户屏蔽系统的复杂性,简化用户与
    系统的交互。从数据库管理系统的角度,数据库也分为外模式、概念模式和内模式。

    数据库系统子三级模式之间提供了两级映像:概念模式/内模式映像、外模式/概念模式映像。这两级映像保证了数据库中的数据具有较高的
    逻辑独立性
    物理独立性
数据库的三级模式:
概念模式外模式内模式是数据库中全体数据的逻辑结构和特征的形貌,是所有效户的公共数据视图又叫子模式或用户模式,用户根据外模式用数据操作语句或应用程序去操作数据库中的数据是数据物理结构和存储方式的形貌,用以形貌用户看到或正在使用的那部分数据的逻辑结构,是数据在数据库内部的表现方式,定义所有的内部记录类型、索引和文件的组织方式等 。数据库的两级映像
逻辑独立性物理独立性对应外模式和概念模式之间的映像。指应用程序与数据库中的逻辑结构独立,当数据的逻辑结构改变时,应用程序不变对应概念模式和内模式之间的映像,
指应用程序与磁盘中的数据互向独立,当数据的物理结构改变时,应用程序不变8.2关系数据库


  • 属性(Attribute)
  • 域(Domain)
  • 目或度(Degree)
  • 候选码(Candidate Key)
  • 主码(Primary Key)
  • 主属性(Primary Attribute)
  • 外码(Foreign Key)
  • 全码(All-key)
关系代数
π 投影 选择对应的列表
σ 选择 获取符合条件的行

  • 关系数据库设计的基本理论



    • 函数依赖:


    • 非平凡的函数依赖


    • 平凡的函数依赖


    • 完全函数依赖


    • 部分函数依赖


    • 传递依赖


  • 关系数据库的规范化



    • 第一范式:列不可再分


    • 第二范式:不存在非主属性的完全依赖


    • 第三范式:不存在非主属性的传递依赖


    • BCNF:不存在主属性的传递依赖和完全依赖


  • 事务管理
    原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)
8.3 数据库设计


  • 数据库设计的基本步骤。可以分为用户需求分析、概念结构设计、逻辑结构设计、物理结构设计、应用程序设计、运行维护。
  • 数据需求分析
  • 概念结构设计。概念数据模子又称为实体-接洽模子,它按照用户的观点来对数据和信息建模,主要用于数据库设计,概念结构设计的工作步骤包括:选择局部应用、
    逐一设计分ER图和ER图合并。 在进行ER图合并时,需要解决属性冲突、定名冲突和结构冲突。ER图三要素:实体、属性、实体之间的接洽。
  • 逻辑结构设计。主要步骤包括确定命据模子、将ER图转化为指定的数据模子、确定完整性约束和确定用户视图。
  • 物理设计。主要步骤确定命据分布、存储结构和访问方式
  • 数据库实施。根据逻辑和物理设计的效果,在盘算机上建立现实的数据库结构,数据加载(装入),进行试运行和评价。
  • 数据库运行维护。主要包括对数据库性能的监测和改善、故障恢复、数据库的重组和重构。在数据库运行阶段,对数据库的维护主要由DBA完成。
  • 商业智能(Business Intelligence ,BI)是企业对商业数据的搜集、管理和分析的系统过程,目的是使企业的各级决议者得到知识或洞察力,帮助他们作出
    对企业更有利的决议。一样寻常认为数据堆栈、联机分析处理(OLAP)和数据发掘是商业智能的三大组成部分。
  • 数据堆栈(Data Warehouse)是一个面向主题的、集成的、相对稳定且随时间变化的数据集合,用于支持管理决议。
    数据堆栈的关键特征是:面向主题、集成的、非易失的、时变的、
传统数据库和数据堆栈的比较
比较项目传统数据库数据堆栈数据内容当前值汗青的、归档的、归纳的、盘算的数据(处理过的)数据目的面向业务操作程序 、重复操作面向主题域,分析应用数据特性动态变化、 更新静态、不能直接更新,只能定时添加,更新数据结构高度结构化、复杂、得当操作盘算简朴、得当分析使用频率高低数据访问量每个事务只访问少量记录每个事务访问大量记录对相应时间要求计时单元小 如秒计时单元大 ,秒、分钟 、小时OLTP和OLAP的区别
项目OLTPOLAP用户操作人员、低层管理人员决议人员、高级管理人员功能一样寻常操作处理分析决议DB设计面向应用面向主题数据当前的、最新的、细节的、二维的、分立的汗青的、聚集的、多维的、集成的、 同一的存取读/写数十条记录读上百万条记录工作单元简朴的事务复杂的查询用户数上千个上百个DB大小100MB甚至GB级别100GB甚至TB级别

  • 数据发掘。数据发掘是在没有明确的假设的条件下去发掘信息、发现知识。数据发掘所得到的信息应具有先知、有效和实用三个特征。
8.4 应用程序与数据库交互

NoSQL数据库


  • 分类和特点
    NoSQL数据库按照所使用的数据结构的类型,可以分为列式存储数据库、键值对存储数据库、文档型数据库、图数据库。
    NoSQL特征:易扩展、大数据量、高性能、机动的数据模子、高可用。
  • 体系结构
    NoSQL整体框架由下至上分为数据持久层(Data Persistence)、数据分布层(Data Distribution Model)、数据逻辑层(Data Logic
    Model) 和接口层(Interface)。
    NoSQL数据库实用情况:数据模子比较简朴、需要机动性更强的IT系统、对数据库性能要求较高、不需要高度的数据一致性。
8.6 分布式数据库


  • 体系结构




    • 全局视图:(全局外模式)是全局应用的用户视图,是全局概念模式的子集,该层直接与用户(或应用程序)交互。


    • 全局概念模式:全局概念模式定义分布式数据库中数据的整体逻辑结构,数据就如同没有分布意义,可用传统的集中式数据库中所采用的方法进行定义。


    • 分片模式:将一个关系模式分解为几个数据片


    • 分配模式:分布式数据库的本质特性就是数据分布在不同的物理位置。分配模式的主要职责是定义数据片段(即分片模式的处理效果)的存放节点。


    • 局部概念模式:局部概念模式是局部数据库的概念模式。


    • 局部内模式:就是局部数据库的内模式


  • 特点



    • 共享性:不同节点的数据共享


    • 自治性:每个节点对本地数据都能独立管理


    • 可用性:某一园地故障时,可以使用其他园地上的副本而不至于使整个系统瘫痪


    • 分布性: 数据分布在不同园地上存储

8.7 数据库优化技术


  • 集中式数据库优化技术



    • 集中式数据库优化技术
      集中式数据库性能优化最常见的事反规范化设计,主要包括增长冗余列、增长派生列、重新组表、水中分割、垂直分割表
      反规范化设计的主要优点是避免了进行行表之间的连接操作, 从而提高数据操作的性能;缺点还是会造成数据的重复存储,浪费了磁盘空间,会产生数据不一致的标题。
      若要避免数据不一致的标题,可以通过设置触发器、采用事务机制(实用于单体数据库中)、应用保证(实用于异构数据库之间)以及批处理脚本方式。


  • 分布式数据库优化技术
    分布式数据库的性能优化可以采用主从复制、读写分离、分表、分库等技术。



    • 主从复制: 利益做数据的热备。架构的扩展。读写分离。在Mysql数据库中,主从数据库同步的模式有全同步、半同步、异步三种。主从数据库通过binlog进行数据的同步。详细如下图

      基于binlog日记有三种模式:


  • 基于SQL语句的复制:每一条更新语句(insert、update、delete)都会在binlog中,进而同步到从库的relaylog中,被从库的SQL线程取出来,回放执行。
    该模式的优点是binlog的日记量可能会比较少,好比涉及行数一千条数据,同步这一句sql就同步了1000条数据。缺点是同步的SQL内里如果含有绑定本地变量的函数、
    关键,可能造成主从不一致的情况。
  • 基于行的复制:不记录SQL语句,只记录哪个记录更新前和更新后的数据,可以保证主从数据的绝对相同。缺点是:1条SQL更新100条数据,就需要同步100条数据行。
  • 混合复制:以上两种模式的混合,选取两者的优点。对于绑定本地特性、评估可能造成主从不一致的SQL语句,则自动选用基于行的复制,其他的选择基于SQL语句复制。



    • 读写分离:设置不同的主从数据库分别负责不同的操作。让主数据库负责数据的写操作,从数据库负责数据的读操作。通过脚色分担的策略,分别提升读写性能,
      有效减少数据并发操作的耽误。


    • 分表:可以提升数据库并发以及I/O的性能。分表重在单个实例内部,将一个大表分为若干小表,业务内访问多个表。分表有两种方式。垂直切分、水平切分。


    • 分库:分库是将原本存放在一个实例上的浩繁分类的数据表,分开存放到不同的实例上。有利于差异化管理。

8.8 分布式缓存技术Redis

过期策略:
定期删除、惰性删除
镌汰策略:
数据持久化 AOF| RDB
项目RDB内存快照(Redis Data Base)AOF日记(Append Only File)阐明把当前内存中的数据集快照写入到磁盘(数据库中的所有的数据)。恢复时是将快照文件直接读到内存中。通过连续不绝的生存Redis服务器所执行的更新下令来记录数据库的状态。恢复的时候需要从头开始回放更新下令磁盘革新频率低高文件大小小大数据恢复效率高低数据安全低高

  • 缓存穿透: 大量哀求访问了没有缓存的key,即大量key不在redis,从而导致哀求直接访问数据库,数据库压力增大。可能原因:



    • 恶意攻击, 造成大量访问不存在的key。解决方案,1.针对比较少的哀求泉源IP,自动限定其访问次数,大概拉入黑名单。2.应用程序来检查key的合法性,提前
      拒绝不合法哀求。3.使用布隆过滤器


    • 大量哀求访问数据库里有但是Redis内里没有的key。解决方案:1. 预热Redis,运行一个批处理脚本,将可能会大量访问的数据预先加载到Redis。2.在最前端
      进行流量控制,逐步把哀求释放进来。给出一段时间,让Redis逐步加载数据。3.如果是Redis内里也没有的key,也要在Redis设置key,使其值为null或空。


  • 缓存雪崩。大量哀求访问到缓存中的key,这些key是存在的,但同时到了过期时间,从而导致哀求直接访问数据库,数据库压力增大。缓存雪崩可能进而影响一系
    列的雪崩,影响上下游所有的应用服务。可能的原因如下:



    • Redis故障。好比Redis宕机,网络出现抖动等。
      解决方案:1.使用主从复制提高可用性,使用cluster集群方案降低故障的影响范围;2.如果出现故障,则可以采用服务降级、熔断、限流等措施。


    • 大量的key采用了相同的过期时间,比方在同一时刻设置了大量的key,但过期时间都是5分钟。
      解决方案:过期时间加上一个随机值,使浩繁key均匀过期。


  • 缓存击穿。少量热点的key缓存失效了,使得哀求直接访问数据库。
    可能原因:热点key设置了太短的过期时间。比方秒杀业务的库存数量。解决方案:1.将key设置较长的过去时间。对于非常紧张的key则设置永久有效。但需要解决好与数据中key的一致性标题,2.使用分布式锁。如果热点key失效了控制好后段数据库的流量。只允许一个哀求去访问数据库,取出最新的key存放到Redis,其他哀求则必须等待。
  • Redis 集群
    主从复制集群、哨兵集群、Cluster集群。

免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。
继续阅读请点击广告

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

×
回复

使用道具 举报

© 2001-2025 Discuz! Team. Powered by Discuz! X3.5

GMT+8, 2025-7-25 08:14 , Processed in 0.081075 second(s), 30 queries 手机版|qidao123.com技术社区-IT企服评测▪应用市场 ( 浙ICP备20004199 )|网站地图

快速回复 返回顶部 返回列表