从1.1.1节的介绍可以看到,在数据库管理系统出现之前,人们对数据的操作是直接针对数据文件编写应用程序实现的,这种模式会产生很多问题。对于1.1.1小节中列举的学生基本信息管理和学生选课管理两个子系统,如果使用数据库技术来管理,其实现方式如图1-4所示。保证数据的安全是通过数据库管理系统的安全控制机制实现的,保证数据的可靠是通过数据库管理系统的备份和恢复机制实现的。......
2023-11-24
理解今日数据库特征的最好办法是了解在数据库技术产生之前,人们是如何通过文件的方式对数据进行管理的。
20世纪50年代后期到60年代中期,计算机的硬件方面已经有了磁盘等直接存取的存储设备;在软件方面,操作系统中已经有了专门的数据管理软件,一般称为文件管理系统。文件管理系统把数据组织成相互独立的数据文件,利用“按文件名访问,按记录进行存取”的管理技术,可以对文件中的数据进行修改、插入和删除等操作。
在出现程序设计语言之后,开发人员不但可以创建自己的文件并将数据保存在自己定义的文件中,而且还可以编写应用程序来处理文件中的数据,即编写应用程序来定义文件的结构,实现对文件内容的插入、删除、修改和查询操作,当然,真正实现磁盘文件的物理存取操作的还是操作系统中的文件管理系统,应用程序只是告诉文件管理系统对哪个文件的哪些数据进行哪些操作。由开发人员定义存储数据的文件及文件结构,借助文件管理系统的功能编写访问这些文件的应用程序,以实现对用户数据的处理方式称为文件管理,在本章后面的讨论中将忽略文件管理系统,假定应用程序是直接对磁盘文件进行操作的。
如果用文件管理数据,用户必须编写应用程序来管理存储在文件中的数据,其操作模式如图1-1所示。
图1—1 文件管理的操作模式
假设某学校要用文件的方式保存学生及其选课的数据,并在这些数据文件基础之上构建对学生进行管理的系统。此系统主要须实现两部分功能:学生基本信息管理和学生选课情况管理。假设教务部门管理学生选课情况,各系部管理学生基本信息。学生基本信息管理中涉及学生的基本信息数据,假设这些数据保存在F1文件中;学生选课情况管理涉及学生的部分基本信息、课程基本信息和学生选课信息,设文件F2和F3分别保存课程基本信息和学生选课信息的数据。
设A1为实现“学生基本信息管理”功能的应用程序,A2为实现“学生选课管理”功能的应用程序。由于学生选课管理中要用到F1文件中的一些数据,为减少冗余,它将使用“学生基本信息管理”(即F1文件)中的数据,如图1-2所示(图中省略了操作系统部分)。
图1—2 文件管理实现示例
假设文件F1、F2和F3分别包含如下信息。
F1文件——学号、姓名、性别、出生日期、联系电话、所在系、专业、班号。
F2文件——课程号、课程名、授课学期、学分、课程性质。
F3文件——学号、姓名、所在系、专业、课程号、课程名、修课类型、修课时间、考试成绩。
我们将文件中所包含的每一个子项称为文件结构中的“字段”或“列”,将每一行数据称为一个“记录”。
“学生选课管理”的处理过程大致为:在学生选课管理中,若有学生选课,则先查F1文件,判断有无此学生;若有则再访问F2文件,判断其所选的课程是否存在;若一切符合规则,就将学生选课信息写到F3文件中。(www.chuimin.cn)
这样看似很好,但仔细分析一下,就会发现用文件方式管理数据有如下缺点。
(1)编写应用程序不方便。应用程序编写者必须清楚地了解所用文件的逻辑及物理结构,如文件中包含多少个字段,每个字段的数据类型,采用何种逻辑结构和物理存储结构。操作系统只提供了打开、关闭、读、写等几个底层的文件操作命令,而对文件的查询、修改等处理都必须在应用程序中编程实现。这样就容易造成各应用程序在功能上的重复,比如图1-2所示的“学生基本信息管理”和“学生选课管理”都要对F1文件进行操作,而共享这两个功能相同的操作却很难。
(2)数据冗余不可避免。由于A2应用程序需要在学生选课信息文件(F3文件)中包含学生的一些基本信息,比如学号、姓名、所在系、专业等,而这些信息同样包含在学生信息文件(F1文件)中,因此F3文件和F1文件中存在重复数据,从而造成数据的重复,称为数据冗余。
数据冗余所带来的问题不仅仅是存储空间的浪费(其实,随着计算机硬件技术的飞速发展,存储容量不断扩大,空间问题已经不是我们关注的主要问题),更为严重的是造成了数据的不一致。例如,某个学生所学的专业发生了变化,我们一般只会想到在F1文件中进行修改,而往往忘记了在F3文件中应做同样的修改。由此就造成了同一名学生在F1文件和F3文件中的“专业”不一样,也就是数据不一致。人们不能判定哪个数据是正确的,尤其是当系统中存在多处数据冗余时,更是如此。这样数据就失去了其可信性。
文件本身并不具备维护数据一致性的功能,这种功能完全要由用户(应用程序开发者)负责维护。这在简单的系统中还可以勉强应付,但在复杂的系统中,若让应用程序开发者来保证数据的一致性,几乎是不可能的。
(3)应用程序依赖性。就文件管理而言,应用程序对数据的操作依赖于存储数据的文件的结构。文件和记录的结构通常是应用程序代码的一部分,如C程序的struct。文件结构的每一次修改,比如添加字段、删除字段,甚至修改字段的长度(如电话号码从7位扩到8位),都将导致应用程序的修改,因为在打开文件进行数据读取时,必须将文件记录中不同字段的值对应到应用程序的变量中。随着应用环境和需求的变化,修改文件的结构不可避免,这些都需要在应用程序中做相应的修改,而(频繁)修改应用程序是很麻烦的。人们首先要熟悉原有程序,修改后还需要对程序进行测试、安装等;甚至修改了文件的存储位置或者文件名,也需要对应用程序进行修改,这显然给程序维护人员带来很多麻烦。
所有这些都是由于应用程序对文件结构以及文件物理特性的过分依赖造成的,换句话说,用文件管理数据时,其数据独立性很差。
(4)不支持对文件的并发访问。在现代计算机系统中,为了有效利用计算机资源,一般都允许同时运行多个应用程序(尤其是在现在的多任务操作系统环境中)。文件最初是作为程序的附属数据出现的,它一般不支持多个应用程序同时对同一个文件进行访问。回忆一下,某个用户打开了一个Excel文件,当第二个用户在第一个用户未关闭此文件前打开此文件时,会得到什么信息呢?他只能以只读方式打开此文件,而不能在第一个用户打开的同时对此文件进行修改。再回忆一下,如果用某种程序设计语言编写一个对某文件中内容进行修改的程序,其过程是先以写的方式打开文件,然后修改其内容,最后再关闭文件。在关闭文件之前,不管是在其他的程序中,还是在同一个程序中都不允许再次打开此文件,这就是文件管理方式不支持并发访问的含义。
对于以数据为中心的系统来说,必须要支持多个用户对数据的并发访问,否则就不会有我们现在这么多的火车或飞机的订票点,也不会有这么多的银行营业网点。
(5)数据间联系弱。当用文件管理数据时,文件与文件之间是彼此独立、毫不相干的,文件之间的联系必须通过程序来实现。比如,对上述的F1文件和F3文件,F3文件中的学号、姓名等学生的基本信息必须是F1文件中已经存在的(即选课的学生必须是已经存在的学生);同样,F3文件中课程号等与课程有关的基本信息也必须存在于F2文件中(即学生选的课程也必须是已经存在的课程)。这些数据之间的联系是实际应用当中所要求的很自然的联系,但文件本身不具备自动实现这些联系的功能,我们必须编写应用程序,即手工地建立这些联系。这不但增加了编写代码的工作量和复杂度,而且当联系很复杂时,也难以保证其正确性。因此,用文件管理数据时很难反映现实世界事物间客观存在的联系。
(6)难以满足不同用户对数据的需求。不同的用户(数据使用者)关注的数据往往不同。例如,对于学生基本信息,对负责分配学生宿舍的部门可能只关心学生的学号、姓名、性别和班号,而对教务部门可能关心的是学号、姓名、所在系、专业和班号。
若多个不同用户希望看到的是学生的不同基本信息,就需要为每个用户建立一个文件,这势必造成大量的数据冗余。我们希望的是,用户关心哪些信息就为他生成哪些信息,对用户不关心的数据将其屏蔽,使用户感觉不到其他信息的存在。
可能还会有一些用户,其所需要的信息来自于多个不同的文件,例如,假设各班班主任关心的是班号、学号、姓名、课程名、学分、考试成绩等。这些信息涉及了三个文件:从F1文件中得到“班号”,从F2文件中得到“学分”,从F3文件中得到“考试成绩”;而“学号”“姓名”可以从F1文件或F3文件中得到,“课程名”可以从F2文件或F3文件中得到。在生成结果数据时,必须对从三个文件中读取的数据进行比较,然后组合成一行有意义的数据。比如,将从F1文件中读取的学号与从F3文件中读取的学号进行比较,学号相同时,才可以将F1文件中的“班号”与F3文件中的当前记录所对应的学号和姓名组合起来,之后,还需要将组合结果与F2文件中的内容进行比较,找出课程号相同的课程的学分,再与已有的结果组合起来。然后再从组合后的数据中提取出用户需要的信息。如果数据量很大,涉及的文件比较多时,我们可以想象这个过程有多复杂。因此,这种大容量复杂信息的查询在按文件管理数据的方式中是很难处理的。
(7)无安全控制功能。在文件管理方式中,很难控制某个人对文件容许的操作,比如只允许某个人查询和修改数据,但不能删除数据,或者对文件中的某个或者某些字段不能修改等。而在实际应用中,数据的安全性是非常重要且不可忽视的。比如,在学生选课管理中,我们不允许学生修改其考试成绩。在银行系统中,更是不允许一般用户修改其存款数额。针对文件管理方式的这些缺陷,人们逐步开发出了以统一管理和共享数据为主要特征的数据库管理系统。
有关数据库技术与应用教程的文章
从1.1.1节的介绍可以看到,在数据库管理系统出现之前,人们对数据的操作是直接针对数据文件编写应用程序实现的,这种模式会产生很多问题。对于1.1.1小节中列举的学生基本信息管理和学生选课管理两个子系统,如果使用数据库技术来管理,其实现方式如图1-4所示。保证数据的安全是通过数据库管理系统的安全控制机制实现的,保证数据的可靠是通过数据库管理系统的备份和恢复机制实现的。......
2023-11-24
如果要使用缺省参数创建一个学籍管理数据库StuData,可以使用如下命令:Create Database StuData如果希望为数据库或事务日志指定一个或者多个特定文件,增加一个On Primary子句,列出一个或者多个文件,并可为分配这个文件的空间指定一个可选值,其命令形式如下:Create Database StuDataOn Primary,;如果为了提高性能和可恢复性,则可以使用Log On子句来指定数据库的SQL Server事务日志将存储在一个与数据库对象不同的设备上,示例如下:Create Database StuDataOn Primary,Log On;GO......
2023-11-24
关键字Modify File用以表示按后面的文件说明,在指定的数据库中修改相应数据库文件。下面的语句可在学籍管理数据库增加一个新数据库文件,同时要修改原数据库文件StuFile l的最大文件尺寸为2000 MB。Alter Database StuDataAdd FileModify File又如,如果要删除学籍管理数据库文件StuFile2,则可使用如下命令:Alter Database StuDataRemove File StuFile2......
2023-11-24
SQL的数据查询语句中包括SELECT,FROM,WHERE,GROUP BY和ORDER BY子句。SELECT语句具有数据查询、统计、分组和排序的功能,其语句表达能力非常强大。查询操作需要的数据源指基本表组,表间用“,”分割。当SELECT子句后的目标列中有统计函数,如果查询语句中有分组子句,则统计为分组统计,否则为对整个结果集统计。交查询操作,操作结果为取<查询1>和<查询2>共有的元组。......
2023-11-24
由于信息结构复杂,应用环境多样,在相当长的一段时期内数据库设计主要采用手工试凑法。人们经过探索提出了各种数据库设计方法,这些方法运用软件工程的思想和方法,提出了各种设计准则和规程,都属于规范设计法。工具在很大程度上依靠开发人员的经验来保证数据库模型能生成可行的设计方案和高性能的数据库。大多数的数据库设计方法都需要经历这三个步骤。根据所选择的设计方法按部就班地进行并最终获得一个实用的应用系统。......
2023-11-24
下面介绍的优化策略能提高查询的效率,但它们不一定是最优的策略,实际上“优化”一词并不是很确切,用“改进”或“改善”或许更恰当些。即使这样,使用预处理方法执行连接的时间一般仍大大减少。当查询视图时,定义视图的表达式就是公共子表达式的情况。......
2023-11-24
近年来发展起来的数据挖掘技术及其产品已经成为数据仓库开采的有效工具。数据挖掘技术涉及数据库技术、人工智能技术、机器学习、统计分析等多种技术,它使决策支持系统跨入了一个新的阶段。传统的DSS系统通常是在某个假设的前提下,通过数据查询和分析来验证或否定这个假设。有关数据挖掘技术的研究已经从理论走向了产品开发,其发展速度是十分惊人的。能够使用数据挖掘工具已经成为能否在市场竞争中获胜的关键所在。......
2023-11-24
相关推荐