免费智能真题库 > 历年试卷 > 系统分析师 > 2024年下半年 系统分析师 下午试卷 案例
  第1题      
  知识点：   实际应用   数据流图   数据字典   需求分析   关系模式的规范化   规范化   数据库   数据库设计   数据流   索引   销售管理

 
某集团公司在各省均设有分公司，现欲建立全国统一的销售管理信息系统，以便总公司及时掌握各分公司的销售情况。公司成立专门的项目组进行该系统的研发工作，其中张工负责其中的数据库设计工作。
张工和需求分析小组紧密合作，在设计出数据流图和数据字典的基础上，给出了数据库关系模式和相应的索引设计。同时考虑到未规范化关系模式可能引起的各类数据错误，对关系模式进行了全面的规范化处理，使所有关系模式均达到了3NF或BCNF。
在项目实施过程中，应用开发小组认为该设计方案未考虑应用功能的实际需求。如果严格按照设计方案实施，会对应用系统的整体性能产生较大影响。主要的原因在于进行数据查询时，会产生大量的多表连接操作，影响性能。而设计方案中的索引设计，并不能完全满足数据查询的性能要求。
应用开发小组还认为，该设计方案未考虑到信息系统中核心销售数据处理的特点：各分公司在使用该信息系统时只能操作自己分公司的销售数据，无权操作其他分公司的销售数据：只有总公司有权利操作所有销售数据，以便进行统计分析。
应用开发小组要求，在数据库设计方案中，必须针对实际应用功能的实现来考虑关系模式的规范化，必要时需要采用逆规范化或解除规范化的方法来保证性能要求。
 
问题：1.1   系统需要管理供应商和货物等信息，具体包括供应商姓名、地址以及货物名称、价格等，供应商可以提供0〜n种货物，其公司地址也可能发生变化。请以供应商关系模式 supplier(name, address, product, price)为例，解释不规范的关系模式存在哪些问题。
 
问题：1.2   应用开发小组认为张工的规范化设计虽然解决了未规范化关系模式带来的问题，但实际实现功能时会造成系统性能的下降。请解释其原因。
 
 
 

   知识点讲解    
   · 实际应用    · 数据流图    · 数据字典    · 需求分析    · 关系模式的规范化    · 规范化    · 数据库    · 数据库设计    · 数据流    · 索引    · 销售管理
 
       实际应用
        在考试时，可能会出现一些需要综合应用的问题，需要考生根据基本的概念，结合实际问题进行解答。
        例如：在某并发系统中，有一个发送进程A、一个接收进程B、一个环形缓冲区BUFFER、信号量S1和S2。发送进程不断地产生消息并写入缓冲区BUFFER，接收进程不断地从缓冲区BUFFER取消息。假设发送进程和接收进程可以并发地执行，那么，当缓冲区的容量为N时，如何使用P、V操作才能保证系统的正常工作。发送进程A和接收进程B的工作流程如下图所示。请在下图中的（1）～（4）处填写正确的操作。
        
        P、V操作实例一
        根据题意，很显然，这是一个“生产者－消费者”问题，根据该问题的特性，通常需要3个信号量来实现：两个用来管理缓冲区同步，信号量empty表示空闲缓冲区数量，初值为缓冲区最大数N，信号量full表示已填充缓冲区数量，初值为0；一个用于管理互斥，由信号量mutex保证只有一个进程在写缓冲区，初值为1。但在本题中，进程A和进程B允许并发地访问缓冲区，因此无须管理互斥，就不需要使用信号量mutex了。因此只需定义两个信号量：S1和S2，初值为N的S1在此承担的是信号量empty的功能，初值为0的S2在此则承担的是信号量full的功能。
        通过这样的分析，不难得出：（1）处应该是P（S1），将空闲缓冲区数量减1；（2）处应该是V（S2），将已填充的缓冲区数量加1；（3）处则是P（S2），（4）处为V（S1）。
        在这个例子的基础上，如果系统中有多个发送进程和接收进程，进程间的工作流程如下图所示，其中空（1）～（4）的内容与上图相同。发送进程产生消息并顺序地写入环形缓冲区BUFFER，接收者进程顺序地从BUFFER中取消息，且每条消息只能读取一次。为了保证进程间的正确通信，增加了信息量SA和SB。请说明信息量SA和SB的物理意义，在下图中的（5）和（6）处填入正确的内容，并从下图的（a）～（l）中选择四个位置正确地插入P（SA），V（SA），P（SB），V（SB）。
        下图所涉及的问题在普通的“生产者－消费者”问题上增加了一些复杂度：“系统中有多个发送进程和接收进程”，根据题意，我们可以得知它要完成的控制是：发送进程顺序写入，接收进程顺序读取，而且每条消息都只能够读取一次。这显然是两个互斥的问题，即多个发送进程在写缓冲区时是互斥关系，多个接收进程读缓冲区也是互斥关系。因此，信号量SA和SB分别实现这两个用来完成两个进程的互斥控制。
        （1）SA：初值为1，表示允许同时对缓冲区进行写操作的进程数量。
        （2）SB：初值为1，表示允许同时对缓冲区进行读操作的进程数量。
        当然，两个对调也是可以的。在发送进程和接收进程中分别有一组信号量SA和SB的P、V操作。因此，接下来的问题就是找出插入点。互斥控制的要点在于判断出临界区的范围，也就是哪部分程序必须互斥进入，否则将出现问题。根据这一点，我们可以进行如下分析。
        
        P、V操作实例二
        （1）发送进程：在进程产生消息之后准备写入缓冲区时，这时就需要进行互斥判断，因此在位置（b）应插入P（SA）；而直到完成“i=（i+1）modN”操作后，才完成缓冲区操作，因此必须在位置（f）插入V（SA）。
        （2）接收进程：由于接收进程是负责读数据的，如果数据区是空的则应该等待，因此必须先完成P（S2）操作，来决定其是否需要阻塞。如果没有阻塞时，再进入临界区，因此应该在位置（h）处操作P（SB）；而“对读取的消息进行处理”已显然在临界区之外，因此应该在位置（k）插入V（SB）。
 
       数据流图
        DFD是结构化分析中的重要方法和工具，是表达系统内数据的流动并通过数据流描述系统功能的一种方法。DFD还可被认为是一个系统模型，在信息系统开发中，一般将它作为需求说明书的组成部分。
        
        业务流程图符号
        DFD从数据传递和加工的角度，利用图形符号通过逐层细分地描述系统内各个部件的功能和数据在它们之间传递的情况，来说明系统所完成的功能。具体来说，DFD的主要作用如下：
        （1）DFD是理解和表达用户需求的工具，是系统分析的手段。由于DFD简明易懂，理解它不需要任何计算机专业知识，因此通过它同客户交流很方便。
        （2）DFD概括地描述了系统的内部逻辑过程，是系统分析结果的表达工具，因而也是系统设计的重要参考资料，是系统设计的起点。
        （3）DFD作为一个存档的文字材料，是进一步修改和充实开发计划的依据。
        在DFD中，通常会出现4种基本符号，分别是数据流、加工、数据存储和外部实体（数据源及数据终点）。数据流是具有名字和流向的数据，在DFD中用标有名字的箭头表示。加工是对数据流的变换，一般用圆圈表示。数据存储是可访问的存储信息，一般用直线段表示。外部实体是位于被建模的系统之外的信息生产者或消费者，是不能由计算机处理的成分，它们分别表明数据处理过程的数据来源及数据去向，用标有名字的方框表示。下图是一个典型的DFD示例。
        
        办理取款手续的DFD
        为了表达数据处理过程中的数据加工情况，用一个DFD是不够的。稍微复杂的实际问题，在DFD中常常出现十几个甚至几十个加工。这样的DFD看起来很不清楚。层次结构的DFD能很好地解决这一问题。按照系统的层次结构进行逐步分解，并以分层的DFD反映这种结构关系，能清楚地表达整个系统。
        下图给出分层DFD的示例。数据处理S包括3个子系统1、2、3。顶层下面的第一层DFD为DFD/L1，第二层的DFD/L2.1、DFD/L2.2及DFD/L2.3分别是子系统1、2和3的细化。对任何一层数据流图来说，它的上层图称为父图，在它下一层的图则称为子图。
        
        分层数据流图
        概括地说，画DFD的基本步骤，就是“自顶向下，逐层分解”。检查和修改的原则如下：
        （1）DFD中的所有图形符号只限于前述4种基本图形元素。
        （2）顶层DFD必须包括前述4种基本元素，缺一不可。
        （3）顶层DFD中的数据流必须封闭在外部实体之间。
        （4）每个加工至少有一个输入数据流和一个输出数据流。
        （5）在DFD中，需按层给加工框编号。编号表明了该加工处在哪一层，以及上下层的父图与子图的对应关系。
        （6）规定任何一个数据流子图必须与它上一层的一个加工对应，两者的输入数据流和输出数据流必须一致。此即父图与子图的平衡。
        （7）可以在DFD中加入物质流，帮助用户理解DFD。
        （8）图上每个元素都必须有名字。
        （9）DFD中不可夹带控制流。
 
       数据字典
        数据字典是关于数据的信息的集合，也就是对DFD中包含的所有元素的定义的集合。DFD和数据字典共同构成系统的逻辑模型。没有DFD，数据字典难以发挥作用；没有数据字典，DFD就不严格。只有把DFD和对DFD中每个元素的精确定义放在一起，才能共同构成系统的规格说明。
        数据字典的设计包括：数据流设计、数据元素字典设计、数据处理字典设计、数据结构字典设计和数据存储设计。这些设计涵盖了数据的采集和范围的确定等信息。在数据字典的每一个词条中应包含以下信息：名称、别名或编号、分类、描述、何处使用。
        对加工的描述是数据字典的组成内容之一，常用的加工描述方法有结构化语言、判定树及判定表。
        （1）结构化语言：介于自然语言和形式语言之间的一种半形式语言，在自然语言基础之上加了一些限度，使用有限的词汇和有限的语句来描述加工逻辑。结构化语言是受结构化程序设计思想启发而扩展出来的。结构化程序设计只允许3种基本结构。结构化语言也只允许3种基本语句，即简单的祈使语句、判断语句和循环语句。与程序设计语言的差别在于结构化语言没有严格的语法规定，与自然语言的不同在于它只有极其有限的词汇和语句。结构化语言使用3类词汇：祈使句中的动词、数据字典中定义的名词及某些逻辑表达式中的保留字。
        （2）判定树：若一个动作的执行不只依赖一个条件，而与多个条件有关，那么这项策略的表达就比较复杂。如果用结构化语言的判断语句，就有多重嵌套，层次一多，可读性就会下降。用判定树来表示，可以更直观一些。
        （3）判定表：一些条件较多、在每个条件下取值也较多的判定问题，可以用判定表表示。判定表能清晰地表达复杂的条件组合与应做动作之间的对应关系，判定表的优点是能够简洁、无二义性地描述所有的处理规则。但判定表表示的是静态逻辑，是在某种条件取值组合情况下可能的结果，它不能表达加工的顺序，也不能表达循环结构，因此判定表不能成为一种通用的设计工具。
 
       需求分析
        需求分析的方法种类繁多，不过如果按照分解的方式不同，可以很容易地划分出几种大类型：
        （1）结构化分析方法。本节后续内容将详细讨论SA的内容。
        （2）面向对象分析方法。将在10.3节中进行详细介绍。
        （3）面向问题域的分析（Problem Domain Oriented Analysis, PDOA）方法。PDOA更多地强调描述，而少强调建模。它的描述大致分为关注问题域和关注解系统的待求行为这两个方面。问题框架是PDOA的核心元素，是将问题域建模成为一系列相互关联的子域。也可以把问题框架看作是开发上下文图，但不同的是上下文图的建模对象是针对解系统，而问题框架则是针对问题域。也就是说，问题框架的目标就是大量地捕获更多有关问题域的信息。PDOA方法现在还在研究阶段，并未广泛应用。
               业务流程分析
               业务流程分析的目的是了解各个业务流程的过程，明确各个部门之间的业务关系和每个业务处理的意义，为业务流程的合理化改造提供建议，为系统的数据流程变化提供依据。
               业务流程分析的步骤如下：
               （1）通过调查掌握基本情况。
               （2）描述现有业务流程（绘制业务流程图）。
               （3）确认现有业务流程。
               （4）对业务流程进行分析。
               （5）发现问题，提出解决方案。
               （6）提出优化后的业务流程。
               在业务流程图中使用的基本符号如下图所示。
               数据流图
               DFD是结构化分析中的重要方法和工具，是表达系统内数据的流动并通过数据流描述系统功能的一种方法。DFD还可被认为是一个系统模型，在信息系统开发中，一般将它作为需求说明书的组成部分。
               
               业务流程图符号
               DFD从数据传递和加工的角度，利用图形符号通过逐层细分地描述系统内各个部件的功能和数据在它们之间传递的情况，来说明系统所完成的功能。具体来说，DFD的主要作用如下：
               （1）DFD是理解和表达用户需求的工具，是系统分析的手段。由于DFD简明易懂，理解它不需要任何计算机专业知识，因此通过它同客户交流很方便。
               （2）DFD概括地描述了系统的内部逻辑过程，是系统分析结果的表达工具，因而也是系统设计的重要参考资料，是系统设计的起点。
               （3）DFD作为一个存档的文字材料，是进一步修改和充实开发计划的依据。
               在DFD中，通常会出现4种基本符号，分别是数据流、加工、数据存储和外部实体（数据源及数据终点）。数据流是具有名字和流向的数据，在DFD中用标有名字的箭头表示。加工是对数据流的变换，一般用圆圈表示。数据存储是可访问的存储信息，一般用直线段表示。外部实体是位于被建模的系统之外的信息生产者或消费者，是不能由计算机处理的成分，它们分别表明数据处理过程的数据来源及数据去向，用标有名字的方框表示。下图是一个典型的DFD示例。
               
               办理取款手续的DFD
               为了表达数据处理过程中的数据加工情况，用一个DFD是不够的。稍微复杂的实际问题，在DFD中常常出现十几个甚至几十个加工。这样的DFD看起来很不清楚。层次结构的DFD能很好地解决这一问题。按照系统的层次结构进行逐步分解，并以分层的DFD反映这种结构关系，能清楚地表达整个系统。
               下图给出分层DFD的示例。数据处理S包括3个子系统1、2、3。顶层下面的第一层DFD为DFD/L1，第二层的DFD/L2.1、DFD/L2.2及DFD/L2.3分别是子系统1、2和3的细化。对任何一层数据流图来说，它的上层图称为父图，在它下一层的图则称为子图。
               
               分层数据流图
               概括地说，画DFD的基本步骤，就是“自顶向下，逐层分解”。检查和修改的原则如下：
               （1）DFD中的所有图形符号只限于前述4种基本图形元素。
               （2）顶层DFD必须包括前述4种基本元素，缺一不可。
               （3）顶层DFD中的数据流必须封闭在外部实体之间。
               （4）每个加工至少有一个输入数据流和一个输出数据流。
               （5）在DFD中，需按层给加工框编号。编号表明了该加工处在哪一层，以及上下层的父图与子图的对应关系。
               （6）规定任何一个数据流子图必须与它上一层的一个加工对应，两者的输入数据流和输出数据流必须一致。此即父图与子图的平衡。
               （7）可以在DFD中加入物质流，帮助用户理解DFD。
               （8）图上每个元素都必须有名字。
               （9）DFD中不可夹带控制流。
               数据字典
               数据字典是关于数据的信息的集合，也就是对DFD中包含的所有元素的定义的集合。DFD和数据字典共同构成系统的逻辑模型。没有DFD，数据字典难以发挥作用；没有数据字典，DFD就不严格。只有把DFD和对DFD中每个元素的精确定义放在一起，才能共同构成系统的规格说明。
               数据字典的设计包括：数据流设计、数据元素字典设计、数据处理字典设计、数据结构字典设计和数据存储设计。这些设计涵盖了数据的采集和范围的确定等信息。在数据字典的每一个词条中应包含以下信息：名称、别名或编号、分类、描述、何处使用。
               对加工的描述是数据字典的组成内容之一，常用的加工描述方法有结构化语言、判定树及判定表。
               （1）结构化语言：介于自然语言和形式语言之间的一种半形式语言，在自然语言基础之上加了一些限度，使用有限的词汇和有限的语句来描述加工逻辑。结构化语言是受结构化程序设计思想启发而扩展出来的。结构化程序设计只允许3种基本结构。结构化语言也只允许3种基本语句，即简单的祈使语句、判断语句和循环语句。与程序设计语言的差别在于结构化语言没有严格的语法规定，与自然语言的不同在于它只有极其有限的词汇和语句。结构化语言使用3类词汇：祈使句中的动词、数据字典中定义的名词及某些逻辑表达式中的保留字。
               （2）判定树：若一个动作的执行不只依赖一个条件，而与多个条件有关，那么这项策略的表达就比较复杂。如果用结构化语言的判断语句，就有多重嵌套，层次一多，可读性就会下降。用判定树来表示，可以更直观一些。
               （3）判定表：一些条件较多、在每个条件下取值也较多的判定问题，可以用判定表表示。判定表能清晰地表达复杂的条件组合与应做动作之间的对应关系，判定表的优点是能够简洁、无二义性地描述所有的处理规则。但判定表表示的是静态逻辑，是在某种条件取值组合情况下可能的结果，它不能表达加工的顺序，也不能表达循环结构，因此判定表不能成为一种通用的设计工具。
 
       关系模式的规范化
        由E-R图转换得来的初始关系模式并不能完全符合要求，还会有数据冗余、更新异常存在，这就需要经过进一步的规范化处理，具体步骤如下：
        （1）根据语义确定各关系模式的数据依赖。在设计的前一阶段，只是从关系及其属性来描述关系模式，并没有考虑到关系模式中的数据依赖。关系模式包含着语义，要根据关系模式所描述的自然语义写出关系数据依赖。
        （2）根据数据依赖确定关系模式的范式。由关系的码及数据依赖，根据规范化理论，就可以确定关系模式所属的范式，判定关系模式是否符合要求，即是否达到了3NF或4NF。
        （3）如果关系模式不符合要求，要根据关系模式的分解算法对其进行分解，达到3NF、BCNF或4NF。
        （4）关系模式的评价及修正。根据规范化理论，对关系模式分解之后，就可以在理论上消除冗余和更新异常。但根据处理要求，可能还需要增加部分冗余以满足处理要求，这就需要做部分关系模式的处理，分解、合并或增加冗余属性，提高存储效率和处理效率。
 
       规范化
        关系数据库设计的方法之一就是设计满足适当范式的模式，通常可以通过判断分解后的模式达到几范式来评价模式规范化的程度。范式有：1NF、2NF、3NF、BCNF、4NF和5NF，其中1NF级别最低。这几种范式之间成立。
        通过分解，可以将一个低一级范式的关系模式转换成若干个高一级范式的关系模式，这种过程叫作规范化。下面将给出各个范式的定义。
               1NF（第一范式）
               【定义7.10】若关系模式R的每一个分量是不可再分的数据项，则关系模式R属于第一范式。记为R∈1NF。
               例如，供应者和它所提供的零件信息，关系模式FIRST和函数依赖集F如下：
               FIRST（Sno，Sname，Status，City，Pno，Qty）
               F=｛Sno→Sname，Sno→Status，Status→City，（Sno，Pno）→Qty｝
               对具体的关系FIRST如下表所示。从下表中可以看出，每一个分量都是不可再分的数据项，所以是1NF的。但是，1NF存在4个问题：
               
               FIRST
               （1）冗余度大。例如每个供应者的Sno、Sname、Status、City要与其供应的零件的种类一样多。
               （2）引起修改操作的不一致性。例如供应者S1从“天津”搬到“上海”，若不注意，会使一些数据被修改，另一些数据未被修改，导致数据修改的不一致性。
               （3）插入异常。关系模式FRIST的主码为Sno、Pno，按照关系模式实体完整性规定主码不能取空值或部分取空值。这样，当某个供应者的某些信息未提供时（如Pno），则不能进行插入操作，这就是所谓的插入异常。
               （4）删除异常。若供应商S4的P2零件销售完了，并且以后不再销售P2零件，那么应删除该元组。这样，在基本关系FIRST找不到S4，可S4又是客观存在的。
               正因为上述4个原因，所以要对模式进行分解，并引入了2NF。
               2NF（第二范式）
               【定义7.11】若关系模式R∈1NF，且每一个非主属性完全依赖于码，则关系模式R∈2NF。
               换句话说，当1NF消除了非主属性对码的部分函数依赖，则称为2NF。
               例如，FIRST关系中的码是Sno、Pno，而Sno→Status，因此非主属性Status部分函数依赖于码，故非2NF的。
               若此时，将FIRST关系分解为：
               FIRST1（Sno，Sname，Status，City）∈ 2NF
               FIRST2（Sno，Pno，Qty）∈2NF
               因为分解后的关系模式FIRST1的码为Sno，非主属性Sname、Status、City完全依赖于码Sno，所以属于2NF；关系模式FIRST2的码为Sno、Pno，非主属性Qty完全依赖于码，所以也属于2NF。
               3NF（第三范式）
               【定义7.12】若关系模式R（U，F）中不存在这样的码X，属性组Y及非主属性使得X→Y，成立，则关系模式R∈3NF。
               即当2NF消除了非主属性对码的传递函数依赖，则称为3NF。
               例如，FIRST1?3NF，因为在分解后的关系模式FIRST1中有Sno→Status，Status→City，存在着非主属性City传递依赖于码Sno。若此时将FIRST1继续分解为：
               FIRST11（Sno，Sname，Status）∈ 3NF
               FIRST12（Status，City）∈3NF
               通过上述分解，数据库模式FIRST转换为FIRST11（Sno，Sname，Status）、FIRST12（Status，City）、FIRST2（Sno，Pno，Qty）三个子模式。由于这三个子模式都达到了3NF，因此称分解后的数据库模式达到了3NF。
               可以证明，3NF的模式必是2NF的模式。产生冗余和异常的两个重要原因是部分依赖和传递依赖。因为3NF模式中不存在非主属性对码的部分函数依赖和传递函数依赖，所以具有较好的性能。对于非3NF的1NF、2NF其性能弱，一般不宜作为数据库模式，通常要将它们变换成为3NF或更高级别的范式，这种变换过程称为“关系模式的规范化处理”。
               BCNF（Boyce Codd Normal Form，巴克斯范式）
               【定义7.13】关系模式R∈1NF，若X→Y且时，X必含有码，则关系模式R∈BCNF。
               也就是说，当3NF消除了主属性对码的部分函数依赖和传递函数依赖，则称为BCNF。
               结论：一个满足BCNF的关系模式，应有如下性质。
               （1）所有非主属性对每一个码都是完全函数依赖。
               （2）所有非主属性对每一个不包含它的码，也是完全函数依赖。
               （3）没有任何属性完全函数依赖于非码的任何一组属性。
               例如，设R（Pno，Pname，Mname）的属性分别表示零件号、零件名和厂商名，如果约定，每种零件号只有一个零件名，但不同的零件号可以有相同的零件名；每种零件可以有多个厂商生产，但每家厂商生产的零件应有不同的零件名。这样我们可以得到如下一组函数依赖：
               Pno→Pname，（Pname，Mname）→Pno
               由于该关系模式R中的候选码为（Pname，Mname）或（Pno，Mname），因而关系模式R的属性都是主属性，不存在非主属性对码的传递依赖，所以R是3NF的。但是，主属性Pname传递依赖于码（Pname，Mname），因此R不是BCNF的。当一种零件由多个生产厂家生产时，零件名与零件号间的联系将多次重复，带来冗余和操作异常现象。若将R分解成：
               R1（Pno，Pname）和R2（Pno，Mname）
               就可以解决上述问题，并且分解后的关系模式R1、R2都属于BCNF。
               4NF（第四范式）
               【定义7.14】关系模式R∈1NF，若对于R的每个非平凡多值依赖X→→Y且时，X必含有码，则关系模式R（U，F）∈4NF。
               4NF是限制关系模式的属性间不允许有非平凡且非函数依赖的多值依赖。
               注意：如果只考虑函数依赖，关系模式最高的规范化程度是BCNF；如果考虑多值依赖，关系模式最高的规范化程度是4NF。
               连接依赖5NF
               连接依赖：当关系模式无损分解为n个投影（n>2）会产生一些特殊的情况。下面考虑供应商数据库中SPJ关系的一个具体的值，如下图所示。
               
               关系SPJ是三个二元投影的连接
               第一次SP、PJ投影连接“”起来的结果比原始SPJ关系多了一个元组“S2，P1，J2”，即上图中带下画线的元组。第二次连接的结果去掉了多余的元组，从而恢复了原始的关系SPJ。在这种情况下，原始的SPJ关系是可3分解的。注意，无论我们选择哪两个投影作为第一次连接，结果都是一样的，尽管在每种情况下中间结果不同。
               SPJ的可3分解性是基本与时间无关的特性，是关系模式的所有合法值满足的特性，也就是说，这是关系模式满足一个特定的与时间无关的完整性约束。将这种约束简称为3D（3分解）约束。上述情况就是连接依赖要研究的问题。
               连接依赖：如果给定一个关系模式R，R1，R2，R3，…，Rn是R的分解，那么称R满足连接依赖JD*｛R1，R2，R3，…，Rn｝，当且仅当R的任何可能出现的合法值都与它在R1，R2，R3，…，Rn上的投影等价。
               形式化地说，若R=R1∪R2∪…∪Rn，且，则称R满足连接依赖JD*｛R1，R2，R3，…，Rn｝。如果某个Ri，就是R本身，则连接依赖是平凡的。
               为了进一步理解连接依赖的概念，我们考虑银行数据库中的子模式：贷款（L-no，Bname，C-name，amount）。其中：
               .贷款号为L-no的贷款是由机构名为Bname贷出的。
               .贷款号为L-no的贷款是贷给客户名为C-name的客户。
               .贷款号为L-no的贷款的金额是amount。
               我们可以看到这是一个非常直观的逻辑蕴涵连接依赖：
               JD*（（L-no，Bname），（L-no，C-name），（L-no，amount））
               这个例子说明了连接依赖很直观，符合数据库设计的原则。
               【定义7.15】一个关系模式R是第五范式（也称投影-连接范式PJNF），当且仅当R的每一个非平凡的连接依赖都被R的候选码所蕴涵，记作5NF。
               “被R的候选码所蕴涵”的含义可通过SPJ关系来理解。关系模式SPJ并不是5NF的，因为它满足一个特定连接依赖，即3D约束。这显然没有被其唯一的候选码（该候选码是所有属性的组合）所蕴涵。其区别是，关系模式SPJ并不是5NF，因为它是可被3分解的，可3分解并没有为其（Sno，Pno，Jno）候选码所蕴涵。但是将SPJ3分解后，由于3个投影SP、PJ、JS不包括任何（非平凡的）连接依赖，因此它们都是5NF的。
 
       数据库
        数据库（DataBase，DB）是指长期存储在计算机内的、有组织的、可共享的数据集合。数据库中的数据按一定的数据模型组织、描述和存储，具有较小的冗余度、较高的数据独立性和易扩展性，并可为各种用户共享。
        系统使用的所有数据存储在一个或几个数据库中。
 
       数据库设计
        数据库的设计质量对整个系统的功能和效率有很大的影响。数据库设计的核心问题是：从系统的观点出发，根据系统分析和系统设计的要求，结合选用的数据库管理系统，建立一个数据模式。设计的基本要求是：
        .符合用户需求，能正确反映用户的工作环境
        .设计与所选用的DBMS所支持的数据模式相匹配
        .数据组织合理，易操作、易维护、易理解
               数据库设计步骤
               数据库的设计过程可以分为4个阶段，即用户需求分析、概念结构设计、逻辑结构设计和物理结构设计。下图反映和分析了这一设计过程，其中：
               
               数据库设计步骤
               .用户需求分析是对现实世界的调查和分析
               .概念结构设计是从现实世界向信息世界的转换。根据用户需求来进行数据库建模，也称为概念模型，常用实体关系模型表示。
               .逻辑结构设计是从信息世界向数据世界的转化。将概念模型转化为某种数据库管理系统所支持的数据模型。
               .物理结构设计是为数据模型选择合适的存储结构和存储方法。
               用户需求分析
               用户需求分析需要结合具体的业务需求分析，确定信息系统的各类使用者以及管理员对数据及其处理、数据安全性和完整性的要求。主要设计如下三方面：
               （1）系统应用环境分析。
               系统应用环境及系统所服务和运行的特殊组织环境。不同业务单位有不同的组织结构和业务工作流程。环境的特殊性将决定数据库的整体设计思路和风格。
               （2）用户数据需求及加工分析。
               用户需求及加工分析指用户希望从数据库中获得那些信息以及对信息的处理要求。由此决定数据库中应该存储哪些信息以及对数据需要进行哪些加工处理，包括在处理过程中特定的查询要求、响应时间要求，以及数据安全性、保密性、完整性和一致性等方面的要求，应在此基础上编制数据字典。
               （3）系统约束条件分析。
               系统约束条件分析及分析现有系统的规模、结构、资源和地理分布，明确现有系统存在的种种限制或约束，从而使系统设计不至于脱离实际条件，确保系统设计顺利实施。
               数据库概念结构设计
               概念结构设计是指由现实世界的各种客观事物及其联系转化为信息世界中的信息模型的过程，即为数据库的概念结构设计。E-R模型即实体-联系模型是描述数据库概念结构的有力工具。下面结合实例说明E-R模型的构建。
               在一个政府部门中存在着多个不同科室，每一个由若干名科员构成，每个科室都有一名主管上级领导，科室公务员负责为前来机关办事的群众提供相关的服务。现分别画出各个科室的E-R模型图，再画出整个机关的E-R模型。
               一个科室结构应包括：
               （1）实体，即上级领导、科室、科员、群众。
               （2）实体联系，主管领导与科室之间是一对多的关系，科室与科员之间的联系也是一对多的关系，科员与群众之间是多对多的关系。
               （3）各个实体所具有的属性。
               .主管上级领导，属性可以有编号、姓名、性别、年龄、职务、任职时间、参加工作时间、入党时间、学历
               .科室的属性可以包括科室号
               .科员的属性包括编号、姓名、性别、年龄、职称、参加工作时间、入党时间、学历
               .群众属性包括服务日期、服务事宜、处理结果
               .服务，包括服务日期、服务事宜、处理结果
               通过以上分析，可以得到如下的E-R模型，如下图所示（部分属性）。
               
               科室E-R模式图
               数据库逻辑结构设计
               逻辑结构设计的任务是要将概念结构设计阶段完成的概念模型转换成能被选定的数据库管理系统支持的数据模型。现行的数据库管理系统一般支持网状、层次和关系三种数据模型中的一种，其中关系型的数据模型在DBMS中的应用和支持较为广泛，已成为主流。
               下面简单介绍一下由E-R模型转换为关系数据模型的转化规则。在关系数据模型下，数据的逻辑结构是一张二维表，每个关系为一张二维表格。E-R模型转换为关系数据模型的转化规则如下。
               .每一实体及其属性对应于一个关系模式。实体名作为关系名，实体的属性作为对应关系的属性。所谓关系模式，就是对关系的描述，用关系名（属性1、属性2、属性3，……属性n）来表示。
               .两两实体之间的联系及其属性一般对应一个关系模式，联系名作为对应的关系名，联系的属性作为对应关系的属性；不带属性的联系可以去掉。
               .实体和联系中关键字属性在关系模式中仍作为关键字。
               上图中所示的实体关系图可以按照这些转换规则进行转化得到如下对应的关系模型。
               .主管上级领导，编号、姓名、性别、年龄、职务、任职时间、参加工作时间、入党时间、学历
               .科室，包括主管上级领导编号、科室号
               .科员，包括科室号、编号、姓名、性别、年龄、职称、参加工作时间、入党时间、学历
               .群众，包括来访者编号、姓名、性别、年龄、来访日期、服务事宜
               .服务，包括受理公务员编号、来访者编号、服务日期、服务事宜、处理结果
               不同的系统配备的数据库管理系统性能不同，因而必须结合具体DBMS的性能和要求将一般数据模型转换成所选用的数据管理系统支持的数据模型，若选用的DBMS支持层次、网络模型，则还要完成从关系模型向层次或网络模型的转换。
               数据库物理结构设计
               数据库的物理设计以逻辑结构设计的结果为输入，结合关系数据库系统的功能和应用环境、存储设备等具体条件为数据模型选择合适的存储结构和存储方法。从而提高数据库的效率。物理结构设计的主要任务如下。
               （1）确定存储结构。
               根据用户对数据结构和处理的要求，权衡数据存取时间、空间利用率和维护代价等三方面的利弊，综合考虑存储效率、维护成本等相关因素，从数据库管理系统提供的各种存储结构（例如顺序存储结构、索引存储结构，等等）中，选取合适的结构并加以实现。
               （2）选择和调整存储路径。
               数据库必须支持多个用户的多种应用，因此必须提供多个存取入口、多条存取路径，建立多个辅助索引。此过程中需要考虑一些问题，例如如何选取合适的数据项建立索引，如何建立辅助索引从而达到检索效率和存储空间的统一等。
               （3）确定数据存储位置。
               按照不同的应用可将数据分为若干个组。根据各组数据利用频率和存储要求的不同，各类数据的存放位置、存储设备以及区域划分都应有所不同。应该把存取频率和存取速度要求较高的数据存储在高速存储器上，把存取频率和存取速度要求较低的数据存储在低速存储器上。
               （4）确定存储分配。
               大多数据库管理系统会提供一些存储分配参数，例如溢出区大小、块大小、缓冲区大小和个数等，设计人员应全面考虑这些参数，以进行物理优化。
               （5）确定数据的完整性与安全性约束。
               进行物理设计时不仅要考虑所选用数据库管理系统提供的安全机制和完整性约束，还要考虑用户使用制度、应用程序、计算机系统等各个涉及具体应用的方面。
               （6）考虑数据恢复方案。
               数据库的物理设计阶段也要考虑数据库的恢复问题，采取必要的物理措施和手段，为突发事件和故障后的恢复做好准备，提供必要的物理工具。
 
       数据流
        数据流由一组固定成分的数据组成，表示数据的流向。在DFD中，数据流的流向可以有以下几种：从一个加工流向另一个加工；从加工流向数据存储（写）；从数据存储流向加工（读）；从外部实体流向加工（输入）；从加工流向外部实体（输出）。
        DFD中的每个数据流用一个定义明确的名字表示。除了流向数据存储或从数据存储流出的数据流不必命名外，每个数据流都必须有一个合适的名字，以反映该数据流的含义。
        数据流或者由具体的数据属性（也称为数据结构）构成，或者由其他数据流构成。组合数据流是由其他数据流构成的数据流，它们用于在高层的数据流图中组合相似的数据流，以使数据流图更便于阅读。
        控制流是对数据流图的补充，采用虚线表示，是对由触发系统功能的事件进行描述。
        另外，一个加工可以有多个输入数据流和多个输出数据流，此时可以加上一些扩充字符符号或图形元素来描述多个数据流之间的关系。如：
        （1）星号（*）。星号表示数据流之间存在“与”关系。如果是输入流则表示所有输入数据流全部到达后才能进行加工处理；如果是输出流则表示加工结束将同时产生所有的输出数据流。
        （2）加号（+）。加号表示数据流之间存在“或”关系。如果是输入流则表示其中任何一个输入数据流到达后就能进行加工处理；如果是输出流则表示加工处理的结果是至少产生其中一个输出数据流。
        （3）异或（⊕）。异或表示数据流之间存在“互斥”关系。如果是输入流则表示当且仅当其中一个输入流到达后才能进行加工处理；如果是输出流则表示加工处理的结果是仅产生这些输出数据流中的一个。
 
       索引
        在数据库系统中，索引是一种可选结构，其目的是提高数据访问速度。利用索引可提高用户访问数据的速度，或直接从索引中独立检索数据。如果对索引的配置和使用进行了优化，那么索引能大大降低数据文件的I/O操作并提高系统性能。
        但是在为一个表创建索引之后，Oracle将自动维护这个索引。当用户在表中插入、更新或删除记录时，系统将自动更新与该表相关的索引。一个表可以有任意数量的索引，但一个表的索引越多，用户在该表中插入、更新或删除记录时所造成的系统开销也越大。其原因是无论何时更新表，系统都必须更新与之相关的索引。
        索引是建立在表的一个或多个字段之上的。索引的作用大小取决于该字段或字段集的选择性。所谓选择性，是指索引能降低数据集中的程度。如果表中与某个索引相关的字段值各不相同，那么该索引就有很好的选择性。一个选择性很差的索引的例子，是基于字段值仅为true/false的字段创建的索引，因为表中很多记录该字段的字段值都相同。一个索引可能只能帮助管理员降低检索的记录数，而不能惟一地确定一条记录。例如：如果为一个表的LastName字段创建了一个索引，现在用户需要搜索John Smith，那么这个索引将返回LastName字段值为Smith的所有记录，因而用户还不得不在返回的记录中搜索含John的记录。索引的选择性越好，就越有助于降低返回记录的数量，从而提高数据访问速度。下面介绍有效创建和使用索引的技巧和方法。
        . 索引和降低系统处理的数据量。
        索引的主要作用之一就是降低系统处理的数据量。对CPU使用和等待完成I/O操作的时间上，I/O操作引起的系统开销都是非常昂贵的。降低I/O操作可提高系统性能和处理能力。如果不使用索引，那么为了找到特定的数据，系统将不得不扫描表中的所有数据。
        例如如下查询语句：
        
        如果不使用索引，系统必须扫描整个emp表并检查表中每条记录的employee_id字段的值。如果emp表很大，那么这个操作可能意味着数量巨大的I/O读写和很长的处理时间。
        如果为emp表的employee_id字段创建了索引，那么系统将遍历该索引并找到用户所查询记录的ID。找到记录ID之后，只需一条额外的I/O操作就能检索到用户所需的数据。
        用于说明这个问题的最好例子，是只需查找一条记录的情况。在表的每条记录中，类似employee_id这样的字段的值可能在整个表中都是惟一的。这意味着查询结果值返回一条记录，这种查询的效率是非常高的。
        在某些情况下，索引必须返回大量数据。如下面的例子：
        
        这个查询语句很可能返回大量数据，因为索引操作返回了大量记录的ID，并且系统必须独立访问这些记录的ID，所以这种情况下，不使用索引可能比使用索引的效率更高，直接进行表扫描可能效率更高。不同情况下，采用哪种查寻方法更好，很大程度上取决于表的数据量和组织形式。
        对于不同的数据，在某些情况下位图索引可能非常有用，而在另外一些情况下，使用位图索引可能没有任何好处。
        . 索引和更新。
        如果对表创建了索引，那么更新、插入和删除表中的记录都将导致额外的系统开销。在系统提交这些操作之前，系统将会更新所有与该表相关的索引。这可能需要花费很长时间，并额外增加一定的系统开销。
        . 在字段选择性很低的情况下适用索引。
        在某些情况下，表中的某些字段的选择性可能很低。开发人员没必要为所有表创建索引，实事上，在某些情况下索引引起的问题比解决的问题更多。在很多情况下，需要反复试验，才能确定一个索引是否有助于提高系统性能。
        但是，位图索引能在字段选择性不高的情况下工作得很好。一个位图索引可以和其他位图索引联合使用，以降低系统检索的数据集。对于某些值为true/false、yes/no或其他小范围数据的字段，建立位图索引是非常合适的。请记住：位图索引所占用的空间，是随着与该索引相关的字段的不同值的数量的增加而增加的。
        如果决定创建一个索引，那么确定为哪些字段创建索引是非常重要的。对于不同的表，可能会选择一个或多个字段创建索引。可使用如下方法来确定在哪些字段上创建索引：
        ①选择那些最常出现在where子句中的字段。经常被访问的字段最可能受益于索引。
        ②经常用于连接表的字段是创建索引的必然候选字段。
        ③必须注意索引导致的查询语句性能的提高与更新数据时性能的降低之间的平衡。
        ④经常被修改的字段不适合创建索引，其原因是，更新索引将增加系统开销。
        在某些情况下，使用复合索引的效率可能比使用简单索引的效率更高。下面的一些例子说明了应当在何种情况下使用复合索引。
        ①某两个字段单独来看都不具有惟一性，但结合在一起却有惟一性，那么这种情况下，复合索引将工作得很好。例如：A字段和B字段都几乎没有惟一性值，但绝大多数情况下，字段A和B的某个特定组合却具有惟一性特点。那么在检索数据时，可在where子句重视and操作符来将这两个字段连接在一起。
        ②如果select语句中的所有值都位于复合索引中，那么Oracle将不会检索表，而直接从索引中返回数据。
        ③如果多个查询语句的where子句中作为查询条件的字段都不相同，但返回的记录相同，那么应当考虑利用这些字段创建一个复合索引。
        在创建索引之后，开发人员应当定期利用SQL TRACE工具或EXPLAIN PLAN来察看用户查询是否充分利用了索引。很有必要花费一定精力来试验使用索引和未使用索引在效率上的差别，以判断索引所耗费资源是否物有所值。
        应该删除那些不经常使用的索引。可使用alter index monitoring usage语句来跟踪索引的使用情况。还可以从系统表all_indexes、user_indexes和dba_indexes中查询用户访问索引的频率。
        如果为一个不适合创建索引的字段或表创建了索引，那么这可能会导致系统能力的下降。而如果创建的索引合理，那么这将降低系统的I/O操作并加快访问速度，从而大大提高系统性能。
 
       销售管理
        物联网系统具有快速的信息传递能力，及时获取销货信息，汇总传递给上一级分销商或制造商，进行补货等操作。及时准确的信息传递，有利于上游供应商合理安排生产计划或者补货计划，降低运营风险。在货物调配环节，RFID技术的支持大大提高了货物拣选、配送及分发的速度，还在此过程中实时监督货物流向，保障其准时准点到达，实现了销售环节的畅通。对零售商来说，合理的库存数量，保证了定单供货，降低脱销的可能性和库存积压的风险。将库存水平保持在最小安全库存量，释放占有的资金，有助于企业投资管理。并且，可定位之作品能够的产品，零售商可实时监控仓库库存水平，仓储货物种类等信息，一定程度上帮助销售。
   题号导航      2024年下半年 系统分析师 下午试卷 案例   本试卷我的完整做题情况  
1 /
2 /
3 /
4 /
5 /
 
第1题    在手机中做本题