eTravel - aplikacja wspomagająca planowanie

Transkrypt

Uniwersytet im. Adama Mickiewicza w Poznaniu
Wydział Matematyki i Informatyki
kierunek: Informatyka, Technologie informacyjne i internetowe
Praca inżynierska
eTravel - aplikacja
wspomagająca planowanie
przejazdów
eTravel - An application supporting journey planning
Maciej Klimkowski, 383968
współautorzy: Tomasz Przydróżny, Bartosz Szabanowski
Promotor:
dr Krzysztof Dyczkowski
Poznań, 2016
Poznań .................
Oświadczenie
Ja, niżej podpisany Maciej Klimkowski, student Wydziału Matematyki i
Informatyki Uniwersytetu im. Adama Mickiewicza w Poznaniu oświadczam,
że przedkładaną pracę dyplomową pt: eTravel - aplikacja wspomagająca planowanie przejazdów (część 2) napisałem samodzielnie. Oznacza to, że przy
pisaniu pracy, poza niezbędnymi konsultacjami, nie korzystałem z pomocy
innych osób, a w szczególności nie zlecałem opracowania rozprawy lub jej
części innym osobom, ani nie odpisywałem/am tej rozprawy lub jej części od
innych osób.
Oświadczam również, że egzemplarz pracy dyplomowej w wersji drukowanej jest całkowicie zgodny z egzemplarzem pracy dyplomowej w wersji
elektronicznej. Jednocześnie przyjmuję do wiadomości, że przypisanie sobie,
w pracy dyplomowej, autorstwa istotnego fragmentu lub innych elementów
cudzego utworu lub ustalenia naukowego stanowi podstawę stwierdzenia nieważności postępowania w sprawie nadania tytułu zawodowego.
[TAK]* - wyrażam zgodę na udostępnianie mojej pracy w czytelni Archiwum UAM
[TAK]* - wyrażam zgodę na udostępnianie mojej pracy w zakresie koniecznym do ochrony
mojego prawa do autorstwa lub praw osób trzecich
*Należy wpisać TAK w przypadku wyrażenia zgody na udostępnianie pracy w czytelni
Archiwum UAM, NIE w przypadku braku zgody. Niewypełnienie pola oznacza brak zgody
na udostępnianie pracy.
......................................................
SPIS TREŚCI
iii
Spis treści
Wprowadzenie
1. Przetwarzanie danych w aplikacji rozproszonej
7
14
1.1. System rozproszony . . . . . . . . . . . . . . . . . . . . . . . . 15
1.1.1. Wprowadzenie . . . . . . . . . . . . . . . . . . . . . . . 15
1.1.2. Cechy . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.1.3. Zalety i wady . . . . . . . . . . . . . . . . . . . . . . . 16
1.1.4. Architektury . . . . . . . . . . . . . . . . . . . . . . . . 17
1.1.5. Przykłady systemów . . . . . . . . . . . . . . . . . . . 17
1.2. Rozproszona baza danych . . . . . . . . . . . . . . . . . . . . 19
1.2.1. Wprowadzenie . . . . . . . . . . . . . . . . . . . . . . . 19
1.2.2. Postulaty Date’a . . . . . . . . . . . . . . . . . . . . . 19
1.2.3. Budowa i architektura . . . . . . . . . . . . . . . . . . 22
1.3. Przetwarzanie danych . . . . . . . . . . . . . . . . . . . . . . . 23
1.3.1. Pozyskiwanie i obróbka . . . . . . . . . . . . . . . . . . 23
1.3.2. Komunikacja . . . . . . . . . . . . . . . . . . . . . . . 27
2. Budowa stron internetowych na podstawie frameworków
Bootstrap i Phalcon
33
2.1. Nowe metody budowy stron internetowych . . . . . . . . . . . 34
2.1.1. Informacja ogólna . . . . . . . . . . . . . . . . . . . . . 34
2.1.2. Dynamika zmian w bieżącej dekadzie . . . . . . . . . . 35
SPIS TREŚCI
iv
2.1.3. Zmiana priorytetów w tworzeniu witryn . . . . . . . . 37
2.2. Frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.2.1. User Experience . . . . . . . . . . . . . . . . . . . . . . 38
2.2.2. Responsive Web Design . . . . . . . . . . . . . . . . . 39
2.2.3. Warstwa klienta . . . . . . . . . . . . . . . . . . . . . . 44
2.3. Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.3.1. Wprowadzenie . . . . . . . . . . . . . . . . . . . . . . . 47
2.3.2. Zalety i wady . . . . . . . . . . . . . . . . . . . . . . . 47
3. Projektowanie i implementacja baz danych na przykładzie
MySQL
49
3.1. Relacyjna baza danych . . . . . . . . . . . . . . . . . . . . . . 50
3.1.1. Wprowadzenie . . . . . . . . . . . . . . . . . . . . . . . 50
3.1.2. Cechy . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.1.3. Integralność danych . . . . . . . . . . . . . . . . . . . . 53
3.2. Etap projektowania . . . . . . . . . . . . . . . . . . . . . . . . 54
3.2.1. Wprowadzenie . . . . . . . . . . . . . . . . . . . . . . . 54
3.2.2. Planowanie bazy spełniającej założenia projektu . . . . 55
3.2.3. Częste błędy w projektowaniu baz . . . . . . . . . . . . 57
3.2.4. Projektowanie bazy dla projektu eTravel . . . . . . . . 59
3.3. Etap implementacji . . . . . . . . . . . . . . . . . . . . . . . . 60
3.3.1. Diagram ERD projektu eTravel . . . . . . . . . . . . . 60
3.3.2. MySQL w projekcie eTravel . . . . . . . . . . . . . . . 61
Podsumowanie
63
Streszczenie
Celem niniejszej pracy inżynierskiej było opracowanie zagadnień teoretycznych, które pozwoliły na stworzenie systemu wspomagania planowania podróży - eTravel. Projekt opiera się na architekturze rozproszonej i wykorzystuje wzorzec REST do udostępniania danych. Wszystkie dane trzymane są
w relacyjnej bazie danych MySQL. Projekt eTravel składa się ze strony internetowej oraz dedykowanej na platformę android aplikacji mobilnej. Przy
budowie warstwy webowej wykorzystane zostało wsparcie gotowych narzędzi
takich jak Bootstrap (frontend) oraz Phalcon (backend). W celu ułatwienia
planowania podróży w mieście Poznań wprowadzono wizualizację tras wyszukiwanych przez użytkowników, wykorzystano OpenStreetMap oraz GoogleMaps API.
Praca inżynierska opisuje teorię dotyczącą systemów rozproszonych, wyróżnia ich zalety i wady oraz dostępne architektury, wskazując na zasadność
użycia w projekcie eTravel. Oprócz tego w pracy przedstawione zostały sposoby zaimplementowania niektórych rozwiązań w konkretnych funkcjonalnościach systemu. Praca demonstruje także metody i etapy budowy strony
internetowej wraz z panującymi trendami oraz wymaganiami rynku i dostosowaniem ich do różnych urządzeń. Opisano sposób prezentacji zasobów
witryny dla użytkownika oraz wady i zalety wybranych rozwiązań, których
użyto w projekcie eTravel. Przedstawiono architekturę komunikacji, przetwarzania oraz przechowywania informacji w bazie danych.
5:1092434329
Abstract
The aim of this engineering thesis was to discuss the theoretical issues which
led to the emergence of the system supporting the „eTravel” project used to
planning journeys. The project is based on the distributed communication
architecture and operates on the REST software used to sharing data. The
all data is stored in the MySQL database. The „eTravel” project provides
its users with access to a website as well as a mobile application dedicated
to mobile phones with Android operating systems. While creating the web
layer, a few ready-made collections of tools such as Bootstrap (frontend) and
Phalcon (backend) were used. In order to simplify journeys planning for users
in Poznań, routs visualizations were intrduced thanks to OpenStreetMap and
GoogleMaps API.
In this engineering thesis the issues regarding the distributed systems were
disscussed. The systems’ advantages and disadvantages were presented along
with the available architectures. Later on, the neccessity of using them while
creating the „eTravel” project was demonstrated. In addition, implementing
a few solutions to the system’s specific areas of functioning were shown.
In the paper the methods and stages of building a website were disccussed
with references to the variable trends, the demands of the market and the
need to adjust the systems to the various appliances. Additionely, the ways
of presenting site resources to a user were described as well as advantages
and disadvantages of the chosen solutions used in the „eTravel” project.
What is more, the issues of the communication architecture, data storing
and proccessing were presented in this paper.
6:5858704897
Wprowadzenie
Wstęp
Ludzie poruszają się za pomocą różnorakich środków komunikacji. Może to
być tramwaj, może to być autobus, a także pociąg. Bardzo ważną rzeczą przy
podróżowaniu jest planowanie. Musimy wiedzieć jakim środkiem lokomocji
możemy dostać się do naszego celu, kiedy kursuje, i najważniejsze - jaki
będzie koszt podróży? Wszystkie te zagadnienia są niewątpliwie kluczem do
takiego zaplanowania podróży, aby przebiegła ona przyjemnie i bezstresowo.
Wyżej wymienione pobudki skłoniły do powstania projektu eTravel. Aplikacja pozwala użytkownikowi zaplanować podróż międzymiastową na terenie
Polski, a także odnaleźć się w obecnej komunikacji miejskiej w Poznaniu.
Dzięki aplikacji mobilnej oraz webowej, użytkownik może skorzystać z aplikacji w każdej chwili i w każdym miejscu, jeśli tylko posiada połączenie z
internetem.
Oczywiście istnieją już rozwiązania pozwalające na efektywne planowanie
podróży, ale nie łączą one w sobie wszystkich możliwych funkcjonalności. Z
jednej strony planujemy podróż międzymiastową, z drugiej zaś po dotarciu
do celu, musimy skorzystać z kolejnej aplikacji, która obsługuje komunikację
miejską. Aplikacja eTravel umożliwia to wszystko w jednym miejscu.
7:1099044835
Wprowadzenie
8
Opis projektu
Projekt eTravel to połączenie różnych technologii w jedną całość, która pozwala na efektywne planowanie podróży. Główna część to aplikacja webowa
napisana w PHP oraz dodatkowo aplikacja mobilna dla systemu Android.
Intuicyjny oraz nowoczesny interfejs, a także szybkość działania i dbałość o
sprawdzone informacje to rzeczy, które cechują projekt. Dane pobierane są z
wielu źródeł, w tym wewnętrznej bazy danych, a udostępniane przez REST,
dzięki czemu mamy gwarancję szybkości przesyłu danych. Tak więc nieważne
jest czy korzystamy z aplikacji webowej czy też mobilnej, dane są synchronizowane i zawsze aktualne. Do tego dochodzi łatwość użytkowania (ang. UX),
na który położono duży nacisk przy realizacji projektu. Nie ma tu zbędnej
treści, a co ważne, jej spora część jest zwizualizowana. Na sam koniec warto
dodać, że projekt zakłada pełną personalizację, czyli możliwość utworzenia
swojego konta co daje pewne korzyści. Diagram przepływu danych został
zaprezentowany na rysunku 1, z kolei diagram klas na rysunku 2.
Główna funkcjonalnością projektu eTravel jest wyszukiwarka połączeń.
Wyświetla się ona na stronie głównej i umożliwia wpisanie punktu początkowego oraz końcowego naszej podróży (Rysunek 3). Następnie musimy sprecyzować wybór punktów, czyli miejscowości oraz opcjonalnie możemy wybrać
tryb podróży, czas i datę (Rysunku 4). Finalnie uzyskujemy tabelę z wynikami wyszukiwania (Rysunek 5).
Cel i zakres pracy
Celem projektu „eTravel” było stworzenie multiplatformowego oprogramowania do planowania podróży. Głównym i najtrudniejszym zadaniem było
stworzenie skomplikowanego systemu mającego za zadanie wspomagać pla-
8:1039546830
Wprowadzenie
9
nowanie podróży środkami komunikacji miejskiej miasta Poznań, przewoźników publicznych, a także prywatnych na terenie Polski. Zgodnie z założeniem
i trendem w projektowaniu nowoczesnych aplikacji, nastąpił trójwarstwowy
podział aplikacji. W projekcie wyróżniono następujące warstwy:
• interfejs użytkownika (komunikacja z aplikacją, zwracanie danych),
• API (modyfikacje i nadzór danych, zarządzanie klientem),
• baza danych (przechowywanie danych, bezpośrednie operacje na zbiorach danych).
Funkcjonalności
• Lokalizator przystanków - pozwala na określenie przystanków znajdujących się w określonym promieniu wokół miejsca, w którym znajduje
się obecnie użytkownik. Używa modułu GPS lub WiFi do określenia
położenia. Wyświetla przystanki na mapie wygenerowanej przez Google Maps API i pozwala na zapoznanie się z najbliższymi odjazdami
z wybranego markera.
• Najbliższe odjazdy - funkcja pozwalająca na zapoznanie się z najbliższymi odjazdami autobusów/tramwajów z danej stacji. Określa wszystkie linie przebiegające przez dany przystanek i liczbę minut do odjazdu
łącznie z ich kierunkiem.
• Wyszukiwarka połączeń - główna funkcjonalność projektu, polegająca
na wyszukiwaniu połączeń komunikacyjnych na zasadzie międzymiastowej oraz miastowej w Poznaniu. Dzięki wyszukiwarce możemy znaleźć
połączenia PKS, PKP oraz MPK.
9:8703247710
Wprowadzenie
10
• Opinie – każde połączenie międzymiastowe może zostać skomentowane
przez osobę, która korzystała z tego połączenia. Opinia może być wykorzystana w celach informacyjnych dla innych pasażerów, a także w
celu poprawy jakości usług danego przewoźnika.
• Wizualizacja tras – aby wspomóc orientację dla pasażera, który korzysta z usług MPK Poznań, stworzona została wizualizacja tras tramwajowych oraz autobusowych poszczególnych linii.
• Zarządzanie profilem - każdy użytkownik ma do dyspozycji możliwość
zarządzania swoim profilem
Zakres prac projektowych obejmuje następujące zagadnienia zrealizowane
przez poszczególnych członków zespołu:
1. Bartosz Szabanowski:
• aplikacja mobilna na platformę Android,
• nawiązywanie współpracy z podmiotami zewnętrznymi,
• systemy rozproszone,
2. Tomasz Przydróżny:
• zdefiniowanie przypadków użycia dla projektu,
• projektowanie relacyjnej bazy danych,
• implementacja bazy MySQL,
3. Maciej Klimkowski:
• geolokalizacja,
• wizualizacja,
• frontend.
10:9982419062
Wprowadzenie
11
Autorzy poszczególnych rozdziałów pracy:
• Rozdział 1. „Przetwarzanie danych w aplikacji rozproszonej”, Bartosz
Szabanowski
• Rozdział 2. „Budowa stron internetowych na podstawie frameworków
Bootstrap i Phalcon”, Maciej Klimkowski
• Rozdział 3. „Projektowanie i implementacja baz danych na przykładzie
MySQL”, Tomasz Przydróżny
11:7009752643
Wprowadzenie
12
Rysunek 1. Diagram przepływu danych
Rysunek 2. Diagram klas
12:3547314203
Wprowadzenie
13
Rysunek 3. Widok początkowy - wyszukiwarka
Rysunek 4. Widok wyboru parametrów
Rysunek 5. Widok końcowy z wynikami wyszukiwania
13:9635067421
Rozdział 1
Przetwarzanie danych w
aplikacji rozproszonej
autor: Bartosz Szabanowski
14:1005701598
1.1 System rozproszony
15
1.1. System rozproszony
1.1.1. Wprowadzenie
Definicja
System rozproszony to zbiór niezależnych, połączonych jednostek komputerowych, które dzielą zasoby w celu przetwarzania informacji [1].
1.1.2. Cechy
System rozproszony powinien posiadać następujące cechy [2]:
• Transparentność - system sprawia dla użytkownika wrażenie jednej logicznej całości.
• Odporność na błędy - zdolność systemu do działania, mimo awarii jednego z urządzeń (możliwa jednak utrata wydajności).
• Dzielenie obciążenia - wiele procesów/zadań może być wykonywane w
tym samym czasie na różnych jednostkach. W przypadku, gdy dana
jednostka jest mocno obciążona, zadanie przechodzi do kolejnej, mniej
obciążonej.
• Skalowalność - możliwość rozbudowy systemu w celu uzyskania większej
wydajności poprzez rozszerzenie konfiguracji sprzętowej bądź oprogramowania.
• Współdzielenie zasobów - zasoby są udostępniane dla każdej jednostki,
która wchodzi w skład systemu rozproszonego (np. dane, urządzenia).
15:1141425713
16
1.1.3. Zalety i wady
Z cech opisanych w poprzednim punkcie wynikają następujące zalety systemu
rozproszonego:
• Szybkość - skalowalność, a także dzielenie obciążenia powoduje, że systemy rozproszone mogą oferować bardzo dużą wydajność, zdecydowanie
większą niż system scentralizowany oparty na jednej jednostce.
• Niezawodność - awaria jednej z jednostek wchodzącej w skład systemu rozproszonego nie oznacza, że cały system przestaje działać - w
przeciwieństwie do systemu scentralizowanego, gdzie awaria paraliżuje
najczęściej cały system.
• Otwartość - dodawanie elementów takich jak nowy sprzęt bądź usługi
nie narusza integralności całego systemu. Jest to możliwe, dzięki odpowiednim standardom używanych protokołów i interfejsów sieciowych.
Istnieją jednak również wady:
• Uzależnienie od szybkości transmisji danych - system rozproszony polega na przepływie informacji poprzez sieć, tak więc jest uzależniony
od działania i przepustowości tej sieci, w której także mogą zdarzać się
awarie bądź przeciążenia.
• Bezpieczeństwo - o wiele trudniej jest chronić system rozproszony, gdzie
na atak narażona jest każda pojedyncza jednostka wchodząca w skład
systemu - w odróżnieniu do jednego serwera w systemie charakterze
scentralizowanym.
16:6530630702
17
1.1.4. Architektury
Wyróżniamy następujące architektury systemów rozproszonych [1]:
• Klient-serwer - istnieje jeden serwer oferujący zbiór usług, z których
korzystać może wiele różnych, niezależnych klientów. Należy wyróżnić
następujące warianty tej architektury:
– Model cienkiego klienta - cała warstwa logiczna znajduje się na
serwerze, zaś użytkownik/klient uruchamia jedynie warstwę widoku.
– Model grubego klienta - serwer spełnia tu rolę jednostki udostępniającej dane, zaś oprogramowanie po stronie klienta odpowiada
za przetworzenie logiczne danych oraz interakcję z użytkownikiem.
• Multi-serwer (architektura wielowarstwowa) - w odniesieniu do architektury klient-serwer, mamy tu wiele serwerów, na których zgromadzone są dane. Dzięki temu przetwarzanie danych jest rozproszone na
kilka jednostek, co wpływa pozytywnie na skalowalność systemu. Taka architektura jest głównie stosowana w aplikacjach o dużej liczbie
użytkowników, gdzie dane są zmienne.
• P2P (sieć równorzędna) - każdy węzeł takiej sieci jest jednocześnie usługodawcą oraz usługobiorcą. Dane wymieniane są poprzez bezpośrednią
komunikację. Jest to architektura, która zapoczątkowała systemy rozproszone i znana głównie z aplikacji typu torrent.
1.1.5. Przykłady systemów
Aktualnie zastosowanie systemów rozproszonych jest ogromne. W życiu codziennym cały czas napotykamy urządzenia wchodzące w skład takich syste-
17:1581152384
18
mów. Przykładowe to:
• Bankomaty - każdy bankomat obsługiwany jest poprzez centralny serwer bankowy. Tak naprawdę bankomat jest tylko pośrednikiem, który
żądania użytkownika przesyła do serwera i zwraca odpowiedź, a także
wydaje pieniądze klientowi. Zastosowana tutaj architektura to klientserwer z modelem grubego klienta.
Rysunek 1.1. wykorzystanie architektury klient-serwer w bankomatach
(na podstawie [1])
• Systemy rezerwacyjne (np. w kinach) - chcąc zarezerwować miejsce w
hotelu bądź seans w kinie używamy do tego celu systemu rezerwacji.
Wszystkie dane rezerwacyjne zgromadzone są zazwyczaj na serwerze
centralnym, który przetwarza zapytania i gromadzi dane w bazie. Stosuje się tutaj architekturę klient-serwer, najczęściej z modelem cienkiego klienta.
• Strony WWW - coraz częściej zdarza się, że strona internetowa to tak
naprawdę aplikacja internetowa korzystająca z wielu serwerów, których
używa do pozyskiwania danych bądź logicznego przetwarzania treści
na stronie. Wyróżnia się tutaj architekturę multi-serwer. Przykładem
takiej aplikacji jest projekt eTravel.
18:1156624477
1.2 Rozproszona baza danych
19
1.2. Rozproszona baza danych
1.2.1. Wprowadzenie
Rozdział ten zostanie poświęcony zagadnieniu jakim jest rozproszona baza
danych. Jest to kolejny i szczególny przykład systemu informatycznego, gdzie
wykorzystany jest system rozproszony.
Definicja
Z rozproszoną bazą danych (RBD) mamy do czynienia, gdy wiele baz lokalnych umieszczonych w pewnych węzłach zostaje połączonych ze sobą za
pomocą sieci, tak że możliwe jest uzyskanie dostępu do każdej bazy lokalnej
z dowolnego węzła w sieci [3].
1.2.2. Postulaty Date’a
Pożądane właściwości RBD zostały podsumowane poprzez poniższe postulaty Date’a [4]:
• Lokalna autonomia - każdy węzeł RBD powinien działać niezależnie od
innych węzłów. Do tego wszelkie operacje na danym węźle powinny być
kontrolowane tylko i wyłącznie przez ten węzeł. Oznacza to działanie
niezależnego systemu zarządzania bazą danych w każdym węźle sieci.
• Uniezależnienie od centralnego węzła - z powyższej własności wynika
równorzędność każdego węzła w RBD. Nie może być żadnej centralnej
jednostki, która przetwarzałaby transakcje, ponieważ oznaczałoby to
uzależnienie innych węzłów od jej działania.
19:3086800716
20
• Działanie ciągłe - każda RBD jest szczególnym przypadkiem systemu
rozproszonego, tak więc musi spełniać jego cechy. Jedną z nich jest
niezawodność, czyli usunięcie/dodanie jednego węzła w systemie bądź
aktualizacja oprogramowania nie może spowodować, że system przestanie działać. Cechę te wspomaga także fakt replikacji danych w RBD,
czyli awaria jednego węzła nie oznacza braku dostępu do danych, które
przetrzymywał. Inny węzeł może udostępniać te dane z powodzeniem.
• Niezależność lokalizacji (przezroczystość lokalizacji) - oznacza, że logika
aplikacji, która umożliwia dostęp do danych, nie powinna różnić się
działaniem w zależności od tego z jakiej lokalizacji są pobierane dane.
Niezależnie od ich położenia, użytkownik musi mieć świadomość jakoby
dane były pobierane lokalnie.
• Niezależność fragmentacji - użytkownik nie powinien wiedzieć w jaki
sposób dane są podzielone. Ponadto każdy fragment danych można
umieścić w innym węźle RBD, bez utraty spójności danych.
• Niezależność replikacji - użytkownik nie powinien mieć świadomości czy
korzysta z danych oryginalnych czy też replikowanych trzymanych na
innej bazie lokalnej.
• Niezależność sprzętowa - niezależnie od tego, na jakiej platformie sprzętowej opiera się dany węzeł, musi zostać zachowana poprawność dostępu do danych i działania całej sieci rozproszonej.
• Niezależność od systemu operacyjnego - załóżmy, że mamy system rozproszony baz danych, składający się z 3 jednostek. Na każdym znajduje
się inne oprogramowanie bazodanowe. Niezależnie od tego, wymagane
20:4454003473
21
jest, aby system mógł działać poprawnie, a użytkownik nie widział różnicy w dostępie do danych.
• Niezależność sieciowa - rezultaty jakie uzyskuje użytkownik, nie mogą
być uzależnione od protokołów sieciowych, z jakich korzystają dane
węzły RBD.
• Rozproszone zarządzanie transakcjami - system RBD musi zapewniać
poprawne przetwarzanie transakcji zgodnie z aksjomatami ACID:
– atomowość - każda transakcja może zostać wykonana tylko w całości bądź wcale.
– spójność - po wykonaniu transakcji system nadal pozostanie spójny.
– izolacja - w zależności od określonego poziomu izolacji, zostaje zachowana kontrola nad transakcjami wykonywanymi współbieżnie.
– trwałość - po restarcie systemu bądź awarii, system nadal zapewnia dostęp do spójnych i nienaruszonych danych.
• Rozproszone przetwarzanie zapytań - system RBD gwarantuje, że jest
możliwe wykonanie zapytań z jednego węzła do innych węzłów.
21:1059452653
22
1.2.3. Budowa i architektura
Na rysunku 1.2 została przedstawiona przykładowa realizacja rozproszonego
systemu baz danych. Przedstawia ona klienta, który ze Szczecina łączy się
się z interfejsem i przesyła mu żądanie na zwrócenie pewnych danych. Warstwa logiczna przekazuje jego żądanie do odpowiedniego serwera, który ma
zwrócić dane. Wybrany został najbliższy dostępny serwer, czyli w Gdańsku.
Zgodnie z postulatem o niezależności fragmentacji. Dzięki temu zyskujemy
na wydajności.
Rysunek 1.2. przykładowa architektura RBD
(na podstawie [4])
Architektury:
• Jednorodna - wszystkie bazy lokalne oparte są na tym samym oprogramowaniu, np. Oracle.
• Niejednorodna - bazy lokalne oparte są na różnych systemach operacyjnych, np. Oracle, MSSQL. Przykładem takiej architektury może być
projekt eTravel, gdzie istnieje kilka źródeł danych. Jest to baza oparta
na MySQL oraz druga, oparta na silniku SQLite.
22:7469728942
1.3 Przetwarzanie danych
23
1.3. Przetwarzanie danych
W tym rozdziale zostanie opisany proces przetwarzania danych w aplikacji
rozproszonej, na który składa się pozyskiwanie danych z różnych źródeł, ich
obróbka pozwalająca na jednolity format składowania w bazie danych oraz
komunikacja umożliwiająca wymianę danych pomiędzy jednostkami systemu
rozproszonego. Przykłady będą oparte na projekcie eTravel.
1.3.1. Pozyskiwanie i obróbka
Pierwsza i najważniejsza kwestia to wytypowanie kilku źródeł danych, z których możemy pozyskać informacje do naszej aplikacji. Następnie należy dokonać analizy struktury źródła i na tej podstawie wybrać najlepsze narzędzie do
procesu ekstrakcji. Dane mogą być przechowywane w rozmaitych formatach.
Na przykład:
• relacyjne bazy danych
• płaskie bazy danych (XML, JSON, SQLite, ...)
• źródła stron www
• API
Aplikacja eTravel swoje dane pozyskała z płaskiej bazy danych w formacie
JSON, źródła strony e-podroznik.pl oraz API peka.poznan.pl. Rozważmy
jeden z przykładów. Mamy do dyspozycji dwa pliki, które tworzą płaską
bazę danych MPK Poznań:
• Linie, z których chcemy pozyskać koordynaty prostych, numer linii
(a3), typ linii (a4), przystanek początkowy i końcowy odcinka (stopfrom, stop-to).
23:1073116736
24
1
2
{ " geometry " : { " coordinates " : [ [
16.952150457775801 ,
5 2.3 98 78 76 47 06 71 03
3
4
],
5
[ 16.951971759047101 ,
5 2.3 98 47 13 00 26 39 99
6
7
],
8
[ 16.951597783775401 ,
5 2.3 97 81 67 80 10 44 99
9
]
10
],
11
" type " : " LineString "
12
13
},
14
" id " : 5022609 ,
15
" properties " : { " a1 " : null ,
16
" a2 " : null ,
17
" a3 " : " 5 " ,
18
" a4 " : " T " ,
19
" a5 " : " 0 " ,
20
" a6 " : " 14 " ,
21
" stop_from " : " RRAT03 " ,
22
" stop_to " : " KORN01 "
23
}
Kod źródłowy 1.1. Linia opisana za pomocą JSON
• Przystanki, z których pozyskać trzeba: współrzędne, typ przystanku
(a4), kursujące linie (a2), nazwę (a3).
24:1012874357
25
" features " : [ { " geometry " : { " coordinates " : [
1
16.774494820691402 , 52.4737050253528 ] , " type " :
" Point " } ,
2
" id " : " KIEK22 " ,
3
" properties " : { " a1 " : " 1 " ,
4
" a2 " : " 86 , 95 , 239 " ,
5
" a3 " : " KIEKRZ " ,
6
" a4 " : " A " ,
7
" a5 " : " przystanek autobusowy "
}
8
Kod źródłowy 1.2. P rzystanek opisany za pomocą JSON
W celu zdobycia powyższych danych użyjemy wbudowanej w PHP biblioteki do obsługi formatu JSON. Tak wygląda skrypt (Kod źródłowy
1.3), który pozwoli nam na przekonwertowanie danych zakodowanych
w JSON na obiekt bądź tablicę asocjacyjną.
1
<? php
2
// zwraca zawartosc pliku
3
$contents = file_ get_co ntents ( ’ przystanki . json ’) ;
4
// zwraca tablice asocjacyjna ( klucz = > wartosc )
5
$results = json_decode ( $contents , true ) ;
6
// zwraca obiekt
7
$results = json_decode ( $contents ) ;
8
?>
Kod źródłowy 1.3. K onwersja
25:6173042955
26
Teraz możemy przejść do właściwej części, czyli obróbki pozyskanych
danych. Opieramy się na informacjach zapisanych w tablicy asocjacyjnej. Poniższy listing (Kod źródłowy 1.4) prezentuje wyodrębnienie
wspomnianych wcześniej elementów, z pojedynczego rekordu przystanku. Informacje są zapisane kolejno w nowych tablicach.
1
for ( $i =0; $i < count ( $results ) ; $i ++)
2
$lines = explode ( " ," , $properties [ $i ][ ’ a2 ’ ]) ;
3
$geoY = $geometry [ $i ][ ’ coordinates ’ ][0];
4
$geoX = $geometry [ $i ][ ’ coordinates ’ ][1];
5
$name = $properties [ $i ][ ’ a3 ’ ];
6
$short = $short_name [ $i ];
7
$type = $properties [ $i ][ ’ a4 ’ ];
Kod źródłowy 1.4. P ozyskanie
danych
przystanku
z
pojedynczego
rekordu
Ostatnim elementem jest załadowanie danych do bazy. Prezentuje to
poniższy listing (Kod źródłowy 1.5). Należy zwrócić uwagę na rozbicie
danych na dwie tabele w celu zachowania przejrzystości oraz zwiększenia wydajności przy ich odpytywaniu (szybciej zostanie odpytana
tabela ”lines” o daną linie aniżeli kolumna ”lines” z wierszem ”86, 95,
239”, gdzie należy dodatkowo rozbić string).
1
$mysqli -> query ( "
2
INSERT INTO stations ( geoX , geoY , name ,
short_name , type ) VALUES ( ’ $geoX ’, ’ $geoY ’, ’
$name ’, ’ $short ’, ’ $type ’) " ) ;
26:6900672126
27
3
4
$id = $mysqli - > insert_id ;
5
foreach ( $lines as $line )
$mysqli -> query ( " INSERT INTO lines (
6
station_id , number ) VALUES ( $id , $line ) "
);
Kod źródłowy 1.5. Dodanie danych do bazy
W ten sposób przystanki zostają załadowane do bazy MySQL, lecz
mogą być one również w dowolnym momencie w podobny sposób zaaktualizowane (polecenie UPDATE). Nic nie stoi również na przeszkodzie, aby w przypadku awarii bazy danych, skorzystać z tych informacji
bezpośrednio z pliku, jako płaska baza danych. Dodatkowym atutem
takiego rozwiązania jest fakt, że taki plik stanowi odrębną bazę lokalną
umieszczoną w innym węźle, w tym przypadku jest to serwer FTP.
1.3.2. Komunikacja
W systemach rozproszonych ważną rolę pełni skuteczna komunikacja między
jednostkami pozwalająca na poprawną i szybką wymianę danych. Istnieje
kilka protokołów/interfejsów, które spełniają taką rolę:
1. SOAP
Protokół komunikacyjny oparty o język znaczników XML [5]. Umożliwia przekazywanie wywołań zdalnych procedur poprzez mechanizmy
transportowe takie jak: HTTP, POP, SMTP itd. Podstawowe użycie
prezentują poniższe listingi (Kod źródłowy 1.6, 1.7):
27:4139353539
1
<? xml version = " 1.0 " ? >
2
< soap : Envelope
3
xmlns : soap = " http :// w3 . org /2001/ soap - envelope "
4
soap : encodingStyle = " http ://. w3 . org /2001/12/ soap encoding " >
5
6
7
8
9
10
< soap : Body xmlns : m = " http :// yoursite . com / news " >
<m : GetNewsById >
<m : NewsId >44 </ m : NewsId >
</ m : GetNewsById >
</ soap : Body >
</ soap : Envelope >
Kod źródłowy 1.6. W ywołanie procedury
1
<? xml version = " 1.0 " ? >
2
< soap : Envelope
3
xmlns : soap = " http :// w3 . org /2001/12/ soap - envelope "
4
soap : encodingStyle = " http :// w3 . org /2001/12/ soap encoding " >
5
6
7
8
9
10
< soap : Body xmlns : m = " http :// yoursite . com / news " >
<m : GetNewsByIdResponse >
<m : Title > news example </ m : Title >
</ m : GetNewsById >
</ soap : Body >
</ soap : Envelope >
Kod źródłowy 1.7. Odpowiedź
28:3996677310
28
29
2. REST
Styl architektoniczny budowania aplikacji rozproszonych z wykorzystaniem protokołu HTTP do wymiany danych pomiędzy maszynami [6].
Wykorzystuje architekturę klient-serwer. Składa się zasobów:
/users, /news, /stations - rzeczownik w liczbie mnogiej
na których mogą być wykonane następujące akcje:
• GET - pobierz
• POST - utwórz
• PATCH - aktualizacja częściowa
• PUT - zaaktualizuj
• DELETE - usuń
Każda z akcji powinna zwrócić:
• status HTTP
• opis błędu dla użytkownika
• opis błędu dla dewelopera
Obsługa błędów polega na zwróceniu przejrzystego komunikatu i konkretnego kodu błędu:
• 4xx - błędy po stronie klienta
• 5xx - błędy po stronie serwera
• 2xx - sukces
29:1138506230
30
Przykładowe żądanie w formacie JSON o dodanie użytkownika i odpowiedź w zależności od powodzenia akcji prezentuje kod źródłowy 1.8. Jednak,
aby taka akcja mogła zostać obsłużona wymagane jest odpowiednie REST
API. W eTravel do tego celu został użyty framework php - phalcon. Posiada on wbudowaną obsługę zapytań restowych. Przykładowy kod obsługi
powyższej akcji POST można ujrzeć na listingu (Kod źródłowy 1.9).
1
request
2
{
" username " : " user1 " , " email " : " user1@poczta . pl " , "
3
password " : " qwerty "
4
}
5
6
response
7
200: { " message " : " Uzytkownik zostal dodany poprawnie ! "
}
8
404: {
" field " : " username " ,
9
" userMessage " : " Istnieje juz uzytkownik o podanej
10
nazwie " ,
" devMessage " : " Username must be unique "
11
12
}
Kod źródłowy 1.8. Odpowiedź i żądanie
30:9840552938
31
1
2
$app - > post ( ’/ users ’ , function () use ( $app ) {
3
$user = $app - > request - > getJsonRawBody () ;
4
$phql = " INSERT INTO users ( username , email ,
password ) VALUES (: username : , : email : , : password
:) " ;
$status = $app - > modelsManager - > executeQuery ( $phql ,
5
array (
6
’ username ’ = > $user - > username ,
7
’ email ’ = > $user - > email ,
8
’ password ’ = > sha1 ( $user - > password )
));
9
10
$response = new Phalcon \ Http \ Response () ;
11
if ( $status - > success () == true ) {
$response - > setStatusCode (200 , " Success " ) ->
12
setJsonContent ( array ( ’ message ’ = > " Uzytkownik
zostal dodany poprawnie ! " , ’ status ’ = > 1) ) ;
} else {
13
$response - > setStatusCode (404 , " Failure " ) ->
14
setJsonContent ( array ( ’ userMessage ’ = > "
Istnieje juz uzytkownik o podanej nazwie ! " , ’
developerMessage ’ = > " Username must be unique
!"));
15
}
16
return $response ;
17
}) ;
Kod źródłowy 1.9. Obsługa akcji POST w Phalcon
31:1112722243
32
Najpierw należy wskazać jaka akcja i jaki zasób ma zostać obsłużony
(post, /users). Następnie dane przekazane przez HTTP są pobierane i wstawiane do bazy danych, z uwzględnieniem filtrowania zmiennych (modelsManager). Dalej tworzony jest obiekt odpowiedzi przez Phalcona (Response), w
którym w zależności od powodzenia dodania danych do bazy danych, zwracane są odpowiednie komunikaty i status w formacie JSON.
Rysunek 1.3 prezentuje przepływ danych w aplikacji rozproszonej eTravel
z użyciem REST API. Użytkownik widzi jedynie interfejs aplikacji mobilnej
bądź stronę internetową. Nie wie jednak, że każde zapytanie jest kierowane
do serwera, na którym działa API i dopiero ono dostarcza właściwych danych
z lokalnych baz.
Rysunek 1.3. REST w projekcie eTravel
Podsumowując, wzorzec REST to prosty i lekki wzorzec, który pozwala
na wygodną komunikację w aplikacjach rozproszonych.
32:1891501590
Rozdział 2
Budowa stron internetowych na
podstawie frameworków
Bootstrap i Phalcon
autor: Maciej Klimkowski
33:4283534076
2.1 Nowe metody budowy stron internetowych
34
2.1. Nowe metody budowy stron internetowych
Szybki i dynamiczny rozwój sieci Internet bardzo intensywnie wpłynął na
metody tworzenia stron internetowych. Powodem zmian i rozwoju była popularyzacja internetu oraz stałe zwiększanie jego szybkości. Użytkownicy potrzebowali nowych możliwości. Proces rozwoju trwa nieustannie i przyspiesza
wraz z coraz to większym dostępem ludzkości do sieci.
2.1.1. Informacja ogólna
Pierwsze witryny internetowe opierały swoje działanie na zamieszczonym
przez autora stałym tekście, który użytkownik mógł tylko czytać. Wraz z
rozwojem Internetu oraz zwiększeniem jego szybkości do stron www zaczęto
wprowadzać elementy graficzne oraz zamieszczać fotografie lub obrazy wzbogacające treść zamieszczona w formie tekstu. Doszło jednak do sytuacji, gdy
pula możliwych działań okazała się zbyt mała. Spowodowało to wprowadzenie rewolucyjnych zmian do których przyczynił się stały rozwój idei stron
internetowych oraz ich popularyzacja. Wzbudzały one coraz większe zainteresowanie użytkowników, w tym także dużych instytucji oraz przestępców.
W celu ochrony danych oraz propagowania dalszego rozwoju opracowano nowe standardy, ich celem było stałe zwiększanie bezpieczeństwa danych oraz
użytkowników oraz nowy typ tworzenia stron internetowych, który pozwoli
na bezpośrednią interakcję z użytkownikiem. Ideę tą nazwano „web 2.0”.
Przyjmuje się, że „web 2.0” powstał w 2004 roku. Pojęcie to miało określać
nowy wymiar Internetu. Nowego medium, które przestało być tylko miejscem
prezentacji przekazu, a zaczęło być dostępne dla wszystkich użytkowników.
Działanie sieci Internet od tej pory miało pozwolić na tworzenie treści przez
grupę twórców oraz odbieranie treści przez grupę odbiorców. Przy czym każ-
34:4861152683
35
dy z użytkowników mógł należeć do obydwu grup. „Web 2.0” umożliwiał
interaktywność i elastyczność. Od tej pory użytkownicy samodzielnie mogli
tworzyć treść oraz ją edytować oraz reagować na zamieszczane treści. [7]
2.1.2. Dynamika zmian w bieżącej dekadzie
Początek bieżącej dekady to wdrożenie idei „web 2.0” oraz udostępnienie wielu nowych opcji dla użytkownika. Od teraz każdy kto zechciał, brał udział
w tworzeniu witryny internetowej. Możliwe to było poprzez tworzenie różnego rodzaju treści (artykuły, komentarze, wpisy na forach) oraz stopniowe
pojawianie się społeczności użytkowników. Masowo zaczęły powstać strony,
gdzie użytkownicy oprócz tworzenia treści, mogli zakładać także społeczności
stworzone wokół danej witryny oraz współdziałać.
Powiększenie grupy twórców treści na stronach internetowych pozwoliło
na powstanie nowych typów witryn internetowych oraz zwiększenie kanałów przekazu. Na początku obecnej dekady powstały popularne dziś serwisy
społecznościowe (facebook.com, twitter.com), platformy z wideo oraz muzyką (youtube.com), platformy wymiany plików (megaupload.com), sklepy
internetowe (rozwój: allegro.pl, amazon.com) oraz wiele innych typów stron
internetowych, które stały się bardziej multimedialne. Niewątpliwie było to
możliwe dzięki stałe powiększającemu się zasięgowi Internetu oraz dużym
wzrostem jego prędkości.
Duży przyrost stron internetowych spowodował, że ich właściciele musieli
dbać już nie tylko o treść, którą strona zawierała, ale także o wygląd, reklamę
oraz unikalność. Konkurencja stale się zwiększała, użytkowników przybywało,
a kluczem było zdobycie ich dla siebie. Rynek stworzył zapotrzebowanie na
nowe usługi. Zaczęto świadczyć usługi w tworzeniu szat graficznych witryn,
35:8452135270
36
optymalizacji i standaryzowania kodu witryn, promocji w wyszukiwarkach
oraz tworzenia szeroko pojętej reklamy. Internet stał się źródłem dochodu i
nadal posiadał ogromny potencjał.
Rozwój techniki i popularyzacja urządzeń mobilnych miały duży wpływ
na strony www. Gdy użytkownicy zaczęli korzystać z Internetu w nowy sposób, np. z telefonu komórkowego, należało dostosować witrynę, tak aby korzystanie z było wygodne. Nowe urządzenia miały mniejszy ekran, działały
wolniej, zazwyczaj posiadały też wolniejsze połączenie internetowe. Wszystkie te aspekty sprawiły, że korzystanie z pełnej wersji strony byłoby uciążliwe.
Tak powstał pomysł tworzenia „mini stron”, były to specjalnie przygotowane, oddzielne wersje witryn internetowych, które wyświetlano użytkownikom
telefonów komórkowych. „Mini strony” charakteryzowały się znacznie okrojoną treścią, brakiem fotografii i obrazków, często brakiem lub małą ilością
grafiki.
Rozwój techniczny przyspieszał jeszcze bardziej, zaczęto tworzyć mnóstwo nowych urządzeń mobilnych jak tablety czy smartfony o różnej wielkości ekranu. Ponadto Internet stawał się jeszcze popularniejszy, a dostęp
do dobrej jakości łącza nie stanowił już problemu. Wskazane elementy składowe w drugiej połowie bieżącej dekady wymusiły zaprzestanie tworzenia
„mini stron”. Urządzenia oraz sieć były dostatecznie szybkie, aby móc ładować pełne strony internetowe, a nie ich bardzo okrojone wersje. Użytkownicy
pragnęli korzystać z jednej wersji strony, mieć dostęp do swoich kont, układu witryny czy posiadać identyczną treść na wszystkich urządzeniach. Nadal
pozostawał jednak problem dostosowania witryn internetowych do różnego
rodzaju rozdzielczości i wielkości ekranów. Urządzenia korzystające z sieci
różniły się diametralnie, od 3,5” smartfonów do 50” i większych ekranów
telewizorów. Problem zdefiniowano jako „świat multiscreen”. Opracowano
36:1025690308
37
technologie, które tworzą „płynny” szablon strony. Twórcy stron www mogli
przygotowywać rozbudowaną wersję szablonu, które pozwalają na automatyczne wykrywanie rozdzielczości ekranu oraz same dostosowują witrynę, tak
aby wyświetlała się poprawnie na każdym urządzeniu. Dzięki temu użytkownicy posiadają dostęp do jednej wersji strony (treść, konta, możliwości działania), a jedyną różnicą jest ułożenie i wyświetlenie elementów na ekranie.
2.1.3. Zmiana priorytetów w tworzeniu witryn
Początkowo strony internetowe były miejscem, gdzie autor lub grupa autorów promował swoje idee, pomysły, publikacje lub informacje o sobie lub
swoich dokonaniach. Strona internetowa była wizytówką, miejscem realizacji
swoich własnych założeń i pasji. Ich budowa oraz kompozycja była samoistną
wizją twórcy. W erze „web 2.0” Internet i strony www zaczęły przekształcać się w nowe, dochodowe formy biznesu. Dzięki temu zyskiwać zaczęły
standardy budowy i użytkowania stron. Każdy twórca stron pragnął, aby jego strona była najpopularniejsza, zgodna ze standardami budowy, czytelna,
często odwiedzana, a przy tym szybka i możliwe dogodna w edycji. Zauważono, że to użytkownik jest tym, który dyktuje idee poprzez wybór tego co
jest dla niego najdogodniejsze. Wprowadzono więc systemy ankiet, komentarzy, zgłaszania uwag czy formularzy kontaktowych. Położono duży nacisk na
śledzenie użytkownika i zbieranie informacji o nim, zaczęto tworzyć profile
użytkownika, dostarczać mu treść która go interesuje oraz brać pod uwagę
jego sugestie. Stworzono zaawansowane narzędzia badające ruch na stronie
(np. Google Analytics) oraz pozwalające na uzyskanie szczegółowych danych
o użytkowniku. Rozwinęła się gałąź analizy ruchu na witrynach internetowych oraz e-marketing. Stosowanie standardów, badania ryku oraz odejście
od własnej wizji doprowadziły do zmian priorytetów – obecnie najważniejszy
37:7550494135
2.2 Frontend
38
dla twórcy jest użytkownik. To on dyktuje co czyta, jak wygląda strona i co
go interesuje. Pod wymagania użytkownika dostosowuje się szablony stron,
ich funkcjonalność, elastyczność, świadczone usługi, zamieszczane materiały oraz rozrywkę. Internet niewątpliwie zyskał, stał się najpopularniejszym
środkiem masowego przekazu. Jest także inny niż wszystkie media, bo tak
naprawdę tworzony dla użytkownika, skrojony na jego potrzeby i wymagania,
a jednocześnie rozległy.
2.2. Frontend
Frontend to słowo pochodzące z języka angielskiego, w informatyce oznacza
część strony internetowej przeznaczonej dla użytkownika. Pojęcie to określa
część kliencką, interfejs. Jest to część systemu komputerowego, który znajduje
się najbliżej użytkownika. Frontend zbiera dane od użytkownika, przekazuje
do „backendu” i zwraca użytkownikowi wyniki działania.
2.2.1. User Experience
Wzrost znaczenia użytkownika strony internetowej jako konsumenta doprowadził do powstania nowych metod pozyskiwania informacji biznesowych i
kształtowania modelu danych oraz ich wizualizacji. Obecnie każdy internauta
może przeglądać miliardy stron internetowych, konkurencja jest ogromna, a
pozyskanie użytkownika bardzo trudne. Pozyskanie użytkownika, zatrzymanie go przy sobie oraz przekonanie go do dokonania konwersji na stronie stało
się kluczowe. W tej sposób zrodziło się określenie oraz idea User Experience.
User Experience (skrót: UX) to pojęcie bardzo szerokie, niemożliwe
jednoznacznie do zdefiniowania. Określa bowiem doświadczenia użytkownika,
38:1365731907
2.2 Frontend
39
towarzyszące mu podczas korzystania z usługi, produktu czy dokonywaniu
konwersji. Każde doświadczenie użytkownika jest subiektywną oceną, zależną
od wielu czynników towarzyszących, często niemożliwych do odtworzenia.
Pojęcie to znajduje się na granicy wielu dziedzin nauki: psychologi, sztuki,
wzornictwa, użyteczności oraz technologii.
Główną ideą UX jest zbieranie doświadczeń wielu użytkowników, przetworzenie tych danych, analiza oraz przygotowanie takiej warstwy klienckiej,
która spełni oczekiwania jak największej grupy użytkowników. Dostosowanie
do trendów, przyzwyczajeń użytkownika, intuicyjnej symboliki, czytelności
oraz typografi stało się zdecydowanie łatwiejsze dzięki User Experience.
Rozwój dziedziny doprowadził do projektowania interfejsów wygodnych,
użytecznych, dostosowanych do potrzeb użytkownika/klienta, które są dopracowane w najmniejszych szczegółach, a jednocześnie są łatwe w obsłudze. Zrezygnowano z niepotrzebnych wariantów graficznych, multimedialnych
czy rozbudowanych formularzy. Głównym trendem jest prostota, czytelność,
szybkość, elastyczność oraz funkcjonalność.
Praktyka User Experience stała się bardzo popularna. Producenci i twórcy
mają świadomość jej potęgi. Korzystają z niej wszyscy, począwszy od dużych
korporacji aż do jednoosobowych firm. Inspiracja użytkownika i zachęcenie
go do skorzystania z naszej witryny, dokonania na niej konwersji stało się
kluczowe. [8]
2.2.2. Responsive Web Design
Rewolucja internetowa zwana „świat multiscreen” wymusiła zmiany w tworzeniu witryn. Korzystanie z Internetu na różnych urządzeniach, o różnej
rozdzielczości i wielkości ekranu wymagało elastycznego sposobu wyświetla-
39:2777848730
2.2 Frontend
40
nia informacji. Niemożliwe stało się przygotowanie oddzielnych wersji witryny, bowiem wariantów z jakich korzystają użytkownicy przeglądający sieć
jest zbyt dużo. Głównym celem było stworzenie jednego typu szablonu, dostępnego na wielu platformach, który pozwoli wyświetlić witrynę w różnych
wariantach, jednak nie zaburzy formy przekazywanych treści. Rozwiązanie
udało się wypracować, a ideę nazwano Responsive Web Design.
Responsive Web Design (skrót: RWD) to sposób tworzenia uniwersalnej i elastycznej strony internetowej. Polega na przygotowaniu jednego szablonu, którego układ, wygląd oraz zawarta treść dostosuje się automatycznie
do używanego urządzenia i rozdzielczości ekranu. Reguła Responsive Web
Design oznacza, że strona ma się nie tylko wyświetlić, ale być maksymalnie
zoptymalizowana do używanego urządzenia. Oznacza to przygotowanie do łatwego i szybkiego przeglądania zawartości, wprowadzania treści, korzystania
z funkcji społecznościowych oraz łatwą i intuicyjną nawigację. Bez względu
na rodzaj urządzenia korzystanie z witryny ma być łatwe i komfortowe. [9]
Rysunek 2.1. Responsive Web Design w praktyce
[12]
40:8547652699
2.2 Frontend
41
Pierwszym i najważniejszym krokiem w idei Responsive Web Design jest
automatyczne określenie rozdzielczości ekranu oraz przygotowanie odpowiedniego wariantu szablonu strony internetowej. Możliwe jest to dzięki regułą
media queries. Znaczniki @media dostępne były w kaskadowych arkuszach
stylów (CSS) już zanim powstała idea RWD, jednak to trzecia wersja CSS
zrodziła zapotrzebowanie na ich użycie i stworzenie idei płynnego i elastycznego szablonu witryny. Za pomocą znacznika @media określamy układ kolumn (rozkład sekcji elementów strony) na ekranie. Media queries przyjmują
kilka głównych wartości wejściowych, które określają typ urządzenia, maksymalną lub minimalną szerokość ekranu na których wyświetlamy dany schemat kolumn oraz reguł z pliku CSS. Poniżej zamieszczono przykłady użycia
@media.
1
@media ( min - width : 768 px ) {
// kod pliku css
2
3
}
Kod źródłowy 2.1. @media
definiujący
styl
dla
ekranu
o
minimalnej
rozdzielczości 768 pikseli
1
@media screen and ( min - width : 480 px ) {
// kod pliku css
2
3
}
Kod źródłowy 2.2. @media definiujący styl dla urządzenia mobilnego lub
komputera o minimalnej rozdzielczości 480 pikseli
41:1131159034
2.2 Frontend
1
@media print {
// kod pliku css
2
3
42
}
Kod źródłowy 2.3. @media definiujący styl dla drukarki
1
@media not TV and ( max - width : 1024 px ) {
// kod pliku css
2
3
}
Kod źródłowy 2.4. @media definiujący styl dla wszystkiego oprócz telewizorów
i maksymalnej rozdzielczości 1024 piksele
Projektowanie płynnych i elastycznych szablonów stron internetowych
wymaga tworzenia rozbudowanych kaskadowych arkuszy stylów. W celu ułatwienia i przyspieszenia tego procesu, powstały rozwiązania z predefiniowanymi, wymaganymi klasami i standardowymi zawartościami, które w łatwy
sposób pozwalają na edycję interesujących nas klas i dodanie własnych. Najpopularniejszym na świece tego typu rozwiązaniem jest framework Bootstrap.
Platforma ta pozwala na dogodne budowanie responsywnego wyglądu strony, ponadto oferuje zestaw popularnych technik i bibliotek front-end oraz
zawiera wbudowane skrypty Java Script.
Predefiniowane szablony frameworku Bootstrap pozwalają na szybką zmianę układów witryn i dostosowanie ich do własnych potrzeb. Strona dzielona
jest na dwanaście płynnych obszarów, kolumn. Gdzie dwanaście oznacza całą
szerokość strony, a jeden tylko 1/12 szerokości. Możliwe są zmiany szerokości
obszarów ad-hoc i wyświetlanie różnego ułożenia dla desktopów, smartfonów
42:2257777007
2.2 Frontend
43
i tabletów. Klasy, kolumny decydujące o szerokości strony są zdefiniowane
dla każdego typu w plikach CSS. Jedyną operacją użytkownika jest zmiana
„liczb” w zakresie 1-12. Obszary nie wymagają definicji, ani deklaracji. Bootstrap oferuje ponadto możliwość nadpisywania predefiniowanych klas oraz
definiowanie własnych w plikach CSS, a następnie dodanie ich do wykorzystywanego szkieletu w pliku HTML.
1
< div class = " col - xs -12 col - sm -6 col - lg -8 " > Komunikat </ div >
Kod źródłowy 2.5. Przykład zastosowania kolumn we frameworku Bootstrap
Powyższy kod źródłowy (2.5) przypisuje do znacznika DIV trzy warianty wyświetlania jego zawartości (łańcucha znaków ”Komunikat”) zależnie
od spełnionego warunku. Instrukcje zamieszczone w atrybucoe class należy
interpretować następująco:
• col-xs-12 dla urządzeń o rozdzielczości ekranu mniejszej niż 544 pikseli
wyświetl DIVa na całej szerokości ekranu,
• col-sm-6 dla urządzeń o rozdzielczości ekranu większej niż 544 piksele
wyświetl DIVa na połowie szerokości ekranu,
• col-lg-8 dla urządzeń o rozdzielczości ekranu większej niż 992 piksele
wyświetl DIVa na 2/3 szerokości ekranu.
Testując kod źródłowy (2.5) otrzymamy wynik, które mówi, że powyższe reguły nie działają jak instrukcja warunkowa (pierwsze pasujące dopasowanie), lecz wybierają wariant najlepiej dopasowany. Powyższy kod dla
rozdzielczości ekranu full HD (1920x1024px) wybierze wariant col-lg-8. [10]
43:8153614787
2.2 Frontend
44
Tworząc projekt eTravel stosowaliśmy się do najważniejszych zasad i
trendów w dotyczących tworzenia witryn internetowych. Użyto znaczników
@media w celu zaprojektowania strony w pełni responsywnej oraz elastycznej
i dostosowanej do każdego urządzenia oraz rozdzielczości.
1
@media only screen and ( min - width : 520 px )
// kod pliku css
2
3
{
}
4
5
@media only screen and ( min - width : 1024 px ) {
// kod pliku css
6
7
}
Kod źródłowy 2.6. Fragmenty reguł @media w projekcie eTravel
2.2.3. Warstwa klienta
Zaprojektowanie udanego frontendu nie jest zadaniem łatwym. Musimy spełnić oczekiwania jak największej grupy użytkoników (zgodnie z ideologią User
Experience) i przygotować stronę dostępną na wszystkie urządzenia (Responsive Web Design). Ponadto przygotowany projekt musi działać szybko, być
wydajny po każdej ze stron (klient oraz serwer), posiadać możliwość szybkiej
i łatwej edycji oraz wykorzystywać sprawdzone technologie.
Przygotowanie interfejsu użytkownika rozpoczynamy od zaprojektowania
i stworzenia szablonu graficznego strony. Kolejnym krokiem jest przygotowanie go do transformacji w zakodowany w HTML i CSS projekt. Ostatni krok
to dostosowanie go do używanego przez nas schematu lub rodzaju witryny,
44:3982570133
2.2 Frontend
45
umieszczenie kodu w odpowiednich plikach. Na pozór każdy z etapów jest
krótki, jednak nie jest to prawda. Minimalizując czas na operacje związane z
przełożeniem wyglądu witryny na używalny kod używa się gotowych rozwiązań. Jednym z takich rozwiązań jest wspomniany w poprzednim rozdziale
Bootstrap, którego w celu optymalizacji czasu pracy użyliśmy w projekcie
eTravel.
Bootstrap to rozbudowany zbiór predefiniowanych funkcji i reguł kaskadowych arkuszy stylów. Obsługuje nie tylko responsywność i elastyczność
witryny. Posiada reguły odpowiadające za wygląd nawigacji, przycisków, formularzy, wykresów, nagłówków, akapitów i wielu innych. Modyfikacja prefediniowanych reguł jest łatwa, możemy to zrobić poprzez nadpisanie klasy o
danej nazwie w głównym pliku CSS lub przygotowanie własnej klasy w pliku
CSS, a następnie dodanie jej w atrybucie class pliku HTML dla znacznika,
który chcemy zmodyfikować.
1
< button type = " submit " class = " btn btn - success " name = "
submit " > Wyszukaj </ button >
Kod źródłowy 2.7. Użycie
predefiniowanej
reguły
wyglądu
przycisku
w
projekcie eTravel
1
< button type = " submit " class = " btn btn - success btn - red "
name = " submit " > Wyloguj </ button >
Kod źródłowy 2.8. Modyfikacja predefiniowanej reguły wyglądu przycisku w
projekcie eTravel
45:9250717738
2.2 Frontend
1
. btn - red {
background - color : red ;
2
3
46
}
Kod źródłowy 2.9. Zawartość klasy btn-red użytej w kodzie źródłowym 2.8
Framework Bootstrap posiada także wsparcie dynamicznych języków modyfikacji arkuszy stylu less oraz sass. Języki te pozwalają na tworzenie funkcji
i zmiennych, który znacznie zmniejszają objętość kodu, tym samym prowadząc do optymalizacji działania witryny internetowej. Ponadto framework
wspiera język Java Script oraz najnowsze wersje standardów CSS oraz HTML.
Wszystkie wymienione dodatki i funkcjonalności pozwalają z powodzeniem
zastąpić starą i sprawiającą duże problemy technologię Flash.
1
@color : # ffffff ;
2
@background : # 1 F363D ;
3
. special - bar a {
4
color : @color ;
5
}
6
. special - bar div {
background - color : @background ;
7
8
}
Kod źródłowy 2.10. Użycie less w projekcie eTravel
Tworzenie nowoczesnych i w pełni kompatybilnych stron internetowych
nie wymaga ogromnego nakładu czasu i sił. Spowodowane jest to udostępnieniem gotowych rozwiązań początkowych takich jak Bootstrap.
46:6009724107
2.3 Backend
47
2.3. Backend
Backend to wewnętrzna część strony internetowej, która nie jest widoczna
dla użytkownika. Frontend przekazuje mu dane od użytkownika. Na podstawie pozyskanych danych backend wykonuje określone operacje i zadania.
Jeśli jest to konieczne zwraca wynik do użytkownika poprzez frontend.
2.3.1. Wprowadzenie
Obecnie dostępny jest bardzo szeroki zakres możliwości tworzenia backendu.
Analogicznie do frontendu, tutaj również powstały gotowe rozwiązanie prekonfigurowane, które ułatwiają budowę witryny od strony technicznej i są
łatwe do modyfikacji czy rozbudowy. Bardzo ciekawym i nowoczesnym rozwiązaniem jest framework języka PHP o nazwie Phalcon. System ten jest
bazą całej webowej części projektu eTravel, rozbudowaliśmy go do naszych
potrzeb i wykorzystaliśmy część opcji, które oferuje.
2.3.2. Zalety i wady
Decydując się na gotowe rozwiązania, nawet gdy są one łatwe do modyfikacji
i elastyczne w działaniu zawsze uznajemy pewne kompromisy. Otrzymujemy
pewien zbiór, który ułatwia i przyspiesza naszą pracę, jednak trafiamy też
na wady, które musimy zaakceptować. Tworząc eTravel zdecydowaliśmy się
na framework Phalcon. Poniżej opisano ułatwienia i problemy z jakimi się
spotkaliśmy.
Phalcon posiada bardzo dużo zalet. Przy budowie projektu, którego główną ideą było realizowanie szybkich połączeń między warstwami frontendbackend niewątpliwy nacisk położyliśmy na szybkość działania. Wśród fra-
47:6043825527
2.3 Backend
48
meworków PHP użyty przez nas produkt jest jednym z najszybszych. Jednocześnie jest w pełni funkcjonalny i wzbogacony nowoczesnymi rozwiązaniami.
Ponadto posiada pełne wsparcie REST API, które używamy do bardzo wielu
operacji w systemie eTravel. Od strony technicznej udostępniono najpopularniejszą obecnie architekturę Model-Widok-Kontroler (MVC), możliwości
pracy z różnymi bazami danych (w tym szerokie wparcie baz MongoDB),
prosty routing, system szablonów opracowanych pod widoki i wsparty Bootstrap oraz duże i elastyczne możliwości rozwoju aplikacji, tak aby dostosować
ją do własnych potrzeb. Phalcon zachowuje także kompatybilność względem
starszych wersji, posiada rozbudowaną dokumentację, zastosowanie gotowych
rozwiązań poparte przykładami, ciągle wsparcie i rozwój przez dużą społeczność.
Niestety na rynku nie ma rozwiązań idealnych. Wykorzystywany przez
nas system posiada także cechy negatywne. Możemy do nich zaliczyć wymaganie serwera, który jest w pełni modyfikowalny, a więc wybór hostingu
dla witryny ulega znacznemu zawężeniu. Jako, że jest to framework, rozwijając stronę musimy odwoływać się do stworzonego pierwotnie i narzuconego
nam wzorca oraz opierać na nim wszystkie działania rozwoju funkcjonalności
witryny. Do pełnego rozwiązania części problemów potrzebne jest poznanie
myśli technologicznej jaką posiadali i kierowali się twórcy Phalcon. [11]
Decydując się na gotowe rozwiązanie musimy być świadomi, że posiada
ono poza zaletami także wady. W naszym projekcie Phalcon, mimo swoich
wad, okazał się bardzo dobrym wyborem i pozwolił przyspieszyć prace nad
systemem eTravel.
48:4757669047
Rozdział 3
Projektowanie i implementacja
baz danych na przykładzie
MySQL
autor: Tomasz Przydróżny
49:8640757813
3.1 Relacyjna baza danych
50
3.1. Relacyjna baza danych
3.1.1. Wprowadzenie
Bazy danych przechowują informacje w ściśle określonych strukturach tak,
aby dostęp do nich był szybki i wygodny oraz by łatwo można było zarządzać
ogromnymi zasobami danych. Do obsługi bazy danych wykorzystywany jest
system zarządzania bazą danych, który zapewnia możliwość projektowania
nowych baz danych jak i komunikowania się z bazą danych w celu wyszukiwania informacji czy administrowania danymi i dostępem do nich. Przykładami
popularnych systemów zarządzania bazami danych są: Microsoft SQL Server,
MySQL, Oracle, PostgreSQL.
Definicja bazy danych: ”Zbiór danych zorganizowany zgodnie z pojęciową strukturą opisującą charakterystyki tych danych oraz związki między ich
elementami, stosowany w jednym lub wielu zastosowaniach.” [13]
Wyróżnić można wiele modeli baz danych sklasyfikowanych na podstawie
przyjętego w nich modelu reprezentacji danych. Oto kilka przykładów:
• hierarchiczny - wszystkie dane przechowywane są na zasadzie rekordów
nadrzędnych-podrzędnych i przypominają strukturę drzewa. Każdy rekord (oprócz głównego) jest związany z jednym rekordem nadrzędnym.
Budowanie bazy opartej na tym modelu odbywa się od ogółu do szczegółu w miarę jak zwiększa się poziom zagłębienia drzewa. Jedyną relacją jest jeden do wielu, więc w przypadku gdy jakiś obiekt ma wielu
”rodziców” musi zostać zduplikowany aby została zachowana struktura
drzewiasta.
• sieciowy - zmodyfikowany model hierarchiczny pozwalający na relacje
wiele do wielu bez konieczności duplikacji obiektów w strukturze drze-
50:7272165687
51
Rysunek 3.1. Przykład drzewa danych w modelu hierarchicznym
wiastej. Korzysta on z rekordów i zbiorów: rekordy przechowują pola
zawierające dane, zbiory natomiast określają relację jeden do wielu między rekordami. Każdy rekord może być w wielu zbiorach, jak i posiadać
wiele zbiorów.
Rysunek 3.2. Przykład drzewa danych w modelu sieciowym
• relacyjny - dane są przechowywane w dwuwymiarowych tablicach (wiersze i kolumny) i obsługiwane są na podstawie matematycznej teorii
relacji. Nie istnieje relacja wiele do wielu, ale można zasymulować ją
dodając tabelę pośrednią pomiędzy dwie tabele w relacji jeden do wielu
51:2784138566
52
i wiele do jednego. Obecnie najbardziej rozpowszechniony model stosowany w większości baz danych.
• obiektowy - dane przechowywane są w postaci obiektów, czyli struktur
nazywanych klasami, które wyświetlają zawarte w nich dane. Pola stanowią przykłady tych klas. Dzięki takiemu podejściu dane są w pełni
kompatybilne z danymi używanymi w programach napisanych w obiektowych językach programowania.
• relacyjno-obiektowy - stanowi kompromis między relacyjnymi, a obiektowymi bazami danych. Pozwala na operowanie na danych jak na obiektach, posiada jednak bazę relacyjną jako wewnętrzny mechanizm przechowywania danych. Systemy obiektowo-relacyjne są wyposażane w
wiele cech umożliwiających efektywną produkcję aplikacji. Wśród nich
można wymienić przystosowanie do multimediów, dane przestrzenne,
abstrakcyjne typy danych, metody definiowane przez użytkownika w
różnych językach, kolekcje, typy referencyjne, przeciążanie funkcji, późne wiązanie i inne. Systemy te zachowują wiele technologii, które sprawdziły się w systemach relacyjnych. Dodatkową zaletą jest uniknięcie
konwersji aktualnych baz danych do nowego, obiektowego.
Ze względu na fakt, iż w pracy omawiana jest baza danych na przykładzie
MySQL, który jest oparty na modelu relacyjnej bazy danych, w dalszej jej
części rozważania o bazie danych zostały zawężone do modelu relacyjnego.
3.1.2. Cechy
Przede wszystkim relacyjna struktura charakteryzuje się reprezentowaniem
związków między rekordami jedynie przez wartości danych w kolumnach,
pochodzących ze wspólnej dziedziny. Własnością podejścia relacyjnego jest
52:6443731827
53
przedstawienie w sposób jednolity za pomocą tabel całej informacji, jaką jest
zbiór danych i relacji między nimi. Typ rekordu to nazwana struktura danych,
złożona ze zbioru nazwanych pól; każde pole służy do zapisu pojedynczego
atrybutu obiektu opisywanego przez rekord, i charakteryzuje się określonym
typem danych, np. liczba całkowita (integer), napis (char), data (date), itp.
Na ogół jedno z pól danego typu rekordu wyróżnia się jako klucz, tj. unikalny
identyfikator rekordu wśród rekordów danego typu (często wykorzystuje się
”naturalne klucze” jak np. nr albumu studenta lub nr PESEL w ewidencji
ludności) oraz zakłada się uporządkowanie rekordów wg. wartości jednego
z pól (zwykle klucza, choć niekoniecznie). Typy rekordów tworzą strukturę
drzewa, tj. każdy typ rekordu (z wyjątkiem najwyższego w hierarchii, tzw.
korzenia – root) związany jest z dokładnie jednym typem nadrzędnym. Zarazem każdy określony rekord typu podrzędnego jest związany z określonym
rekordem właściwego typu nadrzędnego.
3.1.3. Integralność danych
Model relacyjny zapewnia dodatkowe, specyficzne postaci reguł integralności.
Przede wszystkim zagwarantowany jest brak powtórzeń wierszy w tabelach
(unikalność) dzięki ustawieniu wartości klucza głównego (primary key) na
unikatowe. Dodatkowo relacyjna baza danych musi posiadać tzw. integralność referencyjną, czyli każda wartość klucza obcego (foreign key) musi być
równa wartości klucza głównego występującego w tabeli powiązanej (istnieje
możliwość nadania wartości NULL kluczowi obcemu). Pociąga to za sobą koniczność określenia zasad funkcji wykonywanych w przypadku zmiany, modyfikacji lub usuwania rekordów z tabel powiązanych. Brak wartości w kolumnie
tabeli łączącej wartości klucza obcego spowodował by jego unieważnienie, i
doprowadził do anomalii w bazie danych. Przykładem takiej anomalii może
53:7493386563
3.2 Etap projektowania
54
być usunięcie wiersza w tabeli nadrzędnej przez co klucz główny przestaje
istnieć, a wszystkie klucze obce z tabel podrzędnych wskazują aktualnie na
nieistniejący wiersz powodując przerwanie relacji między tabelami. Aby nie
dopuścić do takich sytuacji stosuje się trzy podejścia zachowania integralności danych:
• restricted - nie można usunąć wiersza dopóki istnieją jakiekolwiek klucze obce w innych tabelach odwołujące się do klucza głównego
• cascades - usunięcie wiersza powoduje usunięcie wierszy we wszystkich
tabelach zawierających klucze obce odnoszące się do klucza głównego
• nullifies - nieważne wartości kluczy obcych zostają zastąpione przez
wartość NULL.
3.2. Etap projektowania
3.2.1. Wprowadzenie
Projektowanie bazy danych jest kluczowym elementem powstawania dobrze
działającej i wydajnej bazy danych.
Model E-R (Entity-Relationship Model), autorstwa dr. Peter’a Chen’a,
jest początkiem etapu konceptualnego (abstrakcyjnego) każdego projektu relacyjnej bazy danych [14]. Opisuje dziedzinę przedmiotową za pomocą pojęć
takich jak encja, atrybut oraz związek. Jest on opisem bardzo teoretycznym,
wymagającym przełożenia na język praktyki. Jego zadaniem jest opisanie
fragmentu rzeczywistości za pomocą związków encji. W tym modelu używa się definicji, które mają swoje odzwierciedlenie na późniejszym etapie –
wdrożenia projektu w życie.
54:7763048563
55
3.2.2. Planowanie bazy spełniającej założenia projektu
Tworzenie funkcjonalnej bazy ma trzy etapy. Zaczyna się od ogólnego konceptu pozbawionego jakichkolwiek szczegółów implementacyjnych czy ograniczeń wynikających z relacyjności baz danych (dopuszczalne relacje typu
wiele do wielu). Jest to określenie podstawowych założeń, które mają być
spełnione w konkretnym projekcie (wymagania), oraz jakie ma dane przechowywać (np. informacje o użytkownikach lub produktach). czy też zdefiniowanie relacji między krotkami. Następnie tworzy się diagram relacji encji
(ERD), w którym to uwzględnia się podstawowe relacje między tabelami
wraz z krotnościami. Nadal nie ma tam informacji szczegółowych ani czysto
technicznych, lecz wyłania się ogólny zarys bazy w postaci tabel, kolumn
oraz opcjonalnych funkcji czy procedur. Bardzo ważne jest aby na tym etapie skupić się na ogólnej wizji całej bazy zamiast wdawać się w szczegóły
opisujące poszczególne pola w tabelach. Jeden błąd, przeoczenie czy niedopatrzenie może skutkować błędnie zaprojektowaną bazą, która nie spełnia
wszystkich założeń projektu, co często początkujący projektant dostrzega
dopiero na etapie implementacji lub (co gorsza) testowania. Późniejsze naprawianie błędu na tak wczesnym i kluczowym etapie staje się bardzo trudne,
czasochłonne a często wręcz niemożliwe. Następnym krokiem jest wkroczenie na wyższy stopień szczegółowości, czyli wybór kluczy głównych i obcych,
nadanie typów dla pól w tabelach oraz rozbicie relacji typu wiele do wielu na
jeden do wielu dodając tabele pośrednie. Na tym etapie należy już mieć na
uwadze względy wydajnościowe naszej bazy. Projektant musi być świadomy
ograniczeń tworzonej przez siebie bazy by być w stanie ocenić czy jest ona w
stanie sprostać wymogom projektu. Podstawowymi informacjami jakimi musi on dysponować są dane dotyczące przewidywanego obciążenia bazy, ilości i
częstotliwości zapytań, wielkości poszczególnych danych (pól) jak i ich ilości
55:3805552330
56
(krotek). Bez rozpatrzenia tych aspektów może się okazać, ze baza jest niewydajna co skutkować będzie bardzo długim dostępem do danych lub nawet
odmową dostępu ze względu na przeciążenie. Dlatego tak ważny jest ostatni
etap projektowania bazy danych, którym jest optymalizacja. W tym kroku
znajduje się wszystkie redundantne dane jakie jeszcze pozostały w schemacie
bazy i przebudowuje się ją pod kątem ich usunięcia. Nazywa się to normalizacją i ma trzy następujące po sobie etapy (postaci normalne). Baza danych
znajduje się w pierwszej postaci normalnej gdy wszystkie pola w tabelach
posiadają jedną, atomową wartość. Druga postacią normalną jest sytuacja,
w której wszystkie kolumny niebędące kluczami są zależne od całego klucza
podstawowego w danej tabeli. Przykładem nie spełniającym tej reguły jest
tabela z dwoma kluczami i kolumną zależną tylko od jednego klucza. Oznacza
to, że kolumna ta nie jest zależna od całego klucza tylko od jego części i należy ją przenieść do innej tabeli, bądź stworzyć dla niej nową tabelę. Trzecia
postać normalna wymaga dodatkowa, aby każda kolumna niebędąca kluczem
była zależna tylko i wyłącznie od klucza. Niedopuszczalnym jest zatem aby w
tej postaci zmiana wartości w jednej z kolumn (nie będących kluczem) miała
wpływ na wartość w innej kolumnie w tej tabeli. Te trzy etapy normalizacji
w zupełności wystarczą do skutecznego pozbycia się redundancji w bazie. Co
prawda istnieją jeszcze dwie zasady, ale ich w praktyce się nie stosuje, gdyż
wprowadzają zbyt dużą fragmentaryczność w bazie przez co staje się nieczytelna i trudna w administrowaniu (czasami spotyka się także odstępstwa od
trzeciej reguły jeśli projektant uzna, że sytuacja tego wymaga i będzie to
miało dobry wpływ na wygodę użytkowania bazy).
56:1145876988
57
3.2.3. Częste błędy w projektowaniu baz
Bardzo ważne w projektowaniu baz jest konkretne zdefiniowanie założeń projektu. Nawet najlepiej zaplanowany diagram bazy jest bezużyteczny jeśli nie
uwzględnia wszystkich niezbędnych funkcjonalności, jakie ma oferować finalny produkt. Przykładem błędnie zaprojektowanej bazy jest stworzenie tabel
”klasy” oraz ”profesorowie” w relacji jeden do wielu, gdzie założeniem projektu była możliwość przypisywania profesorowi wielu grup zajęciowych i na
odwrót. Kolejnym istotnym błędem jest rozrzutność przy dobieraniu typów
danych. Często są stosowane BIGINT’y w sytuacjach gdzie w zupełności wystarczą zwykłe INT’y, które zajmują 4 bajty zamiast 8 bajtów. Oszczędność
4 bajtów nie wydaje się istotna, lecz przemnożona przez kilka milionów rekordów w bazie danych oraz ilość atrybutów będących liczbami potrafi dokonać
istotnej różnicy. Jeśli dodatkowo taki atrybut zostanie indeksem problem
szybko się zwielokrotni. Ta sama zasada dotyczy się ciągów znaków, gdzie
zawsze warto (pomijając wartości hash’owane np. hasła użytkowników) zawężać maksymalną ilość znaków do rozsądnych wartości. Istotną kwestią jest
umiejętne korzystanie z indeksów służących do skracania czasu dostępu do
często wyszukiwanych danych w bazie. Ich zadanie zbliżone jest do zadania
kluczy głównych z tą różnicą, że nie służą do tworzenia relacji między tabelami. Można zatem za ich pomocą posortować rekordy w tabeli według
wartości konkretnej kolumny, co znacząco skróci czas realizacji zapytania do
bazy, gdyż nie trzeba już przeszukiwać tysięcy rekordów jeden po drugim.
Jest to wspaniałe narzędzie optymalizujące, ale nie jest lekarstwem na źle zaprojektowaną bazę. Często początkujący projektanci popadając w zachwyt
nad możliwościami indeksowania danych zapominają o wadach takiego rozwiązania. Należy pamiętać, że każda zaindeksowana kolumna w tabeli musi
być zapisana w pamięci oraz w trakcie każdej edycji danych również wszystkie
57:3714903649
58
indeksy odnoszące się do tych danych muszą zostać zaktualizowane. Generuje to dwa poważne ograniczenia: łatwo można przekroczyć dostępną pamięć
potrzebną do zapisu indeksów oraz edytowanie danych w bazie może wymagać zdecydowanie za dużo czasu ze względu na konieczność aktualizowania
indeksów. Przed stworzeniem indeksu należy zatem zastanowić się czy jest
on przydatny na tyle aby opłacało się go dodać. Oto kilka podstawowych
sytuacji przemawiających za tworzeniem indeksów:
• w klauzuli WHERE zapytania korzysta się często z danego pola lub
zestawu pól
• pola często wykorzystywane są do złączania tabel poprzez JOIN-y
• pola są często wykorzystywane do sortowania wyników tabeli
• pola są często wykorzystywane w funkcjach MIN() i MAX()
• rekordy w tabeli danego pola mają bardzo różne wartości – wyszukiwanie przy pomocy indeksu jest tym skuteczniejsze, im mniej rekordów
ma szukaną wartość
Natomiast w sytuacjach poniższych stosowanie indeksów jest niewskazane:
• dane w tabeli są częściej edytowane niż odczytywane
• pola zawierają dużo jednakowych wartości
• zapytania są mało selektywne
• pole w zapytaniach jest wykorzystywane poprzez funkcję np. WHERE
substr(name, 4, 1) = ‘r’ – silnik nie wykorzysta wtedy indeksu
58:5281208682
59
3.2.4. Projektowanie bazy dla projektu eTravel
W założeniach projektu eTravel był łatwy i szybki dostęp do dużej ilości
danych dotyczących przystanków oraz linii komunikacyjnych. Baza danych
miała także umożliwiać przechowywanie informacji o zarejestrowanych użytkownikach oraz dokonanych przez nich zakupów biletów, czy wyrażonych
opiniach na temat odbytej trasy. Po przeanalizowaniu wszystkich wymagań
stworzony został diagram ERD, w oparciu którego została póżniej stworzona
baza danych dla projektu. Powstało łącznie sześć tabel odpowiadających za
przechowywanie informacji dotyczących linii komunikacyjnych, ich przystanków zawierających dane geolokalizacyjne, użytkowników wraz z ich dokonanymi zakupami i wyrażonymi opiniami na temat konkretnych połączeń.
59:1831766490
3.3 Etap implementacji
3.3. Etap implementacji
3.3.1. Diagram ERD projektu eTravel
Rysunek 3.3. Diagram związków encji w bazie danych projektu eTravel
60:4056030155
60
3.3.2. MySQL w projekcie eTravel
1
CREATE TABLE
‘ lines ‘ (
2
‘ line_id ‘ int (11) NOT NULL AUTO_INCREMENT ,
3
‘ station_id ‘ int (11) NOT NULL ,
4
‘ number ‘ int (11) NOT NULL ,
5
PRIMARY KEY ( ‘ line_id ‘) ) ;
Kod źródłowy 3.1. tabela linie
1
CREATE TABLE ‘ orders ‘ (
2
‘ order_id ‘ int (11) NOT NULL AUTO_INCREMENT ,
3
‘ user_id ‘ int (11) NOT NULL ,
4
‘ cost ‘ float NOT NULL ,
5
‘ date ‘ date NOT NULL ,
6
PRIMARY KEY ( ‘ order_id ‘) ) ;
Kod źródłowy 3.2. tabela zamówienia
1
CREATE TABLE ‘ order_details ‘ (
2
‘ transaction_id ‘ int (11) NOT NULL AUTO_INCREMENT ,
3
‘ order_id ‘ int (11) NOT NULL ,
4
‘ product_id ‘ int (11) NOT NULL ,
5
‘ amount ‘ int (11) NOT NULL ,
6
PRIMARY KEY ( ‘ transaction_id ‘) ) ;
Kod źródłowy 3.3. tabela szczegóły zamówienia
61:5641978503
61
1
CREATE TABLE ‘ products ‘ (
2
‘ product_id ‘ int (11) NOT NULL AUTO_INCREMENT ,
3
‘ price ‘ float NOT NULL ,
4
‘ amount ‘ int (11) NOT NULL ,
5
‘ start_city ‘ varchar (50) NOT NULL ,
6
‘ end_city ‘ varchar (50) NOT NULL ,
7
PRIMARY KEY ( ‘ product_id ‘) ) ;
Kod źródłowy 3.4. tabela produkty
1
CREATE TABLE ‘ stations ‘ (
2
‘ station_id ‘ int (11) NOT NULL AUTO_INCREMENT ,
3
‘ geoX ‘ text NOT NULL ,
4
‘ geoY ‘ text NOT NULL ,
5
‘ name ‘ varchar (50) NOT NULL ,
6
‘ short_name ‘ varchar (20) NOT NULL ,
7
PRIMARY KEY ( ‘ station_id ‘) ) ;
Kod źródłowy 3.5. tabela stacje
62:1737685852
62
Podsumowanie
Niniejsza praca inżynierska pokazała w jaki sposób został osiągnięty cel, którym było stworzenie projektu aplikacji eTravel wspierającej planowanie podróży. Przedstawia ona zarówno podstawy teoretyczne związane z zagadnieniem systemów rozproszonych, tworzenia stron www oraz baz danych, a także
konkretną implementację rozwiązań. eTravel to aplikacja, która wykorzystuje zalety architektury rozproszonej z wykorzystaniem REST. W połączeniu
z dobrym zaprojektowaniem bazy danych oraz utrzymaniem odpowiednich
standardów przy budowie stron www, pozwoliło to na powstanie aplikacji
wydajnej i użytecznej. Podsumowując, udało się zbudować system wspomagania planowania podróży z użyciem komunikacji miejskiej miasta Poznań,
a także przewoźników międzymiastowych.
63:6078808500
Bibliografia
[1] Paweł Lula, Tadeusz Wilusz.
Architektury systemów rozproszonego przetwarzania danych.
http://yadda.icm.edu.pl/yadda/element/bwmeta1.element.ekonelement-000151173283
[2] Robert Wójcik.
Wymagania projektowe systemów rozproszonych.
http://staff.iiar.pwr.wroc.pl/robert.wojcik/dydaktyka/dzienne/rsbd/RB˙4.pdf
[3] Zofia Kruczkiewicz.
Rozproszone bazy danych.
http://zofia.kruczkiewicz.staff.iiar.pwr.wroc.pl/wyklady/intBD/wyklad6/intbd6.pdf
[4] C.J. Date.
An Introduction to Database Systems.
[5] Maciej Zakrzewicz.
Wprowadzenie do technologii WebServices.
http://www.cs.put.poznan.pl/mzakrzewicz/pubs/ploug06ws.pdf
[6] Mateusz Stępniak, Allegro.
Budowa poprawnego i intuicyjnego api REST.
64:5373232184
BIBLIOGRAFIA
65
http://www.slideshare.net/zenedith/budowa-apiresthateoasdevfest2013
[7] Ewa Korulska, Anna Stokowska.
Centrum Edukacji Obywatelskiej. Historia Internetu.
http://www.ceo.org.pl/sites/default/files/newsfiles/historia˙internetu˙2.pdf
[8] Radosław Kozłowski, Piotr Płyś, Allegro.
User Experience i budowanie użytecznych interfejsów.
https://drive.google.com/file/d/0Byz4Bk88kEb3Z3dVWWw2Mk5PSGs/view
[9] Google.
Any place, any time, any device - Building Websites for the Multi-Screen
Consumer.
http://www.google.com/think/multiscreen/whitepapermultiscreenconsumer.html
[10] Bootstrap.
Dokumentacja framework’a BootStrap.
http://getbootstrap.com
[11] Phalcon.
Dokumentacja framework’a Phalcon.
https://docs.phalconphp.com/en/latest/index.html
[12] Wizualizacja idei Responsive Web Design.
http://www.web.gov.pl/g2/big/2014˙12/ac45b44dbc4d941d305d27ad7336c10f.png
[13] Technika informatyczna - Terminologia - Terminy podstawowe PNISO/IEC 2382-1, Alfa-Wero, 1996.
65:3082660285
BIBLIOGRAFIA
66
[14] The Entity-Relationship Data Model: toward a unified view of data. P.P.
Chen, ACM Transactions on Database Systems, 1976
66:4469458600
Załączniki
• Dokumentacja techniczna projektu eTravel
67:5607218004

eTravel - aplikacja wspomagająca planowanie

Transkrypt

Podobne dokumenty

zobacz online

zobacz online

zobacz online

zobacz online

zobacz online

zobacz online

zobacz online

zobacz online