精华内容
下载资源
问答
  • 详写数据库需求分析

    千次阅读 2020-04-04 21:03:46
    需求分析一、数据库系统设计概述  1.数据库系统设计的内容1>数据库的结构特性设计2>数据库的行为特性设计3>数据库的物理模式设计   2.应注意的问题  3.基本方法  4.基本步骤二、系统需求分析  1....

    本篇文章通过上课讲解,网上资料总结而成

    需求分析

    Date date = new Date();
    System.out.println(date);
    //当前时间为2020-4-4 19:00;

    一、数据库系统设计概述

      1.数据库系统设计的内容

      数据库系统设计的目标是:对于给定的应用环境,建立一个性能良好的、能满足不同用户使用要求的、又能被选定的DBMS所接受的数据库系统模式。按照该数据库系统模式建立的数据库系统,应当能够完整地反映现实世界中信息及信息之间的联系;能够有效地进行数据存储;能够方便地执行各种数据检索和处理操作;并且有利于进行数据维护和数据控制管理的工作。
      数据库系统设计的内容主要有:数据库的结构特性设计、数据库的行为特性设计、数据库的物理模式设计。
      在数据库系统设计过程中,数据库结构特性的设计起着关键作用,行为特性设计起着辅助作用。将数据库的结构特性设计和行为特性设计结合起来,相互参照,同步进行,才能较好地达到设计目标。

    1>数据库的结构特性设计

      数据库的结构特性是指数据库的逻辑结构特征。由于数据库的结构特性是静态的,一般情况下不会轻易变动,因此数据库的结构特性设计又称为数据库的静态结构设计。
      数据库的结构特性设计过程是:先将现实世界中的事物、事物间的联系用E-R图表示,再将各个分E-R图汇总,得出数据库的概念结构模型,最后将概念结构模型转化为数据库的逻辑结构模型表示。

    2>数据库的行为特性设计

      数据库的行为特性设计是指确定数据库用户的行为和动作,并设计出数据库应用系统的系统层次结构、功能结构和系统数据流程图,确定数据库的子模式。数据库用户的行为和动作是指数据查询和统计、事物处理及报表处理等操作,这些都要通过应用程序表达和执行。由于用户行为总是更新数据库内容的存取数据操作,用户行为特性是动态的,所以数据库的行为特性设计也称为数据库的动态特性设计。
      数据库行为特性的设计步骤是:将现实世界中的数据及应用情况用数据流程图和数据字典表示,并详细描述其中的数据操作要求(即操作对象、方法、频度和实时性要求);确定选和系统层次结构;确定系统的功能模块结构;确定数据库的子模式;确定系统数据流程图。

    3>数据库的物理模式设计

      数据库的物理模式设计要求:根据库结构的动态特性(即数据库应用处理要求),在定的DBMS环境下,把数据库的逻辑结构模型加以物理实现,从而得出数据库的存储模式存取方法。

       2.应注意的问题

      数据库系统设计时应使结构特性设计和行为特性设计紧密结合。数据库设计过程是一种自上而下的、逐步逼近设计目标的过程。数据库设计过程是结构设计和行为设计分离设计、相互参照、反复探寻的过程。

      3.基本方法

      数据库设计应分6个阶段进行:
        需求分析
        概念结构设计
        逻辑结构设计
        物理结构设计
        数据库实施
        数据库运行与维护
      在数据库设计的不同阶段上,实现的具体方法有基于E-R模型的数据库设计方法、基于3NF(第3范式)的设计方法、基于抽象语法规范的设计方法等。

      4.基本步骤

    在这里插入图片描述
    在这里插入图片描述

    二、系统需求分析

      1.概述

      需求分析是数据库设计的第一步,也是最困难、最耗时间的一步。需求分析的任务是准确了解并分析用户对系统的需要和要求,弄清系统要达到的目标和实现的功能。需求分析是否做得充分与准确,决定着在其上构建数据库大厦的速度与质量。如果需求分析做不好,会影响整个系统的性能,甚至会导致整个数据库设计返工。
      数据库应用系统的需求分析包括数据需求分析功能需求分析(数据处理需求分析、业务规则需求分析)、性能需求分析(数据操作响应时间或数据访问响应时间、系统吞吐量、允许并发访问的最大用户数、每秒TPS代价值)、其他需求分析(存储需求分析、安全性需求分析、备份和恢复需求分析)。
      ①数据处理需求分析:从对数据组织与存储的设计角度,辨识应用领域所管理的各类数据项和数据结构,与数据处理需求分析结果一 起,组成数据字典,形成数据规范说明书”。
      ②功能需求分析:功能需求分析主要针对DBAS应具有的功能进行分析,是DBAS需求分析的核心环节,总体上可分为数据处理需求分析与业务规则需求分析。数据处理需求分析从数据访问和处理的角度,明确对各数据项所需要进行的数据访问操作。在系统规划与分析阶段,DBAS开发者已经明确了各类用户视图。因此数据处理需求分析阶段可以从这些视图出发,
      ③性能需求分析:性能需求则描述了系统应当做到什么程度,分析DBAS应具有的性能指标。
      ④其他需求分析包括:存储需求、安全性需求等。
        a.存储需求分析:存储需求分析是指估计DBAS系统需要的数据存储量,如DB所存储的数据总量。
        b.安全需求分析:主要用于数据库安全设计,避免被非法使用和攻击。

       2.基本步骤

      设计者的中心工作是弄清并综合各个用户的应用需求;

       3.主要任务

      详细调查现实世界要处理的对象(组织、部门、企业等);充分了解原系统(手工系统或计算机系统)的概况和发展前景;明确用户的各种需求;收集支持系统目标的基础数据及其处理方法;确定新系统的功能和边界。

      4.抽象系统概貌

    在这里插入图片描述

      5.常用的数据建模方法

    1>DFD方法

      数据流图(Data Flow Diagram,简称DFD)是便于用户理解系统数据流程的图形表示。DFD建模方法的核心是数据流,它能精确地在逻辑上描述系统的功能、输入、输出和数据存储等,从而摆脱了其物理内容。数据流图是系统逻辑模型的重要组成部分。
      DFD的主要组成包括外部实体(外部项)、处理过程、数据存储和数据流。外部实体指系统之外又和系统有联系的人或者事物,说明了数据的外部来源和去处。处理指对数据逻辑处理,也就是数据变换,它用来改变数据值。数据流是指处理功能的输入输出数据存储表示数据保存的地方,它用来存储数据。
      在DFD建模方法中,数据流用箭头表示,处理用矩形框表示,数据存储用圆角矩形框表示,外部项用圆角框或
    者平行四边形框表示。
      数据流程图表达了数据和处理过程之间的关系。在结构化分析方法中,处理过程的处理逻辑常常用判定表或判定树来描述。
      DFD特性:
      ①抽象性:在DFD中具体的组织机构、工作场所、物质流等都已经去掉,只剩下信息和数据存储、流动、使用以及加工的情
    况。所以描述的是抽象出来的数据。

      ②概括性:它把系统对各种业务的处理过程联系起来考虑,形成一个总体,可反映出数据流之间的概括情况。

    2>IDEF0方法

    1.IDEF方法
      是70年代提出的结构化分析方法基础上发展起来的
      IDEF0:描述系统的功能活动及其联系
      IDEF1:描述系统信息及其联系,建立信息模型作为数据库设计的依据
      IDEF2:用于系统模拟,建立动态模型
    2.IDEF大家族
    在这里插入图片描述
    3.IDEF0详解
      用于系统的需求处理和结构关系的功能定义,IDEF0能同时表达系统的活动(用盒子表述)和数据流(用箭头表示)以及它们之间的联系,IDEF0被称为“Static Model”,是一种图形化方法,采用的是层次分解,逐步细化的结构树描述系统。
    4.IDEF0控制图
    IDEF0是活动模型(ICAM DEF inition Method)的缩写,来源于结构化分析与设计技术的一套标准,这些标准包含多种层次的图形语言。输入(Input)箭头表示完成特定活动所需的数据,置于矩形框的左侧;输出(Output)箭头说明由活动产生的结果及信息,置于矩形框的右侧;控制(Control) 箭头描述了影响这个活动执行的事件或约束条件,置于矩形框的上方;机制(Mechanisms) 箭头表示实施该活动的物理手段或完成活动需要的资源(计算机系统、人或组织),置于矩形框的下方。
    在这里插入图片描述

    3>UML方法

      UML-Unified Modeling Language 统一建模语言,又称标准建模语言。是用来对软件密集系统进行可视化建模的一种语言。UML的定义包括UML语义和UML表示法两个元素。
      UML是在开发阶段,说明、可视化、构建和书写一个面向对象软件密集系统的制品的开放方法。最佳的应用是工程实践,对大规模,复杂系统进行建模方面,特别是在软件架构层次,已经被验证有效。统一建模语言(UML)是一种模型化语言。模型大多以图表的方式表现出来。一份典型的建模图表通常包含几个块或框,连接线和作为模型附加信息之用的文本。这些虽简单却非常重要,在UML规则中相互联系和扩展。

    参考软件工程导论这里不做细

      6.数据字典

      数据字典是各类数据描述的集合,它是进行详细的数据收集和数据分析后所获得的主要成果。数据字典在数据库设计中占有很重要的地位。数据字典通常包括以下5个部分。

    1>数据项

      数据项是不可再分的数据单位。它的描述为:
      数据项={数据项名,含义说明,别名,类型,长度,取值范围,与其他数据项的逻辑关系}。
      其中:“取值范围”和“与其他数据项的逻辑关系”两项定义了数据的完整性约束条件,它们是设计数据完整性检验功能的依据。

    2> 数据结构

      数据结构的描述为:
      数据结构={数据结构名,含义说明,组成,{数据项或数据结构}}。
      数据结构反映了数据之间的组合关系。一个数据结构可以由若干个数据项组成,也可以由若干个数据结构组成,或由若干数据项和数据结构混合组成。

    3>数据流

      数据流是数据结构在系统内传输的路径。数据流的描述通常为:
      数据流 ={数据流名,说明,流出过程,流入过程,组成:{数据结构},平均流量,高峰期流量}。
      其中,“流出过程”说明该数据流来自哪个过程;“流入过程”说明该数据流将到哪个过程去;“平均流量”是指在单位时间(每天、每周、每月等)里传输的次数;“高峰期流量”则是指在高峰时期的数据流量。
      数据流是数据结构在系统内传输的路径。数据流的描述通常为:
      数据流 ={数据流名,说明,流出过程,流入过程,组成:{数据结构},平均流量,高峰期流量}。
      其中,“流出过程”说明该数据流来自哪个过程;“流入过程”说明该数据流将到哪个过程去;“平均流量”是指在单位时间(每天、每周、每月等)里传输的次数;“高峰期流量”则是指在高峰时期的数据流量。

    4> 数据存储

      数据存储是数据及其结构停留或保存的地方,也是数据流的来源和去向之一。数据存储可以是手工文档、手工凭单或计算机文档。数据存储的描述通常为:
      数据存储 ={数据存储名,说明,编号,输入的数据流,输出的数据流,组成:{数据结构},数据量,存取频度,存取方式}。
      其中:“数据量”说明每次存取多少数据;“存取频度”指每小时或每天或每周存取几次、每次存取多少数据等信息;“存取方式”指是批处理还是联机处理,是检索还是更新,是顺序检索还是随机检索等;“输入的数据流”要指出其数据的来源处;“输出的数据流”要指出其数据去向处。

    5>处理过程

      处理过程的具体处理逻辑一般用判定表或判定树来描述。数据字典中只需要描述处理过程的说明性信息,通常包括以下内容:
      处理过程={处理过程名,说明,输入:{数据流},输出:{数据流},处理:{简要说明}}。
      其中:“简要说明”中主要说明该处理过程用来做什么(不是怎么做)及处理频度要求,如单位时间里处理多少事务、多少数据量、响应时间要求等。

    6>小结

      数据字典是关于数据库中数据的描述,即对元数据的描述。数据字典是在需求分析阶段建立,在数据库设计过程中不断修改、充实、完善的。
      需求和分析阶段收集到的基础数据用数据字典和一组数据流程图(Data Flow Diagram , 简称DFD)表达,它们是下一步进行概念设计的基础。数据字典能够对系统数据的各个层次和各个方面进行精确和详尽的描述,并且把数据和处理有机地结合起来,可以使概念结构的设计变得相对容易。

    三、数据库概念结构的设计

      1.概述

     &emsp概念结构设计是整个数据库设计的关键。在概念结构的设计过程中,设计者要对用户需求进行综合、归纳和抽象,形成一个独立于具体计算机和DBMS的概念模型。

      2.基本步骤

      设计者要将应用需求转换为与计算机硬件无关的、与各个数据库管理系统产品无关的概念模型(即E-R图);

      3.特点

      概念结构独立于数据库逻辑结构和支持数据库的DBMS,其主要特点如下。

    • 1)概念模型是现实世界的一个真实模型:概念模型应能真实、充分地反映现实世界,能满足用户对数据的处理要求。
    • 2)概念模型应当易于理解:概念模型只有被用户理解后,才可以与设计者交换意见,参与数据库的设计。
    • 3)概念模型应当易于更改:由于现实世界(应用环境和应用要求)会发生变化,这就需要改变概念模型,易于更改的概念模型有利于修改和扩充。
    • 4)概念模型应易于向数据模型转换:概念模型最终要转换为数据模型。设计概念模型时应当注意,使其有利于向特定的数据模型转换。

      4.步骤

      概念结构的设计可分为两步:

    • 第一步是抽象数据,并设计局部视图;
    • 第二步是集成局部视图,得到全局的概念结构。

       5.数据抽象与局部视图设计

      概念结构是对现实世界的一种抽象。所谓抽象是对实际的人、物、事和概念进行人为处理,抽取所关心的共同特性,忽略非本质的细节,并把这些特性用各种概念精确地加以描述,这些概念组成了某种模型。

    1.三种数据抽象方法

    ⑴ 分类 (Classification)
      定义某一类概念作为现实世界中一组对象的类型,这些对象具有某些共同的特性和行为。分类抽象了对象值和型之间的“成员”的语义。在E-R模型中,实体集就是这种抽象。
    ⑵ 聚集 (Aggregation)
      定义某一类型的组成部分,它抽象了对象内部类型和对象内部“组成部分”的语义。若干属性的聚集组成了实体型。
    ⑶ 概括 (Generalization)
      定义了类型之间的一种子集联系,它抽象了类型之间的“所属”的语义。例如,学生是一个实体型,本科生、研究生也是实体型。本科生、研究生均是学生的子集。把学生超类( Superclass ),本科生、研究生称为学生的子类( Subclass)。
      在E-R模型中用双竖边的矩形框表示子类,用直线加小圆圈表示超类­-子类的联系。
       概括的一个重要性质是继承性。继承性指子类继承超类中定义的所有抽象。

      6.E-R图

    概念结构设计是利用抽象机制对需求分析阶段收集到的数据进行分类、组织(聚集),形成实体集、属性和码,确定实体集之间的联系类型(一对一、一对多或多对多的联系),进而设计分E-R图。
    ⑴ 设计分E-R图的具体做法

    • 1)选择局部应用。选择局部应用是根据系统的具体情况,在多层的数据流程图中选择一个适当层次的数据流程图,作为设计分E-R图的出发点,并让数据流程图中的每一部分都对应一个局部应用。选择好局部应用之后,就可以对每个局部应用逐一设计分E-R图了。
    • 2)设计分E-R图。在设计分E-R图前,局部应用的数据流程图应已经设计好,局部应用所涉及的数据应当也已经收集在相应的数据字典中了。在设计分E-R图时,要根据局部应用的数据流程图中标定的实体集、属性和码,并结合数据字典中的相关描述内容,确定E-R图中的实体、实体之间的联系。

      7.视图

      各子系统的局部E-R图设计好以后,下一步就是要将所有的局部E-R图综合成一个系统的总E-R图。一般说来,视图集成可以有两种方式:

    • 多个局部E-R图一次集成。
    • 逐步集成,用累加的方式一次集成两个局部E-R图。

      第一种方法比较复杂,做起来难度较大。
      第二种方法每次只集成两个局部E-R图,可以降低复杂度。
      每次集成局部E-R图时都需要分两步走

    ① 合并。解决各局部E-R图之间的冲突,将各局部E-R图合并起来生成初步E-R图。
    ② 修改和重构。消除不必要的冗余,生成基本E-R图。

    1.合并分E-R图,生成初步E-R图

      各个局部应用所面向的问题不同,且通常是由不同的设计人员进行局部视图设计,这就导致各个局部E-R图之间必定会存在许多不一致的地方,这称之为冲突。因此,合并局部E-R图时并不能简单地将各个局部E-R图画到一起,而是必须着力消除各个局部E-R图中的不一致,以形成能为全系统中所有用户共同理解和接受的统一的概念模型。合理消除各局部E-R图的冲突是合并局部E-R图的主要工作与关键所在。
      ⑴ 属性冲突
      ① 属性域冲突,即属性值的类型、取值范围或取值集合不同。例如零件号,有的部门把它定义为整数,有的部门把它定义为字符型。不同的部门对零件号的编码也不同。又如年龄,某些部门以出生日期形式表示职工的年龄,而另一些部门用整数表示职工的年龄。
      ② 属性取值单位冲突。例如,零件的重量有的以公斤为单位,有的以斤为单位,有的以克为单位。
      ③ 属性冲突理论上好解决,但实际上需要各部门讨论协商,解决起来并非易事。
      ⑵ 命名冲突
      ① 同名异义,即不同意义的对象在不同的局部应用中具有相同的名字。
      ② 异名同义(一义多名),即同一意义的对象在不同的局部应用中具有不同的名字。如对科研项目,财务科称为项目,科研处称为课题,生产管理处称为工程。
      命名冲突可能发生在实体、联系一级上,也可能发生在属性一级上。其中属性的命名冲突更为常见。处理命名冲突通常也像处理属性冲突一样,需要通过讨论、协商等行政手段加以解决。
      ⑶ 结构冲突
      ① 同一对象在不同应用中具有不同的抽象。例如,职工在某一局部应用中被当作实体,而在另一局部应用中则被当作属性。
      解决方法通常是把属性变换为实体或把实体变换为属性,使同一对象具有相同的抽象。
      ② 同一实体在不同局部E-R图中所包含的属性个数和属性排列次序不完全相同。
      解决方法是根据应用的语义对实体联系的类型进行综合或调整。

    2.消除不必要的冗余,设计基本E-R图

      在初步E-R图中,可能存在一些冗余的数据和实体间冗余的联系。所谓冗余的数据是指可由基本数据导出的数据,冗余的联系是指可由其他联系导出的联系。冗余数据和冗余联系容易破坏数据库的完整性,给数据库维护增加困难,应当予以消除。消除了冗余后的初步 E-R图称为基本E-R图。
      消除冗余主要采用分析方法,即以数据字典和数据流图为依据,根据数据字典中关于数据项之间逻辑关系的说明来消除冗余。
      但并不是所有的冗余数据与冗余联系都必须加以消除,有时为了提高效率,不得不以冗余信息作为代价。因此在设计数据库概念结构时,哪些冗余信息必须消除,哪些冗余信息允许存在,需要根据用户的整体需求来确定。如果人为地保留了一些冗余数据,则应把数据字典中数据关联的说明作为完整性约束条件。

    四、数据库逻辑结构的设计

      1.概述

      数据逻辑结构设计的主要任务是将概念结构转换为某个DBMS所支持的数据模型,并将其性能进行优化。

      2.基本步骤

      要完成数据库的逻辑模式和外模式的设计工作,即系统设计者要先将E-R图转换成具体的数据库产品支持的数据模型,形成数据库逻辑模式,然后根据用户处理的要求、安全性的考虑建立必要的数据视图,形成数据的外模式;
    ( 1 ) 将概念结构转换为一般的关系、网状、层次模型;
    ( 2 ) 将转换来的关系、网状、层次模型向指定数据库管理系统支持的数据模型转换;
    ( 3 ) 对数据模型进行优化。

       3.范式

    1>第一范式

      定义:数据库表中的所有字段都是单一属性,不可再分的。这个单一属性是由基本的数据类型所构成的,如整数,浮点数,字符串等,换句话说,第一范式要求数据库中的表都是二维表。(二维表就是由行和列组成的表)

    2>第二范式

      定义:数据库的表中不存在非关键字段对任一候选关键字段的部分函数依赖。
      部分函数依赖是指存在着组合关键字中的某一关键字决定非关键字的情况。
      换句话说:所有单关键字的表都符合第二范式。

    3>第三范式

      定义:第三范式是在第二范式的基础上定义的,如果数据表中不存在非关键字段,对任意候选关键字段的传递函数依赖则符合第三范式。

    4>BC范式

      定义:在第三范式的基础上,数据库表中如果不存在任何字段对任一候选关键字段的传递函数依赖则符合BC范式。也就是说如果是复合关键字,则复合关键字之间也不能存在函数依赖关系

    5>范式之间的关系

    在这里插入图片描述

       4.E-R图向关系模型的转换

      转换规则 
    1) 一个实体型转换为一个关系模式 
    一般E-R图中的一个实体转换为一个关系模式,实体的属性就是关系的属性,实体的码就是关系的码。
    2) 一个1:1联系可以转换为一个独立的关系模式,也可以与任意一端对应的关系模式合并。
    3) 一个1:n联系可以转换为一个独立的关系模式,也可以与n端对应的关系模式合并。
    4) 一个m:n联系可以转换为一个独立的关系模式。 
    5) 一个多元联系可以转换为一个独立的关系模式。
    6) 具有相同码的关系模式可以合并。
    7) 有些1:n的联系,将属性合并到n端后,该属性也作为主码的一部分

       5.数据模型的优化

       有了关系模型,可以进一步优化,方法为:
    1).确定数据依赖。
    2).对数据依赖进行极小化处理,消除冗余联系(参看范式理论)。
    3).确定范式级别,根据应用环境,对某些模式进行合并或分解。
    4).对关系模式进行必要的分解。
    1.2.3.工作理论性比较强,主要目的是设计一个数据冗余尽量少的关系模式。
    4.考虑效率问题了。
      对关系模式进行必要的分解。如果一个关系模式的属性特别多,就应该考虑是否可以对这个关系进行垂直分解。如果有些属性是经常访问的,而有些属性是很少访问的,则应该把它们分解为两个关系模式。
      如果一个关系的数据量特别大,就应该考虑是否可以进行水平分解。

       6.设计用户子模式

      这部分主要是考虑使用方便性和效率问题,主要借助视图手段实现
    1)建立视图,使用更符合用户习惯的别名。
    2)对不同级别的用户定义不同的视图,以保证系统的安全性。
    3)对复杂的查询操作,可以定义视图,简化用户对系统的使用。

    五、数据库物理结构的设计

      1.概述

      数据库物理结构设计的主要任务是为逻辑数据模型选取一个最适合应用环境的物理结构,包括数据存储位置、数据存储结构和存取方法。

      2.基本步骤

      数据库上运行的各种事务响应时间小、存储空间利用率高、事务吞吐率大,首先对要进行的事务进行详细分析,获得选择物理数据库设计所需要的参数;其次,要充分了解所用关系数据库管理系统的内部特征,特别是系统所提供的存取方法和存取结构。
      以下是确定关系的存取方法的依据:

    1. 对于数据库查询事务,需要得到:查询的关系,查询条件所涉及的属性,连接条件所涉及的属性,查询的投影属性。
    2. 对于数据更新事务,需要得到:被更新的关系,每个关系上的更新操作条件所涉及的属性,修改操作要改变的属性值。
    3. 除此之外,还需要制定每个事务在各关系上运行的频率和性能要求。

      通常关系数据库物理设计的内容主要包括为关系模式选择存取方法,以及设计关系、索引等数据库文件的物理存储结构。

      3、关系模式存取方法选择

      数据库系统是多用户共享的系统,对同一个关系要简历多条存取路径才能满足多用户的多种应用要求。物理结构设计的任务之一是根据关系数据库管理系统支持的存取方法确定选择哪些存取方法。
      存取方法是快速存取数据库中数据的技术。数据库管理系统一般提供索引方法和聚簇方法。

    1.B+树索引和hash索引

    B+树索引存取方法的选择
    所谓选择索引存取方法,实际上就是根据应用要求确定对关系的那些属性列建立索引、哪些属性列建立组合索引、哪些索引要设计唯一索引。

    • 1)如果一个(或一组)属性经常在查询条件中出现,则考虑在这个(或这组)属性上建立索引(或组合索引)。
    • 2)如果一个属性经常作为最大值和最小值等聚集函数的参数,则考虑在这个属性上建立索引。
    • 3)如果一个(或一组)属性经常在连接操作的连接条件中出现,则考虑在这个(或这组)属性上建立索引。

    hash索引存取方法的选择
      选择hash存取方法的规则:如果一个关系的属性主要出现在等值连接条件中或主要出现在等值比较选择条件中,而且满足下列两个条件之一,则此关系可以选择hash存取方法。
    1)一个关系的大小可预知,而且不变。
    2)关系的大小动态改变,但数据库管理系统提供了动态hash存取方法。

    2. 聚簇存取方法的选择

      为了提高某个属性(或属性组)的查询速度,把这个或这些属性上具有相同值的元组集中存放在连续的物理块中称为聚簇。该属性(或属性组)称为聚簇码。
      聚簇功能可以大大提高按聚簇码进行查询的效率。
      聚簇功能不单适用于单个关系,也适用于经常进行连接操作的多个关系。即把多个连接关系的元组按连接属性值聚集存放。这就相当于把多个关系按“预连接”的形式存放,从而大大提高连接操作的效率。
    一个数据库可以连接多个聚簇,一个关系只能加入一个聚簇。这样聚簇存取方法,即确定要建立多少个聚簇,每个聚簇中包括哪些关系。
    首先设计候选聚簇,一般来说:

    1. 对经常在一起进行连接操作的关系可以建立聚簇。
    2. 如果一个关系的一组属性经常出现在相等比较条件中,则该单个关系可建立聚簇。
    3. 如果一个关系的一个(或一组)属性上的值重复率很高,则此单个关系可建立聚簇。即对应每个聚簇码值的平均元组数不能太少,太少则聚簇的效果不明显。

    然后检查候选聚簇中的关系,取消其中不必要的关系

    1. 从聚簇中删除经常进行全表扫描的关系。
    2. 从聚簇中删除更新操作远多于连接操作的关系。
    3. 不同的聚簇中可能包含相同的关系,一个关系可以在某一个聚簇中,但不能同时加入多个聚簇。要从这多个聚簇方案(包括不建立聚簇)中选择一个较优的,即在这个聚簇上运行各种事务的总代价最小。

      聚簇只能提高某些应用的性能,而且能建立与维护聚簇的开销是相当大的。对已有关系简历聚簇将导致关系中元组移动其物理存储位置,并使此关系上原来建立的所有索引无效,必须重建。当一个元组的聚簇码值改变时,该元组的存储位置也要做相应的移动,聚簇码值要相对稳定,以减少修改聚簇码值所引起的维护开销。
      当通过聚簇码进行访问或连接是该关系的主要应用,与聚簇码无关的其他访问很少或者是西药的,这时可以使用聚簇。尤其当SQL语句中包含有与聚簇码有关的ORDER BY、GROUP BY、UNION、DISTINCT等子句或短语时,使用聚簇特别有利,可以省去对结果集的排序操作。

      4、确定数据库的存储结构

      确定数据库物理结构主要指确定数据的存放位置和存储结构,包括确定关系、索引、聚簇、日志、备份等的存储安排和存储结构,确定系统配置等。
      确定数据的存放位置和存储结构要综合考虑存取时间、存储空间利用率和维护代价三方面的因素。这三个方面常常是相互矛盾的,因此需要进行权衡选择一个折中方案。

    1. 确定数据的存放位置
      为了提高系统性能,应根据应用情况将数据的易变部分与稳定部分、经常存取部分和存取频率较低部分分开存放。

    2. 确定系统配置
      关系数据库管理系统产品一般都提供了一些系统配置变量和存储分配参数,供设计人员和数据库管理员对数据库进行物理优化。

      5、评价物理结构

    数据库物理设计过程中需要对时间效、空间效率、维护代价和各种用户要求进行权衡,其结果可以产生多种方案。评价物理数据库的方法完全依赖于所选用的关系数据库管理系统,主要是从定量估算各种方案的存储空间、存取时间和维护代价入手,对估算结果进行权衡、比较,选择出一个较优的、合理的物理结构

    版权声明:本文为CSDN博主「lxwthinker」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。
    原文链接:https://blog.csdn.net/lxw983520/article/details/80890419

    六、数据库实施

      1.概述

      在数据库实施阶段中,系统设计人员要运用DBMS提供的数据操作语言和宿主语言,根据数据库的逻辑设计和物理设计的结果建立数据库,编制与调试应用程序,组织数据入库并进行系统试运行。

      2.步骤以及详细描述

      数据库的实施一般包括以下几个步骤:

    1>定义数据库结构

      在确定了数据库的逻辑结构和物理结构之后,接着就要使用所选定的数据库管理系统提供的各种工具来建立数据库结构。当数据库结构建立好后,就可以开始运行DBMS提供的数据语言及其宿主语言编写数据库的应用程序。

    2>数据的载人

      数据库结构建立之后,可以向数据库中装载数据。组织数据入库时数据库实施阶段的主要工作。来自于各部门的数据通常不符合系统的格式,需要对数据格式进行统一,同时还要保证数据的完整性和有效性。

    3>应用程序的编码与调试

      数据库应用程序的设计应与数据库的设计同时进行,也就是说编制与调试应用程序的同时,需要实现数据的入库。如果调试应用程序时,数据的入库尚未完成,可先使用模拟数据。

      在将一部分数据加载到数据库后,就可以开始对数据库系统进行联合调试了,这个过程又称为数据库试运行。这个阶段要实际运行数据库应用程序,执行对数据库的各种操作,测试应用程序的功能是否满足设计要求。如果不满足网站建设要求,则要对应用程序进行修改、调整,直到满足设计要求为止。此外,还要对系统的性能指标进行测试,分析其是否达到设计目标。

      当应用程序开发与调试完毕后,就可以对原始数据进行采集、整理、转换及入库,并开始数据库的试运行。

    4>数据库的试运行
    1. 应用程序调试完成并已有一小部分数据入库,就可以开始数据库的试运行,也称联合调试;
    2. 试运行十分重要,因为:
      (1) 检测应用程序在接近真实的环境中运行是否符合设计要求;
      (2) 检测系统设计的性能和评价。
    3. 试运行的工作主要有两个:
      (1) 功能测试:运行数据库应用程序,执行各种操作,测试程序是否满足设计要求,找出不足,改进现有程序直到符合设计要求;
      (2) 性能测试:测量系统的性能指标,分析是否符合设计目标。

    七、数据库运行维护

       1.概述

      数据库应用系统经过试运行后即可投入正式运行。在数据库系统运行过程中,必须不断地对其结构性能进行评价、调整和修改。

       2、数据库运行维护基本工作

       ①数据库的转储与恢复
       ②数据库的安全性、完整性控制
       ③检测并改善数据库的性能
       ④数据库的重组和重构

       3、运行状态监控与分析

       管理员借助相应工具在数据库运行过程中监测数据库系统的运行情况,掌握系统当前或以往的负荷、配置、应用和其他相关信息,并对监测数据进行分析。

       ①自动监控机制
       ②手动监控机制
       ③对数据库构架体系的监控
       ④对数据库性能的监控

       4、 数据库存储空间管理

       数据库的存储结构一般分为逻辑存储结构和物理存储结构,其物理存储结构决定了数据库存储数据时数据文件所占用空间的大小及分布。不同的数据库对空间的管理是不一样的。空间不足可扩大存储容量或合理备份转储。

       5、 数据库运行环境与参数调整

    1)外部调整:

       ①CPU:在空闲是使用率超过90%,说明服务器缺乏CPU资源;若高峰期时CPU 使用率依然很低,说明CPU资源充足。
       ②网络:大量SQL数据会使网络速度变慢,调整网络。

    2) 调整内存分配
    3)调整磁盘I/O:响应时间的最大组成部分。
    4)调整竞争:

       方法:
       ① 修改参数以控制连接到数据库的最大进程数
       ②减少调度进程的竞争

       ③ 减少多线程服务进程竞争
       ④减少重做日志缓冲区竞争
       ⑤减少回滚段竞争。

    Date date = new Date();
    System.out.println(date);
    //当前时间为2020-4-4 21:01;

    展开全文
  • 选课数据库需求分析

    千次阅读 2018-07-10 22:33:36
    需求分析背景 全校性选修课开设的目的在于扩大学生的知识面、加强学生素质教育、培养复合型高级人才,具有不可替代的重要性。随着教育改革的不断深入和素质教育的加强,学分制的实施,选修课在一个学生的培养计划中...

    需求分析

    背景

        全校性选修课开设的目的在于扩大学生的知识面、加强学生素质教育、培养复合型高级人才,具有不可替代的重要性。随着教育改革的不断深入和素质教育的加强,学分制的实施,选修课在一个学生的培养计划中占的比重将越来越大。
        网上选课系统的出现使同学们能够更加自主、便捷、准确的进行选课。但是,由于一般高校中的学生都比较多,因此带来了诸多如信息管理等问题,鉴于需要将学生信息、选课信息等信息数字化以便于管理维护,我们便想到了利用数据库能够比较良好地解决此类问题,由此下面我将设计出一个高校选课系统以供参考。

    概要分析

        根据1.2节中所描述的系统分析要求,我们的高校选课系统将包含学生、教师、管理员等实体,学生可以在规定的时间内选课、退选和成绩查询等操作;教师可以查看学生的相关信息,录入学生成绩等操作;管理员可以添加管理员,管理教师、学生等信息。

    开发技术

    开发工具:Microsoft SQL Server 2000 
    开发语言:SQL
    开发技术:数据库开发技术
    面向对象:需求者
        SQL  Server 2000 是Microsoft 公司推出的SQL Server 数据库管理系统,该版本继承了SQL Server 7.0 版本的优点,同时又比它增加了许多更先进的功能。具有使用方便可伸缩性好与相关软件集成程度高等优点,可跨越从运行Microsoft Windows 98 的膝上型电脑到运行Microsoft Windows XP 的大型多处理器的服务器等多种平台使用。本实验中最终将使用Microsoft SQL Server 2000数据库管理系统将我们设计的数据库实现。

    系统主要功能

        实验选课系统分为教师,学生及系统管理员三类用户,学生的功能包括选课、退选、查询选课信息等,教师的功能包括学生成绩录入,查询实验信息等。管理员的功能包括新建教师、学生账户,添加课程信息,其系统功能模块如图2-1:
    展开全文
  • 数据库需求分析整理

    千次阅读 2019-06-17 15:40:37
    下面的数据是我们所做项目中提取出来的数据,由于是第一次提取数据,可能和理想的数据要差很多。 用户表:用户名(Username) 角色(Role) 账号(Account number) 密码(Password) 身份证(IDNumber) 性别...

    下面的数据是我们所做项目中提取出来的数据,由于是第一次提取数据,可能和理想的数据要差很多。                                      

    用户表:用户名(Username) 角色(Role) 账号(Account number) 密码(Password) 身份证(IDNumber) 性别(Sex) 手机号(Cell-PhoneNumber) 家庭住址(FamilyAddress)

     

    仓库表:仓库名(WarehouseName) 仓库地址(WarehouseAddress)

     

    商品列表:商品名(CommodityName) 仓库(Warehouse) 商品价格(CommodityPrice)

    商品零售价(RetailPrice) 商品批发价(TradePrice) 商品数量(CommodityNumber)

     

    角色表:角色名(RoleName) 管理员(Administrator) 销售组(Market)

    仓管组(Store Clerk) 财务组(Finance) 查看组(Check) 库存查询(Inventory)

    调拨组(Allot) 采购组(Purchase) 库管组(InventoryKeeper) 入库组(BePutInStorage) 出库组(Stock Removal) 查询组(Demand)

     

    权限表:用户(User) 角色 (Role)

     

    收支:

     

    日常收支:

    日常收入:业务日期(BusinessData) 单据编号(BillsNumber) 账目类型(AccountsForm) 金额(元)(Money)收入账户(IncomeAccount) 备注(Remark)

    日常支出:业务日期(BusinessData) 单据编号(BillsNumber) 账目类型(AccountsForm) 金额(元)(Money) 支出账户(ExpendAccount) 备注(Remark)

     

    收支项目管理:

    账目:账目类型(AccountsForm) 收支类型(IncomeAndExpenses) 备注(Remark)

     

    资金往来:

     

    客户应收欠款:

    应收欠款(ReceivableDebe) = 期初欠款(TbotpDebe) + 增加应收欠款(ZJ ReceivableDebe) - 收回欠款 (TakeBackDebe)- 优惠(元)(Discounts)- 抵消欠款(CounteractDebe)

     

    客户:

    客户编号(ClienteleNumber) 客户名称(ClienteleName) 联系人(contacts)

    联系电话(ContactPhone) 期初欠款(元)(TbotpDebe)

    增加应收欠款(元)(ZJReceivableDebe)收回应收欠款(元)(ShReceivableDebe)

    优惠(元)(Discounts) 抵消欠款(元)(CounteractDebe)

    应收欠款(元)(ReceivableDebe) 关联供应商(RelevanceSupplier)

     

    供应商应付欠款:

    应付欠款(ReceivableDebe) = 期初欠款(TbotpDebe) + 增加应付欠款(ZJReceivableDebe) - 支付欠款(PaymentDebe) - 优惠欠款(元)(Discounts) – 抵消欠款(CounteractDebe)

     

    供应商:

    供应商编号(SupplierNumber) 供应商名称(SupplierName) 联系人(contacts)

    联系电话(ContactPhone) 期初欠款(TbotpDebe) 增加应付欠款(元)(ZJReceivableDebe) 支付欠款(元)(PaymentDebe) 优惠欠款(元)(Discounts) 抵消欠款(元)(CounteractDebe) 应付欠款(元)(AccountPayable) 关联客户(RelevanceClient)

     

    付款单:结算账户(CloseAnAccount) 应付金额(元)(AmountPayable)

    本次付款(元)(ThisTimePayment)优惠金额(元)(Discounts)

    合计(元)(Total) 备注(Remark)

     

    资金流水:

    业务日期(BusinessData) 单据编号(BillsNumber) 往来单位名称(CompanyName)

    收支项目名(SZItemsName) 经手人(JSPeople) 结算账户(CloseAnAccount) 收入(元)(Income) 支出(元)(Expend) 当前余额(元)(AtPresentBalance) 备注(Remark)

     

    收支类型:收入(Income) 支出(Expend)

     

    经手人:老板(Boss) 财务(Finance) 仓管或采购(StoreClerkOrPurchase) 销售(Market)

     

    结算账户:建设银行(CCB) 现金(Cash)

     

    收支项目名称:期初余额(TbotpBalance) 进货退货(StockSalesReturn)

    销售收入(MarketEarning) 收回欠款(TakeBackDebe)日常收入(EverydayEarning)

    转入金额(ShiftToMoney) 进货支出(StockExpend) 销售退货(MarketSalesReturn)

    支付欠款(PaymentDebe) 日常支出(EverydayExpend) 转出金额(RollOutMoney)

    销售订金(Market) 进货订金(StockEarnest) 挑拨其他费用(TBQTFY)

     

    账户转账:

    转出账户(RollOutAccoun) 转出日期(RollOutData) 转入账户(ShiftToAccoun)

    到账日期(DZData) 余额(元)(Balance)

    手续费(元)(service charge)手续费支付方式(mode of payment) 备注(Remark)

    展开全文
  • 网上订餐系统数据库需求分析

    千次阅读 2020-12-25 22:55:08
    需求分析及项目流程图 1 需求分析 学生到食堂用餐,有时会在选餐和排队上浪费很多时间,我们设计的线上校园订餐系统可以节省学生的时间和精力,避免食堂食物的浪费,同时让就餐学生都吃到满意的食物,提高服务质量...

    需求分析及项目流程图

    1 需求分析
    学生到食堂用餐,有时会在选餐和排队上浪费很多时间,我们设计的线上校园订餐系统可以节省学生的时间和精力,避免食堂食物的浪费,同时让就餐学生都吃到满意的食物,提高服务质量以及对餐厅的满意度。
    校园订餐系统的功能模块分别有:用户使用模块,管理员模块两大部分。用户使用模块可以实现用户注册及登录、浏览并选择菜品、提交订单查看订单相关信息等功能。管理员模块可以实现菜品管理、用户管理及订单管理等功能。
    2 总体设计框图图
    在这里插入图片描述
    3 数据库设计
    我们基于系统的基本要求和系统模块的划分,对用户登录子系统、管理员登录子系统、订单子系统、菜品分类子系统进行具体的数据库设计,在需求分析中形成的数据流图。
    3.1系统功能的设计和划分
    本系统按照所完成的功能分成以下几个子系统:用户登录子系统、管理员登录子系统、订单子系统、菜品分类子系统。各子系统完成的功能如下:
    3.1.1用户登录子系统用户登录界面,可实现已有账号用户的登录和新用户的注册和登录,并在用户登录时获取用户的宿舍号方便之后配送。
    3.1.2管理员登录子系统在管理员登录界面中,管理员可以查看用户所报的菜品,根据菜品进行配送。
    3.1.3订单子系统在订单界面,可以结算消费总额,及查看下订单时间与预计送达时间。 3.1.4菜品分类子系统 在选餐页面选择菜品,可增减已选菜品,生成最终订单。
    3.2 子系统流程图图
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    展开全文
  • 数据库性能需求分析及评估模型

    万次阅读 2017-11-22 17:05:50
    数据库作为应用系统当中最重要的一块,也是性能测试非常关注的一块,根据我自己的项目经验,和以往对应用系统的性能需求分析和测试策略制定过程,总结一下如何开展数据库系统的性能需求分析,以及制定数据库能力评估...
  • 数据库设计之需求分析

    万次阅读 2018-07-01 11:02:21
    需求分析简单地说就是分析用户的需求,它是设计数据库的起点,需求分析结果是否准确反映用户的实际要求将直接直接影响到后面各阶段的设计,并影响到设计结果是否合理和实用。 1、需求分析的任务 需求分析的任务是...
  • 一个公交卡充值的APP,需要实现些什么功能,请高人指点指点,其数据库该怎么设计呢?急求
  • 从这开始,就真正进入项目实战啦。先说点体会,我刚开始接触...对于一个系统来说,如果需求分析不到位,那么将有灾难性的后果,从这节的小标题就能看出,需求是数据库设计的基石,需求定了,数据库基本上就定了,...
  • 数据库备份的四种方法:l 全备份:创建备份完成时数据库内存在的数据的副本。l 差异备份:只记录自上次数据库备份后发生更改的数据。差异数据库备份比数据库备份小,而且备份速度快,因此可以更经常地备份,经常备份...
  • 具备数据库查询和报表打印功能,及时根据需求进行数据的检索、打印各种基础报表等操作。 如图 所示是本书示例数据库图书管理系统数据库的 E-R 图。在该图中显示了图书管理中所要使用实体集、实体属性和实体之间的...
  • 数据库应用系统的需求分析

    千次阅读 2019-03-01 23:46:58
    需求分析的概念与意义 所谓的需求分析,就是对待开发系统要做什么,完成什么功能的全面描述 软件的一些特性使得需求的获取常常并不容易! 比如软件功能复杂,需求可变性,软件的不可见性 二 获取需求的方法 ...
  • 数据库设计:需求分析

    千次阅读 2012-09-06 19:29:10
    需求分析的主要任务是通过详细调查要处理的对象,包括某个组织、某个部门、某个企业的业务管理等,充分了解原手工或原计算机系统的工作概况及工作流程,明确用户的各种需求,产生数据流图和数据字典,然后在此基础上...
  • 1、为什么要做数据库需求分析? 1:了解系统中所要存储的数据 2:了解数据的存储特点 3:了解数据的生命周期 需求分析是设计数据库的起点,需求分析结果是否准确反映用户的实际要求将直接直接影响...
  • 数据库管理员DBA职位需求分析

    千次阅读 2012-06-28 11:55:54
    [分析] 相比其他职位对认证不屑一顾的状况,企业对DBA职位的需求更加看重数据库厂商办法的认证证书。   经验要求关键词: 2-3年所维护的数据库的管理经验,所维护数据库的开发经验,大型关系型数据库系统设计...
  • 教材:王珊 萨师煊 编著 数据库系统概论(第5版) 高等教育出版社 注:文档高清截图在后 第7章 数据库设计 7.1 数据库设计概述 1、数据库应用系统,通常是指使用数据库的各类信息系统,比如以数据库为基础的各种管理...
  • 需求分析:1. 持卡人:属性(卡编号,姓名,性别,年龄,电话,发卡日期)2. 操作员:属性(编号,姓名)一个操作员进行多个收费结算,一个收费结算只对应一个操作员。3. 医生:属性(医生编号,姓名,科室)一个...
  • 今天开始跟着视频做一个简易的客户关系管理系统crm,先进行需求分析得到功能模块思维导图(如下图) 然后是按需求设计数据库,在这里使用powerDesign进行数据库设计,得到如图所示数据表关系 设计好后再power...
  • 实际项目的数据库设计基本方法

    千次阅读 2019-08-05 22:59:05
    需求分析阶段(常用自顶向下) 概念结构设计阶段(常用自底向上) 逻辑结构设计阶段 物理设计阶段 数据库实施阶段 6.数据库运行和维护阶段 二、 数据库设计实例 数据库数据分析 数据库概念结构设计 数据库逻辑结构...
  • 功能需求分析数据库设计 不论是Web开发还是Android开发,在设计后台的时候我们都要做的重要的事情不外乎两点:1. 需求分析;2.数据库表格的设计。在进行这两项工作的过程中,第一项工作对第二项起着非常重要的...
  • 需求分析 概念结构设计 逻辑结构设计 物理结构设计 数据库实施 数据库运行和维护 1. 需求分析阶段 是否做得充分与准确,决定了构建数据库的速度和质量 2. 概念结构设计阶段 通过对用户需求进行综合、...
  • SQL数据库设计(一)---需求分析与逻辑设计

    万次阅读 多人点赞 2016-05-22 21:20:23
    今天先来介绍 数据库设计中的需求分析和逻辑设计(ER图)阶段,明天介绍物理设计与维护优化,数据库设计是非常有意思的:-) 数据库设计 根据系统业务的需要,结合我们所选用的DBMS,为这个业务系统构建出最优的数据存储...
  • 常见数据库场景分析

    千次阅读 2016-08-07 22:00:25
    常见数据库场景分析 2 一 关系型数据库 2 1.关系型数据简介 2 2.常用的概念 2 4.特点 3 5.常见关系型数据库 3 二 常见非关系型数据库(NoSQL)场景分析 3 1、NoSQL的特性 3 2、根据需求进行分类 4 2.1满足...
  • 概要设计说明书 http://chinaunix.net/forum/viewtopic.php?t=181092&highlight=carol1980数据库设计说明书http://chinaunix.net/forum/viewtopic.php?t=181087&highlight=carol1980 http://www.hudong.com/w
  • 7种数据库分析

    万次阅读 多人点赞 2018-01-26 09:23:27
    摘要: 数据库的七种武器,是我在工作维护和接触到的七种常用数据库,包括4种常用的关系型数据库,3种常用nosql数据库。 这些数据库作为业务底层的存储选型,每种数据库都有各自的定位和特点,结合业务,有各自的...
  • 数据库职位分析

    千次阅读 2013-01-29 12:54:24
    以下是个人总结的几种数据发展方向的职业,希望对大家确定自己的职业方向和重点有一点帮助。... 除了基本的SQL方面的知识,还要对开发流程,软件工程,各种框架和开发工具等等,数据库应用开发这个方向上
  • hive元数据库分析及操作

    万次阅读 2016-06-12 22:59:57
    本文分析hive的元数据作用、配置,元数据库表结构、功能以及对元数据的直接查询
  • 分析数据库——分析系统的艺术

    千次阅读 2012-11-28 17:40:22
    下载了几个收银软件,都是cs的,功能分析得差不多了,就想看看表结构,结果发现有2个系统是db的,1个mdf的,1个mdb的,剩余一个居然没有发现数据库。 第一个查询都有什么数据库文件是db格式的,结果一查,太多了,...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 412,816
精华内容 165,126
关键字:

数据库需求分析的方法