An introduction to Mendix for data analysts and BI-engineers

Leverage the value of data by combining the Mendix data assets with data analytics. This guide will give you an introduction on how Mendix manages the database and helps you understand the data structures from Mendix apps.

Introduction#

Mendix#

Mendix is a cloud-based low-code application development platform that allows you to create, deploy, maintain, and improve mobile and web apps at scale.

Database support#

Mendix uses a PostgreSQL database for apps deployed to the Mendix cloud, but it supports a wider list of database servers. Each app must have its own database, Mendix apps cannot share data by sharing the same database. There are multiple approaches to sharing data between Mendix apps or with your analytics environment, each with its own benefits and considerations. In this guide will cover how Mendix data is structured and how to analyze data from Mendix apps, in another post I will explain more on how to access data from Mendix apps.

Domain model (Data)#

Information used in Mendix apps is visually described using a domain model. The domain model is a data model which abstracts the structure of a relational database which stores the data that is used in your app.

Each module in a Mendix app has its own domain model and describes the data used in that module. A domain model consists of entities, associations and attributes. These entities can be persistable (blue), non-persistable (orange) or external (purple).

This is a very simple domain model depicting an Order and a Customer which has a 1-n association (owned by Order). The customer has two attributes defined: FullName and NameLength. These persistable (blue) entities will be stored in the database (more on Domain Models in Mendix docs).

Database tables#

Each Mendix app has its own database or schema where it persists the data. Non-persistable entities and external entities (data which belongs to another app or service) are kept in the memory of the app.

In the database, every entity is stored in a separate table and has columns for system attributes and the attributes defined in the domain model. Each table row contains the data for an object of the particular entity, and every table contains a column holding a unique identifier for the object. Associations are stored in junction tables with columns holding the identifiers (ID) of both associated objects.

Database management#

ORM#

Mendix handles all aspects of database management through object-relational mapping (ORM). Which means developers can focus on developing the domain model and application while the Mendix Platform will handle the creation and maintenance of tables, data types, joins and constraints.

Upon deployment of the application, Mendix ORM will start with a data definition language (DDL) phase, which will automatically create the correct database structures based on the domain models. Changes made to the application are automatically updated in the database by Mendix and when possible data will also be migrated (for example, attribute renaming or type changes).

Changes#

Since Mendix developers don’t have to manage the database schema, the need to think about technical database aspects is removed. Changes to the data structures in the domain model are automatically updated by Mendix in the database, but these changes are not propagated to a remote data analysis system. This might pose a challenge to Data Integration, for example if attributes are renamed that are also used in data analytics. A metadata repository and a change management process will help solving these challenges. Consider:

• Establish a process for data model changes (keep each other informed)
• Save the DDL commands generated by Mendix
• Use the mendixsystem database tables for entities, attributes and associations to detect changes

MendixSystem tables#

The Mendix Platform stores the metadata about the data structures in tables starting with mendixsystem. The table mendixsystem$entity will contain the entity identifier, the entity name (as represented in the domain model), the table name (as used in the database), its super entity (if part of an inheritance structure) and some other attributes. Similarly this metadata is available for attributes, associations, indexes and constraints.

These tables are typically not relevant for data analytics but will help you track changes to the database structure.

Analyzing the data#

Find data#

To find the data you could cut your way through all the database tables of a Mendix app. Or you could talk to the Mendix team (recommended). They would be able to quickly identify the required data for analysis, as well as provide Domain Model exports¹ (visual representations of the entities, associations and attributes). These exports will support the process of identifying, prioritizing and documenting the data.

Understand data#

Now you have the data, but you have to understand what it means. Identify, prioritize, precisely formulate, and validate the data needed for analysis and (again) talk to the Mendix development team to understand the data. It is important to know the context, source and constructs of the data in order to drive effective and high quality business decisions based on your data analysis. Ask questions like what is the quality of the data, what are the defaults, what is missing, how is it calculated or processed, does it depend on other attributes, possible unique values, changes over time in enumerations/categories, validations and constraints. Understanding the data is a prerequisite for data quality and analysis.

Use data#

Now you are ready to use the data in your analysis and business intelligence reporting! Make sure to implement a feedback loop where learnings and business decisions can lead to actions in and development of the operational systems.