【NCRE三级数据库技术】数据库分析与设计(1)

目录

前言

数据库应用系统生命周期 

软件开发方法

DBAS生命周期模型 

项目规划

系统规划与定义

可行性分析

项目规划

需求分析

需求分类 

数据需求分析

功能需求分析

性能需求分析

其他需求分析

需求分析方法

DFD需求建模方法

 其他需求建模方法


前言

        大数据(Big Data),是现代互联网生活中每个人都离不开的名词,也是信息时代最为重要的一环,涵盖生活的方方面面,它是你的游戏账号、偏好、个人信息等等,也是企业产品的生产、库存、销售信息,还是今天你无意间刷到我的文章的原因。数据(data)是用于表示客观事物的未经加工的原始材料,而大数据比其突出一个“大”字,大到几乎无法简单地通过软件工具在合理的时间内处理而为人所用,但是我们又需要处理它们使其变成有意义的信息(information),这离不开多方面技术的协调配合,而数据库(DataBase)技术作为数据管理的最有效的手段,极大地促进了计算机应用的发展。数据库技术主要是用来解决数据处理的非数值计算问题,数据处理的主要内容是数据的存储、查询、修改、排序和统计等。【来源:百度百科】

        本专栏是我学完三级数据库技术进行的笔记整理,希望能对未来需要备考三级数据库的小伙伴们有所帮助,仅供交流分享❥(^_-)

关于NCRE三级想简单分享一下个人看法:博主并不是自控力强的人,于是报考想去“强迫”自己去认真学习相关知识,其实考试作用本身不大,甚至连四级的难度和含金量也比软考稍低一些,正如我的一位导师说的:“食之无味,弃之可惜”,如果只是为了证书而来,它只能证明你学过,以及作为求职时的微加分项,对于非本专业的学生更是费力不讨好。但是你也想将其作为进入数据库世界大门的钥匙,将结果作为对自己的嘉奖,我相信这段旅程会对你意义非凡的。

数据库应用系统生命周期 

数据(data):是描述事务的符号记录,数据的含义称为数据的语义,数据与其语义是不可分的。

数据库(DataBase,DB):是长期存储在计算机内、有组织的、可共享的大量数据的集合。数据库中的数据按一定的数据模型组织、描述和储存,具有较小的冗余度(redundancy)、较高的数据独立性(data independency)和易扩展性(scalability),并可为各种用户共享。

数据库管理系统(DataBase Management System,DBMS):和操作系统一样是计算机的基础软件,也是一个大型复杂的软件系统。

数据库系统(DataBase System,DBS):由数据库、数据库管理系统(及其开发工具)、相关应用程序和数据库管理员(Database Administrator,DBA)组成的存储、管理、处理和维护数据的系统,主要提供数据管理功能。

数据库应用系统(DataBase Application System,DBAS):由数据库系统、应用程序系统(应用软件、应用界面等)、用户组成,不仅为用户提供数据管理功能,还根据具体应用领域业务规则,通过数据库应用程序,实现了更为复杂的数据处理功能。

        DBAS的设计开发既要遵循DBS三级模式结构所规定的范型,也要符合软件工程所定义的复杂软件系统开发基本原则,本章主要围绕DBAS生命周期模型简要介绍DBAS设计、开发和运维各阶段的相关内容。

软件开发方法

  1. 瀑布模型(软件生命周期模型):项目规划、系统分析、总体设计、详细设计、编码调试与集成测试、运行维护共六个阶段,形成线性顺序便于保证阶段工作的有效性、一致性和完备性,但是实际操作起来困难,用户对系统的需求往往是随着项目的深入而不断清晰的。
  2. 快速原型模型:快速分析、设计构造原型、运行原型、评价原型、改进原型五个阶段,优点在于先构建可运行的早期版本,再不断重复“运行原型、评价原型、改进原型”三个阶段不断改进和完善。
  3. 螺旋模型:1988年由Barry Boehm提出的,包括项目规划、风险评估、工程实现、用户评估四个阶段(四个象限),将瀑布模型的系统化与快速原型模型的可修改性结合起来,引入了风险评估活动,有效降低了大型项目实施过程中因成本、进度、质量等因素的不确定性带来的风险。

4.增量模型:把待开发的软件系统模块化,将每个模块作为一个增量组件,从而分批次地分析、设计、编码和测试这些增量组件。运用增量模型的软件开发过程是递增式的过程。相对于瀑布模型而言,采用增量模型进行开发,开发人员不需要一次性地把整个软件产品提交给用户,而是可以分批次进行提交。【来源:百度百科】

DBAS生命周期模型 

        通过软件开发方法的指导,得出了DBAS常用的生命周期模型

        其中项目规划、需求分析、系统设计、实现与部署、运行维护为五个基本活动,按照数据组织与存储、数据访问与处理、应用程序三条设计主线,分别实现数据库、数据库事务和应用程序,其中数据访问与处理设计、应用程序设计属于功能设计。系统设计阶段又分为概念设计、逻辑设计、物理设计

项目规划

        作为DBAS生命周期中的第一步,规划与分析的对象既包括作为产品的DBAS本身,也包括开发这一产品的项目,下面按顺序给出其主要工作内容

系统规划与定义

  1. 任务陈述:描述总体目标。
  2. 确定任务目标:明确为了实现总体目标而该支持的一系列数据管理和数据处理任务与活动。
  3. 确定系统范围和边界:做什么、不做什么、做到什么程度。
  4. 确定用户视图:表示不同用户的数据访问处理需求。

可行性分析

        经济可行性、技术可行性、操作可行性、开发方案选择,最后形成相应的DBAS开发可行性报告并提交给项目管理部门进行评审。

项目规划

        项目团队、项目环境、项目活动、成本预算、进度计划,最后形成DBAS项目计划文档,即项目计划书。

需求分析

        需求分析是软件开发阶段的前提和基础,所谓需求分析,就是对待开发的系统要做什么,完成什么功能的全面描述,Kotonya和Sommerville(1998)把需求定义为“系统服务或约束的描述”。需求分析的目标是以文档形式提供一个关于目标系统所完成的全部功能及性能等需求的完整描述,但是软件功能复杂、需求的可变性、软件产品的不可见性的软件特性使得需求的获取困难重重。通常,一个计算机应用信息系统的需求分析工作是在系统分析人员与用户不断交互的过程中完成的。获取需求的方法一般有面谈(最基本的方法)、实地观察、问卷调查、查阅资料,需求分析过程一般按顺序为标识问题、建立需求模型、描述需求(生成需求文档是完成的标志)、确认需求。

描述需求主要由需求模型(又称系统功能模型)和软件需求说明书组成。系统功能模型采用一些流行的建模方法如DFD等构建,软件需求说明书侧重文字说明(需求概述、功能需求、信息需求、性能需求、环境需求、其他需求)。

需求分类 

        一般分为功能和非功能需求,非功能需求一般也可以划分成性能需求、数据(信息)需求与其他需求

数据需求分析

        对数据进行组织与存储的角度,从用户视图出发,分析与辨识应用领域所管理的各类数据项(Data Items)和数据结构,形成数据字典的主要内容。

        数据字典包括数据项数据结构数据流数据存储处理过程五部分,数据项是数据的最小组成单位,若干个数据项组成一个数据结构,通过对数据项和数据结构的定义描述数据流和数据存储的逻辑内容。

功能需求分析

        描述做什么,是DBAS需求分析的核心环节

  1. 数据处理需求分析:从数据访问和处理的角度明确对各类数据项所需进行的数据访问操作,分析结果可表示为数据流图(Data Flow Diagram,DFD)或DBAS应支持的各种数据处理事务规范。事务规范包括事务名称、事务描述、事务所访问的数据项、事务用户
  2. 业务规则需求分析:从DBAS高层目标和整体功能出发,分析系统或系统中一些大粒度子系统应具有的业务类型和功能,明确用户或外部系统与DBAS的交互模式,主要面向系统开发者,分析结果可采用UML等方法表述。

性能需求分析

        描述做到什么程度,以及分析性能指标,包括数据操作(访问)响应时间、系统吞吐量、允许并发访问的最大用户数、每TPS代价值(Price per TPS)

系统吞吐量指系统在单位时间内可以完成的数据库事务或数据查询的数量,可表示为每秒事务数TPS,每TPS代价值用于衡量系统性价比。

其他需求分析

        存储需求分析、安全需求分析、备份和恢复需求分析等。 

需求分析方法

        包括结构化分析(SAD)与功能建模方法、面向对象分析(OOAD)与建模方法,SAD的基本特征是抽象分解,主要包括功能模型、数据模型、行为模型,接下来介绍常见的SAD与功能建模方法DFD与IDEF0。

DFD需求建模方法

        数据流图(DFD)的四种基本元素(模型对象):数据流(Data Flow,是DFD的核心)、处理(Process)、数据存储、外部项,符号表示分别如下

        

        DFD图采用自顶向下逐步细化的结构化分析方法表示目标系统,其层次机构如下图

        建立DFD图的目的是描述系统的功能需求,主要步骤为:明确目标,确定系统范围;建立顶层DFD图,其中包含的处理有且只有1个;构建第一层DFD分解图(中间层DFD),如图0层图;开发DFD层次结构图(底层DFD),如图1层图,可以继续往下扩展;检查确认DFD图。

上述的分层都是对上一层基本元素中处理的分解,分解可采用以下原则:

  1. 保持均匀模型深度,例如给定父图1,则应工作在1.1、1.2、1.3上,而不是1.1、1.1.1、1.1.1.1上,即每一层都应将所对应的上一层处理完全包含。
  2. 按困难程度进行选择,即可以从最不熟悉不清楚的处理开始分解。
  3. 如果一个处理难以确切命名,可以考虑对它重新进行分解。

 其他需求建模方法

        IDEF0:基本元素是矩形框和箭头,矩形框代表功能活动,写在矩形框内的动词短语描述功能活动的名称,活动的编号按要求写在矩形框右下角指定的位置,左边的箭头代表输入,右边的箭头为输入,上方的箭头为控制(影响事件或约束条件),下方的箭头为机制(物理手段或所需资源)

        IDEF0也有类似的层次结构图

         UML中的用例图UML(统一建模语言)采用面向对象分析(OOAD)的思想建模,其中的用例图由系统、角色和用例三种模型元素及其直接的关系构成,同样能作为需求建模方法,在后面会详细介绍。

DFD与IDEF0比较

        基础都是结构化分析思想,强调用自顶向下逐步求精的方法对现实世界建模,先抓住主要的问题或方面,形成较高层次的抽象,然后再由粗到细,由表及里地逐步细化,逐步涉及问题的具体细节。把一个大问题分解成几个小问题,把每个小问题分解成更小的问题,然后对这一个个的简单问题进行分析和求解,这些解的集合就是我们的解空间

  1. DFD图用箭头也叫作数据流来描述数据移动的方向、数据处理及处理之间的数据依赖关系。IDEF0图也用箭头代表数据流,但在IDEF0图中不是强调流或顺序,而是强调数据约束。
  2. IDEF0图中的箭头有更加丰富的语义,不仅能够表示出数据流,还可以表示出控制流和说明处理或活动实施方式的一些约束。
  3. 从模型元素的组成上来看,DFD模型由四种元素组成:外部项(数据源及终点)、数据流、数据存储和处理,而IDEF0模型元素的组成更加简单,只有两种元素组成:箭头和活动。通过这两种元素可以清楚地描述出二个目标系统将要做什么,完成什么功能及处理之间的约束,而进出IDEF0图的箭头究竟从哪儿来、到哪儿去,可在专门的文档中说明,不必表示在IDEF0图中。这使得IDEF0模型结构清楚,容易理解,更适合于大型复杂系统的需求建模。
    评论
    添加红包

    请填写红包祝福语或标题

    红包个数最小为10个

    红包金额最低5元

    当前余额3.43前往充值 >
    需支付:10.00
    成就一亿技术人!
    领取后你会自动成为博主和红包主的粉丝 规则
    hope_wisdom
    发出的红包
    实付
    使用余额支付
    点击重新获取
    扫码支付
    钱包余额 0

    抵扣说明:

    1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
    2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

    余额充值