Studia Podyplomowe IT w Biznesie Wprowadzenie do handlu elektronicznego (HEL)

K.Subieta. SPIT, Wprowadzenie do handlu elektronicznego, Wykład 3, Folia 1 maj 2006

Studia Podyplomowe IT w Biznesie

Wprowadzenie do handlu elektronicznego(HEL)

Wykład 3

Polsko-Japońska Wyższa Szkoła Technik Komputerowych,

Warszawa

Wykładowca:Prof. dr hab. inż. Kazimierz Subieta

[email protected]://www.ipipan.waw.pl/~subieta


Profesjonalny CMS do zarządzania tekstami w sklepie

System do edycji zawartości stron sklepu WYSIWYG (What you see is what you get) .

Edytor zainstalowany we wszystkich miejscach sklepu, w których można zmieniać teksty (opisy produktów, teksty informacyjne na stronie, newsy, newsletter itp.)

Bez znajomości html można dowolnie formować tekst w sklepie, podgląd zmienianych tekstów na bieżąco.

Rozbudowany system wprowadzania newsów tekstowych na stronie. Podział newsów na grupy, możliwość umieszczania 1 newsa w kilku

grupach lub np. tylko w 1 wersji językowej. Newsy w formacie XML-RSS - RSS (Rich Site Summary) - publikowanie

newsów w specjalnym, ujednoliconym formacie opartym na języku XML, które mogą być następnie pobierane i przechowywane przy pomocy tzw. czytników RSS.


Funkcje oprogramowania e-sklepu – Moduły dodatkowe (2)

Informacje - pozwala na dowolne tworzenie katalogów oraz informacji zawartych wewnątrz danego katalogu.

Wersja do druku - pozwala na wydruk ulotki o produkcie wraz ze zdjęciem, a także logiem i adresem sklepu internetowego sprzedawcy.

Cenniki w formacie PDF - pozwala na wydrukowanie aktualnej oferty wraz z cenami pochodzącymi z odpowiedniego dla danego klienta poziomu cenowego lub też zapisanie cennika jako pliku pdf.

TOP 10 - pozwala na wyświetlenie listy produktów najczęściej kupowanych lub oglądanych przez osoby dokonujące zakupów.

Zobacz też - umożliwia automatyczne bądź też ręczne tworzenie list produktów skojarzonych ze sobą i wyświetlanie ich klientom podczas dokonywania zakupów.

Upusty - automatycznie nalicza rabat według zadanych kryteriów i wyświetla użytkownikom informację zarówno o rabacie, jak i kwocie zamówienia uwzględniającej upust.


Funkcje oprogramowania e-sklepu – Zarządzanie bazą klientów

Możliwość przeglądania listy klientów Zaawansowane wyszukiwanie klientów według następujących kryteriów:

loginu, imienia, nazwiska, e-mail'a, daty Dostęp do danych klienta (dane bilingowe i dane korespondencyjne) Łatwa edycja danych klienta Automatyczne nadawanie przez system numeru id klienta Możliwość przypisania odpowiedniej liczby punktów klientowi Możliwość zdefiniowania czy klient jest użytkownikiem hurtowym czy

detalicznym Wysyłanie maili do klienta z poziomu panelu administracyjnego Dostęp do wszystkich transakcji dokonanych przez danego klienta Informacja o dacie zarejestrowania się klienta Usuwanie klientów Lojalnościowy system punktów Produkty polecane - Klienci którzy zakupili produkt x, zakupili również y.


Funkcje oprogramowania e-sklepu – Zarządzanie transakcjami (1)

Przeglądanie listy transakcji Informacja o zamówionym towarze, numerze transakcji, danych

bilingowych oraz danych dostawy Możliwość zdefiniowania statusu zamówienia Dostęp do danych klienta Informacja o numerze IP, z którego zostało dokonane zamówienie Informacja o formie płatności, dostawcy, koszcie zamówienia oraz dacie

dokonania zamówienia Możliwość wyświetlenia nie rozliczonych zamówień Zaawansowane wyszukiwanie transakcji według następujących kryteriów:

daty zawarcia transakcji, wartości transakcji, metody płatności, statusu transakcji, potwierdzenia płatności

Możliwość zdefiniowania ilości punktów za każde 100 PLN


Funkcje oprogramowania e-sklepu – Zarządzanie transakcjami (2)

Możliwość dodawania nowych statusów transakcji Możliwość modyfikowania transakcji po otrzymaniu zamówienia. Możliwość wprowadzania produktów niestandardowych (nie

znajdujących się w cenniku). Rozbudowane statusy transakcji: wysyłanie automatycznych potwierdzeń

do klienta o statusie transakcji. Klient ma wgląd w każdy etap realizacji zamówienia. Rozbudowane wyszukiwanie i sortowanie transakcji. Przypisanie danej transakcji do zdefiniowanego uprzednio partnera, jeśli

transakcja nastąpiła po wejściu do sklepu ze strony partnera Naliczanie prowizji dla partnerów. Zestawienia dotyczące wybranego okresu. Potwierdzanie transakcji partnera.


Funkcje oprogramowania e-sklepu – Magazyn produktów

Możliwość wprowadzenia stanów magazynowych dla wszystkich produktów.

Zmiana stanu magazynowego po dokonaniu/potwierdzeniu transakcji. Wyszukiwanie produktów brakujących/na wyczerpaniu (powiadamianie

e-mail). Przechowalnia informacji o produktach, która stwarza możliwość

przechowywania przez klienta w sklepie w swoim profilu towarów, których nie chce kupić w danym momencie, ale jest nimi zainteresowany i chce mieć możliwość szybkiego włożenia ich do koszyka bez ponownego wyszukiwania ich w sklepie.


Funkcje oprogramowania e-sklepu – System zarządzania dostawcami

możliwość obliczania kosztów dostawy na podstawie jednostki miary np. wagi, rozmiaru itp.

definiowanie listy krajów dostawy. wybór kraju dostawy/strefy. definiowanie zakresów jednostek miary i kosztów. definiowanie indywidualnych dostawców dla różnych stref, nazwy

dostawcy, krótkiego opisu oraz wartości zakupów powyżej, której dostawa jest bezpłatna

definiowanie metod płatności dla każdego z dostawców oddzielnie


Bezpieczeństwo

Główną zasadą jaką należy kierować się przy projektowaniu systemu jest zero tolerancji dla elementów mogących stwarzać zagrożenie - żadnych kompromisów zmniejszających bezpieczeństwo danych i serwisów.

Każda część programu powinna być dokładnie sprawdzana pod względem bezpieczeństwa.

Staramy się wyprzedzać potencjalnych "wrogów", testujemy nasze programy w warunkach zagrożenia, sami dokonujemy próbnych ataków.

Bezpieczeństwo oprogramowania opiera się na kilkustopniowej strukturze, kilku warstwach ochronnych, które skutecznie bronią dostępu do danych klientów. Dodatkowo program powinien korzystać z niewykrywalnego monitoringu, który analizuje i rejestruje osoby pracujące z programem.

Ważne dane powinny być szyfrowane i nikt, nawet administrator serwera, nie może mieć do nich dostępu.

Dane osobowe powinny być przechowywane zgodnie z wymogami ustawy o ochronie danych osobowych.


Baza danych - konkretny przypadek EMPiK

Koncepcja bazy danych opiera się na następujących kryteriach: Elastyczność przy wprowadzaniu nowych kategorii produktów. Aplikacje nie

powinny podlegać radykalnym zmianom w wyniku zmian własności obecnego asortymentu sprzedawanych produktów, jak również w wyniku pojawiania się nowych kategorii produktów. Przykładowo, mogą się pojawić nowe kategorie PLAKAT lub MAPA, którą trzeba będzie dostawić do już oprogramowanych produktów.

Elastyczność przy wprowadzaniu opisów nowych własności istniejących produktów. Przykładowo, kamery cyfrowe mogą zostać wyposażone w oprogramowanie, którego typ stanie się istotną cechą handlową.

Skuteczna automatyczna kontrola wprowadzanych danych: słownikowa, typologiczna, i/lub referencyjna.

Precyzyjne odwzorowanie ról osób związanych z wytworzeniem danego produktu: autorów, wykonawców, kompozytorów, dyrygentów, aktorów, solistów, redaktorów, edytorów, scenarzystów, fotografików, operatorów, itd.

Być może istotne okaże odwzorowanie organizacji związanych z wytworzeniem danego produktu: orkiestr, zespołów rockowych, domów wydawniczych, itd.


Proponowana realizacja modelu pojęciowego

Konieczne jest stworzenie struktur w bazie danych umożliwiających objęcie hierarchii wszystkich kategorii produktów oraz elastyczność w zakresie dostawiania nowych kategorii w trakcie eksploatacji systemu.

Dotychczasowa struktura była oparta na założeniu, że każda nowa kategoria produktów jest zapisana w postaci tabeli w relacyjnej bazie danych.

Ze strategicznego punktu widzenia takie założenie jest naiwne, gdyż może spowodować eksplozje ilości tabel i ich atrybutów, co w konsekwencji musi zaowocować niejednorodnościami i błędami.


Kategorie produktów (1)

Przykład sprzętu fotograficznego pokazuje, że liczba kategorii, które mogą być przedmiotem informacji handlowej dla klienta, jest znaczna.

Kategorie są objęte hierarchiczną strukturą o nieznanej liczbie pięter.

Najwygodniej zaimplementować wszystkie kategorie jako strukturę danych o hierarchicznej budowie.

PRODUCT_IDPRODUCT_NAMESELL_PRICEBUY_PRICESTORE_STATEIS_AVAILVATSWW_CODE(?)BARCODEAVAIL_DATEEASYNET_NAME(?)INPUT_DATELAST_UPDATE

PRODUCT

CATEGORY_IDCATEGORY_NAME

CATEGORY

parent

belongs_to

1+*

*

Hierarchiczna organizacja kategorii


Kategorie produktów (2)

Produkt może należeć do więcej niż jednej kategorii. Podstawowymi kategoriami produktów są książki, multimedia, filmy,

muzyka, sprzęt foto, kosmetyki, komputery, ale nie będą one reprezentowane jako odrębne tabele. Każda kategoria będzie opisywana przez identyfikator i nazwę. Kategoria może mieć dowolną liczbę pod-kategorii (związek parent). Każdy produkt będzie należał (związek belongs_to) do jednej kategorii, przy

czym przyjmuje się założenie implicite, że jeżeli produkt należy do kategorii A, to automatycznie należy do wszystkich kategorii nadrzędnych w stosunku do A.

Np. jeżeli produkt należy do kategorii „Filtr korekcyjny 49”, to automatycznie należy także do kategorii „Filtr korekcyjny”, „Filtr”, „Akcesoria” i „Sprzęt foto”. Rysunek na następnym slajdzie przedstawia fragment hierarchii kategorii. Linie łączące kategorie są związkami „parent”.


Przykład hierarchii kategorii produktów

CATEGORY1"książki"

CATEGORY2"multimedia"

CATEGORY3"filmy"

CATEGORY4"muzyka"

CATEGORY5"foto"

CATEGORY6"kosmetyki"

CATEGORY7"komputery"

CATEGORY41"blues, jazz"

CATEGORY42"boksy, wydania kolekconerskie, digipacki"

CATEGORY43"folk, szanty, etno, country"

CATEGORY41"blues, jazz"

CATEGORY42"boksy, wydania kolekconerskie, digipacki"

CATEGORY43"folk, szanty, etno, country"

CATEGORY431"country"

CATEGORY432"etno"

CATEGORY433"folk"

CATEGORY434"szanty"

CATEGORY434"inne"

CATEGORY431"country"

CATEGORY432"etno"

CATEGORY433"folk"

CATEGORY434"szanty"

CATEGORY434"inne"

CATEGORY4331"flamenco"

CATEGORY4332"rumba"

CATEGORY4333"folk rock"

CATEGORY4334"mambo"

CATEGORY4335"miejski folk"


Informacja o produktach

Każdy produkt będzie opisywany przez atrybuty przedstawione poniżej:


PRODUCT PIC_IDPIC_FORMATPIC_FILE

PICTURE

has

MODEL_IDMODEL_NAMEMODEL_DESCRMIN_SEL_PRICEMAX_SEL_PRICE

PRODUCT_GROUP

designedhas

MAIN_IN_BUNCHCOMPLEX_PRODUCT

consists_of

*

*

**

0..1

0..1


Opis założeń

Każdy produkt może mieć dowolną liczbę zdjęć (klasa PICTURE). Zdjęcie jest częścią w agregacie związanym z produktem lub grupą produktów. Zdjęcie nie może w związku z tym istnieć samodzielnie.

Produkt jest opisywany przez następujące atrybuty: AVAIL_DATE - określa kiedy produkt będzie fizycznie dostępny w sklepie, INPUT_DATE - określa datę wprowadzenia informacji o produkcie do bazy danych (i

co za tym idzie, może być podstawą informacji o nowościach), LAST_UPDATE, który określa datę ostatniej aktualizacji.

Produkty mogą być złożone, tj. powiązane w kilka produktów. Złożone produkty mogą się pojawić w wyniku promocji, która wiąże sprzedaż kilku produktów lub oferuje pewne produkty za darmo, o ile były zakupione inne produkty. Przyjmuje się, ze produkt złożony jest odrębnym obiektem COMPLEX_PRODUCT, który ma własne atrybuty, takie jak cena, zdjęcia, itd. W szczególności, cena produktu złożonego nie musi być sumą cen składowych, zaś niektóre atrybuty mogą być nierelewantne, np. VAT, który może być różny dla produktów składowych.

Hierarchię produktu złożonego wyznacza związek consists_of. Atrybut MAIN_IN_BUNCH jest identyfikatorem produktu składowego, który jest główny w produkcie złożonym.


Atrybuty produktu

Każda kategoria produktu może mieć własne atrybuty, które powinny być obsługiwane przez aplikację.

Zapis tych atrybutów w postaci tabel spowodowałby eksplozję ich ilości, zwiększenie skłonności do błędów oraz zwiększenie narzutów na pielęgnację.

Dodatkowa trudność polega na tym, ze niektóre atrybuty (np. autor w przypadku kategorii książka) mają charakter powtarzalny (wielu autorów), opcjonalny (brak autora) i/lub złożony (autor może być złożoną hierarchiczną strukturą).

Te okoliczności sugerują filozofię opisu produktu zbliżoną do XML. Zastosowanie XML jako podstawy zapisu informacji o atrybutach produktu (w postaci jednego XML-owego stringu) przypisanego do produktu jest kontrowersyjne z kilku powodów, np. z powodu słabych możliwości kontroli słownikowej i referencyjnej, słabych możliwości aktualizacji, i innych niedogodności.

Z tego powodu opis atrybutów został związanych z klasą kategorii atrybutów. Jest to przedstawione na następnym slajdzie.


Atrybuty kategorii produktów

Każda kategoria jest związana z pewną liczbą atrybutów. Klasa ATTRIBUTE może być zaimplementowana w postaci tabeli w

relacyjnej bazie danych. Informacja DICTIONARY CHECK ustala czy atrybut podlega kontroli słownikowej, informacja REPEATED, ustala czy atrybut może mieć dla danego produktu wiele wartości, informacja binarna OPTIONAL ustala, czy atrybut może być nieobecny w opisie produktu.

Każda kategoria może być podłączona do wielu atrybutów i odwrotnie, jeden atrybut może charakteryzować wiele kategorii. Dziedziczenie atrybutów: jeżeli dany atrybut jest właściwy dla kategorii A, to jest on także właściwy dla wszystkich podkategorii kategorii A, w dół hierarchii kategorii.

Ten sposób zapisu jest także właściwy dla ról osób, które mogą być charakteryzowane przez atrybuty takie jak: „autor”, „wykonawca”, „kompozytor”, „dyrygent”, „aktor”, itd.

Istotne jest tu oddzielenie ról osób od samych osób, gdyż w tym ujęciu ta sama osoba może być w danym produkcie (lub w różnych produktach) np. aktorem, reżyserem, piosenkarzem i reżyserem.


Produkty, kategorie i atrybuty


PRODUCT


CATEGORY

parent

ATTRIBUTE_IDATTRIBUTE_NAMEATTRIBUTE_TYPEDICTIONARY_CHECKREPEATEDOPTIONAL

ATTRIBUTE

can_be_described_by

1+

*

*

*

*

belongs_to


Atrybuty i kategorie

CATEGORY3"filmy"

ATTRIBUTEATT_ID: "a1"ATT_NAME: "reżyser"TYPE: "string"DICT_CHECK: YESREPEATED: NOOPTIONAL: YES

CATEGORY1"książki"

ATTRIBUTEATT_ID: "a4"ATT_NAME: "aktor"TYPE: "string"DICT_CHECK: YESREPEATED: YESOPTIONAL: YES

ATTRIBUTEATT_ID: "a44"ATT_NAME: "tytuł"TYPE: "string"DICT_CHECK: NOREPEATED: NOOPTIONAL: NO

CATEGORY35"filmy z ograniczeniem wieku"

parent

ATTRIBUTEATT_ID: "a87"ATT_NAME: "dozwolony od lat"TYPE: "unsigned"DICT_CHECK: NOREPEATED: NOOPTIONAL: NO

can be described by

can be described by

can be described bycan be described by

can be described by

ATTRIBUTEATT_ID: "a74"ATT_NAME: "słowo kluczowe"TYPE: "string"DICT_CHECK: YESREPEATED: YESOPTIONAL: YES

can be described by

can be described by


Wartości atrybutów

Każdy produkt jest charakteryzowany przez pewną liczbę wartości atrybutów. Z jednej strony, wartości te będą podłączone do klasy ATTRIBUTE, zaś z drugiej strony – do klasy PRODUCT . Tabeli powinno być tyle, ile typów wartości. Przewiduje się wartości atrybutów będące identyfikatorami agregatów.

Dla każdego takiego agregatu powinna istnieć odrębna tabela lub zespół tabel. Realizacja tej sytuacji, z uwzględnieniem trzech typów i dwóch agregatów PERSON i TRACK jest przedstawiona na poniższym rysunku. Podany sposób zapisu klas PERSON i TRACK jest jednocześnie realizacją kontroli słownikowej i referencyjnej, ponieważ minimalizuje ryzyko pojawienia się np. tego samego nazwiska w wielu miejscach w różnej pisowni.


Wartości atrybutów


PRODUCT


CATEGORY

parent


ATTRIBUTE

can_be_described_by

1+

*

*

*

*

belongs_to

Attribute value

*

*

is a value of

describes


Kolejna faza tworzenia diagramu klas


PRODUCT CATEGORY_IDCATEGORY_NAME

CATEGORYparent


ATTRIBUTE

VALUESTRING_DICT_ITEM

DATE_VALUEATTR_VALUE_DATE

ATTRIBUTE_VALUE

INT_VALUEATTR_VALUE_INT

STRING_VALUEATTR_VALUE_STRING

describes

can_be_described_by

ATTR_VALUE_PERSON

PERSON_IDLAST_NAME(S)FIRST_NAME(S)NICK_NAME(S)NATIONALITY.....other attributes if necessary

PERSON

ATTR_VALUE_TRACK

TRACK_IDVOLUME_NOTRACK_NOTITLETIMEDESCRIPTION

TRACK

AU_IDAU_FORMATAU_FILE

AUDIO_CLIP

1+

is_pattern_for

DICT_NAMEDICTIONARY

INT_DICTSTRING_DICT DATE_DICT PERSON_DICT TRACK_DICT

VALUEINT_DICT_ITEM

VALUEDATE_DICT_ITEM

is_value_of

checks

checks

belongs_to

* *

*

*

* *

*

*

*

*

*

*

*


Kontrola słownikowa

Podany wyżej sposób jest także odpowiedni dla kontroli słownikowej. Możliwe są tu dwie sytuacje: utworzenie wielu słowników, dla kontroli poszczególnych atrybutów, zintegrowany słownik dla kontroli wszystkich atrybutów.

Pierwsza wersja jest lepsza z punktu widzenia administracji i zarządzania, Druga jest bardziej uniwersalna. W tym zakresie można byłoby

wypracować pewien kompromis. Na rysunku przedstawiona jest wersja pierwsza, bez rozwijania poszczególnych kategorii słowników.


Całość modelu

pojęciowego bazy danych


PRODUCT

SUPPLIER_IDSUPPLIER_NAME

SUPPLIER

POSTAL_CODELOCALITYADDRESS_STRING

ADDRESS

has

PIC_IDPIC_FORMATPIC_FILE

PICTURE

has

PRODUCER_IDPRODUCER_NAME

PRODUCER

produces

MODEL_IDMODEL_NAMEMODEL_DESCRMIN_SEL_PRICEMAX_SEL_PRICE

PRODUCT_GROUP

designed


CATEGORYparent


ATTRIBUTE

VALUE

STRING_DICT_ITEM

DATE_VALUE

ATTR_VALUE_DATE

ATTRIBUTE_VALUE

INT_VALUE

ATTR_VALUE_INT

STRING_VALUE

ATTR_VALUE_STRING

describes

belongs_to

can_be_described_by

ATTR_VALUE_PERSON

PERSON_IDLAST_NAME(S)FIRST_NAME(S)NICK_NAME(S)NATIONALITY.....other attributes if necessary

PERSON

has

ATTR_VALUE_TRACK

TRACK_IDVOLUME_NOTRACK_NOTITLETIMEDESCRIPTION

TRACK

AU_IDAU_FORMATAU_FILE

AUDIO_CLIP

1+

MAIN_IN_BUNCH

COMPLEX_PRODUCT

supplies

consists_of

DICT_NAME

DICTIONARY

INT_DICTSTRING_DICT DATE_DICT PERSON_DICT TRACK_DICT

VALUE

INT_DICT_ITEM

VALUE

DATE_DICT_ITEM

is_value_of

checks

checks

*** * *

*

*

*

**

*

*

**

*

*

**

*

*

**

0..1

* *

0..1

0..1

0..1

is_pattern_for


Podsumowanie Handel elektroniczny na świecie przestał już być kosztownym

eksperymentem, promowanym przez grupę zapaleńców. 4% ogólnej wartości sprzedaży i rynek wart 66 mld $ w USA w 2004 r.

jest tego najlepszym dowodem. W Polsce pomimo pewnych słabości i barier handel elektroniczny to

branża, która rozwija się bardzo dynamicznie i ma ogromny potencjał na dalszy, intensywny rozwój.

171% średniorocznego wzrostu, przez ostatnie 4 lata, oraz 1 mld PLN obrotu nie pozostawiają złudzeń.

Co trzeci nabywca, który już kupuje w sieci, deklaruje, że zamierza w najbliższej przyszłości wydawać więcej niż dotychczas.

Oprogramowanie sklepu internetowego wymaga profesjonalnego podejścia, zarówno od strony zastosowanego narzędzia, stworzonego na jego bazie oprogramowania sklepu, jaki i wdrożonych procesów działania takiego sklepu

Studia Podyplomowe IT w Biznesie Wprowadzenie do handlu elektronicznego (HEL)

Documents

Transcript of Studia Podyplomowe IT w Biznesie Wprowadzenie do handlu elektronicznego (HEL)