Utilisation d'un modèle de données commun

Conseils pour adhérer à un modèle de données commun et exemples de création d'un tel modèle.

Qu'est-ce qu'un modèle de données commun ?

Un modèle de données commun fournit une collection de schémas de données normalisés et extensibles. Ces schémas prédéfinis couvrent différents types de données, notamment des artefacts opérationnels, des artefacts physiques, des documents de référence et des journaux d'événements. En représentant des concepts et des activités largement utilisés, tels que les ordres de travail et les unités, ces schémas facilitent la création, la compilation et l'analyse des données. Cette normalisation permet de rationaliser le traitement des données dans les différents systèmes.

Modèle de données commun dans la composabilité

Les tables Tulip jouent un rôle crucial dans la gestion des flux de données et le maintien de la connexion entre les applications. Elles contiennent des informations qui sont affichées dans les applications et les applications créent, mettent à jour et suppriment des enregistrements de table. Si plusieurs applications utilisent les mêmes tables, elles peuvent communiquer entre elles par l'intermédiaire des tables.

Lors de la conception d'une solution à un problème donné, la définition des tables qui seront utilisées est l'une des étapes les plus importantes. Un choix logique des tables peut aboutir à des applications plus simples, plus réutilisables et plus composables. Si la bonne quantité de données est stockée dans les tables, l'app builder peut réduire le nombre de variables utilisées, ce qui rend l'application moins complexe et plus facile à personnaliser. Si les applications d'une solution utilisent le même ensemble de tables, elles deviennent interchangeables ou composables, sans qu'il soit nécessaire de revoir la conception de l'une ou l'autre application.

Exemple de modèle de données commun

Les tables Tulip devraient principalement suivre le modèle Digital Twin, ce qui signifie que les tables devraient refléter l'usine physique ou l'atelier aussi strictement que possible. Les données historiques de l'application doivent être limitées aux enregistrements d'achèvement, en veillant à ce que les tables ne soient pas utilisées pour stocker des données de base ou des données dupliquées à partir d'enregistrements d'achèvement ou d'enregistrements externes.

Types de tables primaires

Idéalement, les tables devraient représenter des artefacts physiques et opérationnels.

Ces tables comprendront toujours un champ Statut qui sera régulièrement mis à jour par les applications.

Artéfacts physiques

Les artefactsphysiques sont des objets tangibles de votre installation ou des composants utilisés ou produits pendant les opérations.

Exemples :

• Éléments d'inventaire
• Unités
• Emplacements
• Stations
• Équipements et biens

Artéfacts opérationnels

Lesartefacts opérationnels sont des éléments ou des composants tangibles ou intangibles qui permettent ou soutiennent les opérations.

Exemples :

• Demandes de matériel
• Défauts
• Cartes Kanban
• Ordres de travail
• Actions

Types de tableaux secondaires (avancés)

Les types de tableaux secondaires suivants ne s'intègrent pas dans un modèle de jumeau numérique et ne devraient être envisagés que par des utilisateurs expérimentés. Vous ne devez inclure les tables de référence ou de journal qu'une fois que vous avez suivi le processus de conception de la solution et que vous avez épuisé toutes les autres options. Ces tables ne doivent jamais servir de base à une solution d'application.

Journaux

Lesjournaux d'événements sont des informations qui peuvent être consultées et qui définissent quelque chose dans la production. On les trouve souvent dans des systèmes externes tels qu'un ERP.

Exemples :

• Notes et commentaires
• Enregistrements généalogiques
• Historique de l'activité de la station
• Résultats d'inspection

Références

Lesréférences sont des registres partagés entre les applications. Ce concept est similaire à celui d'un enregistrement d'achèvement, sauf qu'il est partagé entre les applications et qu'il rend accessibles les requêtes de tables, les Aggregation et la mutabilité des tables Tulip.

Exemples :

• Définitions des matériaux
• Nomenclature des matériaux

Construisez votre propre modèle de données commun

L'exemple de Modèle Commun de Données de Tulip est conçu pour être un point de départ pour construire votre modèle de données. Cependant, tous les processus et solutions sont différents et, comme les applications, le modèle de données peut être personnalisé selon les besoins.

Les modifications mineures consistent à ajouter ou à supprimer des champs dans les tables. Dans certains cas (processus spéciaux, plusieurs tables nécessaires pour le même cas d'utilisation), des changements majeurs sont nécessaires. Pour ce faire, on peut remplacer une ou plusieurs tables du modèle de données téléchargé ou insérer des tables supplémentaires.

Planifier un modèle de données commun

1. Définissez les artefacts physiques et opérationnels de votre processus.
2. Trouver les tables respectives pour chaque artefact
3. Étudier les types de données à collecter par les applications et les références à utiliser.

Pour en savoir plus

• Stockage des données
• Tables Tulip communes
• Meilleures pratiques pour le stockage des données dans Tulip