K.Subieta. SPIT, Wprowadzenie do handlu elektronicznego, Wykład 3, Folia 1 maj 2006 Studia Podyplomowe IT w Biznesie Wprowadzenie do handlu elektronicznego.

Prezentacja na temat: "K.Subieta. SPIT, Wprowadzenie do handlu elektronicznego, Wykład 3, Folia 1 maj 2006 Studia Podyplomowe IT w Biznesie Wprowadzenie do handlu elektronicznego."— Zapis prezentacji:

1 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 subieta@pjwstk.edu.pl http://www.ipipan.waw.pl/~subieta

2 K.Subieta. SPIT, Wprowadzenie do handlu elektronicznego, Wykład 3, Folia 2 maj 2006 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.

3 K.Subieta. SPIT, Wprowadzenie do handlu elektronicznego, Wykład 3, Folia 3 maj 2006 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.

4 K.Subieta. SPIT, Wprowadzenie do handlu elektronicznego, Wykład 3, Folia 4 maj 2006 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.

5 K.Subieta. SPIT, Wprowadzenie do handlu elektronicznego, Wykład 3, Folia 5 maj 2006 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

6 K.Subieta. SPIT, Wprowadzenie do handlu elektronicznego, Wykład 3, Folia 6 maj 2006 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.

7 K.Subieta. SPIT, Wprowadzenie do handlu elektronicznego, Wykład 3, Folia 7 maj 2006 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.

8 K.Subieta. SPIT, Wprowadzenie do handlu elektronicznego, Wykład 3, Folia 8 maj 2006 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

9 K.Subieta. SPIT, Wprowadzenie do handlu elektronicznego, Wykład 3, Folia 9 maj 2006 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.

10 K.Subieta. SPIT, Wprowadzenie do handlu elektronicznego, Wykład 3, Folia 10 maj 2006 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.

11 K.Subieta. SPIT, Wprowadzenie do handlu elektronicznego, Wykład 3, Folia 11 maj 2006 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.

12 K.Subieta. SPIT, Wprowadzenie do handlu elektronicznego, Wykład 3, Folia 12 maj 2006 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_ID PRODUCT_NAME SELL_PRICE BUY_PRICE STORE_STATE IS_AVAIL VAT SWW_CODE(?) BARCODE AVAIL_DATE EASYNET_NAME(?) INPUT_DATE LAST_UPDATE PRODUCT CATEGORY_ID CATEGORY_NAME CATEGORY parent belongs_to 1+ * * Hierarchiczna organizacja kategorii

13 K.Subieta. SPIT, Wprowadzenie do handlu elektronicznego, Wykład 3, Folia 13 maj 2006 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”.

14 K.Subieta. SPIT, Wprowadzenie do handlu elektronicznego, Wykład 3, Folia 14 maj 2006 Przykład hierarchii kategorii produktów

15 K.Subieta. SPIT, Wprowadzenie do handlu elektronicznego, Wykład 3, Folia 15 maj 2006 Informacja o produktach Każdy produkt będzie opisywany przez atrybuty przedstawione poniżej: PRODUCT_ID PRODUCT_NAME SELL_PRICE BUY_PRICE STORE_STATE IS_AVAIL VAT SWW_CODE(?) BARCODE AVAIL_DATE EASYNET_NAME(?) INPUT_DATE LAST_UPDATE PRODUCT PIC_ID PIC_FORMAT PIC_FILE PICTURE has MODEL_ID MODEL_NAME MODEL_DESCR MIN_SEL_PRICE MAX_SEL_PRICE PRODUCT_GROUP designed has MAIN_IN_BUNCH COMPLEX_PRODUCT consists_of * * * * 0..1

16 K.Subieta. SPIT, Wprowadzenie do handlu elektronicznego, Wykład 3, Folia 16 maj 2006 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.

17 K.Subieta. SPIT, Wprowadzenie do handlu elektronicznego, Wykład 3, Folia 17 maj 2006 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.

18 K.Subieta. SPIT, Wprowadzenie do handlu elektronicznego, Wykład 3, Folia 18 maj 2006 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.

19 K.Subieta. SPIT, Wprowadzenie do handlu elektronicznego, Wykład 3, Folia 19 maj 2006 Produkty, kategorie i atrybuty PRODUCT_ID PRODUCT_NAME SELL_PRICE BUY_PRICE STORE_STATE IS_AVAIL VAT SWW_CODE(?) BARCODE AVAIL_DATE EASYNET_NAME(?) INPUT_DATE LAST_UPDATE PRODUCT CATEGORY_ID CATEGORY_NAME CATEGORY parent ATTRIBUTE_ID ATTRIBUTE_NAME ATTRIBUTE_TYPE DICTIONARY_CHECK REPEATED OPTIONAL ATTRIBUTE can_be_described_by 1+ * * * * belongs_to

20 K.Subieta. SPIT, Wprowadzenie do handlu elektronicznego, Wykład 3, Folia 20 maj 2006 Atrybuty i kategorie CATEGORY 3 "filmy" ATTRIBUTE ATT_ID: "a1" ATT_NAME: "reżyser" TYPE: "string" DICT_CHECK: YES REPEATED: NO OPTIONAL: YES CATEGORY 1 "książki" ATTRIBUTE ATT_ID: "a4" ATT_NAME: "aktor" TYPE: "string" DICT_CHECK: YES REPEATED: YES OPTIONAL: YES ATTRIBUTE ATT_ID: "a44" ATT_NAME: "tytuł" TYPE: "string" DICT_CHECK: NO REPEATED: NO OPTIONAL: NO CATEGORY 35 "filmy z ograniczeniem wieku" parent ATTRIBUTE ATT_ID: "a87" ATT_NAME: "dozwolony od lat" TYPE: "unsigned" DICT_CHECK: NO REPEATED: NO OPTIONAL: NO canbedescribedby canbedescribedby canbedescribedby canbedescribedby canbedescribedby ATTRIBUTE ATT_ID: "a74" ATT_NAME: "słowo kluczowe" TYPE: "string" DICT_CHECK: YES REPEATED: YES OPTIONAL: YES canbedescribedby canbedescribedby

21 K.Subieta. SPIT, Wprowadzenie do handlu elektronicznego, Wykład 3, Folia 21 maj 2006 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.

22 K.Subieta. SPIT, Wprowadzenie do handlu elektronicznego, Wykład 3, Folia 22 maj 2006 Wartości atrybutów PRODUCT_ID PRODUCT_NAME SELL_PRICE BUY_PRICE STORE_STATE IS_AVAIL VAT SWW_CODE(?) BARCODE AVAIL_DATE EASYNET_NAME(?) INPUT_DATE LAST_UPDATE PRODUCT CATEGORY_ID CATEGORY_NAME CATEGORY parent ATTRIBUTE_ID ATTRIBUTE_NAME ATTRIBUTE_TYPE DICTIONARY_CHECK REPEATED OPTIONAL ATTRIBUTE can_be_described_by 1+ * * * * belongs_to Attribute value * * is a value of describes

23 K.Subieta. SPIT, Wprowadzenie do handlu elektronicznego, Wykład 3, Folia 23 maj 2006 Kolejna faza tworzenia diagramu klas PRODUCT_ID PRODUCT_NAME SELL_PRICE BUY_PRICE STORE_STATE IS_AVAIL VAT SWW_CODE(?) BARCODE AVAIL_DATE EASYNET_NAME(?) INPUT_DATE LAST_UPDATE PRODUCT CATEGORY_ID CATEGORY_NAME CATEGORY parent ATTRIBUTE_ID ATTRIBUTE_NAME ATTRIBUTE_TYPE DICTIONARY_CHECK REPEATED OPTIONAL ATTRIBUTE VALUE STRING_DICT_ITEM DATE_VALUE ATTR_VALUE_DATE ATTRIBUTE_VALUE INT_VALUE ATTR_VALUE_INT STRING_VALUE ATTR_VALUE_STRING describes can_be_described_by ATTR_VALUE_PERSON PERSON_ID LAST_NAME(S) FIRST_NAME(S) NICK_NAME(S) NATIONALITY.....other attributes if necessary PERSON ATTR_VALUE_TRACK TRACK_ID VOLUME_NO TRACK_NO TITLE TIME DESCRIPTION TRACK AU_ID AU_FORMAT AU_FILE AUDIO_CLIP 1+ is_pattern_for DICT_NAME DICTIONARY INT_DICTSTRING_DICTDATE_DICTPERSON_DICTTRACK_DICT VALUE INT_DICT_ITEM VALUE DATE_DICT_ITEM is_value_of checks belongs_to * * * * * * * * * * * * *

24 K.Subieta. SPIT, Wprowadzenie do handlu elektronicznego, Wykład 3, Folia 24 maj 2006 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.

25 K.Subieta. SPIT, Wprowadzenie do handlu elektronicznego, Wykład 3, Folia 25 maj 2006 Całość modelu pojęciowego bazy danych PRODUCT_ID PRODUCT_NAME SELL_PRICE BUY_PRICE STORE_STATE IS_AVAIL VAT SWW_CODE(?) BARCODE AVAIL_DATE EASYNET_NAME(?) INPUT_DATE LAST_UPDATE PRODUCT SUPPLIER_ID SUPPLIER_NAME SUPPLIER POSTAL_CODE LOCALITY ADDRESS_STRING ADDRESS has PIC_ID PIC_FORMAT PIC_FILE PICTURE has PRODUCER_ID PRODUCER_NAME PRODUCER produces MODEL_ID MODEL_NAME MODEL_DESCR MIN_SEL_PRICE MAX_SEL_PRICE PRODUCT_GROUP designed CATEGORY_ID CATEGORY_NAME CATEGORY parent ATTRIBUTE_ID ATTRIBUTE_NAME ATTRIBUTE_TYPE DICTIONARY_CHECK REPEATED OPTIONAL 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_ID LAST_NAME(S) FIRST_NAME(S) NICK_NAME(S) NATIONALITY.....other attributes if necessary PERSON has ATTR_VALUE_TRACK TRACK_ID VOLUME_NO TRACK_NO TITLE TIME DESCRIPTION TRACK AU_ID AU_FORMAT AU_FILE AUDIO_CLIP 1+ MAIN_IN_BUNCH COMPLEX_PRODUCT supplies consists_of DICT_NAME DICTIONARY INT_DICTSTRING_DICTDATE_DICTPERSON_DICTTRACK_DICT VALUE INT_DICT_ITEM VALUE DATE_DICT_ITEM is_value_of checks * * * * * * * * * * * * * * * * * * * * * * 0..1 * * is_pattern_for

26 K.Subieta. SPIT, Wprowadzenie do handlu elektronicznego, Wykład 3, Folia 26 maj 2006 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