Dessiner les relations
Aussi en 28 langues
English · Español · 日本語 · Português (Brasil) · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Module 2 sur 6 du chapitre Modéliser les données pour leur sens, chapitre 2 du cours Data Architect. Chaque module se suffit à lui-même. Précédent : Écouter les noms · Suivant : Construire le modèle logique
La question à laquelle répond ce module : comment transformer des entités candidates en modèle de données conceptuel ?
Nous avons des noms au tableau. Je veux maintenant comprendre les traits entre les boîtes, car un ensemble d’entités n’est pas encore vraiment un modèle de données. C’est dans les relations que se trouve une grande partie du sens. Un partenaire distributeur exploite des centres de distribution. Un manifeste liste des livraisons. Une livraison va à un destinataire. Une équipe conduit un camion. Chacune de ces phrases m’apprend quelque chose sur le métier, et chacune me donne une autre question à poser.
Commencez par le langage du métier
Section intitulée « Commencez par le langage du métier »Je ne veux toujours pas parler de Salesforce. Je ne me demande pas s’il faut une relation de référence ou principal-détails, je ne pense pas aux objets de jonction Salesforce (Salesforce Junction Objects), et je ne décide pas de ce qui se passe quand un enregistrement parent est supprimé. J’essaie de comprendre la relation métier.
Prenez « un partenaire distributeur exploite des centres de distribution ». Cela paraît simple. Mais un partenaire distributeur peut-il avoir un seul centre ou plusieurs ? Chez Steve Trucking, chaque partenaire distributeur exploite un centre de distribution régional dans chaque région desservie par Steve Trucking, donc plusieurs. Un centre peut-il appartenir à plus d’un partenaire ? Un centre compte-t-il en lui-même, avec son personnel et son historique, ou n’est-il qu’une adresse ? Si un partenaire distributeur part, nous intéressons-nous encore à ses centres ?
Ce ne sont pas des questions Salesforce. Ce sont des questions métier, et les réponses peuvent changer complètement le modèle.
Lire les traits
Section intitulée « Lire les traits »Avant d’aller plus loin, je veux vous donner le langage que nous utiliserons dans tous les schémas à partir de maintenant. Il est réduit. Un trait entre deux boîtes indique que les deux choses sont liées, et les marques à ses extrémités indiquent combien.
Commencez par un trait simple, sans aucune marque. C’est par là que je commence au tableau : je sais que ces deux noms sont liés, je n’ai simplement pas encore demandé comment. Puis les extrémités reçoivent des marques. Une barre en travers du trait signifie un. La patte de corbeau, l’extrémité qui se divise en trois comme une patte d’oiseau, signifie plusieurs. Plus loin dans ce module, vous verrez une deuxième marque apparaître à côté de la première, une barre ou un cercle, et celle-là répond à une autre question : peut-il n’y en avoir aucun ?
La seule règle à retenir : chaque marque se lit du côté de la boîte qu’elle touche. La marque la plus proche de la boîte est le maximum possible ; la marque suivante est le minimum.
Assis, pas bouger, modèle
Section intitulée « Assis, pas bouger, modèle »Avant Steve Trucking, retour aux chiens du module 1. Nous avions cinq boîtes : Propriétaire, Éleveur, Chien, Race et Tour. Je m’intéresse maintenant aux traits entre elles.
Un ou plusieurs ? Un propriétaire peut avoir plus d’un chien ; Ana en a deux. Un chien a un seul propriétaire, du moins dans notre modèle. C’est un-à-plusieurs : une barre côté Propriétaire, une patte de corbeau côté Chien. L’éleveur a la même forme : un éleveur élève de nombreux chiens.
Peut-il n’y en avoir aucun ? Max vient de la fourrière, il n’a donc aucun éleveur. L’extrémité Éleveur reçoit un cercle : un chien a zéro ou un éleveur. Chaque chien a un propriétaire, en revanche, donc cette extrémité reçoit une deuxième barre : exactement un.
Plusieurs-à-plusieurs ? Un chien connaît de nombreux tours, et un tour, disons « Assis », est connu de nombreux chiens. C’est un plusieurs-à-plusieurs, et c’est exactement là que je vais chercher un concept caché. Y a-t-il quelque chose à dire sur le fait que ce chien connaisse ce tour ? Son niveau, et quand elle l’a appris. La relation a ses propres faits, donc elle devient une chose à part entière : le Tour du chien (Dog Trick), avec le nom du chien en premier en anglais, parce que c’est le chien qui le pilote.
Que signifie chaque trait ? Un propriétaire possède un chien. Un éleveur l’élève. Un chien connaît ses tours. Nommez les traits, et n’importe qui peut vous relire le modèle.
Maintenant, ou dans le temps ? Quelqu’un s’intéresse-t-il au niveau de Bella sur « Assis » aujourd’hui, ou à la façon dont elle y est arrivée ? Si un dresseur la contrôle tous les quelques mois, chaque contrôle est un enregistrement à part entière : une Évaluation de tour, avec la date, le niveau de maîtrise et qui a fait le contrôle, sous le Tour du chien auquel elle appartient. Même une relation devenue une chose peut avoir son propre historique.
Je laisse la Race non reliée pour l’instant. C’est toujours la question du module 1, une boîte à part entière ou un mot sur le chien, et le module 4 la tranche.
Chacune de ces questions fonctionne de la même façon sur un vrai métier. Posons-les maintenant à Steve Trucking.
Demandez « un ou plusieurs ? »
Section intitulée « Demandez « un ou plusieurs ? » »L’une des premières choses que je veux comprendre d’une relation, c’est sa cardinalité. C’est le terme des bases de données ; la question est bien plus simple : combien de ceux-ci peuvent être liés à combien de ceux-là ? Au niveau conceptuel, il y a trois modèles de base.
C’est une étape importante du processus : prendre deux noms différents et comprendre leur relation. Dans la plupart des cas, c’est un un-à-plusieurs, ou un plusieurs-à-un. Ce n’est que dans de rares cas que vous rencontrerez un un-à-un.
Le un-à-plusieurs est partout. Un partenaire distributeur a plusieurs centres de distribution. Un manifeste liste plusieurs livraisons. Une tournée a une dizaine d’arrêts. Quand j’entends ce genre de formulation, je commence à tracer le trait.
Et maintenant le trait reçoit ses marques. Chaque extrémité indique combien de la boîte qu’elle touche : la barre pour un, la patte de corbeau pour plusieurs. Lisez-le depuis chaque boîte : un partenaire distributeur a plusieurs centres de distribution.
Les relations un-à-un existent, mais elles sont rares, et quand j’en trouve une, je pose des questions. S’agit-il vraiment de deux noms différents, ou du même ? S’ils sont différents, quelle est la relation un-à-un entre eux ? Et sera-t-elle toujours un-à-un, ou seulement un-à-un pour l’instant ? Ce sont des questions clés dans la conception du modèle de données. Une équipe et un camion paraissent un-à-un un matin donné : deux personnes, un camion, une tournée. Sur un mois, ce n’est plus le cas, et c’est là que se cache la relation la plus intéressante de ce modèle.
Les relations plusieurs-à-plusieurs sont particulièrement intéressantes, parce qu’elles nous disent souvent qu’il existe un autre concept dans le métier. Une équipe peut-elle conduire plus d’un camion au fil du temps ? Oui. Un camion peut-il être conduit par plus d’une équipe ? Au cours de sa vie, certainement. Les équipes et les camions ont donc une relation plusieurs-à-plusieurs. Mais je veux en savoir plus. Le métier s’intéresse-t-il au moment où une équipe avait un camion ? Pour quelle tournée, quel jour ? Qui a fait l’affectation ? Si la relation elle-même porte une information qui nous intéresse, nous avons découvert un autre concept métier : l’affectation d’équipe (Crew Assignment).
C’est une habitude de modélisation importante. Parfois, la chose la plus intéressante n’est pas l’un des noms entendus au début. Elle se cache dans la relation entre deux noms.
Les relations peuvent devenir des choses
Section intitulée « Les relations peuvent devenir des choses »C’est l’un des endroits où je veux que les administrateurs commencent à penser autrement. Dans Salesforce, nous avons l’habitude de parler d’objets et de champs, donc il est facile de traiter les boîtes comme la partie importante et les traits comme de la tuyauterie. Mais la relation elle-même peut avoir un sens métier.
Prenons une livraison et les produits qu’elle contient. Une livraison peut contenir plusieurs produits, un lave-linge et un sèche-linge par exemple. Un produit, le même modèle de réfrigérateur, apparaît dans des milliers de livraisons. Jusque-là, c’est simple. Mais si j’ai besoin de savoir combien de ce produit sont dans cette livraison, s’il est installé, ou si l’ancien est enlevé ? Je ne m’intéresse plus seulement à une relation entre Livraison et Produit. Je m’intéresse à un article de livraison (Delivery Item), et ce concept mérite sa propre entité.
Si vous venez de Salesforce, vous pensez peut-être déjà : « C’est un objet de jonction. » Vous n’avez pas tort. Mais je ne veux pas commencer par là. Un article de livraison est un concept métier avant d’être un objet de jonction Salesforce. Le métier d’abord, la mise en œuvre ensuite.
Quelques-unes de mes habitudes pour ces entités de relation, où qu’elles finissent par être construites.
Nommez-la. Si le métier a déjà un mot pour elle, utilisez le sien. Sinon, prenez les noms des deux parents et assemblez-les. Pensez à une commande et à un produit. Ce qui se trouve entre les deux, c’est la ligne de commande (Order Item) : la commande, et l’article sur la commande. C’est un enfant des deux parents, et dans Salesforce il pourrait devenir un objet de jonction Salesforce. Mais quel nom vient en premier en anglais : Item Order, ou Order Item ? Regardez de quel type de données est chaque parent. Le produit est une donnée de référence ; la commande est transactionnelle, et c’est la commande qui pilote. Donc c’est Order Item, ou Order Product, de la même façon que Salesforce a Opportunity Product. Chez Steve Trucking, c’est le Delivery Item. Le nom qui pilote vient en premier, et l’enregistrement se range à côté de son propriétaire dans toutes les listes que vous consulterez.
Donnez-lui sa propre clé. Il est tentant de dire qu’un article de livraison est identifié par Livraison plus Produit, et d’en rester là. C’est une clé composée, et les clés composées sont bien plus difficiles à gérer : chaque système qui pointe vers l’enregistrement doit transporter les deux moitiés. Donnez à l’entité de relation son propre identifiant, et gardez Livraison plus Produit comme règle d’unicité, pas comme identité.
Remarquez ce qui n’y figure pas : un numéro de série. Une quantité et un numéro de série n’ont pas leur place sur le même enregistrement. Une quantité compte plusieurs exemplaires d’une chose ; un numéro de série identifie un exemplaire précis. Si le métier a besoin de numéros de série, chaque unité devient son propre enregistrement, et cinq réfrigérateurs font cinq enregistrements. Je ne vois aucun cas justifiant un article de livraison avec un détail d’article de livraison en dessous. C’est l’un ou l’autre : un agrégat avec une quantité, ou un enregistrement par unité. Ici, c’est la quantité.
Surveillez les attributs qui ont besoin d’historique. Certaines entités de relation sont figées une fois créées : le lave-linge de cette livraison reste le lave-linge de cette livraison. D’autres changent sans cesse. Une équipe a le camion 117 cette semaine, et la semaine prochaine le camion passe à une autre équipe. Quand la relation change et que le métier s’intéresse à ce qu’elle était, l’entité de relation a besoin de dates, et c’est l’affectation d’équipe qu’il faut surveiller. Demandez tôt si le métier s’intéresse à maintenant ou dans le temps ; nous y reviendrons dans un instant.
Les relations ont un sens au-delà de la cardinalité
Section intitulée « Les relations ont un sens au-delà de la cardinalité »« Un-à-plusieurs » ne suffit pas pour comprendre une relation. Je veux aussi savoir ce que la relation signifie.
Une livraison a un lieu. Lequel ? Le centre de distribution d’où elle part ? Le domicile du destinataire où elle va ? Ils ne sont pas interchangeables. Deux modèles peuvent avoir exactement les mêmes boîtes et la même cardinalité, et les traits peuvent signifier des choses complètement différentes. C’est pourquoi un bon modèle n’est pas juste des boîtes reliées par des traits. Les traits ont besoin de noms. Si je remets mon schéma à un autre architecte, il ne devrait pas avoir à deviner ce que signifie une relation, et si je le montre au métier, il devrait utiliser un langage qu’il reconnaît.
Le caractère facultatif compte aussi
Section intitulée « Le caractère facultatif compte aussi »Une autre question se cache dans « combien ? » : la relation est-elle obligatoire ? Une livraison peut-elle exister avant d’avoir été placée dans une tournée ? Elle le doit : le manifeste arrive un ou deux jours avant la livraison, et les tournées sont finalisées la veille au soir. Une livraison peut-elle exister sans partenaire distributeur ? Non ; chaque livraison vient du manifeste d’un partenaire. C’est le caractère facultatif.
Encore une fois, ne sautez pas directement à une case Obligatoire dans Salesforce. Il y a une différence entre dire « chaque livraison doit avoir un partenaire distributeur » et dire « Salesforce doit exiger le champ partenaire distributeur à la création de l’enregistrement ». Elles peuvent finir par la même mise en œuvre, mais ce n’est pas la même affirmation. La première est une règle métier ; la seconde est une façon de l’appliquer. En tant qu’architectes, nous voulons comprendre la première avant de décider la seconde.
Sur le schéma, le caractère facultatif est la deuxième marque à chaque extrémité. La marque la plus proche de la boîte est le maximum : la barre pour un, la patte de corbeau pour plusieurs. La marque suivante est le minimum : une autre barre signifie au moins un, un cercle signifie qu’il peut n’y en avoir aucun. Ainsi, chaque livraison figure sur exactement un manifeste, et un manifeste liste une ou plusieurs livraisons. Une livraison est à zéro ou un arrêt, aucun tant qu’elle n’a pas été placée dans une tournée, et un arrêt dépose zéro ou plusieurs livraisons.
Le temps change les relations
Section intitulée « Le temps change les relations »Voici une question que je pose souvent : vous voulez dire maintenant, ou dans le temps ?
Une équipe conduit un camion. En ce moment ? Pour la tournée d’aujourd’hui ? Aussi longtemps que ces deux personnes travaillent ensemble ? Cela donne des modèles différents. Si le métier ne s’intéresse qu’au camion qu’une équipe a aujourd’hui, le modèle peut rester simple. S’il a besoin de chaque camion qu’une équipe a conduit, quand, et sur quelle tournée, il nous faut de l’historique, et cette affectation d’équipe que nous avons découverte devient soudain très importante.
C’est une source courante d’erreurs de modélisation. Nous modélisons l’état actuel parce que c’est ce que nous voyons à l’écran. Puis, des semaines plus tard, un partenaire distributeur dépose une réclamation pour dommage et quelqu’un demande : « Quelle équipe avait le camion 117 le 17 mars ? » Et nous découvrons que nous avons écrasé la réponse à chaque changement d’affectation.
Une façon de garder cet historique est de faire de l’affectation un enregistrement à part entière. Quand une équipe est affectée, nous créons une affectation d’équipe avec une date de début. Quand l’affectation change, nous mettons une date de fin sur l’ancien enregistrement et en créons un nouveau avec sa propre date de début. Maintenant, « qui avait cette affectation il y a six mois ? » est une question simple, au lieu de fouiller l’historique des champs ou un journal des modifications de données. Et une fois qu’une équipe a eu de nombreuses affectations, quelqu’un demandera laquelle est l’actuelle, donc j’ajouterais aussi un indicateur Actif.
Alors, quand quelqu’un me parle d’une relation, je ne demande pas seulement comment les choses sont liées. Je demande : cette relation change-t-elle, et son historique nous intéresse-t-il ?
Dessinez avant de configurer
Section intitulée « Dessinez avant de configurer »Notre modèle Steve Trucking devient utile. Nous savons quelles relations sont un-à-plusieurs, où un plusieurs-à-plusieurs cache un autre concept, quelles relations sont facultatives, et lesquelles changent dans le temps. Et nous n’avons toujours pas créé d’objet Salesforce. C’est voulu.
Ce schéma devrait être quelque chose que je peux montrer au métier, et il ne devrait pas avoir besoin de connaître Salesforce pour me dire s’il est juste. S’il ne peut pas le valider parce qu’il est plein de terminologie Salesforce, je suis passé trop vite à la conception physique.
Ce que l’architecte décide ici
Section intitulée « Ce que l’architecte décide ici »Quand je travaille les relations d’un modèle conceptuel, je décide :
- Comment les principales entités métier sont liées entre elles.
- Si chaque relation est un-à-un, un-à-plusieurs ou plusieurs-à-plusieurs, maintenant et dans le temps.
- Si chaque relation est obligatoire ou facultative.
- Si une relation plusieurs-à-plusieurs cache un concept métier significatif.
- Si la relation change dans le temps, et si nous avons besoin de son historique.
Référence ou principal-détails, configuration de la jonction, comportement en cascade et partage sont des décisions physiques ; nous y viendrons. Pour l’instant, nous répondons encore à la question la plus importante : comment cette activité fonctionne-t-elle réellement ? Une fois que nous comprenons les entités et les relations entre elles, nous pouvons commencer à ajouter les détails qui les décrivent. C’est là que notre modèle conceptuel commence à devenir un modèle de données logique.