Que sont les modèles de données ?

La base de nombreuses applications logicielles est souvent leur modèle de données. Un modèle de données définit les données qui seront utilisées et avec lesquelles une application interagira. Ces données sont soit stockées temporairement en mémoire, soit stockées de manière permanente dans un magasin de données tel qu'une base de données.

Modèles de données dans Mendix sont construits à l'aide d'un langage visuel appelé modèle de domaine. Dans un modèle de domaine, vous pouvez définir les composants suivants :

• Entités:Ces entités peuvent être persistantes ou non persistantes et vous permettent de stocker des données de manière temporaire ou permanente. Une entité persistante est l'équivalent d'une table de base de données, qui est fournie avec une clé primaire unique (c'est-à-dire une entité de localisation ou une entité de transaction financière).
• Attributs:Il s’agit de colonnes similaires à celles d’une table de base de données (c’est-à-dire le nom et l’adresse d’un lieu ou la date et le type de la transaction financière).
• Associations:Ceux-ci définissent les relations entre deux entités, comme une jointure entre deux tables de base de données.

Quand un Mendix Une fois l'application exécutée, le runtime comparera le modèle à la base de données choisie et exécutera tous les scripts de mise à jour nécessaires. Mendix prend en charge une gamme de types de bases de données, notamment :

• PostgreSQL
• Microsoft SQL Server
• MySQL
• Oracle
• Base de données HANA

Le choix t'appartient!

1. Définissez vos entités

Lorsque vous démarrez un nouveau projet, la première chose à définir est votre structure de données. Vous devez penser aux entités que vous devez créer pour créer votre application. Dans cet exemple, nous allons créer une application permettant aux clients de commander plusieurs produits différents.

Pour le modèle de domaine de cette application, vous aurez besoin d'une entité persistante pour un client, une commande et une ligne de commande. Cela nous permettra de suivre les commandes passées par un client pour quels produits. Chaque entité persistante génère une table dans la base de données avec une clé unique. Le diagramme ci-dessous présente nos quatre entités :

2. Ajoutez vos attributs

Après avoir créé vos entités, vous devez ajouter plus de détails à chaque entité, c'est là que les attributs entrent en jeu. Dans notre exemple, le client peut avoir un nom ou un type de compte tel que VIP ou général. Le produit peut avoir un nom ou une description.
Au fur et à mesure que nous complétons les entités, les détails de l'application se concrétisent. Il est très facile de revenir en arrière et d'ajouter d'autres attributs nécessaires. Le diagramme ci-dessous illustre la manière dont les attributs sont répertoriés dans nos quatre entités :

Nous avons ajouté des noms et un numéro de commande généré automatiquement, ainsi qu'une date à laquelle la commande a été passée. Les attributs sont l'équivalent des colonnes d'un tableau et ont un type et une taille d'attribut, tels que chaîne, entier, booléen et tous les types de données typiques dont vous avez besoin pour créer l'application.

3. Créer des associations

Après avoir déterminé les entités et leurs attributs, il est temps de déterminer comment elles sont toutes liées. Dans cet exemple, un client peut avoir plusieurs commandes, une commande peut avoir plusieurs lignes de commande et chaque produit peut être commandé plusieurs fois. La figure ci-dessous représente la relation entre les entités.

Vous remarquerez comment les relations sont représentées visuellement par les associations. La relation client-commande est de type un-à-plusieurs, comme l'indiquent les astérisques. Pour aller plus loin dans cet exemple, nous pouvons également supprimer le comportement entre les relations.

Par exemple, si un client a des commandes, dois-je supprimer toutes les commandes associées au client (ce qu'on appelle une suppression en cascade) ? Ou, si un client a des commandes, devons-nous empêcher l'utilisateur de supprimer une commande (ce qu'on appelle une suppression préventive) ?

Double-cliquez sur les associations pour voir le comportement et la manière dont l'option de suppression est configurée. Le comportement de suppression doit dépendre des besoins de l'entreprise. Réfléchissez aux questions suivantes : est-il important de conserver le client lorsqu'il a des commandes ? Ou est-il plus important de nettoyer la base de données et de ne pas avoir de commandes orphelines lors de la suppression de clients ?

Il s'agit de questions pertinentes à poser aux utilisateurs professionnels et qui aideront à élaborer les règles métier appropriées. La représentation visuelle de ces questions est soit bleue (pour la suppression préventive), soit rouge (pour la suppression en cascade).

Découvrez ce qui est possible avec Mendix