心得體會是指一種讀書、實踐后所寫的感受性文字。那么心得體會該怎么寫？想必這讓大家都很苦惱吧。以下我給大家整理了一些優質的心得體會范文，希望對大家能夠有所幫助。

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

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

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

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

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

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

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

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

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

不管做什么，我們都要相信自己，不能畏懼，不能怕遇到困難，什么都需要去嘗試，有些你開始認為很難的事在你嘗試之后你可能會發現原來她并沒有你以前覺得的那樣，自己也

是可以的。如果沒有自信，沒有目標，沒有信心就不可能把事情做好，當其他人都在迷茫的時候，自己一定要堅信目標，大學畢業出去即面臨找工作，從學習這個專業，到以后從事這方面的工作都需要不斷地去學習去實踐，這次實踐可以給我們敲一個警鐘，我們面臨畢業，面臨擇業，需要這些實踐經驗，在困難面前要勇于嘗試，這是這次課程設計給我的最大感想！

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

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

今天進行了一次完整的數據庫設計的過程，其實一直來說我都是非常害怕數據庫的設計的，因為在剛剛接觸的時候，我就知道，數據庫設計其實是一個項目的開端，因為數據庫設計實際上就是業務的設計，在需求清晰的時候，完成清晰流暢的業務設計又是一大難點。

一下為我自己的心得經驗希望大家批評指正！

數據庫設計應該遵循以下幾個原則：

對需求的認知完全沒有歧義；

熟練而且正確的e-r圖繪制，明確改圖是表明實體和關系的圖，實體表示要在數據庫里保存的類，關系表示類與類之間的相互關系，關系主要有一對一，一對多，多對多。經驗之談，繼承關系通常可以用一對一表示，而一對多或者多對多通常表示類之間的使用關系；

在設計時要做到高度的抽象，對內容或者關系相類似的內容抽象為一類實體，在分類時可以抽象出一個“類”的實體，與要分類實體之間進行多對多關系映射，明確哪些是必須要進行存儲的實體；

如果系統涉及用戶角色的不同不妨把，賬戶和身份的考慮分離開，賬戶的存在讓他是一直存在的并且在身份變化時個人的歷史和基礎內容是不變的，就是身份的加持讓他可以有特權或者使命，而賬戶是他在系統中的根；

對于有值內容，并且需要對值進行統計結果的需要對他進行內容的拆分，比如：問卷表和問卷內容表，問卷內容值表要拆開，才有利于統計計算，而且他們之間是一對多關系；

有時更加困難的是一個實體會發生多個維度的分類，那么就把他的拆分維度一一分開；

“頻道”概念在消息分發時是一個非常靈活的概念；

數據庫可以建表來模擬消息服務器分發消息，在無法保證實時性必須存儲內容時，同一消息對不同用戶創建不同的副本；

總結，其實我在今天的數據庫設計中就學習到這些，學習是一個逐漸進步的過程，也是一個自我折磨的過程，希望我可以在這條路上走的再遠一點。