This blog post details how to use the template models provided in MDM Workbench to create and deploy a new Virtual Configuration Project to an Operational Server, and then deploy the sample data supplied in the template model.
Creating a new Virtual Configuration Project
Creating a connection to the Operational Server
Deploy the new Configuration Project:
Processing and loading the sample data:
vwilburn 100000F865 Visits (3058)
In Version 11 of InfoSphere MDM, some big changes happened. One change that might leave you scratching your head is the addition of new and changed terms for some familiar components. We also have a couple new components, so those might be unfamiliar too. Let's take a quick walk through the changed terms to get you started.
The first thing that you'll notice is an emphasis on capabilities rather than product names. You might not see these familiar product names anymore:
InfoSphere MDM Server
Initiate Master Data Service (MDS)
Other Initiate product names
Instead, you’ll see references to technical capabilities that those products achieve:
You might be wondering what exactly these technical capability terms mean. You can use virtual, physical, and hybrid MDM to manage your master data, whether you store that data in a distributed fashion, in a centralized repository, or in a combination of both.
The following definitions show the differences and the relationships among the technical capabilities:
The management of master data where master data is created in a distributed fashion on source systems and remains fragmented across those systems with a central "indexing" service.
The management of master data where master data is created in (or loaded into), stored in, and accessed from a central system.
The management of master data where a coexistence implementation style combines physical and virtual technologies.
Server and engine terms
Another new area that you’ll notice is a unified server, which is referred to by one common term:
The former InfoSphere MDM Server and the former Initiate Master Data Service are combined to share a single infrastructure in the application server. That single infrastructure is called the MDM operational server or operational server for short. The operational server is the software that provides services for managing and taking action on master data. The operational server includes the data models, business rules, and functions that support entity management, security, auditing, and event detection. For detailed descriptions and diagrams, see the arch
Records, member records, and entities
Finally, the concepts of entities and records were clarified:
A single unique object in the real world that is being mastered. Examples of an entity are a single person, single product, or single organization.
The storage representation of a row of data.
The representation of the entity as it is stored in individual source systems. Information for each member record is stored as a single record or a group of records across related database tables
Depending on your implementation style, these concepts reflect the technical capabilities of virtual, physical, and hybrid MDM. For example, an entity in virtual MDM is assembled dynamically based on the member records by using linkages and then is stored in the MDM database. Conversely, an entity in physical MDM is based on matching records from the source systems that are merged to form the single entity. For details, see the diag
I’ll leave a discussion of hybrid MDM to a future article. If you’d like to read some conceptual topics about hybrid MDM now, see its technical overview.
Some helpful links:
jaylimburn 2700028UUJ Visits (2008)
I recently found myself in a tricky situation. I had built a demo using a back level version of the MDM Standard Edition engine. I had beautifully created some dummy data specific to the demo, which included a lovely complex set of h
Here are the steps:
This saved me a huge amount of time in my specific scenario and stopped me having to remember how to configure the Individual sample data and link the enti