❶ 資料庫設計的基本步驟
資料庫設計的基本步驟如下：
1、安裝並打開Mysql WorkBench軟體以後，在軟體的左側邊欄有三個選項，分別是對應「連接資料庫」、「設計資料庫」、「遷移資料庫」的功能。這類選擇第二項，設計資料庫，點擊右邊的「＋」號，創建models。
❷ 資料庫如何設計
資料庫設計的基本步驟
按照規范設計的方法，考慮資料庫及其應用系統開發全過程，將資料庫設計分為以下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的概念模型。
設計概念結構通常有四類方法：
自頂向下。即首先定義全局概念結構的框架，再逐步細化。
自底向上。即首先定義各局部應用的概念結構，然後再將他們集成起來，得到全局概念結構。
逐步擴張。首先定義最重要的核心概念結構，然後向外擴張，以滾雪球的方式逐步生成其他的概念結構，直至總體概念結構。
混合策略。即自頂向下和自底向上相結合。
- 需要注意：
- ● 在確定支持數據時，請一定要參考你之前所確定的宏觀行為，以清楚如何利用這些數據。
- ● 比如，如果你知道你需要所有員工的按姓氏排序的列表，確保你將支持數據分解為名字與姓氏，這比簡單地提供一個名字會更好。
- ● 你所選擇的名稱最好保持一致性。這將更易於維護資料庫，也更易於閱讀所輸出的報表。
- ● 比如，如果你在某些地方用了一個縮寫名稱Emp_status，你就不應該在另外一個地方使用全名(Empolyee_ID)。相反，這些名稱應當是Emp_status及Emp_id。
- ● 數據是否與正確的table相對應無關緊要，你可以根據自己的喜好來定。在下節中，你會通過測試對此作出判斷。
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
如果將這些數據畫成圖表，就像：
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、概念結構設計：主要採用E-R模型進行設計，包括畫E-R圖
3、邏輯結構設計：通過將E-R圖轉換成表，實現從E-R模型到關系模型的轉換
4、資料庫物理設計：主要是為所設計的資料庫選擇合適的存儲結構和存取路徑
5、資料庫的實施：包括編程、測試和試運行
6、資料庫運行與維護：系統的運行與資料庫的日常維護
(3)資料庫設計的起點是擴展閱讀：
設計原則
1、一對一設計原則
在軟體開發過程中，需要遵循一對一關系設計原則進而開展數據維護工作，通過利用此原則能夠盡量減少維護問題的出現，保證數據維護工作順利開展同時降低維護工作難度。
2、獨特命名原則
獨特命名原則的應用是為了減少在資料庫設計過程中出現重復命名和規范命名現象出現。
3、雙向使用原則
雙向使用原則包括：事務使用原則和索引功能原則，軟體市場常見的索引模式有：多行檢索聚簇索引和單行檢索非聚簇索引。
❹ 資料庫設計
說起資料庫設計，相信大家都明白怎麼回事，但說起資料庫設計的重要性，我想大家也只是停留在概念上而已，到底如何重要？怎麼重要呢？今天就將我至今為止的理解向大家闡述下。
一個不良的資料庫設計，必然會造成很多問題，輕則增減欄位，重則系統無法運行。我先來說說資料庫設計不合理的表現吧：
1. 與需求不符
因為這個原因造成的改動量往往是最大。如果進入編碼階段的話，很可能會直接讓你崩潰掉。
2. 性能低下
含有大數據量的表之間的關聯過多；沒有合理的欄位設計來用於查詢而造成的SQL查詢語句很復雜；對於大數據量的表沒有採用有效的手段去處理；濫用視圖等。
3. 數據完整性喪失
含有主外鍵關系的表之間關聯欄位的設計方式不合理，造成更新與刪除操作後程序容易出錯或不完善；使用了已經刪除或丟失掉的數據。
4. 可擴展性性太差
表設計的與業務綁定的太緊密、單一，造成表的可拓展性、可修改性太差，無法新需求的要求。
5. 非必要數據冗餘量太大
沒用的垃圾數據存儲過多，不僅佔用資源，還影響查詢效率。
6. 不利於計算或統計
缺少必要的聯系性或統計性欄位或用於計算統計的欄位分散於多個表中，造成計算統計的步驟繁瑣，甚至無法計算統計。
7. 沒有詳盡的數據記錄信息
缺少必要的欄位，造成無法跟蹤數據變化、用戶操作，也無法進行數據分析。
8. 表之間的耦合性太大
多張表之間關聯的過於緊密，造成一張表發生變化而影響到其他表。
9. 欄位設計考慮不周
欄位長度過短或欄位類型過於明確，造成可發揮、可拓展的空間太小。
大多數的程序員對於軟體開發的出發點認識不是很明確，總是認為實現功能才是重要的，在簡單了解完基本需求後就急忙進入編碼階段，對於資料庫設計思考的比較少、比較簡單，大多設計都只停留在表面上，這往往是要命的，會為系統留下很多隱患。要麼是寫代碼開發過程中才發現問題，要麼就是系統上線運轉後沒多久就出現問題，還有可能給後期維護增加了很多工作量。如果到了那個時候再想修改資料庫設計或進行優化等同於推翻重來。
資料庫是整個軟體應用的根基，是軟體設計的起點，它起著決定性的質變作用，因此我們必須對資料庫設計高度重視起來，培養設計良好資料庫的習慣，是一個優秀的軟體設計師所必須具備的基本素質條件！
那麼我們要做到什麼程度才是對的呢？下面就說說資料庫設計的原則
1. 資料庫設計最起碼要佔用整個項目開發的40%以上的時間
資料庫是需求的直觀反應和表現，因此設計時必須要切實符合用戶的需求，要多次與用戶溝通交流來細化需求，將需求中的要求和每一次的變化都要一一體現在資料庫的設計當中。如果需求不明確，就要分析不確定的因素，設計表時就要事先預留出可變通的欄位，正所謂「有備無患」。
2. 資料庫設計不僅僅停留於頁面demo的表面
頁面內容所需要的欄位，在資料庫設計中只是一部分，還有系統運轉、模塊交互、中轉數據、表之間的聯系等等所需要的欄位，因此資料庫設計絕對不是簡單的基本數據存儲，還有邏輯數據存儲。
3. 資料庫設計完成後，項目80%的設計開發在你腦海中就已經完成了
每個欄位的設計都是有他必要的意義的，你在設計每一個欄位的同時，就應該已經想清楚程序中如何去運用這些欄位，多張表的聯系在程序中是如何體現的。換句話說，你完成資料庫設計後，程序中所有的實現思路和實現方式在你的腦海中就已經考慮過了。如果達不到這種程度，那當進入編碼階段後，才發現要運用的技術或實現的方式資料庫無法支持，這時再改動資料庫就會很麻煩，會造成一系列不可預測的問題。
4. 資料庫設計時就要考慮到效率和優化問題
一開始就要分析哪些表會存儲較多的數據量，對於數據量較大的表的設計往往是粗粒度的，也會冗餘一些必要的欄位，已達到盡量用最少的表、最弱的表關系去存儲海量的數據。並且在設計表時，一般都會對主鍵建立聚集索引，含有大數據量的表更是要建立索引以提供查詢性能。對於含有計算、數據交互、統計這類需求時，還要考慮是否有必要採用存儲過程。
5. 添加必要的（冗餘）欄位
像「創建時間」、「修改時間」、「備注」、「操作用戶IP」和一些用於其他需求（如統計）的欄位等，在每張表中必須都要有，不是說只有系統中用到的數據才會存到資料庫中，一些冗餘欄位是為了便於日後維護、分析、拓展而添加的，這點是非常重要的，比如黑客攻擊，篡改了數據，我們便就可以根據修改時間和操作用戶IP來查找定位。
6. 設計合理的表關聯
若多張表之間的關系復雜，建議採用第三張映射表來關聯維護兩張表之間的關系，以降低表之間的直接耦合度。若多張表涉及到大數據量的問題，表結構盡量簡單，關聯也要盡可能避免。
7. 設計表時不加主外鍵等約束性關聯，系統編碼階段完成後再添加約束性關聯
這樣做的目的是有利於團隊並行開發，減少編碼時所遇到的問題，表之間的關系靠程序來控制。編碼完成後再加關聯並進行測試。不過也有一些公司的做法是乾脆就不加表關聯。
8. 選擇合適的主鍵生成策略
主鍵生成策略大致可分：int自增長類型（identity、sequence）、手動增長類型（建立單獨一張表來維護）、手動維護類型（如userId）、字元串類型（uuid、guid）。int型的優點是使用簡單、效率高，但多表之間數據合並時就很容易出現問題，手動增長類型和字元串類型能很好解決多表數據合並的問題，但同樣也都有缺點：前者的缺點是增加了一次資料庫訪問來獲取主鍵，並且又多維護一張主鍵表，增加了復雜度；而後者是非常佔用存儲空間，且表關聯查詢的效率低下，索引的效率也不高，跟int類型正好相反。
終上所述，我們可見資料庫設計在整個軟體開發的起到的舉足輕重的作用，尤其是我說的設計原則的第一點，資料庫與需求是相輔相成的，我經常把軟體開發比作汽車製造。汽車製造會經過圖紙設計，模型製作，樣車製造，小批量試生產，最後是批量生產等步驟。整個過程環環相扣，後一過程是建立在前一過程正確的前提基礎之上的。如果在圖紙設計階段發現了一個紕漏，我們可以重新進行圖紙設計，如果到了樣車製造階段發現這個錯誤，那麼我們就要把從圖紙設計到樣車製造的階段重來，越到後面發現設計上的問題，所付出的代價越大，修改的難度也越大。
資料庫設計難度其實要比單純的技術實現的難很多，他充分體現了一個人的全局設計能力和掌控能力，所以在今後的項目中大家一定要著重培養這方面的能力，這里我將我的經驗分享給了大家，希望能對大家有所幫助。
❺ 設計資料庫時應該首先設計什麼
資料庫設計包括六個主要步驟：
1、需求分析：了解用戶的數據需求、處理需求、安全性及完整性要求；
2、概念設計：通過數據抽象，設計系統概念模型，一般為E-R模型；
3、邏輯結構設計：設計系統的模式和外模式，對於關系模型主要是基本表和視圖；
4、物理結構設計：設計數據的存儲結構和存取方法，如索引的設計；
5、系統實施：組織數據入庫、編制應用程序、試運行；
6、運行維護：系統投入運行，長期的維護工作。
所以首先設計概念~~
❻ 資料現狀與數據需求
數據需求分析是建立數據模型和開展資料庫設計的起點。需求調查和分析的具體內容 包括：(1)信息內容要求和數據存儲、數據的分類與組織方式、元數據要求；(2)信息處理要求； (3)安全性與完整性要求。
通過對丁家山鉛鋅礦山收集的全部紙介質資料和從相關技術人員處獲得的電子資料的 整理，對現有資料的數據來源、管理現狀、數字化程度、資料的完整性進行了分析，總結如下：
（1）現有的紙介質和電子資料涵蓋了丁家山礦床和關兜礦床的地質礦產資料。地質 礦產資料主要包括：(1)普查地質報告；(2)詳查地質報告；(3)儲量核實報告；(4)潛力評價報告； (5)勘查地質報告；(6)生產探礦資料；(7)涉及物探、化探、區域及外圍等報告。
（2）資料保存形式多樣，有以紙介質和電子文檔形式保存的科研報告和圖件。
（3）數據資料的來源多樣，分別來自華東有色地質礦產勘查開發院、福州東鑫礦業 技術有限公司、福建省尤溪金東礦業有限公司、福建省尤溪縣三鑫鉛鋅礦業有限公司、華 東有色地勘局807隊和華東有色地質勘查局805隊等單位。
（4） 目前的紙介質資料和電子資料均不能滿足國際礦業軟體的三維地質建模數據要 求。為使現有資料滿足國際礦業軟體的建模數據要求，必須對這些資料進行編碼數字化。 電子介質形式的圖件和文檔，因缺乏地勘資料數字化標准，數據仍只能採用傳統紙介質的 組織方式，所以，現有的電子介質形式的勘探報告同樣需要進行編碼數字化。
根據上述資料現狀分析和數據需求調查分析，將綜合地質資料庫的實際數據需求概 括為：
（1）內容需求包括：(1)地質礦產資料（紙介質資料、電子文檔資料）的分類目錄和 資料列表；(2)重要詳查報告與儲量報告、地質綜合研究報告、重要電子文檔等重要地質資 料，資料形式可以為報告、表格、圖件、電子文檔包；(3)編碼數字化數據。
（2）綜合地質資料庫在存儲與處理上應適應地質礦產資料擴充的要求，應選用高性 能和高容量的伺服器系統（帶磁碟陣列）、資料庫軟體系統（Oracle）；支持大量資料的存 儲管理。
（3）綜合地質資料庫及其管理系統應保證資料的安全性和完整性。
❼ 說明在設計資料庫表時你是如何考慮的
資料庫是整個軟體應用的根基，是軟體設計的起點，它起著決定性的質變作用，因此我們必須對資料庫設計高度重視起來，培養設計良好資料庫的習慣，是一個優秀的軟體設計師所必須具備的基本素質條件！ 那麼我們要做到什麼程度才是對的呢？下面就說說資料庫設計的原則： （1）、資料庫設計最起碼要佔用整個項目開發的40%以上的時間
資料庫是需求的直觀反應和表現，因此設計時必須要切實符合用戶的需求，要多次與用戶溝通交流來細化需求，將需求中的要求和每一次的變化都要一一體現在資料庫的設計當中。如果需求不明確，就要分析不確定的因素，設計表時就要事先預留出可變通的欄位，正所謂「有備無患」。 （2）、資料庫設計不僅僅停留於頁面demo的表面 頁面內容所需要的欄位，在資料庫設計中只是一部分，還有系統運轉、模塊交互、中轉數據、表之間的聯系等等所需要的欄位，因此資料庫設計絕對不是簡單的基本數據存儲，還有邏輯數據存儲。 （3）、資料庫設計完成後，項目80%的設計開發在你腦海中就已經完成了 每個欄位的設計都是有他必要的意義的，你在設計每一個欄位的同時，就應該已經想清楚程序中如何去運用這些欄位，多張表的聯系在程序中是如何體現的。換句話說，你完成資料庫設計後，程序中所有的實現思路和實現方式在你的腦海中就已經考慮過了。如果達不到這種程度，那當進入編碼階段後，才發現要運用的技術或實現的方式資料庫無法支持，這時再改動資料庫就會很麻煩，會造成一系列不可預測的問題。 （4）、資料庫設計時就要考慮到效率和優化問題 一開始就要分析哪些表會存儲較多的數據量，對於數據量較大的表的設計往往是粗粒度的，也會冗餘一些必要的欄位，已達到盡量用最少的表、最弱的表關系去存儲海量的數據。並且在設計表時，一般都會對主鍵建立聚集索引，含有大數據量的表更是要建立索引以提供查詢性能。對於含有計算、數據交互、統計這類需求時，還要考慮是否有必要採用存儲過程。 （5）、添加必要的（冗餘）欄位 像「創建時間」、「修改時間」、「備注」、「操作用戶IP」和一些用於其他需求（如統計）的欄位等，在每張表中必須都要有，不是說只有系統中用到的數據才會存到資料庫中，一些冗餘欄位是為了便於日後維護、分析、拓展而添加的，這點是非常重要的，比如黑客攻擊，篡改了數據，我們便就可以根據修改時間和操作用戶IP來查找定位。 （6）、設計合理的表關聯 若多張表之間的關系復雜，建議採用第三張映射表來關聯維護兩張表之間的關系，以降低表之間的直接耦合度。若多張表涉及到大數據量的問題，表結構盡量簡單，關聯也要盡可能避免。 （7）、設計表時不加主外鍵等約束性關聯，系統編碼階段完成後再添加約束性關聯 這樣做的目的是有利於團隊並行開發，減少編碼時所遇到的問題，表之間的關系靠程序來控制。編碼完成後再加關聯並進行測試。不過也有一些公司的做法是乾脆就不加表關聯。 （8）、選擇合適的主鍵生成策略
❽ .資料庫設計分為幾個階段,各階段的任務是什麼
按照規范的設計方法，一個完整的資料庫設計一般分為需求分析、概念結構設計、邏輯結構設計、資料庫物理設計、資料庫的實施、資料庫運行與維護六個階段：
各階段的任務如下：
1、需求分析：分析用戶的需求，包括數據、功能和性能需求；
拓展資料：
資料庫設計(Database Design)是指對於一個給定的應用環境，構造最優的資料庫模式，建立資料庫及其應用系統，使之能夠有效地存儲數據，滿足各種用戶的應用需求(信息要求和處理要求)。在資料庫領域內，常常把使用資料庫的各類系統統稱為資料庫應用系統。
資料庫設計是建立資料庫及其應用系統的技術，是信息系統開發和建設中的核心技術。由於資料庫應用系統的復雜性，為了支持相關程序運行，資料庫設計就變得異常復雜，因此最佳設計不可能一蹴而就，而只能是一種"反復探尋，逐步求精"的過程，也就是規劃和結構化資料庫中的數據對象以及這些數據對象之間關系的過程。
❾ 有一道資料庫的問題
設計一個資料庫需要我們耐心收集和分析數據，仔細理清數據間的關系，消除對資料庫應用不利的隱患等等。在整個設計過程中，我們必須按步驟認真完成。一個資料庫的設計好壞將直接影響將來基於該資料庫的應用。
另外，資料庫也不是獨立存在的，它總是與具體的應用相關的，為具體的應用而建立的。因此在設計資料庫之前我們必須明確應用的目的，在設計資料庫的時候也應時刻考慮用戶需求，資料庫與具體應用之間是相輔相成的關系。
資料庫的設計過程一般包括以下幾個步驟：
確定建立資料庫的目的和收集數據；
建立概念模型；
建立數據模型；
實施與維護資料庫；
1．確定建立資料庫的目的和收集數據
資料庫設計過程的第一個階段是確定建立資料庫的目的和收集數據。通常，我們也把確定建立資料庫的目的稱為需求分析。需求分析的任務就是通過詳細調查要處理的對象來明確用戶的各種需求。並且通過調查、收集和分析信息，以了解在資料庫中需要存儲哪些數據，要完成什麼樣的數據處理功能。這一過程是資料庫設計的起點，它將直接影響到後面各個階段的設計，並影響到設計結果是否合理和實用。
確定目的之後就需要根據目的收集有用的數據。在著手收集數據之前最重要的就是要調查用戶的實際需求，然後分析與表達這些需求。調查用戶需求的方法有很多，如查閱記錄、訪談、開調查會、設計調查表請用戶填寫或回答相關問題等。其中比較有效的方法是訪談，我們可以藉助一些設計合理的調查表來與用戶直接交流。通過充分交流，可以了解他們平時是如何使用資料庫的，以及對當前信息的要求，進而設計滿足用戶需求的欄位，並根據設計的欄位收集數據。
2．建立概念模型
確定建立資料庫的目的以及完成數據收集後，就進入資料庫設計過程的第二階段——建立概念模型。這一階段是整個資料庫設計的關鍵。設計時，一般先根據應用的需求，畫出能反映每個應用需求的E-R圖，其中包括確定實體、屬性和聯系的類型。然後優化初始的E-R圖，消除冗餘和可能存在的矛盾。概念模型是對用戶需求的客觀反映，並不涉及具體的計算機軟、硬體環境。因此，在這一階段中我們必須將注意力集中在怎樣表達出用戶對信息的需求，而不考慮具體實現問題。
3．建立數據模型
完成上一階段後，我們得到了一個與具體計算機軟、硬體無關的概念模型。接著我們就可以著手建立資料庫模型了，這是資料庫設計過程的第三個階段。在這一階段中我們要將概念模型中得到的E-R圖轉換成具體的數據模型。通過前面的學習，我們已經了解到數據模型一般分為層次、網狀、關系和面向對象模型等。目前比較常用的是關系數據模型，我們通常將E-R圖轉換成關系數據模型，實際上就是要將實體、實體的屬性和實體之間的聯系轉換為關系模式。
4．實施與維護資料庫
最後一個階段是實施與維護資料庫。完成數據模型的建立後，我們就必須對欄位進行命名，確定欄位的類型和寬度，並利用資料庫管理系統或資料庫語言創建資料庫結構、輸入數據和運行等，因此資料庫的實施是資料庫設計過程的「最終實現」。如果資料庫運行很成功，則表明資料庫設計任務基本結束，以後的重點就是資料庫的維護工作，包括做好備份工作、資料庫的安全性和完整性調整、改善資料庫性能等。
資料庫的設計在資料庫應用系統的開發中佔有很重要的地位。只有設計出合理的資料庫，才能為建立在資料庫上的應用提供方便。不過資料庫的設計過程從來都不會有真正的結束，因為隨著用戶需求和具體應用的變化和擴大，資料庫的結構也可能會隨之變化。
資料庫基本的功能：
信息瀏覽和查詢；
信息的修改、添加和刪除；
信息的統計、匯總等。
設計資料庫時要注意保留以下內容：
設計文檔、內容操作說明，實例資料庫、幫助及過程性文件（如下載的資源、工作日誌）等。
❿ 資料庫的設計一般經過哪幾個階段
資料庫設計可以分為概念結構設計、邏輯結構設計和物理結構設計三個階段。
（1）概念結構設計。這是資料庫設計的第一個階段，在管理信息系統的分析階段，已經得到了系統的數據流程圖和數據字典，現在要結合數據規范化的理論，用一種數據模型將用戶的數據需求明確地表示出來。
概念數據模型是面向問題的模型，反映了用戶的現實工作環境，是與資料庫的具體實現技術無關的。建立系統概念數據模型的過程叫做概念結構設計。
（2）邏輯結構設計。根據已經建立的概念數據模型，以及所採用的某個資料庫管理系統軟體的數據模型特性，按照一定的轉換規則，把概念模型轉換為這個資料庫管理系統所能夠接受的邏輯數據模型。不同的資料庫管理系統提供了不同的邏輯數據模型，如層次模型、網狀模型、關系模型等。
（3）物理結構設計。為一個確定的邏輯數據模型選擇一個最適合應用要求的物理結構的過程，就叫做資料庫的物理結構設計。資料庫在物理設備上的存儲結構和存取方法稱為資料庫的物理數據模型。