Przedstawiony projekt systemu internetowej sprzedaży towarów jest fragmentem całości
serwisu internetowego firmy. Został on zbudowany przy wykorzystaniu narzędzi

i oprogramowania OpenSource. Korzysta z istniejących w aplikacjach finansowo księgowych

danych, gromadzonych w codziennej działalności przedsiębiorstwa. Za kryterium
podstawowe przyjęto ekonomiczne dostosowanie tworzonych rozwiązań pod kątem

zastosowania takiego modelu sklepu internetowego w firmach małej i średniej wielkości.
Kod aplikacji jest wysoce elastyczny i pozwala na swobodne modyfikowanie zarówno

formatu wejścia danych jak i interfejsu użytkownika oraz wkomponowanie w istniejący

serwis internetowy firmy. Aktualna działająca aplikacja sklepu internetowego znajduje się
pod adresem:

http://www.vt.pl/

gdzie jest użytkowana i stale rozwijana. W rozwój aplikacji

sklepu internetowego oraz całości serwisu firmy duży wkład pracy stale wnosi mój przyjaciel

Radosław Wierzbicki za co niniejszym składam mu podziękowanie.

Cel i zakres pracy

Rozdział I omawia założenia wstępne, przedstawia charakter pracy oraz metody i narzędzia
zastosowane w budowie aplikacji. Omówiono tutaj uwarunkowania ekonomiczne

powstającego systemu oraz zaprezentowano bazę systemową oprogramowania.

Rozdział II przedstawia teorię i funkcjonowanie sklepu internetowego, ukazuje wymagania
użytkowników dotyczące działania serwisów internetowych firm. Przedstawia wpływ

marketingu i reklamy na popularność serwisu. Prezentuje zasady działania oraz model
logiczny i funkcjonalny tego typu aplikacji internetowych.

Rozdział III prezentuje przygotowanie danych na potrzeby sklepu internetowego.

Przedstawia sposoby konwersji, archiwizacji i przesyłania danych pomiędzy serwerami
i aplikacjami istniejącymi w przedsiębiorstwie. Pokazuje procedury konwersji i obróbki

danych oraz ich automatyczny załadunek do systemu bazodanowego.

Rozdział IV omawia strukturę i organizację bazy danych sklepu. Prezentuje skrypty
administracyjne i bazodanowe systemu oraz omawia ich budowę i działanie. Przedstawia

podział funkcjonalny konstruowanych podprocedur oraz strukturę bazy SQL.
Rozdział V prezentuje wyszukiwarkę towarów, koncepcję i zasadę działania oraz kod

źródłowy. Omawia napotykane problemy optymalizacji zapytań do bazy danych i sposoby

ich rozwiązywania.
Rozdział VI przedstawia dalsze cele i kierunki rozwoju projektu sklepu internetowego.

Omawia budowę interfejsu rejestracji informacji dodatkowych o towarach oraz model

i zasadę działania „koszyka” na towary. Prezentuje stosowane metody śledzenia
i utrzymywania sesji pomiędzy webserwerem a przeglądarką klienta.

Podsumowanie pracy omawia zebrane podczas budowy projektu wnioski i doświadczenia.

Rozdział I – Z

AŁOŻEN IA WSTĘPNE

PRZEDSTAWIENIE METOD

NARZĘDZI

WARUNKOWANIA EKONOMICZNE

W czasach gwałtownego rozwoju Internetu, działalność gospodarcza wkracza w nowy etap

rozwoju. Nowe możliwości jakie stwarza zasięg działania, powszechność oraz dostępność

Internetu inspirują do zainteresowania się rozwojem biznesu na tej platformie. Szczególną
dziedziną, w której jest możliwy szybki rozwój i poszerzenie podstawowej i tradycyjnej

działalności jest handel, rozumiany zarówno jako wymiana pomiędzy partnerami jak
i dostawcami a ich klientami. Rozwój małej i średniej przedsiębiorczości wymaga rozwiązań

dostosowanych do potrzeb tego segmentu działalności komercyjnej. Rynek ten w krajach

Unii Europejskiej czy też w Stanach Zjednoczonych jest określany jako SOHO (Small Office
Home Office). Podstawowym kryterium jest tu wielkość firmy, różnie rozumiana, często

jako ilość zatrudnionych pracowników czy też wielkość generowanych przychodów,

obrotów itp. Jedyną różnicą pomiędzy Polską a innymi krajami Europy Zachodniej jest
właśnie skala według której następuje segmentacja. W Polsce przyjmuje się że średniej

wielkości przedsiębiorstwo zatrudnia ponad dwudziestu pięciu pracowników. Jest to o rząd
wielkości mniejsza liczba niż w innych krajach Unii Europejskiej. Analiza potrzeb takich firm

wykazała, że podstawowym kryterium wyboru rozwiązań informatycznych wspierających

i rozszerzających działalność podstawową są koszty zarówno zakupu, rozwoju jak
i

utrzymania systemów, oprogramowania i administracji. Społeczność internetowa

jednoznacznie wykazuje ogromne zainteresowanie rozwojem oprogramowania i systemów

OpenSource (

www.opensource.org

) zarówno opartych na licencji GNU GPL jak i BSD.

Teksty tych dokumentów umieszczone są pod adresem

www.opensource.org/licenses

Przykładem systemów OpenSource jest np. Linux czy wiele innego doskonałego
oprogramowania określanego wspólną nazwą GNU. Kolejnym elementem jest także cała

rodzina Unix’owych sieciowych systemów operacyjnych *BSD takich jak

FreeBSD (

danych takich jak PostgreSQL

(

www.postgresql.org

), języków programowania jak

PHP (

www.php.net

) i innych. Tendencje te ostatnio znalazły poparcie u „wielkich” rynku

informatycznego. Sun wykupił i udostępnił na licencji GNU pakiet biurowy StarOffice, IBM
przeniósł Linux'a na swoje platformy mainframe, Borland stworzył środowisko

Delphi/Kylix do budowy uniwersalnych aplikacji dla środowiska Windows/Linux oraz

udostępnił bazę InterBase itp. Powstała organizacja Free Software Foundation
(

www.fsf.org

) wspierająca ten „ruch” w kierunku dalszego upowszechniania

i popularyzowania tego trendu. Bazując na osiągnięciach społeczności internetowej w tej
dziedzinie za podstawę realizacji systemu umożliwiającego małym i średnim firmom

wkroczenie w sferę e-biznesu przyjęto systemy bazujące na tego typu oprogramowaniu.

REZENTACJA BAZY SYSTEMOWEJ OPROGRAMOWANIA

Na podstawę do budowy systemu kompleksowo obsługującego całość działań

komunikacyjnych, sieciowych, aplikacyjnych a jednocześnie zapewniającego wysoki stopień
bezpieczeństwa całego systemu został wybrany system Unix z rodziny BSD. FreeBSD jest

systemem dedykowanym i optymalizowanym do pracy na platformie Intel (IA32) oraz
Alpha. Jest on z powodzeniem stosowany przez największych dostawców usług

internetowych i przeznaczony jest do pracy przy bardzo dużych obciążeniach. Przykładem

jego wykorzystania są serwisy web i email np.

Yahoo.com

lub

Hotmail.com

, największy serwis

ftp

ftp.cdrom.com

czy też rodzimy

Home.pl

. Na serwerze firmy gdzie wykonano wdrożenie

kompletnego środowiska obsługującego całość działalności internetowej zainstalowany

został Unix FreeBSD, serwer pocztowy Qmail (

www.qmail.org

) dedykowany do obsługi

poczty internetowej (nawet do kilku milionów przesyłek dziennie), webserwer

Apache (

www.apache.org

) do obsługi serwisów WWW oraz dostępu do poczty poprzez

przeglądarkę na bazie TWIG (

twig.screwdriver.net

) a także obsługi sklepu internetowego

działającego na bazie PostgreSQL (

www.postgresql.org

), do której dostęp i dynamicznie

budowane strony wykonano w PHP4 (

www.php.net

). Gwałtownie rosnącą popularność tego

języka przedstawia Rysunek 1.

Rysunek 1 – Popularność języka PHP.

Serwer internetowy świadczy ponadto wiele innych usług i zabezpieczony został firewallem.
Analogicznie, po stronie wewnętrznego LAN firmy został uruchomiony drugi serwer na

bazie FreeBSD obsługujący kilka podsieci firmy oraz zapewniający dostęp do internetu
z wewnątrz firmy. Na serwerze w celu poprawienia wewnętrznego bezpieczeństwa sieci

również uruchomiono firewall oraz translację adresów. Sieć firmowa oparta jest na stacjach

roboczych z oprogramowaniem MS Windows natomiast na serwerze FreeBSD sieć
Windows jest obsługiwana przez oprogramowanie Samba

(

www.samba.org

Oprogramowanie finansowo księgowe stworzone przez firmę Comvar (

www.comvar.com.pl

)

na bazie CA Clipper rezyduje na dyskach sieciowych wewnętrznego serwera i tam
przechowywane są dane. Taka organizacja pozwoliła na wykorzystanie danych firmy do

automatycznego zasilania sklepu internetowego a ponadto udostępniła całej firmie
wymagane usługi internetowe przy minimalnych kosztach, bowiem całe oprogramowanie

serwerów bazuje na OpenSource. Schemat działania całości struktury sieciowej firmy

sprawdził się w ciągu kilku lat jego funkcjonowania i gwarantuje wysoką jakość
i niezawodność działania. Na serwerach dokonywana jest regularna archiwizacja wszystkich

danych firmy a samo środowisko FreeBSD jako wyjątkowo odporne na awarie wydaje się

być wręcz przeznaczone do takich celów. Początkowo wyjściowym systemem był Linux,
jednak problemy występujące z udostępnianiem i poprawną pracą sieci Windows oraz

podatność jego filesystemu (extfs2) na awarie wykluczyła go z dalszego stosowania, gdyż był
on tutaj najsłabszym ogniwem. Strategia ta znalazła późniejsze potwierdzenie w sytuacji, gdy

z przyczyn niezależnych od firmy cała serwerownia na skutek awarii wodociągów w budynku

została doszczętnie zalana wodą. Zniszczeniu uległy zasilacze UPS oraz router Cyclades
obsługujący łącze do internetu poprzez Polpak Frame Relay. Modemy Lucent DSLPipe

obsługujące łącza do zdalnych siedzib firmy na terenie miasta nie zostały uszkodzone.

W serwerach na skutek tej awarii zniszczeniu uległy karty sieciowe. Po wymianie kart
sieciowych w ciągu kilku godzin sieć firmowa przywrócona została do działania a żadne dane

zgromadzone na dyskach serwerów nie uległy uszkodzeniu. Poprzez zastosowanie struktury
skrzynek pocztowych natywnych dla Qmail’a określanej jako Maildir, pomimo awarii

zasilania w trakcie dostarczania poczty do skrzynek nie uległa ona uszkodzeniu. Bieżąca

działalność firmy, po krótkim czasie niezbędnym na wymianę uszkodzonych podzespołów,
mogła być kontynuowana i żadne dane nie uległy zniszczeniu, nie było nawet potrzeby

odzyskiwania ich z kopii zapasowych.

Rysunek 2 przedstawia schematyczną strukturę topologiczną sieci firmy:

Internet

zdalne oddziały firmy

siedziba główna firmy

strefa zdemilitaryzowana (DMZ)

Rysunek 2 – Topologia sieci przedsiębiorstwa.

Rozdział II – T

EORIA I FUNKCJONOWANIE

YMAGANIA UŻYTKOWNIKÓW

Podstawą działania sklepu internetowego są dane o towarach, na bazie których możliwe jest
dalsze jego konstruowanie. W praktyce działania sklepu dane te służą prezentacji

posiadanych produktów przeznaczonych do sprzedaży internetowym kanałem dystrybucji.
Z przeprowadzanych analiz zachowań internautów odwiedzających tego typu serwisy,

charakterystyczna jest zasada, że każda strona musi zostać załadowana w ciągu 7-10 sekund

od próby wejścia do serwisu internetowego. Dłuższy czas „odświetlania” strony zniechęca
internautów i powoduje rezygnację z dalszej eksploracji zasobów firmy. Szybkość transferów

osiągana przez najczęściej wykorzystywane do łączenia z Internetem popularne modemy

gwarantuje przepustowość w zakresie od 3KB/s do 6KB/s, stąd wynika iż ilość danych
wysyłanych przez serwer WWW do przeglądarki klienta nie powinna przekraczać 30KB do

60KB maksymalnie na podstawowe strony firmowe. Specyficzne jest natomiast podejście
internautów do stron specjalizowanych np. z prezentacjami multimedialnymi lub

szczegółowymi danymi technicznymi i użytkowymi produktów, które wzbudziły ich

zainteresowanie i o których chcą uzyskać szczegółowe informacje. Tutaj „cierpliwość”
użytkowników Internetu jest dużo większa, a ich gotowość do „czekania” na załadowanie

strony jest kilku a nawet kilkunastokrotnie większa. Takie strony mogą mieć rozmiary rzędu

100KB i więcej, o ile zbudowane są w taki sposób, że już w trakcie ich ładowania
przeglądarka wyświetla stopniowo ściągane dane. Przy największych stronach konieczne

wydaje się dzielenie prezentowanych informacji na wiele mniejszych fragmentów, po których
użytkownik może swobodnie nawigować za pomocą hyperlinków i różnego rodzaju

statycznych i dynamicznych odsyłaczy. W dobrym tonie jest konstruowanie stron „lekkich”

czyli nie przeładowanych zbędną grafiką ładującą się powoli, a przy odnośnikach do plików
z większymi obrazami czy też plikami multimedialnymi podawanie ich rozmiaru lub

przybliżonego czasu ładowania. Organizacja logiczna i wizualna strony musi być jasna

i przejrzysta dla potencjalnego klienta. Jezyk HTML opisu strony musi być zgodny ze
obowiązującymi standardami i zwyczajami stosowanymi w budowie stron. Występuje

tendencja do takiego budowania strony, aby była możliwa do poprawnej prezentacji nawet
przez najprostsze przeglądarki trybu tekstowego dostępne na platformach unixowych (jak

choćby Lynx, Links czy W3M). Oczywiście należy także wykorzystywać wszelkie nowości jak

skrypty Java czy DHTML jednak w taki sposób, aby zapewnić poprawne interpretowanie

strony we wszystkich najpopularniejszych przeglądarkach różnych firm i ich kilku ostatnich
wersjach. Charakterystycznym wydaje się być celowa rezygnacja w wielu serwisach

internetowych ze stosowania ramek i zastąpienie ich tabelami. Sklep internetowy ze względu
na specyfikę swojego działania, musi zapewniać bezpieczeństwo zgromadzonych danych

klientów, szczególnie gdy realizowane są płatności kartami płatniczymi. Stosowanym

standardem jest szyfrowanie transmisji takich danych przy użyciu protokołu SSL. Obecną
tendencją jest także scedowanie obowiązku weryfikacji i autoryzacji kart płatniczych na

zaufaną stronę „trzecią” w osobie organizacji zajmującej się autoryzowaniem transakcji

elektronicznych. Nowością ostatnio wprowadzaną w Polsce przez
PolCard S.A. (

www.polcard.pl

), jako największego krajowego publicznego „operatora”

transakcji kartowych, jest autoryzowanie online takich transakcji, poprzez przekierowanie
transakcji autoryzacji przez sklep do serwera autoryzacji tej firmy. Analiza preferencji

użytkowników dokonujących zakupów online wykazuje jeszcze przeważającą wśród polskich

internautów strategię realizowania płatności „za zaliczeniem pocztowym”, jednak występują
pierwsze oznaki zwiększającego zainteresowania płatnościami kartą płatniczą. Związane jest

to z dużym naciskiem banków i organizowanymi promocjami zarówno przez Visa

International (

www.visa.com

) jak i same banki na promocję i sprzedaż usług

bezgotówkowych. Często karta płatnicza jest obecnie wydawana bez opłat do każdego

zakładanego rachunku konta osobistego a bankowe tabele opłat i prowizji tak konstruowane,
aby niejako „administracyjnie” motywować klientów do korzystania z bezgotówkowych

form płatności.

ARKETING I REKLAMA

Ogólna zasada funkcjonowania sklepu internetowego opiera się na kilku filarch. Z jednej

strony jest to baza danych o towarach, katalogach, cennikach itp. informacjach, z drugiej są
to dane gromadzone na podstawie informacji uzyskiwanych od klientów. Wszystko to

wsparte jest analizami i statystykami oglądalności i odwiedzin na firmowych stronach serwisu
webowego. Można analizować liczbę odwiedzin, specyfikę i rodzaje poszukiwanych towarów

i informacji o nich, adresy domen z których następują wejścia oraz charakterystykę czasową

na przestrzeni dnia, tygodnia czy miesiąca lub roku. Podstawą są logi serwera jak i dane
zapisywane w bazie SQL. Analizy te pozwalają przewidywać okresy wzmożonego

zainteresowania konkretnymi produktami jak i umożliwiają na precyzowanie oferty

kierowanej do potencjalnego klienta. To daje duże pole działania w porównaniu do

tradycyjnych metod sprzedażowych, gdzie klient pozostaje anonimowy praktycznie aż do
momentu zawarcia konkretnej transakcji. Wsparciem dla strategii marketingowych może być

dobrze zaplanowana akcja reklamowa na bazie banerów reklamowych prezentowanych na
różnych stronach zarówno własnego serwisu jak i na zasadzie wymiany banerowej z innymi.

Wejścia poprzez kliknięcie w baner mogą być analizowane pod kątem charakterystyki

wiekowej klienta. Wiadomo bowiem gdzie dany baner był umieszczony, na jakim serwisie

i jaki jest profil internautów odwiedzających dany serwis. Nikt przecież nie będzie

reklamować drogiego sprzętu RTV na serwisach internetowych przeznaczonych dla
nastolatków. W takim przypadku właściwszym będzie zaprezentowanie sprzętu przenośnego

typu walkman czy discman. Całokształt działań promujących sklep internetowy musi być

wsparty podstawami zarówno psychologicznymi, ekonomicznymi jak i informatycznymi,
mającymi na celu osiągnięcie zamierzonego celu i sukcesu. Prezentowane rozwiązania

umożliwiają rozbudową całego serwisu o różnorakie narzędzia wpierające dział marketingu
firmy w cenne informacje, na których zebranie tradycyjnymi metodami należałoby

Rysunek 3 – Internetowa promocja towarów sklepu.

wydatkować zarówno duże środki finansowe jak i poświęcić sporo czasu na badania
marketingowe. Oczywistym jest także fakt, że informacje zebrane tradycyjnymi metodami

przekładają się także na sam sklep internetowy i prezentowaną ofertę. W obecnych czasach
właściwym wydaje się model działalności dodatkowej i uzupełniającej „tradycyjną”

ekonomię handlu podczas prowadzenia tego typu serwisu internetowego. W przypadku

małych i średnich przedsiębiorstw taki model może prowadzić do poszerzenia kontaktu
z potencjalnymi klientami, wyrobienia sobie dobrej marki i pozytywnej opinii wśród klientów

jak i zwiększenia sprzedaży, udziałów w rynku czy też zadowolenia klientów co może mieć

przełożenie na wymierne odnoszone korzyści.

ASADA DZIAŁANIA

Zasada działania sklep internetowego została oparta o model wirtualnego środowiska

pozyskiwania informacji o produktach i w przypadku ich atrakcyjności dla klienta ewentualną

sprzedaż. Zaobserwowane zachowania dowodzą często, że wizyty na stronach służą
uzyskaniu konkretnych informacji o produkcie. Nie zawsze kończą się one zrealizowaniem

transakcji, jednak często klienci przychodzący do „tradycyjnego” sklepu firmowego

powołują się na informacje uzyskane z serwisu webowego firmy. Świadczy to o tym, iż
potencjalny klient chce być dobrze poinformowany zanim skontaktuje się już

z rzeczywistym sprzedawcą a nie jego wirtualnym odpowiednikiem. Jednak transakcje na
droższy sprzęt zawierane są w normalnym sklepie. Tutaj uwidacznia się cel działania takiego

sklepu jako bardziej informujący i promujący konkretny produkt niż nastawiony ściśle na

sprzedaż. Chcąc sprostać temu zadaniu zbudowany od podstaw sklep internetowy
udostępnia klientom wygodną wyszukiwarkę towarów, przeglądanie informacji o towarach,

nowościach i specjalnych ofertach czy promocjach. Często klienci mają już wyrobione zdanie

o konkretnych producentach i starają się dokonywać zakupów sprzętu tylko konkretnie
wybranej serii, modelu czy producenta. W tym celu przeglądarka sklepu została wzbogacona

w możliwość przeglądania tematycznego jak i w oparciu o konkretnego producenta. Chcąc
sprostać tym zadaniom, wymagana była rozbudowa modułu aktualizowania i wprowadzania

informacji dodatkowych o towarach. Oprogramowanie finansowo księgowe firmy nie było

przeznaczone do tego celu i nie udostępniało wymaganych narzędzi. Dane zgromadzone
i przetwarzane w bieżącej działalności firmy doskonale nadawały się do wykorzystania jako

wsad informacyjny o posiadanych towarach, producentach i cenach. Także informacje

o odbiorcach oraz dostawcach pozwalają na uzupełnienie sklepu o moduł kontaktów

ze stałymi partnerami handlowymi i rozszerzenie działalności modelu B2C (business-to-
consumer) także o model B2B (business-to-business). Jednocześnie wykorzystanie

posiadanych danych znacząco ułatwia funkcjonowanie sklepu, gdyż są one automatycznie
ładowane do bazy danych sklepu i prezentowane w serwisie webowym firmy bez

konieczności udziału pracowników. Nie jest tu wymagana specjalistyczna wiedza na temat

konstruowania zaawansowanych systemów webowych, gdyż sposób w jaki zostało to
zrealizowane jest uniwersalny i łatwo dostosowywany praktycznie do każdej aplikacji

finansowo księgowej obsługującej podstawową działalność firmy. Zwrotnie informacje ze

sklepu internetowego mogą być w łatwy sposób ładowane do modułu zamówień lub
rezerwacji w firmie, tym samym udostępniając niezbędne informacje do bieżącej działalności

firmy. Chcąc zapewnić wymagane bezpieczeństwo operacji zdecydowano się na model
wsadowego ładowania danych do sklepu oraz jego fizyczne umiejscowienie na odrębnym

serwerze. LAN-serwer lokalny ładuje dane do serwera Internetowego, gdzie są one dalej

odpowiednio obrabiane i przetwarzane a następnie prezentowane w tam zlokalizowanym
serwisie internetowym firmy. Taki logiczny podział zadań pozwolił także na oddzielenie

i rozłożenie obciążeń pomiędzy obydwa serwery uniezależniając wewnętrzną pracę firmy od

obciążenia generowanego przez internautów a także na podniesienie bezpieczeństwa
w przypadku ataków na serwer internetowy. Konieczność zapewnienia ciągłej i bezawaryjnej

pracy wewnętrznego serwera firmy była tutaj zadaniem priorytetowym.

ODEL LOGICZNY I FUNKCJONALNY

Opierając się na założeniach wstępnych, stworzony został model działania sklepu
internetowego jak i całokształtu „obecności” firmy w Internecie. Roboczo na wewnętrzne

potrzeby całość oprogramowania obsługującego serwis internetowy firmy otrzymała nazwę

„eMarket”. Działanie całego systemu sprowadza się do przetwarzania różnego rodzaju
danych i komunikacji sieciowej co schematycznie obrazuje Rysunek

4. Założenia

początkowe dotyczące całości systemu doprowadziły do jego logicznej budowy w sensie
topologii sieciowej oraz przepływu danych. Zasoby informacyjne firmy chronione są przed

nieuprawnionym dostępem poprzez system uprawnień zarówno do systemów finansowo

księgowych oraz na niższym poziomie dostępu do plików, katalogów i udostępnionych
drukarek sieciowych. Korzystanie z zasobów Internetu także wymaga odpowiednich

uprawnień. Ostatnia plaga wirusów pocztowych wymusiła rezygnację z mało bezpiecznych

programów pocztowych typu Microsoft Outlook oraz uruchomienie systemu pocztowego

w oparciu o webserwer i przeglądarki na bazie oprogramowania TWIG, które zostało
zmodyfikowane i odpowiednio dostosowane do potrzeb firmy. Spowodowało to drastyczne

zakończenie problemów z zawirusowanymi załącznikami aktywującymi się automatycznie na
skutek różnego rodzaju błędów w oprogramowaniu pocztowym firmy Microsoft. Większość

systemów, działających na serwerach firmy korzysta i współpracuje z bazą danych

PostgreSQL. Baza ta została wybrana do zastosowań wymagających dużych obciążeń jako

jedyna obsługująca standardy SQL takie jak: zaawansowane transakcje i złączenia tabel,

sekwencje, triggery, wbudowany język konstruowania funkcji i procedur uruchamianych po
stronie samej bazy danych i wiele innych nowoczesnych metod. Z bazą współpracuje

webserwer Apache, na którym wykonują się skrypty PHP generujące dynamicznie strony

korzystając ze zgromadzonych danych. Na serwerze wewnętrznym firmy cyklicznie
uruchamiają się procesy pobierające dane z baz systemu finansowo księgowego. Dane są

wstępnie konwertowane i

przygotowywane do załadowania do bazy PostgreSQL.

Wykonywana jest konwersja strony kodowej ze standardu cp852 na iso-8859-2 a gotowe do

załadunku zbiory są przesyłane na serwer internetowy firmy. Więcej informacji na temat

standardów kodowania polskich znaków można znaleźć na Polskiej Stronie
Ogonkowej (

www.agh.edu.pl/ogonki

). Tu następuje załadunek poszczególnych zbiorów do

tabel w bazie danych. Wykonywane jest indeksowanie poszczególnych pól i w tym

momencie kończy się faza dostarczenia danych dla potrzeb sklepu. Schematycznie całość
tych procesów przedstawia Rysunek 5.

Taka logiczna organizacja przepływu danych jest jakby naturalna dla topologicznej
organizacji sieci firmy jak i specyfiki działania samego oprogramowania finansowo

Zasoby sprzętowe systemów

Zbiory danych i dokumentów

Przetwarzanie

danych

Rysunek 4 – Schemat przetwarzania danych.

księgowego. Rozdzielenie funkcji wstepnego przygotowania danych od ich prezentowania
pozwoliło na zachowanie bezpieczeństwa zasobów zgromadzonych na wewnętrzym

serwerze firmy poprzez ich fizyczne oddzielenie od warstwy aplikacji internetowych. Dalsza
ich prezentacja obciąża serwer internetowy i nie zakłóca działania sieci wewnętrznej. Nawet

w przypadku ewentualnej awarii czy ingerencji w zasoby serwera internetowego, maszyna

“produkcyjna” kontynuuje normalne działanie bez wpływu na bieżącą pracę firmy.

Pliki DBF systemu F/K

Konwersja danych

Załadowanie do bazy SQL

Wewnętrzny serwer firmy

Internetowy serwer firmy

Rysunek 5 – Schemat procesu obiegu informacji.

Rozdział III – P

RZYGOT OWANIE DANYCH

KONWERSJA DANYCH

Aplikacja finansowo księgowa firmy napisana w Clipperze 5.3 przechowuje dane w postaci
plików DBF. Struktura katalogów samej aplikacji zorganizowana jest w postaci katalogu

systemu podstawowego oraz podkatalogów poszczególnych magazynów. Na podstawie

analizy przechowywanych w poszczególnych plikach danych

określono że wstępnie na potrzeby sklepu internetowego

potrzebnych będzie kilka tabel z systemu podstawowego oraz ze
wszystkich poszczególnych magazynów. Rysunek 6 przedstawia

fizyczną organizację aplikacji na dysku sieciowym widzianą od

strony użytkowników sieci Windows a z drugiej strony od
wewnątrz serwera. Z poziomu użytkownika widziana jest struktura

katalogów począwszy od wnętrza katalogu „sklep” bowiem tak
udostępniony zasób Samby jest mapowany jako dysk logiczny.

Położenie całości aplikacji magazynowej na dyskach serwera umożliwiło dostęp do tych

danych pod kątem ich konwersji dla sklepu internetowego, bez zbędnego obciążania sieci
wewnętrznej transferami a jedynie obróbką samych danych na poziomie serwera. W celu

zapewnienia integralności danych konwersja wykonuje się automatycznie w godzinach

nocnych, tak aby to nie kolidowało z działalnością firmy a jednocześnie zapewniało
aktualność danych. Charakter działania aplikacji magazynowej wymusił takie przystosowanie

modułu konwersji do struktury katalogów, aby dodanie kolejnych magazynów automatycznie
zapewniało pobieranie danych także z nich.

W celu konwersji z formatu DBF do formatu tekstowego rozpatrywano dwa warianty.

Pierwszy opierał się na konwersji skryptem napisanym w języku Perl natomiast drugi
zakładał wykorzystanie gotowego i wielokrotnie szybszego programu w języku C którego

autorem jest Brad Eacker a kod był opublikowany w 1994r w grupach USENET.

Ostatecznie przeważyła szybkość konwersji nad elastycznością rozwiązania w Perlu. Chcąc
jednak zachować możliwość dostosowywania „wyciąganych” danych z tabel DBF, wyjściowe

pliki po kompletnej konwersji DBF na TXT obrabiane są już skryptem shellowym
napisanym z wykorzystaniem natywnych unixowi narzędzi takich jak awk czy tr. Poniższy

listing prezentuje ten skrypt opatrzony komentarzami wyjaśniającymi wykonywane działania:

Rysunek 6 - Katalogi.

#!/bin/sh

echo Subject: Konwersja baz eMarket
echo
echo Przygotowanie baz z MGZ do zasilenia bazy SQL eMarket....

# maska tworzenia plików z prawami odczyt/zapis dla wlasciciela i odczyt dla grupy
umask 027

# parametry poczatkowe, sciezki oraz zmienne:
KAT_MGZ='/work/sklep/MGZ2'
KAT_TMP='/bofh/bazy/emarket/tmp'

# sciezka do programu AnsiC konwersji dbf2lst
DBFLST='/bofh/bazy/emarket/bin/dbflst'

#echo Kasowanie starych zbiorow po poprzedniej konwersji
rm -f /bofh/bazy/emarket/tmp/*.LST
rm -f /bofh/bazy/emarket/tmp/*.IN

echo -n Start wstepnej konwersji zbiorkow zasilajacych glownych
$DBFLST $KAT_MGZ/CENNIK.DBF >$KAT_TMP/CENNIK.LST && echo -n .
$DBFLST $KAT_MGZ/CENY_DEW.DBF >$KAT_TMP/CENY_DEW.LST && echo -n .
$DBFLST $KAT_MGZ/ODBIORCY.DBF >$KAT_TMP/ODBIORCY.LST && echo -n .
$DBFLST $KAT_MGZ/DOSTAWCY.DBF >$KAT_TMP/DOSTAWCY.LST && echo .

echo -n Start konwersji zbiorkow stanow magazynowych
if [ -f $KAT_TMP/MAGAZYN.LST ] ; then
rm $KAT_TMP/MAGAZYN.LST
fi

# wykonujemy w petli przebieg po wszystkich katalogach magazynow
for MAGAZYN in `ls -d $KAT_MGZ/MAG_??` ; do
$DBFLST $MAGAZYN/MAGAZYN.DBF >>$KAT_TMP/MAGAZYN.LST && echo -n .
done

echo -n Wycinamy wymagane pola z rekordow
# i jak poszlo dobrze to kasujemy niepotrzebne *.LST

# konwersja pliku nazw towarow
cat $KAT_TMP/CENNIK.LST | awk -F\| 'ORS=""{}

{printf "%i", $2}
{gsub(" ", "", $3)} {print "|"toupper($3)}
{gsub(" ", "", $6)} {print "|"toupper($6)"|"}
{printf "%i", $7} {print "|"}
{printf "%G", $15} {print "\n"}' >$KAT_TMP/CENNIK.IN && \

rm $KAT_TMP/CENNIK.LST && echo -n .

# konwersja pliku cen towarow
cat $KAT_TMP/CENY_DEW.LST | awk -F\| 'ORS=""{}

{printf "%i",$2}{print "|"}
{printf "%G",$6}{print "|"}
{print $7"\n"}' >$KAT_TMP/CENY_DEW.IN && \

rm $KAT_TMP/CENY_DEW.LST && echo -n .

# konwersja pliku danych o dostawcach
cat $KAT_TMP/DOSTAWCY.LST | awk -F\| 'ORS=""{}

{printf "%i",$2}{print "|"}
{gsub(" ", "", $5)}{print toupper($5)"|"}
{gsub(" ", "", $6)}{print toupper($6)"|"}
{gsub(" ", "", $7)}{print toupper($7)"|"}
{gsub(" ", "", $8)}{print toupper($8)"|"}
{gsub(" ", "", $9)}{print toupper($9)"|"}
{gsub(" ", "", $10)}{print toupper($10)"|"}
{gsub(" ", "", $11)}{print toupper($11)"|"}
{gsub(" ", "", $12)}{print toupper($12)"|"}
{gsub(" ", "", $14)}{print $14"\n"}' >$KAT_TMP/DOSTAWCY.IN && \

rm $KAT_TMP/DOSTAWCY.LST && echo -n .

# konwersja pliku danych o odbiorcach
cat $KAT_TMP/ODBIORCY.LST | awk -F\| 'ORS=""{}

{gsub(" ", "", $14)}{print $14"\n"}' >$KAT_TMP/ODBIORCY.IN && \

rm $KAT_TMP/ODBIORCY.LST && echo -n .
# konwersja pliku cen towarow
cat $KAT_TMP/MAGAZYN.LST | awk -F\| 'ORS=""{}

{printf "%i",$2}{print "|"}
{gsub(" ", "", $6)}{print $6"|"}
{printf "%G",$14}{print "|"}
{printf "%G",$18}{print "\n"}' >$KAT_TMP/MAGAZYN.IN && \

rm $KAT_TMP/MAGAZYN.LST && echo -n .

# ustalamy prawa do plikow po konwersji
chmod u+rw-x,g+rw-x,o-rwx $KAT_TMP/CENNIK.IN
chmod u+rw-x,g+rw-x,o-rwx $KAT_TMP/CENY_DEW.IN
chmod u+rw-x,g+rw-x,o-rwx $KAT_TMP/MAGAZYN.IN
chmod u+rw-x,g+rw-x,o-rwx $KAT_TMP/DOSTAWCY.IN
chmod u+rw-x,g+rw-x,o-rwx $KAT_TMP/ODBIORCY.IN

echo
echo Zbiorki po konwersji zajmuja\:
echo
echo "KB: Nazwa:"
du -k $KAT_TMP/*.IN
echo

echo Upload plikow dla bazy emarket
cd /bofh/bazy/emarket/tmp
echo Zaczynamy transfer...

# wywolujemy skrypt ftp transfer na podstawie listy polecen
ftp -p < /bofh/bazy/emarket/tmp/transfer

echo Zaladowane.

ARCHIWIZACJA I PRZESYŁANIE DANYCH

Skrypty są wywoływane cyklicznie co noc wykonując wstępne przygotowanie danych oraz
ich przesłanie przy pomocy ftp na serwer internetowy, gdzie następuje dalsza faza obróbki

danych i ich ładowanie do PostgreSQL. Oprócz skasowania starych zbiorów i wkopiowania
na ich miejsce nowych wykonywana jest także archiwizacja. Przy pomocy poniższej listy

poleceń skryptu „transfer” dane przekazywane są protokołem ftp na serwer internetowy:

open inet-serwer
bin
cd /home/bazy/emarket/tmp

del /home/bazy/emarket/tmp/CENNIK.IN
del /home/bazy/emarket/tmp/CENY_DEW.IN
del /home/bazy/emarket/tmp/DOSTAWCY.IN
del /home/bazy/emarket/tmp/MAGAZYN.IN
del /home/bazy/emarket/tmp/ODBIORCY.IN

put /bofh/bazy/emarket/tmp/CENNIK.IN /home/bazy/emarket/tmp/CENNIK.IN
put /bofh/bazy/emarket/tmp/CENY_DEW.IN /home/bazy/emarket/tmp/CENY_DEW.IN
put /bofh/bazy/emarket/tmp/DOSTAWCY.IN /home/bazy/emarket/tmp/DOSTAWCY.IN
put /bofh/bazy/emarket/tmp/MAGAZYN.IN /home/bazy/emarket/tmp/MAGAZYN.IN
put /bofh/bazy/emarket/tmp/ODBIORCY.IN /home/bazy/emarket/tmp/ODBIORCY.IN
ls
bye

Wyniki wykonania całej operacji są „wyświetlane” na standardowe wyjście (stdout)

a następnie wysyłane pocztą email do administratora. Pozwala to na kontrolę poprawności
działania całej operacji, gdyż odbywa się ona bezobsługowo. Cykliczność wykonania tych

działań realizowana jest dwoma wpisami w pliku konfiguracyjnym crontab. Zapewniają one

oprócz konwersji i przekazania danych na serwer internetowy także archiwizację całości
systemów finansowo księgowych firmy i umieszczenie ich w katalogu udostępnionym

obsłudze w celu przegrania na wymienne nośniki:

# zrob archiwizacje codziennie po dniu roboczym o 3:00 w nocy
#minute hour mday month wday what
0 3 * * 1,2,3,4,5,6 /bofh/bin/archiwizacja 2>&1 | /usr/sbin/sendmail operator
# zrob konwersje i przekazanie danych o 20:00
0 20 * * 1,2,3,4,5,6 /bofh/bazy/emarket/konwersja 2>&1 | /usr/sbin/sendmail operator

Archiwizacja wykonywana jest poniższym skryptem przygotowującym paczkę do
przekopiowania na nośniki wymienne:

#!/bin/sh
# odpalane z crona codziennie w nocy
echo "Subject: Status archiwizacji"
echo
echo Archiwizacja...

dladaty=`date "+20%y%m%d"`
echo $dladaty

# przygotowanie ksiegowosci
echo KSH
cd /work/ksieg
tar -czf /home/archiwa/ksz$dladaty.tgz ./KSH2/*
echo OK.

# przygotowanie magazynow
echo MGZ
cd /work/sklep
tar -czf /home/archiwa/mzz$dladaty.tgz ./MGZ2/*
echo MGZ OK.

echo Archiwa zajmuja obecnie\:
echo KBytes Nazwa pliku
du -k /home/archiwa/
echo Zajetosc dyskow\:
df -ki
echo KONIEC

TRUKTURA KONWERTOWANYCH PLIKÓW

W celu wykonania operacji konwersji danych na potrzeby sklepu internetowego poddano

analizie zawartość poszczególnych plików DBF systemów magazynowych. Wyodrębniono
przydatne tabele i na ich podstawie określone pola niezbędne dla działania sklepu. Poniższy

fragment każdego z plików przekazywanych do zaimportowania do bazy SQL obrazuje jakie
dane są wykorzystane z systemów finansowo księgowych firmy:

# Fragment pliku CENNIK.IN
# struktura pliku:
# ind | nazwa towaru cp852 | ozn. producenta | stan | VAT

167636|UCHWYT ZEZ+OBEJMA FI 40|UCHWYT ZEZ+OBEJMA |16|22
982027|YAMAHA RX-V 520 AMPLITUNER AV TI.|YAMAHA RX-V520 TI.|17|22
300405|KAMERA PANASONIC NV-DS27 EG|PANASONIC NV-DS27 |57|22
300052|TELEWIZOR PANASONIC TX 29 AS10P|PANASONIC TX 29 AS|78|22
300051|MAGNETOWID PANASONIC NV-FJ 762 EE|PANASONIC NV-FJ762|78|22
300050|MAGNETOWID PANASONIC NV-FJ 622 EE|PANASONIC NV-FJ622|78|22
51102|PANASONIC RT-60MC MIKROKASETA|PANASONIC RT-60MC |5|22

# Fragment pliku CENY_DEW.IN
# struktura pliku:
# ind | cena netto | symbol waluty

330055|1146.72|ZLP
110003|548.36|ZLP
140021|1638.52|ZLP
167636|14.75|ZLP
500018|10.66|ZLP
51102|6.56|ZLP

# Fragment pliku DOSTAWCY.IN oraz ODBIORCY.IN
# struktura pliku:
# ind | nazwa krotka | nazwa dluga | adres1 ... adres6 | nip

1|WIZJA TV |WIZJA TV|UL.PAWINSKIEGO 5A/BLOK D|02-106 WARSZAWA |||||113-15-59-441
28|PHILIPS AGD|PHILIPS POLSKA SP Z.O.O.|02-222 WARSZAWA |AL. JEROZOLIMSKIE 195 B |||||526-021-09-55
43|THOMSON|THOMSON CONSUMER ELECTRONIC POLAND|UL OKULICKIEGO 7/9|05 - 500 PIASECZNO|||||123-00-05-409

# Fragment pliku MAGAZYN.IN
# struktura pliku:
# ind | data | stan dyspozycyjny | stan ksiegowy

240029|20010528|2|2
270018|20010703|28|28
270015|20010628|19|19

ONWERSJA STRONY KODOWEJ

Dane rejestrowane w systemie finansowo księgowym firmy są danymi „brudnymi” pod
względem historycznie stosowanych kodowań, poczynając od standardu polskich znaków

Mazovia poprzez Latin i inne a kończąc na cp852. Koniecznym było dokonanie konwersji
tych danych do jednolitego formatu jednak różnorodność stacji roboczych oraz ich

wykorzystanie do różnych celów wykluczała wykonanie tego na głównych danych firmy oraz

na zastosowanie jednakowego kodowania na wszystkich końcówkach. Konwersją polskich
znaków został „obarczony” serwer internetowy, gdzie wykonywana jest ona przed

wczytaniem danych do bazy SQL. Skrypt konwertujący jest uniwersalnym narzędziem

napisanym przez tragicznie zmarłego w 1996r dziennikarza Krakowskiej Gazety Wyborczej
Andrzeja Górbiela (

http://studweb.euv-frankfurt-o.de/twardoch/f/pl/comp/gorbiel/

Poniższy listing przedstawia tego skryptu:

#!/bin/sh
#
# plconv - filtr do konwersji polskich znakow diakrytycznych
#
# (c) 1994 Andrzej Gorbiel <A.Gorbiel@Ga-Wyb.Krakow.PL>
#
# a, c' e, l\ n' o' s' z' z. A, C' E, L\ N' O' S' Z' Z~
MAZ="\206\215\221\222\244\242\236\246\247\217\225\220\234\245\243\230\240\241"
LAT="\245\206\251\210\344\242\230\253\276\244\217\250\235\343\340\227\215\275"
WIN="\271\346\352\263\361\363\234\237\277\245\306\312\243\321\323\214\217\257"
ISO="\261\346\352\263\361\363\266\274\277\241\306\312\243\321\323\246\254\257"
TXT="acelnoszzACELNOSZZ"
MAZTAB="\206\215\221\222\244\242\236\246\247\217\225\220\234\245\243\230\240\241\277\263\
300\301\302\303\304\305\331\332\264"
ISOTAB="\261\346\352\263\361\363\266\274\277\241\306\312\243\321\323\246\254\257\53\174\53\
53\55\174\55\53\53\53\174"

ShowHelp ()
{
echo "Uzycie: $0 standard_we standard_wy [ < plik wejsciowy > plik wyjsciowy]"

echo " dopuszczalne standardy:"
echo " MAZ - Mazovia"
echo " LAT - Latin-2 (MS-DOS CP 852)"
echo " WIN - Windows ANSI (CP 1250)"
echo " ISO - ISO Latin-2 (CP 8859/2)"
echo " TXT - ASCII (7-bit)"
exit
}

SetStd ()
{
case $1 in

MAZ) std=$MAZ;;
LAT) std=$LAT;;
WIN) std=$WIN;;
ISO) std=$ISO;;
TXT) std=$TXT;;
MAZTAB) std=$MAZTAB;;
ISOTAB) std=$ISOTAB;;
*) ShowHelp; exit;;

esac
}

if [ $# != 2 ]; then ShowHelp; fi

SetStd $1
std1=$std
SetStd $2

tr "$std1" "$std"

AŁADOWANIE DANYCH DO BAZY

OSTGRE

SQL

Pliki w formacie tekstowym wczytywane są po ich otrzymaniu z serwera wewnętrznego
firmy. W tym momencie wykonywana jest konwersja kodowania na stronę kodową iso88592

(obowiązujący standard kodowania polskich znaków na stronach www tzw. iso-latin2).
Proces ten wywoływany jest również jako cykliczne zadanie w crontab’ie następującym

wpisem w plik konfiguracyjny:

# zasilenie dla emarket codziennie o 20:30
30 20 * * 1,2,3,4,5,6,7 /home/bazy/emarket/zaladunek 2>&1 | /var/qmail/bin/qmail-inject

Skrypt „załadunek” zbudowany jest podobnie jak skrypt konwersji danych na maszynie

wewnętrznej i wykonywane działania wyświetla na standardowe wyjście (stdout) co jest
poprzez sposób wywołania w corntab wysyłane jako raport do operatora. Jedyną różnicą

w wywołaniu skryptu jest to, iż działa on na tej samej maszynie na której zainstalowany
został system pocztowy Qmail i dlatego można było wykorzystać jeden z pocztowych

programów usługowych do dostarczenia poczty bezpośrednio do adresata. Działania takie

maja na celu informowanie obsługi lub administratorów o wszelkich występujących
problemach a także o powodzeniu każdego z etapów działania sklepu internetowego.

Poniższy skrypt prezentuje działania wykonywane w czasie importowania danych do bazy

PostgreSQL:

#!/bin/sh

echo "From: zaladunek <operator@localhost>"
echo "To: operator"
echo "Subject: Zaladowanie danych do bazy eMarket."
echo

# zdefiniowanie polozenia katalogow roboczych
KAT_TMP='/home/bazy/emarket/tmp'
PATH=$PATH:/usr/local/pgsql/bin ; export PATH
BINARIA='/home/bazy/emarket'
cd $BINARIA

#echo Sprawdzenie czy sa sciagniete pliki zasilajace...

pliki=`ls $KAT_TMP/*.IN | wc -l`

if [ $pliki != 5 ] ; then
echo Brak pliku zasilajacego.
echo Sa tylko te...
echo
ls -l $KAT_TMP/*.IN
echo
echo STOP.
exit 1
fi

echo Jest wszystkie $pliki plikow...
echo
ls -l $KAT_TMP/*.IN
echo

# konwersja strony kodowej
echo Konwersja pl znakow na ISO
($BINARIA/bin/plznaki LAT ISO < $KAT_TMP/CENNIK.IN > $KAT_TMP/CENNIK.PL) && \
mv $KAT_TMP/CENNIK.PL $KAT_TMP/CENNIK.IN && chmod a+r $KAT_TMP/CENNIK.IN

# data i czas rozpoczecia zaladunku
echo Zaczynamy o `date`

# ustawienie znacznika zaladunku do bazy
# skrypty php sklepu blokuja dostep do bazy w przypadku
# wykrycia obecnosci tego pliku na czas zaladunku danych
echo Tymczasowe zablokowanie dostepu do bazy...
touch $KAT_TMP/emarket.tmp

# 90-usuntabele
$BINARIA/90-usuntabele

# 20-zaloztabele
$BINARIA/20-zaloztabele

# 30-zaladujtabele
$BINARIA/30-zaladujtabele

# 40-zalozindeksy
$BINARIA/40-zalozindeksy

# 40-zaladujkatalog
$BINARIA/40-zaladujkatalog

# 45-optymalizuj
$BINARIA/45-optymalizuj

# 50-statystyka
$BINARIA/50-statystyka

echo Konczymy o `date`
echo Odblokowanie dostepu do bazy...

rm $KAT_TMP/emarket.tmp

echo
echo Koniec ladowania.

Etapy załadunku danych do bazy zostały podzielone na osobne funkcjonalne części,
co ułatwia ewentualne diagnozowanie nieprawidłowości oraz dalszy rozwój tego

oprogramowania. Każdy ze skryptów wykonujących działania na bazie PostgreSQL otrzymał
nazwę zbudowaną z początkowych dwóch cyfr oznaczających jego logiczną kolejność

w wykonaniu, analogicznie jak to ma miejsce w przypadku skryptów startowych w systemach

UNIX typu SysV 4.2 gdzie takie uporządkowanie występuje oraz w systemach BSD
w skryptach administracyjnych (daily, weekly, monthly itp.). Omówienie poszczególnych

skryptów SQL zostało umieszczone w kolejnych rozdziałach traktujących o samej strukturze

bazy danych. Wspomnieć należy, iż aby wykorzystywać bazę danych PostgreSQL,
administrator bazy założył odpowiednich użytkowników bazy z hasłami dostępu

i uprawnieniami pozwalającymi na czynności administracyjne. Głównym plikiem
konfiguracyjnym PostgreSQL regulującym dostęp określonych użytkowników z określonych

hostów jest plik konfiguracyjny „pg_hba.conf”. Dokładnie omawia to dokumentacja

PostgreSQL (

www.postgresql.org/idocs/index.php?client-authentication.html

). Sposób

autoryzacji (czy system wymaga hasła czy też nie) jest definiowany w tym pliku. Na jego

końcu przy domyślnej konfiguracji znajdują się wpisy:

local all trust
host all 127.0.0.1 255.255.255.255 trust

Oznaczają one, że dla połączeń lokalnych (local) - czyli takich, gdzie łączymy się nie

korzystając z socket’ów tcpip i dla dowolnej bazy (all), system ma przyjąć regułę nie pytania

o hasło (trust) natomiast dla połączeń zdalnych, ale tylko z maszyny o adresie 127.0.0.1 (czyli
z tego samego hosta, ale przez sockety tcpip), będzie obowiązywać ta sama reguła. Aby to

zmienić należy zastąpić ostatnie słowo (trust) na "password" lub "crypt" (różnią się one
metodą przesyłania hasła). Przykładowo zapis:

host all 192.168.1.10 255.255.255.0 password

Oznacza, że osoby łączące się z serwera o adresie 192.168.1.10 oraz z całej klasy C (czyli
w rzeczywistości adres ip może być typu 192.168.1.*) muszą podać hasło aby dostać się do

dowolnej bazy. Chcąc wymusić aby wzorcowy szablon bazy PostgreSQL był także

chroniony można dokonać zapisu:

host template1 192.168.1.10 255.255.255.0 password

co oznacza, że te same osoby będą mogły teraz dostać się tylko do bazy template1 i będą
musiały podać hasło. Metod autoryzacji użytkowników jest wiele, między innymi także na

podstawie protokołu ident. Przy pisaniu reguł dostępu należy pamiętać o kolejności. Zawsze

użyta zostanie ta reguła która jest pierwsza w pliku i pasuje do sytuacji (regułki
przeszukiwane są w kolejności od początku do końca pliku aż do znalezienia pierwszej

pasującej i na tym się kończy przeszukiwanie). Poniższy zapis byłby błędny, pozbawiony
sensu poprzez swoją błędną hierarchię:

local all trust
host all 127.0.0.1 255.255.255.255 trust
local template1 password
host template1 127.0.0.1 255.255.255.255 password

Poprawnej konfigurację tej access listy przedstawia przykładowy zapis:

local template1 password
host template1 127.0.0.1 255.255.255.255 password
local all trust
host all 127.0.0.1 255.255.255.255 trust

W przypadku konfiguracji rzeczywistej sklepu wpisy dopuszczające ustalają dostęp do bazy
sklepu nazwanej jako „emarket” tylko i wyłącznie z serwera na którym działa sklep oraz dla

określonego użytkownika z hasłem. Zapewnia to już zwiększony poziom bezpieczeństwa

poprzez odrzucenie przez silnik bazy danych połączeń pochodzących zarówno od
użytkowników lokalnych serwera jak i zdalne próby nawiązania połączeń (choć to także

zabezpiecza zastosowany firewall). PostgreSQL zapewnia ponadto zabezpieczenia dostępu

do tabel zgodnie ze standardem SQL92 (

www.postgresql.org/idocs/index.php?sql.html

Na zasadzie przywilejów na konkretne działania i operacje na krotkach, tabelach, indeksach,

procedurach czy funkcjach. Można tu bardzo precyzyjnie określać co, kto jak i kiedy może
uczynić ze zgromadzonymi danymi, czy może tylko czytać nasze dane czy też usuwać,

poprawiać, dodawać nowe itp.

Rozdział IV – S

TRUKTU RA I ORGANIZACJA BAZY EMARKET

KRYPTY ADMINISTRACYJNE

Chcąc zautomatyzować czynności tworzenia i uruchomienia samej bazy, a także jej zasilania
danymi na potrzeby sklepu napisano skrypty powłoki wywołujące określone działania

w bazie danych. Proces zasilania danymi sterowany jest głównym skryptem wywołującym
poszczególne pod-skrypty odpowiedzialne za pewne fragmenty działania poszczególnych

zadań zasilania w dane całej bazy. Niektóre z nich uruchamiane są jednorazowo w momencie

tworzenia bazy lub też jej kasowania. Inne pozwalają na wykonanie pewnych analiz
(na obecnym etapie rozwoju aplikacji jedynie w minimalnym zakresie). Większość danych

ładowana jest bez natychmiastowego indeksowania co znacząco przyśpiesza całą operację.

Dopiero po załadowaniu danych do tabel następuje zaindeksowanie wszystkich wymaganych
pól w konkretnych tabelach. Na samym końcu wykonywana jest „odkurzenie” bazy

pozwalająca PostgreSQL’owi na empiryczną i statystyczną optymalizację wyszukiwania
danych. Poniższe zestawienie prezentuje i omawia wywołania wszystkich skryptów.

#!/bin/sh
# skrypt 20-zaloztabele
#
echo Zalozenie tabel bazy emarket SQL...
#

KAT_SQL='/home/bazy/emarket/sql'
SQL='/usr/local/pgsql/bin/psql -d emarket -q -f'

echo

echo cennik...
$SQL $KAT_SQL/create/create_table_cennik.sql

echo cenydew...
$SQL $KAT_SQL/create/create_table_cenydew.sql

echo dostawcy...
$SQL $KAT_SQL/create/create_table_dostawcy.sql

echo magazyn...
$SQL $KAT_SQL/create/create_table_magazyn.sql

echo odbiorcy...
$SQL $KAT_SQL/create/create_table_odbiorcy.sql

#echo informacje...
$SQL $KAT_SQL/create/create_table_informacje.sql

echo
echo Koniec.

Powyższy pod-skrypt „20-zaloztabele” odpowiedzialny jest za początkowe założenie

niezbędnych tabel w bazie SQL. Wywołuje już bezpośrednio, napisane w dialekcie języka

SQL92 polecenia zakładające poszczególne tabele z polami określonego typu.

#!/bin/sh
# skrypt 20-zaladujtabele
#
echo Zaladowanie danych do tabel bazy emarket SQL...
#

KAT_SQL='/home/bazy/emarket/sql'
SQL='/usr/local/pgsql/bin/psql -d emarket -q -f'

echo

echo cennik...
$SQL $KAT_SQL/load/load_table_cennik.sql

echo cenydew...
$SQL $KAT_SQL/load/load_table_cenydew.sql

#echo dostawcy...
#$SQL $KAT_SQL/load/load_table_dostawcy.sql

#echo odbiorcy...
#$SQL $KAT_SQL/load/load_table_odbiorcy.sql

echo magazyn...
$SQL $KAT_SQL/load/load_table_magazyn.sql

echo
echo Przy okazji skorygujemy bledne dane...

# pewne dane w zasilajacych zbiorach sa zduplikowane lub nie maja
# wypelnionych wymaganych pol (zaszlosc historyczna) poprawiamy to tutaj
SQL='/usr/local/pgsql/bin/psql -d emarket -q -c'
$SQL "UPDATE magazyn SET data='19940505' where data=' ';"
#$SQL "DELETE FROM cenydew where indeks='984001' and cenat='1036.07';"

SQL='/usr/local/pgsql/bin/psql -d emarket -q -f'
echo uniqmagazyn...
$SQL $KAT_SQL/load/load_table_uniqmagazyn.sql

echo Koniec.

Powyższy pod-skrypt „20-zaladujtabele” wywołuje skrypty SQL92 wczytujące i korygujące

dane bezpośrednio do tabel w bazie. Niektóre dane (np. odbiorcy i dostawcy) nie są
wczytywane na obecnym etapie rozwoju sklepu internetowego aż do momentu gdy aplikacja

zostanie rozbudowana o moduły współpracy z partnerami handlowymi (B2B), realizację
wymiany partnerskiej, dynamicznie konstruowane cenniki w zależności od podpisanych

umów na upusty globalne itp.

#!/bin/sh
# Skrypt 40-zaladujkatalog
#
echo Zaladowanie danych do tabel bazy emarket SQL...
#

KAT_SQL='/home/bazy/emarket/sql'
SQL='/usr/local/pgsql/bin/psql -d emarket -q -f'

echo

echo ladujemy dane do tabeli katalog...
$SQL $KAT_SQL/load/load_table_katalog.sql

echo indeksujemy tabele katalog...
$SQL $KAT_SQL/create/create_index_katalog.sql

echo
echo Koniec.

Powyższy pod-skrypt generuje dane do dodatkowo tworzonej tabeli zawierającej
wyfiltrowane dane z tabeli zawierającej dane ze wszystkich magazynów. W aplikacji

finansowo księgowej firmy, każdy magazyn zawiera towary współistniejące w innych
magazynach. Każdy z magazynów posiada ten sam indeks dla towaru, zgodny z innymi

indeksami w pozostałych magazynach. Każdy z nich ma swój własny stan magazynowy

(dyspozycyjny i księgowy) oraz cenę. Istnieje także globalna tabela cen dewizowych
przechowująca wspólną cenę dla wszystkich magazynów. Idea działania aplikacji

magazynowej w firmie jest taka, iż gdy istnieje dla danego towaru cena w centralnym cenniku

to właśnie ona ma przewagę nad ceną lokalną w danym magazynie, dlatego tutaj właśnie
zdecydowano się na zagregowanie tych danych w jeden wspólny rekord będący podstawą do

dalszego działania sklepu.

#!/bin/sh
# skrypt 40-zalozindeksy
echo Zalozenie indeksow bazy emarket SQL...
#

KAT_SQL='/home/bazy/emarket/sql'
SQL='/usr/local/pgsql/bin/psql -d emarket -q -f'

echo

echo cennik...
$SQL $KAT_SQL/create/create_index_cennik.sql

echo cenydew...
$SQL $KAT_SQL/create/create_index_cenydew.sql

#echo dostawcy...
#$SQL $KAT_SQL/create/create_index_dostawcy.sql

#echo magazyn...
#$SQL $KAT_SQL/create/create_index_magazyn.sql

#echo odbiorcy...
#$SQL $KAT_SQL/create/create_index_odbiorcy.sql

echo uniqmagazyn...
$SQL $KAT_SQL/create/create_index_uniqmagazyn.sql

echo informacje...
$SQL $KAT_SQL/create/create_index_informacje.sql

echo
echo Koniec.

Powyższy pod-skrypt indeksuje wszystkie potrzebne pola w tabelach. Wykonywane jest to
dopiero po wczytaniu całości danych gdyż w ten sposób uniknięto przebudowywania

indeksów przy wczytywaniu danych do tabel i uzyskano znaczny wzrost szybkości całej

operacji importu danych. Silnik bazy danych w takim przypadku nie wykonuje blokad przy
dodawaniu rekordów a i same dane są fizycznie na dysku nie pofragmentowane, co miało by

miejsce, gdyby równocześnie trwało przeplatanie wczytania rekordu i zaktualizowanie

indeksu. Co prawda leżący u podstaw systemu plików mechanizm dba o takie

rozmieszczenie plików, aby ulegały jak najmniejszej fragmentacji, jednak odbywa się to
kosztem zwiększonego zapotrzebowania na zasoby systemu. Pamiętajmy że PostgreSQL

przechowuje wszystkie obiekty bazy w osobnych plikach.

#!/bin/sh
# skrypt 45-optymalizuj
echo Optymalizacja bazy emarket SQL...
#

echo

/usr/local/pgsql/bin/vacuumdb --analyze emarket

echo
echo Koniec.

Powyższy pod-skrypt uruchamia mechanizmy analizy i optymalizacji wbudowane w silnik
bazy danych. W przypadku bazy, w której nie są kasowane tabele z danymi ten mechanizm

wpływa na „uczenie” się rozkładu danych i wykorzystywanie metod stochastycznych dla

przyspieszenia dostępu do danych i powinien być uruchamiany okresowo. W przypadku
bazy eMarket nie ma on aż tak znaczącego wpływu, gdyż dane są stale „młode”.

#!/bin/sh
# skrypt 50-statystyka
echo Statystyka tabel bazy emarket SQL...
#

KAT_SQL='/home/bazy/emarket/sql'
SQL='/usr/local/pgsql/bin/psql -d emarket -q -c'

echo
echo Zaladowane rekordy w tabelach:

echo cennik...... `$SQL "SELECT count(*) FROM cennik;"`
echo ceny_dew.... `$SQL "SELECT count(*) FROM cenydew;"`
echo dostawcy.... `$SQL "SELECT count(*) FROM dostawcy;"`
echo uniqmagazyn. `$SQL "SELECT count(*) FROM uniqmagazyn;"`
echo odbiorcy.... `$SQL "SELECT count(*) FROM odbiorcy;"`
echo katalog..... `$SQL "SELECT count(*) FROM katalog;"`
echo informacje.. `$SQL "SELECT count(*) FROM informacje;"`

echo
echo Koniec.

Powyższy pod-skrypt zlicza ilości krotek w poszczególnych tabelach po załadowaniu danych

oraz je prezentuje co zostaje dołączone przy wczytywaniu danych do raportu kontrolnego
przesyłanego administratorom.

#!/bin/sh
# skrypt 80-usunindeksy
echo Skasowanie indeksow bazy emarket SQL...
#

KAT_SQL='/home/bazy/emarket/sql'
SQL='/usr/local/pgsql/bin/psql -d emarket -q -f'

$SQL $KAT_SQL/delete/drop_all_index.sql

echo
echo Koniec.

#!/bin/sh
# skrypt 90-usuntabele
echo Skasowanie tabel bazy emarket SQL...
#

KAT_SQL='/home/bazy/emarket/sql'
SQL='/usr/local/pgsql/bin/psql -d emarket -q -f'

$SQL $KAT_SQL/delete/drop_all_table.sql

echo
echo Koniec.

Powyższe dwa pod-skrypty usuwają wszystkie tabele i indeksy z bazy eMarket. Wykonywane
są przed załadowaniem nowych danych do tabel. Operacja skasowania całych tabel wraz

z indeksami jest nieporównywalnie szybsza niż kasowanie zawartości tabel a ponadto
fizycznie usuwane są niepotrzebne już pliki z dysku serwera.

#!/bin/sh
# 95-czysctmp
echo Usuwanie plikow zasilenia bazy SQL eMarket....
#

# parametry poczatkowe:

KAT_TMP='/home/bazy/emarket/tmp'

rm $KAT_TMP/CENNIK.IN
rm $KAT_TMP/CENY_DEW.IN
rm $KAT_TMP/ODBIORCY.IN
rm $KAT_TMP/DOSTAWCY.IN
rm $KAT_TMP/MAGAZYN.IN

echo Zbiorki zasilajace usuniete!
echo Koniec.

Powyższy pod-skrypt ma na celu fizyczne usunięcie niepotrzebnych zbiorów zasilających.

Jest uruchamiany w tylko specyficznych przypadkach, bowiem zbiory te są kasowane przy

przesyłaniu danych z serwera wewnętrznego firmy.

#!/bin/sh
# 99-struktura
echo Struktura bazy emarket SQL...
#

echo "\d cennik"