資料庫關系表的設計

㈠ 數據表設計考慮哪些問題

DB2資料庫的性能與穩定性直接跟資料庫對象的多少、大小有關。如果對象很少，不復雜，那麼就算不怎麼規劃，也能夠達到比較高的性能。如果對象數據比較多、比較大的話，那麼就需要在資料庫設計之前好好的規劃，否則會在很大程度上影響資料庫的性能與穩定性。

一、選擇合適的語言與資料庫字元集。

在企業中部署資料庫的時候，首先需要在操作系統上安裝資料庫。而在安裝資料庫的時候，需要選擇安裝的語言環境。即是以中文狀態下安裝資料庫還是以英文狀態安裝資料庫。如在啟動安裝程序的時，可以利用/i language選項來指定安裝過程中所採用的語言。到目前為止，DB2資料庫已經支持很多種語言。那麼資料庫在安裝過程中，該採用什麼語言呢？筆者建議，只要資料庫管理員有一點英語基礎，最好能夠採用英文語言環境來進行安裝。雖然說現在DB2資料庫的中文語言環境已經設計的比較完善，但是筆者仍然擔心其有一些不知名的漏洞。為此筆者在安裝DB2資料庫的時候，基本上都採用的是英文語言環境來進行安裝。即將語言設置為「EN」，表示英文。提高DB2數據備份與恢復的效率。

另外如果DB2 資料庫中要保存英文以外的數據，或者說用戶會使用不同的字元集訪問資料庫時，還需要在資料庫安裝過程中選擇特定的資料庫字元集。DB2資料庫中的所有字元數據，包括數據字典中的數據，都是存儲在資料庫字元集中的。如果用戶使用不同的字元集訪問資料庫時，資料庫管理員就需要選擇包含所有這些用戶的字元集的超集。只有如此，才能夠確保系統能夠很方便的使用替代字元完成字元的轉換，從而提高資料庫的性能。如果用戶選擇的字元集不對，有可能會出現一些莫名其妙的問題。如一次用戶在安裝資料庫過程中，沒有選擇合適的字元集。雖然在使用的過程中，其存儲中文字元沒有問題。但是當對資料庫採取還原操作時，卻發現還原後的資料庫中有些原來是中文字元的地方，盡然出現了亂碼。這主要就是沒有選擇合適的字元集惹的禍。有時候如果字元集選擇不當的話，從外部數據源(如Excel表格)導入數據的時候，中文數據也會無法順利導入。所以，資料庫管理員在安裝資料庫的時候，需要根據實際企業，來選擇合適的字元集。

二、評估資料庫對象的大小、數量。

DB2資料庫的性能與穩定性直接跟資料庫對象的多少、大小有關。如果對象很少，不復雜，那麼就算不怎麼規劃，也能夠達到比較高的性能。如果對象數據比較多、比較大的話，那麼就需要在資料庫設計之前好好的規劃，否則會在很大程度上影響資料庫的性能與穩定性。其實DB2 資料庫就好像一個倉庫，資料庫中的對象(如索引、數據表、表空間)等等就好像倉庫中的貨物。如果貨物比較少，那麼隨便放放，倉庫都顯得很空曠。貨物尋找起來也會很方便。但是如果貨物數量比較多、比較大，就必須要對其存儲空間進行合理規劃。只有如此才能夠讓倉庫的空間利用率達到最佳狀態。並且貨物的存放有序，在查找起來也特別的方便。筆者這里就以倉庫管理為例，說話該如何做好資料庫對象大小、數量等方便的評估，以及他們對於資料庫性能與穩定性的影響。

1、根據對象大小來規劃存儲空間。在倉庫貨物的擺放上，要根據貨物的大小來規劃存儲空間。或者說要首先防止大的貨物。只有如此空間的利用率才會最高。其實在規劃DB2對象的時候，也是如此。如某些表可能會包含的記錄比較多，屬於大表。此時資料庫管理員就需要考慮，是否將其放置在一個獨立的表空間或者硬碟空間上，以提高數據操作的性能。大表所對應的索引往往也是比較大的。為此在硬體條件允許的情況下，將索引表與數據表分別存放在不同的硬碟上，可以提高資料庫的性能。而對於一些比較小的對象(如數據表)，可以將它們存放在一個表空間中。其實這個表空間就好像倉庫中的一個個紙盒子。將小的對象放入到這個「紙盒子」中，不但不佔空間，而且也容易管理。

2、根據對象的使用頻率來規劃存放空間。在倉庫中擺放物品的時候，往往會把近期就要用到的貨物或者頻繁需要用到的東西放在倉庫門口或者容易拿到的地方。如此在拿這些貨物時就會比較便捷，也不會對其他貨物產生影響。對於DB2資料庫中的對象來說，也是這么一回事。可以將那些訪問量比較大的對象，如索引、數據表，存放在性能比較好的硬碟上或者單獨的硬碟中。此時訪問這些數據，就不會與其它對象產生I/O沖突，操作起來速度就會比較快。而將不怎麼用到的對象，存放在一起。由於他們不怎麼被用到，所以即使存放在性能比較低的硬碟上，其對資料庫性能產生的負面影響也是非常有限的。 在DB2資料庫裡面如何更新執行計劃

3、根據類別來存放資料庫對象。在倉庫中存放貨物的時候，還會對其進行分類。然後根據類別來進行存放。這有利於貨物的管理與檢索。其實在資料庫對象存儲空間設計時，也需要考慮這個因素。如現在應用軟體在設計的時候，很多都是根據模塊來設計。那麼在資料庫對象設計時，也需要根據這個模塊來設計存儲的空間。如將同一個模塊的資料庫對象存放在同一個表空間內。不過這可能會跟上面的兩個建立相違背。此時最好是在對象的命名上做文章。如可以根據模塊的不同，分別給資料庫對象取一個相同的前綴或者後綴。如即使同一塊模塊要用到多個表空間，此時就可以給表空間一個相同的前綴。如此在管理資料庫對象的時候，根據表空間的前綴就可以判斷其所屬的模塊了。如果再加上一個後綴來表示其資料庫對象的分類，那麼就更合理了。為此在管理資料庫對象的時候，要執行分類管理。不僅要從技術上對其進行分類，如分為索引、數據表、關鍵字等等。還需要從功能上進行分類，如按應用程序的模塊來進行分類等等。

三、設計好資料庫備份與還原的方案。

在資料庫交付生產使用之後，往往需要進行大量的測試。但是在測試過程中往往又會產生很多的垃圾數據。可是交給企業應用的，肯定是一個干凈的資料庫系統。為此在資料庫設計的時候，就需要想好如果減少測試過程中的垃圾數據。或者採取什麼樣的方式來實現在交互時自動清除垃圾數據的機制。

一般來說，想要一個資料庫備份與還原的方案，減少資料庫測試所產生的垃圾數據。如現在在給企業部署資料庫的時候，往往是先安裝一個干凈的資料庫系統。當然字元集這些需要預先設置好。然後再利用資料庫還原功能將預先定義好的資料庫模型還原出來。

另外有些時候需要兩個方案互為補充。如在資料庫初始化的過程中，採用資料庫還原的方式來創建資料庫對象。但是在應用軟體升級的時候，由於此時已經有了用戶的數據，為此不能夠在使用資料庫還原的方法。而是通過應用程序來執行某些SQL代碼，來調整或者增加部分資料庫對象。無論採用哪一種方式，需要遵循的一個原則就是在給企業創建資料庫對象時要最大限度的減少測試。而要做到這一點，就是需要先在測試伺服器上創建對象並測試對象可用。然後直接將相關的SQL代碼在投入使用的資料庫伺服器上執行。

㈡ 資料庫多表關聯如何設計

你用用戶表和管理員表
關聯有什麼意義么？
表之間的關聯是表示表之間的關系
比如
你有個用戶分類表
在用戶表中有個用戶類型
這個時候在用戶類型欄位
你就可以存放用戶分類的一個編號
【注意：在這里這個編號只要是唯一的就可以啊，見得一定得是自動編號的】
再打個比方說
一個員工表
記錄員工的基本信息
一個工資表
記錄員工的工資
這個時候在工資表中的員工信息部分完全可以只村一個員工編號【姓名可以重復
但是編號不會】
在每個表中的這個唯一的欄位
稱為「關鍵字」
當然也可以是幾個欄位的組合
比如員工有兩個叫張**
一個男的一個女的
我們在資料庫查詢的時候完全可以用
姓名='張**'
and
性別='男'
這樣來查詢到那個男的張**
當然就像是上面說的
這個員工還有個唯一的編號
這個時候可以用
編號=12345
這樣的來查詢到

㈢ 請問資料庫在創建表的時候如何設計表關系，一對一，一對多，多對多 請高手舉例說明。謝謝！！！

多對多關系至少需要3個表，我們把一個表叫做主表，一個叫做關系表，另外一個叫做字典表或者副表（字典表是紀錄比較少，而且基本穩定的，例如：版塊名稱；副表是內容比較多，內容變化的，例如）。
按照資料庫的增刪查改操作，多對多關系的查找都可以用inner join或者

select * from 主表 where id in (select 主表id from 關系表)

1，角色任命型

特點：關系表兩外鍵組合無重復紀錄，關系表一般不需要時間欄位和主鍵，有一個表是字典類型的表。
界面特點：顯示主表，用checkbox或多選select設置多選關系。
例如：任命版主（用戶表-關系表-版塊名稱表），角色許可權控制等，用戶是5個版塊版主，只要關系表5行紀錄就可以確立，關系表的兩個外鍵具有聯合主鍵性質。
增加關系：如果沒有組合紀錄，insert之。
刪除關系：如果有組合紀錄，刪除之。

2，集合分組型

特點：同角色任命型類似，關系表兩外鍵組合無重復紀錄，關系表一般不需要時間欄位和主鍵。區別是主副表都不是字典表，可能都很大不固定。
界面特點：顯示主表，用搜索代替簡單的checkbox或多選select，或者一條一條的添加。
例如：歌曲專集（專集表-關系表-歌曲表）。手機分組（分組表-關系表-手機表）。用戶圈子（圈子表-關系表-用戶表）。文章標簽（文章表-關系表-標簽表）
增加關系：同版主任命型。
刪除關系：同版主任命型。

3，明細帳型

特點：關系表可以有重復紀錄，關系表一般有時間欄位，有主鍵，可能還有文字型的欄位用來說明每次發生關系的原因（消費）。
界面特點：顯示關系表，用radio或下拉設置單選關系。
例如：現金消費明細帳或訂單（用戶表-訂單表-消費原因表），用戶可能多次在同一事情上重復消費。積分變化紀錄也屬於這類。
增加關系：不管有沒有組合紀錄，insert之，紀錄時間。
刪除關系：根據關系表PK刪除。

4，評論回復型

特點：同明細帳型關系表一般有時間欄位，有主鍵，區別是重點在文字型的欄位用來說明每次發生關系的內容（評論回復）。
界面特點：回復文本框。
例如：論壇回復（用戶表-回復表-帖子表），用戶可能多次在不同帖子上評論回復費。
增加關系：不管有沒有組合紀錄，insert之，紀錄時間和文字。
刪除關系：根據關系表（回復表）PK刪除。

5，站內簡訊型

特點：主副表是同一個，關系表一般有時間欄位，有主鍵，重點在關系表文字型的欄位用來說明每次發生關系的內容（消息）或者其他標記位來表示文字已讀狀態時間等。
界面特點：回復文本框。
例如：站內簡訊（用戶表-簡訊表-用戶表），用戶可能給用戶群發或者單發，有標記位來表示文字已讀狀態時間等。
增加關系：不管有沒有組合紀錄，insert之，紀錄時間和文字。
刪除關系：根據關系表（回復表）PK刪除。

6，用戶好友型

特點：主副表是同一個，同集合分組型，關系表兩外鍵組合無重復紀錄，關系表一般不需要時間欄位和主鍵。
界面特點：同集合分組型，顯示主表，用搜索代替簡單的checkbox或多選select，或者一條一條的添加。
例如：下載站點的文件，（文件表-關系表-文件表）可以被軟體工具打開，軟體工具本身也是一種文件，可以被下載。用戶的好友，也是用戶（用戶表-好友關系表-用戶表）
增加關系：同版主任命型。
刪除關系：同版主任命型

㈣ 關系資料庫的幾種設計範式

.1 第一範式（1NF）無重復的列
所謂第一範式（1NF）是指資料庫表的每一列都是不可分割的基本數據項，同一列中不能有多個值，即實體中的某個屬性不能有多個值或者不能有重復的屬性。如果出現重復的屬性，就可能需要定義一個新的實體，新的實體由重復的屬性構成，新實體與原實體之間為一對多關系。在第一範式（1NF）中表的每一行只包含一個實例的信息。簡而言之，第一範式就是無重復的列。
說明：在任何一個關系資料庫中，第一範式（1NF）是對關系模式的基本要求，不滿足第一範式（1NF）的資料庫就不是關系資料庫。
1.2 第二範式（2NF）屬性完全依賴於主鍵[消除部分子函數依賴]
第二範式（2NF）是在第一範式（1NF）的基礎上建立起來的，即滿足第二範式（2NF）必須先滿足第一範式（1NF）。第二範式（2NF）要求資料庫表中的每個實例或行必須可以被唯一地區分。為實現區分通常需要為表加上一個列，以存儲各個實例的唯一標識。
第二範式（2NF）要求實體的屬性完全依賴於主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性，如果存在，那麼這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體，新實體與原實體之間是一對多的關系。為實現區分通常需要為表加上一個列，以存儲各個實例的唯一標識。簡而言之，第二範式就是屬性完全依賴於主鍵。
1.3 第三範式（3NF）屬性不依賴於其它非主屬性[消除傳遞依賴]
滿足第三範式（3NF）必須先滿足第二範式（2NF）。簡而言之，第三範式（3NF）要求一個資料庫表中不包含已在其它表中已包含的非主關鍵字信息。第三範式就是屬性不依賴於其它非主屬性。

㈤ 求access資料庫關聯多個表的設計方法

1.在access對象面板中，打開想要建立關系的數據表。方法是先選中。

㈥ 資料庫表的設計

用戶表：{用戶編號(PK)，用戶名，密碼，用戶類別, 所屬專業號(FK)}
課程表：{課程編號(PK)，課程名，用戶編號(FK) ,學分}
院 系：{院系編號(PK)，院名}
專 業：{專業號(PK)，專業名稱 ,專業簡介 ,總學時,所屬院號(FK)}
參考書：{索書號(PK)，課程編號(FK)，ISBN/ISSN，責任者，出版日期，校圖書館連接地址，電子書連接地址}
專業課程表{專業號,課程編號} 聯合主鍵

㈦ 資料庫在創建表的時候如何設計表關系

1、一對一可以兩個實體設計在一個資料庫中l例如設計一個夫妻表，裡面放丈夫和妻子

2、一對多可以建兩張表，將一這一方的主鍵作為多那一方的外鍵

3、多對多可以多加一張中間表，將另外兩個表的主鍵放到這個表中

㈧ 關系資料庫設計過程的步驟有哪些

資料庫設計包括六個主要步驟： 1、需求分析：了解用戶的數據需求、處理需求、安全性及完整性要求； 2、概念設計：通過數據抽象，設計系統概念模型，一般為E-R模型； 3、邏輯結構設計：設計系統的模式和外模式，對於關系模型主要是基本表和視圖； 4、物理結構設計：設計數據的存儲結構和存取方法，如索引的設計； 5、系統實施：組織數據入庫、編制應用程序、試運行； 6、運行維護：系統投入運行，長期的維護工作。

㈨ 如何設計資料庫中表的關系

1.理解您的數據
在設計表之前，應明確您打算如何處理數據，還要了解隨著時間的推移數據會發生什麼樣的變化。您所做的假設將會影響最終的設計。
2.您需要什麼樣的數據
設計應用程序時，關鍵要了解設計的最終結果，以便確保您准備好所有必需的數據並知道其來源。例如，報表的外觀、每個數據的來源以及所需的所有數據是否都存在。對項目損失最大的莫過於在項目後期發現重要報表缺少數據。
3.明確所需數據的類型和來源
知道需要什麼樣的數據後，就必須確定數據的來源。數據是否從其他數據源中導入？數據是否需要清理或驗證？用戶是否需要輸入數據？明確所需數據的類型和來源是資料庫設計的第一步。
4.您打算如何處理這些數據？
用戶是否需要編輯這些數據？如果需要，應如何顯示數據以便於用戶理解和編輯？有沒有驗證規則和相關的查找表？要求對編輯和刪除保留備份的數據輸入有沒有相關聯的審核問題？需要為用戶顯示哪些摘要信息？是否需要生成導出文件？了解這些信息後，就可以想像欄位之間是如何相互關聯的了。
5數據之間如何相互關聯？
將數據分組放入相關欄位（例如與客戶相關的信息、與發票相關的信息等），每個欄位組都代表要建立的表。然後考慮如何將這些表相互關聯。例如，哪些表具有一對多關系（例如，一個客戶可能持有多張發票）？哪些表具有一對一關系（這種情況下，通常會考慮將其組合到一個表中）？
6.隨著時間的推移數據會發生什麼樣的變化？
設計表之後，常常會由於沒有考慮時間的影響而導致以後出現嚴重問題。許多表設計在當時使用時效果非常好，但是，常常會因為用戶修改數據、添加數據以及隨時間的推移而崩潰。開發人員經常會發現需要重新設計表的結構來適應這些變化。表的結構發生變化時，所有相關的內容（查詢、窗體、報表、代碼等）也必須隨之更新。理解並預測數據會隨時間推移發生哪些變化，可以實現更好的設計，減少問題的發生。
7.學習如何使用查詢
了解如何分析和管理數據同樣很重要。您應該深刻理解查詢的工作原理，理解如何使用查詢在多個表之間鏈接數據，如何使用查詢對數據進行分組和匯總，以及如何在不需要以規范化格式顯示數據時使用交叉表查詢。
好的數據設計的最終目標就是要平衡兩個需要：既要隨著時間的推移有效地存儲數據，又要輕松地檢索和分析數據。理解查詢的功能對正確設計表很有幫助。