① 書店銷售管理系統資料庫設計目的和意義
學號 1
課 程 設 計課程名稱 《資料庫系統原理》課程設計
題 目 書店銷售管理系統
專 業
班 級
姓 名
成 績
指 導 老 師
2019 年 12 月 30 日至 2019 年 1月 3日一、課程設計目的與任務《資料庫系統原理課程設計》是針對計算機專業基礎課《資料庫系統原理》開設的課程設計，目的是使學生通過本課程設計之後，對資料庫設計的基本概念、基本原理和優化技術有較全面的了解和領會，並能操作當前流行的DBMS，了解資料庫在計算機應用系統的作用，獨立地開發實現一個小型的基於DBMS上的應用系統。結合具體的開發案例，理解並初步掌握資料庫系統需求分析、概念結構設計、邏輯結構設計、物理結構設計、應用功能設計（視圖，索引，游標，存儲過程，觸發器等）數據錄入及測試等系統設計與系統實施及維護管理的主要環節和步驟以及軟體文檔的製作能力。二、課程設計的題目與基本要求1．設計題目：書店銷售管理系統資料庫設計2.基本要求：（1）圖書入庫管理：維護入庫圖書信息（如圖書編號、書名、作者、價格、圖書分類、出版社等），自動計算庫存。（2）圖書查詢統計：按圖書分類，出版社、書名、作者等條件查詢圖書的詳細信息。（3）銷售管理： 銷售過的圖書都記錄在銷售列表中，方便統計收入。圖書銷售後，實時記錄圖書庫存，按每天統計銷售額、按每個月或季度統計銷售額，並能根據銷售數量統計生成暢銷書名單。（4）設計報告內容包括：基本原理、設計方案的選擇與確定，詳細的設計過程及結果做出評價，分析存在的問題，提出改進意見並寫出心得體會。三、學時分配進度安排
序號 設計內容 所用時間
1 選題及調研 1天
2 資料庫結構設計 1天
3 資料庫查詢優化 1天
4 調試及撰寫報告 1天
5 答辯 1天
合 計 1周
四、課程設計考核及評分標准1.設計報告要求課程設計報告要求邏輯清晰、層次分明、書寫整潔。格式包括標題、提要、正文（包括①設計項目要求與說明。②數據模型分析。③軟體流程分析。④調試分析。⑤實驗數據分析。⑥答辯。⑦成績評定。）附錄(圖紙、程序清單或軟盤)。設計報告須每人一份，獨立完成。2.圖紙要求系統結構框圖、概念模型圖等。3.評分標准
評分依據 評分成績
1．設計方案正確，具有可行性、創新性 30分
2．資料庫測試性能達到任務書要求 25分
3．設計報告的規范化、內容充實、參考文獻 15分
4．答辯 20分
5．平時成績（考勤等） 10分
總分 100分
註：成績等級：優（90分—100分）、良（80分—89分）、中（70分—79分）、及格（60分—69分）、60分以下為不及格。五、指導時間
周次 星期一 星期二 星期三 星期四 星期五
第17周 第3-4節 第3-4節 第3-4節 第3-4節
地點 233 231 現教 現教
1.引言Internet的迅速發展正以前所未有的深度和廣度影響和改善著人類生活的各個方面，越來越多的人開始意識到Internet所起到的重大作用隨著書店規模的不斷擴大，員工人數的不斷增多，使得書店管理的手工操作管理模式的局限性越發突出.本書店管理系統應用了科學的管理模式對員工.書籍.訂單信息進行管理和維護，並且還提供了給類報表的列印,使原本非常復雜的手工管理變得簡潔明了。計算機信息管理技術的應用，除了能在相當大的程度.上代替人工作業，從而減少人員工作量，減輕工作負擔，減少工作中因人為原因而產生的錯誤從而避免不必要的損失外，更重要的是能建立准確暢通、簡便的信息流通渠道，為工作提供所需要的准確、及時的信息以幫助做出正確而及時的選擇與決定，從而給採用這門]技術的單位帶來了巨大的可見或不可見的利益與效益。2.需求階段分析2.1需求分析書店管理系統是適應時代發展的需要,提高管理的效率而開發設計的。通過對信息的收集、存儲、傳遞、統計、分析、綜合查詢、報表輸出和信息共享，及時為書店管理人員提供全面、准確的各種數據。實現了書店管理的簡單化和規劃化，提高了書店的工作效率，從而使書店能夠以少的投入獲得更好的社會效益與經濟效益。2.2數據分析顧客表：應包含顧客號，顧客姓名以及顧客聯系方式訂單表：應包含訂單號，銷售圖書號，銷售數量，金額以及日期圖書表：應包含圖書編號，圖書名，作者，單價，類別和出版社庫存表：應包含圖書編號，總量和餘量2.3功能分析資料庫應實現的功能有：（1）圖書入庫管理：維護入庫圖書信息（如圖書編號、書名、作者、價格、圖書分類、出版社等），自動計算庫存。（2）按圖書分類，出版社、書名、作者等條件查詢圖書的詳細信息。（3）銷售過的圖書都記錄，並且能顯示每種圖書的銷售量，將銷售量高的圖書定為熱銷書，能夠查詢出某一天到某一天的銷售額以及訂單消息2.3.1書籍管理功能系統設置包括圖書名稱設置、書籍編號、書籍出版社、書籍價格、書籍類別。基本信息管理模塊可以實現添加和重置書籍信息功能。
2.3.2訂單管理功能系統設置包括顧客姓名設置、訂單日期設置、訂單編號設置、訂單數量設置、訂單金額設置。基本信息管理模塊可以實現對訂單的查詢。2.3.3顧客管理功能系統設置包括顧客編號設置、顧客姓名設置、顧客聯系方式設置。基本信息管理模塊可以實現對顧客的查詢。2.3.4庫存管理功能系統設置包括圖書編號、圖書總量、圖書餘量設置。基本信息管理模塊可以實現對圖書數量的查詢2.4安全性和完整性要求（1）安全性要求 ：系統安全性要求體現在資料庫安全性、信息安全性和系統平台的安全性等方面。安全性先通過視圖機制，不同的用戶只能訪問系統授權的視圖，這樣可提供系統數據一定程度上的安全性，再通過分配許可權、設置許可權級別來區別對待不同操作者對資料庫的操作來提高資料庫的安全性；系統平台的安全性體現在操作系統的安全性、計算機系統的安全性和網路體系的安全性等方面。（2）完整性要求：系統完整性要求系統中數據的正確性以及相容性。可通過建立主、外鍵，使用check約束，或者通過使用觸發器和級聯更新。3 .結構設計3.1總體功能模塊圖圖3.13.2書籍信息模塊圖圖3.23.3訂單信息模塊圖圖3.33.4顧客信息模塊圖圖3.43.5數據字典表3.5.1顧客表
列名 數據類型 約束
顧客號（Gno） Char（7） primary key
姓名（Gname） Nchar（20） Not null
聯系方式（Gnumber） Char（20）
表3.5.2訂單表
列名 數據類型 約束
訂單號（Dno） Char（7） primary key
購買圖書號（Bno） Char（7） primary key
購買數量（Dshul） Int Not null
金額（Dmoney） Int Not null
日期（Dtime） Smalldatetime Not null
顧客號（Gno） Char（7） External code
表3.5.3 圖書表
列名 數據類型 約束
編號（Bno） Char（7） primary key
書名（Bname） nchar (20) not null
作者（Bwriter） nchar (20) not null
價格（Bjiage） Int not null
類別（Bleibie） nchar (20) not null
出版社（Bcbs） nchar (20) not null
表3.5.4庫存表
列名 數據類型 約束
編號（Bno） Char（7） Primary key
總量（Kzong） Int Not null
餘量（Kyu） Int
3.6 ER圖設計3.6..1顧客ER圖3.6.2 圖書ER圖圖3.6.3圖3.6.4圖3.6.54 邏輯結構設計4.1 關系模型顧客與訂單是1：m類型 訂單與庫存是1：1類型 庫存與圖書是1：m類型 關系模型如下：顧客表（顧客號、姓名、聯系方式）訂單表（訂單號、購買圖書號、購買數量、金額、日期、顧客號）圖書表（編號、書名、作者、價格、類別、出版社）庫存表（編號、總量、餘量）（——代表主鍵，...代表外碼）4.2 函數依賴在顧客表中，顧客號是主碼，其它屬性完全依賴於顧客號在訂單表中，訂單號是主碼，顧客號是外碼，其餘屬性完全依賴於訂單號在圖書表中，編號是主碼，其餘屬性完全依賴於編號在庫存表中，編號是主碼，其餘屬性完全依賴於編號5.物理結構設計5.1創建圖書表use books /*創建圖書表*/create table book(Bno char (7) primary key,Bname nchar (20) not null,Bwirter nchar (20) not null,Bjiage int not null,Bleibie nchar (20) not null,Bcbs nchar (20) not null,）5.2 創建顧客表use books /* 創建顧客表*/create table guke(Gno char(7) primary key,Gname nchar (20) not null,Gnumber char(20),）5.3創建庫存表use books /*創建庫存表*/Create table kucun(Bno char(7) primary key,
Kzong int not null,Kyu int,)5.4創建訂單表use books /*創建訂單表*/Create table Dingdan(Dno char(7) primary key,Bno char(7) primary key,Dshul int not null,Dmoney int not null,Dtime smalldatetime not null,Gno char(10) not null,)6 資料庫的實施6.1 給各個表添加數據例use books /*給圖書表添加一行數據*/insert into bookvalues('101','白夜行','東野圭吾','30','偵探','天空出版社')使用語句添加完數據的表如下：6.1.1圖書表6.1.2訂單表6.1.3 顧客表6.1.4庫存表6.2創建存儲過程6.2.1圖書的存儲過程create proc tushu@Bno char(7),@Bname nchar(20),@Bwirter nchar(20),@Bjiage int, @Bleibie nchar(20),@Bcbs nchar(20),@MM INTasif not exists (select * from bookwhere Bno=@Bno)BEGINinsert into bookvalues (@Bno,@Bname,@Bwirter,@Bjiage,@Bleibie,@Bcbs)INSERT INTO KucunVALUES (@Bno,@MM,@MM)ENDELSEBEGINUPDATE KucunSET Kzong=KZONG+@MMWHERE BNO=@BNOUPDATE KucunSET KYU=KYU+@MM
WHERE BNO=@BNOEND圖5.2.16.2.2顧客的存儲過程create proc gukecun@Gno char(7),@gname nchar(10),@gnumber nchar(20)asinsert into gukevalues (@Gno,@gname,@gnumber )圖5.2.26.2.3 訂單的存儲過程create proc dingdan@dno char(10),@Bno char(10),@Dshul int,@Dtime smalldatetime, @Gno char(10)asdeclare @Dmoney intselect @Dmoney=@Dshul*Bjiagefrom book,Dingdaninsert into Dingdanvalues (@dno,@Bno,@Dshul,@Dmoney,@Dtime,@Gno)圖5.2.36.3 創建觸發器針對圖書信息表創建一個觸發器，當向表book插入一條信息時，自動顯示表中book中的記錄create trigger 插入顯示on bookfor insertasSelect * from bookInsert into book values('115','幻想之城','中此撒','30','懸疑','颯颯我出版社')6.4 建立視圖6.4.1建立視圖建立一個圖書類別為偵探的視圖，包括圖書編號，圖書名，作者，單價以及圖書總量和餘量create view v_leibieasselect book.Bno ,bname,bwirter,bjiage,kzong,kyufrom book,Kucunwhere book.Bno =Kucun.Bno and Bleibie ='偵探'圖6.4.1圖6.4.26.5 調試運行6.5.1查詢姓張的顧客的購買記錄select * from Dingdan
where Gno in (select Gno from gukewhere Gname like '張%')圖6.5.16.5.2 添加一條圖書信息後圖書表以及庫存表的顯示exec tushu'115','幻想之城','中此撒','30','懸疑','颯颯我出版社','60'圖6.5.2圖6.5.36.5.3 查詢銷售量在10本以上的書，以此為暢銷書select SUM(dshul),bnofrom Dingdangroup by Bnohaving SUM(Dshul)>10圖6.5.46.5.4查詢某一天的銷售額select sum (Dmoney )總金額 from Dingdanwhere Dtime between '2019-11-01 'and '2019-11-02'圖6.5.57.設計體會一個個星期的時間非常快就過去了，這一個星期不敢說自己有多大的進步。獲得了多少如識，但起碼是了解了項目開發的部分過程。雖說上過資料庫的課程，但是沒有親身經歷過相關的設計工作細節。這次課程設計剛好提供了一個很好的機會。通過這次課程設計發現這其中需要的很多知識我們都接觸過，去圖書館查資料的時侯發現我們前邊所學到的僅僅是皮毛還有很多需要我們掌握的東西我們根本不知道。同時也發現有很多已經學過的東西我們沒有理解到位，不能靈活運用於實際，不能很好的用來解決問題，這就需要我們不斷的大量的實踐，通過不斷的自學，不斷地發現問題，思考問題，進而解決問題。在這個過程中我們將深刻理解所學知識，同時也可以學到不少很實用的東西。本次課程設計即將結束，我完成了自己所選的課題。通過完成這次課程設計，我加深了對相關知識的理解，加強了知識之間的聯吊，促進了知識的遷移和應用。從需求分析、概念結構設計、邏輯結構設計、物理結構設計。親身體驗了一回系統的設計開發過程。很多東西書上寫的很清楚，貌似看著也很簡單，思路非常清晰。但真正需要自己想辦法去設計一個系統的時候才發現其中的難度。經常做到後面突然就發現自己-開始的設計有問題，然後又回去翻工在各種反復中不斷完善自己的想法。
致謝在這次資料庫的課程設計過程中，我選擇了書店銷售管理系統的設計與實現。該系統能夠順利的完成，得益於老師的悉心指導和同學的幫助。更重要的是老師幫我們解決了許多技術的難題，以至於我們能夠將書店銷售管理系統的功能做得盡可能的完善。在這過程中，我周圍的同學給了我許多啟發，讓我把書店銷售管理系統設計的更加完善，老師淵博的知識、開闊的視野和敏銳的思維給了我深深的啟迪，使我不僅了解到許多新知識、開闊了視野，更提高了自身的資料庫設計能力。另外，感謝老師給我們提供這樣-一個課程設計的機會，使我們在學得專業知識的基礎上能夠自己動手並獨立地完成資料庫的設計與開發，使我們能夠更多的學習-些實踐應用知識，增強實際操作和動手應用能力。最後，我再一次感謝在整個課程設計期間，在各個方面給予我們幫助的老師和同學，正是因為有了你們的幫助，才使我們的課程設計得以順利完成。參考文獻[1]李彥，韓光林，李玉波. sql SERVE完全自學手冊[M].北京:電子工業出版社,2007[2]薩師煊，王珊.資料庫系統概論.北京:高等教育出版社.2005[3]Y.Daniel Liang.Java.萬波. JAVA語言程序設計[M].第六版.北京:機械工業出版社，2008[4]《資料庫原理及應用》 ，錢雪忠主編，北京郵電大學出版社，2007，第二版[5]《SQL server 2000數據倉庫與Analysis Services》，Bain T著 ，中國電力出版社， 2003[6]《資料庫技術與聯機分析處理》 王珊主編，北京科學出版社，1998課程設計成績評定表
課程設計題目 書店銷售管理系統
課程設計學生答辯或質疑記錄：
評 分 依 據 分 值 評分成績
1．設計方案正確，具有可行性、創新性 30 分
2．系統調試與結果（系統功能正確、軟體程序完整） 25分
3．設計報告的規范化、內容充實、參考文獻 15分
4．平時成績（考勤等） 10分
5．答辯 20分
總 分 100分
最終評定等級為：指導老師簽字： 年 月 日
￥
5.9
網路文庫VIP限時優惠現在開通,立享6億+VIP內容
立即獲取
書店銷售管理系統資料庫設計
學號 1
課 程 設 計
課程名稱 《資料庫系統原理》課程設計
題 目 書店銷售管理系統
專 業
班 級
姓 名
成 績
指 導 老 師
2019 年 12 月 30 日至 2019 年 1月 3日
一、課程設計目的與任務
第 1 頁
《資料庫系統原理課程設計》是針對計算機專業基礎課《資料庫系統原理》開設的課程設計，目的是使學生通過本課程設計之後，對資料庫設計的基本概念、基本原理和優化技術有較全面的了解和領會，並能操作當前流行的DBMS，了解資料庫在計算機應用系統的作用，獨立地開發實現一個小型的基於DBMS上的應用系統。結合具體的開發案例，理解並初步掌握資料庫系統需求分析、概念結構設計、邏輯結構設計、物理結構設計、應用功能設計（視圖，索引，游標，存儲過程，觸發器等）數據錄入及測試等系統設計與系統實施及維護管理的主要環節和步驟以及軟體文檔的製作能力。
② 請大夥給我解釋一下資料庫設計的基本原則！
資料庫設計的三範式所謂範式，是關系型資料庫關系模式規范化的標准，從規范化的寬松到嚴格，分別為不同的範式，通常使用的有第一範式、第二範式、第三範式及BC範式等。範式是建立在函數依賴基礎上的。
函數依賴
定義：設有關系模式R(U)，X和Y是屬性集U的子集，函數依賴是形為X→Y的一個命題，對任意R中兩個元組t和s，都有t[X]=s[X]蘊涵t[Y]=s[Y]，那麼FD X→Y在關系模式R(U)中成立。X→Y讀作『X函數決定Y』，或『Y函數依賴於X』。通俗的講，如果一個表中某一個欄位Y的值是由另外一個欄位或一組欄位X的值來確定的，就稱為Y函數依賴於X。函數依賴應該是通過理解數據項和企業的規則來決定的，根據表的內容得出的函數依賴可能是不正確的。
第一範式（1NF）
定義：如果關系模式R的每個關系r的屬性都是不可分的數據項，那麼就稱R是第一範式的模式。
簡單的說，每一個屬性都是原子項，不可分割。1NF是關系模式應具備的最起碼的條件，如果資料庫設計不能滿足第一範式，就不稱為關系型資料庫。關系資料庫設計研究的關系規范化是在1NF之上進行的。
第二範式（2NF）
定義：如果關系模式R是1NF，且每個非主屬性完全函數依賴於候選鍵，那麼就稱R是第二範式。
簡單的說，第二範式要滿足以下的條件：首先要滿足第一範式，其次每個非主屬性要完全函數依賴與候選鍵，或者是主鍵。也就是說，每個非主屬性是由整個主鍵函數決定的，而不能由主鍵的一部分來決定。舉個例子：
有股票日行情表的主鍵是股 票代碼和交易日期組成。非主屬性中有收盤價和成交量等，都是由主鍵，即股票代碼和交易日期函數決定的，單獨的股票代碼或者交易日期都不能函數決定這些非主 屬性。如果這個表中有非主屬性股票簡稱，則股票簡稱是可以由股票代碼來函數決定的，這樣股票簡稱這個非主屬性就不是完全函數依賴於候選鍵，這樣的設計就不 滿足第二範式。
第三範式（3NF）
定義：如果關系模式R是2NF，且關系模式R（U，F）中的所有非主屬性對任何候選關鍵字都不存在傳遞依賴，則稱關系R是屬於第三範式。
簡單的說，第三範式要滿足以下的條件：首先要滿足第二範式，其次非主屬性之間不存在函數依賴。由於滿足了第二範式，表示每個非主屬性都函數依賴於主鍵。如果非主屬性之間存在了函數依賴，就會存在傳遞依賴，這樣就不滿足第三範式。
舉 個例子：在股票基本情況表中，主鍵是股票代碼，有非主屬性所屬一級行業和所屬二級行業。根據業務規則，所屬二級行業能夠函數決定所屬一級行業，這就表示存 在這樣一種關系：股票代碼函數決定所屬二級行業，所屬二級行業函數決定所屬一級行業，這就形成了傳遞依賴，這樣的設計就不符合第三範式。不過在實際運用 中，為查詢和使用的方便，有時也會違反第三範式。如上例，如果沒有所屬一級行業的屬性，需要查詢所屬一級行業的相關股票，需要查詢時使用函數來從二級行業 中函數生成所屬一級行業，使用性能上會受影響。所以通常會加上所屬一級行業的屬性。
BC範式（BCNF）
BC範式是第三範式的增強版，不過也有人說是直接從1NF發展過來的，即每個屬性，包括主屬性或非主屬性，都完全依賴於候選鍵，並且不存在傳遞依賴情況。
③ 數據倉庫和傳統資料庫的區別和聯系是什麼
首先我們來了解數據倉庫和資料庫分別是什麼：
1、資料庫:是一種邏輯概念，用來存放數據的倉庫，通過資料庫軟體來實現。資料庫由很多表組成，表是二維的，一張表裡面有很多欄位。欄位一字排開，對數據就一行一行的寫入表中。資料庫的表，在於能夠用二維表現多維的關系。如：oracle、DB2、MySQL、Sybase、MSSQL Server等。
2、數據倉庫：是資料庫概念的升級。從邏輯上理解，資料庫和數據倉庫沒有區別，都是通過資料庫軟體實現存放數據的地方，只不過從數據量來說，數據倉庫要比資料庫更龐大德多。數據倉庫主要用於數據挖掘和數據分析，輔助領導做決策；
區別主要總結為以下幾點：
1.資料庫只存放在當前值，數據倉庫存放歷史值；
2.資料庫內數據是動態變化的，只要有業務發生，數據就會被更新，而數據倉庫則是靜態的歷史數據，只能定期添加、刷新；
3.資料庫中的數據結構比較復雜，有各種結構以適合業務處理系統的需要，而數據倉庫中的數據結構則相對簡單；
4.資料庫中數據訪問頻率較高，但訪問量較少，而數據倉庫的訪問頻率低但訪問量卻很高；
5.資料庫中數據的目標是面向業務處理人員的，為業務處理人員提供信息處理的支持，而數據倉庫則是面向高層管理人員的，為其提供決策支持；
6.資料庫在訪問數據時要求響應速度快，其響應時間一般在幾秒內，而數據倉庫的響應時間則可長達數幾小時
④ 資料庫設計的根本目的是什麼
資料庫設計的根本目標是要解決
A）數據共享問題 B）數據安全問題
C）大量數據存儲問題 D）簡化數據維護
一般書上很少這么提，大家在答這個題的時候，可以從資料庫的概念上入手，資料庫設計的根本目標是要解決應該是共享問題。四個答案可以做一些比較，最好的答案應該是A答案。你可以看一下資料庫的概念，一般資料庫是長期存儲在計算機內有組織的可共享的數據集合。還有一個線索，資料庫設計的六個階段，每一個階段主要做什麼，或者是大家看資料庫的一些範式，這個範式主要解決什麼問題。從這一題大家一定要注意二級考試的公共基礎知識，很多地方都考最根本，最主要的地方。
*************************
以上是轉載的資料
呵呵，說一下我的理解：
資料庫設計的目的即設計目標從根本上來說就是要實現數據的共享和安全存取，從細化及技術上來說，一個優秀的資料庫設計必須要最終實現用戶對於數據共享的具體要求，必須要在滿足於用戶的數據存取要求的基礎上實現對於數據的關聯性及優化，必須實現數據的安全性及可移植性，以保證用戶數據能夠簡單的進行移植，必須要實現資料庫的可擴容性結構以保證資料庫對於用戶未來數據要求的兼容性等等
⑤ 資料庫與數據倉庫的本質差別是什麼
資料庫與數據倉庫的本質差別如下：
1、邏輯層面/概念層面：資料庫和數據倉庫其實是一樣的或者及其相似的，都是通過某個資料庫軟體，基於某種數據模型來組織、管理數據。但是，資料庫通常更關注業務交易處理（OLTP），而數據倉庫更關注數據分析層面（OLAP），由此產生的資料庫模型上也會有很大的差異。
2、資料庫通常追求交易的速度，交易完整性，數據的一致性等，在資料庫模型上主要遵從範式模型（1NF，2NF，3NF等），從而盡可能減少數據冗餘，保證引用完整性；而數據倉庫強調數據分析的效率，復雜查詢的速度，數據之間的相關性分析，所以在資料庫模型上，數據倉庫喜歡使用多維模型，從而提高數據分析的效率。
3、產品實現層面：資料庫和數據倉庫軟體是有些不同的，資料庫通常使用行式存儲，如SAP ASE，Oracle, Microsoft SQL Server，而數據倉庫傾向使用列式存儲，如SAP IQ，SAP HANA。
⑥ 資料庫設計過程中，對於大批量的數據如何進行資料庫優化
實例講解MYSQL資料庫的查詢優化技術
作者：佚名 文章來源：未知 點擊數：2538 更新時間：2006-1-19
資料庫系統是管理信息系統的核心，基於資料庫的聯機事務處理（OLTP）以及聯機分析處理(OLAP)是銀行、企業、政府等部門最為重要的計算機應用之一。從大多數系統的應用實例來看，查詢操作在各種資料庫操作中所佔據的比重最大，而查詢操作所基於的SELECT語句在SQL語句中又是代價最大的語句。舉例來說，如果數據的量積累到一定的程度，比如一個銀行的賬戶資料庫表信息積累到上百萬甚至上千萬條記錄，全表掃描一次往往需要數十分鍾，甚至數小時。如果採用比全表掃描更好的查詢策略，往往可以使查詢時間降為幾分鍾，由此可見查詢優化技術的重要性。
筆者在應用項目的實施中發現，許多程序員在利用一些前端資料庫開發工具（如PowerBuilder、Delphi等）開發資料庫應用程序時，只注重用戶界面的華麗，並不重視查詢語句的效率問題，導致所開發出來的應用系統效率低下，資源浪費嚴重。因此，如何設計高效合理的查詢語句就顯得非常重要。本文以應用實例為基礎，結合資料庫理論，介紹查詢優化技術在現實系統中的運用。
分析問題
許多程序員認為查詢優化是DBMS（資料庫管理系統）的任務，與程序員所編寫的SQL語句關系不大，這是錯誤的。一個好的查詢計劃往往可以使程序性能提高數十倍。查詢計劃是用戶所提交的SQL語句的集合，查詢規劃是經過優化處理之後所產生的語句集合。DBMS處理查詢計劃的過程是這樣的：在做完查詢語句的詞法、語法檢查之後，將語句提交給DBMS的查詢優化器，優化器做完代數優化和存取路徑的優化之後，由預編譯模塊對語句進行處理並生成查詢規劃，然後在合適的時間提交給系統處理執行，最後將執行結果返回給用戶。在實際的資料庫產品(如Oracle、Sybase等)的高版本中都是採用基於代價的優化方法，這種優化能根據從系統字典表所得到的信息來估計不同的查詢規劃的代價，然後選擇一個較優的規劃。雖然現在的資料庫產品在查詢優化方面已經做得越來越好，但由用戶提交的SQL語句是系統優化的基礎，很難設想一個原本糟糕的查詢計劃經過系統的優化之後會變得高效，因此用戶所寫語句的優劣至關重要。系統所做查詢優化我們暫不討論，下面重點說明改善用戶查詢計劃的解決方案。
解決問題
下面以關系資料庫系統Informix為例，介紹改善用戶查詢計劃的方法。
1．合理使用索引
索引是資料庫中重要的數據結構，它的根本目的就是為了提高查詢效率。現在大多數的資料庫產品都採用IBM最先提出的ISAM索引結構。索引的使用要恰到好處，其使用原則如下：
●在經常進行連接，但是沒有指定為外鍵的列上建立索引，而不經常連接的欄位則由優化器自動生成索引。
●在頻繁進行排序或分組（即進行group by或order by操作）的列上建立索引。
●在條件表達式中經常用到的不同值較多的列上建立檢索，在不同值少的列上不要建立索引。比如在雇員表的「性別」列上只有「男」與「女」兩個不同值，因此就無必要建立索引。如果建立索引不但不會提高查詢效率，反而會嚴重降低更新速度。
●如果待排序的列有多個，可以在這些列上建立復合索引（compound index）。
●使用系統工具。如Informix資料庫有一個tbcheck工具，可以在可疑的索引上進行檢查。在一些資料庫伺服器上，索引可能失效或者因為頻繁操作而使得讀取效率降低，如果一個使用索引的查詢不明不白地慢下來，可以試著用tbcheck工具檢查索引的完整性，必要時進行修復。另外，當資料庫表更新大量數據後，刪除並重建索引可以提高查詢速度。
2．避免或簡化排序
應當簡化或避免對大型表進行重復的排序。當能夠利用索引自動以適當的次序產生輸出時，優化器就避免了排序的步驟。以下是一些影響因素：
●索引中不包括一個或幾個待排序的列；
●group by或order by子句中列的次序與索引的次序不一樣；
●排序的列來自不同的表。
為了避免不必要的排序，就要正確地增建索引，合理地合並資料庫表（盡管有時可能影響表的規范化，但相對於效率的提高是值得的）。如果排序不可避免，那麼應當試圖簡化它，如縮小排序的列的范圍等。
3．消除對大型錶行數據的順序存取
在嵌套查詢中，對表的順序存取對查詢效率可能產生致命的影響。比如採用順序存取策略，一個嵌套3層的查詢，如果每層都查詢1000行，那麼這個查詢就要查詢10億行數據。避免這種情況的主要方法就是對連接的列進行索引。例如，兩個表：學生表（學號、姓名、年齡……）和選課表（學號、課程號、成績）。如果兩個表要做連接，就要在「學號」這個連接欄位上建立索引。
還可以使用並集來避免順序存取。盡管在所有的檢查列上都有索引，但某些形式的where子句強迫優化器使用順序存取。下面的查詢將強迫對orders表執行順序操作：
SELECT ＊ FROM orders WHERE (customer_num=104 AND order_num>1001) OR order_num=1008
雖然在customer_num和order_num上建有索引，但是在上面的語句中優化器還是使用順序存取路徑掃描整個表。因為這個語句要檢索的是分離的行的集合，所以應該改為如下語句：
SELECT ＊ FROM orders WHERE customer_num=104 AND order_num>1001
UNION
SELECT ＊ FROM orders WHERE order_num=1008
這樣就能利用索引路徑處理查詢。
4．避免相關子查詢
一個列的標簽同時在主查詢和where子句中的查詢中出現，那麼很可能當主查詢中的列值改變之後，子查詢必須重新查詢一次。查詢嵌套層次越多，效率越低，因此應當盡量避免子查詢。如果子查詢不可避免，那麼要在子查詢中過濾掉盡可能多的行。
5．避免困難的正規表達式
MATCHES和LIKE關鍵字支持通配符匹配，技術上叫正規表達式。但這種匹配特別耗費時間。例如：SELECT ＊ FROM customer WHERE zipcode LIKE 「98_ _ _」
即使在zipcode欄位上建立了索引，在這種情況下也還是採用順序掃描的方式。如果把語句改為SELECT ＊ FROM customer WHERE zipcode >「98000」，在執行查詢時就會利用索引來查詢，顯然會大大提高速度。
另外，還要避免非開始的子串。例如語句：SELECT ＊ FROM customer WHERE zipcode[2，3]>「80」，在where子句中採用了非開始子串，因而這個語句也不會使用索引。
6．使用臨時表加速查詢
把表的一個子集進行排序並創建臨時表，有時能加速查詢。它有助於避免多重排序操作，而且在其他方面還能簡化優化器的工作。例如：
SELECT cust.name，rcvbles.balance，……other columns
FROM cust，rcvbles
WHERE cust.customer_id = rcvlbes.customer_id
AND rcvblls.balance>0
AND cust.postcode>「98000」
ORDER BY cust.name
如果這個查詢要被執行多次而不止一次，可以把所有未付款的客戶找出來放在一個臨時文件中，並按客戶的名字進行排序：
SELECT cust.name，rcvbles.balance，……other columns
FROM cust，rcvbles
WHERE cust.customer_id = rcvlbes.customer_id
AND rcvblls.balance>0
ORDER BY cust.name
INTO TEMP cust_with_balance
然後以下面的方式在臨時表中查詢：
SELECT ＊ FROM cust_with_balance
WHERE postcode>「98000」
臨時表中的行要比主表中的行少，而且物理順序就是所要求的順序，減少了磁碟I/O，所以查詢工作量可以得到大幅減少。
注意：臨時表創建後不會反映主表的修改。在主表中數據頻繁修改的情況下，注意不要丟失數據。
7．用排序來取代非順序存取
非順序磁碟存取是最慢的操作，表現在磁碟存取臂的來回移動。SQL語句隱藏了這一情況，使得我們在寫應用程序時很容易寫出要求存取大量非順序頁的查詢。
有些時候，用資料庫的排序能力來替代非順序的存取能改進查詢。
實例分析
下面我們舉一個製造公司的例子來說明如何進行查詢優化。製造公司資料庫中包括3個表，模式如下所示：
1．part表
零件號零件描述其他列
（part_num）（part_desc）（other column）
102，032Seageat 30G disk……
500，049Novel 10M network card……
……
2．vendor表
廠商號廠商名其他列
（vendor _num）（vendor_name） （other column）
910，257Seageat Corp……
523，045IBM Corp……
……
3．parven表
零件號廠商號零件數量
（part_num）（vendor_num）（part_amount）
102，032910，2573,450,000
234，423321，0014，000，000
……
下面的查詢將在這些表上定期運行，並產生關於所有零件數量的報表：
SELECT part_desc，vendor_name，part_amount
FROM part，vendor，parven
WHERE part.part_num=parven.part_num
AND parven.vendor_num = vendor.vendor_num
ORDER BY part.part_num
如果不建立索引，上述查詢代碼的開銷將十分巨大。為此，我們在零件號和廠商號上建立索引。索引的建立避免了在嵌套中反復掃描。關於表與索引的統計信息如下：
錶行尺寸行數量每頁行數量數據頁數量
（table）(row size)（Row count）（Rows/Pages）（Data Pages）
part15010，00025400
Vendor1501，000 2540
Parven13 15，000300 50
索引鍵尺寸每頁鍵數量頁面數量
（Indexes）(Key Size)（Keys/Page)(Leaf Pages）
part450020
Vendor45002
Parven825060
看起來是個相對簡單的3表連接，但是其查詢開銷是很大的。通過查看系統表可以看到，在part_num上和vendor_num上有簇索引，因此索引是按照物理順序存放的。parven表沒有特定的存放次序。這些表的大小說明從緩沖頁中非順序存取的成功率很小。此語句的優化查詢規劃是：首先從part中順序讀取400頁，然後再對parven表非順序存取1萬次，每次2頁（一個索引頁、一個數據頁），總計2萬個磁碟頁，最後對vendor表非順序存取1.5萬次，合3萬個磁碟頁。可以看出在這個索引好的連接上花費的磁碟存取為5.04萬次。
實際上，我們可以通過使用臨時表分3個步驟來提高查詢效率：
1．從parven表中按vendor_num的次序讀數據：
SELECT part_num，vendor_num，price
FROM parven
ORDER BY vendor_num
INTO temp pv_by_vn
這個語句順序讀parven（50頁），寫一個臨時表（50頁），並排序。假定排序的開銷為200頁，總共是300頁。
2．把臨時表和vendor表連接，把結果輸出到一個臨時表，並按part_num排序：
SELECT pv_by_vn，＊ vendor.vendor_num
FROM pv_by_vn，vendor
WHERE pv_by_vn.vendor_num=vendor.vendor_num
ORDER BY pv_by_vn.part_num
INTO TMP pvvn_by_pn
DROP TABLE pv_by_vn
這個查詢讀取pv_by_vn(50頁)，它通過索引存取vendor表1.5萬次，但由於按vendor_num次序排列，實際上只是通過索引順序地讀vendor表（40＋2=42頁），輸出的表每頁約95行，共160頁。寫並存取這些頁引發5＊160=800次的讀寫，索引共讀寫892頁。
3．把輸出和part連接得到最後的結果：
SELECT pvvn_by_pn.＊，part.part_desc
FROM pvvn_by_pn，part
WHERE pvvn_by_pn.part_num=part.part_num
DROP TABLE pvvn_by_pn
這樣，查詢順序地讀pvvn_by_pn(160頁)，通過索引讀part表1.5萬次，由於建有索引，所以實際上進行1772次磁碟讀寫，優化比例為30∶1。筆者在Informix Dynamic
Sever上做同樣的實驗，發現在時間耗費上的優化比例為5∶1(如果增加數據量，比例可能會更大)。
小結
20％的代碼用去了80％的時間，這是程序設計中的一個著名定律，在資料庫應用程序中也同樣如此。我們的優化要抓住關鍵問題，對於資料庫應用程序來說，重點在於SQL的執行效率。查詢優化的重點環節是使得資料庫伺服器少從磁碟中讀數據以及順序讀頁而不是非順序讀頁。
⑦ 數據課程設計心得體會
課程設計既可以指為掌握某一課程內容所進行的設計，也要指對某一門課程教學策劃的研究活動，下面是為大家搜集整理的數據課程設計心得體會，歡迎閱讀。
數據課程設計心得體會(一)
在我看來，資料庫課程設計主要的目標是利用課程中學到的資料庫知識和技術較好的開發設計出資料庫應用系統，去解決各行各業信息化處理的要求。通過這次的課程設計，可以鞏固我們對資料庫基本原理和基礎理論的理解，掌握資料庫應用系統設計開發的基本方法，進一步提高我們綜合運用所學知識的能力。
當我們這組決定做大學生就業咨詢系統時，我們並沒有著手寫程序。而是大家一起商量這個系統概述、系統目標、系統需求、業務流程分析、數據流程分析和數據詞典。當這些都准備好了之後，我們進行模塊的分工。每個人都有自己的模塊設計，而且寫出來的代碼要求可以實現相應模塊的功能，得到理想的效果。當每個人都把自己的分工做好了，最後會由一個人把這些全部組合搭建在一起。我們使用的是Html和php相互嵌套使用，當一個系統做好了之後，我會好好地把程序都看一遍，理會其中的奧秘。
知識的獲得是無止境的，只要你想學，只要你行動，沒有什麼會難倒我們的。回首這一個多星期的課程設計，我很欣慰。因為我有了動力，有了勇氣。謝謝老師對我們的不懈幫助，謝謝學校給了我們這一次實踐的機會，也謝謝組員們的關懷。這些美好的回憶美好的東西將永遠伴隨著我。
數據課程設計心得體會(二)
資料庫課程設計大賽的塵囂漸漸遠去，懷著對這次大賽的些許不舍，懷著對當初課程設計開始時候的豪情萬丈的決心的留戀，懷著通過這次課程設計積累的信心與鬥志，我開始寫這篇文章，賀老薯為自己的足跡留下哪怕是微不足道但是對自己彌足珍貴的痕跡並期望與大家共勉。
首先，讓我的記憶追溯到大二暑假，在老含李大的指引下(老大勸我學ASP(ASP培訓 ).net)，我接觸到microsoft 公司的.net產品。那個時候我已經學過vc和asp，因為windows程序設計實驗的課的關系，接觸過VB(VB培訓 )，但是沒有專門去學他，因為習慣了c++裡面的class，int，覺得vb的sub，var 看著就不是很順心。我是一個好奇心很強的人，突然看到了一個號稱“.net是用於創建下一代應用程序的理想而又現實的開發工具”，而且主推c#語言，由於對c語言的一貫好感，我幾乎是立刻對他產生了興趣。我就開始了對c#的學習，任何語言都不是孤立存在的，所以數據交互是很重要的，暑假的時候我把我們這學期的課本資料庫系統概論看了一遍。我記得以前用c語言編程的時候，數據是在內存中申請空間，譬如使用數組等等。很耗費內存空間。這個時候就是資料庫站出來的時候啦，於是我又裝上了sql server2000，以前學asp的時候用的是access，那個時候只是照著人家做，理論是什麼也不是很清楚。
開發的時候我想過用什麼架構，c/s模式?模式有很多，怎麼選擇?我就上網搜索現在最流行的架構是什麼。結果搜到了mvc架構，就是你啦。我決定用這個架構，不會，沒關系，咱學。just do it!前期工作準備好後，那麼我就得把我暑假學的.net加以實踐。這個時候我更加深入的了解了利用ado.net操縱資料庫的知識。並且對資料庫裡面的存儲過程有了比較深入的了解。經過大概2個多星期的奮斗，我完成了我的資料庫課程設計--基於.net數據集的圖書館管理系統。並最後非常榮幸的獲得了大賽的一等獎以及以及新技術應用獎。
與其臨淵羨魚，不如退而結網。這次資料庫課程設計給我的最大的印象就是如果自己有了興趣，就動手去做，困難在你的勇氣和毅力下是抬不了頭的。從做這個資料庫開始無論遇到什麼困難，我都沒有一絲的放棄的念頭。出於對知識的渴望，出於對新技術的好奇，出於對一切未知的求知。我完成了這次資料庫課程設計，不過這只是我學習路上的驛站，未來十年.net的核心技術就是xml[至少微軟是這么宣傳的]，我會繼續學習它禪者，包括jave公司的j2ee我也很想試試，語言本來就是相通的，just do it!語言並不重要畢竟它僅僅是工具，用好一個工具並不是一件值得為外人道的事情，主要是了解學習思想。古語說的好：學無止境啊。
實際上從學習的經歷來看，我們接觸的知識體系都是屬於比較老或比較傳統的，與現在發展迅速的IT行業相比很多情況已不再適用，尤其是當開源模式逐漸走近開發者後更是如此。雖然是一個資料庫課程設計，由於本人在選擇項目的時候是本著對自己有實際應用價值的角度考慮的，所以其中也涉及到一些資料庫以外的設計。總而言之，這次資料庫設計心得體會不能用語言完全表達。
數據課程設計心得體會(三)
本次課程設計，使我對《數據結構》這門課程有了更深入的理解。《數據結構》是一門實踐性較強的課程，為了學好這門課程，必須在掌握理論知識的同時，加強上機實踐。
我的課程設計題目是線索二叉樹的運算。剛開始做這個程序的時候，感到完全無從下手，甚至讓我覺得完成這次程序設計根本就是不可能的，於是開始查閱各種資料以及參考文獻，之後便開始著手寫程序，寫完運行時有很多問題。特別是實現線索二叉樹的刪除運算時很多情況沒有考慮周全，經常運行出現錯誤，但通過同學間的幫助最終基本解決問題。
在本課程設計中，我明白了理論與實際應用相結合的重要性，並提高了自己組織數據及編寫大型程序的能力。培養了基本的、良好的程序設計技能以及合作能力。這次課程設計同樣提高了我的綜合運用所學知識的能力。並對VC有了更深入的了解。《數據結構》是一門實踐性很強的課程，上機實習是對學生全面綜合素質進行訓練的一種最基本的方法，是與課堂聽講、自學和練習相輔相成的、必不可少的一個教學環節。上機實習一方面能使書本上的知識變“活”，起到深化理解和靈活掌握教學內容的目的;另一方面，上機實習是對學生軟體設計的綜合能力的訓練，包括問題分析，總體結構設計，程序設計基本技能和技巧的訓練。此外，還有更重要的一點是：機器是比任何教師更嚴厲的檢查者。因此，在“數據結構”的學習過程中，必須嚴格按照老師的要求，主動地、積極地、認真地做好每一個實驗，以不斷提高自己的編程能力與專業素質。
通過這段時間的課程設計，我認識到數據結構是一門比較難的課程。需要多花時間上機練習。這次的程序訓練培養了我實際分析問題、編程和動手能力，使我掌握了程序設計的基本技能，提高了我適應實際，實踐編程的能力。總的來說，這次課程設計讓我獲益匪淺，對數據結構也有了進一步的理解和認識。
數據課程設計心得體會(四)
兩個星期的時間非常快就過去了，這兩個星期不敢說自己有多大的進步，獲得了多少知識，但起碼是了解了項目開發的部分過程。雖說上過資料庫上過管理信息系統等相關的課程，但是沒有親身經歷過相關的設計工作細節。這次實習證實提供了一個很好的機會。
通過這次課程設計發現這其中需要的很多知識我們沒有接觸過，去圖書館查資料的時候發現我們前邊所學到的僅僅是皮毛，還有很多需要我們掌握的東西我們根本不知道。同時也發現有很多已經學過的東西我們沒有理解到位，不能靈活運用於實際，不能很好的用來解決問題，這就需要我們不斷的大量的實踐，通過不斷的自學，不斷地發現問題，思考問題，進而解決問題。在這個過程中我們將深刻理解所學知識，同時也可以學到不少很實用的東西。
從各種文檔的閱讀到開始的需求分析、概念結構設計、邏輯結構設計、物理結構設計。親身體驗了一回系統的設計開發過程。很多東西書上寫的很清楚，貌似看著也很簡單，思路非常清晰。但真正需要自己想辦法去設計一個系統的時候才發現其中的難度。經常做到後面突然就發現自己一開始的設計有問題，然後又回去翻工，在各種反復中不斷完善自己的想法。
我想有這樣的問題不止我一個，事後想想是一開始著手做的時候下手過於輕快，或者說是根本不了解自己要做的這個系統是給誰用的。因為沒有事先做過仔細的用戶調查，不知道整個業務的流程，也不知道用戶需要什麼功能就忙著開發，這是作為設計開發人員需要特別警惕避免的，不然會給後來的工作帶來很大的麻煩，甚至可能會需要全盤推倒重來。所以以後的課程設計要特別注意這一塊的設計。
按照要求，我們做的是機票預訂系統。說實話，我對這個是一無所知的，沒有訂過機票，也不知道航空公司是怎麼一個流程。盲目開始設計的下場我已經嘗過了，結果就是出來一個四不像的設計方案，沒有什麼實際用處。沒有前期的調查，僅從指導書上那幾條要求著手是不夠的。
在需求分析過程中，我們通過上網查資料，去圖書館查閱相關資料，結合我們的生活經驗，根據可行性研究的結果和客戶的要求，分析現有情況及問題，採用Client/Server結構，將機票預定系統劃分為兩個子系統：客戶端子系統，伺服器端子系統。在兩周的時間里，不斷地對程序及各模塊進行修改、編譯、調試、運行，其間遇到很多問題：由於忘記了一些java語言的規范使得在調試過程中一些錯誤沒有發現，通過這次課程設計，我對調試掌握得更加熟練了，意識到了程序語言的規范性以及我們在編程時要有嚴謹的態度，同時在寫程序時如有一定量的注釋，既增加了程序的可讀性，也可以使自己在讀程序時更容易。
我們學習並應用了SQL語言，對資料庫的創建、修改、刪除方法有了一定的了解，通過導入表和刪除表、更改表學會了對於表的一些操作，為了建立一個關系資料庫信息管理系統，必須得經過系統調研、需求分析、概念設計、邏輯設計、物理設計、系統調試、維護以及系統評價的一般過程，為畢業設計打下基礎。
很多事情不是想像中的那麼簡單的，它涉及到的各種實體、屬性、數據流程、數據處理等等。很多時候感覺後面的設計根本無法繼續，感覺像是被前面做的各種圖限制了。在做關系模型轉換的時候碰到有些實體即可以認為是實體又可以作為屬性，為了避免冗餘，盡量按照屬性處理了。
物理結構設計基本沒有碰到問題，這一塊和安全性、完整性不覺就會在物理結構設計中添加一些安全設置：主鍵約束、check約束、default定義等。最後才做索引的部分，對一些比較經常使用搜索的列，外鍵上建立索引，這樣可以明顯加快檢索的速度，最後別忘記重要的安全性設置，限制用戶訪問許可權，新建用戶並和資料庫用戶做相應的映射。
不管做什麼，我們都要相信自己，不能畏懼，不能怕遇到困難，什麼都需要去嘗試，有些你開始認為很難的事在你嘗試之後你可能會發現原來她並沒有你以前覺得的那樣，自己也是可以的。如果沒有自信，沒有目標，沒有信心就不可能把事情做好，當其他人都在迷茫的時候，自己一定要堅信目標，大學畢業出去即面臨找工作，從學習這個專業，到以後從事這方面的工作都需要不斷地去學習去實踐，這次實踐可以給我們敲一個警鍾，我們面臨畢業，面臨擇業，需要這些實踐經驗，在困難面前要勇於嘗試，這是這次課程設計給我的最大感想!
以上基本是這次實習的體會了，設計進行的非常艱難，編碼非常不容易，才發現做一個項目最重要的不在於如何實現，而是實現之前的需求分析和模塊設計。創新很難，有些流行的系統其實現並不難，難的在於對市場的分析和准確定位。設計，是一個任重道遠的過程。
⑧ 數據倉庫的目的是什麼
數據倉庫組織的最根本目的就是能夠更加便利，有序的進行倉庫管理，讓倉庫數據化，可以讓管理更加的便利的同時，更加的科學，安全。
數據倉庫中的數據是在對原有分散的資料庫數據抽取、清理的基礎上經過系統加工、匯總和整理得到的，必須消除源數據沖虛中的不一致性，以保證數據倉庫內的信息是關於整個企業的一致的全局信息。
數據倉庫的數據主要供企業決策分析之用，所涉及的數據操作主要是數據查詢，一旦某個數據進入數據倉庫以後，一般情況下將被長期保留，也就是數據倉庫中一般有大量的查詢操作，但修改和刪除操作很少，通常只需要定期的載入、刷新。
數據倉庫中的數據通常包含歷史信息，系統記錄了企業從過去某一時點(如開始應用數據倉庫的時點)到當前的各個階段的信息，通過這些信息，可以對企業的發展歷程和未來趨勢做出定量分析和預測。
(8)資料庫設計的根本目的擴展閱讀：
數據倉庫所提供的各種信息，肯定要准確的數據，但由於數據倉庫流程通常分為多個步驟，包括數據清洗，裝載，跡判山查詢，展現等等，復雜的架構會更多層次，那麼由於數據源有臟數據或者代碼不嚴謹，都可以導致數據失真，客戶看到錯誤的信息就可能導致分析出錯誤的決策，造成損失，而不姿中是效益。
之所以有的大型數據倉庫系統架構設計復雜，是因為考慮到了未來3-5年的擴展性，這樣的話，未來不用太快花錢去重建數據倉庫系統，就能很穩定運行。主要體現在數據建模的合理性，數據倉庫方案中多出一些中間層，使海量數據流有足夠的緩沖，不至於數據量大很多，就運行不起來了。
⑨ 資料庫技術的根本目標是什麼
資料庫技術的根本目標是解決數據的「共享問題」。
資料庫技術是信息系統的一個核心技術。是一種計算機輔助管理數據的方法，它研究如何組織和存儲數據，如何高效地獲取和處理數據。
資料庫技術是信息系統的一個核心技術。是一種計算機輔助管理數據的方法，它研究如何組織和存儲數據，如何高效地獲取和處理數據。是通過研究資料庫的結構、存儲、設計、管理以及應用的基本理論和實現方法，並利用這些理論來實現缺山對資料庫中的數據進行處理、分析和理解的技術。即：資料庫技術是研究、管理和應握仿用資料庫的一門軟體科學。
⑩ 資料庫設計範式深入淺出
關系資料庫設計之時是要遵守一定的規則的。尤其是資料庫設計範式 現簡單介紹1NF（第一範式），2NF（第二範式），3NF（第三範式）和BCNF，另有第四範式和第五範式留到以後再介紹。 在你設計資料庫之時，若能符合這幾個範式，你就是資料庫設計的高手。
第一範式（1NF）：在關系模式R中的每一個具體關系r中，如果每個屬性值 都是不可再分的最小數據單位，則稱R是第一範式的關系。例：如職工號，姓名，電話號碼組成一個表（一個人可能有一個辦公室電話 和一個家裡電話號碼） 規范成為1NF有三種方法：
一是重復存儲職工號和姓名。這樣，關鍵字只能是電話號碼。
二是職工號為關鍵字，電話號碼分為單位電話和住宅電話兩個屬性
三是職工號為關鍵字，但強制每條記錄只能有一個電話號碼。
以上三個方法，第一種方法最不可取，按實際情況選取後兩種情況。
第二範式（2NF）：如果關系模式R（U，F）中的所有非主屬性都完全依賴於任意一個候選關鍵字，則稱關系R 是屬於第二範式的。
例：選課關系 SCI（SNO，CNO，GRADE，CREDIT）其中SNO為學號， CNO為課程號，GRADEGE 為成績，CREDIT 為學分。 由以上條件，關鍵字為組合關鍵字（SNO，CNO）
在應用中使用以上關系模式有以下問題：
a.數據冗餘，假設同一門課由40個學生選修，學分就 重復40次。
b.更新異常，若調整了某課程的學分，相應的元組CREDIT值都要更新，有可能會出現同一門課學分不同。
c.插入異常，如計劃開新課，由於沒人選修，沒有學號關鍵字，只能等有人選修才能把課程和學分存入。
d.刪除異常，若學生已經結業，從當前資料庫刪除選修記錄。某些門課程新生尚未選修，則此門課程及學分記錄無法保存。
原因：非關鍵字屬性CREDIT僅念顫函數依賴於CNO，也就是CREDIT部分依賴組合關鍵字（SNO，CNO）而不是完全依賴。
解決方法：分成兩個關系模式 SC1（SNO，CNO，GRADE），C2（CNO，CREDIT）。新關系包括兩個關系模式，它們之間通過SC1中的外關鍵字CNO相聯系，需要時再進行自然聯接，恢復了原來的關系
第三範式（3NF）：如果關系模式R（U，F）中的所有非主屬性對任何候選關鍵字都不存在傳遞信賴，則稱關系R是屬於第三範式的。
例：如S1（SNO，SNAME，DNO，DNAME，LOCATION） 各屬性分別代表學號，
姓名，所在系，系名稱，系地址。
關鍵字SNO決定各個屬性。由於是單個關鍵字，沒有部分依賴的問題，仔肆敗肯定是2NF。但這關系肯定有大量的冗餘，有關學生所在的幾個屬性DNO，DNAME，LOCATION將重復存儲，插入，刪除和修改時也將產生類似以上例的情況。
原因：關系中存在傳遞依賴造成的。即SNO - DNO。 而DNO - SNO卻不存在，DNO - LOCATION, 因此關鍵遼 SNO 對 LOCATION 函數決定是通過傳遞依賴 SNO - LOCATION 實現的。也就是說，SNO不直接決定非主屬性LOCATION。
解決目地：每個關系模式中不能留有傳遞依賴。
解決方法：分為兩個關系 S（SNO，SNAME，DNO），D（DNO，DNAME，LOCATION）
注意：關系S中不能沒有外關鍵字DNO。否則兩個關系之間失去聯系。
BCNF：如果關系模式R（U，F）的所有屬性（包括主屬性和非主屬性）都不傳遞依賴於R的任何候選關鍵字，那麼稱關系R是屬於BCNF的。或是關系模式R，如果每個決定因素都包含關鍵字（而不是被關鍵字所包含），則RCNF的關系模式。
例：配件管理關系模式 WPE（WNO，PNO，ENO，QNT）分別表倉庫號，配件號，職工號，數量。有以下條件
a.一個倉庫有多個職工雹舉。
b.一個職工僅在一個倉庫工作。
c.每個倉庫里一種型號的配件由專人負責，但一個人可以管理幾種配件。
d.同一種型號的配件可以分放在幾個倉庫中。
分析：由以上得 PNO 不能確定QNT，由組合屬性（WNO，PNO）來決定，存在函數依賴（WNO，PNO） - ENO。由於每個倉庫里的一種配件由專人負責，而一個人可以管理幾種配件，所以有組合屬性（WNO，PNO）才能確定負責人，有（WNO，PNO）- ENO。因為 一個職工僅在一個倉庫工作，有ENO - WNO。由於每個倉庫里的一種配件由專人負責，而一個職工僅在一個倉庫工作，有 （ENO，PNO）- QNT。
找一下候選關鍵字，因為（WNO，PNO） - QNT，（WNO，PNO）- ENO ，因此 （WNO，PNO）可以決定整個元組，是一個候選關鍵字。根據ENO-WNO，（ENO，PNO）-QNT，故（ENO，PNO）也能決定整個元組，為另一個候選關鍵字。屬性ENO，WNO，PNO 均為主屬性，只有一個非主屬性QNT。它對任何一個候選關鍵字都是完全函數依賴的，並且是直接依賴，所以該關系模式是3NF。
分析一下主屬性。因為ENO-WNO，主屬性ENO是WNO的決定因素，但是它本身不是關鍵字，只是組合關鍵字的一部分。這就造成主屬性WNO對另外一個候選關鍵字（ENO，PNO）的部 分依賴，因為（ENO，PNO）- ENO但反過來不成立，而P-WNO，故（ENO，PNO）- WNO 也是傳遞依賴。
雖然沒有非主屬性對候選關鍵遼的傳遞依賴，但存在主屬性對候選關鍵字的傳遞依賴，同樣也會帶來麻煩。如一個新職工分配到倉庫工作，但暫時處於實習階段，沒有獨立負責對某些配件的管理任務。由於缺少關鍵字的一部分PNO而無法插入到該關系中去。又如某個人改成不管配件了去負責安全，則在刪除配件的同時該職工也會被刪除。
解決辦法：分成管理EP（ENO，PNO，QNT），關鍵字是（ENO，PNO）工作EW（ENO，WNO）其關鍵字是ENO
缺點：分解後函數依賴的保持性較差。如此例中，由於分解,函數依賴（WNO，PNO）- ENO 丟失了, 因而對原來的語義有所破壞。沒有體現出每個倉庫里一種部件由專人負責。有可能出現 一部件由兩個人或兩個以上的人來同時管理。因此，分解之後的關系模式降低了部分完整性約束。
一個關系分解成多個關系，要使得分解有意義，起碼的要求是分解後不丟失原來的信息。這些信息不僅包括數據本身，而且包括由函數依賴所表示的數據之間的相互制約。進行分解的目標是達到更高一級的規范化程度，但是分解的同時必須考慮兩個問題：無損聯接性和保持函數依賴。有時往往不可能做到既有無損聯接性，又完全保持函數依賴。需要根據需要進行權衡。
1NF直到BCNF的四種範式之間有如下關系：
BCNF包含了3NF包含2NF包含1NF
小結：
目地：規范化目的是使結構更合理，消除存儲異常，使數據冗餘盡量小，便於插入、刪除和更新
原則：遵從概念單一化 "一事一地"原則，即一個關系模式描述一個實體或實體間的一種聯系。規范的實質就是概念的單一化。
方法：將關系模式投影分解成兩個或兩個以上的關系模式。
要求：分解後的關系模式集合應當與原關系模式"等價"，即經過自然聯接可以恢復原關系而不丟失信息，並保持屬性間合理的聯系。
注意：一個關系模式結這分解可以得到不同關系模式集合，也就是說分解方法不是唯一的。最小冗餘的要求必須以分解後的資料庫能夠表達原來資料庫所有信息為前提來實現。其根本目標是節省存儲空間，避免數據不一致性，提高對關系的操作效率，同時滿足應用需求。實際上，並不一定要求全部模式都達到BCNF不可。有時故意保留部分冗餘可能更方便數據查詢。尤其對於那些更新頻度不高，查詢頻度極高的資料庫系統更是如此。
在關系資料庫中，除了函數依賴之外還有多值依賴，聯接依賴的問題，從而提出了第四範式，第五範式等更高一級的規范化要求。在此，以後再談。
各位朋友，你看過後有何感想，其實，任何一本資料庫基礎理論的書都會講這些東西，考慮到很多網友是半途出家，來做資料庫。特找一本書大抄特抄一把，各位有什麼問題，也別問我了，自已去找一本關系資料庫理論的書去看吧，說不定，對各位大有幫助。說是說以上是基礎理論的東西，請大家想想，你在做資料庫設計的時候有沒有考慮過遵過以上幾個範式呢，有沒有在資料庫設計做得不好之時，想一想，對比以上所講，到底是違反了第幾個範式呢？
我見過的資料庫設計，很少有人做到很符合以上幾個範式的，一般說來，第一範式大家都可以遵守，完全遵守第二第三範式的人很少了，遵守的人一定就是設計資料庫的高手了，BCNF的範式出現機會較少，而且會破壞完整性，你可以在做設計之時不考慮它，當然在ORACLE中可通過觸發器解決其缺點。以後我們共同做設計之時，也希望大家遵守以上幾個範式。