软考下午题详解--数据库设计

        在前面的两篇博客中，小编分别对软考下午试题中的数据流图设计和uml图的相关知识点进行了详细的阐述，今天我们继续来看软考下午题中的大题部分---数据库设计，数据库的设计我们也已经早早的接触过，在第一次机房收费系统的时候我们直接用的是别人的脚本，也没有想过当时的数据库存在什么样的问题，等到个人重构机房的时候，我们需要重新设计数据库，这个时候，就不再是傻傻的导入数据库脚本文件这么简单了，我们需要从需求分析开始，自己设计数据库，什么三范式，主外键关联这都是我们需要注意的地方，可以这么说数据库设计贯穿我们学习的始终，那么今天，数据库出现在我们的软考当中，她又会以一种什么样的方式出现nie，是白裙摇曳，还是一席落地长裙，小编今天就简单介绍一下数据库设计的相关知识点，首先我们来看下面的一张图：

        

        接下来，小编就随着上面思维导图的脉络，一一讲解数据库设计中的相关知识点，首先我们来看第一个知识点：

        数据库设计阶段

        数据库设计阶段分为四个阶段，我们来看下面的一张图片：

         

         接下来，小编对四个阶段到底是什么，干什么的等进行一一的介绍。首先我们来看第一个阶段，需求分析。所谓的需求分析就是收集和分析用户对系统的信息需求和处理需求，得到设计系统所必须的需求分析，建立系统说明文档，需求分析的目标是通过调查研究了解用户的数据要求和处理要求，并且按照一定的格式整理形成需求说明书，也就是说，需求说明书是需求分析阶段的成果，也是以后设计的一个基础和依据，她包括数据库所涉及的数据，数据的特征，使用频率和数据量的估计，例如数据名。属性。类型，还包括数据的保密要求， 数据库的完整性约束，使用的频率，数据量的大小等一系列问题，设计大型数据库的时候，这些数据信息通常是使用数字字典进行管理，这是需求分析的内容。

        我们再来看概念结构设计：概念结构设计是对需求说明书所提供的所有数据和处理要求进行抽象和综合处理，按照一定的方法，构造反应用户环境的数据以及数据之间相互联系的概念模型。也就是我们通常所讲的ER模型，所以这种概念模型是与具体的DBMS是没有关系的，她是面向现实世界的，用户很容易理解的一种数据模型，为了保证所涉及的概念数据模型能够正确的完全的反应用户的数据以及相互关系，便于进行所要求的各种处理，  在概念结构设计阶段就可以吸收用户来参与，在进行概念结构设计的时候，可以先设计各个应用的视图，也就是各个应用所看到的数据以及他的结构，局部视图，然后再把局部视图进行集成，也就是后面所说的分ER图到整个ER图合并的过程，所以，最终结果，形成概念设计模型，形成了概念设计模型以后，就要开始逻辑结构设计。

        接着是我们的逻辑结构设计：根据有关的规则 ，把ER模型转换为关系模式，再根据有关规范化的理论，确定关系模式的主键、外键、约束等这些特性，所以这种转换就是要能为某个特定的DBMS所接受的逻辑模型所表示的一种形式，逻辑结构设计阶段的结果就是用DBMS所提供的数据定义语言所写成的数据模式，逻辑设计的具体方法与dbms的逻辑数据模型是有关系的，所以另为一个输入是DBMS的特性。逻辑模型应该要满足数据库的存储，一致性，以及运行各方面的用户需求。

       最后是我们的的物理设计：把逻辑设计阶段所得到的满足用户需求的已经确定的逻辑模型在物理上加以实现，他的主要内容是根据DBMS所提供的各种手段设计数据的存储形式和存储路径，包括文件结构，索引这样一些设计过程，也就是说要设计数据库的内模式或者存储模式，由于数据库的内模式对数据库的性能影响比较大，所以应该要根据处理的要求 以及操作系统硬件的性能来进行设计，所以她的输入是按照硬件以及操作系统的特性。看完了数据库的设计阶段，我们再来看一下ER模型。

        ER模型

        ER模型，实体-联系模型（简称E-R模型）它提供不受任何DBMS约束的面向用户的表达方法，在数据库设计中被广泛用作数据建模的工具。E-R数据模型问世后，经历了许多修改和扩充。我们来看一张简单的ER图，如下所示：

        

        在我们的ER图中，各个图形表示的是什么意思nie，小编来简单的介绍一下， 椭圆表示属性。长方形表示实体、菱形表示联系，数字表示联系的类型，比如仓库和零件的关系是库存，仓库里面可以存多个零件，零件可以放在多个仓库里面进行存放，所以他们之间的关系是多对多的关系。总的来讲，在数据库的概念结构设计当中，先要设计各个 子系统的局部ER图，左边是一个采购管理的ER图，中间是库存管理的ER图，右边是人事管理的ER图，先设计好局部的ER图，然后再进行合并。
        那么要设计各个子系统的局部ER图，可以分为以下步骤：
        首先，确定局部视图的范围，然后再识别该部分的每一个实体，以及实体之间的联系，最后分配实体，以及实体联系之间的属性。当各个子系统的局部ER图设计好之后，我们需要做的就是合并子系统的ER图使之成为一个总的ER图，，称为视图的集成，这种集成有两种方式，一种方式，多个局部ER图一次集成，第一步逐步集成，先集成前两个，然后再集成。不管用那种方式，由于各个子系统在应用的时候面临的问题不同，而且在一个大型的系统中，通常不只有一个设计人，所以不同的子系统由不同的设计人员设计，导致各个局部的ER图之间必定会存在许多不一致的问题，我们把这种不一致的问题称为冲突，因此合并分ER图的时候，并不能简单的将各个局部的ER图分到一起。而是必须消除各个子系统之间的不一致，这样才能形成一个 能为全系统当中所有用户都能理解和接受的统一的概念模型。关于数据库设计的理论知识，小编就暂时介绍到这里，接下来，我们来看看历年的软考真题，看看我们如何利用理论知识在实际中运用的nie？

        典型例题分析

        首先，我们来看一道2004年11月份的一道真题，题目如下所示：

         

         ER图如下所示：

         

         题目我们看完了，接着我们来看第一个小问，如下所示：

         

         据我们刚才介绍的把ER图转化为关系模式，在我们上面的图中，一共有两个联系，三个实体，每个实体都要转换为关系模式，就有三个关系模式，两个联系转换为一个关系模式，题目要求转四个，把第一个进行合并。所以这个时候确定这些实体之间的联系，看她们之间的关系，我们看题目中是这样来描述的：“一个顾客可以在同一天填写多张购书单，每张购书单上可填写多种图书，每种图书可以订购多本，bid相同的图书在同一张够数单上不能出现多次，注意，为了简化起见，不考虑信用卡号码泄露所带来的安全性等问题”通过试题中的描述我，我们可以很容易的看出，顾客和购书单之间的联系是一对多的联系，我们再看图书和订单，一个订单当中中含有多本图书，根据尝试，一本图书可以出现在多个订单中，所以图书和订单的联系是多对多，前面我们提到过多对多的联系应该要转换成一个独立的关系模式，所以PlaceOrder与Orders进行合并，所以四个关系模式是书籍Books（属性六个，竹马bid图书编号），第二个顾客，属性有四个，主键顾客编号cid，第三个是订单，所以她的属性有订单的编号，顾客的编号，还有填写的日期bRderDate,这是根据我们刚才所讲的，一个n比n的关系与另外一段合并的时候，就应该包括一段的码要加进来，所以这个订单的属性有三个，订单编号，顾客编号，填写日期，一个第四个OrderList，单独组成一个关系模式，那么就要把与她相联系的各个实体的码都需要加进来，所以一共有四个属性bid（图书的编号），订单的编号，发货的日期，数量，主键是图书编号和订单编号的一个组合。
        外码：对于books来讲，没有外码，因为这些属性都是自己的，顾客也是的，订单有三个属性，cid就是Orders的外码，因为她是顾客的主键，不是订单的主键，所以她是一个外码，在看OrderList，我们知道在OrderList当中他的主键是bid和ordernum的一个组合，但是其中的任何一个都不是她的主键，所以每一个都是她的外键。接着我们来看第二个问题，如下所示：

        
        从题目的描述我们知道顾客属性有四个，所以这两个空填写的肯定不是属性，那会是什么nie，就是约束，那么在这个题目当中有什么约束nie，看题目，首先要求cardnum这个值是唯一的，在这里没有体现出，题中只是给出了不为空，我们采用约束unique，所以第一个空填写的是unique  cardnun，使cardnum的值是唯一的，还有一个约束是什么ne，我们知道在创建一个表的时候，我们需要指定这个表的主键，这里面没有指出来，这个表的主键是cid，这里仅仅指出了非空，但是非空不是主键，所以第二个空填写的是primary key（cid），所以有关填写sql语句的题目的时候，建立表和视图的情况，我们首先看他的属性是否完整，如果完整，剩下的就是约束。接着我们来看第三题：

        
        我们首先不要急于看sql语句，这样是看不出名堂来的，我们必须首先弄清楚，这个查询怎么去做，如题意，需要查询的是所有订购了bid为123 456图书的用户订购其他图书的情况，我们可以分为两个步骤来进行，我们首先查出那些用户订购了bid为123 345的图书，第二步再查这些用户订购了其他图书的情况，所以这里面使用的就是查询的嵌套，在嵌套里面现查第一个，然后查询第二个，所以第四个空应该是c.bid，第五个空c.ordernum,在orderList这个关系模式当中，她是一个n比n的关系转换过来的，所以她有图书的编号和订单的编号，所以图书的编号等于123--456，订单的编号等于就等于订单这个关系模式的订单编号，所以4和5就填写完毕了，第4个空是c，第5个空是c.ordernum。所以3填写的是not in。

         小编寄语：该博文，小编主要讲解了软考下午题目当中的数据设计的相关知识点，分别从数据库设计的阶段，ER模型已经典型例题分析三个方面对数据库设计进行了简单的讲解，在软考当中，通常会考察我们，ER图当中各个实体之间的联系联系，写出关系模式，找出主外键；在软考中考察的问题包括在给定的er图当中，指出实体之间的联系类型，在关系模式当中补充属性，找出关系模式的主外键以及sql语句。同时在确定主外键的时候，我们可以根据常识来得出结论，和试题描述，解答此类问题需要认真读题。