Partie 2 - Comment organiser un grand diagramme de base de données

Dans la partie 1 de cette série, nous avons importé avec succès la structure de la base de données SuiteCRM dans notre outil de modélisation de base de données en ligne. C'est alors que nous avons vu que le modèle contient 201 tables sans relations entre elles. Nous avons eu un tas de tables sauvages qui avaient l'air vraiment en désordre. Dans cet article, je vais vous montrer comment organiser un si grand modèle.

Juste après l'importation dans Vertabelo, le modèle de base de données SuiteCRM se présente comme suit :

Le modèle fonctionne – mais pas efficacement. Nous devrons le modifier pour le rendre vraiment utile. Puisque nous voulons analyser la base de données SuiteCRM après actions sont effectuées sur son interface graphique, nous devons comprendre les définitions de table et les relations entre les tables. Commençons par regrouper les tableaux par domaines et par établir les relations les plus importantes.

Vertabelo propose trois outils principaux pour vous aider à organiser de grands diagrammes :

• Domaines
• Raccourcis pour les tableaux et les vues
• Raccourcis de référence

Je les décrirai plus tard dans cet article, mais vous pouvez également en savoir plus en regardant cette vidéo.

Étape 1. Désactiver la génération automatique de clés étrangères

Tout d'abord, nous allons désactiver la génération automatique de clés étrangères. Par défaut, Vertabelo génère des attributs de clé étrangère lorsque nous extrayons des relations d'une table primaire vers une table référencée. C'est généralement une bonne chose, mais pas ici. Nous avons déjà des attributs qui représentent des clés étrangères. Ce qui nous manque, ce sont les relations "réelles" entre les tables. Pour désactiver cette option, cliquez sur "Mon compte" dans le menu du haut et recherchez les "Préférences personnelles" rubrique.

L'option est désactivée. Maintenant, lorsque nous traçons une ligne de référence entre les tables, la ligne est créée - mais nous devrons spécifier quels attributs sont utilisés, à la fois du côté primaire et du côté étranger.

Étape 2. Regrouper les tableaux préfixés avec des domaines

Ensuite, regroupons quelques tables. Nous le ferons en utilisant la zone Objet outil qui permet d'associer des tables en fonction de critères sélectionnés. Dans notre cas, nous essayons d'identifier les tables qui sont liées ou qui font partie du même processus. Cela se traduira par des groupes tels que "Appels", "Réunion" et "Campagnes".

Nous pouvons créer un domaine en cliquant sur "Ajouter un nouveau domaine" icône dans la boîte à outils :

puis en dessinant un rectangle sur notre modèle :

Le domaine est créé. Nous pouvons le voir dans la "Structure du modèle" panneau de gauche :

Chaque domaine contient une liste de tous les objets qui se trouvent à l'intérieur de ses frontières; dans ce cas, il s'agit de tables et de types de références.

Dans SuiteCRM, de nombreuses tables partagent un préfixe commun. J'ai donc commencé à regrouper les tables préfixées. Jetez un œil aux tables « acl » à titre d'exemple. Dans le panneau "Structure du modèle", j'ai trouvé toutes les tables dont les noms commençaient par "acl_" :

Ensuite, j'ai créé le domaine "acl" dans le modèle et y ai fait glisser toutes les tables appropriées. (Pour une meilleure visibilité, j'ai défini la couleur d'arrière-plan sur violet.)

Maintenant, nous pouvons maintenant voir le groupe "acl", avec une liste de toutes les tables qui lui appartiennent, sous "Domaines" dans la "Structure du modèle" :

J'ai répété la même procédure pour toutes les tables préfixées restantes.

Étape 3 :Disposez les tables restantes.

La même table deux fois dans le diagramme ? Raccourcis de tableau !

Il y a environ 80 tables préfixées. Après les avoir regroupés, il me restait environ 120 tables "sauvages". Ceux-ci sont significatifs :ils stockent des informations sur les utilisateurs, les clients, les appels, les réunions et d'autres éléments CRM. C'est beaucoup d'informations à garder en vue, alors trions ces tableaux.

La fonctionnalité que j'ai trouvée la plus utile pour organiser ces tableaux s'appelle les raccourcis de tableau . Parfois, vous souhaitez utiliser la même table plusieurs fois dans un modèle. (Pourquoi ? Pour aplatir le modèle et éviter les chevauchements.) Nous pouvons facilement le faire en utilisant le "Copier" et "Coller comme raccourci" boutons.

Sélectionnez simplement la table pour laquelle vous souhaitez créer un raccourci et cliquez sur "Copier" dans la barre d'outils supérieure (ou appuyez sur Ctrl + C ):

Pour créer un raccourci, cliquez sur "Coller comme raccourci" (ou appuyez sur Ctrl + K ). Après cela, un nouveau tableau avec un contour en pointillé apparaîtra :

Ce n'est pas une copie de la table, mais une autre instance de la table d'origine. Nous pouvons le placer n'importe où dans notre modèle. J'ai utilisé des instances du même tableau dans différents domaines pour éviter le chevauchement des références. Il est intéressant de mentionner que chaque instance de table a un nom de domaine attribué (à côté de son nom) tant qu'elle se trouve à l'intérieur de ce domaine.

Un bon exemple de la façon dont cela fonctionne est le users table. Il peut être trouvé dans « Utilisateur et comptes », « Rôles », « Documents » et d'autres domaines. Nous verrons cela plus tard dans le modèle.

J'utilise beaucoup les raccourcis de tableau lors de la création de domaines avec des relations établies entre les tableaux. Pour voir comment cela fonctionne, consultez le domaine "Opportunités" ci-dessous. Notez que toutes les tables de ce domaine sont nommées selon cette règle :{table name} :{subject area name} .

Lorsque nous développons le {subject area name} dans le panneau "Structure du modèle", on voit clairement qu'il contient des tables et des références :

Je l'ai fait pour les domaines suivants :"Appels", "Requêtes", "Campagne", "Contacts", "Documents", "Rencontre et prospects", "oauth", "Projets", "Prospects et marketing par e-mail", « Rôles » et « Utilisateurs et comptes ». Toutes ces zones partagent un fond bleu clair.

Les tables restantes sont regroupées en fonction de leur nom et de leur signification présumée :"E-mails", "Utilisateurs (extra)" et "Autres tables". Ces groupes ont leur couleur d'arrière-plan définie sur rouge clair.

Le modèle arrangé

J'ai utilisé les options décrites précédemment pour aplatir le modèle autant que possible tout en regroupant les tables logiquement. Le résultat est 26 domaines, dont certains ne contiennent que des tableaux tandis que d'autres ont des tableaux et des relations. Passons en revue rapidement chaque catégorie :

Domaines contenant des tableaux et des relations :

"Appels", "Campagnes", "Requêtes", "Contacts", "Documents", "Rencontres et leads", "Opportunités", "Projets", "Prospects et email marketing", "Rôles", "Utilisateurs et comptes"

Toutes les relations sont définies comme non obligatoires. Cela conserve les informations que ces tables sont liées et via quel(s) attribut(s).

Domaines contenant uniquement des tableaux :

"acl", "am", "aod", "aok", "aop", "aor", "aos", "aow", "Emails", "fp", "jwg", "oauth", "security_groups" ”, “Utilisateurs supplémentaires”

Cela ne signifie pas que les relations n'existent pas ici; ils ne sont tout simplement pas mis en valeur.

Le domaine "Autres tableaux" est destiné aux tableaux qui ne correspondent pas vraiment à un groupe spécifique.

À quoi ressemble le modèle ?

Le modèle réorganisé ressemble à ceci :

Évidemment, une convention de nommage a été utilisée. Voici un aperçu des directives que nous avons suivies :

1. Les noms de table sont généralement au pluriel :users , contracts , folders , roles , tasks . Certains noms de table sont au singulier, comme project .
2. La clé primaire dans la plupart des tables s'appelle simplement id et est un type char(36).
3. Lorsqu'une relation un-à-plusieurs se produit, la clé étrangère est généralement nommée parent_id . (Exemple :contacts_audit.parent_id est une référence à contacts.id .)
4. Dans les relations plusieurs-à-plusieurs, "parent_id " ne peut pas être utilisé comme nom pour plusieurs colonnes. Au lieu de cela, un nom de table singulier avec le suffixe "_id" est utilisé. (Exemple :contacts_bugs.bug_id fait référence à bug.id .)
5. Dans certaines situations, la même colonne est utilisée comme clé étrangère pour plusieurs tables. (Exemple :calls.parent_id fait référence à la colonne id dans chacune des tables suivantes :accounts , bugs , cases , contacts , leads , tasks , opportunities and prospects . Je n'ai pas vérifié les valeurs dans la base de données, mais je suppose qu'il n'y a pas les mêmes valeurs de clé dans ces tables. Comme tous sont de type char(36), une combinaison de nom de table et d'auto-incrémentation est probablement utilisée. Nous vérifierons cela dans les prochains articles.)
6. Nous utilisons les mêmes noms pour les colonnes qui ont la même signification dans différentes tables. (Exemple :modified_user_id , created_by et assigned_user_id peuvent être trouvés dans de nombreux tableaux du modèle. Tous sont référencés à users.id .)

Quelle est la prochaine ?

Dans les prochains articles, nous utiliserons l'interface graphique de SuiteCRM et garderons un œil sur les changements que cela entraîne dans la base de données. Avec ces informations, nous essaierons d'apporter des modifications au modèle, de réorganiser les domaines et d'établir des liens si nécessaire. Nous chercherons également d'autres règles spécifiques à SuiteCRM, telles que la manière dont les clés primaires sont générées.

La gestion de diagrammes de base de données volumineux n'est jamais une tâche facile. Tout comme construire une bonne fondation pour une maison, passer plus de temps sur les fondamentaux maintenant apportera des avantages plus tard. Si nous voulons analyser des modèles comme celui derrière SuiteCRM, analyser avant d'avoir organisé la structure du modèle et défini les relations entre les tables, c'est le faire à la manière de Sisyphe.