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

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ế.. Mục tiêu của việc chuyển đổi mô hình dữ liệu quan hệ và đối tượng sang NoSQ

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

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

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

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

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

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

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 http://www.tpc.org/tpch/

2 http://dblp.uni-trier.de/

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

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

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ể

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 đề

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

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.1Minh họa dữ liệu hướng đối tượng

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

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

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

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.3Mô 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.1Kiểu dữ liệu phức hợp

Kiểu dữ liệu phức hợp định

nghĩa sẵn

Ý nghĩa

Binary Large Object - BLOB Đối tượng lớn dạng nhị phân không

có cấu trúc trong cơ sở dữ liệu Khả năng lưu được 4GB dữ liệu

Character Large Object - CLOB Đối tượng lớn dạng ký tự

Fixed - Width Multibyte

Character Large Object-

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

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,

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ỗ

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.5Document trong MongoDB

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.7Ví dụ về Embeded documents

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: (https://www.mongodb.com/)

❖ Công cụ trực quan làm việc với MongoDB là phần mềm RoboMongo

(download tại https://robomongo.org/)

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

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:

Bảng 2.1 Ánh xạ giữa cơ sở dữ liệu quan hệ và MongoDB

Tên gọi Cơ sở dữ liệu quan

Khóa chính Primary key _id field

2.4 Chọn lựa mô hình dữ liệu MongoDB

Đầu tiên cần xác định số lượng thực thể và mối quan hệ giữa chúng Xác định nghiệp vụ hiện tại cần sử dụng mô hình nào là phù hợp, mô hình dữ liệu quan

hệ quan hệ có đáp ứng được các yêu cầu hiện tại hay không? Khi thiết kế các

mô hình dữ liệu, cần xem xét kĩ các vấn đề sử dụng dữ liệu truy vấn, cập nhật

và xử lý dữ liệu cũng như cấu trúc vốn có của dữ liệu

2.5 Phương pháp chuyển đổi mô hình

2.5.1 Phương pháp chuyển đổi mô hình dữ liệu quan hệ sang NoSQL

Hình 2.1 Minh họa chuyển cấu trúc dữ liệu quan hệ sang MongoDB

Hình 2.2 Minh họa dữ liệu một bảng chuyển qua MongoDB

2.5.1.1 Kỹ thuật chuyển đổi

Sử dụng công nghệ NET (C#) Ngoài ra, hiện nay NET đã có những tính năng mới trong việc cung cấp các trình điều khiển driver giúp MongoDB

sử dụng và tương tác được với ngôn ngữ C# Các thư viện hỗ trợ đó là MongoDB.Bson, MongoDB.Driver và một số thư viện hỗ trợ khác

2.5.1.2 Phân tích dữ liệu và mối quan hệ lược đồ

Dữ liệu được sử dụng là DBLP (được tham khảo tại:

http://dblp.uni-trier.de/ và TPC-H (http://www.tpc.org)

Dữ liệu DBLP gồm 12 bảng (Table): Wwws, Journal, Raw_Links, Books, Paper, Msthesis, Phpthesis, Baseobject, Simulatedmetriclookup, Metrics, Processings

Thiết kế Lược đồ cơ sở dữ liệu quan hệ DBLP

Hình 2.3Lược đồ cơ sở dữ liệu quan hệ DBLP Mối quan hệ phụ thuộc nhau giữa các thực thể như sau:

Wwws - Baseobject 1-1 Journals - Baseobject 1-1 Raw_links - Baseobject 1-n Books - Baseobject 1-1 Paper - Baseobject 1-1 Person - Baseobject 1-1 Msthesis-Baseobject 1-1 Phdthesis-Baseobject 1-1

Dữ liệu TPC-H gồm 8 thực thể: Part, Supplier, Partsupp, Lineitem, Orders, Customer, Nation, Region Trong đó thực thể chính là: Partsupp, Lineitem

• Lược đồ cơ sở dữ liệu quan hệ TPC-H:

Hình 2.4Lược đồ cơ sở dữ liệu quan hệ TPC-H

• Mối quan hệ phụ thuộc nhau giữa các thực thể như sau:

PART - PARTSUPP .1-n SUPPLIER - PARTSUPP 1-n ORDERS - LINEITEM .1-n CUSTOMER - ORDERS .1-n NATION - CUSTOMER .1-n NATION - REGION .1-n 2.5.1.3 Thiết kế lược đồ MongoDB

Dữ liệu DBLP:

CUSTOMER

C_CUSTKEY C_NAME C_ADDRESS C_NATIONKEY C_PHONE C_ACCTBAL C_MKTSEGMENT C_COMMENT

LINEITEM

L_ORDERKEY L_PARTKEY L_SUPPKEY L_LINENUMBER L_QUANTITY L_EXTENDEDPRICE L_DISCOUNT L_TAX L_RETURNFLAG L_LINESTATUS L_SHIPDATE L_COMMITDATE L_RECEIPTDATE L_SHIPINSTRUCT L_SHIPMODE L_COMMENT

NATION

N_NATIONKEY N_NAME N_REGIONKEY N_COMMENT

ORDERS

O_ORDERKEY O_CUSTKEY O_ORDERSTATUS O_TOTALPRICE O_ORDERDATE O_ORDERPRIORITY O_CLERK O_SHIPPRIORITY O_COMMENT

PART

P_PARTKEY P_NAME P_MFGR P_BRAND P_TYPE P_SIZE P_CONTAINER P_RETAILPRICE P_COMMENT

PARTSUPP

PS_PARTKEY PS_SUPPKEY PS_AVAILQTY PS_SUPPLYCOST PS_COMMENT

REGION

R_REGIONKEY R_NAME R_COMMENT

SUPPLIER

S_SUPPKEY S_NAME S_ADDRESS S_NATIONKEY S_PHONE S_ACCTBAL S_COMMENT

Hình 2.5Lược đồ cơ sở dữ liệu DBLP trong MongoDB Thiết kế lược đồ TPC-H trong MongoDB

Hình 2.6 Lược đồ cơ sở dữ liệu TPC-H trong MongoDB

2.5.1.4 Quá trình chuyển đổi dữ liệu

Về phương pháp chuyển đổi dữ liệu từ mô hình dữ liệu quan hệ sang NoSQL

sẽ thực hiện theo nhiều cách Chuyển từng bảng sang NoSQL hoặc chuyển tất

cả các bảng sang NoSQL, hoặc chọn vài bảng có mối quan hệ ràng buộc với nhau, sau đó chuyển qua NoSQL Tuy nhiên, tùy vào từng nghiệp vụ mà có thể chọn một phương pháp phù hợp với dự án thực tế

Trong bài này, phương pháp được chọn là ánh xạ từ một bảng của dữ liệu quan

hệ sang thành một collection trong NoSQL, trong đó toàn bộ lược đồ cơ sở dữ liệu, bảng, cột, dòng, khóa chính được chuyển qua và dùng lại đúng tên trước

đó có bên dữ liệu quan hệ Người dùng có thể tùy chọn bất kì cơ sở dữ liệu có sẳn từ SQL Server để chuyển đổi dữ liệu sang NoSQL Có thể chọn chuyển một lần đối với tất cả các bảng hoặc chuyển theo yêu cầu những bảng mà người dùng mong muốn Với phương pháp này, các khóa chính (primary key) từ SQL Server chuyển qua NoSQL không còn mang tính ràng buộc dữ liệu như ở SQL Server Các bước chuyển đổi qua mô hình hệ thống

Hình 2.7Sơ đồ hệ thống chuyển đổi dữ liệu quan hệ sang NoSQL

2.5.2 Phương pháp chuyển đổi từ mô hình đối tượng sang NoSQL

Hình 2.8Minh họa chuyển đổi đối tượng sang NoSQL

2.5.2.1 Kỹ Thuật chuyển đổi

Sử dụng công nghệ NET (C#) Ngoài ra, NET còn cung cấp các trình điều khiển driver giúp MongoDB tương tác với ngôn ngữ C#

Các thư viện hỗ trợ đó là MongoDB.Bson, MongoDB.Driver và một số thư viện hỗ trợ khác Sử dụng mô hình ORM [10] để ánh xạ các bảng (Table) qua đối tượng (đối tượng) và bảng quan hệ trong cơ sở dữ liệu ánh xạ với mối quan hệ liên kết trong các đối tượng

2.5.2.2 Phân tích dữ liệu đối tượng và lược đồ TPC-H

Ở lược đồ này có 08 đối tượng bao gồm: Part, Supplier, Partsupp,

Lineitem, Orders, Customer, Nation, Region Trong đó thực thể chính là: Partsupp, Lineitem

Hình 2.9Lược đồ của mô hình đối tượng TPC-H

2.5.2.3 Quá trình chuyển đổi mô hình

Quá trình chuyển đổi mô hình đối tượng sang NoSQL đã sử dụng các đặc tính nổi bật của mô hình đối tượng như tính kế thừa, tính bao đóng, tính

đa hình Việc khai thác triệt để các đặc tính trên nhằm phục vụ cho quá trình chuyển đổi mô hình Hiện nay công nghệ NET cũng đã hỗ trợ các

kỹ thuật cho việc chuyển đổi mô hình thông qua các Entity Framework Một số minh họa đặc tính của mô hình đối tượng trong code (dùng bộ dữ liệu TPC-H)

Hình 2.10Minh họa tính kế thừa của mô hình đối tượng TPC-H

Tính đa hình thể hiện qua minh họa sau:

Hình 2.11Minh họa tính đa hình trong mô hình đối tượng TPC-H

Hình 2.12Minh họa tính đa hình trong mô hình đối tượng TPC-H Tính bao đóng:

Hình 2.13Minh họa tính bao đóng trong mô hình đối tượng TPC-H

Về phương pháp chuyển đổi cho quá trình này cũng giống như phương pháp chuyển đổi dữ liệu quan hệ sang NoSQL Tuy nhiên ở phương pháp này sử dụng hai trường hợp:

• Một là, chuyển từng đối tượng sang NoSQL, hoặc chọn tất cả các đối tượng chuyển sang NoSQL

• Hai là, thực hiện gom các đối tượng có ràng buộc dữ liệu với nhau và sau đó chuyển đối tượng này sang NoSQL Các bước thực hiện như sau: