版权声明

主要针对希赛出版的架构师考试教程《系统架构设计师教程（第4版）》，作者“希赛教育软考学院”。完成相关的读书笔记以便后期自查，仅供个人学习使用，不得用于任何商业用途。

  • 版权声明
  • 第八节 数据库设计的基本步骤
    • 需求分析

      • 说明
      • 重要性
      • 阶段任务
        • 确认需求、确定设计目标
        • 分析和收集数据
        • 整理文档
    • 概念结构设计
      • 说明
      • 重要性
      • 概念数据模型的作用
      • 概念模型的描述工具
      • 概念结构的设计策略
        • 视图

          • 视图设计
          • 设计步骤
            • 确定局部视图的范围
            • 功能域之间的联系应最少
            • 识别实体及其标识
            • 确定实体间的联系
            • 分配实体及联系的属性
          • 视图集成
            • 冲突的表现和处理策略
      • 逻辑结构设计
        • 逻辑结构设计步骤
        • 逻辑设计介绍基本原则和方法
      • 数据库物理设计
        • 设计者必须了解

第八节 数据库设计的基本步骤

分步设计法遵循自顶向下、逐步求精的原则，将数据库设计过程分解为若干相互独立又相互依存的阶段，每一阶段采用不同的技术与工具，解决不同的问题，从而将问题局部化，减少了局部问题对整体设计的影响。目前，此方法已在数据库设计中得到了广泛应用并获得了较好的效果。

在分步设计法中，通常将数据库的设计分为需求分析、概念结构设计、逻辑结构设计和数据库物理设计 4 个阶段，如图 3-3 所示。

需求分析

说明

需求分析是指收集和分析用户对系统的信息需求和处理需求，得到设计系统所必需的需求信息，建立系统说明文档。其目标是通过调查研究，了解用户的数据要求和处理要求，并按一定格式整理形成需求说明书。需求说明书是需求分析阶段的成果，也是今后设计的依据，它包括数据库所涉及的数据、数据的特征、使用频率和数据量的估计，如数据名、属性及其类型、主关键字属性、保密要求、完整性约束条件、更改要求、使用频率、数据量估计等。这些关于数据的数据称为元数据。在设计大型数据库时，这些数据通常由数据字典来管理。用数据字典管理元数据有利于避免数据的重复或重名，以保持数据的一致性及提供各种统计数据，因而有利于提高数据库设计的质量，同时可以减轻设计者的负担。

重要性

需求分析是数据库设计过程的第一步，是整个数据库设计的依据和基础。需求分析做得不好，会导致整个数据库设计重新返工。需求分析的目标是通过对单位的信息需求及处理要求的调查分析得到设计数据库所必需的数据集及其相互联系，形成需求说明书，作为后面各设计阶段的基础。

阶段任务

确认需求、确定设计目标

数据库设计的第一项工作就是要对系统的整个应用情况进行全面、详细的实地调查，弄清现行系统的组织结构、功能划分、总体工作流程，收集支持系统总的设计目标的基础数据和对这些数据的处理要求，明确用户总的需求目标；通过分析，确定相应的设计目标，即确定数据库应支持的应用功能和应用范围，明确哪些功能由计算机完成或准备让计算机完成，哪些环节由人工完成，以确定应用系统实现的功能。这一阶段收集到的基础数据和一组数据流程图是下一步进行概念设计的基础。

分析和收集数据

这是整个需求分析的核心任务。它包括分析和收集用户的信息需求、处理需求、完整性需求、安全性需求，以及对数据库设计过程有用的其他信息。

信息需求是指在设计目标范围内涉及的所有实体、实体的属性及实体间的联系等数据对象，包括用户在数据处理中的输入/输出数据及这些数据间的联系。在收集中，要收集数据的名称、类型、长度、数据量、对数据的约束及数据间联系的类型等信息。

处理需求是指为了获得所需的信息而对数据加工处理的要求。它主要包括，处理方式是实时还是批处理，各种处理发生的频度、响应时间、优先级别及安全保密要求等。所要收集的其他信息还有企业在管理方式、经营方式等方面可能发生的变化等。

分析和收集数据的过程是数据库设计者对各类管理活动进行深入调查研究的过程，调查对象包括数据管理部门的负责人、各使用部门的负责人及操作员等各类管理人员，通过与各类管理人员相互交流，逐步取得对需求的一致认识。

整理文档

分析和收集得到的数据必须经过筛选整理，并按一定格式和顺序记载保存，经过审核成为正式的需求说明文档，即需求说明书。实际上，需求说明书是在需求分析的过程中逐渐整理形成的，是随着这一过程的不断深入而反复修改与完善的对系统需求分析的全面描述。由用户、领导和专家共同评审，是以后各设计阶段的主要依据。这一步的工作是进行全面的汇总与整理，使之系统化，以形成标准化的统一形式。

概念结构设计

说明

它是数据库设计的第二阶段，其目标是对需求说明书提供的所有数据和处理要求进行抽象与综合处理，按一定的方法构造反映用户环境的数据及其相互联系的概念模型，即用户的数据模型或企业数据模型。这种概念数据模型与 DBMS 无关，是面向现实世界的、极易为用户所理解的数据模型。为保证所设计的概念数据模型能正确、完整地反映用户的数据及其相互关系，便于进行所要求的各种处理，在本阶段设计中可吸收用户参与和评议设计。在进行概念结构设计时，可先设计各个应用的视图（view），即各个应用所看到的数据及其结构，然后再进行视图集成，以形成一个单一的概念数据模型。这样形成的初步数据模型还要经过数据库设计者和用户的审查与修改，最后形成所需的概念数据模型。

重要性

概念结构设计阶段所涉及的信息不依赖于任何实际实现时的环境，即计算机的硬件和软件系统。概念结构设计的目标是产生一个用户易于理解的，反映系统信息需求的整体数据库概念结构。概念结构设计的任务是，在需求分析中产生的需求说明书的基础上按照一定的方法抽象成满足应用需求的用户的信息结构，即通常所称的概念模型。概念结构的设计过程就是正确选择设计策略、设计方法和概念数据模型并加以实施的过程。

概念数据模型的作用

概念数据模型的作用是：提供能够识别和理解系统要求的框架；为数据库提供一个说明性结构，作为设计数据库逻辑结构，即逻辑模型的基础。

概念模型的描述工具

概念模型的描述工具应该能够体现概念模型的特点，如 E-R 模型。近年来，由于面向对象数据模型具有更丰富的语义、更强的描述能力而越来越受到人们的重视，不但出现了商品化的面向对象DBMS，而且开始实际应用于概念模型的设计中，作为数据库概念设计的工具。Teory 等人提出的扩展的 E-R 模型增加了类似面向对象数据模型中的普遍化和聚合等语义描述机制，为这种最为人们熟悉的数据模型注入了新的生机，为概念模型的描述增加了一种理想的选择。

概念结构的设计策略

主要有自底向上、自顶向下、由里向外和混合策略。在具体实现设计目标时有两种极端的策略或方案，一是建立一个覆盖整个单位所有功能域的全局数据库，称之为全局方案或全局策略；另一种则是对每一个应用都建立一个单独的数据库，称之为应用方案或应用策略。

视图

由于各个部门对于数据的需求和处理方法各不相同，对同一类数据的观点也可能不一样，它们有自己的视图，所以可以首先根据需求分析阶段产生的各个部门的数据流图和数据字典中的相关数据设计出各自的局部视图，然后进行视图集成。

视图设计

在实体分析法中，局部视图设计的第一步是确定其所属的范围，即它所对应的用户组，然后对每个用户组建立一个仅由实体、联系及它们的标识码组成的局部信息结构（局部数据模式）框架，最后再加入有关的描述信息，形成完整的局部视图（局部数据模式）。这样做的目的是为了集中精力处理好用户数据需求的主要方面，避免因无关紧要的描述细节而影响局部信息结构的正确性。

设计步骤
  1. 确定局部视图的范围
  2. 识别实体及其标识
  3. 确定实体间的联系
  4. 分配实体及联系的属性
确定局部视图的范围

需求说明书中标明的用户视图范围可以作为确定局部视图范围的基本依据，但它通常与子模式范围相对应，有时因为过大而不利于局部信息结构的构造，故可根据情况修改，但也不宜分得过小，过小会造成局部视图的数量太大及大量的数据冗余和不一致性，给以后的视图集成带来很大的困难。

局部视图范围确定的基本原则

功能域之间的联系应最少

实体个数适量。一个局部视图所包含的实体数量反映了该局部视图的复杂性，按照信息论中的观点，人们在同一时刻可同时顾及的事情一般在 5～9 之间，其中以 6 或 7 最为适当。因此，一个局部视图内的实体数不宜超过 9 个，否则就会过于复杂，不便于人们理解和管理。

识别实体及其标识

在需求分析中，人们已经初步地识别了各类实体、实体间的联系及描述其性质的数据元素，这些统称为数据对象，它们是进一步设计的基本素材。这一步的任务就是在确定的局部视图范围内，识别哪些数据对象作为局部视图的基本实体及其标识，并定义有关数据对象在 E-R 模型中的地位。

确定实体间的联系

  1. 实际上，识别联系的主要任务是在需求分析阶段完成的。这里的工作一是从局部视图的角度进行一次审核，检查有无遗漏之处，二是确切地定义每一种联系。

    在现实世界中，诸多形式的联系大致可分为三类：存在性联系、功能性联系和事件联系。存在性联系如学校有教师、教室有学生、工厂有产品、产品有顾客等；功能性联系如教师讲授课程、教师参与科研、仓库管理员管理仓库等；事件联系如学生借书、产品发运等。

    根据上述分类仔细检查在给定的局部视图范围内是否有未识别的联系，在确认所有的联系都已识别并无遗漏之后，还需对联系进行正确的定义。定义联系就是对联系语义的仔细分析，识别联系的类型，确定实体在联系中的参与度。

    ① 二元联系的类型与定义。二元联系是指两个实体类之间的联系。根据参与联系的两个实体类值之间的对应关系分为一对一、一对多及多对多三种类型。

    ② 多元联系的识别与定义。两个以上的实体类之间的联系称为多元联系。例如在供应商向工程供应零件这类事件中，如果任一供应商可向任一工程供应任一种零件，则为了确定哪个供应商向哪个工程供应了何种零件，就必须定义一个三元联系，因为只有供应商、工程及零件三者一起才能唯一地确定一个联系值。其联系的标识由参与联系的实体类的标识拼接而成，在此例中由供应商、工程、零件三个实体类的标识拼接而成。

分配实体及联系的属性
视图集成

视图集成就是要将反映各用户组数据的局部数据模式综合成单位中某个确定范围内的单一数据视图，即全局数据模式，又称模式汇总。该全局数据模式是未来数据库结构的基础，因此视图集成是数据库设计过程中一个十分重要的步骤，也是一项较为复杂和困难的任务。当所有局部视图设计完毕，就可开始视图集成。

冲突的表现和处理策略

① 同名异义。为了发现不同视图间的同名异义问题，可以列出所有同名数据对象，然后逐一判别其语义。对同名异义冲突通常采用换名加以解决，既可对同名者之一换名，也可对两者都给以重新命名。识别语义的主要方法是进行值域分析。

② 异名同义。识别异名同义比较困难，一般由设计者对所有对象一个不漏地逐一鉴别。它同样采用换名的方法解决。若归并时试图将它们合并为一个对象，则可以把其中之一的名称作为合并后的对象名；若集成后，它们仍以两个不同的对象存在，则可对其一换名。当然，若原名都不合适，则可以对两者都重新命名。

③ 同名不同层次。如果两个对象同名，但其中之一是作为一个视图中的实体，而另一个是另一视图中的属性，则在集成时就会发生同名不同层次的冲突。解决这种冲突的办法有两个，一是将属性转换为实体，二是将实体变换成属性。

逻辑结构设计

这一阶段的设计目标是把上一阶段得到的与 DBMS 无关的概念数据模型转换成等价的，并为某个特定的 DBMS 所接受的逻辑模型所表示的概念模式，同时将概念设计阶段得到的应用视图转换成外部模式，即特定 DBMS 下的应用视图。在转换过程中要进一步落实需求说明，并满足 DBMS 的各种限制。该阶段的结果是用 DBMS 所提供的数据定义语言（DDL）写成的数据模式。逻辑设计的具体方法与 DBMS 的逻辑数据模型有关。逻辑模型应满足数据库存取、一致性及运行等各方面的用户需求。

逻辑结构设计步骤

（1）将概念结构向一般关系模型转化。

（2）将第一步得到的结构向特定的 DBMS 支持下的数据模型转换。

（3）依据应用的需求和具体的 DBMS 的特征进行调整与完善。

逻辑设计介绍基本原则和方法

1.基本E-R 模型向关系模型的转换

一对一联系

基本 E-R 模型主要包含实体和联系两个抽象概念，实体和联系本身还可能附有若干属性。其转换的基本原则是，实体和联系分别转换成关系，属性则转换成相应关系的属性。

方案 1：将实体 E1、E2 和联系名 R 分别转换成为关系 E1、E2 和 R，它们的属性分别转为相应关系的属性，即得到：

El（k1，a） \\K1 关系关键字
E2（k2，b） \\K2 关系关键字
R（k1，k2，r）（k2 是候选关键字）

方案 2：将实体 El 转换为关系 El ，将实体E2 与联系名 R 一起转换成关系E2 ，E2 的属性由 E2 和 R 的属性加上E1 的关键字组成，其关键字k1、k2 为其候选关键字。转换后的关系为：

E1（k1，a）\\k1 关系关键字
E2′（k2，b，k1，r），（k2 关系关键字 ， k1是候选关键字）

方案3：与方案2 类似，不过把实体E1 与联系R一起转换成关系E1 后，其结果为：

E1′（k1，a，k2，r），（k1关系关键字 ， k2是候选关键字）
E2（k2，b）

上述三个方案实际上可归结为转换成三个关系和转换成两个关系两种。如果每个实体的属性数较少，而联系的属性与两个实体之一关系又较密切，则可采用方案 2 或方案 3，其优点是可减少关系数，有利于减少连接运算从而提高查询效率，但如果每个实体的属性较多，且合并后，会造成较大数据冗余和操作异常，则以采用方案 1 为宜。

一对多联系

方案1:

把两个实体类和一个联系类分别转换成对应的关系，实体类的属性转换为对应关系的属性，其标识属性即为对应关系的关键字，而联系类转换得到的关系，其属性由两个实体的标识属性和联系类本身的属性组成，并以多端实体类的标识属性为其关键字。其转换结果为三个关系。

方案2:

转换成两个关系，设少端和多端的两个实体类分别为 El、E2，联系名 R。转换时，将实体类 El 转换为一个关系 El，E2 和 R 合起来转换成一个关系 E2′，E2′的属性由 E2 和 R 的属性加上 E1 的标识属性组成，并以 E 2 的标识属性为其关键字。

多对多联系

实体类分别转换为相应的关系，三个实体类间的多元联系转换为以该联系名为关系名的关系，关系的属性由各实体的标识属性及其联系的属性组成，并以各实体的标识属性为其关键字。

自联系

自联系是同一实体集的实体间的联系。例如对于职工实体类内部有领导与被领导的联系，在部件这个实体集的实体之间有组成成分与组成者之间的联系等，均属于实体类的自联系。在这种联系中，参与联系的实体虽然来自同一实体类，但所起的作用不一样。

弱实体类的转换

一个实体类，如果它的存在依赖于另一实体类，则称之为弱实体类。

2．数据模型的优化

由 E-R 图表示的概念模型转换得到的关系模型经过规范化以后，基本上可以反映一个企业数据的内在联系，但不一定能满足应用的全部需要和系统要求，因此，还必须根据需求分析对模型做进一步的改善和调整，其内容主要是改善数据库的性能和节省存储空间两个方面。

（1）改善数据库性能的考虑。查询速度是关系数据库应用中影响性能的关键问题，必须在数据库的逻辑设计和物理设计中认真加以考虑，特别是那些对响应时间要求较苛刻的应用，应予以特别注意。

提高查询的速度考虑方面

① 减少连接运算。连接运算对关系数据库的查询速度有着重要的影响，连接的关系越多，参与连接的关系越大，开销也越大，因而查询速度也越慢。对于一些常用的、性能要求较高的数据库查询，最好是一元查询，但这与规范化的要求相矛盾。有时为了保证性能，往往不得不牺牲规范化要求，把规范化的关系再合并起来，称之为逆规范化。当然，这样做会引起更新异常。总之，逆规范化有得有失，设计者可根据实际情况进行权衡。

② 减小关系大小及数据量。被查询的关系的大小对查询速度影响较大。为了提高查询速度，可以采用水平分割或垂直分割等方法把一个关系分成几个关系，使每个关系的数据量减少。例如，对于大学中有关学生的数据，既可以把全校学生的数据集中在一个关系中，也可以用水平分割的方法，分系建立关系，从而减少了每个关系的元组数。前者对全校范围内的查询较方便，后者则可以显著提高对指定系的查询速度。也可采用垂直分割的方法，把常用数据与非常用数据分开，以提高常用数据的查询速度。例如，高校中教职工档案，属性很多，有些需经常查询，有些则很少查询，如果放在一起，则关系的数据量就会很大，影响查询速度，因此把常用属性和非常用属性分开，就可提高对常用属性的查询速度。

③ 尽量使用快照。快照是某个用户所关心的那部分数据，与视图一样是一种导出关系，但它与视图有两点不同：一是视图是虚关系，数据库中并不存储作为视图的导出关系，仅仅保留它的定义，快照则是一个由系统事先生成后保留在数据库中的实关系；二是视图随数据当前值的变化而变化，快照则不随原来关系中数据的改变而及时改变，它只反映数据库中某一时刻的状态，不反映数据库的当前状态，犹如照片只反映某一时刻的情景，不能反映情景变化一样，之所以称它为快照，原因就在于此。但它与照片又有不同，快照不是一成不变的，它可以由系统周期性地刷新，或由用户用命令刷新。刷新时用当前值更新旧值。在实际应用中，快照可满足相当一部分应用的需要，甚至有些应用就是需要快照，而不是当前值。例如注明列出“某年某月某日截止”的统计或报表就是快照。由于快照是事先生成并存储在数据库中的，因而可大大缩短响应时间。目前不少 DBMS，如Oracle、 MS SQL Server 等支持快照。对不支持快照的 DBMS，用户也可以把需要作为实关系使用的导出关系作为一个独立关系存于数据库中，但这种做法只能供查询使用，对它们的刷新及管理由用户负责。

2）节省存储空间的一些考虑。尽管随着硬件技术的发展，提供给用户使用的存储空间越来越大，但毕竟是有限度的。而数据库，尤其是复杂应用的大型数据库，需要占用较大的外存空间。因此，节省存储空间仍是数据库设计中应该考虑的问题，不但要在数据库的物理设计中考虑，而且还应在逻辑设计中加以考虑。

节省存储空间考虑方面

① 缩小每个属性占用的空间。减少每个属性占用的空间，是节省存储空间的一个有效的措施。通常可以有两种方法：即用编码和用缩写符号表示属性，但这两种方法的缺点是失去了属性值含义的直观性。

② 采用假属性。采用假属性可以减少重复数据占用的存储空间。设某关系模型 R 的属性 A 和 B 之间存在函数依赖 A→B，B 的每一个值需要占用较大的空间，但 B 的域中不同的值却比较少，A 的域中具有较多的不同值，则 B 的同一值可能在多个元组中重复出现，从而需要占用较多的空间。为了节省空间，可利用属性 B 的域中不同值少的特点，对 B 的值进行分类，用 B′表示 B 的类型，则A→B 可分解成两个函数依赖，即：A→B′，B′→B

这样，就可用 B′代替原来元组较多的关系 R 中的属性 B，而另外建立一个较小的关系 R′来描述 B′与 B 的对应关系。这里 B′在原关系 R 中起了属性 B 的替身的作用，所以称 B′ 为假属性。例如，在职工关系中，职工的经济状况这一属性通常由职工号决定，一个大型企业的职工人数很多，如每一职工逐一填写，就要占用较多的空间，为了节省空间可把经济状况分为几种类型，在元组较多的职工关系中用经济状况的类型代替原来的经济状况，这里经济状况的类型就是假属性，另外建立一个较小的关系来描述每种经济状况类型的具体内容。

数据库物理设计

物理设计阶段的任务是把逻辑设计阶段得到的满足用户需求的已确定的逻辑模型在物理上加以实现，其主要内容是根据 DBMS 提供的各种手段，设计数据的存储形式和存取路径，如文件结构、索引设计等，即设计数据库的内模式或存储模式。数据库的内模式对数据库的性能影响很大，应根据处理需求及 DBMS、操作系统和硬件的性能进行精心设计。

数据库在实际的物理设备上的存储结构和存取方法称为数据库的物理结构。数据库物理设计是利用已确定的逻辑结构及 DBMS 提供的方法、技术，以较优的存储结构、数据存取路径、合理的数据存储位置及存储分配，设计出一个高效的、可实现的物理数据库结构。显然，数据库的物理设计是完全依赖于给定的硬件环境和数据库产品的。

设计者必须了解

（1）了解并熟悉应用要求，包括各个用户对应的数据视图，即数据库的外模式（子模式），分清哪些是主要的应用，了解各个应用的使用方式、数据量和处理频率等，以便对时间和空间进行平衡，并保证优先满足应用的时间要求。

（2）熟悉使用的 DBMS 的性能，包括 DBMS 的功能，提供的物理环境、存储结构、存取方法和可利用的工具。

（3）了解存放数据的外存设备的特性，如物理存储区域的划分原则，物理块的大小等有关规定及I/O 特性等。

存储模式和概念模式不一样，它不是面向用户的，一般的用户不一定也不需要了解数据库存储模式的细节。所以数据库存储模式的设计可以不必考虑用户理解的方便，其设计目标主要是提高数据库的性能，其次是节省存储空间。

在进行物理设计时，设计人员可能用到的数据库产品是多种多样的。不同的数据库产品所提供的物理环境、存储结构和存取方法有很大差别，能供设计人员使用的设计变量、参数范围也大不相同，因此没有通用的物理设计方法可遵循，只能给出一般的设计内容和原则。

软考-架构师-第三章-数据库系统 第八节 数据库设计的基本步骤（读书笔记）相关推荐

  1. 软考-架构师-第三章-数据库系统 第七节 数据库设计（读书笔记）

    版权声明 主要针对希赛出版的架构师考试教程<系统架构设计师教程(第4版)>,作者"希赛教育软考学院".完成相关的读书笔记以便后期自查,仅供个人学习使用,不得用于任何商业 ...

  2. 软考-架构师-第七章-系统规划 第二节 可行性研究与效益分析 (读书笔记)

    版权声明 主要针对希赛出版的架构师考试教程<系统架构设计师教程(第4版)>,作者"希赛教育软考学院".完成相关的读书笔记以便后期自查,仅供个人学习使用,不得用于任何商业 ...

  3. 软考-架构师-第五章-系统性能评价 第二节 性能计算(读书笔记)

    版权声明 主要针对希赛出版的架构师考试教程<系统架构设计师教程(第4版)>,作者"希赛教育软考学院".完成相关的读书笔记以便后期自查,仅供个人学习使用,不得用于任何商业 ...

  4. 软考架构师 | 03 软件工程

    软考架构师 | 03 软件工程

  5. 软考架构师-论文提纲总结

    论软件架构评估 [提纲总结] 1. 摘要:项目背景,点题,使用了ATAM等 2. 开始:系统使用的技术以及系统整体架构介绍 3. 入题:提出架构评估,简述质量属性,和质量效用树的四个重要属性 4. 切 ...

  6. python第三章上机实践_《机器学习Python实践》读书笔记-第三章

    <机器学习Python实践>,第三章,第一个机器学习项目 以往目录:橘猫吃不胖:<机器学习Python实践>读书笔记-第一章​zhuanlan.zhihu.com 书中介绍了一 ...

  7. 软考架构师（第十二章 系统可靠性分析与设计 -- 案例题，论文）

    12.1 系统故障模型 12.2 系统可靠性指标 12.3 串联系统 与 并联系统 12.4 系统容错 12.4.1 N版本程序设计 – 不常见 12.4.2 恢复块方法 – 不常见 12.4.3 防 ...

  8. 软考架构师-知识点总结

    用例之间的关系有泛化.包含和扩展 类之间的关系有关联 , 聚合 , 组合 , 依赖 , 泛化 实时系统是指向系统发出一指令后 , 在一个极短时间内系统回复结果 实时系统的特性 : 时间约束性(及时性) ...

  9. 《数据库设计入门经典》读书笔记——第二章：工作场所中的数据库建模

    感觉这章讲的技术点很少,我就不想写了,这章就跳过了. 转载于:https://www.cnblogs.com/tuhooo/p/8468760.html

最新文章

  1. c语言xml序列化,C# XML和实体类之间相互转换(序列化和反序列化)
  2. oracle+view性能,Oracle 10g的隐含参数_complex_view_merging引发的性能问题
  3. 【QuantOS】jaqs实例代码（可以使用版本）
  4. 初学者学用Github
  5. PhoneUtils
  6. Linux命令总结（之二）Find
  7. std string与线程安全_是std :: regex线程安全吗？
  8. 345.反转字符串中的元音字符（力扣leetcode） 博主可答疑该问题
  9. 数据可视化常用LED字体
  10. 三菱plc控制步进电机实例_电工进阶PLC工程师！必学步进电机的编程控制指令，你掌握了吗...
  11. thinkpad x60安装WINDOWS2003SERVER
  12. 电脑登录微信,手机退出微信，电脑端微信仍然在线（IOS）
  13. FLOW 3D二次开发
  14. rabbitmq port is already allocated
  15. 网站被劫持怎么办，怎么解决？
  16. python两张图片无缝合成一张,Python实现拼接多张图片的方法
  17. Java字节码角度分析方法调用 ——提升硬实力7
  18. 国产操作系统突破重围，中兴新支点系统宣布：30万+，并发布服务器模式
  19. scp cp
  20. 高树玛丽亚在线观看_音乐玛丽亚·凯里的数学数字

热门文章

  1. 2021年中国燃料电池行业发展现状及趋势分析[图]
  2. 字符串匹配代码C语言,KMP算法(快速模式匹配算法)详解以及C语言实现
  3. Arduino UNO测试BME680环境传感器
  4. “个人能力之外的资本为零”
  5. 帝国CMS7.5仿《D9下载站》软件应用下载网站源码
  6. 转Android APP安装后不在桌面显示图标的应用场景举例和实现方法
  7. python_制作Windows安装程序包
  8. 【雕刻机】coppercam软件导出的NC文件导入grbl刀路显示不完整
  9. Apollo 7.0——percception：lidar源码剖析（万字长文）
  10. 源码编译安装部署LNMP架构（Nginx、MYSQL、PHP+论坛）