Ⅰ 資料庫為什麼要規范化
規范化是進行資料庫的設計，主要是為了消除冗餘，做到資料庫關系簡單，數據簡約
Ⅱ 資料庫遵循哪些標准
基本的有三範式，BCNF範式 ，第二範式已經不用了，可以不看
理論不是一下能說清楚的 需要自己去看去想，
設計的原則要和需求關應，不是固定的，要貼合現實模型
Ⅲ 資料庫系統建設需要依據哪些行業和國家標准或規范
你要是數據中心機房建設請參照一下標准：
1<<電子信息系統機房設計規范>>GB 50174-2008
2<<電子信息系統機房施工及驗收規范>>GB 50462-2008
3<<電子計算機場地通用規范>>GB/T 2887-2000
4<<防靜電活動地板通用規范>>SJ/T10796-2001
5<<通風與空調工程質量驗收規范>>GB 50243-2002
6<<火災自動報警系統設計規范>>GB 50116-2008
7<<火災自動報警系統施工及驗收規范>>GB 50166-2007
8<<供配電系統設計規范>>GB 50052-2009
9<<建築電氣工程施工質量驗收規范>>GB 50303-2002
10<<建築物電子信息系統防雷技術規范>>GB 50343-2004
11<<建築物防雷設計規范>>GB 50057-2010
12<<綜合布線系統工程設計規范>>GB/T50311-2007
13<<綜合布線系統工程驗收規范>>GB/T50312-2007
註： 數據中心建設不牽扯民用標准。。DXJS 標準是電信標准，看你是什麼行業，金融數據中心有自己的標准， 電力數據中心有自己的標准。
Ⅳ 理解什麼是資料庫規范化
優點是降低冗餘，利於保證數據的一致性和完整性；缺點是過度的規范化，易造成查詢和統計時的效率下降，這主要是由於多表連接所造成的問題。適當的反規范化設計可以提高效率，但最好在那些數據不太發生變化的情況下使用。通常情況下，可以從兩個方面來判斷資料庫是否設計的比較規范。一是看看是否擁有大量的窄表，二是寬表的數量是否足夠的少。若符合這兩個條件，則可以說明這個資料庫的規范化水平還是比較高的。當然這是兩個泛泛而談的指標。為了達到資料庫設計規范化的要求，一般來說，需要符合以下五個要求。要求一：表中應該避免可為空的列。雖然表中允許空列，但是，空欄位是一種比較特殊的數據類型。資料庫在處理的時候，需要進行特殊的處理。如此的話，就會增加資料庫處理記錄的復雜性。當表中有比較多的空欄位時，在同等條件下，資料庫處理的性能會降低許多。所以，雖然在資料庫表設計的時候，允許表中具有空欄位，但是，我們應該盡量避免。若確實需要的話，我們可以通過一些折中的方式，來處理這些空欄位，讓其對資料庫性能的影響降低到最少。一是通過設置默認值的形式，來避免空欄位的產生。如在一個人事管理系統中，有時候身份證號碼欄位可能允許為空。因為不是每個人都可以記住自己的身份證號碼。而在員工報到的時候，可能身份證沒有帶在身邊。所以，身份證號碼欄位往往不能及時提供。為此，身份證號碼欄位可以允許為空，以滿足這些特殊情況的需要。但是，在資料庫設計的時候，則可以做一些處理。如當用戶沒有輸入內容的時候，則把這個欄位的默認值設置為0或者為N/A。以避免空欄位的產生。二是若一張表中，允許為空的列比較多，接近表全部列數的三分之一。而且，這些列在大部分情況下，都是可有可無的。若資料庫管理員遇到這種情況，筆者建議另外建立一張副表，以保存這些列。然後通過關鍵字把主表跟這張副表關聯起來。將數據存儲在兩個獨立的表中使得主表的設計更為簡單，同時也能夠滿足存儲空值信息的需要。要求二：表不應該有重復的值或者列。為了解決這個問題，有多種實現方式。但是，若設計不合理的話在，則會導致重復的值或者列。如我們也可以這么設計，把客戶信息、聯系人都放入同一張表中。為了解決多個聯系人的問題，可以設置第一聯系人、第一聯系人電話、第二聯系人、第二聯系人電話等等。若還有第三聯系人、第四聯系人等等，則往往還需要加入的欄位。所以，在資料庫設計的時候要盡量避免這種重復的值或者列的產生。筆者建議，若資料庫管理員遇到這種情況，可以改變一下策略。如把客戶聯系人另外設置一張表。然後通過客戶ID把供應商信息表跟客戶聯系人信息表連接起來。也就是說，盡量將重復的值放置到一張獨立的表中進行管理。然後通過視圖或者其他手段把這些獨立的表聯系起來。要求三：表中記錄應該有一個唯一的標識符。在資料庫表設計的時候，資料庫管理員應該養成一個好習慣，用一個ID號來唯一的標識行記錄，而不要通過名字、編號等欄位來對紀錄進行區分。每個表都應該有一個ID列，任何兩個記錄都不可以共享同一個ID值。另外，這個ID值最好有資料庫來進行自動管理，而不要把這個任務給前台應用程序。否則的話，很容易產生ID值不統一的情況。要求四：資料庫對象要有統一的前綴名。一個比較復雜的應用系統，其對應的資料庫表往往以千計。若讓資料庫管理員看到對象名就了解這個資料庫對象所起的作用，恐怕會比較困難。而且在資料庫對象引用的時候，資料庫管理員也會為不能迅速找到所需要的資料庫對象而頭疼。其次，表、視圖、函數等最好也有統一的前綴。如視圖可以用V為前綴，而函數則可以利用F為前綴。如此資料庫管理員無論是在日常管理還是對象引用的時候，都能夠在最短的時間內找到自己所需要的對象。要求五：盡量只存儲單一實體類型的數據。這里將的實體類型跟數據類型不是一回事，要注意區分。這里講的實體類型是指所需要描述對象的本身。筆者舉一個例子，估計大家就可以明白其中的內容了。如現在有一個圖書館里系統，有圖書基本信息、作者信息兩個實體對象。若用戶要把這兩個實體對象信息放在同一張表中也是可以的。如可以把表設計成圖書名字、圖書作者等等。可是如此設計的話，會給後續的維護帶來不少的麻煩。遇到這種情況時，筆者建議可以把上面這張表分解成三種獨立的表，分別為圖書基本信息表、作者基本信息表、圖書與作者對應表等等。如此設計以後，以上遇到的所有問題就都引刃而解了。以上五條是在資料庫設計時達到規范化水平的基本要求。除了這些另外還有很多細節方面的要求，如數據類型、存儲過程等等。而且，資料庫規范往往沒有技術方面的嚴格限制，主要依靠資料庫管理員日常工作經驗的累積。第一範式每個分量不可再分第一範式消除了非主屬性對鍵的部分函數依賴,就是第二範式第二範式消除了任何屬性對鍵的傳遞依賴,就是第三範式~
Ⅳ 信息資料庫用戶管理規范規定了哪些原則
（一）完善管理制度，強化監管力度。資料庫系統的安全與企業自身內部的安全機制、內外網路環境、從業人員素質等密切相關。因此，企業應該完善網路系統安全規章制度，防範因制度缺陷帶來的風險；企業應該規范操作流程和故障處理流程，減少人為失誤與故障，提高故障處理速度，縮短故障處理時間；企業應該通過建立科學合理的責任追究機制，防止出現由於工作態度、工作作風等各種人為因素導致的資料庫安全事故。
（二）採取措施，確保資料庫數據的安全。保證資料庫數據的安全是資料庫日常管理與維護工作的首要任務，企業需要採取的安全措施主要有：
（1）網路及操作系統安全。網路系統是資料庫應用的外部環境和基礎，網路系統安全是資料庫安全的第一道屏障。從技術角度講，網路系統層次的安全防範技術有很多種，大致可以分為防火牆、數字簽名與認證、入侵檢測等。操作系統是資料庫系統的運行平台，能夠為資料庫系統提供一定程度的安全保護。
（2）操作系統的安全控制方法主要是採用隔離控制、訪問控制、信息加密和審計跟蹤。主要安全技術有操作系統安全策略、安全管理策略等。
（3）加強用戶身份驗證。用戶身份驗證是資料庫系統的重要防線。利用窗體身份驗證資料庫程序的漏洞，進而獲取存儲在資料庫中的用戶身份驗證密碼，這是目前對網路資料庫攻擊最常見的方式。對此，企業信息部門通常使用帶有salt值的單向密碼哈希值，以避免用戶密碼在資料庫中以明文形式存儲，減輕字典攻擊帶來的威脅。
（4）對重要數據加密。數據加密交換又稱密碼學，是計算機系統對信息進行保護的一種最可靠的辦法。它利用密碼技術對信息進行交換，實現信息隱蔽，從而有效保護信息的安全不受侵犯。資料庫加密要求加解密的粒度是每個記錄的欄位數據。採用庫外口加密的方式，對密鑰的管理較為簡單，只需借用文件加密的密鑰管理方法，將加密後的數據塊納入資料庫，在演算法或資料庫系統中做些必要的改動就行。這樣有利於公共數據字典的使用和維護系統的完整性。
（5）做好資料庫備份與恢復。數據備份是備份資料庫某個時刻的數據狀態，當系統出現意外時用來恢復系統。依靠網路辦公的企業，其信息系統很可能隨時被破壞而丟失數據。因此，資料庫管理系統必須具備把資料庫從錯誤狀態恢復到某一已知的正確狀態的功能，這就是資料庫的恢復技術。
（三）開展資料庫健康檢查。為及時發現資料庫系統存在的問題，在日常管理與維護中，數據管理員要對資料庫開展健康檢查。檢查內容主要包括以下六個方面
（1）系統環境：操作系統版本、文件系統容量、內存交換區使用率、系統性能。
（2）資料庫環境：資料庫和補丁版本、是否有僵屍資料庫進程、資料庫節點數、是否有其他資料庫產品及版本。
（3）日誌記錄：db2diag.log報錯、db2inst1.nfy報錯、是否有需要處理的DUMP文件。
（4）資料庫健康狀況：表空間利用率和狀態、表空間容器利用率和狀態、排序溢出、是否需要收集統計信息、是否需要數據重組、活動日誌和日誌所在文件系統利用率、死鎖發生率、鎖升級發生率、鎖等待的百分比、編目Cache命中率、包Cache命中率、監視堆利用率、資料庫堆利用率、資料庫緩沖池命中率。
（5）資料庫維護內容：最近一次統計信息收集時間、最近一次表數據重組時間、最近一次綁定包時間、最近一次資料庫備份時間。
（6）資料庫基本信息記錄：資料庫內存使用、環境變數。
資料庫的管理日常工作
（1） 每天對資料庫的運行狀態 , 日誌文件 , 備份情況 , 資料庫的空間使用情況 , 系統資源的使用情況進行檢查 , 發現並解決問題。
（2）每周對資料庫對象的空間擴展情況 , 數據的增長情況進行監控 , 對資料庫做健康檢查 , 對資料庫對象的狀態做檢查。
（3） 每月對表和索引等進行 Analyze, 檢查表空間碎片 , 尋找資料庫性能調整的機會 , 進行資料庫性能調整 , 提出下一步空間管理
計劃。對 ORACLE 資料庫狀態進行一次全面檢查。
資料庫管理的意義重大，關繫到企業信息系統的正常運作，仍至整個企業的生死存亡。要做好資料庫的日常管理與維護，不僅要求資料庫管理員熟悉掌握專業技術知識，還要有足夠的細心和高度的責任心。
Ⅵ 資料庫規范設計
這個書上應該都有的啊1.需求分析階段
准確了解與分析用戶需求（包括數據與處理）
是整個設計過程的基礎，是最困難、最耗費時間的一步
2.概念結構設計階段
是整個資料庫設計的關鍵
通過對用戶需求進行綜合、歸納與抽象，形成一個獨立於具體DBMS的概念模型
3.邏輯結構設計階段
將概念結構轉換為某個DBMS所支持的數據模型
對其進行優化
4.資料庫物理設計階段
為邏輯數據模型選取一個最適合應用環境的物理結構（包括存儲結構和存取方法）
5.資料庫實施階段
運用DBMS提供的數據語言、工具及宿主語言，根據邏輯設計和物理設計的結果
建立資料庫，編制與調試應用程序，組織數據入庫，並進行試運行
6.資料庫運行和維護階段
資料庫應用系統經過試運行後即可投入正式運行。
Ⅶ 如何在資料庫設計是規范成第三範式
你好，很高興能為您解答，請耐心看完，記得採納,謝謝.
第一範式：在任何一個關系資料庫中，第一範式（1NF）是對關系模式的基本要求，不滿足第一範式（1NF）的資料庫就不是關系資料庫。所謂第一範式（1NF）是指資料庫表的每一列都是不可分割的基本數據項，同一列中不能有多個值，即實體中的某個屬性不能有多個值或者不能有重復的屬性。如果出現重復的屬性，就可能需要定義一個新的實體，新的實體由重復的屬性構成，新實體與原實體之間為一對多關系。在第一範式（1NF）中表的每一行只包含一個實例的信息。
第二範式：第二範式（2NF）是在第一範式（1NF）的基礎上建立起來的，即滿足第二範式（2NF）必須先滿足第一範式（1NF）。第二範式（2NF）要求資料庫表中的每個實例或行必須可以被唯一地區分。為實現區分通常需要為表加上一個列，以存儲各個實例的唯一標識。這個唯一屬性列被稱為主關鍵字或主鍵、主碼。
第三範式：滿足第三範式（3NF）必須先滿足第二範式（2NF）。簡而言之，第三範式（3NF）要求一個資料庫表中不包含已在其它表中已包含的非主關鍵字信息。
資料庫的設計範式是資料庫設計所需要滿足的規范，滿足這些規范的資料庫是簡潔的、結構明晰的；同時，不會發生插入（insert）、刪除（delete）和更新（update）操作異常。反之則是亂七八糟，不僅給資料庫的編程人員製造麻煩，而且面目可憎，可能存儲了大量不需要的冗餘信息。
Ⅷ 資料庫系統管理規范
管理規范這個要根據實際情況，資料庫類型，數據量，數據流，等等來制訂！！
這個需要經驗，沒有固定的模板，但你可以在網上找一些有這方面經驗的人的文章來做參考！！
----上面說了相當於沒說！僅僅做個標記！：）
Ⅸ 為什麼資料庫規范化處理
通常情況下，可以從兩個方面來判斷資料庫是否設計的比較規范。一是看看是否擁有大量的窄表，二是寬表的數量是否足夠的少。若符合這兩個條件，則可以說明這個資料庫的規范化水平還是比較高的。當然這是兩個泛泛而談的指標。為了達到資料庫設計規范化的要求，一般來說，需要符合以下五個要求。
要求一：表中應該避免可為空的列。
雖然表中允許空列，但是，空欄位是一種比較特殊的數據類型。資料庫在處理的時候，需要進行特殊的處理。如此的話，就會增加資料庫處理記錄的復雜性。當表中有比較多的空欄位時，在同等條件下，資料庫處理的性能會降低許多。
所以，雖然在資料庫表設計的時候，允許表中具有空欄位，但是，我們應該盡量避免。若確實需要的話，我們可以通過一些折中的方式，來處理這些空欄位，讓其對資料庫性能的影響降低到最少。
一是通過設置默認值的形式，來避免空欄位的產生。如在一個人事管理系統中，有時候身份證號碼欄位可能允許為空。因為不是每個人都可以記住自己的身份證號碼。而在員工報到的時候，可能身份證沒有帶在身邊。所以，身份證號碼欄位往往不能及時提供。為此，身份證號碼欄位可以允許為空，以滿足這些特殊情況的需要。但是，在資料庫設計的時候，則可以做一些處理。如當用戶沒有輸入內容的時候，則把這個欄位的默認值設置為0或者為N/A。以避免空欄位的產生。
二是若一張表中，允許為空的列比較多，接近表全部列數的三分之一。而且，這些列在大部分情況下，都是可有可無的。若資料庫管理員遇到這種情況，筆者建議另外建立一張副表，以保存這些列。然後通過關鍵字把主表跟這張副表關聯起來。將數據存儲在兩個獨立的表中使得主表的設計更為簡單，同時也能夠滿足存儲空值信息的需要。
要求二：表不應該有重復的值或者列。
為了解決這個問題，有多種實現方式。但是，若設計不合理的話在，則會導致重復的值或者列。如我們也可以這么設計，把客戶信息、聯系人都放入同一張表中。為了解決多個聯系人的問題，可以設置第一聯系人、第一聯系人電話、第二聯系人、第二聯系人電話等等。若還有第三聯系人、第四聯系人等等，則往往還需要加入更多的欄位。
所以，在資料庫設計的時候要盡量避免這種重復的值或者列的產生。筆者建議，若資料庫管理員遇到這種情況，可以改變一下策略。如把客戶聯系人另外設置一張表。然後通過客戶ID把供應商信息表跟客戶聯系人信息表連接起來。也就是說，盡量將重復的值放置到一張獨立的表中進行管理。然後通過視圖或者其他手段把這些獨立的表聯系起來。
要求三：表中記錄應該有一個唯一的標識符。
在資料庫表設計的時候，資料庫管理員應該養成一個好習慣，用一個ID號來唯一的標識行記錄，而不要通過名字、編號等欄位來對紀錄進行區分。每個表都應該有一個ID列，任何兩個記錄都不可以共享同一個ID值。另外，這個ID值最好有資料庫來進行自動管理，而不要把這個任務給前台應用程序。否則的話，很容易產生ID值不統一的情況。
要求四：資料庫對象要有統一的前綴名。
一個比較復雜的應用系統，其對應的資料庫表往往以千計。若讓資料庫管理員看到對象名就了解這個資料庫對象所起的作用，恐怕會比較困難。而且在資料庫對象引用的時候，資料庫管理員也會為不能迅速找到所需要的資料庫對象而頭疼。
其次，表、視圖、函數等最好也有統一的前綴。如視圖可以用V為前綴，而函數則可以利用F為前綴。如此資料庫管理員無論是在日常管理還是對象引用的時候，都能夠在最短的時間內找到自己所需要的對象。
要求五：盡量只存儲單一實體類型的數據。
這里將的實體類型跟數據類型不是一回事，要注意區分。這里講的實體類型是指所需要描述對象的本身。筆者舉一個例子，估計大家就可以明白其中的內容了。如現在有一個圖書館里系統，有圖書基本信息、作者信息兩個實體對象。若用戶要把這兩個實體對象信息放在同一張表中也是可以的。如可以把表設計成圖書名字、圖書作者等等。可是如此設計的話，會給後續的維護帶來不少的麻煩。
遇到這種情況時，筆者建議可以把上面這張表分解成三種獨立的表，分別為圖書基本信息表、作者基本信息表、圖書與作者對應表等等。如此設計以後，以上遇到的所有問題就都引刃而解了。
以上五條是在資料庫設計時達到規范化水平的基本要求。除了這些另外還有很多細節方面的要求，如數據類型、存儲過程等等。而且，資料庫規范往往沒有技術方面的嚴格限制，主要依靠資料庫管理員日常工作經驗的累積。
Ⅹ 什麼是資料庫中的規范化
規范化理論把關系應滿足的規范要求分為幾級，滿足最低要求的一級叫做第一範式(1NF)，在第一範式的基礎上提出了第二範式(2NF)，在第二範式的基礎上又提出了第三範式(3NF)，以後又提出了BCNF範式，4NF，5NF。範式的等級越高，應滿足的約束集條件也越嚴格。
第一範式（1NF）
在關系模式R中中，如果每個屬性值都是不可再分的原子屬性，則稱R是第一範式的關系[2]。例如：關系R（職工號，姓名，電話號碼）中一個人可能有一個辦公室電話和一個住宅電話號碼，規范成為1NF的方法一般是將電話號碼分為單位電話和住宅電話兩個屬性，即 R（職工號，姓名，辦公電話，住宅電話）。1NF是關系模式的最低要求。
第二範式（2NF）
如果關系模式R是1NF且其中的所有非主屬性都完全函數依賴於關鍵字，則稱關系R 是屬於第二範式的[2]。例：選課關系 SC（SNO，CNO，GRADE，CREDIT）其中SNO為學號， CNO為課程號，GRADEGE 為成績，CREDIT 為學分。 由以上條件，關鍵字為組合關鍵字（SNO，CNO）。在應用中使用以上關系模式有以下問題： （1）數據冗餘，假設同一門課由40個學生選修，學分就重復40次；（2）更新復雜，若調整了某課程的學分，相應元組的CREDIT值都要更新，有可能會出現同一門課學分不同；（3）插入異常，如計劃開新課，由於沒人選修，沒有學號關鍵字，只能等有人選修才能把課程和學分存入；（4）.刪除異常，若學生已經結業，從當前資料庫刪除選修記錄，而某些課程新生尚未選修，則此門課程及學分記錄無法保存。以上問題產生的原因是非主屬性CREDIT僅函數依賴於CNO，也就是CREDIT部分依賴組合關鍵字（SNO，CNO）而不是完全依賴。解決方法是將以上關系分解成兩個關系模式 SC（SNO，CNO，GRADE）和C（CNO，CREDIT）。新關系包括兩個關系模式，它們之間通過SC中的外鍵CNO相聯系，需要時再進行自然聯接，恢復原來的關系
第三範式（3NF）
如果關系模式R是2NF且其中的所有非主屬性都不傳遞依賴於碼，則稱關系R是屬於第三範式的[1]。例如關系模式S（SNO，SNAME，DNO，DNAME，LOCATION）中各屬性分別代表學號、姓名、所在系、系名稱、系地址。關鍵字SNO決定各個屬性。由於是單個關鍵字，沒有部分依賴的問題，肯定是2NF。但關系S肯定有大量的冗餘，有關學生所在系的幾個屬性DNO，DNAME，LOCATION將重復存儲，插入、刪除和修改時也將產生類似以上例的情況。原因在於關系中存在傳遞依賴，即SNO -> DNO，DNO -> LOCATION, 因此關鍵字SNO對LOCATION函數決定是通過傳遞依賴SNO -> LOCATION 實現的。也就是說，SNO不直接決定非主屬性LOCATION。解決方法是將該關系模式分解為兩個關系S（SNO，SNAME，DNO）和D（DNO，DNAME，LOCATION），兩個關系通過S中的外鍵DNO聯系。
BC範式(BCNF)
如果關系模式R的所有屬性（包括主屬性和非主屬性）都不傳遞依賴於R的任何候選關鍵字，那麼稱關系R是屬於BCNF的。或者說關系模式R中，如果每個決定因素都包含關鍵字（而不是被關鍵字所包含），則R是BCNF[3]。 通常認為BCNF是修正的第三範式，有時也稱為擴充的第三範式。