数据建模中比较常用的工具有哪些

随着科技的日新月异，人们对数据的依赖稳步上升中，尤其在商业等领域，对于企业而言正确且连贯的数据流，是他们做出快速、精准的决策的重要依据之一。因此，建立正确的数据流和数据结构才能保证最好的结果，这个过程就是大家耳闻能详的数据建模。

下面为大家推荐一些数据建模中常见的几种工具。

1、SQL数据库建模器

该软件使企业可以参与逆向工程和正向工程。利用已经存在的数据库并完善它们。然后，使用正向工程技术来了解它们如何随时间的推移而增长。该平台的更多独特功能包括创建多个主题区域的能力以及非常友好的用户界面。使用此工具的一些企业包括福特、联想、Wayfair和德勤等公司。

2、PowerDesigner

PowerDesigner是目前数据建模业界的领头羊。功能包括：完整的集成模型，和面向包含IT为中心的、非IT为中心的差异化建模诉求。支持非常强大的元数据信息库和各种不同格式的输出。PowerDesigner拥有一个优雅且人性化的界面，非常易懂的帮助文档，快速帮助用户解决专业问题。

3、CA ERwin

ERwin 也是业界领先的数据建模解决方案，能够为用户提供一个简单而优雅的界面同时处理复杂的数据环境问题。Erwin的解决方案提提供敏捷模型，同时元数据可以放在普通的数据库中进行处理，这样就能够保证数据的一致性和安全性。Erwin支持高度自定义的数据类型、APIs，允许自动执行宏语言等等。Erwin还建有一个很活跃的用户讨论社区，使得用户之间可以分享知识和各种经验。

4、SQL Power Architect

SQL Power Architect 是一个Java开发的数据库建模工具，特别适合做数据仓库和数据集市的应用建模，它允许设计人员同时打开多个数据源连接，并直接从数据库中获取模型定义。

5、dbdiagramio

dbdiagramio是一个快速上手的数据库设计器，专注于绘制数据库关系图，专为开发人员，DBA，数据分析师而设计，在线保存和共享图表可帮助您使用其自己的特定于域的语言（DSL：Domain-specific language）绘制数据库图。它们的定义语言非常简单，使用键盘即可轻松进行编辑/复制，UI简洁，并包含有漂亮的图表。

为了避免错误并加快进度，建议大家可以使用这些更加专业的工具（软件），来帮助我们建立数据模型，且能够更快捷的生成报告来描述这个数据模型，为大家带来实利。

（一）基础地质数据资料

地下水系统建模所涉及的基础资料有图文数据、矢量位图，不同比例、不同坐标系的数据，建模时需要进行数据融合、转换，仔细分析原始资料，存精去伪，才能为模型构建奠定坚实的基础。黑河流域建模资料主要由甘肃省地质调查院提供。

1黑河流域地图

黑河流域矢量地图是研究黑河的基础图件，是地质大调查的标准用图，它划定了流域的研究边界，钻孔、剖面线都可在其上标出地理位置。从建模的需求考虑，还在上面绘制了流域内断层的位置和各盆地的分界线。

2钻孔资料

主要包括钻孔各地层深度、岩性、所属时代等与地质结构相关的内容。钻孔数量有240多个，主要分布在黑河流域平原区。钻孔数据已装订成册记录，为符合建模数据的要求，把钻孔全部录入到地下水资源数据系统access数据库Gwexplore中。

3剖面图

按照建模对地质剖面的要求，我们与甘肃水文二队的地质技术人员共同绘制了黑河流域的地质剖面图，剖面主要集中在流域平原区各盆地内，使用MapGIS软件进行绘制。图b为绘制的一张剖面图，它由MAPGIS的区文件WP、线文件WL、点文件WT组成。图a表示绘制的58条剖面线，剖面线投影到黑河流域地图上，以红色表示。

剖面绘制比例为横1∶20万，纵1∶1万。剖面绘制以地层岩组为主，流域内主要绘制第四系下更新统—全新统、第三系，还有少量的白垩系、侏罗系以及花岗岩侵入体，颜色以淡黄至浅绿为主，山区由于资料少，采用透1∶20万地质图的方式勾出一薄层地表岩层，因为20万地质图对于大区域来说内容太细，不能反映规律性的东西，所以建模主要集中在平原区的盆地内进行。

在绘制剖面图过程中，参考查阅了大量的图文资料及钻孔资料，现列举如下：

（1）黑河流域1∶20万地质图；

图5-1 黑河流域水文地质剖面线片面分布图

图5-2 黑河流域典型水文地质剖面

（2）黑河流域1∶20万地形图；

（3）张掖盆地1∶20万水文地质立体结构图；

（4）黑河流域1∶20万综合水文地质图；

（5）河西走廊1∶50万第四系松散层等值线及底界高程图；

（6）河西走廊中东段诸盆地1∶20万电测深推断第四系松散层及厚度图；

（7）黑河干流中游地区1∶20万地下水位拟和图；

（8）黑河干流中游地区1∶20万地貌图；

（9）黑河干流中游地区1∶20万潜水埋深及等水位线图；

（10）黑河流域1∶20万区域水文地质普查报告；

（11）区域地质调查报告多本；

（12）区域地质测量报告多本。

4地表等高线DEM数据

此数据为国家基础地理信息中心标准数据，数据格式为ARC/INFO类型，比例尺为1∶25万，坐标为地理坐标格式，椭球参数为北京54/克拉索夫，坐标单位为度。

除地表高程线外，还有地表地理信息数据，以多层形式存放。黑河流域所用的图号是：J4701—J4712，K4701—K4716。

5地下水顶板、底板、水位等值线图

此图件是对黑河流域地下水系统进行了平面和垂向上分区划分。主要是依据黑河流域地下水补、径、排的关系以及地下水类型进行划分。绘制地下水系统平面分区图和垂向上的单层和多层分区图，潜水底界埋深和承压水顶板埋深，以及基底埋深和构造分布等内容。此图件为保定方法所提供，比例尺为1∶100万。

图5-3 黑河流域基底埋深构造图

6卫星地面遥感

收集的遥感影像是合成好的，进行几何精纠正的资料，在影像边上有经纬度，可以使用MapGIS进行校正。

图5-4 黑河流域卫星影像照片

7地下水动态观测资料

流域内观测资料包括一系列的气象、降水等与地下水相关的数据记录。模型构建需要地下水水位变化的动态观测资料，它包括观测点的位置、坐标、孔深、监测层位及状况，和水位、水温及水位动态曲线。我们收集了近两年的流域水位和有记录的降水观测资料，数据以EXCEL表形式存放。

8文档资料

文档资料为黑河流域的勘探、科研报告，包括项目汇报书、区域水文地质普查报告、专题研究报告等。这些资料为模型的建立具有重要的参考价值。

（二）数据预处理

数据预处理是使数据资料整合成统一比例、投影的图件，完成DEM数据、遥感影像数据、MapGIS等数据集成融合、精度匹配的问题。需解决的问题有图文资料的投影转换、比例缩放、范围裁减、数字化、几何校正、坐标匹配等。

1坐标系统和高程系统的选择

从收集的资料看，对流域内所做的工作大多是基于高斯坐标的基础上进行绘图，因此，本建模采用高斯-克里格坐标系统。所有的资料都向高斯投影转换，转换的高斯-克里格投影参数如下：

坐标系类型：投影平面直角坐标系

投影类型：高斯克力格投影

比例尺：1∶500000

椭球面高程：0

坐标单位：mm

投影面高程：0

投影中心点经度：993000

投影区任意点纬度：370000

投影带类型：任意

投影带序号：20

坐标系统选定后，还需要确定高程系统，由于收集的资料都以标高为单位，即以1956年黄海平均海水面为基准。因此，本次建模不再设立自定义高程系统，以标准高程进行建模。

2地表数据预处理

原始数据以ARC/INFO格式存放，首先需要用ARC/INFO软件将此数据转换为MapGis格式的文件，进行接图 *** 作，把分块的小图拼装为一张大图，进行投影变换，然后以源投影参数比例为25万，地理坐标格式，椭球参数为北京54/克拉索夫，比例尺为1，坐标单位为度的投影方式转换为目标投影方式。投影转换完毕后，进行等高线的高程数据属性提取，使用MAPGIS属性库管理模块进行提取，转换成DBF格式数据库文件，再使用FOXPRO转换成文本文件。MAPGIS把等高线文件转成MAPGIS明码数据文件格式，这样，每条线段与高程数据一一对应，就有了地表的三维坐标。

3黑河流域地图预处理

黑河流域地图以兰伯特格式存在，与上面相同，采取同样的方式进行投影变换。转换为50万比例的高斯投影。

4不明投影方式的图件预处理

由于收集到的图件资料较多，有个别的图纸投影方式不明确，这就需要进行投影识别，即把已知投影和比例的文件进行不同形式的投影变换，然后进行对比，以确认投影方式，如果比较效果不明确，则进行图形的误差校正，使不明投影方式的图件与目的投影相符，达到数据的融合一致。

5剖面文件预处理

对剖面的输入涉及到两个文件，即剖面线文件和剖面文件。剖面线需在已投影的流域地图上单独提取出来，转变为MAPGIS明码文件。剖面使用MAPGIS的转换模块转换成DXF文件。

剖面的坐标需要按照规定进行调整，即设定剖面左下角标尺的横坐标为零，纵坐标为实际高程除以剖面纵向比例后的数值，以毫米为单位。剖面线方向为从左向右，这样才能保证剖面在输入系统后与剖面线保持一致，不会出现剖面与剖面线相分离的现象。

6遥感卫片的处理变换

遥感卫片的处理需要使用ERDAS软件进行波段叠加处理，即多波段低分辨率影像数据的光谱信息与单波段高分辨率影像数据的分辨率信息进行融合。在建模阶段，还需要使用MapGIS软件进行几何校准及配准，用PHOTOSHOP软件进行图像的格式变换和裁剪，以符合流域建模分辨率、工区的要求。

十张图讲清楚ddd建模六个问题与六个步骤如下：

1 六个问题

11 为什么使用

DDD方法论的核心是将问题不断分解，把大问题分解为小问题，大业务分解小领域，简而言之就是分而治之，各个击破。

分而治之是指直接面对大业务我们无从下手，需要按照一定方法进行分解，分解为高内聚的小领域，使得业务有边界清晰，而这些小领域是我们有能力处理的，这就是领域驱动设计的核心。

各个击破是指当问题被拆分为小领域后，因为小领域业务内聚，其子领域高度相关，我们在技术维度可以对其进行详细设计，在管理维度可以按照领域对项目进行分工。需要指出DDD不能替代详细设计，DDD是为了更清晰地详细设计。

在微服务流行的互联网行业，当业务逐渐复杂时，技术人员需要解决如何划分微服务边界的问题，DDD这种清晰化业务边界的特性正好可以用来解决这个问题。

12 方法与目标

我们的目标是将业务划分清晰的边界，而DDD是达成目标的有效方法之一，这一点是需要格外注意的。DDD是方法不是目标，不需要为了使用而使用。

例如业务模型比较简单可以很容易分析的业务就不需要使用DDD，还有一些目标是快速验证类型的项目，追求短平快，前期可能也不需要使用领域驱动设计。

13 整体与局部

领域可以划分多个子领域，子域可以再划分多个子子域，限界上下文本质上也是一种子子域，那么在业务分解时一个业务模块到底是领域、子域还是子子域？

我认为不用纠结在这个问题，因为这取决于看待这个模块的角度。你认为整体可能是别人的局部，你认为的局部可能是别人的整体，叫什么名字不重要，最重要的是按照高内聚的原则将业务高度相关的模块收敛在一起。

14 粒度粗与细

业务划分粒度的粗细并没有统一的标准，还是要根据业务需要、开发资源、技术实力等因素综合考量。例如微服务拆分过细反而会增加开发、部署和维护的复杂度。

但是拆分过粗可能会导致大量业务高度耦合，开发部署起来是挺快的，但是缺失可维护性和可扩展性，这需要根据实际情况做出权衡。

15 领域与数据

领域对象与数据对象一个重要的区别是值对象存储方式。在讨论领域对象和数据对象之前，我们首先讨论实体和值对象这一组概念。实体是具有唯一标识的对象，而唯一标识会伴随实体对象整个生命周期并且不可变更。值对象本质上是属性的集合，并没有唯一标识。

领域对象在包含值对象的同时也保留了值对象的业务含义，而数据对象可以使用更加松散的结构保存值对象，简化数据库设计。

现在假设我们需要管理足球运动员信息，对应的领域模型和数据模型应该如何设计？姓名、身高、体重是一名运动员本质属性，加上唯一编号可以对应实体对象。跑动距离，传球成功率，进球数是运动员比赛中的表现，这些属性的集合可以对应值对象。

值对象在数据对象中可以用松散的数据结构进行存储，而值对象在领域对象中需要保留其业务含义。

16 抽象与灵活

抽象的核心是找相同，对不同事物提取公因式。实现的核心是找不同，扩展各自的属性和特点。例如模板方法设计模式正是用抽象构建框架，用实现扩展细节。

我们再回到数据模型的讨论，可以发现脚本化是一种拓展灵活性的方式，脚本化不仅指使用groovy、QLExpress脚本增强系统灵活性，还包括松散可扩展的数据结构。

数据模型抽象出了姓名、身高、体重这些基本属性，对于频繁变化的比赛表现属性，这些属性值可能经常变化，甚至属性本身也是经常变化，例如可能会加上射门次数，突破次数等，所以采用松散的JSON数据结构进行存储。

2 六个步骤

工程理论总是要落地的，落地也是需要一些步骤和方法的。本文我们一起分析一个足球运动员信息管理系统，目标是管理运动员从转会到上场比赛整条链路信息，这个系统大家应该也都没有接触过，我们一起来分析。

需要说明本实例着重演示DDD方法论如何落地，业务细节可能并不能面面俱到。

21 流程梳理

梳理流程有两个问题需要考虑，第一个问题是从什么视角去梳理？因为不同的人看到的流程是不一样的。答案是取决于系统需要解决的是什么问题，因为我们要管理运动员从转会到上场比赛整条链路信息，所以从运动员视角出发是一个合适的选择。

第二个问题是对业务不熟悉怎么办？因为我们不是体育和运动专家，并不清楚整条链路的业务细节。

答案是梳理流程时一定要有业务专家在场，因为没有真实业务细节，无法领域驱动设计。同理在互联网梳理复杂业务流程时，一定要有对相关业务熟悉的产品经理或者运营一起参与。

假设足球业务专家梳理出了业务流程，运动员提出转会，协商一致后到新俱乐部体检，体检通过就进行签约。进入新俱乐部后进行训练，训练指标达标后上场比赛，赛后参加新闻发布会。

22 四色建模

(1) 时标对象

四色建模第一种颜色是红色，表示时标对象。时标对象是四色建模最重要的对象，可以理解为核心业务单据。在业务进行过程中一定要对关键业务留下单据，通过这些单据可以追溯出整个业务流程。

时标对象具有两个特点：第一是事实不可变性，记录了过去某个时间点或时间段内发生的事实。第二是责任可追溯性，记录了管理者关注的信息。现在我们分析本系统时标对象有哪些，需要留下哪些核心业务单据。

转会对应转会单据，体检对应体检单据，签合同对应合同单据，训练对应训练指标单据，比赛对应比赛指标单据，新闻发布会对应采访单据。根据分析绘制如下时标对象：

(2) 参与方、地、物

这三类对象在四色建模中用绿色表示，我们以电商场景为例进行说明。用户支付购买商家的商品时，用户和商家是参与方。物流系统发货时配送单据需要有配送地址对象，地址对象就是地。订单需要商品对象，物流配送需要有货品，商品和货品就是物。

我们分析本例得到「参与方」包含总经理、队医、教练、球迷、记者，「地」包括训练地址、比赛地址、采访地址，「物」包含签名球衣和签名足球。

(3) 角色对象

在四色建模中用**表示，这类对象表示参与方、地、物是以什么角色参与到业务流程。

(4) 描述对象

增加对象相关描述信息，在四色建模法用蓝色表示。

23 划分领域

在四色建模过程中我们体会到时标对象是最重要的对象，因为其承载了业务系统核心单据。在划分领域时我们同样离不开时标对象，核心是通过收敛相关时标对象划分业务领域。

24 领域事件

当业务系统发生一件事情时，如果本领域或其它领域有后续动作跟进，那么我们把这件事情称为领域事件，这个事件需要被感知。

例如球员比赛受伤了，这是比赛子域事件，但是医疗和训练子域是需要感知的，那么比赛子域就发出一个事件，医疗和训练子域会订阅。

例如球员比赛取得进球，这也是比赛子域事件，但是训练和合同子域也会关注这个事件，那么比赛子域也会发出一个事件，训练和合同子域会订阅。

通过事件交互有一个问题需要注意，通过事件订阅实现业务只能采用最终一致性，需要放弃强一致性，这一点可能会引入新的复杂度需要权衡。

25 项目搭建

(1) API

接口层：提供面向外部接口声明和DTO对象

(2) controller

访问层：提供>

(3) service

业务层：领域层和业务层都包含业务，但是用途不同。业务层可以组合不同领域业务，并且可以增加流控、监控、日志、权限控制切面，相较于领域层更为丰富，提供BO对象

(4) domain

领域层：提供DMO（DomainObject）、VO、事件、数据访问对象，核心是按照领域进行分包，领域内高内聚，领域间低耦合

(5) dependency

外部访问层：在这个模块中调用外部RPC服务，解析返回码和返回数据

(6) infrastructure

基础层：包含基础功能，例如缓存工具，消息队列，分布式锁，消息发送等功能

我们展开分析领域层，核心是按照领域进行分包，并且提供DMO、VO、事件、数据访问对象，领域内高内聚，领域间低耦合，例如domain1对应合同子域，domain2对应训练子域。

26 详细设计

目前为止领域已经确定了，现在可以划分任务了，组内成员分别负责一个或多个领域进行详细设计，这个阶段就是大家熟悉的用例图，活动图，时序图，数据库设计，接口设计的用武之地。需要说明领域驱动设计不是取代详细设计，而是为了更清晰地详细设计。

3 文章总结

本文探讨了DDD落地时需要关注的六个问题，并通过一个足球运动员信息管理系统案例分析落地的六个步骤。在实际应用中各业务形态可能千差万别，但是方法论却可以通用，我们需要明确DDD核心是分而治之各个击破，并配合一些经过检验的有效方法进行建模，希望本文对大家有所帮助。

————————————————

版权声明：本文为CSDN博主「JAVA前线」的原创文章，遵循CC 40 BY-SA版权协议，转载请附上原文出处链接及本声明。

概念建模

数据建模大致分为三个阶段，概念建模阶段，逻辑建模阶段和物理建模阶段。其中概念建模和逻辑建模阶段与数据库厂商毫无关系，换言之，与MySQL，SQL Server，Oracle没有关系。物理建模阶段和数据库厂商存在很大的联系，因为不同厂商对同一功能的支持方式不同，如高可用性，读写分离，甚至是索引，分区等。

概念建模阶段

实际工作中，在概念建模阶段，主要做三件事：

1 客户交流

2 理解需求

3 形成实体

这也是一个迭代，如果先有需求，尽量去理解需求，明白当前项目或者软件需要完成什么，不明白或者不确定的地方和客户及时交流，和客户double confirm过的需求，落实到实体（Package）；但是好多时候我们需要通过先和客户交流，进而将交流结果落实到需求，之后进一步具体到实体；本文可能会涉及到一些来自于EA（Enterprise Architect 71）建模术语，（EA中将每个实体视为一个Package）。这里并不对各种建模工具进行比较，如Visio，EA，PowerDesigner， ERWin等；其实作为员工的我们选择性很少，公司有哪个产品的Licence，我们就用哪个吧。

举例说明：在一个B2C电子商务网站中，这样的需求再普通不过了：客户可以在该网站上自由进行购物！我们就以这个简单例子，对其进行细分，来讲解整个数据建模的过程，通过上面这句话，我们可以得出三个实体：客户，网站，商品；就像Scrum（敏捷开发框架的一种）中倡导的一样每个Sprint，都要产出确确实实的东西，OK，概念建模阶段，我们就要产出实体。客户和商品（我们将网站这个实体扔掉，不需要它。）

在创建这两个实体（Package）的时候，我们记得要讲对需求的理解，以及业务规则，作为Notes添加到Package中，这些信息将来会成为数据字典中非常重要的一部分，也就是所谓的元数据。BTW，EA或者其他建模工具应该都可以自动生成数据字典，只不过最终生成的格式可能不太一样。如在Customer这个Package的Notes上，我们可以这样写，用户都要通过填写个人基本信息以及一个邮箱来注册账户，之后使用这个邮箱作为登录帐号登录系统进行交易。

在概念建模阶段，我们只需要关注实体即可，不用关注任何实现细节。很多人都希望在这个阶段把具体表结构，索引，约束，甚至是存储过程都想好，没必要！！因为这些东西使我们在物理建模阶段需要考虑的东西，这个时候考虑还为时尚早。可能有的人在这个阶段担心会不会丢掉或者漏掉一些实体也不用担心，2013年好多公司都在采用Scrum的开发模式，只要你当前抽象出来的实体满足当前的User Story，或者当前的User Story里面的实体，你都抽象出来了，就可以了！如果你再说，我们User Story太大，实体太多，不容易抽象，那就真没办法了，建议你们的团队重新开Sprint 计划会议。

逻辑建模

逻辑建模阶段

对实体进行细化，细化成具体的表，同时丰富表结构。这个阶段的产物是，可以在数据库中生成的具体表及其他数据库对象（包括，主键，外键，属性列，索引，约束甚至是视图以及存储过程）。我在实际项目中，除了主外键之外，其他的数据库对象我都实在物理建模阶段建立，因为其他数据库对象更贴近于开发，需要结合开发一起进行。如约束，我们可以在web page上做JavaScript约束，也可以在业务逻辑层做，也可以在数据库中做，在哪里做，要结合实际需求，性能以及安全性而定。

针对Customer这个实体以及我们对需求的理解，我们可以得出以下几个表的结构，用户基本信息表（User），登录账户表（Account），评论表（Commnets,用户可能会对产品进行评价），当然这个案例中我们还会有更多的表，如用户需要自己上传头像（），我们要有Picture表。

针对产品实体，我们需要构建产品基本信息表（Product），通常情况下，我们产品会有自己的产品大类（ProductCategory）甚至产品小类（ProductSubCategory），某些产品会因为节假日等原因进行打折，因为为了得到更好的Performance我们会创建相应ProductDiscount表，一个产品会有多张，因此产品表（ProductPicture）以及产品关系表（ProductPictureRelationship），（当然我们也可以只设计一张Picture表，用来存放所有，用户，产品以及其他）有人说产品和是一对多的关系，不需要创建一个关系表啊是的，我认为只要不是一对一的关系，我都希望创建一个关系表来关联两个实体。这样带来的好处，一是可读性更好，实现了实体和表一一对应的关系，二是易于维护，我们只需要维护一个关系表即可，只有两列（ProductID和PictureID），而不是去维护一个Picture表。

客户进行交易，即要和商品发生关系，我们需要Transaction表，一个客户会买一个或者多个商品，因为一笔Transaction会涉及一个或多个Products，因此一个Transaction和ProductDiscount之间的关系（ProductDiscount和Product是一一对应的关系）需要创建，我们称其为Item表，里面保存TransactionID以及这笔涉及到的ProductDiscountID（s），这里插一句，好多系统都需要有审计功能，如某个产品历年来的打折情况以及与之对应的销售情况，我们这里暂不考虑审计方面的东西。

就这样，我们根据需求我们确定下来具体需要哪些表，进一步丰富每一个表属性（Column），当然这里面会涉及主键的选取，或者是使用代理键（Surrogate Key），外键的关联，约束的设置等细节，这里笔者认为只要能把每个实体属性（Column）落实下来就是很不错了，因为随着项目的开展，很多表的Column都会有相应的改动。至于其他细节，不同数据库厂商，具体实现细节不尽相同。关于主键的选取多说一句，有的人喜欢所有的表都用自增长ID作为主键，而有的人希望找到唯一能标识当前记录的一个属性或者多个属性作为主键；自增长ID作为代理主键，对于将来以多个类似当前Transaction System作为数据源，构建数据仓库的时候，这些自增长ID主键会是一个麻烦（多个系统中，相同表存在大量主键重复）；使用一个属性或多个属性作为作为主键，不管主键是可编辑的，读写效率是我们必须考虑得。所以并没有一个放之四海而皆准的原则，笔者只是给大家推荐一些考虑的因素。

物理建模

物理建模阶段

EA可以将在逻辑建模阶段创建的各种数据库对象生成为相应的SQL代码，运行来创建相应具体数据库对象（大多数建模工具都可以自动生成DDL SQL代码）。但是这个阶段我们不仅仅创建数据库对象，针对业务需求，我们也可能做如数据拆分（水平或垂直拆分），如B2B网站，我们可以将商家和一般用户放在同一张表中，但是针对PERFORMANCE考虑，我们可以将其分为两张表；随业务量的上升，Transaction表越来越大，整个系统越来越慢，这个时候我们可以考虑数据拆分，甚至是读写分离（即实现MASTER-SLAVE模式，MYSQL/SQLSERVER可以使用Replication，当然不同存储引擎采用不同的方案），这个阶段也会涉及到集群的事情，如果你是架构师或者数据建模师，这个时候你可以跟DBA说，Alright,I am done with it,now is your show time

相信大家都知道范式，更有好多人把3NF奉为经典，3NF确实很好，但是3NF是几十年前提出来的，那个时候的数据量以及访问频率和2012年完全不是一个数量级的；因此我们绝对不能一味地遵守3NF；在整个数据建模过程中，在保证数据结构清晰的前提下，尽量提高性能才是我们关注的要点，因此笔者大力倡导数据适当冗余!

上面笔者是结合一些实际例子表达自己对数据建模的观点，希望对读着有用。在数据建模过程中，不要希望一步到位将数据库设计完整，笔者不管是针对data warehouse还是Transactional Database设计，从来没有过一次成功的经历。随着项目的进行，客户和开发团队对业务知识与日增长，因此原来的设计也在不断完善中。毕竟，数据建模或者设计数据库不是我们的最终目的，我们需要的是一个健壮，性能优越，易扩展，易使用的软件!

（一）确定性建模

储层建模的主要目的是将储层结构和储层参数的变化在二维或三维空间用图形显示出来。一般而言，储层地质建模有以下四个主要步骤。

1数据准备和数据库的建立

储层建模一般需要以下四大类数据（库）。

（1）坐标数据。包括井位坐标、深度、地震测网坐标等。

（2）分层数据。各井的层组划分与对比数据、地震资料解释的层面数据等。

（3）断层数据。包括断层的位置、产状、断距等。

（4）储层数据。各井各层组砂体顶底界深度、孔隙度、渗透率、含油饱和度等。

2建立地层格架模型

地层格架模型是由坐标数据、分层数据和断层数据建立的叠合层面模型，即将各井的相同层组按等时对比连接起来，形成层面模型，然后利用断层数据，将断层与层面模型进行组合，建立地层的空间格架，并进行网格化。

3二维或三维空间赋值

利用井所提供的数据对地层格架的每个网格进行赋值，建立二维或三维储层数据体。

4图形处理与显示

对所建数据体进行图形变换，并以图形的形式显示出来。

（二）随机建模

随机建模的步骤与确定性建模有所差别，主要有以下五个步骤。

1建立原始数据库

任何储层模型的建立都是从数据库开始的，但与确定性建模数据库不同的是，用于随机建模的数据库分为两大类，第一类是原始数据库（与确定性建模相同），包括坐标、分层、断层和储层数据；第二类是随机模拟需要输入的统计特征数据。

2建立定性地质概念模型

根据原始数据库及其他基础地质资料，建立定性储层地质概念模型，如沉积相分布、砂体连续性、储层非均质性模型等，以用于选择模拟参数和指导随机模型的优选。

3确定模拟输入的统计特征参数

统计特征参数包括变异函数（岩性指标变异系数和岩石物性变异函数）特征值、概率密度函数特征值（砂岩面积或体积密度、岩石物性概率密度函数）、砂体宽厚比、长宽比等。

4随机模拟，建立一簇随机模型

应用合适的随机模拟方法进行随机建模，得出一簇随机模型。在建模过程中，可采用两步建模法，先建立离散的储层结构模型，然后在此基础上建立连续的储层参数分布模型。

5随机模型的优选

对于建立的一簇随机模型，应根据储层地质概念模型对其进行优选，选择一些接近实际地质情况的随机模型作为下一步油藏数值模拟的输入。

数据仓库数据建模的几种思路主要分为一下几种

1 星型模式

星形模式(Star Schema)是最常用的维度建模方式。星型模式是以事实表为中心，所有的维度表直接连接在事实表上，像星星一样。星形模式的维度建模由一个事实表和一组维表成，且具有以下特点：a 维表只和事实表关联，维表之间没有关联；b 每个维表主键为单列，且该主键放置在事实表中，作为两边连接的外键；c 以事实表为核心，维表围绕核心呈星形分布；

2 雪花模式

雪花模式(Snowflake Schema)是对星形模式的扩展。雪花模式的维度表可以拥有其他维度表的，虽然这种模型相比星型更规范一些，但是由于这种模型不太容易理解，维护成本比较高，而且性能方面需要关联多层维表，性能也比星型模型要低。所以一般不是很常用

雪花模式

3．星座模式

星座模式是星型模式延伸而来，星型模式是基于一张事实表的，而星座模式是基于多张事实表的，而且共享维度信息。前面介绍的两种维度建模方法都是多维表对应单事实表，但在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，绝大部分维度建模都采用的是星座模式。

星座模型

以上就是关于数据建模中比较常用的工具有哪些全部的内容，包括:数据建模中比较常用的工具有哪些、三维建模的基础数据与预处理、十张图讲清楚ddd建模六个问题与六个步骤等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！