模块化程序设计技术是 20 世纪 60 年代出现的一种结构化程序设计技术。该技术是基于“分解”和“模块化”原则来控制大型软件的复杂度。模块结构是指将程序或系统按照功能或其他原则划分为若干个具有一定独立性和大小的模块，每个模块具有某方面的功能。

模块结构是指将程序或系统按照功能或其他原则划分为若干个具有一定独立性和大小的模块，每个模块具有某方面的功能。例如，操作系统模块结构中，OS 按其功能精心地划分为若干个模块；每个模块具有某方面的管理功能，如进程管理模块、存储器管理模块、I/O 设备管理模块等，并仔细地规定好各模块间的接口，使各模块之间能通过该接口实现交互。然后，再进一步将各模块细分为若干个具有一定功能的子模块，如把进程管理模块又分为进程控制、进程同步等子模块，同样也要规定好各子模块之间的接口。若子模块较大时，可再进一步将它细分。

基本原则

在结构化设计中，采用自顶向下，逐步细化的方法将系统分解成为一些相对独立、功能单一的模块。

在一个管理信息系统中，系统的各组成部分之间总是存在着各种联系的，将系统或子系统划分成若干模块，则一个模块内部的联系就是块内联系，而穿越模块边界的联系就是块间联系。由于模块之间的互相联系越多，模块的独立性就越少，因此，引入模块耦合和内聚的概念。

耦合表示模块之间联系的程度。紧密耦合表示模块之间联系非常强，松散耦合表示模块之间联系比较弱，非耦合则表示模块之间无任何联系，是完全独立的。

内聚表示模块内部各成分之间的联系程度。

一般说来，在系统中各模块的内聚越大，则模块间的耦合越小。但这种关系并不是绝对的。耦合小使得模块间尽可能相对独立，从而各模块可以单独开发和维护。内聚大使得模块的可理解性和维护性大大增强。因此，在模块的分解中应尽量减少模块的耦合，力求增加模块的内聚。

划分的依据

一个合理的子系统或模块划分，应该是内部联系强，子系统或模块间尽可能独立，接口明确、简单，尽量适应用户的组织体系，有适当的共用性。也就是上面所说的“耦合小，内聚大”。按照结构化设计的思想，对模块或子系统进行划分的依据通常有以下几种：

(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为了保证其独立性与可移植性，大部分物理数据模型的实现工作又系统自动完成，而设计者只设计索引、聚集等特殊结构。

数据库管理系统的各系统层进行分解、细化和具体化，形成功能相对单一和相对独立，具有清晰的接口关系的模块或子系统的结构层。精心构造的一个正确合理且能高效和稳定运行的动态结构，则称为与之相应的数据库管理系统的进程结构。各模块相互之间的界面和调用关系以及调用频度必须简单、明了。

模块结构

子系统通常还需细分为一些功能小模块。例如， 编译子系统(见图 )至少应包括接口模块、扫描模 块、语法分析模块、语义分析模块、类型检查模块、 完整性约束检查模块、授权检查模块、错误处理模块、优化模块等。

执行子系统(见图)至少应包括接口模块，关系表达式解释模块，单元组接口模块，存取路径管理模块，元组或记录管理模块，排序/合并模块，优化 模块和缓冲区管理模块等。

模块结构

以上的模块结构只表示了系统的各模块间的静 态结构，对于一个实际运行的系统必须清晰地定义 各子系统和各模块间的动态结构，即相互间的调用关系，数据和控制信息的流向，各模块间的输入和 输出以及哪些是子程序(只生成一份拷贝)，哪些是进 程(生成多份拷贝)等。对于不同的数据库管理系统， 其进程结构的定义各有其特点，一般是不相同的。 例如，存在多个同时存取数据库的并发用户时，有的系统对每个用户都生成一套系统拷贝，而有的系统则生成一套服务进程，对多个用户提供服务。