資料庫設計方案

Ⅰ 資料庫怎麼設計多對多的數據表

1.資料庫中的多對多關聯關系一般需採用中間表的方式處理，將多對多轉化為兩個一對多。
2.通過表的關系，來幫助我們怎樣建表，建幾張表。
一對一
一張表的一條記錄一定只能與另外一張表的一條記錄進行對應，反之亦然。

學生表：姓名，性別，年齡，身高，體重，籍貫，家庭住址，緊急聯系人
其中姓名、性別、年齡、身高，體重屬於常用數據，但是籍貫、住址和聯系人為不常用數據
如果每次查詢都是查詢所有數據，不常用的數據就會影響效率，實際又不用
常用信息表：ID(P)，姓名，性別，年齡，身高，體重
不常用信息表：ID(P)，籍貫，家庭住址，緊急聯系人

解決方案：將常用的和不常用的信息分享存儲，分成兩張表
不常用信息表和常用信息表，保證不常用信息表與常用信息表能夠對應上：找一個具有唯一性的
欄位來共同連接兩張表。
一個常用表中的一條記錄永遠只能在一張不常用表中匹配一條記錄，反之亦然。
一對多
一張表中有一條記錄可以對應另外一張表中的多條記錄；但是反過來，另外一張表的一條記錄
只能對應第一張表的一條記錄，這種關系就是一對多或多對一
母親與孩子的關系：母親，孩子兩個實體
母親表：ID(P),名字，年齡，性別
孩子表：ID(P),名字，年齡，性別
以上關系：一個媽媽可以在孩子表中找到多條記錄（也可能是一條），但是一個孩子只能找到一個媽媽
是一種典型的一對多的關系。
但是以上設計：解決了實體的設計表問題，但是沒有解決關系問題，孩子找不到母親，母親也找不到孩子

解決方案：在某一張表中增加一個欄位，能夠找到另外一張表中的記錄:在孩子表中增加一個欄位
指向母親表，因為孩子表的記錄只能匹配到一條母親表的記錄。
母親表：ID(P),名字，年齡，性別
孩子表：ID(P),名字，年齡，性別，母親表ID（母親表主鍵）
多對多
一對表中（A）的一條記錄能夠對應另外一張表（B）中的多條記錄；同時B表中的一條記錄
也能對應A表中的多條記錄

老師和學生
老師表 T_ID(P),姓名，性別
學生表 S_ID(P),姓名，性別
以上設計方案：實現了實體的設計，但是沒有維護實體的關系
一個老師教過多個學生，一個學生也被多個老師教過

解決方案：增加一張中間關系表
老師與學生的關系表：ID(P),T_ID,S_ID
老師表與中間表形成一對多的關系，而中間表是多表；維護了能夠唯一找到一表的關系；
同樣的學生表與中間表也是一個一對多的關系;
學生找老師：找出學生ID--->中間表尋找匹配記錄（多條）--->老師表匹配（一條）
老師找學生：找出老師ID--->中間表尋找匹配記錄（多條）--->學生表匹配（一條）

Ⅱ 大學生信息資料庫改怎麼設計

第二個看上去好些。但是聯合主鍵太多，個人不建議這樣設計。
你的兩種設計都有硬傷：耦合度太高。
我想多說兩句的事，數據的主鍵、外鍵是很強的約束，能夠解決很多問題；可是同樣會帶來很多問題。如果想讓系統更加靈活，就不能把表結構設計得太死。依賴關系不能太強。否則，如果你的系統需要擴展，你的資料庫就要修改。打個比方，地基都改了，那麼上面的建築自然也要動。不然系統就會癱瘓。

下面說說我的建議：
方案一：每張表中都增加一個欄位，確保此欄位全表唯一。比如可以叫做 unique_id，用來唯一定位數據，類似rowid。聯合主鍵全都不要。我知道你會問，這樣一來就沒有主外鍵約束，就會出現重復的，或者沒有依賴關系的數據。解決這個不難，程序控制。可以使用存儲過程，在固化數據，修改或刪除數據時加以控制。
這樣做的好處是只要整個設計不改動，資料庫無需調整。
當然也有缺點，投入量會大，很多控制需要編寫代碼。

方案二：採用你的第一種設計方式，從數據入手，將每張表中的id都採用一定的規則，比如：專業id中前幾位由系id組成，確保不同系中不會出現相同的專業id。其他表以此類推。不過這個方案也依賴程序中對各種id生成時的控制。
相比方案一，程序量較小。

方案三：也就是你的第二種方案，把對數據的控制都交給主鍵和外鍵。不過不建議。

自己斟酌一下吧。

Ⅲ 求一份圖書管理系統的資料庫設計方案

1． 對圖書館的信息建幾個表，考慮表之間的關系。
2．系統功能的基本要求：
a) 對資料庫的編輯功能：對圖書館信息記錄的添加、修改、刪除。
b) 對圖書的統計（國內圖書、國外圖書、計算機圖書、外語圖書、中文圖等各類圖書的統計）。
c) 對圖書的查詢（按關鍵字查詢、模糊查詢等）；
d) 對報表的列印；
e) 界面友好。

1、概述
包括項目背景、編寫目的、軟體定義、開發環境等內容。
2、需求分析
問題陳述、需完成的功能。
用數據流圖、數據字典、判斷樹等完成。
3、資料庫概念設計
畫出ER模型圖
4、資料庫邏輯設計
把ER模型圖轉換為關系表。
描述每一個基本表關系。要求所有關系達到BCNF範式。
定義視圖、定義索引、主關鍵字、定義許可權。
5 物理設計
主要用到存取方法
6、結束語
寫出完成本課程設計的心得，領會資料庫理論與軟體開發實踐的關系。有哪些收獲。軟體還需要哪些改進。
設計結果：設計報告，源程序代碼。

Ⅳ 資料庫規劃一般要包含那些內容

總體數據規劃主要從三個方面去規劃：1、管理方面、2、技術方面 3、用戶方面。
總體規劃的內容包括：戰略的業務規劃、戰略的信息技術規劃、戰略的數據規劃。

Ⅳ 大型Oracle資料庫如何設計

超大型系統的特點為： 1、處理的用戶數一般都超過百萬，有的還超過千萬，資料庫的數據量一般超過1TB; 2、系統必須提供實時響應功能，系統需不停機運行，要求系統有很高的可用性及可擴展性。 為了能達到以上要求，除了需要性能優越的計算機和海量存儲設備外，還需要先進的資料庫結構設計和優化的應用系統。 一般的超大型系統採用雙機或多機集群系統。下面以資料庫採用Oracle 8.0.6並行伺服器為例來談談超大型資料庫設計方法： 確定系統的ORACLE並行伺服器應用劃分策略 資料庫物理結構的設計 系統硬碟的劃分及分配 備份及恢復策略的考慮 二、Oracle並行伺服器應用劃分策略 Oracle並行伺服器允許不同節點上的多個INSTANCE實例同時訪問一個資料庫，以提高系統的可用性、可擴展性及性能。Oracle並行伺服器中的每個INSTANCE實例都可將共享資料庫中的表或索引的數據塊讀入本地的緩沖區中，這就意味著一個數據塊可存在於多個INSTANCE實例的SGA區中。那麼保持這些緩沖區的數據的一致性就很重要。Oracle使用 PCM( Parallel Cache Management)鎖維護緩沖區的一致性，Oracle同時通過I DLM(集成的分布式鎖管理器)實現PCM 鎖,並通過專門的LCK進程實現INSTANCE實例間的數據一致。 考慮這種情況：INSTANCE1對BLOCK X塊修改，這時INSTANCE2對BLOCK X塊也需要修改。Oracle並行伺服器利用PCM鎖機制，使BLOCK X從INSTANCE 1的SGA區寫入資料庫數據文件中，又從數據文件中把BLOCK X塊讀入INSTANCE2的SGA區中。發生這種情況即為一個PING。PING使原來1個MEMORY IO可以完成的工作變成2個DISK IO和1個 MEMORY IO才能夠完成,如果系統中有過多的PING，將大大降低系統的性能。 Oracle並行伺服器中的每個PCM鎖可管理多個數據塊。PCM鎖管理的數據塊的個數與分配給一個數據文件的PCM鎖的個數及該數據文件的大小有關。當INSTANCE 1和INSTANCE 2要操作不同的BLOCK，如果這些BLOCK 是由同一個PCM鎖管理的,仍然會發生PING。這些PING稱為FALSE PING。當多個INSTANCE訪問相同的BLOCK而產生的PING是TRUE PING。 合理的應用劃分使不同的應用訪問不同的數據，可避免或減少TRUE PING;通過給FALSE PING較多的數據文件分配更多的PCM鎖可減少 FALSE PING的次數，增加PCM鎖不能減少TRUE PING。 所以，Oracle並行伺服器設計的目的是使系統交易處理合理的分布在INSTANCE實例間，以最小化PING，同時合理的分配PCM鎖，減少FALSE PING。設計的關鍵是找出可能產生的沖突，從而決定應用劃分的策略。應用劃分有如下四種方法： 1、根據功能模塊劃分，不同的節點運行不同的應用 2、根據用戶劃分，不同類型的用戶運行在不同的節點上 3、根據數據劃分，不同的節點訪問不同的數據或索引 4、根據時間劃分，不同的應用在不同的時間段運行 應用劃分的兩個重要原則是使PING最小化及使各節點的負載大致均衡。 三、資料庫物理結構的設計 資料庫物理結構設計包括確定表及索引的物理存儲參數，確定及分配資料庫表空間，確定初始的回滾段，臨時表空間，redo log files等，並確定主要的初始化參數。物理設計的目的是提高系統的性能。整個物理設計的參數可以根據實際運行情況作調整。 表及索引數據量估算及物理存儲參數的設置 表及索引的存儲容量估算是根據其記錄長度及估算的最大記錄數確定的。在容量計算中考慮了數據塊的頭開銷及記錄和欄位的頭開銷等等。

Ⅵ 如何設計穩健的資料庫之如何減少磁碟IO

1、首先你要確定的資料庫的量。這點很重要，決定了你的設計方案。

2、要根據你的業務來決定你的數據類型。不要總選varchar(50)來代替Int，有些人認為varchar什麼數據都支持，所以就選這個類型，其實資料庫是保存在磁碟上的，如果10000000這個數字，在Int中就是4個位元組，而在varhchar就是保留8個位元組，因為選擇這個數據類型，就需要多讀一倍的磁碟數據，給磁碟IO帶來負擔。