Come si collegano Varianti di prodotto, accessori e attrezzature compatibili senza duplicati record?

Prima di decidere se due dischi descrivono una cosa o due cose

La modellazione delle relazioni inizia dopo la risoluzione dell'identità, non prima di esso. Due righe di fornitore possono essere descrizioni alterne dello stesso prodotto fisico, mentre due prodotti quasi identici possono essere davvero diverse varianti vendibili. La fusione della seconda coppia perde importanti distinzioni; mantenere la prima coppia separata crea duplicati che si diffondono attraverso ricerca, stock, raccomandazioni e reporting.

Utilizzare identificatori stabili e attributi di definizione del prodotto per prendere la decisione. Un ID prodotto Shopify identifica il prodotto all'interno di un negozio, mentre un ID variante Shopify identifica una versione vendibile. Un ID elemento ERP identifica il record operativo. Un numero di parte GTIN o del produttore può fornire prove esterne, soggetto al modo in cui il proprietario del produttore o degli standard lo assegna. Titoli, maniglie e descrizioni sono etichette, non chiavi di identità durevoli.

Registra la decisione del match e la sua base. Un record di origine dovrebbe risolvere un'entità canonica, rimanere separata, o inserire una coda di revisione. Mai lasciare che un titolo fuzzy match silenziosamente creare o unire un'entità. Tale decisione deve essere riproducibile quando il prossimo file fornitore arriva.

Modello la famiglia del prodotto separatamente dalle sue varianti vendibili

Una famiglia di prodotti descrive il concetto condiviso; una variante rappresenta una versione contraddistinta da opzioni o altre dimensioni approvate. Shopify descrive le varianti come combinazioni di valori di opzione come dimensioni e colore. Ogni variante può anche portare il proprio inventario. Questo è un forte motivo operativo per non appiattire ogni versione in un unico record di prodotto generico.

Schema.org utilizza ProductGroup con hasVariant e la relazione inversa èVariantOf. Il suo modello tratta il gruppo come modello per prodotti che variano su dimensioni esplicitamente definite. Questa distinzione è utile all'interno di un modello di conoscenza aziendale anche quando il database finale non è RDF.

Conservare attributi condivisi sulla famiglia solo quando sono autenticamente ereditati. Mettere la variante-specifica SKU, codice a barre, prezzo, dimensioni, colore, dimensione e disponibilità sulla variante. Se un attributo differisce, il valore variante deve vincere senza sovrascrivere la definizione di famiglia o i suoi fratelli.

• Famiglia: gruppo tubo idraulico H100
• Variante: H100, 1/2 pollici, lunghezza 1,5 metri
• Shopify prodotto ID: allegato al record di famiglia per quel negozio
• Shopify variant ID: allegato alla variante vendibile
• ID articolo ERP e SKU: attaccato al livello che l'ERP gestisce in realtà

Utilizzare tipi di relazione precisi invece di un campo di prodotti correlati

Un collegamento generico non può rispondere in modo sicuro alle domande operative. Un kit di tenuta che è un pezzo di ricambio per una pompa non è lo stesso dell'olio che viene consumato dalla pompa, una pompa più nuova che la sostituisce, o una staffa di montaggio che lo rende compatibile con una macchina. Le applicazioni hanno bisogno del significato reale.

Definire un piccolo vocabolario governato. Per ogni relazione, indicare i tipi di origine e di entità di destinazione consentiti, la sua direzione, se l'inverso è memorizzato o calcolato, se sono permessi duplicati, e quali qualifiche o prove sono richieste. Schema.org distingue èAccessoryOrSparePartFor da isConsumableFor e relazioni varianti; che la separazione illustra perché un'associazione di prodotto indifferenziata è insufficiente.

Preferire il linguaggio aziendale che i recensori capiscono, quindi mapparlo a vocabulari esterni dove utile. Il termine interno si adatta-modello macchina potrebbe richiedere la gamma seriale e la posizione di montaggio, mentre non è-accessorio-per potrebbe. Una mappatura standard dovrebbe chiarire il significato, non forzare diverse relazioni commerciali nell'etichetta conveniente più vicina.

Fare la direzione parte della definizione di relazione

La direzione cambia la domanda che un grafico può rispondere. Cartridge C10 è un consumabile per la stampante P20 non significa che la stampante P20 sia un consumabile per la cartuccia C10. Variant V appartiene alla famiglia F è l'inverso della famiglia F ha variante V, ma le due forme non dovrebbero diventare affermazioni non correlate.

Il modello di dati W3C RDF esprime un rapporto come triplo oggetto-predicato-oggetto. Tratta anche il predicato come la proprietà che riguarda il soggetto all'oggetto. Questo fornisce un test di progettazione utile: un recensore può leggere il rapporto in una direzione come una frase inequivocabile?

Scegliere una direzione di stoccaggio canonica e generare una vista inversa sicura dove richiesto. Documento che le relazioni sono simmetriche, come è-equivalente-a dopo l'approvazione, e che non sono. Non assumere mai che la compatibilità o la sostituzione sia automaticamente bidirezionale.

Trattare la compatibilità come affermazione qualificata

La compatibilità è raramente un fatto permanente sì o no tra due ID prodotto. Può dipendere dal modello della macchina, anno di costruzione, gamma di numeri seriali, motore, regione, posizione di montaggio, firmware o un adattatore. Conservare quelle condizioni con l'affermazione piuttosto che in una nota non strutturata.

Creare un record di relazione contenente il prodotto soggetto, tipo di relazione, attrezzatura di destinazione o modello, qualifiche, riferimento di prova, recensore, stato e periodo valido. Uso confermato, escluso e sconosciuto come stati distinti. L'assenza di un link confermato non dimostra che un prodotto è incompatibile.

Quando un fornitore rivede l'adattamento, chiudi o sostituisci la vecchia affermazione invece di riscrivere la storia. Il W3C nota che una relazione può contenere una volta e non un altro. Le date efficaci proteggono le pagine dei prodotti, le risposte di supporto e le applicazioni a valle dal trattamento silenzioso di una relazione scaduta come attuale.

Tenere gli ID del sistema sorgente collegati all'ente canonico

Un grafico di conoscenza dovrebbe collegare gli identificatori utilizzati da ogni applicazione, non sostituirli con un nome di visualizzazione. Un prodotto canonico può portare un ID prodotto Shopify per un negozio, un ID diverso per un altro negozio, un ID prodotto NetSuite o Sage, codici dei fornitori e identificatori esterni approvati. Ogni identificatore ha bisogno del suo namespace e della sua portata.

Un valore come 12345 è privo di significato senza sapere se si tratta di un prodotto Shopify, una variante Shopify, un prodotto ERP o una riga di fornitore. Fornitore di negozio, account o negozio, tipo di oggetto, identificatore, validità e fonte di scoperta. Fornire l'unicità nell'ambito corretto.

Ogni lettura o scrittura per Shopify deve risolvere l'esatto negozio collegato e utilizzare il suo Shopify ID. Non cercare per titolo e prendere il primo risultato. La stessa regola si applica ai registri ERP e dei fornitori. Se manca un ID o indica una diversa entità canonica, interrompere il cambiamento e presentare un'eccezione.

Non trasformare accessori, materiali di consumo e sostituzioni in varianti

Una variante è un membro di una famiglia di prodotti che differisce sulle dimensioni dichiarate. Un accessorio è un prodotto separato utilizzato con un altro prodotto. Un consumabile viene esaurito tramite l'uso. Una sostituzione o una supersessione esprime il ciclo di vita o la sostituzione. Queste relazioni possono tutti apparire vicino a una pagina del prodotto, ma portano diverse conseguenze commerciali e di sicurezza.

Se una cartuccia filtrante viene modellata come variante della pompa, inventario, prezzi e selezione del cliente diventano fuorvianti. Se una parte sostitutiva è etichettata semplicemente simile, un agente di supporto può mancare un sostituto approvato. Se due accessori compatibili sono fusi perché condividono un titolo, stock e storia dell'ordine possono allegare alla voce sbagliata.

Rendere esplicita la relazione, mantenere ogni oggetto vendibile come propria entità e definire se il rapporto è consultivo o approvato per uso automatizzato. Le sostituzioni ad alto rischio dovrebbero rimanere raccomandazioni per la revisione umana a meno che l'azienda non abbia approvato le regole e le prove necessarie.

Un esempio concreto: un escavatore, tre filtri e due fornitori

Immaginate un modello di escavatore E200 con due generazioni di motori. Fornitore A elenca filtro olio OF-10 per ogni E200. Il fornitore B elenca OF-10 per numeri di serie anticipati e OF-11 per macchine successive. L'ERP contiene entrambi i filtri, mentre Shopify ha un prodotto per OF-10 con varianti confezionate e un prodotto separato per OF-11.

Il grafico crea entità canoniche per il modello di escavatore, le sue generazioni di motori, i due filtri, la famiglia di prodotti OF-10 e le sue varianti confezionate. Shopify ID prodotto e variante rimangono attaccati alle entità corrispondenti. Le righe dei fornitori e gli ID degli articoli ERP sono collegati come record di origine; non diventano prodotti extra.

La compatibilità è rappresentata da affermazioni qualificate. OF-10 si adatta alla generazione iniziale del motore all'interno della sua gamma seriale approvata. OF-11 si adatta alla generazione successiva. L'ampio reclamo del fornitore A rimane visibile ma contrasta con le prove più specifiche e entra in recensione. Il pacchetto di sei rimane una variante di OF-10, non un filtro compatibile diverso.

Ora il negozio può mostrare la corretta variante vendibile, il team di supporto può rispondere a quale filtro si adatta un numero di serie, e un'importazione di catalogo può aggiornare il giusto oggetto Shopify. Ogni applicazione utilizza le stesse entità e le relazioni approvate senza copiare l'intero record in una nuova verità locale.

Evitare relazioni duplicate e prodotti duplicati

Anche con entità pulite, le importazioni ripetute possono creare bordi duplicati. Definire una chiave di relazione dal soggetto canonico, tipo di relazione, oggetto canonico e qualsiasi qualifica che cambi il suo significato. Un riferimento sorgente dovrebbe sostenere che l'affermazione piuttosto che creare un'altra affermazione indistinguibile ogni volta che appare.

Fonti multiple possono sostenere una relazione approvata, mentre fonti contrastanti possono rimanere come affermazioni separate in attesa di risoluzione. Distinguere l'affermazione del business dai registri delle prove dietro di esso. Ciò permette ai recensori di vedere l'accordo senza gonfiare l'apparente numero di relazioni.

Rendere idemponte l'ingestione. Rielaborazione della stessa riga del fornitore o webhook dovrebbe aggiornare il suo stato di prova, non aggiungere un altro prodotto o collegamento. Leggi il risultato memorizzato e confronta ID canonici, chiavi di relazione e qualifiers prima di marcare la corsa completa.

Progettare il grafico per le applicazioni domande deve rispondere

Iniziare con un piccolo insieme di domande del cliente e operativo: quale variante è vendibile, quale consumabile si adatta a questo modello, quale parte di ricambio sostituisce l'oggetto interrotto, e quale Shopify ID dovrebbe ricevere il cambiamento approvato? Modello solo le entità e le relazioni necessarie per rispondere in modo sicuro.

M.I.A.I Knowledge Graph è progettato per collegare entità canoniche, relazioni e prove in modo che le applicazioni possano riutilizzare una visione aziendale coerente. Le sue capacità approvate includono entità canoniche, modellazione delle relazioni, provenienza delle prove e accesso alle conoscenze riutilizzabili. Il grafico rimane più utile quando questi controlli servono un flusso di lavoro definito piuttosto che un tentativo di collegare ogni campo contemporaneamente.

Risponde alle risposte con gli identificatori e il contesto. Una raccomandazione del prodotto dovrebbe includere il prodotto canonico, il prodotto di destinazione o l'ID variante, il tipo di relazione, le qualifiche rilevanti e lo stato di revisione. Se il rapporto è irrisolto, le applicazioni dovrebbero ricevere un risultato esplicito sconosciuto o richiesto dalla revisione piuttosto che un link indovinato.

Anteprima relazione modifiche prima della pubblicazione

Un'anteprima sicura mostra le entità attuali e proposte, tutti gli ID del sistema sorgente, la direzione di relazione, le qualifiers, le prove e ogni destinazione che consumano il cambiamento. Sommarizzare nuovi link, link rimossi, conflitti, identità irrisolte e prodotti interessati.

Test casi difficili: un record di origine abbinato a due entità, un ID variante Shopify riutilizzato nei negozi, un prodotto sia accessorio che consumabile in contesti diversi, una gamma di compatibilità con un limite, e una supersessione che non è reversibile. Conferma che i guasti rimangono isolati.

Approva un lotto controllato, scrivi usando gli ID di destinazione stabili e leggi il risultato indietro. Mantenere lo stato di relazione precedente in modo che un lotto errato possa essere invertito senza rotolare indietro i prezzi non correlati, le azioni o la copia del prodotto.

1. Risolvere ogni record sorgente ad un'entità canonica o ad un'eccezione visibile.
2. Convalida ogni identificatore all'interno del suo provider, account e oggetto.
3. Applicare il tipo di relazione approvato, la direzione e le qualifiche.
4. Deduplicare le asserzioni mantenendo tutte le prove di supporto.
5. Anteprima prodotto, variante e vista applicazione.
6. Approva un lotto limitato e scrivi con l'ID di destinazione esatto.
7. Leggi le relazioni memorizzate e l'output pubblico.

Elenco di controllo della modellazione del prodotto

• Dare ad ogni prodotto reale, variante, modello e organizzazione un ID canonico stabile.
• Attach Shopify, ERP, fornitore, SKU, GTIN e identificatori a numero parziale con portata.
• Famiglie di prodotti separate da varianti vendibili.
• Utilizzare tipi precisi per varianti, accessori, materiali di consumo, compatibilità e supersessione.
• Definire la direzione del rapporto, il comportamento inverso e i tipi di entità consentiti.
• Conservare le qualifiche di compatibilità e le date di validità come dati strutturati.
• Tenere più record di prove dietro un'affermazione aziendale.
• Rendere le importazioni ripetute idempotent sia per le entità e le relazioni.
• Interrompere i cambiamenti di destinazione quando l'identificativo della piattaforma esatto non può essere risolto.
• Anteprima, approvare, scrivere e leggere i lotti controllati.