Dự đoán liên kết trên cơ sở dữ liệu đồ thị

Bài toán dự đoán liên kết Link prediction có nhiều ứng dụng trong thực tế như mạng xã hội, hệ gợi ý, mối liên hệ giữa các phân tử trong mạng sinh học, đồng tác giả tiềm năng trong mạng l

BỘ GIÁO DỤC VÀ ĐÀO TẠO

TRƯỜNG ĐẠI HỌC QUY NHƠN

NGUYỄN TRỌNG NHÂN

DỰ ĐOÁN LIÊN KẾT TRÊN SƠ SỞ DỮ LIỆU ĐỒ THỊ

Chuyên ngành: Khoa học máy tính

Mã số: 8480101

Người hướng dẫn: TS Trần Thiên Thành

Tôi cam đoan các kết quả tìm hiểu đưa ra trong luận văn này dựa trên các kết quả thu được trong quá trình tìm hiểu của riêng tôi Các kết quả nghiên cứu và các kết luận trong luận văn là trung thực, không sao chép từ bất

kỳ một nguồn nào và dưới bất kỳ hình thức nào Việc tham khảo các nguồn tài liệu (nếu có) đã được thực hiện trích dẫn và ghi nguồn tài liệu tham khảo đúng quy định

Quy Nhơn, tháng 09, năm 2021

Nguyễn Trọng Nhân

Luận văn Thạc Sỹ này được thực hiện tại Trường Đại học Quy Nhơn

Để hoàn thành luận văn này, tôi xin tỏ lòng biết ơn sâu sắc và gửi lời cảm ơn chân thành đến Thầy TS Trần Thiên Thành, đã tận tình hướng dẫn, giúp đỡ cho tôi trong suốt quá trình thực hiện luận văn Tôi xin chân thành cảm ơn quý Thầy, cô trong khoa Khoa học máy tính và phòng sau đại học của Trường Đại học Quy Nhơn đã tận tình truyền đạt kiến thức, tạo điều kiện thuận lợi về mặt thủ tục cho hoạt động học tập và thực hiện luận văn của tôi Cuối cùng tôi cũng xin gửi lời cảm ơn tới các anh chị và các bạn lớp cao học Khóa 22 luôn động viên, khích lệ tinh thần, giúp tôi rất nhiều trong quá trình học tập cũng như hoàn thành luận văn thạc sỹ

Quy Nhơn, tháng 09, năm 2021

Nguyễn Trọng Nhân

LỜI CAM ĐOAN

LỜI CẢM ƠN

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

DANH MỤC CÁC BẢNG

DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ

MỞ ĐẦU 1

1 Lý do chọn đề tài 1

2 Mục tiêu nghiên cứu 1

3 Đối tượng và phạm vi nghiên cứu 1

3.1 Đối tượng nghiên cứu 1

3.2 Phạm vi nghiên cứu 2

4 Phương pháp nghiên cứu 2

5 Nội dung nghiên cứu 2

Chương 1: CƠ SỞ DỮ LIỆU ĐỒ THỊ 3

1.1 Đồ thị 3

1.2 Cơ sở dữ liệu đồ thị 7

1.2.1 Các mô hình cơ sở dữ liệu đồ thị 9

1.2.2 Ứng dụng của cơ sở dữ liệu đồ thị 12

1.2.3 Một số hệ quản trị cơ sở dữ liệu đồ thị tiêu biểu 14

1.3 Cơ sở dữ liệu đồ thị Neo4J 15

1.3.1 Giới thiệu 15

1.3.2 Mô hình dữ liệu 16

1.3.3 Ngôn ngữ truy vấn Cyper 22

1.3.4 Khoa học dữ liệu đồ thị 26

1.4 Tiểu kết chương 1 29

2.1 Bài toán dự đoán liên kết 30

2.1.1 Giới thiệu bài toán 30

2.1.1 Ứng dụng 31

2.1.2 Phương pháp dự đoán liên kết 31

2.2 Dự đoán liên kết trên cơ sở dữ liệu đồ thị Neo4j 33

2.2.1 Ưu điểm của cơ sở dữ liệu đồ thị đối với bài toán dự đoán liên kết 33

2.2.2 Phương pháp sử dụng 33

2.2.3 Ví dụ minh họa 42

2.3 Xây dựng bô phân loại học máy trong bài toán dự đoán liên kết 45

2.3.1 Xây dựng mô hình học máy 45

2.3.2 Tập huấn luyện và tập kiểm tra 47

2.3.3 Các metrics đánh giá mô hình: 48

2.4 Tiểu kết chương 2 52

Chương 3: CÀI ĐẶT MÔ PHỎNG THỰC NGHIỆM 53

3.1 Môi trường và Công cụ thực nghiệm 53

3.1.1 Môi trường và ngôn ngữ lập trình 53

3.1.2 Công cụ và thư viện 53

3.2.3 Bộ dữ liệu 54

3.2 Bài toán dự đoán đồng tác giả 55

3.3 Cài đặt mô phỏng 57

3.2.1 Kết nối Neo4j: 57

3.2.2 Nạp cơ sở dữ liệu DBLP vào Neo4j 57

3.2.3 Xây dựng biểu đồ đồng tác giả 58

3.2.4 Tạo tập dữ liệu huấn luyện và kiểm tra 58

3.2.7 Đánh giá mô hình 63

3.2.8 Xây dựng một số tính năng đồ thị khác 64

3.3 Đánh giá kết quả đạt được 67

3.4 Tiểu kết chương 3 69

KẾT LUẬN 70

DANH MỤC TÀI LIỆU THAM KHẢO 71

QUYẾT ĐỊNH GIAO ĐỀ TÀI LUẬN VĂN THẠC SĨ (BẢN SAO)

CSDL : Cơ sở dữ liệu

RDBMS : Hệ quản trị cơ sở dữ liệu quan hệ SQL : Structured Query Language

API : Application Programming Interface RDF : Resource Description Framework URI : Uniform Resource Identifier

IDE : Integrated Development Environment APOC : Awesome Procedures on Cypher

Bảng 2.1: Các thông số cú pháp thư viện thuật toán Adamic Adar 34

Bảng 2.2: Các thông số cú pháp thư viện thuật toán hàng xóm chung 35

Bảng 2.3: Các thông số cú pháp thư viện thuật toán đính kèm thích hợp 35

Bảng 2.4: Các thông số cú pháp thư viện thuật toán phân bổ tài nguyên 36

Bảng 2.5: Các thông số cú pháp thư viện thuật toán cùng cộng đồng 36

Bảng 2.6: Các thông số cú pháp thư viện thuật toán tổng số lân cận 37

Bảng 2.7: Các thông số cú pháp thuật toán đếm số tam giác 38

Bảng 2.8: Cấu hình chung để thực thi thuật toán trên đồ thị đã đặt tên 39

Bảng 2.9: Kết quả 39

Bảng 2.10: Các thông số cú pháp thuật toán hệ số phân cụm cục bộ 40

Bảng 2.11: Cấu hình chung để thực thi thuật toán trên đồ thị đã đặt tên 40

Bảng 2.12: Cấu hình cụ thể của thuật toán 41

Bảng 2.13: Kết quả 41

Bảng 2.14: Các chỉ số của Positive và Negative 49

Bảng 3.1: Bảng kết quả đánh giá mô hình 67

Hình 1.1: Ví dụ về hai đỉnh không có cạnh nối 3

Hình 1.2: Ví dụ về hai đỉnh có một cạnh nối 3

Hình 1.3: Ví dụ về hai đỉnh có nhiều hơn một cạnh nối 4

Hình 1.4: Ví dụ về cạnh có hướng 4

Hình 1.5: Ví dụ về cạnh khuyên 4

Hình 1.6: Ví dụ về đồ thị vô hướng với 6 đỉnh và 7 cạnh 5

Hình 1.7: Cấu trúc dữ liệu theo danh sách cạnh 6

Hình 1.8: Cấu trúc dữ liệu theo ma trận kề 6

Hình 1.9: Một số dạng đồ thị 6

Hình 1.10: ví dụ về CSDL đồ thị mạng xã hội 9

Hình 1.11: Ví dụ về đồ thị thuộc tính đơn giản 10

Hình 1.12: Biểu đồ RDF 12

Hình 1.13: Ví dụ dự đoán liên kết tình bạn trong mạng xã hội 12

Hình 1.14: Ví dụ về phân loại nút 13

Hình 1.15: Ví dụ về phân cụm đồ thị 13

Hình 1.16: Kiến trúc logic của Neo4j 16

Hình 1.17: Nút, các mối quan hệ và tập thuộc tính 17

Hình 1.18: Ví dụ về một đồ thị đơn giản với 1 nút và 1 thuộc tính 17

Hình 1.19: Mối quan hệ và các quan hệ liên quan 18

Hình 1.20: Một mối quan hệ giữa nút bắt đầu và nút kết thúc 18

Hình 1.21: Quan hệ vào và quan hệ ra của một nút 18

Hình 1.22: Quan hệ trên 1 nút 18

Hình 1.23: Ví dụ một mạng xã hội 19

Hình 1.24: Biểu diễn một thuộc tính 20

Hình 1.25: Đường đi 20

Hình 1.28: Biểu diễn một nhãn 21

Hình 1.29: Các phiên bản Neo4j được hổ trợ thư viện GDS v1.6 27

Hình 1.30: Cài đặt GDS ở cấp độ cơ sở dữ liệu 27

Hình 1.31: Cài đặt GDS trong cấu hình Neo4j 28

Hình 1.32: Kiểm tra phiên bản GDS 28

Hình 1.33: Các thuật toán trong GDS 29

Hình 2.1: Các thuật toán dự đoán liên kết [[4]] 31

Hình 2.2: Đồ thị đơn giản trong Neo4j 42

Hình 2.3: Kết quả số hàng xóm chung của 2 nút Thu và Nam 42

Hình 2.4: Kết quả số hàng xóm chung của 2 nút Thu và Nhi 43

Hình 2.5: Kết quả số hàng xóm chung sử dụng hướng quan hệ của 2 nút Thu và Nhi 43

Hình 2.6: Kết quả tích của 2 nút Thu và Nam 44

Hình 2.7: Kết quả tổng số nút và số tam giác trong đồ thị 44

Hình 2.8: Kết quả sử dụng thuật toán hệ số phân cụm cục bộ 45

Hình 3.1: Một mô hình rừng ngẫu nhiên 56

Hình 3.2: Truy vấn và kết quả kết nối với Neo4j 57

Hình 3.3: Lược đồ và minh họa dữ liệu DBLP.v10 trong Neo4j 57

Hình 3.4: Truy vấn Cyper và biểu đồ đồng tác giả trong Neo4j 58

Hình 3.5: Truy vấn và biểu đồ kết quả số bài báo theo năm 59

Hình 3.6: Truy vấn và kết quả số bài bảo xuất bản trước và từ năm 2006 về sau 60

Hình 3.7: Truy vấn và kết quả mối quan hệ đồng tác giả giữa các bài báo trước năm 2006 60

Hình 3.9: Truy vấn tạo DataFrame huấn luyện 61

Hình 3.10: Truy vấn tạo DataFrame kiểm tra 61

Hình 3.11: Tạo bộ phân loại rừng ngẫu nhiên 62

Hình 3.12: Truy vấn lấy các nút được ghép nối từ DataFrame và tính toán các kết quả cho từng cặp nút: (CN), (PA) và (TN) 62

Hình 3.13: Truy vấn và mẫu DataFrame huấn luyện 63

Hình 3.14: Truy vấn tạo mô hình huấn luyện 63

Hình 3.15: Kết quả Accuracy, Precision, Recall, F1 63

Hình 3.16: Vai trò của các tính năng dự đoán liên kết 64

Hình 3.17: Truy vấn đếm số tam giác và hệ số phân cụm cục bộ 65

Hình 3.18: Mẫu DataFrames 65

Hình 3.19: Truy vấn tính các giá trị nhỏ nhất và lớn nhất 66

Hình 3.20: Mô hình đào tạo và kết quả đánh giá mô hình 66

Hình 3.21: Vai trò của các tính năng 66

Hình 3.22: Kết quả đánh giá mô hình ở năm 1997 68

Hình 3.23: Kết quả đánh giá mô hình ở năm 2004 68

Hình 3.24: Kết quả đánh giá mô hình ở năm 2013 68

MỞ ĐẦU

1 Lý do chọn đề tài

Bài toán dự đoán liên kết (Link prediction) có nhiều ứng dụng trong thực tế như mạng xã hội, hệ gợi ý, mối liên hệ giữa các phân tử trong mạng sinh học, đồng tác giả tiềm năng trong mạng lưới trích dẫn, mối quan tâm đến nghệ sĩ hoặc tác phẩm nghệ thuật … Trong bài toán dự đoán liên kết dữ liệu thường có mối liên hệ với nhau nên việc sử dụng cơ sở dữ liệu mô hình đồ thị

để lưu trữ dữ liệu cho bài toán dự đoán liên kết sẽ khai thác được nhiều điểm mạnh của mô hình dữ liệu đồ thị

Cơ sở dữ liệu đồ thị Neo4j đã xây dựng thư viện hỗ trợ cho bài toán dự đoán liên kết nên việc sử dụng cơ sở dữ liệu Neo4j lưu trữ dữ liệu sẽ thuận lợi cho những bài toán ứng dụng dự đoán liên kết

Với những lí do trên tôi tôi chọn “Dự đoán liên kết trên cơ sở dữ liệu đồ thị” làm đề tài nghiên cứu cho luận văn của mình Nội dung chính của luận

văn là sử dụng dự đoán liên kết trong mạng trích dẫn: dự đoán hành động của hai người cộng tác trên một bài báo

2 Mục tiêu nghiên cứu

Tìm hiểu việc tổ chức lưu trữ dữ liệu trên cơ sở dữ liệu Neo4j và các chức năng tính toán để sử dụng giải quyết bài toán dự đoán liên kết và thực nghiệm trên dữ liệu trích dẫn tham khảo, đồng tác giả các bài báo khoa học để

dự đoán đồng tác giả trong tương lai

3 Đối tượng và phạm vi nghiên cứu

3.1 Đối tượng nghiên cứu

Cơ sở dữ liệu mô hình đồ thị Neo4j và thư viện hỗ trợ dự đoán liên kết Bài toán dự đoán liên kết

Các kỹ thuật khai phá dữ liệu, học máy sử dụng thư viện viện học máy:

4 Phương pháp nghiên cứu

Phân tích và tổng hợp lý thuyết

Điều tra, thu thập dữ liệu

Mô hình hóa

Thực nghiệm khoa học

Phân tích và tổng hợp kết quả thực nghiệm

5 Nội dung nghiên cứu

Tìm hiểu về bài toán dự đoán liên kết và các thuật toán dự đoán liên kết cũng như khả năng ứng dụng của nó

Tìm hiểu cơ sở dữ liệu Neo4j và thư viện hỗ trợ dự đoán liên kết

Tìm hiểu về ngôn ngữ lập trình Python và thư viện thao tác với Neo4j, scikit-learning với các kỹ thuật phân lớp

Ứng dụng dự đoán liên kết cho bài toán dự đoán đồng tác giả trong các bài báo dựa trên dữ liệu trích dẫn và đồng tác giả của các bài báo trong DBLP Citation Network

Chương 1: CƠ SỞ DỮ LIỆU ĐỒ THỊ

Trong chương đầu tiên này, nội dung luận văn không đi sâu mà chỉ giới thiệu một cách tổng quan về đồ thị, cơ sở dữ liệu đồ thị và Neo4j Đồng thời cũng trình bày tổng quan về mô hình dữ liệu, ngôn ngữ truy vấn Cyper và thư viện khoa học dữ liệu đồ thị của Neo4j làm cơ sở lý thuyết để tiếp tục đi sâu, phân tích và trình bày nội nội dung chính của luận văn ở các chương tiếp theo

1.1 Đồ thị

Đồ thị là một mô hình xây dựng trên một tập hữu hạn các đối tượng và những mối quan hệ hai ngôi trên chúng

Một đồ thị G xem như một hệ thống gồm hai tập hợp (hữu hạn) mà ta

ký hiệu cho gọn là G = (V, E), trong đó các phần tử của V được gọi là đỉnh và các phần tử của E được gọi là cạnh Mỗi cạnh e của đồ thị được xem như hình thành bởi việc liên kết hai đỉnh u và v của đồ thị, và thường viết e = (u, v) Các đỉnh u, v được gọi là các đỉnh mút của e và e được gọi là cạnh nối u với v Để trực giác, đồ thị thường được biểu diễn trên mặt phẳng, trong đó mỗi đỉnh được vẽ như một điểm và mỗi cạnh được vẽ như một cung nối hai điểm Trong trường hợp tổng quát nhất của mối quan hệ giữa đỉnh và cạnh, có các trường hợp sau:

 Giữa hai đỉnh có thể không có cạnh nối nào:

Hình 1.1: Ví dụ về hai đỉnh không có cạnh nối

 Giữa hai đỉnh có thể có đúng một cạnh nối:

Hình 1.2: Ví dụ về hai đỉnh có một cạnh nối

 Giữa hai đỉnh có thể có nhiều hơn một cạnh nối:

Hình 1.3: Ví dụ về hai đỉnh có nhiều hơn một cạnh nối

Như thế, nếu mỗi đỉnh của đồ thị mô tả một đối tượng, thì mỗi cạnh biểu diễn một quan hệ hai ngôi nào đó giữa các đối tượng này Thông thường, vai trò của hai đỉnh mút u, v của cạnh e là như nhau, nghĩa là trong biểu diễn

e = (u, v), thứ tự của u và v là không quan trọng Trường hợp này, cạnh e mô

tả một quan hệ đối xứng giữa u và v và e được gọi là cạnh vô hướng

Trong một số ứng dụng, người ta đưa thêm hướng vào các cạnh để mô

tả những quan hệ không đối xứng Khi đó cặp đỉnh (u, v) biểu diễn cạnh e cần phải kể thứ tự và e được gọi là cạnh có hướng, đỉnh u được gọi là đỉnh đầu và đỉnh v được gọi là đỉnh cuối của cạnh e

Để diễn đạt e = (u, v) là cạnh vô hướng, người ta thường nói e là cạnh nối giữa u và v, còn để diễn đạt e = (u, v) là cạnh có hướng, người ta thường nói e là cạnh nối từ u đến v và trên cung biểu diễn nó, người ta thêm vào chiều mũi tên hướng từ u đến v

Hình 1.4: Ví dụ về cạnh có hướng

Ngoài ra trong định nghĩa cạnh, người ta cũng cho phép trường hợp cạnh nối một đỉnh với chính nó, nghĩa là e = (u, u) Một cạnh như vậy được gọi là khuyên Một đỉnh có khuyên mô tả một phần tử có quan hệ đang xét với chính nó

Hình 1.5: Ví dụ về cạnh khuyên

Phân loại:

Để thuận tiện cho việc nghiên cứu, người ta phân loại đồ thị theo những định nghĩa hẹp hơn với những tên dành riêng Dưới đây là những phân loại

thông thường nhất

 Đồ thị vô hướng và đồ thị có hướng Một đồ thị mà tất cả các

cạnh của nó đều vô hướng được gọi là đồ thị vô hướng, trái lại đồ thị được gọi là có hướng Trong nhiều tình huống, một đồ thị vô hướng được xử lý như một đồ thị có hướng bằng cách đồng nhất một cạnh vô hướng bằng hai cạnh có hướng ngược chiều nhau Ngược lại, nếu bỏ đi các hướng trên các cạnh, thì đồ thị có hướng trở thành đồ thị vô hướng

 Đơn đồ thị và đa đồ thị Một đồ thị không có khuyên và giữa hai

đỉnh chỉ có nhiều nhất là một cạnh nối được gọi là một đơn đồ thị Các đồ thị có khuyên hay có nhiều cạnh nối giữa hai đỉnh được gọi chung là các đa đồ thị Như thế đơn đồ thị là một trường hợp riêng, nhằm nghiên cứu các mô hình mà người ta chỉ quan tâm việc giữa hai đối tượng khác nhau có hay không có mối

quan hệ được xét

Hình 1.6: Ví dụ về đồ thị vô hướng với 6 đỉnh và 7 cạnh

Biểu diễn đồ thị trên máy tính:

Có nhiều cách biểu diễn cấu trúc dữ liệu của Đồ thị như Danh sách cạnh, Danh sách kề, Ma trận kề, Ma trận liên thuộc đỉnh - cạnh v.v

Ví dụ: Danh sách cạnh ta có thể biểu diễn dưới dạng danh sách với mỗi phần tử là 1 Tuple (nút, nút, quan hệ)

Hình 1.7: Cấu trúc dữ liệu theo danh sách cạnh

Hay với Ma trận Kề ta phải biểu diễn 2 ma trận khác nhau, mỗi ma trận

có kích thước N x N với N là số nút và giá trị tại (X, Y) thể hiện 1 mối quan hệ

từ X Y

Hình 1.8: Cấu trúc dữ liệu theo ma trận kề

Có rất nhiều dạng đồ thị khác nhau được phân tích trong lĩnh vực lý thuyết đồ thị, dưới đây là một số dạng [[2]]:

Hình 1.9: Một số dạng đồ thị

Càng về sau, công nghệ ngày càng phát triển, nhất là từ khi web nổi lên, khối lượng dữ liệu, thông tin về người dùng, về sản phẩm, đối tượng, sự kiện mà các hệ thống cần phải xử lý giờ đây ngày 1 lớn Ví dụ như Google, Facebook phải lưu trữ và xử lý một lượng dữ liệu cực lớn mỗi ngày Ngay cả việc hiển thị một trang web hoặc trả lời một yêu cầu API có thể làm mất hàng chục hoặc hàng trăm yêu cầu cơ sở dữ liệu khi các ứng dụng xử lý thông tin ngày một phức tạp

Giờ đây thì SQL lại gây một số cản trở với những hạn chế - cụ thể là lược đồ/schema cứng nhắc, thiếu linh hoạt - khiến chúng trở nên ít phù hợp hơn với các loại ứng dụng khác

Để đáp ứng những cần thiết về cơ sở dữ liệu, những cơ sở hạ tầng phục

vụ và cả những chiến lược liên tục được các nhà phát triển đưa ra và cũng đã

có những thay đổi đáng kể Những công nghệ đám mây đơn giản hơn và giá

cả hợp lý đã xuất hiện để thay thế những máy chủ phức tạp và đắt tiền Hay nữa là những kĩ sư sử dụng các phương pháp đẩy nhanh tốc độ, nhằm mục đích liên tục phát triển và rút ngắn các chu trình, mục đích để truy vấn dữ liệu với tốc độ nhanh, đáp ứng nhu cầu của người dùng

Và như vậy, NoSQL đã ra đời để phục vụ những yêu cầu phù hợp với

hiện tại Hệ thống NoSQL lưu trữ và quản trị dữ liệu sao cho có thể hỗ trợ được tốc độ vận hành ở công suất cao và cung cấp tính linh hoạt tuyệt vời cho các nhà phát triển sử dụng Không giống với cơ sở dữ liệu SQL, rất nhiều cơ

sở dữ liệu NoSQL có thể mở rộng theo chiều ngang trên hàng trăm hoặc hàng ngàn máy chủ

Với NoSQL, dữ liệu có thể được lưu trữ theo kiểu không có lược đồ hoặc dạng tự do Dữ liệu bất kỳ có thể được lưu trữ trong bản ghi bất kỳ Trong số các cơ sở dữ liệu NoSQL, có 4 mô hình lưu trữ dữ liệu phổ biến Do

đó, có 4 loại hệ thống NoSQL phổ biến là Document database, Key-value stores, Wide column stores và Graph database

Trong nội dung của luận văn này, tập trung nghiên cứu về cơ sở dữ liệu hướng đồ thị Cơ sở dữ liệu đồ thị như Neo4j nhằm mục đích cung cấp cho người dùng một cách tốt hơn để quản lý sự phức tạp của mạng dày đặc của cấu trúc dữ liệu trong tầm tay

Cơ sở dữ liệu đồ thị là cơ sở dữ liệu được thiết kế để coi các mối quan

hệ giữa các dữ liệu là quan trọng như nhau đối với bản thân dữ liệu Nó được thiết kế để lưu giữ dữ liệu mà không cần biến nó thành một mô hình được xác định trước Thay vào đó, dữ liệu được lưu trữ giống như lần đầu tiên chúng ta

vẽ ra – cho biết cách mỗi thực thể riêng lẻ kết nối với hoặc có liên quan với những thực thể khác

Biểu đồ sau đây cho thấy một ví dụ về biểu đồ mạng xã hội Với những người (các nút) và các mối quan hệ của họ (các cạnh), bạn có thể tìm ra ai là

“bạn của những người bạn” của một người cụ thể Ví dụ: bạn của những người bạn của Lam

Hình 1.10: ví dụ về CSDL đồ thị mạng xã hội

1.2.1 Các mô hình cơ sở dữ liệu đồ thị

1.2.1.1 Mô hình đồ thị thuộc tính

Về cơ bản, nó có nghĩa là chúng ta sẽ lưu trữ dữ liệu của mình trong cơ

sở dữ liệu đồ thị Cấu trúc đồ thị có nghĩa là chúng ta sẽ sử dụng các đỉnh và cạnh (hoặc các nút và các mối quan hệ) để lưu trữ dữ liệu một cách liên tục

Do đó, cấu trúc đồ thị cho phép chúng ta [[2]]:

• Biểu diễn dữ liệu theo cách tự nhiên hơn

• Áp dụng các loại thuật toán đồ thị khác nhau trên các cấu trúc này Tuy nhiên, mô hình đồ thị thuộc tính không phù hợp với tất cả các cấu trúc đồ thị Cụ thể, nó được tối ưu hóa cho:

• Đồ thị có hướng: Các liên kết giữa các nút (còn được gọi là các mối quan hệ) có hướng

• Đồ thị đa quan hệ: Có thể có nhiều mối quan hệ giữa hai nút giống nhau Những mối quan hệ này, như chúng ta sẽ thấy ở phần sau, sẽ khác biệt rõ ràng và thuộc một kiểu khác

• Lưu trữ các cặp khóa-giá trị như thuộc tính của các nút và các mối quan hệ

Trong các loại thuộc tính khác nhau có thể thuộc về các phần tử khác nhau của cấu trúc đồ thị, tất nhiên, những thuộc tính cơ bản nhất là các thuộc tính được gán cho các đỉnh và các cạnh

Hình 1.11: Ví dụ về đồ thị thuộc tính đơn giản

Mô hình đồ thị thuộc tính có những đặc điểm sau:[[2]]

• Không có lược đồ cố định

• Một phần do tính chất không có lược đồ của cơ sở dữ liệu, nên phù hợp để xử lý dữ liệu bán cấu trúc Nếu một nút hoặc mối quan hệ có nhiều thuộc tính hơn hoặc ít hơn, thì chúng ta không phải thay đổi thiết kế cho điều này; chúng ta có thể tự động giải quyết sự khác biệt về cấu trúc đó và làm việc với nó theo cùng một cách

• Các nút và thuộc tính của nút tương đối dễ hiểu Theo thuật ngữ quan hệ, có thể dễ dàng so sánh các nút với các bản ghi trong bảng

Nó như thể biểu đồ thuộc tính chứa rất nhiều bảng một hàng, tức là các nút của biểu đồ Các nút sẽ có các thuộc tính giống như các bản ghi

• Các mối quan hệ là rõ ràng: Chúng không được suy ra bởi một số loại ràng buộc hoặc được thiết lập tại thời điểm truy vấn thông qua một hoạt động nối Các mối quan hệ là bình đẳng trong cơ sở dữ

liệu; chúng có cùng sức mạnh biểu đạt như các nút đại diện cho các thực thể trong cơ sở dữ liệu

• Mối quan hệ cũng có thể có các thuộc tính: Chúng có thể có các giá trị được liên kết với chúng có thể chỉ định độ dài, dung lượng hoặc bất kỳ đặc tính nào khác của mối quan hệ đó Điều này cực kỳ quan trọng, và rất khác với bất cứ điều gì chúng ta biết từ thế giới quan

hệ

1.2.1.2 Mô hình đồ thị RDF

Trong một RDF mô hình đồ thị, việc bổ sung thông tin được biểu diễn bằng một nút riêng biệt Ví dụ, hãy tưởng tượng một tình huống trong đó người dùng phải thêm thuộc tính tên cho một người được biểu thị dưới dạng một nút riêng biệt trong biểu đồ Trong mô hình đồ thị thuộc tính có nhãn, điều này sẽ được thực hiện với việc bổ sung thuộc tính tên vào nút của một người Tuy nhiên, trong RDF, người dùng phải thêm một nút riêng biệt được

gọi là hasName kết nối nó với nút người gốc Cụ thể, một mô hình đồ thị RDF

bao gồm các nút và cung Ký hiệu đồ thị RDF hoặc một câu lệnh được biểu diễn bằng: một nút cho chủ đề, một nút cho đối tượng và một cung cho vị ngữ Một nút có thể để trống, một theo nghĩa đen và/hoặc được xác định bởi một URI Một cung cũng có thể được xác định bởi một URI Một ký tự cho một nút có thể có hai loại: đơn giản (không định kiểu) và đã định kiểu Một từ đơn giản có dạng từ vựng và có thể là một thẻ ngôn ngữ Một ký tự đã nhập được tạo thành từ một chuỗi có URI xác định một kiểu dữ liệu cụ thể Một nút trống có thể được sử dụng để minh họa chính xác trạng thái của dữ liệu khi dữ liệu không có URI [[14]]

Hình 1.13: Ví dụ dự đoán liên kết tình bạn trong mạng xã hội

1.2.2.2 Phân loại nút

Là bài toán phân loại từng nút trên đồ thị ứng với các nhãn tương ứng

Hình 1.14: Ví dụ về phân loại nút

1.2.2.3 Phân cụm và phát hiện cộng đồng

Phân cụm đồ thị đề cập đến việc phân nhóm dữ liệu dưới dạng đồ thị Hai dạng phân cụm riêng biệt có thể được thực hiện trên dữ liệu đồ thị Phân cụm theo đỉnh tìm cách gom các nút của biểu đồ thành các nhóm vùng được kết nối dày đặc dựa trên trọng số cạnh hoặc khoảng cách cạnh Dạng thứ hai của phân cụm đồ thị xử lý các đồ thị như các đối tượng được phân cụm và phân cụm các đối tượng này trên cơ sở tương tự Cách tiếp cận thứ hai thường gặp trong ngữ cảnh của dữ liệu có cấu trúc hoặc XML

Hình 1.15: Ví dụ về phân cụm đồ thị

1.2.3 Một số hệ quản trị cơ sở dữ liệu đồ thị tiêu biểu

Mặc dù cơ sở dữ liệu đồ thị không quá phổ biến như một số cơ sở dữ liệu NoSQL khác, nhưng có một số cơ sở dữ liệu đã trở thành tiêu chuẩn khá phổ biến khi nói về NoSQL:

1.2.3.1 Neo4j

Một trong những cơ sở dữ liệu đồ thị hàng đầu trên thế giới, nó vừa là

mã nguồn mở, vừa được xây dựng thú vị trên Java Nó cũng có ngôn ngữ truy vấn riêng, được gọi là Cypher, tương tự như ngôn ngữ SQL khai báo, nhưng được tạo ra để phù hợp với đồ thị Nó cũng hỗ trợ các ngôn ngữ phổ biến bên cạnh Java, chẳng hạn như Python, NET, JavaScript và một số ngôn ngữ khác

Neo4j lý tưởng cho những việc như quản lý trung tâm dữ liệu và phát hiện gian lận

1.2.3.2 RedisGraph

RedisGraph thực sự là một mô-đun đồ thị được tích hợp sẵn trong Redis, bản thân nó là một cơ sở dữ liệu NoSQL có khóa-giá trị Vì bản thân Redis được xây dựng trên cấu trúc dữ liệu trong bộ nhớ, nên RedisGraph được tạo ra để có dữ liệu được lưu trữ trong Ram Điều này dẫn đến một cơ

sở dữ liệu đồ thị hiệu suất cao, với khả năng truy vấn và lập chỉ mục nhanh chóng

RedisGraph cũng sử dụng Cypher, điều này thật tuyệt nếu bạn muốn có được sự linh hoạt hơn cho cơ sở dữ liệu với tư cách là một lập trình viên hoặc nhà khoa học dữ liệu

1.2.3.3 OrientDB

OrientDB là sự kết hợp của nhiều loại mô hình dữ liệu khác nhau và hỗ trợ đồ thị, kho lưu trữ tài liệu, lưu trữ khóa-giá trị và dựa trên đối tượng Điều

đó có nghĩa, tất cả các mối quan hệ được lưu trữ bằng cách sử dụng mô hình

đồ thị sử dụng kết nối trực tiếp giữa các cơ sở dữ liệu

Giống như hai cơ sở dữ liệu đồ thị trước đó, OrientDB cũng là mã nguồn mở và giống như Neo4j, nó được viết bằng Java nhưng nó không sử dụng ngôn ngữ truy vấn Cyper Ý tưởng đằng sau OrientDB là để sử dụng khi yêu cầu nhiều mô hình dữ liệu và do đó được tối ưu hóa để đảm bảo tính nhất quán của dữ liệu, cũng như giảm độ phức tạp của dữ liệu

1.3 Cơ sở dữ liệu đồ thị Neo4J

1.3.1 Giới thiệu

Neo4j là một hệ thống quản lý cơ sở dữ liệu đồ thị được phát triển bởi Neo Technology Inc và là cơ sở dữ liệu đồ thị phổ biến nhất hiện nay theo DB-Engines [[13]] Nó là một cơ sở dữ liệu tuân thủ tính ACID [[2]] chứa các

dữ liệu được cấu trúc dưới dạng đồ thị bao gồm các nút và các mối quan hệ giữa chúng Trong Neo4j, mọi thứ được lưu trữ ở dạng của một nút, một quan

hệ, hoặc một thuộc tính Mỗi nút và quan hệ có thể có một số lượng không giới hạn các thuộc tính Cả nút và quan hệ đều có thể được gắn nhãn Nhãn có thể được sử dụng để thu hẹp việc tìm kiếm

Đặc điểm của Neo4j:

 Biểu diễn mô hình dữ liệu hướng đồ thị một các trực quan

 Quản lý lưu trữ trên đĩa cứng, hoàn toàn tối ưu cho việc lưu trữ các cấu trúc đồ thị với hiệu năng lớn nhất và có khả năng mở rộng tối đa

 Neo4j có thể xử lý đọc và ghi hiệu suất nhanh như chớp, trong khi vẫn bảo vệ bạn toàn vẹn dữ liệu

 Một framework duyệt mạnh mẽ với tốc độ duyệt trên các nút cực nhanh trong không gian nút Độ sâu của quá trình duyệt có thể lên đến 1000 mức và dưới tốc độ 1 giây

 Giao dịch đầy đủ như một cơ sở dữ liệu thực sự, với đầy đủ các đặc tính ACID

1.3.2 Mô hình dữ liệu

1.3.2.1 Kiến trúc logic của Neo4j

Kiến trúc logic của Neo4j được mô tả theo hình dưới đây:

Hình 1.16: Kiến trúc logic của Neo4j

Trong đó:

- File system: là các file trên ổ cứng, được lưu trữ cẩn thận để tính toán các offset và tìm đến đến bất kỳ một record nào trong các file một cách nhanh nhất Ta lưu trữ tách biệt các nút, các quan hệ và các thuộc tính, và tối ưu trong những trường hợp chung nhằm để đảm bảo dữ liệu được tìm thấy trên 1 file

- Memory-mapped (N)IO: ta sử dụng java IO cho mục đích nhanh chóng

- Caches: cho phép làm việc nhanh chóng trên các đĩa quay, cho phép chúng ta duyệt hàng triệu phép duyệt mỗi giây trên một phần cứng của máy laptop

- CoreAPI : là phần nhân của Neo4j, lưu trữ các cấu trúc mức trừu tượng của đồ thị, mang tính hiệu quả cao

- Traversal Framework: tầng truy vấn dữ liệu

- JVM Language Bindings: các thành phần của Java API như Jruby, Jython, Scala,…

Hình 1.17: Nút, các mối quan hệ và tập thuộc tính

Một đồ thị đơn giản chỉ chứa 1 nút, và có thể chỉ chứa một thuộc tính

Ví dụ:

Hình 1.18: Ví dụ về một đồ thị đơn giản với 1 nút và 1 thuộc tính

Trong ví dụ trên, đồ thị có 1 nút có 1 thuộc tính tên là “name”, với giá trị là “Lam”

1.3.2.3 Mối quan hệ

Trong cơ sở dữ liệu đồ thị, các mối quan hệ giữa các nút là thành phần quan trọng của cơ sở dữ liệu đồ thị Chúng cho phép tìm kiếm các dữ liệu có liên quan với nhau Cũng giống như các nút, các mối quan hệ cũng có tập các thuộc tính

Hình 1.19: Mối quan hệ và các quan hệ liên quan

Một mối quan hệ kết nối 2 nút với nhau, gồm nút bắt đầu và nút kết thúc Mỗi mối quan hệ có kiểu quan hệ, mỗi kiểu quan hệ này được xác định bởi một tên (định danh) duy nhất Một mối quan hệ có tập các thuộc tính với các giá trị của các thuộc tính này

Một mối quan hệ luôn có hướng Chúng biểu diễn quan hệ đầu vào của

1 nút, và quan hệ đầu ra của 1 nút, dùng cho phép duyệt đồ thị:

Hình 1.20: Một mối quan hệ giữa nút bắt đầu và nút kết thúc

Hình 1.21: Quan hệ vào và quan hệ ra của một nút

Một nút cũng có thể tự có quan hệ với chính nó:

Hình 1.22: Quan hệ trên 1 nút

Để nâng cao hơn phép duyệt đồ thị tất cả các mối quan hệ có một kiểu quan hệ, có thể được xem là nhãn của một mối quan hệ

Cả nút và mối quan hệ đều có tập các thuộc tính

Thuộc tính là cặp khóa – giá trị trong đó khóa có kiểu là String (kiểu

mô tả này tương tự như kiểu dữ liệu Map trong Java) Các giá trị của thuộc tính có thể là 1 kiểu nguyên thủy, hoặc một mảng của nhiều kiểu nguyên thủy

Ví dụ : kiểu String, kiểu int, hoặc mảng int[]

Các thuộc tính không chứa giá trị null, nếu một thuộc tính có giá trị = null nghĩa là không tồn tại khóa đó trong tập các thuộc tính của các nút hay các mối quan hệ

Ví dụ:

Hình 1.24: Biểu diễn một thuộc tính

1.3.2.5 Đường đi

Một đường đi là một hay nhiều nút được kết nối với nhau bởi các mối quan hệ, thường được biểu diễn bằng kết quả của phép duyệt

Hình 1.25: Đường đi

Đường đi ngắn nhất có thể bằng 0 khi đó là đường đi từ 1 nút đến chính

nó, như hình dưới đây:

Hình 1.26: Đường đi đến chính nút đó bằng 0

Đường đi của một nút đến nút khác được biểu diễn như sau :

Hình 1.27: Đường đi từ nút 1 đến nút 2 có quan hệ relationship 1

1.3.2.6 Nhãn

Nhãn được sử dụng để nhóm các nút vào một bộ (tập hợp) Tất cả các nút có nhãn giống nhau cùng thuộc về một bộ Nhiều truy vấn cơ sở dữ liệu

có thể làm việc với các bộ thay vì toàn bộ đồ thị, làm cho các truy vấn dễ dàng hơn để viết và hiệu quả hơn Một nút có thể được gắn nhãn với bất kì số nào hoặc không, làm cho các nhãn trở nên không bắt buộc trong đồ thị

Hình 1.28: Biểu diễn một nhãn

1.3.2.7 Duyệt đồ thị

Duyệt đồ thị là cách truy vấn đồ thị, điều hướng từ bắt đầu từ một nút đến các nút có liên quan để trả lời cho các câu hỏi dạng như “Bạn của tôi thích thể loại nhạc nào?”, hay “Những người bạn của bạn tôi là ai?”,…

Duyệt một đồ thị nghĩa là đi thăm các nút của đồ thị đó, dựa trên các mối quan hệ giữa các nút theo một số quy tắc Trong một số trường hợp, chỉ

có một đồ thị con được thăm

Kết quả của duyệt đồ thị có thể trả về là một đường đi từ nút này đến nút kia

1.3.3 Ngôn ngữ truy vấn Cyper

Cypher là một ngôn ngữ truy vấn cơ sở dữ liệu đồ thị, với ngôn ngữ này chúng ta có thể tương tác như là truy vấn, cập nhập hay là quản trị một cách hiệu quả với cơ sở dữ liệu đồ thị Ngôn ngữ này được thiết kế giúp cho developer cũng như là các chuyên gia có thể thuận tiện khi làm việc với Neo4j Cypher vốn được thiết kế đơn giản, tuy nhiên nó rất mạnh mẽ [[11]]

Cypher được lấy cảm hứng từ rất nhiều các cách tiếp cận khác nhau, một số các từ khóa như là WHERE, ORDER BY được lấy cảm hứng từ ngôn ngữ SQL, trong khi đó pattern matching thì lại được mượn từ SPARQL Ngoài ra một vài ngữ nghĩa thì lại được mượn từ các ngôn ngữ khác như là Haskell và Python Cấu trúc của Cypher được xây dựng dựa trên ngôn ngữ Tiếng Anh với ngữ nghĩa thuận tiện cho người thao tác với ngôn ngữ, điều này giúp cho việc viết và đọc các câu query cũng dễ dàng hơn Dưới đây là một số câu truy vấn được tìm hiểu để xử lý trong khuôn khổ của luận văn này

Trong đó:

- MATCH: là những gì tìm kiếm một nút, mối quan hệ, nhãn, … tồn

tại trong cơ sở dữ liệu MATCH hoạt động khá giống SELECT trong SQL Chúng ta có thể tìm thấy tất cả các nhãn nút trong cơ sở dữ liệu, tìm kiếm một nút cụ thể, tìm tất cả các nút có mối quan hệ cụ thể, tìm kiếm các mẫu nút và mối quan hệ, v.v bằng cách sử dụng MATCH

+ WHERE: cung cấp các tiêu chí để lọc các mẫu kết quả phù hợp

- RETURN: Mệnh đề này quy định việc các nút, các mối quan hệ và

các thuộc tính trong dữ liệu được nối nên được trả về như thế nào cho client

Ví dụ: Cho nhãn HocSinh có 1 nút với thuộc tính {name: "Lam"}

MATCH (s: HocSinh {name: "Lam"}) RETURN s

 CREATE

Dùng để tạo nút:

CREATE (tên:Nhãn {thuộc tính: giá trị,…}), …

Ví dụ: Tạo thêm một node có nhãn Hocsinh với thuộc tính {name:

"Vy"}

CREATE (s: Hocsinh {name: "Vy"}) RETURN s Lưu ý: lệnh RETURN là không bắt buộc Nút vừa tạo nsẽ đứng độc lập

và chưa có mối quan hệ

Để thiết lập mối quan hệ cho nó, ta phải sử dụng MATCH để tránh lặp lại nút đã tạo

Ví dụ:

MATCH (lam: HocSinh {name: “Lam”}) MATCH (vy: HocSinh {name: “Vy”}) CREATE (lam)-[rel:IS_FRIEND_WITH]->(vy) Lưu ý: Nếu không có 2 lệnh MATCH như trên, Cypher sẽ tự động tạo các nút mới mà không kiểm tra xem nó đã tồn tại trong csdl hay chưa

 Cập nhật dữ liệu

Sử dụng MATCH SET để cập nhật thuộc tính cho đối tượng (nút, quan hệ):

- Xác định đối tượng: MATCH …

- Set giá trị cho các thuộc tính: SET dt.thuocTinh = giaTri

Ví dụ: Thêm thuộc tính birthday cho HocSinh Lam

MATCH (h: HocSinh {name: “Lam”}) SET h.birthday = date(“2004-03-01”)

Ví dụ: Chèn HocSinh Vy vào CSDL bằng MERGE

MERGE (vy: HocSinh {name: “Vy”}) RETURN vy

Nút vy đã tồn tại trong Csdl trước đó, nên câu lệnh trên sẽ không tạo thêm nút vy mới mà chỉ trả về nút vy đã có

MERGE trên 1 mối quan hệ: Sử dụng tương tự như Create Nếu mối quan hệ chưa được thiết lập, MERGE sẽ thực hiện tạo mới toàn bộ (mặc dù nút đã tồn tại)

Ví dụ: Thực hiện tạo mối quan hệ bạn bè giữa Lam và Vy

MATCH (l: HocSinh {name: “Lam”}) MATCH (v: HocSinh {name: “Vy”}) MERGE (l)-[r: IS_FRIEND_WITH]->(v) RETURN l, r, v

Sử dụng MATCH để thực hiện khớp dữ liệu trước khi tạo mối quan hệ Mối quan hệ này đã được tạo trước đó nên MERGE chỉ cần trả về dữ liệu đã tồn tại

Lưu ý: Nếu chỉ sử dụng MERGE mà không khớp dữ liệu sẽ dẫn đến việc lệnh MERGE tạo lại các nút đã tạo nếu không tìm thấy mối quan hệ giữa các nút đó dẫn đến bị lặp dữ liệu

WHERE NOT: trả về thuộc tính không khớp với mẫu

Ví dụ:

MATCH (hocsinh: HocSinh) WHERE NOT hocsinh.name = “Lam”

RETURN hocsinh Ngoài ra, WHERE còn có thể đi cùng với AND, OR, XOR

Truy vấn trong một phạm vi nhất định với WHERE:

Ví dụ:

MATCH (hocsinh: HocSinh) WHERE 2003 <= hocsinh.yearBirthday <= 2004 RETURN hocsinh

WHERE EXISTS(thuộc tính): kiểm tra sự tồn tại của một thuộc tính trong đối tượng, một quan hệ, v.v

Ví dụ:

Tìm những học sinh chưa có ngày sinh

MATCH (h: HocSinh) WHERE NOT EXISTS (h.Birthday) RETURN h

 WITH:

Dùng khi cần lấy kết quả truy vấn trong quá trình xử lý truy vấn và dùng nó làm điều kiện hay tính toán

WITH dùng với hàm tính toán để làm điều kiện

Ví dụ: tìm những trường PT có nhiều hơn 50 sinh viên học tại trường ĐHQN

MATCH (t:TruongPT)-[:HOCPT]-(s:SinhVien) WITH t, count(*) as sl

WHERE sl>50 RETURN t.tenTruong

1.3.4 Khoa học dữ liệu đồ thị

Khoa học dữ liệu đồ thị là một phương pháp tiếp cận theo hướng khoa học để thu thập kiến thức từ các mối quan hệ và cấu trúc trong dữ liệu, điển hình là để cung cấp các dự đoán Nó mô tả một bộ công cụ gồm các kỹ thuật giúp các nhà khoa học dữ liệu trả lời các câu hỏi và giải thích kết quả bằng cách sử dụng dữ liệu đồ thị

Trong phạm vi nghiên cứu của luận văn chỉ đi tập trung vào tìm hiểu Thư viện Khoa học Dữ liệu Đồ thị Neo4j (GDS)

Các phiên bản Neo4j được hổ trợ:

Hình 1.29: Các phiên bản Neo4j được hổ trợ thư viện GDS v1.6

Thư viện Khoa học Dữ liệu Đồ thị Neo4j (GDS) được cung cấp dưới dạng một plugin cho cơ sở dữ liệu Đồ thị Neo4j Plugin cần được cài đặt vào

cơ sở dữ liệu và được thêm vào danh sách cho phép trong cấu hình Neo4j

Hình 1.30: Cài đặt GDS ở cấp độ cơ sở dữ liệu

Thêm 2 dòng lệnh sau vào trong cấu hình Neo4j:

Hình 1.31: Cài đặt GDS trong cấu hình Neo4j

Điều này là cần thiết vì thư viện GDS truy cập các thành phần cấp thấp của Neo4j để tối đa hóa hiệu suất

Để kiểm tra phiên bản GDS ta vào trình duyệt Neo4j và gọi hàm gds.version()

RETURN gds.version()

Hình 1.32: Kiểm tra phiên bản GDS

Để liệt kê tất cả các thuật toán đã cài đặt trong GDS, sử dụng thủ tục gds.list():

Hình 1.33: Các thuật toán trong GDS

Có rất nhiều thuật toán GDS được trình bày trong [[11]]. Trong nội dung luận văn nghiên cứu chỉ tập trung tìm hiểu một số hàm GDS liên quan Điều này được mô tả chi tiết ở mục 2.2.2 của luận văn này

1.4 Tiểu kết chương 1

Trong nội dung chương đầu tiên này, luận văn đã trình bày các kiến thức cũng như các khái niệm về đồ thị, cơ sở dữ liệu đồ thị và Neo4j Đồng thời, luận văn cũng đã giới thiệu tổng quan về mô hình dữ liệu, ngôn ngữ truy vấn Cypher và thư viện khoa học dữ liệu đồ thị của Neo4j Trong chương tiếp theo, luận văn sẽ trình bày chi tiết về bài toán dự đoán liên kết và dự đoán liên kết trên cơ sở dữ liệu đồ thị Neo4j là nội dung chính của luận văn