Module

In the context of Enterprise Data Integration, data records (such as contacts, companies, contracts, etc.) in enterprise systems (such as CRM system, ERP system, marketing automation application, etc.) are organized in modules. These usually adhere to a relational database schema. Thus, in simple terms, modules usually represent tables in relational databases.

The DataEngine is also organized in modules, which follow a relational schema. You can create as many modules as you like in the DataEngine and relate them to each other in any way you like.

The word entity is often used in the same context. The terms module and entity are usually used synonymously. Entity describes a clearly identifiable object and this often means the content object of a module, such as a contact (contact entity). Modules thus contain entities and further associated functionalities (editing, sending, displaying, filtering of entities, etc.).

Relational schemes

To introduce you to the idea of modules, we will illustrate one of the most common relational data structures in the enterprise domain: contacts and companies. We use a very reduced example with minimal fields – for a better overview. In an enterprise system, like a CRM system, contacts and companies are stored between other related data. However, they are generally the main entities. Let’s first look at the contact module (contains the contact entity).

Module: Contacts

Normally, of course, the contact module contains much more information about a contact, such as last name, phone number, email address, assigned sales person, etc.

ID	Name	Account
1	John	SAP AG
2	Jane	HubSpot, Inc.
3	Mary	SAP AG

Module: Accounts

Normally, of course, the company module contains much more information about a company, such as address, billing address, board of directors or management, industry, sales etc.

ID	Name
A	SAP AG
B	HubSpot, Inc.

The Contacts and Companies modules are related to each other. Each contact is assigned to a company. For example, John is associated with SAP AG, Jane with HubSpot, Inc. However, multiple contacts can be associated with one company. For example, both John and Mary are associated with SAP AG. Thus, either one or many contacts are related to a company.

The relation between contacts and firms is thus called a 1:n relation.

The most common relations between entities are: 1:1, 1:n, n:m

For the relation betweem the records of the two modules it needs a relation table:

Relation table

Contact_ID	Account_ID
1	A
2	B
3	A

The company with ID A (SAP AG) can be related to the contact with ID 1 (John) via the relation table. As already described, it is a 1:n relation table. To describe relations between entities, ERMs (Entity-Relationship-Models) are used. A reduced and simplified ERM of the case described above can be found below.

The entity relation model (ERM) shows the relation between contacts and accounts. They have an 1:n-relation.

Prescriptive Analytics

Model Evaluation for Machine Learning

Data Steward

Glossary overview

Book Recommendation

Contents, contributors and CIEF at a glance

Customer Intelligence: Strategies and Use Cases for Leveraging Customer Data

Edited by Prof. Dr. Emanuel Bayer and Manuel Marini · Springer, 2026
The anthology shows how customer data becomes measurable value — with 22 contributions from academia and practice, structured along the five stages of the Customer Intelligence Evolution Framework (CIEF).

Framework: Targets & Commitment, Data Integration, Data Quality, Insights, Use Cases
Topics: Golden Record, Customer Data Platform, data enrichment, AI-driven personalization, compliance
Practice: Field reports from companies including Commerzbank, Deutsche Bank, ADAC, Dun & Bradstreet and IKB

Springer Nature

Amazon

Marini Systems GmbH | Website | Privacy Statement | Legal