Page 141 -

MDM Maturity Levels 105

employees on the same course is possible. The join table is a
technical object positioned between “employee” and “course”.
This object contains the list of employee identifiers and
course identifier pairs showing the enrollments. This object,
which only contains IDs, is not meaningful for the business
by itself.

From a semantic point of view, it is preferable to say that
employees are enrolled on courses and vice-versa. The
technical object should not be visible to the business users
and IT professionals are generally responsible for putting
hard-coded software mechanisms in place to hide it from
view. A Model-driven MDM system automatically hides the
existence of this object, which eases the use of that data by
business users while still avoiding bespoke developments led
by IT professionals .
5

Figure 5.3 illustrates this principle, in the case of the
relationship between authors and their books. The left-hand
part illustrates the use of the join table; the right-hand part
shows the use of the direct association between the book and
author. The generation of the user interface is automatic
because there is no join table to hide. Beyond this, the
Model-driven MDM system ensures integrity controls and
the non-duplication of information, despite the absence of a
join table.

5. This technical mechanism is known as a Data Access Layer (DAL) or,
more precisely, Object Relational Mapping (ORM) with specialized
frameworks like Hibernate. A Model-driven MDM system reuses this
mechanism and applies it to reference and master data in order to ease
the business administration of the data, hiding join tables in the User
Interface and software (application interface or services) as their presence
is not relevant to business users.