數據庫課程設計心得體會篇

時間：2020-11-26 10:47:18 學習心得體會

數據庫課程設計心得體會精選篇

　　課程培訓活動，四對于提高專業技能的一個很好的方式，下面由yjbys小編為大家帶來的數據庫課程設計心得體會精選范文，僅供參考~

數據庫課程設計心得體會精選篇

　　【數據庫課程設計心得體會一】

　　兩個星期的時間非常快就過去了，這兩個星期不敢說自己有多大的進步，獲得了多少知識，但起碼是了解了項目開發的部分過程。雖說上過數據庫上過管理信息系統等相關的課程，但是沒有親身經歷過相關的設計工作細節。這次實習證實提供了一個很好的機會。

　　通過這次課程設計發現這其中需要的很多知識我們沒有接觸過，去圖書館查資料的時候發現我們前邊所學到的僅僅是皮毛，還有很多需要我們掌握的東西我們根本不知道。同時也發現有很多已經學過的東西我們沒有理解到位，不能靈活運用于實際，不能很好的用來解決問題，這就需要我們不斷的大量的實踐，通過不斷的自學，不斷地發現問題，思考問題，進而解決問題。在這個過程中我們將深刻理解所學知識，同時也可以學到不少很實用的東西。

　　從各種文檔的閱讀到開始的需求分析、概念結構設計、邏輯結構設計、物理結構設計。親身體驗了一回系統的設計開發過程。很多東西書上寫的很清楚，貌似看著也很簡單，思路非常清晰。但真正需要自己想辦法去設計一個系統的時候才發現其中的難度。經常做到后面突然就發現自己一開始的設計有問題，然后又回去翻工，在各種反復中不斷完善自己的想法。

　　我想有這樣的問題不止我一個，事后想想是一開始著手做的時候下手過于輕快，或者說是根本不了解自己要做的這個系統是給誰用的。因為沒有事先做過仔細的用戶調查，不知道整個業務的流程，也不知道用戶需要什么功能就忙著開發，這是作為設計開發人員需要特別警惕避免的，不然會給后來的工作帶來很大的麻煩，甚至可能會需要全盤推倒重來。所以以后的課程設計要特別注意這一塊的設計。

　　按照要求，我們做的是機票預訂系統。說實話，我對這個是一無所知的，沒有訂過機票，也不知道航空公司是怎么一個流程。盲目開始設計的下場我已經嘗過了，結果就是出來一個四不像的設計方案，沒有什么實際用處。沒有前期的調查，僅從指導書上那幾條要求著手是不夠的。

　　在需求分析過程中，我們通過上網查資料，去圖書館查閱相關資料，結合我們的生活經驗，根據可行性研究的結果和客戶的要求，分析現有情況及問題，采用client/server結構，將機票預定系統劃分為兩個子系統：客戶端子系統，服務器端子系統。在兩周的時間里，不斷地對程序及各模塊進行修改、編譯、調試、運行，其間遇到很多問題：由于忘記了一些java語言的規范使得在調試過程中一些錯誤沒有發現，通過這次課程設計，我對調試掌握得更加熟練了，意識到了程序語言的規范性以及我們在編程時要有嚴謹的態度，同時在寫程序時如有一定量的注釋，既增加了程序的可讀性，也可以使自己在讀程序時更容易。

　　我們學習并應用了sql語言，對數據庫的創建、修改、刪除方法有了一定的了解，通過導入表和刪除表、更改表學會了對于表的一些操作，為了建立一個關系數據庫信息管理系統，必須得經過系統調研、需求分析、概念設計、邏輯設計、物理設計、系統調試、維護以及系統評價的一般過程，為畢業設計打下基礎。

　　很多事情不是想象中的那么簡單的，它涉及到的各種實體、屬性、數據流程、數據處理等等。很多時候感覺后面的設計根本無法繼續，感覺像是被前面做的各種圖限制了。在做關系模型轉換的時候碰到有些實體即可以認為是實體又可以作為屬性，為了避免冗余，盡量按照屬性處理了。

　　物理結構設計基本沒有碰到問題，這一塊和安全性、完整性不覺就會在物理結構設計中添加一些安全設置：主鍵約束、check約束、default定義等。最后才做索引的部分，對一些比較經常使用搜索的列，外鍵上建立索引，這樣可以明顯加快檢索的速度，最后別忘記重要的安全性設置，限制用戶訪問權限，新建用戶并和數據庫用戶做相應的映射。

　　不管做什么，我們都要相信自己，不能畏懼，不能怕遇到困難，什么都需要去嘗試，有些你開始認為很難的事在你嘗試之后你可能會發現原來她并沒有你以前覺得的那樣，自己也是可以的。如果沒有自信，沒有目標，沒有信心就不可能把事情做好，當其他人都在迷茫的時候，自己一定要堅信目標，大學畢業出去即面臨找工作，從學習這個專業，到以后從事這方面的工作都需要不斷地去學習去實踐，這次實踐可以給我們敲一個警鐘，我們面臨畢業，面臨擇業，需要這些實踐經驗，在困難面前要勇于嘗試，這是這次課程設計給我的最大感想!

　　以上基本是這次實習的體會了，設計進行的非常艱難，編碼非常不容易，才發現做一個項目最重要的不在于如何實現，而是實現之前的需求分析和模塊設計。創新很難，有些流行的系統其實現并不難，難的在于對市場的分析和準確定位。設計，是一個任重道遠的過程。

　　【數據庫課程設計心得體會二】

　　數據庫課程設計大賽的塵囂漸漸遠去，懷著對這次大賽的些許不舍，懷著對當初課程設計開始時候的豪情萬丈的決心的留戀，懷著通過這次課程設計積累的信心與斗志，我開始寫這篇文章，為自己的足跡留下哪怕是微不足道但是對自己彌足珍貴的痕跡并期望與大家共勉。

　　首先，讓我的記憶追溯到大二暑假，在老大的指引下(老大勸我學asp.net)，我接觸到microsoft 公司的.net產品。那個時候我已經學過vc和asp，因為windows程序設計實驗的課的關系，接觸過vb，但是沒有專門去學他，因為習慣了c++里面的class，int，覺得vb的sub，var 看著就不是很順心。我是一個好奇心很強的人，突然看到了一個號稱“.net是用于創建下一代應用程序的理想而又現實的開發工具”，而且主推c#語言，由于對c語言的一貫好感，我幾乎是立刻對他產生了興趣。我就開始了對c#的學習，任何語言都不是孤立存在的，所以數據交互是很重要的，暑假的時候我把我們這學期的課本數據庫系統概論看了一遍。我記得以前用c語言編程的時候，數據是在內存中申請空間，譬如使用數組等等。很耗費內存空間。這個時候就是數據庫站出來的時候啦，于是我又裝上了sql server2000，以前學asp的時候用的是access，那個時候只是照著人家做，理論是什么也不是很清楚。

　　通過一個暑假的學習，基本搞清楚了理論方面的東西，具體怎么用也不是很清楚。但是這為這學期的課程設計打下了鋪墊。

　　來到學校后，隨著這學期的數據庫課程大賽開始了，我有一個看法就是我自己應該具備的能力不是我會多少，而是我應該具備快速學會東西的能力。遇到什么就學什么。我們有時候很容易被一些專業名詞說嚇著，包括什么建模，軟件工程，數據分析，數據挖掘等等。我身邊就有很多同學被這些紙老虎所唬住，而沒有勇氣去接觸他們，總是說這個太難了之類的退堂鼓的話，他們低估了自己的潛力同時也壓抑住了他們自己的好奇心。其實都是紙老虎，又不是什么國家科研難題，只是去用一些工具，發明工具是很難，但是用一個工具就容易多了，just do it!我記得我做這個數據庫之前，我們老師說要做好前期分析，我就在網上搜索用什么分析工具好。最后我選擇了roseuml建模工具。在此之前，我腦袋里面沒有軟件建模的思想，什么uml建模對我而言就是一張空白的紙。但是真正接觸后并沒有想象的那么難，有什么不懂的上網去搜索，這是一個信息橫流的世界，有google，baidu就沒有不能解決的知識難題。以及后來的數據庫分析的時候用到的powerdesigner也是一樣。

　　開發的時候我想過用什么架構，c/s模式?模式有很多，怎么選擇?我就上網搜索現在最流行的架構是什么。結果搜到了mvc架構，就是你啦。我決定用這個架構，不會，沒關系，咱學。just do it!前期工作準備好后，那么我就得把我暑假學的.net加以實踐。這個時候我更加深入的了解了利用操縱數據庫的知識。并且對數據庫里面的存儲過程有了比較深入的了解。經過大概2個多星期的奮斗，我完成了我的數據庫課程設計--基于.net數據集的圖書館管理系統。并最后非常榮幸的獲得了大賽的一等獎以及以及新技術應用獎。

　　與其臨淵羨魚，不如退而結網。這次數據庫課程設計給我的最大的印象就是如果自己有了興趣，就動手去做，困難在你的勇氣和毅力下是抬不了頭的。從做這個數據庫開始無論遇到什么困難，我都沒有一絲的放棄的念頭。出于對知識的渴望，出于對新技術的好奇，出于對一切未知的求知。我完成了這次數據庫課程設計，不過這只是我學習路上的驛站，未來十年.net的核心技術就是xml[至少微軟是這么宣傳的]，我會繼續學習它，包括jave公司的j2ee我也很想試試，語言本來就是相通的，just do it!語言并不重要畢竟它僅僅是工具，用好一個工具并不是一件值得為外人道的事情，主要是了解學習思想。古語說的好：學無止境啊!

　　我很慶幸我參加了這次數據庫大賽，讓我確實打開了眼界。

　　【數據庫課程設計心得體會三】

　　由于平時接觸的都是一些私人項目，這些項目大都是一些類庫，其他人的交流相對可以忽略不計，因此也就不考慮規范化的文檔。實際上從學習的經歷來看，我們接觸的知識體系都是屬于比較老或比較傳統的，與現在發展迅速的it行業相比很多情況已不再適用，尤其是當開源模式逐漸走近開發者后更是如此。

　　雖然這次是一個數據庫課程設計，由于本人在選擇項目的時候是本著對自己有實際應用價值的`角度考慮的，所以其中也涉及到一些數據庫以外的設計。對于ooa/ood的開發模式有時不免要提出一些疑問，uml是設計階段的工具，而它基本涵蓋了軟件設計的方方面面，也就是說按照這一軟件工程的正常流程，在動手寫第一句代碼之前，開發人員已經非常熟悉軟件產品了，這對于相當有經驗的架構師一類人說可能會很容易，但是我們作為學生，連足夠的編碼經驗都沒有，卻首先被教授并要求先ooa再oop，這樣直接導致的問題就是文檔與編碼對不上號，在修改代碼的時候基本不會再去審查文檔和先前的分析。甚至根本就是現有代碼再有文檔，即便是這種情況，代碼與文檔還是不對應。不可否認，在傳統軟件工程的詳細設計之前的項目過程中還是有很多利于項目開發的部分的。所以我就一直在尋找適合我——針對探究型項目——的開發模式，這次的項目也算是一次嘗試，當然這個過程并不會太短。

　　回到數據庫設計上了，這次的數據庫設計我是嚴格按照數據庫建模的步驟來進行的，老實說我并沒有感覺這樣的流程對開發帶來多大的幫助，反倒是覺得將思維轉化為圖表很浪費時間。總體上來說這次的項目也不是很大，而且在數據庫的設計上比較保守，也就是說實際上數據庫設計還可以再完善完善的。隨著我對計算機領域的拓寬和加深，我也會靜下心來思考在接觸計算機之前的行為，很多次我能深切感覺到，其實我的大腦(未于別人比較)本身就是在使用一種更接近關系數據庫的方式來記憶，所以我很可恨自然的設計出符合三范式的表結構來，即便我不知道這些范式的確切含義。可能就像“范式不太容易用通俗易懂的方式解釋”一樣，在“讓工具用圖標表述我的思維”時費了一番力氣。

　　從我作為項目的提出人和實現者來看，這是個失敗的項目，結合幾次教學項目的的實踐，發現這也已經不是第一次了。主觀原因占多數，比如，嘗試新的開發方式，根據設計花了太多的時間來抽象出公用的庫而忽略業務邏輯。就這次項目而言，失敗的原因有以下幾點：

　　使用了新的開發環境(vim)，這是首次在脫離高級ide的情況下編碼。

　　使用了新的開發語言(python，actionscript3)，因為我一直比較喜歡“學以致用”，而且這樣的“數據驅動型”軟件的整套自實現的庫都已經完成了，但是由于語言本身的差異，遷移時問題很多，當發現這一點是，已沒有多少有效剩余時間了。

　　編碼流程的不妥，我比較喜歡從底層的庫開始開發，因為一旦庫測試通過，將很容易將它放到不同的表示層下。但如果庫沒有測試成功，將導致整個項目沒有任何可視化模型，所以這次的項目無法提交“可運行的代碼”。

　　實踐目的的不同，我輕易不放棄鍛煉的機會，事實上，有機會就一定要比以前有所突破，總是照搬以前的做法還不如就不做呢。這個前提是因為現在能完全用來的學習的時間比較多，等到工作時再這樣做的可能性就很小了，因此當然要抓緊機會了。不過還有一個隱藏原因，總以為自己很了不起，其實“遇到的問題數跟人的能力是成正比的”。

【數據庫課程設計心得體會精選篇】相關文章：

課程設計致謝04-08