Un bon exercice de modélisation de données pour les débutants consiste à créer un modèle de données d'une boutique en ligne. . Chaque fois que je donne cet exercice à mes élèves, je suis surpris de voir à quel point c'est difficile pour eux.
Trouvez les concepts...
Voyons comment cela peut être fait. Nous savons que nous devons créer une table pour chaque concept du domaine. Pensez aux noms et locutions nominales vous utiliseriez pour décrire le domaine. En gros, chaque nom est soit un concept, soit un attribut d'un concept, soit un exemple . Quels sont les concepts de base dans une boutique en ligne ? Deux mots me viennent immédiatement à l'esprit :
- clients – les personnes qui achètent des choses dans notre magasin, et
- produits – articles que les gens achètent dans notre magasin.
Chaque client dispose d'un ensemble de données de base qui le décrit :identifiant (vous avez généralement besoin d'un attribut d'identifiant dans votre table), nom, e-mail et mot de passe. De même, un produit a un identifiant et un nom. Nous pourrions ajouter plus d'attributs pour les clients et les produits, mais pour les besoins de cet exemple, ceux-ci feront l'affaire. Nous ajoutons les deux tables dans notre modèle.
... Ainsi que les concepts abstraits
Il s'agit d'un magasin, donc évidemment, nous voulons savoir quoi a été commandé et par qui . "Order" est un mot-clé dans la plupart des bases de données, nous ne devrions donc pas l'utiliser pour un nom de table. À la place, nous utiliserons le nom purchase pour la troisième table de notre modèle. La table doit être en quelque sorte connectée au customer et au product . Pour commencer, traçons simplement une référence entre purchase et customer , et entre purchase et product .
Le customer-purchase la référence est OK. Chaque achat est effectué par un seul client ; chaque client peut effectuer plusieurs achats. Cette référence est là pour rester.
Cependant, il y a quelque chose qui ne va pas avec le purchase-product référence. Plusieurs produits peuvent être achetés en un seul achat; plusieurs achats peuvent inclure le même produit. Mais notre référence ne permet d'acheter qu'un seul produit en un seul achat. Supprimons la référence et réfléchissons à une autre façon de la modéliser.
Un seul grand champ de texte pour tous les produits achetés ?
Que diriez-vous d'ajouter un grand champ de texte pouvant stocker les noms ou les identifiants des produits achetés ? Maintenant, nous pouvons acheter plusieurs produits en un seul achat. Cependant, il y a quelques problèmes ici :
- Tout d'abord, il est difficile de vérifier que le produit dans les
purchased_itemsle champ est vraiment dans la base de données. - Deuxièmement, si vous voulez changer le nom du produit (parce que vous l'avez mal orthographié), vous devez mettre à jour tous les
purchased_itemsinstances de champ dans lepurchasetableau. - Enfin, il est difficile d'analyser les données dans la base de données. Par exemple, si vous souhaitez savoir quel produit est acheté le plus souvent, vous devez utiliser une opération de sous-chaîne de texte. Et ce n'est jamais très efficace.
Plusieurs colonnes de produits dans le tableau des achats ?
Quelles sont les autres options? Nous voulons qu'un achat soit lié à plusieurs produits donc peut-être devrions-nous ajouter plusieurs purchase_item colonnes dans une table d'achat ? Eh bien, c'est fastidieux (je n'ai ajouté que 5 colonnes et je me suis fatigué) et crée un artificiel et stupide limite du nombre de produits achetés.
Utilisez une table intermédiaire !
La solution idiote fait allusion à la bonne solution. Nous voulons avoir un illimité nombre de produits liés à l'achat. Le seul moyen est d'avoir une table de liaison intermédiaire . Appelons-le purchase_item . Le purchase_item la table est liée à l'purchase et product . Désormais, un achat peut inclure autant de produits que nous le souhaitons. En bonus, nous pouvons ajouter des données supplémentaires dans le tableau :nombre de fois acheté, prix total de cet article, etc.
Conclusion :
- Les tables du modèle peuvent représenter non seulement des objets physiques comme client ou produit. Les tableaux peuvent représenter davantage de concepts abstraits comme un achat. D'autres exemples pourraient être une réservation dans un système de réservation d'hôtel, un book_loan dans un modèle pour bibliothèque, un rendez-vous dans un système pour médecins, etc.
- Lorsque vous modélisez une transaction (c'est-à-dire l'achat ou la vente de nombreuses choses), vous avez généralement besoin de trois tables :un pour la transaction (achat ou réservation dans un système de réservation d'hôtel), un pour les choses achetées/vendues dans une transaction (produit, chambre d'hôtel), et un pour les éléments de transaction (purchase_item, booking_item). Vous pouvez ajouter des informations supplémentaires dans le tableau intermédiaire si nécessaire.
Créez votre propre modèle de base de données de magasin avec Vertabelo !
