閱讀屋>資料庫作業系統> 資料庫課程設計實驗報告

資料庫課程設計實驗報告

資料庫課程設計實驗報告

  導語:透過本課程設計,培養學生具有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、客觀原因在這裡就不說了。

  由於專案還未完成,暫時無法提出需要改進了地方。

【資料庫課程設計實驗報告】相關文章: