管理信息資料庫的設計

Ⅰ 什麼是資料庫的概念設計、邏輯設計、物理設計，以及三者的關系

1、概念設計：

對用戶要求描述的現實世界(可能是一個工廠、一個商場或者一個學校等)，通過對其中住處的分類、聚集和概括，建立抽象的概念數據模型。這個概念模型應反映現實世界各部門的信息結構、信息流動情況、信息間的互相制約關系以及各部門對信息儲存、查詢和加工的要求等。

所建立的模型應避開資料庫在計算機上的具體實現細節，用一種抽象的形式表示出來。以擴充的實體—（E-R模型）聯系模型方法為例，第一步先明確現實世界各部門所含的各種實體及其屬性、實體間的聯系以及對信息的制約條件等，從而給出各部門內所用信息的局部描述。第二步再將前面得到的多個用戶的局部視圖集成為一個全局視圖，即用戶要描述的現實世界的概念數據模型。

2、邏輯設計：

主要工作是將現實世界的概念數據模型設計成資料庫的一種邏輯模式，即適應於某種特定資料庫管理系統所支持的邏輯數據模式。與此同時，可能還需為各種數據處理應用領域產生相應的邏輯子模式。這一步設計的結果就是所謂「邏輯資料庫」。

3、物理設計：

根據特定資料庫管理系統所提供的多種存儲結構和存取方法等依賴於具體計算機結構的各項物理設計措施，對具體的應用任務選定最合適的物理存儲結構(包括文件類型、索引結構和數據的存放次序與位邏輯等)、存取方法和存取路徑等。這一步設計的結果就是所謂「物理資料庫」。

4、三者關系：

由上到下，先要概念設計，接著邏輯設計，再是物理設計，一級一級設計。三者一環扣住一環，缺一不可，概念設計是前提，邏輯設計是紐扣，將概念設計和物理設計緊密聯系起來，物理設計的結果就是傳說中的「物理資料庫」也就是最後的結果。三者密不可分，缺一不可。

(1)管理信息資料庫的設計擴展閱讀

資料庫設計的基本步驟：

1、需求分析階段：准確了解與分析用戶需求（包括數據與處理），是整個設計過程的基礎，是最困難、最耗費時間的一步。

2、概念結構設計階段：是整個資料庫設計的關鍵,通過對用戶的需求進行綜合、歸納與抽象，形成一個獨立於具體DBMS的概念模型。從實際到理論。

3、邏輯結構設計階段：將概念結構轉換為某個DBMS所支持的數據模型,對其進行優化。優化理論。

4、資料庫物理設計階段：為邏輯數據模型選取一個最適合應用環境的物理結構（包括存儲結構和存取方法）。選擇理論落腳點。

5、資料庫實施階段：運用DBMS提供的數據語言、工具及宿主語言，根據邏輯設計和物理設計的結果,建立資料庫，編制與調試應用程序，組織數據入庫，並進行試運行。理論應用於實踐。

6、資料庫運行和維護階段：資料庫應用系統經過試運行後即可投入正式運行。在資料庫系統運行過程中必須不斷地對其進行評價、調整與修改。理論指導實踐，反過來實踐修正理論。

主要特點：

1、 實現數據共享：資料庫伺服器數據共享包含所有用戶可同時存取資料庫中的數據，也包括用戶可以用各種方式通過介面使用資料庫，並提供數據共享。

2、 減少數據的冗餘度：同文件系統相比，由於資料庫實現了數據共享，從而避免了用戶各自建立應用文件。減少了大量重復數據，減少了數據冗餘，維護了數據的一致性。

3、數據的獨立性：數據的獨立性包括邏輯獨立性（資料庫中資料庫的 邏輯結構和 應用程序相互獨立）和物理獨立性（數據物理結構的變化不影響數據的邏輯結構）。

4、數據實現集中控制：文件管理方式中，數據處於一種分散的狀態，不同的用戶或同一用戶在不同處理中其文件之間毫無關系。利用資料庫可對數據進行集中控制和管理，並通過 數據模型表示各種數據的組織以及數據間的聯系。

5、數據一致性和可維護性，以確保數據的安全性和可靠性主要包括：安全性控制：以防止數據丟失、錯誤更新和越權使用；完整性控制：保證數據的正確性、有效性和相容性；並發控制：使在同一時間 周期內，允許對數據實現多路存取，又能防止用戶之間的不正常交互作用。

6、故障恢復：由資料庫管理系統提供一套方法，可及時發現故障和修復故障，從而防止數據被破壞。資料庫系統能盡快恢復資料庫系統運行時出現的故障，可能是物理上或是邏輯上的錯誤。比如對系統的誤操作造成的數據錯誤等。

Ⅱ 信息管理資料庫設計

要幫忙設計你的這些個表？
那太費事了。
我告訴你怎麼設計吧
欄位名：給你的資料庫起一個列名。就好比EXCEL的列名一個道理。但是不能用中文
欄位類型：常用的有（varchar(x)可控制字元型x填寫你的欄位的最大長度，你可以設的大一點，
int 數字型，只包括整數
float 浮點小數
datetime 時間
text 文本類型，不限制字元長度
其他類型去網路吧
）
欄位長度：這個你也估計一個最大長度吧
是否主鍵：主鍵在每個表裡邊只有一個。一般用自動增長的編號來做主鍵，主鍵相當於人的身份證號碼，不能有重復的值，專門做標示用，沒其他的意思
備注就隨便填了，前面那些項不能完全表達你的意思，就補充在備注里邊。

下面那些都是要錢的。別費事留你的郵箱了

Ⅲ 資料庫如何設計

資料庫設計的基本步驟

按照規范設計的方法，考慮資料庫及其應用系統開發全過程，將資料庫設計分為以下6個階段

1.需求分析

2.概念結構設計

3.邏輯結構設計

4.物理結構設計

5.資料庫實施

6.資料庫的運行和維護

資料庫設計通常分為6個階段1分析用戶的需求，包括數據、功能和性能需求；2概念結構設計：主要採用E-R模型進行設計，包括畫E-R圖；3邏輯結構設計：通過將轉換成表，實現從E-R模型到關系模型的轉換；4：主要是為所設計的資料庫選擇合適的和存取路徑；5資料庫的實施：包括編程、測試和試運行；6資料庫運行與維護：系統的運行與資料庫的日常維護。）,主要討論其中的第3個階段,即邏輯設計。

在資料庫設計過程中，需求分析和概念設計可以獨立於任何資料庫管理系統進行，邏輯設計和物理設計與選用的DAMS密切相關。

1.需求分析階段（常用自頂向下）

進行資料庫設計首先必須准確了解和分析用戶需求（包括數據與處理）。需求分析是整個設計過程的基礎，也是最困難，最耗時的一步。需求分析是否做得充分和准確，決定了在其上構建資料庫大廈的速度與質量。需求分析做的不好，會導致整個資料庫設計返工重做。

需求分析的任務，是通過詳細調查現實世界要處理的對象，充分了解原系統工作概況，明確用戶的各種需求，然後在此基礎上確定新的系統功能，新系統還得充分考慮今後可能的擴充與改變，不僅僅能夠按當前應用需求來設計。

調查的重點是，數據與處理。達到信息要求，處理要求，安全性和完整性要求。

分析方法常用SA(Structured Analysis) 結構化分析方法，SA方法從最上層的系統組織結構入手，採用自頂向下，逐層分解的方式分析系統。

數據流圖表達了數據和處理過程的關系，在SA方法中，處理過程的處理邏輯常常藉助判定表或判定樹來描述。在處理功能逐步分解的同事，系統中的數據也逐級分解，形成若干層次的數據流圖。系統中的數據則藉助數據字典（data dictionary，DD）來描述。數據字典是系統中各類數據描述的集合，數據字典通常包括數據項，數據結構，數據流，數據存儲，和處理過程5個階段。

2.概念結構設計階段（常用自底向上）

概念結構設計是整個資料庫設計的關鍵，它通過對用戶需求進行綜合，歸納與抽象，形成了一個獨立於具體DBMS的概念模型。

設計概念結構通常有四類方法：

• 自頂向下。即首先定義全局概念結構的框架，再逐步細化。

• 自底向上。即首先定義各局部應用的概念結構，然後再將他們集成起來，得到全局概念結構。

• 逐步擴張。首先定義最重要的核心概念結構，然後向外擴張，以滾雪球的方式逐步生成其他的概念結構，直至總體概念結構。

• 混合策略。即自頂向下和自底向上相結合。

3.邏輯結構設計階段（E-R圖）

邏輯結構設計是將概念結構轉換為某個DBMS所支持的數據模型，並將進行優化。

在這階段，E-R圖顯得異常重要。大家要學會各個實體定義的屬性來畫出總體的E-R圖。

各分E-R圖之間的沖突主要有三類：屬性沖突，命名沖突，和結構沖突。

E-R圖向關系模型的轉換，要解決的問題是如何將實體性和實體間的聯系轉換為關系模式，如何確定這些關系模式的屬性和碼。

4.物理設計階段

物理設計是為邏輯數據結構模型選取一個最適合應用環境的物理結構（包括存儲結構和存取方法）。

首先要對運行的事務詳細分析，獲得選擇物理資料庫設計所需要的參數，其次，要充分了解所用的RDBMS的內部特徵，特別是系統提供的存取方法和存儲結構。

常用的存取方法有三類：1.索引方法，目前主要是B+樹索引方法。2.聚簇方法（Clustering）方法。3.是HASH方法。

5.資料庫實施階段

資料庫實施階段，設計人員運營DBMS提供的資料庫語言（如sql）及其宿主語言，根據邏輯設計和物理設計的結果建立資料庫，編制和調試應用程序，組織數據入庫，並進行試運行。

6.資料庫運行和維護階段

資料庫應用系統經過試運行後，即可投入正式運行，在資料庫系統運行過程中必須不斷地對其進行評價，調整，修改。

資料庫設計5步驟
Five Steps to design the Database

1.確定entities及relationships

a)明確宏觀行為。資料庫是用來做什麼的？比如，管理雇員的信息。

b)確定entities。對於一系列的行為，確定所管理信息所涉及到的主題范圍。這將變成table。比如，僱用員工，指定具體部門，確定技能等級。

c)確定relationships。分析行為，確定tables之間有何種關系。比如，部門與雇員之間存在一種關系。給這種關系命名。

d)細化行為。從宏觀行為開始，現在仔細檢查這些行為，看有哪些行為能轉為微觀行為。比如，管理雇員的信息可細化為：

· 增加新員工

· 修改存在員工信息

· 刪除調走的員工

e)確定業務規則。分析業務規則，確定你要採取哪種。比如，可能有這樣一種規則，一個部門有且只能有一個部門領導。這些規則將被設計到資料庫的結構中。

====================================================================
範例：
ACME是一個小公司，在5個地方都設有辦事處。當前，有75名員工。公司准備快速擴大規模，劃分了9個部門，每個部門都有其領導。
為有助於尋求新的員工，人事部門規劃了68種技能，為將來人事管理作好准備。員工被招進時，每一種技能的專業等級都被確定。


定義宏觀行為
一些ACME公司的宏觀行為包括：
● 招聘員工
● 解僱員工
● 管理員工個人信息
● 管理公司所需的技能信息
● 管理哪位員工有哪些技能
● 管理部門信息
● 管理辦事處信息
確定entities及relationships
我們可以確定要存放信息的主題領域(表)及其關系，並創建一個基於宏觀行為及描述的圖表。
我們用方框來代表table，用菱形代表relationship。我們可以確定哪些relationship是一對多，一對一，及多對多。
這是一個E-R草圖，以後會細化。



細化宏觀行為
以下微觀行為基於上面宏觀行為而形成：
● 增加或刪除一個員工
● 增加或刪除一個辦事處
● 列出一個部門中的所有員工
● 增加一項技能
● 增加一個員工的一項技能
● 確定一個員工的技能
● 確定一個員工每項技能的等級
● 確定所有擁有相同等級的某項技能的員工
● 修改員工的技能等級

這些微觀行為可用來確定需要哪些table或relationship。

確定業務規則
業務規則常用於確定一對多，一對一，及多對多關系。
相關的業務規則可能有：
● 現在有5個辦事處；最多允許擴展到10個。
● 員工可以改變部門或辦事處
● 每個部門有一個部門領導
● 每個辦事處至多有3個電話號碼
● 每個電話號碼有一個或多個擴展
● 員工被招進時，每一種技能的專業等級都被確定。
● 每位員工擁有3到20個技能
● 某位員工可能被安排在一個辦事處，也可能不安排辦事處。

2.確定所需數據

要確定所需數據：

a)確定支持數據

b)列出所要跟蹤的所有數據。描述table(主題)的數據回答這些問題：誰，什麼，哪裡，何時，以及為什麼

c)為每個table建立數據

d)列出每個table目前看起來合適的可用數據

e)為每個relationship設置數據

f)如果有，為每個relationship列出適用的數據

確定支持數據

你所確定的支持數據將會成為table中的欄位名。比如，下列數據將適用於表Employee，表Skill，表Expert In。

Employee

Skill

Expert In

ID

ID

Level

Last Name

Name

Date acquired

First Name

Description

Department

Office

Address


如果將這些數據畫成圖表，就像：



• 需要注意：


• ● 在確定支持數據時，請一定要參考你之前所確定的宏觀行為，以清楚如何利用這些數據。


• ● 比如，如果你知道你需要所有員工的按姓氏排序的列表，確保你將支持數據分解為名字與姓氏，這比簡單地提供一個名字會更好。


• ● 你所選擇的名稱最好保持一致性。這將更易於維護資料庫，也更易於閱讀所輸出的報表。


• ● 比如，如果你在某些地方用了一個縮寫名稱Emp_status，你就不應該在另外一個地方使用全名(Empolyee_ID)。相反，這些名稱應當是Emp_status及Emp_id。


• ● 數據是否與正確的table相對應無關緊要，你可以根據自己的喜好來定。在下節中，你會通過測試對此作出判斷。

3.標准化數據

標准化是你用以消除數據冗餘及確保數據與正確的table或relationship相關聯的一系列測試。共有5個測試。本節中，我們將討論經常使用的3個。
關於標准化測試的更多信息，請參考有關資料庫設計的書籍。

標准化格式
標准化格式是標准化數據的常用測試方式。你的數據通過第一遍測試後，就被認為是達到第一標准化格式；通過第二遍測試，達到第二標准化格式；通過第三遍測試，達到第三標准化格式。

如何標准格式：
1． 列出數據
2． 為每個表確定至少一個鍵。每個表必須有一個主鍵。
3． 確定relationships的鍵。relationships的鍵是連接兩個表的鍵。
4． 檢查支持數據列表中的計算數據。計算數據通常不保存在資料庫中。
5． 將數據放在第一遍的標准化格式中：
6． 從tables及relationships除去重復的數據。
7． 以你所除去數據創建一個或更多的tables及relationships。
8． 將數據放在第二遍的標准化格式中：
9． 用多於一個以上的鍵確定tables及relationships。
10． 除去只依賴於鍵一部分的數據。
11． 以你所除去數據創建一個或更多的tables及relationships。
12． 將數據放在第三遍的標准化格式中：
13． 除去那些依賴於tables或relationships中其他數據，並且不是鍵的數據。
14． 以你所除去數據創建一個或更多的tables及relationships。

數據與鍵
在你開始標准化（測試數據）前，簡單地列出數據，並為每張表確定一個唯一的主鍵。這個鍵可以由一個欄位或幾個欄位（連鎖鍵）組成。

主鍵是一張表中唯一區分各行的一組欄位。Employee表的主鍵是Employee ID欄位。Works In relationship中的主鍵包括Office Code及Employee ID欄位。給資料庫中每一relationship給出一個鍵，從其所連接的每一個table中抽取其鍵產生。

RelationShip

Key

Office

*Office code

Office address

Phone number

Works in

*Office code

*Employee ID

Department

*Department ID

Department name

Heads

*Department ID

*Employee ID

Assoc with

*Department ID

*EmployeeID

Skill

*Skill ID

Skill name

Skill description

Expert In

*Skill ID

*Employee ID

Skill level

Date acquired

Employee

*Employee ID

Last Name

First Name

Social security number

Employee street

Employee city

Employee state

Employee phone

Date of birth


將數據放在第一遍的標准化格式中
● 除去重復的組
● 要測試第一遍標准化格式，除去重復的組，並將它們放進他們各自的一張表中。
● 在下面的例子中，Phone Number可以重復。（一個工作人員可以有多於一個的電話號碼。）將重復的組除去，創建一個名為Telephone的新表。在Telephone與Office創建一個名為Associated With的relationship。

將數據放在第二遍的標准化格式中
● 除去那些不依賴於整個鍵的數據。
● 只看那些有一個以上鍵的tables及relationships。要測試第二遍標准化格式，除去那些不依賴於整個鍵的任何數據（組成鍵的所有欄位）。
● 在此例中，原Employee表有一個由兩個欄位組成的鍵。一些數據不依賴於整個鍵；例如，department name只依賴於其中一個鍵（Department ID）。因此，Department ID，其他Employee數據並不依賴於它，應移至一個名為Department的新表中，並為Employee及Department建立一個名為Assigned To的relationship。


將數據放在第三遍的標准化格式中
● 除去那些不直接依賴於鍵的數據。
● 要測試第三遍標准化格式，除去那些不是直接依賴於鍵，而是依賴於其他數據的數據。
● 在此例中，原Employee表有依賴於其鍵（Employee ID）的數據。然而，office location及office phone依賴於其他欄位，即Office Code。它們不直接依賴於Employee ID鍵。將這組數據，包括Office Code，移至一個名為Office的新表中，並為Employee及Office建立一個名為Works In的relationship。

4.考量關系

當你完成標准化進程後，你的設計已經差不多完成了。你所需要做的，就是考量關系。

考量帶有數據的關系
你的一些relationship可能集含有數據。這經常發生在多對多的關系中。

遇到這種情況，將relationship轉化為一個table。relationship的鍵依舊成為table中的鍵。

考量沒有數據的關系
要實現沒有數據的關系，你需要定義外部鍵。外部鍵是含有另外一個表中主鍵的一個或多個欄位。外部鍵使你能同時連接多表數據。

有一些基本原則能幫助你決定將這些鍵放在哪裡：

一對多在一對多關系中，「一」中的主鍵放在「多」中。此例中，外部鍵放在Employee表中。

一對一在一對一關系中，外部鍵可以放進任一表中。如果必須要放在某一邊，而不能放在另一邊，應該放在必須的一邊。此例中，外部鍵（Head ID）在Department表中，因為這是必需的。

多對多在多對多關系中，用兩個外部鍵來創建一個新表。已存的舊表通過這個新表來發生聯系。

5.檢驗設計

在你完成設計之前，你需要確保它滿足你的需要。檢查你在一開始時所定義的行為，確認你可以獲取行為所需要的所有數據：
● 你能找到一個路徑來等到你所需要的所有信息嗎？
● 設計是否滿足了你的需要？
● 所有需要的數據都可用嗎？
如果你對以上的問題都回答是，你已經差不多完成設計了。

最終設計
最終設計看起來就像這樣：

設計資料庫的表屬性
資料庫設計需要確定有什麼表，每張表有什麼欄位。此節討論如何指定各欄位的屬性。

對於每一欄位，你必須決定欄位名，數據類型及大小，是否允許NULL值，以及你是否希望資料庫限制欄位中所允許的值。

選擇欄位名
欄位名可以是字母、數字或符號的任意組合。然而，如果欄位名包括了字母、數字或下劃線、或並不以字母打頭，或者它是個關鍵字（詳見關鍵字表），那麼當使用欄位名稱時，必須用雙引號括起來。

為欄位選擇數據類型
SQL Anywhere支持的數據類型包括：
整數（int, integer, smallint）
小數（decimal, numeric）
浮點數（float, double）
字元型（char, varchar, long varchar）
二進制數據類型（binary, long binary）
日期/時間類型（date, time, timestamp）
用戶自定義類型

關於數據類型的內容，請參見「SQL Anywhere數據類型」一節。欄位的數據類型影響欄位的最大尺寸。例如，如果你指定SMALLINT，此欄位可以容納32,767的整數。INTEGER可以容納2,147,483,647的整數。對CHAR來講，欄位的最大值必須指定。

長二進制的數據類型可用來在資料庫中保存例如圖像(如點陣圖)或者文字編輯文檔。這些類型的信息通常被稱為二進制大型對象，或者BLOBS。

關於每一數據類型的完整描述，見「SQL Anywhere數據類型」。

Ⅳ 資料庫設計是指設計資料庫管理系統嗎

不是；前者是設計應用，後者是設計軟體怎麼開發。

資料庫設計(Database Design)是指對於一個給定的應用環境，構造最優的資料庫模式，建立資料庫及其應用系統。

使之能夠有效地存儲數據，滿足各種用戶的應用需求（信息要求和處理要求）。在資料庫領域內，常常把使用資料庫的各類系統統稱為資料庫應用系統。

資料庫管理系統(Database Management System)是一種操縱和管理資料庫的大型軟體，用於建立、使用和維護資料庫，簡稱DBMS。

它對資料庫進行統一的管理和控制，以保證資料庫的安全性和完整性。用戶通過DBMS訪問資料庫中的數據，資料庫管理員也通過dbms進行資料庫的維護工作。

它可使多個應用程序和用戶用不同的方法在同時或不同時刻去建立，修改和詢問資料庫。

大部分DBMS提供數據定義語言DDL（Data Definition Language）和數據操作語言DML（Data Manipulation Language）。

供用戶定義資料庫的模式結構與許可權約束，實現對數據的追加、刪除等操作。

(4)管理信息資料庫的設計擴展閱讀：

資料庫設計是建立資料庫及其應用系統的技術，是信息系統開發和建設中的核心技術。

由於資料庫應用系統的復雜性，為了支持相關程序運行，資料庫設計就變得異常復雜，因此最佳設計不可能一蹴而就。

而只能是一種「反復探尋，逐步求精」的過程，也就是規劃和結構化資料庫中的數據對象以及這些數據對象之間關系的過程。

需求分析：

調查和分析用戶的業務活動和數據的使用情況，弄清所用數據的種類、范圍、數量以及它們在業務活動中交流的情況，確定用戶對資料庫系統的使用要求和各種約束條件等，形成用戶需求規約。

需求分析是在用戶調查的基礎上，通過分析，逐步明確用戶對系統的需求，包括數據需求和圍繞這些數據的業務處理需求。

在需求分析中，通過自頂向下，逐步分解的方法分析系統，分析的結果採用數據流程圖(DFD)進行圖形化的描述。

概念設計：

對用戶要求描述的現實世界(可能是一個工廠、一個商場或者一個學校等)，通過對其中諸處的分類、聚集和概括，建立抽象的概念數據模型。

這個概念模型應反映現實世界各部門的信息結構、信息流動情況、信息間的互相制約關系以及各部門對信息儲存、查詢和加工的要求等。

所建立的模型應避開資料庫在計算機上的具體實現細節，用一種抽象的形式表示出來。

以擴充的實體—（E-R模型）聯系模型方法為例，第一步先明確現實世界各部門所含的各種實體及其屬性、實體間的聯系以及對信息的制約條件等。

從而給出各部門內所用信息的局部描述(在資料庫中稱為用戶的局部視圖)。第二步再將前面得到的多個用戶的局部視圖集成為一個全局視圖，即用戶要描述的現實世界的概念數據模型。

資料庫管理系統是一種操縱和管理資料庫的大型軟體，用於建立、使用和維護資料庫，簡稱 DBMS。它對資料庫進行統一的管理和控制，以保證資料庫的安全性和完整性。

資料庫管理系統是一個能夠提供數據錄入、修改、查詢的數據操作軟體，具有數據定義、數據操作、數據存儲與管理、數據維護、通信等功能，且能夠允許多用戶使用。

另外，資料庫管理系統的發展與計算機技術發展密切相關。而且近年來，計算機網路逐漸成為人們生活的重要組成部分。

為此，若要進一步完善計算機資料庫管理系統，技術人員就應當不斷創新、改革計算機技術，並不斷拓寬計算機資料庫管理系統的應用范圍，從而真正促進計算機資料庫管理系統技術的革新。

技術特點：

（1）採用復雜的數據模型表示數據結構，數據冗餘小，易擴充，實現了數據共享。

（2）具有較高的數據和程序獨立性，資料庫的獨立性有物理獨立性和邏輯獨立性。

（3）資料庫系統為用戶提供了方便的用戶介面。

（4）資料庫系統提供4個方面的數據控制功能，分別是並發控制、恢復、完整性和安全性。

資料庫中各個應用程序所使用的數據由資料庫系統統一規定，按照一定的數據模型組織和建立，由系統統一管理和集中控制。

（5）增加了系統的靈活性。

參考資料來源：網路-資料庫設計

網路-資料庫管理系統

Ⅳ 如何合理和有效的進行資料庫設計

通常情況下，可以從兩個方面來判斷資料庫設計的是否規范:
1)一是看看是否擁有大量的窄表
窄表往往對於OLTP比較合適，符合範式設計原則
2)寬表的數量是否足夠的少。
所謂的寬表就是欄位比較多的表，包含的維度層次比較多，造成冗餘也比較多，毀範式設計，但是利於取數統計
若符合這兩個條件，我們可以說資料庫設計的比較好.
當然這是兩個泛泛而談的指標。為了達到資料庫設計規范化的要求，一般來說，需要符合以下五個要求。
要求一：表中應該避免可為空的列。
雖然表中允許空列，但是，空欄位是一種比較特殊的數據類型。資料庫在處理的時候，需要進行特殊的處理。如此的話，就會增加資料庫處理記錄的復雜性。當表中有比較多的空欄位時，在同等條件下，資料庫處理的性能會降低許多。
所以，雖然在資料庫表設計的時候，允許表中具有空欄位，但是，我們應該盡量避免。若確實需要的話，我們可以通過一些折中的方式，來處理這些空欄位，讓其對資料庫性能的影響降低到最少。
要求二：表不應該有重復的值或者列。
如現在有一個進銷存管理系統，這個系統中有一張產品基本信息表中。這個產品開發有時候可以是一個人完成，而有時候又需要多個人合作才能夠完成。所以，在產品基本信息表產品開發者這個欄位中，有時候可能需要填入多個開發者的名字。
如進銷存管理中，還需要對客戶的聯系人進行管理。有時候，企業可能只知道客戶一個采購員的姓名。但是在必要的情況下，企業需要對客戶的采購代表、倉庫人員、財務人員共同進行管理。因為在訂單上，可能需要填入采購代表的名字;可是在出貨單上，則需要填入倉庫管理人員的名字等等。
為了解決這個問題，有多種實現方式。但是，若設計不合理的話在，則會導致重復的值或者列。如我們也可以這么設計，把客戶信息、聯系人都放入同一張表中。為了解決多個聯系人的問題，可以設置第一聯系人、第一聯系人電話、第二聯系人、第二聯系人電話等等。若還有第三聯系人、第四聯系人等等，則往往還需要加入更多的欄位。
所以，我們在資料庫設計的時候要盡量避免這種重復的值或者列的產生。筆者建議，若資料庫管理員遇到這種情況，可以改變一下策略。如把客戶聯系人另外設置一張表。然後通過客戶ID把供應商信息表跟客戶聯系人信息表連接起來。也就是說，盡量將重復的值放置到一張獨立的表中進行管理。然後通過視圖或者其他手段把這些獨立的表聯系起來。
要求三：表中記錄應該有一個唯一的標識符。
在資料庫表設計的時候，資料庫管理員應該養成一個好習慣，用一個ID號來唯一的標識行記錄，而不要通過名字、編號等欄位來對紀錄進行區分。每個表都應該有一個ID列，任何兩個記錄都不可以共享同一個ID值。另外，這個ID值最好有資料庫來進行自動管理，而不要把這個任務給前台應用程序。否則的話，很容易產生ID值不統一的情況。
另外，在資料庫設計的時候，最好還能夠加入行號。如在銷售訂單管理中，ID號是用戶不能夠維護的。但是，行號用戶就可以維護。如在銷售訂單的行中，用戶可以通過調整行號的大小來對訂單行進行排序。通常情況下，ID列是以1為單位遞進的。但是，行號就要以10為單位累進。如此，正常情況下，行號就以10、20、30依次擴展下去。若此時用戶需要把行號為30的紀錄調到第一行顯示。此時，用戶在不能夠更改ID列的情況下，可以更改行號來實現。如可以把行號改為1，在排序時就可以按行號來進行排序。如此的話，原來行號為30的紀錄現在行號變為了1，就可以在第一行中顯示。這是在實際應用程序設計中對ID列的一個有效補充。這個內容在教科書上是沒有的。需要在實際應用程序設計中，才會掌握到這個技巧。
要求四：資料庫對象要有統一的前綴名。
一個比較復雜的應用系統，其對應的資料庫表往往以千計。若讓資料庫管理員看到對象名就了解這個資料庫對象所起的作用，恐怕會比較困難。而且在資料庫對象引用的時候，資料庫管理員也會為不能迅速找到所需要的資料庫對象而頭疼。
其次，表、視圖、函數等最好也有統一的前綴。如視圖可以用V為前綴，而函數則可以利用F為前綴。如此資料庫管理員無論是在日常管理還是對象引用的時候，都能夠在最短的時間內找到自己所需要的對象。
要求五：盡量只存儲單一實體類型的數據。
這里將的實體類型跟數據類型不是一回事，要注意區分。這里講的實體類型是指所需要描述對象的本身。筆者舉一個例子，估計大家就可以明白其中的內容了。如現在有一個圖書館里系統，有圖書基本信息、作者信息兩個實體對象。若用戶要把這兩個實體對象信息放在同一張表中也是可以的。如可以把表設計成圖書名字、圖書作者等等。可是如此設計的話，會給後續的維護帶來不少的麻煩。
如當後續有圖書出版時，則需要為每次出版的圖書增加作者信息，這無疑會增加額外的存儲空間，也會增加記錄的長度。而且若作者的情況有所改變，如住址改變了以後，則還需要去更改每本書的記錄。同時，若這個作者的圖書從資料庫中全部刪除之後，這個作者的信息也就盪然無存了。很明顯，這不符合資料庫設計規范化的需求。
遇到這種情況時，筆者建議可以把上面這張表分解成三種獨立的表，分別為圖書基本信息表、作者基本信息表、圖書與作者對應表等等。如此設計以後，以上遇到的所有問題就都引刃而解了。

Ⅵ 資料庫設計過程包括幾個主要階段哪些階段獨立於資料庫管理系統哪些階段依賴於資料庫管理系統

資料庫設計階段包括五個階段，分別是：需求分析階段、概念結構設計階段、邏輯結構設計階段、物理設計階段、資料庫實施階段、資料庫運行和維護階段。

獨立於資料庫管理系統的是：需求分析階段，概念設計階段，邏輯設計階段，物理設計階段。

依賴於資料庫管理系統的是：實施階段，運行和維護階段。

資料庫設計是建立資料庫及其應用系統的技術，是信息系統開發和建設中的核心技術。由於資料庫應用系統的復雜性，為了支持相關程序運行，資料庫設計就變得異常復雜。

因此最佳設計不可能一蹴而就，而只能是一種「反復探尋，逐步求精」的過程，也就是規劃和結構化資料庫中的數據對象以及這些數據對象之間關系的過程。

(6)管理信息資料庫的設計擴展閱讀：

形成過程

1、需求分析階段：綜合各個用戶的應用需求(數據流程圖(DFD)。

2、概念設計階段：形成獨立於機器特點，獨立於各個DBMS產品的概念模式(E-R圖)。

3、邏輯設計階段：首先將E-R圖轉換成具體的資料庫產品支持的數據模型，如關系模型，形成資料庫邏輯模式；然後根據用戶處理的要求、安全性的考慮，在基本表的基礎上再建立必要的視圖(View)，形成數據的外模式。

4、物理設計階段：根據DBMS特點和處理的需要，進行物理存儲安排，建立索引，形成資料庫內模式。

Ⅶ .資料庫設計分為幾個階段,各階段的任務是什麼

按照規范的設計方法，一個完整的資料庫設計一般分為需求分析、概念結構設計、邏輯結構設計、資料庫物理設計、資料庫的實施、資料庫運行與維護六個階段：

各階段的任務如下：

1、需求分析：分析用戶的需求，包括數據、功能和性能需求；

拓展資料：

資料庫設計(Database Design)是指對於一個給定的應用環境，構造最優的資料庫模式，建立資料庫及其應用系統，使之能夠有效地存儲數據，滿足各種用戶的應用需求(信息要求和處理要求)。在資料庫領域內，常常把使用資料庫的各類系統統稱為資料庫應用系統。

資料庫設計是建立資料庫及其應用系統的技術，是信息系統開發和建設中的核心技術。由於資料庫應用系統的復雜性，為了支持相關程序運行，資料庫設計就變得異常復雜，因此最佳設計不可能一蹴而就，而只能是一種"反復探尋，逐步求精"的過程，也就是規劃和結構化資料庫中的數據對象以及這些數據對象之間關系的過程。