CHUYỂN đổi mô HÌNH dữ LIỆU QUAN hệ và đối TƯỢNG SANG NOSQL

LỜI CAM ĐOAN
Tôi xin cam đoan:
1. Những nội dung trong luận văn này là do tôi thực hiện dưới sự hướng dẫn trực
tiếp của Thầy PGS.TS Nguyễn Đình Thuân.
2. Mọi tham khảo trong luận văn đều được trích dẫn rõ ràng tên tác giả, tên công
trình, thời gian công bố.
3. Mọi sao chép không hợp lệ, vi phạm quy chế đào tạo tôi xin chịu hoàn toàn trách
nhiệm.

Tp Hồ Chí Minh, ngày tháng 9 năm 2017
Học viên

Văn Thị Phương Lâm


LỜI CẢM ƠN

Để hoàn thành khóa luận này, em xin tỏ lòng biết ơn sâu sắc đến thầy Thầy PGS. TS
Nguyễn Đình Thuân – Trường Đại học Công nghệ Thông tin - ĐH Quốc gia TP HCM
đã khuyến khích, động viên, hướng dẫn tận tình cho em trong suốt quá trình thực hiện
luận văn.
Em chân thành cám ơn đến quý Thầy Cô Trường Đại học Công nghệ Thông
tin – ĐH Quốc gia TP HCM đã đã tận tình truyền đạt kiến thức và tạo điều kiện tốt
nhất để em hoàn thành luận văn này.
Cảm ơn gia đình, bạn bè, người thân luôn bên cạnh động viên, khuyến khích em hoàn
thành luận văn này.

Văn Thị Phương Lâm


MỤC LỤC

LỜI CAM ĐOAN ..........................................................................................................
LỜI CẢM ƠN ................................................................................................................
MỤC LỤC....................................................................................................................1
DANH MỤC CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT ..................................................3
DANH MỤC CÁC BẢNG ..........................................................................................4
MỞ ĐẦU ......................................................................................................................6
Chương 1 Lý Thuyết và các nghiên cứu liên quan ......................................................8
1.1 Tổng quan tình hình nghiên cứu ............................................................................8
1.1.1 Tình hình nghiên cứu về chuyển đổi mô hình dữ liệu quan hệ sang NoSQL .8
1.1.2 Tình hình nghiên cứu về chuyển đổi mô hình đối tượng sang NoSQL...........8
1.2 Mục tiêu, phương pháp nghiên cứu .....................................................................12
1.3 Lý thuyết về mô hình dữ liệu hướng đối tượng ...................................................13
1.3.1 Cái khái niệm .................................................................................................13
1.3.1.1 Đối tượng và lớp .....................................................................................13
1.3.1.2 Cơ sơ dữ liệu hướng đối tượng ...............................................................13
1.3.2 Mô hình dữ liệu hướng đối tượng..................................................................14
1.3.2.1 Tính bao đóng..........................................................................................14
1.3.2.2 Kế thừa ....................................................................................................14
1.3.2.3 Tính đa hình ............................................................................................14
1.3.2.4 Class Diagram .........................................................................................15
1.3.3 Ưu điểm và nhược điểm của OODBMS........................................................15
1.4 Lý thuyết về mô hình dữ liệu quan hệ đối tượng .................................................15
1.4.1 Giới thiệu .......................................................................................................15
1.4.2 Tính năng của mô hình ORDBMS: ...............................................................16
1.4.3 Kiểu dữ liệu của quan hệ - đối tượng ORDBMS ..........................................16
1.4.3.1 Các kiểu dữ liệu phức hợp định nghĩa sẵn ..............................................16
1.4.3.2 Kiểu kế thừa ............................................................................................17
1.4.3.3 Kiểu đối tượng (Object Type) .................................................................17
1.4.3.4 Tạo bảng đối tượng .................................................................................17
1.4.3.5 Bảng lồng nhau (Nested table) ................................................................18

1.4.3.6 Kiểu mảng ...............................................................................................18
1.4.3.7 Kiểu tham chiếu ......................................................................................18
1.4.4 Một số hệ quản trị quan hệ đối tượng ORDBMS thường dùng ....................18
1.4.5 Ưu điểm mô hình dữ liệu quan hệ hướng đối tượng (ORDBMS) .................18
1.4.6 Nhược điểm mô hình ORDBMS ...................................................................18
1.5 Lý thuyết về cơ sở dữ liệu NoSQL ......................................................................19
1.5.1 Giới thiệu ..........................................................................................................19
1.5.1.1 Sơ lược về NoSQL ..................................................................................19
1.5.1.2 Phân loại NoSQL ....................................................................................19
1.5.2 Cơ sở dữ liệu MongoDB ...............................................................................19
1.5.3 Mô hình dữ liệu trong MongoDB ..................................................................21
1.5.3.1 Phép tham chiếu Reference .....................................................................21
1.5.3.2 Phép nhúng Embedded documents .........................................................21
1.6 Các thao tác cơ bản trong Mongodb ....................................................................22
1.6.1 Thao tác với Database (Cơ sở dữ liệu) ..........................................................22
1


1.6.1.1 Tạo mới Database (Cơ sở dữ liệu) ..........................................................22
1.6.1.2 Lệnh xóa dữ liệu ......................................................................................22
1.6.2 Thao tác với Collection .................................................................................22
1.6.2.1 Lệnh tạo Collection .................................................................................22
1.6.2.2 Lệnh xóa Collection ................................................................................22
1.6.3 Thao tác với Document .................................................................................22
1.6.3.1 Chèn Document .......................................................................................22
1.6.3.2 Truy vấn Document .................................................................................22
1.6.3.3 Cập nhật Document .................................................................................22
1.6.3.4 Xóa Document.........................................................................................22
Chương 2 CHUYỂN ĐỔI MÔ HÌNH CƠ SỞ DỮ LIỆU QUAN HỆ VÀ ĐỐI
TƯỢNG SANG NoSQL ............................................................................................23

2.1 Lập kế hoạch ........................................................................................................23
2.2 Mục tiêu chuyển đổi .............................................................................................23
2.3 Thiết kế lược đồ ...................................................................................................23
2.4 Chọn lựa mô hình dữ liệu MongoDB ..................................................................24
2.5 Phương pháp chuyển đổi mô hình .......................................................................24
2.5.1 Phương pháp chuyển đổi mô hình dữ liệu quan hệ sang NoSQL .................24
2.5.1.1 Kỹ thuật chuyển đổi ................................................................................25
2.5.1.2 Phân tích dữ liệu và mối quan hệ lược đồ ...............................................25
2.5.1.3 Thiết kế lược đồ MongoDB ....................................................................27
2.5.1.4 Quá trình chuyển đổi dữ liệu ...................................................................29
2.5.2 Phương pháp chuyển đổi từ mô hình đối tượng sang NoSQL ......................30
2.5.2.1 Kỹ Thuật chuyển đổi ...............................................................................30
2.5.2.2 Phân tích dữ liệu đối tượng và lược đồ TPC-H.......................................30
2.5.2.3 Quá trình chuyển đổi mô hình .................................................................30
Chương 3 CÀI ĐẶT VÀ ĐÁNH GIÁ .......................................................................34
3.1 Bộ dữ liệu .............................................................................................................34
3.2 Môi trường thực nghiệm ......................................................................................34
3.3 Công cụ chuyển đổi dữ liệu .................................................................................34
3.4 Đánh giá ...............................................................................................................35
3.4.1 Đánh giá mô hình trước và sau khi chuyển đổi .............................................35
3.4.1.1 Đánh giá kết quả đạt được ở mô hình NoSQL ........................................35
3.4.1.2 Đánh giá dung lượng của hai bộ dữ liệu .................................................37
3.4.2 Đánh giá hiệu suất thực hiện .........................................................................39
3.4.3 Đánh giá về hai phương pháp thực hiện chuyển đổi .....................................45
Chương 4 KẾT LUẬN VÀ KHUYẾN NGHỊ ...........................................................47
TÀI LIỆU THAM KHẢO..........................................................................................50
PHỤ LỤC ...................................................................................................................52

2

DANH MỤC CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT
ACID

Atomic, Consistent, Independent, and Durable

BSON

Binary JavaScript Object Notation

ETL

Extract Transform Load

JSON

JavaScript Object Notation

NoSQL

Not Only SQL

TPC

Transaction Processing Performance Council

TPC-H

TPC Benchmark™H

DBLP

Digital Bibliography & Library Project

RDBMS

Relational Database Management System

RDB

Relational Database

ODBMS

Object Database Management System

ORDBMS

Object Relation Database Management System

ORM

Object Relation Mapping

JPA

Java Persistence API

API

Application Programming Interface

3


DANH MỤC CÁC BẢNG
Bảng 1.1 Kiểu dữ liệu phức hợp ................................................................................16
Bảng 2.1 Ánh xạ giữa cơ sở dữ liệu quan hệ và MongoDB ......................................24
Bảng 3.1 Bảng dữ liệu TPCH của SQL Server và MongoDB ...................................37
Bảng 3.2 Bảng dữ liệu DBLP của SQL Server và MongoDB ...................................38
Bảng 3.3 Thời gian chạy 100 Records .......................................................................41
Bảng 3.4 Thời gian chạy 1.000 Records ....................................................................41
Bảng 3.5 Thời gian chạy 10.000 Records ..................................................................42
Bảng 3.6 Thời gian chạy 100.000 Records ................................................................42
Bảng 3. 7 Đánh giá thời gian INSERT dữ liệu của SQL Server và MongoDB .........43
Bảng 3.8 Đánh giá thời gian SELECT dữ liệu của SQL Server và MongoDB .........43
Bảng 3. 9 Đánh giá thời gian UPDATE dữ liệu của SQL Server và MongoDB .......44

4


DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ
Hình 1.1 Minh họa dữ liệu hướng đối tượng .............................................................13
Hình 1.2 Minh họa Class Diagram.............................................................................15
Hình 1.3 Mô hình cơ sở dữ liệu hướng đối tượng .....................................................16
Hình 1.4 Collection của MongoDB ...........................................................................20
Hình 1.5 Document trong MongoDB ........................................................................20
Hình 1.6 Ví dụ cấu trúc tham chiếu văn bản.............................................................21
Hình 1.7 Ví dụ về Embeded documents ....................................................................21
Hình 2.1 Minh họa chuyển cấu trúc dữ liệu quan hệ sang MongoDB......................24

Hình 2.2 Minh họa dữ liệu một bảng chuyển qua MongoDB ..................................25
Hình 2.3 Lược đồ cơ sở dữ liệu quan hệ DBLP.........................................................26
Hình 2.4 Lược đồ cơ sở dữ liệu quan hệ TPC-H .......................................................27
Hình 2.5 Lược đồ cơ sở dữ liệu DBLP trong MongoDB ..........................................28
Hình 2.6 Lược đồ cơ sở dữ liệu TPC-H trong MongoDB .........................................28
Hình 2.7 Sơ đồ hệ thống chuyển đổi dữ liệu quan hệ sang NoSQL ..........................29
Hình 2.8 Minh họa chuyển đổi đối tượng sang NoSQL ............................................30
Hình 2.9 Lược đồ của mô hình đối tượng TPC-H .....................................................30
Hình 2.10 Minh họa tính kế thừa của mô hình đối tượng TPC-H .............................31
Hình 2.11 Minh họa tính đa hình trong mô hình đối tượng TPC-H ..........................31
Hình 2.12 Minh họa tính đa hình trong mô hình đối tượng TPC-H ..........................32
Hình 2.13 Minh họa tính bao đóng trong mô hình đối tượng TPC-H .......................32
Hình 2.14 Sơ đồ hệ thống chuyển đổi đối tượng sang NoSQL .................................33
Hình 3.1 Giao diện chuyển đổi mô hình. ..................................................................34
Hình 3.2 Dữ liệu DBLP ở SQL Server ......................................................................35
Hình 3.3 Giao diện RoboMongo ban đầu ..................................................................35
Hình 3.4 Dữ liệu DBLP đã được chuyển qua NoSQL .............................................36
Hình 3.5 Kiểm tra tổng số dòng của t Book_DBLP trong MongoDB(NoSQL) ......36
Hình 3.6 Kết quả đạt được trong NoSQL ..................................................................37
Hình 3.7 Lược đồ Mô hình đối tượng MongoSqlTest ...............................................40
Hình 3.8 Giao diện so sánh hiệu năng .......................................................................40
Hình 3.9 Kết quả được thực hiện với 100 Records ...................................................41
Hình 3.10 Thời gian INSERT của SQL Server và MongoDB ..................................43
Hình 3.11 Thời gian SELECT của SQL Server và MongoDB ..................................44
Hình 3.12 Thời gian Update của SQL Server và MongoDB .....................................45

5


MỞ ĐẦU

Cơ sở dữ liệu là một phần không thể thiếu trong các công ty, tổ chức, doanh nghiệp.
Khi số lượng khách hàng ngày càng lớn cùng với các giao dịch diễn ra hàng ngày
tăng theo thì hiệu suất thực hiện, số lượng truy cập dữ liệu, cũng như những đòi hỏi
ngày càng cao của khách hàng là bài toán mà các doanh nghiệp cần có những giải
pháp thực hiện tối ưu nhằm mang lại hiệu quả trong kinh doanh.
Mô hình cơ sở dữ liệu quan hệ thể hiện ưu điểm nổi trội về tính ràng buộc và toàn
vẹn dữ liệu. Tuy nhiên khi lượng dữ liệu lớn, cập nhật liên tục, tính đa dạng cao, cấu
trúc dữ liệu, mối quan hệ dữ liệu phức tạp thì mô hình này đứng trước những khó
khăn và thách thức về hiệu suất thực hiện. Mô hình dữ liệu quan hệ hướng đối tượng
là một cuộc cách mạng cải tiến phần mềm với thiết kế dễ dàng, dễ mở rộng dự án
và khả năng tái sử dụng. Nhưng cũng hạn chế về mặt hiệu suất khi phân chia các đối
tượng quá phức tạp xuống các bảng dữ liệu quan hệ.
Chính những nhược điểm của mô hình dữ liệu quan hệ và mô hình đối tượng mà
NoSQL ra đời. NoSQL có khả năng lưu trữ dữ liệu lớn, khả năng phân tán cũng như
dễ phân vùng dữ liệu, truy vấn dữ liệu nhanh nhờ thực hiện các công việc song song,
tăng khả năng chịu lỗi, hiệu suất cao mà ít đòi hỏi về phần cứng cũng như tài nguyên
hệ thống. NoSQL áp dụng nhiều ở trong các công ty lớn.
NoSQL ra đời không phải để thay thế và loại bỏ hoàn toàn các mô hình trước đây,
mà nó ra đời để bổ sung và khắc phục những nhược điểm mà mô hình trước đó chưa
thể làm được. NoSQL đã giải quyết được bài toán về dữ liệu lớn, về khả năng lưu
trữ dữ liệu và khả năng cải thiện hiệu suất cao hơn mô hình trước. Với cơ sở dữ liệu
mã nguồn mở, có khả năng mở rộng theo chiều ngang, chi phí thấp, tốc độ truy cập
nhanh chóng và tức thời, NoSQL là một sự lựa chọn đến với nhu cầu người dùng
hiện nay. Vì vậy tôi đã chọn thực hiện đề tài “Chuyển đổi mô hình dữ liệu quan hệ
và đối tượng sang NoSQL”
Mỗi mô hình có những ưu điểm cũng như lợi thế riêng. Việc chuyển đổi mô hình dữ
liệu quan hệ và đối tượng sang NoSQL được thực hiện tùy thuộc vào nhu cầu thực
tế. Cụ thể trong trường hợp người dùng có nhu cầu về đồng bộ hóa dữ liệu để cải
6

thiện hiệu suất cho một hệ thống dữ liệu phát triển lâu năm. Hoặc khi nhu cầu của
các doanh nghiệp về việc cần phân tích, thống kê, truy vấn, tìm kiếm dữ liệu lớn và
phức tạp thì NoSQL là một sự cân nhắc cũng như một lựa chọn dành cho người dùng
bởi khả năng mở rộng theo chiều ngang, truy vấn nhanh cùng với tính sẵn sàng cao.
Song song đó, trong thực tế có một số trường hợp, các ứng dụng yêu cầu cao về tính
toàn vẹn dữ liệu, độ tin cậy, độ an toàn như các giao dịch tài chính, ngân hàng, chứng
khoán, kinh doanh và sản xuất các lĩnh vực thì mô hình dữ liệu quan hệ và đối tượng
là một sự lựa chọn hoàn hảo bởi nó có tính chặt chẽ và ràng buộc cao.
Nội dung đề tài thực hiện hai công việc chính: chuyển đổi mô hình dữ liệu quan hệ
sang NoSQL và chuyển đổi mô hình đối tượng sang NoSQL. Tuy nhiên, việc chuyển
đổi mô hình dữ liệu quan hệ sang NoSQL đã được thực hiện trước đó [1], nên sẽ
được nhắc lại và tập trung chủ yếu vào chuyển đổi mô hình đối tượng sang NoSQL.
Mục tiêu của việc chuyển đổi mô hình dữ liệu quan hệ và đối tượng sang NoSQL
nhằm thực hiện kiểm tra, đánh giá và đưa ra kết luận về tính khả thi của mô hình
trước và sau khi chuyển đổi. Từ đó, tùy vào hoàn cảnh, thời điểm mà lựa chọn mô
hình phát triển cho phù hợp, nâng cao hiệu suất thực hiện cho hệ thống, đảm bảo
tiến trình nhanh và hiệu quả, đáp ứng được nhu cầu thực tiễn đặt ra.
Luận văn này sử dụng bộ dữ liệu mẫu TPC-H1 và DBLP2 để thực nghiệm cùng với
sự hỗ trợ công nghệ .NET C# và một số driver hỗ trợ tương tác giữa C# và NoSQL.
Luận văn được trình bày thành 4 chương:
Chương 1: Lý thuyết và các nghiên cứu liên quan
Chương 2: Chuyển đổi mô hình dữ liệu quan hệ và đối tượng sang NoSQL
Chương 3: Cài đặt và đánh giá
Chương 4: Kết luận và hướng phát triển

1
2

/> />

7


Chương 1 Lý thuyết và các nghiên cứu liên quan

Chương 1 Lý Thuyết và các nghiên cứu liên quan
1.1 Tổng quan tình hình nghiên cứu
1.1.1 Tình hình nghiên cứu về chuyển đổi mô hình dữ liệu quan hệ
sang NoSQL
Bigdata (dữ liệu lớn) hiện nay vẫn còn là một trong những đề tài đang được các
nhà nghiên cứu dữ liệu tìm hiểu và đưa ra những giải pháp tối ưu. Chen và Zhang
đã thảo luận và đưa ra những quan điểm khác nhau về các ứng dụng của Big Data.
Tác giả đưa ra cơ hội cùng những thách thức, cũng như các kỹ thuật hiện đại và
công nghệ hiện nay đang áp dụng để giải quyết với các vấn đề về Big Data [4].
Roijackers [12] đề xuất một cách tiếp cận lớp trung gian trừu tượng trên hai cơ sở
dữ liệu để giảm khoảng cách SQL và NoSQL, mang chúng đến gần nhau hơn.
Mặc dù người dùng có thể hiểu và sử dụng hệ thống truy vấn đơn giản, nhưng
hiệu suất không cao vì việc truy vấn dữ liệu lồng nhau phức tạp.
Lee, Chao-Hsien, và Yu-Lin Zheng [7] đề xuất một cơ chế tự động chuyển đổi
lược đồ từ SQL sang NoSQL thông qua cơ sở dữ liệu MySQL và Hbase. Dựa trên
kết quả thử nghiệm, tác giả đã chứng minh được đề xuất này có thể cải thiện hiệu
suất truy cập khoảng 47%. Tác giả Tianyu Jia và cộng sự của ông đã đề xuất cách
tiếp cận mô hình chuyển đổi và di chuyển dữ liệu từ cơ sở dữ liệu quan hệ sang
MongoDB [6], từ thuật toán đề xuất, chứng chứng minh được NoSQL đạt hiệu
suất tốt hơn so với cơ sở dữ liệu quan hệ.

1.1.2 Tình hình nghiên cứu về chuyển đổi mô hình đối tượng sang
NoSQL
Bên cạnh các công trình nghiên cứu về chuyển đổi cơ sở dữ liệu sang NoSQL với
nhiều phương pháp khác nhau như đã dẫn chứng, còn rất nhiều công trình khác

cũng đã nghiên cứu và thực hiện đánh giá về chuyển đổi mô hình cơ sở dữ liệu
đối tượng sang NoSQL (Object-NoSQL).
Wolf cùng cộng sự của ông [15] đã thảo luận và phân tích về vấn đề mở rộng
Hibernate, một framework của ORM [10] để hỗ trợ cho RIAK, một kho lưu trữ
dữ liệu khóa/giá trị(key/value) của NoSQL. Wolf chỉ ra rằng việc tích hợp RIAK
8


Chương 1 Lý thuyết và các nghiên cứu liên quan

vào trong Hibernate là có thể nhưng phải chỉnh sửa trong phần lõi Hibernate. Thay
vì buộc một ánh xạ quan hệ với RIAK, Wolf chọn một mô hình lưu trữ gần với
mô hình dữ liệu hướng đối tượng theo cách mà các mối liên kết được lưu trữ với
các đối tượng và không tách rời chúng. Wolf đã đánh giá và so sánh giữa hiệu
suất RIAK và hiệu suất của Hibernate-ORM (đã được cấu hình với MySQL), cung
cấp kỹ thuật để tích hợp giữa NoSQL vào ORM framework. Wolf đã thực hiện
các bước tích hợp kho giá trị/khóa của RIAK vào trong Hibernate, tránh ánh xạ
trung gian tới mô hình quan hệ. Đã thực hiện được một tập hợp các tính năng của
Hibernate bao gồm lưu trữ, cập nhật và xóa cũng như hỗ trợ trong ngôn ngữ truy
vấn Hibernate HQL (Hibernate Query language). Mặc dù, RIAK giới thiệu một
số chi phí ảnh hưởng đến hiệu suất, nhưng kết quả thực nghiệm cho thấy Hibernate
mang lại lợi ích từ việc phân tán và khả năng mở rộng của RIAK. Đây là trường
hợp đặc biệt trong các tình huống mà hệ thống tải về với kích thước dữ liệu, số
lượng đối tượng và số lượng yêu cầu đồng thời tăng lên rất nhiều. Một hạn chế ở
bài báo này được tác giả nêu ra, đó là việc khai thác tất cả các tính năng của
Hibernate kết hợp với RIAK đòi hỏi cần phải chỉnh sửa đáng kể trong framework
Hibernate. Đặc biệt, hỗ trợ đầy đủ ngôn ngữ truy vấn HQL trên RIAK là một
nhiệm vụ đầy thách thức. Bên cạnh đó, trong việc xây dựng hỗ trợ của MapReduce
không tăng thêm tốc độ như mong đợi đặt ra.
Störl và cộng sự [13] đưa ra một cái nhìn khái quát cũng như chỉ ra cách ánh xạ

giữa Object và NoSQL (Object-NoSQL Mappers -ONMs) với ngôn ngữ sử dụng
là Java ONMs và các các thư viện rất nổi bật (EclipseLink, DataNucleus,
Hibernate OGM, Kundera, Morphia). Störl đã phân tích và đánh giá tính CRUD
(create - tạo mới, read – đọc, update- cập nhật, delete- xóa) của các thư viện
ONMs. ONMs có khả năng cung cấp ngôn ngữ truy vấn độc lập và mạnh mẽ hơn,
hỗ trợ MapReduce và hỗ trợ cải tiến cho việc chuyển đổi dữ liệu. ONMs định
nghĩa lược đồ ngầm, hỗ trợ một số hoạt động phát triển lược đồ như thêm và xóa
thuộc tính hoặc mối quan hệ. Tuy nhiên bài báo này do không trực tiếp định lượng
chi phí, làm cho việc so sánh trở nên khó khăn. Các ngôn ngữ truy vấn được hỗ
trợ từ NoSQL thường có sự khác biệt lớn trong cách thể hiện của chúng. Các toán
tử truy vấn được hỗ trợ thường phụ thuộc vào khả năng của các kho dữ liệu
9


Chương 1 Lý thuyết và các nghiên cứu liên quan

NoSQL bên dưới. Störl và cộng sự của ông đã không tính tới một số trường hợp
đặc biệt nên khi thử nghiệm thực thi chương trình mà các toán tử truy vấn vẫn
chưa được thực thi, một số toán tử truy vấn không được thực thi với ngữ nghĩa
được mô tả trong tài liệu. Các thí nghiệm của cho thấy rằng trong việc đọc dữ liệu
từ các thư viện của ONMs được so sánh không chênh lệch nhiều. Tuy nhiên, hiệu
suất ghi của ánh xạ đối tượng NoSQL có chi phí đáng kể. Và khi một số hoạt động
phát triển lược đồ được áp dụng, các nhà phát triển cần phải sử dụng mã tùy chỉnh.
Mặc dù có nhiều khuyết điểm nhưng ONMs là giải pháp giải cứu cho nhiều nhà
phát triển ứng dụng đang loay hoay, những nhà phát triển đang gặp khó khăn với
các kho dữ liệu NoSQL và các thư viện độc quyền.
Một nghiên cứu khác về Object-NoSQL Mappers của nhóm tác giả Reniers [10]
cũng được thực hiện bởi việc tạo ra chuẩn định lượng và so sánh hiệu suất hoạt
động của Object-NoSQL Mappers (ONMD) với việc tạo dữ liệu, đọc dữ liệu, cập
nhật và tìm kiếm dữ liệu. Năm trong số các ONDM có triển vọng nhất và sẵn sàng

đó là Impetus Kundera, Apache Gora, EclipseLink, DataNucleus và Hibernate
OGM và được thực hiện trên cả một nút đơn và thiết lập cluster 9-node. Chuẩn
benchmark được thực hiện trên Yahoo! Cloudcheck Service Benchmark (YCSB),
YCSB cung cấp một số cơ sở để đo chính xác và kiểm soát việc thực hiện chuẩn
của khối lượng công việc khác nhau trên nền tảng NoSQL. Reniers đặt ra năm câu
hỏi và thực nghiệm để kết luận các vấn đề liên quan đến hiệu suất trong triển khai
cũng như truy vấn tìm kiếm JPQL, hoạt động đọc JPA, sự phát triển của API và
chi phí (tuyệt đối và tương đối) của hoạt động ghi, đọc và cập nhật trong ONDM.
Tiếp theo Reniers bàn về các quyết định thiết kế chính liên quan đến việc cài đặt
nghiên cứu benchmark, mô tả về kiến trúc tổng thể của một framework ONDM,
phương pháp đo lường chi phí hiệu suất. Qua thực nghiệm, Reniers kết luận được
chi phí trên rất đáng kể đối với hoạt động của cơ sở dữ liệu trong bộ nhớ, tuy
nhiên các hoạt động trên đĩa và độ trễ cao dẫn đến chi phí không đáng kể, chi phí
cho hiệu năng tìm kiếm tăng lên theo tuyến tính với số kết quả, chi phí tìm kiếm
của DataNucleus và Hibernate OGM là đặc biệt cao so với các ONDM khác. Tuy
nhiên, một nhược điểm kể đến là sự không trùng khớp nhau giữa các APIs có thể
dẫn đến khả năng mất các thuộc tính đặc biệt trong NoSQL. ONDM cho phép tạo
10


Chương 1 Lý thuyết và các nghiên cứu liên quan

ra các công nghệ lưu trữ không đồng nhất bằng cách tạo ra mã nguồn độc lập với
các API của client NoSQL cụ thể và cho phép các ứng dụng tương đối dễ dàng
với các công nghệ lưu trữ khác nhau. Ngoài ra, chúng còn là những yếu tố then
chốt cho các xu hướng mới như hệ thống lưu trữ liên kết, trong đó tầng lưu trữ
của ứng dụng bao gồm các công nghệ lưu trữ không đồng nhất khác nhau, thậm
chí có khả năng lưu trữ bởi các nhà cung cấp khác nhau. Các tiêu chí đánh giá
hiệu suất được trình bày trong bài báo này đã định lượng được chi phí theo chuẩn
benchmarks của NoSQL (YCSB), đặc biệt cho việc tạo, đọc và cập nhật, và đáng

chú ý là các hoạt động tìm kiếm. Bên cạnh đó, Reniers thấy được tác động của
một số khía cạnh lên chi phí như cài đặt triển khai kiến trúc lưu trữ, số lượng các
hoạt động có liên quan và tác động của các API phát triển về hiệu suất. Các kết
quả thu được trong nghiên cứu này cho thấy tiềm năng áp dụng công nghệ ONDM
về chi phí liên quan đến các hệ thống và cung cấp chỉ số về sự trưởng thành của
các công nghệ này. Đặc biệt là trong lĩnh vực tìm kiếm, Reniers quan sát thấy sự
khác biệt lớn giữa các ONDMs về hiệu suất hoạt động.
Bugiotti, Francesca, và Luca Cabibbo [2] đề xuất ONDM (Object-NoSQL
Datastore Mapper) hỗ trợ thiết kế cơ sở dữ liệu NoSQL, một framework hỗ trợ
quản lí của các đối tượng ổn định trong kho dữ liệu NoSQL, cung cấp cho các nhà
phát triển ứng dụng với một giao diện lập trình thống nhất, cũng như khả năng
ánh xạ dữ liệu ứng dụng cho việc biễu diễn dữ liệu khác nhau một cách linh hoạt.
ONDM cung cấp cho các nhà phát triển ứng dụng một API hướng đối tượng mà
mô hình dữ liệu của nó dựa trên các thực thể, các đối tượng giá trị, các mối quan
hệ, và tập hợp. Bằng cách áp dụng tiêu chuẩn này, rất dễ di chuyển các ứng dụng
JPA vào NoSQL. Bugiotti cùng đồng sự của ông tin rằng các tính năng này là cần
thiết để hỗ trợ thiết kế cơ sở dữ liệu NoSQL trong các ứng dụng của các thế hệ
web tiếp theo. Bugiotti dùng NoAM, một cách tiếp cận hệ thống độc lập cho thiết
kế cơ sở dữ liệu NoSQL. Phương pháp này với đầu vào (input) là một tập dữ liệu
ứng dụng của các đối tượng tổng hợp, ánh xạ nó đến lớp trung gian (Intermediate
Representation) trong một mô hình dữ liệu trừu tượng, và sau đó thực hiện nó theo
các cấu trúc dữ liệu của hệ thống NoSQL đích. Để hỗ trợ linh hoạt, ONDM sử
dụng ngôn ngữ mô tả biểu diễn dữ liệu (Data Representations Language) được đề
11


Chương 1 Lý thuyết và các nghiên cứu liên quan

xuất trong NoAM (NoSQL Abstract Model-mô hình trừu tượng NoSQL [17]).
ONDM diễn giải các khai báo và sử dụng chúng để ánh xạ đối tượng và các hoạt

động CRUD qua cấu trúc dữ liệu và truy cập dữ liệu vào hệ thống NoSQL theo
như mô tả của data representations. Một ưu điểm nữa của ONDM ở đây là giúp
các nhà phát triển biểu diễn dữ liệu cụ thể có thể lựa chọn một hệ thống mục tiêu
khác nhau hoặc biểu diễn dữ liệu khác nhau bằng cách chỉ cần thay đổi khai báo
đó, và không có sự thay đổi khác trong mã ứng dụng được yêu cầu. Một Prototype
(mẫu) đơn giản đầu tiên của ONDM đã được thực hiện, nó cung cấp khả năng tiếp
cận trong suốt đối với một số ít các kho dữ liệu NoSQL. Tuy nhiên Prototype này
vẫn chưa thực hiện các ngôn ngữ NoAM như mô tả trong bài báo.
Ở Việt Nam, có rất nhiều bài báo và công trình nghiên cứu về NoSQL. Hiện nay,
nhiều công ty, tập đoàn lớn cũng đã nghiên cứu và dần dần áp dụng việc chuyển
đổi mô hình cơ sở dữ liệu quan hệ sang NoSQL để đáp ứng nghiệp vụ của dự án
thực tế.
Hội thảo Quốc gia lần thứ XVIII năm 2015 với chủ đề “Một số vấn đề chọn lọc
của Công nghệ thông tin và truyền thông”. Bài báo với chủ để “Chuyển đổi lược
đồ cơ sở dữ liệu SQL Server sang MongoDB” [1] đã được báo cáo. Bài báo đề
cập đến việc triển khai một hệ thống NoSQL trên mô hình phân tán bằng phương
pháp Sharding (mảnh lưu trữ). Ngoài ra, bài báo đã xây dựng được ứng dụng và
đánh giá hiệu suất khi chuyển đổi lược đồ SQL Server sang MongoDB.

1.2 Mục tiêu, phương pháp nghiên cứu
Mục tiêu nghiên cứu đề tài là thực hiện thành công việc mô tả, thiết kế cơ sở dữ
liệu, cài đặt ứng dụng, đánh giá hiệu suất đạt được của từng mô hình, phân tích,
đánh giá được từng mô hình trước và sau khi chuyển đổi để thấy rõ được những
ưu điểm và nhược điểm của nó. Từ đó, lựa chọn mô hình phù hợp với tình hình
thực tế.
Phương pháp nghiên cứu: Tìm hiểu csdl NoSQL, MongoDB, dữ liệu TPC-H và
DBLP. Tham khảo các bài báo uy tín và tin cậy. Dựa vào kết quả đạt được, phân
tích, so sánh, rút ra các bài học kinh nghiệm; đề xuất các hướng phát triển.
Hiện nay có rất nhiều phương pháp chuyển đổi mô hình. Việc lựa chọn phương
12

Chương 1 Lý thuyết và các nghiên cứu liên quan

pháp dựa vào nghiệp vụ của từng dự án thực tế. Đề tài này, chúng tôi đề xuất hai
phương pháp thực hiện chuyển đổi:
Phương pháp thứ nhất:
❖ Chuyển đổi một bảng (hoặc nhiều bảng) của mô hình cơ sở dữ liệu quan
hệ sang thành một collection (hoặc nhiều collection) trong NoSQL.
❖ Chuyển đổi một đối tượng (hay nhiều đối tượng) của mô hình hướng
đối tượng sang thành một collection (hay nhiều Collection) trong
NoSQL.
Phương pháp thứ 2:
❖ Gom các đối tượng có mối quan hệ cha con với nhau trong mô hình dữ
liệu hướng đối tượng, sau đó thực hiện chuyển đổi sang thành một
collection của NoSQL có đầy đủ thông tin dữ liệu cũng như mối quan hệ
của các đối tượng được chuyển qua (Theo mô hình Embeded Document
của NoSQL).
1.3 Lý thuyết về mô hình dữ liệu hướng đối tượng

1.3.1 Cái khái niệm
1.3.1.1 Đối tượng và lớp
Mỗi đối tượng là một khái niệm về một thực thể nào đó hoặc là một sự trừu
tượng hóa được định nghĩa một cách minh bách và được đặc trưng bởi một
tên duy nhất.
Lớp là sự mô tả của một nhóm các đối tượng có chung các thuộc tính,
phương thức, các mối quan hệ...

Hình 1.1 Minh họa dữ liệu hướng đối tượng

1.3.1.2 Cơ sơ dữ liệu hướng đối tượng
13


Chương 1 Lý thuyết và các nghiên cứu liên quan

Cơ sở dữ liệu hướng đối tượng (Object- Oriented Database Management
System - viết tắc OODBMS hoặc ODBMS) là hệ thống hỗ trợ cho quá trình
mô hình hóa và quản lí dữ liệu dưới dạng đối tượng. ODBMS bao gồm một
số loại hỗ trợ cho các lớp của các đối tượng và sự kế thừa các thuộc tính
và phương thức của các lớp con và đối tượng của chúng. Trong ODBMS,
ngôn ngữ được sử dụng cho việc chỉnh sửa, thêm bớt các đối tượng là C++,
Java thay vì dùng truy vấn ngôn ngữ SQL như trong cơ sở dữ liệu quan hệ.
Phương pháp cơ bản được sử dụng để lưu trữ các đối tượng đó là sử dụng
một ID duy nhất và sự kế thừa để xác định các thuộc tính, ngoài ra việc lưu
trữ và quản lý đối tượng còn sử dụng ánh xạ bộ nhớ ảo.

1.3.2 Mô hình dữ liệu hướng đối tượng
Mô hình dữ liệu đối tượng có các đặc tính của lập trình hướng đối tượng:
như tính bao đóng, kế thừa, đa hình.

1.3.2.1 Tính bao đóng
Tính chất này thể hiện tính toàn vẹn dữ liệu, sự ràng buộc với nhau cả về
thuộc tính lẫn phương thức trong cùng một lớp. Cụ thể chỉ có các phương
thức bên trong lớp của đối tượng mới được phép thay đổi trạng thái của nó.
Hoặc nếu muốn thay đổi bên trong đối tượng thì phải được sự chấp nhận
của đối tượng đó thông qua Private, Protected và Public.Tính bao đóng
không cho phép các đối tượng bên ngoài thay đổi trạng thái bên trong của
một đối tượng.

1.3.2.2 Kế thừa
Là cơ chế mà các lớp con kế thừa các thuộc tính cũng như phương thức từ
các lớp cha với điều kiện phải được lớp cha cho phép. Bên cạnh đó, lớp
con cũng có thể thêm các thuộc tính và phương thức riêng của nó và có thể
sửa đổi bất kỳ phương thức từ lớp cha. Các loại kế thừa thường gặp như
đơn kế thừa (một lớp con chỉ kế thừa từ một lớp cha), đa kế thừa (kế thừa
nhiều lớp).

1.3.2.3 Tính đa hình
Đa hình cho phép các đối tượng cùng tên phương thức nhưng ý nghĩa và
sử dụng khác nhau thể hiện qua các lớp phải có quan hệ kế thừa với lớp
14


Chương 1 Lý thuyết và các nghiên cứu liên quan

cha. Tính chất này dễ quản lý các đối tượng bởi việc sử dụng tính kế thừa
và định nghĩa các hàm ảo. Ngoài ra, tính chất này còn thể hiện tính đa hình
ở chỗ các phương thức phải được ghi đè (Override) ở các lớp con.

1.3.2.4 Class Diagram
Class Diagram (sơ đồ lớp) của cơ sở dữ liệu đối tượng được biểu diễn nhằm
để mô tả, biễu diễn cấu trúc của các lớp, đối tượng và mối quan hệ giữa
chúng.

Hình 1.2 Minh họa Class Diagram

1.3.3 Ưu điểm và nhược điểm của OODBMS
OODBMS có khả năng tái sử dụng, mang tính ổn định và tin cậy, hỗ trợ cho
sự phát triển lược đồ, cải thiện hiệu suất, các kiểu dữ liệu của dữ liệu hướng

đối tượng có thể mở rộng để hỗ trợ các kiểu dữ liệu phức tạp như đa phương
tiện, kỹ thuật số... Tuy nhiên, OODBMS vẫn tồn tại những khuyết điểm về
ràng buộc, sự phức tạp của các đối tượng. Việc thiết kế OODBMS phù hợp
với việc thiết kế ứng dụng hơn.

1.4 Lý thuyết về mô hình dữ liệu quan hệ đối tượng
1.4.1 Giới thiệu
Mô hình dữ liệu quan hệ hướng đối tượng (Object Relational Model viết
tắt ORDBMS [5] ra đời nhằm khắc phục những yếu kém của mô hình dữ
liệu đối tượng OODBMS.
Là mô hình cơ sở dữ liệu mở rộng mô hình quan hệ với mô hình đối tượng
có các khái niệm hướng đối tượng như: lớp, sự thừa kế, và những phương
15


Chương 1 Lý thuyết và các nghiên cứu liên quan

thức. Dữ liệu quan hệ hướng đối tượng (ORDBMS) có thể làm việc tốt và
tương thích với ngôn ngữ của cơ sở dữ liệu quan hệ, quản lý các kiểu dữ
liệu đa phương tiện cũng như cho phép các thuộc tính của dòng có các kiểu
dữ liệu phức tạp, khả năng tái sử dụng và khả năng ánh xạ đối tượng vào
dữ liệu quan hệ một cách dễ dàng.

Hình 1.3 Mô hình cơ sở dữ liệu hướng đối tượng

1.4.2 Tính năng của mô hình ORDBMS:
Giải quyết được sự phức tạp của mô hình lồng ghép đối tượng là đặc trưng
cơ bản của ORDBMS, thể hiện trong thiết kế và xây dựng các đối tượng,
các tài liệu đa phương tiện. Ngoài ra, ORDBMS còn hỗ trợ cho các loại
dữ liệu dùng chung, hỗ trợ thường xuyên và hữu ích cho các khái niệm

hướng đối tượng như là đối tượng, lớp, thừa kế, mối quan hệ đối tượng.

1.4.3 Kiểu dữ liệu của quan hệ - đối tượng ORDBMS
1.4.3.1 Các kiểu dữ liệu phức hợp định nghĩa sẵn
Bảng 1.1 Kiểu dữ liệu phức hợp
Kiểu dữ liệu phức hợp định

Ý nghĩa

nghĩa sẵn
Đối tượng lớn dạng nhị phân không

Binary Large Object - BLOB

có cấu trúc trong cơ sở dữ liệu. Khả
năng lưu được 4GB dữ liệu
Đối tượng lớn dạng ký tự

Character Large Object - CLOB

16


Chương 1 Lý thuyết và các nghiên cứu liên quan

Fixed - Width Multibyte

Đối tượng lớn dạng kí tự có chiều dài

Character Large Object-

cố định.

NCLOB
Binary Large File Object -

Đối tượng lớn dạng lưu trữ dữ liệu

BFILE

nhị phân không có cấu trúc trong các
tập tin.

1.4.3.2 Kiểu kế thừa
Có 2 loại:
▪ Kế thừa kiểu Type (Inheritance of Types)
▪ Kế thừa bảng (Inheritance of tables)

1.4.3.3 Kiểu đối tượng (Object Type)
Kiểu đối tượng là một khái niệm chỉ về khả năng tác động lên dữ liệu thông
qua các phương thức được xây dựng.
Cấu trúc của kiểu đối tượng bao gồm hai phần: phần đặc tả (Specification)
và phần thân (Body).
Thuộc tính Kiểu dữ liệu của thuộc tính có thể là kiểu dữ vô hướng định
nghĩa sẵn hoặc kiểu mảng hoặc bảng lồng ghép, tham chiếu, kiểu đối tượng
lồng nhau
Phương thức (hàm và thủ tục) dùng cho việc xử lý dữ liệu. Phương thức
định nghĩa cho đối tượng có thể là:
▪ Hàm (Function) và thủ tục (Procedure)
▪ Phương thức ánh xạ (Map Method)

▪ Phương thức khởi tạo (Constructor Method)

1.4.3.4 Tạo bảng đối tượng
Lệnh tạo bảng: CREATE TABLE.
Lệnh chèn thêm, cập nhật, xóa hay truy vấn đối tượng bằng câu lệnh SQL:
INSERT, UPDATE, DELETE, SELECT...
Bảng đối tượng có thể có dạng: Bảng dữ liệu mà có các cột có kiểu Object
và bảng dữ liệu từ một kiểu Object.

17


Chương 1 Lý thuyết và các nghiên cứu liên quan

1.4.3.5 Bảng lồng nhau (Nested table)
Là một tập hợp những phần tử dữ liệu không cần tuân theo thứ tự, có cùng
kiểu dữ liệu, chỉ về bảng dữ liệu chứa nhiều cột tương ứng với mỗi thuộc
tính của kiểu đối tượng. Bảng lồng nhau chứa thêm một cột định nghĩa
hàng bảng cha hay đối tượng hàm thành phần. Thuộc tính của kiểu đối
tượng có thể được định nghĩa bởi bảng lồng ghép nhau.

1.4.3.6 Kiểu mảng
Mảng trong quan hệ đối tượng cũng giống như khai báo mảng trong các
ngôn ngữ khác. Mảng là một tập hợp có thứ tự của những phần tử dữ liệu
cùng kiểu với nhau.

1.4.3.7 Kiểu tham chiếu
ORDBMS tham chiếu dựa vào thuộc tính của đối tượng mang kiểu con trỏ
tham chiếu đến đối tượng khác, hoặc xây dựng các đối tượng mà bản thân
nó mang kiểu con trỏ. Khác hẳn với mô hình dữ liệu quan hệ, khi tham

chiếu dữ liệu cần có các khóa ràng buộc.

1.4.4 Một số hệ quản trị quan hệ đối tượng ORDBMS thường dùng
Một số hệ quản trị dữ liệu hướng đối tượng thường dùng: UniSQL/X (1992),
OpenODB, SQL3, Informix: Illustra (Informix-Universal Server), Oracle:
Oracle8. Trong đó, nhà cung cấp RDBMS dẫn đầu đó là Oracle, IBM...

1.4.5 Ưu điểm mô hình dữ liệu quan hệ hướng đối tượng (ORDBMS)
Ưu điểm chính của cơ sở dữ liệu quan hệ đối tượng là khả năng tái sử dụng,
mở rộng dự án, quản lí code dễ dàng, khả năng mở rộng cơ sở dữ liệu hỗ trợ
ngôn ngữ hướng đối tượng một cách dễ dàng và đáng tin cậy hơn so với các
mô hình dữ liệu quan hệ. Ngoài ra, ORDBMS còn có khả năng làm việc với
các loại dữ liệu phức tạp và nâng cao hiệu suất tổng thể hệ thống.

1.4.6 Nhược điểm mô hình ORDBMS
Ngoài những ưu điểm trong việc sử dụng mô hình dữ liệu quan hệ đối tượng,
mô hình này khi thực hiện với các đối tượng cũng như mối quan hệ quá phức
tạp, bộc lộ những hạn chế qua việc ánh xạ các đối tượng quá phức tạp lưu trữ
dữ liệu xuống các bảng làm cho hiệu suất hệ thống chậm chạp. Ngoài ra,

18


Chương 1 Lý thuyết và các nghiên cứu liên quan

ORDBMS vẫn trong giai đoạn phát triển nên còn thiếu chuyên gia trong lĩnh
vực này.

1.5 Lý thuyết về cơ sở dữ liệu NoSQL
1.5.1 Giới thiệu

1.5.1.1 Sơ lược về NoSQL
NoSQL [14] viết tắt của từ Not only SQL (không chỉ SQL). NoSQL được
giới thiệu lần đầu vào năm 1998, và giới thiệu lại vào năm 2009 bởi Eric
Evans [14]. Là cơ sở dữ liệu mã nguồn mở và miễn phí phù hợp với công
nghệ đám mây. NoSQL phát triển theo hướng phân tán và không mang tính
ràng buộc. NoSQL có tính BASE [3], viết tắc của các cụm từ như Basically
Available (Tính sẵn sàng), Soft-state (Trạng thái thời gian của hệ thống),
Eventually consistent (Tính nhất quán)). NoSQL thể hiện tính sẵn sàng cao,
có thể lưu trữ dữ liệu bị trùng lắp.
Nhược điểm của NoSQL:
• Do dữ liệu trùng lắp nên khi có nhu cầu cần xây dựng một ứng dụng
mang tính ràng buộc thì NoSQL không thể đáp ứng tốt được.
• NoSQL còn mới so với người dùng.
• Chưa có nhiều chuyên gia trong lĩnh vực này.
Tuy nhiên, NoSQL chấp nhận những nhược điểm này để giải quyết bài
toán về hiệu suất. NoSQL hiện đang được sử dụng bởi các công ty lớn như
Amazon, google...

1.5.1.2 Phân loại NoSQL
• NoSQL lưu trữ dữ liệu dưới nhiều dạng khác nhau [14].
• Lưu trữ dữ liệu dạng Key-Value (Khóa-giá trị).
• Lưu trữ dữ liệu dạng cột (Column-oriented /Column Families)
• Lưu trữ dữ liệu hướng văn bản (Document Store)
• Lưu trữ dữ liệu dạng đồ thị (Graph Databases)

1.5.2 Cơ sở dữ liệu MongoDB
MongoDB [14] là một trong những cơ sở dữ liệu mã nguồn mở và miễn phí
của NoSQL, có khả năng mở rộng theo chiều ngang và tính sẵn sàng cao, hỗ
19

Chương 1 Lý thuyết và các nghiên cứu liên quan

trợ tính năng lập chỉ mục. MongoDB lưu trữ dữ liệu dưới dạng BSON
(Binary JSON).
MongoDB có lược đồ cơ sở dữ liệu linh động. Tuy nhiên việc thiết kế lược
đồ MongoDB cần cân nhắc trước khi thực hiện. Khác với lược đồ cơ sở dữ
liệu quan hệ, cấu trúc của MongoDB được thiết kế tùy vào nhu cầu thực tế.
Chẳng hạn theo một nghiệp vụ nào đó hoặc thiết kế theo những yêu cầu tối
ưu hóa cơ sở dữ liệu cho các trường hợp thường xuyên sử dụng, hoặc các
yêu cầu về tốc độ truy vấn dữ liệu.
MongoDB hoạt động trên các khái niệm Collection và Document. Collection
bao gồm một nhóm các Document trong MongoDB, Collection tương đương
như một bảng trong cơ sở dữ liệu quan hệ. Document trong MongoDB, có
là một tập các cặp key/value [14].

Hình 1.4 Collection của MongoDB

Hình 1.5 Document trong MongoDB

20


Chương 1 Lý thuyết và các nghiên cứu liên quan

Phạm vi lưu trữ của MongoDB:
✓ Dữ liệu: khoảng 2GB trên hệ thống 32 bit
✓ Tên trong MongoDB (tổng collection, index): 24000.

1.5.3 Mô hình dữ liệu trong MongoDB

1.5.3.1 Phép tham chiếu Reference
Đây là phương pháp thiết kế mối quan hệ chuẩn hóa. Phương pháp này
liên kết từ một văn bản (Document) này sang một văn bản (Document)
khác thông qua một id chung. Việc truy cập dữ liệu dễ dàng do dữ liệu
được tổ chức riêng lẻ.

Hình 1.6 Ví dụ cấu trúc tham chiếu văn bản

1.5.3.2 Phép nhúng Embedded documents
Phép nhúng này lưu trữ các mối quan hệ giữa dữ liệu bằng cách lưu trữ
dữ liệu liên quan trong một cấu trúc tài liệu đơn. Điều này giúp cho việc
tìm kiếm dữ liệu dễ dàng. Tuy nhiên, khi dữ liệu lớn, việc sử dụng phép
nhúng giảm đi hiệu suất đọc/ghi.

Hình 1.7 Ví dụ về Embeded documents
21


Chương 1 Lý thuyết và các nghiên cứu liên quan

1.6 Các thao tác cơ bản trong Mongodb
Công cụ thao tác:
❖ Cơ sở dữ liệu MongoDB phiên bản 3.4.5 được download tại:
( />❖ Công cụ trực quan làm việc với MongoDB là phần mềm RoboMongo
(download tại />❖ Command line (cmd)

1.6.1 Thao tác với Database (Cơ sở dữ liệu)
1.6.1.1 Tạo mới Database (Cơ sở dữ liệu)
Cú pháp: use tên_cơ_sở_dữ_liệu

1.6.1.2 Lệnh xóa dữ liệu
Cú pháp: db.dropDatabase()

1.6.2 Thao tác với Collection
1.6.2.1 Lệnh tạo Collection
Cú pháp: db.createCollection(tên_collection, options).

1.6.2.2 Lệnh xóa Collection
Cú pháp: db.tên_Collection.drop()

1.6.3 Thao tác với Document
1.6.3.1 Chèn Document
Cú pháp: > db.tên_collection.insert(document)
1.6.3.2 Truy vấn Document
Cú pháp >db.tên_collection.find()

1.6.3.3 Cập nhật Document
Cú pháp: >db.tên_Collection.update(điều kiện, dữ liệu được thay thế)

1.6.3.4 Xóa Document
Cú pháp: > db.tên_Collection.remove(điều kiện Document xóa)

22


Chương 2 Chuyển đổi mô hình cơ sở dữ liệu quan hệ và đối tượng sang NoSQL

Chương 2 CHUYỂN ĐỔI MÔ HÌNH CƠ SỞ DỮ LIỆU QUAN HỆ VÀ ĐỐI

TƯỢNG SANG NoSQL

2.1 Lập kế hoạch
▪ Tìm hiểu về nội dung, phương pháp qua các bài báo, công trình đã được
nghiên cứu. Tìm ra những điểm mạnh và điểm yếu của các công trình, phát
triển những hạn chế đang tồn tại. Lập ra kế hoạch cho từng thời điểm thực
hiện của mỗi công việc rõ ràng.
▪ Chọn công nghệ .NET với phần mềm Visual Studio 2013 (ngôn ngữ C#)
▪ Chọn hệ quản trị cơ sở dữ liệu (cơ sở dữ liệu quan hệ (SQL Server 2013),
NoSQL (MongoDB version 3.4.5)
▪ Bộ dữ liệu mẫu để thực nghiệm: DBLP và TPC-H
▪ Phân tích dữ liệu với mối quan hệ trong lược đồ cơ sở dữ liệu quan hệ
▪ Thiết kế và phát triển một lược đồ ngầm cho MongoDB lưu trữ dữ liệu.
▪ Thiết kế và phát triển lược đồ các lớp của đối tượng
▪ Viết mã (code) cho các lớp được định nghĩa trong sơ đồ lớp
▪ Viết code cho hai quá trình chuyển đổi mô hình dữ liệu quan hệ sang
NoSQL và chuyển đổi mô hình đối tượng sang NoSQL.
▪ Đánh giá và kết luận các phương pháp thực hiện và so sánh hiệu suất truy
vấn giữa dữ liệu quan hệ với đối tượng, giữa đối tượng với NoSQL

2.2 Mục tiêu chuyển đổi
Trong quá trình chuyển đổi dữ liệu phải đạt được mục tiêu như:
Các nghiệp vụ xử lí truy vấn bên cơ sở dữ liệu quan hệ và đối tượng
thực hiện được, khi chuyển qua NoSQL cũng phải thực hiện được.
Dữ liệu chuyển từ mô hình cơ sở dữ liệu quan hệ và đối tượng sang
NoSQL phải đảm bảo dữ liệu chuyển qua đầy đủ.

2.3 Thiết kế lược đồ
Tùy vào mỗi cơ sở dữ liệu mà có thiết kế lược đồ cho từng collection (table)
và mối quan hệ giữa chúng sao cho phù hợp nhất. Bảng dưới đây thể hiện ánh
xạ giữa cơ sở dữ liệu quan hệ và MongoDB:

23