模塊結構

模塊結構是指將程序或系統按照功能或其他原則劃分為若干個具有一定獨立性和大小的模塊，每個模塊具有某方面的功能。例如，操作系統模塊結構中，OS 按其功能精心地劃分為若干個模塊；每個模塊具有某方面的管理功能，如進程管理模塊、存儲器管理模塊、I/O 設備管理模塊等，並仔細地規定好各模塊間的接口，使各模塊之間能通過該接口實現交互。然後，再進一步將各模塊細分為若干個具有一定功能的子模塊，如把進程管理模塊又分為進程控制、進程同步等子模塊，同樣也要規定好各子模塊之間的接口。若子模塊較大時，可再進一步將它細分。 ^[1] 

在結構化設計中，採用自頂向下，逐步細化的方法將系統分解成為一些相對獨立、功能單一的模塊。

在一個管理信息系統中，系統的各組成部分之間總是存在着各種聯繫的，將系統或子系統劃分成若干模塊，則一個模塊內部的聯繫就是塊內聯繫，而穿越模塊邊界的聯繫就是塊間聯繫。由於模塊之間的互相聯繫越多，模塊的獨立性就越少，因此，引入模塊耦合和內聚的概念。

耦合表示模塊之間聯繫的程度。緊密耦合表示模塊之間聯繫非常強，鬆散耦合表示模塊之間聯繫比較弱，非耦合則表示模塊之間無任何聯繫，是完全獨立的。

內聚表示模塊內部各成分之間的聯繫程度。

一般説來，在系統中各模塊的內聚越大，則模塊間的耦合越小。但這種關係並不是絕對的。耦合小使得模塊間儘可能相對獨立，從而各模塊可以單獨開發和維護。內聚大使得模塊的可理解性和維護性大大增強。因此，在模塊的分解中應儘量減少模塊的耦合，力求增加模塊的內聚。

一個合理的子系統或模塊劃分，應該是內部聯繫強，子系統或模塊間儘可能獨立，接口明確、簡單，儘量適應用户的組織體系，有適當的共用性。也就是上面所説的“耦合小，內聚大”。按照結構化設計的思想，對模塊或子系統進行劃分的依據通常有以下幾種：

(1)按邏輯劃分，把相類似的處理邏輯功能放在一個子系統或模塊裏。例如，把“對所有業務輸入數據進行編輯”的功能放在一個子系統或模塊裏。那麼不管是庫存、還是財務，只要有業務輸入數據都由這個子系統或模塊來校錯、編輯。

(2)按時間劃分，把要在同一時間段執行的各種處理結合成一個子系統或模塊。

(3)按過程劃分，即按工作流程劃分。從控制流程的角度看，同一子系統或模塊的許多功能都應該是相關的。

(4)按通信劃分，把相互需要較多通訊的處理結合成一個子系統或模塊。這樣可減少子系統間或模塊間的通訊，使接口簡單。

(5)按職能劃分，即按管理的功能。例如，財務、物資、銷售子系統，或輸入記帳憑證、計算機優解子系統或模塊等等。一般來説，按職能劃分子系統，按邏輯劃分模塊的方式是比較合理和方便的。

概念數據模型（Conceptual Data Model）：簡稱概念模型，主要用來描述世界的概念化結構，它使數據庫的設計人員在設計的初始階段，擺脱計算機系統及DBMS的具體技術問題，集中精力分析數據以及數據之間的聯繫等，與具體的數據管理系統（Database Management System，簡稱DBMS）無關。概念數據模型必須換成邏輯數據模型，才能在DBMS中實現。

概念數據模型是最終用户對數據存儲的看法，反映了最終用户綜合性的信息需求，它以數據類的方式描述企業級的數據需求，數據類代表了在業務環境中自然聚集成的幾個主要類別數據。

概念數據模型的內容包括重要的實體及實體之間的關係。在概念數據模型中不包括實體的屬性，也不用定義實體的主鍵。這是概念數據模型和邏輯數據模型的主要區別。

概念數據模型的目標是統一業務概念，作為業務人員和技術人員之間溝通的橋樑，確定不同實體之間的最高層次的關係。在有些數據模型的設計過程中，概念數據模型是和邏輯數據模型合在一起進行設計的。

邏輯數據模型（Logical Data Model）:簡稱數據模型，這是用户從數據庫所看到的模型，是具體的DBMS所支持的數據模型，如網狀數據模型(Network Data Model)、層次數據模型(Hierarchical Data Model)等等。此模型既要面向用户，又要面向系統，主要用於數據庫管理系統（DBMS）的實現。

邏輯數據模型反映的是系統分析設計人員對數據存儲的觀點，是對概念數據模型進一步的分解和細化。邏輯數據模型是根據業務規則確定的，關於業務對象、業務對象的數據項及業務對象之間關係的基本藍圖。

邏輯數據模型的內容包括所有的實體和關係，確定每個實體的屬性，定義每個實體的主鍵，指定實體的外鍵，需要進行範式化處理。

邏輯數據模型的目標是儘可能詳細的描述數據，但並不考慮數據在物理上如何來實現。

邏輯數據建模不僅會影響數據庫設計的方向，還間接影響最終數據庫的性能和管理。如果在實現邏輯數據模型時投入得足夠多，那麼在物理數據模型設計時就可以有許多可供選擇的方法。

物理數據模型（Physical Data Model）:簡稱物理模型，是面向計算機物理表示的模型，描述了數據在儲存介質上的組織結構，它不但與具體的DBMS有關，而且還與操作系統和硬件有關。每一種邏輯數據模型在實現時都有起對應的物理數據模型。DBMS為了保證其獨立性與可移植性，大部分物理數據模型的實現工作又系統自動完成，而設計者只設計索引、聚集等特殊結構。

數據庫管理系統的各系統層進行分解、細化和具體化，形成功能相對單一和相對獨立，具有清晰的接口關係的模塊或子系統的結構層。精心構造的一個正確合理且能高效和穩定運行的動態結構，則稱為與之相應的數據庫管理系統的進程結構。各模塊相互之間的界面和調用關係以及調用頻度必須簡單、明瞭。

子系統通常還需細分為一些功能小模塊。例如， 編譯子系統(見圖 )至少應包括接口模塊、掃描模 塊、語法分析模塊、語義分析模塊、類型檢查模塊、 完整性約束檢查模塊、授權檢查模塊、錯誤處理模塊、優化模塊等。

執行子系統(見圖)至少應包括接口模塊，關係表達式解釋模塊，單元組接口模塊，存取路徑管理模塊，元組或記錄管理模塊，排序/合併模塊，優化 模塊和緩衝區管理模塊等。

以上的模塊結構只表示了系統的各模塊間的靜 態結構，對於一個實際運行的系統必須清晰地定義 各子系統和各模塊間的動態結構，即相互間的調用關係，數據和控制信息的流向，各模塊間的輸入和 輸出以及哪些是子程序(只生成一份拷貝)，哪些是進 程(生成多份拷貝)等。對於不同的數據庫管理系統， 其進程結構的定義各有其特點，一般是不相同的。 例如，存在多個同時存取數據庫的併發用户時，有的系統對每個用户都生成一套系統拷貝，而有的系統則生成一套服務進程，對多個用户提供服務。 ^[2]