資料庫課程設計報告

一、什麼是資料庫

資料庫是“按照資料結構來組織、儲存和管理資料的倉庫”。是一個長期儲存在計算機內的、有組織的、可共享的、統一管理的大量資料的集合。

二、資料庫的定義

資料庫是存放資料的倉庫。它的儲存空間很大，可以存放百萬條、千萬條、上億條資料。但是資料庫並不是隨意地將資料進行存放，是有一定的規則的，否則查詢的效率會很低。當今世界是一個充滿著資料的網際網路世界，充斥著大量的資料。即這個網際網路世界就是資料世界。資料的來源有很多，比如出行記錄、消費記錄、瀏覽的網頁、傳送的訊息等等。除了文字型別的資料，影象、音樂、聲音都是資料。

三、資料庫課程設計報告

隨著個人素質的提升，報告的使用成為日常生活的常態，不同的報告內容同樣也是不同的。你知道怎樣寫報告才能寫的好嗎？下面是小編收集整理的資料庫課程設計報告，僅供參考，大家一起來看看吧。

資料庫課程設計報告1

一、緒論

隨著計算機技術的飛速發展和經濟體制改革的不斷深入，傳統企業管理方法、手段以及工作效率已不能適應新的發展需要，無法很好地完成員工工資管理工作。提高公司企業管理水平的主要途徑是更新管理者的思想，增強對管理活動的科學認識。基於 SQL server資料庫技術建立一個通用工資管理系統，該系統為提供了查詢、增加記錄、刪除等功能，功能比較的齊全，並對工資進行了統計如津貼管理、報表統計等。基本上能滿足管理員和公司的要求。

此次資料庫課程設計的主要設計如下：

原理分析、程式設計過程、程式實現和程式除錯以及資料庫的設計。

需求分析、概要結構設計、邏輯結構設計、物理結構設計和資料庫的實施和維護。

二、員工薪資管理系統概述

1、現狀分析

隨著企業人員數量增加，企業的工資管理工作也變得越來越複雜。早期的工資統計和發放都是使用人工方式處理紙質材料，不僅花費財務人員大量的時間且不易儲存，往往由於個人的因素抄寫不慎或計算疏忽，出現工資發放錯誤的現象。早期工資管理多采取紙質材料和具有較強的時間限制。隨著我國國民經濟建設

的蓬勃發展和具有中國特色的社會主義市場經濟體制的迅速完善，各個行業都在積極使用現代化的手段，不斷改善服務質量，提高工作效率，這些都在很大程度上給企業提出越來越嚴峻的挑戰，對企業體系無論是在行政職能、企業管理水平以及優質服務上都提出更高的要求。建設一個科學高效的資訊管理系統是解決這一問題的必由之路。企業內部財務管理是該企業運用現代化技術創造更多更高的經濟效益的主要因素之一。工資管理作為企業內部的一種財務管理也是如此，由於企業職工人數較多，每一位職工的具體實際情況也不盡相同，各項工資條款的發放，如果沒有一個完整的管理系統對企業和員工的工作都帶來許多的不便。基於以上原因，企業工資管理系統使用電腦安全儲存、快速計算、全面統計，實現工資管理的系統化、規範化、自動化。

2、系統目標

員工薪資管理系統的主要目的是利用計算機對員工的各種工資資訊進行日常的管理，如查詢、修改、新增、刪除以及儲存等，迅速準確地完成各種工資資訊的統計計算和彙總工作，針對系統服務物件的具體要求，設計了企業工資管理系統。企業工資管理系統主要有以下幾大功能：

(1)對單位人員的變動進行處理。一個單位的職工不會是一成不變的，總是在不斷的變化：有調出、有調入、也有職工在本單位內部調動。因此，設計系統是應考慮到這些情況。

(2)對職工的工資進行計算、修改。可以對職工的工資檔案進

行個別、部分和批量修改，同時，能對各職工的工資進行計算，即計算基本工資、崗位工資及實發金額等。

(3)查詢統計功能。要求即可以單項查詢，比如檢視某個職工的工資情況等；也可以多項查詢，比如某個部門所有的員工的工資資訊。

（4）對使用者管理功能。一個系統的應用有管理員和普通使用者，他們對系統的許可權受到限制。

3、系統特點

(1) 本系統使工資管理基本實現了資訊化，系統設計的各種查詢要求代替了原來了人工查詢，即節省了人力，又減輕了員工的工作量，最重要的是由計算機操作，可以提高資料的準確性，避免人為的錯誤，方便管理。

(2) 本系統設定了系統資料備份功能，定期的系統備份可以在資料庫受到意外的或有意的破壞的情況下，系統得以恢復，減少損失。

(3) 本系統的介面設計簡潔明瞭，採用了流行的選單設計，對於不是計算機專業的管理人員，只需閱讀操作說明書，就能方便的使用本系統。

資料庫課程設計報告2

有關於資料庫實驗的心得體會，總的來說，受益匪淺。在這些天中，我們學到了很多東西，包括建表，匯入資料，查詢，插入。最重要的是我們有機會用電腦自己進行實踐，沒接觸的時候總是覺得它比較深奧或是不可接近的新型語言，儘管自己對C語言非常感興趣，但還是有些心理上的陌生感。學習資料庫就和我們平時的其它科目學習一樣感覺它有永無止境的知識，資料庫是我在高中時候聽過，到了大學漸漸瞭解了些，但就其原理性的內容還不知道，也就是根本就不清楚什麼是資料庫，只是知道一個所謂的中國字典裡的名詞。我認識它是從我接觸實驗運作開始的，剛開始就是建立資料庫，兩種驗證模式，沒什麼東西但還覺得不錯。進而就是操作語言了，緊接著就是觸發器的使用，進而對資料庫高階的使用，等等。 開始知道資料庫的時候想學，不知道從何而起，不懂的話怎麼問，從什麼地方學起。後來到大三開學後有資料庫原理必修課，非常高興。當時感覺SQL Sever資料庫管理既然是單獨一門課程一定會講的.比較細，也能學到真正實用的內容。學了這門課以後發現和我想的基本是一樣的，老師對學生也比較和藹可親，對我們要求也不是很緊。讓每個人都覺得輕輕鬆鬆就能把這門課程學完，沒有多麼緊張的作業，也沒有太苛刻的要求。

當老師在最後說這個課程結束了，回顧一下以前老師給我們講過的東西，真的有很多是我們應該去注意的。學習完SQL Sever資料庫後感覺可分兩大塊，一塊是開發，一塊是管理。開發主要是寫寫儲存過程、觸發器什麼的，還有就是用Oracle的Develop工具做form。有點類似於程式設計師。開發還需要有較強的邏輯思維和創造能力，自己沒有真正做過，但感覺應該會比較辛苦，是青春飯；管理則需要對SQL Sever資料庫的原理有深刻的認識，有全域性操縱的能力和緊密的思維，責任較大，因為一個小的失誤就會弄掉整個資料庫，相對前者來說，後者更看重經驗。這些東西都是從老師哪裡和朋友的討論中得到的心得，也希望其他朋友能多多向老師和朋友請教，如果是個人單獨靠自己來完成一個完美的資料庫我覺得比較困難，現在基本上都是團隊型別的，而且他們的效率高開發的週期也快。由於資料庫管理的責任重大，很少公司願意請一個剛剛接觸SQL Sever的人去管理資料庫。對於我們這些初出茅廬的新手而且電子商務的專業，個人認為可以先選擇做管理，有一定經驗後轉型，去做資料庫的開發。當然，這個還是要看人個的實際情況來定。

SQL Server資料庫的實驗學習使我對資料庫的有了新的進步，以後再看到也就不至於什麼也不懂，其實那麼多資料庫我覺得學好一門就行，只是他們的語言可能不大一樣，學好一門後就可去認識其它的，這樣應該有事半功倍的效果。就像我學習C語言，當時不能說是學習的棒，但不算差。所以我對以後的語言感覺都不是很困難，瞭解了VB、C++還有網頁中用的Html語言、asp語言都能看懂，起碼可以對別人的東西進行了一下修改。因此，我感謝資料庫老師給了我有用的知識，以便我在以後學習或認識更多的內容能有新的方法和思維，也能更加有效和快速的去消化吸收新的東西。希望在今後中，SQL Server能給我更多幫助。感謝學校開設這樣一門優秀使用的課程，讓我對資料庫有了更深的瞭解。

資料庫課程設計報告3

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

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

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

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

1、使用了新的開發環境(Vim)，這是首次在脫離高階IDE的情況下編碼。

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

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

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

5、客觀原因在這裡就不說了。

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