数据库实训心得体会(优质4篇)
通过数据库实训,掌握了数据管理与查询技巧,增强了对数据库设计的理解,提高了实践操作能力,为未来工作打下坚实基础。以下是小编为大家整理分享的数据库实训心得体会相关内容,供您学习参考!
数据库实训心得体会【第一篇】
关系型数据库,是指采用了关系模型来组织数据的数据库。
关系模型是在1970年由IBM的研究员博士首先提出的,在之后的几十年中,关系模型的概念得到了充分的发展并逐渐成为主流数据库结构的主流模型。
简单来说,关系模型指的就是二维表格模型,而一个关系型数据库就是由二维表及其之间的联系所组成的一个数据组织。
关系模型中常用的概念:
关系:可以理解为一张二维表,每个关系都具有一个关系名,就是通常说的表名
元组:可以理解为二维表中的一行,在数据库中经常被称为记录
属性:可以理解为二维表中的一列,在数据库中经常被称为字段
域:属性的取值范围,也就是数据库中某一列的取值限制
关键字:一组可以唯一标识元组的属性,数据库中常称为主键,由一个或多个列组成
关系模式:指对关系的描述。其格式为:关系名(属性1,属性2,...... ,属性N),在数据库中成为表结构
关系型数据库的优点:
容易理解:二维表结构是非常贴近逻辑世界的一个概念,关系模型相对网状、层次等其他模型来说更容易理解
使用方便:通用的SQL语言使得操作关系型数据库非常方便
易于维护:丰富的完整性(实体完整性、参照完整性和用户定义的完整性)大大减低了数据冗余和数据不一致的概率
数据库实训心得体会【第二篇】
高并发读写需求
网站的用户并发性非常高,往往达到每秒上万次读写请求,对于传统关系型数据库来说,硬盘I/O是一个很大的瓶颈
海量数据的高效率读写
网站每天产生的数据量是巨大的,对于关系型数据库来说,在一张包含海量数据的表中查询,效率是非常低的
高扩展性和可用性
在基于web的结构当中,数据库是最难进行横向扩展的,当一个应用系统的用户量和访问量与日俱增的时候,数据库却没有办法像webserver和appserver那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说,对数据库系统进行升级和扩展是非常痛苦的事情,往往需要停机维护和数据迁移。
对网站来说,关系型数据库的很多特性不再需要了:
事务一致性
关系型数据库在对事物一致性的维护中有很大的开销,而现在很多系统对事物的读写一致性都不高
读写实时性
对关系数据库来说,插入一条数据之后立刻查询,是肯定可以读出这条数据的,但是对于很多web应用来说,并不要求这么高的实时性,比如发一条消息之后,过几秒乃至十几秒之后才看到这条动态是完全可以接受的
复杂SQL,特别是多表关联查询
任何大数据量的web系统,都非常忌讳多个大表的关联查询,以及复杂的数据分析类型的复杂SQL报表查询,特别是SNS类型的网站,从需求以及产品阶级角度,就避免了这种情况的产生。往往更多的只是单表的主键查询,以及单表的简单条件分页查询,SQL的功能极大的弱化了
在关系型数据库中,导致性能欠佳的最主要原因是多表的关联查询,以及复杂的数据分析类型的复杂SQL报表查询。为了保证数据库的ACID特性,我们必须尽量按照其要求的范式进行设计,关系型数据库中的表都是存储一个格式化的数据结构。每个元组字段的组成都是一样,即使不是每个元组都需要所有的字段,但数据库会为每个元组分配所有的字段,这样的结构可以便于标语表之间进行链接等操作,但从另一个角度来说它也是关系型数据库性能瓶颈的一个因素。
数据库实训心得体会【第三篇】
一个月的数据库实训就转眼间就上完了,期间讲解了一个学生管理系统,最后还做了一个小的数据库链接作业。现在就说说关于vb链接的数据库的一些方法。
首先说数据库,简单的说就是建表格,然后把一张一张的表格和在一起,成为一大堆的数据集合。他是依照某种数据结构组织起来并存放二级存储器中的数据集合,基本分为三个层次,物理数据层,概念数据层和逻辑数据层。不同层次间的联系是通过映射来转换的。
大多数vb链接数据库都使用ado控件,他可以分为分为有源数据库和无源数据库,即是否使用了dsn数据源。在连接数据库前首先要在vb菜单中“工程”-“引用”或“部件”从中选择 microsoft activex data objects library和 microsoft activex data objects recordset 两个组件,然后定义链接的对象,用什么名字由自己决定。这样数据库也就基本上链接好了。
数据库实训心得体会【第四篇】
持续一个月的数据库实训,让我参与了软件工程化的开发过程。其中体会最深的便是我们这个实训网的几个之最:
一.项目最大:项目大是因为我们这个事业起点网站涉及到用户众多-高校,企业,学生,老师,专家,第二个原因是网站的功能多-用户管理,网上实习,网上竞赛,毕业实习设计,项目管理,人才库管理,人才推荐,搜索 ... 项目大很容易造成系统范围的泛滥,在我们的开发初期,由于需求不太明确,功能实现没有重点,造成了需求范围的扩大,给项目开发进度造成了严重的滞后性。然后我们召开了会议讨论了这个问题,一致认同先把项目的基本功能实现,将网站的基本架构搭建起来,最后再在这个基础上继续增加我们网站的其他功能。因此在这个过程中,我深刻体会到了软件工程初期阶段的需求分析以及概要设计的重要性,这两个文档是指导我们后期开发的最重要的依据。
二.数据库表最多:如此庞大的系统,就需要庞大的数据库来支持,所以项目大的直接后果就是我们的数据库表特别多,而且表与表之间的依赖关系也复杂,实体类之间的关系众多,设计起来有一定的难度。数据库的另外一个问题是-数据表的属性,数据表属性的设计完全是依赖于我们刚开始做的需求分析文档,如果需求分析不完整的话,就会造成数据库表属性的缺失,从用户的角度看,就会觉得你的系统提供的数据不够全面,信息量小。
三.开发团队最大:我们团队一共有十四个人,这个对于我们的项目经理来说,是一个相当严峻的问题,毕竟十四个人的团队相当于其他几个小组加起来的人数总和,管理起来有相当大的难度。对于我们这些小组成员来说,由于沟通渠道太多,造成了我们项目中遇到问题,不知道去跟哪个小组成员沟通。为了解决这个问题,我们在团队中又选出了三个小组长,小组成员遇到问题,先去咨询小组长,然后小组长提供反馈信息。
四.项目各个模块间藕合度高:网站涉及的各个功能模块之间的联系紧密,模块之间的接口设计的好坏是项目最终集成成功与否的最重要因素。用户管理这一个部分要为每个模块提供接口,主要是用户的编号以及用户的类型等。每个页面之间的链接也是其中重要的模块接口。这个问题由于我们前期做好了充分的沟通以及按照概要设计中的接口说明去设计自己的模块,所以后期的模块整合没有遇到什么太大的不兼容性等问题。
接下来就谈谈我这一个月中的工作:
需求分析阶段:需求分析阶段我完成了网上竞赛模块的需求分析,其中遇到的主要问题是阅读材料后发现网上实习,网上竞赛,毕业设计指导这几个模块的功能是类似的,提取需求分析后不够明确,经过几次跟汤老师的交流后,确定了这几个模块之间的具体差别,网上竞赛模块的基本需求也大致确定了,网上竞赛模块的基本功能就是学生通过网站报名参加竞赛,企业审核通过后,专家对作品进行评分,排名。
概要设计阶段:在需求分析的基础上,对网上竞赛模块进行了比较具体的概要设计,流程图(IPO图以及用例图);这个阶段的主要难点是对网上竞赛业务流程的描述,如何实现学生报名,企业发布,专家评审的步骤操作,与及跟其他模块对该模块的限制。
数据库设计阶段:我负责整合初步数据库设计说明书,分配组员按照各自的功能模块的具体需求设计自己模块需要的数据表,然后对这些数据表进行整合。在这个过程中遇到的问题就是数据库实在是太大了,最后下来一共有30多张表,表与表之间的关系复杂,关联性大,需要设置的外键较多,很难将所有的属性字段给提取出来,属性的类型设置也是一个问题,采用数值型还是采用字符串性在数据库设计中尤为重要,因为在后台搜索方面,数值型比较快捷,而在数据显示方面,字符串型又有直接读出不用转换的好处。每个表的主键我们采用了用实体的编号去标记它,因为这样实体间关联起来会更加简单。数据库的设计关键是要对整个项目的整体的把握,并且要细化对每个实体类的具体属性要求。
详细设计阶段:我觉得是最重要的一个方面,一个完整的详细设计说明应该可以帮助程序员完成具体的实现,程序员可以不用考虑模块之间的耦合问题,只需要将单一的功能按照逻辑顺序编写出来就可以了。网站整体构架搭好了,我们就可以在里面填充自己的功能了。但是因为时间太仓促了,我们这个阶段也就缩水了,带来后面的问题就是后期代码编写的时候比较混乱,函数接口较难统,界面风格多样化。这个阶段,我的主要工作是跟队友一起设计出了网上竞赛模块的学生,企业,管理员,高校以及专家的界面。
编码阶段:我们是用开发的,主要任务就是从工具中选出你想要的控件,然后在控件响应函数中填充代码,完成相应的事件响应。这里遇到的最大问题是页面的排版问题,因为自己是第一次开发网站,造成了自己设计的界面风格单调,不太美观,现在就尽量做到页面的整齐。这个阶段主要做的就是:写代码→编译→调试→写代码。
这一个月中我学到了很多东西,技术方面就是学会了用编写网站,最重要的是让我经历了软件工程化的所有阶段,让我对整个软件工程有了感性的认识,而且将大学三年所学到的知识进行了一次系统的串联,更重要的是学会了如何跟项目团队中的成员沟通问题,这是一个宝贵的实践经验。