Báo cáo chuyên đề cơ sở dữ liệu nâng cao
LỜI MỞ ĐẦU
«
Dữ liệu đã ra đời rất lâu, ngay cả lúc ngành công nghệ thông tin chưa khai sinh
đã có khái niệm dữ liệu rồi. Dữ liệu là tập hợp thông tin có cấu trúc. Tuy nhiên, thuật ngữ
này thường dùng trong công nghệ thông n và nó thường được hiểu rõ hơn dưới dạng một tập hợp
liên kết các dữ liệu, thường đủ lớn để lưu trên một thiết bị lưu trữ như đĩa hay băng. Dữ liệu này được
duy trì dưới dạng một tập hợp các tập n trong hệ điều hành hay được lưu trữ trong các hệ quản trị
cơ sở dữ liệu.
Ngày nay, với lượng dữ liệu khổng lồ, việc cập nhật và truy xuất dữ liệu thường xuyên, đây là
một thách thức không nhỏ đối với các hệ cở sở dữ liệu. Quá trình Am kiếm, phân Bch cấu trúc dữ liệu
của thông n, các chuyên gia nghiên cứu cơ sở dữ liệu đã cho ra đời một hệ cơ sở dữ liệu mới mà
thừa kế từ cơ sở dữ liệu quan hệ, cơ sở dữ liệu dạng key-value, cơ sở dữ liệu tài liệu, Column-Family,
đó là cấu trúc cơ sở dữ liệu đồ thị. Dữ liệu đồ thị là cách thức lưu trữ thông tin ở dạng đồ
thị những nút và cạnh.Nút của đồ thị sẽ có quan hệ đối với những nút khác thông qua
các cạnh của đồ thị. Với cách thức lưu trữ này, việc quản lý dữ liệu trở nên mềm dẽo
và dễ dàng hơn ngay cả trong việc ứng dụng tri thức vào khối dữ liệu lưu trữ.
Tiểu luận này trình bày một mã nguồn mở mà lưu dữ liệu dưới dạng cấu trúc sở
dữ liệu đồ thị, đó là Neo4j và ngôn ngữ truy vấn đồ thị thông minh Cypher.
Tiểu luận gồm có 5 chương:
Chương 1. Neo4j là một cơ sở dữ liệu đồ thị: giới thiệu về Neo4j và so sánh neo4j với
RDBMS, Key-Value, cơ sở dữ liệu tài liệu.
Chương 2. Cơ sở dữ liệu đồ thị Neo4j: đi vào chi tiết cơ sở dữ liệu được lưu trữ trên
Neo4.
HVTH: Nguyễn Thành Đệ Trang: 1
Báo cáo chuyên đề cơ sở dữ liệu nâng cao
Chương 3.Framework Java API: Các khái niệm cơ bản để duyệt đồ thị bằng Java API.
Chương 4. Ví dụ về mồ hình đồ thị và duyệt đồ thị: Chương này có ta các ví dụ về đồ
thị và truy vấn dữ liệu thông qua Java API và ngôn ngữ truy vấn đồ thị Cypher.
Chương 5. Ngôn ngữ truy vấn đồ thị Cyper: Chương này trình bày văn phạm trong
Cypher, các qui định và cách truy vấn đồ thị băng Cypher.
Chương 6. Kết luận
Em xin chân thành cảm ơn PGS.TS. Đỗ Phúc – Giảng viên môn học cơ sở dữ liệu nâng
cao đã truyền đạt những kiến thức vô cùng quý báu, xin chân thành cám ơn ban cố vấn
học tập và ban quản trị chương trình đào tạo thạc sĩ Công nghệ thông tin qua mạng
của Đại Học Quốc Gia TPHCM đã tạo điều kiện về tài liệu tham khảo để em có thể
hoàn thành môn học này.
Em xin chân thành cảm ơn
Nguyễn Thành Đệ
HVTH: Nguyễn Thành Đệ Trang: 2
Báo cáo chuyên đề cơ sở dữ liệu nâng cao
CHƯƠNG 1. NEO4J LÀ MỘT CƠ SỞ DỮ LIỆU ĐỒ THỊ
*Một cơ sở dữ liệu đồ thị : quản lý một → đồ thị và → cũng quản lý những mối quan
hệ → lập chỉ mục
Neo4j là một cơ sở dữ liệu mã nguồn mở. Nó được thiết kế dựa trên cơ sở dữ liệu quan
hệ. Tối ưu hóa bằng cấu trúc dữ liệu đồ thị thay vì là dữ liệu bảng. Khi làm việc với
Neo4j, cơ sở dữ liệu ứng dụng của bạn sẽ được biểu diễn bằng đồ thị, như đồ thị dưới
đây:
HVTH: Nguyễn Thành Đệ Trang: 3
Báo cáo chuyên đề cơ sở dữ liệu nâng cao
Hình 1. Cở sở dữ liệu đồ thị
1.1. So sánh các mô hình cơ sở dữ liệu
Cơ sở dữ liệu đồ thị lưu trữ cấu trúc dữ liệu bằng nút ( node) và mối quan
hệ(relationship) trong đồ thị. Vậy làm thế nào để ta so sánh với các mô hình cơ sở dữ
liệu khác? Bởi vì một đồ thị là một cấu trúc chung, sau đây là một vài so sánh với một
vài mô hình cơ sở dữ liệu khác.
1.1.1. Cơ sở đồ thị biến đổi thành RDBMS
Xóa bỏ cấu trúc ngăn xếp của bản tin trong cở sở dữ liệu quan hệ nhưng vẫn giữ
tất cả các quan hệ, và nó như một đồ thị gồm có cạnh(edges) và nút(node). RDBMS
được sử dụng để tối ưu hóa dữ liệu tổng hợp, còn Neo4j được dùng để tối ưu hóa kết
nối dữ liệu.
HVTH: Nguyễn Thành Đệ Trang: 4
Báo cáo chuyên đề cơ sở dữ liệu nâng cao
Hình 2.1. RDBMS
Hình 2.2. Cơ sở dữ liệu đồ thị bằng RDBMS
1.1.2. Xây dựng một cơ sở dữ liệu đồ thị như một cách lưu trữ Key-Value
Mô hình Key-value là một mô hình rất tốt và phổ biến cho việc tìm kiếm những
danh sách khóa hay giá trị. Khi các giá trị được kết nối với nhau, bạn sẽ nhận được một
đồ thị. Neo4j cho phép ta tạo cấu trúc dữ liệu đơn giản từ một cấu trúc phức tạp, dữ
liệu được kết nối.
Hình 2.3. Lưu trữ dạng Key-Value
HVTH: Nguyễn Thành Đệ Trang: 5
Báo cáo chuyên đề cơ sở dữ liệu nâng cao
Ghi chú: K* đại diện cho khóa(key) và V* đại diện cho giá trị(value). Một vài khóa
cũng có thể trỏ đến những khóa khác như trỏ đến giá trị vậy.
Hình 2.4. Cơ sở dữ liệu đồ thị lưu dạng Key-value
1.1.3. Cơ sở dữ liệu đồ thị cũng có liên quan đến mô hình Column-Family
Cơ sở dữ liệu Column-Family(BigTable) là mô hình cái tiến của key-value, sử
dụng từ “families” cho phép nhóm các dòng. Việc lưu trữ trong đồ thị, gia
đình(families) trở thành phân cấp, và giữ mối quan hệ giữa các dữ liệu, dữ liệu trở nên
tường mình.
1.1.4. Điều hướng cơ sở dữ liệu đồ thị như một lưu trữ tài liệu
Cơ sở dữ liệu tài liệu chứa những phân cấp rõ ràng, mô hình dữ liệu đơn giản
mà có thể dễ dàng chuyển đổi như mô hình cây. Dĩ nhiên đó là mô hình đồ thị. Tham
chiếu đến tài liệu khác(hoặc những phân tử trong tài liệu) như một cây và sẽ có nhiều
HVTH: Nguyễn Thành Đệ Trang: 6
Báo cáo chuyên đề cơ sở dữ liệu nâng cao
dữ liệu điện điện cho những dữ liệu tương tự nhau. Khi dùng Neo4j, mối quan hệ đó sẽ
dễ dàng hơn.
Hình 2.5. Lưu trữ dạng tài liệu
Ghi chú: D=tài liệu, S=tài liệu con,V=giá trị, D/S = tham chiếu đến tài liệu khác
Hình 2.6 Cơ sở dữ liệu đồ thị lưu trữ dạng tài liệu
HVTH: Nguyễn Thành Đệ Trang: 7
Báo cáo chuyên đề cơ sở dữ liệu nâng cao
CHƯƠNG 2 CƠ SỞ DỮ LIỆU ĐỒ THỊ NEO4J
Chương này sẽ nói rõ mô hình và cách thức hoạt động của Neo4j
2.1. Nút(Nodes)
Nền tản của mô hình đồ thị là nút(nodes) và các mối quan hệ(relationships) của
chúng. Trong Neo4j, cả hai nút và mối quan hệ của chúng có thể chưa thuộc tính của
chúng.
Nút thường được đại diện cho thực thể(entities), nhưng phục thuộc vào các mối quan
hệ cụ thể mà có thể được sử dụng với mục đích khác nhau.
Hình 2.7. Nút
Chúng ta bắt đầu với một đồ thị đơn giản là chỉ có một nút.
2.2. Mối quan hệ (Relationships)
HVTH: Nguyễn Thành Đệ Trang: 8
Name: Marko
Name: Marko
Nút
Nút
Báo cáo chuyên đề cơ sở dữ liệu nâng cao
Mối quan hệ giữa các nút là một bộ phận khóa của cơ sở dữ liệu đồ thị. Chúng
cho phép ta tìm mối liên hệ của dữ liệu. Cũng giống như nút, mối quan hệ có thể là
thuộc tính của thực thể(entities).
Hình 2.8. Mối quan hệ của các nút
Một quan hệ kết nối 2 nút và đảm bảo phải có nút bắt đầu và nút kết thúc
Những mối quan hệ trực tiếp, chúng có thể được xem như là cung đi ra(outgoing) và
cung đi vào(incoming) của nút. Ví dụ xem hình sau:
Chú ý rằng nút có thể quan hệ với chính nó:
HVTH: Nguyễn Thành Đệ Trang: 9
Nút bắt đầu Nút kết thúc
Quan hệ
Quan hệ đi vào
Quan hệ đi ra
Báo cáo chuyên đề cơ sở dữ liệu nâng cao
Tất cả các mối liên hệ có một kiểu quan hệ(relationship type). Ví dụ sau đây cho thấy
việc follow của một mạng xã hội đơn giản với hai kiểu quan hệ(relationship type)
Hình 2.9. Mối quan hệ có hướng và kiểu quan hệ
Sử dụng mối quan hệ có hướng và kiểu (type)
What How
người follow Mối quan hệ follows đi ra, độ sâu 1
Người được follow Mối quan hệ follows đi vào, độ sâu 1
Người block Mối quan hệ block đi ra, độ sâu 1
Người được block Mối quan hệ block đi vào, độ sâu 1
Ví dụ sau là một mô hình đơn giản của hệ thông tập tin:
HVTH: Nguyễn Thành Đệ Trang: 10
Báo cáo chuyên đề cơ sở dữ liệu nâng cao
Hình 2.10. Đồ thị và kiểu quan hệ
Để tìm kiếm file nào đó, chúng ta sử dụng mối quan hệ có hướng và kiểu của nút để
duyệt.
What How
Lấy đường dẫn của tập tin Mối quan hệ tập tin đi vào
Lấy toàn bộ đường dẫn của tập tin Mối quan hệ tập tin và symbolic link đi
vào
Lấy tất cả các tập tin trong một thư mục Mối quan hệ tập tin và symbolic link đi ra,
độ sâu 1
Lấy tất cả các tập tin trong thư mục và
chạy liên kết
Mối quan hệ tập tin đi ra, độ sâu 1
Lấy tất cả các tập tin trong thư mục, đệ
qui
Mối quan hệ tập tin và symbolic link đi ra
2.3. Thuộc tính(properties)
Cả hai nút(nodes) và mối quan hệ(relationship) đều có thể có thuộc
tính(properties). Thuộc tính là khóa-giá trị mà khóa là chuỗi. Giá trị thuộc tính có thể là
giá trị của một kiểu dữ liệu nào đó hoặc có thể làm mảng của một kiểu dữ liệu nào đó.
Ví dụ giá trị string, int[] là giá trị hợp lệ của thuộc tính.
HVTH: Nguyễn Thành Đệ Trang: 11
Báo cáo chuyên đề cơ sở dữ liệu nâng cao
Chú ý rằng NULL không là giá trị hợp lệ của giá trị thuộc tính. Nulls có thể được thay
thế là sự vắng mặt của khóa.
Hình 2.11. Kiểu dữ liệu đồ thị
Bảng kiểu giá trị thuộc tính:
Kiểu Mô tả Giá trị
Boolean True/false
Byte 8bit integer -128 đến 127
Short 16 bit integer - 32768 đến 32767
Int 32 bit integer - 2147483648 đến
2147483647
Long 64 bit integer
-9223372036854775808
đến 9223372036854775807
Float 32-bit IEEE 754 floating-
HVTH: Nguyễn Thành Đệ Trang: 12
Báo cáo chuyên đề cơ sở dữ liệu nâng cao
point number
double 64-bit IEEE 754 floating-
point number
Char 16-bit unsigned integers u0000 to uffff (0 to 65535)
String Chuỗi các ký tự Unicode
2.4. Đường kết nối (Paths)
Một đường kết nối có thể qua nhiều nút với việc kết nối qua các mối quan hệ, thông
thường là một truy vấn hay kết quả phép duyệt
Đường kết nối ngắn nhất có độ dài bằng 0, là độ thì có một nút. Độ dài của đường dẫn:
HVTH: Nguyễn Thành Đệ Trang: 13
Nút 1
Nút 2
Mối quan hệ 1
Báo cáo chuyên đề cơ sở dữ liệu nâng cao
2.5. Duyệt đồ thị
Duyệt đồ thị có nghĩa là viến thăm các nút, những mối quan hệ theo một số luật.
Hầu như các trường hợp chỉ là một đồ thị con được viến thăm. Như bạn đã biết mối
quan tâm lớn nhất của đồ thị là nút và mối quan hệ của nút.
Neo4j cung cấp cho chúng ta API mà cho phép chúng ta duyệt đồ thị theo nhiều phép
duyệt khác nhau. Chúng ta có thể duyệt theo chiều rộng, duyệt theo chiều sâu.
Neo4j cung cấp một framework Java API cho duyệt đồ thị, framework Java API này có
thể tham khảo ở địa chỉ www.neo4j.org. Ngoài ra cũng có lựa chọn khác ở Neo4j cho
phép duyệt đồ thị hoặc truy vấn đồ thị đó là Cypher và Grelin.
CHƯƠNG 3. FRAMEWORK NEO4J ĐỂ DUYỆT ĐỒ THỊ
Gói Neo4j Traversal API cung cấp ở địa chỉ:
/>ge-summary.html
3.1. Những khái niệm:
Sau đây là một số khái niệm:
- Expanders: Định nghĩa những gì sẽ duyệt, đặc biệt trong những mối quan hệ có
hướng và kiểu
- Order: Ví dụ như duyệt chiều sâu-chiều rộng
- Uniqueness: Thăm nút (Mối quan hệ, đường kết nối) chỉ một lần
- Evaluator: Khi dừng hoặc tiếp tục duyệt đồ thị thì những gì sẽ được trả về
- Starting node: Nút bắt đầu duyệt
HVTH: Nguyễn Thành Đệ Trang: 14
Báo cáo chuyên đề cơ sở dữ liệu nâng cao
3.2. Duyệt bằng Framework Java API
Framework duyệt đồ thị bao gồm một vài màn hình chính như Nút đến các mối
quan hệ như: TraversalDescription, Evaluator, Traverser và Uniquenese. Giao diện
paths cũng được hỗ trợ trong phép duyệt.
CHƯƠNG 4 . VÍ DỤ VỀ MÔ HÌNH ĐỒ THỊ VÀ DUYỆT ĐỒ THỊ
Chương này cung cấp cho chúng ta những ví dụ về việc sử dụng Neo4j để tạo nút, quan
hệ, và dùng các phép duyệt đồ thị.
Chúng ta nên tham khảo chương sau để biết việc sử dụng truy vấn Cypher.
4.1. Qui tắc user trong đồ thị
Đây là một đồ thị cho thấy qui tắc phân cấp. Sự quan tâm về cây đồ thị thật sự có lưu
trữ đủ cấu trúc dữ liệu này hay không, như nó có thể:
HVTH: Nguyễn Thành Đệ Trang: 15
Báo cáo chuyên đề cơ sở dữ liệu nâng cao
Hình 4.1 Ví dụ về cấu trúc dữ liệu đồ thị
Có thể xem chi tiết bài báo thảo luận về cách lưu trữ trực tiếp bằng đồ thị trong SQL
dựa trên DBs, cách lưu trữ Store Procedured.tại địa chỉ:
/>Graphs-DAG-o.
DAGs là hầu như là cây, như với một phép xoay nó có thể tìm đến những nút giống
nhau thông qua nhưng đường kết nối khác nhau. Những cây giới hạn bởi khả năng này,
mà đảm bảo chúng xử lý dễ dàng hơn. Trong trường hợp của chúng ta nó là “Ali” và
“Engin”, họ là admin và user như thật ra có thể truy cập thông qua những nút trong
nhóm đó của họ.
Trong bài báo giải pháp SQL Stored Procedured được cung cấp. Ý chính đã có một vài
hỗ trợ từ các nhà khoa học, việc tính toán lại tất cả các đường kết nối . Ưu nhược điểm
của hướng tiếp cận này:
HVTH: Nguyễn Thành Đệ Trang: 16
Báo cáo chuyên đề cơ sở dữ liệu nâng cao
- Giảm hiệu năng cho việc đọc.
- Hiệu năng thấp khi thêm dữ liệu
- Quá nhiều không gian lãng phí
- Tin cậy vào Store procedured
Trong Neo4j có những qui tắt lưu trữ khá đơn giản. Trong trường hợp này, chúng ta sử
dụng mối quan hệ PART_OF(hình 4.1) đến các nhóm phân cấp và quan hệ
MEMBER_OF(hình 4.1) đến mô hình thành viên trong những nhóm. Chúng ta cũng
kết nối những nhóm mức độ cao nhất đến những nút tham chiếu bởi quan hệ ROOT.
Điều này giúp chúng ta có được sự phân chia hữu ích của đồ thị. Neo4j không có
những kiểu quan hệ(relationship type) được xác định trước, bạn có thể tự do tạo bất kỳ
kiểu quan hệ và gán cho chúng bất kỳ ngữ nghĩa nếu bạn muốn.
4.1.1. Lấy thông tin admins
Node admins = getNodeByName( "Admins" );
Traverser traverser = admins.traverse(
Traverser.Order.BREADTH_FIRST,
StopEvaluator.END_OF_GRAPH,
ReturnableEvaluator.ALL_BUT_START_NODE,
RoleRels.PART_OF, Direction.INCOMING,
RoleRels.MEMBER_OF, Direction.INCOMING );
Kết quả xuất ra:
Found: Ali at depth: 0
Found: HelpDesk at depth: 0
Found: Engin at depth: 1
Found: Demet at depth: 1
Kết quả thu thập từ phép duyệt sử dụng đoạn mã này:
HVTH: Nguyễn Thành Đệ Trang: 17
Báo cáo chuyên đề cơ sở dữ liệu nâng cao
String output = "";
for ( Node node : traverser )
{
output += "Found: " + node.getProperty( NAME ) + " at depth: "
+ ( traverser.currentPosition().depth() - 1 ) + "\n";
}
Trong Ngôn ngữ truy vấn Cypher, truy vấn đơn giản hơn nhiều:
START admins=node(14)
MATCH admins<-[:PART_OF*0 ]-group<-[:MEMBER_OF]-user
RETURN user.name, group.name
Kết quả:
4.1.2. Lấy ra những thành viên nhóm của một user
Sử dụng phép duyệt của Framework Java API, cấu truy vấn giống như thế này:
Node jale = getNodeByName( "Jale" );
traverser = jale.traverse(
Traverser.Order.DEPTH_FIRST,
StopEvaluator.END_OF_GRAPH,
ReturnableEvaluator.ALL_BUT_START_NODE,
HVTH: Nguyễn Thành Đệ Trang: 18
Báo cáo chuyên đề cơ sở dữ liệu nâng cao
RoleRels.MEMBER_OF, Direction.OUTGOING,
RoleRels.PART_OF, Direction.OUTGOING );
Và kết quả:
Found: ABCTechnicians at depth: 0
Found: Technicians at depth: 1
Found: Users at depth: 2
Trong Cypher:
START jale=node(10)
MATCH jale-[:MEMBER_OF]->()-[:PART_OF*0 ]->group
RETURN group.name
4.1.3. Lấy ra tất cả nhóm.
Trong Java:
Node referenceNode = getNodeByName( "Reference_Node") ;
traverser = referenceNode.traverse(
Traverser.Order.BREADTH_FIRST,
StopEvaluator.END_OF_GRAPH,
ReturnableEvaluator.ALL_BUT_START_NODE,
RoleRels.ROOT, Direction.INCOMING,
HVTH: Nguyễn Thành Đệ Trang: 19
Báo cáo chuyên đề cơ sở dữ liệu nâng cao
RoleRels.PART_OF, Direction.INCOMING );
Kết quả:
Found: Admins at depth: 0
Found: Users at depth: 0
Found: HelpDesk at depth: 1
Found: Managers at depth: 1
Found: Technicians at depth: 1
Found: ABCTechnicians at depth: 2
Trong Cypher:
START refNode=node(16)
MATCH refNode<-[:ROOT]->()<-[:PART_OF*0 ]-group
RETURN group.name
4.1.4. Lấy ra tất cả thành viên của tất cả các nhóm
Trong java:
traverser = referenceNode.traverse(
Traverser.Order.BREADTH_FIRST,
StopEvaluator.END_OF_GRAPH,
HVTH: Nguyễn Thành Đệ Trang: 20
Báo cáo chuyên đề cơ sở dữ liệu nâng cao
new ReturnableEvaluator()
{
@Override
public boolean isReturnableNode(
TraversalPosition currentPos )
{
if ( currentPos.isStartNode() )
{
return false;
}
Relationship rel =
currentPos.lastRelationshipTraversed();
return rel.isType( RoleRels.MEMBER_OF );
}
},
RoleRels.ROOT, Direction.INCOMING,
RoleRels.PART_OF, Direction.INCOMING,
RoleRels.MEMBER_OF, Direction.INCOMING );
Và Kết quả:
Found: Ali at depth: 1
Found: Engin at depth: 1
Found: Burcu at depth: 1
Found: Can at depth: 1
Found: Demet at depth: 2
Found: Gul at depth: 2
Found: Fuat at depth: 2
Found: Hakan at depth: 2
HVTH: Nguyễn Thành Đệ Trang: 21
Báo cáo chuyên đề cơ sở dữ liệu nâng cao
Found: Irmak at depth: 2
Found: Jale at depth: 3
Trong Cypher:
START refNode=node(16)
MATCH refNode<-[:ROOT]->root, p=root<-[PART_OF*0 ]-()<-[:MEMBER_OF]-
user
RETURN user.name, min(length(p))
ORDER BY min(length(p)), user.name
Và kết quả:
4.2. Cấu trúc ACL trong đồ thị
HVTH: Nguyễn Thành Đệ Trang: 22
Báo cáo chuyên đề cơ sở dữ liệu nâng cao
Ví dụ này cho ta một cái nhìn tổng quát của hướng tiếp cận danh sách điều
khiển truy cập(Access Control Lists) trong đồ thị và đơn giản hóa những câu truy vấn
phức tạp.
4.2.1. Hướng tiếp cận tổng quát:
Trong nhiều kịch bản, một ứng dụng cần phải xử lý bảo mật trên một vài hình
thức của đối tượng quản lý. Ví dụ này mô tả một mẫu để xử lý điều này thông qua việc
sử dụng cấu trúc đồ thị và phép duyệt đồ thị mà xây dựng một cơ cấu cấp phép đầy đủ
cho bất kỳ một đối tượng quản lý với khả năng ghi đè hoặc loại trừ chúng. Chức năng
này được xây dựng động của ACLs dựa trên vị trí và ngữ cảnh của đối tượng.
Kết quả là một mô hình an ninh phức tạp mà có thể dễ dàng được cài trong cấu trúc đồ
thị. Hỗ trợ chỉnh sửa cấp phép. Thành phần nội dung và dữ liệu, đảm bảo dữ liệu không
trùng bất kỳ nơi nào.
HVTH: Nguyễn Thành Đệ Trang: 23
Báo cáo chuyên đề cơ sở dữ liệu nâng cao
Hình 4.2. Ví dụ về ACL
Kỹ thuật
- Như đã thấy trong ví dụ trên: Có một vài khái niệm khóa trong mô hình này
- Quản lý nội dung(tập tin, thư mục) được kết nối bằng mối quan hệ
HAS_CHILD_CONTENT
- Cây con Principal chỉ ra principal mà có thể hành động bằng thành viện ACL,
chỉ ra bởi mối quan hệ PRINCIPAL
- Tập hợp principals vào trong những nhóm, được kết nối bằng mối quan hệ
IS_MEMBER_OF. Một principals(nhóm hoặc người dùng) có thể là bộ phận
của nhiều nhóm tại một thời điểm.
- Mối quan hệ Security : Việc kết nối cấu trúc hỗn hợp nội dung với cấu trúc hỗn
hợp principals, chứa thuộc tính thêm/xóa(“+RW”)
Xây dựng ACLs
Tính toán các quyền có hiệu lực(ví dụ: đọc,ghi,thực thi)cho một principal để đưa ra bất
kỳ nút quản lý ALC(nội dung) cho phép một số qui tắc thành viên mà có thể được mã
hóa vào trong quyền duyệt :
Duyệt Top-down:
Hướng tiếp cận này cho phép chúng ta định nghĩa mẫu cấp quyền chung trên nội dung
ban đầu. Và sau đó điều chỉnh nội dung các nút con cho phù hợp.
1. Đặt câu hỏi duyệt từ dưới lên bắt đầu tại nút content đến nút content ban đầu để
xác định đường kết nối của nó.
2. Bắt đầu với một danh sách hiệu quả bảo mật “được phép” được mã hóa là 111
hoặc nếu không đảm bảo kbaor mật thì sẽ được mã hóa là 000(mọi thứ sẽ cấm
nếu như nó không tường minh)
HVTH: Nguyễn Thành Đệ Trang: 24
Báo cáo chuyên đề cơ sở dữ liệu nâng cao
3. Bắt đầu với nút content trên cùng, tìm kiếm bất kỳ mối quan hệ SECURITY trên
nó.
4. Nếu tìm thấy, nếu câu hỏi principal là một bộ phận của mối quan hệ
SECURITY principal kết thúc
5. Nếu đúng, thêm “+” đến ma
Ví dụ:
Bây giờ, để nhận kết quả quyền truy cập cho “user 1” trên “My File.pdf” theo hướng
top-down trên mô hình đồ thị trên như sau:
1. Duyệt trở lên, Chúng ta bắt đầu với “Root folder”, và cấp quyền là 11(chỉ đọc
và ghi)
2. Có hai mối quan hệ SECURITY đến folder đó. User 1 chứa hai mối quan hệ
đó, nhưng “root” mang tính chất chung hơn, vì thế nó cấp quyền “All
principals” +W +R ->11
3. “Home” không có mối quan hệ SECURITY, và tiếp tục.
4. “user1 Home” có quan hệ SECURITY, đầu tiên cấp quyền "Regular Users" (-R
-W) → 00, sau đó "user 1" (+R +W) → 11.
5. Nút mục tiêu là "My File.pdf" không có quan hệ SECURITY. Vì thế cấp quyền
cho “user 1” trên “My File.pdf” là ReadWrite->11
4.2.2. Ví dụ quyền đọc
Trong ví dụ này, chúng ta sẽ kiểm tra một cấu trúc cây directories và files. Có
những file của users tạo và có những qui tắc mà users có thể được gán. Những qui tắc
có thể là quyền truy cập đến directories hoặc files (và ở đây mô hình của chúng ta là có
thể đọc ).
Tìm tất cả các files trong directories
Lệnh để tìm các files chứa trong cấu trúc directories này, chúng ta cần có một biến
để chứa tất cả mối quan hệ và thông tin nút đến nút lá.
HVTH: Nguyễn Thành Đệ Trang: 25