流程資料庫設計

① 如何實現OA系統的自定議審批流程的資料庫設計

請問定製開發一套OA系統需要多少錢呢？應滿足哪幾個功能才算得上是好的OA系統？

隨著信息技術的發展，為了提高辦公效率，企業都將辦公自動化辦公管理系統用於辦公工作。然而，辦公自動化系統辦公管理軟體收費的結構並不十分清楚。一般來說，辦公自動化辦公管理系統供應商的費用包括軟體使用費、服務費和開發費。由於oA系統軟體能伴著公司發展的手機軟體，因而在長期性的應用之中是不可或缺生產商服務項目和開發設計，那_人們主要來剖析oA系統軟豎棗件是如何收費標準的呢?oA系統軟體辦公管理軟體的收費標準是分為訂制顧客和標准版顧含握客來扣除。

一、通用版OA系統收費

一般來說使用通用版OA辦公管理系統的收費都是按照板塊來收，因為通用版的OA辦公管理系統有很多功能板塊，不是每一個板塊客戶都能夠使用的，因此使用什麼板塊就開通什麼板塊這樣的收費方式性價比很高。並且通用版的OA辦公管理系統比較成熟穩定，在使用當中的維護費也很低，如果在後期有新的需求，那就是需要開發費了。因此通用版OA系統收費是使用費和維護費組成的。

二、定製版OA系統收費

有些企業有個性化管理制度或者個性需求，通用版的OA辦公管理系統不能滿足的，那麼就需要定製版OA辦公管理系統。定製的OA辦公管理系統很多功能都要根據企業的需求來做的，因此需要在通用版OA辦公管理軟體上進行二次開發。OA系統廠商投入的時間和開發成本就很多了，在加上後續的功能完善和多次測試的bug修復，定製OA系統的維護費用比較高，由使用費、服務費、開發費組成的。

三、怎麼減少OA系統費用呢

我們在選擇OA辦公管理系統的時候，要選擇系統架構和功能都是比較成熟和穩定的，這樣可以減少了對OA辦公管理系統的工作量，同時減少了因為系統不成熟帶來的維護費。若是想要在後續使用中進行二次開發，那麼前期的的選型上需要OA辦公管理軟體具有易擴展性，那麼進行二次開發的難度和維護都會降低，那麼收費也會減少。很多軟體在實施和服務的時候不需要到現場，遠程都可以解決的問題，如果還要到現場處理服務費也相應的高，因此選擇能支持遠程實施或者的OA系統廠商，也會減少軟體的服務費。

辦公自動化(OFA)是一種面向***日常運營和管理的應用系統，最常被員工和經理使用。隨著科學技術和互聯網的進一步發展，辦公自動化在應用內容的深度和廣度以及信息技術的應用方面都發生了新的變化和發展，已經成為一個***不可或缺的核心。

OA系統開發以及維護過程

系統開發

軟體開發廠商根據系統的需求和設計，開發人員進行系統的代碼編寫，最終用戶一般很難將需求一次性完成的提出，開發過程中涉及到需求的問題需要對設計進行細節的調整。開發人員對需求的理解、編碼的規范和質量等，對軟體系統的質量和穩定性、安全性等方面影響非常大。

oa開發系統測試

依據階段的需求對系統進行功能測試、性能測試(對使用用戶數非常多可能需要進行性能測試)、安全性檢測，功能測試一般由軟體開發廠商和用戶同時進行。

系統測試根據項目周期和功能的多少，可以迭代的進行，如果開發的內容多可以分步提交開發成果進行測試，實現開發和測試迭代進行。

對於測試中發現的問題，一般提交開發人員進行修改，再進行回歸測試(針對修改過的問題進行測試和驗證)。 系統的測試是軟體定製開發的一個重要環節，需要軟體開發廠商和最終用戶的緊密配合和合理的規劃時間(特別是工期非常緊的情況下)，測試是高質量的軟體系統的根本保障。

oa開發系統部署和交付

系統開發完成後部署在最終用戶的正式運行環境，交付給最終用戶使用，同時需要對相關的人員進行培訓。這這個環節中軟體的推廣和使用是，直接關繫到軟體的應用效果。

oa開發系統的維護和服務

軟體在正式運行過程中會遇到BUG(系統錯誤)、使用問題、功能的完善和修改等，軟體廠商需提供相應的服務確保最終用戶系統正常穩定的運行。

從以上過程中可以看出，需求階段、測試階段是最終用戶和軟體廠商配合程度的階段。軟體定製開發的周期和復雜程度是由用戶業務需求來決定的，對於業務需求比較簡單的某些環節可以省略、合並。一般情況下，軟體定製開發和軟體產品之間聯系是非常緊密余老拆的，當軟體產品不能夠滿足客戶要求時一般只能通過定製開發進行完善，而軟體產品也是在眾多的應用中通過定製開發積累和完善的。

軟體定製開發相對於單純的軟體產品實施，選擇軟體供應商更加重要，供應商的軟體定製開發經驗、技術水平、提供的服務等直接決定軟體開發的成敗。

② 資料庫設計的步驟有哪些

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

1、需求分析階段

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

2、概念結構設計階段

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

3、邏輯結構設計階段

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

4、資料庫物理設計階段

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

5、資料庫實現階段

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

6、資料庫運行維護階段

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

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

(2)流程資料庫設計擴展閱讀：

資料庫設計技術

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

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

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

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

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

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

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

③ 資料庫設計技巧

就我個人的經驗來說，資料庫雖然在設計上確實需要有一定的經驗，但是它並不是最難的。

對於數據的設計其實是對於現實中業務的一種抽象。

就我的習慣的話，我會先對於現實中的業務場景、業務的角色進行分析。

就拿一般的進銷存系統來舉例吧。

我有一個對於物料管理的倉庫，我需要對我的物料的進銷存進行管理。

那麼我們就需要分析，沒有系統的時候，人與人之間的業務是怎麼流轉的，他們都是通過哪些表單來進行流轉的，上下級之間的消息傳遞和反饋都是怎麼進行的。

當知道了業務以後，我們的資料庫無非就是對於現實中的業務的一種具現。

對於業務的設計完成以後，就是針對角色的了。

例如：業務的傳遞都是在業務人員之間的，我們已經整理表單的傳遞，那角色其實就已經在這些傳遞中存在了。

但是，業務的角色是業務的角色，我們還要包括財務的角色，那對於財務來說，他需要在哪些環節看到這些業務的單據？並且需要怎麼處理？財務的處理結果又包括哪些？不同的處理結果對於下一步的操作又有什麼影響。

當我們把這一切的邏輯整理完成後，我們對於資料庫的功能上就已經滿足了。

接下來的就是抽象數據的分類了。

例如：我們需要對不同的表進行一個分類，我個人喜歡把表分成三種，一種是基礎數據表，一種是過程表，一種是結果表。

怎麼解釋呢？

基礎數據表：顧名思義，就是對於基礎數據的維護，哪些可以成為基礎數據呢？就是我們的業務發生的各個過程中，這些數據都是可以參與其中的，這就是基礎數據。

例如：貨物的信息，客戶的信息。

過程表：就是僅僅在一個過程中使用的表，當這個過程結束了，這個表就沒用了。

例如：訂單表，付款單表。他們表示的僅僅是訂單從下單到最後關閉的這個過程，關閉以後，這個訂單表其實我們就不會再去使用它了。

結果表：這個表的數據有一個特點，只允許添加，不允許刪除和修改，這個表的數據本身就是對於老敏一種最終結果的表現。

例如：日誌表、賬單表。

那我們在進行資料庫設計的時候螞寬，就需要將這些使用情況考慮進去，將不同功能的表進行分離，盡量降低耦合，讓相互表的修改不會影響使用。

例如：收款單，我們需要收一筆款的時候，就會生成這個收款單，當款收到後，這個收款單的功能就結束了。

但現實的情況中，可能財務收到了這筆錢，結束了收款單流程後，他發現填錯了，本來應該收100，結果收款單寫的110。

但是，收款單表示的是過程，當這個過程結束了，我們就不會再需要上一個收款單了，所以，按照我們業務的處理流程，我們應該先生成一筆沖抵的收款單，例如收到-110，然後再生成新的100的收款單。

我們每個月還會有財務統計報表，財務報表因為和現實中的財務賬有關，是絕對不允許變動的，因此，這個財務報表就是一個結果表，我們會按月通過批處理程序，將收款單的明細和統計數據放到另一張表中，感覺好像比較冗餘，但是這個確實非常必要的。

因為我曾經就遇到過一個情況，我們直接用過程表來進行數據的統計，然後11月30日有一筆收款已經完成了，結果發現收錯了，就重新做了個收款單，結果本來已經出了11月結果的賬單發生了變化，導致財務實際的處理出現了問題。

因此，數據的冗餘有時候是有必要的，我們需要根據不同表的類型進行一些冗餘的設計。

對於資料庫設計的考慮點還有很多，可能一時半會兒也說不完，大家如果有什麼好的思路，也可以在下方悶含亮評論或關注我給我留言。

④ 具體的資料庫設計與實現過程

大致的講主要是根據用戶的需求，然後設計資料庫的E-R模型，然後將E-R模型圖轉換為各種表，並對其進行資料庫設計範式（範式因不同書籍有不同）的審核，然後進行資料庫的實施，然後運行維護。

一句話來講就是將用戶的需求變成帶有各種關系的表，以及其它的資料庫結構，然後供編程使用

具體如下：

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

（1）需求分析。

（2）概念設計。

（3）邏輯設計。

（4）物理設計。

（5）資料庫實施。

（6）資料庫運行和維護。

5．1．1需求分析階段

進行資料庫設計首先必須准確了解與分析用戶需求，包括數據與處理需求。需求分析是整個設計過程的基礎，是最困難、最耗時的一步。作為「地基」的需求分析是否做得充分與准確，決定了在其上構建「資料庫大廈」的速度與質量。需求分析做得不好，可能會導致整個資料庫重新設計，因此，務必引起高度重視。

5．1．2概念模型設計階段

在概念設計階段，設計人員僅從用戶角度看待數據及其處理要求和約束，產生一個反映用戶觀點的概念模式，也稱為「組織模式」。概念模式能充分反映現實世界中實體間的聯系，又是各種基本數據模型的共同基礎，易於向關系模型轉換。這樣做有以下好處：

（1）資料庫設計各階段的任務相對單一化，設計復雜程度得到降低，便於組織管理。

（2）概念模式不受特定DBMS的限制，也獨立於存儲安排，因而比邏輯設計得到的模式更為穩定。

（3）概念模式不含具體的DBMS所附加的技術細節，更容易為用戶所理解，因而能准確地反映用戶的信息需求蠢兆信。

概念模型設計是整個資料庫設計的關鍵，它通過對用戶需求進行綜合、歸納與抽象，形成一個獨立於具體DBMS的概念模型。如採用基於E-R模型的資料庫設計方法，該階段即將所設計的對象抽象出E-R模型；如採用用戶視圖法，則應設計出不同的用戶視圖。

5．1．3邏輯模型設計階段

邏輯模型設計階段的任務是將概念模型設計階段得到的基本E-R圖，轉換為與選用的DBMS產品所支持的數據模型相符合的邏輯結構。如採用基於E-R模型的資料庫設計方法，該階段就是將所設計的E-R模型轉換為某個DBMS所支持的數據模型；如採用用戶視圖法，則應進行表的規范化，列出所有的關鍵字以及用數據結構圖描述表集合中的約束與聯系，匯總各用戶視圖的設計結果，將所有的用戶視圖合成一個復雜的資料庫系統。

5．1．4資料庫物理設計階段

資料庫的物理結構主要指資料庫的存儲記錄格式、存儲記錄安排和存取方法。顯然，資料庫的物理設計完全依賴於給定的硬體環境和資料庫產品。在關系模型系統中，物理設計比較簡單一些，因為文件形式是單記錄類型文件，僅包含索引機制、空間大小、塊的大小等內容。

物理設計可分五步完成，前三步涉及到物理結構設計，後兩步涉及到約束和具體的程序設計：

（1）存儲記錄結構設計：包括記錄的猜型組成、數據項的類型、長度，以及邏輯記錄到存儲記錄的映射。

（2）確定數據存放位置：可以把經常同時被訪問的數據組合在一起，「記錄聚簇（cluster）」技帶輪術能滿足這個要求。

（3）存取方法的設計：存取路徑分為主存取路徑及輔存取路徑，前者用於主鍵檢索，後者用於輔助鍵檢索。

（4）完整性和安全性考慮：設計者應在完整性、安全性、有效性和效率方面進行分析，作出權衡。

（5）程序設計：在邏輯資料庫結構確定後，應用程序設計就應當隨之開始。物理數據獨立性的目的是消除由於物理結構的改變而引起對應用程序的修改。當物理獨立性未得到保證時，可能會引發對程序的修改。

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

5．1．5資料庫實施階段

根據邏輯設計和物理設計的結果，在計算機系統上建立起實際資料庫結構、裝入數據、測試和試運行的過程稱為資料庫的實施階段。實施階段主要有三項工作。

（1）建立實際資料庫結構。對描述邏輯設計和物理設計結果的程序即「源模式」，經DBMS編譯成目標模式並執行後，便建立了實際的資料庫結構。

（2）裝入試驗數據對應用程序進行調試。試驗數據可以是實際數據，也可由手工生成或用隨機數發生器生成。應使測試數據盡可能覆蓋現實世界的各種情況。

（3）裝入實際數據，進入試運行狀態。測量系統的性能指標，是否符合設計目標。如果不符，則返回到前面，修改資料庫的物理模型設計甚至邏輯模型設計。

5．1．6資料庫運行和維護階段

資料庫系統正式運行，標志著資料庫設計與應用開發工作的結束和維護階段的開始。運行維護階段的主要任務有四項：

（1）維護資料庫的安全性與完整性：檢查系統安全性是否受到侵犯，及時調整授權和密碼，實施系統轉儲與備份，發生故障後及時恢復。

（2）監測並改善資料庫運行性能：對資料庫的存儲空間狀況及響應時間進行分析評價，結合用戶反應確定改進措施。

（3）根據用戶要求對資料庫現有功能進行擴充。

（4）及時改正運行中發現的系統錯誤。

⑤ 資料庫設計的基本步驟

需求分析

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

需求分析是在用戶調查的基礎上，通過分析，逐步明確用戶對系統的需求，包括數據需求和圍繞這些數據的業務處理需求。在需求分析中，通過自頂向下，逐步分解的方法分析系統，分析的結果採用數據流程圖(DFD)進行圖形化的描述。

概念設計

對用戶要求描述的現實世界(可能是一個工廠、一個商場或者一個學校等)，通過對其中諸處的分類、聚集和概括，建立抽象的概念數據模型。這個概念模型應反映現實世界各部門的信息結構、信息流動情況、信息間的互相制約關系以及各部門對信息儲存、查詢和加工的要求等。所建立的模型應避開資料庫在計算機上的具體實現細節，用一種抽象的形式表示出來。以擴充的實體—（E-R模型）聯系模型方法為例，第一步先明確現實世界各部門所含的各種實體及其屬性、實體間的聯系以及對信息的制約條件等，從而給出各部門內所用信息的局部描述(在資料庫中稱為用戶的局部視圖)。第二步再將前面得到的多個用戶的局部視圖集成為一個全局視圖，即用戶要描述的現實世界的概念數據模型。

邏輯設計

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

物理設計

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

驗證設計

在上述設計的基礎上，收集數據並具體建立一個檔鎮資料庫，運行一些典型的應用任務來驗證資料庫設計的正確性和合理性。一般，一個大型資料庫的設計過程往往需要經過多次循環反復。當設計的某步發現問題時，可能就需要返回到前面去進行修改。因此，在做上述資料庫設計時就應考慮到今後修改設計的可能性和方便性。

⑥ 資料庫的開發流程是什麼(開發資料庫系統的工作步驟)

這是一個非常復雜的問題。建議這位網友去看看有關軟體工程的書籍。當然，看書是一件非常煩悶的事情，在這，盡管試試將我的經驗寫一點吧。

首先，要明確你要做一個什麼系統。想達到什麼目的。想怎樣去使用。有了明確的目標後，便要開始計劃整個資料庫系統該怎樣去做。

第二，是選擇資料庫後台。資料庫是保存數據的工具，可以理解為保存數據的一個大倉庫，它把你所需要的數據全部保存起來。但要怎樣使用這些數據，使之可以根據你的需要顯示出來，那就不是資料庫的責任了，這就需要程序來實現了。不同的資料庫後台各有優點缺點，不可一概而論哪個好哪個差，要看系統實際來斟酌。即是說，確定目標後就需要選擇資料庫。

第三，確定後台資料庫的內容，即確定數據結構。既然整個資料庫等於一個大倉庫，此時就要把倉庫劃分成一個個區域，用於保存不同類別的東西。這就是確定數據表及每個表的欄位及各欄位的數據類型。這是非常巨大的工作，你需要把有可能使用到的內容都設計到你的數據表中，以便以後可以保存及調用數據。還要想到表與表的關系，欄位與欄位的關系。好的數據結構會使到整個程序設計方便、科學、全面。這些內容，必須去查看相關書籍，同時不斷積累經驗，並非三言兩語可以說得清楚了。

第四，選擇合適的前台開發工具。對於後台數據脊猛庫的操作，目前常用的前台畢野此開發工具基本都可以與之相連並對之操作，但是不同的開發語言有各自的長處。選擇哪一種語言並不太重要，最重要是看你是否願意一心一意鑽研下去。對於初學者，什麼語言都是手迅一樣的，就如小孩子學語言，學中英意日其實都一樣容易，也一樣難。

第五，當清楚資料庫後台和開發前台的特性與功能後，就可以開始規劃系統的流程了。一般可以根據系統功能先將其劃分為幾大功能模塊，然後再細分為各個細功能模塊，然後對於各個功能模塊進行設計。一般流程可以是這樣的：

1、設計流程圖。把整個功能用流程的方式顯示出來，讓自己的思路清楚地記錄在流程圖上，這樣可以輕易地模擬模塊的運算過程，查找出不合理的地方進行修改。

2、編寫程序。確定流程合理無誤後，便可以開發進行程序的編寫。由於現時硬體的強大，對語句的要求已經不再強調。只要可以達到目的，就可以了。

第六，試運行程序。完成一個功能後，可以試運行，輸入數據進行測試，不斷修改，最後達到完全無誤。

第七，測試。完成程序後，就要進行全面的測試。一般來說，自己是找不到自己的錯誤的。明知是錯就不會寫進去，所以我喜歡找別人來為我測試。讓別人去用，而且是讓別人隨便地用，不一定按自己所說的操作方法去用。這樣最容易找到程序中的錯誤。

第八，不斷地修改。不斷修改程序，使其所有的漏洞都改正過來。

第九，編譯。程序確認無誤後，就可以進行編譯。

第十，投入使用。

其實我所寫的並不能回答這個問題，完全解答這個問題，最後還是去學習一下軟體工程。不看書總是不行的。希望可以為你帶來一點點幫助吧。

⑦ 數據流程設計

1.系統與外部的數據交流

遙感圖像處理系統與外部的數據交流主要是直接同數據管理與資料庫子系統的交流，本系統所孫孝需要的數據如空間地質數據、遙感圖像數據、地質礦產專題數據從數據管理與資料庫子系統的基礎資料庫調入，產生的成果地質矢量專題圖件存入數據管理與資料庫子系統的成果數沒凱侍據庫。圖7-1為系統系統數據流程圖。

圖7-1 系統數據流程圖

遙感圖像處理系統選用ESRI公司的ArcSDE for Oracle作為空間資料庫引擎，實現空間數據、屬性數據、遙感圖像數據的無縫連接。圖7-2為本子系統與資料庫系統關系結構圖。

2.系統內部的數據流動

系統從綜合資料庫中將圖像數據、地質礦產數據、空間地質數據讀入後，經過圖像處理模塊、信息提取模塊獲得專題信息，再將這些數據輸枯吵出到資料庫。詳細流程見圖7-2。

⑧ 簡述資料庫應用系統的設計步驟(簡述資料庫系統構成及數據設計的原則)

資料庫設計的基本步驟：

1、系統需求分析與設計。

2、概念結構分析與設計。

3、邏輯結構分析與設計。

4、物理結構分析與設計。

5、系統實施。

6、系統維護。

(8)流程資料庫設計擴展閱讀：

資料庫設計技巧：

1、原始文件與實體的關系

它可以是一對一，一對多，多對多的關系。一般來說，它們是一對一的關系：一個原始文檔只對應於一個實體。在特殊情況下，它們可以是一對多或多對一關系，即一個原始文檔對應於多個實體，或者多個原始文檔對應於一個實體。

這里的實體可以姿殲理解為基本表。在對應關系明確後，對輸入介面的設計非常有利。

2、主鍵和外鍵

一般來說，實體不能既沒有主鍵也沒有外鍵。在E－R圖中，葉中的實體可以定義主鍵或不定義主鍵（因為它沒有子代），但它必須有外鍵（因為它有父項）。

主鍵和外鍵的設計在全局資料庫的設計中起著重要的作用。當全球資料庫的設計完成後，一位美國資料庫設計專家說：「鑰匙無處不在，只有鑰匙。」。這是他資料庫設計的經驗，也體現了他對信息系統核心（數據模型）高度抽象的理念。

因為：主鍵是一個高度抽象的實體。主鍵和外鍵的配對表示實體之間的連接。

3、基本表的屬性

基本表不同於中間表和臨時表，因為它具有以下四個特點：

原子性。基本表跡握沖中的欄位不可分解。

原始主義。基本表中的記錄是原始數據（基本數據）的記錄。

演繹的。所有輸出數據都可以從基本表和代碼表中的數據導出。

穩定。基本表的結構比較穩定，表中的記錄要長期保存。

在了解基本表的性質之後，在設計資料庫時，可以將基本表與中間表和臨時表區分皮升開來。

來源：網路-資料庫設計

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

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

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

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

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

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

(9)流程資料庫設計擴展閱讀：

形成過程

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

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

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

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

⑩ 如何實現OA系統的自定議審批流程的資料庫設計

我舉一個例子：有的OA系統是要公司客戶自己有伺服器，然後裝到客戶的伺服器上。可是客戶嫌麻煩，所以我想將OA系統（PHP+Mysql）放在自己的伺服器上，讓公司客戶及其員工來注冊使用。那麼問題來了，原來在客戶自己的伺服器上資料庫也就十幾張表，但都放到我的伺服器上，每注冊一個公司就得增加十幾張表，那如果有一萬家公司注冊資料庫不得有幾十萬張表？跟樓主一樣的問題，有一些老牌廠商早就給出來完美答案了，比如華為、天翎都有過類似的問題，這些企業提出的解決方案就很不錯，就針對上面的問題，最簡單的辦法是給每張表加個實例ID，一個公司對應一個實例ID，然後在你的MVC架構中跟DB最近的這一層加個攔截器，每個SQL查詢都自動帶上實例ID，這樣不用對代碼做很大改動。後期再根據需要優化，哪些公司合用一張表，哪些單獨佔用一張表甚至一個資料庫，總之具體問題具體對待，需要在運營的過程中根據用戶量和業務情況來分析採取對策。