免费智能真题库 > 历年试卷 > 数据库系统工程师 > 2016年上半年 数据库系统工程师 上午试卷 综合知识
  第32题      
  知识点:   规范化   逻辑结构设计   数据库设计   数据库
  关键词:   关系规范化   数据库   数据        章/节:   数据库设计       

 
关系规范化是在数据库设计的(32)阶段进行。
 
 
  A.  需求分析
 
  B.  概念设计
 
  C.  逻辑设计
 
  D.  物理设计
 
 
 

 
  第41题    2011年上半年  
   35%
某医院管理系统部分关系模式为:科室(科室号,科室名,负责人,电话)、病患(病历号,姓名,住址,联系电话)和职工(职工号,..
  第63题    2018年上半年  
   26%
下图所示的扩展E-R图中,属性“电话”属于(62),在逻辑结构设计中,该图中的(63)属性将不会被转换到关系模式中。<..
  第40题    2011年上半年  
   48%
某医院管理系统部分关系模式为:科室(科室号,科室名,负责人,电话)、病患(病历号,姓名,住址,联系电话)和职工(职工号,..
   知识点讲解    
   · 规范化    · 逻辑结构设计    · 数据库设计    · 数据库
 
       规范化
        关系数据库设计的方法之一就是设计满足适当范式的模式,通常可以通过判断分解后的模式达到几范式来评价模式规范化的程度。范式有: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的。
 
       逻辑结构设计
        逻辑结构设计即在概念结构设计的基础上进行数据模型设计,可以是层次模型、网状模型和关系模型,本节介绍如何在全局E-R图基础上进行关系模型的逻辑结构设计。逻辑结构设计阶段的主要工作步骤包括确定数据模型、将E-R图转换成为指定的数据模型、确定完整性约束和确定用户视图,如下图所示。
        
        逻辑结构设计阶段工作步骤
                      E-R图向关系模式的转换
                      E-R方法所得到的全局概念模型是对信息世界的描述,并不适用于计算机处理,为适合关系数据库系统的处理,必须将E-R图转换为关系模式。E-R图是由实体、属性和联系三要素构成的,而关系模型中只有唯一的结构——关系模式,通常采用下述方法加以转换。
                             实体向关系模式的转换
                             将E-R图中的实体逐一转换成为一个关系模式,实体名对应关系模式的名称,实体的属性转换为关系模式的属性,实体标识符就是关系的码。
                             联系向关系模式的转换
                             E-R图中的联系有三种:一对一联系(1:1)、一对多联系(1:*)和多对多联系(*:*)。针对这三种不同的联系,转换方法如下:
                             (1)一对一联系的转换。通常一对一联系不需要将其转换为一个独立的关系模式,只需要将联系归并到关联的两个实体的任一方,给待归并的一方实体属性集中增加另一方实体的码和该联系的属性即可,归并后的实体码保持不变。
                             (2)一对多联系的转换。通常一对多联系也不需要将其转换为一个独立的关系模式,只需要将联系归并到关联的两个实体的多方,给待归并的多方实体属性集中增加一方实体的码和该联系的属性即可,归并后的多方实体码保持不变。
                             (3)多对多联系的转换。多对多联系只能转换成一个独立的关系模式,关系模式的名称取联系的名称,关系模式的属性取该联系所关联的两个多方实体的码及联系的属性,关系的码是多方实体的码构成的属性组。
                      关系模式的规范化
                      由E-R图转换得来的初始关系模式并不能完全符合要求,还会有数据冗余、更新异常存在,这就需要经过进一步的规范化处理,具体步骤如下:
                      (1)根据语义确定各关系模式的数据依赖。在设计的前一阶段,只是从关系及其属性来描述关系模式,并没有考虑到关系模式中的数据依赖。关系模式包含着语义,要根据关系模式所描述的自然语义写出关系数据依赖。
                      (2)根据数据依赖确定关系模式的范式。由关系的码及数据依赖,根据规范化理论,就可以确定关系模式所属的范式,判定关系模式是否符合要求,即是否达到了3NF或4NF。
                      (3)如果关系模式不符合要求,要根据关系模式的分解算法对其进行分解,达到3NF、BCNF或4NF。
                      (4)关系模式的评价及修正。根据规范化理论,对关系模式分解之后,就可以在理论上消除冗余和更新异常。但根据处理要求,可能还需要增加部分冗余以满足处理要求,这就需要做部分关系模式的处理,分解、合并或增加冗余属性,提高存储效率和处理效率。
                      确定完整性约束
                      根据规范化理论确定了关系模式之后,还要对关系模式加以约束,包括数据项的约束、表级约束及表间约束,可以参照SQL标准来确定不同的约束,如检查约束、主码约束、参照完整性约束,以保证数据的正确性。
                      用户视图的确定
                      确定了整个系统的关系模式之后,还要根据数据流图及用户信息建立视图模式,提高数据的安全性和独立性。
                      (1)根据数据流图确定处理过程使用的视图。数据流图是某项业务的处理,使用了部分数据,这些数据可能要跨越不同的关系模式,建立该业务的视图,可以降低应用程序的复杂性,并提高数据的独立性。
                      (2)根据用户类别确定不同用户使用的视图。不同的用户可以处理的数据可能只是整个系统的部分数据,而确定关系模式时并没有考虑这一因素,如学校的学生管理,不同的院系只能访问和处理自己的学生信息,这就需要建立针对不同院系的视图达到这一要求,这样可以在一定程度上提高数据的安全性。
                      应用程序设计
                      应用程序设计与开发是数据库应用系统开发的重要组成内容,它应遵循应用软件开发的一般规律,即遵循常规的软件工程的方法。数据库应用系统开发是基于DBMS的二次开发,一方面是对用户信息的存储,另一方面就是对用户处理要求的实现,通常在设计过程中把数据存储的设计称为结构设计,处理的实现称为行为设计。在现阶段,还没有一种将两者合一的设计方法,因而称之为行为和结构分离的设计。
                      应用程序设计有两种方法:结构化设计方法和面向对象设计方法。在设计阶段就是从分析入手,得到结构化模型或面向对象模型。
                             结构化设计方法
                             结构化分析将数据和处理作为分析对象,数据的分析结果表示了现实世界中实体的属性及其之间的相互关系,而处理的分析结果则展现了系统对数据的加工和转换。面向数据流建模是目前仍然被广泛使用的方法之一,而DFD则是面向数据流建模中的重要工具,DFD将系统建模成输入一处理一输出的模型,即流入软件的数据对象,经由处理的转换,最后以结果数据对象的形式流出软件。DFD使用分层的方式表示,第一个数据流模型有时被称为第0层DFD或者环境数据流图。从整体上表现系统,随后的数据流图将改进第0层图,并增加细节信息。
                             除DFD外,在进行建模时,还可结合数据字典和加工处理说明对DFD进行补充。数据字典以一种准确的和无二义的方式定义所有被加工引用的数据流和数据存储,通常包括数据流条目、数据存储条目和数据项条目。数据流条目描述DFD中数据流的组成,数据存储条目描述DFD中数据存储文件的组成,而数据项条目则描述数据流或数据存储中所使用的数据项。加工处理的说明则可采用结构化自然语言、判定表和判定树等多种形式进行详细描述,其目的在于说明加工做什么。
                             掌握上述的工具后,即可对问题进行结构化的分析,其实施步骤如下:
                             (1)确定系统边界,画出系统环境图。
                             (2)自顶向下,画出各层数据流图。
                             (3)定义数据字典。
                             (4)定义加工说明。
                             (5)将图、字典以及加工组成分析模型。
                             DFD、数据字典和处理加工说明可以充分地描述系统的分析模型,其后需要对分析模型进行变换从而得到系统的总体设计模型。系统总体设计模型可以采用层次图、HIPO图和结构图来表达,但不论是哪一种图形工具,都反映了模块间的调用关系。
                             在分析模型的基础上进行设计时,主要是针对DFD进行变换从而得到模块的调用关系图,因此,需要掌握数据流的变换设计与事务设计。面向数据流的设计方法把数据流图映射成软件结构,数据流图的类型决定了映射的方法,数据流图可分为变换型数据流图和事务型数据流图。变换型数据流图具有明显的输入、变换(或称主加工)和输出;而事务型数据流图则是数据沿输入通路到达一个处理时,这个处理根据输入数据的类型在若干动作序列中选择一个来执行。变换设计的核心在于确定输入流和输出流的边界,从而孤立出变换中心;事务设计的核心在于将事务类型判断处理变换成调度模块以选择后续的输出分支模块。
                             经过总体设计阶段的工作,已经确定了软件的模块结构和接口描述,但每个模块仍被看作黑盒子。后续的详细设计目标是确定怎样具体地实现所要求的系统,经过详细设计,可以得出对目标系统的精确描述,从而在编码阶段可以将这个描述直接翻译成用某种程序设计语言书写的程序。因此,详细设计的结果基本上决定了最终的程序代码的质量。详细设计可以采用程序流程图、N-S图、PAD图和PDL语言等工具来表达。
                             数据库应用程序的设计可以借鉴传统的结构化程序设计方法,使用“输入一处理一输出”模型编写系统结构,这些模型大部分依靠数据库和文件,并且不需要复杂的实时处理。同时也有着广泛的结构化程序设计语言作支持,如C、Basic、Pascal、Fortran等。
                             面向对象开发方法
                             目前,面向对象分析和设计通常采用UML。UML是面向对象的标准建模语言,通过统一的语义和符号表示,使各种方法的建模过程和表示统一起来,已成为面向对象建模的工业标准。UML通过事务、关系和图对现实世界进行建模。
                             面向对象开发方法将问题和问题的解决方案组织为离散对象的集合,数据结构和行为都包含在对象的表示中。面向对象的特性包括表示、抽象、分类、封装、继承、多态和持久性。面向对象开发方法包括面向对象分析、面向对象设计和面向对象实现。面向对象分析强调在问题领域内发现和描述对象或概念。例如,在图书馆信息系统里包含了书、图书馆和顾客这样一些概念。面向对象设计采用协作的对象、对象的属性和方法说明软件解决方案的一种方式,强调的是定义软件对象和这些软件对象如何协作来满足需求,是面向对象分析的延续。例如,图书馆系统中的软件对象“书”可以有“标题”属性和“获取书”方法,在面向对象编程过程中会实现设计的对象,如Java中的Book类。
                             面向对象开发方法中分析和设计有时会存在一部分重叠,不是完全独立的活动。在迭代开发中,不严格区分分析、设计和实现,而是每次迭代不同程度地进行精化。有关应用程序设计的详细内容可参考本书第10章。
 
       数据库设计
        数据库设计的主要任务是在DBMS的支持下,按照应用的要求,为某一部门或组织设计一个结构合理、使用方便、效率较高的数据库及其应用系统。其中主要的研究方向是数据库设计方法学和设计工具,包括数据库设计方法、设计工具和设计理论的研究,数据模型和数据建模的研究,计算机辅助数据库设计方法及其软件系统的研究,数据库设计规范和标准的研究等。
 
       数据库
        数据库(DataBase,DB)是指长期存储在计算机内的、有组织的、可共享的数据集合。数据库中的数据按一定的数据模型组织、描述和存储,具有较小的冗余度、较高的数据独立性和易扩展性,并可为各种用户共享。
        系统使用的所有数据存储在一个或几个数据库中。
   题号导航      2016年上半年 数据库系统工程师 上午试卷 综合知识   本试卷我的完整做题情况  
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 /
 
第32题    在手机中做本题