Ⅰ 簡述一個資料庫應用系統的建立過程
資料庫應用系統的開發是一項軟體工程。一般可分為以下幾個階段:
1.規劃
2.需求分析
3.概念模型設計
4. 邏輯設計
5.物理設計
6.程序編制及調試
7.運行及維護。
這些階段的劃分目前尚無統一的標准,各階段間相互聯接,而且常常需要回溯修正。
在資料庫應用系統的開發過程中,每個階段的工作成果就是寫出相應的文檔。每個階段都是在上一階段工作成果的基礎上繼續進行,整個開發工程是有依據、有組織、有計劃、有條不紊地展開工作。
1.規劃
規劃的主要任務就是作必要性及可行性分析。
在收集整理有關資料的基礎上,要確定將建立的資料庫應用系統與周邊的關系,要對應用系統定位,其規模的大小、所處的地位、應起的作用均須作全面的分析和論證。
明確應用系統的基本功能,劃分資料庫支持的范圍。分析數據來源、數據採集的方式和范圍,研究數據結構的特點,估算數據量的大小,確立數據處理的基本要求和業務的規范標准。
規劃人力資源調配。對參與研製和以後維護系統運作的管理人員、技術人員的技術業務水平提出要求,對最終用戶、操作員的素質作出評估。
擬定設備配置方案。論證計算機、網路和其他設備在時間、空間兩方面的處理能力,要有足夠的內外存容量,系統的響應速度、網路傳輸和輸入輸出能力應滿足應用需求並留有餘量。要選擇合適的os,dbms和其它軟體。設備配置方案要在使用要求、系統性能、購置成本和維護代價各方面綜合權衡。
對系統的開發、運行、維護的成本作出估算。預測系統效益的期望值。
擬定開發進度計劃,還要對現行工作模式如何向新系統過渡作出具體安排。
規劃階段的工作成果是寫出詳盡的可行性分析報告和資料庫應用系統規劃書。內容應包括:系統的定位及其功能、數據資源及數據處理能力、人力資源調配、設備配置方案、開發成本估算、開發進度計劃等。
可行性分析報告和資料庫應用系統規劃書經審定立項後,成為後續開發工作的總綱。
資料庫應用系統的開發是一項軟體工程,本文介紹了資料庫應用系統的開發步驟……
2.需求分析
需求分析大致可分成三步來完成。
(1) 需求信息的收集, 需求信息的收集一般以機構設置和業務活動為主幹線,從高層中層到低層逐步展開
(2) 需求信息的分析整理, 對收集到的信息要做分析整理工作。數據流圖(dfd, data flow diagram)是業務流程及業務中數據聯系的形式描述。圖4.1是一個簡單的dfd 示例。
數據字典(dd, data dictionary)詳細描述系統中的全部數據。
數據字典包含以下幾個部分。
· 數據項:是數據的原子單位。
· 數據組項:由若干數據項組成。
· 數據流:表示某一數據加工過程的輸入/輸出數據。
· 數據存儲:是處理過程中要存取的數據。
· 數據加工過程 數據加工過程的描述包括:數據加工過程名、說明、輸入、輸出、加工處理工作摘要、加工處理頻度、加工處理的數據量、響應時間要求等。
數據流圖既是需求分析的工具,也是需求分析的成果之一。數據字典是進行數據收集和數據分析的主要成果。
(3) 需求信息的評審. 開發過程中的每一個階段都要經過評審,確認任務是否全部完成,避免或糾正工作中出現的錯誤和疏漏。聘請項目外的專家參與評審,可保證評審的質量和客觀性。
評審可能導致開發過程回溯,甚至會反復多次。但是,一定要使全部的預期目標都達到才能讓需求分析階段的工作暫告一個段落.
需求分析階段的工作成果是寫出一份既切合實際又具有預見的需求說明書,並且附以一整套詳盡的數據流圖和數據字典。
3.概念模型設計
概念模型不依賴於具體的計算機系統,他是純粹反映信息需求的概念結構。
建模是在需求分析結果的基礎上展開,常常要對數據進行抽象處理。常用的數據抽象方法是『聚集』和『概括』。
er方法是設計概念模型時常用的方法。用設計好的er圖再附以相應的說明書可作為階段成果
概念模型設計可分三步完成。
(1) 設計局部概念模型
① 確定局部概念模型的范圍
② 定義實體
③ 定義聯系
④ 確定屬性
⑤ 逐一畫出所有的局部er圖,並附以相應的說明文件
資料庫應用系統的開發是一項軟體工程,本文介紹了資料庫應用系統的開發步驟……
(2) 設計全局概念模型
建立全局er圖的步驟如下:
① 確定公共實體類型
② 合並局部er圖
③ 消除不一致因素
④ 優化全局er圖
⑤ 畫出全局er圖,並附以相應的說明文件。
(3) 概念模型的評審
概念模型的評審分兩部分進行
第一部分是用戶評審。
第二部分是開發人員評審。
4.邏輯設計
邏輯設計階段的主要目標是把概念模型轉換為具體計算機上dbms所支持的結構數據模型。
邏輯設計的輸入要素包括:概念模式、用戶需求、約束條件、選用的dbms的特性。
邏輯設計的輸出信息包括:dbms可處理的模式和子模式、應用程序設計指南、物理設計指南。
(1) 設計模式與子模式
關系資料庫的模式設計可分四步完成。
① 建立初始關系模式
② 規范化處理
③ 模式評價
④ 修正模式
經過多次的模式評價和模式修正,確定最終的模式和子模式。
寫出邏輯資料庫結構說明書。
資料庫應用系統的開發是一項軟體工程,本文介紹了資料庫應用系統的開發步驟……
(2) 編寫應用程序設計指南
根據設計好的模式和應用需求,規劃應用程序的架構,設計應用程序的草圖,指定每個應用程序的數據存取功能和數據處理功能梗概,提供程序上的邏輯介面。
編寫出應用程序設計指南。
(3) 編寫物理設計指南。
根據設計好的模式和應用需求,整理出物理設計階段所需的一些重要數據和文檔。例如,資料庫的數據容量、各個關系(文件)的數據容量、應用處理頻率、操作順序、響應速度、各個應用的lra和tv、程序訪問路徑建議,等等。這些數據和要求將直接用於物理資料庫的設計。
編寫出物理設計指南。
5.物理設計
物理設計是對給定的邏輯數據模型配置一個最適合應用環境的物理結構。
物理設計的輸入要素包括:模式和子模式、物理設計指南、硬體特性、os和dbms的約束、運行要求等。
物理設計的輸出信息主要是物理資料庫結構說明書。其內容包括物理資料庫結構、存儲記錄格式、存儲記錄位置分配及訪問方法等。
物理設計的步驟如下:
(1) 存儲記錄結構
設計綜合分析數據存儲要求和應用需求,設計存儲記錄格式。
(2) 存儲空間分配
存儲空間分配有兩個原則:
①存取頻度高的數據盡量安排在快速、隨機設備上,存取頻度低的數據則安排在速度較慢的設備上。
②相互依賴性強的數據盡量存儲在同一台設備上,且盡量安排在鄰近的存儲空間上。
從提高系統性能方面考慮,應將設計好的存儲記錄作為一個整體合理地分配物理存儲區域。盡可能充分利用物理順序特點,把不同類型的存儲記錄指派到不同的物理群中。
(3) 訪問方法的設計
一個訪問方法包括存儲結構和檢索機構兩部分。存儲結構限定了訪問存儲記錄時可以使用的訪問路徑;檢索機構定義了每個應用實際使用的訪問路徑。
資料庫應用系統的開發是一項軟體工程,本文介紹了資料庫應用系統的開發步驟……
(4) 物理設計的性能評價
① 查詢響應時間
從查詢開始到有結果顯示之間所經歷的時間稱為查詢響應時間。查詢響應時間可進一步細分為服務時間、等待時間和延遲時間。
在物理設計過程中,要對系統的性能進行評價。性能評價包括時間、空間、效率、開銷等各個方面。
⊙ cpu服務時間和i/o服務時間的長短取決於應用程序設計。
⊙ cpu隊列等待時間和i/o隊列等待時間的長短受計算機系統作業的影響。
⊙ 設計者可以有限度地控制分布式資料庫系統的通信延遲時間。
② 存儲空間
存儲空間存放程序和數據。程序包括運行的應用程序、dbms子程序、os子程序等。數據包括用戶工作區、dbms工作區、os工作區、索引緩沖區、數據緩沖區等。
存儲空間分為主存空間和輔存空間。設計者只能有限度地控制主存空間,例如可指定緩沖區的分配等。但設計者能夠有效地控制輔存空間。
③ 開銷與效率
設計中還要考慮以下各種開銷,開銷增大,系統效率將下降。
⊙ 事務開銷指從事務開始到事務結束所耗用的時間。更新事務要修改索引、重寫物理塊、進行寫校驗等操作,增加了額外的開銷。更新頻度應列為設計的考慮因素。
⊙ 報告生成開銷指從數據輸入到有結果輸出這段時間。報告生成佔用cpu及i/o的服務時間較長。設計中要進行篩選,除去不必要的報告生成。
⊙ 對資料庫的重組也是一項大的開銷。設計中應考慮數據量和處理頻度這兩個因數,做到避免或盡量減少重組資料庫。
在物理設計階段,設計、評價、修改這個過程可能要反復多次,最終得到較為完善的物理資料庫結構說明書。
建立資料庫時,dba依據物理資料庫結構說明書,使用dbms提供的工具可以進行資料庫配置。
在資料庫運行時,dba監察資料庫的各項性能,根據依據物理資料庫結構說明書的准則,及時進行修正和優化操作,保證資料庫系統能夠保持高效率地運行。
6.程序編制及調試
在邏輯資料庫結構確定以後,應用程序設計的編制就可以和物理設計並行地展開
程序模塊代碼通常先在模擬的環境下通過初步調試,然後再進行聯合調試。聯合調試的工作主要有以下幾點:
資料庫應用系統的開發是一項軟體工程,本文介紹了資料庫應用系統的開發步驟……
(1) 建立資料庫結構
根據邏輯設計和物理設計的結果,用dbms提供的數據語言(ddl)編寫出資料庫的源模式,經編譯得到目標模式,執行目標模式即可建立實際的資料庫結構。
(2) 調試運行
資料庫結構建立後,裝入試驗數據,使資料庫進入調試運行階段。運行應用程序,測試
(3) 裝入實際的初始數據
在資料庫正式投入運行之前,還要做好以下幾項工作:
(1) 制定資料庫重新組織的可行方案。
(2) 制定故障恢復規范
(3) 制定系統的安全規范
7.運行和維護
資料庫正式投入運行後,運行維護階段的主要工作是:
(1) 維護資料庫的安全性與完整性。
按照制定的安全規范和故障恢復規范,在系統的安全出現問題時,及時調整授權和更改密碼。及時發現系統運行時出現的錯誤,迅速修改,確保系統正常運行。把資料庫的備份和轉儲作為日常的工作,一旦發生故障,立即使用資料庫的最新備份予以恢復。
(2) 監察系統的性能。
運用dbms提供的性能監察與分析工具,不斷地監控著系統的運行情況。當資料庫的存儲空間或響應時間等性能下降時,立即進行分析研究找出原因,並及時採取措施改進。例如,可通修改某些參數、整理碎片、調整存儲結構或重新組織資料庫等方法,使資料庫系統保持高效率地正常運作。
(3) 擴充系統的功能
在維持原有系統功能和性能的基礎上,適應環境和需求的變化,採納用戶的合理意見,對原有系統進行擴充,增加新的功能。
Ⅱ 如何設計一個完整的資料庫系統
資料庫系統(database
system),是由資料庫及其管理軟體組成的系統。
一個完整的資料庫系統包括
1
計算機硬體
計算機硬體是資料庫系統的物質基礎,是存儲資料庫及運行資料庫管理系統的硬體資源,主要包括主機、存儲設備、輸入輸出設備以及計算一個完整的資料庫系統包括哪些部分?
Ⅲ 用資料庫做一個設備管理系統
課題1. 《設備管理信息系統》包括的實體類型有:n 固定資產(資產編號,資產名稱,型號規格,計量單位,價值,製造廠,出廠日期)n 部門(部門編號,部門名稱,負責人)n 折舊單(折舊單編號畝困,年折舊率,年折舊額,開始使用日期,全部使用年限,已使用年數,尚可使用年限)n 大修理單(修理單編號,修理日期,修理時限,修理費用,經手人)n 內部轉移單(轉移單編號,轉移日期,轉出部門,轉入部門),即該設備從一個部門調撥到另一個部門n 報廢單(報廢單編號,報迅薯念廢日期手好,經手人),指該設備已經到了使用年限,扔到廢品倉庫里n 清理單(清理單編號,資產原值,累計折舊金額,清理金額),從廢品倉庫里清理掉。n 《設備管理信息系統》包括的具體操作:n 自行補充實體之間的聯系n 輸入數據,每個表不少於10行數據,數據必須是有意義的n 實現設備報廢過程n 實現設備的內部轉移n 統計固定資產的已進行的大修費用n 列出兩個基本表的插入、更新和刪除記錄的操作(各舉1例)
Ⅳ 如何用資料庫做倉庫管理系統我只是學生完成老師作業的,不用太復雜。
n 系統簡介
給產品增加防偽方案, 讓產品經銷商和客戶在拿到產品時, 可以根據產品所帶的防偽號碼到廠家查詢, 確認產品是正品。這樣廠家和用戶的利益都可以得到保障, 合法經營的經銷商也會因此受益。
n 「竄貨「是分銷商或代理商受利益的驅動未經許可私自將產品轉向非所屬的經銷區域跨區域銷售,結果造成市場失調,供求關系失衡,價格體系破壞。使企業蒙受經濟損失,聲譽也遭到嚴重破壞。挫傷了代理商的積極性。
生產型企業來說,對產品信息的有效管理能力是企業具備競爭力的重要標志。隨著技術的革新與市場競爭的日益激烈,越來越多的企業迫切要求對其產品的製程、包裝、銷售、流通等信息進行採集、管理、追蹤。使用條形碼管理系統培攔,對倉儲各環節實施全過程式控制制管理,並可對貨物進行貨位、批次、保質期、配送等實現條形碼標簽序列號管理,對整個收貨、發貨、補貨、集貨、送貨等各個環節的規范化作業,還可以根據客戶的需求製作多種合理的統計報表.
條碼技術與信息技術的結合幫助企業合理有效地利用倉庫空間,以快速、准確、低成本的方式為客戶提供最好的服務。在對某公司的現行作業分析之後,我們擬訂一套成品管理和追蹤系統,幫助公司管理其成品,從產品裝箱之前,採集每一瓶酒之上的條形碼以及其裝箱之後箱的條形碼作為跟蹤產品的線索,實現對倉庫和成品防竄氏鏈貨的有效管理。條碼作為其身份ID,能唯一的標識其身份。
行業解決方案
1. 倉庫管理:對於現行倉庫而言都是基於人工的管理方式,無論是入庫還是出庫都有可能產生很多人為的失誤,造成公司盤點困難,倉庫核查成為難題。為了防止這種情況的頻繁發生,需要對倉庫進行規范化管理,從倉庫的入庫出庫到盤配核胡點,都使用條形碼來記錄相關信息,節省手工記錄的時間,減少人工操作的錯誤率。
2. 防竄貨管理:在貨物從總廠發出之後,各分公司出現竄貨的情況,為了有效防止竄貨,給定每一個貨物唯一的條形碼序列號,跟蹤其發貨記錄,使分公司和總公司能核對所發貨物是否正確。
功能模塊簡介
本系統包含條碼數據採集模塊、入庫管理模塊、出庫管理模塊、綜合查詢與報表模塊、系統維護與設定等模塊。
1. 系統功能模塊具體說明
1.1系統功能設置模塊
1.1.1 用戶管理
定義系統特殊組/用戶組/用戶三個管理對象。
1.1.2 口令管理
以用戶為單位,進行密碼的設定/修改等維護作業。
1.1.1 許可權管理
按組/用戶對象設定系統功能的使用許可權。
1.2基礎資料維護模塊
1.2.1 分銷商的管理
由於某公司有很多分公司銷售其產品,因此對其分銷商有效管理,包括:分銷商資料新增、刪除和編輯功能。
1.2.2 商品資料的管理
對公司生產的所有的產品信息進行管理,包括:產品的品名、規格型號、包裝規格(針對單瓶包裝、成箱包裝)。對所有的產品信息進行新增、刪除和編輯功能。 2 條碼規則制定模塊 3 條碼信息採集模塊
對於公司中需要成箱包裝的產品,定義其成箱包裝數為:N,當現場信息採集的時候,每採集N個條碼,系統自動生成一個貼在箱上的條碼,且把該條碼信息與其匹配的N個單瓶條碼信息綁定起來,記錄到資料庫中,作為入庫信息。此時已成功更改庫存信息。
a) 正常出庫管理模塊 b) 異常出庫管理模塊 c) 出庫重疊報警模塊,當出庫的時候,如果正常出庫產品序列號重復、異常出庫後出庫產品序列號和將要正常出庫的產品序列號重疊,庫存出錯,此時系統報警。 d) 分銷商數據管理模塊 e) 分銷商倉庫調撥模塊對於各分銷商倉庫庫存不均勻的時候,允許對其產品進行調撥處理。
4 報表與綜合查詢應用
4.1 按需定製各式報表
1、生產效率統計 2、按作業員/生產線統計日作業量,並進行相關分析 3、其它(需求規格說明書確定數量與規格)。
4.2 靈活強大的綜合查詢應用 1、按序列號查詢出庫/生產資料 2、其它(需求規格說明書確定具體查詢功能)
優異的軟體性能
1.集成性極強。包括對企業內部業務的完整整合能力以及對供應鏈外部資源的整合能力。具有開放的與流行電子商務平台集成的能力。
2.業界最先進的技術。
3.先進的管理理念和前瞻性考慮。
4.極強的擴展能力。
5.優秀的可維護性和極低的維護成本性能指標可支持的最大用戶數:無限制;可支持的最大並發用戶數:無限制;吞吐量:只受到網路帶寬的限制,系統本身無限制;響應速度:只受到網路帶寬的限制,系統本身無限制。
Ⅳ 資料庫進階:ERP管理軟體資料庫系統的幾種設計方法
自增長primary key
採用自增長primary key主要是性能 早期的資料庫系統 經常採用某種編號 比如身份證號碼 公司編號等等作為資料庫表的primary key 然而 很快 大家就發現其中的不利之處
比如早期的醫院管理系統 用身份證號碼作為病人表的primary key 然而 第一 不是每個人都有身份證;第二 對於國外來的病人 不同國家的病人的證件號碼並不見得沒有重復 因此 用身份證號碼作為病人表的primary key是一個非常糟糕的設計 考慮到沒有醫生或者護士會刻意去記這些號碼 使用自增長primary key是更好的設計
公司編號採用某種特定的編碼方法 這也是早期的資料庫系統常見的做法 它的缺點也顯而易見 很容易出現像千年蟲的軟體問題 因為當初設計資料庫表的時候設計的位數太短 導致系統使用幾年後不能滿足要求 只有修改程序才能繼續使用 問題在於 任何人設計系統的時候 在預計某某編號多少位可以夠用的時候 都存在預計不準的風險 而採用自增長primary key 則不存在這種問題 同樣的道理 沒有人可以去記這些號碼
使用自增長primary key另外一個原因是性能問題 略有編程常識的人都知道 數字大小比較比字元串大小比較要快得多 使用自增長primary key可以大大地提高數據查找速度
避免用復合主鍵 (pound primary key)
這主要還是因為性能問題 數據檢索是要用到大量的 primary key 值比較 只比較一個欄位比比較多個欄位快很多 使用單個primary key 從編程的角度也很有好處 sql 語句中 where 條件可以寫更少的代碼 這意味著出錯的機會大大減少
雙主鍵
雙主鍵是指資料庫表有兩個欄位 這兩個欄位獨立成為主鍵 但又同時存在 資料庫系統的雙主鍵最早用在用戶管理模塊 最早的來源可能是參照操作系統的用戶管理模塊
操作系統的用戶管理有兩個獨立的主鍵 操作系統自己自動生成的隨機 ID (Linux windows 的 SID) login id 這兩個 ID 都必須是唯一的 不同的是 刪除用戶 test 然後增加一個用戶 test SID 不同 login id 相同 採用雙主鍵主要目的是為了防止刪除後增加同樣的 login id 造成的混亂 比如銷售經理 hellen 本機共享文件給總經理 peter 一年後總經理離開公司 進來一個普通員工 peter 兩個peter 用同樣的 login id 如果只用 login id 作操作辯叢歷系統的用戶管理主鍵 則存在漏洞 普通員工 peter 可以訪問原來只有總經理才能看的文件 操作系統自己自動生成的隨機 ID 一般情況下面用戶是看不到的
雙主鍵現在已經廣泛用在各種資料庫系統中 不限於用戶管理系統
以固定的資料庫 表應付變化的客戶需求
這主要基於以下幾個因素的考慮
大型EPR系統的正常使用 維護需要軟體廠商及其眾多的合作夥伴共同給客戶提供技術服務 包括大量的二次開發攜搜
如果用戶在軟體正常使用過程中需要增加新的表或者資料庫 將給軟體廠商及其眾多的合作夥伴帶來難題
軟體升級的需要
沒有一個軟體能夠讓客戶使用幾十上百年不用升級的 軟體升級往往涉及資料庫表結構的改變 軟體廠商會做額外的程序將早期版本軟體的資料庫數據升級到新的版本 但是對於用戶使用過程中生成的表進行處理就比較為難
軟體開鄭絕發的需要
使用固定的資料庫庫表從開發 二次開發來說 更加容易 對於用戶使用過程中生成的表 每次查找數據時都要先查表名 再找數據 比較麻煩
舉例來說 早期的用友財務軟體用Access作資料庫 每年建立一個新的資料庫 很快 用戶和用友公司都發現 跨年度數據分析很難做 因此這是一個不好的設計 在 ERP 中 很少有不同的年度數據單獨分開 一般來說 所有年份的數據都在同一個表中 對於跨國公司甚至整個集團公司都用同一個 ERP 系統的時候 所有公司的數據都在一起 這樣的好處是數據分析比較容易做
現在大多數資料庫系統都能做到在常數時間內返回一定量的數據 比如 Oracle 資料庫中 根據 primary key 在 萬條數據中取 條數據 與在 億條數據中取 條數據 時間相差並不多
避免一次取資料庫大量數據 取大量數據一定要用分頁
這基本上是現在很多資料庫系統設計的基本守則 ERP 系統中超過 萬條數據的表很多 對於很多表中的任何一個 一次取所有的會導致資料庫伺服器長時間處於停滯狀態 並且影響其它在線用戶的系統響應速度
一般來說 日常操作 在分頁顯示的情況下面 每次取得數據在 之間 系統響應速度足夠快 客戶端基本沒有特別長的停頓 這是比較理想的設計 這也是大型資料庫系統往往用 ODBC ADO 等等通用的資料庫聯接組件而不用特定的速度較快的專用資料庫聯接組件的原因 因為系統瓶頸在於資料庫( Database) 方面(數據量大) 而不在於客戶端(客戶端每次只取少量數據)
在 B/S 資料庫系統中 分頁非常普遍 早期的資料庫系統經常有客戶端程序中一次性取大量數據做緩沖 現在已經不是特別需要了 主要原因有
資料庫本身的緩沖技術大大提高
大部分資料庫都會自動將常用的數據自動放在內存中緩沖 以提高性能
資料庫聯接組件的緩沖技術也在提高
包括 ADO 在內的一些資料庫聯接組件都會自動對數據結果集(result set)進行緩沖 並且效果不錯 比較新穎的資料庫聯接組件 比如 Hibernate 也加入了一些數據結果集緩沖功能
當然 也有一些資料庫聯接組件沒有對數據結果集進行緩沖 比如 JDBC Driver 不過幾年之內情況應該有所改觀 也有些不太成功的數據緩沖 比如 EJB 中的實體Bean 性能就不盡如人意 實體Bean數據也是放在內存中 可能是因為佔用內存過多的緣故
lishixin/Article/program/SQL/201311/16157
Ⅵ 利用Access 2003 製作一個資料庫管理系統(圖書管理),並實現其中的部分功能
①打開資料庫時能夠直接進入主界面:
菜單中選擇:工具=>啟動=>設置「顯示窗體/頁」
②在「財務科目管理窗體」中,添加新的財務科目,點擊「新建科目」按鈕時,系統將把「財務科目管理」窗體中其他所有控制項都清空,寫出實現該功能在「新建科目」按鈕的單擊事件代碼。
PrivateSubCommand0_Click()
OnErrorGoToErr_Command0_Click
DoCmd.GoToRecord,,acNewRec
Exit_Command0_Click:
ExitSub
Err_Command0_Click:
MsgBoxErr.Description
ResumeExit_Command0_Click
EndSub
③完成「保存科目」功能。在「財務科目管理窗體」中對應控制項內輸入待保存備猛科目的信息,點擊「保存科目」按鈕,將窗體中控制項內的值保存到「財務科目」數據表中。寫出實現該功能的事件代碼。
PrivateSubCommand1_Click()
OnErrorGoToErr_Command1_Click
DoCmd.DoMenuItemacFormBar,acRecordsMenu,acSaveRecord,,acMenuVer70
Exit_Command1_Click:
橡滾或Exit梁伍Sub
Err_Command1_Click:
MsgBoxErr.Description
ResumeExit_Command1_Click
EndSub
Ⅶ 資料庫管理系統怎麼用
SQL Server 是一個關系資料庫管理系統。它最初是由Microsoft Sybase 和Ashton-Tate三家公司共同開發的,於1988 年推出了第一個OS/2 版本。在Windows NT 推出後,Microsoft與Sybase 在SQL Server 的開發上就分道揚鑣了,Microsoft 將SQL Server 移植到Windows NT系統上,專注於開發推廣SQL Server 的Windows NT 版本。Sybase 則較專注於SQL Server在UNIX 操作系統上的應用。
SQL Server 2000 是Microsoft 公司推出的SQL Server 資料庫管理系統,該版本繼承了SQL Server 7.0 版本的優點,同時又比它增加了許多更先進的功能。具有使用方便可伸縮性好與相關軟體集成程度高等優點,可跨越從運行Microsoft Windows 98 的膝上型電腦到運行Microsoft Windows 2000 的大型多處理器的伺服器等多種平台使用。
Microsoft SQL Server 2005?
Microsoft SQL Server 2005 是一個全面的數搏孝襲據庫平台,使用集成的商業智能 (BI) 工具提供了企業級的數據管理。Microsoft SQL Server 2005 資料庫引擎為關系型數據和結構化數據提供了更安全可靠的存儲功能,使您可以構建和管理用於業務的高可用基兄和高性能的數據應用程序。
Microsoft SQL Server 2005 數據引擎是本企業數據管理解決方案的核心。此外 Microsoft SQL Server 2005 結合了分析、報表、集成和通知功能。這使您的企業可以構建和部署經濟有效的 BI 解決方案,幫助您的團隊通過記分卡、Dashboard、Web services 和移動設備將數據應用推向業務的各個領域。
與 Microsoft Visual Studio、Microsoft Office System 以及新的開發工具包(包括 Business Intelligence Development Studio)的緊密集成使 Microsoft SQL Server 2005 與眾不同。無論您是開發人員、資料庫管理員、信息工作者還是決策者,Microsoft SQL Server 2005 都可以為您提供創新的解決方案,幫助您從數據中更多地獲益。
Microsoft SQL Server 2008
Microsoft SQL Server 2008是一個重大的產品版本,它推出了許多新的特性和關鍵的改進,使得它成為至今為止的最強大和最全面的Microsoft SQL Server版本。這篇文章詳細介紹了Microsoft SQL Server 2008中的新的特性、優點和功能……
微軟的這個數據平台滿足這些數據爆炸和下一代數據驅動應用程序的需求,支持數據平台慎畢願景:關鍵任務企業數據平台、動態開發、關系數據和商業智能。