資料庫設計圖

㈠ 資料庫的邏輯結構設計的E-R圖

E-R圖的組件有很多，但概括起來說，可分為以下四種：
線段：用於將實體、關系相連接
對於雙矩形、雙菱形、雙橢圓、雙線段等等一些組件，可以不用去管，通常用以上四種組件就可以表達清楚實體及實體間的關系。
從E-R圖向關系模式轉化 資料庫的邏輯設計主要是將概念模型轉換成一般的關系模式，也就是將E-R圖中的實體、實體的屬性和實體之間的聯系轉化為關系模式。在轉化過程中會遇到如下問題：
(1)命名問題。命名問題可以採用原名，也可以另行命名，避免重名。
(2)非原子屬性問題。非原子屬性問題可將其進行縱向和橫行展開。
(3)聯系轉換問題。聯系可用關系表示。 1、標識實體：
通常有用戶、角色這兩個實體。
2、標識關系：
用戶與角色間為多對多的互相擁有關系。
3、標識實體、關系的屬性:
不僅僅是實體有屬性，關系同樣也有屬性，這些屬性在實體間建立關系時才會存在。
有時屬性太多，無法在圖上一一列出，可以用表格，在後面的步驟中這個表格同樣會用到，如下： 實體 屬性 描述 … 用戶 性別
年齡
電話
… 男/女
多大了
聯系方式
… … 4、確定屬性域：
屬性域就是屬性的取值范圍。
這時，可以用表格將屬性的數據類型、數據長度、取值范圍及是否可為空、簡單/復合、單值/多值、是否為派生屬性等域信息定義出來。
這個過程，事實上包含了邏輯結構設計中的數據類型、NULL、CHECK、DEFAULT等信息。 實體 屬性 描述 數據類型及長度 是否可為空 用戶 性別
年齡
電話
… 男/女
多大了
聯系方式
… 1位元組的短整形或布爾型
1位元組的短整形
20位元組的字元型或長整形
… NO
NO
YES 5、確定鍵：鍵就是可用於標識實體的屬性，有：主鍵、唯一鍵、外鍵。 實體 屬性 描述 鍵 用戶 用戶編號
性別
年齡
電話
… 男/女
多大了
聯系方式
… 主鍵 6、實體的特化/泛化：
也就是面向對象模型中父類和子類的概念，這是個可選的步驟。舉個例子，用戶中大部分人都是普通員工，但有一小部分是從事銷售的，銷售人員
有個負責區域的屬性，如果將這個屬性放在用戶實體中，如右圖：
這時我們會發現，除了銷售人員外，其他非銷售人員這個屬性全都不存在，這就是特化的過程。可以另建一個銷售人員的實體來泛化用戶實體，如右圖：
這樣就完成了對用戶實體的泛化，泛化的過程也就是抽出實體間公共屬性的過程，但通常，除非特化的部分太多，才會考慮將一個實體抽象成兩個
1對1關系的實體，所有這個步驟是可選的。
7、檢查模型：
（1）檢查冗餘
首先檢查實體：1對1關系的實體中有沒有非外鍵的重復屬性，或者就是同一個實體；
其次檢查關系：有沒有通過其他關系也可以得到的重復屬性；
當然有時，需要考慮時間維度，因為有些屬性是有時效性的，也就是雖然是同一個屬性，但不同的時間表示的卻是不同的內容，這一點在後面的邏輯結構設計中會提到，這並不是真正的冗餘。
（2）檢查業務
檢查當前的E-R模型是否滿足當前業務的場景。可以從某個實體開始，沿著當前E-R模型的各個節點去模擬業務場景。尤其需要和《需求規格說明書》去做校驗。
到這里，也就完成了E-R模型建立的全過程，有時，對於比較復雜的E-R模型，一張圖可能顯得太過局促，可以建立全局、局部E-R模型圖，以便於查看和分析。

㈡ sql資料庫關系圖設計

建議:客戶表: id,customername,... (id是主鍵)
訂單表:orderid,id,proctid,...(orderid,表示訂單編號<新增>,id是客戶id，proctid是產品id；其中orderid是主鍵,id和proctid是外鍵)，
產品表：proctid，proctname,...(proctid是主鍵)

㈢ 資料庫的E-R圖要如何設計

1、找到業務實體，比如：圖書管理系統的學生實體、圖書實體
2、寫也實體具有的屬性，比如學生具有姓名、年齡等屬性
3、畫出實體間的關系：有無關聯，一對多、多對多等，還有關系的方向；這就是E-R圖

注意：實體不能重復，屬性不能重復等等
畫圖時，可以找一個好工具，比如：vision。

㈣ 資料庫設計概念模型圖，邏輯模型圖分別是什麼

1.1.概念模型(E-R圖描述)
概念模型是對真實世界中問題域內的事物的描述，不是對軟體設計的描述。
表示概念模型最常用的是"實體-關系"圖。
E-R圖主要是由實體、屬性和關系三個要素構成的。在E-R圖中，使用了下面幾種基本的圖形符號。
實體，矩形
E/R圖三要素 屬性，橢圓形
關系，菱形
關系：一對一關系，一對多關系，多對多關系。
E/R圖中的子類(實體)：
1.2.邏輯模型
邏輯數據模型反映的是系統分析設計人員對數據存儲的觀點，是對概念數據模型進一步的分解和細化。
1.3.物理模型
物理模型是對真實資料庫的描述。資料庫中的一些對象如下：表，視圖，欄位，數據類型、長度、主鍵、外鍵、索引、是否可為空，默認值。
概念模型到物理模型的轉換即是把概念模型中的對象轉換成物理模型的對象。

㈤ 資料庫設計er圖實例

用Microsoft Office Visio可以很方便地設計資料庫ER模型。

㈥ 資料庫的邏輯結構設計的圖向關系

模型的轉換 E-R圖如何轉換為關系模型呢？我們先看一個例子。
圖2.1是學生和班級的E-R圖，學生與班級構成多對一的聯系。根據實際應用，我們可以做出這個簡單例子的關系模式：
學生（學號，姓名，班級）
班級（編號，名稱）
「學生.班級」為外鍵，參照「班級.編號」取值。
這個例子我們是憑經驗轉換的，那麼裡面有什麼規律呢？在2.2節，我們將這些經驗總結成一些規則，以供轉換使用。 (1)一個實體型轉換為一個關系模式
一般E-R圖中的一個實體轉換為一個關系模式，實體的屬性就是關系的屬性，實體的碼就是關系的碼。
(2)一個1:1聯系可以轉換為一個獨立的關系模式，也可以與任意一端對應的關系模式合並。
圖2.2是一個一對一聯系的例子。根據規則（2），有三種轉換方式。
(i) 聯系單獨作為一個關系模式
此時聯系本身的屬性，以及與該聯系相連的實體的碼均作為關系的屬性，可以選擇與該聯系相連的任一實體的碼屬性作為該關系的碼。結果如下：
職工（工號，姓名）
產品（產品號，產品名）
負責（工號，產品號）
其中「負責」這個關系的碼可以是工號，也可以是產品號。
(ii) 與職工端合並
職工（工號，姓名，產品號）
產品（產品號，產品名）
其中「職工.產品號」為外碼。
(iii) 與產品端合並
職工（工號，姓名）
產品（產品號，產品名，負責人工號）
其中「產品.負責人工號」為外碼。
(3)一個1:n聯系可以轉換為一個獨立的關系模式，也可以與n端對應的關系模式合並。
(i) 若單獨作為一個關系模式
此時該單獨的關系模式的屬性包括其自身的屬性，以及與該聯系相連的實體的碼。該關系的碼為n端實體的主屬性。
顧客（顧客號，姓名）
訂單（訂單號，……）
訂貨（顧客號，訂單號）
(ii) 與n端合並
顧客（顧客號，姓名）
訂單（訂單號，……，顧客號）
(4)一個m:n聯系可以轉換為一個獨立的關系模式。
該關系的屬性包括聯系自身的屬性，以及與聯系相連的實體的屬性。各實體的碼組成關系碼或關系碼的一部分。
教師（教師號，姓名）
學生（學號，姓名）
教授（教師號，學號）
(5)一個多元聯系可以轉換為一個獨立的關系模式。
與該多元聯系相連的各實體的碼，以及聯系本身的屬性均轉換為關系的屬性，各實體的碼組成關系的碼或關系碼的一部分。
(6)具有相同碼的關系模式可以合並。
(7)有些1：n的聯系，將屬性合並到n端後，該屬性也作為主碼的一部分
這類問題多出現在聚集類的聯系中，且部分實體的碼只能在某一個整體中作為碼，而在全部整體中不能作為碼的情況下才出現（其它情況本人還沒碰到，呵呵，歡迎指教）。
比如上篇文章介紹的管理信息系統中訂單與訂單細節的聯系。
關於什麼是聚集，2.3節介紹。 這部分本應在概念設計中介紹的，用到了才想起來，這里補充一下。
關於現實世界的抽象，一般分為三類：
（1） 分類：即對象值與型之間的聯系，可以用「is member of」判定。如張英、王平都是學生，他們與「學生」之間構成分類關系。
（2） 聚集：定義某一類型的組成成分，是「is part of」的聯系。如學生與學號、姓名等屬性的聯系。
（3） 概括：定義類型間的一種子集聯系，是「is subset of」的聯系。如研究生和本科生都是學生，而且都是集合，因此它們之間是概括的聯系。
例：貓和動物之間是概括的聯系，《Tom and Jerry》中那隻名叫Tom的貓與貓之間是分類的聯系，Tom的毛色和Tom之間是聚集的聯系。
訂單細節和訂單之間，訂單細節肯定不是一個訂單，因此不是概括或分類。訂單細節是訂單的一部分，因此是聚集。 有了關系模型，可以進一步優化，方法為：
（1） 確定數據依賴。
（2） 對數據依賴進行極小化處理，消除冗餘聯系（參看範式理論）。
（3） 確定範式級別，根據應用環境，對某些模式進行合並或分解。
以上工作理論性比較強，主要目的是設計一個數據冗餘盡量少的關系模式。下面這步則是考慮效率問題了：
（4） 對關系模式進行必要的分解。
如果一個關系模式的屬性特別多，就應該考慮是否可以對這個關系進行垂直分解。如果有些屬性是經常訪問的，而有些屬性是很少訪問的，則應該把它們分解為兩個關系模式。
如果一個關系的數據量特別大，就應該考 慮是否可以進行水平分解。如一個論壇中，如果設計時把會員發的主貼和跟貼設計為一個關系，則在帖子量非常大的情況下，這一步就應該考慮把它們分開了。因為 顯示的主貼是經常查詢的，而跟貼則是在打開某個主貼的情況下才查詢。又如手機號管理軟體，可以考慮按省份或其它方式進行水平分解。 這部分主要是考慮使用方便性和效率問題，主要藉助視圖手段實現，包括：
（1） 建立視圖，使用更符合用戶習慣的別名。
（2）對不同級別的用戶定義不同的視圖，以保證系統的安全性。
（3）對復雜的查詢操作，可以定義視圖，簡化用戶對系統的使用。
物理設計主要工作是選擇存取方法（索引），以及確定資料庫的存儲結構，這里就不說明了。

㈦ 資料庫如何設計

資料庫設計的基本步驟

按照規范設計的方法，考慮資料庫及其應用系統開發全過程，將資料庫設計分為以下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數據類型」。

㈧ 一個項目的資料庫設計用什麼圖最好

你可以用ER圖展示一下概念模型的設計，但是ER圖和資料庫中表結構的設計還是有區別的，建議你用power designer設計你的資料庫表結構，這樣更容易展示資料庫的結構和關聯關系。

㈨ 麻煩做個資料庫設計的圖，很少東西的，欄位名我都給出來了。

看例子去。。。。

http://freeweb.nyist.net/~guo/%CD%BC%CA%E9%B2%D6%B9%DC%C0%ED%CF%B5%CD%B3%B5%C4%BF%AA%B7%A2%BA%CD%C9%E8%BC%C6.doc