Data Model (Overview) of Open Cloud MDM

At the core of Open Cloud MDM lies its data model, which is the foundational layer behind a comprehensive suite of services. This model is intricately aligned with the Information Framework (IFW) Industry Models, allowing Open Cloud MDM to serve as a physical embodiment of these models, tailored to the specific requirements of master data management. While Open Cloud MDM doesn't mirror IFW in its entirety, there's a coherent mapping between them. Open Cloud MDM's data model, particularly its Product Domain, draws significant influence from IFW's Product and Arrangements section.

The Open Cloud MDM data model is bifurcated into two main logical sections: COMMON and DOMAIN. The DOMAIN section encapsulates three primary business domain models: PARTY, PRODUCT, and ACCOUNT. Each of these domain models can operate independently or establish inter-domain relationships. Leveraging our extensive data model, new master data domains can be accommodated through our adaptable concepts (subtypes, entities) and extensibility features.

The database structure of Open Cloud MDM is organized into operational and history tables. The operational tables are repositories for the business data, while the history tables serve as their audit counterparts, enriched with additional columns for tracking data evolution. These history tables mirror the operational tables and are dynamically updated via triggers.

The physical data model encompasses more than 400 tables, making a comprehensive overview challenging. Consequently, the provided illustrations offer a simplified, conceptual view at a high level of abstraction. For a detailed understanding of the complete data model, including thorough descriptions, please refer to our GitHub repository.

Party Domain Model

Central to the Party Domain is the Party entity, uniquely recorded in the CONTACT table and further subclassified into Person (PERSON table) and Organization (ORGANIZATION table). Open Cloud MDM doesn't necessitate further subclassification of the Party entity. Both Person and Organization names are managed distinctly within their respective tables. The Party supertype forms the basis of most related entities, thus applying to both Organizations and Persons. The Party entity establishes relationships with various other entities like Address, Party Identification, Hierarchy, Grouping, Privacy Preference, Lines of Business, Interaction, Campaign, Party Values, and other Parties.

Account Domain Model

The Account entity stands at the forefront of the Account Domain, performing several key functions:

• Providing an account-focused perspective of master data.
• Offering consolidated views of multiple accounts for business applications.
• Enabling connections to party and product domains.
• Facilitating the introduction of new products and services through cross-account relationship management.
• Managing diverse agreement types, including account and purchase/vendor agreements.

The CONTRACT table is the primary table in the Account domain. An account can represent a legal embodiment of a product (as indicated by the CONTRACT.PRODUCT_ID field) or be linked to multiple products in the Product domain via the PROD_CONTRACT_REL table. The Account (Contract) Domain employs a role-based model for interfacing with the Party.

Product Domain Model

In the Product Domain, the Product entity, stored uniquely in the PRODUCT table, is paramount. Product attributes are delineated by product types. There are two primary methods for persisting entity attributes: hard and soft. The hard persistence method involves creating database tables and services for specific subtypes. In contrast, the soft persistence method utilizes Specs and XML metadata, avoiding the creation of new tables and services.

Specs define the hierarchical structure of dynamic attributes, specify their types, and provide additional related metadata through the utilization of XSD (XML Schema Definition) technology.

This approach allows for flexible modeling of product attributes through the SPEC table. Products inherit Specs from their Types and define Values in XML format, stored in the PRODUCT_VALUE table. The use of XML facilitates a seamless association of product types with other structured elements.

Specs Formats, stored in the SPEC_FORMAT table, enable the introduction of attribute changes over time without affecting existing products that utilize the same spec. These formats are further supported by a SPEC_FORMAT_TRANSLATION table for localized attribute name translations.

Open Cloud MDM is equipped to manage product content in various languages, with system local values stored in the PRODUCT_VALUE table and other locale values in the PRODUCT_VALUE_LOC table. Additionally, Open Cloud MDM encompasses features like Product Party Relation, Terms and Conditions, Category Hierarchies, Product Search, Product Suspect Process, among others.

Supertype and Subtype Entities for Seamless Integration

The Open Cloud MDM data model is designed with a hierarchical structure comprising 'Supertype' and 'Subtype' entities to facilitate a unified and efficient data management system. This structure enhances the versatility and integration capability of the model, making it suitable for a wide range of business applications.

Supertype Entities:

• These entities act as a foundational layer, encompassing universally applicable and essential attributes. For example, in a 'Person' entity, common attributes like ID, first name, surname, and date of birth are included.
• This approach ensures that all applications accessing these entities have a consistent and shared understanding of core data elements, promoting data integrity and reusability.

Subtype Entities:

• Subtypes extend the supertype entities, allowing for the addition of specific attributes tailored to particular business needs. For instance, subtypes such as 'Employee', 'Supplier', or 'Customer' can be developed, each augmenting the 'Person' supertype with additional, role-specific attributes.
• These subtypes are particularly beneficial for specialized business applications developed by HubDock partners, such as in Human Resources (HR), Customer Relationship Management (CRM), or Supply Chain Management (SCM). They leverage the shared structure of supertype entities while providing application-specific data handling.

Integration of Similar Subtypes:

• In cases where different HubDock development partners create similar subtype entities (for example, various 'Customer' applications), these can be logically merged and integrated through configurations in API management and the request-response processor.
• This ability to merge similar subtypes ensures data harmonization across different applications, even when developed independently, facilitating seamless cross-application data flow and integrity.

Integration with External Applications:

• The Open Cloud MDM model accommodates external applications that may not follow the Open Cloud MDM standard, integrating them via the 'Dock' integration framework. This acts as a gateway, translating and processing data between external applications and the Open Cloud MDM system.
• Such integration is crucial for organizations employing a diverse range of applications, ensuring that data from non-standard systems can be effectively incorporated into the MDM ecosystem without compromising data quality or security.

Derivative Domains (Examples)

On the basis of our concepts (subtypes, entities) and extension options, further master data domains can be flexibly covered on the basis of our comprehensive data model. Some examples include:

1. Customer Management: Encompassing customer relationship management (CRM) systems, sales, and marketing. Master data about customers (like contact details, purchase history, and preferences) is critical for effective customer engagement, personalized marketing, and sales strategies.
2. Supplier and Vendor Management: In procurement and supply chain management, master data about suppliers and vendors (such as contact information, product lists, and pricing) is essential for efficient procurement processes and supplier relationship management.
3. Product Information Management: For retail, manufacturing, and e-commerce, master data about products (including specifications, pricing, and inventory levels) is crucial for inventory management, product development, and marketing.
4. Employee and Human Resources Management: In HR systems, master data about employees (like personal details, job roles, and performance data) supports HR functions such as payroll, talent management, and workforce planning.
5. Financial Management: In finance and accounting systems, master data related to financial accounts, cost centers, and budgeting is vital for accurate financial reporting, budgeting, and financial analysis.
6. Asset Management: Involving master data about physical and digital assets of a company, crucial for maintenance, asset tracking, and lifecycle management.
7. Logistics and Distribution: Master data about transportation, warehousing, and distribution networks is central to efficient logistics and supply chain operations.
8. Regulatory Compliance and Risk Management: Master data assists in adhering to legal and regulatory requirements, managing risk by ensuring compliance with various industry standards and regulations.
9. IT Management: Involving master data about IT infrastructure, software applications, and users, essential for IT operations, cybersecurity, and technology strategy planning.