级别： 中级 David Borean, MDM Server 架构师, IBM
Martin Oberhofer, MDM 高级技术顾问, IBM
Dr. Thomas Schwarz, MDM 高级技术顾问, IBM
2009 年 9 月 07 日 IBM® InfoSphere™ Master Data Management Server (MDM Server) Product Domain（MDM Server 8.0 中引入）能够管理产品主数据的操作视图。它还为企业提供了惟一版本的产品数据源。在本文中，了解特定于 Product Domain 的特性，包括产品类型层次结构、产品架构、产品关系、产品分类、条款和条件以及本地化。MDM Server 8.0 还新增了一些称为 “specs” 的新扩展机制，这是实现灵活的产品数据管理的关键特性。本文介绍了 specs 特性并提供它的使用指导。
简介
本文是包含三部分的系列文章的第一篇，从功能方面概述了 IBM InfoSphere Master Data Management Server (InfoSphere MDM Server) 针对 Product Domain 的各种特性，逐一介绍了定义产品模型的功能，然后探究了根据产品模型管理产品的功能。
熟悉 MDM Server 的 Party Domain（即以前的 WebSphere Customer Center）的人会从中发现一些相似之处和模式，也会找到一些关键的差异，这些差异主要体现在企业的产品主数据管理方面。
本文主要关注特定于 Product Domain 的特性。本文并没有解释其他领域的特性，也没有介绍 MDM Server 底层平台的多种特性。一些平台特性包括安全性、事务审计、扩展机制、通知机制、业务规则实施等等。本系列的后续文章将更加深入并提供实现示例。第二篇文章描述了一个完整的代码样例，它通过创建 “硬产品类型（hard product type）” 在 MDM Server 中使用传统扩展机制对 Product Domain 进行扩展。第三篇文章通过创建 “软产品类型（soft product type）” 使用新的 specs 特性对 Product Domain 进行扩展。
MDM Server 初探
MDM Server 使公司能够管理和维护企业主数据的完整、精确的视图，从而帮助公司获得对业务信息的控制。通过将多个数据域集中在一起并提供全面的预构建业务服务，支持全方位的主数据管理（MDM）功能，MDM Server 使公司能够从主数据获取最大的价值。
MDM Server 维护来自多个领域的主数据，包括合作伙伴、客户和产品。MDM Server 使用业务服务将来自不同领域的数据集成在一起，这些业务服务与使用主数据的所有应用程序和业务流程相交互。
MDM Server 在管理合作伙伴和客户主数据方面非常有名，并且涉及业务驱动因素，比如更好的客户服务，以及洞察力和技术驱动因素，比如降低运营成本。同样，管理产品主数据有助于实现遵从性或满足法规需求，找出交叉销售和向上销售机会，并提供不仅不局限于单一业务线，反而跨越多个业务线的真正的产品包。一致的产品主数据还改善了收入报告并简化了与供应商和经销商的交易。
MDM Server 为企业提供了产品主数据的操作视图。相比之下，IBM InfoSphere Master Data Management Server for Product Information Management（InfoSphere MDM Server for PIM 以前称为 WebSphere Product Center）提供了协作创建产品主数据的功能。在一个简单的视图中，产品在 MDM Server for PIM 中创建，然后在 MDM Server 中进行操作。
MDM Server Product Domain 特性
不同行业以及同一行业中的产品组成有很大的差异。在金融服务中，信贷措施不同于储蓄产品。在电信行业，手机服务不同于互联网服务。而在零售业，音响设备不同于等离子电视。
为了应对这种多样性（比如，音乐产品 包含艺术家名称 和发行日期 等元素），Product Domain 使您能够定义需要管理的产品及其元素的类型。这些特性在 “定义产品模型” 小节进行了描述。
定义好产品模型后（比如名为 The Beatles – White Album 的光盘，艺术家名称为 The Beatles，发行日期为 1968），您就可以创建并管理产品（产品类型的实例）。“创建产品” 一节将描述与此相关的特性。
定义产品模型
要在 Product Domain 中创建产品，首先需要以产品层次结构的形式定义产品的类型，并为每一种类型定义它们的元素。还必须确定可能的产品架构，比如是独立 产品还是打包 产品。这些特性将在以下小节中描述。
定义产品类型层次结构
产品类型层次结构定义了您希望对之进行管理的产品的类型。MDM Server 提供了现成的产品类型层次结构，如 图 1 所示：
图 1. 产品类型层次结构
这种产品类型层次结构使用元数据结构进行定义，并具有一组相关数据库表和业务服务。您将进一步扩展它来细分将要进行管理的产品的类型。例如，银行可能会将金融产品 细分为储蓄产品。然后再细分为取款、存款 和定期存款。类似地，网上零售商可能会细分 GoodsProduct，如 图 2 所示：
图 2. 扩展后的产品类型层次结构的样例
在层次结构中创建新类型时，可以选择将类型声明为硬类型或软类型。
硬类型表示可以使用一个相关的数据库表和服务集合管理该类型。例如，AddMusicProduct 是一个将数据写入到 musicproduct 数据库表的服务。musicproduct 表可以包含 artist name 和 release date 等列。
另一方面，软类型表示不存在相关的数据库表和相关服务。例如，如果音乐作品的类型为软类型的话，那么现有的 AddGoodsProduct 服务将被用于添加一个音乐作品。
定义产品类型的元素
定义了产品类型层次结构后，可以继续定义希望为层次结构中的每个类型捕捉的数据。有很多种可立即使用的产品元素，比如关系、标识符、类别层次结构和条件，并且它们与底层模型的根产品类型相关联，因此可应用到所有产品类型。但是您可能希望添加模型以外的额外元素。比如，对于音乐作品，可能希望捕获艺术家名称 和发行日期 等元素。可以通过两种方法实现这一点。第一种是使用众所周知的 MDM Server 数据扩展机制，这将修改物理数据模型。第二种方法是使用名为 specification 的新扩展机制，这种方法不需要您实际修改数据模型。这两种方式都为 MDM Server 升级提供了完整的向后兼容性。
使用传统的数据扩展机制
MDM Workbench 可用于创建数据扩展。要表示现成的产品类型层次结构的现有产品表，可以使用附加的元素进行扩展。
类似地，如果必要的话，添加到产品类型层次结构的任何新产品类型都可以添加到一个具有相关服务集合的模型中。这些产品类型被描述为硬类型，因为它们被 固定在模型中。开发人员指南中描述了创建硬类型的步骤，并且本系列的第二篇文章描述了使用 MDM 工作台实现这一过程的步骤。例如，如果 Music Product 类型被声明为硬类型，那么将创建一个 musicproduct 数据库表，并且可以定义 artist name 和 release date 元素作为列。Music Product 产品的实例可以通过 AddMusicProduct 等专用服务访问。
未被声明为硬类型的产品类型可以声明为软类型，并且没有相关的数据库表和服务来管理特定于这些类型的元素。相反，它使用了面向现有产品类型的 specification 机制和现有服务。
使用新的 specification 机制
当不需要通过创建物理表在数据库中固定产品类型时（和使用传统数据扩展机制时所做的操作一样），为了解决不同产品类型的变化问题，引入了一种新的扩展机制。这一机制被称为 specifications（或 specs）。
spec 由各种不同结构组成，但是其核心为一个 XML 模式。因此，specs 可以通过使用 XML 模式并随后以 XML 形式管理某些产品数据元素来扩展数据模型。
spec 可在 MDM Workbench 中创建，然后部署到运行中的 MDM Server 实例中，部署工具将使用管理服务管理 spec 数据。spec 随后可被关联到产品类型（硬类型或软类型），如果需要的话，还可关联到其子类型。这将定义特定于产品类型的元素，并且在创建该类型的产品时提供这些元素的值。图 3 展示了这一模型的一个简单视图：
图 3. Specification 概览
图 4 使用音乐作品的类型扩展了产品类型层次结构示例，并在模型中引入 spec。它展示了关联到硬类型和软类型的 specification。此外，对于 LogisticsSpecs specification，图 4 展示了 spec 如何沿着产品类型层次结构实现关联。
图 4. 关联到硬类型和软类型的 Specification
有一些特定的因素促使您决定使用传统数据扩展方法在物理数据模型中固定元素，而不是使用新的 spec 机制。表 1 给出了一些值得考虑的问题，并根据简单的 yes 或 no 的回答帮助您决定采取何种方法。（表 1 之后的小节详细介绍了这些问题）。为了最终确定最佳方案，您将必须权衡所有问题的答案，以及特定于您的实现的问题的答案。
表 1. 采用硬类型和软类型的影响因素
扩展是否随时间演变？
如果产品类型（或扩展）是动态或经常变化的，并且可能随时间变化，那么 specs 是最佳选择。Specs 包含一个或多个版本（或格式）。产品价值取决于 spec 的版本。因此，您可以使用新的元素和约束来使 spec 发生演变，而不会对产品数据产生影响或实施迁移。
另一方面，如果产品元素是非常静态的并且生命周期很长（比如 Party Domain 中的元素），那么考虑使用传统的扩展机制并固定这些元素。这样做会带来一些好处，比如良好的服务接口，它在集成中间件和表示逻辑中可能更容易使用。
是否定期引入新的产品类型？
如果由于不断地引入新的产品类型而经常要扩展产品类型层次结构（取决于分阶段的 MDM 实现或业务需要），那么考虑使用 spec。Spec 可以帮助最小化引入新产品类型的时间，因为不需要对数据模型或应用程序做任何修改就可支持新的类型及其元素。然而，如果涉及与新类型有关的特定业务逻辑，那么可能需要做一些开发工作。
如果产品类型层次结构是比较静态的，包括类型元素，那么考虑固定这些类型。
产品数据是否应用多种语言？
Product Domain 的特性之一就是能够以多种语言管理数据。该特性在固定数据和 spec 基础设施中都受支持。如果需要使用对语言敏感的元素扩展模型，那么使用 spec 是一种更简单的解决方案，因为它提供了内置的功能来管理和查询使用多种语言的数据。
使用传统的扩展机制也是可行的，但是所需的工作量更多一些。比如，引入一个新的实体会导致产生两个一对多关系的新实体，如 图 5 所示：
图 5. 对于硬类型使用 NLS 支持
在本例中，PRODUCTNLS 持有对语言敏感的元素，并使用一个语言 id 作为关键字段。
是否使用 DB2 8 在 z/OS 上搜索数据？
简单地说，搜索 XML 数据（spec 值）在 MDM Server 8.5 中并没有得到完全的支持。然而，这里提供的样例支持使用 DB2 9.x 在 AIX® 上搜索 XML 数据。
以此样例为基础，可以扩展 MDM Server 来搜索 XML 数据，前提是所使用的数据库的版本支持 XML 类型。然而，如果这样做不可取或者数据库的版本不支持 XML 类型，那么可能需要对将要对之进行搜索的元素使用传统扩展机制。比如，XML 数据在 z/OS® 上的 DB2 8 中以 CLOB 的形式保存。
产品类型层次结构是否分为很多层？
在查询具有叶产品类型的产品时，如果产品层次结构很深，例如 7 层或更多层，并且对此层次结构中的所有产品应用了硬类型，那么将产生一个跨越 7 个或更多表的复杂表连接。这是因为层次结构中的每个硬类型将在一个独立表中存储该类型引入的新属性。如果更深的层次结构中的某些类型是软类型并且没有在模型中固定，那么将减少被访问的表的数量，记住需要访问一个小的表结构来从中获取 spec 的值。
如果产品类型层次结构相对简单（只有 3 或 4 层），那么数据库访问就会简单一些。
是否所有数据消费者都能接受 XML？
如果 MDM Server 的消费者对 RMI 和消息传递接口使用 Web 服务接口或使用 XML 格式，那么 XML 格式的 Spec 值将很好地适应服务请求和响应。
然而，如果消费者使用不同的接口和非 XML 格式（例如，使用分隔的或 COBOL copybook 解析器），那么 spec 值就不能很好地配合，因为在非 XML 消息中会出现 XML 片段。在这种情况下，硬产品类型更可取。固定产品类型提供了一个良好的服务接口，易于在集成中间件和表示逻辑中使用。
可以考虑插入一个新的解析器/构造器来将 XML 格式的 spec 值转换为理想的格式，但这样做将抵消使用 spec 的一些好处，比如缩短开发时间。同样，并非所有第三方工具（比如报告工具）都提供数据库 XML 的支持。如果在 MDM 实现中使用这些工具，那么就会预先排除使用 spec 的可能性。
扩展的结构是否很复杂？
在定义产品类型的元素时，这些元素可能会分解为多个对象。这意味着固定类型时将用到多个数据库表。例如，如果希望为 CD 产品获得一个曲目清单，那么从 CDPRODUCT 表到 TRACK 表之间会映射一个一对多关系。
在 spec 中能够为元素定义一个复杂的层次结构，因为 spec 的核心是一个 XML 模式。这种方法可以使数据模型更加简单，并且避免了在查询产品时连接多个表的需要。
是否在其他特性中使用 specs？
Spec 在 MDM Server 的其他特性中都得到了使用（例如合作伙伴统计、合同属性和产品类别属性）。产品类别属性特性使产品能够继承放入某个类别的额外 spec。该特性将在 “产品类别层次结构” 一节中进一步介绍。
本节的重点是您在考虑 spec 时需要统观整个解决方案。如果 spec 在 MDM Server 的其他位置得到了采用，那么可以更轻松地添加产品类型。另一方面，必须考虑在 spec 中定义的元素是否更适合在其他位置管理，例如产品关系、条款和条件以及 “创建自己的产品” 小节描述的其他特性。
定义产品的结构
产品具有一定的结构。结构类型从数据的角度来看只是一个代码表值。然而，可以在扩展产品时加以利用，比如创建符合服务、添加额外的功能。MDM Server 为代码表中的一组结构提供了一个起点，在此基础上可以进一步扩展。提供的结构包括：
-
独立产品：示例产品包括一个 No Fee Checking 产品、一个 High Speed Broadband Internet 服务和一个 No Frills MP3 Player 产品。
-
产品包：产品包本身就是一种产品（使用根产品类型）。一个示例包就是 Student Banking Package，它捆绑了一个 No Fee Checking 产品、Regular Savings 产品和一个 Standard Credit Card 产品，可能附带一个条件，即信用卡使用较低的利率。与实际组件产品的关联通过产品关系特性确立（参见 “产品关系” 小节获得该特性的更多细节）。
可以定义额外的结构，比如：
-
产品模板：这种产品可以作为创建新产品的模板或起点。
-
产品变体：这是一种基于另一种产品但具备一些不同特性的产品。一个例子就是具有 红色、绿色 和 蓝色 等不同颜色的 MP3 播放器。
-
产品组件：这是一种作为构建其他产品的组件的产品。一个例子就是汽车保险产品，该产品包括物理性损害 和债务 组件。
创建自己的产品
定义了产品类型层次结构及每个产品类型的元素后，就可以创建产品了。在创建产品时可以利用大量特性，本节将对此进行介绍。这些特性包括：
这些特性都被视为功能性特性。MDM Server 平台的其他特性也可以用于 Product Domain。然而，本文并未对此进行讨论。
产品标识符
MDM Server 管理两种形式的产品标识符。第一种形式是业务标识符，用于描述和搜索产品。第二种形式是系统标识符，用于记录其他存储产品的应用程序中使用的主键。
业务标识符将惟一地（或相对惟一地）标识产品。您将能够定义需要为产品捕捉的标识符的类型。业务标识符的例子包括产品代码，例如 Global Trade Identification Number (GTIN)，股票代号 和条形码编号。这些标识符可用于完整地描述产品，并且通常用做查找产品的重要搜索条件。如果标识符对于产品是相对惟一的，那么将有助于实现非常有效的产品搜索。
系统标识符在其他系统中惟一地标识产品。这被称为产品等值（product equivalency）特性。即使产品是在 MDM Server 中管理，它仍然有可能存在于企业中的某些位置，而这一特性能够追溯 MDM Server 上的产品，以及企业其他系统中与之等值的产品。例如，某个产品存储于名为 Account Management System (AMS) 的遗留数据库中，其主键为 383732XX，那么 MDM Server 中产品代码为 47118888 的产品将具有一个产品等同关系，表示该产品也存在于 AMS 中并且主键为 383732XX。在处理 MDM Server 上的产品时，产品等值将用作识别键。
产品关系
由于各种原因，某个产品会关联到其他产品。MDM Server 允许您管理这些关系，不管是简单的关系还是会影响产品结构的复杂关系。
简单关系的例子包括：
- 从 No Fee Checking 产品到 Regular Savings 产品的交叉销售。
- 从 Dial Up Internet 服务到 Broadband Internet 服务的向上销售。
会影响产品组成结构的复杂关系包括：
- 变体关系，表示红色、蓝色 和绿色 的 No Frills MP3 Player 都属于 Base No Frills MP3 Player 的变体。
- 组件关系，表示 Email 服务是 Dial Up Internet 和 Broadband Internet 服务的一部分。
从上面的例子可以看到，如果结构类型表示给定产品中涉及了其他产品，那么产品的结构类型将同关系结构一起使用。
对于 MDM Server 中的大部分结构，关系是受类型驱动的，因此能够定义感兴趣的关系的类型。
产品类别层次结构
为了向不同的用户提供产品集的不同视图，通常需要将产品按各种用途组织成不同的层次结构。示例用法包括：
- 消费者层次结构，将产品组织成不同的类别，然后在网站上显示以供用户浏览。这是零售商常用的方法，您可以在其网站上导航整个层次结构来查看位于不同类别和子类别的产品。类似地，银行网站也通常允许您下钻不同的类别来查找产品和服务。在音乐作品 中，可以将作品放到不同音乐流派的类别中。
- 位置可用性层次结构，包含位置层次结构，例如国家 -> 州/省 -> 市。每个类别表示一个位置，分到此类别中的产品表示该产品可在这一销售区域销售。
- 内部销售层次结构，将产品按不同的级别分类，例如分公司、部门、类别、品牌等等。
使用 MDM Server 可以按照不同用途创建多个类别层次结构。产品可以被放入多个层次结构中，也可以被放入一个给定层次结构的多个类别中。可以导航层次结构来查找产品，或者对于给定的产品，可以使用可用的服务导航所有相关的类别及其层次结构。
图 6 演示了一个简单的 Music Catalog 类别层次结构，其中一个音乐作品与两个类别有关。
图 6. Music Catalog 的类别层次结构示例
类别层次结构可以作为继承层次结构 使用，从而可以根据其分类为产品提供额外的元素（以 spec 的形式）。这些额外的元素被称为产品类别属性 并且具有以下特征：
- 如果需要的话，可以将多个 specs 连接到一个类别并串联为子类别，从而为产品定义额外的元素。
- 当某个产品与具有这类 spec 附件的类别关联时，它将继承这些 spec。
- 随后可以为 spec 中定义的属性提供值。这些值是针对产品而不是针对类别的。
使用可用的扩展机制可以将额外的业务规则插入到现有服务中。例如，可以根据属性值将新的或修改后的产品自动划分到相应的层次结构中。
类别层次结构提供了根据不同用途组织产品的能力。不应当将其与产品类型层次结构混淆。下面是两者之间的关键区别：
- 只有一个产品类型层次结构，但是可以有多个类别层次结构
- 任何给定产品都属于一种单一的产品类型。任何给定产品都可以划分到层次结构内的或跨许多层次结构的多个类别中。
- 产品类型层次结构是相对静态的。需要随时间的推移添加新的类型，而某些类型则被淘汰。然而，类型层次结构的基本结构则不需要经常修改，相比之下，类别层次结构要求进行结构方面的修改，包括重新对产品分类以及将类别移动到层次结构中的不同位置。
- 产品类型为其所有产品提供了一组基本属性（即 specs）。换言之，产品继承了它所属的某个产品类型的基本属性。这些属性是产品属性并适用于所有该类型的产品。类别可以为产品提供一组属性（即 specs）。这些也是产品属性，但是只适用于与该类别相关的产品。
- 产品类型层次结构是一个严格的树，而类别层次结构则是一个有方向的非循环图表。
产品条款和条件
条款和条件可以被管理并关联到产品和产品之间的关系。条款和条件可以包含描述性词语，但更重要的是，它们和它们的子条件可以以结构化的形式捕捉数据，这种结构化的形式可以提供给外部规则或系统以进行评估。例如，可以使用外部内容管理引用特性将条款和条件关联到内容管理系统的图像或文档中。示例包括：
- 用于产品包的条款和条件
- 产品采购的资格规则
- 行为奖励的资格规则
- 公开性原则
- 费率和收费条款
基本的 TermConditions 结构为：
- TermCondition 指特定使用类型（例如资格和费率）并且有一个要进行连接的目标实体类型（例如产品、产品关系和帐户）。
- TermCondition 可以包含子 TermConditions（或子条件），从而生成 TermConditions 层次结构。子条件本身就是一个 TermCondition。
- 按照其使用类型中的定义，TermCondition 可以具有许多条件属性值。例如，一个资格条件的条件属性可以是年限、净资产 和地理位置。这些属性的值可以作为 TermCondition 的一部分提供，并且全部在一个关系结构中进行管理。
图 7 展示了一个 Student Banking 产品包以及该包的条款和条件：
图 7. student banking 产品包的条款和条件示例
在此例中，包被定义为包含取款、存款和信用卡服务。这些全部是 Product Domain 中的定义性数据。换言之，上图仅仅描述了产品包。MDM Server 中的 Account Domain 负责存储和管理学生购买此包的事实，在这种情况下，学生将拥有一个支取帐户、一个存款帐户和一个信用卡帐户。此包有两个截然不同的条件：
- 将从信用卡获得一个折现率，这一条件是使用此包的主要好处。它包含一个描述实际折现率的条件属性。实际折现率将必须应用到信用卡管理系统中。
- 包内的帐户必须拥有有效的状态，此条件包含了子条件，描述了帐户必须拥有的可能状态，这样包才能够保持完整性。每个子条件包含一个条件属性列表，这些条件属性表示存款（支出和存款）和支出帐户的有效状态。这些数据可以作为规则的一部分被 Account Domain 利用，例如，评估包在支取、存款和信用卡帐户状态改变时是否仍然完整。
产品本地化
产品数据可能需要以多种语言进行管理，因为它被视为定义性 数据。所有基于字符串的数据，不管是在数据库表中固定的数据还是使用 spec 机制管理的数据，都可以以多种语言进行管理，并获得服务支持。例如，产品名可以使用多种语言维护。在本例中，在添加产品时，将提供英语、法语、德语 和意大利语 的产品名。
从查询角度来看，服务控件标题信息（DWLControl）可用于表示将为查询服务返回哪种语言的产品内容。例如，在查询产品时，返回英语 和德语显示的内容。
对于任何熟悉 MDM Server 的 Party Domain 的人来说，这一概念扩展了它的功能。在 Party Domain 中，给定的服务将使用请求者所用的语言返回代码表值。Product Domain 则更进一步，以多种语言返回产品内容。
产品服务
提供完整的开箱即用服务集合来支持上文中描述的所有（和更多）功能。这包括细粒度的和粗粒度的服务，用于添加、更新、查询和搜索产品。
这些服务遵从与其他 MDM Server 服务相同的模式，例如 Party Domain 中的服务。一些关键要点包括：
- 添加和更新服务允许您提供完整的子元素集合。例如，可以为新产品添加 spec 中定义的属性的值、标识符、与其他产品的关系、与类别层次结构的关系、条款和条件，并且所有内容都使用多种语言表示。
- 查询服务允许您按照产品 id 或按照相等标识符查询产品。提供了对查询级别的支持，可以定义返回的内容的数量，并且通过配置元数据即可添加新的查询级别。还提供了按照 spec 筛选值的能力。例如，可以查询一种产品，并只要求获得 LogisticSpec 和 MusicMediaSpec 值。
- 搜索服务提供了各种搜索条件，包括产品元素和类别层次结构，并支持与 Party Domain 相同的框架，比如可插入式搜索框架。DB2 on AIX 示例支持搜索 spec 值。
结束语
您现在应当基本理解了 MDM Server 的 Product Domain 的各种特性。其中包括：
- 定义需要管理的产品及其属性的类型的功能。这可以视为产品模型。
- 实际创建产品并实施管理的功能。
在本系列的随后两篇文章中，了解如何通过完整的代码样例实现所有这些特性。
参考资料 学习
获得产品和技术
讨论
作者简介  | 
| | David Borean 在产品和定制开发领域的任务关键型企业应用程序的架构和开发方面具有超过 13 年的工作经验。David 加入 DWL 并领导开发 DWL Customer（现为 MDM Server）的架构，该产品可帮助定义 CDI/MDM。该产品的面向服务架构经受了时间的考验，并且在 MDM Server 开发中仍然保持战略性。David 利用 DWL 的休假致力于实现公共服务的现代化架构，并在 2005 年 DWL 被收购后不久加入 IBM。David 现在是 MDM Server 的首席产品架构师并负责实验室推广计划。在加入 DWL 之前，David 为 Castek 工作，在有关金融服务的各种项目中担任开发人员和架构师角色。 |
| 
| | Martin Oberhofer 作为一名 IBM 数据库技术开发人员加入 IBM 硅谷实验室。回到德国后，他加入了 IBM Boblingen Lab 并成为 World-Wide IBM Software Group Master Data Management Center of Excellence 的技术顾问和成员。他的专业领域包括数据库技术、Java 软件开发、MDM 架构和 IT 系统集成。他特别关注将 MDM 系统集成到运营 IT 领域，涉及到使用 SAP 应用程序系统同步并分发主数据。Martin 还为客户和系统集成人员提供了架构工作室。他从德国的 University of Constance 获得了数学硕士学位。 |
| 
| | Thomas Schwarz 是德国 IBM Boeblingen 实验室的 Center of Excellence for MDM 的主数据管理技术顾问。他是 IBM InfoSphere MDM Server 与应用程序系统（特别是 SAP）集成方面的专家。此外，他还擅长使用 IBM InfoSphere Information Server 实现数据迁移和整合（特别是针对 SAP 系统）。Thomas 还为客户提供有关 MDM 架构和集成问题的咨询。在此之前，Thomas 曾是 Stuttgart 大学的研究助理，从事松散耦合的数据服务中基于位置的数据的集成和联合。他于 2007 年从德国的 University of Stuttgart 获得了博士学位。 |
对本文的评价
| 
