Ⅰ 信息資料庫用戶管理規范規定了哪些原則
（一）完善管理制度，強化監管力度。資料庫系統的安全與企業自身內部的安全機制、內外網路環境、從業人員素質等密切相關。因此，企業應該完善網路系統安全規章制度，防範因制度缺陷帶來的風險；企業應該規范操作流程和故障處理流程，減少人為失誤與故障，提高故障處理速度，縮短故障處理時間；企業應該通過建立科學合理的責任追究機制，防止出現由於工作態度、工作作風等各種人為因素導致的資料庫安全事故。
（二）採取措施，確保資料庫數據的安全。保證資料庫數據的安全是資料庫日常管理與維護工作的首要任務，企業需要採取的安全措施主要有：
（1）網路及操作系統安全。網路系統是資料庫應用的外部環境和基礎，網路系統安全是資料庫安全的第一道屏障。從技術角度講，網路系統層次的安全防範技術有很多種，大致可以分為防火牆、數字簽名與認證、入侵檢測等。操作系統是資料庫系統的運行平台，能夠為資料庫系統提供一定程度的安全保護。
（2）操作系統的安全控制方法主要是採用隔離控制、訪問控制、信息加密和審計跟蹤。主要安全技術有操作系統安全策略、安全管理策略等。
（3）加強用戶身份驗證。用戶身份驗證是資料庫系統的重要防線。利用窗體身份驗證資料庫程序的漏洞，進而獲取存儲在資料庫中的用戶身份驗證密碼，這是目前對網路資料庫攻擊最常見的方式。對此，企業信息部門通常使用帶有salt值的單向密碼哈希值，以避免用戶密碼在資料庫中以明文形式存儲，減輕字典攻擊帶來的威脅。
（4）對重要數據加密。數據加密交換又稱密碼學，是計算機系統對信息進行保護的一種最可靠的辦法。它利用密碼技術對信息進行交換，實現信息隱蔽，從而有效保護信息的安全不受侵犯。資料庫加密要求加解密的粒度是每個記錄的欄位數據。採用庫外口加密的方式，對密鑰的管理較為簡單，只需借用文件加密的密鑰管理方法，將加密後的數據塊納入資料庫，在演算法或資料庫系統中做些必要的改動就行。這樣有利於公共數據字典的使用和維護系統的完整性。
（5）做好資料庫備份與恢復。數據備份是備份資料庫某個時刻的數據狀態，當系統出現意外時用來恢復系統。依靠網路辦公的企業，其信息系統很可能隨時被破壞而丟失數據。因此，資料庫管理系統必須具備把資料庫從錯誤狀態恢復到某一已知的正確狀態的功能，這就是資料庫的恢復技術。
（三）開展資料庫健康檢查。為及時發現資料庫系統存在的問題，在日常管理與維護中，數據管理員要對資料庫開展健康檢查。檢查內容主要包括以下六個方面
（1）系統環境：操作系統版本、文件系統容量、內存交換區使用率、系統性能。
（2）資料庫環境：資料庫和補丁版本、是否有僵屍資料庫進程、資料庫節點數、是否有其他資料庫產品及版本。
（3）日誌記錄：db2diag.log報錯、db2inst1.nfy報錯、是否有需要處理的DUMP文件。
（4）資料庫健康狀況：表空間利用率和狀態、表空間容器利用率和狀態、排序溢出、是否需要收集統計信息、是否需要數據重組、活動日誌和日誌所在文件系統利用率、死鎖發生率、鎖升級發生率、鎖等待的百分比、編目Cache命中率、包Cache命中率、監視堆利用率、資料庫堆利用率、資料庫緩沖池命中率。
（5）資料庫維護內容：最近一次統計信息收集時間、最近一次表數據重組時間、最近一次綁定包時間、最近一次資料庫備份時間。
（6）資料庫基本信息記錄：資料庫內存使用、環境變數。
資料庫的管理日常工作
（1） 每天對資料庫的運行狀態 , 日誌文件 , 備份情況 , 資料庫的空間使用情況 , 系統資源的使用情況進行檢查 , 發現並解決問題。
（2）每周對資料庫對象的空間擴展情況 , 數據的增長情況進行監控 , 對資料庫做健康檢查 , 對資料庫對象的狀態做檢查。
（3） 每月對表和索引等進行 Analyze, 檢查表空間碎片 , 尋找資料庫性能調整的機會 , 進行資料庫性能調整 , 提出下一步空間管理
計劃。對 ORACLE 資料庫狀態進行一次全面檢查。
資料庫管理的意義重大，關繫到企業信息系統的正常運作，仍至整個企業的生死存亡。要做好資料庫的日常管理與維護，不僅要求資料庫管理員熟悉掌握專業技術知識，還要有足夠的細心和高度的責任心。
Ⅱ 資料庫三大範式
資料庫 的設計範式是資料庫 設計所需要滿足的規范，滿足這些規范的資料庫 是簡潔的、結構明晰的，同時，不會發生插入（insert）、刪除（delete）和更新（update）操作異常。反之則是亂七八糟，不僅給資料庫 的編程 人員製造麻煩，而且面目可憎，可能存儲了大量不需要的冗餘信息。
設計範式是不是很難懂呢？非也，大學教材上給我們一堆數學公式我們當然看不懂，也記不住。所以我們很多人就根本不按照範式來設計資料庫 。
實質上，設計範式用很形象、很簡潔的話語就能說清楚，道明白。本文將對範式進行通俗地說明，並以筆者曾經設計的一個簡單論壇的資料庫 為例來講解怎樣將這些範式應用於實際工程。
範式說明
第一範式（1NF）：資料庫 表中的欄位都是單一屬性的，不可再分。這個單一屬性由基本類型構成，包括整型、實數、字元型、邏輯型、日期型等。
例如，如下的資料庫 表是符合第一範式的：
欄位1 欄位2 欄位3 欄位4
而這樣的資料庫 表是不符合第一範式的：
欄位1 欄位2 欄位3 欄位4 欄位3.1欄位3.2
很顯然，在當前的任何關系資料庫 管理系統（DBMS）中，傻瓜也不可能做出不符合第一範式的資料庫 ，因為這些DBMS不允許你把資料庫 表的一列再分成二列或多列。因此，你想在現有的DBMS中設計出不符合第一範式的資料庫 都是不可能的。
第二範式（2NF）：資料庫 表中不存在非關鍵欄位對任一候選關鍵欄位的部分函數依賴（部分函數依賴指的是存在組合關鍵字中的某些欄位決定非關鍵欄位的情況），也即所有非關鍵欄位都完全依賴於任意一組候選關鍵字。
假定選課關系表為SelectCourse(學號, 姓名, 年齡, 課程名稱, 成績, 學分)，關鍵字為組合關鍵字(學號, 課程名稱)，因為存在如下決定關系：
(學號, 課程名稱) → (姓名, 年齡, 成績, 學分)
這個資料庫 表不滿足第二範式，因為存在如下決定關系：
(課程名稱) → (學分)
(學號) → (姓名, 年齡)
即存在組合關鍵字中的欄位決定非關鍵字的情況。
由於不符合2NF，這個選課關系表會存在如下問題：
(1) 數據冗餘：
同一門課程由n個學生選修，"學分"就重復n-1次；同一個學生選修了m門課程，姓名和年齡就重復了m-1次。
(2) 更新異常：
若調整了某門課程的學分，數據表中所有行的"學分"值都要更新，否則會出現同一門課程學分不同的情況。
(3) 插入異常：
假設要開設一門新的課程，暫時還沒有人選修。這樣，由於還沒有"學號"關鍵字，課程名稱和學分也無法記錄入資料庫 。
(4) 刪除異常：
假設一批學生已經完成課程的選修，這些選修記錄就應該從資料庫 表中刪除。但是，與此同時，課程名稱和學分信息也被刪除了。很顯然，這也會導致插入異常。
把選課關系表SelectCourse改為如下三個表：
學生：Student(學號, 姓名, 年齡)；
課程：Course(課程名稱, 學分)；
選課關系：SelectCourse(學號, 課程名稱, 成績)。
這樣的資料庫 表是符合第二範式的，消除了數據冗餘、更新異常、插入異常和刪除異常。
另外，所有單關鍵字的資料庫 表都符合第二範式，因為不可能存在組合關鍵字。
第三範式（3NF）：在第二範式的基礎上，數據表中如果不存在非關鍵欄位對任一候選關鍵欄位的傳遞函數依賴則符合第三範式。所謂傳遞函數依賴，指的是如果存在"A → B → C"的決定關系，則C傳遞函數依賴於A。因此，滿足第三範式的資料庫 表應該不存在如下依賴關系：
關鍵欄位 → 非關鍵欄位x → 非關鍵欄位y
假定學生關系表為Student(學號, 姓名, 年齡, 所在學院, 學院地點, 學院電話)，關鍵字為單一關鍵字"學號"，因為存在如下決定關系：
(學號) → (姓名, 年齡, 所在學院, 學院地點, 學院電話)這個資料庫 是符合2NF的，但是不符合3NF，因為存在如下決定關系：
(學號) → (所在學院) → (學院地點, 學院電話)
即存在非關鍵欄位"學院地點"、"學院電話"對關鍵欄位"學號"的傳遞函數依賴。
它也會存在數據冗餘、更新異常、插入異常和刪除異常的情況，讀者可自行分析得知。
把學生關系表分為如下兩個表：
學生：(學號, 姓名, 年齡, 所在學院)；
學院：(學院, 地點, 電話)。
這樣的資料庫 表是符合第三範式的，消除了數據冗餘、更新異常、插入異常和刪除異常。
鮑依斯-科得範式（BCNF）：在第三範式的基礎上，資料庫 表中如果不存在任何欄位對任一候選關鍵欄位的傳遞函數依賴則符合第三範式。
假設倉庫管理關系表為StorehouseManage(倉庫ID, 存儲物品ID, 管理員ID, 數量)，且有一個管理員只在一個倉庫工作；一個倉庫可以存儲多種物品。這個資料庫 表中存在如下決定關系：
(倉庫ID, 存儲物品ID) →(管理員ID, 數量)
(管理員ID, 存儲物品ID) → (倉庫ID, 數量)
所以，(倉庫ID, 存儲物品ID)和(管理員ID, 存儲物品ID)都是StorehouseManage的候選關鍵字，表中的唯一非關鍵欄位為數量，它是符合第三範式的。但是，由於存在如下決定關系：
(倉庫ID) → (管理員ID)
(管理員ID) → (倉庫ID)
即存在關鍵欄位決定關鍵欄位的情況，所以其不符合BCNF範式。它會出現如下異常情況：
(1) 刪除異常：
當倉庫被清空後，所有"存儲物品ID"和"數量"信息被刪除的同時，"倉庫ID"和"管理員ID"信息也被刪除了。
(2) 插入異常：
當倉庫沒有存儲任何物品時，無法給倉庫分配管理員。
(3) 更新異常：
如果倉庫換了管理員，則表中所有行的管理員ID都要修改。
把倉庫管理關系表分解為二個關系表：
倉庫管理：StorehouseManage(倉庫ID, 管理員ID)；
倉庫：Storehouse(倉庫ID, 存儲物品ID, 數量)。
這樣的資料庫 表是符合BCNF範式的，消除了刪除異常、插入異常和更新異常。
範式應用
我們來逐步搞定一個論壇的資料庫 ，有如下信息：
（1） 用戶：用戶名，email，主頁，電話，聯系地址
（2） 帖子：發帖標題，發帖內容，回復標題，回復內容
第一次我們將資料庫 設計為僅僅存在表：
用戶名 email 主頁電話聯系地址發帖標題發帖內容回復標題回復內容
這個資料庫 表符合第一範式，但是沒有任何一組候選關鍵字能決定資料庫 表的整行，唯一的關鍵欄位用戶名也不能完全決定整個元組。我們需要增加"發帖ID"、"回復ID"欄位，即將表修改為：
用戶名email主頁電話聯系地址發帖ID發帖標題發帖內容回復ID回復標題回復內容
這樣數據表中的關鍵字(用戶名，發帖ID，回復ID)能決定整行：
(用戶名,發帖ID,回復ID) → (email,主頁,電話,聯系地址,發帖標題,發帖內容,回復標題,回復內容)
但是，這樣的設計不符合第二範式，因為存在如下決定關系：
(用戶名) → (email,主頁,電話,聯系地址)
(發帖ID) → (發帖標題,發帖內容)
(回復ID) → (回復標題,回復內容)
即非關鍵欄位部分函數依賴於候選關鍵欄位，很明顯，這個設計會導致大量的數據冗餘和操作異常。
我們將資料庫 表分解為（帶下劃線的為關鍵字）：
（1） 用戶信息：用戶名，email，主頁，電話，聯系地址
（2） 帖子信息：發帖ID，標題，內容
（3） 回復信息：回復ID，標題，內容
（4） 發貼：用戶名，發帖ID
（5） 回復：發帖ID，回復ID
這樣的設計是滿足第1、2、3範式和BCNF範式要求的，但是這樣的設計是不是最好的呢？
不一定。
觀察可知，第4項"發帖"中的"用戶名"和"發帖ID"之間是1：N的關系，因此我們可以把"發帖"合並到第2項的"帖子信息"中；第5項"回復"中的"發帖ID"和"回復ID"之間也是1：N的關系，因此我們可以把"回復"合並到第3項的"回復信息"中。這樣可以一定量地減少數據冗餘，新的設計為：（1） 用戶信息：用戶名，email，主頁，電話，聯系地址
（2） 帖子信息：用戶名，發帖ID，標題，內容
（3） 回復信息：發帖ID，回復ID，標題，內容
資料庫 表1顯然滿足所有範式的要求；
資料庫 表2中存在非關鍵欄位"標題"、"內容"對關鍵欄位"發帖ID"的部分函數依賴，即不滿足第二範式的要求，但是這一設計並不會導致數據冗餘和操作異常；
資料庫 表3中也存在非關鍵欄位"標題"、"內容"對關鍵欄位"回復ID"的部分函數依賴，也不滿足第二範式的要求，但是與資料庫 表2相似，這一設計也不會導致數據冗餘和操作異常。
由此可以看出，並不一定要強行滿足範式的要求，對於1：N關系，當1的一邊合並到N的那邊後，N的那邊就不再滿足第二範式了，但是這種設計反而比較好！
對於M：N的關系，不能將M一邊或N一邊合並到另一邊去，這樣會導致不符合範式要求，同時導致操作異常和數據冗餘。
對於1：1的關系，我們可以將左邊的1或者右邊的1合並到另一邊去，設計導致不符合範式要求，但是並不會導致操作異常和數據冗餘。
Ⅲ SQL編寫規范
書寫格式 示例代碼 存儲過程SQL文書寫格式例selectc dealerCode round(sum(c submitSubletAmountDLR + c submitPartsAmountDLR + c submitLaborAmountDLR) / count(*) ) as avg decode(null x xx CNY )from (selecta dealerCode a submitSubletAmountDLR a submitPartsAmountDLR a submitLaborAmountDLRfrom SRV_C_F awhere (to_char(a ORIGSUBMITTIME yyyy/mm/dd ) >= Date Range(start) and to_char(a ORIGSUBMITTIME yyyy/mm/dd ) <= Date Range(end) and nvl(a deleteflag ) <> )union allselectb dealerCode b submitSubletAmountDLR b submitPartsAmountDLR b submitLaborAmountDLRfrom SRV_CHistory_F bwhere (to_char(b ORIGSUBMITTIME yyyy/mm/dd ) >= Date Range(start) and to_char(b ORIGSUBMITTIME yyyy/mm/dd ) <= Date Range(end) and nvl(b deleteflag ) <> )) cgroup by c dealerCodeorder by avg desc;Java source里的SQL字元串書寫格式例strSQL = insert into Snd_FinanceHistory_Tb + (DEALERCODE + REQUESTSEQUECE + HANDLETIME + JOBFLAG + FRAMENO + INMONEY + REMAINMONEY + DELETEFLAG + UPDATECOUNT + CREUSER + CREDATE + HONORCHECKNO + SEQ) + values ( + draftInputDetail dealerCode + + + draftInputDetail requestsequece + + sysdate + + + frameNO + + requestMoney + + remainMoney + + + + + draftStruct employeeCode + + sysdate + + draftInputDetail honorCheckNo + + index + ) ; ) 縮進對於存儲過程文件 縮進為 個空格對於Java source里的SQL字元串 不可有縮進 即每一行字元串不可以空格開頭 ) 換行 > Select/From/Where/Order by/Group by等子句必須另其一行寫 > Select子句內容如果只有一項 與Select同行寫 > Select子句內容如果多於一項 每一項單獨佔一行 在對應Select的基礎上向右縮進 個空格（Java source無縮進） > From子句內容如果只有一項 與From同行寫 > From子句內容如果多於一項 每一項單獨佔一行 在對應From的基礎上向右縮進 個空格（Java source無縮進） > Where子句的條件如果有多項 每一個條件佔一行 以AND開頭 且無縮進 > (Update)Set子句內容每一項單獨佔一行 無縮進 > Insert子句內容每個表欄位單獨佔一行 無縮進 values每一項單獨佔一行 無縮進 > SQL文中間不允許出現空行 > Java source里單引號必須跟所屬的SQL子句處在同一行 連接符（ + ）必須在行首 ) 空格 > SQL內算數運算符 邏輯運算符連接的兩個元素之間必須用空格分隔 > 逗號之後必須接一個空格 > 關鍵字 保留字和左括弧之間必須有一個空格 不等於統一使用 <> Oracle認為 != 和 <> 是等價的 都代表不等於的意義 為了統一 不等於一律使用 <> 表示 使用表的別名 資料庫查詢 必須使用表的別名 SQL文對表欄位擴展的兼容性 在Java source里使用Select *時 嚴禁通過getString( )的形式得到查詢結果 必須使用getString( 欄位名 )的形式使用Insert時 必須指定插入的欄位名 嚴禁不指定欄位名直接插入values 減少子查詢的使用 子查詢除了可讀性差之外 還在一定程度上影響了SQL運行效率請盡量減少使用子查詢的使用 用其他效率更高 可讀性更好的方式替代 適當添加索引以提高查詢效率 適當添加索引可以大幅度的提高檢索速度請參看ORACLE SQL性能優化系列 對資料庫表操作的特殊要求 本項目對資料庫表的操作還有以下特殊要求 ) 以邏輯刪除替代物理刪除注意 現在資料庫表中數據沒有物理刪除 只有邏輯刪除以deleteflag欄位作為刪除標志 deleteflag= 代表此記錄被邏輯刪除 因此在查詢數據時必須考慮deleteflag的因素deleteflag的標准查詢條件 NVL(deleteflag ) <> ) 增加記錄狀態欄位資料庫中的每張表基本都有以下欄位 DELETEFLAG UPDATECOUNT CREDATE CREUSER UPDATETIME UPDATEUSER要注意在對標進行操作時必須考慮以下欄位插入一條記錄時要置DELETEFLAG= UPDATECOUNT= CREDATE=sysdate CREUSER=登錄User查詢一條記錄時要考慮DELETEFLAG 如果有可能對此記錄作更新時還要取得UPDATECOUNT作同步檢查修改一條記錄時要置UPDATETIME=sysdate UPDATEUSER=登錄User UPDATECOUNT=(UPDATECOUNT+ ) mod 刪除一條記錄時要置DELETEFLAG= ) 歷史表資料庫里部分表還存在相應的歷史表 比如srv_c_f和srv_chistory_f在查詢數據時除了檢索所在表之外 還必須檢索相應的歷史表 對二者的結果做Union（或Union All） 用執行計劃分析SQL性能 EXPLAIN PLAN是一個很好的分析SQL語句的工具 它可以在不執行SQL的情況下分析語句通過分析 我們就可以知道ORACLE是怎樣連接表 使用什麼方式掃描表（索引掃描或全表掃描） 以及使用到的索引名稱按照從里到外 從上到下的次序解讀分析的結果EXPLAIN PLAN的分析結果是用縮進的格式排列的 最內部的操作將最先被解讀 如果兩個操作處於同一層中 帶有最小操作號的將首先被執行目前許多第三方的工具如PLSQL Developer和TOAD等都提供了極其方便的EXPLAIN PLAN工具PG需要將自己添加的查詢SQL文記入log 然後在EXPLAIN PLAN中進行分析 盡量減少全表掃描 ORACLE SQL性能優化系列 選擇最有效率的表名順序(只在基於規則的優化器中有效) ORACLE的解析器按照從右到左的順序處理FROM子句中的表名 因此FROM子句中寫在最後的表（基礎表driving table）將被最先處理在FROM子句中包含多個表的情況下 必須選擇記錄條數最少的表作為基礎表當ORACLE處理多個表時 會運用排序及合並的方式連接它們首先 掃描第一個表（FROM子句中最後的那個表)並對記錄進行排序 然後掃描第二個表（FROM子句中最後第二個表) 最後將所有從第二個表中檢索出的記錄與第一個表中合適記錄進行合並例如:表 TAB 條記錄表 TAB 條記錄選擇TAB 作為基礎表 (最好的方法)select count(*) from tab tab 執行時間 秒選擇TAB 作為基礎表 (不佳的方法)select count(*) from tab tab 執行時間 秒如果有 個以上的表連接查詢 那就需要選擇交叉表（intersection table）作為基礎表 交叉表是指那個被其他表所引用的表例如:EMP表描述了LOCATION表和CATEGORY表的交集SELECT *FROM LOCATION L CATEGORY C EMP EWHERE E EMP_NO BEEEN AND AND E CAT_NO = C CAT_NOAND E LOCN = L LOCN將比下列SQL更有效率SELECT *FROM EMP E LOCATION L CATEGORY CWHERE E CAT_NO = C CAT_NOAND E LOCN = L LOCNAND E EMP_NO BEEEN AND WHERE子句中的連接順序 ORACLE採用自下而上的順序解析WHERE子句根據這個原理 表之間的連接必須寫在其他WHERE條件之前 那些可以過濾掉最大數量記錄的條件必須寫在WHERE子句的末尾例如 (低效 執行時間 秒)SELECT *FROM EMP EWHERE SAL > AND JOB = MANAGER AND < (SELECT COUNT(*) FROM EMP WHERE MGR=E EMPNO);(高效 執行時間 秒)SELECT *FROM EMP EWHERE < (SELECT COUNT(*) FROM EMP WHERE MGR=E EMPNO)AND SAL > AND JOB = MANAGER ; SELECT子句中避免使用 * 當你想在SELECT子句中列出所有的COLUMN時 使用動態SQL列引用 * 是一個方便的方法 不幸的是 這是一個非常低效的方法實際上 ORACLE在解析的過程中 會將 * 依次轉換成所有的列名這個工作是通過查詢數據字典完 lishixin/Article/program/Oracle/201311/18246
Ⅳ 資料庫系統管理規范
管理規范這個要根據實際情況，資料庫類型，數據量，數據流，等等來制訂！！
這個需要經驗，沒有固定的模板，但你可以在網上找一些有這方面經驗的人的文章來做參考！！
----上面說了相當於沒說！僅僅做個標記！：）
Ⅳ 一個完整的資料庫包含哪些資料庫文件，其中哪些是在一個資料庫中必須存在的
分為「主要文件，次要文件，事物日誌文件」，其中「主要文件和事物日誌文件」是必須存在的。
Ⅵ 資料庫中為什麼要對關系模式進行規范化
關系模式進行規范化的目地：規范化目的是使結構更合理，消除存儲異常，使數據冗餘盡量小，便於插入、刪除和更新
關系模式進行規范化的原則：遵從概念單一化 "一事一地"原則，即一個關系模式描述一個實體或實體間的一種聯系。規范的實質就是概念的單一化。
關系模式進行規范化的方法：將關系模式投影分解成兩個或兩個以上的關系模式。
要求：分解後的關系模式集合應當與原關系模式"等價"，即經過自然聯接可以恢復原關系而不丟失信息，並保持屬性間合理的聯系。
注意：一個關系模式結這分解可以得到不同關系模式集合，也就是說分解方法不是唯一的。最小冗餘的要求必須以分解後的資料庫能夠表達原來資料庫所有信息為前提來實現。其根本目標是節省存儲空間，避免數據不一致性，提高對關系的操作效率，同時滿足應用需求。實際上，並不一定要求全部模式都達到BCNF不可。有時故意保留部分冗餘可能更方便數據查詢。尤其對於那些更新頻度不高，查詢頻度極高的資料庫系統更是如此。
Ⅶ 為什麼資料庫規范化處理
通常情況下，可以從兩個方面來判斷資料庫是否設計的比較規范。一是看看是否擁有大量的窄表，二是寬表的數量是否足夠的少。若符合這兩個條件，則可以說明這個資料庫的規范化水平還是比較高的。當然這是兩個泛泛而談的指標。為了達到資料庫設計規范化的要求，一般來說，需要符合以下五個要求。
要求一：表中應該避免可為空的列。
雖然表中允許空列，但是，空欄位是一種比較特殊的數據類型。資料庫在處理的時候，需要進行特殊的處理。如此的話，就會增加資料庫處理記錄的復雜性。當表中有比較多的空欄位時，在同等條件下，資料庫處理的性能會降低許多。
所以，雖然在資料庫表設計的時候，允許表中具有空欄位，但是，我們應該盡量避免。若確實需要的話，我們可以通過一些折中的方式，來處理這些空欄位，讓其對資料庫性能的影響降低到最少。
一是通過設置默認值的形式，來避免空欄位的產生。如在一個人事管理系統中，有時候身份證號碼欄位可能允許為空。因為不是每個人都可以記住自己的身份證號碼。而在員工報到的時候，可能身份證沒有帶在身邊。所以，身份證號碼欄位往往不能及時提供。為此，身份證號碼欄位可以允許為空，以滿足這些特殊情況的需要。但是，在資料庫設計的時候，則可以做一些處理。如當用戶沒有輸入內容的時候，則把這個欄位的默認值設置為0或者為N/A。以避免空欄位的產生。
二是若一張表中，允許為空的列比較多，接近表全部列數的三分之一。而且，這些列在大部分情況下，都是可有可無的。若資料庫管理員遇到這種情況，筆者建議另外建立一張副表，以保存這些列。然後通過關鍵字把主表跟這張副表關聯起來。將數據存儲在兩個獨立的表中使得主表的設計更為簡單，同時也能夠滿足存儲空值信息的需要。
要求二：表不應該有重復的值或者列。
為了解決這個問題，有多種實現方式。但是，若設計不合理的話在，則會導致重復的值或者列。如我們也可以這么設計，把客戶信息、聯系人都放入同一張表中。為了解決多個聯系人的問題，可以設置第一聯系人、第一聯系人電話、第二聯系人、第二聯系人電話等等。若還有第三聯系人、第四聯系人等等，則往往還需要加入更多的欄位。
所以，在資料庫設計的時候要盡量避免這種重復的值或者列的產生。筆者建議，若資料庫管理員遇到這種情況，可以改變一下策略。如把客戶聯系人另外設置一張表。然後通過客戶ID把供應商信息表跟客戶聯系人信息表連接起來。也就是說，盡量將重復的值放置到一張獨立的表中進行管理。然後通過視圖或者其他手段把這些獨立的表聯系起來。
要求三：表中記錄應該有一個唯一的標識符。
在資料庫表設計的時候，資料庫管理員應該養成一個好習慣，用一個ID號來唯一的標識行記錄，而不要通過名字、編號等欄位來對紀錄進行區分。每個表都應該有一個ID列，任何兩個記錄都不可以共享同一個ID值。另外，這個ID值最好有資料庫來進行自動管理，而不要把這個任務給前台應用程序。否則的話，很容易產生ID值不統一的情況。
要求四：資料庫對象要有統一的前綴名。
一個比較復雜的應用系統，其對應的資料庫表往往以千計。若讓資料庫管理員看到對象名就了解這個資料庫對象所起的作用，恐怕會比較困難。而且在資料庫對象引用的時候，資料庫管理員也會為不能迅速找到所需要的資料庫對象而頭疼。
其次，表、視圖、函數等最好也有統一的前綴。如視圖可以用V為前綴，而函數則可以利用F為前綴。如此資料庫管理員無論是在日常管理還是對象引用的時候，都能夠在最短的時間內找到自己所需要的對象。
要求五：盡量只存儲單一實體類型的數據。
這里將的實體類型跟數據類型不是一回事，要注意區分。這里講的實體類型是指所需要描述對象的本身。筆者舉一個例子，估計大家就可以明白其中的內容了。如現在有一個圖書館里系統，有圖書基本信息、作者信息兩個實體對象。若用戶要把這兩個實體對象信息放在同一張表中也是可以的。如可以把表設計成圖書名字、圖書作者等等。可是如此設計的話，會給後續的維護帶來不少的麻煩。
遇到這種情況時，筆者建議可以把上面這張表分解成三種獨立的表，分別為圖書基本信息表、作者基本信息表、圖書與作者對應表等等。如此設計以後，以上遇到的所有問題就都引刃而解了。
以上五條是在資料庫設計時達到規范化水平的基本要求。除了這些另外還有很多細節方面的要求，如數據類型、存儲過程等等。而且，資料庫規范往往沒有技術方面的嚴格限制，主要依靠資料庫管理員日常工作經驗的累積。