在当前的智能生产和数字化管理时代，企业的发展变得多样化，仓库中的产品越来越多。如何帮助企业成功地从传统的仓库管理模式向数字化、智能化转变是一个非常重要的过程。然而，WMS仓库管理系统对于仓库管理的转型和数字化是不可或缺的。高度成熟的WMS仓储管理系统能够很好的满足大型企业的仓储管理需求，产品的灵活性和可配置性也为公司未来业务的拓展提供了便利。同时，该系统可以与公司内部的SAP/ERP、SRM系统、MES系统无缝集成，实现多个系统之间的数据同步共享，从而构建统一、规范、透明的管理体系。

一、企业部署数字云表WMS系统的好处

　　（1）精细化仓库管理

　　通过云表WMS企业对业务流程和运营场景中各个环节的实时管理和控制，可以实现多货主、多仓库、多商品、多条码、多批次的精细化管理。

　　（2）规则的灵活配置

　　它打破了手工记录和按固定规则管理每个仓库的局面。使用WMS后，出库流程、货架规则和提货规则可以高度灵活配置，充分适应企业业务模式的发展和不断优化，满足不同客户和不同业务的需求。

　　（3）集成智能设备

　　在现代企业的仓库管理中，各种智能仓库机器设备，如智能叉车、AGV小车、机械臂、仓储货架、RFID等。都是为了更好的操作而配备的。和射频操作一样，从收货上架到拣货复检，从发货交接到盘点都是无纸化操作。不仅节约了人力物力成本，还提高了仓库管理水平和运营效率。

　　（4）自动数据收集

　　在数据采集方面，实现了自动数据采集、智能分析和实时同步，无需人工重新操作，数据变得实时、准确。

　　（5）无代码开发

　　云表无代码开发平台，用户可以自己开发符合企业个性化的WMS软件，不需要代码，只要会画表格，普通的业务人员都能开发。

　　（6）智能报表查询

　　支持各类作业过程记载明细表和统计分析陈述的管理和查询功用，为决策和作业供给参考。

　　能够看出，经过数字WMS库房管理体系，能够改善库房管理中的痛点和难点问题，完成全方位的精细化和数字化管理，使库房运营更加通明高效，降低成本，帮助企业提升核心竞争力。

       在很多企业中，往往存在多个信息系统，如SAP/ERP、MES、TMS、SRM等。云表WMS仓库管理系统可以与这些系统对接，有很好的集成，实时同步数据，提高公司供应链的效率。完善的仓储管理不仅可以提高仓储资产的利用率，降低库存和库存管理成本，还可以缩短货物的交付时间，提高对客户的快速反应能力，提高公司的经营利润。仓库管理系统可以帮助企业实现这一点。

一、仓库管理概述

仓库管理系统（WMS）通过出库，入库、库位调拨、库存调拨等功能，综合批次管理，物料对应、库存盘点、质检管理和即时库存管理等功能综合运用的管理系统，有效控制和跟踪仓库业务的物流和成本管理的全过程，实现完善的企业仓储信息管理。
从业务上讲，仓库管理系统主要是出库，入库以及仓库内部管理，而WMS系统作为进销存体系的重要一环，需要与采购系统，财务系统，订单调度中心，库存中心等系统发生信息交互。

二，仓库管理模块设计

1 出库

当发货单推送至仓库，就进入仓库的任务处理队列中，经历调度，打单，拣货 ，复核，包装，交接发货等过程，最后交给物流公司。
a，调度：锁定拣货库位，生成拣货波次，（拣货波次的原则是选择几个锁定库位相邻，不超出拣货车存放量的仓库订单合并，可按照预设规则自动生成，也可人工筛选）
b，打单：将波次对应的物流单和发货单打印出来
c，拣货：关联拣货车，按波次拣货
d，复核：对拣货完成的订单进行核对，保证发货单、实物商品、物流单的统一。
e，包装：复核后对订单进行打包，称重，体积录入。
f，交接发货：打包后，根据物流单对应的快递公司，推至相应的交接区，扫描物流单号完成交接并发货。

2 入库

商品入库主要是根据采购单，退/换货入库单，调拨入库单等，入库单推送至仓库时，经历到货确认，验货打码，商品上架等环节最终完成入库。
到货确认：当仓库收到入库单时，相应的货物不会立马到仓库，而是会先进行到货确认，同时生成相应的验货任务，打印相应的入库验货单
验货打码：到货确认之后进入验货打码环节，验货员根据验货单上的任务验货，并反馈给系统合格和不良品的到货数量，（不良品退给供应商），到货数量小应到数量时，将剩余未到货任务再次返回到到货确认，等待下次到货，退货单将合格品和不合格品都录入到系统中，不良品会上架至不良品库区
验货完成后，通过系统打印相应数量的商品条码，由仓库人员进行贴码。
商品上架：不仅包括商品入库上架，还包括补货上架，移库上架，返库上架等情形，上架后更新库位库存信息

3 仓库内部管理

盘点：定期或临时对库存商品的实际数量进行清查，清点，对仓库现有商品的实际数量与保管账上记录的数量相核对，以便准确的掌握库存数量

a，根据业务需求选择相应的库位和商品创建盘点任务，盘点员根据盘点任务进行盘点
b，盘点后录入盘点数据
c，当盘点单中所有任务完成后，判断是否有盘盈或者盘亏。
d，无盘盈或盘亏，盘点结束，如果有，提交给主管审核，审核不通过，对库存不一致的库位商品重新生成盘点单，进行复盘；审核通过，提交给财务审核
e，财务审核通过后，生成盘盈，盘亏单，去更新仓库库存。

库位库区管理

仓库的库区主要分为分拣区，储存区，不良品存储区，发货暂存区，收货暂存区几块，需要给每个库区进行编码，在仓库中使用条形码对货品信息，批次，库位进行管理，提高各个环节的作业效率和信息化程度。

统计查询

统计查询模块主要是关于仓库的流水、库存、工作量等方面的统计并提供库存预警功能。包括出库明细，入库明细、库存变动明细、总库存查询、库位库存查询等。

什么是阿里onedata？

• 面对爆炸式增长的数据，如何建设高效的数据模型和体系，对这些数据进行有序和有结构地分类组织和存储，避免重复建设和数据不一致性，保证数据的规范性，一直是大数据系统建设不断追求的方向。

• 数据仓库模型实施过程：

1. 首先，在建设大数据数据仓库时，要进行充分的业务调研和需求分析。这是数据仓库建设的基石，业务调研和需求分析做得是否充分直接决定了数据仓库建设是否成功；
2. 其次，进行数据总体架构设计，主要根据数据域对数据进行划分；按照维度建模理论，构建总线矩阵、抽象出业务过程和维度；
3. 再次，对报表抽象整理出相关指标体系，使用 OneData 工具完成指标规范定义和模型设计；
4. 最后，代码研发和运维；

一、概述

• 阿里大数据建设方法论的核心：从业务架构设计到模型设计，从数据研发到数据服务，做到数据可管理化、可追溯、可规避重复建设；

1、定位及价值

• 建设统一的，规范的数据接入层（ODS）和数据中间层（DWD 和DWS），通过数据服务和数据产品，完成服务于阿里的大数据系统建设，即数据公共层建设。提供标准化的（Standard）、共享的（Shared）、数据服务（Service）能力，降低数据互通成本，释放计算、存储、人力等资源，以消除业务和技术之痛；

2、体系架构

• 

• 业务板块：根据业务属性，将业务划分出几个相对独立的板块，使业务板块之间的指标或业务重叠性较小 ；
• 规范定义：结合行业的数据仓库建设经验和阿里数据自身特点，设计出的一套数据规范命名体系，规范定义将会被用在模型设计中；
• 模型设计：以维度建模理论为基础，基于维度建模总线架构，构建一致性的维度和事实（进行规范定义），同时，在落地表模型时，基于阿里自身业务特点，设计一套规范命名体系；

二、规范定义

• 规范定义指以维度建模作为理论基础，构建总线矩阵，划分和定义数据域、业务过程、维度、定量/原子指标、修饰类型、修饰词、时间周期、派生指标。

• 

 1、名词术语

• 数据域：指面向业务分析，将业务过程或维度进行抽象的集合。

1. 将业务过程的一个个不可拆分的行为事件，如下单、支付等行为，进行分类，每一类行为事件的集合为一个数据域；
2. 数据域需要抽象提炼，并且长期维护和更新，但不能轻易变动；
3. 划分数据域时（即对行为事件分类），要既能涵盖当前所有的业务需求，又能在新业务进入时无影响地被包含进已有的数据域中和扩展新的数据域；

• 业务过程：指企业的业务活动事件，如下单、支付、退款都是业务过程；

1. 业务过程是一个不可拆分的行为事件，业务过程就是企业活动中的事件；

• 时间周期：用来明确数据统计的时间范围或时间点；（如最近30天、自然周、截止当日等）
• 修饰类型：对修饰词的抽象划分；（比如，修饰词花呗，它的修饰类型是支付方式）
• 修饰词：隶属于修饰类型，是指除了统计维度以外指标的业务场景的限定抽象；（如在修饰类型支付方式下：花呗、账户余额、余额宝、银行卡，都是修饰词）
• 度量 / 原子指标：度量和原子指标含义相同，对某一业务行为（或业务过程中的不可拆分的行为事件）的度量（如，花呗，花了多少钱，具体的金额数值就是度量）；

1. 度量 / 原子指标是业务定义中不可拆分的指标，具有明确业务含义的名词；

• 维度：是度量的环境，用来反映业务的一类属性（如，维度订单，是交易域下的一类属性），这类属性的集合构成一个维度，也可称为实体对象；

1. 维度属于一个数据域；
2. 例1：地理维度，其中包含国家、地区、城市、大山、河流等，所有实体的位置信息的集合，称为地理维度；
3. 例2：时间维度，其中包含年、季、月、周、日、时等；

• 维度属性：隶属于一个维度，如地理维度里面的国家名称、国家 ID、省份名称等，都属于维度属性；
• 派生指标：派生指标 = 一个原子指标 + 多个修饰词（可选）+ 时间周期；

1. 例：原子指标：支付金额，最近 1 天海外买家支付金额则为派生指标（最近 1 天为时间周期，海外为修饰词，买家作为维度，而不作为修饰词）

• 

2、指标体系

　1）基本原则

　 1/1 组成体系之间的关系

1. 派生指标有原子指标、时间周期修饰词、若干其他修饰词组合得到；（见图 9.3）
2. 原子指标、修饰类型及修饰词，直接归属在业务过程下，其中修饰词继承修饰类型的数据域；
3. 派生指标可以选择多个修饰词，修饰词之间的关系为“或”或者“且”，由具体的派生指标语义决定；
4. 派生指标唯一归属一个原子指标，继承原子指标的数据域，与修饰词的数据域无关；
5. 原子指标有确定的英文字段名、数据类型和算法说明；派生指标要继承原子指标的英文名、数据类型和算法要求；

• 

　 1/2 命名约定

1. 命名所用术语：指标命名，尽量使用英文简写，其次是英文，当指标英文名太长时，可考虑用汉语拼音首字母命名（如中国制造用 zgzz）。
2. 业务过程：英文名：用英文或英文的缩写或者中文拼音简写；中文名：具体业务过程中文即可；
3. 原子指标：英文名：动作 + 度量；中文名：动作 + 度量；原子指标必须挂靠在某个业务过程下；
4. 修饰词：只有时间周期才会有英文名，且长度为 2 位，加上 “-” 为 3 位（例 _1d ），其它修饰词无英文名；
5. 派生指标：英文名：原子指标英文名 + 时间周期修饰词（3 位）+ 序号（4 位，如 “_001”）；中文名：时间周期修饰词 + [ 其它修饰词 ] + 原子指标；

• 

　 1/3 算法

• 原子指标、修饰词、派生指标的算法说明必须让各种使用人员看得明白，包括：

1. 算法概述：算法对应的用户容易理解的阐述；
2. 举例：通过具体例子帮助理解指标算法；
3. SQL 算法说明：对于派生指标给出 SQL 的写法或者伪代码；

　2）操作细则

　 2/1 派生指标的种类

• 派生指标可以分为三类：事务型指标、存量型指标、复合型指标；（按照特性不同，有些需要新建原子指标，有些可以在其他类型原子指标的基础上增加修饰词形成派生指标）

1. 事务型指标：是指对业务活动进行衡量的指标；（例：新发商品数、重发商品数、新增注册会员数，这类指标需要维护原子指标及修饰词，在此基础上创建派生指标）
2. 存量型指标：是指对实体对象（如商品、会员）某些状态的统计；（例：商品总数、注册会员总数，这类指标需要维护原子指标及修饰词，在此基础上创建派生指标，对应的事件周期一般为 “历史载至当前某个时间”）
3. 复合型指标：是在事务型指标和复合型指标的基础上复合而成的；（例：浏览 UV - 下单买家数转化率，有些需要创建新原子指标，有些则可以在事务型或存量型原子指标的基础上增加修饰词得到派生指标）

　 2/2 复合型指标的规则

• 比率型：创建原子指标，如 CTR、浏览 UV - 下单买家数转化率、满意率等；

1. 例：“最近 1 天店铺首页 CTR（点击率）”，原子指标为 “CTR”，时间周期为 “最近 1 天”，修饰类型为 “页面类型”，修饰词为 “店铺首页”；

• 比例型：创建原子指标，如百分比、占比；

1. 例：“最近 1 天无线支付金额占比”，原子指标为 “支付金额占比”，修饰类型为 “终端类型”，修饰词为 “无线”；

• 变化量型：不创建原子指标，增加修饰词，在此基础上创建派生指标；

1. 例：“最近 1 天订单支付金额上 1 天变化量”，原子指标为 “订单支付金额”，时间周期为 “最近 1 天”，修饰类型为 “统计方法”，修饰词为 “上 1 天变化量”；

• 变化率型：创建原子指标；

1. 例：“最近 7 天海外买家支付金额上 7 天变化率”，原子指标为 “支付金额变化率”，修饰类型为 “买家地域”（因为此需求中重点强调“海外买家”），时间周期为 “最近 7 天”，修饰词为 “海外买家”；

• 统计型（均值、分位数）：不需要创建原子指标，增加修饰词，在此基础上创建派生指标；

1. 在修饰类型 “统计方法” 下增加修饰词，如人均、日均、行业平均、商品平均、90 分位数、70分位数等；
2. 例：“自然月日均 UV（访问量）”，原子指标为 “UV”，修饰类型为 “统计方法”，修饰词为 “日均”；

• 排名型：创建原子指标，一般为 top_xxx_xxx ，有时会同时选择 rank 和 top_xxx_xxx 组合使用；创建派生指标时选择对应的修饰词如下：

1. 统计方法（如降序、升序）
2. 排名名次（如 TOP10）
3. 排名范围（如行业、省份、一级来源等）
4. 根据什么排序（如搜索次数、PV）

5. 

• 对象集合型：主要指数据产品和应用需要展现数据时，将一些对象以 k-v 对的方式存储在一个字段中，方便前端展现。比如趋势图、TOP 排名对象等。其定义方式是，创建原子指标，一般为 xxx 串；创建派生指标时选择对应的修饰词如下：

1. 统计方法（如降序、升序）
2. 排名名次（如 TOP10）
3. 排名范围（如行业、区域）

4. 

　3）其他规则

• 上下层级同时存在时：如最近 1 天支付金额和最近 1 天 PC 端支付金额，建议使用前者，把 PC 端最为维度属性存放在物理表中体现；
• 父子关系原子指标存在时：派生指标使用子原子指标创建派生指标；（如 PV、IPV（商品详情页 PV），当统计商品详情页 PV 时，优先选择子原子指标）

三、模型设计

1、知道理论

• 数据模型的维度设计主要以维度建模理论为基础，基于维度数据模型总线架构，构建一致性的维度和事实；

2、模型层次

• 主要分三层：操作数据层（ODS）、公共维度数据层（CDM）、应用数据层（ADS）；

• 

• 其中 CDM 数据层包括明细数据层（DWD）和汇总数据层（DWS）；

• 操作数据层（ODS）：把操作系统数据几乎无处理的存放子数据仓库系统中；

1. 同步：结构化数据增量或全量同步到 MaxCompute；
2. 结构化：非结构化（日志）结构化处理并存储到 MaxCompute ；
3. 累积历史、清洗：根据数据业务需求及稽核和审计要求保存历史数据、清洗数据；

• 公共维度模型层（CDM）：存放明细事实数据、维表数据及公共指标汇总数据，其中明细事实数据、维表数据一般根据 ODS 层数据架构生成；公共指标汇总数据一般根据维表数据和明细事实数据加工生成；
• CDM 层又细分为 DWD 层和 DWS 层，分别是明细数据层和汇总数据层，采用维度模型方法作为理论基础，采用一些维度退化手法，将维度退化至事实表中，减少事实表和维表的关联，提高明细数据表的易用性；同时在汇总数据层，加强指标的维度退化，采取更多的宽表化手段构建公共指标数据层，提升公共指标的复用性，减少重复加工；

• 主要功能：

1. 组合相关和相似数据：采用明细宽表，复用关联计算，减少数据扫描；
2. 公共指标统一加工：基于 OneData 体系构建命名规则、口径一致和算法统一的统计指标，为上层数据产品、应用和服务提供公共指标；建立逻辑汇总宽表；
3. 建立一致性维度：建立一致的数据分析维表，简单数据计算口径、算法不统一的风险；

• 应用数据层（ADS）：存放数据产品个性化的统计指标数据，根据 CDM 层与 ODS 层加工；

1. 个性指标加工：不公用性、复杂性（指数型、比值型、排名型指标）；
2. 基于应用的数据组装：大宽表集市、横表转纵表、趋势指标串；

• 

• 数据调用服务优先使用公共维度模型层（CDM）数据，当公共层没有数据时，需评估是否需要创建公共层数据，当不需要建设公用的公共层时，方可直接使用操作数据层（ODS）数据；
• 应用数据层（ADS）作为产品特有的个性化数据一般不对外提供数据服务，但是 ADS 作为被服务方也需要遵守上述（条件 1）约定；

3、基本原则

1. 高内聚和低耦合：将业务相近或者相关、粒度相同的数据设计为一个逻辑或者物理模型；将高概率同时访问的数据放一起，将低概率同时访问的数据分开存储；
2. 核心模型与扩展模型分离：核心模型包括的字段支持常用的核心业务，扩展型包括的字段支持个性化或少了应用的需要，不能让扩展模型的字段过多侵入核心模型，以免破坏核心模型的架构简洁性与可维护性；
3. 公共处理逻辑下沉及单一：越是底层公用的处理逻辑越应该在数据调度依赖的底层进行封装与实现，不要让公用的处理逻辑暴露给应用层实现，不要让公共逻辑多处同时存在；
4. 成本与性能平衡：适当的数据冗余可以换钱查询和刷新性能，不宜过度冗余与数据复制；
5. 数据可回滚：处理逻辑不变，在不同时间多次运行数据结果确定不变；
6. 一致性：具有相同含义的字段在不同表中的命名必须相同，必须使用规范定义中的名称；
7. 命名清晰、可理解：表名需易于消费者理解和使用；

四、模型实施

• 如何从具体的需求或项目转换为可实施的解决方案，如何进行需求分析、架构设计、详细模型设计等，则是模型实施过程中讨论的内容；

1、业界常用的模型实施过程

　1/1）Kimball 模型实施过程

• Kimball 维度建模主要讨论需求分析、高层模型、详细模型和模型审查整个过程；
• 构建维度模型主要经历 4 个阶段：

　　1/1/1）高层模型设计

• 定义业务过程维度模型的范围，提供每种星形模式的技术和功能描述；
• 产出目标：创建高层维度模型图，是对业务过程中的维表和事实表的图形描述；
• 确定维表创建初始属性列表，为每个事实表的创建提议度量；

　　1/1/2）详细模型设计

• 对每个星形模型添加属性和度量信息；
• 详细的维度建模过程是为高层模型填补缺失的信息，解决设计问题，并不断测试模型能否满足业务需求，确保模型的完备性；
• 确定每个维表的属性和每个事实表的度量，并确定信息来源的位置、定义，确定属性和度量如何填入模型的初步业务规则；

　　1/1/3）模型审查、再设计和验证

• 主要召集相关人员进行模型的审查和验证，根据审查结果对详细维度进行再设计；

　　1/1/4）提交 ETL 设计和开发

• 完成模型详细设计文档，提交给 ETL 开发人员，进入 ETL 设计和开发阶段，由 ETL 人员完成物理模型的设计和开发；

　1/2）Inmon 模型实施过程

• Inmon 对数据模型的定位：扮演着通往数据仓库其他部分的智能路线图的角色；（建立一个路线图——数据模型，描述数据仓库各部分是如何结合在一起的）

• Inmon 将模型分为 3 个层次：ERD（Entity Relationship Diagram，实体关系图）层、DIS（Data Item Set，数据项集）层、物理层（Physical Model，物理模型）；

• ERD 层是数据模型的最高层，描述公司业务中的实体或主题域以及他们之间的关系；

• DIS 层是数据模型的中间层，描述数据模型的关键字、属性以及细节数据之间的关系；

• 物理层是数据模型的最底层，描述数据模型的物理特性；

• Inmon 对于构建数据仓库模型建议采用螺旋式开发方法，采用迭代方式完成多次需求；但需要采用统一的 ERD 模型，才能够将每次迭代的结果整合在一起；

• ERD 模型是高度抽象的数据模型，描述企业完整的数据，而每次迭代则是完成 ERD 模型的子集，通过 DIS 和物理数据模型实现；

　1/3）其他模型实施过程

1. 业务建模，生成业务模型，主要解决业务层面的分解和程序化；
2. 领域建模，生成领域模型，主要是对业务模型进行抽象处理，生成领域概念模型；
3. 逻辑建模，生成逻辑模型，主要将领域模型的概念实体以及实体之间的关系进行数据库层次的逻辑化；
4. 物理建模，生成物理模型，主要解决逻辑模型针对不同关系数据库的物理化以及性能等一些具体的技术问题；

2、OneData 实施过程

 　2/1）指导方针

• 首先，在建设大数据数据仓库时，要进行充分的业务调研和需求分析。这是数据仓库建设的基石，业务调研和需求分析做得是否充分直接决定了数据仓库建设是否成功；
• 其次，进行数据总体架构设计，主要根据数据域对数据进行划分；按照维度建模理论，构建总线矩阵、抽象出业务过程和维度；
• 再次，对报表抽象整理出相关指标体系，使用 OneData 工具完成指标规范定义和模型设计；
• 最后，代码研发和运维；

　2/2）实施工作流

• 

　　2/2/1）数据调研

• 业务调研

1. 不但只了解具体的需求，还要明白需求的数据在业务中的意义，帮助我们更好的建仓建模，特别是在划分数据域时；
2. 了解各个业务领域、业务线的业务有什么共同点和不同点，以及各个业务线可以细分为那几个业务模块，每个业务模块具体的业务流程有事怎样的；
3. 一般各个业务领域独自建设数据仓库，业务领域内的业务线由于业务相似、业务相关性较大，进行统一集中建设；

• 例：

  

• 需求调研

1. 收集数据使用者的需求；（可以找分析师、业务运营人员了解他们有什么数据诉求，一般更多的就是报表需求）
2. 需求调研的两种途径：一是与分析师、业务运营人员的沟通（邮件、IM）获知需求；二是对报表系统中现有的报表进行研究分析；（很多时候，都是由具体的数据需求驱动数据仓库团队去了解业务系统的业务数据）

• 例：分析师需要了解大淘宝（淘宝、天猫、天猫国际）一级类目的成交金额

• 获知需求后，需要考虑的问题：

1. 根据什么（维度）汇总，汇总什么（度量 / 原子指标）？（这里类目是维度，金额是度量）
2. 明细数据和汇总数据应该怎么设计？
3. 这是一个公用的报表吗？
4. 是需要沉淀到汇总表里面，还是在报表工具中进行汇总？

 　　2/2/2）架构设计

•  数据域划分（将各个业务行为分类）

• 数据域：指面向业务分析，将业务过程或者维度进行抽象的集合；
• 业务过程可以概括为一个个不可拆分的行为事件，如下单、支付、退款；
• 为保障整个体系的生命力，数据域需要抽象提炼，并且长期维护和更新，但不轻易变动；

• 划分数据域原则：既能涵盖当前所有的业务需求，又能在新业务进入时无影响地被包含进已有的数据域中，或者扩展新的数据域；

• 例（将业务行为分类划分数据域）：

• 

• 

• 构建总线矩阵

•  明确每个数据域下有哪些业务过程；
• 业务过程与哪些维度相关，并定义每个数据域下的业务过程和维度；
• 例（构建采购分销数据域的总线矩阵）：

• 

 　2/3）规范定义

• 主要定义指标体系，包括原子指标、修饰词、时间周期、派生指标；

　2/4）模型设计

• 主要包括维度及属性的规范定义，维表、明细事实表、汇总事实表的模型设计；

　2/5）总结

• OneData 的实施过程是一个高度迭代和动态的过程，一般采用螺旋式实施方法；
• 在总体架构设计完成后，开始根据数据域进行迭代式模型设计和评审；
• 在架构设计、规范定义、模型设计等模型实施过程中，都会引入评审机制，以确保模型实施过程的正确性；