Jak połączyć warianty produktów, akcesoria i kompatybilny sprzęt bez duplikatów?

Najpierw zdecyduj, czy dwie płyty opisują jedną czy dwie rzeczy

Modelowanie relacji zaczyna się po rozwiązaniu tożsamości, nie wcześniej. Dwa rzędy dostawców mogą być alternatywnymi opisami tego samego produktu fizycznego, podczas gdy dwa niemal identyczne produkty mogą być rzeczywiście różnymi wariantami sprzedaży. Połączenie drugiej pary traci ważne rozróżnienie; utrzymanie pierwszej pary oddzielnie tworzy duplikaty, które rozprzestrzeniają się poprzez wyszukiwania, zapasów, rekomendacji i sprawozdawczości.

Aby podjąć decyzję, użyj stabilnych identyfikatorów i atrybutów definiujących produkt. Identyfikator produktu Shopify identyfikuje produkt wewnątrz jednego sklepu, natomiast identyfikator wariantu Shopify identyfikuje wersję do sprzedaży. Identyfikator pozycji ERP identyfikuje zapis operacyjny. Numer części GTIN lub producenta może dostarczyć dowodów zewnętrznych, z zastrzeżeniem sposobu, w jaki producent lub właściciel norm je przypisuje. Tytuły, uchwyty i opisy to etykiety, a nie trwałe klucze identyfikacyjne.

Zapis decyzji meczu i jego podstawy. Rejestr źródłowy powinien zostać przekazany jednej jednostce kanonicznej, pozostać odrębny lub wprowadzić kolejkę przeglądową. Nigdy nie pozwól, aby niewyraźny mecz tytułowy po cichu stworzył lub połączył jednostkę. Decyzja ta musi być powtarzalna, gdy pojawi się kolejna dokumentacja dostawcy.

Wzorować rodzinę produktów oddzielnie od jej wariantów do sprzedaży

Rodzina produktów opisuje wspólną koncepcję; wariant reprezentuje wersję wyróżniającą się opcjami lub innymi zatwierdzonymi wymiarami. Shopify opisuje warianty jako kombinacje wartości opcji, takich jak rozmiar i kolor. Każdy wariant może również mieć własny inwentarz. Jest to silny operacyjny powód, aby nie spłaszczyć każdej wersji w jeden ogólny rekord produktu.

Schema.org wykorzystuje ProductGroup z hasVariant i odwrotnym isVariantOf relacji. Jego model traktuje grupę jako wzór dla produktów, które różnią się na wyraźnie określonych wymiarach. Rozróżnienie to jest przydatne w modelu wiedzy biznesowej, nawet jeśli ostateczna baza danych nie jest RDF.

Przechowuj wspólne atrybuty na rodzinie tylko wtedy, gdy są one rzeczywiście dziedziczone. Umieść na wariancie specyficzne dla wariantu SKU, kod kreskowy, cenę, wymiary, kolor, rozmiar i dostępność. Jeśli atrybut się różni, wartość wariantu musi wygrać bez nadpisywania definicji rodziny lub jej rodzeństwa.

• Rodzina: zakres montażu węży hydraulicznych H100
• Wariant: H100, 1 / 2 calowy otwór, długość 1,5 metra
• Szopify ID produktu: dołączony do rejestru rodzinnego dla tego sklepu
• Identyfikator wariantu Shopify: dołączony do wariantu zbywalnego
• Identyfikator pozycji ERP i SKU: dołączony na poziomie ERP faktycznie zarządza

Użyj precyzyjnych typów relacji zamiast jednego pola produktów powiązanych

Ogólny powiązany link nie może bezpiecznie odpowiedzieć na pytania operacyjne. Zestaw uszczelniający, który jest częścią zamienną pompy, nie jest taki sam jak olej zużywany przez pompę, nowsza pompa, która go zastępuje, lub wspornik montażowy, który sprawia, że jest kompatybilny z maszyną. Aplikacje potrzebują rzeczywistego znaczenia.

Zdefiniuj małe regulowane słownictwo. W odniesieniu do każdego związku należy podać dozwolone typy źródeł i podmiotów docelowych, jego kierunek, czy odwrotność jest przechowywana lub obliczana, czy duplikaty są dozwolone i jakie kwalifikacje lub dowody są wymagane. Schema.org odróżnia isAccesoryOrSparePartFor od isConsumableFor i relacji wariantowych, które ilustrują, dlaczego jedno niezróżnicowane stowarzyszenie produktów jest niewystarczające.

Preferuj język biznesu, który recenzenci rozumieją, a następnie mapować go do zewnętrznych słowników tam, gdzie przydatne. Wewnętrzny termin - model maszyny może wymagać szeregowego zakresu i pozycji montażowej, podczas gdy is- access - for może nie. Mapowanie norm powinno wyjaśniać znaczenie, a nie zmuszać kilka relacji biznesowych do uzyskania najbliższego wygodnego oznakowania.

Uczyń kierunek częścią definicji związku

Kierunek zmienia pytanie, na które może odpowiedzieć wykres. Wkład C10 jest przeznaczony do produkcji drukarki P20 nie oznacza, że drukarka P20 jest przeznaczona do produkcji wkładu C10. Wariant V należy do rodziny F jest odwrotnością wariantu V rodziny F, ale te dwie formy nie powinny stać się niepowiązanymi twierdzeniami.

Model danych W3C RDF wyraża relację jako trójkącik obiektu subiektywnego. Traktuje również predykat jako nieruchomość, która odnosi się do przedmiotu. Zapewnia to przydatny test projektowy: czy recenzent może odczytać związek w jednym kierunku jako jednoznaczne zdanie?

Wybierz jeden kanoniczny kierunek przechowywania i wygeneruj bezpieczny widok odwrotny tam, gdzie jest to wymagane. Dokument, które relacje są symetryczne, takie jak równoważność iz- po zatwierdzeniu, a które nie. Nigdy nie zakładaj, że kompatybilność lub wymiana jest automatycznie dwukierunkowa.

Traktuj zgodność jako kwalifikowane twierdzenie

Kompatybilność jest rzadko stałym tak lub nie jest faktem pomiędzy dwoma identyfikatorami produktu. Może zależeć od modelu maszyny, roku budowy, zakresu numerów seryjnych, silnika, regionu, pozycji montażu, oprogramowania firmowego lub adaptera. Warunki te należy przechowywać raczej z twierdzeniem, niż w nieustrukturyzowanej notatce.

Utwórz rejestr relacji zawierający produkt, typ relacji, sprzęt docelowy lub model, kwalifikacje, odniesienie do dowodów, recenzenta, status i ważny okres. Stosowanie potwierdzone, wykluczone i nieznane jako różne stany. Brak potwierdzonego związku nie stanowi dowodu na niezgodność produktu.

Kiedy dostawca zmienia montaż, zamyka lub zastępuje stare twierdzenie zamiast przepisywania historii. W3C zauważa, że związek może utrzymywać się w jednym czasie, a nie innym. Skuteczne daty chronią strony produktów, wspierają odpowiedzi i zastosowania niższego szczebla przed cichym traktowaniem przeterminowanych relacji jako bieżących.

Utrzymuj identyfikatory systemu źródłowego dołączone do jednostki kanonicznej

Wykres wiedzy powinien łączyć identyfikatory używane przez każdą aplikację, a nie zastępować je nazwą wyświetlacza. Jeden produkt kanoniczny może posiadać identyfikator produktu Shopify dla jednego sklepu, inny identyfikator dla innego sklepu, identyfikator NetSuite lub Sage, kody dostawców i zatwierdzone identyfikatory zewnętrzne. Każdy identyfikator potrzebuje swojej przestrzeni nazw i zakresu.

Wartość taka jak 12345 jest bez znaczenia, nie wiedząc czy jest to produkt Shopify, wariant Shopify, element ERP czy wiersz dostawcy. Dostawca, konto lub magazyn, typ obiektu, identyfikator, ważność i źródło odkrycia. Wymuszenie wyjątkowości w odpowiednim zakresie.

Każdy odczyt lub zapis na Shopify musi rozwiązać dokładnie podłączony sklep i użyć jego Shopify ID. Nie szukaj według tytułu i weź pierwszy wynik. Ta sama zasada ma zastosowanie do ERP i rejestrów dostawców. Jeżeli brak identyfikatora lub wskazuje na inną jednostkę kanoniczną, należy przerwać zmianę i przedstawić wyjątek.

Nie należy zmieniać akcesoriów, materiałów eksploatacyjnych i zamienników w warianty

Wariant jest członkiem rodziny produktów, które różnią się na zadeklarowanych wymiarach. Akcesoria to oddzielny produkt używany z innym produktem. Skonsumowany jest wyczerpany przez użycie. Wymiana lub nadczynność wyraża cykl życia lub zastępowanie. Wszystkie te relacje mogą pojawić się w pobliżu jednej strony produktu, ale mają różne konsekwencje handlowe i bezpieczeństwa.

Jeśli wkład filtrujący jest modelowany jako wariant pompy, inwentaryzacja, ceny i wybór klienta stają się mylące. Jeżeli część zastępcza jest oznakowana jedynie podobnymi etykietami, czynnik wspomagający może przegapić zatwierdzone zastąpienie. Jeśli dwa kompatybilne akcesoria są połączone, ponieważ mają jeden tytuł, historia akcji i zamówień może dołączyć do niewłaściwego elementu.

Ujawnić związek, zachować każdy przedmiot podlegający sprzedaży jako swój własny podmiot i określić, czy jest to związek doradczy czy zatwierdzony do automatycznego wykorzystania. Zastępstwa wysokiego ryzyka powinny pozostać zaleceniami dotyczącymi przeglądu sytuacji u ludzi, chyba że przedsiębiorstwo zatwierdziło niezbędne zasady i dowody.

Betonowy przykład: jeden koparka, trzy filtry i dwóch dostawców

Wyobraź sobie model koparki E200 z dwoma generacjami silników. Dostawca A zawiera listę filtrów olejowych OF- 10 dla każdego E200. Dostawca B wymienia OF- 10 dla wczesnych numerów seryjnych i OF- 11 dla późniejszych maszyn. ERP zawiera oba filtry, natomiast Shopify ma jeden produkt dla OF- 10 z wariantami wielkości opakowania i oddzielny produkt dla OF- 11.

Wykres tworzy jednostki kanoniczne dla modelu koparek, jego generacji silników, dwóch filtrów, rodziny produktów OF- 10 i jego wariantów wielkości opakowania. Szopify produktów i identyfikatorów wariantów pozostają dołączone do podmiotów dopasowujących. Wiersze dostawców i identyfikatory pozycji ERP są połączone jako zapisy źródłowe; nie stają się one dodatkowymi produktami.

Zgodność ze wspólnym rynkiem jest reprezentowana za pomocą kwalifikowanych twierdzeń. OF- 10 pasuje do wczesnej generacji silnika w zatwierdzonym zakresie seryjnym. OF- 11 pasuje do późniejszego pokolenia. Szerokie roszczenie dostawcy A pozostaje widoczne, ale jest sprzeczne z bardziej szczegółowymi dowodami i wchodzi w zakres przeglądu. Zestaw sześciu pozostaje wariantem OF- 10, a nie innym kompatybilnym filtrem.

Teraz sklep może pokazać prawidłowy wariant do sprzedaży, zespół wsparcia może odpowiedzieć, który filtr pasuje do numeru seryjnego, a import katalogu może zaktualizować właściwy obiekt Shopify. Każda aplikacja używa tych samych jednostek i zatwierdzonych relacji bez kopiowania całego rekordu do nowej lokalnej prawdy.

Zapobieganie podwójnym związkom oraz podwójnym produktom

Nawet w przypadku czystych podmiotów, wielokrotny import może tworzyć podwójne krawędzie. Zdefiniuj klucz relacji z przedmiotu kanonicznego, typu związku, obiektu kanonicznego i wszelkich kwalifikacji, które zmieniają jego znaczenie. Odniesienie źródłowe powinno wspierać to twierdzenie, a nie tworzyć kolejne niepodzielne twierdzenie za każdym razem, gdy się pojawia.

Wiele źródeł może wspierać jeden zatwierdzony związek, natomiast sprzeczne źródła mogą pozostać odrębnymi twierdzeniami oczekującymi na rozwiązanie. Wyróżnienie twierdzenia biznesowego z dokumentów dowodowych za nim. To pozwala recenzentom zobaczyć porozumienie bez zawyżania widocznej liczby związków.

Zrób z tego ideologa. Przetworzenie tego samego wiersza dostawcy lub haka webhook powinno uaktualnić jego stan dowodowy, a nie dodać inny produkt lub link. Odczytaj zapisany wynik z powrotem i porównaj identyfikatory kanoniczne, klucze relacji i kwalifikatory przed oznaczeniem przebiegu.

Zaprojektuj wykres dla zapytań aplikacji muszą odpowiedzieć

Zacznij od małego zestawu pytań dotyczących klienta i kwestii operacyjnych: który wariant jest sprzedawany, który nadaje się do konsumpcji, który część zamienna zastępuje zaniechaną pozycję, a który Sopify ID powinien otrzymać zatwierdzoną zmianę? Modelować tylko jednostki i relacje potrzebne do bezpiecznej odpowiedzi.

M.I.A.I Knowledge Graph jest przeznaczony do łączenia jednostek kanonicznych, relacji i dowodów, tak aby aplikacje mogły ponownie wykorzystać spójny punkt widzenia biznesu. Zatwierdzone przez nią zdolności obejmują jednostki kanoniczne, modelowanie relacji, źródło dowodów i dostęp do wiedzy wielokrotnego użytku. Wykres pozostaje najbardziej użyteczny, gdy sterownik służy raczej zdefiniowanemu przepływowi pracy niż próbie podłączenia każdego pola jednocześnie.

Zwróć odpowiedzi z identyfikatorami i kontekstem. Zalecenie produktu powinno obejmować produkt kanoniczny, produkt docelowy lub identyfikator wariantu, typ związku, odpowiednie kwalifikacje i stan przeglądu. Jeżeli związek jest nierozwiązany, wnioski powinny otrzymać wyraźnie nieznany lub wymagany wynik przeglądu, a nie odgadnięty link.

Podgląd zmian relacji przed publikacją

Bezpieczny podgląd pokazuje obecne i proponowane podmioty, wszystkie identyfikatory systemu źródłowego, kierunek relacji, kwalifikatory, dowody i każdy cel, który zużyłby zmiany. Podsumowanie nowych linków, usuniętych linków, konfliktów, nierozwiązanych tożsamości i produktów, które mają wpływ.

Sprawdzić trudne przypadki: jeden zapis źródłowy dopasowany do dwóch podmiotów, jeden Szopify wariant ID ponownie używane w sklepach, produkt, który jest zarówno akcesoria i konsumowalny w różnych kontekstach, zakres zgodności z granicą, i supersesja, która nie jest odwracalna. Potwierdź, że porażki pozostają odizolowane.

Zatwierdzić kontrolowaną partię, zapisać za pomocą stabilnych identyfikatorów docelowych i odczytać wynik z powrotem. Zachowaj stan poprzedniego związku, aby nieprawidłowa partia mogła być odwrócona bez wycofywania niepowiązanych cen, zapasów lub kopii produktu.

1. Rozdzielcie każdy zapis źródłowy na jednostkę kanoniczną lub widoczny wyjątek.
2. Sprawdzić każdy identyfikator w ramach jego dostawcy, konta i zakresu obiektu.
3. Zastosować zatwierdzony typ związku, kierunek i kwalifikacje.
4. Potwierdzenia kopie przy zachowaniu wszystkich dowodów potwierdzających.
5. Podgląd produktu, wariant i widok aplikacji.
6. Zatwierdzić ograniczoną partię i zapisać za pomocą dokładnego identyfikatora miejsca przeznaczenia.
7. Przeczytaj ponownie przechowywane relacje i wyniki publiczne.

Lista kontrolna modelowania związków produkcyjnych

• Daj każdemu realnemu produktowi, wariantowi, modelowi i organizacji stabilną tożsamość kanoniczną.
• Dołącz identyfikatory Shopify, ERP, dostawcy, SKU, GTIN i numeru częściowego z zakresem.
• Oddzielne rodziny produktów od sprzedawanych wariantów.
• Użyj precyzyjnych typów dla wariantów, akcesoriów, materiałów eksploatacyjnych, kompatybilności i ponadsesji.
• Określić kierunek zależności, odwrotne zachowanie i dozwolone typy jednostek.
• Przechowuj kwalifikacje zgodności i terminy ważności jako dane ustrukturyzowane.
• Zachowaj wiele dowodów za jednym twierdzeniem.
• Powtórzyć import idemstrong zarówno dla podmiotów, jak i relacji.
• Zatrzymaj zmiany miejsca przeznaczenia, gdy dokładny identyfikator platformy nie może być rozwiązany.
• Podgląd, zatwierdzanie, pisanie i odczytywanie partii kontrolowanych.