Understanding Entities and Databases
This is a continuation of the Hello Mendix series — where I explain the essentials of Mendix development and try to fill the gaps in your knowledge as quickly as possible. In part 4 of this series, I will be talking all about Entities and Domain Models. Let’s go!
What is a Domain Model?
In Mendix we model our database in the Domain Model. Which is similar to an ERD or entity relationship diagram. Except that it also creates a functional database modeled on that Diagram when your app compiles. Mendix has a built-in database option, but will also support IBM DB2, Microsoft SQL Server, MySQL, Oracle, and PostgreSQL.
The Mendix Docs say this on Domain models: ‘The domain model is a model that describes the information (or data) used by your application in an abstract way. It is central to the architecture of your application. Each module has its own domain model which describes the data used in that module. All modules in an app can use data from all the domain models within the app.”
If this has left you confused I will try to explain it simply in my own words, a Domain model is a collection of Entities and how they relate to each other Represented in a Visual way.
An Entity can be compared to a Table in traditional SQL.
Entities have attributes — which you can think of as fields — and have primitive types like string, int, and date-time. Entities can relate to each other either 1–1, 1-*, or *-*.
If you’re interested in learning more about how Mendix keeps the underlying database in sync with your model, check out this video where I cover in detail how this works.
Understanding Generalizations
You can also make an entity inherit properties from a parent, by creating an entity as a generalization. Generalizations give the child all the properties of the parent, and you can cast the entities to their generalizations when using them in a flow or on a page. This is very similar to inheritance used in other traditional coding methods.
The 3 different types of Entities
The coolest thing about Entities, in my opinion, is that they come in 3 different types: Persistent which is blue, non-persistent, which is orange, and remote entities which are purple.
Persistent entities can be committed to and retrieved from the database. Non-persistent entities live in the browser’s memory and are cleared when the user’s session expires. These can only be retrieved via association and cannot ever be committed to the database. This makes them ideal for integrations, or for storing data temporarily to be used in a calculation. The final form an entity can take is a remote entity. This is made possible using Mendix DataHub, which is an open metadata catalog. This allows you to share data between apps using Odata communications to send the data back and forth
You can expose an existing table from one app, using DataHub, and consume that data in any other app created by you or your company.
Remember security is always important when dealing with entities as this controls access to your app’s data. Open the properties for any entity while in the Domain Model by right-clicking on it, and head over to the access tab, in order to configure who can create, edit, and view your data.
Final thoughts
Don’t be afraid to try new things and make changes to your data structures — sometimes simple changes can massively improve performance. Just make sure to back up your app’s data before you do, so that you can roll back if you break it!
To find out more head over to academy.mendix.com and look for learning paths on the Domain Model and DataHub.