Internetowe BD notatki w1

INTERNETOWE BAZY DANYCH

(notatki do wykładów)

dr inż. Paweł Skrobanek

Wrocław 2006

Spis treści:

1. Bazy danych w Internecie....................................................................................................... 3

1.1. Wprowadzenie................................................................................................................. 3
1.2. Wybór technologii oraz architektury............................................................................... 5

X. Bibliografia.......................................................................................................................... 11

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).

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ą

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

Liczba

odpowiedzi

Udział

procentowy

MySQL

3220

93%

PostgreSQL

773

22%

Oracle

500

14%

Microsoft SQL Server

565

16%

Sybase

LDAP

309

SAP

Żadne

Inne

204

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.

Porównanie kosztów wybranych rozwiązań (na podstawie: [2]):

Rozwiązanie

Narzędzia do tworzenia

oprogramowania

Serwer

RDBMS

(Relational Database

Management System)

ASP

/SQL Server

0 – 7500 zł

3000 zł

15 000 zł

CouldFusion MX

/SQL Server

1800 zł

7000 zł

15 000 zł

JSP

/Oracle

0 – 6000 zł

0 – 100 000 zł

60 000 zł

PHP

/MySQL

0 -750 zł

0 zł

0 – 660 zł

PHP

/PostgreSQL

0 – 750 zł

0 zł

0 – (?…) zł

Różniece pomiędzy serwerami MySQL oraz PostgreSQL możemy przedstawić

następująco:

MySQL

PostgreSQL

•

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

•

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

System Zarządzania Relacyjną Bazą Danych

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.

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),

•

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.

Zakupić kasy fiskalne, zastosować system

bazy danych np. ACCESS, MySQL

i opracować interfejs do bazy

Znacznie większe koszty projektu oraz

niebezpieczeństwa związane z niewłaściwym

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ć 

Nic nie kosztuje, ale i nic nie zyskamy.

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