数据库课程设计实验报告

数据库课程设计实验报告

　　导语：通过本课程设计，培养学生具有C/S模式的数据库应用软件系统的设计和开发能力。以下是小编为大家整理的数据库课程设计实验报告，欢迎大家阅读与借鉴！

　　数据库课程设计实验报告（1）

　　有关于数据库实验的心得体会，总的来说，受益匪浅。在这些天中，我们学到了很多东西，包括建表，导入数据，查询，插入。最重要的是我们有机会用电脑自己进行实践，没接触的时候总是觉得它比较深奥或是不可接近的新型语言，尽管自己对C语言非常感兴趣，但还是有些心理上的陌生感。学习数据库就和我们平时的其它科目学习一样感觉它有永无止境的知识，数据库是我在高中时候听过，到了大学渐渐了解了些，但就其原理性的内容还不知道，也就是根本就不清楚什么是数据库，只是知道一个所谓的中国字典里的名词。我认识它是从我接触实验运作开始的，刚开始就是建立数据库，两种验证模式，没什么东西但还觉得不错。进而就是操作语言了，紧接着就是触发器的使用，进而对数据库高级的使用，等等。 开始知道数据库的时候想学，不知道从何而起，不懂的话怎么问，从什么地方学起。后来到大三开学后有数据库原理必修课，非常高兴。当时感觉SQL Sever数据库管理既然是单独一门课程一定会讲的比较细，也能学到真正实用的内容。学了这门课以后发现和我想的基本是一样的，老师对学生也比较和蔼可亲，对我们要求也不是很紧。让每个人都觉得轻轻松松就能把这门课程学完，没有多么紧张的作业，也没有太苛刻的要求。

　　当老师在最后说这个课程结束了，回顾一下以前老师给我们讲过的东西，真的有很多是我们应该去注意的。学习完SQL Sever数据库后感觉可分两大块，一块是开发，一块是管理。开发主要是写写存储过程、触发器什么的，还有就是用Oracle的Develop工具做form。有点类似于程序员。开发还需要有较强的逻辑思维和创造能力，自己没有真正做过，但感觉应该会比较辛苦，是青春饭；管理则需要对SQL Sever数据库的原理有深刻的认识，有全局操纵的能力和紧密的`思维，责任较大，因为一个小的失误就会弄掉整个数据库，相对前者来说，后者更看重经验。这些东西都是从老师哪里和朋友的讨论中得到的心得，也希望其他朋友能多多向老师和朋友请教，如果是个人单独靠自己来完成一个完美的数据库我觉得比较困难，现在基本上都是团队类型的，而且他们的效率高开发的周期也快。由于数据库管理的责任重大，很少公司愿意请一个刚刚接触SQL Sever的人去管理数据库。对于我们这些初出茅庐的新手而且电子商务的专业，个人认为可以先选择做管理，有一定经验后转型，去做数据库的开发。当然，这个还是要看人个的实际情况来定。

　　SQL Server数据库的实验学习使我对数据库的有了新的进步，以后再看到也就不至于什么也不懂，其实那么多数据库我觉得学好一门就行，只是他们的语言可能不大一样，学好一门后就可去认识其它的，这样应该有事半功倍的效果。就像我学习C语言，当时不能说是学习的棒，但不算差。所以我对以后的语言感觉都不是很困难，了解了VB、C++还有网页中用的Html语言、asp语言都能看懂，起码可以对别人的东西进行了一下修改。因此，我感谢数据库老师给了我有用的知识，以便我在以后学习或认识更多的内容能有新的方法和思维，也能更加有效和快速的去消化吸收新的东西。希望在今后中，SQL Server能给我更多帮助。感谢学校开设这样一门优秀使用的课程，让我对数据库有了更深的了解。

　　数据库课程设计实验报告（2）

　　由于平时接触的都是一些私人项目，这些项目大都是一些类库，其他人的交流相对可以忽略不计，因此也就不考虑规范化的文档。实际上从学习的经历来看，我们接触的知识体系都是属于比较老或比较传统的，与现在发展迅速的IT行业相比很多情况已不再适用，尤其是当开源模式逐渐走近开发者后更是如此。

　　虽然这次是一个数据库课程设计，由于本人在选择项目的时候是本着对自己有实际应用价值的角度考虑的，所以其中也涉及到一些数据库以外的设计。对于OOA/OOD的开发模式有时不免要提出一些疑问，UML是设计阶段的工具，而它基本涵盖了软件设计的方方面面，也就是说按照这一软件工程的正常流程，在动手写第一句代码之前，开发人员已经非常熟悉软件产品了，这对于相当有经验的架构师一类人说可能会很容易，但是我们作为学生，连足够的'编码经验都没有，却首先被教授并要求先OOA再OOP，这样直接导致的问题就是文档与编码对不上号，在修改代码的时候基本不会再去审查文档和先前的分析。甚至根本就是现有代码再有文档，即便是这种情况，代码与文档还是不对应。不可否认，在传统软件工程的详细设计之前的项目过程中还是有很多利于项目开发的部分的。所以我就一直在寻找适合我——针对探究型项目——的开发模式，这次的项目也算是一次尝试，当然这个过程并不会太短。

　　回到数据库设计上了，这次的数据库设计我是严格按照数据库建模的步骤来进行的，老实说我并没有感觉这样的流程对开发带来多大的帮助，反倒是觉得将思维转化为图表很浪费时间。总体上来说这次的项目也不是很大，而且在数据库的设计上比较保守，也就是说实际上数据库设计还可以再完善完善的。随着我对计算机领域的拓宽和加深，我也会静下心来思考在接触计算机之前的行为，很多次我能深切感觉到，其实我的大脑(未于别人比较)本身就是在使用一种更接近关系数据库的方式来记忆，所以我很可恨自然的设计出符合三范式的表结构来，即便我不知道这些范式的确切含义。可能就像“范式不太容易用通俗易懂的方式解释”一样，在“让工具用图标表述我的思维”时费了一番力气。

　　从我作为项目的提出人和实现者来看，这是个失败的项目，结合几次教学项目的的实践，发现这也已经不是第一次了。主观原因占多数，比如，尝试新的开发方式，根据设计花了太多的时间来抽象出公用的库而忽略业务逻辑。就这次项目而言，失败的原因有以下几点：

　　1、使用了新的开发环境(Vim)，这是首次在脱离高级IDE的情况下编码。

　　2、使用了新的开发语言(Python，Actionscript3)，因为我一直比较喜欢“学以致用”，而且这样的“数据驱动型”软件的整套自实现的库都已经完成了，但是由于语言本身的差异，迁移时问题很多，当发现这一点是，已没有多少有效剩余时间了。

　　3、编码流程的不妥，我比较喜欢从底层的库开始开发，因为一旦库测试通过，将很容易将它放到不同的表示层下。但如果库没有测试成功，将导致整个项目没有任何可视化模型，所以这次的项目无法提交“可运行的代码”。

　　4、实践目的的不同，我轻易不放弃锻炼的机会，事实上，有机会就一定要比以前有所突破，总是照搬以前的做法还不如就不做呢。这个前提是因为现在能完全用来的学习的时间比较多，等到工作时再这样做的可能性就很小了，因此当然要抓紧机会了。不过还有一个隐藏原因，总以为自己很了不起，其实“遇到的问题数跟人的能力是成正比的”。

　　5、客观原因在这里就不说了。

　　由于项目还未完成，暂时无法提出需要改进了地方。