|
|
知识路径： > 数据库应用基础知识 > 数据库应用基础知识 > 数据库管理系统的基本理论 >
|
被考次数：26次
被考频率：高频率
总体答错率：41%
知识难度系数： 
|
由 软考在线 用户真实做题大数据统计生成
|
|
考试要求：熟悉
相关知识点：10个
|
|
|
|
|
数据库系统是对数据进行存储、管理、处理和维护的软件系统，是现代计算环境中的一个核心成分。随着计算机硬件、软件技术的飞速发展和计算机系统在各行各业的广泛应用，数据库技术的发展尤其迅速，引人注目。有关数据库系统的理论和技术是计算机科学技术教育中必不可少的部分。
|
|
|
|
|
|
数据库是存储在一起的相关数据的集合，这些数据是结构化的，无有害的或不必要的冗余，并为多种应用服务。数据的存储独立于使用它的程序。对数据库插入新数据，修改和检索原有数据均能按一种公用的和可控制的方式进行。
|
|
|
|
|
|
数据库应用系统是指系统开发人员利用数据库系统资源开发的面向某一类实际应用的软件系统。例如，企业职工管理系统、学籍管理系统、工资管理系统和图书管理系统等。
|
|
|
|
|
|
数据库管理系统（DataBase Management System，DBMS）是对数据进行科学地组织和存储，帮助用户高效地获取或维护数据的系统软件。数据库管理系统是位于用户与操作系统之间的一层数据管理软件。其主要功能是为用户或应用程序提供访问数据库的方法，包括数据库的建立、查询、更新及各种数据控制。
|
|
|
|
|
|
数据库系统（DataBase System）是指引进数据库技术后的计算机系统，能实现有组织地、动态地存储大量的相关数据，提供数据处理和信息资源共享的便利手段。
|
|
|
|
|
|
E-R（实体-联系）模型是一种描述信息世界的重要手段。E-R模型独立于具体的计算机系统。E-R模型的主要成分是实体、联系和属性，通常可用E-R图来表示。矩形表示实体型，矩形框内为实体名；椭圆表示属性，椭圆框内为属性名；菱形表示联系，菱形框内为联系名。
|
|
|
|
（1）实体：客观存在并可相互区分的事物。同一类型实体的集合构成实体集。
|
|
|
|
（2）属性：实体所具有的某一特性。一个实体可以由若干个属性来描述。实体名和各个属性名的集合构成实体型。
|
|
|
|
（3）联系：现实世界的事物之间存在的联系，包括实体内部的联系和实体之间的联系。两个实体之间的联系可分为三类：
|
|
|
|
①一对一联系（1:1）：如果对于实体集A中的每一个实体，实体集B中至多有一个实体与之对应；反之亦然，则称A与B具有一对一联系。
|
|
|
|
②一对多联系（1:n）：如果对于实体集A中的每一个实体，实体集B中有n个实体（n≥0）与之对应；反之，对于实体集B中的每一个实体，实体集A中至多只有一个实体与之对应，则称A与B具有一对多联系。
|
|
|
|
③多对多联系（m:n）：如果对于实体集A中的每一个实体，实体集B中有n个实体（n≥0）与之对应；反之，对于实体集B中的每一个实体，实体集A中也有m个实体（m≥0）与之对应，则称A与B具有多对多联系。
|
|
|
|
|
|
数据模型是用来描述现实世界中的事物及其联系的，它将数据库中的数据按照一定的结构组织起来，并能反映事物本身及事物之间的各种联系。
|
|
|
|
|
|
不同的数据模型具有不同的数据结构形式。目前最常用的数据结构模型有如下4种：
|
|
|
|
①层次模型（Hierarchical Model）：用树型结构表示实体及其之间的联系。
|
|
|
|
②网络模型（Network Model）：用网状结构表示实体及其之间的联系。
|
|
|
|
③关系模型（Relational Model）：用二维表结构表示实体及其之间的联系。
|
|
|
|
④面向对象数据模型（Object Oriented Model）：用对象、类型、继承和方法等基本面向对象技术构造的实体及其之间的联系。
|
|
|
|
其中层次模型和网状模型统称为非关系模型。非关系模型的数据库系统在20世纪70年代非常流行，在数据库系统产品中占据了主导地位。关系数据模型以关系数学理论为基础，一个二维表就是一个关系，不仅能描述实体本身，而且还能反映实体之间的联系，模型简单，使用方便，应用也最广泛。
|
|
|
|
|
|
关系模型中常用的术语有关系、元组、属性、域、关系模式、主关键字和外部关键字。其中学生关系与术语的对应关系如下图所示。
|
|
|
|
|
|
|
|
关系：一个关系就是一张二维表，每个关系有一个关系名。
|
|
|
|
|
|
属性：表中的一列即为一个属性，也称为一个字段或者数据项。
|
|
|
|
域：属性的取值范围，例如性别的取值范围为“男”或“女”。
|
|
|
|
关系模式：对关系的描述，它对应一个关系的结构。可表示为：
|
|
|
|
|
|
主关键字：在表中能够唯一标识一个记录的属性或属性组合，称为候选关键字。一个表中可能有多个候选关键字，从中选择一个作为主关键字，简称主键。
|
|
|
|
外部关键字：如果表A和表B中有公共字段，且该字段在表B中是主键，则该字段在表A中就称为外部关键字，简称外键。
|
|
|
|
|
|
①关系中的每个属性必须是不可分割的数据项（表中不能再包含表）。
|
|
|
|
②关系中每一列元素必须是同一类型的数据，来自同一个域。
|
|
|
|
|
|
|
|
⑤关系中的行、列次序可以任意交换，不影响其信息内容。
|
|
|
|
|
|
E-R方法所得到的概念模型是对信息世界的描述，并不适用于计算机处理，为适合关系数据库系统的处理，必须将E-R图转换成关系模式。通常采用以下方法加以转换：
|
|
|
|
|
|
将E-R图中的实体逐一转换成为一个关系模式，实体名对应关系模式的名称，实体的属性转换成关系模式的属性，实体标识符就是关系的主键。
|
|
|
|
|
|
E-R图中的联系有三种：一对一联系（1:1）、一对多联系（1:n）和多对多联系（m:n），针对这三种不同的联系，有不同的转换方法。
|
|
|
|
一对一（1:1）联系的转换：可以转换为一个独立的关系模式，也可以与联系的任意一端实体所对应的关系模式合并。如果转换为一个独立的关系模式，则与该联系的各实体的码以及联系本身的属性均转换为关系的属性，每个实体的码均是该关系的候选码。如果与联系的任意一端实体所对应的关系模式合并，则需要在该关系模式的属性中加入另一个实体的码和联系本身的属性。
|
|
|
|
一对多（1:n）联系的转换：可以转换为一个独立的关系模式，也可以与联系的任意n端实体所对应的关系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而联系的码为n端实体的码。如果与联系的n端实体所对应的关系模式合并，则需要在该关系模式的属性中加入1端实体的码和联系本身的属性。
|
|
|
|
多对多（m:n）联系的转换：多对多联系只能转换成一个独立的关系模式，与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为各实体码的组合。
|
|
|
|
通过以上方法，就可以将E-R图中的实体、属性和联系全部转换为关系模式，建立初始的关系模式。
|
|
|
|
|
|
关系代数运算符有4类：集合运算符、专门的关系运算符、算术比较符和逻辑运算符。根据运算符的不同，关系代数运算可分为传统的集合运算和专门的关系运算。传统的集合运算是从关系的水平方向进行的，包括并、交、差及广义笛卡儿积。专门的关系运算既可以从关系的水平方向进行运算，又可以向关系的垂直方向运算，包括选择、投影、连接以及除法。如下表所示。
|
|
|
|
|
|
|
|
上表中的并、差、笛卡儿积、投影、选择是5种基本的运算，其他运算可以通过基本的运算导出。
|
|
|
|
|
|
数据库设计（Database Design）是指根据用户的需求，在某一具体的数据库管理系统上设计数据库的结构和建立数据库的过程。通常数据库的设计可分为6个阶段：
|
|
|
|
（1）需求分析阶段。调查和分析用户的业务活动和数据的使用情况，掌握所用数据的种类、范围、数量以及它们在业务活动中交流的情况，确定用户对数据库系统的使用要求和各种约束条件等，形成用户需求分析报告。
|
|
|
|
（2）概念设计阶段。对用户要求描述的现实世界（可能是一个公司、一个商场或者一个学校等），通过分类、聚集和概括，建立抽象的概念数据模型（例如E-R模型）。这个概念模型应反映现实世界各部门的信息结构、信息流动情况、信息间的互相制约关系以及各部门对信息储存、查询和加工的要求等。
|
|
|
|
（3）逻辑设计阶段。主要工作是将现实世界的概念数据模型设计成数据库的一种逻辑模式，即适应于某种特定数据库管理系统所支持的逻辑数据模式（例如关系模式）。与此同时，可能还需为各种数据处理应用领域产生相应的逻辑子模式。这一步设计的结果就是所谓“逻辑数据库”。
|
|
|
|
（4）物理设计阶段。根据特定数据库管理系统所提供的多种存储结构和存取方法等依赖于具体计算机结构的各项物理设计措施，对具体的应用任务选定最合适的物理存储结构（包括文件类型、索引结构和数据的存放次序与位逻辑等）、存取方法和存取路径等。这一步设计的结果就是所谓“物理数据库”。
|
|
|
|
（5）测试阶段。是在数据系统投入使用之前，通过精心制定的测试计划和测试数据来测试系统的性能是否满足设计要求，发现问题。
|
|
|
|
（6）运行维护阶段。数据库应用系统经过测试、试运行后即可正式投入运行。运行维护是系统投入使用后，必须不断地对其进行评价、调整与修改，直至系统消亡。
|
|
|
|
在数据库设计的任一阶段，一旦发现不能满足用户数据需求时，均需返回到前面的适当阶段，进行必要的修正。经过如此的迭代求精过程，直到能满足用户需求为止。事实上，数据库设计中，对每一个阶段设计成果都应该通过评审。评审的目的是确认某一阶段的任务是否全部完成，从而避免出现重大的错误或疏漏，保证设计质量。
|
|
|
