INTERNETOWE BAZY DANYCH
(notatki do wykładów)
dr inż. Paweł Skrobanek
Wrocław 2006
2
Spis treści:
1. Bazy danych w Internecie....................................................................................................... 3
1.1. Wprowadzenie................................................................................................................. 3
1.2. Wybór technologii oraz architektury............................................................................... 5
X. Bibliografia.......................................................................................................................... 11
3
1. Bazy danych w Internecie
1.1. Wprowadzenie
Internetowe bazy danych  takie, do których dostęp jest możliwy z sieci Internet.
Cele projektów informatycznych wykorzystujących bazy danych:
" zastąpienie dotychczasowego systemu w celu poprawienia wydajności
(gdy system  ręczny lub komputerowy nie nadąża z przetwarzaniem dużej
ilości transakcji lub nie umożliwia ich realizacji na dużą skalę),
" obniżkę kosztów związanych z realizacją transakcji lub dystrybucją informacji
(np. rezygnacja z  papierowego przekazywania informacji w dużych firmach),
a w przypadku sklepów internetowych  brak kosztów związanych z obsługą
osób nie dokonujących żadnych transakcji,
" uzyskanie lepszego obiegu informacji w przypadku systemów związanych z jej
dystrybucją lub zwiększenie liczby klientów,
" poprawę image przedsiębiorstwa,
" zwiększenie  dostępności firmy dla klienta (nie jest problemem 24 h dostęp),
" uzyskanie możliwości zbierania informacji o guście i upodobaniach klientów
(w tym zakresie stosowane są nawet techniki znane wcześniej ze zwykłych
sklepów, np. ustawianie przy kasach odpowiednich produktów = np.
wyświetlanie w odpowiedni sposób informacji w oknie koszyka).
Ryzyko i zagrożenia:
" związane z projektem (typowo: złe oszacowanie kosztów przedsięwzięcia,
niedopracowany lub nieprzemyślany projekt interfejsu, trudności z  dotarciem
odbiorcy do naszej witryny, trudności z implementacją nieprzewidzianych
wcześniej elementów  skalowalność systemu, niezrozumienie lub zła
specyfikacja potrzeb zleceniodawcy i odbiorcy projektu przez  informatyków ),
" działania hakerów,
" awarie sprzętu oraz błędy w oprogramowaniu,
" często zmieniające się przepisy prawne,
" zawodność dostawców,
" aktualizacja danych (np. modyfikacja cen).
4
Bardzo ważnym problem stanowią przepisy prawne związane między innymi z ochroną
danych osobowych (konieczność rejestracji baz danych przechowujących tego rodzaju
informacje), koniecznością odpowiedniego rejestrowania transakcji oraz odpowiednie metody
jej dokumentowania. Z tym wiąże się również problem składowania całej dokumentacji oraz
okresy jej przechowywania. W przypadku dokumentacji sprzedaży typowym okresem jest 5
lat, a np. dla dokumentów płacowych jest to 50 lat. Stosowanie podpisu elektronicznego,
wymagane certyfikaty w tym zakresie  to kolejne problemy z jakimi można się zetknąć.
Dobrze byłoby w przypadku serwisów związanych z  biznesem zasięgnąć opinii prawnika,
jeśli pewne zagadnienia związane z jego funkcjonowaniem nie są dla nas w pełni zrozumiałe.
Być może konieczna będzie również  opieka prawna w ramach outsourcing u.
Pewnych zagrożeń nie można uniknąć i trzeba odpowiednio im zapobiegać. W zakresie
zabezpieczenia przed niepowołanym dostępem konieczna jest współpraca na kilku
płaszczyznach: administratora systemu, webmastera oraz administratora bazy danych. Jeśli
planujemy przedsięwzięcie związane z Internetem, to należy te dodatkowe koszty
(np. związane ze stworzeniem stanowiska pracy lub outsourcing iem) uwzględnić.
Typowe zastosowania Internetowych baz danych:
" serwisy WWW - m. in. uniezależnienie prezentowanych treści od  wyglądu
witryny,
" e  commerce,
" inne usługi np. serwer poczty WWW, forum internetowe, baza dokumentów.
Pierwsze rozwiązanie może być wykorzystane w firmach do uniezależnienia strony
wizualnej od serwisu WWW. Może zostać utworzona baza danych zawierająca informacje,
które są następnie umieszczane na stronach internetowych. Można pójść dalej i wykorzystując
architekturę trój warstwową oddzielić warstwę związaną z prezentacją danych od warstwy
kodu php i bazy danych.
Rozważmy prosty przykład.
Sekretariat szkoły policealnej umieszcza na stronach WWW informacje dotyczące
oferty szkoły (wysokość czesnego, opłat miesięcznych, informacje o realizowanych
przedmiotach i programie nauczania, itp.). W celu aktualizacji tych informacji przekazuje w
formie wydruku tekst informatykowi, który następnie aktualizuje stronę WWW.
W przypadku, gdy prywatna firma obsługuje wiele szkół, to taka procedura ma miejsce dla
każdej szkoły, a czasem  dla każdego przedmiotu (ponieważ informacje o zajęciach podają
5
również wykładowcy). Jeśli strony WWW zawierają kod PHP, to dodatkowo zmiany może
wprowadzać tylko informatyk posiadający umiejętności w tym zakresie. Dodatkowe
niebezpieczeństwo tkwi także w tym, iż przez przypadek można spowodować np. skasowanie
jakiegoś fragmentu kodu php i konieczne będzie wówczas znalezienie błędu.
Jeśli zostałaby zastosowana w tym przypadku architektura 3  warstwowa, to pracownik
sekretariatu loguje siÄ™ do bazy danych i w odpowiednim miejscu modyfikuje zapisane
informacje. W tej sytuacji jednak konieczne jest odpowiednie przeszkolenie pracownika lub
dostarczenie mu stosownej instrukcji  obsługi .
Które z podanych rozwiązań będzie lepsze, to zależy od wielu czynników, począwszy
od ilości zmian serwisu w ciągu roku, posiadanych w bieżącym momencie czasu rozwiązań
(firma mogła zaczynać od jednej strony WWW, która była rozwijana w serwis i obecna
zmiana koncepcji wymagałaby znacznych nakładów czasu oraz finansowych), zasobów
sprzętowych, a nawet zdolności technicznych personelu oraz doświadczeń i umiejętności
projektanta.
1.2. Wybór technologii oraz architektury
Według ankiety serwisu zend (http://www.zend.com/zend/php_survey_results.php)
statystyka wykorzystywanych baz danych z dostępem przez php jest następująca (UWAGA:
jedna osoba mogła zaznaczyć kilka serwerów):
Jakiego rodzaju bazy danych wykorzystuje Liczba Udział
twoja firma w projektach php odpowiedzi procentowy
MySQL 3220 93%
PostgreSQL 773 22%
Oracle 500 14%
Microsoft SQL Server 565 16%
Sybase 74 2%
LDAP 309 9%
SAP 33 1%
Żadne 50 1%
Inne 204 6%
Zatem byÅ‚o ok. 3462 ankietowanych (wedÅ‚ug moich obliczeÅ„ Jð)..
Należy jednak pamiętać, iż oprócz php istnieją również inne możliwości dostępu do baz
danych, a niektóre bazy danych są z nimi częściej użytkowane, np. JSP i Oracle.
6
Porównanie kosztów wybranych rozwiązań (na podstawie: [2]):
Rozwiązanie Narzędzia do tworzenia Serwer RDBMS1
oprogramowania (Relational Database
Management System)
ASP 0  7500 zł 3000 zł 15 000 zł
/SQL Server
CouldFusion MX 1800 zł 7000 zł 15 000 zł
/SQL Server
JSP 0  6000 zł 0  100 000 zł 60 000 zł
/Oracle
PHP 0 -750 zł 0 zł 0  660 zł
/MySQL
PHP 0  750 zł 0 zł 0  (?& ) zł
/PostgreSQL
Różniece pomiędzy serwerami MySQL oraz PostgreSQL możemy przedstawić
następująco:
MySQL PostgreSQL
" darmowy w zasadzie dla wszystkich " darmowy (wymaga zamieszczenia
rozwiązań, które nie będą informacji o autorach i o tym, że nie
dystrybuowane (dyskusyjną pozostaje ponoszą odpowiedzialności, jeśli
sprawa, czy sprzedaż niewłaściwie będzie działał)
oprogramowania do bazy MySQL
" mniej popularny,
w przypadku, gdy klient sam instaluje
" brak książek do najnowszych wersji
sobie serwer MySQL nie wymaga
(ciężko znalez
ć),
opłaty, natomiast pewne jest, że jeśli
" od niedawna dla WIN32,
dołączymy przy sprzedaży serwer
" nieco wolniejszy dla małych baz
MySQL do komercyjnego
danych, ale lepszy w zastosowaniach
oprogramowania to trzeba zapłacić),
dla większych systemów
" bardzo popularny, bogata literatura,
" szybszy oraz wygodny dla
mniejszych baz danych
Czym siÄ™ kierujemy przy wyborze systemu operacyjnego, serwera WWW, oraz DBMS?
Jednym z czynników jest doświadczenie i umiejętności zespołu. Bywa nawet tak, że jest
to czynnik decydujący. Ważne jest jednak, by nie miała miejsca sytuacja, w której wszystkie
projekty, niezależnie od potrzeb, robimy w taki sam sposób.
Przykład (z innej dziedziny). Spotkałem się z sytuacją, gdzie istotnym było (system
czasu rzeczywistego), by każde urządzenie otrzymało, co pewien czas możliwość przesłania
wyników pomiaru końcowego produktu (w przeciwnym razie, jeśli wyniki nie zostały
zapisane na serwerze, produkt otrzymywał najniższą klasę i huta traciła pieniądze).
Urządzenia połączono z wykorzystaniem technologii ETHERNET, a następnie bardzo wiele
1
System ZarzÄ…dzania RelacyjnÄ… BazÄ… Danych
7
czasu poświęcono nad taką konstrukcją oprogramowania, by wspomniany warunek spełniało.
Na pytanie, dlaczego nie zastosowano technologii token ring, padła odpowiedz
, że nie
używano jej wcześniej w projektach, a było mało czasu (o ile dobrze pamiętam, to zespół miał
kilka miesięcy).
Innym czynnikiem decydujÄ…cym o wyborze DBMS (systemu zarzÄ…dzajÄ…cego bazÄ…
danych) jest oprogramowanie, które posiada klient. O ile czynnik ten ma marginalne
znaczenie w przypadku, gdy usługi będą realizowane na dedykowanym serwerze, to jest już
bardzo istotny w sytuacji, gdy przeznaczeniem produktu (gotowej aplikacji) jest sprzedaż dla
indywidualnego klienta. Przykład mogą stanowić programy księgowe.
Architekturę możemy rozpatrywać w dwóch płaszczyznach:
1) podział aplikacji na modułu realizujące określone usługi,
2) podział aplikacji na warstwy ze względu na sposób przetwarzania danych.
Pierwszy z tych podziałów jest ściśle związany z rzeczywistością, którą ma opisywać
projekt. Jeśli decydujemy się na modułową realizację programu, to bardzo istotne jest
ustalenie, czy i w jaki sposób realizowana będzie wymiana informacji pomiędzy modułami.
Często stosowaną techniką jest export/import danych do pliku, ale nawet w tym przypadku
pojawiają się pytania, np. czy inicjowany i wykonywany przez użytkownika,. czy też przez
wyzwalacz, czy jego realizacja pociÄ…ga za sobÄ… zmiany w bazie danych (np. rejestracja
operacji w odpowiednim miejscu i/lub blokowanie rekordów).
Innym problemem są wymogi prawne. Zachęcam do obejrzenia witryny
www.janosik.net (dotyczy problemów z konstrukcją alternatywnego programu  w miejsce
PA
ATNIKA, do transmisji danych do ZUS).
Najczęściej stosowana architektura to dwu lub
trójwarstwowa.
Pierwsze rozwiÄ…zanie jest zapewne znane. Mamy
wówczas warstwę danych oraz warstwę aplikacji,
która stanowi interfejs pomiędzy użytkownikiem i
bazą danych. Drugie rozwiązanie, omówione np. w
[3], pokazuje rysunek obok.
WARSTWA PREZENTACJI.
8
Stanowi  wizytówkę naszej firmy. Zachęca (lub odstrasza) klientów do zapoznania z
ofertą, zakupami lub zachęca do odwiedzania naszej strony (to z kolei zapewnia np.
finansowanie ze strony reklamodawców). Może także zawierać proste procedury
sprawdzające poprawność wprowadzonych danych. Przy jej realizacji możemy korzystać z
gotowych szablonów lub opracować własne.
WARSTWA BIZNESOWA
Obsługuje żądania z warstwy prezentacji, przekazując je do warstwy danych. Może to
być podanie danych operacji do zapisania w bazie danych. Wówczas zapytanie to zostanie
przetworzone na zrozumiałe dla warstwy danych i do niej przekazane.
WARSTWA DANYCH
Odpowiada za zarzÄ…dzanie danymi.
Wadą tej architektury w porównaniu z poprzednim rozwiązaniem jest trudniejsza
realizacja oraz zwiększenie czasu przetwarzania (sekwencyjne przetwarzanie danych).
Dodatkowy narzut czasu powstaje, gdy zastosujemy szablony i choć w typowych
rozwiązaniach nie jest to istotne (użytkownik tego nie zauważy ze względu na dużą szybkość
serwera w porównaniu z transmisją przez Internet), to w niektórych przypadkach może to
mieć znaczenie. Pozostaje wówczas możliwość stworzenia własnych szablonów lub
poszukanie innych rozwiązań.
Zaletą jest natomiast rozdzielenie logiczne aplikacji umożliwiające łatwą skalowalność
i elastyczność projektu oraz łatwiejsze przeniesienie na inną platformę  gdyby było
konieczne (choć niektórzy twierdzą, iż w praktyce taka sytuacja ma miejsce rzadko, gdyż
przeniesienie i tak najczęściej wiąże się z modyfikacją całego systemu i ten aspekt ma
marginalne znaczenie). W porównaniu z architekturą dwuwarstwową wydłuża się także czas
projektu.
Przy bardzo złożonych projektach celowe może być wykorzystanie większej niż 3
liczby warstw.
Zwróćmy uwagę, kto uczestniczy w procesie projektowania systemu informatycznego:
" zamawiajÄ…cy,
" inwestor,
" projektant (architekt),
" urzędnicy (przepisy prawne, normy, standardy związane zarówno z dziedziną
informatyki, jak i modelowanej rzeczywistości),
9
" wykonawca (np. technik implementujÄ…cy projekt, dokonujÄ…cy jego instalacji,
wdrożenia i walidacji),
" użytkownicy,
" otoczenie (zarówno fizyczne oddziaływanie systemu, jak i inni użytkownicy),
" operator,
" konserwator.
Przyjmijmy, iż jesteśmy  prezesami firmy, która zamierza poszerzyć działalność towarów
sprzedaż towarów i usług, potocznie sklepu. Dostępne możliwości stojące przed
zamawiajÄ…cym, czyli nami:
ROZWI
ZANIA UWAGI  problemy, zalety itp.
zakupić kasy fiskalne Trzeba wpisać towary do kas fiskalnych,
prowadzić papierową dokumentację
sprzedaży (m. in. rejestr VAT, dokumentację
księgową), ale jeśli już posiadamy
oprogramowanie księgowe, to tylko
rejestracja sprzedaży dziennej, rozwiązanie
proste, nie wymagajÄ…ce szkolenia personelu
(osoby szkolone w zawodzie sprzedawcy
taką umiejętność powinny posiadać, można
też zatrudnić personel z taką umiejętnością)
zakupić kasy fiskalne oraz oprogramowanie Decydując się na gotowy produkt mamy
zapewnionÄ… aktualizacjÄ™ w zwiÄ…zku ze
zmianami przepisów prawnych, ale
oprogramowanie nie zawsze jest dopasowane
do naszych usług. Dodatkowo dochodzą
koszty szkolenia pracowników (niektóre
firmy liczą sobie nawet kilka tysięcy za 3 dni
szkolenia). Produkty mogą również wymagać
konkretnych rozwiązań technicznych i mogą
nie zawsze współpracować z każdym
urządzeniem. Do pozytywów zaliczyć trzeba
dostęp do wsparcia technicznego.
10
Zakupić kasy fiskalne, zastosować system Znacznie większe koszty projektu oraz
bazy danych np. ACCESS, MySQL niebezpieczeństwa związane z niewłaściwym
i opracować interfejs do bazy procesem projektowania. Większe
możliwości rozbudowy, elastyczność
i skalowalność.
zakupić kasy fiskalne i wszystko opracować Tylko dla dużych przedsięwzięć lub
specyficznych zastosowań, np. zastosowania
zwiÄ…zane z przetwarzaniem czasu
rzeczywistego, niezawodnością lub duże
systemy np. rezerwacji i sprzedaży biletów,
sterowania ruchem lotniczym itp.
zrezygnować Jð Nic nie kosztuje, ale i nic nie zyskamy.
11
X. Bibliografia
[1]pod. red. J.Górski Inżynieria oprogramowania w projekcie informatycznym, MIKOM
2000
[2] T.Converse, J.Park, C.Morgan PHP5 i MySQL Biblia, Helion 2005
[3] E.Balanescu, M.Bucica C.Darie PHP5 i MySQL Zastosowania e-commerce, Helion
2005
[4] J. Perkins PostgreSQL, MIKOM 2002
[i1] http://www.php.net/ - do php
[i2] http://www.zend.com/manual/ - do php
[i3] http://smarty.php.net  szablony Smarty
[i4] http://dev.mysql.com/doc/ - serwer MySQL
[i5] http://www.postgresql.org/docs/ - PostgreSQL
[i6] http://www.biznesplan.com.pl/swot.html - analiza SWOT
[i7] http://prace.sciaga.pl/42962.html - analiza SWOT
[i8] http://www.netmba.com/strategy/swot/ - analiza SWOT
[i9] http://www.dbf.pl/faq/faq_pcbd.html - forum (bazy danych)
Przepisy prawne (do zadania z FakturÄ… VAT):
" art. 106-108 - Ustawa z dnia 11 marca 2004 r. o podatku od towarów i usług
(Dz.U. Nr 54, poz. 535 z póz
n. zm.)
" Rozporządzenie Ministra Finansów z dnia 25 maja 2005 r. w sprawie zwrotu
podatku niektórym podatnikom, zaliczkowego zwrotu podatku, wystawiania
faktur, sposobu ich przechowywania oraz listy towarów i usług, do których nie
mają zastosowania zwolnienia od podatku od towarów i usług (Dz.U. Nr 95, poz.
798)