Dans les modules précédents, nous avons introduit le concept de base de données, discuté des types de données qu'elles stockent et pratiqué l'envoi de requêtes API REST pour récupérer des données. Dans le même temps, nous sommes restés un participant extérieur au processus et avons seulement demandé des informations à diverses sources.

Il est temps de créer votre base de données ! Dans ce module, c'est ce que nous allons faire, nous allons comprendre comment les données sont stockées dans la base de données et comment elles peuvent être interconnectées. Mais avant toute chose, commençons par la théorie. Traitons de la forme sous laquelle les données nous parviennent, ainsi que des catégories dans lesquelles se répartissent les bases de données en fonction de la structure des données.

Principes de base des données

Représentation des données

Le leader absolu de la représentation des données dans l'API REST est le format JSON. Dans tous les exemples des modules précédents, nous avons reçu des données dans ce format. Il est bon de rappeler que REST ne nous impose pas de restrictions quant au choix du format, à l'avenir vous en rencontrerez sûrement d'autres (par exemple, XML). En même temps, en raison de sa légèreté et de sa lisibilité par l'homme, les développeurs préfèrent souvent le format JSON.

JSON (JavaScript Object Notation) est un format d'échange de données en mode texte basé sur JavaScript. Et ne laissez pas le JavaScript du titre vous tromper. Le format JSON, bien qu'il soit issu de ce langage de programmation, en est totalement indépendant et peut être utilisé partout.

Voyons en quoi consiste un objet JSON et comment il est écrit.

Toutes les données que vous avez reçues sont entourées d'accolades "{}". Elles sont toujours placées au début et à la fin de l'objet JSON.

L'objet lui-même est constitué d'un ensemble d'enregistrements, qui sont des paires "Clé : Valeur" et sont séparés les uns des autres par des virgules ",".

La clé est le nom de l'entrée elle-même, entre guillemets "". Exemples : "nom", "valeur", "région", "adresse". Il peut s'agir de n'importe quel mot, l'essentiel lors du développement étant de s'assurer que cette signification est claire.

Les valeurs peuvent être de différents types. Examinons-les toutes.

  1. Chaîne de caractères. Contient des informations textuelles, un ensemble de caractères de la norme Unicode. Les chaînes de caractères sont placées entre guillemets "".
  2. Nombre. Il peut s'agir d'un nombre entier ou à virgule flottante. Il est écrit tel quel, il n'est pas nécessaire de le mettre entre guillemets.
  3. Booléen. Une des deux valeurs. Soit vrai, soit faux. Comme un nombre, il s'écrit sans guillemets.
  4. Tableau. Un ensemble ordonné d'éléments. Chaque élément peut être de n'importe quel type. Un tableau est entouré de crochets "[]", et ses éléments sont séparés par des virgules.
  5. Objet. La valeur JSON peut être un autre objet JSON. Les mêmes règles s'appliquent à cet objet qu'à l'objet racine. Il est également entouré d'accolades et contient son propre ensemble d'enregistrements.

Examinez les données que vous avez reçues dans les premiers modules en gardant ces informations à l'esprit. Sélectionnez les composants JSON, déterminez à quel type appartiennent les valeurs reçues.

Stockage des données

Nous avons traité du JSON. Nous passons maintenant à l'essentiel : les bases de données. Les données peuvent y être stockées de différentes manières. En même temps, elle s'est historiquement développée de telle sorte que le modèle de base de données relationnelle a reçu la plus grande diffusion.

Lorsqu'on utilise le modèle relationnel, les données sont stockées sous la forme de tables, avec un ensemble spécifique de données, dont la structure est spécifiée de manière rigide lors de la conception de la base de données. La description d'une structure de données dans les bases de données relationnelles s'appelle un schéma. Il définit la composition des tables, la structure des champs de ces tables, ainsi que les relations entre elles.

Le SGBD utilise le langage SQL pour gérer les données avec un modèle relationnel.

SQL - Structured Query Language. Il s'agit d'un langage déclaratif, ce qui signifie que ses commandes ne décrivent que l'action nécessaire (trouver des données, les supprimer, les modifier), et chaque SGBD décide lui-même comment l'exécuter.

Il existe de nombreux SGBD relationnels différents. Parmi les plus courants, on trouve Oracle, MySQL, MS SQL, PostgreSQL. À propos, AppMaster utilise PostgreSQL, ce qui signifie qu'il utilise un SGBD moderne et avancé qui fonctionne dans un grand nombre d'organisations différentes et qui est également un logiciel libre (c'est-à-dire que vous n'avez pas besoin de payer un supplément pour l'utiliser).

Avez-vous remarqué la présence de l'abréviation SQL dans presque tous les noms de SGBD ? En fait, un nom alternatif pour une base de données relationnelle est une base de données SQL.

Cependant, il existe une autre approche. Les bases de données non relationnelles, ou NoSQL. Il convient de noter que, dans ce cas, No n'est pas la négation de "non", mais l'abréviation de Not only. Autrement dit, "Pas seulement SQL".

Les SGBD non relationnels n'utilisent pas un format de requête commun (comme SQL), chacun d'entre eux met en œuvre sa propre façon de travailler avec les données.

Ils ne nécessitent pas une structure de stockage des données définie de manière unique. Les données elles-mêmes y sont stockées non pas sous la forme de tables strictes, mais sous la forme d'objets avec un ensemble arbitraire d'attributs (un peu comme JSON). Cela peut s'avérer pertinent lorsque l'on travaille avec des données dont la structure est sujette à de fréquentes modifications.

Parallèlement, en raison de leur structure libre, les solutions NoSQL sont plus faciles à faire évoluer si vous devez créer une base de données distribuée sur plusieurs serveurs.

Parmi les exemples de SGBD NoSQL, citons MongoDB et Redis.

Conception de la base de données

Il est temps de concevoir votre propre base de données. Pour ce faire, allez dans l'onglet Data Design (Concepteur de données) dans le panneau de gauche.

Les données de la base de données sont stockées sous la forme de tables spéciales (modèles). Vous pouvez remarquer que nous avons déjà un modèle. Il fait partie du module d'autorisation et est inclus par défaut dans chaque projet. C'est grâce à lui que sont créés les nouveaux utilisateurs de l'application et que sont gérés les utilisateurs existants. Mais nous ne nous attarderons pas sur son étude maintenant, et nous allons créer notre propre modèle.

Imaginons que nous développions un service de cartographie. Créons un modèle qui contient des informations sur les pays. Pour le créer, il faut faire un clic droit dans une zone vide du canevas et sélectionner Créer un modèle vide.

Pour créer, nous devons seulement spécifier le nom du modèle. Nous traiterons de l'auto-génération des points de terminaison et des éléments de l'interface utilisateur dans les autres modules du cours.

Veuillez noter qu'immédiatement après la création, le modèle contient déjà 4 champs. Il s'agit de champs système, dont la présence simplifie grandement la création initiale et l'utilisation ultérieure du modèle.

  1. ID (integer) - Identifiant unique, clé primaire. Il est automatiquement créé pour chaque nouvelle entrée dans la table et est destiné à garantir qu'il n'y a pas de doublons. C'est par l'ID que l'on peut identifier de façon unique un enregistrement dans une table. Sa valeur commence à 1 et augmente automatiquement de 1 pour chaque nouvelle entrée.
  2. CreatedAt (datetime) - Heure à laquelle l'enregistrement a été créé dans la table.
  3. UpdatedAt (datetime) - Heure à laquelle l'entrée a été modifiée pour la dernière fois.
  4. DeletedAt (datetime) - L'heure à laquelle l'entrée a été supprimée. Bien sûr, uniquement si la suppression douce a été utilisée. C'est-à-dire, une telle suppression, lorsque l'enregistrement est seulement marqué comme supprimé et filtré par les demandes d'accès à celui-ci, mais en même temps reste physiquement dans la table. Ceci est différent de la suppression en bloc, qui supprime réellement les données complètement.

En plus de ceux du système, il serait judicieux d'ajouter des champs personnalisés au modèle créé. Supposons que nous voulions voir le nom du pays et une description contenant des informations à son sujet.

Le choix d'un type de champ ne devrait pas poser de problème. Pour le nom, String convient, et pour la description informative, Text.


En outre, quatre autres commutateurs sont disponibles :

  1. Multiple values (Array) - utilisez des tableaux au lieu d'entrées uniques.
  2. Not null - le champ spécifié ne peut pas être vide, il doit toujours contenir des données.
  3. Unique - la valeur du champ doit être unique, dans ce modèle il ne peut pas y avoir deux enregistrements dont les valeurs de ce champ sont les mêmes.
  4. Index - indique qu'un index spécial sera créé pour ce champ afin d'accélérer la recherche.

En général, il convient de ne cocher les cases que si c'est vraiment nécessaire. Par exemple, nous pourrions cocher Not null et Unique pour les noms de pays, en supposant qu'il ne peut y avoir un pays sans nom, ou deux pays avec le même nom. Cependant, il est préférable de contrôler cela au stade de la création de la logique de l'application, et de ne pas imposer de restrictions à la base de données elle-même.

De même, créez une table contenant des informations sur les villes. Réfléchissez aux champs de données qu'elle peut contenir et au type de ces champs.

Les données de la base de données n'existent pas toutes seules, sous la forme de tables éparses. Elles sont liées les unes aux autres d'une certaine manière. La clé de l'élaboration d'un modèle de données consiste à définir ces relations et à établir des liens.

Pour établir ces liens, il est nécessaire de tracer une ligne avec la souris de la frontière d'un modèle à un autre. Dans notre exemple, nous savons avec certitude que chaque ville est située dans un certain pays, nous pouvons donc créer un lien du pays vers la ville.


Il existe 3 différents types de connexions :

  1. One-to-one (a un). Chaque enregistrement de la table est mis en correspondance avec un enregistrement de la table associée (ceci est également vrai en sens inverse). Un exemple simple est celui d'une personne et de son passeport. Nous pouvons toujours être sûrs que cette connexion est unique. Un passeport ne peut avoir qu'un seul titulaire, et chaque personne ne peut avoir qu'un seul passeport valide.
  2. One-to-many (a plusieurs). Chaque enregistrement d'une table peut avoir de nombreux enregistrements dans une autre table. Notre base de données est un exemple similaire. Un pays peut avoir de nombreuses villes différentes, mais chaque ville ne peut appartenir qu'à un seul pays. C'est la connexion que nous allons établir.
  3. Many-to-many. Une relation dans laquelle plusieurs enregistrements d'une table peuvent correspondre à plusieurs enregistrements d'une autre. Un exemple simple est la relation entre les enseignants et les étudiants. Chaque professeur peut enseigner à de nombreux élèves, tout comme chaque élève peut apprendre de nombreux professeurs différents.

Les devoirs

Imaginez que vous deviez développer une application pour une boutique en ligne. Créez un modèle de base de données pour qu'elle fonctionne.

  • Il est nécessaire de prévoir la disponibilité des marchandises avec des fiches de leur description, différentes catégories de marchandises, des informations sur les commandes et sur les clients.
  • Remplissez les tables avec des champs de différents types (utilisez au moins 5 types).
  • Établissez des relations entre les tables. Utilisez les 3 types de liens.