- From your current MDM Standard instance use workbench to run madunlunload. (So if we screw anything up we now have a backup of the data)
- Install the new version of MDM Standard Edition, into a different directory than your other instance.
Run madconfig create_datasource
- Use a different datasource name
- Crucially use the same database name used by your other MDM instance
Run madconfig create_instance
- Specify the newly created datasource at the appropriate prompt
- DO NOT bootstrap the database when prompted
Run madconfig upgrade_instance
- Select yes to make the various changes to the database. This process is updating various config rows in the MDS database to ensure it can work with the newer version of the engine.
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 hierarchical data specific to the scenario of the demo. I then discovered that I needed to utilize a feature from a newer version of the engine and thus would need to upgrade the engine.....oh no what about my data and beautifully crafted relationships contained within it?
Well, fortunately thanks to a colleague he explained a simple way to install the new version of the engine and point it to the current database, therefore leaving said beautifully crafted data untouched and usable from the upgraded engine. This solution worked beautifully from a demo perspective and meant I didn't have to re-create my data or go through some long winded export/import routine.
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 entities....something that once I have to go through again I will blog about, but from memory it involved mpxdatx, mpxcomp, mpxlink and mdaunlload.
vwilburn 100000F865 Tags:  glossary virtual-mdm mdm member-record record mdm11 hub entity mds operational-server physical-mdm initiate hybrid-mdm mdm-server terms 6,081 Views
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 architecture and concepts topic.
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 diagrams and definitions for these concepts.
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:
Nic Townsend 2700051ED4 Tags:  mdm11 virtual initiate techtip sample configuration mdm mdm-workbench mds 1 Comment 9,280 Views
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: