A. 數據質量包括什麼方面
數據質量包括數據質量控制和數據治理。
數據是組織最具價值的資產之一。企業的數據質量與業務績效之間存在著直接聯系，高質量的數據可以使公司保持競爭力並在經濟動盪時期立於不敗之地。有了普遍深入的數據質量，企業在任何時候都可以信任滿足所有需求的所有數據。
一個戰略性和系統性的方法能幫助企業正確研究企業的數據質量項目，業務部門與 IT 部門的相關人員將各自具有明確角色和責任，配備正確的技術和工具，以應對數據質量控制的挑戰。
(1)用戶資料庫質量擴展閱讀：
控制方法：
1、探查數據內容、結構和異常
第一步是探查數據以發現和評估數據的內容、結構和異常。通過探查，可以識別數據的優勢和弱勢，幫助企業確定項目計劃。一個關鍵目標就是明確指出數據錯誤和問題，例如將會給業務流程帶來威脅的不一致和冗餘。
2、建立數據質量度量並明確目標
Informatica的數據質量解決方案為業務人員和IT人員提供了一個共同的平台建立和完善度量標准，用戶可以在數據質量記分卡中跟蹤度量標準的達標情況，並通過電子郵件發送URL來與相關人員隨時進行共享。
3、設計和實施數據質量業務規則
明確企業的數據質量規則，即，可重復使用的業務邏輯，管理如何清洗數據和解析用於支持目標應用欄位和數據。業務部門和IT部門通過使用基於角色的功能，一同設計、測試、完善和實施數據質量業務規則，以達成最好的結果。
4、將數據質量規則構建到數據集成過程中
Informatica Data Quality支持普遍深入的數據質量控制，使用戶可以從擴展型企業中的任何位置跨任何數量的應用程序、在一個基於服務的架構中作為一項服務來執行業務規則。
數據質量服務由可集中管理、獨立於應用程序並可重復使用的業務規則構成，可用來執行探查、清洗、標准化、名稱與地址匹配以及監測。
5、檢查異常並完善規則
在執行數據質量流程後，大多數記錄將會被清洗和標准化，並達到企業所設定的數據質量目標。然而，無可避免，仍會存在一些沒有被清洗的劣質數據，此時則需要完善控制數據質量的業務規則。Informatica Data Quality可捕獲和突顯數據質量異常和異常值，以便更進一步的探查和分析。
5、對照目標，監測數據質量
數據質量控制不應為一次性的「邊設邊忘」活動。相對目標和在整個業務應用中持續監測和管理數據質量對於保持和改進高水平的數據質量性能而言是至關重要的。
Informatica Data Quality包括一個記分卡工具，而儀錶板和報告選項則具備更為廣泛的功能，可進行動態報告以及以更具可視化的方式呈現。
B. 求一份SQL server資料庫課程設計報告
2.2需求分析
（1）需求分析的任務
需求分析的任務是通過詳細調查現實世界要處理的對象（組織、部門、企業等），充分了解原系統（手工系統或計算機系統）工作概況，明確用戶的各種需求，用通俗的話來講，就是分析了解用戶關心什麼，用戶需要什麼樣的結果，然後在此基礎上分析和設計新系統的資料庫。
需求分析的重點是調查、收集與分析用戶在數據管理中的信息要求、處理要求、安全性與完整性要求。
信息要求
是指用戶需要從資料庫中獲得信息的內容與性質。由用戶的信息要求可以導出數據要求，即在資料庫中需要存儲哪些數據。
處理要求
是指用戶要求完成什麼處理功能，對處理的響應時間有什麼要求，處理方式是批處理還是聯機處理。
安全性與完整性要求
一是指用戶對系統和數據有什麼安全性要求，如不同級別的用戶具有什麼操作許可權和使用哪些數據；二是對數據的輸入和存儲的什麼要求，如數據的長度和范圍、數據的有效性、一致性和唯一性等。
確定用戶的最終需求其實是一件很困難的事，這是因為一方面用戶缺少計算機知識，開始時無法確定計算機究竟能為自己做什麼，不能做什麼，因此無法一下子准確地表達自己的需求，他們所提出的需求往往不斷地變化。另一方面設計人員缺少用戶的專業知識，不易理解用戶的真正需求，甚至誤解用戶的需求。因此設計人員必須與用戶不斷深入地進行溝通和交流，才能逐步得以確定用戶的實際需求。
（2）需求分析的基本步驟
1．調查與初步分析用戶的需求，確定系統的功能邊界
⑴首先調查組織機構情況
⑵然後調查各部門的業務活動情況
⑶協助用戶明確對新系統的各種要求
⑷確定新系統的結構和功能邊界，確定哪些功能由計算機完成或將來由計算機完成，哪些活動由人工完成。
常用的調查方法有：
⑴跟班作業
⑵開調查會
⑶請專人介紹
⑷詢問
⑸問卷調查
⑹查閱記錄
2．生成數據字典
1）數據項條目：數據項是不可再分的數據單位，它直接反映事物的某一特徵。
2）數據結構條目：反映了數據之間的組合關系。
3）數據流條目：數據流是數據結構在系統內傳輸的路徑。
4）數據文件條目：數據文件是數據項停留或保存的地方，也是數據流的來源和去向之一。
5）處理過程條目。
(3) 案例分析：教學管理系統資料庫的需求分析
用戶的需求具體體現在各種信息的提供、保存、更新和查詢上，這就要求資料庫的結構能充分滿足各種信息的輸出和輸入。需求分析階段主要是收集基本數據，確定數據結構及數據處理的流程，組成一份詳盡的數據字典，以便為後面的概念設計和邏輯設計打下基礎。
2．3概念結構設計
概念結構設計是對收集來的信息和數據進行分析整理，確定實體、屬性及聯系，形成獨立於計算機的反映用戶觀點的概念模型。概念設計的重點在於信息結構的設計，它是整個資料庫系統設計的關鍵。
（1）概念結構設計的目標和任務
概念結構設計的目標是產生反映系統信息需求的資料庫概念結構，即概念模式。概念結構是獨立於DBMS和使用的硬體環境的。在這一階段，設計人員要從用戶的角度看待數據以及數據處理的要求和約束，產生一個反映用戶觀點的概念模式，然後再把概念模式轉換為邏輯模式。
概念模型的表示方法很多，其中最著名、最常用的表示方法為實體-聯系方法，這種方法也稱為E-R模型方法，該方法採用E-R圖描述概念模型。
E-R圖提供了表示實體、屬性和聯系的方法，它由以下三個組件構成：
實體---用矩形表示，矩形框內寫明實體名。
屬性---用橢圓形表示，並用無向邊將其與相應的實體連接起來。
聯系---用菱形表示，菱形框內寫明聯系名，並用無向邊分別與有關實體連接起來，同時在無向邊旁標上聯系的類型（1:1、1:n或m:n）。
例如教學管理系統中的學生實體與課程實體的E-R圖如下圖表示：
（2）概念結構設計的過程
●數據抽象
概念結構是對現實世界的一種抽象，所謂抽象就是對實際的人、事、物和概念進行加工處理，抽取所關心的共同特性，用各種概念精確的加以描述，組成某種模型。
在需求分析中，已初步得到了有關各類實體、實體間的聯系以及描述它們性質的數據元素，統稱數據對象。
在這一階段中，首先要從以上數據對象中找出：系統有哪些實體？每個實體有哪些屬性？哪些實體間存在聯系？每一種聯系有哪些屬性？然後就可以做出系統的局部E-R模型和全局E-R模型。
● 局部E-R模型設計
局部E-R模型設計是從數據流圖出發確定實體和屬性，並根據數據流圖中表示的對數據的處理、確定實體之間的聯系。
設計局部E-R圖的步驟是：
1．確定實體類型和屬性
實體和屬性之間沒有嚴格的區別界限，但對於屬性來講，可以用下面的兩條准則作為依據：
1）作為屬性必須是不可再分的數據項，也就是屬性中不能再包含其他的屬性。
2）屬性不能與其他實體之間具有聯系。
2．確定實體間的聯系
依據需求分析結果，考察任意兩個實體類型之間是否存在聯系，若有，則確定其類型（一對一，一對多或多對多）。
3．畫出局部E-R圖
確定了實體及實體間的聯系後，可用E-R圖描述出來。形成局部E-R圖之後，還必須返回去徵求用戶意見，使之如實地反映現實世界，同時還要進一步規范化，以求改進和完善。每個局部E-R圖必須滿足：
（1）對用戶需求是完整的。
（2）所有實體、屬性、聯系都有惟一的名字。
（3）不允許有異名同義、同名異義的現象。
● 全局E-R模型的設計
各個局部E-R模型建立好後，還需要對它們進行合並，集成為一個整體的數據概念結構，即總E-R圖。在合並全局E-R模型時，應注意檢查和消除屬性、命名的沖突及數據冗餘。
（3）案例分析：教學管理系統資料庫的概念結構設計
通過上面的需求分析，就可以進行資料庫的概念結構設計，先對現實當中的人、事、物和概念進行抽象的加工處理，抽取所關心的共同特性，用各種概念進行描述，從中找出能夠滿足用戶需求的各種實體，以及它們之間的關系，並用實體-聯系圖表示出來(即畫出E-R圖)，為後面的邏輯結構設計打下基礎。
1、確定實體及其屬性
經過對人工進行的教學管理系統的業務調查，得知系統主要涉及以下幾個實體：
● 學生實體：屬性主要包括班級名稱、學號、姓名、性別、出生日期、民族、政治面貌、來源地、入學成績、學生類別、電話、備注等。
● 教師實體：屬性主要包括教師號、教師姓名、性別、出生日期、所在系、職稱
● 班級實體：屬性主要包括系部名稱、班級號、班級名稱、班主任、學生人數、備注等。
● 系部實體：屬性主要包括系號、系部名稱、班級數等。
● 課程實體：屬性主要包括課程號、課程名、考核方式、學分、學時數等。
2、確定實體之間的聯系
2．4 邏輯結構設計
（1）邏輯結構設計的目標和任務
邏輯結構設計的目標就是把概念結構設計階段設計好的E-R圖轉換為特定的DBMS所支持的數據模型(即層次、網狀、關系模型之一)，並對其進行優化。
概念模型向邏輯模型的轉換過程分為3步進行：
（1）把概念模型轉換為一般的數據模型。
（2）將一般的數據模型轉換成特定的DBMS所支持的數據模型。
（3）通過優化方法將其轉化為優化的數據模型。
(2) 概念模型轉換為一般的關系模型
1．實體的轉換規則
將E-R圖中的每一個常規實體轉換為一個關系，實體的屬性就是關系的屬性，實體的碼就是關系的碼。
2．實體間聯系的轉換規則
1）一個1：1聯系可以轉換為各自獨立的關系模式，也可以與任意一端所對應的關系模式合並。
2）一個1 : n聯系可以轉換為各自獨立的關系模式。
3）一個m : n聯系轉換為一個關系模式。轉換的方法為：與該聯系相連的各實體的碼以及聯系本身的屬性均轉換為關系的屬性，新關系的碼為兩個相連實體碼的組合
(3) 案例分析：教學管理系統資料庫的邏輯結構設計
邏輯結構設計的任務是把概念結構設計階段設計好的E-R圖轉換為特定的DBMS所支持的數據模型(即層次、網狀、關系模型之一)，並對其進行優化，得到滿足用戶要求和系統功能需求的關系模式。
1、 E-R模型轉換為關系模式
將E-R模型轉換成初始關系模式的一般規則是：系統中各個實體轉換為對應的關系模式；實體之間多對多的聯系也轉換為關系模式。
根據轉換規則，可以將系部、班級、學生、教師、課程五個實體轉換成與之對應的五個關系模式；而將學生與課程兩者之間多對多的選修關系以及教師、班級和課程三者之間多對多的開課關系也轉換為關系模式。
2、關系模式的設計
根據上述的轉換結果，在對關系模式中數據進行規范化處理後，得到了符合第三範式的關系模式如下：
學生：{學號、姓名、性別、出生日期、民族、政治面貌、來源地、入學成績、學生類別、班級名稱、電話、備注}
班級：{班級號、班級名稱、班主任、學生人數、系部名稱、備注}
系部：{系號、系部名稱、班級數}
教師：{教師號、教師姓名、性別、出生日期、所在系、職稱}
課程：{課程號、課程名、考核方式、學分、學時數}
選修：{學號、課程號、成績}
開課： {教師號、班級名稱、課程號、開課學期、授課地點}
每個關系模式中帶下劃線的屬性或屬性的組合表示主鍵、帶雙波浪線的屬性表示與之關聯的表的外鍵。
根據系統功能需求，數據採用SQL Server 2000所支持的實際數據模型，也就是資料庫的邏輯結構。啟動SQL Server 2000，創建一個資料庫命名為:jxgl。該資料庫中各個數據表的結構如下面各個表格所示。每個表格對應於資料庫中的一個表。
3、將關系模式轉換為資料庫中的表
按照關系數據模型的結構，將關系模式轉換為關系資料庫中的數據表，轉換的規則是：一個關系模式轉換為一個數據表，關系模式中的每個屬性轉換為數據表中的一個列。同時設置表中各個列的名稱、數據類型、數據寬度以及數據規則，得到如下幾個表：
學生表(student)
列名 類型 寬度 規則
班級名稱 CHAR 20 內容取自班級信息表的班級名稱
學號 CHAR 10 主鍵、長度為10個字元
姓名 CHAR 8
性別 CHAR 2 非空、只能取「男」或「女」
出生日期 DATETIME
民族 CHAR 4 假定只能取以下之一：漢、壯、白、回、苗、滿、其它
政治面貌 CHAR 4 只能取以下之一：黨員、團員、群眾
來源地 CHAR 10
入學成績 INT
學生類別 CHAR 10 假定只能取以下之一：本科、大專（普）、大專（業）、中專、技校、函授、其它
電話 CHAR 11
備注 CHAR 10
註：(1)該表存放全校所有學生的基本信息，每個學生產生一條記錄。
(2)學號的前4位表示年級，第5--8位表示班級號(其中第5-6位表示系號, 第7-8位表示系內班級號)，最後兩位是班內的學生編號，在輸入記錄內容時應加以區分。
班級表(class)
列名 類型 寬度 規則
系部名稱 CHAR 10 非空、內容取自系部信息表的系部名稱
班級號 CHAR 4 非空、長度為4個字元
班級名稱 CHAR 20 主鍵
班主任 CHAR 8
學生人數 INT
備注 CHAR 10
註：(1)該表存放全校所有班級的信息，每個班級產生一條記錄。
(2)班級號的前2位表示系號，後兩位為系內的班級編號，在輸入記錄內容時應加以區分。
系部表(department)
列名 類型 寬度 規則
系號 CHAR 2 非空、長度為2個字元
系部名稱 CHAR 10 主鍵
班級數 INT
註：該表存放某校所有的系部信息，每個系部產生一條記錄。
教師表(teacher)
列名 類型 寬度 規則
教師號 CHAR 4 主鍵、長度為4個字元
姓名 CHAR 8
性別 CHAR 2 非空、只能取「男」或「女」
出生日期 DATETIME
職稱 CHAR 6 只能取以下之一：教授、副教授、講師、助教、其他
所在系 CHAR 20 非空、外鍵(內容取自系部表的系部名稱)
課程表(course)
列名 類型 寬度 規則
課程號 CHAR 4 主鍵、長度為4個字元
課程名 CHAR 20
考核方式 CHAR 4 假定只能取以下之一：考試、考查、其他
學分 INT 非空
學時數 INT
註：該表存放某校所有的課程信息，每門課產生一條記錄。
成績表(SC)
列名 類型 寬度 規則
學號 CHAR 8 主鍵、內容取自學生信息表的學生姓名
課程號 CHAR 20 主鍵、內容取自課程信息表的課程名稱
成績 INT
註：該表存放某校所有學生的成績信息，每個學生學習每門課程產生一條記錄。
開課信息表(tcc)
列名 類型 寬度 規則
教師號 CHAR 4 主鍵、內容取自教師信息表的教師號
課程號 CHAR 4 主鍵、內容取自課程信息表的課程號
班級號 CHAR 4 主鍵、內容取自班級信息表的班級號
開課學期 CHAR 20
授課地點 CHAR 20
註：該表存放某校開設課程的信息，每個教師教授某個班級的某門課產生一條記錄。
2. 5 物理設計
資料庫的物理設計目標是在選定的DBMS上建立起邏輯設計結構確立的資料庫結構，這一過程也稱為資料庫的物理實現。它主要包括兩項工作：
一是根據資料庫的結構、系統的大小、系統需要完成的功能及對系統的性能要求，決定選用哪個資料庫管理系統。目前，資料庫產品市場上比較好的產品有：Microsoft SQL Server、Oracle、IBM DB/2，SYBASE等。
二是根據選用的資料庫管理系統的資料庫實現方法來建立用戶資料庫，即創建所需要的資料庫、表及其他資料庫對象。
本系統選用的DBMS是SQL Server 2000，並在該系統上創建用戶資料庫jxgl以及下屬的7個用戶表：student、class、department、teacher、course、sc、tcc，各個表的結構按2.4節第3點各表給出的具體內容設定。
2. 5 實訓二
以小組討論的形式，完成人事工資管理系統用戶資料庫的設計，要求個人寫出用戶資料庫設計的文檔（包括資料庫的需求分析、概念設計、邏輯設計和物理設計，表達方法可參考本章相應內容的案例分析部分），每個小組上交一份本系統用戶資料庫包括的數據表。
第三章 資料庫的數據完整性設計
3．1數據完整性的基本概念及內容
正確創建資料庫後，需要考慮數據的完整性、數據的安全性等要求。數據的完整性主要指數據的正確性、有效性、相容性，強制實施數據完整性可以確保資料庫中的數據的質量。
進行數據完整性設計主要考慮以下幾個方面的內容：
1)表名惟一；
由系統強制實施控制。
2)列名惟一；()
由系統強制實施控制。
3)數據行惟一；
通過設置主鍵約束或觸發器來實施控制。
4)列值非空；
通過設置非空約束來實施控制。
5)列值惟一性
通過設置惟一約束或惟一索引來實施控制。
6)列值滿足一定的條件
通過設置檢查約束或觸發器來實施控制。
7)數據的一致性和有效性
通過設置外鍵約束或觸發器來實施控制。
至於具體要對資料庫的哪一個表的哪一項數據進行什麼樣的數據完整性設計，還應根據用戶的需求來考慮和確定。
3．2 數據完整性的分類與實現方法
在SQL Server關系資料庫中，數據完整性分為以下三類：
1. 域完整性
域完整性是指一個列的輸入有效性，是否允許空值。實現域完整性的方法主要有：限制數據類型（通過設定列的數據類型）、限定格式（通過CHECK約束和規則）或可能值的范圍（通過 FOREIGN KEY 約束、CHECK 約束、DEFAULT定義、NOT NULL定義和規則）以及程序控制。
2. 實體完整性
實體完整性是指保證表中所有的行唯一。實現實體完整性的方法主要有：索引、UNIQUE約束、PRIMARY KEY約束或 IDENTITY屬性以及程序控制。
3. 參照完整性
參照完整性也叫引用完整性。參照完整性確保主鍵（被引用表）和外鍵（引用表）之間的參照關系。它涉及兩個或兩個以上表數據的一致性維護。如student表(稱為引用表、參照表或子表)的class_id列就是參照class表(稱為被引用表、被參照表或父表)的外鍵。參照完整性可以實現以下兩種控制：
(1)存在外鍵時，被參照表中的這一行不能被刪除，主鍵值也不能改變 (以student和class表的「班級名稱」列為例說明)。
(2)若在被參照表中不存在包含相應主鍵的行時，一個外鍵值不能插入參照表中(MsgBox "添加記錄成功！", vbOKOnly + vbInformation, "提示"
End Sub
Private Sub Command5_Click()
rs.Close
Unload Me
End Sub
Private Sub Form_Load()
rs.CursorLocation = adUseClient ' 設置在客戶端創建游標
rs.CursorType = adOpenKeyset '設置游標類型為鍵集類型
rs.LockType = adLockOptimistic '設置打開記錄集時的鎖定類型為樂觀鎖，在執行UPdate方法前不鎖定編輯的數據
rs.Open "select * from teacher", cnn
'在表格上顯示class表的記錄內容
Set DataGrid1.DataSource = rs
DataGrid1.Refresh
'將表格上的數據與文本框或下拉列表框綁定
Set Text1.DataSource = rs
Text1.DataField = "教師號"
Set Text2.DataSource = rs
Text2.DataField = "姓名"
Set Combo1.DataSource = rs
Combo1.DataField = "所在系"
Set Text3.DataSource = rs
Text3.DataField = "出生日期"
Set Text4.DataSource = rs
Text4.DataField = "從教日期"
Set Combo2.DataSource = rs
Combo2.DataField = "性別"
Set Combo3.DataSource = rs
Combo3.DataField = "職稱"
Set Combo4.DataSource = rs
Combo4.DataField = "政治面貌"
Set Combo5.DataSource = rs
Combo5.DataField = "學歷"
Set Text7.DataSource = rs
Text7.DataField = "家庭住址"
Set Text5.DataSource = rs
Text5.DataField = "聯系電話"
Set Text6.DataSource = rs
Text6.DataField = "備注"
'下拉列表框提供班級名稱
Combo1.Clear
rs1.Open "select 系部名稱 from department", cnn
While Not rs1.EOF()
Combo1.AddItem Trim(rs1.Fields("系部名稱"))
rs1.MoveNext
Wend
rs1.Close
End Sub
對其餘幾個表的數據進行增、刪、改操作的窗體的設計方法與上述類擬。
C. 資料庫管理員DBA的職責、系統分析員和資料庫設計人員的職責、應用程序員的職責
資料庫管理員負責全面管理和控制資料庫系統，包括資料庫的安裝、監控、備份、恢復等基本工作。
系統分析員的主要職責是對軟體項目進行整體規劃、需求分析、設計軟體的核心架構、指導和領導項目開發小組進行軟體開發和軟體實現，並對整個項目進行全面的管理工作。
資料庫設計人員的職責包括：需求分析、概念結構設計、邏輯結構設計、物理結構設計、資料庫的實施和資料庫的運行和維護。
應用程序員的職責：對項目經理負責，負責軟體項目的詳細設計、編碼和內部測試的組織實施，對小型軟體項目兼任系統分析工作，完成分配項目的實施和技術支持工作。協助項目經理和相關人員同客戶進行溝通，保持良好的客戶關系。參與需求調研、項目可行性分析、技術可行性分析和需求分析。
熟悉並熟練掌握交付軟體部開發的軟體項目的相關軟體技術。負責向項目經理及時反饋軟體開發中的情況，並根據實際情況提出改進建議。參與軟體開發和維護過程中重大技術問題的解決，參與軟體首次安裝調試、數據割接、用戶培訓和項目推廣。負責相關技術文檔的擬訂。負責對業務領域內的技術發展動態進行分析研究。
(3)用戶資料庫質量擴展閱讀
產品的整個生命周期里資料庫管理員的職責重要而廣泛，這催生了各個縱向的運維技術方向，凡是關繫到資料庫質量、效率、成本、安全等方面的工作，及涉及到的技術、組件，主要包括：
資料庫監控技術：包括監控平台的研發、應用，服務監控准確性、實時性、全面性的保障。
資料庫故障管理：包括服務的故障預案設計，預案的自動化執行，故障的總結並反饋到產品/系統的設計層面進行優化以提高產品的穩定性。
資料庫容量管理：測量服務的容量，規劃服務的機房建設，擴容、遷移等工作。
資料庫性能優化：從各個方向，包括SQL優化、參數優化、應用優化、客戶端優化等，提高資料庫的性能和響應速度，改善用戶體驗。
資料庫安全保障：包括資料庫的訪問安全、防攻擊、許可權控制等。
資料庫自動部署：部署平台/工具的研發，及平台/工具的使用，做到安全、高效的發布服務。
資料庫集群管理：包括資料庫的伺服器管理、分布式集群管理等。
資料庫模型設計：包括資料庫邏輯和物理模型的設計，如何實現性能最優，架構可擴展，服務可運維等。
D. 如何確保數據，信息的准確性，完整性，可靠性，及時性，安全性和保密性
數據完整性（Data Integrity）是
指數據的精確性（Accuracy） 和可靠性（Reliability）。它是應防止資料庫中存在不符合語義規定的數據和防止因錯誤信息的輸入輸出造成無效操作或錯誤信息而提出的。數據完整性分為四類：實體完整性（Entity Integrity）、域完整
性（Domain Integrity）、參照完整性（Referential Integrity）、用戶定義的完整性（User-definedIntegrity）。
保證數據的完整性:
用約束而非商務規則強制數據完整性
如果你按照商務規則來處理需求，那麼你應當檢查商務層次/用戶界面：如果商務規則以後發生變化，那麼只需要進行更新即可。
假如需求源於維護數據完整性的需要，那麼在資料庫層面上需要施加限制條件。
如果你在數據層確實採用了約束，你要保證有辦法把更新不能通過約束檢查的原因採用用戶理解的語言通知用戶界面。除非你的欄位命名很冗長，否則欄位名本身還不夠。 — Lamont Adams
只要有可能，請採用資料庫系統實現數據的完整性。這不但包括通過標准化實現的完整性而且還包括數據的功能性。在寫數據的時候還可以增加觸發器來保證數據的正確性。不要依賴於商務層保證數據完整性；它不能保證表之間（外鍵）的完整性所以不能強加於其他完整性規則之上。
— Peter Ritchie
2. 分布式數據系統
對分布式系統而言，在你決定是否在各個站點復制所有數據還是把數據保存在一個地方之前應該估計一下未來5 年或者10 年的數據量。當你把數據傳送到其他站點的時候，最好在資料庫欄位中設置一些標記。在目的站點收到你的數據之後更新你的標記。為了進行這種數據傳輸，請寫下你自己的批處理或者調度程序以特定時間間隔運行而不要讓用戶在每天的工作後傳輸數據。本地拷貝你的維護數據，比如計算常數和利息率等，設置版本號保證數據在每個站點都完全一致。
— Suhair TechRepublic
3. 強制指示完整性
沒有好辦法能在有害數據進入資料庫之後消除它，所以你應該在它進入資料庫之前將其剔除。激活資料庫系統的指示完整性特性。這樣可以保持數據的清潔而能迫使開發人員投入更多的時間處理錯誤條件。
— kol
4. 關系
如果兩個實體之間存在多對一關系，而且還有可能轉化為多對多關系，那麼你最好一開始就設置成多對多關系。從現有的多對一關系轉變為多對多關系比一開始就是多對多關系要難得多。
— CS Data Architect
5. 採用視圖
為了在你的資料庫和你的應用程序代碼之間提供另一層抽象，你可以為你的應用程序建立專門的視圖而不必非要應用程序直接訪問數據表。這樣做還等於在處理資料庫變更時給你提供了更多的自由。
— Gay Howe
6. 給數據保有和恢復制定計劃
考慮數據保有策略並包含在設計過程中，預先設計你的數據恢復過程。採用可以發布給用戶/開發人員的數據字典實現方便的數據識別同時保證對數據源文檔化。編寫在線更新來「更新查詢」供以後萬一數據丟失可以重新處理更新。
— kol
7. 用存儲過程讓系統做重活
解決了許多麻煩來產生一個具有高度完整性的資料庫解決方案之後，我所在的團隊決定封裝一些關聯表的功能組，提供一整套常規的存儲過程來訪問各組以便加快速度和簡化客戶程序代碼的開發。在此期間，我們發現3GL 編碼器設置了所有可能的錯誤條件，比如以下所示：
SELECT Cnt = COUNT (*)
FROM [<Table>]
WHERE [<primary key column>] = <new value>
IF Cnt = 0
BEGIN
INSERT INTO [<Table>]
( [< primary key column>] )
VALUES ( <New value> )
ELSE
BEGIN
<indicate plication error>
而一個非3GL 編碼器是這樣做的：
INSERT INTO [<Table>]
( [< primary key column>] )
VALUES
( <New value> )
IF @@ERROR = 2627 -- Literal error code for Primary Key Constraint
BEGIN
<indicate plication error>
第2 個程序簡單多了，而且事實上，利用了我們給資料庫的功能。雖然我個人不喜歡使用嵌入文字（2627）。但是那樣可以很方便地用一點預先處理來代替。資料庫不只是一個存放數據的地方，它也是簡化編碼之地。
— a-smith
8. 使用查找
控制數據完整性的最佳方式就是限制用戶的選擇。只要有可能都應該提供給用戶一個清晰的價值列表供其選擇。這樣將減少鍵入代碼的錯誤和誤解同時提供數據的一致性。某些公共數據特別適合查找：國家代碼、狀態代碼等
E. 數據入庫質量控制的方法實現
資料庫數據質量是資料庫的生命，再好的入庫數據質量控制的方法，如果得不能貫徹和執行，也不能保證入庫數據的正確性。所以，基於上述入庫數據質量控制思想，研發了航空物探資料庫數據採集軟體（圖5-3），強制數據入庫工作按規范化的流程執行，保證資料庫數據質量。
數據採集軟體包括數據導入錄入、數據檢查、數據編輯、數據歸檔入庫等功能，為了方便數據採集人員工作，把本系統應用軟體中的數據查詢統計和數據制圖功能也集成到該軟體中。各部分功能分述如下。
圖5-3 資料庫數據採集軟體結構
一、創建項目樹
航空物探勘查項目工作一般分為航空物探生產測量、數據處理和地質解釋3個階段，野外生產測量和數據處理完成之後分別編寫航空物探生產報告和數據處理報告，通過評審後須上交測量資料和處理後的數據。此時，地質解釋工作正進行。
航空物探科研項目工作一般是分課題（二級項目）、課題分子課題（三級項目）等進行的。級別低的項目總是最先完成，然後評審和上交資料；級別較高的項目較後完成，一級項目最後完成，最後上交資料。
如果把勘查項目的3個階段當成3個課題（事實上的確如此，只是習慣上不這樣叫），勘查項目和科研項目不僅在工作形式上是一致的，資料上交的次序也是相同的（圖5-5）。這種按項目完成的先後次序進行項目資料歸檔方式，在資料人工管理人工服務時代，人們並沒有覺得有什麼問題。只是，資料管理方式的變革，人們對資料服務提出了更高的要求，希望資料信息化管理不要再忽視不同級別項目間的關系信息。
這種關系與計算機磁碟文件管理的目錄間關系是相似的，目錄等同於項目，子目錄等同於子項目。目錄、子目錄間的關系似樹形結構，稱為目錄樹；項目、子項目間的關系也似樹形結構，稱之為項目樹。有計算機常識的人都知道，按照一定的方式建立目錄樹，把文件存在相應目錄下，不僅文件管理更有條理，用戶查找文件的速度也成倍提高。因此，本系統採用項目樹方式來管理項目資料。該管理方式符合人們的思維習慣，資料查詢更方便。
圖5-4 資料庫數據採集軟體主界面
圖5-5 不同級別項目資料歸檔次序圖
在新項目數據導入或錄入資料庫之前，須先創建項目樹。建項目樹與在磁碟上創建文件目錄相似，按項目（目錄）、子項目（子目錄）順序創建，不能倒行逆施。然後，按項目導入或錄入數據。圖5-6為創建項目樹界面。用戶在父項目的下拉框中選擇新建項目的父項目（一級項目為null），再填寫項目的檔案號等信息後，按「確定」創建項目樹的根項目（一級項目），或項目樹的一個節點（子項目），並自動為項目分配一個項目標識號，作為識別項目和項目資料的唯一標志。
圖5-6 創建項目樹功能界面
二、數據錄入和導入
項目數據進入資料庫有數據錄入和數據導入兩種方式。數據錄入方式是使用系統的數據錄入界面將數據直接錄入到數據採集庫中。若用戶已按入庫數據介面標准要求整理好入庫數據，可採用導入方式將數據導入到數據採集庫中。其實，這兩種方式沒有本質上的差別。例如，項目概況數據、空間要素類（岩石物性、異常、解釋評價）屬性數據等都必須是人工錄入的，區別是誰來錄入?資料整理人員，還是數據採集人員?這不屬本系統的研究范疇，系統支持這兩種數據入庫方式。
因資料庫的每張表所包含的信息不同，所以每張表都應有獨立的數據錄入界面（錄入、瀏覽、編輯數據）。加之用戶查詢界面、數據統計界面，1張資料庫表需要3個用戶界面。本系統共有地球物理資料庫表31張，按照常規做法需要開發93個用戶界面。隨著航空物探技術發展，可能在資料庫表中增加新的信息，或新增資料庫表，都需要通過修改軟體代碼來滿足新的需求。該方法不僅軟體研發和測試工作量大，後期軟體維護工作量也很大。
為此，本系統研究出根據資料庫表的描述信息動態生成用戶界面的方法，此方法具有很好的通用性，對資料庫的所有表均適用，有效地降低了軟體開發工作量，方便了後期軟體維護。圖5-7是使用該方法動態生成的項目概況數據錄入界面，用於項目概況數據的錄入和編輯。
圖5-7 項目概況數據的錄入定製界面
該方法是將資料庫表的描述信息存儲在資料庫中的庫表屬性清單表中，在運行時系統根據資料庫表名稱從庫表屬性清單表和其相關的數據字典表中提取該表對應的欄位信息，然後調用界面定製函數，根據界面類型（錄入、瀏覽、修改、簡單查詢）動態生成相應的界面。
由於資料庫表包含的欄位數相差較大（多的近30個欄位，少的不到10個欄位）、同一表的欄位類型不同（有字元串、數字、時間、大欄位）、欄位數據類型長度不一（有的欄位長度為200個字元，有的只有1個字元），同時庫表的相關欄位在界面上相鄰擺放較合適，針對這些問題在界面定製時採取以下策略：
1）對庫表欄位分組，並為每組取一個合適的名字。在定製界面上，同組的欄位擺放在同一張卡片中，組名作為卡片名。
2）欄位值來源於數據字典表的數字型欄位，用組合框顯示其值，組合框中內容從數據字典表提取。用文本框顯示其他數字型欄位、字元串型欄位值。
3）根據定製界面上父控制項的尺寸、欄位名稱、欄位數據類型長度確定其對應控制項的位置和大小，控制項的布局遵循一行最多顯示兩欄位的原則。
不同類型界面的定製方法大同小異，因此採用了同界面定製代碼，只是在個別地方根據需要相關處理。例如，對於大欄位型的欄位，如果界面定製類型為「錄入」，則其對應文本框後的命令按鈕為打開文件。如果界面定製類型為「瀏覽」，則其對應文本框後的命令按鈕為瀏覽大欄位值。
三、入庫前系統檢查
入庫數據進入採集數據前，系統對其進行唯一性檢查、缺項檢查和數據類型檢查，即入庫前系統檢查。
唯一性檢查：航空物探資料庫是航空物探數據的最終目的地，但可能會有部分項目數據因沒有通過質量檢查而滯留在採集庫中。在進行新的項目數據採集過程時，為了避免項目數據2次入庫，在其進入採集庫前需要進行唯一性檢查。方法是用入庫數據每條記錄主鍵作為查詢條件，查找資料庫和採集庫中相對應的庫表是否存在有相同的記錄。例如，黃海北部海域航空磁測普查（項目標識號AGS011978000251），在項目概況數據導入採集庫時，根據項目概況資料庫表的項目標識號（主鍵）在採集庫和資料庫的相應表中查找是否有相同的項目標識號存在：若資料庫中存在，說明該項目數據已歸檔；若採集庫中存在，該項目數據已被導入採集庫中待檢，不需再次導入。
缺項檢查：入庫數據的欄位數必須等於相應資料庫表的欄位數，比資料庫表欄位數多或少都不能通過缺項檢查。
數據類型檢查：對入庫數據所有欄位數據進行類型檢查。若是日期型數據，則檢查數據格式（YYYY-MM-DD），YYYY、MM、DD是否為數字。若數字型數據，檢查整數位和小數位的位數是否超過范圍，整數位和小數位是否為數字。字元型數據，則檢查字元串長度是否超限。
入庫數據通過入庫前系統檢查後被存入採集庫中，否則軟體給出錯誤提示信息（圖5-8）。採集人員根據提示信息糾正數據中存在錯誤，再新導入數據。
圖5-8 入庫前系統檢查的錯誤提示
四、入庫後系統檢查
系統對進入採集庫中的數據進行非空和可空檢查、前後數據檢查、相關數據檢查、值域范圍檢查、選擇范圍檢查，即入庫後系統檢查（圖5-9）。
非空檢查：入庫數據指定欄位的值不能為空，如所有資料庫表的項目標識不能為空，項目名稱、項目參加單位名稱、參加人員名稱都不能為空。
可空缺項檢查：入庫數據指定欄位的值在有一定條件下可以為空，例如當勘查項目概況表記錄方式欄位的值為打點記錄或紙卷模擬記錄時，航磁數據的采樣率為空。若為數字收錄，航磁數據的采樣率不能為空。
前後數據檢查：檢查入庫數據指定欄位與其父表中相同欄位數據的一致性，如項目參加人員表中的項目標識必須與項目概況信息中的項目標識相同。
圖5-9 入庫後系統檢查
相關數據檢查：檢查相關表中相關欄位數據對入庫數據指定欄位的約束，如項目概況信息中有項目的起始日期和完成日期兩個欄位，那麼項目人員參加項目工作的起止日期都必須在項目的起始日期和完成日期之間。
值域范圍檢查：入庫數據指定欄位的數值必須是在設定的值域范圍內，如勘查項目概況中的調機小時設定在0和100 h范圍，若超過此范圍，調機小時數據有錯誤。
選擇范圍檢查：入庫數據指定欄位的數值必須是一個已知數據集合的元素之一，如項目成果評價只能在優秀、良好、通過和不合格4個選項中擇其一。
根據選定的庫表名提取該庫表各個欄位的檢查規則，逐條記錄進行前後數據檢查、相關檢查、值域范圍檢查、選擇范圍檢查。發現錯誤，把錯誤記錄暫存在內存中，繼續進行下條記錄檢查，至所有記錄檢查完。把錯誤寫入檢查日誌表（若有相同檢查日誌記錄，則先備份到檢查日誌備份表後再刪除，以便查看數據入庫不通過的歷史軌跡）；否則，寫入一條系統檢查通過的日誌記錄。再進行另一張表的系統檢查，所有庫表全部檢查後，若有錯誤，系統給出錯誤提示信息。
五、拓撲檢查
航空物探解釋數據和評價數據為空間要素類數據，入庫時要進行拓撲檢查（表5-6，圖5-10）。檢查各要素類之間相互位置關系的正確性。
以油氣遠景評價數據集為例說明拓撲檢查。檢查規則是局部構造異常位置應位於油氣遠景評價區的某一分布區內，油氣遠景評價區之間不以有重疊。若發現錯誤，把檢查的錯誤日誌暫存在內存中，繼續進行拓撲檢查；檢查完成後，把錯誤寫入檢查日誌表。沒有發現拓撲錯誤寫入一條通過拓撲檢查的日誌記錄。
表5-7 解釋數據和評價數據拓撲檢查規則表
圖5-10 拓撲檢查空間數據源列表界面
六、文件比較檢查
通過入庫後系統檢查和拓撲檢查的入庫數據，系統將對其進行與原數據文件比較檢查，保證數據的一致性。所有的入庫數據均須與原數據文件進行比較檢查。
根據項目標識號和庫表名從採集庫中提取相應的數據，若存在數據字典代碼，則將其替換文字字元，存放在Oracle臨時表中；打開本地路徑下原數據文件，逐條記錄對比。若有不匹配的記錄，顯示提示信息，並在日誌庫中寫一條檢查日誌。
七、人工檢查與復核
經過系統檢查、空間拓撲檢查，以及文件比較檢查後，還必須進行人工檢查和人工復核檢查。人工檢查是用原表格數據、空間屬性數據、解釋評價數據、圖件、文字報告（含軟體源代碼）與採集庫中相應的各類數據進行人工比對。若有原始紙質圖件，則需從採集庫中提取相應的數據使用相同軟體相同繪圖參數繪圖，並加以比較。若人工檢查發現錯誤，寫明錯誤原因（圖5-11），保存日誌。
圖5-11 填寫人工檢查結果界面
人工復核檢查與人工檢查過程完成一樣，只是人員不同。
八、系統歸檔檢查
在入庫數據歸檔到資料庫之前，系統對歸檔項目數據的完整性進行檢查，即歸檔檢查。系統根據歸檔項目的類別、工作性質、測量方法及歸檔階段，定義了項目資料歸檔對照表，該表記錄每類項目各個歸檔階段的項目資料清單和資料的歸檔標識。在資料歸檔時，系統檢查項目資料的歸檔標識。若為非空，說明該資料必須歸檔；若為空，說明該資料可歸檔，從而保證了資料庫中的項目資料完整性。
如區域航空磁力勘查項目資料歸檔分為3個階段（圖5-12），第一階段是生產測量資料歸檔，航空磁力勘查項目概況（項目概況、勘查項目概況、航磁概況）信息、測區信息生產報告必須歸檔。第二階段是數據處理資料歸檔，航跡線數據、航磁數據、數據處理報告必須歸檔。第三階段是地質解釋資料歸檔，項目概況信息、岩石磁性數據、圖件數據、文字數據、斷裂構造和區域構造單元必須歸檔。
科研項目資料歸檔時，根據項目標識號及項目級次，確定該項目是否有子項目，以及子項目資料是否已全部歸檔。在所有子項目資料全部歸檔後，使用項目資料歸檔向導（圖5-13）進行該級次的項目資料歸檔。如果項目屬保密項目，系統同時對歸檔數據進行加密。數據成功歸檔後，系統刪除採集庫中已歸檔數據，並把各種檢查日誌存放到備份日誌表中，以備檢查。
圖5-12 勘查項目資料歸檔示意圖
圖5-13 項目資料歸檔向導
F. 資料庫與數據倉庫的區別
資料庫是面向事務的設計，數據倉庫是面向主題設計的。資料庫一般存儲在線交易數據，數據倉庫存儲的一般是歷史數據。
「與時間相關」：資料庫保存信息的時候，並不強調一定有時間信息。數據倉庫則不同，出於決策的需要，數據倉庫中的數據都要標明時間屬性。決策中，時間屬性很重要。同樣都是累計購買過九車產品的顧客，一位是最近三個月購買九車，一位是最近一年從未買過，這對於決策者意義是不同的。
「不可修改」：數據倉庫中的數據並不是最新的，而是來源於其它數據源。數據倉庫反映的是歷史信息，並不是很多資料庫處理的那種日常事務數據（有的資料庫例如電信計費資料庫甚至處理實時信息）。因此，數據倉庫中的數據是極少或根本不修改的；當然，向數據倉庫添加數據是允許的。
拓展資料：
數據倉庫的出現，並不是要取代資料庫。數據倉庫，是在資料庫已經大量存在的情況下，為了進一步挖掘數據資源、為了決策需要而產生的，它決不是所謂的「大型資料庫」。
目前，大部分數據倉庫還是用關系資料庫管理系統來管理的。可以說，資料庫、數據倉庫相輔相成、各有千秋。