SAP TechEd 09 - Live Expert Session: Multiple domains in one MDM repository vs one MDM repository per domain
While MDM 5.5 had certain limitations in regards to Data Modeling (no deeply nested structures, only one main table) MDM 7.1 solved most of these issues by introducing the Multiple Main table and Tuples concept.
While it’s relatively easy to use these functions when designing completely new repositories, it also needs to be considered whether it really makes sense to use these new functionalities, like putting multiple domains in one and the same repository versus having each single domain in its own repsitory.
Locating multiple domains in a single repository can also benefit from the functions and features that are available inside a single repository only, e.g. workflows, assignments and validations are available over multiple main tables in the same repository but they do not span different repositories.
The challenge is to decide about having one repository for each Master Data Domain or combining several master data domains into one repository
A classic example for having two main tables in a repository would be products and vendors/suppliers. Both of them are stored in their own main table while the supplier part number can act as a link between the two objects.
Having one repository incorporating several domains or one repository/domain - that's the big question.
You should consider having several main tables in a repository, when
- Each main table is an entity of its own (like vendor, customer, material, etc.). The object types in each main table can be clearly differentiated from each other.
- Multiple main tables are related with each other for business reasons or that they share the same commonly used data from lookup tables, e.g. Plant codes, Countries etc.
In order to make the right decision three different areas need to be considered. These are the Console, Read/Write operations and scenarios.
Considerations in the Console
- A downtime (e.g. repository maintenance) will impact all main tables. Since several domains are in one and the same repository, all these domains would be affected when the repository is unloaded.
- Performance impact (like load time of the repository). The more records and tables you have in your repository the more time it takes to load it. Similar impact would be when it comes to updating or inserting new records into the repository. Indexes need to be rebuild etc.
Considerations for Data Entry (CRUD operations)
- Increase of the number of users working with multiple main tables in one repository. More domains in a repository typically means also more concurrent users working in the repository. In repositories where users have Read/Write authorizations, this could lead to potentially more locking issues.
- Scalability for large number of records in repository. The more records there are in your repository and the more users are working concurrently with your repository, the more powerful your machine has to be.
- Consider impact of imports, syndications and synchronizations for repositories having multiple domains – this would probably mean more or more often performing these operations
Considerations from a Scenario perspective
- Separation of operations: If there’s one domain with read/write access required and another domain only with read access required, these two domains should go into separate repositories
- Keep Business scenarios is separate repositories: e.g. CMDM (Central Master Data Management) and MDM-GDS (Global Data Synchronization) both should their own repository.
Above list provides a good starting point when it comes to making the decisions of single domain repositories vs. multi domain repositories. Often it will be also required to develop a prototype to see whether all requirements can be handled with the one or the other strategy.
Related Posts
