导读：在应用层面讲，主数据（ Master Data ）是在多系统集成应用的背景下，被多个信息系统（或功能模块）共用的基础性标准化的数据，常见的主数据包括：供应商、客户、物料、人员、部门、项目等。
先看示例，在没有对主数据进行管理的情况下是这样的：
比如在费用控制系统中向供应商某公司支付货款，费控系统中该供应商的编码是PAYV000345，完成付款后，费控系统需要向ERP系统传递付款的会计凭证，但是，ERP系统中某公司的编码是ERP00000123，如果费控系统直接把PAYV000345传给ERP系统，ERP系统是不能识别的，那么就需要建立一种对照表，把PAYV000345翻译为ERP00000123才可以。
在这种情况下，费控系统和ERP系统都需要有管理员维护各自系统的供应商数据（维护两次），同时还得维护两个系统之间供应商数据的对照关系，应用成本比较高，很不方便。这还仅仅是两个系统之间的情况，如果系统更多，这种使用方式就太复杂了。
于是就有了如下的新办法：
在一种叫做主数据管理系统（MDM）的软件中，由该系统的管理员统一维护供应商数据（维护一次），并且统一编制唯一性的编码（如某公司的主数据编码是10002608），然后MDM再把这个供应商主数据推送给费控系统和ERP系统，这样所有系统中的某公司编码都是统一的10002608，系统之间不再需要做编码的翻译，直接使用即可，大大的简单化和标准化了供应商这类数据的应用。
现在可以引入主数据这个概念了，在应用层面讲，主数据（ Master Data ）是在多系统集成应用的背景下，被多个信息系统（或功能模块）共用的基础性标准化的数据，常见的主数据包括：供应商、客户、物料、人员、部门、项目等。
展开说明一下，首先，主数据，带个主字，英文是Master，字面就显示出这种数据的地位很高，非常的重要，为什么这么重要呢？因为如果这类数据没有管好，多个系统之间数据交换的成本就会非常大（需要各自维护，需要翻译，……），如果没有管好主数据，系统间交换的数据就会发生混乱并产生错误，严重影响系统的正常使用。
为更好的管理主数据，主数据管理系统（Master Data Management，即MDM）这类软件就出现了。
对常规的终端用户而言，MDM的核心功能主要有三个方面：
1、保障主数据的规范性和唯一性。按规则和流程规范管理主数据，比如规定主数据名称要使用营业执照上的名称，社会统一信用代码、国别地区等必填，按名称、信用代码等条件校验避免重复录入，系统自动按规则统一产生唯一性编码，主数据要经流程审核后方能生效等。
2、主数据的集中管理。主数据全部在MDM中产生或者受控（其他系统产生的主数据要符合MDM的规则才能进入MDM），在MDM系统中可以由专岗集中管理所有主数据，保障来源唯一从而避免歧义。
3、主数据的自动分发。提供分发和订阅功能，能够通过配置把主数据自动分发给相关系统，让多个系统可以方便的使用到统一规范的主数据；也可以自动的接收外部系统产生的主数据，经MDM管理后再自动分发出去，而不用数据源系统自己向多个系统分发。
除去以上功能外，MDM其实还有很多相关的专业性功能，比如：元数据、接口适配、数据交互监控、界面和流程定义、数据清洗等。这些都是系统建设和运维人员的工作内容。
在国内，一些综合性的信息化厂商很多都有自己的MDM产品，比如金蝶、用友、浪潮、汉得、英诺森等；也有把主数据相关领域作为核心业务的MDM专业性厂商；还有一些某类专业领域的厂商，比如项目管理信息化专业厂商易贝恩等。
这些厂商的MDM产品各有千秋，但核心功能基本一样，所以MDM基本是通用的，可用于各类系统集成的信息化项目。总的来说，MDM产品的可配置性越强越好，尽量减少代码开发，减少每个MDM项目的个性化，这样的MDM相对更稳定、更通用，上线时间更短，更易运维和扩展。同时，因为主数据的数据量往往很大，那么MDM对数据的处理性能也很关键，要能满足大规模数据量的处理要求。此外，MDM系统中内置的标准编码也是一个很大的价值点，比如已内置某行业的物料分类编码表（可能数万条数据），那么在实施该行业的主数据项目时就会更有力。
转自：百度安全验证
主数据（MD Master Data）指系统间共享数据（例如，客户、供应商、账户和组织部门相关数据）。与记录业务活动，波动较大的交易数据相比，主数据（也称基准数据）变化缓慢。在正规的关系数据模型中，交易记录（例如，订单行项）可通过关键字（例如，订单头或发票编号和产品代码）调出主数据。主数据必须存在并加以正确维护，才能保证交易系统的参照完整性。
高质量的主数据依赖于围绕主数据构建的流程、系统和管理要求，其对应的载体为主数据管理系统。
简介
主数据就是在计算机系统之间分享的数据。分享是关键词，经典的主数据的例子就是客户，我们都了解客户数据，我们都是别人的客户，但是我们必须要理解，客户是我们MDM的项目中心，同时我们要理解还有其它各种各样的主数据，比如说产品数据、地点、资产、员工等等，这些是相互联系的，因为客户买产品，你卖产品，客户买产品，可能有零售商，是从一个具体的零售店卖出商品，然后顾客来买商品，所以你管理的不仅仅是顾客的数据、产品的数据，还有地点的数据，以及其它相关的数据。
从报告或维度建模角度看，主数据指基于其组织或配置指标的维度或层次，而不是实际情况或其自身测量结果。例如，收入、成本和利润是实际情况，而时间、地点、客户和供应商是维度。
详细内容
应根据以下因素或更多因素综合考虑主数据：
企业绩效管理报告（如利润或收入计划随产品、客户、账户等产生的变化）要求综合多个系统的主数据。遵从报告要求一致性主数据。
同步交易系统处理特定客户（如提供具体报价）或供应商（如指定采购的首选供应商）。
主数据管理(MDM)的成熟度
根据主数据管理实施的复杂程度，参照Jill Dyche，Evan Levy的观点大体可以把主数据管理可以分为六个层次，从低到高反映了主数据管理(MDM)的不同成熟度。下面我们简单介绍一下这六个层次：
Level 0 ：没有实施任何主数据管理(MDM)
在Level 0的情况下，意味着企业的各个应用之间没有任何的数据共享，整个企业没有数据定义元素存在。比如，一个公司销售很多产品，对这些产品的生产和销售由多个独立的系统来处理，各个系统独立处理产品数据并拥有自己独立的产品列表，各个系统之间不共享产品数据。在Level 0，每个独立的应用负责管理和维护自己的关键数据(比如产品列表、客户信息等)，各个系统间不共享这些信息，这些数据是不连通的。
Level 1 ：提供列表
不管公司大还是小，列表管理是我们常用的一种方式。在公司内部，会通过手工的方式维护一个逻辑或物理的列表。当各个异构的系统和用户需要某些数据的时候，就可以索取该列表了。对于这个列表的维护，包括数据添加、删除、更新以及冲突处理，都是由各个部门的工作人员通过一系列的讨论和会议进行处理的。业务规则(Business Rules)是用来反映价值的一致性，当业务规则发生改变或者出现类似的情况时，这样高度手工管理的流程容易发生错误。由于列表管理是通过手工管理的，其列表维护的质量取决于谁参加了变更管理流程，一旦某人缺席，将会影响列表的维护。
Level 2 ：同等访问(通过接口的方式，各个系统与主数据主机之间直接互联)
MDM Level 2与MDM Level 1相比，引入了对主数据的(自动)管理。通过建立数据标准，定义对存储在中央知识库(Central Repository)中详细数据的访问和共享，为各个系统间共享使用数据提供了严密的支持。中央知识库(Central Repository)通常会被称为“主数据主机(Master Data Host)”。这个知识库可以是一个数据库或者一个应用系统，通过在线的方式支持数据的访问和共享。
创建、读取、更新和删除 (CRUD)是处理基本功能的典型编程术语。即便在MDM中，CRUD处理也是基本功能。你的数据库如果仅仅支持CRUD处理并不意味着你实现了MDM。 MDM Level 2引入了“同等访问”(peer-based access)，也就是说一个应用可以调用另一个应用来更新或刷新需要的数据。当CRUD处理规则定义完成后，MDM Level 2 需要客户或“同等”应用格式化请求(和数据)，以便和MDM知识库保持一致。MDM知识库提供集中的数据存储和供应(provisioning)。在这个阶段，规则管理、数据质量和变更管理必须在企业范围内作为附加功能定制构建。
Level 3 ：集中总线处理
与MDM Level 2相比，MDM Level 3打破了各个独立应用的组织边界，使用各个系统都能接受的数据标准统一建立和维护主数据(MDM Level 2的主数据主机上存储的数据还是按照各个系统分开存储的，没有真正的整合在一起)。
集中处理意味着为MDM构建了一个通用的、基于目标构建的平台。大多数公司发现MDM正在挑战他们现有的IT架构：他们拥有太多的独立平台处理主数据。 MDM Level 3 集中数据访问、控制跨不同应用和系统使用数据。这极大的降低了应用数据访问的复杂性，大大简化了面向数据规则的管理，使MDM比一个分散环境具有更多的功能和特点。企业主数据面临一致性的挑战。数据在不同的地方存在，数据所代表的含义也是不同的，数据的规则各个系统之间也是不一样的。集中MDM处理-通过一个公共的平台作为一个总线(HUB)-说明一个共识，从多个系统整合主题域数据，意味着使用集中、标准化的方法转换异构操作数据，不管其在源系统中是什么样子，都会被整合起来。在MDM Level 3，公司对主题域内容采用集中管理方式。这意味着应用系统，作为消费者或使用主数据，拥有一个共识就是数据是主题数据内容的映像，打破了各个独立应用的组织边界。MDM Level 3支持分布主参考数据的存在。
Level 4 ：业务规则和政策支持
一旦数据从多个数据源整合在一起，主题域视图超越单独的应用并表现为一个企业视图，你将获得事实的单一版本。当事实的单一版本已经能够提供出来时，来自业务主管和执行人员的必然反应经常是：“证明它”。MDM Level 4可以保证主数据反映一个公司业务规则和流程，并证实其正确性。MDM Level 4通过引入主数据来支持规则，并对MDM总线以及其它外部系统进行完整性检查。由于多数公司相对比较复杂，影响业务数据访问和操作的规则以及策略 (rules and policies)相对也比较复杂。假定任何一个单一系统可以包含并管理与主参考数据相关的各种类型的规则是不切实际的。因此，如果一个MDM总线真正打算提供企业范围内数据的精确性，工作流和流程整合的支持是必不可少的。
Level 5 ：企业数据集中
在MDM Level 5 ，总线和相关的主数据被集成到独立的应用中。主数据和应用数据之间没有明显的分隔。他们是一体的。当主数据记录详细资料被修改后，所有应用的相关数据元素都将被更新。这意味着所有的消费应用和源系统访问的是相同的数据实例。这本质上是一个闭环的MDM：所有的应用系统通过统一管理的主数据集成在一起。在这个级别，所有在系统看起来都是事实的同一个版本。操作应用系统和MDM内容是同步的，所以当变更发生时，操作应用系统都将更新。在那些熟悉的MDM架构风格中，持久总线架构，当一个总线更新所有的操作应用系统将体现这种变更，形成改变的直接操作视图。在注册环境中，当数据数据更新时，总线将通过Web服务连接相关系统应用事务更新。因此，MDM Level 5提供一个集成的，同步的架构，当一个有权限的系统更新一个数据值时，公司内所有的系统将反映这个变更。系统更新完数据值后不要单选其他系统中相应值的更新：MDM将使这种更新变的透明。
从MDM Level 4到MDM Level 5意味着MDM功能性不是在一个应用内被特殊设计或编码的。这还意味着主数据传播和供应不需要源系统专门的开发或支持。所有的应用清楚的知道他们并不拥有或控制主数据。他们仅仅使用数据来支持他们自己的功能和流程。由于MDM总线和支持的IT基础架构，所有的应用可以访问主参考数据。一个公司在完成MDM Level 5后将使他们所有的应用连在一起—既包括操作的也包括分析的—所有访问主数据是透明的。举例说明，当一个客户更新她的状态—不要管注册该变更的系统—数据变更将被广播到所有的应用平台(因此一致起来)。MDM Level 5是把数据概念作为一种service来实现。MDM Level 5保证了一个一致的主数据主题域企业映像。定义“客户”和其他应用接受客户主数据业务规则变化实际上是一回事。MDM Level 5移走了主数据的最后一个障碍：统一采用数据定义、授权使用和变更传播。
转自：百度百科-验证