數據庫建設規范

目錄

1-序言...................................................................3

2.范圍..................................................................4

3.術語和定義...........................................................4

3.1范式..................................................................4

3.2關聯..................................................................4

3.3關系模型.............................................................4

3.4視圖..................................................................S

3.5外鍵..................................................................5

3.6約束..................................................................5

3.7主鍵..................................................................5

4.命名規范.............................................................6

4.1規范約定.............................................................6

4.2表名..................................................................6

4.3視圖..................................................................6

4.4存儲過程.............................................................6

4.5函數..................................................................7

4.6觸發器................................................................7

4.7字段..................................................................7

4.8索引..................................................................7

5.數據庫建設過程規范....................................................7

5.1概述..................................................................7

5.2需求分析階段.........................................................9

5.2.1需求調查............................................................9

5.2.2內容分析...........................................................10

5.3概念構造設L階段....................................................10

521定義實體............................................................10

5.3.3定義關系...........................................................11

5.3.4定義屬性...........................................................11

5.3.5定義鍵.............................................................11

5.3.6定義索引12

53.7定義其他對象和規則................................................13

5.4邏輯構造設L階段...................................................14

5.5數據庫物理設計階段.................................................15

5.6實行、運行、維護規范...............................................16

6.數據庫建設安全性規范.................................錯誤!未定義書簽。

6.1概述.................................................................17

6.2完整性設計..........................................................18

6.3物理安全............................................................21

6.4訪問控制............................................................21

6.5數據備份............................................................23

1.序言

數據庫技術是信息資源管理最有效的手段。數據庫設計是指對于一種給定R勺應用環境,

構造最優的數據庫模式，建在數據庫及其應用系統，有效存儲數據，滿足顧客信息規定和處

理規定。

本規范通過數據建庫的命名、構造、建庫過程及安全性措施等幾種技術方面進行約定，

目的就是提供一套規范、合理、科學日勺建庫技術體系，應用系統提供建庫技術參照。

2.范圍

本規范重要從關系數據庫U勺命名、關系和構造以及建設過程等幾種方面來規定數據庫設

計應遵照的規范。

3.術語和定義

3.1范式

關系數據庫中的關系是要滿足一定規定的，滿足不同樣程度規定H勺為不同樣范式。滿足

最低規定的叫第一范式，簡稱1NF。在第一范式中滿足深入規定H勺為第二范式，其他以此

類推。一般而言，數據庫的設計應至少滿足第三范式0

3.2關聯

關聯是不同樣表之間的數據彼此聯絡的措施。關聯同步存在于形成不同樣實體的數據項

之間和表實體自身之間，構成了數據庫規范化的基本關鍵問題。它分為一對一、一對多、多

對多三種關聯形式。

3.3關系模型

關系模型由關系數據構造、關系操作集合和關系完整性約束三部分構成。在

關系模型中，實體與實體訶的聯絡都是用關系來體現H勺。

3.4視圖

視圖是一種定制的虛擬表，可以是當地的、遠程的或帶參數的；其數據可以

來源于一種或多種表，或者其他視圖；它是可更新歐I,可以引用遠程表：它可以

更新數據源。視圖是基于數據庫的，因此，創立視圖的前必須有數據庫。

3.5外鍵

外鍵是一種關系中MJ—組屬性（一種或多種列），它同步也是某種（相似的

或其他的）關系中的主鍵，它是關系之間的邏輯鏈接。

3.6約束

數據庫管理系統必須提供一種機制來檢查數據庫中的數據，看其與否滿足語

義規定的條件，這些加在數據庫數據之上依J語義規范，稱為約束。約束又可以分

為完整性約束、唯一性約束等。

3.7主鍵

每張表都應當包括相似的J一種或一組字段，它們都是保留在表中的、每一條

記錄時唯一標識，一般這些字段（即主鍵）需要在建立數據表時就設定并標識。

4.命名規范

4.1規范約定

命名采用26個英文字母（一律大寫）和0—9這十個自然數，加上下劃線“一”

構成，共63個字符，不能出現其他字符（注釋除外）。

數據庫對象包括表、視圖、存儲過程、函數、觸發器、字段、數據庫文檔。

對象名字由前綴和實體名稱構成，長度不超過30個字符。前綴描述對象類型，

實體名稱包括系統標識等信息盡量詳盡描述實體的內容，不以數字或下劃線開頭，對象名稱

中的標識用下劃線進行分隔。其中“口”內的內容體現是可選內容。

4.2表名

T_［（系統標識〉」［＜....＞」（表標識〉

如:T_NPCP_ORDER

4.3視圖

V_［＜系統標識〉」［＜....＞」＜視圖標識〉

如：V_NPCP_ORDER

4.4存儲過程

P_［＜系統標識習［＜....＞」＜存儲過程標識＞［_＜存儲過程行為標識習

如：PNPCPORDERADD

4.5函數

F_［＜系統標識〉」［＜....＞」〈函數標識＞［_＜函數行為標識＞］

如：F_NPCP_ORDER_ADD

4.6觸發器

TR_［＜系統標識習［＜表標識＞』＜…….＞」＜觸發標識〉

如：TR_NPCP_ORDER_ADD

4.7字段

［〈外鍵表標識〉」［＜…….＞」＜字段標識〉

如I：ORDERJD

4.8索引

IN」（系統標識〉」［＜表標識＞」［＜....＞」＜索引標識〉

如：IN_NPCP_ORDER_NAME

5.數據庫建設過程規范

5.1概述

建庫過程提議參照如下的建庫流程如圖1所示。

需求分析階段綜合各科學數據顧客時應用需求，形成規范日勺需求調查表、需求規格書、

功能需求表。

概念設計階段形成獨立于機器特點、獨立于各個數據庫管理系統產品的概念模式，用

E-R圖來描述。

邏輯設計階段將E-R圖轉換成詳細的數據庫產品支持的數據模型如關系模型，形成數據

庫邏輯模式。然后根據顧客處理的規定，安全性的考慮，在基本表H勺基礎上再建立必要H勺視

圖形成數據的外模式。

數據可以分為兩大類：關系數據和非關系數據，在物理設計階段根據數據庫管理系統的

特點和處理的需要，進行物理存儲安排，設計索引，形成數據庫內模式。

最終進行數據（或元數據）錄入。建庫過程歐I每一步都是對其前一步

驟的檢查，對于發現的錯誤或偏差需要進行及時的評估，并進行修正完善。對由

于數據庫的設計而在應用當中的導致II勺不良影響及出現數據誤差等現象進行修

繕、更新、完善。

邏輯結構設計

Wf~~?=>:

5.2需求分析階段

需求分析階段可以分為兩個環節：需求調查和內容分析。數據大概分為兩類數據：

關系型數據和非關系型數據（如文獻，文檔）。在需求分析階段可以對這兩種數據進行

不同樣H勺處理和分析，

5.2.1需求調查

數據信息來源有如下幾種措施，分析系統需求分析匯報書，組織調杳會，征詢業務

專家。

非關系型數據要分析哪幾類類型，如文獻日勺格式。

5.2.2內容分析

需求搜集和分析，成果得到數據字典描述的數據需求，數據流圖描述的處理需求。

數據項數據項含義數據類型長度取值范圍可選性注釋

表1數據字典規范模式

圖2數據流圖的體現方式

5.3概念構造設計階段

這個階段口勺任務確定建模目日勺，開發建模計劃，組織建模隊伍，搜集數據資源，制

定約束和規范。

5.2.1定義實體

找出潛在的實體，形成初步實體表，然后再進行必要的調整。滿足下述兩條準則的

事物，一般均可作為屬性看待。

(1)作為“屬性”，不能再具有需要描述的性質。“屬性”必須是不可分的數據

項，不能包括其他屬性。

(2)“屬性”不能與其他實體具有聯絡，即E-R圖中所示的聯絡是實體之間U勺聯

絡。

5.3.3定義關系

模型中只容許二元聯絡，n元聯絡必須定義為n個二元聯絡。根據實際的業務需求和

規則，使用實體聯絡矩陣來標識實體間口勺二元關系，然后艱據實際狀況確定出連接關系的勢、

關系名和闡明，確定關系類型，是標識關系、北標識關系(強制的或可選的)還是#確定關

系、分類關系。假如子實體歐I每個實例都需要通過和父實體的關系來標識，則為標識關系,

否則為非標識關系。非標識關系中，假如每個子實體的實例都與并且只與一種父實體關聯,

則為強制的，否則為非強制H勺。假如父實體與子實體代表H勺是同一現實對象，那么它們為分

類關系。即在這一步工作中確定任意有關聯的兩個實體之間的關系類型。

5.3.4定義屬性

從源數據表中抽取闡明性的名詞開發出屬性表，確定屬性的所有者。定義非主鍵屬性,

檢查屬性的非空及非多值規則。此外，還要檢查完全依賴函數規則和非傳遞依賴規則，保證

一種非主鍵屬性必須依賴丁主鍵、整個主鍵、僅僅是主健。

5.3.5定義鍵

通過引入交叉實體除去上一階段產生的非確定關系，然后從非交叉實體和獨立實體

開始標識侯選鍵屬性，以便唯一識別每個實體的實例，再從侯選鍵中確定主鍵。為了確

定主鍵和關系的有效性，通過非空規則和非多值規則來保證，即一種實體實例的）一種屬

性不能是空值，也不能在同一種時刻有一種以上的值。找出誤認確實定關系，將實體深

入分解,最終構造出IDEF1X模型H勺鍵基視圖，確定關系中日勺主鍵和外鍵等。鍵選擇規

范：

1）鍵設計原則：為關聯字段創立外鍵;所有"勺鍵都必須唯一;防止使用復合鍵;外鍵總

是關聯唯一口勺鍵字段，

2）使用系統生成的主鍵，設計數據庫R勺時候采用系統生成H勺鍵作為主鍵，那么實際

控制了數據庫的索引完整性。這樣，數據庫和非人工機制就有效地控制了對存儲數據中

每一行的訪問。采用系統生成鍵作為主鍵尚有一種長處：當擁有一致H勺鍵構造時，找到

邏輯缺陷很輕易。

3）不要采用顧客可編輯口勺字段作鍵（不讓主鍵具有可更新性）在確定采用什么字段作

為表叢J鍵日勺時候，可一定要小心顧客將要編輯的字段。一般口勺狀況下不要選擇顧客可編

輯口勺字段作為鍵。

4）可選鍵有時可做主鍵，把可選鍵深入用做主鍵，可以擁有建立強大索引的能力。

536定義索引

索引是從數據庫中獲取數據日勺最高效方式之一。95%臥J數據庫性能問題都可

以采用索引技術得到處理，

1）假如一種（或一組）屬性常常在查詢條件中出現，則考慮在這個（或這

組）屬性上建立索引（或組合索引）;

2）假如一種屬性常常作為最大值和最小值等匯集函數日勺參數，則考慮在這個

屬性.上建立索引；

3）假如一種（或一組）屬性常常在連接操作的連接條件中出現，則考慮在這

個（或這組）屬性上建立索引：

4）邏輯主鍵使用唯一日勺成組索引，對系統鍵（作為存儲過程）采用唯一的

非成組索引，對任何外鍵列采用非成組索引。考慮數據庫的空間有多大，表怎樣

進行訪問，尚有這些訪問與否重要用作讀寫。

5）大多數數據庫都索引自動創立H勺主鍵字段，不過可別忘了索引外鍵，它

們也是常常使用的鍵，例如運行查詢顯示主表和所有關聯表的某條記錄就用得上。

6）不要索引MEMO（備注）字段，不要索引大型字段（有諸多字符），這樣作

會讓索引占用太多的存儲空間。

7）不要索引常用H勺小型表。不要為小型數據表設置任何鍵，假如它們常常

有插入和刪除操作就更別這樣作了,對這些插入和刪除操作的索引維護也許比掃

描表空間消耗更多的時間。

5.3.7定義其他對象和規則

定義屬性H勺數據類型、長度、精度、非空、缺省值,約束規則等。定義觸發

器、存儲過程、視圖、角色、同義詞、序列等對象信息。

最終形成的概念模型用E-R圖進行體現。

5.4邏輯構造設計階段

將概念構造轉換為某個數據庫管理系統所支持口勺數據模型(例如關系模

型)，并對其進行優化。設計邏輯構造應當選擇最適于描述與體現對應概念構造

的數據模型，然后選擇最合適的數據庫管理系統，形成數據庫文檔。

將E-R圖轉換為關系模型實際上就是要將實體、實體的屬性和實體之間的

聯絡轉化為關系模式。關系模型的邏輯構造是一組關系模式的集合。E-R圖則

是由實體、實體H勺屬性和實體之間H勺聯絡三個要素構成II勺。因此將E-R圖轉換

為關系模型實際上就是要將實體、實體的屬性和實體之間的聯絡轉換為關系模

式，這種轉換要遵照如下規范原則：

1)一種實體型轉換為一種關系模式。實體的屬性就是關系口勺屬性。實體的

標識對應關系模型的候選碼。

2)一種m:n聯絡轉換為一種關系模式。與該聯絡相連的各實體U勺碼以及聯

系自身的屬性均轉換為關系的屬性。而關系模型的候選碼為各實體標識口勺組合。

3)一種l:n聯絡可以轉換為一種獨立的關系模式，也可以與n端對應的|關

系模式合并。假如轉換為一種獨立日勺關系模式，則與該聯絡相連的各實體日勺標識

以及聯絡自身的屬性均轉換為關系的屬性，而關系H勺碼為n端實體的碼。

4)一種1:1聯絡可以轉換為一種獨立的關系模式，也可以與任意一端對應

的關系模式合并。

5）三個或三個以上實體同的一種多元聯絡轉換為一種關系模式。與該多元

聯絡相連的各實體的標識以及聯絡自身的屬性均轉換為關系的屬性。而關系模型

時候選碼為各實體碼的組合。

6）同一實體集日勺實體間的聯絡，即白聯絡，也可按上述1:1、1:n和m:n三

種狀況分別處理。

7）具有相似碼"勺關系模式可合并。為了深入提高數據庫應用系統口勺性能，一般以規范

化理論為指導，還應當合適地修改、調整數據模型的構造，這就是數據模型的優化。確定數

據依賴。消除冗氽的聯絡,確定各關系模式分別屬丁第幾范式。確定與否要對它們進行合并

或分解。一般來說將關系分解為3NF的原則，即：表內的每一種值都只能被體現一次。表

內的每一行都應當被唯一的標識（有唯一鍵）。表內不應當存儲依賴于其他鍵的非鍵信息。

對所有的快捷方式、命名規范、限制和函數都要編制文檔。采用給表、歹h觸發器等加注釋

的數據庫工具。對開發、支持和跟蹤修改非常有用。對數據庫文檔化，或者在數據庫臼身日勺

內部或者單獨建立文檔。

為加緊數據庫設計速度，目前有諸多數據庫輔助工具（CASE工具），如Rational企業的

RationalRose,CA企業Erwin和Bpwin,Sybase企業RJowerDesigner以及Oracle企業日勺

OraclADA.ignPr等八設計人員可根據需要選用對應時數據庫設計建模工具.

5.5數據庫物理設計階段

數據庫物理設計過程中需要對時間效率、空間效率、維護代價和多種顧客要

求進行權衡，其成果可以產生多種方案，數據庫設計人員必須對這些方案進行細

致的評價，從中選擇一種較優日勺方案作為數據庫的I物理構造。

評價物理數據庫的措施完全依賴于所選用的數據庫管理系統，重要是從定量

估算多種方案的存儲空間、存取時間和維護代價入手，對估算成果進行權衡、比

較,選擇出一種較優的合理的物理構造。假如該構造不符合顧客需求，則需要修

改設計。

規范規定，物理設計當中在遵照數據庫設計范式的基礎之匕規定科學數據

庫建庫時除數據庫設計所遵照的范式外的某些合用規范：

1）所有數據記錄都要有ID序列字段，ID號由數據庫自動生成，以標識記錄。

2）所有記錄都要有“更新時間”字段，記錄標識數據更新狀況。

3）對于主-明細表構造，設計對應日勺視圖將兩表連接用于查詢。

4）可以取消主外鍵關聯，通過對應的程序來維護數據一致性。

）類別和狀態的多選：多選分為必選）和匕選（）如是必選，在設計時要

5（l..n0..no

有闡明，在程序實現中應有控制和檢查。兩個可選的類別或狀態表可以合并為一種

表,再與引用此表H勺主表形成多對多H勺關系。

5.6實行、運行、維護規范

運用數據庫管理系統提供II勺數據語言（例如SQL）及其宿主語言（例如

JAVA）,根據邏輯設計和物理設計的成果建科學數據庫，編制與調試應用程序，

組織科學數據入庫，并進行試運行。規范規定：SQL關鍵詞所有大寫，例如

SELECT,UPDATE,FROM,ORDER,BY等。

數據庫實行重要包括如下工作：用DDL定義數據庫構造、組織數據入庫、

編制與調試應用程序、數據庫試運行。建立或者修訂數據庫之后，必須用顧客新

輸入的數據測試數據字段，

所有Hjsql語句要最進性能分析，和壓力測試。并且需要提交測試匯報。

數據庫應用系統通過試運行后即可投入正式運行。在數據庫系統運行過程中

必須不停地對其進行評價、調整與修改，定期提交運行監測匯報。包括：數據庫

的轉儲和恢復、數據庫的安全性、完整性控制、數據庫性能的監督、分析和改善、

數據庫『、J重組織和重構造，

6.數據庫建設安全性規范

6.1概述

伴隨數據庫技術的不停進步，信息安全問題也日益突出，數據庫"勺安全性也愈加受到重

視。建設科學數據庫中，諸多科學數據都是不可再現的，甚至是長期積累獲得的成果，失不

可得，因此科學數據的安全性顯得尤為重要。

安全方略重要是維護科學數據信息的完整性、保密性和可用性。科學數據庫的I安全建設

規范重要是物理安全、訪問控制、數據備份等。同其他數據資源相似，科學數據庫數據日勺安

全威脅重要來自三個方面：非人為破壞，例如地震等；人為時非積極破壞，例如誤操作；人

為積極破壞，例如黑客入侵。對于非人為破壞，重要只能依托定期備份或者熱備份等，并在

相隔物理距離外保護備份。本規范重要討論對于人為破壞的安全性規范。

6.2完整性設計

1）完整性實現機制：

實體完整性：每個數據實體都要有主鍵，即每條數據記錄都要有唯一標識以

辨別不同樣記錄。

父表中插入數據：父表中插入數據，要看有哪些受限條件，以及注意插入父

表數據時尚有無其他的輔助數據輸入。如添加化學品數據基本信息時，要注意

其成分信息的添加和關聯。

父表中更新數據：同樣需要注意級聯更新和受限條件的更新。

顧客定義完整性：數據字段的可選性（與否非空）以及數據檢查等。

2）用約束強制數據完整性

完整性約束條件作用的對象可以是關系、元組、列三種。其中列約束重要是

列的類型、取值范圍、精度、排序等約束條件。元組日勺約束是元組中各個字段間

的聯絡的約束。關系的約束是若干元組間、關系集合上以及關系之間的聯絡的約

束。完整性約束條件波及的這三類對象，其狀態可以是靜態歐J,也可以是動態的I。

(1)靜態列級約束

靜態列級約束是對一種列的取值域的闡明，這是最常用也最輕易實現H勺一類

完整性約束，包括如下幾方面：

對數據類型口勺約束(包括數據的類型、長度、單位、精度等)。

對數據格式的約束。

對取值范圍或取值集合的約束。

對空值的約束，空值體現未定義或未知的值，它與零值和空格不同樣。有日勺列容許空值,

有的則不容許。

其他約束，例如有關列的排序闡明，組合列等。

(2)靜態元組約束

一種元組是由若干個列值構成H勺，靜態元組約束就是規定元組的各個列之間

的約束關系。例如訂貨關系中包括發貨量、訂貨量等列，規定發貨量不得超過訂

貨量；又如教師關系中包括職稱、工資等列，規定專家B勺工資不低于1000元

(3)靜態關系約束

在一種關系的各個元組之間或者若干關系之間常常存在多種聯絡或約束。常

見的靜態關系約束有：

實體完整性約束和參照完整性約束：實體完整性約束和參照完整性約束是關系模型日勺兩

個極其重要的I約束，稱為關系日勺兩個不變性。

函數依賴約束。大部分函數依賴約束都在關系模式中定義。

記錄約束。即字段值與關系中多種元組的記錄值之間的約束關系。例如規定部門經理的

工資不得高于本部門職工平均工資的5倍，不得低于本部門職工平均工資的2倍。這里，

本部門職工的平均工資是一種記錄值。

(4)動態列級約束

動態列級約束是修改列定義或列值時應滿足的約束條件：包括卜面兩方面：

修改列定義時U勺約束，例如，將容許空值的列改為不容許空值時，假如該列目前已存在

空值，則拒絕這種修改。

修改列值時的約束，修改列值有時需要參照其舊值，并且新舊值之間需要滿足某種約束

條件。例如，職工工資調整不得低于其本來工資，學生年齡只能增長等。

(5)動態元組約束

動態元組約束是指修改元組日勺值時元組中各個字段間需要滿足某種約束條件。例如職工

工資調整時新工資不得低于原工資+工齡*1.5等。

(6)動態關系約束

動態關系約束是加在關系變化前后狀態上的限制條件，例如事務一致性、原

子性等約束條件。

3)強制指小完整性

在有害數據進入數據庫之前將其剔除。激活數據庫系統的指示完整性特性。這樣可以保

持數據的清潔而能迫使開發人員投入更多的時間處理錯誤條件。

4）使用查找控制數據完整性

控制數據完整性口勺最佳方式就是限制顧客的選擇。只要有也許都應當提供應顧客一種清晰的

價值列表供其選擇。這樣將減少鍵入代碼的錯誤和誤解同步提供數據的一致性。某些公共數

據尤其適合查找：國家代碼、狀態代碼等。

5）采用視圖

在數據庫和應用程序代碼之間提供另一層抽象，可認為應用程序建立專門的

視圖而不必非耍應用程序直接訪問數據表。這樣做會在處理數據庫變更時提供了

更多的自由。

6.3物