資料庫設計-九游会j9娱乐平台

ⅰ 資料庫設計的基本步驟

資料庫設計的基本步驟如下：

1、安裝並打開mysql workbench軟體以後，在軟體的左側邊欄有三個選項，分別是對應「連接資料庫」、「設計資料庫」、「遷移資料庫」的功能。這類選擇第二項，設計資料庫，點擊右邊的「＋」號，創建models。

ⅱ 資料庫設計技巧

就我個人的經驗來說，資料庫雖然在設計上確實需要有一定的經驗，但是它並不是最難的。
對於數據的設計其實是對於現實中業務的一種抽象。
就我的習慣的話，我會先對於現實中的業務場景、業務的角色進行分析。
就拿一般的進銷存系統來舉例吧。
我有一個對於物料管理的倉庫，我需要對我的物料的進銷存進行管理。
那麼我們就需要分析，沒有系統的時候，人與人之間的業務是怎麼流轉的，他們都是通過哪些表單來進行流轉的，上下級之間的消息傳遞和反饋都是怎麼進行的。
當知道了業務以後，我們的資料庫無非就是對於現實中的業務的一種具現。
對於業務的設計完成以後，就是針對角色的了。
例如：業務的傳遞都是在業務人員之間的，我們已經整理表單的傳遞，那角色其實就已經在這些傳遞中存在了。
但是，業務的角色是業務的角色，我們還要包括財務的角色，那對於財務來說，他需要在哪些環節看到這些業務的單據？並且需要怎麼處理？財務的處理結果又包括哪些？不同的處理結果對於下一步的操作又有什麼影響。
當我們把這一切的邏輯整理完成後，我們對於資料庫的功能上就已經滿足了。
接下來的就是抽象數據的分類了。
例如：我們需要對不同的表進行一個分類，我個人喜歡把表分成三種，一種是基礎數據表，一種是過程表，一種是結果表。
怎麼解釋呢？
基礎數據表：顧名思義，就是對於基礎數據的維護，哪些可以成為基礎數據呢？就是我們的業務發生的各個過程中，這些數據都是可以參與其中的，這就是基礎數據。
例如：貨物的信息，客戶的信息。
過程表：就是僅僅在一個過程中使用的表，當這個過程結束了，這個表就沒用了。
例如：訂單表，付款單表。他們表示的僅僅是訂單從下單到最後關閉的這個過程，關閉以後，這個訂單表其實我們就不會再去使用它了。
結果表：這個表的數據有一個特點，只允許添加，不允許刪除和修改，這個表的數據本身就是對於一種最終結果的表現。
例如：日誌表、賬單表。
那我們在進行資料庫設計的時候，就需要將這些使用情況考慮進去，將不同功能的表進行分離，盡量降低耦合，讓相互表的修改不會影響使用。
例如：收款單，我們需要收一筆款的時候，就會生成這個收款單，當款收到後，這個收款單的功能就結束了。
但現實的情況中，可能財務收到了這筆錢，結束了收款單流程後，他發現填錯了，本來應該收100，結果收款單寫的110。
但是，收款單表示的是過程，當這個過程結束了，我們就不會再需要上一個收款單了，所以，按照我們業務的處理流程，我們應該先生成一筆沖抵的收款單，例如收到-110，然後再生成新的100的收款單。
我們每個月還會有財務統計報表，財務報表因為和現實中的財務賬有關，是絕對不允許變動的，因此，這個財務報表就是一個結果表，我們會按月通過批處理程序，將收款單的明細和統計數據放到另一張表中，感覺好像比較冗餘，但是這個確實非常必要的。
因為我曾經就遇到過一個情況，我們直接用過程表來進行數據的統計，然後11月30日有一筆收款已經完成了，結果發現收錯了，就重新做了個收款單，結果本來已經出了11月結果的賬單發生了變化，導致財務實際的處理出現了問題。
因此，數據的冗餘有時候是有必要的，我們需要根據不同表的類型進行一些冗餘的設計。
對於資料庫設計的考慮點還有很多，可能一時半會兒也說不完，大家如果有什麼好的思路，也可以在下方評論或關注我給我留言。

ⅲ 簡述資料庫設計過程

資料庫設計過程分為以下六個階段：

1、需求分析階段

准確理解和分析用戶需求（包括數據和處理），它是整個設計過程的基礎，也是最困難、最耗時的一步。

2、概念結構設計階段

是整個資料庫設計的關鍵，通過對用戶需求的集成、歸納和抽象，形成了一個獨立於特定資料庫管理系統的概念模型。

3、邏輯結構設計階段

將概念結構轉換為dbms支持的數據模型，對其進行優化。

4、資料庫物理設計階段

為邏輯數據模型選擇最適合應用程序環境的物理結構（包括存儲結構和存取方法）。

5、資料庫實現階段

根據邏輯設計和物理設計的結果，使用資料庫管理系統提供的數據語言、工具和主機語言，建立資料庫，編寫調試應用程序，組織數據倉庫，並進行試運行。

6、資料庫運行維護階段

資料庫應用系統經試運行後可投入正式運行，在資料庫系統運行過程中，需要不斷地對其進行評估、調整和修改。

註：在設計過程中，將資料庫的設計與資料庫中數據處理的設計緊密結合起來，在每個階段同時對這兩個方面的要求進行分析、抽象、設計和實現，相互借鑒和補充，從而完善這兩個方面的設計。

(3)資料庫設計擴展閱讀：

資料庫設計技術

1、清晰的用戶需求：作為計算機軟體開發的重要基礎，資料庫設計直接反映了用戶的需求。資料庫必須與用戶緊密溝通，緊密結合用戶需求。在定義了用戶開發需求之後，設計人員還需要反映具體的業務關系和流程。

2、注意數據維護：設計面積過大、數據過於復雜是資料庫設計中常見的問題，設計人員應注意數據維護。

3、增加命名規范化：命名資料庫程序和文件非常重要，不僅要避免重復的名稱，還要確保數據處於平衡狀態。為了降低檢索信息和資源的復雜度和難度，設計人員應了解資料庫程序與文件之間的關系，並靈活使用大小寫字母命名。

4、充分考慮資料庫的優化和效率：考慮到資料庫的優化和效率，設計人員需要對不同表的存儲數據採用不同的設計方法。在設計中，還應該使用最少的表和最弱的關系來實現海量數據的存儲。

5、不斷調整數據之間的關系：不斷調整和簡化數據之間的關系，可以有效減少設計與數據之間的聯系，進而為維護數據之間的平衡和提高數據讀取效率提供保障。

6、合理使用索引：資料庫索引通常分為聚集索引和非聚集索引，這樣可以提高數據搜索的效率。

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

ⅳ 　資料庫設計

根據以上數據內容分析，當前遙感綜合調查基礎資料庫主要由各個專題資料庫（以矢量數據為主）、公共資料庫（既有矢量數據又有柵格數據，前者如1∶25萬基礎地理數據，後者如1∶25萬dem資料庫和1∶25萬etm＋遙感影像）等構成，同時整個系統還必須具備自身的擴展機制，隨著用戶和應用的不斷變化，資料庫的內容也必將隨之變化。因此，遙感綜合調查基礎資料庫設計的主導思想是，利用arcsde技術提供的multiuser geodatabase模型組織復雜的空間數據，建立一個開放的、靈活的空間資料庫。

geodatabase由矢量要素數據集、柵格數據集、tin數據集、空間域、規則等部件構成。它對通常所要處理和表達的地理空間要素，如矢量、柵格、三維表面、網路、地址等進行了統一的描述，並引入了這些地理空間要素的行為、規則和關系（esri,2001）。而遙感綜合調查基礎資料庫只存儲其中的矢量要素數據集、柵格數據集等幾種類型。基於geodatabase的遙感綜合調查數據模型如圖11.4所示。

設計geodatabase與設計普通的資料庫是相同的，也分成兩個基本步驟——邏輯數據模型的表達和資料庫模型的物理實施，即邏輯設計和物理設計。邏輯設計是空間數據在用戶或應用中的表現形式，物理設計主要是空間數據在存儲介質里的具體儲存方式。邏輯數據模型是對所要研究的現實世界的有關數據而建立的一個抽象的關聯結構，以描述這些數據之間的邏輯關系。它完全獨立於具體系統實現和處理過程，區別於物理數據模型，即它不是一個在資料庫管理系統中的表結構，不化解或消除實體間的多對多關系，更接近於現實世界，是一個訪問數據的基本視圖。可以說邏輯層是物理層的表現，而物理層是邏輯層的基礎。

圖11.4基於geodatabase的遙感綜合調查數據模型

圖11.5邏輯層與物理層的聯系

從邏輯設計的角度來看，本系統基礎資料庫的設計思路是：資料庫→子庫→圖層→空間實體，庫可以包含多個子庫，子庫用來存放不同比例尺或不同用途的空間數據，再根據項目設計書的要求對每一個子庫做大類和圖層的劃分。從物理設計的角度來看，最終反映在arcsde的物理資料庫模型則是geodatabase→featuredataset→featureclass→feature（如圖11.5）所示。

ⅳ 中心資料庫設計

5.2.2.1 資料庫

根據該系統的開發需求，按照資料庫的功能和作用將其分為風險查詢類、風險評價類、系統管理類三大類（薩師煊等，2000）。主要數據見表5.5。

表5.5 海外油氣與金屬礦產資源開發風險管理系統的主要數據表

續表

5.2.2.2 數據倉庫

油價數據來源於美國能源部（doe）下屬的能源信息署（eia）網站、中石油（cnpc）網站和《華爾街日報》（wsj）網站提供的油價數據，油價序列本身就是一個不規則的時間序列，油價數據具有以下幾個特點。

（1）數據的一致性差

油價數據格式多樣，存在數據冗餘，主要體現在：使用的數據格式均不相同，並且各個子系統相對獨立。在網站單獨作用的情況下，一般都沒有問題，但要將這些不同系統或不同時期的數據集中起來綜合利用，就可能出現數據不齊全、不一致或重復的現象。

（2）數據存放的分散

油價數據來源多，缺乏統一管理，沒有一種相應的網頁數據自動化抓取操作實現數據的本地化操作過程。

（3）數據資源開發不充分

大容量數據導致對數據資源的開發利用不充分，缺乏對獲取的數據如各分析機構制定的期貨合約元數據進行各種深層次分析、綜合、提煉、挖掘和展現的應用，因此很難對豐富的統計數據資源進行二次開發利用。

根據油價數據中所包含的油氣產品種類、油氣產品合約制定日期、油氣產品的價格類型、不同市場下油氣產品價格的差異等，能夠加深對油價走勢的了解。油價的這種與時間相關性、不可修改性，以及集成的性質，使得我們採用多種角度對原始數據進行理解，並真實反映其特性，也讓我們發現使用一種整合的技術對油價進行精確預測十分必要。

數據倉庫的構建流程如圖5.13所示由下至上逐步實現。

圖5.13 數據倉庫構建流程

1）數據源。

a.數據源的復雜性。數據分散在資料庫管理系統、電子表格、電子郵件系統、電子文檔甚至紙上。系統中要求採集的3個數據源中，eia 網站存儲在網頁上的油價相關事件更新較慢，雖然提供了各市場日、周、月、年的油價數據下載，但是下載完成之後的表格欄位格式時常發生變化，這為實現自動獲取數據並下載到本地自動入庫的要求增加了難度；中石油網站數據除上述只顯示3條數據之外，網站上會將訪問流量過大的ip地址列入黑名單使其不能繼續下載到本地進行保存，為這些數據建立統一的模型將會耗費很大精力。

b.數據的有效性。由於存在經驗局限，如何處理數據的空值、不同時間間隔時間欄位格式，入庫時應注意的問題等，如果應用程序沒有檢驗數據的有效性，會對數據多維顯示產生極大影響，因此也歸結為數據源數據質量問題。

c.數據的完整性。數據源上的數據並不那麼明顯或者容易獲得。油價是高度敏感的數據，因此各個網站雖然提供了各個油品交易市場的日、月或年數據，但是完整性並不能充分保證，根據企業政策的不同，有時對要獲得的數據，需花費大量精力。為此，要對不同的數據源進行建庫，以保證所獲數據的完整性。

2）數據處理。

高效的多維數據集展示離不開底層數據源數據的精確獲取，或者叫做數據理解和數據清洗。於是系統在基於元數據獲取、加工、入庫和多維數據集展示上實現預期的要求。

a.etl。該功能是整個油價數據倉庫的核心之一，主要功能是按照事先定義的數據表對應關系從相關系統表中抽取數據（extraction），經過數據清洗和轉換（transform）,最終把正確的數據裝載到數據倉庫的源數據中（load），作為以後應用的基礎。

b.數據轉換。該功能是在數據抽取過程中按照定義的規則轉換數據，避免了數據在分析時的多樣性，保證數據一致性。

c.數據集成。該功能主要是把油價信息數據倉庫系統的源數據，按照事先定義的計算邏輯以主題的方式重新整合數據，並以新的數據結構形式存儲。

3）數據存儲。

星型模型（星型架構）是數據倉庫開發中多維展現重要的邏輯結構，構成星型模型的幾個重要特徵是：維、度和屬性，在實際應用中表示為事實表和維度表。在油價數據中，各市場的期現貨價格表為數據倉庫的事實表，油品類型、合約規定日期等為維度表。

油價數據倉庫星型模型的設計方案如下：

a.事實表。資料庫表中eia的期現貨價格表（包括日、周、月、年表）作為數據倉庫中的事實表，根據不同時間維度構成多個星型模型，即星座模型。這些價格表中以市場編號、油氣產品類型、期貨合約日期、價格單位度量衡編號作為主鍵和外鍵與其他維度表相連，形成多維展示聯動的基礎，以油價數據和其他事實數據為記錄數據，作為主要輸出結果。

b.維度表。根據市場、油品、價格數據、度量衡和事件類型作為油氣數據倉庫中多維分析的角度和目標。

圖5.14以eia的日期貨數據表作事實表為例，構建星型模型，其他不同時間維度的模型結構圖與此圖基本相同。

圖5.14 以eia數據為例的日期貨價格星型模型

以星型模型設計為基礎，完善數據存儲中操作型數據存儲（ods）的原型設計，提供db-dw之間中間層的數據環境，可實現操作型數據整合和各個系統之間的數據交換。

ⅵ 資料庫如何設計

資料庫設計的基本步驟

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

ⅶ 資料庫設計原則

本系統中資料庫的設計，要考慮和遵循下列資料庫設計的基本原則，以建立穩定、安全、可靠的資料庫。

1)一致性原則:對數據來源進行統一、系統的分析與設計，協調好各種數據源，保證數據的一致性和有效性。

2)完整性原則:資料庫的完整性是指數據的正確性和相容性。要防止合法用戶使用資料庫時向資料庫加入不合語義的數據。對輸入到資料庫中的數據要有審核和約束機制。

3)安全性原則:資料庫的安全性是指保護數據，防止非法用戶使用資料庫或合法用戶非法使用資料庫造成數據泄露、更改或破壞。要有認證和授權機制。

4)可伸縮性與可擴展性原則:資料庫結構的設計應充分考慮發展的需要、移植的需要，具有良好的擴展性、伸縮性和適度冗餘。

5)規范化:資料庫的設計應遵循規范化理論。規范化的資料庫設計，可以減少資料庫插入、刪除、修改等操作時的異常和錯誤，降低數據冗餘度等。