hệ thống thông tin hỗ trợ du lịch

TRƯỜNG ĐẠI HỌC CẦN THƠ
KHOA CÔNG NGHỆ THÔNG TIN & TRUYỀN THÔNG
BỘ MÔN TIN HỌC ỨNG DỤNG

LUẬN VĂN TỐT NGHIỆP ĐẠI HỌC

HỆ THỐNG THÔNG TIN
HỖ TRỢ DU LỊCH

SINH VIÊN THỰC HIỆN

CÁN BỘ HƯỚNG DẪN

NGUYỄN TRUNG TÍN

KS. PHẠM TRƯƠNG HỒNG NGÂN

MSSV: 1117887

Cần Thơ, 2015


TRƯỜNG ĐẠI HỌC CẦN THƠ
KHOA CÔNG NGHỆ THÔNG TIN & TRUYỀN THÔNG
BỘ MÔN TIN HỌC ỨNG DỤNG

LUẬN VĂN TỐT NGHIỆP ĐẠI HỌC

HỆ THỐNG THÔNG TIN
HỖ TRỢ DU LỊCH
SINH VIÊN THỰC HIỆN

CÁN BỘ HƯỚNG DẪN

NGUYỄN TRUNG TÍN

KS. PHẠM TRƯƠNG HỒNG NGÂN

MSSV: 1117887

Cán bộ phản biện
Chủ tịch hội đồng: ThS. VŨ DUY LINH
Ủy viên: ThS. HỒ VĂN TÚ
Luận văn được bảo vệ tại: Hội đồng chấm luận văn tốt nghiệp Bộ môn Tin học
Ứng dụng, Khoa Công nghệ Thông tin & Truyền thông, Trường Đại học Cần Thơ
vào ngày 25 tháng 06 năm 2015

Mã số đề tài:
Có thể tìm hiểu luận văn tại:
- Trung tâm Học liệu, Trường Đại học Cần Thơ
- Website: />Cần Thơ, 2015


LỜI CẢM ƠN
Với lòng kính trọng và biết ơn sâu sắc, tôi xin chân thành bày tỏ lời cảm ơn đến
Ban Giám Hiệu Trường Đại học Cần Thơ, quý Thầy (Cô) Khoa Công nghệ
Thông tin & Truyền thông đã tạo mọi điều kiện thuận lợi, giúp đỡ tôi trong quá trình
học tập, nghiên cứu, sinh hoạt Đoàn và các hoạt động khác tại trường.
Gởi lời cảm ơn chân thành và lòng biết ơn tới toàn thể giáo viên trong Bộ môn
Tin Học Ứng Dụng (Khoa Khoa học Tự Nhiên) - hiện nay trực thuộc Khoa
Công nghệ Thông tin & Truyền thông - Trường Đại học Cần Thơ đã giảng dạy những

kiến thức quý báo để tôi có thể hoàn thành đề tài. Kiến thức của các thầy, cô giáo
giảng dạy là vô cùng quý báu và là hành trang cần thiết cho tôi nói riêng và tất cả sinh
viên nói chung sau khi ra trường.
Cảm ơn Thầy Phạm Trương Hồng Ngân, là người đã hướng dẫn, giải đáp tận
tình những câu hỏi cũng như khích lệ tôi trong quá trình nghiên cứu và hoàn thành
luận văn tốt nghiệp.
Cảm ơn Cô Lê Minh Lý luôn quan tâm, giúp đỡ và động viên tôi trong suốt quá
trình học tập tại trường.
Xin chân thành cảm ơn quý Thầy (Cô) trong hội đồng chấm luận văn đã cho tôi
những đóng góp quý báu để hoàn chỉnh luận văn này.
Xin chân thành cảm ơn Mẹ, Cha và anh hai đã luôn ở bên cạnh, động viên và
khích lệ tôi trong quá trình học tập.
Xin gửi lời cảm ơn chân thành đến các bạn trong lớp Tin Học Ứng Dụng K37,
Trường Đại học Cần Thơ đã đồng hành và giúp đỡ tôi trong suốt những năm học tại
trường.
Tôi xin chân thành cảm ơn!
Cần Thơ, ngày 25 tháng 06 năm 2015
Sinh viên thực hiện
NGUYỄN TRUNG TÍN


NHẬN XÉT CỦA CÁN BỘ HƯỚNG DẪN
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................

......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................

......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................


NHẬN XÉT CỦA CÁN BỘ PHẢN BIỆN
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................

......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................


MỤC LỤC
MỤC LỤC ................................................................................................................... i
DANH MỤC HÌNH .................................................................................................. iii
DANH MỤC BẢNG .................................................................................................. v
DANH MỤC KÝ HIỆU VÀ VIẾT TẮT .................................................................. vi

TÓM TẮT................................................................................................................. vii
ABSTRACT ............................................................................................................ viii
CHƯƠNG 1: TỔNG QUAN ...................................................................................... 1
1.1. ĐẶT VẤN ĐỀ ..................................................................................................... 1
1.1.1. Bối cảnh ............................................................................................................ 1
1.1.2. Mục tiêu ............................................................................................................ 1
1.2. LỊCH SỬ VÀ GIẢI QUYẾT VẤN ĐỀ ............................................................... 1
1.3. PHẠM VI NGHIÊN CỨU .................................................................................. 2
1.3.1. Về cơ sở lý thuyết ............................................................................................. 2
1.3.2. Về chức năng .................................................................................................... 2
1.3.3. Về kỹ thuật........................................................................................................ 3
1.4. HƯỚNG GIẢI QUYẾT ...................................................................................... 3
CHƯƠNG 2: CƠ SỞ LÝ THUYẾT ........................................................................... 4
2.1. KHÁI NIỆM CÁC MÔ HÌNH TRONG CƠ SỞ DỮ LIỆU QUAN HỆ ............. 4
2.1.1. Mô hình phân rã chức năng .............................................................................. 4
2.1.2. Mô hình Use Case ............................................................................................ 4
2.1.3. Mô hình luồng dữ liệu ...................................................................................... 4
2.1.4. Mô hình dữ liệu quan niệm .............................................................................. 5
2.1.5. Mô hình dữ liệu mức logic ............................................................................... 5
2.2. CÁC KHÁI NIỆM TRONG CƠ SỞ DỮ LIỆU ĐỒ THỊ.................................... 5
2.2.1. Giới thiệu về cơ sở dữ liệu đồ thị ..................................................................... 5
2.2.2. So sánh về khả năng lưu trữ các dữ liệu liên kết .............................................. 7
2.2.3. Mô hình hóa bằng CSDL đồ thị ..................................................................... 12
2.2.4. Xây dựng một ứng dụng sử dụng CSDL đồ thị .............................................. 13
2.3. NGÔN NGỮ PHÍA CLIENT ............................................................................ 14
2.3.1. Javascript ........................................................................................................ 14
2.3.2. HTML ............................................................................................................. 14
2.3.3. XML ............................................................................................................... 15
i

2.3.4. CSS ................................................................................................................. 15
2.4. NGÔN NGỮ PHÍA SERVER ........................................................................... 16
2.5. KHÁI QUÁT VỀ NEO4J, ZEND FRAMEWORK, JQUERY MOBILE
FRAMEWORK VÀ GOOGLE MAPS JAVASCRIPT API .................................... 16
2.5.1. Neo4j .............................................................................................................. 16
2.5.2. Zend Framework ............................................................................................ 20
2.5.3. jQuery Mobile Framework ............................................................................. 25
2.5.4. Google Maps Javascript API .......................................................................... 26
CHƯƠNG 3: NỘI DUNG VÀ KẾT QUẢ NGHIÊN CỨU ..................................... 27
3.1. ĐẶC TẢ ỨNG DỤNG ...................................................................................... 27
3.1.1. Giới thiệu ........................................................................................................ 27
3.1.2. Mô tả bài toán ................................................................................................. 28
3.2. PHÂN TÍCH - THIẾT KẾ HỆ THỐNG ........................................................... 28
3.2.1. Mô hình phân rã chức năng BFD ................................................................... 28
3.2.2. Mô hình Use Case .......................................................................................... 28
3.2.3. Mô hình luồng dữ liệu DFD ........................................................................... 30
3.2.4. Lưu trữ trên cơ sở dữ liệu quan hệ MySQL ................................................... 31
3.2.5. Lưu trữ trên cơ sở dữ liệu đồ thị Neo4j .......................................................... 31
3.3. KẾT QUẢ NGHIÊN CỨU ................................................................................ 33
3.3.1. Trang chính của hệ thống ............................................................................... 33
3.3.2. Trang tra cứu thông tin địa điểm và dịch vụ hỗ trợ ........................................ 34
3.3.3. Trang tìm kiếm đường đi ................................................................................ 35
3.3.4. Trang tạo lịch trình ......................................................................................... 37
KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN ............................................................... 44
PHỤ LỤC ................................................................................................................. 45
TÀI LIỆU THAM KHẢO ........................................................................................ 57

ii

DANH MỤC HÌNH
Hình 1.1. Hình ảnh 15 thành phố trong Bài toán người bán hàng ............................. 2
Hình 1.2. Hệ quản trị CSDL sử dụng trong ứng dụng ............................................... 3
Hình 1.3. Các nền tảng sử dụng trong ứng dụng ........................................................ 3
Hình 1.4. Các ngôn ngữ sử dụng trong ứng dụng ...................................................... 3
Hình 2.1. Một đồ thị nhỏ mô tả mạng xã hội Twitter................................................. 6
Hình 2.2. Mô hình hóa các mối quan hệ bạn bè trong CSDL quan hệ ....................... 8
Hình 2.3. Các mối quan hệ cụ thể trong việc lưu trữ một tập hợp trong NOSQL ..... 9
Hình 2.3. Mô hình đơn giản về mối quan hệ bạn bè giữa một người với những người
khác trong CSDL đồ thị ............................................................................................ 10
Hình 2.4. Một mẫu đồ thị đơn giản trong CSDL đồ thị ........................................... 12
Hình 2.5. Mô hình dữ liệu về sở thích đọc sách của một người............................... 13
Hình 2.6. Cửa sổ khởi động server Neo4j ................................................................ 17
Hình 2.7. Giao diện browser của Neo4j ................................................................... 17
Hình 2.8. Giao diện admin của Neo4j ...................................................................... 18
Hình 2.9. Ví dụ tìm đường đi ngắn nhất giữa hai nút............................................... 19
Hình 2.10. Tạo project Zend Framework 2 trong Zend Studio 12 ........................... 21
Hình 2.10. Cấu trúc thư mục và tập tin trong Zend Framework 2 ........................... 22
Hình 3.1. Ứng dụng Google Maps trên điện thoại thông minh ................................ 27
Hình 3.2. Sơ đồ phân rã chức năng BFD.................................................................. 28
Hình 3.3. Mô hình Use Case .................................................................................... 28
Hình 3.4. Mô hình luồng dữ liệu mức 0 ................................................................... 30
Hình 3.5. Mô hình luồng dữ liệu mức 1 ................................................................... 30
Hình 3.6. Lưu trữ trên cơ sở dữ liệu MySQL ........................................................... 31
Hình 3.7. Lưu trữ trên cơ sở dữ liệu Neo4j .............................................................. 31
Hình 3.8. Thuộc tính của các nút trong CSDL Neo4j .............................................. 32
Hình 3.9. Thuộc tính của các quan hệ trong CSDL Neo4j ....................................... 32
Hình 3.10. Giao diện chính của ứng dụng ................................................................ 33
Hình 3.11. Tra cứu thông tin địa điểm và dịch vụ hỗ trợ ......................................... 34

Hình 3.12. Trang tìm kiếm đường đi ........................................................................ 35
Hình 3.13. Trang tìm kiếm đường đi (hiển thị kết quả) ........................................... 36
Hình 3.14. Trang tạo lịch trình (thêm địa điểm) ...................................................... 37
Hình 3.15. Trang tạo lịch trình (hiển thị danh sách các địa điểm đã chọn) ............. 38
iii


Hình 3.16. Trang tạo lịch trình (chỉnh sửa các địa điểm đã chọn) ........................... 39
Hình 3.17. Trang tạo lịch trình (chọn phương tiện và thời gian đi) ......................... 40
Hình 3.18. Trang tạo lịch trình (xác nhận lịch trình đã gợi ý) ................................. 41
Hình 3.19. Trang tạo lịch trình (xem lịch trình trên bản đồ và lịch trình chi tiết) ... 42
Hình 3.20. Trang tạo lịch trình (hiển thị các thông báo lỗi) ..................................... 43

iv


DANH MỤC BẢNG
Bảng 2.1. Thời gian thực hiện truy vấn tìm "bạn của bạn" trong một hệ quản trị CSDL
quan hệ (RDBMS) và trong một hệ quản trị CSDL đồ thị (Neo4j) ......................... 11
Bảng 2.2 Thành phần thư mục và tập tin trong Zend Framework 2 ........................ 23
Bảng 3.1. Mô tả Use Case chi tiết ............................................................................ 29
Bảng 3.2. Bảng mô tả các thuộc tính của các nút ..................................................... 32
Bảng 3.3. Bảng mô tả các thuộc tính của các mối quan hệ ...................................... 32

v


DANH MỤC KÝ HIỆU VÀ VIẾT TẮT
STT

Chữ viết tắt Nguyên nghĩa

1

API

Application Programming Interface

2

BA

Business Analysis

3

CDN

Content Delivery Network

4

CSDL

Cơ Sở Dữ Liệu

5

CSS

Cascading Style Sheets

6

DOM

Document Object Model

7

HTML

Hyper Text Markup Language

8

LDM

Logic Data Model

9

NOSQL

Not Only SQL

10

OOP

Object-Oriented Programming

11

PHP

Hypertext Preprocessor

12

RDBMS

Relational Database Management System

13

REST

Representation State Transfer

14

SOAP

Simple Object Access Protocol

15

W3C

World Wide Web Consortium

16

XML

eXtensible Markup Language

17

ZF

Zend Framework

vi


TÓM TẮT
Tại thời điểm hiện tại, chúng ta có thể thấy rằng công nghệ thông tin đã đi vào khắp
các mọi lĩnh vực của đời sống hằng ngày, không thể phủ nhận việc tin học hóa giúp
con người tiết kiệm thời gian và nâng cao hiệu suất khi giải quyết vấn đề.
Có những bài toán xuất phát từ thực tế nhu cầu của chúng ta, điển hình như bài toán
người bán hàng (Travelling Salesman Problem) - một nhân viên bán hàng có
khách hàng nằm rải rác trên một loạt các thành phố, nếu biết chính xác khoảng cách
giữa mỗi hai thành phố và làm thế nào tìm ra con đường ngắn nhất để có thể đến thăm
mỗi thành phố một lần và sau đó trở về nhà, nơi người đó đã xuất phát. Bài toán này
là một vấn đề rất cơ bản và ứng dụng của nó thì nhiều vô kể, như trong việc tính toán
lộ trình để một người đi du lịch có thể đi nhiều nơi nhất với khoảng thời gian ít nhất
và chi phí hợp lý nhất.
Phương pháp trực tiếp nhằm tìm ra lời giải phổ biến là kiểm tra tất cả các tổ hợp.

Tuy nhiên, trên thực tế phương pháp này không thật sự khả thi bởi nếu lấy mẫu chỉ
gồm 20 thành phố thì sẽ có gần 60,8 triệu tỉ phép so sánh để tìm ra hành trình có lợi
nhất. Từ lúc phiên bản đầu tiên của cơ sở dữ liệu đồ thị Neo4j được cho ra mắt vào
năm 2007, với khả năng lưu trữ dữ liệu trên đồ thị và thực hiện được những truy vấn
phức tạp, nó đã tỏ ra vượt trội hơn các cơ sở dữ liệu quan hệ khi lưu trên bảng.
Cơ sở dữ liệu đồ thị đã được áp dụng thành công trong khá nhiều vấn đề, dễ thấy nhất
có lẽ là trong các mạng xã hội như Facebook và Twitter. Nếu quan sát kỹ thì
hoàn toàn có thể thấy chúng đã xuất hiện khắp mọi nơi trong đời sống hằng ngày của
chúng ta, từ trong lĩnh vực kinh tế tài chính đến việc xây dựng hệ thống chăm sóc
y tế cho người dân,...
Đề tài này tập trung tìm hiểu sức mạnh của cơ sở dữ liệu đồ thị và áp dụng nó để
giải quyết bài toán trên cho các lĩnh vực khác nói chung và cho người đi du lịch
nói riêng. Ứng dụng sẽ sử dụng cơ sở dữ liệu đồ thị là chính và cơ sở dữ liệu quan hệ
hỗ trợ; tìm kiếm và biểu diễn đường đi dựa trên Google Maps; và được xây dựng trên
giao diện điện thoại sử dụng jQuery Mobile Framework để thuận tiện cho người
sử dụng khi di chuyển mà không bị phụ thuộc vào máy tính.
Từ khóa: bài toán người bán hàng, bài toán người đi du lịch, đường đi ngắn nhất,
du lịch cá nhân, cơ sở dữ liệu đồ thị, web điện thoại, Google Maps

vii


ABSTRACT
At this moment, we can see what Information Technology did in various fields of our
daily life. We all depend on technology and we use many technologies to accomplish
specific tasks in our lives.
There are a lot of real life mathematical problems, especially Travelling Salesman
Problem (TSP) - a salesman have several customers living in cities, given a list of
cities and the distances between each pair of cities, what is the shortest possible route
that visits each city exactly once and returns to the origin city? The TSP has several

applications even in its purest formulation, such as planning for travellers to have a
trip which having the cheapest cost in less time.
The most direct solution would be to try all permutations (ordered combinations) and
see which one is cheapest. However, the factorial of the number of cities, so this
solution becomes impractical even for only 20 cities. Since the first version Neo4j
was released in 2010, it stores connected data natively in graphs and executing
complex queries is more efficient more than relational databases storing data in
tables.
Graph database has been used in a lots applications; on top of that, there's a lot of
uptake in social networks as Facebook and Twitter. We are surrounded by graphs,
they are everywhere: the financial industry, the health care system,...
This thesis concentrates on researching power of graph database and using to solve
difficult problems in various fields in general and finding solution for traveler in
particular. The application uses both graph database and relational database; searchs
and directs base on Google Maps; develops using jQuery Mobile Framework for
smartphone - which users can bring everywhere along.
Key words: travelling salesman problem, the shortest path, travel alone, graph
database, mobile web, Google Maps

viii


CHƯƠNG 1: TỔNG QUAN
1.1. ĐẶT VẤN ĐỀ
1.1.1. Bối cảnh
Trong bối cảnh hội nhập quốc tế nói chung và trong ngành du lịch nói riêng
hiện nay, toàn cầu hóa và địa phương hóa du lịch đang là một xu hướng phát triển, gây
ra những tác động mạnh mẽ, lớn lao đến các quốc gia có tiềm năng lớn về du lịch.
“Ngành công nghiệp không khói” của Việt Nam cũng đang phát huy các giá trị tài
nguyên di sản của địa phương một cách chọn lọc, sáng tạo những giá trị mới từ sự tiếp

thu tinh hoa văn hóa, du lịch thế giới. Du lịch Việt Nam đã và đang có những đột phá
thú vị thông qua sự đa dạng của các loại hình du lịch khác nhau.
Các loại hình du lịch Việt Nam trong những năm gần đây có những bước khởi sắc
phát triển cùng với sự phát triển như vũ bão của công nghệ thông tin trên một phương
diện rộng thúc đẩy các tổ chức và cá nhân làm việc trong lĩnh vực du lịch nghiên cứu và
liên tục chào bán gói du lịch mới theo nhiều tên gọi khác nhau. Tuy vậy, nhưng số lượng
khách tham gia vẫn chỉ rất giới hạn như: du lịch theo mùa; du lịch quá cảnh; du lịch
trăng mật với những cặp vợ chồng mới cưới; du lịch công vụ (có khả năng chi trả cao
nhưng thiếu thời gian nghỉ ngơi hoàn toàn).
Một bộ phận du khách trẻ ưa trải nghiệm và thích tự mình khám phá lại chọn
“phượt” - loại hình du lịch đang khá phổ biến hiện nay. Theo đó đã phát sinh ra bài toán
làm thế nào để tính toán chi phí tối ưu nhất để có thể đi được nhiều nơi nhất trong một
khoảng thời gian ít hơn. Thực tế, một người khi đi du lịch đến một nơi nào đó sẽ tự tạo
một lịch trình riêng cho mình nhưng sẽ mất khá nhiều thời gian do phải tìm hiểu thông
tin về các nơi muốn tham quan và đặc thù của địa phương đó. Với những bất tiện đó thì
việc xây dựng một hệ thống web có thể giúp mọi người tự tra cứu, sắp xếp một chuyến
đi riêng cho mình ngay trên điện thoại (điện thoại thông minh) có kết nối internet thật
sự hữu ích.
1.1.2. Mục tiêu
Xây dựng hệ thống website hỗ trợ du lịch cá nhân dành cho tất cả mọi đối tượng
trên điện thoại thông minh với các chức năng:
 Tìm kiếm, xem thông tin và chỉ đường đi đến các địa điểm tham quan
 Gợi ý các địa điểm ăn uống, khách sạn, trụ ATM, dịch vụ hỗ trợ chuyến đi
 Gợi ý lịch trình với danh sách các địa điểm muốn đến, tối ưu theo chi phí thấp
nhất hoặc tối ưu theo khoảng cách để đi được nhiều nơi nhất
1.2. LỊCH SỬ VÀ GIẢI QUYẾT VẤN ĐỀ
Đầu tiên, phải đề cập đến “Bài toán Người đi du lịch” hay “Bài toàn Người bán
hàng” (Travelling Salesman Problem - TSP) là một trong những bài toán kinh điển và
khó trong tin học. Nội dung bài toán như sau: “Cho trước một danh sách các thành phố
và khoảng cách giữa chúng, tìm đường đi ngắn nhất đi qua mỗi thành phố đúng một

lần.”
Trang 1


`
Hình 1.1. Hình ảnh 15 thành phố trong Bài toán người bán hàng
Bài toán có phát biểu rất đơn giản nhưng rất khó giải trong trường hợp tổng quát
với không gian tìm kiếm rộng lớn, khó bởi các thuật toán hiệu quả nhất đã được biết đến
có thời gian giải quyết bài toán này tăng dần theo cấp số nhân của n, hay độ phức tạp
thuật toán tăng theo hàm số mũ. Có rất nhiều cách tiếp cận giải bài toán này ngay từ khi
nó mới ra đời, như sử dụng quy hoạch tuyến tính, thuật toán vét cạn, thuật toán người
láng giềng gần nhất, kỹ thuật nhánh và cận, nhưng mới chỉ dừng lại ở các bộ dữ liệu
nhỏ. Gần đây có nhiều thuật toán ra đời theo hướng tiếp cận về tiến hóa như thuật toán
di truyền (Genetic Algorithm) hay cách mô phỏng hành vi của đàn kiến như thuật toán
đàn kiến (Ant Colony Optimization - ACO) được áp dụng cho kết quả tốt hơn rất nhiều.
Vấn đề của bài toán đang giải quyết tuy không giống hoàn toàn nhưng có nhiều
điểm tương đồng với bài toán TSP. Hiểu và tìm được giải thuật để bài toán TSP tối ưu
thì việc giải quyết vấn đề của đề tài sẽ trở nên dễ dàng hơn.
1.3. PHẠM VI NGHIÊN CỨU
1.3.1. Về cơ sở lý thuyết
Dựa vào các kiến thức đã học và kiến thức có được qua thời gian nghiên cứu về
cơ sở dữ liệu đồ thị Neo4j, Google Maps Javascript API v3, Zend Framework 2 và
jQuery Mobile Framework.
1.3.2. Về chức năng
Gợi ý danh sách các địa điểm tham quan, ăn uống, khách sạn, trụ ATM...
Tra cứu thông tin địa điểm
Tìm kiếm đường đi giữa hai địa điểm
Trang 2

Gợi ý lịch trình đi qua các địa điểm đã chọn
Gợi ý các địa điểm nổi bật khác nếu chúng gần với các địa điểm đã chọn
Ghi chú lịch trình chi tiết: thời gian ở mỗi địa điểm và phương tiện di chuyển
1.3.3. Về kỹ thuật
Giao diện thân thiện với người dùng
Hệ quản trị CSDL: Neo4j 2.3.0, MySQL 5.0

Hình 1.2. Hệ quản trị CSDL sử dụng trong ứng dụng
Nền tảng sử dụng: Zend Framework 2, jQuery Mobile Framework 1.4.5, Google
Maps Javascript API v3

Hình 1.3. Các nền tảng sử dụng trong ứng dụng
Ngôn ngữ sử dụng: Javascript, PHP, HTML5, CSS3, XML

Hình 1.4. Các ngôn ngữ sử dụng trong ứng dụng
1.4. HƯỚNG GIẢI QUYẾT
Hướng giải quyết vấn đề được thực hiện qua các giai đoạn:
Giai đoạn 1: Từ yêu cầu đề tài, mô tả chi tiết bài toán và tìm hiểu thực tế thông
qua ý kiến người dùng, tham khảo một số website về cách thể hiện các chức năng hệ
thống website mobile
Giai đoạn 2: Phân tích và hoạch định ra các hướng giải quyết vấn đề
Giai đoạn 3: Tìm hiểu các công nghệ phục vụ cho quá trình giải quyết bài toán
Giai đoạn 4: Vẽ lưu đồ giải thuật cho các module, thiết kế giao diện người dùng
Giai đoạn 5: Cài đặt các ứng dụng và sử dụng các công nghệ hỗ trợ

Trang 3


CHƯƠNG 2: CƠ SỞ LÝ THUYẾT
2.1. KHÁI NIỆM CÁC MÔ HÌNH TRONG CƠ SỞ DỮ LIỆU QUAN HỆ

2.1.1. Mô hình phân rã chức năng
Mô hình phân rã chức năng (Business Function Diagram - BFD) là công cụ biểu
diễn việc phân rã có thứ bậc đơn giản các công việc cần thực hiện. Mỗi công việc được
chia ra làm các công việc con, số mức chia ra phụ thuộc kích cỡ và độ phức tạp của
hệ thống.
Mỗi chức năng có một tên duy nhất, các chức năng khác nhau phải có tên khác
nhau. Để xác định tên cho chức năng có thể bàn luận và nhất trí với người sử dụng. Tên
của chức năng cần ngắn và giải thích đủ nghĩa của chức năng và phải sử dụng thuật ngữ
nghiệp vụ.
Đặc điểm của mô hình phân rã chức năng:





Cung cấp cái nhìn khái quát chức năng
Dễ thành lập
Gần gũi với sơ đồ tổ chức
Không đưa ra mối liên quan về thông tin giữa các chức năng

Mục đích của mô hình phân rã chức năng:
 Xác định phạm vi của hệ thống cần phân tích
 Cho phép mô tả khái quát dần các chức năng của tổ chức một cách trực tiếp,
khách quan, phát hiện được chức năng thiếu hoặc trùng lặp
 Tạo điều kiện thuận lợi khi hợp tác giữa nhà thiết kế và người sử dụng trong
qua trình phát triển hệ thống.
2.1.2. Mô hình Use Case
Kết quả của quá trình khảo sát hệ thống phản ánh quá trình làm việc của người
phát triển với người sử dụng. Mô hình này mô tả sự tương tác đặc trưng giữa người dùng
bên ngoài (actor) và hệ thống. Từ quan điểm người dùng phát hiện ra các tình huống sử

dụng (use case) khác nhau, tập hợp use case và tác nhân cùng với quan hệ giữa chúng
tạo ra mô hình Use Case mô tả yêu cầu của hệ thống.
Mục đích của mô hình Use Case:
 Tạo nên một nền tảng cho các bước kiểm thử hệ thống, đảm bảo hệ thống thỏa
mãn đúng những yêu cầu do người dùng đưa ra.
 Đơn giản hóa việc thay đổi và mở rộng hệ thống qua việc thay đổi và mở rộng
mô hình Use Case.
2.1.3. Mô hình luồng dữ liệu
Mô hình luồng dữ liệu (Data Flow Diagram - DFD) mô tả sự trao đổi, luân chuyển
thông tin, dữ liệu giữa các đối tượng.

Trang 4


Mô hình này cung cấp cái nhìn tổng thể về mối quan hệ giữa các thành phần dữ
liệu và xử lý (xử lý nào phụ thuộc vào xử lý nào, dữ liệu nào cần cho chuỗi xử lý) nên
yêu cầu phải chính xác, đầy đủ và rõ ràng.
Mục đích của mô hình luồng dữ liệu là cho thấy các thực thể, các quá trình chính,
các dòng dữ liệu và các kho dữ liệu.
2.1.4. Mô hình dữ liệu quan niệm
Mô hình dữ liệu quan niệm (Conceptual Data Model - CDM) là phương tiện để
giao tiếp với người dùng nhằm xác định tính đúng đắn & đầy đủ của yêu cầu thông tin
của hệ thống. Sau khi tất cả các yêu cầu đã được thu thập và phân tích, bước tiếp theo
là tạo ra lược đồ quan niệm cho cơ sở dữ liệu bằng cách sử dụng mô hình này.
Lược đồ quan niệm là một mô tả súc tích về các yêu cầu dữ liệu của những người
sử dụng. Nó bao gồm các mô tả chi tiết của các kiểu thực thể, kiểu liên kết và các ràng
buộc, chúng được biểu diễn bằng các khái niệm do các mô hình dữ liệu bậc cao cung
cấp. Vì những khái niệm này không chứa các chi tiết cài đặt nên chúng thường dễ hiểu
và có thể sử dụng chúng để giao lưu với những người sử dụng.
2.1.5. Mô hình dữ liệu mức logic

Bước tiếp theo trong việc thiết kế cơ sở dữ liệu là việc cài đặt một cơ sở dữ liệu
bằng cách sử dụng một hệ quản trị cơ sở dữ liệu có sẵn. Lược đồ quan niệm được chuyển
từ mô hình dữ liệu bậc cao thành mô hình dữ liệu cài đặt. Bước này gọi là thiết kế logic
hoặc là ánh xạ mô hình dữ liệu.
Nhiệm vụ của mô hình dữ liệu mức logic (Logic Data Model - LDM) không đi sâu
vào chi tiết kỹ thuật truy xuất hoặc lưu trữ dữ liệu (đó là nhiệm vụ của mô hình dữ liệu
mức vật lý), nhưng phải kể đến các khả năng, giới hạn của hệ thống quản lý tập tin hay
hệ thống quản lý cơ sở dữ liệu. Hơn nữa, mô hình luận lý cho dữ liệu quan tâm đến sự
tổ chức cho dữ liệu, sao cho thích hợp với thời gian đáp ứng mà xử lý đòi hỏi.
Mục tiêu của mô hình này chính là tổ chức dữ liệu và tối ưu hóa cách tổ chức đó.
2.2. CÁC KHÁI NIỆM TRONG CƠ SỞ DỮ LIỆU ĐỒ THỊ [2]
2.2.1. Giới thiệu về cơ sở dữ liệu đồ thị
2.2.1.1. Khái quát
Thông thường, một đồ thị được định nghĩa là một tập các đỉnh được nối với nhau
bởi các cạnh, hay nói cách khác là gồm các nút và các quan hệ liên kết chúng lại với
nhau. Đồ thị biểu diễn các thực thể như là các nút và cách chúng liên hệ với thế giới
thực như là các quan hệ.
Đồ thị cực kỳ hữu ích cho việc tìm hiểu một số lượng rất đa dạng các tập dữ liệu
trong nhiều lĩnh vực như khoa học, chính trị và kinh doanh. Một khi có thể hiểu rõ được
đồ thị là gì thì chúng ta sẽ bắt đầu nhận thấy rằng chúng xuất hiện ở khắp mọi nơi. Đồ
thị cho phép chúng ta mô hình hóa tất cả các đối tượng, vấn đề hay tình huống nào trong
thực tế, ví dụ như mô hình hóa từ một mạng xã hội đến một hệ thống đường giao thông,
Trang 5


một chuỗi cung cấp thực phẩm hay phát triển hệ thống y tế phục vụ cho người dân, và
hơn thế nữa.
Ví dụ, dữ liệu của Twitter dễ dàng biểu diễn như một đồ thị như sau:
Billy

FOLLOWS

Ruth

FOLLOWS

Harry

Hình 2.1. Một đồ thị nhỏ mô tả mạng xã hội Twitter
Trong đồ thị Hình 2.1 các nút biểu diễn các thực thể là những người dùng được
định danh bằng tên và có các mối quan hệ là [:FOLLOWS]. Mối quan hệ có thể là
một chiều hoặc hai chiều. Như trong đồ thị trên, hầu hết các mối quan hệ là hai
chiều, duy chỉ có mối quan hệ giữa Ruth và Billy là một chiều. Dĩ nhiên trong thực tế
thì đồ thị của Twitter lớn hơn trăm triệu lần so với đồ thị trên, nhưng đồ thị này vẫn hoạt
động chính xác dựa trên cùng một nguyên tắc.
2.2.1.2. Sức mạnh của cơ sở dữ liệu đồ thị
Hiện nay, mặc dù CSDL đồ thị không thể thay thế được tính tiện dụng của CSDL
quan hệ đã mang lại, nhưng để khai thác được giá trị các mối quan hệ của tất cả các thực
thể trong thế giới thực thì CSDL đồ thị lại vô cùng mạnh mẽ. Sức mạnh của nó thể hiện
qua các đặc điểm về hiệu suất, linh hoạt và nhanh chóng.
Hiệu suất:
 Hiệu suất là một lý do hoàn toàn thuyết phục khi chọn CSDL đồ thị để làm việc
với các dữ liệu có liên kết thay vì chọn CSDL quan hệ hay NOSQL. Đối với
CSDL quan hệ, khi các tập dữ liệu ngày càng lớn thì việc phải kết hợp nhiều
bảng lại với nhau và thực hiện các truy vấn chuyên sâu khá vất vả, mất thời
gian và kém hiệu quả, ngược lại CSDL đồ thị lại làm rất tốt việc này.
 Lý do là vì các truy vấn đã được nội bộ hóa như một phần của đồ thị. Thế nên
thời gian để thực hiện các câu truy vấn tỷ lệ với kích thước của một phần đồ thị
được duyệt để đáp ứng các câu truy vấn đó, chứ không phụ thuộc vào kích
thước của toàn bộ đồ thị. Do vậy, dù kích thước của tập dữ liệu có tăng lên thì

thời gian thực hiện truy vấn vẫn đảm bảo.
Linh hoạt:
 Khác với các CSDL khác, CSDL đồ thị không cần xác định trước cấu trúc hay
mô hình của CSDL. Ví dụ như khi xây dựng một CSDL quan hệ, chúng ta cần
xác định các bảng, các trường của từng bảng và kiểu của các trường,... và quan
trọng là chúng ta gần như không thể thay đổi được gì hoặc là thay đổi rất khó
khăn. Còn với CSDL đồ thị, chúng ta hoàn toàn có thể thêm vào các nút và các

Trang 6


quan hệ mới mà không sợ làm ảnh hưởng đến các nút khác, cũng như không
làm thay đổi kết quả truy vấn đang thực hiện.
 Bởi vì tính linh hoạt này của CSDL đồ thị, nên nó rất phù hợp cho các công
việc có tính chất hay thay đổi và tính ổn định không cao. Do vậy, chúng ta
không cần phải có trước một mô hình hoàn chỉnh nào đó mà sau một thời gian
khi thấy không phù hợp nữa thì phải xây dựng lại một mô hình khác. Ngoài ra,
tính linh hoạt của CSDL đồ thị còn giúp giảm chi phí bảo trì và rủi ro như các
CSDL khác mang lại.
Nhanh chóng:
 Đặc biệt, CSDL đồ thị với việc mô hình hóa các lược đồ tự do (schema-free)
kết hợp với khả năng thử nghiệm các giao diện lập trình ứng dụng (Application
Programming Interface - API) giúp cho người sử dụng có thể phát triển ứng
dụng một cách có kiểm soát.
 Tính nhanh chóng ở đây là chúng ta có thể vận dụng và tiếp cận với các xu
hướng mới một cách thuận lợi khi mà thế giới xung quanh luôn thay đổi không
ngừng.
2.2.2. So sánh về khả năng lưu trữ các dữ liệu liên kết
Chúng ta đang sống trong một thế giới mà mọi thứ đều có liên hệ với nhau. Các
thông tin vô cùng quý giá nhưng chúng sẽ càng có ích hơn nếu như được liên kết và

hỗ trợ cho nhau để phát triển, giúp con người xử lý vấn đề nhanh hơn. Tuy nhiên, với
nguồn tài nguyên khổng lồ trên mạng như hiện nay thì việc kết nối chúng lại với nhau
không dễ dàng chút nào.
2.2.2.1. Cơ sở dữ liệu quan hệ
Trong nhiều thập kỷ, các nhà phát triển luôn tìm cách để đưa các dữ liệu liên kết
(connected data) và các tập dữ liệu bán cấu trúc vào trong CSDL quan hệ. Trong khi đó,
CSDL quan hệ ban đầu lại được thiết kế theo một định dạng cố định với một hệ thống
các bảng có cấu trúc. Trớ trêu thay, việc lấy một cái có cấu trúc để lưu trữ cái nửa cấu
trúc thật sự là một vấn đề nan giải.
Các mối quan hệ thật có tồn tại trong một CSDL nhưng chỉ xuất hiện khi chúng ta
nối các bảng lại với nhau. Nhưng như thế vẫn chưa đáp ứng được tính chất của các dữ
liệu liên kết. Tệ hơn nữa khi cấu trúc của các tập dữ liệu ngày một phức tạp và không
thống nhất với nhau, CSDL quan hệ trở nên cồng cềnh với số lượng lớn các bảng được
nối với nhau, các dòng thưa thớt hơn và không được kiểm tra rỗng (null-checking). Sự
gia tăng trong việc liên kết các giao dịch ngày càng lớn làm cản trở khả năng làm việc
của CSDL quan hệ, khiến nó không còn đáp ứng được việc xử lý, thực hiện truy vấn và
lữu trữ dữ liệu. Điều này dẫn đến sự ra đời của một loại CSDL khác phù hợp hơn. Để
hiểu rõ hơn chúng ta có thể thực hiện một vài câu truy vấn với CSDL sau:

Trang 7


Person

PersonFriend

ID

Person

PersonID

FriendID

1

Alice

1

2

2

Bob

2

1

…

…

2

99

99

Zach

…

…

99

1

Hình 2.2. Mô hình hóa các mối quan hệ bạn bè trong CSDL quan hệ
Ví dụ 1. Thực hiện truy vấn “Ai là bạn của Bob?”
SELECT p1.Person
FROM Person p1 JOIN PersonFriend
ON PersonFriend.FriendID = p1.ID
JOIN Person p2
ON PersonFriend.PersonID = p2.ID
WHERE p2.Person = 'Bob'

Theo như trong bảng dữ liệu thì chúng ta có thể thấy Alice và Zach là bạn của Bob.
Đây không phải là một câu truy vấn khó, tuy nhiên bạn bè luôn là mối quan hệ hai chiều,
chúng ta hãy chuyển sang ví dụ tiếp theo để làm rõ điều này.
Ví dụ 2. Câu truy vấn “Ai là bạn với Bob?”
SELECT p1.Person
FROM Person p1 JOIN PersonFriend
ON PersonFriend.PersonID = p1.ID
JOIN Person p2
ON PersonFriend.FriendID = p2.ID
WHERE p2.Person = 'Bob'

Chúng ta có thể hiểu câu truy vấn trên hỏi ai là bạn trong danh sách bạn bè của
Bob và ngược lại, Bob nằm trong danh sách bạn bè của ai. Câu trả lời đã khác đi một
chút, không phải là Alice và Zach nữa, mà chỉ có Alice thôi. Bởi vì trong danh sách bạn
bè của Zach không có Bob.
Vấn đề ở đây là do tính chất của dữ liệu, chúng ta chỉ quan tâm đến cách nó xử lý
truy vấn như thế nào thôi. Trong Ví dụ 1, chúng ta duyệt tuần tự đến khi nào hết mẫu
tin có PersonID = 2 thì kết thúc. Còn trong Ví dụ 2, chúng ta phải duyệt tất cả các mẫu
tin. Vấn đề này cũng thường hay gặp trong khi thực hiện truy vấn với CSDL quan hệ,
tuy nhiên nếu ta tiếp tục truy vấn sâu hơn “Ai là bạn của bạn của Bob?” thì mọi chuyện
sẽ trở nên phức tạp hơn rất nhiều.
Ví dụ 3. Câu truy vấn “Ai là bạn của bạn của Bob?”
SELECT p1.Person AS PERSON, p2.Person AS FRIEND_OF_FRIEND
FROM PersonFriend pf1 JOIN Person p1 ON pf1.PersonID = p1.ID
JOIN PersonFriend pf2 ON pf2.PersonID = pf1.FriendID
JOIN Person p2 ON pf2.FriendID = p2.ID
WHERE p1.Person = 'Alice' AND pf2.FriendID <> p1.ID

Đây là một câu truy vấn phức tạp, mặc dù nó chỉ xử lý với danh sách bạn của Alice
mà không đi sâu hơn vào những thứ khác trong mạng xã hội của Alice và nếu đi sâu hơn
Trang 8


vào trong mạng thì mọi thứ sẽ trở nên phức tạp và khó khăn hơn. Mặc dù nó có thể trả
lời câu hỏi “Ai là bạn của bạn của bạn của tôi?” trong một thời gian nhất định, câu truy
vấn mở rộng đến 4, 5 hoặc 6 mức độ (truy vấn con) trong một mối quan hệ bạn bè do sự
phức tạp trong cách tính toán và phức tạp về không gian của các bảng đệ quy.
Các nhà phát triển cố gắng mô hình hóa và thực hiện các truy vấn với dữ liệu liên
kết trong CSDL quan hệ. Ngoài việc truy vấn và tính toán phức tạp vừa đề cập, chúng
ta còn phải đương đầu với con dao hai lưỡi của một lược đồ, một là sự gia tăng về số
lượng các kết nối làm phá vỡ toàn bộ các liên kết, hai là hạn chế trong việc phát triển

một sơ đồ lên một ứng dụng.
2.2.2.2. Cơ sở dữ liệu NOSQL
Hầu hết các CSDL NOSQL đều đã linh động hơn rất nhiều so với CSDL quan hệ
khi lưu trữ bằng các cặp khóa-giá trị, các tài liệu, hoặc các cột có hướng - thành một tập
tài liệu / giá trị / cột không có liên kết gì với nhau. Điều này khiến nó khó khăn khi sử
dụng chúng để liên kết các dữ liệu với các đồ thị lại.
Có một cách thường sử dụng để thêm mới các mối quan hệ cho việc lưu trữ là
nhúng một tập hợp các định danh vào bên trong một trường thuộc một tập hợp khác gọi là một khóa ngoại. Nhưng điều này đòi hỏi việc phải nối các tập hợp đó lại trong
ứng dụng nên nó nhanh chóng làm tốn kém không gian lưu trữ.
Khi nhìn vào một mô hình lưu trữ tổng hợp như trong hình sau đây, có thể giúp
chúng ta gợi lên về các mối quan hệ, cụ thể với bảng lưu trữ user:Alice thì chúng ta lại
có các bảng liên kết phụ khác là order và item. Điều này dễ khiến ta tưởng rằng có thể
dùng cặp khóa - giá trị để quản lý cả đồ thị.

Hình 2.3. Các mối quan hệ cụ thể trong việc lưu trữ một tập hợp trong NOSQL

Trang 9


Trong hình trên chúng ta có thể suy luận rằng một số thuộc tính của các giá trị thật
sự có tham chiếu đến các bảng liên kết phụ ở đâu đó trong CSDL. Nhưng để đưa những
suy luận này vào trong một cấu trúc có điều hướng thì lại không dễ dàng, hầu hết các
lưu trữ chỉ cho biết cấu trúc bên trong tập hợp, là một dạng các bản đồ lồng vào nhau
mà thôi.
Chúng ta cũng phải bảo đảm khi ứng dụng cập nhật hoặc xóa một bảng thì các
bảng liên kết phụ tham chiếu song song với nó cũng phải được cập nhật hoặc xóa theo;
nếu không dữ liệu sẽ bị xung đột và không được bảo toàn, gây ra sự dư thừa làm lãng
phí không gian lưu trữ.
2.2.2.3. Cơ sở dữ liệu đồ thị
Những ví dụ trước đã nêu ra một số vấn đề khi xử lý dữ liệu liên kết, khi đóng vai

trò như một người dùng, chúng ta hoàn toàn có thể suy luận ra các phụ thuộc về ngữ
nghĩa giữa các thực thể với nhau, tuy nhiên các mô hình dữ liệu và CSDL của chúng thì
lại bị ẩn đi. Điều chúng ta thật sự muốn là một bức tranh toàn cảnh bao gồm những kết
nối giữa các phần tử.
Trong các CSDL đồ thị, dữ liệu liên kết được lưu trữ như là dữ liệu được kết nối.
Trong một phạm vi nhất định, ở đâu có các kết nối thì ở đó có các liên kết trong dữ liệu.
Cùng xét một mạng xã hội được mô tả trong ví dụ sau:

Hình 2.3. Mô hình đơn giản về mối quan hệ bạn bè giữa một người với những người
khác trong CSDL đồ thị
Trong mạng xã hội này, như trong rất nhiều trường hợp thực tế của dữ liệu liên
kết, có thể thấy rõ ràng các mối quan hệ giữa các thực thể không bị bó buộc trong một
Trang 10


phạm vi nhất định (bán cấu trúc). Mạng xã hội là một ví dụ điển hình của một kết nối
dày đặc, một mạng đơn giản về các mối quan hệ bạn bè của chúng ta đã tăng về kích cỡ
và mức độ các mối quan hệ cũng được phát triển hơn. Nhờ sự linh động của CSDL đồ
thị cho phép chúng ta có thể thêm bớt các nút và các mối quan hệ mới mà không cần lo
lắng đến việc di chuyển hay thay đổi cấu trúc dữ liệu trong mạng, đồng thời vẫn giữ
được dữ liệu và các quan hệ ban đầu của chúng.
Thật sự thì đồ thị có thể cho chúng ta thấy được bức tranh phong phú hơn về một
mạng đang xét, tức là chúng ta có thể thấy được các mối quan hệ của một thực thể với
các thực thể còn lại thông qua hướng của các mối quan hệ. Ví dụ như ai có tình cảm với
ai [:LOVES], ai là đồng nghiệp của nhau [:COLLEAGUE_OF] và ai là sếp của họ
[:BOSS_OF] và có thể phát hiện được các phần tử xấu của một mạng bằng mối quan hệ
[:DISLIKES]. Với mạng mà chúng ta đã xây dựng nên bằng CSDL đồ thị thì khi nó xử
lý các dữ liệu liên kết lại tỏ ra khá dễ dàng.
So sánh đã cho thấy rằng CSDL đồ thị nhanh hơn đáng kể trong việc liên kết dữ
liệu so với CSDL quan hệ. Ví dụ như Zach là bạn của Alice nhưng chiều ngược lại thì

không - điều này nếu thực hiện trong CSDL quan hệ thì khá lằng nhằng và phức tạp. Và
việc thực hiện các câu truy vấn như "bạn của bạn của bạn,..." thì sẽ dễ dàng hơn nhất là
khi độ sâu của truy vấn tăng lên. Thử nghiệm trên một mạng xã hội 1,000,000 người,
mỗi người với khoảng 50 bạn và độ sâu tối đa là 5. Kết quả được thể hiện như trong
bảng sau:
Bảng 2.1. Thời gian thực hiện truy vấn tìm "bạn của bạn" trong một hệ quản trị CSDL
quan hệ (RDBMS) và trong một hệ quản trị CSDL đồ thị (Neo4j)
Thời gian thực hiện
trong RDBMS (s)

Thời gian thực hiện
trong Neo4j (s)

Số mẫu tin trả về

2

0.016

0.01

~2500

3

30.267

0.168

~110,000

4

1543.505

1.359

~600,000

5

Không thực hiện được

2.132

~800,000

Độ sâu

Có thể thấy sự chênh lệch đáng kể của hệ quản trị CSDL quan hệ qua các lần truy
vấn và khi độ sâu bằng 5 thì nó đã không thể thực hiện được câu truy vấn nữa. Trong
khi đó, Neo4j chẳng những thực hiện truy vấn ổn định mà thời gian cũng nhanh hơn rất
nhiều so với CSDL quan hệ. Đến đây thì có thể khẳng định CSDL đồ thị hiệu quả hơn
hẳn CSDL quan hệ khi làm việc với dữ liệu liên kết. Tuy vậy không có nghĩa là CSDL
quan hệ và các CSDL NOSQL khác không hữu ích và hiệu quả, chúng vẫn làm việc tốt
với các liệu liệu không có tính liên kết cao và ổn định. Tùy theo tính chất của từng loại
dữ liệu mà người ta sẽ xem xét nên sử dụng loại CSDL nào cho phù hợp.
Từ ví dụ về mạng xã hội vừa nêu, chúng ta hoàn toàn có thể áp dụng vào các vấn
đề khác trong nhiều lĩnh vực của đời sống như quản lý thông tin sinh học, bản đồ gen,
phác đồ điều trị dựa trên bệnh án của bệnh nhân và gia đình, hay gợi ý sản phẩm trong

kinh doanh dựa vào lịch sử mua hàng,... tất cả đều có thể áp dụng CSDL đồ thị để có
được các quyết định chính xác hơn.

Trang 11


2.2.3. Mô hình hóa bằng CSDL đồ thị
2.2.3.1. Đặc điểm
Một mô hình đồ thị muốn hoạt động thì nó phải có các đặc điểm chính sau:
 Gồm có các nút, các mối quan hệ và các thuộc tính
 Các nút chứa cả các thuộc tính
 Các mối quan hệ liên kết và tạo thành cấu trúc cho các nút. Một mối quan hệ
luôn có một hướng, một nhãn và một nút bắt đầu cũng như một nút kết thúc không thể có một mối quan hệ "lủng lẳng"
 Giống như các nút, các mối quan hệ cũng có thể chứa các thuộc tính
2.2.3.2. Ngôn ngữ truy vấn đồ thị: Giới thiệu về Cypher
Cypher là ngôn ngữ truy vấn được thiết kế cho CSDL đồ thị, dễ đọc và dễ hiểu đối
với các nhà phát triển, các chuyên gia về CSDL và các nhà kinh tế. Cypher cho phép
người dùng tìm kiếm thông tin theo một mô hình cụ thể nào đó.
a

b

KNOWS

c

Hình 2.4. Một mẫu đồ thị đơn giản trong CSDL đồ thị
Hình 2.4 mô tả 3 người bạn chung, biểu diễn bằng ASCII tương ứng với đồ thị
trong Cypher như sau:
(a)-[:KNOWS]->(b)-[:KNOWS]->(c), (a)-[:KNOWS]->(c)

Cũng như hầu hết các ngôn ngữ khác, Cypher cũng có các câu lệnh riêng. Câu truy
vấn đơn giản nhất bao gồm một mệnh đề START theo sau đó là MATCH và RETURN. Sau đây
là một ví dụ đơn giản cho câu truy vấn sử dụng 3 mệnh đề trên để tìm bạn chung của
một người có tên là Michael:
START a=node:user(name='Michael')
MATCH (a)-[:KNOWS]->(b)-[:KNOWS]->(c), (a)-[:KNOWS]->(c)
RETURN b, c

Sử dụng:
 Dấu ngoặc đơn để biểu diễn các nút, ví dụ như (a)
 Cặp dấu gạch ngang và dấu lớn hơn/dấu nhỏ hơn để biểu diễn mối quan hệ, ví
dụ như -> và < Giữa các dấu gạch ngang là các dấu ngoặc vuông và dấu hai chấm là tên các
mối quan hệ, ví dụ như [:KNOWS]

Trang 12