Notatki (do wykladu 1)

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
twoja firma w projektach php
MySQL
PostgreSQL
Oracle
Microsoft SQL Server
Sybase
LDAP
SAP
Żadne
Inne
Liczba
odpowiedzi
3220
773
500
565
74
309
33
50
204
Udział
procentowy
93%
22%
14%
16%
2%
9%
1%
1%
6%
Zatem było ok. 3462 ankietowanych (według moich obliczeń )..
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
oprogramowania
Serwer
RDBMS1
(Relational Database
Management System)
ASP
/SQL Server
CouldFusion MX
/SQL Server
JSP
/Oracle
PHP
/MySQL
PHP
/PostgreSQL
0 – 7500 zł
3000 zł
15 000 zł
1800 zł
7000 zł
15 000 zł
0 – 6000 zł
0 – 100 000 zł
60 000 zł
0 -750 zł
0 zł
0 – 660 zł
0 – 750 zł
0 zł
0 – (?…) zł
Różniece pomiędzy serwerami MySQL oraz PostgreSQL możemy przedstawić
następująco:
•
•
•
MySQL
darmowy w zasadzie dla wszystkich
rozwiązań, które nie będą
dystrybuowane (dyskusyjną pozostaje
sprawa, czy sprzedaż
oprogramowania do bazy MySQL
w przypadku, gdy klient sam instaluje
sobie serwer MySQL nie wymaga
opłaty, natomiast pewne jest, że jeśli
dołączymy przy sprzedaży serwer
MySQL do komercyjnego
oprogramowania to trzeba zapłacić),
bardzo popularny, bogata literatura,
szybszy oraz wygodny dla
mniejszych baz danych
•
•
•
•
•
PostgreSQL
darmowy (wymaga zamieszczenia
informacji o autorach i o tym, że nie
ponoszą odpowiedzialności, jeśli
niewłaściwie będzie działał)
mniej popularny,
brak książek do najnowszych wersji
(ciężko znaleźć),
od niedawna dla WIN32,
nieco wolniejszy dla małych baz
danych, ale lepszy w zastosowaniach
dla większych systemów
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 odpowiedź, ż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
PŁ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
zakupić kasy fiskalne
UWAGI – problemy, zalety itp.
Trzeba wpisać towary do kas fiskalnych,
prowadzić
papierową
dokumentację
sprzedaży (m. in. rejestr VAT, dokumentację
księgową),
ale
oprogramowanie
jeśli
już
księgowe,
posiadamy
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
zakupić kasy fiskalne oraz oprogramowanie
też zatrudnić personel z taką umiejętnością)
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
możliwości
zakupić kasy fiskalne i wszystko opracować
projektowania.
rozbudowy,
i skalowalność.
Tylko dla dużych
Większe
elastyczność
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,
zrezygnować 
sterowania ruchem lotniczym itp.
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óź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)