Handel internetowy: ontologia dla MŚP
Temat: Ontologia firmy
Model handlu internetowego oddziela zamiar zakupu od potwierdzonej sprzedaży i prowadzi przez płatność, rezerwację towaru, dostawę oraz zwrot. To autorski, przykładowy model dla MŚP, a nie specyfikacja gotowa do wdrożenia w każdej firmie. Odpowiada na pytanie: Dlaczego koszyk nie stał się opłaconym i doręczonym zamówieniem? Zawiera 12 encji i 13 nazwanych relacji. Przed użyciem trzeba uzgodnić definicje z właścicielami procesu i sprawdzić je na rzeczywistych rekordach.
Ten tekst należy do katalogu ontologii w filarze Ontologia firmy. Jeśli dopiero zaczynasz, przeczytaj jak odróżnić ontologię od taksonomii i modelu danych.
Zobacz model jako graf
Miniatura otwiera pełny graf, w którym można wybrać encję lub relację i odczytać jej znaczenie. Tabele poniżej zawierają tę samą informację w formie tekstowej.
Jaką decyzję pomaga podjąć ten model?
Kupująca dodała dwa produkty do koszyka, kliknęła zapłać i zamknęła przeglądarkę. System sklepu pokazuje zamówienie, operator płatności pokazuje nieudaną autoryzację, a magazyn już zarezerwował towar. Bez wspólnego modelu obsługa może obiecać wysyłkę, której nie wolno jeszcze uruchomić.
Model pozwala ustalić, na którym etapie proces się zatrzymał, komu należy zwolnić zapas i czy trzeba wysłać kupującej wiadomość o niedokończonym zakupie. Granica modelu jest równie ważna jak jego zakres: Nie uznaje rezerwacji za sprzedaż ani autoryzacji płatności za ostateczne rozliczenie.
Jakie pojęcia trzeba rozróżnić?
W tabeli każda encja ma własną definicję, klucz identyfikacyjny i przykładowe źródło. Nazwa rekordu w dwóch systemach nie dowodzi jeszcze, że chodzi o ten sam obiekt. Tożsamość trzeba potwierdzić kluczem lub świadomą regułą mapowania; status i prognozę należy datować.
| Encja | Znaczenie w tym modelu | Identyfikator | Przykładowe źródło |
|---|---|---|---|
| Kupujący | Podmiot składający zamówienie lub działający anonimowo przed zakupem. | identyfikator kupującego | sklep |
| Koszyk | Zapis wybranych produktów przed przyjęciem zamówienia. | identyfikator koszyka | sklep |
| Pozycja koszyka | Produkt i ilość wybrane w koszyku. | koszyk i numer pozycji | sklep |
| Produkt | Pozycja katalogowa z kodem i wersją oferty. | kod produktu | katalog |
| Zamówienie | Przyjęte żądanie zakupu z historią stanów. | numer zamówienia | sklep |
| Pozycja zamówienia | Uzgodniona ilość i cena produktu. | zamówienie i numer pozycji | sklep |
| Próba płatności | Żądanie autoryzacji lub obciążenia z wynikiem. | identyfikator próby | operator płatności |
| Płatność | Potwierdzony przepływ środków. | identyfikator transakcji | operator płatności |
| Rezerwacja | Czasowe odłożenie zapasu dla zamówienia. | identyfikator rezerwacji | magazyn |
| Dostawa | Fizyczne przekazanie jednej lub wielu pozycji. | numer przesyłki | system logistyczny |
| Zwrot | Przyjęty proces oddania towaru lub środków. | numer zwrotu | system obsługi |
| Zgoda kontaktowa | Decyzja o dopuszczonym celu i kanale kontaktu. | identyfikator zgody | rejestr zgód |
Koszyk jest listą zamiarów, zamówienie przyjętym żądaniem zakupu, a płatność przepływem o własnym stanie. Rezerwacja zapasu obniża dostępność do sprzedaży, ale nie dowodzi wydania towaru. Zwrot to osobny proces, który może obejmować tylko część pozycji.
Jak encje łączą się w graf biznesowy?
Krawędź ma kierunek, czasownik i znaczenie. Krotność w tabeli opisuje założenie tego modelu, które trzeba zweryfikować w konkretnej firmie. Gdy powiązanie ma własną kwotę, datę albo dowód, warto zachować je jako osobną encję zamiast ukrywać w atrybucie.
| Od | Relacja | Do | Krotność | Co potwierdza |
|---|---|---|---|---|
| Kupujący | tworzy | Koszyk | 1 : 0..n | Zachowuje autora zamiaru zakupu. |
| Koszyk | zawiera | Pozycja koszyka | 1 : 0..n | Rejestruje wybrane ilości. |
| Pozycja koszyka | wskazuje | Produkt | 0..n : 1 | Łączy wybór z katalogiem. |
| Koszyk | prowadzi do | Zamówienie | 0..1 : 0..1 | Powiązanie wymaga przyjęcia zamówienia. |
| Kupujący | składa | Zamówienie | 1 : 0..n | Określa stronę zakupu. |
| Zamówienie | obejmuje | Pozycja zamówienia | 1 : 1..n | Utrwala ceny z chwili przyjęcia. |
| Pozycja zamówienia | dotyczy | Produkt | 0..n : 1 | Wskazuje sprzedawany produkt. |
| Zamówienie | inicjuje | Próba płatności | 1 : 0..n | Pozwala śledzić ponowne próby. |
| Próba płatności | potwierdza | Płatność | 0..1 : 0..1 | Tylko zakończona próba ma wpłatę. |
| Zamówienie | ma | Rezerwacja | 1 : 0..n | Oddziela blokadę zapasu od sprzedaży. |
| Dostawa | realizuje | Zamówienie | 0..n : 1 | Umożliwia wysyłkę częściową. |
| Zwrot | dotyczy | Pozycja zamówienia | 0..n : 1..n | Wskazuje konkretną część zakupu. |
| Kupujący | udziela | Zgoda kontaktowa | 1 : 0..n | Oddziela obsługę zamówienia od marketingu. |
Jak przejść po grafie w jednej sprawie?
Koszyk K8 zawiera pozycje P1 i P2. Powstaje zamówienie Z9 oraz próba płatności T4. T4 kończy się odmową, więc Z9 nie ma potwierdzonej wpłaty. Rezerwacja R3 jest widoczna, ale brak relacji Z9 → dostawa. Zespół może bez zgadywania zwolnić rezerwację według polityki sklepu.
Nie wiemy, czy klientka spróbuje ponownie inną metodą ani czy operator później prześle zmianę statusu; potrzebna jest obsługa spóźnionych komunikatów. Puste powiązanie ma pozostać widoczną luką. Model nie powinien dopowiadać relacji tylko dlatego, że rekordy mają podobne nazwy lub bliskie daty.
Jak połączyć dane i nie zgubić kontekstu?
Uzgodnij identyfikatory koszyka, zamówienia i transakcji operatora. Komunikaty płatnicze zapisuj z czasem i identyfikatorem zdarzenia, aby ponowione powiadomienie nie tworzyło drugiej płatności. Dla każdego mapowania zapisz system źródłowy, lokalny identyfikator, czas aktualizacji i regułę, która połączyła rekordy. Sprzeczne dane powinny trafić do kolejki wyjaśnienia, a nie zostać po cichu nadpisane. Właściciel procesu zatwierdza znaczenie relacji, a właściciel systemu potwierdza sposób jej pobierania.
Nie przenoś pełnych danych instrumentu płatniczego do grafu. Obsługa sklepu potrzebuje stanu i referencji transakcji, a nie tajnych szczegółów rozliczenia. Dostęp do połączonych danych musi odzwierciedlać cel pracy i uprawnienia. Sam fakt, że graf potrafi przejść między dwiema encjami, nie oznacza, że każda osoba może zobaczyć wszystkie atrybuty po obu stronach.
Jak sprawdzić pierwszy wycinek modelu?
Weź kilka prawdziwych, ale bezpiecznie udostępnionych spraw. Dla każdej ustal oczekiwaną ścieżkę i dokument, który potwierdza każdą krawędź. Na początek wystarczą poniższe próby:
- Nieudana autoryzacja nie oznacza opłacenia zamówienia.
- Dwie dostawy mogą realizować jedno zamówienie.
- Zwrot jednej pozycji nie anuluje pozostałych.
- Ponowione powiadomienie operatora nie podwaja płatności.
Jeżeli dwie osoby inaczej interpretują ten sam węzeł lub relację, popraw definicję przed budową interfejsu. Przy niewielkiej liczbie stabilnych powiązań istniejąca baza i widok mogą wystarczyć. Graf pomaga rozmawiać o znaczeniu danych; nie naprawia automatycznie błędów w źródłach.
Co zrobić dalej?
Wybierz jedno pytanie operacyjne z początku tekstu i wskaż osobę, która potwierdzi znaczenie kluczowych pojęć. Następnie sprawdź pięć spraw w systemach źródłowych. Szerszą procedurę opisuje poradnik budowy ontologii firmy. Kolejny model w katalogu: Komunikacja w firmie.
- Ontologia
- Model danych
- MŚP
