免费智能真题库 > 历年试卷 > 系统分析师 > 2013年上半年 系统分析师 上午试卷 综合知识
  第41题      
  知识点:   实体联系模型   数据库设计阶段   需求分析   概念结构设计   结构设计   逻辑结构设计   设计阶段   数据库   数据库逻辑结构设计   数据库设计   物理结构设计
  关键词:   E-R   设计阶段   数据库   需求分析   数据   需求        章/节:   数据库系统       

 
数据库设计的需求分析概念结构设计、逻辑结构设计和物理结构设计的四个阶段中,基本E-R图是(41):数据库逻辑结构设计阶段的主要工作步骤依次为(42)。
 
 
  A.  需求分析阶段形成的文档,并作为概念结构设计阶段的设计依据
 
  B.  逻辑结构设计阶段形成的文档,并作为概念结构设计阶段的设计依据
 
  C.  概念结构设计阶段形成的文档,并作为逻辑结构设计阶段的设计依据
 
  D.  概念结构设计阶段形成的文档,并作为物理设计阶段的设计依据
 
 
 

 
  第44题    2013年上半年  
   50%
给定关系模式科室K (科室号,科室名,负责人,科室电话)、医生Y (医生号,医生名,性别,科室号,联系电话,家庭地址)和患者B (..
  第5题    2014年上半年  
   40%
使用UML进行关系数据库的(5)时,需要设计出表达持久数据的实体类及其联系,并将它们映射为数据库表和视图等。
  第41题    2010年上半年  
   59%
确定系统边界应在数据库设计的(41)阶段进行;关系规范化是在数据库设计的(42)阶段进行。
   知识点讲解    
   · 实体联系模型    · 数据库设计阶段    · 需求分析    · 概念结构设计    · 结构设计    · 逻辑结构设计    · 设计阶段    · 数据库    · 数据库逻辑结构设计    · 数据库设计    · 物理结构设计
 
       实体联系模型
        E-R模型简称E-R图,它是描述概念世界,建立概念模型的实用工具。E-R图包括3个要素:
        (1)实体(型):用矩形框表示,框内标注实体名称。
        (2)属性:用椭圆形表示,并用连线与实体连接起来。
        (3)实体之间的联系:用菱形框表示,框内标注联系名称,并用连线将菱形框分别与有关实体相连,并在连线上注明联系类型。
        例如,下图就是一个教学系统的E-R图(为了简单起见,省略了部分实体的属性和联系的属性)。
        
        某教学系统E-R图
               联系的类型
               E-R图中的联系归结为三种类型:
               (1)一对一联系(1:1)。设A、B为两个实体集。若A中的每个实体至多和B中的一个实体有联系,反过来,B中的每个实体至多和A中的一个实体有联系,称A对B或B对A是1:1联系。注意:1:1联系不一定都是一一对应的关系。可能存在着无对应。例如,在上图中,一个班只有一个班主任,一个班主任不能同时在其他班再兼任班主任,由于老师紧缺,某个班的班主任也可能暂缺。
               (2)一对多联系(1:n)。如果A实体集中的每个实体可以和B中的几个实体有联系,而B中的每个实体至少和A中的一个实体有联系,那么A对B属于1:n联系。例如,在上图中,一个班级有多个学生,而一个学生只能编排在一个班级,班级与学生属于一对多的联系。
               (3)多对多联系(mn)。若实体集A中的每个实体可与和B中的多个实体有联系,反过来,B中的每个实体也可以与A中的多个实体有联系,称A对B或B对A是mn联系。例如,在上图中,一个学生可以选修多门课程,一门课程由多个学生选修,学生和课程间存在多对多的联系。
               有时联系也有属性,这类属性不属于任一实体,只能属于联系。
               E-R图的集成
               在数据库的概念结构设计过程中,先设计各子系统的局部E-R图,设计过程可分为以下几个步骤:
               (1)确定局部视图的范围。
               (2)识别实体及其标识。
               (3)确定实体间的联系。
               (4)分配实体及联系的属性。
               各子系统的局部E-R图设计好后,下一步就是要将所有的分E-R图综合成一个系统的总体E-R图,一般称为视图的集成。视图集成通常有两种方式:
               (1)多个局部E-R图一次集成。这种方式比较复杂,做起来难度较大。
               (2)逐步集成,用累加的方式一次集成两个局部E-R图。这种方式每次只集成两个局部E-R图,可以降低复杂度。
               由于各子系统应用所面临的问题不同,且通常是由不同的设计人员进行局部视图设计,这就导致各个局部E-R图之间必定会存在许多不一致的问题,称之为冲突。因此合并E-R图时并不能简单地将各个局部E-R图画到一起,而是必须着力消除各个局部E-R图中的不一致,以形成一个能为全系统中所有用户共同理解和接受的统一的概念模型。
               各局部E-R图之间的冲突主要有3类:
               (1)属性冲突:包括属性域冲突和属性取值冲突。属性冲突理论上好解决,只要换成相同的属性就可以了,但实际上需要各部门协商,解决起来并不简单。
               (2)命名冲突:包括同名异义和异名同义。处理命名冲突通常也像处理属性冲突一样,通过讨论和协商等行政手段加以解决。
               (3)结构冲突:包括同一对象在不同应用中具有不同的抽象,以及同一实体在不同局部E-R图中所包含的属性个数和属性排列次序不完全相同。对于前者的解决办法是把属性变换为实体或实体变换为属性,使同一对象具有相同的抽象。对于后者的解决办法是使该实体的属性取各局部E-R图中属性的并集,再适当调整属性的次序。
               另外,实体间的联系在不同的局部E-R图中可能为不同的类型,其解决方法是根据应用的语义对实体联系的类型进行综合或调整。
               在初步的E-R图中,可能存在一些冗余的数据和实体间冗余的联系。冗余数据和冗余联系容易破坏数据库的完整性,给数据库维护增加困难,应当予以消除。消除冗余的主要方法为分析方法,即以数据字典和数据流图为依据,根据数据字典中关于数据项之间逻辑关系的说明来消除冗余。
               在集成之后,还需要对E-R模型进行评审。评审的作用在于确认建模任务是否全部完成,通过评审可以避免重大的疏漏或错误。
               E-R图向关系模式的转换
               E-R图向关系模式的转换属于数据库的逻辑设计阶段的工作,该阶段需要把E-R模型转换为某种DBMS能处理的关系模式,具体转换规则如下:
               (1)一个实体转换为一个关系模式,实体的属性就是关系的属性,实体的码(关键字)就是关系的码。
               (2)一个1:1联系可以转换为一个独立的关系模式,也可以与任意一端对应的关系模式合并。如果转换为一个独立的模式,则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性,每个实体的码均是该关系的候选键。如果与某一端实体对应的关系模式合并,则需要在该关系模式的属性中加入另一个关系模式的码和联系本身的属性。
               (3)一个1:n联系可以转换为一个独立的关系模式,也可以与任意n端对应的关系模式合并。如果转换为一个独立的模式,则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性,而关系的码为n端实体的码。如果与n端实体对应的关系模式合并,则需要在该关系模式的属性中加入1端关系模式的码和联系本身的属性。
               (4)一个mn联系转换为一个独立的关系模式,与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性,而关系的码为各实体码的组合。
               (5)三个以上实体间的一个多元联系可以转换为一个独立的关系模式,与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性,而关系的码为各实体码的组合。
               另外,还有4种情况是需要特别注意的:
               (1)多值属性的处理。如果E-R图中某实体具有一个多值属性,则应该进行优化,把该属性提升为一个实体。或者在转化为关系模式时,将实体的码与多值属性单独构成一个关系模式。
               (2)BLOB型属性的处理。典型的BLOB是一张图片或一个声音文件,由于它们的容量比较大,必须使用特殊的方式来处理。处理BLOB的主要思想就是让文件处理器(如数据库管理器)不去理会文件是什么,而是关心如何去处理它。因此,从优化的角度考虑,应采用的设计方案是将BLOB字段与关系的码独立为一个关系模式。
               (3)派生属性的处理。因为派生属性可由其他属性计算得到,因此,在转化成关系模式时,通常不转换派生属性。
               (4)在对象-关系数据模型中,这里的关系模式就对应类,关系模式的属性就对应类的属性。
 
       数据库设计阶段
        基于DBS生存期的数据库设计分成5个阶段,分别为规划、需求分析、概念设计、逻辑设计和物理设计。
               规划
               规划阶段的主要任务是进行建立数据库的必要性及可行性分析,确定DBS在组织和信息系统中的地位,以及各个数据库之间的联系。有关这方面的详细知识,请阅读9.5节。
               需求分析
               需求分析可以通过3步来完成,即需求信息的收集、分析整理和评审,其目的在于对系统的应用情况做全面详细的调查,确定企业组织的目标,收集支持系统总的设计目标的基础数据和对这些数据的要求,确定用户的需求,并把这些要求写成用户和数据设计者都能够接受的文档。有关这方面的详细知识,请阅读9.6节。
               概念设计
               概念设计(概念结构设计)阶段的目标是对需求说明书提供的所有数据和处理要求进行抽象与综合处理,按一定的方法构造反映用户环境的数据及其相互联系的概念模型,即用户的数据模型或企业数据模型。这种概念数据模型与DBMS无关,是面向现实世界的、极易为用户所理解的数据模型。为保证所设计的概念数据模型能正确、完全地反映用户的数据及其相互关系,便于进行所要求的各种处理,在本阶段设计中可吸收用户参与和评议设计。在进行概念结构设计时,可先设计各个应用的视图,即各个应用所看到的数据及其结构,然后再进行视图集成,以形成一个单一的概念数据模型。这样形成的初步数据模型还要经过数据库设计者和用户的审查与修改,最后形成所需的概念数据模型。
               有关概念模型的建立,请阅读3.6.3节。对概念模型的要求是:
               (1)概念模型是对现实世界的抽象和概括,它应真实、充分地反映现实世界中事物和事物之间的联系,有丰富的语义表达能力,能表达用户的各种需求,包括描述现实世界中各种对象及其复杂联系、用户对数据对象的处理要求和手段。
               (2)概念模型应简洁、明晰,独立于机器、容易理解、方便数据库设计人员与应用人员交换意见,使用户能积极地参与数据库的设计工作。
               (3)概念模型应易于变动。当应用环境和应用要求改变时,容易对概念模型修改和补充。
               (4)概念模型应很容易向关系、层次或网状等各种数据模型转换,易于从概念模式导出与DBMS有关的逻辑模式。
               逻辑设计
               逻辑设计(逻辑结构设计)主要是把概念模式转换成DBMS能处理的模式。转换过程中要对模式进行评价和性能测试,以便获得较好的模式设计。逻辑设计的主要内容包括初始模式的形成、子模式设计、应用程序设计梗概、模式评价、修正模式(通过模式分解或模式合并来实现规范化)。
               逻辑设计的目的是把概念设计阶段设计好的基本E-R图转换为与选用的具体机器上的DBMS所支持的数据模型相符合的逻辑结构,包括数据库模式和外模式。
               逻辑设计过程中的输入信息有:
               (1)独立于DBMS的概念模式,即概念设计阶段产生的所有局部和全局概念模式。
               (2)处理需求,即需求分析阶段产生的业务活动分析结果。
               (3)约束条件,即完整性、一致性、安全性要求及响应时间要求等。
               (4)DBMS特性,即特定的DBMS所支持的模式、子模式和程序语法的形式规则。
               逻辑设计过程输出的信息有DBMS可处理的模式、子模式、应用程序设计指南、物理设计指南。
               物理设计
               物理设计(物理结构设计)是指对一个给定的逻辑数据模型选取一个最适合应用环境的物理结构的过程,所谓数据库的物理结构主要指数据库在物理设备上的存储结构和存取方法。
               物理设计的步骤为:
               (1)设计存储记录结构,包括记录的组成、数据项的类型和长度,以及逻辑记录到存储记录的映射。
               (2)确定数据存储安排。
               (3)设计访问方法,为存储在物理设备上的数据提供存储和检索的能力。
               (4)进行完整性和安全性的分析、设计。
               (5)程序设计。
 
       需求分析
        需求分析的方法种类繁多,不过如果按照分解的方式不同,可以很容易地划分出几种大类型:
        (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模型来描述概念结构。
        概念结构设计的基本方法有自顶向下、自底向上、逐步扩张、混合策略。
        扩充的E-R模型概念主要包括以下内容。
        (1)数据的抽象。对象之间两种基本联系是聚集和概括。
        (2)依赖关系。一个实体的存在必须以另一个实体的存在为前提。通常将前者称为弱实体,用双线框表示,用指向弱实体的箭头表明依赖关系。
 
       结构设计
        多媒体课件的结构规定了教学软件中各部分教学内容的相互关系及呈现的形式,它反映了教学软件的主要框架及其教学功能,多媒体课件的系统结构大多采用非线性的超媒体结构,在此基础上形成了以下四种组织结构方式。
        ①线性结构:学生顺序地接收信息,从当前帧到下一帧,是一个事先设置好的序列。
        ②树状结构:学生沿着一个树状分支展开学习活动,该树状结构按教学内容的自然逻辑形成。
        ③网状结构:多媒体课件的网状结构是超文本结构,学生可在内容单元之间自由航行,没有预设路径的约束。
        ④复合结构:学生可以在一定范围内自由地航行,但同时受主流信息的线性引导和分层逻辑组织的影响。
 
       逻辑结构设计
        逻辑结构设计的目的是把概念设计阶段的基本E-R图转换成与选用的具体机器上的DBMS所支持的数据模型相符合的逻辑结构(包括数据库模式和外模式)。逻辑设计有以下3个步骤。
        (1)将概念模型(E-R图)转换为一般的关系、网状或层次模型。
        (2)将关系、网状或层次模型向特定的DBMS支持下的数据模型转换。
        (3)对数据模型进行优化。
 
       设计阶段
        设计阶段监理进行质量控制的要点如下。
        (1)了解建设单位的建设需求和对信息系统安全性的要求,协助建设单位制定项目质量目标规划和安全目标规划。
        (2)对各种设计文件提出设计质量标准。
        (3)进行设计过程跟踪,及时发现质量问题,并及时与承建单位协调解决。审查阶段性成果,并提出监理意见。审查承建单位提交的总体设计方案,审查承建单位对关键部位的测试方案。
        (4)协助承建单位建立质量保障体系。
        (5)协助承建单位完善现场质量管理制度。
        (6)组织设计文件及设计方案交底会,制定质量要求标准。
 
       数据库
        数据库(DataBase,DB)是指长期存储在计算机内的、有组织的、可共享的数据集合。数据库中的数据按一定的数据模型组织、描述和存储,具有较小的冗余度、较高的数据独立性和易扩展性,并可为各种用户共享。
        系统使用的所有数据存储在一个或几个数据库中。
 
       数据库逻辑结构设计
        逻辑结构设计的任务是要将概念结构设计阶段完成的概念模型转换成能被选定的数据库管理系统支持的数据模型。现行的数据库管理系统一般支持网状、层次和关系三种数据模型中的一种,其中关系型的数据模型在DBMS中的应用和支持较为广泛,已成为主流。
        下面简单介绍一下由E-R模型转换为关系数据模型的转化规则。在关系数据模型下,数据的逻辑结构是一张二维表,每个关系为一张二维表格。E-R模型转换为关系数据模型的转化规则如下。
        .每一实体及其属性对应于一个关系模式。实体名作为关系名,实体的属性作为对应关系的属性。所谓关系模式,就是对关系的描述,用关系名(属性1、属性2、属性3,……属性n)来表示。
        .两两实体之间的联系及其属性一般对应一个关系模式,联系名作为对应的关系名,联系的属性作为对应关系的属性;不带属性的联系可以去掉。
        .实体和联系中关键字属性在关系模式中仍作为关键字。
        上图中所示的实体关系图可以按照这些转换规则进行转化得到如下对应的关系模型。
        .主管上级领导,编号、姓名、性别、年龄、职务、任职时间、参加工作时间、入党时间、学历
        .科室,包括主管上级领导编号、科室号
        .科员,包括科室号、编号、姓名、性别、年龄、职称、参加工作时间、入党时间、学历
        .群众,包括来访者编号、姓名、性别、年龄、来访日期、服务事宜
        .服务,包括受理公务员编号、来访者编号、服务日期、服务事宜、处理结果
        不同的系统配备的数据库管理系统性能不同,因而必须结合具体DBMS的性能和要求将一般数据模型转换成所选用的数据管理系统支持的数据模型,若选用的DBMS支持层次、网络模型,则还要完成从关系模型向层次或网络模型的转换。
 
       数据库设计
        数据库的设计质量对整个系统的功能和效率有很大的影响。数据库设计的核心问题是:从系统的观点出发,根据系统分析和系统设计的要求,结合选用的数据库管理系统,建立一个数据模式。设计的基本要求是:
        .符合用户需求,能正确反映用户的工作环境
        .设计与所选用的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)考虑数据恢复方案。
               数据库的物理设计阶段也要考虑数据库的恢复问题,采取必要的物理措施和手段,为突发事件和故障后的恢复做好准备,提供必要的物理工具。
 
       物理结构设计
        对于给定的基本数据模型选取一个最适合应用环境的物理结构的过程,称为物理结构设计。对于一个给定的逻辑数据模式选取一个最适合应用环境的物理结构的过程,称为数据库的物理结构设计。
   题号导航      2013年上半年 系统分析师 上午试卷 综合知识   本试卷我的完整做题情况  
1 /
2 /
3 /
4 /
5 /
6 /
7 /
8 /
9 /
10 /
11 /
12 /
13 /
14 /
15 /
 
16 /
17 /
18 /
19 /
20 /
21 /
22 /
23 /
24 /
25 /
26 /
27 /
28 /
29 /
30 /
 
31 /
32 /
33 /
34 /
35 /
36 /
37 /
38 /
39 /
40 /
41 /
42 /
43 /
44 /
45 /
 
46 /
47 /
48 /
49 /
50 /
51 /
52 /
53 /
54 /
55 /
56 /
57 /
58 /
59 /
60 /
 
61 /
62 /
63 /
64 /
65 /
66 /
67 /
68 /
69 /
70 /
71 /
72 /
73 /
74 /
75 /
 
第41题    在手机中做本题