精华内容
下载资源
问答
  • 分布式数据库在光大银行关键业务系统的应用探索
    千次阅读
    2020-07-06 14:19:59

    作者介绍:王志刚,光大银行数据库运维主管。

    大家好,我是来自中国光大银行信息科技部的王志刚,非常高兴有机会给大家分享一些分布式数据库在光大银行的应用探索。我目前在光大银行银行信息科技部负责数据库管理团队,在加入光大银行之前在三星、索尼爱立信,还有 Oracle 工作过,一直在负责数据库相关的工作。在近十年我和我的团队一直负责光大银行总行的数据库运维,这里面既包括我们的交易型数据库,也包括 MPP,还有 Hadoop 这样的大数据运维。在运维的过程中,我们一直也在思考现在的数据库有哪些问题、面临哪些风险、数据库技术的发展趋势是什么,这一点是很重要的,因为它决定了我们为什么要转向分布式,我们希望分布式能替我们解决哪些问题,它能够解决哪些问题和它不能够解决哪些问题。

    我们现在运维的数据库包括商业数据库,像 Oracle、SQL Server、DB2;也有开源数据库,像关系型的 MySQL、NoSQL 数据库、Redis(KV 型),还有大数据、MPP,和分布式数据库等等。

    目前运维的数据库面临哪些挑战?

    以我们的观点去看现在银行数据库面临哪些挑战呢?我们认为有下面几点。

    1. 处理能力受限

    很多人都认为我们现在处理能力受限,但是数据库能力受限到底瓶颈在哪里?在我们看来在高的业务压力下瓶颈主要有两点:

    一是集中式存储资源的压力。我们可以用最高端的存储,用最好的设备,但他终究是一个单点,他的性能受整体的限制;

    二是热点资源。其实我们做数据库的时候更会发现相较于硬件的限制,软件的限制可能更大,像我们经常遇到的锁冲突的问题可能还是比较表层的问题,其实更多的是在数据库软件给你提供 ACID 和各种 SQL 接口的时候,他本身不是没有代价的,而是有成本的,这些成本本身会造成热点的内存、热点的序列、热点的内部闩锁等冲突,这些冲突在高压力下会对我们的性能造成极大的影响。

    2. 部署集中会导致风险的集中

    我们可以用最高端的设备,可以用最好的软件集群,我们可以将故障率降低到非常非常的低,也可以让切换时间变得非常短,变成秒级,让他可以在几秒的时间切换完,但是他仍旧避免不了一点,就是在我们的数据库是集中式的时候,一旦出现问题,在这几秒之内我们所有的交易都会停止。这其实是我们想提升的一个方面,我们希望有一个能够 24 小时不间断运行的数据库。

    3. 跨数据库中心多活部署

    银行是两地三中心的结构,它的投入很大,我们希望每个中心都利用起来,能够利用我们运维中数据中心的资源尽量的对外提供业务服务,这也是我们希望能够通过分布式的方案去解决的。因为在传统的架构下,我们只能用最高端的设备,比如双活的存储、双活的软件,但这在更多的情况下提供的是更高的可用性,并不能保证我们在所有的数据中心同时对外服务。

    4. 数据库产品多样化

    面对内外部多变形势,抵御产品供应链风险,我认为供应链的问题一直存在,在这我们必须要感谢大洋彼岸的大统领,因为他让我们知道这个问题现在有多么的紧迫,因为我们是 China,我们可能要跟大统领说一下“感谢,让我们意识到这个问题”。它决定了我们为什么要转向分布式数据库,我们希望分布式数据库或者说分布式架构替我们解决什么样的问题,因为这是一个比较复杂的应用场景,当我们在整个应用场景遇到一些问题的时候,当我们面临一些抉择的时候,甚至是遇到一些困难的时候,它可以让我们回到问题的本原,回到我们的初心,让我们想想我们当时要解决什么问题,我们要选择什么样的技术去解决这个问题。

    银行需要什么样的数据库?

    我们总结了一下银行到底需要什么样的数据库。

    首先数据库是科技重器。

    大家回想一下银行的本原,银行是经营什么的?有人说银行是经营钱的,我觉得不准确,印钞厂是经营钱的,银行的使命其实是财富的流转。以前的票号说汇通天下,意思是让财富在空间之间流转,现在大家贷款买房,银行给你贷款,过几十年你把他还清,在几十年之后你去住这个房子,这是银行让财富在时间上流转,其实银行的使命是让财富在时空之中流转,在流转的过程中为什么你相信银行能承担这个使命呢?是因为银行有一个经营的核心,这个核心是信用,只有有信用的银行你才愿意把钱存给它,这个信用不仅仅是你的钱要一分不差的给你,同时还要准时的给你。如果你取存款的时候银行跟你说:“你一个月之后再来吧,对不起现在没有钱。”你还会存给他吗?不会。银行经营的核心决定了我们后台支撑银行的整个系统,不仅仅是数据库,都要有准确极致的要求,既要时间准确,又要数字准确。

    第二是银行业务发展本身的需要。

    互联网金融某信、某宝的发展倒逼银行信息系统不断提升,既要提升交易的性能,也要提升我们批处理的性能,因为银行整个金融系统是互相连接的,你要这样做,别人也要这样做,我们要连成一个整体的金融网。

    第三是监管的要求。

    这一点可能是银行发展和互联网金融发展比较大的一个区别,在这里我跟大家分享一下,在过去两年双十一大促的时候,光大银行一直在双十一网联的统计中成功率排名第一,其实准确的说网联考核的不仅是成功率,成功率是 99.9%,可以说很好,但是不够,网联还要考核成功的绝对数量。去年双十一大促的时候,光大银行在全国银行中排名第一,是因为光大银行在整个双十一促销过程中只有三笔交易超时,所以整个系统对我们的要求是相当苛刻的。我们在整个环境中,不仅在量大之后只能有很低的失败比例,而且几乎要求你每笔交易都不能错。另外监管要求,如果有几笔交易错了一定要找出原因,他对我们的运维管理和对我们的问题分析有极高的要求,这可能是在实际应用场景中和现有的互联网金融的一个区别。

    第四是银行也同样面临成本压力。

    经常有人跟我们说银行很好,有钱,你买买买就可以了,银行是有钱,但是没有一分钱是可以随便花的,所以买买买只存在于段子中,现实是每一分钱都要精打细算,我们希望把钱投入到一个真正有收益的地方,银行需要的就是这样的数据库,这样的科技产品。

    关于分布式数据库,我们的思考

    基于上面这些思考,我们转向分布式数据库,我们希望分布式数据库能解决我们的难题,同时符合银行对数据库的要求。关于分布式数据库我们的思考大概有以下几种说法,有的我们同意,有的我们不太同意,在这里我跟大家分享一下。

    第一点是说中国的分布式数据库技术是世界第一梯队,这点我们认同。

    因为中国的分布式数据库技术得益于中国有世界上最大的互联网应用,就像你要做一个好的厨子,一定要有好的食客一样,我们有了好的食客,我们就有了成为好厨子的潜质。

    第二点是当前(2020 年)分布式数据库产品已经成熟了吗?

    经过我们的调研对比测试,我们觉得这个答案是 No。分布式数据库产品的完全成熟,当然也不排除后面会出现技术爆炸、飞跃,我们认为还需要五年以上的时间。大家可以回想一下这个路程,我们举一个国外产品的例子,现在国外最大的一个数据库厂商 70 年代末成立,进入中国是 80 年代末,真正在中国铺开是 90 年代末,经历了 20 年的时间。我们现在虽然有了各种技术的飞跃,但是有些时间跨度还是不可避免的,所以对于第二个问题的答案我们认为是 No。紧接着是第三个问题,我们要继续等待五年之后吗?对不起,我们的答案也是 No,其实不光是数据库,对所有产品的成熟,我们认为有三种因素:

    • 第一产品自身;
    • 第二是应用开发的成熟,产品自身好还是不好是他自身的能力,但你需要知道怎么用他;
    • 第三是运维管理,就是你会不会管理他,会不会维护他。

    就像一辆车一样,把车做的很好这是产品自身的问题,那我们会不会开,你会开了之后有没有人会修。当所有这三个条件都成熟的时候,一个产品和他的环境才成熟,我们没法等待一个产品,先把车造好了,我们再去学怎么开,然后我们再去学怎么修,这三个条件一定是同步的。

    所以正是基于这个判断,光大银行在做分布式数据库这个项目的时候定了一个原则,叫躬身入局,我们要参与其中,通过我们的应用开发、测试、运维、实践与产品、技术和生态共同成长。生态也很重要,大家想想原来的厂商在中国的推广是仅靠厂商本身吗?我觉得不仅仅是,我们要感谢像 ITPUB 这样的互联网社区, 是这些社区让我们一起成熟起来,包括在同业之间的分享和促进。

    光大银行分布式数据库实践

    我们比较早认知到分布式数据库和整个分布式架构转型对银行科技工作的重要作用。从光大银行信息科技部整个部门来说,把分布式数据库的建设工作列为了部门的年度重点工作之一,从 2018 年就开始研究,到 2019 年我们连续同业调研、技术测试、选型论证以及试点的上线,今年我们的计划是进一步推广使用的范围。因为我是分布式数据库建设的项目经理,我们以前也经常引入一些新产品,那这个项目和以前我们做的其他项目有什么不同呢?还是回到问题的本原,回到我们的初心,我们一开始要拿分布式数据库解决什么问题。我们希望它解决的是三个问题:

    • 第一是性能的问题;
    • 第二是可用性的问题;
    • 第三是多活的问题。

    银行有很多系统,小的有几百个,大的有几千个,这些系统中有大量的边缘系统,在以前这些边缘系统可以给我们新技术的测试提供很好的场景,但是在分布式数据库这个项目中,这个场景不太适用,因为我们对边缘系统的可用性的容忍度很高,一个边缘系统没有我们之前说的那几个问题,他没法验证我们的处理能力、稳定性、可用性,没法帮助我们去锻造开发测试和运维团队的技术能力。而且我们知道分布式数据库是比较复杂的,在这种系统中引入分布式数据库的时候,相对来说投入的设备量也比较大,并且他没有真正解决技术问题,也没有真正创造技术价值,所以正是基于这些考虑,我们首先要把分布式数据库应用到真正需要的系统。所以有人跟我开玩笑说,我们以前做项目都是 Normal 模式,但这个项目一上来就是 Hard 模式

    光大银行有两个受客面最大的系统,也就是对客的系统,一个是理财,一个是缴费,恰恰是这两个系统,我们把他拿来做分布式数据库的引入的试点,可以说是“到中流击水”,我们就要做到“第一战即攻坚战”。

    1. 新一代财富管理平台

    光大银行是一个有理财基因的银行,2004 年光大银行在国内发行了第一款人民币理财产品,所以 2004 年也被称为中国的理财元年,2018 年光大集团的董事长李晓鹏提出了打造一流财富管理银行的愿景, 2019 年光大银行成为了首批获批成立理财子公司的股份制商业银行,到了同年的 9 月,光大银行理财公司正式开业,成为了首家开业的股份制商业银行的理财公司。

    新一代财富管理平台是支撑我们整个光大银行理财公司运营的核心系统,首先它要符合我们的资管新规和理财新规,是新一代的理财业务的全流程管理平台,里面既包括销售注册登记,还要包括理财产品的研发设计、生命管理以及理财相关实时业务管理,可以说是被银行上下寄予厚望的一套系统。

    在这里安利一下光大的理财,光大理财的品牌叫做七彩阳光理财,大家看到这个图里七彩阳光是七种不同的理财风格,既有权益理财,也有混合型理财,我们把 TiDB 用到了现金理财,就是绿色的这一部分,叫阳光碧现金理财,在这里我们是在受众最广的渠道中去应用我们真正需要它的技术。

    并不是说有了分布式数据库,整个就万事大吉,一键我们分布式了,其实整个过程还是很复杂的,我们设计了全面的分布式架构来确保我们的新一代理财系统能够支撑光大银行理财子公司的财富管理的业务,依托光大银行私有云基础设施,基于我行自主研发平台 4.0 开发框架,并且定制了分布式批处理的方案。我们的设计目标是余额宝每小时理财交易 2000 万,零钱通单日 5000 万,同时还要满足未来三到五年的业务发展和接入更多互联网的渠道,其实他是一个面向未来的系统,这个系统去年 11 月上线运行,今年 4 月正式对外开放。

    具体到了 TiDB,我们这次实施的是 TiDB 3.0.5 产品,我们在北京有两个中心,同城跨中心部署,15 节点,5 副本的 TiKV,设计的是 40TB 的逻辑容量,每个节点是专门为这个项目采购的机架式服务器,有两个 4TB 的 SSD,24 核,512G 的内存。因为这是个重要产品,应该说“切入即决战”,所以为了保障新一代数据库的平稳运行,我们可以开最好的车,但是一定要系好安全带,这个安全带就是我们在实施的过程中,除了 TiDB 本身,我们还把 TiDB 的数据实时复制到了 MySQL,用一个异构的数据库来保证一旦出现极端情况,能有一个逃生环境,去挽救我们的数据,挽救我们整个的应用。大家都知道 TiDB 之前版本有个乐观锁特性(TiDB 4.0 版本 正式推出了悲观锁功能,和 RC 隔离级别,使用 TiDB 4.0 让应用适配更容易),这个是怎么适配的呢?后面 TiDB 有他自己的一个方案,但是我们这个版本还没有这个特性,我们在整个过程中做了大量的适配的,在出现业务冲突的时候,应用程序和业务代码能捕获异常、重试机制,我们和 TiDB 的专家也做了很多合作,我们的开发人员也做了很多修改,为什么这么做呢?还是回到初心,我们希望用一个产品解决这个问题,但我们不完全依赖某个产品解决我们的问题,我们根据他的特色选定了他,然后我们要适配他,这个事就像爱情一样,你爱他就要爱他的全部。

    2. 云缴费

    再安利一下我们另外一个项目,就是光大银行的云缴费。我们有一个口号叫“云缴费缴出新生活”,这是光大银行近年来着力打造的一个名品业务,它也是我们光大银行在金融惠民宗旨下,通过银行的资源、银行的科技能力不断的去方便大家,通过整合水、电、燃气等等项目,我们向第三方开放这些缴费资源,把各个服务提供商整合在一起,向我们其他的银行同业,行内、行外、某信、某宝这些第三方支付公司提供输出。大家用某信、某宝去缴费的时候可没有注意过,后面真正的缴费系统其实是光大银行的云缴费。另外说一句云缴费其实是光大银行目前 TPS 最高的系统,在这个系统中我们用的是由光大银行、光大科技和万里开源合作打造的一款分布式数据库中间件叫 EverDB,是我们自有知识产权的一个产品。

    光大银行数据库技术领域发展规划

    我们回到初心,再分享一下光大银行在数据库技术发展上的规划。我们虽然这次讲分布式,但分布式并不是光大银行在数据库领域的所有,尤其银行的系统特点是系统多,我们相信未来分布式数据库和集中数据库一定会各司其职。并不是每个系统都会用分布式数据库,分布式数据库适配的是那些大并发、高频次的业务系统,集中式数据库仍然有它的生存空间,而且从数量来说,它没准还是占相对大的一个比例,它适配的是传统业务系统,我们通过 RDS 的服务化部署能够提供数据库服务,国外商业产品、国内数据库、开源产品结合使用,最后达到一个比较均衡的比例。在分布式数据库领域我们会做到产品引入和自主研发结合,通过这种开放共赢的方法,打造有光大银行特色分布式的技术方案。最后在应用推广方面,今年我们还会在互联网渠道、支付等系统中应用分布式数据库产品,同时我们会启动新一代分布式核心建设。所有这些规划,我们都非常欢迎像 PingCAP 这样有实力的公司和我们共同发展、共同创造,当然更希望数据库领域的专家还有才俊能够加入我们,让我们共同创造科技、创造财富。

    本文整理自王志刚在 TiDB DevCon 2020 上的演讲。

    更多相关内容
  • 信用卡Web管理系统的设计与实现(论文 、数据库、程序、视频).zip 如有调试问题或者需要协助指导的,请站内私信我
  • 质量信用档案数据库系统—用户操作使用方法.pptx
  • 个人信用信息基础数据库系统数据接口规范标准.doc
  • 前言 企业信用信息基础数据库数据接口规范简称数据接口规范规定了企业信用信息基础数据 库与外部系统进行信息交换时应遵循的有关信息格式和数据管理规定本文档分为六部分 前言简介本规范各部分的内容 报文规范规定了...
  • 随着从通信设备到航空装备和工业控制器等技术中对数据管理需求的不断增长,以及受到这些设备中不断增加的板...设计师经常采用的内存数据库系统(IMDS)是在主存中存储记录,因此可以消除许多延时源,比如通过硬连线接进
  • 随着从通信设备到航空装备和工业控制器等技术中对数据管理需求的不断增长,以及受到这些设备中不断增加的板...设计师经常采用的内存数据库系统(IMDS)是在主存中存储记录,因此可以消除许多延时源,比如通过硬连线接进
  • 项目架构:B/S架构 开发语言:Java语言 开发软件:idea eclipse 前端技术:Layui、HTML、CSS、JS、JQuery等技术 后端技术:JAVA 运行环境:Win10、JDK1.8 数 据 库:MySQL5.7/8.0 运行服务器:Tomcat7.0 CSDN太坑了...
  • 1、客户管理,功能包括新的贷款客户信息,客户信息,查询修改贷款客户信息,信用评级和信用客户所有权等; 2、业务管理,功能包括贷款,贷款审批,贷款,贷款回收逾期贷款,贷款,逾期贷款,等等; 3、利息管理,...
  • 精品教育教学资料
  • 信用卡管理系统+数据库 有简单的信息查询,支出,寸入功能
  • 通过面向对象程序设计法对系统需求进行分析,设计包括业务管理、统计汇总、用户管理等不同功能,同时借助MySql数据库和Delphi技术对系统进行开发,实现了对工程监理企业和建立人员的信用监督,并可查看建立行业的黑...
  • #资源达人分享计划#
  • 对图书类别、读者类型、罚金进行增删改查的操作,图书信息管理功能是对图书信息的增删改查,读者信息管理功能对读者信息的增删改查,图书借阅管理功能包括图书的借阅,图书的归还以及图书借阅记录的查询。...

    一、项目分析

    1、项目功能分析

    项目功能模块主要分为三个模块,登录模块、管理员模块、操作员模块。

    登录模块包括登录功能,注册功能,登录日志功能,修改密码以及找回密码。

    管理员模块包括工作日志功能、图书借阅金额设定、操作员管理功能、图书借阅逾期账单。

    操作员模块包括基础信息维护功能,对图书类别、读者类型、罚金进行增删改查的操作,图书信息管理功能是对图书信息的增删改查,读者信息管理功能对读者信息的增删改查,图书借阅管理功能包括图书的借阅,图书的归还以及图书借阅记录的查询。以上就是整个项目的主体功能结构,理清楚需求与结构后,便着手了项目的说明文档。

    2、说明文档

    说明文档主要从概要设计说明、软件需求说明、接口设计说明、数据库设计说明四个方便对项目的结构,需求,具体的接口,数据库进行全面的规划设计,保证了代码编写的依据性以及合理性。

    概要设计说明对项目编写的背景、需求分析、程序运行的流程、功能结构、接口设计、数据库设计以及程序运行出错后的处理方案进行了总体的描述与规划。

    软件需求说明是对整个程序进行了具体的需求分析,包括了项目整体的结构图,流程图,ER设计图,为项目的进行和程序的编写提供了方向。

    接口设计说明是程序对数据库访问的具体方法的接口设计,接口设计清楚了就能更快速的进行对数据的处理与使用。

    数据库设计说明主要是对数据库进行具体的数据表设计,根据软件的具体需求来设计相应的数据表,存放软件产生的数据。

     二、项目实现

     项目编写严格按照了三层架构的标准来设计同时具体体现了简单工厂的设计模式。从Dao类的设计到实体层再到业务逻辑成最后到页面设计,整体的结构清晰明了。然后展示一些代码吧,满满的成就感!

    图书借阅Dao:

    public interface BookBorrowAndReturnDao {
        //查询所有借阅记录
        List<BookBorrowAndReturn> selectAllBorrow(Connection conn);
    
        //添加一条借阅记录
        void addborrow(Connection conn, BookBorrowAndReturn bbr);
    
        //修改借阅记录
        int updateBorrow(Connection conn, int readerId, int ISBN, Date returnDate, BookBorrowAndReturn bbr);
    
        //根据readerId查询需要归还的图书记录
        List<BookBorrowAndReturn> selectBorrowByReaderId(Connection conn, int readerId);
    
        //根据isbn和readerId以及状态查询需要归还的图书记录
        BookBorrowAndReturn selectBorrowByIsbn(Connection conn, int readerId, int isbn, String state);
    
        //根据状态和图书编号查询
        List<BookBorrowAndReturn> selectBorrowByIsbn(Connection connection, int isbn, String state);
    
        //根据读者ID和状态查询
        List<BookBorrowAndReturn> selectBorrowByState(Connection connection, int readerId, String state);
    }
    

    图书借阅的Impl:

    public class BookBorrowAndReturnImpl extends BaseDao<BookBorrowAndReturn> implements BookBorrowAndReturnDao {
        //查询所有借阅信息
        @Override
        public List<BookBorrowAndReturn> selectAllBorrow(Connection conn) {
            String sql = "select readerId,readerName,bookISBN as ISBN,bookName, borrowDate,returnDate,fine,state from bookborrowandreturn";
            List<BookBorrowAndReturn> beanList = getBeanList(conn, sql);
            return beanList;
        }
    
        //借书记录
        @Override
        public void addborrow(Connection conn, BookBorrowAndReturn bbr) {
            String sql = "insert into bookborrowandreturn(readerId,readerName,bookISBN,bookName,borrowDate,state) values(?,?,?,?,?,?)";
            update(conn, sql, bbr.getReaderId(),bbr.getReaderName(), bbr.getISBN(),bbr.getBookName(), bbr.getBorrowDate(), bbr.getState());
        }
        
        @Override
        public int updateBorrow(Connection conn, int readerId, int ISBN, Date returnDate, BookBorrowAndReturn bbr) {
            String sql = "update bookborrowandreturn set readerId = ?,readerName = ?,bookISBN = ?, bookName = ?,borrowDate = ? ,returnDate = ?, fine = ? ,state = ? where readerId = ? and bookISBN = ? and returnDate is ?";
            int update = update(conn, sql, bbr.getReaderId(), bbr.getReaderName(),bbr.getISBN(),bbr.getBookName(), bbr.getBorrowDate(), bbr.getReturnDate(), bbr.getFine(), bbr.getState(), readerId, ISBN,returnDate);
            return update;
        }
    
        @Override
        public List<BookBorrowAndReturn> selectBorrowByReaderId(Connection conn, int readerId) {
           String sql = "select readerId,readerName,bookISBN as ISBN,bookName, borrowDate,returnDate,fine,state from bookborrowandreturn where readerId = ?";
            List<BookBorrowAndReturn> beanList = getBeanList(conn, sql, readerId);
            return beanList;
        }
    
        @Override
        public BookBorrowAndReturn selectBorrowByIsbn(Connection conn,int readerId, int isbn,String state) {
            String sql = "select readerId,readerName,bookISBN as ISBN,bookName, borrowDate,returnDate,fine,state from bookborrowandreturn where bookISbn = ? and state = ? and readerId = ?";
            BookBorrowAndReturn beanList = getBean(conn, sql, isbn,state,readerId);
            return beanList;
        }
    
        @Override
        public List<BookBorrowAndReturn> selectBorrowByIsbn(Connection connection, int isbn, String state) {
            String sql = "select readerId,readerName,bookISBN as ISBN,bookName, borrowDate,returnDate,fine,state from bookborrowandreturn where bookISbn = ? and state = ?";
            List<BookBorrowAndReturn> beanList = getBeanList(connection, sql, isbn,state);
            return beanList;
        }
    
        @Override
        public List<BookBorrowAndReturn> selectBorrowByState(Connection connection, int readerId, String state) {
            String sql = "select readerId,readerName,bookISBN as ISBN,bookName, borrowDate,returnDate,fine,state from bookborrowandreturn where readerId = ? and state = ?";
            List<BookBorrowAndReturn> beanList = getBeanList(connection, sql, readerId,state);
            return beanList;
        }
    }
    

    图书归还功能的部分代码展示:

     页面设计展示:

     程序运行图:

    三、项目心得

     利用数据库来实现实现数据的存储比使用文件来储存数据要方便多了也要更快捷了,同时效率也更高了。但是在用的时候出现了一些问题还有在业务逻辑层循环语句的使用上还是避免不了出现错误,多层循环的嵌套容易理不清楚,所以就出现的一些bug进行总结。

    1、JDBC使用时sql语句与数据库对应错误。

    主要是由于实体层设计时属性名没有与数据表的列名保持一致,从而在sql语句编写出现错误,导致异常,要使用别名来进行联系。

    如下图的bookISBN与实体类属性ISBN的不一致:

     public List<BookBorrowAndReturn> selectAllBorrow(Connection conn) {
            String sql = "select readerId,readerName,bookISBN as ISBN,bookName, borrowDate,returnDate,fine,state from bookborrowandreturn";
            List<BookBorrowAndReturn> beanList = getBeanList(conn, sql);
            return beanList;
        }

     2、多层循环嵌套

    在编写图书借阅与归还功能时需要添加许多的限制条件,就难免需要多层循环的嵌套,并且还需要对数据库查询出来的数据存储的集合进行遍历,许多的while循环,for循环,if语句嵌套在一起,当时就出现了循环的多余,以及引用的错误!在进行循环嵌套时首先就要搞清楚每一层循环的作用,并添加注释,那么在出现错误后也能一目了然。

    如:

     public void returnBook() {
            System.out.println("**********************");
            System.out.println("********图书归还********");
            System.out.println("**********************");
            //打印读者信息表
            System.out.println("读者信息表");
            new SetReader().selectAllReader();
    
            //获取连接
            Connection conn = null;
            try {
                conn = JDBCutils.getConnectionDruid();
                boolean flag = true;
                while (flag) {
                    System.out.println("请选择你要进行还书的读者的序号");
                    int Id = TSUtility.readInt();
                    List<Reader> readers = new ReaderDAOImp().selectAllReaders(conn);
                    if (Id > readers.size() || Id <= 0) {
                        System.out.println("选择错误,请重新选择!");
                    } else {
                        flag = false;
                        int readerId = readers.get(Id - 1).getReaderId();
    
                        //查询选择的序号对应的读者的所有未还记录
                        String state = "未还";
                        BookBorrowAndReturnOperation b = new BookBorrowAndReturnOperation();
                        List<BookBorrowAndReturn> books = b.selectBorrowByState(readerId, state);
    
                        Date borrowBookDate = null;
                        if (books.size() == 0) {
                            System.out.println("读者" + readers.get(Id - 1).getName() + "暂无未归还记录");
                        } else {
                            System.out.println("====图书未还记录====");
                            System.out.println("序号\t读者ID\t读者姓名\t图书ISBN\t图书名称\t借书日期\t还书日期\t罚金\t状态");
    
                            for (int i = 0; i < books.size(); i++) {
    
                                System.out.println((i + 1) + "\t" + books.get(i).getReaderId() + "\t" + books.get(i).getReaderName() + "\t" + books.get(i).getISBN()
                                        + "\t" + books.get(i).getBookName() + "\t" + books.get(i).getBorrowDate() + "\t" + books.get(i).getReturnDate() +
                                        "\t" + books.get(i).getFine() + "\t" + books.get(i).getState());
    
                                borrowBookDate = books.get(i).getBorrowDate();
                            }
                            TSUtility.readReturn();
    
                            //选择需要归还的图书(一次只能还一本)
                            boolean returnFlag = true;
                            while (returnFlag) {
                                System.out.println("请选择你要还的图书的序号");
                                int bId = TSUtility.readInt();
                                if (bId > books.size() || bId <= 0) {
                                    System.out.println("选择错误,请重新选择!");
                                } else {
    
                                    returnFlag = false;
                                    int bookId = 0;
                                    for (int j = 0; j < books.size(); j++) {
                                        bookId = books.get(bId - 1).getISBN();
                                    }
    
                                    //设置归还时间
                                    Scanner sc = new Scanner(System.in);
                                    Date returnDate = null;
                                    boolean flagD = true;
                                    int days = 0;
                                    while (flagD) {
                                        System.out.println("请输入归还日期(格式:yyyy-MM-dd):");
                                        String date = sc.next();
                                        boolean date1 = isDate(date);
                                        returnDate = getDateStr(date);
                                        if (!date1) {
                                            System.out.println("日期格式输入错误,请重新输入");
                                            TSUtility.readReturn();
                                        } else {
    
                                            //获取借书时间
                                            java.sql.Date borrowDate1 = books.get(bId - 1).getBorrowDate();
                                            //得到相隔天数
                                            int day = daysBetween(borrowDate1, returnDate);//相隔天数
                                            //与可借天数对比计算逾期时间
                                            double money = 0;
                                            Reader reader = new ReaderDAOImp().selectReaderById(conn, readerId);
    
                                            if (day >= 0) {
                                                days = day - reader.getLimit();
                                                flagD = false;
    
                                                //获取罚金标准根据逾期时间计算罚金
                                                String typeName = reader.getTypeName();
                                                List<Fine> fines = new FineDaoImpl().selectAllFine(conn);
                                                for (Fine fine : fines) {
                                                    if (typeName.equals(fine.getReaderTypeName())) {
                                                        //罚金金额
                                                        if (days <= 0) {
                                                            System.out.println("您未逾期,感谢您保持良好的信用习惯。");
                                                            money = 0;
                                                        } else {
                                                            money = days * fine.getFine();
                                                            System.out.println("你已逾期" + days + "天" + ",需缴纳" + money + "元罚金!");
                                                        }
                                                    }
                                                }
                                                String stated = "已还";
                                                Date returnDatejiaoyan = null;
                                                BookBorrowAndReturn bbr = books.get(bId - 1);
                                                bbr.setReturnDate(new java.sql.Date(returnDate.getTime()));
                                                bbr.setFine(money);
                                                bbr.setState(stated);
                                                bbr.setReaderId(readerId);
                                                new BookBorrowAndReturnOperation().updateBorrow2(readerId, bookId, (java.sql.Date) returnDatejiaoyan, bbr);
                                                System.out.println("归还成功!");
    
                                                //归还成功后需返还读者可借数量
                                                Reader reader1 = new ReaderDAOImp().selectReaderById(conn, readerId);
                                                int Num = (reader.getMaxBorrowNum() + 1);
                                                reader1.setMaxBorrowNum(Num);
                                                new ReaderDAOImp().updateReaderById(conn, readerId, reader1);
    
                                                //返还图书库存数
                                                Book book = new BookDaoImpl().selectByISBN(conn, bookId);
                                                int printTime = (book.getPrintTime() + 1);
                                                book.setPrintTime(printTime);
                                                new BookDaoImpl().updateBook(conn, book, bookId);
                                            } else if (day < 0) {
                                                System.out.println("还书日期不能小于借书日期,请重新输入");
                                                TSUtility.readReturn();
                                            }
                                        }
                                    }
                                }
                            }
                        }
                    }
                }
    
            } catch (SQLException throwables) {
                throwables.printStackTrace();
            } finally {
                JDBCutils.closeResoureSelect(conn, null, null);
            }
        }
    

    最后得到最深的感触是,做项目时一定先把说明文档清清楚楚的做好了,在进行程序的编写,只要有方向的去做,时间会节约,效率会提高,bug一直会存在,但这是最宝贵的经验。未来的日子加油!不负韶华!

    展开全文
  • 一个公司希望为其客户订购行为建立一个数据库。一个消费者可以有一个或多个订单,每个订单可以有一种或多种商品。每个订单有一个发票,可以通过多种方式来支付,例如支票、信用卡或者现金。开始运行这个客户订购登记...
  • 我们发现数据集之间存在系统差异,这暗示着不同数据库中价格之间的共同趋势偏差并非纯粹是随机的,而是由特质因素以及金融机构的融资成本,全球风险和其他交易因素。 可用的交易价格越低,数据库之间的偏差就越大。 ...
  • PAGE PAGE 1 [模拟] 数据库系统工程师下午14 填空题 试题一 阅读以下说明和数据流图根据要求回答下列问题 [说明] 现准备为某银行开发一个信用卡管理系统CCMS该系统的基本功能如下 (1) 信用卡申请非信用卡客户填写...
  • 《1》数据库系统(Database System,DBS) 又一个相互关联的数据的集合和一组用以访问这些数据的程序组成;这个数据集合通常被称作数据库(Database); DBS的主要目标是提供一种可以方便、高效地存取数据库信息的途径...

    《1》数据库系统(Database System,DBS) 由一个相互关联的数据的集合和一组用以访问这些数据的程序组成;这个数据集合通常被称作数据库(Database);

    DBS的主要目标是提供一种可以方便、高效地存取数据库信息的途径;

    《2》设计数据库的目的是为了管理大量信息;

    对数据库的管理既涉及信息存储结构的定义,又涉及信息操作机制的提供;

    此外数据库系统还必须提供所存储信息的安全性保证,即使在系统崩溃或有人企图越权访问时也应保证信息的安全性;

    如果数据将被多用户共享,那么系统还必须设法避免可能产生的异常结果;

    《3》在早期,很少有人直接和数据库打交道,而是间接的和数据库打交道,如:打印报表(如信用卡的对账单)或者通过代理(银行的出纳员和机票预定代理等)与数据库打交道;

    自动存取款机的出现,使用户可以直接和数据库进行交互;

    计算机的电话界面(交互式语音互答系统)也使得用户可以直接和数据库进行交互,呼叫者可以通过拨号和按电话键来输入信息或选择可选项;

    20实际90年代末的互联网革命急剧的增加了用户对数据库的直接访问;很多组织将他们的访问数据库的电话页面改为web页面,并提供了大量的在线服务和信息;如,当你访问一家在线书店,浏览一本书或一个音乐集时,其实就是在访问某个数据库的数据;

    尽管用户界面隐藏了访问数据库的细节,大多数人甚至没有意识到他们正在和一个数据库打交道,然而访问数据库已经成为当今几乎每个人生活中必不可少的组成部分;

    《4》数据库系统作为商业数据计算机化管理的早期方法而产生的;

    早期存储在文件处理系统(file-processing system)

    文件处理系统中存储组织信息的主要弊端:

    ① 数据的冗余和不一致(data redundancy and inconsistency)

    由于文件和程序是很长的一段时间内由不同的程序员创建的,不同文件可能有不同的结构,不同程序可能采用不同的程序设计语言写成。此外,相同的信息可能在几个地方(文件)重复存储;

    这种冗余除了导致存储和访问开销增大以外,还可能导致数据不一致性(data inconsistency),即同一数据的不同副本不一致;

    ② 数据访问困难(difficult in accessing data)

    传统的文件处理环境不支持一种方便而高效的方式去获取所需数据;

    如:假设大学的某个办事人员需要找出居住在某个特定邮政编码的所有学生的姓名,由于原始系统的设计者未预料到有这样的需求,因此没有现成的应用程序去满足这个需求;

    ③ 数据孤立(data isolation)

    由于分散在不同文件中,这些文件又可能具有不同的格式,因此,编写新的应用程序来检索适当数据是很困难的;

    ④ 完整性问题(integrity problem)

    数据库中所存储的数据的值必须满足某些特定的一致性约束(consistency constraint);

    如:大学为每个系维护一个账户,并且记录各个账户的余额,要求每个系的账户余额永远不能低于零,开发这可以在不同应用程序中加入适当的代码来强制系统的这些约束,然而,当新的约束加入时,很难通过修改程序来体现这些新的约束,尤其是当约束涉及不同文件的多个数据项时,问题就变得更加复杂了;

    ⑤ 原子性问题(atomicity problem)

    如同别的设备一样,计算机系统也会发生故障,一旦故障发生,数据就应恢复到故障发生以前的一致的状态,对于很多应用来说,这样的保证时至关重要的;

    在传统的文件处理系统中,保持原子性是很难做到的;

    ⑥ 并发访问异常(concurrent- access anomaly)

    为了提高系统的总体性能以及加快响应速度,很多系统允许多个用户同时更新数据。实际上,如今最大的互联网零售商每天就可能有来自购买者对其数据的数百万次访问;

    在这样的环境中,并发的更新操作可能相互影响,有可能导致数据的不一致;

    由于数据可能被多个不同的应用程序访问,这些程序相互间事先又没有协调,管理就很难了;

    如:为保证注册一门课程的学生人数不超过上限,注册程序维护一个注册了某门课的学生人数;当一个学生注册时,该程序读入这门课程的当前计数值,核实该计数还没有到达上限,给计数值加1,将计数存回数据库;假设两个学生同时注册,而此时的计数值是39,尽管两个学生都成功地注册了这门课程,计数值应该是41,然而两个程序可能都读取到值39,然后都写回值40,导致不正确只增加了一个注册人数;此外,假设该课程的注册人数上限是40,在上面的例子里,两个学生都注册成功,就导致违反了40个学生为注册上限的规定;

    ⑦安全性问题(security problem)

    并非数据库系统的所有用户都可以访问所有数据;

    《5》数据库系统(Database System,DBS) 是一些相互关联的数据以及一组使得用户可以访问和修改这些数据的程序的集合;

    数据库系统的一个主要目的是给用户提供数据的抽象视图,也就是说,系统隐藏关于数据存储和维护的某些细节;

    一个可用的系统必须能高效地检索数据;这种高效的需求促使设计者在数据库中使用复杂的数据结构来表示数据;由于许多数据库系统的用户并未受过计算机专业训练,系统开发人员通过以下几个层次上的抽象来对用户屏蔽复杂性,以简化用户与系统交互:

    ①物理层(physical level)

    最低层次的抽象,描述数据实际上怎么存储的;物理层详细描述复杂的底层数据结构;

    ② 逻辑层(logical level)

    比物理层层次稍高的抽象,描述数据库中存储什么数据及这些数据间存在什么关系;

    这样逻辑层就通过少量相对简单的结构描述了整个数据库;

    虽然逻辑层的简单结构的实现可能涉及复杂的物理层结构,但逻辑层的用户不必知道这样的复杂性,这称之为物理数据独立性(physical data independence)

    数据管理员使用抽象的逻辑层,他必须确定数据库中应该保存那些信息;

    ③视图层(view level)

    最高层次的抽象,只描述整个数据库的某个部分;

    尽管在逻辑层使用了比较简单的结构,但由于一个大型数据库中所存信息的多样性,仍存在一定程度的复杂性;

    数据库系统的很多用户并不关系所有的信息,而是只需要访问数据库的一部分;

    视图层抽象的定义正式为了使这样的用户和系统的交互更简单,系统可以为同一数据库提供多个视图;
    在这里插入图片描述
    通过程序设计语言中数据结构的概念进行类比,我们可以弄清个层抽象间的区别,大多数高级程序设计语言支持结构化的概念;

    例如:

    type instructor = record
           ID : char (5);
           name : char (20);
           dept name : char (20);
           salary : numeric (8,2);
           end;
    

    这段代码定义了一个具有四个字段的新纪录instructor,每个字段有一个字段名和所属类型;

    对于一个大学来说,可能包括几个这样的记录类型:

    • department, 包含字段 dept name, building, and budget
    • course, 包含字段 course id, title, dept name, and credits
    • student, 包含字段 ID, name, dept name, and tot cred
    

    在物理层,一个instructor,department 或 student记录可能被描述为连续存储位置组成的存储块。编译器为程序设计人员屏蔽了这一层细节。与此类似,数据库系统为数据库程序设计人员屏蔽了许多底层的存储细节,而数据库管理员可能需要了解数据物理组织的某些细节;

    在逻辑层,每个这样的记录通过类型定义进行描述,正如前面的代码段所示。在逻辑层上同时还要定义这些记录的相互关系。程序设计人员正是在这个抽象层次上使用某种程序设计语言进行工作。与此类似,数据库管理员常常在这个抽象层次上工作;

    在视图层,计算机用户看见的是为其屏蔽了数据类型细节的一组应用程序。与此类似,视图层上定义了数据库的多个视图,数据库用户看到的是这些视图。除了屏蔽数据库的逻辑层细节以外,视图还提供了防止用户访问数据库的某些部分的安全性机制。

    如:大学注册办公室的职员只能看见数据库中关于学生的那部分信息,而不能访问涉及教师工资的信息。

    《6》示例和模式

    特定时刻存储在数据库中的信息的集合称作数据库的一个实例(instance)。

    而数据库的总体设计称作数据库模式(schema)。数据库模式即使发生变化,也不频繁。

    数据库模式和实例的概念可以通过与程序设计语言写出的程序进行类比来理解。数据库模式对应于程序设计语言中的变量声明(以及与之关联的类型的定义)。每个变量在特定的时刻会又特定的值,程序中变量在某一时刻的值对应于书库模式的一个实例;

    数据库系统可以分为几种不同的模式:

    ①物理模式(physical schema)在物理层描述数据库设计;

    ②逻辑模式(logical schema)在逻辑层描述数据库的设计;

    ③数据库在视图层也可以有几种模式,有时称为子模式(subschema),它描述了数据库的不同视图;

    在这些模式中,因为程序员使用逻辑模式来构造数据库应用程序,从其对应用程序的效果来看,逻辑模式是目前最重要的一种模式;

    物理模式隐藏在逻辑模式下,并且通常可以在应用程序中丝毫不受影响的情况下被轻易的修改;

    应用程序如果不依赖物理模式,它们就称为是具有物理数据独立性(physical data independence),因此即使物理模式改变了它们也无需重写;

    《7》数据模型

    数据库结构的基础是数据模型(data model)

    数据模型是一个描述数据、数据联系、数据语义以及一致性约束的概念工具的集合;

    数据模型提供了一种描述物理层、逻辑层以及视图层数据库设计的方式;

    数据模型可以被划分为四类:

    ① 关系模型(relation model):

    关系模型用表的集合来表示数据和数据间的联系;

    每个表有多个列,每列有唯一的列名;

    关系模型是基于记录的模型的一种,基于记录的模型的名称的由来是因为数据库是由若干种固定格式的记录构成;

    每个表包含某种特定类型的记录,每个记录类型定义了固定数目的字段(或属性);

    表的列对应与记录类型的属性;

    关系数据库是使用最广泛的数据模型,当今大量的数据库系统都基于这种关系模型;

    ② 实体 - 联系模型(entity - relationship model)

    实体 - 联系(E-R)数据模型 基于对现实世界的认识:

    现实世界由一组称作实体的基本对象以及这些对象键的联系构成。实体是现实世界中可区别于其他对象的一件“事情”或一个“物体”;

    实体 - 联系模型被广泛用于数据库设计;

    ③ 基于对象的数据模型(object - based data model)

    面向对象的程序设计(特别是Java 、C++ 或C#)已经成为占主导地位的软件开发方法。这导致面向对象模型的发展,面向对象的数据模型可以看成是E-R模型增加了封装、方法(函数)和对象标识等概念后的扩展。

    对象 - 关系模型结合了面向对象的数据模型和关系数据模型的特征;

    ④ 半结构化数模型(semistructured data model)

    半结构化模型允许那些相同类型的数据项含有不同的属性集的数据定义,这些和早先提到的数据模型形成了对比:在那些数据模型中所有某种特定类型的数据项必须具有相同的属性集;

    可扩展标记语言(Extensible Markup Language, XML)被广泛用来表示半结构化数据;

    《8》数据库语言

    数据系统提供数据定义语言(data-definition Language)来定义数据库模式;

    数据操纵语言(data - manipulation Language)来表达数据库的查询和更新;

    数据定义和数据操作语言并不是两种分离的语言,相反的,它们简单地构成了单一地数据库语言(如广泛被使用地SQL语言)地不同部分;

    《9》数据操纵语言

    数据操纵语言(Data - Manipulation Language,DML)是这样一种语言,它使得用户可以访问或操纵那些按照适当的数据模型组织起来地数据;

    访问类型:

    ① 对存储在数据中的信息进行检索;

    ② 向数据库中插入新的信息;

    ③ 从数据库中删除信息;

    ④ 修改数据库中存储的信息;

    两种基本地数据操作语言:

    过程化DML(procedural DML)要求用户指定需要什么数据以及如何获取这些数据;

    声明式DML(declarative DML)(也称为非过程化DML)只要求用户指定需要什么数据,而不声明如何获取这些数据;

    通常声明式DML比过程化DML易学易用;

    查询(query)是要求对信息进行检索地语句;DML中涉及信息检索地部分称作查询语言(query Language);

    事件中常把查询语言和数据操纵语言作为同义词使用,尽管从技术上来说这并不正确;

    抽象层次不仅可以用于定义或构造数据,而且还可以用于操作数据,在物理层,必须定义高可效访问数据地算法;在更高地抽象层次,则强调易用性;目标是人能更有效和系统交互;

    数据库系统地查询处理部件将DML的查询语句翻译成数据库系统物理层的动作序列;

    《10》数据定义语言

    数据库模式是通过一系列定义来说明的,这种定义由一种称作数据定义语言(Data - Definition Language ,DDL)的特殊语言来表达,DDL也可用于定义数据的其他特征;

    数据库系统所使用的存储结构和访问方式是通过一系列特殊的DDL语句来说明的,这种特殊的DDL称作数据存储和定义(data storage and definition)语言。这种语言定义了数据库模式的实现细节,而这些细节对用户来说通常是不可见的;

    存储在数据库中的数据必须满足某些一致性(consistency constraint):

    ① 域约束(domain constraint):

    每个属性必须对应于一个所有可能的取值构成的域;声明一种属性属于某种域就相当于约束它可以取的值;

    域约束是完整性约束的最基本形式;每当由新的数据项插入到数据库中,系统就能方便地进行域约束检测;

    ② 参照完整性(referential integrity)

    一个关系中给定属性集上地取值也在另一关系地某一属性集地取值中出现(参照完整性);

    如:一个course记录中地dept_name值必须出现在department关系中地某个记录地dept_name属性中;

    数据库地修改会导致参照完整性地破坏;当参照完整性约束被违反时,通常地处理时拒绝执行导致完整性被破坏地操作;

    ③ 断言(assertion)

    一个断言就是数据库需要时刻满足的某一条件;

    域约束和参照完整性是断言地特殊形式;

    如:每一个学期每一个系必须至少开设5门课程;

    断言创建后,系统会检测其有效性,如果断言失败,则以后只有不破坏断言地数据库更新才被允许;

    ④ 授权(authorization)

    对用户加以区别,不同的用户在数据库中地不同数据值上允许不同地访问类型;这些区别一授权来表达:

    读权限(read authorization):允许读取数据,但不能修改数据;

    插入权限(insert authorization):允许插入新数据,但不允许修改已有数据;

    更新权限(update authorization):允许修改,但不能删除数据;

    删除权限(delete authorization):允许删除数据;

    DDL以一些指令(语句)作为输入,生成一些输出;

    DDL地输出放在数据字典(data dictionary)中,数据字典包含了元数据(metadata),元数据是关于数据的数据;

    可以把数据字典看作一种特殊的表,这种表只能由数据库系统本身(不是常规地用户)来访问华为修改;

    在读取和修改实际地数据前,数据库系统先要参考数据字典;

    《11》表

    关系数据库基于关系模型,使用一系列表表达数据以及这些数据之间地联系;关系数据库包括DDL和DML;

    每个表都有多个列,每个列由唯一的名字;

    关系模式时基于记录地的模型的一个示例;

    基于记录的模型,之所以有此成为,是因为数据库的结构是几种固定格式的记录;

    每个表包含一种特定类型的记录,每种记录类型定义固定数目的字段或属性;表的列对应记录类型的属性;

    《12》数据操纵语言

    ① SQL查询语言是非过程化的;它以几个表作为输入(也可能是一个),总是返回一个表;

    如:找出历史系的所有教员的名字

    select instructor.name
    from instructor
    where instructor.dept name = ’History’;
    

    ② 查询可能涉及来自不止一个表的信息;

    如:找出与经费预算超过95000美元的系相关联的所有的教员的ID与系名

    select instructor.ID, department.dept name
    from instructor, department
    where instructor.dept name= department.dept name and
                  department.budget > 95000;
    

    《13》数据定义语言

    SQL提供了一个丰富的的DDL语言,可以定义表、完整性约束、断言等;

    如:使用DDL语言定义department表

    create table department
    (  dept name char (20),
        building char (15),
       budget numeric (12,2)
    
    );
    

    《14》来自应用程序的数据库访问

    ① SQL不像一个通用的图灵机那么强大,及有一些计算可以用通用的程序设计语言来表达,但无法通过SQL来表达;

    ② SQL还不支持诸如从用户那儿输入、输出到显示器、或者通过网络通信这样的动作;这样的计算和动作必须用一种宿主语言来写,比如C、C++、或Java,在其中使用嵌入式的SQL查询来访问数据库中的数据;

    ③ 应用程序(application program)在这里指的是与数据库进行交互的程序;

    ④ 为了访问数据库,DML语言需要由宿主语言来执行,具体由两种途径:

    <1>一种是通过提供应用程序接口(过程集),可以将DML和DDL的语句发送给数据库,在取回结果;

    与C语言一起使用的开放数据库连接(ODBC)标准,是一种常用的应用程序接口标准。Java数据库连接(JDBC)标准为Java语言提供了相应的特性;

    <2>另一种通过扩展宿主语言的语法,在宿主语言的程序中嵌入DML调用。

    通常用一个特殊字符作为DML调用的开始,并且通过处理器,称为DML预编译器(DML precompiler),来将DML语句转变成宿主语言中的过程调用;

    《15》数据库设计过程

    ① 数据库设计的主要内容是数据库模式的设计;

    ② 高层的数据模型为数据库设计者提供了一个概念框架,去说明数据库用户的数据需求,以及将来怎么构造数据库结构以满足这些需求;

    ③ 数据库的初始阶段是全面刻画预期的数据库用户的数据需求;

    为了完成这个任务,数据库设计者有必要和领域专家、数据库用户广泛地交流,这个阶段地成果是制定出用户需求地规格文档;

    ④ 下一步,设计者选择一个数据模型,并运用该选定的数据模型概念,将那些需求转换成一个数据库地概念模式;

    在这个概念设计(conceptual-design)阶段开发出来的模式提供了企业的详细概述;设计者在复审这个模式,确保所有的数据需求都满足并且相互之间没有冲突,在检查的过程中设计者也可以去掉这些冗余的特性;

    这一极端的重点是描述数据和他们之间的联系,而不是指定物理的存储细节;

    ⑤ 从关系模型的角度看,概念设计阶段设计决定数据库中应该包括那些属性,以及如何将这些属性组织到多个表中;前者基本上上商业的决策,而后者主要是计算机科学的问题,解决这个问题由两个方法:

    一种是使用实体-联系模型

    另一种是引入一套算法(通常称为规范化),这套算法将所有属性集作为输入,生成一组关系表;

    ⑥ 一个开发的概念模型还将指出企业的功能需求;

    在功能需求说明(specification of functional requirement)中,用户描述数据之上的各种操作(或事物);如:更新数据、检索特定的数据、删除数据等;

    在概念设计的这个阶段,设计者可以对模式进行复审,确保满足功能需求;

    ⑦ 抽象数据模型转换到数据库实现进入最后阶段;

    在逻辑设计阶段(logical-design phrase),设计者将高层的概念模式映射到要使用的数据库系统的实现数据模型上;然后设计者将得到的特定与系统的数据库模式用到物理设计阶段(physical-design phrase )中,在这个阶段中指定数据库的物理特性,这些特性包括文件组织的形式以及内部的存储结构;

    《16》大学机构的数据库设计

    以大学数据库设计为例,来阐明设计过程;

    初始的用户需求说明可以基于与数据库用户的交流以及设计者自身对于大学机构的分析,这个设计阶段中的需求描述是制定数据库的概念结构的基础;

    大学的主要特征:

    • 大学分成几个系,每个系有自己唯一的名称(dept_name)来标识,坐落在特定的建筑物(building)中,有他的经费预算(budget);

    • 每一个系有一个开设课程列表,每门课由课程号(course_id)、课程名(title)、系名(dept_name)和学分(credts),还可能由先修要求(prerequisites);

    • 教师由个人唯一的标识好(ID)来标识,每位教师由姓名(name)、所在的系(dept_name)和工资(salary);

    • 学生由个人唯一的标识好(ID)来标识,每位学生由姓名(name)、主修的系(dept_name)和已修的学分数(tot_cred);

    • 大学维护一个教室列表,具体有楼名(building)、房间号(room_number)和容量(capacity);

    • 大学维护开设的所有课程(开课)的列表,每次开课由课程号(course_id)、开课号(sec_id)、年(year)和学期(semester)来标识,与之相关联的有学期(semester)、年(year)、楼名(building)、房间号(room_number)和时段号(time_slot_id,即上课时间);

    • 系有一个教学任务列表,说明美味教师的授课情况;

    •大学有一个所有学生课程注册的列表,说明每个学生在那些课程的哪次开课中注册了;

    《17》实体 - 联系模型

    ① 实体 - 联系(E - R)数据模型使用一组称为实体的基本对象,以及这些对象之间的联系;实体是现实世界中可区别于其他对象的一件“事情”或一个“物体”;

    ② 数据库中实体通过属性(attribute)集合来描述;

    ③ 联系(relationship)是几个实体之间的关联;同一类型的所有实体的集合称作实体集(entity set),同一类型的所有联系的集合称作联系集(relationship set);

    ④ 数据库的总体逻辑结构(模式)可以用实体 - 联系图(entity-relationship diagram,E - R图)进行图形化表示,有几种方法来描绘,最常用的方法是采用统一建模语言(Unified Modeling Language,UML):

    • 实体集采用矩形框表示,实体名在头部,属性名列在下面;

    • 联系集采用连接一对相关的实体集的菱形表示,联系名放在实体内部;

    如:E-R图表示出instructor 和department 这两个实体集
    在这里插入图片描述
    ⑤ 除了实体和联系外,E-R模型还描述了数据库必须遵守的对其内容的某些约束;一个重要的约束时映射基数(mapping cardinality),他表示通过某个联系集能与一实体进行关联的实体数目;

    《18》规范化

    ① 设计关系数据库所用到的另外一种方法时通常被称为规范化的过程;

    ② 它的目标时生成一个关系模式集合,使我们存储信息时没有不必要的冗余,同时又能轻易地检索数据;

    ③ 这种方法是设计一种符合适当地范式(normal form)地模式,为确定一个关系模式是否符合想要的范式,需要额外的关于用数据库建模的现实世界中机构的信息;

    ④ 最常用的方法就是使用函数依赖(functional dependency);

    ⑤一个不好的设计有以下不良特性:

    • 信息重复;

    • 缺乏表达某些信息的能力;

    ⑥ 空值(null)表示这个值不存在(或者未知),未知值可能是缺失(该值的确存在,但我们没有得到它)或不知道(不知道该值是否存在);

    《19》数据存储和查询

    ① 数据库系统划分为不同的模块,每个模块完成整个系统的一个功能;数据库系统的功能模块大致可分为存储管理器和查询处理部件;

    ② 企业的大型数据库的大小可以达到数百个gigabyte,甚至达到terabyte ;一个gigabyte大约等于1000个(实际上是1024个)megabyte(十亿字节),一个terabyte等于一百万个megabyte(一万亿字节);

    ③ 查询处理器帮助数据库系统简化和方便了数据的访问,查询处理器使得数据库用户能获得很高的性能,同时可以在视图的层次上工作,不必承受了了解系统实现的物理层次细节的负担;

    将在逻辑层编写的更新和查询转变成物理层的高效操作序列,这是数据库的任务;

    《20》存储管理器

    ① 存储管理器是数据库系统中负责在数据库中存储的底层数据与应用程序以及向系统提交的查询之间提供接口的部件;

    ② 存储管理器负责与文件管理器进行交互;原始数据通过操作系统提供的文件系统存储在磁盘上,存储管理器将各种DML语句含义为底层文件系统命令;

    ③ 因此,存储管理器负责数据库中数据的存储、检索和更新;

    ④存储管理部件包括:

    • 权限及完整性管理器(authorization and integrity manager):检索是否满足完整性约束,并检查试图访问数据的用户的权限;

    • 事物管理器(transaction manager):保证了即使发生故障,数据库也保持在一致(正确)的状态,并保证并发事务的执行不发生冲突;

    • 文件管理器(file manager):管理磁盘存储空间的分配,管理用于表示磁盘上所存储的数据结构;

    • 缓冲区管理器(buffer manager):负责将数据从磁盘中取到内存中来,并决定那些数据应被缓冲存储在内存中;缓冲区管理器是数据库中的一个关键部分,因为它使得数据库可以处理比内存更大的数据;

    ⑤ 存储管理器的几种数据结构,作为系统物理实现的一部分:

    • 数据文件(data files):存储数据库本身;

    • 数据字典(data dictionary):存储关于数据库结构的元数据,尤其是数据库模式;

    • 索引(index ):提供对数据库的快速访问;和书中的索引一样,数据库索引提供了指向包含特定值的数据的指针;

    如:可以运用索引找到具有特定的ID的instructor 记录,或具有特定的name的所有instructor记录;

    散列是另外一种索引方式,在某些情况下速度更快,但不是在所有的情况下都这样;

    《20》查询处理器

    查询处理器组件包括:

    • DDL解释器(DDL interpreter):解释DDL语句并将这些定义记录在数据字典中;

    • DML编译器(DML compiler):将查询语言中的DML语句翻译为一个执行方案,包括一系列查询执行引擎能理解的低级指令;

    一个查询通常可以翻译成多种等价的具有相同结果的执行方案的一种。DML编译器还可以进行查询优化(query optimization),也就是从几种选择中选出代价最小的一种;

    • 查询优化引擎(query evaluation engine):执行由DML编译器产生的低级指令;

    《21》事务管理

    ① 通常,对数据库的几个操作合起来形成一个逻辑单元;

    ②如:A、B两个账户间进行资金转账,其中A账户进行取出操作,另一个账户B进行存入操作;显然这两个操作必须保证要么都不发生,要么都发生,也就是说,资金转账必须完成或根本不发生;

    • 这种要么完成要么不发生的要求称为原子性(atomicity);

    • 除此之外,资金转账还必须保持数据库的一致性,也就是说,A和B之间的余额之和应该保持不变,这种要求称做为一致性(consistency);

    • 最后,当资金转账成功结束后,即使数据发生故障,账户A和账户B的余额也应该保持转账成功结束后的新值,这种保持的要求称作持久性(durability);

    ③ 事物(transaction)是数据库应用中完成单一逻辑功能的集合操作,每个事务时一个既有原子性又有一致性的单元;

    • 因此我们要求事物不违反任何的数据库一致性约束,也就是说,如果事物启动时数据库是一致的,那么当这个事物成功结束时也应该时一致的;

    • 然而,在事物执行过程中,必要时允许暂时的不一致,因此无论是A取出的操作在前,还是B存入的操作在前,这两个操作都必然由一个先后次序;这种暂时的不一致虽然是必须的,但在故障发生时,很可能导致问题的产生;

    ④ 适当地定义各个事物时程序员的责任,事务的定义应使之能保持数据库的一致性;

    • 如:资金从账户A转到账户B这个事物可以被定义为由两个单独的程序组成:一个对账户A执行取出操作,另一个对账户B执行存入操作,这两个程序依次执行可以保持一致性;但是,这两个程序自身都不是把数据库从一个一致的状态转入一个新的一致的状态,因此他们都不是事物;

    ⑤ 原子性和持久性的保证时数据库系统自身的职责,确切的说,时恢复管理器(recovery manager)的职责;

    • 在没有故障发生的情况下,所有事物均完成成功,这时要保证原子性很容易,但是,由于各种各样的故障,事物并不总能成功执行完成;

    • 为了保证原子性,失败的事物必须对数据库状态不产生任何影响,因此数据库必须恢复到该失败事物开始执行以前的状态,这种情况下数据库系统必须进行故障恢复(failure recovery),即检测系统故障并将数据库恢复到故障发生以前的状态;

    ⑥ 当多个事物同时对数据库进行更新时,即使每个事物都是正确的,数据的一致性也可能被破坏;

    • 并发控制管理器(concurrency-control manager)控制并发事物间的相互影响,保证数据库一致性;

    • 事物管理器(transaction manager)包括并发控制管理器和恢复管理器;

    《22》数据库体系结构

    • 数据库系统的体系结构很大程度上取决于数据库系统所运行的计算机系统;

    • 数据库系统可以是集中式的、客户/服务器(一台服务器为多个客户执行任务);

    • 也可以针对并行计算机体系结构设计数据库,分布式系统数据库包含地理上分离的多台计算机;

    《22》客户/服务器系统

    ① 如今数据库系统的大多数用户并不直接面对数据库系统,而是通过网络与其连接,因此,可以区分远程数据库用户工作用的客户机(client),和运行数据库系统的服务器(server);

    ② 数据库应用通常可以分为两个或三个部分,

    ③ 在一个两层体系结构(two-tier architecture)中,应用程序驻留在客户机上,通过查询语言表达式来调用服务器上的数据库系统功能;像ODBC和JDBC这样的应用程序接口标准被用于客户端和服务端的交互;

    ④ 在一个三层体系结构(three-tier architecture)中,客户机只作为一个前端并且不包含任何直接的数据库调用;

    • 客户端通常通过一个表单界面与应用服务器(application server)进行通信;而应用服务器与数据库系通信以访问数据;

    • 应用程序的业务逻辑(business logic),也就是说在何种条件下何种反应,被嵌入到应用服务器中,而不是分布到多个客户机上;

    • 三层结构的应用更适合于大型应用和互联网上的应用;
    在这里插入图片描述
    在这里插入图片描述
    《23》并行数据库系统

    ① 并行系统通过并行地使用多个处理器和磁盘来提高处理速度和I/O速度;

    ② 并行计算机正变得越来越普及,相应地使得并行数据库系统地研究变得越来越重要;

    • 有些应用需要查询非常大型地数据库(TB量级,即10^12字节),有些应用需要在每秒钟里处理很大数量的事物(每秒数千个事物),这些应用推动了并行数据库系统的发展;

    • 集中式数据库系统和客户-服务器数据库系统的能力不够强大,不足以处理这样的应用;

    ③ 对数据库系统性能的度量由两者主要方式:

    (1)吞吐量(throughput):在给定时间内所能完成任务的数量;

    (2)响应时间(response time):单个任务从提交到完成所需的时间;

    • 对于处理大量小事物的系统,通过并行地处理多个事物可以提高他的吞吐量。

    • 对于处理大事物地系统,通过并行地执行每个事物中的子任务可以缩短它的响应时间,同时提高它地吞吐量;

    《24》分布式数据库系统

    ① 在分布式数据库系统中(distributed database system)中,数据库存储在几台计算机中;分布式系统中地计算机之间通过诸如高速私有网络或因特网那样地通信媒介相互通信;

    它们不共享主存储器或磁盘,分布式系统中地计算机在规模上和功能上是可变的,小到工作站,大到大型机系统;
    在这里插入图片描述
    建立分布式系统又几个原因,包括数据共享、自治性和可用性:

    <1>数据共享(sharing data): 建立分布式系统地主要优点是,它提供了一个环境是一个站点上的用户可以访问存放在其他站点上的数据;

    • 如:在一个分布式大学系统上,每个校区存储与该校区相关的数据;一个校区的用户可以访问另一个校区的数据;假设没有这种能力,那么把学生记录从一个校区传送到另一个校区,据需要借助于与现有系统相互关联的外部机制;

    <2>自治性(autonomy):通过数据分布的方式来共享数据的主要优点在于,每个站点可以对本地存储的数据保持一定程度的控制;

    • 在集中式系统中,中心站点的数据库管理员对数据库进行控制;

    • 在分布式系统中,有一个全局数据库管理员负责整个系统;又一部分职责被委派给每个站点的本地数据库管理员;每一个管理员可以又不同程度的局部自治(local autonomy),其程度的不同依赖于分布式数据库系统的设计,可以进行本地自治通常是分布式数据库的一个主要优势;

    <3>可用性(available):在分布式系统中,如果一个站点发生故障,其他站点可能还继续运行;

    • 特别地,如果数据项在几个站点上进行了复制(replicate),需要某个特定数据项地事物可以在这几个站点中地任何一个上找到该数据项;于是,一个站点地故障不一定意味着整个系统停止运转;

    《25》数据挖掘和信息检索

    ① 数据挖掘(data mining)指的是半自动地分析大型数据库并从中找出有用的模式的过程;

    ② 和人工智能中的知识发现(也称为机器学习(machine learning))或者统计分析一样,数据挖掘试图从数据中寻找规则或模式;但数据挖掘和机器学习、统计分析不一样的地方在于它处理大量的主要存储在磁盘上的数据,也就是说数据挖掘就是在数据库中发现知识;

    ③ 从数据库中发现的某些类型的知识可以用一套规则(rule)表示:

    如:“年收入高于50000美元的年轻女性是最可能购买小型运动车的人群”,这条规则可能并不是永远正确的,但他有一定的“支持度”和“可信度”;

    其他类型的知识表达方式有联系不同变量的方程式,或者通过其他机制根据某些已知的变量来预测输出;

    ④ 通常在数据挖掘中还需要人参与,包括数据预处理使数据变为适合算法的格式,在已发现模式的后处理中找到新奇的有用模式;

    给定一个数据库,可能不止一种类型的模式,但需要人工交互挑选有用类型的模式;由于这个原因,现实中的数据挖掘是一个半自动的过程;

    ⑤ 大型企业有各种不同的可用于业务决策的数据开源,要在这些各种各样的数据上高效的执行查询,企业建立了数据仓库(data warehouse);数据仓库从多个来源收集数据,建立统一的模式,驻留在单个节点上;于是,就为用户提供了单个统一的数据界面;

    ⑥ 文本数据是非结构化的,与关系数据库中严格的结构化数据不同;

    查询非结构化的文本数据被称为信息检索(information retrieval);

    信息检索系统和数据库系统有很大程度上是相同的–特别是基于辅助存储器的数据存储和检索;

    信息检索系统领域和数据库系统所强调的重点不同,信息系统重点强调基于关键词的查询,文档和查询的相似度,以及文档的分析、分类和检索;

    《26》特种数据库

    ① 数据库系统的一些应用领域受到关系数据库模型的限制,其结果是,研究人员开发了几种数据模型来处理这些领域的应用,包括基于对象的数据模型和半结构化数据模型;

    ② 基于对象的数据模型

    面向对象程序设计已经成为占统治地位的软件开发方法学,这导致面向对象数据模型(object-based data model)的发展;

    面向对象模型可以看作E-R模型的扩展,增加了封装、方法(函数)和对象标识;继承、对象标识和信息封装(信息隐蔽),以及对外提供方法作为访问对象的接口,这些就是面向对象设计的关键概念;

    现在主要的数据库厂商都支持对象-关系数据模型(object-relational data model),这是一个面向对象数据模型和关系数据模型的特点结合在一起的数据模型,它拓展了传统的关系模型,增加了新的特征如结构和集合类型;

    ③ 半结构化数据模型

    半结构化数据模型允许那些相同类型的数据项有不同的属性集的数据说明;这和早先提到的数据模型形成了对比:在那些数据模型中所有某种特定类型的数据项必须有相同的属性集;

    XML语言设计的初衷是为文本文档增加标签信息,但由于他在数据交换中的应用而变得日益繁重;XML语言提供了表达含有嵌套结构的数据的方法,能够灵活组织数据结构,这对于一些非传统数据来说非常重要;

    《27》数据库用户和管理员

    • 数据库系统的一个主要目标是从数据库中检索信息和往数据库中存储新的信息;使用数据库的人员可分为数据库用户和数据库管理员;

    <1>数据库用户和用户界面

    • 数据库系统的用户可以风味四种不同的类型,系统为不同类型的用户设计了不同类型的用户界面;

    ① 无经验的用户(naive user)是默认经验的用户:通过激活事先已经写好的应用程序同系统进行交互;

    • 如:大学的一位职员需要往A系中添加以为新的教师时,激活一个叫做new_hire的程序;该程序要求这位职员输入新教师的名字、新教师的ID、所在系的名称(即A)以及新教师的工资;

    • 此类用户的典型用户界面时表格界面,用户只需要填写表格的对应项就可以了;无经验的用户也可以很简单的阅读数据库产生的报表;

    • 如:一个学生,在课程注册的过程中想通过Web界面来注册一门课程;应用程序首先要验证该用户的身份,然后允许他去访问一个表格,他可以在表格中填入想填的信息;表格信息被送回给服务器上的Web应用程序,让后应用程序确定该课程是否还有空额(从数据库中检索信息),如果有,就把这位学生的信息添加到数据库中的该课程花名册中;

    ② 应用程序员(application programmer)时编写应用程序的计算机专业人员,有很多工具可以供应给程序员来选择开发用户界面;

    • 快速应用开发(Rapid Application Development,RAD)工具是使应用程序员能够尽量少编写程序就可以构造出表格和报表的工具;

    ③ 老练的用户(sophisticated user)不通过编写程序同系统交互,而是用数据库查询语言或数据分析软件这样的工具来表达他们的需求;分析员通过提交查询来研究数据库中的数据,所以属于这一类用户;

    ④ 专门的用户(specialized user)是编写专门、不适合于传统数据处理框架的数据库应用夫人富有经验的用户;

    • 这样的应用包括:计算机辅助设计系统、知识库和专家系统、存储复杂结构数据(如图形数据和声音数据)的系统,以及环境建模系统;

    <2> 数据库管理员

    • 使用DBS的一个主要原因是可以对数据和访问这些相互据的程序进行集中控制;对系统进行几种控制的人称作数据库管理员(DataBaseAdministrator,DBA)

    • DBA的作用包括:

    ① 模式定义(schema definition):DBA 通过DDL书写一系列定义来创建最初的数据库模式;

    ② 存储结构和存储方法定义(storage structure and access-method definition);

    ③ 模式和物理组织的修改(schema and physical-organization modification):由数据库管理员(DBA)对模式和物理组织进行修改,以反映机构的需求变化,或为提高性能选择不同的物理组织;

    ④ 数据访问授权(granting of authorization for data access):通过授予不同类型的权限,数据库管理员可以规定不同的用户各自可以访问的数据库部分;授权信息保存在一个特殊的系统结构中,一旦系统中由访问数据的要求,数据库系统就去查阅这些信息;

    ⑤ 日常维护(routine maintenance):数据库管理员的日常维护活动有:

    • 定期备份数据库,或者在磁带或远程服务器上,以防止像洪水之类的灾难发生时数据丢失;

    • 确保正常运转时所需的空余磁盘空间,并且在需要时升级磁盘空间;

    • 监视数据库的运行,并确保数据库的性能不因一些用户提交了花费时间较多的任务就下降很多;

    《28》数据库系统的历史

    • 从商业计算机的出现,数据处理就一直推动者计算机的发展,事实上,数据处理自动化早于计算机的出现;

    • Herman Hollerith 发明的穿孔卡片,早在20世纪就用来记录美国的人口普查数据,并且用机械系统来处理这些卡片和列出结果;穿孔卡片后被广泛用作数据输入计算机的一种手段;

    • 数据存储和处理技术的发展年代表:

    ① 20世纪50年代和20实际60年代初:磁带被用于数据存储;

    • 诸如工资单这样的数据处理已经自动化了,数据存储在磁带上;数据处理包括从一个或多个磁带上读取数据,并将数据写会到新的磁带上;数据也可以由一叠穿孔卡片输人,而输出到打印机上。

    • 如:工资增长的处理是通过将增长表示到穿孔卡片上,在读人一叠穿孔卡片时同步地读人保存主要工资细节的磁带。记录必须有相同的排列顺序。工资的增加额将被加人到从主磁带读出的工资中,并被写到新的磁带上,新磁带将成为新的主磁带。

    • 磁带(和卡片组)都只能顺序读取,数据规模可以比内存大得多,因此,数据处理程序被迫以一种特定的顺序来对数据进行处理,读取和合并来自磁带和卡片组的数据。

    ② 20世纪60年代末和20世纪70年代:20世纪60年代末硬盘的广泛使用极大地改变了数据处理的情况,因为硬盘允许直接对数据进行访间。

    • 数据在磁盘上的位置是无关紧要的,因为磁盘上的任何位置都可在几十毫秒内访问到。数据由此脱了顺序访问的限制。有了磁盘,我们就可以创建网状和层次的数据库,它可以将表和树这样的数据结构保存在磁盘上。程序员可以构建和操作这些数据结构。

    • 由 Codd [1970]撰写的一篇具有里程碑意义的论文定义了关系模型和在关系模型中査询数据的非过程化方法,由此关系型数据库诞生了。关系模型的简单性和能够对程序员屏蔽所有实现细节的能力具有真正的诱惑力。随后, Codd 因其所做的工作获得了声望很高的 ACM 图灵奖。

    ③ 20世纪80年代:尽管关系模型在学术上很受重视,但是最初并没有实际的应用,这是因为它被认为性能不好;关系型数据库在性能上还不能和当时已有的网状和层次数据库相提并论。

    • 这种情况直到 System R 的出现才得以改变,这是 IBM 研究院的一个突破性项目,它开发了能构造高效的关系型数据库系统的技术。 Astrahan 等[1976]和 Chamberlin 等[1981]给出了关于 System R 的很好的综述。

    • 完整功能的 System R 原型导致了 IBM 的第一个关系型数据库产品 SQL / DS 的出现。与此同时,加州大学伯克利分校开发了 Ingres 系统。它后来发展成具有相同名字的商品化关系数据库系统。最初的商品化关系型数据库系统,如 IBM DB2、 Oracle 、 Ingres 和 DEC Rdb ,在推动高效处理声明性查询的技术上起到了主要的作用。

    • 到了20世纪80年代初期,关系型数据库已经可以在性能上与网状和层次型数据库进行竞争了。

    • 关系型数据库是如此简单易用,以至于最后它完全取代了网状/层次型数据库,因为程序员在使用后者时,必须处理许多底层的实现细节,并且不得不将他们要做的査询任务编码成过程化的形式。

    • 更重要的,他们在设计应用程序时还要时时考虑效率问题,而这需要付出很大的努力。相反,在关系型数据库中,几乎所有的底层工作都由数据库自动来完成,使得程序员可以只考虑逻辑层的工作。

    • 自从在20世纪80年代取得了统治地位以来,关系模型在数据模型中一直独占鳌头。

    • 在20世纪80年代人们还对并行和分布式数据库进行了很多研究,同样在面向对象数据库方面也有初步的工作。

    ④ 20世纪90年代初: SQL 语言主要是为决策支持应用设计的,这类应用是查询密集的;

    • 而20世纪80年代数据库的支柱是事务处理应用,它们是更新密集的。决策支持和查询再度成为数据库的一个主要应用领域。分析大量数据的工具有了很大的发展。

    • 在这个时期许多数据库厂商推出了并行数据库产品。数据库厂商还开始在他们的数据库中加人对象﹣关系的支持。

    ⑤ 20世纪90年代:最重大的事件就是互联网的爆炸式发展。数据库比以前有了更加广泛的应用。

    现在数据库系统必须支持很高的事务处理速度,而且还要有很高的可靠性和24x7的可用性(一天24小时,一周7天都可用,也就是没有进行维护的停机时间)。数据库系统还必须支持对数据的 Web 接口。

    ⑥21世纪第一个十年:21世纪的最初五年中,我们看到了 XML 的兴起以及与之相关联的 XQuery 查询语言成为了新的数据库技术。

    • 虽然 XML 广泛应用于数据交换和一些复杂数据类型的存储,但关系数据库仍然构成大多数大型数据库应用系统的核心。

    • 在这个时期,我们还见证了“自主计算/自动管理”技术的成长,其目的是减少系统管理开销;我们还看到了开源数据库系统应用的显著增长,特别是 PostgreSQL 和 MySQL 。

    • 在21世纪第一个十年的后几年中,用于数据分析的专门的数据库有很大增长,特别是将一个表的每一个列高效地存储为一个单独的数组的列存储,以及为非常大的数据集的分析而设计的高度并行的数据库系统。

    • 有几个新颖的分布式数据存储系统被构建出来,以应对非常大的 Web 节点如 Amazon 、 Facebook 、 Google 、 Microsoft 和 Yahoo !的数据管理需求,并且这些系统中的某些现在可以作为 Web 服务提供给应用开发人员使用。

    • 在管理和分析流数据如股票市场报价数据或计算机网络监测数据方面也有重要的工作。

    • 数据挖掘技术现在被广泛部署应用,应用实例包括基于 Web 的产品推荐系统和 Web 页面上的相关广告自动布放。

    《29》总结

    ● 数据库管理系统( DataBase - Management System , DBMS )由相互关联的数据集合以及一组用于访间这些数据的程序组成。数据描述某特定的企业。

    ● DBMS 的主要目标是为人们提供方便、高效的环境来存储和检索数据。

    ●如今数据库系统无所不在,很多人每天直接或间接地与数据库系统打交道。

    ●数据库系统设计用来存储大量的信息。数据的管理既包括信息存储结构的定义,也包括提供处理信息的机制。另外数据库系统还必须提供所存储信息的安全性,以处理系统崩溃或者非授权访问企图,如果数据在多个用户之间共享,系统必须避免可能的异常结果。

    ●数据库系统的一个主要目的是为用户提供数据的抽象视图,也就是说,系统隐藏数据存储和维护的细节。

    ●数据库结构的基础是数据模型( data model ):一个用于描述数据、数据之间的联系、数据语义和数据约束的概念工具的集合。

    ●关系数据模型是最广泛使用的将数据存储到数据库中的模型。其他的数据模型有面向对象模型、对象﹣关系模型和半结构化数据模型。

    ● 数据操纵语言( Data - Manipulation Language , DML )是使得用户可以访问和操纵数据的语言。当今广泛使用的是非过程化的 DML ,它只需要用户指明需要什么数据,而不需指明如何获得这些数据。

    ● 数据定义语言( Data - Definition Language , DDL )是说明数据库模式和数据的其他特性的语言。

    ●数据库设计主要包括数据库模式的设计。实体﹣联系( E - R )数据模型是广泛用于数据库设计的数据模型,它提供了一种方便的图形化的方式来观察数据、联系和约束。

    ●数据库系统由几个子系统构成:

    存储管理器(storage manager)子系统在数据库中存储的底层数据与应用程序和向系统提交查询之间提供接口。

    查询处理器( quer processor )子系统编译和执行 DDL 和 DML 语句。

    ● 事务管理( transaction management )负责保证不管是否有故障发生,数据库都要处于一致的(正确的)状态。事务管理器还保证并发事务的执行互不冲突。

    ●数据库系统的体系结构受支持其运行的计算机系统的影响很大。数据库系统可以是集中式的,或者客户﹣服务器方式的,即一个服务器机器为多个客户机执行工作。数据库系统还可以设计成具有能充分利用并行计算机系统结构的能力。分布式数据库跨越多个地理上分布的互相分离的计算机。

    ●典型地,数据库应用可被分为运行在客户机上的前端和运行在后端的部分。在两层的体系结构中,前端直接和后端运行的数据库进行通信。在三层结构中,后端又被分为应用服务器和数据库服务器。

    ●知识发现技术试图自动地从数据中发现统计规律和模式。数据挖掘( data mining )领域将人工智能和统计分析研究人员创造的知识发现技术,与使得知识发现技术能够在极大的数据库上高效实现的技术结合起来。

    ●有4种不同类型的数据库用户,按用户期望与数据库进行交互的不同方式来区分他们。为不同类的用户设计了不同的用户界面。

    展开全文
  • 企业信用信息基础数据库管理实施办法 第一章 总 则 第一条 为推动社会信用体系建设维护金融稳定防 范和降低信用风险...第二条 企业信用信息基础数据库以下简称企业征信 系统是全国统一的企业信用信息共享平台 * 信贷 管
  • 产品销售管理系统的总体要求是:企业生产多种产品,产品销售管理系统模拟产品销售过程中的管理,管理对象包括产品、客户、发票等,可以实现产品销售,并能进行各种查询、统计等的处理。 其中大致设计功能如下分为...
  • JSP贸易管理系统 是一套完善的web设计系统系统采用struts2框架进行开发一套源码,对理解JSP java编程开发语言有帮助,系统具有完整的源代码和数据库 系统主要采用B/S模式开发。 二、功能介绍 1.管理员管理 (1)...
  • Java代码版信用卡管理系统数据库采用的是SQLServer,看上去有点复杂,附有全部的Java源代码,Java爱好者可拿去学习参考了。
  • 企业信用信息基础数据库系统数据接口规范(住房公积金信息采集格式).doc
  • 数据库系统概念——引言引言数据库系统的应用数据库系统的目标数据视图数据抽象实例和模式数据模型数据库语言数据...查询事务管理数据库体系结构数据库挖掘与信息检索特种数据库数据库用户和管理员数据库系统的历史总结...

    引言

    数据库管理系统(DataBase-Management System, DBMS)由一个互相关联的数据的集合和一组用以访问这些数据的程序组成。
    这个数据集合通常称作数据库(database),其中包含了关于某个企业的信息。

    DBMS思维主要目标是要提供一种可以方便、高效地存取数据库信息的途径。

    数据库系统的应用

    数据库的一些具有代表性的应用:

    企业信息

    销售: 用于存储客户、产品和购买信息。
    
    会计: 用于存储付款、收据、账户余额、资产和其他会计信息。
    
    人力资源:用于存储雇员、工资、所得税和津贴的信息,以及产生工资单。
    
    生产制造:用于管理供应链,跟踪工厂中产品的生产情况、仓库和商店中产品的详细清单以及产品的订单。
    
    联机零售:用于存储以上所述的销售数据,以及实时的订单跟踪,推荐品清单的生成,还有实时的产品评估的维护。
    

    银行和金融

    银行业: 用于存储客户信息、账户、贷款,以及银行的交易记录。
    
    信用卡交易: 用于记录信用卡消费的情况和产生每月清单。
    
    金融业: 用于存储股票、债券等金融票据的持有、出售和买入的信息;
    		也可用于存储实时的市场数据,以便客户能够进行联机交易,公司能够进行自动交易。
    

    大学

    用于存储学生信息、课程注册和成绩。
    

    航空业

    用于存储订票和航班的信息。
    航空业是最先以地理上分布得方式使用数据库的行业之一。
    

    电信业

    用于存储通话记录,产生每月账单,维护预付电话卡的余额和存储通信网络的信息。
    

    数据库系统的目标

    在文件处理系统中存储组织信息的主要弊端包括:

    数据的冗余和不一致(data redundancy and inconsistency)。
    数据访问困难(difficulty in accessing data)。
    数据孤立(data isolation)。
    完整性问题(integrity problem)。
    原子性问题(atomicity problem)。
    并发访问异常(concurrent-acccess anomaly)。
    安全性问题(security problem)。

    数据视图

    数据库系统是一些互相关联的数据以及一组使得用户可以访问和修改这些数据的程序的集合。
    数据库系统的一个主要目的是给用户提供数据的抽象视图。

    数据抽象

    通过如下几个层次是哪个的抽象来用户屏蔽复杂性,以简化用户与系统的交互:
    物理层(physical level)。最低层次的抽象,描述数据实际上是怎样存储的。物理层详细描述复杂的底层数据结构。
    逻辑层(logical level)。必物理层层次稍高的抽象,描述数据库中存储什么数据及这些数据间存在什么关系。
    视图层(view level)。最高层次的抽象,只描述整个数据库的某个部分。

    实例和模式

    特定时刻存储在数据库中的信息的集合称作数据库的一个实例(instance)。
    数据库的总体设计称作数据库模式(schema)。

    类比:
    数据库模式对应于程序设计语言中的变量声明(以及与之关联的类型的定义)。
    每个变量在特定的时刻会有特定的值,程序中变量在某一时刻的值对应于数据模式的一个实例。

    数据库系统的几种不同的模式:
    物理模式(physical schema)在物理层描述数据库的设计,

    逻辑模式(logical schema)则在逻辑层描述数据库的设计。

    数据库在视图层也可以有几种模式,有时称为子模式(subschema),它描述了数据库的不同视图。

    应用程序如果不依赖于物理模式,它们就被称为具有物理数据独立性(physical data independence),因此即使物理模式改变了它们也无需重写。

    数据模型

    数据库结构的基础是数据模型(data model)。
    数据模型是一个描述数据、数据联系、数据语义以及一致性约束的概念工具的集合。
    数据模型提供了一种描述物理层、逻辑层以及视图层数据库设计的方式。

    数据模型可被划分为四类:

    关系模型(relational model)。

    关系模型用表的集合来表示数据和数据间的联系。

    实体 - 联系模型(entity-relationship model)。

    实体-联系(E-R)数据模型基于对现实世界的这样一种认识:现实世界由一组称作实体的基本对象以及这些对象间的联系构成。实体是现实世界中可区别与其他对象的一件“事情”或者一个“物体”。

    基于对象的数据模型(object-based model)。

    面向对象的数据模型可以看出是E-R模型增加了封装、方法(函数)和对象标识等概念后的扩展。
    对象-关系数据模型结合了面向对象的数据模型和关系数据模型的特征。

    半结构化数据模型(semistructured data model)。

    半结构化的数据模型允许那些相同类型的数据项含有不同的属性集的数据定义。

    数据库语言

    数据库系统提供数据定义语言(data-definition language)来定义数据库模式,以及数据操纵语言(data-manipulation language)来表达数据的查询和更新。
    两者构成了单一的数据库语言(如广泛使用的SQL语言)的不同部分。

    数据操纵语言

    数据操纵语言(Data-Manipulation Language, DML)是这样一种语言,它使得用户可以访问或操纵那些安装某种适当的数据模型组织起来的数据。

    访问类型:

    对存储在数据库中的信息进行检索。
    向数据库中插入新的信息。
    从数据库中删除信息。
    修改数据库中存储的信息。
    

    两类数据操纵语言:
    过程化 DML(procedural DML)要求用户指定需要什么数据以及如何获得这些数据。
    声明化 DML(declarative DML)(也称为非过程化DML)只要求用户指定需要什么数据,而不指明如何回的这些数据。

    查询(query)是要求对信息进行检索的语句。DML中涉及信息检索的部分称作查询语言(query language)。
    实践中常把查询语言和数据操纵语言作为同义词使用。

    数据定义语言

    数据库模式是通过一系列定义来说明的,这些定义由一种称作数据定义语言(Data-Definition language, DDL)的特殊语言来表达。
    DDL也可用于定义数据的其他特征。

    数据库系统所使用的存储结构和访问方式是通过一系列特殊的DDL语句来说明的,这种特殊的DDL称作数据存储和定义(data storage and definition)语言。

    存储在数据库中的数据值必须满足某些一致性约束(consistency constraint)。

    城约束(domain constraint)。每个属性都必须对应于一个所有可能的取值构成的域(例如,整数型、字符型、日期/时间型)。
    参照完整性(referential integrity)。一个关系中给定属性集上的取值也在另一关系的某一属性集的取值中出现(参照完整性)。
    断言(assertion)。一个断言就是数据库需要时刻满足的某一条件。
    授权(authorization)。对于不同的用户在数据库中不同数据值上允许不同的访问类型。

    常见的授权:
    读权限(read authorization),允许读取数据,但不能修改数据;
    插入权限(insert authorization),允许插入新数据,但不允许修改已有数据;
    更新权限(updata authorization),允许修改,但不能删除数据;
    删除权限(delete authorization),允许删除数据。

    关系数据库

    关系数据库基于关系模型,使用一系列表来表达数据以及这些数据之间的联系。
    关系数据库也包括DML和DDL。

    每个表有多个列,每个列有唯一的名字。
    关系模型是基于记录的模型的一个实例。
    基于记录的模型,之所以有此称谓,是因为数据库的结构是几种固定格式的记录。
    每个表包含一种特定类型的记录。
    每个记录类型定义固定数目的字段或属性。
    表的列对应记录类型的属性。

    数据操纵语言

    SQL查询语言是非过程化的。
    它以几个表作为输入(也可能只有一个),总是仅返回一个表。

    select instructor.name
    from instructor
    where instructor.dept_name = ' History ';
    

    查询可以涉及来自不止一个表的信息。

    数据定义语言

    SQL提供了一个丰富的DDL语言,通过它,我们可以定义表、完整性约束、断言,等等。

    来自应用程序的数据库访问

    SQL不支持如从用户那儿输入、输出到显示器,或者通过网络通信这样的动作。
    这样的计算和动作必须用一种宿主语言来写,比如C、C++或Java,在其中使用嵌入式的SQL查询来访问数据库中的数据。
    应用程序(application program)在这里是指以这种方式与数据库进行交互的程序。

    两种途径:

    一种是通过提供应用程序接口(过程集),它可以用来将DML和DDL的语句发送给数据库,在取回结果。

    C语言:数据库连接(ODBC)标准;
    Java语言:数据库连接(ODBJ)标准;
    

    另一种是通过扩展宿主语言的语法,在宿主语言的程序中嵌入DML调用。
    通常用一个特殊字符作为DML调用的开始,并且通过预处理器,称为DML预编译器(DML precomplier),来将DML语句转变成宿主语言中的过程调用。

    数据库设计

    设计过程

    数据库设计的初始阶段是全面刻画预期的数据库用户的数据需求。
    下一步,选择一个数据模型,并运用该选定的数据模型的概念,将那些需求转换成一个数据库的概念模式。
    在这个概念设计(conceptual-design)阶段开发出来的模式提供了企业的详细概述。

    在功能需求说明(specification of functional requirement)中,用户描述数据之上的各种操作(或事务),例如更新数据、检索特定的数据、删除数据等。

    逻辑设计阶段(logical-design phrase),设计者将高层的概念模式映射到要使用的数据库系统的实现数据模型上;
    然后设计者将得到的特定与系统的数据库模式用到物理设计阶段(physical-design phrase)中,在这个阶段中指定数据库的物理特性,这些特性包括文件组织的形式以及内部的存储结构。

    大学机构的数据库设计

    大学的主要特征

    - 分为多个系。每个系有唯一的名字来标识,坐落在特定的建筑物中,有它的经费预算。
    - 每个系有一个开设课程列表。每门课程有课程号,课程名,系名,学分,先修要求。
    - 教师由个人唯一的标识号来标识。每位教师有姓名,所在的系,工资。
    - 学生由个人唯一的标识号来标识。每位学生有姓名,主修的系,已修的学分数。
    - 大学维护一个教室列表,详细说明楼名,房间号,容量。
    - 大学维护开设的所有课程的列表。
    每次开课由课程号,开课号,年,学期来标识。与之关联的有学期,年,楼名,房间号,时段号。
    - 系有一个教学任务列表,说明每位教师的授课情况
    - 大学有一个所有学生课程注册的列表,说明每位学生在哪些课程的哪次开课中注册了。
    

    实体-联系模型

    实体-联系(E-R)数据模型使用一组称作实体的基本对象,以及这些对象间的联系。
    实体是现实世界中可区别于其他对象的一件“事情”或一个“物体”。

    数据库中实体通过属性(attribute)集合来描述。

    联系(relationship)是几个实体之间的关系。
    同一类型的所有实体的集合称作实体集(entity set),同一类型的所有联系的集合称作联系集(relationship set)。

    数据库的总体逻辑结构(模式)可以用实体-联系图(entity-relationship diagram, E-R图)进行图形化表示。

    建模语言(Unified Modeling Language, UML)。

    基于UML的符号中,E-R图如下表示:
    实体集用矩形框表示,实体名在头部,属性名列在下面。
    联系集用连接一对相关的实体集的菱形表示,联系名放在菱形内部。

    在这里插入图片描述
    除了实体和联系,E-R模型还描绘了数据库需遵守的对其内容的某些约束:
    一个重要的约束是映射基数(mapping cardinality),它表示通过某个联系集能与一实体进行关联的实体数目。

    规范化

    规范化的过程:它的目标是生成一个关系模式集合,使我们存储信息时没有不必要的冗余,同时又能很轻易地检索数据。

    这种方法是设计一种符合适当的范式(normal form)的模式,为确定一个关系模式是否符合想要的范式,我们需要额外的关于用数据库建模的现实世界中机构的信息。
    最常用的方法是使用函数依赖(functional dependency)。

    一个不好的设计可能会包括如下不良特性:
    信息重复。
    缺乏表达某些信息的能力。

    数据存储和查询

    数据库系统的功能部件大致可分为存储管理器和查询处理部件。

    存储管理器

    存储管理器是数据库系统中复杂在数据库中存储的底层数据域应用程序以及向系统提交的查询之间提供接口的部件。
    存储管理器复杂数据库中数据的存储、检索和更新。

    存储管理部件包括:

    权限及完整性管理器(authorization and integrity manager),它检测是否满足完整性约束,并检查试图访问数据的用户的权限。

    事务管理器(transaction manager),它保证即使发生了故障,数据库也保持在一致的(正确的)状态,并保证并发事务的执行不发生冲突。

    文件管理器(file manager),它管理磁盘存储空间的分配,管理用于表示磁盘上所存储信息的数据结构。

    缓冲区管理器(buffer manager),它负责将数据从磁盘上取到内存中来,并决定哪些数据应被缓冲存储在内存中。

    数据文件(data files),存储数据库自身。

    数据字典(data dictionary),存储关于数据库结构的元数据,尤其是数据库模式。

    索引(index),提供对数据项的快速访问。

    查询处理器

    查询处理器组件包括:

    DDL解释器(DDL interpreter),它解释DDL语句并将这些定于记录在数据字典中。

    DML编译器(DML compiler),将查询语言中的DML语句翻译为一个执行方案,包括一系列查询执行引擎能理解的低级指令。

    查询执行引擎(query optimization),执行由DML编译器产生的低级指令。

    事务管理

    事务(transaction)是数据库用于中完成单一逻辑功能的操作集合。
    每一个事务是一个既具有原子性又具有一致性的单元。

    原子性和持久性的保证是数据库系统吱声的职责,确切地说,是恢复管理器(recovery manager)的职责。

    故障恢复(failure recovery),即检测系统故障并将数据库恢复到故障发生以前的状态。

    并发控制管理器(concurrency-control manager)控制并发事务间的相互影响,保证数据库一致性。

    事务管理器(transaction manager)包括并发控制管理器和恢复管理器。

    数据库体系结构

    系统体系结构
    在这里插入图片描述
    两层和三层体系结构
    在这里插入图片描述

    数据库挖掘与信息检索

    数据挖掘指半自动地分析大型数据库并从中找出有用的模式的过程。
    数据库中发现的某些类型的知识可用一套规则来表示。
    查询非结构化的文本数据称为信息检索。

    特种数据库

    基于对象的数据模型

    对象-关系数据模型(object-relational data model),这是一个将面向对象数据模型和关系数据模型的特定结合在一起的数据模型。
    它扩展了传统的关系模型,增加了新的特征如结构和集合类型,以及面向对象特性。

    半结构化数据模型

    半结构化数据模型允许相同类型的数据项有不同的属性集的数据说明。

    数据库用户和管理员

    数据库用户和用户界面

    • 无经验用户 是默认经验的用户,他们通过激活事先已经写好的应用程序同系统进行交互。
    • 应用程序员 是编写应用程序的计算机专业人员。
    • 老练的用户 不通过编写程序来同系统交互,而是用数据库查询语言或数据分析软件这样的工具来表达他们的要求。
    • 专门的用户 是编写专门的、不适合与传统数据处理框架的数据库应用的富有经验的用户。

    数据库管理员

    使用DBMS一个原因是可对数据和访问这些数据的程序集中控制。
    对系统集中控制的人称作数据库管理员(DataBase Administrator, DBA)。

    DBA的作用包括:

    • 模式定义(schema definition)。DBA通过用DDL书写的一系列定义来创建最初的数据库模式。

    • 存储结构及存取方法定义(storage structure and sccess-method definition)。

    • 模式及物理组织修改(schema and physical-organization modification)。由数据库管理员(DBA)对模式和物理组织进行修改,以反映机构的需求变化,或为提高性能选择不同的物理组织。

    • 数据访问授权(granting of authorization for data access)。通过授予不同类型的权限,数据库管理员可以规定不同的用户各自可以访问的数据库部分。

    • 日常维护(routine maintenance)。数据库管理员的日常维护活动有:

        定期备份数据库
        确保正常运转时所需的空余磁盘空间,需要时升级磁盘空间
        监视数据库运行,保证不因个别用户而导致整体性能下降
      

    学习参考资料:

    《数据库系统概念》第6版
    
    展开全文
  • 信用卡还款系统

    2018-08-15 18:22:16
    就是写的信用卡还款,用jsp和微软的数据库写的文文件啊
  • 随着全球知识经济和电子商务的迅速发展,企业数据成为企业的生命。同时,数据库的应用也十分广泛,深入到...因此,如何有效地保证数据库系统的安全,实现数据的保密性、完整性和有效性,已经成为企业不得不关注的问题。
  • 详细设计主要包括系统数据库访问的实现,主要功能模块的具体实现,模块实现关键代码等。最后对系统进行功能测试,并对测试结果进行分析总结。 包括程序毕设程序源代码一份,数据库一份,完美运行。
  • 关系型数据库(RDBMS)起初是为了最大化利用昂贵的存储而设计的,不过它现在已经真正成为具有高效和稳定事务处理能力的系统。例如,关系型数据在大规模信用卡事务处理和循环计费操作方面都具有优势。它在索引数据...
  • ClickHouse是一个用于联机分析 (OLAP)的列式数据库管理系统(DBMS),来自于俄罗斯本土搜索引擎企业 Yandex 公司,是为世界第二大web分析平台(Yandex.Metrica)所开发2016年开源,开发语言是C++,是一款PB级的交互式...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 33,785
精华内容 13,514
关键字:

信用数据库查询系统