⑴ 資料庫設計主要包括哪幾部分，分別包括哪些內容
資料庫設計主要包括需求分析、概念結構設計、邏輯結構設計、物理結構設計、資料庫的實施和資料庫的運行和維護，具體內容如下：
1、需求分析
內容：調查和分析用戶的業務活動和數據的使用情況，弄清所用數據的種類、范圍、數量以及它們在業務活動中交流的情況，確定用戶對資料庫系統的使用要求和各種約束條件等，形成用戶需求規約。
2、概念設計
內容：對用戶要求描述的現實世界，通過對其中諸處的分類、聚集和概括，建立抽象的概念數據模型。這個概念模型應反映現實世界各部門的信息結構、信息流動情況、信息間的互相制約關系以及各部門對信息儲存、查詢和加工的要求等。
3、邏輯設計
內容：主要工作是將現實世界的概念數據模型設計成資料庫的一種邏輯模式，即適應於某種特定資料庫管理系統所支持的邏輯數據模式。與此同時，可能還需為各種數據處理應用領域產生相應的邏輯子模式。這一步設計的結果就是所謂「邏輯資料庫」。
4、物理設計
內容：根據特定資料庫管理系統所提供的多種存儲結構和存取方法等依賴於具體計算機結構的各項物理設計措施，對具體的應用任務選定最合適的物理存儲結構(包括文件類型、索引結構和數據的存放次序與位邏輯等)、存取方法和存取路徑等。
5、驗證設計
內容：收集數據並具體建立一個資料庫，運行一些典型的應用任務來驗證資料庫設計的正確性和合理性。一般，一個大型資料庫的設計過程往往需要經過多次循環反復。當設計的某步發現問題時，可能就需要返回到前面去進行修改。
6、運行與維護設計
內容：在資料庫系統正式投入運行的過程中，必須不斷地對其進行調整與修改。除了關系型資料庫已有一套較完整的數據範式理論可用來部分地指導資料庫設計之外，尚缺乏一套完善的資料庫設計理論、方法和工具，以實現資料庫設計的自動化或互動式的半自動化設計。
(1)語言資源資料庫建設包括哪些內容擴展閱讀：
重要性
1、有利於資源節約
對計算機軟體資料庫設計加以重視不僅可減少軟體後期的維修，達到節約人力與物力的目的，同時還有利於軟體功能的高效發揮。
2、有利於軟體運行速度的提高
高水平的資料庫設計可滿足不同計算機軟體系統對於運行速度的需求，而且還可充分發揮並實現系統功能。計算機軟體性能提高後，系統發出的運行指令在為用戶提供信息時也將更加快速有效，軟體運行速度自然得以提高。
3、有利於軟體故障的減少
加強資料庫設計可有效減少軟體故障的發生幾率，推動計算機軟體功能的實現。
⑵ 資料庫系統包括哪 幾個部分
資料庫系統一般包含以下幾個方面：
1、資料庫：
是指長期存儲在計算機內的，有組織，可共享的數據的集合。資料庫中的數據按一定的數學模型組織、描述和存儲，具有較小的冗餘，較高的數據獨立性和易擴展性，並可為各種用戶共享。
2、硬體：
構成計算機系統的各種物理設備，包括存儲所需的外部設備。硬體的配置應滿足整個資料庫系統的需要。
3、軟體：
包括操作系統、資料庫管理系統及應用程序。資料庫管理系統是資料庫系統的核心軟體，是在操作系統的支持下工作，解決如何科學地組織和存儲數據，如何高效獲取和維護數據的系統軟體。
4、人員：
第一類為系統分析員和資料庫設計人員，系統分析員負責應用系統的需求分析和規范說明。資料庫設計人員負責資料庫中數據的確定、資料庫各級模式的設計。
第二類為應用程序員，負責編寫使用資料庫的應用程序。第三類為最終用戶，他們利用系統的介面或查詢語言訪問資料庫。第四類用戶是資料庫管理員，負責資料庫的總體信息控制。
(2)語言資源資料庫建設包括哪些內容擴展閱讀：
資料庫系統的基本功能：
1、能夠保證數據的獨立性。數據和程序相互獨立有利於加快軟體開發速度，節省開發費用。
2、冗餘數據少，數據共享程度高。
3、系統的用戶介面簡單，用戶容易掌握，使用方便。
4、能夠確保系統運行可靠，出現故障時能迅速排除；能夠保護數據不受非受權者訪問或破壞；能夠防止錯誤數據的產生，一旦產生也能及時發現。
5、有重新組織數據的能力，能改變數據的存儲結構或數據存儲位置，以適應用戶操作特性的變化，改善由於頻繁插入、刪除操作造成的數據組織零亂和時空性能變壞的狀況。
參考資料來源：網路-資料庫系統
⑶ 中國語言資源有聲資料庫的簡介
中國擁有55個少數民族，除滿族和回族已使用通用漢語外，其他民族都有自己的語言，有些民族內部的不同支系還使用著不同的語言。因此，傳承和發展少數民族語言文字和文化，成為中國保護語言多樣性的關鍵工作。中國教育部民族教育司官員沙瑪加甲介紹說，中國各語言區逐步開展的雙語教學，有效地保護了民族語言。
國家語委於2008年啟動了「中國語言資源有聲資料庫建設」，按照科學、統一的規劃，調查收集當代漢語方言、少數民族語言和帶有地方特色的普通話的實態、有聲語料，並進行科學整理、加工和有效保存，為推進中國語言信息化、推廣普通話和社會文化建設服務。這是一項具有深遠意義的國家重大語言文字工程。
該有聲資料庫將依照統一規范，採集當代中國的漢語方言和帶有地方特色的普通話的有聲資料，採集中國各少數民族語言及其方言的有聲資料，並進行科學的整理加工，長期保存，以便將來深入研究和有效地開發利用，保護民族語言文化遺產。
⑷ 資料庫一般包括哪些內容，有哪些系統軟體
資料庫應用系統（簡稱資料庫系統）是指引進了資料庫技術後的整個計算機系統，它是由有關的硬體、軟體、數據和人員四個部分組合而形成的，為用戶提供信息服務的系統。
硬體環境是資料庫系統的物理支持，包括 CPU 、內存、外存及輸入/輸出設備。由於資料庫系統承擔著數據管理的任務，它要在操作系統的支持下工作，而且本身包含著資料庫管理例行程序、應用程序等，因此要有足夠大的內存開銷。同時，由於用戶的數據、系統軟體和應用軟體都要保存在外存上，所以對外存容量的要求也很高。
軟體系統包括系統軟體和應用軟體兩類。系統軟體主要包括資料庫管理系統軟體、開發應用系統的高級語言及其編譯系統、應用系統開發的工具軟體等。它們為開發應用系統提供了良好的環境，其中資料庫管理系統是連接資料庫和用戶之間的紐帶，是軟體系統的核心。應用軟體是指在資料庫管理系統的基礎上由用戶根據自己的實際需要自行開發的應用程序。
數據是資料庫系統的管理對象，是為用戶提供數據的信息源。
資料庫系統的人員是指管理、開發和使用資料庫系統的全部人員，主要包括資料庫管理員、系統分析員、應用程序員和用戶。不同的人員涉及不同的數據抽象級別，資料庫管理員負責管理和控制資料庫系統；系統分析員負責應用系統的需求分析和規范說明，確定系統的軟硬體配置、系統的功能及資料庫概念設計；應用程序員負責設計應用系統的程序模塊，根基資料庫的外模式來編寫應用程序；最總用戶通過應用系統提供的用戶介面界面使用資料庫。常用的介面方式有菜單驅動、圖形顯示、表格操作等，這些介面為用戶提供了簡明直觀的數據表示和方便快捷的操作方法。
⑸ 請簡要的敘述一下資料庫的主要設計過程
一、資料庫設計過程
資料庫技術是信息資源管理最有效的手段。
資料庫設計是指：對於一個給定的應用環境，構造最優的資料庫模式，建立資料庫及其應用系統，有效存儲數據，滿足用戶信息要求和處理要求。
資料庫設計的各階段：
A、需求分析階段：綜合各個用戶的應用需求(現實世界的需求)。
B、在概念設計階段：形成獨立於機器和各DBMS產品的概念模式(信息世界模型)，用E-R圖來描述。
C、在邏輯設計階段：將E-R圖轉換成具體的資料庫產品支持的數據模型，如關系模型，形成資料庫邏輯模式。然後根據用戶處理的要求，安全性的考慮，在基本表的基礎上再建立必要的視圖(VIEW)形成數據的外模式。
D、在物理設計階段：根據DBMS特點和處理的需要，進行物理存儲安排，設計索引，形成資料庫內模式。
1. 需求分析階段
需求收集和分析，結果得到數據字典描述的數據需求(和數據流圖描述的處理需求)。
需求分析的重點：調查、收集與分析用戶在數據管理中的信息要求、處理要求、安全性與完整性要求。
需求分析的方法：調查組織機構情況、各部門的業務活動情況、協助用戶明確對新系統的各種要求、確定新系統的邊界。
常用的調查方法有： 跟班作業、開調查會、請專人介紹、詢問、設計調查表請用戶填寫、查閱記錄。
分析和表達用戶需求的方法主要包括自頂向下和自底向上兩類方法。自頂向下的結構化分析方法(Structured Analysis，簡稱SA方法)從最上層的系統組織機構入手，採用逐層分解的方式分析系統，並把每一層用數據流圖和數據字典描述。
數據流圖表達了數據和處理過程的關系。系統中的數據則藉助數據字典(Data Dictionary，簡稱DD)來描述。
2. 概念結構設計階段
通過對用戶需求進行綜合、歸納與抽象，形成一個獨立於具體DBMS的概念模型，可以用E-R圖表示。
概念模型用於信息世界的建模。概念模型不依賴於某一個DBMS支持的數據模型。概念模型可以轉換為計算機上某一DBMS支持的特定數據模型。
概念模型特點：
(1) 具有較強的語義表達能力，能夠方便、直接地表達應用中的各種語義知識。
(2) 應該簡單、清晰、易於用戶理解，是用戶與資料庫設計人員之間進行交流的語言。
概念模型設計的一種常用方法為IDEF1X方法，它就是把實體-聯系方法應用到語義數據模型中的一種語義模型化技術，用於建立系統信息模型。
作者: 小靈, 出處:論壇, 責任編輯: 李書琴, 2007-09-27 15:17
本文詳細解析了資料庫設計過程、設計技巧以及總結了資料庫命名規范……
2.1 第零步——初始化工程
這個階段的任務是從目的描述和范圍描述開始，確定建模目標，開發建模計劃，組織建模隊伍，收集源材料，制定約束和規范。收集源材料是這階段的重點。通過調查和觀察結果，業務流程，原有系統的輸入輸出，各種報表，收集原始數據，形成了基本數據資料表。
2.2 第一步——定義實體
實體集成員都有一個共同的特徵和屬性集，可以從收集的源材料——基本數據資料表中直接或間接標識出大部分實體。根據源材料名字表中表示物的術語以及具有 「代碼」結尾的術語，如客戶代碼、代理商代碼、產品代碼等將其名詞部分代表的實體標識出來，從而初步找出潛在的實體，形成初步實體表。
2.3 第二步——定義聯系
IDEF1X模型中只允許二元聯系，n元聯系必須定義為n個二元聯系。根據實際的業務需求和規則，使用實體聯系矩陣來標識實體間的二元關系，然後根據實際情況確定出連接關系的勢、關系名和說明，確定關系類型，是標識關系、非標識關系(強制的或可選的)還是非確定關系、分類關系。如果子實體的每個實例都需要通過和父實體的關系來標識，則為標識關系，否則為非標識關系。非標識關系中，如果每個子實體的實例都與而且只與一個父實體關聯，則為強制的，否則為非強制的。如果父實體與子實體代表的是同一現實對象，那麼它們為分類關系。
2.4 第三步——定義碼
通過引入交叉實體除去上一階段產生的非確定關系，然後從非交叉實體和獨立實體開始標識侯選碼屬性，以便唯一識別每個實體的實例，再從侯選碼中確定主碼。為了確定主碼和關系的有效性，通過非空規則和非多值規則來保證，即一個實體實例的一個屬性不能是空值，也不能在同一個時刻有一個以上的值。找出誤認的確定關系，將實體進一步分解，最後構造出IDEF1X模型的鍵基視圖(KB圖)。
2.5 第四步——定義屬性
從源數據表中抽取說明性的名詞開發出屬性表，確定屬性的所有者。定義非主碼屬性，檢查屬性的非空及非多值規則。此外，還要檢查完全依賴函數規則和非傳遞依賴規則，保證一個非主碼屬性必須依賴於主碼、整個主碼、僅僅是主碼。以此得到了至少符合關系理論第三範式的改進的IDEF1X模型的全屬性視圖。
2.6 第五步——定義其他對象和規則
定義屬性的數據類型、長度、精度、非空、預設值、約束規則等。定義觸發器、存儲過程、視圖、角色、同義詞、序列等對象信息。
3. 邏輯結構設計階段
將概念結構轉換為某個DBMS所支持的數據模型(例如關系模型)，並對其進行優化。設計邏輯結構應該選擇最適於描述與表達相應概念結構的數據模型，然後選擇最合適的DBMS。
將E-R圖轉換為關系模型實際上就是要將實體、實體的屬性和實體之間的聯系轉化為關系模式,這種轉換一般遵循如下原則：一個實體型轉換為一個關系模式。實體的屬性就是關系的屬性。實體的碼就是關系的碼。
數據模型的優化，確定數據依賴，消除冗餘的聯系，確定各關系模式分別屬於第幾範式。確定是否要對它們進行合並或分解。一般來說將關系分解為3NF的標准，即：
表內的每一個值都只能被表達一次。
表內的每一行都應該被唯一的標識(有唯一鍵)。
表內不應該存儲依賴於其他鍵的非鍵信息。
作者: 小靈, 出處:論壇, 責任編輯: 李書琴, 2007-09-27 15:17
本文詳細解析了資料庫設計過程、設計技巧以及總結了資料庫命名規范……
4. 資料庫物理設計階段
為邏輯數據模型選取一個最適合應用環境的物理結構(包括存儲結構和存取方法)。根據DBMS特點和處理的需要，進行物理存儲安排，設計索引，形成資料庫內模式。
5. 資料庫實施階段
運用DBMS提供的數據語言(例如SQL)及其宿主語言(例如C)，根據邏輯設計和物理設計的結果建立資料庫，編制與調試應用程序，組織數據入庫，並進行試運行。 資料庫實施主要包括以下工作：用DDL定義資料庫結構、組織數據入庫 、編制與調試應用程序、資料庫試運行 ，(Data Definition Language(DDL數據定義語言)用作開新數據表、設定欄位、刪除數據表、刪除欄位，管理所有有關資料庫結構的東西)
●Create (新增有關資料庫結構的東西，屬DDL)
●Drop (刪除有關資料庫結構的東西，屬DDL)
●Alter (更改結構，屬DDL)
6. 資料庫運行和維護階段
在資料庫系統運行過程中必須不斷地對其進行評價、調整與修改。內容包括：資料庫的轉儲和恢復、資料庫的安全性、完整性控制、資料庫性能的監督、分析和改進、資料庫的重組織和重構造。
7. 建模工具的使用
為加快資料庫設計速度，目前有很多資料庫輔助工具(CASE工具)，如Rational公司的Rational Rose，CA公司的Erwin和Bpwin，Sybase公司的PowerDesigner以及Oracle公司的oracle Designer等。
ERwin主要用來建立資料庫的概念模型和物理模型。它能用圖形化的方式，描述出實體、聯系及實體的屬性。ERwin支持IDEF1X方法。通過使用 ERwin建模工具自動生成、更改和分析IDEF1X模型，不僅能得到優秀的業務功能和數據需求模型，而且可以實現從IDEF1X模型到資料庫物理設計的轉變。ERwin工具繪制的模型對應於邏輯模型和物理模型兩種。在邏輯模型中，IDEF1X工具箱可以方便地用圖形化的方式構建和繪制實體聯系及實體的屬性。在物理模型中，ERwin可以定義對應的表、列，並可針對各種資料庫管理系統自動轉換為適當的類型。
設計人員可根據需要選用相應的資料庫設計建模工具。例如需求分析完成之後，設計人員可以使用Erwin畫ER圖，將ER圖轉換為關系數據模型，生成資料庫結構;畫數據流圖，生成應用程序。
二、資料庫設計技巧
1. 設計資料庫之前(需求分析階段)
1) 理解客戶需求，包括用戶未來需求變化。
2) 了解企業業務類型，可以在開發階段節約大量的時間。
3) 重視輸入(要記錄的數據)、輸出(報表、查詢、視圖)。
4) 創建數據字典和ER 圖表
數據字典(Data Dictionary，簡稱DD)是各類數據描述的集合，是關於資料庫中數據的描述，即元數據，不是數據本身。(至少應該包含每個欄位的數據類型和在每個表內的主外鍵)。
數據項描述: 數據項名，數據項含義說明，別名，數據類型，長度，取值范圍，取值含義，與其他數據項的邏輯關系
數據結構描述: 數據結構名，含義說明，組成:[數據項或數據結構]
數據流描述: 數據流名，說明，數據流來源，數據流去向， 組成:[數據結構]，平均流量，高峰期流量
數據存儲描述: 數據存儲名，說明，編號，流入的數據流，流出的數據流，組成:[數據結構]，數據量，存取方式
處理過程描述: 處理過程名，說明，輸入:[數據流]，輸出:[數據流]，處理:[簡要說明]
ER 圖表和數據字典可以讓任何了解資料庫的人都明確如何從資料庫中獲得數據。ER圖對表明表之間關系很有用，而數據字典則說明了每個欄位的用途以及任何可能存在的別名。對SQL 表達式的文檔化來說這是完全必要的。
5) 定義標準的對象命名規范
資料庫各種對象的命名必須規范。
作者: 小靈, 出處:論壇, 責任編輯: 李書琴, 2007-09-27 15:17
本文詳細解析了資料庫設計過程、設計技巧以及總結了資料庫命名規范……
2. 表和欄位的設計(資料庫邏輯設計)
表設計原則
1) 標准化和規范化
數據的標准化有助於消除資料庫中的數據冗餘。標准化有好幾種形式，但Third Normal Form(3NF)通常被認為在性能、擴展性和數據完整性方面達到了最好平衡。簡單來說，遵守3NF 標準的資料庫的表設計原則是：「One Fact in One Place」即某個表只包括其本身基本的屬性，當不是它們本身所具有的屬性時需進行分解。表之間的關系通過外鍵相連接。它具有以下特點：有一組表專門存放通過鍵連接起來的關聯數據。
2) 數據驅動
採用數據驅動而非硬編碼的方式，許多策略變更和維護都會方便得多，大大增強系統的靈活性和擴展性。
舉例，假如用戶界面要訪問外部數據源(文件、XML 文檔、其他資料庫等)，不妨把相應的連接和路徑信息存儲在用戶界面支持的表裡。如果用戶界面執行工作流之類的任務(發送郵件、列印信箋、修改記錄狀態等)，那麼產生工作流的數據也可以存放在資料庫里。角色許可權管理也可以通過數據驅動來完成。事實上，如果過程是數據驅動的，你就可以把相當大的責任推給用戶，由用戶來維護自己的工作流過程。
3) 考慮各種變化
在設計資料庫的時候考慮到哪些數據欄位將來可能會發生變更。
4) 表名、報表名和查詢名的命名規范
(採用前綴命名)檢查表名、報表名和查詢名之間的命名規范。你可能會很快就被這些不同的資料庫要素的名稱搞糊塗了。你可以統一地命名這些資料庫的不同組成部分，至少你應該在這些對象名字的開頭用 Table、Query 或者 Report 等前綴加以區別。如果採用了 Microsoft Access，你可以用 qry、rpt、tbl 和 mod 等符號來標識對象(比如 tbl_Employees)。用 sp_company 標識存儲過程，用 udf_ (或者類似的標記)標識自定義編寫的函數。
欄位設計原則：
1) 每個表中都應該添加的3 個有用的欄位。
dRecordCreationDate，在SQL Server 下默認為GETDATE()
sRecordCreator，在SQL Server 下默認為NOT NULL DEFAULT USER
nRecordVersion，記錄的版本標記;有助於准確說明記錄中出現null 數據或者丟失數據的原因
時效性數據應包括「最近更新日期/時間」欄位。時間標記對查找數據問題的原因、按日期重新處理/重載數據和清除舊數據特別有用。
2) 對地址和電話採用多個欄位
描述街道地址就短短一行記錄是不夠的。Address_Line1、Address_Line2 和Address_Line3 可以提供更大的靈活性。還有，電話號碼和郵件地址最好擁有自己的數據表，其間具有自身的類型和標記類別。
3) 表內的列[欄位]的命名規則(採用前綴/後綴命名)、採用有意義的欄位名
對列[欄位]名應該採用標準的前綴和後綴。如鍵是數字類型：用 _N 後綴;字元類型：_C 後綴;日期類型：_D 後綴。再如，假如你的表裡有好多「money」欄位，你不妨給每個列[欄位]增加一個 _M 後綴。
作者: 小靈, 出處:論壇, 責任編輯: 李書琴, 2007-09-27 15:17
本文詳細解析了資料庫設計過程、設計技巧以及總結了資料庫命名規范……
假設有兩個表：
Customer 和 Order。Customer 表的前綴是 cu_，所以該表內的子段名如下：cu_name_id、cu_surname、cu_initials 和cu_address 等。Order 表的前綴是 or_，所以子段名是：
or_order_id、or_cust_name_id、or_quantity 和 or_description 等。
這樣從資料庫中選出全部數據的 SQL 語句可以寫成如下所示：
Select * From Customer, Order Where cu_surname = "MYNAME" ;
and cu_name_id = or_cust_name_id and or_quantity = 1
在沒有這些前綴的情況下則寫成這個樣子(用別名來區分)：
Select * From Customer, Order Where Customer.surname = "MYNAME" ;
and Customer.name_id = Order.cust_name_id and Order.quantity = 1
第 1 個 SQL 語句沒少鍵入多少字元。但如果查詢涉及到 5 個表乃至更多的列[欄位]你就知道這個技巧多有用了。
5) 選擇數字類型和文本類型的長度應盡量充足
假設客戶ID 為10 位數長。那你應該把資料庫表欄位的長度設為12 或者13 個字元長。但這額外占據的空間卻無需將來重構整個資料庫就可以實現資料庫規模的增長了。
6) 增加刪除標記欄位
在表中包含一個「刪除標記」欄位，這樣就可以把行標記為刪除。在關系資料庫里不要單獨刪除某一行;最好採用清除數據程序而且要仔細維護索引整體性。
7) 提防大小寫混用的對象名和特殊字元
採用全部大寫而且包含下劃符的名字具有更好的可讀性(CUSTOMER_DATA)，絕對不要在對象名的字元之間留空格。
8) 小心保留詞
要保證你的欄位名沒有和保留詞、資料庫系統或者常用訪問方法沖突，比如，用 DESC 作為說明欄位名。後果可想而知!DESC 是 DESCENDING 縮寫後的保留詞。表裡的一個 SELECT * 語句倒是能用，但得到的卻是一大堆毫無用處的信息。
9) 保持欄位名和類型的一致性
在命名欄位並為其指定數據類型的時候一定要保證一致性。假如欄位在表1中叫做「agreement_number」，就別在表2里把名字改成 「ref1」。假如數據類型在表1里是整數，那在表2里可就別變成字元型了。當然在表1(ABC)有處鍵ID，則為了可讀性，在表2做關聯時可以命名為 ABC_ID。
10) 避免使用觸發器
觸發器的功能通常可以用其他方式實現。在調試程序時觸發器可能成為干擾。假如你確實需要採用觸發器，你最好集中對它文檔化。
作者: 小靈, 出處:論壇, 責任編輯: 李書琴, 2007-09-27 15:17
本文詳細解析了資料庫設計過程、設計技巧以及總結了資料庫命名規范……
3. 選擇鍵和索引(資料庫邏輯設計)
參考：《SQL優化-索引》一文
4. 數據完整性設計(資料庫邏輯設計)
1) 完整性實現機制：
實體完整性：主鍵
參照完整性：
父表中刪除數據：級聯刪除;受限刪除;置空值
父表中插入數據：受限插入;遞歸插入
父表中更新數據：級聯更新;受限更新;置空值
DBMS對參照完整性可以有兩種方法實現：外鍵實現機制(約束規則)和觸發器實現機制用戶定義完整性：
NOT NULL;CHECK;觸發器
2) 用約束而非商務規則強制數據完整性
採用資料庫系統實現數據的完整性。這不但包括通過標准化實現的完整性而且還包括數據的功能性。不要依賴於商務層保證數據完整性;它不能保證表之間(外鍵) 的完整性所以不能強加於其他完整性規則之上。如果你在數據層確實採用了約束，你要保證有辦法把更新不能通過約束檢查的原因採用用戶理解的語言通知用戶界面。
3) 強制指示完整性
在有害數據進入資料庫之前將其剔除。激活資料庫系統的指示完整性特性。這樣可以保持數據的清潔而能迫使開發人員投入更多的時間處理錯誤條件。
4) 使用查找控制數據完整性
控制數據完整性的最佳方式就是限制用戶的選擇。只要有可能都應該提供給用戶一個清晰的價值列表供其選擇。這樣將減少鍵入代碼的錯誤和誤解同時提供數據的一致性。某些公共數據特別適合查找：國家代碼、狀態代碼等。
5) 採用視圖
為了在資料庫和應用程序代碼之間提供另一層抽象，可以為應用程序建立專門的視圖而不必非要應用程序直接訪問數據表。這樣做還等於在處理資料庫變更時給你提供了更多的自由。
6) 分布式數據系統
對分布式系統而言，在你決定是否在各個站點復制所有數據還是把數據保存在一個地方之前應該估計一下未來 5 年或者 10 年的數據量。當你把數據傳送到其他站點的時候，最好在資料庫欄位中設置一些標記，在目的站點收到你的數據之後更新你的標記。為了進行這種數據傳輸，請寫下你自己的批處理或者調度程序以特定時間間隔運行而不要讓用戶在每天的工作後傳輸數據。本地拷貝你的維護數據，比如計算常數和利息率等，設置版本號保證數據在每個站點都完全一致。
7) 關系
如果兩個實體之間存在多對一關系，而且還有可能轉化為多對多關系，那麼你最好一開始就設置成多對多關系。從現有的多對一關系轉變為多對多關系比一開始就是多對多關系要難得多。
8) 給數據保有和恢復制定計劃
考慮數據保存策略並包含在設計過程中，預先設計你的數據恢復過程。採用可以發布給用戶/開發人員的數據字典實現方便的數據識別同時保證對數據源文檔化。編寫在線更新來「更新查詢」供以後萬一數據丟失可以重新處理更新。
9) 用存儲過程讓系統做重活
提供一整套常規的存儲過程來訪問各組以便加快速度和簡化客戶程序代碼的開發。資料庫不只是一個存放數據的地方，它也是簡化編碼之地。
本文詳細解析了資料庫設計過程、設計技巧以及總結了資料庫命名規范……
5. 其他設計技巧
1) 避免使用觸發器
觸發器的功能通常可以用其他方式實現。在調試程序時觸發器可能成為干擾。假如你確實需要採用觸發器，你最好集中對它文檔化。
2) 使用常用英語(或者其他任何語言)而不要使用編碼
在創建下拉菜單、列表、報表時最好按照英語名排序。假如需要編碼，可以在編碼旁附上用戶知道的英語。
3) 保存常用信息
讓一個表專門存放一般資料庫信息非常有用。在這個表裡存放資料庫當前版本、最近檢查/修復(對Access)、關聯設計文檔的名稱、客戶等信息。這樣可以實現一種簡單機制跟蹤資料庫，當客戶抱怨他們的資料庫沒有達到希望的要求而與你聯系時，這樣做對非客戶機/伺服器環境特別有用。
4) 包含版本機制
在資料庫中引入版本控制機制來確定使用中的資料庫的版本。時間一長，用戶的需求總是會改變的。最終可能會要求修改資料庫結構。把版本信息直接存放到資料庫中更為方便。
5) 編制文檔
對所有的快捷方式、命名規范、限制和函數都要編制文檔。
採用給表、列、觸發器等加註釋的 資料庫工具。對開發、支持和跟蹤修改非常有用。
對資料庫文檔化，或者在資料庫自身的內部或者單獨建立文檔。這樣，當過了一年多時間後再回過頭來做第2 個版本，犯錯的機會將大大減少。
6) 測試、測試、反復測試
建立或者修訂資料庫之後，必須用用戶新輸入的數據測試數據欄位。最重要的是，讓用戶進行測試並且同用戶一道保證選擇的數據類型滿足商業要求。測試需要在把新資料庫投入實際服務之前完成。
7) 檢查設計
在開發期間檢查資料庫設計的常用技術是通過其所支持的應用程序原型檢查資料庫。換句話說，針對每一種最終表達數據的原型應用，保證你檢查了數據模型並且查看如何取出數據。
三、資料庫命名規范
1. 實體(表)的命名
1) 表以名詞或名詞短語命名，確定表名是採用復數還是單數形式，此外給表的別名定義簡單規則(比方說，如果表名是一個單詞，別名就取單詞的前4 個字母;如果表名是兩個單詞，就各取兩個單詞的前兩個字母組成4 個字母長的別名;如果表的名字由3 個單片語成，從頭兩個單詞中各取一個然後從最後一個單詞中再取出兩個字母，結果還是組成4 字母長的別名，其餘依次類推)
對工作用表來說，表名可以加上前綴WORK_ 後面附上採用該表的應用程序的名字。在命名過程當中，根據語義拼湊縮寫即可。注意：將欄位名稱會統一成大寫或者小寫中的一種，故中間加上下劃線。
作者: 小靈, 出處:論壇, 責任編輯: 李書琴, 2007-09-27 15:17
本文詳細解析了資料庫設計過程、設計技巧以及總結了資料庫命名規范……
舉例：
定義的縮寫 Sales: Sal 銷售;
Order: Ord 訂單;
Detail: Dtl 明細;
則銷售訂單明細表命名為：Sal_Ord_Dtl;
2) 如果表或者是欄位的名稱僅有一個單詞，那麼建議不使用縮寫，而是用完整的單詞。
舉例：
定義的縮寫 Material Ma 物品;
物品表名為：Material, 而不是 Ma.
但是欄位物品編碼則是：Ma_ID;而不是Material_ID
3) 所有的存儲值列表的表前面加上前綴Z
目的是將這些值列表類排序在資料庫最後。
4) 所有的冗餘類的命名(主要是累計表)前面加上前綴X
冗餘類是為了提高資料庫效率，非規范化資料庫的時候加入的欄位或者表
5) 關聯類通過用下劃線連接兩個基本類之後，再加前綴R的方式命名,後面按照字母順序羅列兩個表名或者表名的縮寫。
關聯表用於保存多對多關系。
如果被關聯的表名大於10個字母，必須將原來的表名的進行縮寫。如果沒有其他原因，建議都使用縮寫。
舉例：表Object與自身存在多對多的關系,則保存多對多關系的表命名為：R_Object;
作者: 小靈, 出處:論壇, 責任編輯: 李書琴, 2007-09-27 15:17
本文詳細解析了資料庫設計過程、設計技巧以及總結了資料庫命名規范……
2. 屬性(列)的命名
1) 採用有意義的列名
表內的列要針對鍵採用一整套設計規則。每一個表都將有一個自動ID作為主健,邏輯上的主健作為第一組候選主健來定義;
A、如果是資料庫自動生成的編碼，統一命名為：ID
B、如果是自定義的邏輯上的編碼則用縮寫加「ID」的方法命名，即「XXXX_ID」
C、如果鍵是數字類型，你可以用_NO 作為後綴;
D、如果是字元類型則可以採用_CODE 後綴
E、對列名應該採用標準的前綴和後綴。
舉例：銷售訂單的編號欄位命名：Sal_Ord_ID;如果還存在一個資料庫生成的自動編號，則命名為：ID。
2) 所有的屬性加上有關類型的後綴
注意，如果還需要其它的後綴，都放在類型後綴之前。
注: 數據類型是文本的欄位，類型後綴TX可以不寫。有些類型比較明顯的欄位，可以不寫類型後綴。
3) 採用前綴命名
給每個表的列名都採用統一的前綴，那麼在編寫SQL表達式的時候會得到大大的簡化。這樣做也確實有缺點，比如破壞了自動表連接工具的作用，後者把公共列名同某些資料庫聯系起來。
3. 視圖的命名
1) 視圖以V作為前綴，其他命名規則和表的命名類似;
2) 命名應盡量體現各視圖的功能。
4. 觸發器的命名(盡量不使用)
觸發器以TR作為前綴，觸發器名為相應的表名加上後綴，Insert觸發器加'_I'，Delete觸發器加'_D'，Update觸發器加'_U'，如：TR_Customer_I，TR_Customer_D，TR_Customer_U。
5. 存儲過程名
存儲過程應以'UP_'開頭，和系統的存儲過程區分，後續部分主要以動賓形式構成，並用下劃線分割各個組成部分。如增加代理商的帳戶的存儲過程為'UP_Ins_Agent_Account'。
6. 變數名
變數名採用小寫，若屬於片語形式，用下劃線分隔每個單詞，如@my_err_no。
7. 命名中其他注意事項
1) 以上命名都不得超過30個字元的系統限制。變數名的長度限制為29(不包括標識字元@)。
2) 數據對象、變數的命名都採用英文字元，禁止使用中文命名。絕對不要在對象名的字元之間留空格。
3) 小心保留詞，要保證你的欄位名沒有和保留詞、資料庫系統或者常用訪問方法沖突
4) 保持欄位名和類型的一致性，在命名欄位並為其指定數據類型的時候一定要保證一致性。假如數據類型在一個表裡是整數，那在另一個表裡可就別變成字元型了。
⑹ 簡述一個資料庫應用系統的建立過程
資料庫建立過程包括六個主要步驟：
1．需求分析：了解用戶的數據需求、處理需求、安全和完整性需求。
2．概念設計：通過數據抽象，設計系統的概念模型，一般為e－r模型。
3．邏輯結構設計：設計系統的模式和外部模式，特別是關系模型的基本表和視圖。
4．物理結構設計：設計數據的存儲結構和訪問方法，如索引的設計。
5．系統實現：組織數據存儲，編寫應用程序，試運行。
6．運維：系統投入運行，進行長期維護。
(6)語言資源資料庫建設包括哪些內容擴展閱讀：
資料庫設計技巧：
1．原始文檔與實體之間的關系
它可以是一對一、一對多、多對多。一般來說，它們是一對一的關系：也就是說，原始文檔只對應於一個實體，而且只對應於一個實體。在特殊情況下，它們可能是一對多或多對一的，其中一個原始文檔對應多個實體，或者多個原始文檔對應一個實體。
這里的實體可以理解為基本表。在明確了這些對應關系之後，這對於輸入介面的設計是非常有益的。
2．主鍵和外鍵
通常，實體不能同時沒有主鍵和外鍵。在e－r關系圖中，葉中的實體可以定義主鍵，也可以不定義主鍵（因為它沒有後代），但是它必須有外鍵（因為它有父鍵）。
主鍵和外鍵的設計在全局資料庫的設計中起著重要的作用。當全球資料庫的設計完成後，一位美國的資料庫設計專家說：「鑰匙，鑰匙無處不在，只有鑰匙」，這是他的資料庫設計經驗，也是他高度抽象的信息系統核心思想（數據模型）的體現。
因為：主鍵是實體的高度抽象，主鍵和外鍵對，表示實體之間的連接。
3．基本表的屬性
基表不同於中間表和臨時表，因為它有以下四個特點：
原子性。基表中的欄位沒有分解。
原始性。基表中的記錄是原始數據（底層數據）的記錄。
先驗性。所有輸出數據都可以從基表和代碼表中的數據派生出來。
穩定。表的基本結構比較穩定，表中的記錄保存時間較長。
一旦理解了基本表的性質，就可以在設計資料庫時將它們與中間表和臨時表區分開。
⑺ 資料庫建設
（一）數據准備
1.數據收集
1∶25萬遙感地質填圖數據包含影像數據和矢量數據兩種格式，影像數據主要包括：TM原始影像、SPOT原始影像、SAR原始影像、TM與SPOT融合影像、TM與SAR融合影像、信息增強分類處理後的整幅影像或影像子區；矢量數據主要包括：航磁等值線影像、1∶25萬地形圖、地質圖、航磁解譯地質圖、遙感解譯單元圖、遙感解譯地質圖。現以新疆瓦石峽地區、內蒙古阿龍山地區為例，具體情況如下：
（1）瓦石峽地區
TM衛星影像
SAR衛星影像
航磁等值線（TIF）影像
航磁解譯地質圖
地質圖
遙感解譯影像單元圖
遙感解譯地質圖
（2）阿龍山地區
TM衛星影像
SPOT衛星影像
航磁等值線（TIF）影像
地質圖
航磁解譯地質圖
遙感解譯地質圖
2.數據預處理
1）影像數據處理，主要針對原始影像數據
（1）將TM原始影像、SPOT原始影像、SAR原始影像、航磁等值線（.JPG）數據格式轉換為ERDAS的.IMG格式。
（2）對轉換後的IMG文件進行投影轉換。投影系採用6度分帶的橫軸墨卡托（Transverse Mercator）投影，投影參數為：
Units：Meters
Scale Factor：1.0
Longitude Of Center：123 00 00
Latitude Of Center：0 00 00
False Easting：500 KM
False Northing：0 KM
Xshift：0
Yshift：0
橢球（spheroid）體採用克拉索夫（Krasovsky）橢球，參數為：
SemiMajor：6378245.0000 Meters
SemiMinor：6356863.0188 Meters
坐標系採用大地坐標，度量單位為米，這樣可以在GIS系統中方便的量算特徵的長度和面積。
（3）圖像坐標糾正
參照地形圖選擇同名點，對影像數據進行坐標精校正。同名點的選擇不少於12個。
2）矢量數據處理
工作主要針對地質圖、航磁解譯地質圖、遙感解譯單元圖、遙感解譯地質圖。
（1）數據分層
根據圖面特徵信息內容和制圖要求，每幅矢量圖按特徵類型劃分為點、線、面（區）三個圖層。劃分的依據是遙感地質解譯圖件的信息不完全等同於其他地質調查圖件，它表現的內容主要是：從影像圖中判讀出的地層、岩石影像單元及構造界線，但各種地質特徵的單位、時代、分類、度量、結構、方向等的描述不是十分具體，因此在屬性定義上比較一致，對一個圖件不需要產生基於同一特徵類型的專題圖層，因此按矢量特徵類型劃分較為合理、簡便。
（2）圖件掃描矢量化
將地質、影像單元等圖件掃描成 TIF影像文件，按照分層要求，將每個圖件數字化為點、線、面三個圖層文件。處理的圖件和產生的矢量圖層文件見表3-1至3-7。
表3-1 矢量圖層表
1∶25萬遙感地質填圖方法和技術
c.面特徵：由於影像單元圖的面特徵描述有其特殊之處，有時遵照地層、岩石的分類方法國家標准，但絕大部分是按照影像顏色、紋理等劃分和稱謂，因此進行分類編碼十分困難，有待進一步研究解決。
以上編碼方法是在每種特徵類型組合最大值和預留一定的擴充餘地的基礎上編制的，編碼方案參照國標：GB958—89區域地質圖圖例（1∶5萬）
（6）屬性定義
說明：由於地質代號的組成方式極為復雜，使用了上下角標、希臘字元、拉丁字母等，而這些字元和格式在純文本的屬性欄位中是不能完全或准確表達的，因此在錄入時對地質代號進行了一些簡化。
例如：Pt2xh簡化為Pt2xh
簡化為An1—3
（二）建立資料庫
GIS空間資料庫有兩種存儲形式：一是基於文件索引的傳統空間資料庫管理體系；二是採用商用關系資料庫的解決方案，二者各有千秋。第一種結構是對應用的集成，而數據是鬆散的，雖不利於數據的集中管理，但對不同系統平台之間共享數據提供了很大方便，特別是數據較少的小型應用系統。這種結構的另外一個可取之處是方案簡單，工作量小，不需要資料庫方面的專業知識。第二種結構既是應用的集成，也是數據的集成，並且提供所有的RDBMS的數據和安全管理優勢，但它需要專用的空間數據引擎，對其他軟體使用數據是一個極大的限制，必須進行數據的導入導出和格式轉換，並且要求使用者對RDBMS有一定的操作和管理經驗。
由於本集成系統採用的是ARC/INFO和ERDAS軟體，它們之間只能達到文件方式的數據共享，雖然ARC/INFO 8提供了GeoDataBase這種關系資料庫管理模式，實現真正的空間數據集中管理和RDBMS所有的數據管理能力，但為了滿足兩個軟體之間數據的交互處理，本系統採用文件索引形式的資料庫。在數據完備的基礎上，建庫工作需以下兩個步驟：
（1）首先創建基於項目的不同格式、不同類型的目錄樹工作區，把所有數據文件分類保存在這個工作區中，工作區框架以瓦石峽幅數據為例（圖3-5）。
（2）然後在 ARC/INFO 的 ARCMAP中新建一個 MAP DOCUMENT（以下簡稱為文檔），添加所有數據文件到文檔中。文檔中每個數據文件都被稱為一個 LAYER（以下簡稱為層），每個矢量層可以有它自己的環境，文檔可以保存環境的變化。使用者只需打開這個文檔即可調用項目所有的數據文件，並且恢復到上一次工作時的狀態。
圖3-5 數據分層結構圖
在MAP DOCUMENT這種集成的數據環境下，使用者可以採用ARC/INFO 8的ARCEDITOR、ARCMAP參照影像圖層進行矢量化的解譯工作，對已形成的圖件直接進行圖形和屬性編輯，進行輔助解譯的空間分析，對各種圖件進行疊加比較，使用文字標簽或屬性欄位標注特徵，按照分類符號化特徵，製作專題圖，列印輸出圖件報表等，實現一系列與遙感解譯有關的功能和操作。
由於ARC/INFO提供的地質圖式圖例和符號不能滿足我國的地質成圖要求，因此制圖軟體採用地質行業較為通用的MAPGIS。通過ARCTOOLS工具將最終的解譯成果矢量地質圖轉換為ARC/INFO的標准交換格式E00，提交給MAPGIS形成繪圖文件，出版印刷。具體的實施方案和技術流程見「成果圖件製作方法研究」一節。
⑻ 教育教學資源庫建設包括哪些方面
教育教學資源庫應該具備以下功能：
能夠進行方便、快捷的信息檢索；教師可以自行添加資源；資源種類齊全、科學；要有一定的許可權設置；系統維護簡單。它主要包括以下模塊
（1）資源管理模塊
資源管理模塊的操作對象是資源庫中的各類資源，在進行操作時要保證內容的安全性和可靠性。這一模塊具備的功能主要包括：
資源上載：允許在線的教師和教育工作人員進行單個或多個資源的上載。 資源下載：注冊用戶可以下載免費的資源。
資源審核：審核管理員主要負責對教師上載的資源進行評審，以確定是否發布該資源。
資源查詢：用戶根據查詢條件，輸入關鍵字查詢相應的資源。
資源刪除：資源審核員或系統管理員可以刪除不符合標准和過期的資源。
（2）系統管理模塊。
系統管理模塊主要負責對這個系統的維護工作，以保證系統的穩定性和可擴展性及對並發訪問的支持。應具備的功能有：
資源庫系統的初始化：屬性、參數數據入庫
訪問控制：對訪問本資源庫系統的用戶數量的控制，可採取限定ip或限定訪問流量的方法。
安全控制：使用防火牆等措施以保證系統不受病毒侵蝕和黑客的攻擊。
（3）用戶管理模塊
教育資源庫有其特定的用戶群，其中應為不同用戶賦予各自的許可權，從而確保系統的安全性和資源的質量。一般可以包括：系統管理員、資源審核員、教師、學生和遊客（未注冊用戶），如有特殊的需求，還可視具體情況而變動。他們的許可權應設置如下：
系統管理員應對資料庫系統有完整的控制權，允許他以瀏覽器方式通過internet實施管理和維護，掌握所有用戶的情況，並具有初始化資源庫系統和審核注冊用戶的許可權。
資源審核員：根據管理員分配的許可權，主要負責對相應學科下的資源進行審核和管理。
教師：主要負責對某一特定學科的資源進行管理，包括瀏覽、查詢、使用和上載和審核該學科的資源。
學生：可以瀏覽、查詢、上載和下載信息庫中的資源。 遊客：可以瀏覽、查詢和上載資源。