Conception de modèles de données et bonnes pratiques : Partie 2

Qu'est-ce qu'un modèle de données ? En tant que développeurs Talend, nous le côtoyons jour après jour et nous pensons pouvoir le définir :

• une définition structurelle des données d'un système métier 
• une représentation graphique des données métiers 
• un socle de données sur lequel nous créons des solutions métiers 

Si toutes ces affirmations peuvent être vraies, à mon avis, ce sont des définitions accessoires car, prises séparément, elles ne tiennent pas compte de la racine ou la finalité, voire de la raison d’être d'un modèle de données.

Donc, qu'est-ce qu'est VRAIMENT un modèle de données ? Je pense que c'est à la fois beaucoup de choses et une chose bien particulière. Pour moi, un modèle de données est un socle structurel, représenté sous la forme d'une caractérisation graphique bien définie d'un système d'informations métier. Qu'en pensez-vous ? Que c'est la même chose que les définitions données plus haut, pas vrai ? Et bien, pas vraiment. Cette définition regroupe tous les éléments dans un seul objectif ; c'est un moyen d'identifier sur un plan structurel les informations relatives à un cas d'usage métier et pas seulement ses données.

Dans la Partie 1 de cette série d'articles de blog, j'ai résumé 50 ans d'histoire de la modélisation de données en 4 courts paragraphes. J'ai bien évidemment omis quelques détails, mais j'estime que les enseignements tirés de nos prédécesseurs et des progrès qu'ils ont réalisés nous aident à comprendre comment nous en sommes arrivés là, tant au niveau des connaissances que de nos pratiques dans le domaine de la modélisation des données. Aujourd'hui, la plupart des entreprises utilisent des modèles de données pour valider les besoins, ce qui constitue en soi une vraie valeur métier, mais je me demande souvent si elles savent comment s'y prendre. Bien souvent, elles s'imaginent que, parce qu'elles ont mis en place un modèle de données, il sera durable, alors même qu'elles ne savent pas et n'ont pas vérifié si c'était le bon.

En tant que spécialiste de l'architecture de données et de la conception de bases de données, j'ai vu tant de mauvais modèles de données que je me dois d'avancer que la plupart sont probablement erronés dans une certaine mesure. J'en ai néanmoins vu beaucoup de bien. Alors comment savoir si un modèle de données est bon ou mauvais ? Pourquoi devrions-nous nous en préoccuper ? Tant que les données entrent et sortent, ça suffit, non ? La réponse est un NON catégorique. Les modèles de données doivent être bons voire excellents pour garantir le succès des systèmes métiers qui s'appuient dessus. Le modèle de données est l'essence même du métier et doit par conséquent être complet, irréprochable et résilient.

L'intérêt d'un bon modèle de données est évident. Une fois que l'on commence à faire entrer et sortir des données avec des outils ETL/ELT comme Talend Studio, on s'en rend vite compte (la plupart d'entre nous, en tout cas). Je pense que le modèle de données est l'un des trois éléments techniques cruciaux de tout projet logiciel, les deux autres étant le code d'application et l'interface utilisateur.

J'imagine que vous avez également découvert dans la Partie 1 la méthodologie de cycle de vie du développement des bases de données (DDLC) que j'applique à chaque modèle de données que je conçois. Cette méthodologie m'a bien aidé et je la recommande vivement à toute équipe de développement de bases de données sérieuse. La compréhension et l'adoption de ce processus peuvent permettre de rationaliser, d'automatiser et d'améliorer toute mise en œuvre et maintenance d'un modèle de données. Pourtant, ce processus comporte d'autres aspects que nous nous devons étudier. Je vais vous présenter d'autres bonnes pratiques pouvant contribuer à créer un modèle de données fiable, souple et précis pour votre entreprise.

Conception de modèles de données et bonnes pratiques

De nombreux modèles de données sont conçus selon un processus bien particulier : le modeleur crée un modèle logique, puis un modèle physique. En général, les modèles logiques décrivent des entités et des attributs et les relations qui les lient, offrant ainsi une représentation claire de la finalité des données dans le métier. Les modèles physiques mettent ensuite en œuvre le modèle logique sous forme de tables, de colonnes, de types de données et d'index, associés à de brèves règles d'intégrité des données. Ces règles définissent les clés primaires et étrangères et les valeurs par défaut. En outre, des vues, des déclencheurs et des procédures stockées peuvent être définis afin de faciliter la mise en œuvre, au besoin. Le modèle physique définit également l'allocation de mémoire sur le disque sur la base des options de configuration fournies par la plupart des systèmes hôtes (Oracle, MS SQL Server, MySQL, etc.).

Nous sommes d'accord ? Pourtant, j'ai souvent participé à des discussions enflammées portant sur la différence entre un modèle logique et un modèle conceptuel. Beaucoup m'ont laissé entendre que c'était la même chose, car ils présentent tous les deux des entités et des attributs des données métiers. Je ne suis absolument pas d'accord ! Le modèle conceptuel vise à fournir un contexte pour comprendre les données, contexte qui n'est cependant pas technique. Toutes les parties prenantes peuvent comprendre un modèle conceptuel, mais beaucoup ont du mal avec les entités et les attributs. Je crois que le modèle conceptuel, s'il est bien conçu, est le MEILLEUR outil de communication des données métiers pour toutes les parties concernées. Je préfère utiliser des éléments du langage ULM (Unified Modeling Language) pour schématiser un modèle conceptuel simple, sans me perdre dans des détails. Je laisse ça aux modèles logique et physique dans lesquels ces détails sont cruciaux et minutieux.

L'entreprise, du fait qu'elle dispose souvent d'un grand nombre de systèmes d'application, suscite des préoccupations plus importantes lors de la modélisation des données. J'ai constaté que, malgré tout, les modèles conceptuel, logique et physique ne suffisent tout simplement pas. C'est là qu'entre en jeu : le modèle de données global ou, tout du moins, l'adaptation que j'en ai faite !

L'objectif du modèle de données global est d'identifier et d'abstraire les silos de données au sein d'une entreprise, en résumant ce qui existe ou est nécessaire, les relations entre les silos et comment les organiser pour en tirer le meilleur parti, au plus haut niveau.

Les 4 niveaux du processus de modélisation des données

Étant donné qu'une entreprise peut être amenée à traiter 4 types de données différents, je propose d'observer le processus de modélisation des données suivant, sous forme de « niveaux » descendants destinés à la définition, à l'amélioration de la compréhension et à des fonctions de conception spécifiques. Des rôles clés à chaque niveau identifient les personnes participant au processus et à quel stade elles interviennent.

Modèle de données global :

Le niveau global représente un paysage abstrait de silos de données couvrant l'ensemble de l'entreprise. Ce modèle de données est l'occasion de mettre en place une gouvernance des données métiers généralisée, ce qui permet de mieux comprendre l'ensemble des liens inhérents à l'entreprise qui existent entre les données. Le but est de pouvoir intégrer des données provenant de n'importe quelle application, qu'elle soit interne ou externe. J'utilise un graphique à bulles pour représenter le modèle de données global. Voici comment je procède :

Graphiques à bulles – Silos de données

Le graphique à bulles est constitué de simples bulles représentant des silos de données uniques. Les lignes (appelées liens) reliant deux bulles (et pas plus) indiquent qu'il existe une forme de relation entre elles. Pour l'essentiel, chaque ensemble de bulles (souvent conçu avec un « hub » central d'où partent des rayons), représente un groupe précis de silos de données identifié dans l'entreprise, ni plus, ni moins. Quelques précisions concernant les spécifications :

Les liens BLEUS pleins signalent des relations directes entre deux silos de données. Les liens ROUGES en pointillés signalent des relations indirectes entre deux silos de données. Les liens VERTS formés de points signalent des relations élargies entre deux silos de données. Utilisez ces liens de façon subjective, car ils peuvent représenter plusieurs relations (qui seront définies dans la couche conceptuelle). Ils indiquent simplement qu'il existe une relation.

Une bulle est parfois entourée par une bulle de plus grande taille. Ces bulles plus grandes signalent qu'il existe (ou devrait exister) une ontologie organisant une taxonomie propre à ce silo de données. Les ontologies et leurs métadonnées de taxonomie offrent au silo qu'elles entourent des mises en correspondance pertinentes. Elles sont très utiles pour créer des données pouvant facilement faire l'objet d'une recherche et doivent être identifiées à ce niveau.

Les graphiques à bulles définissent certains ensembles d'informations métiers. L'objectif est d'identifier, de simplifier et de consolider des informations ne figurant pas dans les détails techniques ou les détails de l'application ou de l'implémentation qu'elles appuient. Le modèle de données global présente un avantage : tous les publics peuvent comprendre le paysage des données de l'entreprise à partir d'une unique vue simple mais pourtant globale. Cette vue peut être utilisée, en toute souplesse, pour identifier et insérer de nouvelles données dans le modèle, avec peu voire pas de perturbation pour les modèles de données sous-jacents (ce point sera abordé plus bas).

Voici un exemple de modèle de données global entièrement défini. Imprimez-le EN GRAND et accrochez-le au mur. Il pourra donner lieu à de nombreuses discussions productives et devenir un atout précieux et efficace pour votre entreprise.

Modèle de données conceptuel :

La couche conceptuelle constitue une définition abstraite des éléments de données métiers et de leurs relations. Ce modèle de données définit la sémantique du paysage de données de l'entreprise du point de vue des applications et permet de mieux comprendre les informations métiers sous-jacentes. Le langage UML offre les moyens graphiques permettant de concevoir ce modèle. Composé d'objets d'éléments, le modèle de données conceptuel définit une classe d'informations déduit d'un silo de données dans le modèle global. Pour l'essentiel, vous pouvez voir cela comme un modèle CIM. Voici comment je procède :

Architecture d'information avec UML

Chaque objet d'élément encapsule une partie bien précise d'un silo de données ainsi que les lignes de connexion (aussi appelées liens) qui définissent des relations particulières entre deux éléments (une fois encore, pas plus de deux). Certaines parties d'élément (appelées caractéristiques) sont définies de façon à faciliter encore davantage la compréhension de la finalité de l'objet. Ces caractéristiques sont les suivantes :

• Protégé (les valeurs sont prédéterminées)
• Public (les valeurs sont mutables)
• Privé (l'utilisation des valeurs est restreinte)

Les objets d'éléments reliés directement les uns aux autres sont considérés comme ayant une « association » qui est indiquée par un lien GRIS plein et des étiquettes. L'utilisation, en lien avec ces associations, d'un losange à côté de l'élément parent signale des relations de l'un des types suivants :

• Simple (pas de losange)
• Partagée (losange vide)
• Composite (losange plein)

Un élément enfant peut également être « navigable ». Dans ce cas, il est signalé par une flèche accompagnée d'une cardinalité relationnelle (0.* = de zéro à plusieurs, etc.).

Les objets d'éléments peuvent aussi avoir des « généralisations », c’est-à-dire qu'une instance d'un objet peut avoir des caractéristiques et/ou des relations particulières ou uniques. Dans cette représentation, l'objet est davantage une sous-classe d'un élément parent comportant toutes ses caractéristiques PLUS toute caractéristique unique supplémentaire. Le nom et la représentation de l'élément de la sous-classe est affinée de façon à fournir un affinement compréhensible au niveau du silo de données global abstrait. Les généralisations associées aux objets d'éléments sont signalées par des liens BLEUS pleins et une flèche fermée liée à l'objet parent. Aucune étiquette n'est requise.

Les connexions entre des sous-classes définissent plus précisément les relations qui sont utiles pour comprendre le modèle de données conceptuel qu'elles représentent. Des sous-classes généralisées connectées à d'autres sous-classes généralisées du même objet parent sont considérées comme ayant une « association » qui est signalée par un lien VERT plein et des étiquettes. Ces relations peuvent être « navigables ». Dans ce cas, elles sont signalées par une flèche ouverte accompagnée d'une cardinalité relationnelle (0.* = de zéro à plusieurs, etc.).

Dans le diagramme UML, les éléments peuvent avoir des associations avec des jointures réflexives (des caractéristiques spécifiques qui étendent la définition d'un objet parent) et/ou des « associations » entre des caractéristiques spécifiques. Les extensions spécifiques ne représentent pas une classe ou une généralisation, mais identifient des caractéristiques pertinentes appelées pour permettre une meilleure compréhension du silo de données abstrait. La connexion entre des caractéristiques spécifiques et un élément est signalée par un lien ROUGE plein et une étiquette. En outre, les caractéristiques d'un élément peuvent se connecter aux caractéristiques d'un autre élément du même objet (signalé par des liens VERTS semblables à ceux des généralisations associées). Ces relations peuvent également être « navigables ». Dans ce cas, elles sont signalées par une flèche ouverte facultative accompagnée d'une cardinalité relationnelle (0.* = de zéro à plusieurs, etc.).

Le modèle de données conceptuel décrit des éléments de données particuliers à l'aide d'une métaphore basée sur la classe, idéalement schématisée à l'aide d'UML, qui explique plus précisément les silos de données globaux abstraits. L'objectif est de définir, d'affiner et de limiter les informations métiers, indépendamment de toutes applications, règles d'implémentation ou informations techniques, et d'encapsuler les informations ignorées par le modèle global.

Une fois encore, imprimez ce modèle EN GRAND et notez qu'il représente une interface commune sur laquelle le code d'application peut être écrit sans les modèles de données logique ou physique qui viennent après. Cela peut constituer un point de validation sur la base duquel auxquels ces modèles de données sont conçus. La validation du modèle UML par les ingénieurs logiciels et les parties prenantes est une étape clé du processus de modélisation des données. Voici un exemple d'une partie d'un modèle de données conceptuel.

Remarque : ce modèle comporte des « sous-éléments » qui définissent certains aspects de l'« élément principal », expliquant ainsi certaines caractéristiques uniques et récurrentes.

Modèle de données logique :

La couche logique représente une structure abstraite d'informations sémantiques organisées en entités de domaine (objets de données logiques), leurs attributs et certaines relations les liant. Ce modèle de données qui est déduit des objets d'éléments du modèle conceptuel, définit des informations pertinentes (clés/attributs) et les relations entre les entités, et ce indépendamment de toute technologie de stockage hôte. Les entités peuvent représenter un élément unique, une partie d'un élément ou plusieurs éléments, selon ce qui est nécessaire pour encapsuler des structures de données adaptées. Le modèle de données logique encapsule les entités structurelles et enregistre les ensembles identifiés dans le modèle conceptuel en ajoutant des attributs spécifiques, ce qui permet de mieux comprendre les données concernées. Voici comment je procède :

DER

Les diagrammes d'entité-relation ou DER décrivent des entités identifiables de façon unique et capables d'existence indépendante qui requièrent un ensemble minimum d'attributs d'identification uniques appelé clé primaire (PK sur le diagramme). Si une entité enfant est liée à une entité parent, l'intégrité des données référentielles peut et même doit être appliquée par le biais d'un attribut d'identification dans l'entité enfant qui correspond aux attributs Clé primaire de l'entité parent. Cet attribut est appelé clé étrangère (FK sur le diagramme). Mais vous savez déjà tout ça.

Le cas échéant, des entités peuvent être reliées pour montrer la nature d'un jeu d'enregistrements ou la relation de cardinalité entre deux entités ou plus. Les entités avec des liens peuvent utiliser la technique de notation en patte de corbeau largement utilisée pour les diagrammes d'entité-relation (DER). La notation en patte de corbeau appropriée, qui est signalée par des liens BLEUS pleins, des deux côtés doit également comporter une étiquette décrivant le jeu d'enregistrements qu'elle représente. Ces liens d'entité présente une cardinalité spécifique expliquant le nombre d'enregistrements autorisé d'un jeu d'enregistrements. Ces notations indiquent les informations suivantes : zéro, une ou beaucoup (de lignes) ou une combinaison obligatoire.

La cardinalité n’est soumise qu’à deux règles : le nombre minimum et le nombre maximum de lignes pour chaque entité pouvant participer à une relation, la notation la plus proche de l’entité correspondant au nombre maximum. L'indication d'une cardinalité pour un jeu d'enregistrements suggère également que la relation est facultative ou obligatoire, ce qui simplifie la conception du modèle de données physique.

Un DER peut prendre en charge les liens de plusieurs entités, y compris des liens avec des jointures réflexives. Les entités ne doivent pas être confondues avec des tables ; toutefois elles peuvent souvent être mises en correspondance avec des tables dans un modèle de données physique (voir ci-dessous). Au contraire, les entités logiques sont des abstractions structurelles qui mettent l'accent sur des représentations simplifiées du modèle de données conceptuel.

Le modèle de données logique présente l'abstraction sémantique du modèle de données conceptuel en apportant des informations à partir desquelles un modèle de données physique peut être conçu. Cette particularité peut aider les ingénieurs de services d'application et les ingénieurs de bases de données, en leur permettant de comprendre non seulement la structure de données abstraite mais aussi les exigences concernant les transactions de données. Voici un exemple de modèle de données logique partiel.

Veuillez noter quelques points. J'ai utilisé des couleurs pour représenter les différentes zones fonctionnelles qui peuvent permettre d'établir les modèles conceptuel et global. J'ai aussi intégré une relation « virtuelle » entre ENTITY_D et ENTITY_C (indiquée par un lien GRIS CLAIR). Elle identifie l'existence d'une relation logique. Toutefois, la construction entre ces deux entités plus ENTITY_B représentent une « référence circulaire » qu'il faut éviter à tout prix dans le modèle physique. Notez également qu'un petit nombre d'attributs définissent un large éventail de valeurs. Cela ne pose pas de problème dans le modèle logique car cela le simplifie et le rationalise. Assurez-vous juste de les normaliser dans le modèle physique.

Modèle de données physique :

La couche physique représente une composition d'artefacts (objets de données physiques) du système hôte déduite d'un modèle de données logique, associée à la configuration de stockage souhaitée. Ce modèle de données intègre des tables, des colonnes, des types de données, des clés, des contraintes, des autorisations, des index, des vues et des informations sur les paramètres d'allocation disponibles dans le magasin de données (voir mon article de blog « Beyond the Data Vault » pour de plus amples informations sur les magasins de données). Ces artefacts de l'hôte représentent le modèle de données sur la base duquel les applications logicielles sont créées. Le modèle de données physique encapsule tous ces artefacts provenant d'entités et d'attributs définis dans le modèle de données logique, permettant enfin un accès application afin de stocker et récupérer des données réelles. Voici comment je procède :

SDM

Un modèle SDM (Schema Design Model) (physique) définit les objets impliqués dans un système informatique de base de données. Je vais partir du principe que la plupart de mes lecteurs connaissent davantage ce modèle de données que les trois précédents. Je vais donc éviter de décrire les constructions. Je préfère appeler ce modèle SDM afin d'éviter toute confusion avec le terme plus largement utilisé « DER » qui n'est PAS un modèle de données physique. Le modèle SDM offre plutôt une référence pour les ingénieurs, souvent représentée par le graphique et un document Dictionnaire des données. Parce qu'il offre une référence détaillée essentielle à chaque objet de base de données mis en œuvre dans le modèle SDM, ce document doit comprendre leur objectif, les règles d'intégrité référentielles, ainsi que d'autres informations importantes sur les comportements prévus. Voici une bonne structure que j'ai l'habitude d'utiliser :

• Nom et définition d'objet (tables/vues)
  • Nom du fichier de création/modification d'objets SQL
  • Domaine métier et utilisation fonctionnelle
  • Version/niveau d'intégrité
  • Colonnes/types de données/taille
  • Possibilité de valeur Null
  • Valeurs par défaut
  • Clés primaires
  • Clés étrangères
  • Clés métiers naturelles
  • Contraintes uniques
  • Contraintes de validation
  • Index uniques et non uniques (cluster et non cluster)
• Flux de contrôle (en cas de conception/utilisation bien plus complexes)
• Remarques utiles
• Historique des modifications

Un dictionnaire des données SDM référence les objets dans l'ordre alphabétique de leur nom, pour une grande facilité d'utilisation. Comme la plupart des modèles de données physiques sont fortement normalisés (reportez-vous à la Partie 1 de cette série si vous ne l'avez pas déjà lue), des règles d'intégrité référentielles doivent être appelées pour chaque table. D'après mon expérience, il y a de nombreuses façons de traiter ces règles, en particulier lors de l'exécution de scripts d'objets SQL par rapport à un schéma existant. Il suffit de désactiver les vérifications de l'intégrité, d'exécuter les scripts puis de les réactiver. C'est relativement simple mais je ne suis pas un adepte de cette méthode, car elle est source d'erreurs.

Je préfère prendre le temps de comprendre les références à toutes les tables et d'attribuer un niveau d'intégrité à chacune. Le « niveau d'intégrité » d'une table identifie l'organisation hiérarchique des relations entre les tables parent/enfant. En résumé, le « niveau d'intégrité » d'une table est basé sur n'importe quelle référence Clé étrangère à une ou plusieurs tables parents. Par exemple :

• Une table sans table parent est une table N0 ou de niveau 0 (niveau le plus élevé).
• Une table avec au moins une table parent est une table N1 ou de niveau 1.
• Une table avec au moins une table parent ayant elle-même une table parent N0 est une table N2 ou de niveau 2.
• Une table avec plusieurs tables parents ayant elles-mêmes des tables parents de différents niveaux utilise le niveau le plus bas +1
  • c.-à-d. : si la table parent A est une table N0, la table parent B est une table N1, alors la table enfant est une table N2 ou : si la table parent A est une table N1, la table parent B est une table N4, alors la table enfant est une table N5.
• etc.

REMARQUE : N0 est le niveau le plus élevé, car il n'y a pas de tables parents. Le niveau le plus bas est déterminé par le modèle de données physique. Cette méthode supprime également le risque de création de références circulaires (une bien mauvaise pratique en matière de conception de modèles de données, à mon humble avis).

Le modèle de données physique est le seul modèle étant mis en œuvre. Je préfère utiliser des scripts de création d'objets SQL (SCOS) pour cette implémentation. J'ai découvert, à force d'utiliser cette méthode, que le DDLC (ou cycle de vie du développement des bases de données) de n'importe quel modèle de données physique peut être dissocié comme un processus indépendant, ce qui est très difficile à faire, bien que cela soit souhaitable. L'idée est de créer un fichier SCOS pour un objet de base de données primaire (Table, Vue, Déclencheur ou Procédure stockée). Ces scripts contiennent des vérifications intelligentes visant à déterminer quelles instructions SQL doivent être appliquées (Drop, Create, Alter, etc.) et peuvent, par le biais de commutateurs et d'arguments, tenir compte des étapes du cycle de vie abordées dans mon précédent article. Ces étapes sont les suivantes :

• Une nouvelle INSTALLATION en fonction de la version actuelle du schéma
• L'application d'une MISE À JOUR dépôt/création/modification des objets de base de données en passant d'une version à la suivante
• La MIGRATION de données si une « mise à niveau » perturbatrice a lieu (comme le fractionnement de tables ou d'une plateforme)

Ces fichiers SCOS intègrent également des bonnes pratiques, notamment : (vos bonnes pratiques peuvent être différentes de celles indiquées ici)

• Conventions de nommage uniformes
  • Nom des tables tout en MAJUSCULES
  • Nom des colonnes tout en MINUSCULES
  • Nom des vues tout en casse mixte
  • Nom des fichiers SCOS intégrant le nom d'objet
• Clés primaires d'une colonne unique utilisant des entiers de taille adéquate
• Suppression des données redondantes/en double (tuples)
• Suppression de toutes les références de clé circulaires (pouvant entraîner une situation de type Parent > Enfant > Parent)
• Fichiers SCOS unique par objet
• Fichiers SCOS contenant des sections d'en-tête/objectif/historique correspondant à ce dictionnaire de données
• Formatage SQL garantissant la lisibilité et la maintenabilité

Cet article de blog n'a pas pour objet de fournir de plus amples détails sur ma mise en œuvre des SCOS. Mais je peux peut-être me laisser convaincre de le faire dans un autre article. Vos commentaires et vos questions sont les bienvenus.

Pourquoi es-tu, modèle de données ?

Un bref résumé de ces niveaux vous aidera à comprendre leur objectif, comment les prendre en charge et en quoi ils se différencient les uns des autres dans le cadre du processus de modélisation. Ce tableau vous aidera à y voir plus clair :

Conclusion

Je tiens à remercier chacun d'entre vous d'avoir pris le temps de lire l'ensemble de mes articles de blog. La bonne nouvelle, c'est que j'ai à peu près fait le tour de la question. Hourra ! J'espère que ces informations vous auront été utiles. Quand de bons développeurs Talend connaissent bien leur modèle de données, des modèles de conception de jobs et des bonnes pratiques voient le jour. Si vous n'avez pas lu mes articles sur ce thème, voici le lien vers la Partie 4. Vous y trouverez également des liens vers les Parties 1, 2 et 3. L'article de blog Déployer un data lake gouverné dans le cloud pourrait également vous intéresser. Il a été rédigé conjointement par votre serviteur et mon grand ami, Kent Graziano de Snowflake Computing, un partenaire estimé de Talend.

← Partie 1