当前位置:首页 » 数据仓库 » 数据库设计规划
扩展阅读
webinf下怎么引入js 2023-08-31 21:54:13
堡垒机怎么打开web 2023-08-31 21:54:11

数据库设计规划

发布时间: 2022-09-21 03:49:45

数据库设计过程包括几个主要阶段哪些阶段独立于数据库管理系统哪些阶段依赖于数据库管理系统

数据库设计阶段包括五个阶段,分别是:需求分析阶段、概念结构设计阶段、逻辑结构设计阶段、物理设计阶段、数据库实施阶段、数据库运行和维护阶段。

独立于数据库管理系统的是:需求分析阶段,概念设计阶段,逻辑设计阶段,物理设计阶段。

依赖于数据库管理系统的是:实施阶段,运行和维护阶段。

数据库设计是建立数据库及其应用系统的技术,是信息系统开发和建设中的核心技术。由于数据库应用系统的复杂性,为了支持相关程序运行,数据库设计就变得异常复杂。

因此最佳设计不可能一蹴而就,而只能是一种“反复探寻,逐步求精”的过程,也就是规划和结构化数据库中的数据对象以及这些数据对象之间关系的过程。

(1)数据库设计规划扩展阅读:

形成过程

1、需求分析阶段:综合各个用户的应用需求(数据流程图(DFD)。

2、概念设计阶段:形成独立于机器特点,独立于各个DBMS产品的概念模式(E-R图)。

3、逻辑设计阶段:首先将E-R图转换成具体的数据库产品支持的数据模型,如关系模型,形成数据库逻辑模式;然后根据用户处理的要求、安全性的考虑,在基本表的基础上再建立必要的视图(View),形成数据的外模式。

4、物理设计阶段:根据DBMS特点和处理的需要,进行物理存储安排,建立索引,形成数据库内模式。

② 数据库如何设计

数据库设计的基本步骤

按照规范设计的方法,考虑数据库及其应用系统开发全过程,将数据库设计分为以下6个阶段

1.需求分析

2.概念结构设计

3.逻辑结构设计

4.物理结构设计

5.数据库实施

6.数据库的运行和维护


数据库设计通常分为6个阶段1分析用户的需求,包括数据、功能和性能需求;2概念结构设计:主要采用E-R模型进行设计,包括画E-R图;3逻辑结构设计:通过将转换成表,实现从E-R模型到关系模型的转换;4:主要是为所设计的数据库选择合适的和存取路径;5数据库的实施:包括编程、测试和试运行;6数据库运行与维护:系统的运行与数据库的日常维护。),主要讨论其中的第3个阶段,即逻辑设计。



在数据库设计过程中,需求分析和概念设计可以独立于任何数据库管理系统进行,逻辑设计和物理设计与选用的DAMS密切相关。

1.需求分析阶段(常用自顶向下)

进行数据库设计首先必须准确了解和分析用户需求(包括数据与处理)。需求分析是整个设计过程的基础,也是最困难,最耗时的一步。需求分析是否做得充分和准确,决定了在其上构建数据库大厦的速度与质量。需求分析做的不好,会导致整个数据库设计返工重做。

需求分析的任务,是通过详细调查现实世界要处理的对象,充分了解原系统工作概况,明确用户的各种需求,然后在此基础上确定新的系统功能,新系统还得充分考虑今后可能的扩充与改变,不仅仅能够按当前应用需求来设计。

调查的重点是,数据与处理。达到信息要求,处理要求,安全性和完整性要求。

分析方法常用SA(Structured Analysis) 结构化分析方法,SA方法从最上层的系统组织结构入手,采用自顶向下,逐层分解的方式分析系统。

数据流图表达了数据和处理过程的关系,在SA方法中,处理过程的处理逻辑常常借助判定表或判定树来描述。在处理功能逐步分解的同事,系统中的数据也逐级分解,形成若干层次的数据流图。系统中的数据则借助数据字典(data dictionary,DD)来描述。数据字典是系统中各类数据描述的集合,数据字典通常包括数据项,数据结构,数据流,数据存储,和处理过程5个阶段。

2.概念结构设计阶段(常用自底向上)

概念结构设计是整个数据库设计的关键,它通过对用户需求进行综合,归纳与抽象,形成了一个独立于具体DBMS的概念模型。

设计概念结构通常有四类方法:

  • 自顶向下。即首先定义全局概念结构的框架,再逐步细化。

  • 自底向上。即首先定义各局部应用的概念结构,然后再将他们集成起来,得到全局概念结构。

  • 逐步扩张。首先定义最重要的核心概念结构,然后向外扩张,以滚雪球的方式逐步生成其他的概念结构,直至总体概念结构。

  • 混合策略。即自顶向下和自底向上相结合。

  • 3.逻辑结构设计阶段(E-R图)

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

    在这阶段,E-R图显得异常重要。大家要学会各个实体定义的属性来画出总体的E-R图。

    各分E-R图之间的冲突主要有三类:属性冲突,命名冲突,和结构冲突。

    E-R图向关系模型的转换,要解决的问题是如何将实体性和实体间的联系转换为关系模式,如何确定这些关系模式的属性和码。

    4.物理设计阶段

    物理设计是为逻辑数据结构模型选取一个最适合应用环境的物理结构(包括存储结构和存取方法)。

    首先要对运行的事务详细分析,获得选择物理数据库设计所需要的参数,其次,要充分了解所用的RDBMS的内部特征,特别是系统提供的存取方法和存储结构。

    常用的存取方法有三类:1.索引方法,目前主要是B+树索引方法。2.聚簇方法(Clustering)方法。3.是HASH方法。

    5.数据库实施阶段

    数据库实施阶段,设计人员运营DBMS提供的数据库语言(如sql)及其宿主语言,根据逻辑设计和物理设计的结果建立数据库,编制和调试应用程序,组织数据入库,并进行试运行。

    6.数据库运行和维护阶段

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

    数据库设计5步骤
    Five Steps to design the Database

    1.确定entities及relationships

    a)明确宏观行为。数据库是用来做什么的?比如,管理雇员的信息。

    b)确定entities。对于一系列的行为,确定所管理信息所涉及到的主题范围。这将变成table。比如,雇用员工,指定具体部门,确定技能等级。

    c)确定relationships。分析行为,确定tables之间有何种关系。比如,部门与雇员之间存在一种关系。给这种关系命名。

    d)细化行为。从宏观行为开始,现在仔细检查这些行为,看有哪些行为能转为微观行为。比如,管理雇员的信息可细化为:

    · 增加新员工

    · 修改存在员工信息

    · 删除调走的员工

    e)确定业务规则。分析业务规则,确定你要采取哪种。比如,可能有这样一种规则,一个部门有且只能有一个部门领导。这些规则将被设计到数据库的结构中。

    ====================================================================
    范例:
    ACME是一个小公司,在5个地方都设有办事处。当前,有75名员工。公司准备快速扩大规模,划分了9个部门,每个部门都有其领导。
    为有助于寻求新的员工,人事部门规划了68种技能,为将来人事管理作好准备。员工被招进时,每一种技能的专业等级都被确定。


    定义宏观行为
    一些ACME公司的宏观行为包括:
    ● 招聘员工
    ● 解雇员工
    ● 管理员工个人信息
    ● 管理公司所需的技能信息
    ● 管理哪位员工有哪些技能
    ● 管理部门信息
    ● 管理办事处信息
    确定entities及relationships
    我们可以确定要存放信息的主题领域(表)及其关系,并创建一个基于宏观行为及描述的图表。
    我们用方框来代表table,用菱形代表relationship。我们可以确定哪些relationship是一对多,一对一,及多对多。
    这是一个E-R草图,以后会细化。


    细化宏观行为
    以下微观行为基于上面宏观行为而形成:
    ● 增加或删除一个员工
    ● 增加或删除一个办事处
    ● 列出一个部门中的所有员工
    ● 增加一项技能
    ● 增加一个员工的一项技能
    ● 确定一个员工的技能
    ● 确定一个员工每项技能的等级
    ● 确定所有拥有相同等级的某项技能的员工
    ● 修改员工的技能等级

    这些微观行为可用来确定需要哪些table或relationship。

    确定业务规则
    业务规则常用于确定一对多,一对一,及多对多关系。
    相关的业务规则可能有:
    ● 现在有5个办事处;最多允许扩展到10个。
    ● 员工可以改变部门或办事处
    ● 每个部门有一个部门领导
    ● 每个办事处至多有3个电话号码
    ● 每个电话号码有一个或多个扩展
    ● 员工被招进时,每一种技能的专业等级都被确定。
    ● 每位员工拥有3到20个技能
    ● 某位员工可能被安排在一个办事处,也可能不安排办事处。

    2.确定所需数据

    要确定所需数据:

    a)确定支持数据

    b)列出所要跟踪的所有数据。描述table(主题)的数据回答这些问题:谁,什么,哪里,何时,以及为什么

    c)为每个table建立数据

    d)列出每个table目前看起来合适的可用数据

    e)为每个relationship设置数据

    f)如果有,为每个relationship列出适用的数据

    确定支持数据

    你所确定的支持数据将会成为table中的字段名。比如,下列数据将适用于表Employee,表Skill,表Expert In。

    Employee

  • Skill

  • Expert In

  • ID

  • ID

  • Level

  • Last Name

  • Name

  • Date acquired

  • First Name

  • Description

  • Department

  • Office

  • Address


  • 如果将这些数据画成图表,就像:


  • 需要注意:

  • ● 在确定支持数据时,请一定要参考你之前所确定的宏观行为,以清楚如何利用这些数据。

  • ● 比如,如果你知道你需要所有员工的按姓氏排序的列表,确保你将支持数据分解为名字与姓氏,这比简单地提供一个名字会更好。

  • ● 你所选择的名称最好保持一致性。这将更易于维护数据库,也更易于阅读所输出的报表。

  • ● 比如,如果你在某些地方用了一个缩写名称Emp_status,你就不应该在另外一个地方使用全名(Empolyee_ID)。相反,这些名称应当是Emp_status及Emp_id。

  • ● 数据是否与正确的table相对应无关紧要,你可以根据自己的喜好来定。在下节中,你会通过测试对此作出判断。
  • 3.标准化数据

    标准化是你用以消除数据冗余及确保数据与正确的table或relationship相关联的一系列测试。共有5个测试。本节中,我们将讨论经常使用的3个。
    关于标准化测试的更多信息,请参考有关数据库设计的书籍。

    标准化格式
    标准化格式是标准化数据的常用测试方式。你的数据通过第一遍测试后,就被认为是达到第一标准化格式;通过第二遍测试,达到第二标准化格式;通过第三遍测试,达到第三标准化格式。

    如何标准格式:
    1. 列出数据
    2. 为每个表确定至少一个键。每个表必须有一个主键。
    3. 确定relationships的键。relationships的键是连接两个表的键。
    4. 检查支持数据列表中的计算数据。计算数据通常不保存在数据库中。
    5. 将数据放在第一遍的标准化格式中:
    6. 从tables及relationships除去重复的数据。
    7. 以你所除去数据创建一个或更多的tables及relationships。
    8. 将数据放在第二遍的标准化格式中:
    9. 用多于一个以上的键确定tables及relationships。
    10. 除去只依赖于键一部分的数据。
    11. 以你所除去数据创建一个或更多的tables及relationships。
    12. 将数据放在第三遍的标准化格式中:
    13. 除去那些依赖于tables或relationships中其他数据,并且不是键的数据。
    14. 以你所除去数据创建一个或更多的tables及relationships。

    数据与键
    在你开始标准化(测试数据)前,简单地列出数据,并为每张表确定一个唯一的主键。这个键可以由一个字段或几个字段(连锁键)组成。

    主键是一张表中唯一区分各行的一组字段。Employee表的主键是Employee ID字段。Works In relationship中的主键包括Office Code及Employee ID字段。给数据库中每一relationship给出一个键,从其所连接的每一个table中抽取其键产生。

    RelationShip

  • Key

  • Office

  • *Office code

  • Office address

  • Phone number

  • Works in

  • *Office code

  • *Employee ID

  • Department

  • *Department ID

  • Department name

  • Heads

  • *Department ID

  • *Employee ID

  • Assoc with

  • *Department ID

  • *EmployeeID

  • Skill

  • *Skill ID

  • Skill name

  • Skill description

  • Expert In

  • *Skill ID

  • *Employee ID

  • Skill level

  • Date acquired

  • Employee

  • *Employee ID

  • Last Name

  • First Name

  • Social security number

  • Employee street

  • Employee city

  • Employee state

  • Employee phone

  • Date of birth


  • 将数据放在第一遍的标准化格式中
    ● 除去重复的组
    ● 要测试第一遍标准化格式,除去重复的组,并将它们放进他们各自的一张表中。
    ● 在下面的例子中,Phone Number可以重复。(一个工作人员可以有多于一个的电话号码。)将重复的组除去,创建一个名为Telephone的新表。在Telephone与Office创建一个名为Associated With的relationship。

    将数据放在第二遍的标准化格式中
    ● 除去那些不依赖于整个键的数据。
    ● 只看那些有一个以上键的tables及relationships。要测试第二遍标准化格式,除去那些不依赖于整个键的任何数据(组成键的所有字段)。
    ● 在此例中,原Employee表有一个由两个字段组成的键。一些数据不依赖于整个键;例如,department name只依赖于其中一个键(Department ID)。因此,Department ID,其他Employee数据并不依赖于它,应移至一个名为Department的新表中,并为Employee及Department建立一个名为Assigned To的relationship。


    将数据放在第三遍的标准化格式中
    ● 除去那些不直接依赖于键的数据。
    ● 要测试第三遍标准化格式,除去那些不是直接依赖于键,而是依赖于其他数据的数据。
    ● 在此例中,原Employee表有依赖于其键(Employee ID)的数据。然而,office location及office phone依赖于其他字段,即Office Code。它们不直接依赖于Employee ID键。将这组数据,包括Office Code,移至一个名为Office的新表中,并为Employee及Office建立一个名为Works In的relationship。

    4.考量关系

    当你完成标准化进程后,你的设计已经差不多完成了。你所需要做的,就是考量关系。

    考量带有数据的关系
    你的一些relationship可能集含有数据。这经常发生在多对多的关系中。

    遇到这种情况,将relationship转化为一个table。relationship的键依旧成为table中的键。

    考量没有数据的关系
    要实现没有数据的关系,你需要定义外部键。外部键是含有另外一个表中主键的一个或多个字段。外部键使你能同时连接多表数据。

    有一些基本原则能帮助你决定将这些键放在哪里:

    一对多在一对多关系中,“一”中的主键放在“多”中。此例中,外部键放在Employee表中。

    一对一在一对一关系中,外部键可以放进任一表中。如果必须要放在某一边,而不能放在另一边,应该放在必须的一边。此例中,外部键(Head ID)在Department表中,因为这是必需的。

    多对多在多对多关系中,用两个外部键来创建一个新表。已存的旧表通过这个新表来发生联系。

    5.检验设计

    在你完成设计之前,你需要确保它满足你的需要。检查你在一开始时所定义的行为,确认你可以获取行为所需要的所有数据:
    ● 你能找到一个路径来等到你所需要的所有信息吗?
    ● 设计是否满足了你的需要?
    ● 所有需要的数据都可用吗?
    如果你对以上的问题都回答是,你已经差不多完成设计了。

    最终设计
    最终设计看起来就像这样:

    设计数据库的表属性
    数据库设计需要确定有什么表,每张表有什么字段。此节讨论如何指定各字段的属性。

    对于每一字段,你必须决定字段名,数据类型及大小,是否允许NULL值,以及你是否希望数据库限制字段中所允许的值。

    选择字段名
    字段名可以是字母、数字或符号的任意组合。然而,如果字段名包括了字母、数字或下划线、或并不以字母打头,或者它是个关键字(详见关键字表),那么当使用字段名称时,必须用双引号括起来。

    为字段选择数据类型
    SQL Anywhere支持的数据类型包括:
    整数(int, integer, smallint)
    小数(decimal, numeric)
    浮点数(float, double)
    字符型(char, varchar, long varchar)
    二进制数据类型(binary, long binary)
    日期/时间类型(date, time, timestamp)
    用户自定义类型

    关于数据类型的内容,请参见“SQL Anywhere数据类型”一节。字段的数据类型影响字段的最大尺寸。例如,如果你指定SMALLINT,此字段可以容纳32,767的整数。INTEGER可以容纳2,147,483,647的整数。对CHAR来讲,字段的最大值必须指定。

    长二进制的数据类型可用来在数据库中保存例如图像(如位图)或者文字编辑文档。这些类型的信息通常被称为二进制大型对象,或者BLOBS。

    关于每一数据类型的完整描述,见“SQL Anywhere数据类型”。

③ 试述数据库设计的过程,结构设计中各阶段的主要工作及设计结果。

数据库设计步骤:1规划 2需求分析 3概念设计 4逻辑结构设计 5数据库的物理设计 6数据库的实现 7数据库的运行与维护
第一步,规划。规划阶段的主要任务是进行建立数据库的必要性及可行性分析。如系统调查(即对企业全面调查,画出组织层次图,以了企业组织结构),可行性分析,确定DBS(数据库系统)的总目标和制定项目开发计划。
第二步,需求分析。需求分析阶段应该对系统的整个应用情况作全面的、详细的调查,确定企业组织的目标,收集支持系统总的设计目标的基础数据和对这些数据的要求,确定用户的需求,并把这些要求写成用户和数据库设计者都能够接受的需求分析报告。这一阶段的工作只要有,分析用户活动,产生业务流程图;确定系统范围,产生体统范围图;分析用户活动涉及的数据,产生数据流程图;分析系统数据,产生数据字典。
第三步,概念设计。概念设计的目标是产生反应企业组织信息需求的数据库概念结构,即设计出独立与计算机硬件和DBMS(数据库管理系统)的概念模式。E-R模型是主要设计工具。
第四步,逻辑结构设计。其目的是把概念设计阶段设计好的全局E-R模式转换成与选用的具体机器上的DBMS所支持的数据模型相符合的逻辑结构(包括数据库模式和外模式)。
第五步,数据库的物理设计。对于给定的数据模型选取一个最适合应用应用环境的物理结构的过程。数据库的物理结构主要指数据库的存储记录格式、存储记录安排和存取方法,完全依赖于给定的硬件环境赫尔数据库产品。
第六步,数据库的实现。该阶段主要有3项工作:1建立实际数据库结构 2装入试验数据对应用程序进行调试 3装入实际数据,进入试运行状态。
第七步,数据库的运行与维护。数据库系统的正式运行,标志着数据库设计与应用开发工作的结束和维护阶段的开始,该阶段有4项任务:1维护数据库的安全性与完整性 2监测并改善数据库运行性能 3根据用户要求对数据库现有功能进行扩充 4及时改正运行中发现的系统错误。

④ 说明在创建数据库时如何合理规划数据库的物理存储结构和逻辑存储结构

Oracle数据库的逻辑结构和物理结构

Oracle 数据库的逻辑结构是由一些数据库对象组成,如数据库表空间、表、索引、段、视图、存储过程、触发器等。数据库的逻辑存储结构(表空间等)决定了数据库的物理空间是如何被使用的,数据库对象如表、索引等分布在各个表空间中。

Oracle 数据库的物理结构从操作系统一级查看,是由一个个的文件组成,从物理上可划分为:数据文件、日志文件、控制文件和参数文件。数据文件中存放了所有的数据信息;日志文件存放数据库运行期间产生的日志信息,它被重复覆盖使用,若不采用归档方式的话,已被覆盖的日志信息将无法恢复;控制文件记录了整个数据库的关键结构信息,它若被破坏,整个数据库将无法工作和恢复;参数文件中设置了很多Oracle 数据库的配置参数,当数据库启动时,会读取这些信息。

逻辑结构的优化

逻辑结构优化用通俗的话来说就是通过增加、减少或调整逻辑结构来提高应用的效率,下面通过对基本表的设计及索引、聚簇的讨论来分析ORACLE逻辑结构的优化。

1、基本表扩展

数据库性能包括存储空间需求量的大小和查询响应时间的长短两个方面。为了优化数据库性能,需要对数据库中的表进行规范化。一般来说,逻辑数据库设计满足第三范式的表结构容易维护且基本满足实际应用的要求。所以,实际应用中一般都按照第三范式的标准进行规范化,从而保证了数据库的一致性和完整性,设计人员往往会设计过多的表间关联,以尽可能地降低数据冗余。但在实际应用中这种做法有时不利于系统运行性能的优化:如过程从多表获取数据时引发大量的连接操作,在需要部分数据时要扫描整个表等,这都消耗了磁盘的I/O 和CPU 时间。

为解决这一问题,在设计表时应同时考虑对某些表进行反规范化,方法有以下几种:一是分割表。分割表可分为水平分割表和垂直分割表两种:水平分割是按照行将一个表分割为多个表,这可以提高每个表的查询速度,但查询、更新时要选择不同的表,统计时要汇总多个表,因此应用程序会更复杂。垂直分割是对于一个列很多的表,若某些列的访问频率远远高于其它列,就可以将主键和这些列作为一个表,将主键和其它列作为另外一个表。通过减少列的宽度,增加了每个数据页的行数,一次I/O就可以扫描更多的行,从而提高了访问每一个表的速度。但是由于造成了多表连接,所以应该在同时查询或更新不同分割表中的列的情况比较少的情况下使用。二是保留冗余列。当两个或多个表在查询中经常需要连接时,可以在其中一个表上增加若干冗余的列,以避免表之间的连接过于频繁,一般在冗余列的数据不经常变动的情况下使用。三是增加派生列。派生列是由表中的其它多个列的计算所得,增加派生列可以减少统计运算,在数据汇总时可以大大缩短运算时间。

因此,在数据库的设计中,数据应当按两种类别进行组织:频繁访问的数据和频繁修改的数据。对于频繁访问但是不频繁修改的数据,内部设计应当物理不规范化。对于频繁修改但并不频繁访问的数据,内部设计应当物理规范化。有时还需将规范化的表作为逻辑数据库设计的基础,然后再根据整个应用系统的需要,物理地非规范化数据。规范与反规范都是建立在实际的操作基础之上的约束,脱离了实际两者都没有意义。只有把两者合理地结合在一起,才能相互补充,发挥各自的优点。

2、索引和聚簇

创建索引是提高检索效率最有效的方法之一,索引把表中的逻辑值映射到安全的RowID,能快速定位数据的物理地址,可以大大加快数据库的查询速度,一个建有合理索引的数据库应用系统可能比一个没有建立索引的数据库应用系统效率高几十倍,但并不是索引越多越好,在那些经常需要修改的数据列上建立索引,将导致索引B*树的不断重组,造成系统性能的下降和存储空间的浪费。对于一个大型表建立的索引,有时并不能改善数据查询速度,反而会影响整个数据库的性能。这主要是和SGA的数据管理方式有关,Oracle在进行数据块高速缓存管理时,索引数据比普通数据具有更高的驻留权限,在进行空间竞争时,Oracle会先移出普通数据,对建有索引的大型表进行数据查询时,索引数据可能会用完所有的数据块缓存空间,Oracle不得不频繁地进行磁盘读写来获取数据,所以,在对一个大型表进行分区之后,可以根据相应的分区建立分区索引。

Oracle提供了另一种方法来提高查询速度,就是聚簇(Cluster)。所谓聚簇,简单地说就是把几个表放在一起,按一定公共属性混合存放。聚簇根据共同码值将多个表的数据存储在同一个Oracle块中,这时检索一组Oracle块就同时得到两个表的数据,这样就可以减少需要存储的Oracle块,从而提高应用程序的性能。

对于逻辑结构的优化,还应将表数据和索引数据分开表空间存储,分别使用独立的表空间。因为如果将表数据和索引数据放在一起,表数据的I/O操作和索引的I/O操作将产生影响系统性能的I/O竞争,降低系统的响应效率。将表数据和索引数据存放在不同的表空间中,并在物理层面将这两个表空间的数据文件放在不同的物理磁盘上,就可以避免这种竞争了。

物理结构的优化

数据库的数据最终是存储在物理磁盘上的,对数据进行访问就是对这些物理磁盘进行读写,因此对于这些物理存储的优化是系统优化的一个重要部分。对于物理存储结构优化,主要是合理地分配逻辑结构的物理存储地址,这样虽不能减少对物理存储的读写次数,但却可以使这些读写尽量并行,减少磁盘读写竞争,从而提高效率,也可以通过对物理存储进行精密的计算减少不必要的物理存储结构扩充,从而提高系统利用率。

1、磁盘读写并行优化

对于数据库的物理读写,Oracle系统本身会进行尽可能的并行优化,例如在一个最简单的表检索操作中,如果表结构和检索域上的索引不在一个物理结构上,那么在检索的过程中,对索引的检索和对表的检索就是并行进行的。

2、操作并行优化

操作并行的优化是基于操作语句的统计结果,首先是统计各个表的访问频率,表之间的连接频率,根据这些数据按如下原则分配表空间和物理磁盘,减少系统进程和用户进程的磁盘I/O竞争;把需要连接的表格在表空间/物理磁盘上分开;把高频访问的表格在表空间/物理磁盘上分开;把经常需要进行检索的表格的表结构和索引在表空间/物理磁盘上分开。

3、减少存储结构扩展

如果应用系统的数据库比较脆弱,并在不断地增长或缩小,这样的系统在非动态变化周期内效率合理,但是当在动态变化周期内的时候,性能却很差,这是由于Oracle的动态扩展造成的。在动态扩张的过程中,Oracle必须根据存储的要求,在创建行、行变化获取缺省值时,扩展和分配新的存储空间,而且表格的扩展往往并不是事情的终结,还可能导致数据文件、表空间的增长,这些扩展会导致在线系统反应缓慢。对于这样的系统,最好的办法就是在建立的时候预先分配足够的大小和合适的增长幅度。在一个对象建立的时候要根据应用充分地计算他们的大小,然后再根据这些数据来定义对象Initial、Next和Minextents的值,使数据库在物理存储上和动态增长次数上达到一个比较好的平衡点,使这些对象既不经常发生增长,也不过多地占用数据库。

⑤ 求高手详细解释数据规划和数据库规划/设计的区别,不要百度百科里那种模棱两可的答案,最好有自己见解的

我也说不明白,大概理解是这样:
数据存储过程-----数据逻辑------数据表----数据透视
大型的数据库是用Oracle来完成的,SQL中也包括这种做法,
1. 按周期备份数据库,按数据逻辑备份数据库,按自动编号记录数据变更痕迹,这是第一层
2. 用数据逻辑来建立数据表,如工厂的切割BOMB生产物料清单,银行的业主基本资料
3. 数据表层是记录资料的
4. 数据透视是分析数据的
数据表就象大树上的叶子,数据透视是树枝,逻辑是他的神经系统,存储过程是他的根。所以前期规划应该是搭建服务器,建立表存储过程规则和主表索引,子表索引,自动编号过程
第二个过程搜集基础资料,做物料清单、基础信息,进入数据调查阶段,规范层次逻辑
第三步就要建立数据表了,实施数据表建立和软件部署,发布软件
第四步进入测试阶段,建立数据透视,搜集资料重新按照实际应用制作客户端和服务器应用程序,搭建三层结构,并且建立数据权限,这一步最重要。
我是这么做的

⑥ .数据库设计分为几个阶段,各阶段的任务是什么

按照规范的设计方法,一个完整的数据库设计一般分为需求分析、概念结构设计、逻辑结构设计、数据库物理设计、数据库的实施、数据库运行与维护六个阶段:

各阶段的任务如下:

1、需求分析:分析用户的需求,包括数据、功能和性能需求;

拓展资料:

数据库设计(Database Design)是指对于一个给定的应用环境,构造最优的数据库模式,建立数据库及其应用系统,使之能够有效地存储数据,满足各种用户的应用需求(信息要求和处理要求)。在数据库领域内,常常把使用数据库的各类系统统称为数据库应用系统。

数据库设计是建立数据库及其应用系统的技术,是信息系统开发和建设中的核心技术。由于数据库应用系统的复杂性,为了支持相关程序运行,数据库设计就变得异常复杂,因此最佳设计不可能一蹴而就,而只能是一种"反复探寻,逐步求精"的过程,也就是规划和结构化数据库中的数据对象以及这些数据对象之间关系的过程。

⑦ 数据库设计的基本步骤

数据库设计的基本步骤如下:

1、安装并打开MySQL WorkBench软件以后,在软件的左侧边栏有三个选项,分别是对应“连接数据库”、“设计数据库”、“迁移数据库”的功能。这类选择第二项,设计数据库,点击右边的“+”号,创建models。

⑧ 简述数据库应用系统的设计步骤

数据库设计的基本步骤:

1、系统需求分析与设计。

2、概念结构分析与设计。

3、逻辑结构分析与设计。

4、物理结构分析与设计。

5、系统实施。

6、系统维护。

(8)数据库设计规划扩展阅读:

数据库设计技巧:

1、原始文件与实体的关系

它可以是一对一,一对多,多对多的关系。一般来说,它们是一对一的关系:一个原始文档只对应于一个实体。在特殊情况下,它们可以是一对多或多对一关系,即一个原始文档对应于多个实体,或者多个原始文档对应于一个实体。

这里的实体可以理解为基本表。在对应关系明确后,对输入接口的设计非常有利。

2、主键和外键

一般来说,实体不能既没有主键也没有外键。在E-R图中,叶中的实体可以定义主键或不定义主键(因为它没有子代),但它必须有外键(因为它有父项)。

主键和外键的设计在全局数据库的设计中起着重要的作用。当全球数据库的设计完成后,一位美国数据库设计专家说:“钥匙无处不在,只有钥匙。”。这是他数据库设计的经验,也体现了他对信息系统核心(数据模型)高度抽象的理念。

因为:主键是一个高度抽象的实体。主键和外键的配对表示实体之间的连接。

3、基本表的属性

基本表不同于中间表和临时表,因为它具有以下四个特点:

原子性。基本表中的字段不可分解。

原始主义。基本表中的记录是原始数据(基本数据)的记录。

演绎的。所有输出数据都可以从基本表和代码表中的数据导出。

稳定。基本表的结构比较稳定,表中的记录要长期保存。

在了解基本表的性质之后,在设计数据库时,可以将基本表与中间表和临时表区分开来。

⑨ 数据库规划一般要包含那些内容

DB2数据库的性能与稳定性直接跟数据库对象的多少、大小有关。如果对象很少,不复杂,那么就算不怎么规划,也能够达到比较高的性能。如果对象数据比较多、比较大的话,那么就需要在数据库设计之前好好的规划,否则会在很大程度上影响数据库的性能与稳定性。

一、选择合适的语言与数据库字符集。

在企业中部署数据库的时候,首先需要在操作系统上安装数据库。而在安装数据库的时候,需要选择安装的语言环境。即是以中文状态下安装数据库还是以英文状态安装数据库。如在启动安装程序的时,可以利用/i language选项来指定安装过程中所采用的语言。到目前为止,DB2数据库已经支持很多种语言。那么数据库在安装过程中,该采用什么语言呢?笔者建议,只要数据库管理员有一点英语基础,最好能够采用英文语言环境来进行安装。虽然说现在DB2数据库的中文语言环境已经设计的比较完善,但是笔者仍然担心其有一些不知名的漏洞。为此笔者在安装DB2数据库的时候,基本上都采用的是英文语言环境来进行安装。即将语言设置为“EN”,表示英文。提高DB2数据备份与恢复的效率。

另外如果DB2 数据库中要保存英文以外的数据,或者说用户会使用不同的字符集访问数据库时,还需要在数据库安装过程中选择特定的数据库字符集。DB2数据库中的所有字符数据,包括数据字典中的数据,都是存储在数据库字符集中的。如果用户使用不同的字符集访问数据库时,数据库管理员就需要选择包含所有这些用户的字符集的超集。只有如此,才能够确保系统能够很方便的使用替代字符完成字符的转换,从而提高数据库的性能。如果用户选择的字符集不对,有可能会出现一些莫名其妙的问题。如一次用户在安装数据库过程中,没有选择合适的字符集。虽然在使用的过程中,其存储中文字符没有问题。但是当对数据库采取还原操作时,却发现还原后的数据库中有些原来是中文字符的地方,尽然出现了乱码。这主要就是没有选择合适的字符集惹的祸。有时候如果字符集选择不当的话,从外部数据源(如Excel表格)导入数据的时候,中文数据也会无法顺利导入。所以,数据库管理员在安装数据库的时候,需要根据实际企业,来选择合适的字符集。

二、评估数据库对象的大小、数量。

DB2数据库的性能与稳定性直接跟数据库对象的多少、大小有关。如果对象很少,不复杂,那么就算不怎么规划,也能够达到比较高的性能。如果对象数据比较多、比较大的话,那么就需要在数据库设计之前好好的规划,否则会在很大程度上影响数据库的性能与稳定性。其实DB2 数据库就好像一个仓库,数据库中的对象(如索引、数据表、表空间)等等就好像仓库中的货物。如果货物比较少,那么随便放放,仓库都显得很空旷。货物寻找起来也会很方便。但是如果货物数量比较多、比较大,就必须要对其存储空间进行合理规划。只有如此才能够让仓库的空间利用率达到最佳状态。并且货物的存放有序,在查找起来也特别的方便。笔者这里就以仓库管理为例,说话该如何做好数据库对象大小、数量等方便的评估,以及他们对于数据库性能与稳定性的影响。

1、根据对象大小来规划存储空间。在仓库货物的摆放上,要根据货物的大小来规划存储空间。或者说要首先防止大的货物。只有如此空间的利用率才会最高。其实在规划DB2对象的时候,也是如此。如某些表可能会包含的记录比较多,属于大表。此时数据库管理员就需要考虑,是否将其放置在一个独立的表空间或者硬盘空间上,以提高数据操作的性能。大表所对应的索引往往也是比较大的。为此在硬件条件允许的情况下,将索引表与数据表分别存放在不同的硬盘上,可以提高数据库的性能。而对于一些比较小的对象(如数据表),可以将它们存放在一个表空间中。其实这个表空间就好像仓库中的一个个纸盒子。将小的对象放入到这个“纸盒子”中,不但不占空间,而且也容易管理。

2、根据对象的使用频率来规划存放空间。在仓库中摆放物品的时候,往往会把近期就要用到的货物或者频繁需要用到的东西放在仓库门口或者容易拿到的地方。如此在拿这些货物时就会比较便捷,也不会对其他货物产生影响。对于DB2数据库中的对象来说,也是这么一回事。可以将那些访问量比较大的对象,如索引、数据表,存放在性能比较好的硬盘上或者单独的硬盘中。此时访问这些数据,就不会与其它对象产生I/O冲突,操作起来速度就会比较快。而将不怎么用到的对象,存放在一起。由于他们不怎么被用到,所以即使存放在性能比较低的硬盘上,其对数据库性能产生的负面影响也是非常有限的。 在DB2数据库里面如何更新执行计划

3、根据类别来存放数据库对象。在仓库中存放货物的时候,还会对其进行分类。然后根据类别来进行存放。这有利于货物的管理与检索。其实在数据库对象存储空间设计时,也需要考虑这个因素。如现在应用软件在设计的时候,很多都是根据模块来设计。那么在数据库对象设计时,也需要根据这个模块来设计存储的空间。如将同一个模块的数据库对象存放在同一个表空间内。不过这可能会跟上面的两个建立相违背。此时最好是在对象的命名上做文章。如可以根据模块的不同,分别给数据库对象取一个相同的前缀或者后缀。如即使同一块模块要用到多个表空间,此时就可以给表空间一个相同的前缀。如此在管理数据库对象的时候,根据表空间的前缀就可以判断其所属的模块了。如果再加上一个后缀来表示其数据库对象的分类,那么就更合理了。为此在管理数据库对象的时候,要执行分类管理。不仅要从技术上对其进行分类,如分为索引、数据表、关键字等等。还需要从功能上进行分类,如按应用程序的模块来进行分类等等。

三、设计好数据库备份与还原的方案。

在数据库交付生产使用之后,往往需要进行大量的测试。但是在测试过程中往往又会产生很多的垃圾数据。可是交给企业应用的,肯定是一个干净的数据库系统。为此在数据库设计的时候,就需要想好如果减少测试过程中的垃圾数据。或者采取什么样的方式来实现在交互时自动清除垃圾数据的机制。

一般来说,想要一个数据库备份与还原的方案,减少数据库测试所产生的垃圾数据。如现在在给企业部署数据库的时候,往往是先安装一个干净的数据库系统。当然字符集这些需要预先设置好。然后再利用数据库还原功能将预先定义好的数据库模型还原出来。

另外有些时候需要两个方案互为补充。如在数据库初始化的过程中,采用数据库还原的方式来创建数据库对象。但是在应用软件升级的时候,由于此时已经有了用户的数据,为此不能够在使用数据库还原的方法。而是通过应用程序来执行某些SQL代码,来调整或者增加部分数据库对象。无论采用哪一种方式,需要遵循的一个原则就是在给企业创建数据库对象时要最大限度的减少测试。而要做到这一点,就是需要先在测试服务器上创建对象并测试对象可用。然后直接将相关的SQL代码在投入使用的数据库服务器上执行。