Comment connecter les variantes de produit, les accessoires et les équipements compatibles sans duplicate records?

D'abord décider si deux documents décrivent une ou deux choses

La modélisation des relations commence après la résolution d'identité, pas avant. Deux rangées de fournisseurs peuvent être des descriptions alternatives du même produit physique, tandis que deux produits presque identiques peuvent être des variantes vendables vraiment différentes. La fusion de la deuxième paire perd des distinctions importantes; le fait de séparer la première paire crée des doubles qui se propagent par la recherche, les stocks, les recommandations et les rapports.

Utilisez des identifiants stables et des attributs de définition de produit pour prendre la décision. Un identifiant Shopify identifie le produit dans un magasin, tandis qu'un identifiant de variante Shopify identifie une version vendable. Un ID de l'élément ERP identifie le dossier opérationnel. Un numéro GTIN ou un numéro de pièce du fabricant peut fournir des preuves externes, sous réserve de la façon dont le fabricant ou le propriétaire de la norme les attribue. Les titres, les poignées et les descriptions sont des étiquettes, pas des clés d'identité durables.

Enregistrer la décision de match et sa base. Un enregistrement source doit être résolu par une entité canonique, rester séparé ou entrer une file d'attente d'examen. Ne laissez jamais un titre flou correspondre silencieusement à créer ou fusionner une entité. Cette décision doit être reproductible lorsque le prochain dossier du fournisseur arrive.

Modèle la famille de produits séparément de ses variantes vendables

Une famille de produits décrit le concept partagé; une variante représente une version distinguée par des options ou d'autres dimensions approuvées. Shopify décrit les variantes comme des combinaisons de valeurs d'option telles que la taille et la couleur. Chaque variante peut également avoir son propre inventaire. C'est une forte raison opérationnelle de ne pas aplatir chaque version en un seul enregistrement de produit générique.

Schema.org utilise ProductGroup avec hasVariant et l'inverse estVariantDe relation. Son modèle traite le groupe comme un modèle pour les produits qui varient selon des dimensions explicitement définies. Cette distinction est utile dans un modèle de connaissance d'entreprise même lorsque la base de données finale n'est pas RDF.

Stockez les attributs partagés sur la famille seulement quand ils sont véritablement hérités. Mettre la variante spécifique SKU, code à barres, prix, dimensions, couleur, taille et disponibilité sur la variante. Si un attribut diffère, la valeur de la variante doit gagner sans écraser la définition de famille ou ses frères et sœurs.

• Famille: flexible hydraulique gamme H100
• Variante: H100, perçage de 1/2 po, longueur de 1,5 mètre
• Shopify product ID: attaché au dossier de famille pour ce magasin
• Identification de la variante Shopify: attachée à la variante vendable
• ID de l'article ERP et UGS: attaché au niveau que gère effectivement l'ERP

Utiliser des types de relation précis au lieu d'un champ de produits apparentés

Un lien générique ne peut répondre en toute sécurité aux questions opérationnelles. Un kit d'étanchéité qui est une pièce de rechange pour une pompe n'est pas le même que l'huile consommée par la pompe, une pompe plus récente qui la remplace ou un support de montage qui la rend compatible avec une machine. Les applications ont besoin du sens réel.

Définir un petit vocabulaire régi. Pour chaque relation, indiquez les types de source et d'entité cible autorisés, son orientation, si l'inverse est stocké ou calculé, si les doubles sont autorisés et quelles qualifications ou preuves sont requises. Schema.org distingue isAccessoireOrSparePartFor de isConsumableFor et les relations de variante; cette séparation illustre pourquoi une association de produits indifférenciée est insuffisante.

Préférez le langage d'affaires que les évaluateurs comprennent, puis cartographiez-le vers des vocabulaires externes où il est utile. Le terme interne fits-machine-model peut exiger une portée série et une position de montage, alors que l'accessoire-pour ne peut pas. Une cartographie des normes devrait clarifier le sens, et non forcer plusieurs relations d'affaires à l'étiquette la plus proche.

Faire de la direction une partie de la définition de la relation

L'orientation change la question qu'un graphique peut répondre. La cartouche C10 est consommable pour l'imprimante P20 ne signifie pas que l'imprimante P20 est consommable pour la cartouche C10. La variante V appartient à la famille F est l'inverse de la famille F a la variante V, mais les deux formes ne devraient pas devenir des affirmations sans rapport.

Le modèle de données W3C RDF exprime une relation en tant que sujet-prédicat-objet triple. Il traite également le prédicat comme la propriété qui relie le sujet à l'objet. Cela fournit un test de conception utile: un examinateur peut-il lire la relation dans une direction comme une phrase sans ambiguïté?

Choisissez une direction de stockage canonique et générer des vues inverses sécuritaires lorsque nécessaire. Documenter quelles relations sont symétriques, comme est-équivalent à après approbation, et qui ne le sont pas. Ne présumez jamais que la compatibilité ou le remplacement est automatiquement bidirectionnel.

Traiter la compatibilité comme une affirmation qualifiée

La compatibilité est rarement un fait permanent oui ou non entre deux ID de produit. Elle peut dépendre du modèle de machine, de l'année de construction, de la gamme de numéros de série, du moteur, de la région, de la position de montage, du micrologiciel ou d'un adaptateur. Conservez ces conditions avec l'affirmation plutôt que dans une note non structurée.

Créer un dossier de relation contenant le produit en question, le type de relation, l'équipement cible ou le modèle, les qualifications, la référence de preuve, l'évaluateur, le statut et la période valide. Utilisation confirmée, exclue et inconnue comme états distincts. L'absence de lien confirmé ne prouve pas qu'un produit est incompatible.

Lorsqu'un fournisseur révise l'ajustement, fermer ou remplacer l'ancienne affirmation au lieu de réécrire l'historique. Le W3C note qu'une relation peut avoir lieu à un moment et non à un autre. Les dates d'entrée en vigueur protègent les pages de produits, les réponses de soutien et les applications en aval de traiter silencieusement une relation expirée comme étant actuelle.

Conserver les identifiants du système source attachés à l'entité canonique

Un graphique de connaissance devrait relier les identifiants utilisés par chaque application, et non les remplacer par un nom d'affichage. Un produit canonique peut porter un identifiant Shopify pour un magasin, un identifiant différent pour un autre magasin, un identifiant NetSuite ou Sage, des codes fournisseurs et des identifiants externes approuvés. Chaque identifiant a besoin de son espace de noms et de sa portée.

Une valeur telle que 12345 n'a pas de sens sans savoir s'il s'agit d'un produit Shopify, d'une variante Shopify, d'un article ERP ou d'une ligne fournisseur. Magasiner le fournisseur, le compte ou le magasin, le type d'objet, l'identificateur, la validité et la source de découverte. Appliquer l'unicité dans le cadre approprié.

Chaque lecture ou écriture à Shopify doit résoudre le magasin connecté exact et utiliser son identifiant Shopify. Ne pas chercher par titre et prendre le premier résultat. La même règle s'applique aux dossiers des ERP et des fournisseurs. Si un ID est manquant ou qu'il pointe vers une entité canonique différente, arrêtez le changement et présentez une exception.

Ne pas transformer les accessoires, consommables et remplacements en variantes

Une variante est un membre d'une famille de produits qui diffère selon les dimensions déclarées. Un accessoire est un produit séparé utilisé avec un autre produit. Un consommable est épuisé par l'utilisation. Un remplacement ou une sursession exprime le cycle de vie ou la substitution. Ces relations peuvent toutes apparaître près d'une page de produit, mais elles ont des conséquences commerciales et de sécurité différentes.

Si une cartouche filtre est modélisée comme une variante de pompe, l'inventaire, les prix et la sélection du client deviennent trompeurs. Si une pièce de rechange est simplement étiquetée comme similaire, un agent de soutien peut manquer un remplacement approuvé. Si deux accessoires compatibles sont fusionnés parce qu'ils partagent un titre, stock et l'historique de commande peut attacher au mauvais article.

Rendre la relation explicite, garder chaque article vendable comme son propre entité et définir si la relation est consultative ou approuvée pour une utilisation automatisée. Les substitutions à risque élevé devraient demeurer des recommandations pour l'examen humain à moins que l'entreprise n'ait approuvé les règles et les preuves nécessaires.

Un exemple concret: une pelle, trois filtres et deux fournisseurs

Imaginez un modèle de pelle E200 avec deux générations de moteurs. Le fournisseur A énumère le filtre à huile OF-10 pour chaque E200. Listes du fournisseur B OF-10 pour les numéros de série précoce et OF-11 pour les machines ultérieures. L'ERP contient les deux filtres, tandis que Shopify a un produit pour OF-10 avec des variantes de format pack et un produit séparé pour OF-11.

Le graphique crée des entités canoniques pour le modèle de pelle, ses générations de moteurs, les deux filtres, la famille de produits OF-10 et ses variantes de pack-size. Shopify produit et variantes ID restent attachés aux entités correspondantes. Les rangées de fournisseurs et les identifiants d'item ERP sont liés en tant qu'enregistrements sources; ils ne deviennent pas des produits supplémentaires.

La compatibilité est représentée par des assertions qualifiées. OF-10 s'adapte à la première génération de moteurs dans sa gamme de série approuvée. OF-11 convient à la dernière génération. La revendication générale du fournisseur A demeure visible, mais elle est en conflit avec les éléments de preuve plus précis et entre en examen. Le pack de six reste une variante de OF-10, pas un filtre compatible différent.

Maintenant, la vitrine peut afficher la bonne variante vendable, l'équipe de support peut répondre à quel filtre correspond un numéro de série, et une importation de catalogue peut mettre à jour le bon objet Shopify. Chaque application utilise les mêmes entités et les mêmes relations approuvées sans copier l'ensemble de l'enregistrement dans une nouvelle vérité locale.

Prévenir les relations en double ainsi que les produits en double

Même avec des entités propres, les importations répétées peuvent créer des bords en double. Définir une clé de relation à partir du sujet canonique, type de relation, objet canonique et tous les qualificatifs qui changent sa signification. Une référence source devrait appuyer cette affirmation plutôt que de créer une autre affirmation indistinguable chaque fois qu'elle apparaît.

Plusieurs sources peuvent appuyer une relation approuvée, tandis que des sources contradictoires peuvent demeurer des revendications distinctes en attente de règlement. Distinguer l'affirmation commerciale des dossiers de preuve derrière. Cela permet aux évaluateurs de voir l'accord sans gonfler le nombre apparent de relations.

Faites ingestion idémpotent. Retraitement de la même ligne de fournisseur ou webhook devrait mettre à jour son état de preuve, ne pas ajouter un autre produit ou lien. Lire le résultat stocké et comparer les ID canoniques, les touches relation et les qualificatifs avant de marquer l'exécution complète.

Concevoir le graphique pour les questions

Commencez par une petite série de questions de client et d'exploitation: quelle variante est vendable, quelle consommable correspond à ce modèle, quelle pièce de rechange remplace l'article discontinué, et quelle identification Shopify devrait recevoir la modification approuvée? Modèlez seulement les entités et les relations nécessaires pour répondre en toute sécurité.

M.I.A.I Knowledge Graph est conçu pour connecter les entités canoniques, les relations et les preuves afin que les applications puissent réutiliser une vue d'affaires cohérente. Ses capacités approuvées comprennent les entités canoniques, la modélisation des relations, la provenance des preuves et l'accès réutilisable aux connaissances. Le graphique reste le plus utile lorsque ces contrôles servent un workflow défini plutôt qu'une tentative de connecter chaque champ à la fois.

Retourner les réponses avec les identifiants et le contexte. Une recommandation de produit doit inclure le produit canonique, le produit de destination ou la variante ID, le type de relation, les qualifications pertinentes et l'état d'examen. Si la relation n'est pas résolue, les demandes devraient recevoir un résultat explicite inconnu ou exigé par l'examen plutôt qu'un lien de présomption.

Prévisualiser les changements de relation avant publication

Un aperçu sécuritaire montre les entités actuelles et proposées, tous les identifiants du système source, l'orientation de la relation, les qualificatifs, les preuves et toutes les destinations qui consommeraient le changement. Résumez les nouveaux liens, les liens supprimés, les conflits, les identités non résolues et les produits touchés.

Tester les cas difficiles : un enregistrement source correspondant à deux entités, un identifiant de variante Shopify réutilisé à travers les magasins, un produit à la fois accessoire et consommable dans différents contextes, une gamme de compatibilité avec une limite et une supersession qui n'est pas réversible. Confirmez que les échecs restent isolés.

Approuver un lot contrôlé, écrire en utilisant des identifiants de destination stables et lire le résultat. Gardez l'état de la relation antérieure afin qu'un lot incorrect puisse être inversé sans retourner les prix, le stock ou la copie du produit sans rapport.

1. Résoudre chaque enregistrement source à une entité canonique ou à une exception visible.
2. Valider chaque identifiant au sein de son fournisseur, compte et objet.
3. Appliquer le type de relation, l'orientation et les qualifications approuvés.
4. Dupliquer les affirmations tout en préservant toutes les preuves à l'appui.
5. Aperçu des produits touchés, des variantes et des vues d'application.
6. Approuver un lot limité et écrire par l'identifiant de destination exact.
7. Relisez les relations stockées et la sortie publique.

Liste de contrôle pour la modélisation des relations de produits

• Donnez à chaque produit, variante, modèle et organisation une identification canonique stable.
• Joindre Shopify, ERP, fournisseur, SKU, GTIN et les identifiants de numéro de pièce avec portée.
• Séparer les familles de produits des variantes vendables.
• Utilisez des types précis pour les variantes, accessoires, consommables, compatibilité et supersession.
• Définir l'orientation de la relation, le comportement inverse et les types d'entité autorisés.
• Stocker les qualifications de compatibilité et les dates de validité sous forme de données structurées.
• Conservez plusieurs dossiers de preuves derrière une affirmation commerciale.
• Faire des importations répétées idémpotent pour les entités et les relations.
• Arrêter la destination change lorsque l'ID de la plate-forme exacte ne peut pas être résolu.
• Prévisualiser, approuver, écrire et lire les lots contrôlés.