说起数据模型大部分人就会想到数据库的表结构，就是用一张图把数据库里表的结构给画一遍。
数据模型的作用之一确实是这样，准确来说是用图的方式描述数据库里的表结构。但是，数据模型的用途不应该被局限于这个范围之内，根据设计的流程、产出模型目的的不同，作用不一样，叫法也不一样。
举个栗子！
就拿地图来说，假设我想知道地球上有多少个国家、位置都在什么地方。
我发现地球这么大，自己一个人管的话根本管不过来，所以决定找几个小弟帮我管，就按照一个人一个一个基准来安排。
为了让小弟们知道各自管理的国家里都有啥，还需要给他们各自一张国家地图，而他们根本不需要知道别人管的国家里都有什么。
所以，这时候我的需求是，其他国家都不关注了，每人给他们搞一张国家地图。
这样不断划分和细化，最后就有了各个级别不同的地图，随时想知道啥都能找到。
最终的级别肯定是最最详细的，我想从望京到三里屯怎么走都能告诉我，甚至是给我好几条路，各种交通工具要怎么走耗费多长时间我都可以提前知道个大概，无比方便啊～
这些图跟数据模型一个套路，林子大了不好管，有这么个图，我心里更清楚我有啥。
再按这个套路看看企业数据的模型管理的需求。
概括模型（主题域模型）
从企业级的角度告诉管理者企业都有哪些数据，这样的数据大部分都是按主题划分，主题跟业务是紧密关联的，所以，不同行业之间的主题域会有些许的不同。
这就好比世界地图，不需要过于详细的信息，只需要知道地球上（企业里）有哪些国家（主题域）就行。
比如说，通信行业中有TFM的SID（Shared Information Data Model），金融行业有Teradata的FS-LDM等。
概念模型
概念模型是根据主题域模型，将某一个主题域进行细化的模型图，比如说客户主题域里包含了客户的基本信息、客户的详细信息（联系方式、兴趣爱好等）和与客户相关的一些关系信息等。
中国是一个国家，就相当于一个主题域，这个国家里有哪些省，就相当于详细描述主题域里有哪些数据。道理是一样的，只是针对某一个特定主题的详细描述。
逻辑模型
这样看来逻辑模型是不是就是某个省的地图了呢？这样比喻虽然没啥问题，但是，这样的比喻有点不大恰当。数据管理和地图的管理还是有点不同。
不过逻辑模型是对某个主题域的概念模型进行细化的产物这一点是没错的。
只是，数据模型最详细的一层就定义为逻辑模型了，具体定义了每一个实体、实体中的每一个属性、实体和实体之间的详细关系等。
如果要拿地图打比方的话，就相当于不光划分了每个省，每个省内的每一个城市，城市中的每一条街道和城市之间的联系都定义在了这一级别。
有了这么一张图的话，任何一个地址的信息都能被找到。也就是说，逻辑模型当中能够方便地找到每一个属性的具体位置和定义。
物理模型
物理模型的目的是根据逻辑模型考虑具体某种数据库的具体配置方式，展现物理层面的设计。比如说，具体的字段数据类型、长度，对分区、索引和系统字段设计等，都属于物理模型设计的范围之内。
所以，同一个逻辑模型，根据数据库管理系统的不同可以有多个不同数据库的物理模型。
最终根据设计好的物理模型，就可以根据模型生成SQL脚本或者直接在库中创建数据库对象。
总结
概括模型（主题域模型）是提供一个企业级数据管理视角的模型。
概念模型是对某个主题域中数据描述的框架，提供了主题域中数据的管理视角，同时也是设计某个主题域逻辑模型的初始流程，搭好某个主题域的框架之后，再详细化成逻辑模型。
逻辑模型和物理模型是同一级别的，从特征来看，逻辑模型以中文展示实体和属性，并且融入了具体的业务逻辑，是最细粒度的模型设计产物。也可以作为业务和技术交流的工具。
逻辑模型设计的时候往往是跟物理模型是一一对应的，也就是说逻辑模型中的一个实体对应物理模型中的一个表，逻辑模型中的一个属性也对应了物理模型中的一个字段。
物理模型除了详细定义了每一个字段的具体数据类型和长度之外，还会在设计阶段融入分区、索引、约束关系等的设计要素，保证逻辑模型中设计的结果能够真正落地到某个具体的数据库当中。
而根据物理模型创建的数据库对象来说，它们和物理模型也是一一对应的，物理模型当中设计的每一张表和每一个索引，在实际数据库中都有且仅有一个与其相对应的对象。
