Về tổng quát, ta chia phƣơng pháp này ra các bƣớc chính sau:
i) Tính toán các ánh xạ (các bƣớc 1-3); ii) Tính toán các kế thừa mới (các bƣớc 4-6); iii) Phát hiện lỗi kế thừa (bƣớc 7);
iv) Sửa lỗi kế thừa (các bƣớc 8-12).
Ta sẽ phân tích chi tiết các bƣớc của thuật toán ContentMap ở phần tiếp theo.
Tính toán các ánh xạ (bƣớc 1-3)
Ánh xạ ontology có thể đƣợc tính toán bằng cách sử dụng một hay nhiều công cụ ánh xạ (bƣớc 1), và kết quả các ánh xạ có thể đƣợc tinh chỉnh (ở bƣớc Lines 1- 2 Lines 3- 6 Lines 7- 8 Line 9 Lines 10- 12
No Yes O1, O2 Compute & Select Mappings Input O1, O2 Mappings M No Compute Diffs Compute Plans Finish Select Entailments &O- scope Execute Yes modified O1, O2 Mappings M
2) theo nhiều cách khác nhau (nhƣ bằng phép chọn dựa vào hàm ngƣỡng). Sau khi nhận đƣợc các ánh xạ đã đƣợc tinh chỉnh, ta có thể quyết định kết thúc tiến trình tích hợp (bƣớc 3) hoặc tiếp tục phân tích ngữ nghĩa trong các ontology để đi đến việc tích hợp.
Tính toán các kế thừa mới (bƣớc 4-6)
Để nắm đƣợc những ảnh hƣởng về ngữ nghĩa của phép tích hợp, ta cần biết rằng những kế thừa mới đƣợc sinh ra sẽ đƣợc lƣu lại trong ontology tích hợp U, thay vì trong O1, O2 và M một cách độc lập. Ở đây, ta sử dụng khái niệm về sự khác biệt của suy luận (deductive difference). Sự khác biệt của suy luận giữa O và O‟ đƣợc gọi là ∑, với ∑ là tập các kế thừa đƣợc xây dựng sao cho ∑ chỉ đƣợc lƣu trong O‟ mà không phải là O. Tập khác biệt của phép suy dẫn giữa ontology O và O' đƣợc đƣa ra theo công thức sau:
diff ∑(O,O')={α| α là một mệnh đề, O⊭ α, O'⊨α và Sig(α ⊆ ∑}
Trong công thức trên, sự khác biệt của phép suy luận giữa ontology O và O' chính là một tập hợp gồm các mệnh đề α đƣợc suy dẫn từ O' nhƣng không đƣợc suy dẫn từ O.
Ta gọi các mapping mới khi đó là tập các kế thừa của hai ontology ∑1 và ∑2 sao cho:
∑1∩ ∑2= {⊤, ⊥} và ∑=∑1∪ ∑2. Khi đó, mdiff là tập khác biệt diff ∑(O, O‟) gồm tất cả các mệnh đề α, với α là ánh xạ trên DL giữa ∑1 và ∑2, sao cho tập các mệnh đề α là (Sig(α) ∩ ∑i)\ {┴,T }= ∅ với mọi i ∈ {1,2}. Mệnh đề α đƣợc đánh dấu bằng một id và một chỉ số tin cậy 0<conf(α)≤1.
mdiff∑1,∑2(O,O‟) = { α ∈ mdiff ∑(O,O‟) | α là một ánh xạ giữa ∑1,∑2} Khái niệm tập khác biệt về suy luận đôi khi có một số hạn chế. Đầu tiên, đó là vì không có thuật toán để tính toán diff∑(O,O‟) một các cụ thể. Thứ hai, có thể số lƣợng kế thừa là vô cùng. Vậy nên, bên cạnh khái niêm này, ta cần có sự tinh chỉnh bằng một phép xấp xỉ (ta có thể chọn ở bƣớc 5). Với diff ≈ ∑(O,O‟) (tƣơng ứng là mdiff ≈ ∑1,∑2 ( O,O‟)) là sự xấp xỉ cho diff∑ (O,O‟) (tƣơng ứng mdiff∑1,∑2 (O,O‟)), ta luôn có diff ≈ ∑(O,O‟) ⊆ diff∑(O,O‟) (tƣơng ứng mdiff≈∑1,∑2(O,O‟) ⊆ mdiff∑1,∑2(O, O‟))
ContentMap cho phép ngƣời dùng tùy chỉnh các phép xấp xỉ bằng cách chọn các kế thừa đozn giản sau đây, với A, B là các khái niệm hạt nhân (bao gồm ⊤, ⊥) và R, S là các vai trò hạt nhân hay nghịch đảo của vai trò hạt nhân:
(i)A ⊑ B, (ii) A ⊑ ¬B, (iii) A ⊑∃R.B, (iv) A ⊑∀R.B,
và (v) R ⊑ S.
Phép xấp xỉ bé nhất chỉ xem xét các phép suy dẫn của mệnh đề (i). Trong khi phép xấp xỉ lớn nhất lại xem xét toàn bộ các phép suy dẫn có thể tạo ra (từ i đến v).
ContentMap thực hiện nhiều lần tối ƣu hóa để tính toán các kế thừa. Các lớp của kế thừa mới càng lớn thì ta càng phát hiện ra lỗi.
Phát hiện lỗi kế thừa (bƣớc 7)
Một số kế thừa trong tập các khác biệt có thể dự đoán đƣợc là lỗi, trong khi một số khác chỉ phát hiện thông qua lỗi ở ontology mới sinh (ontology tích hợp) U . Bƣớc 7 thực hiện chọn các kế thừa:
(i) Kế thừa đúng và có thể đƣợc kế thừa trong U (kí hiệu T+ ), (ii) Kế thừa không đúng và không nên kế thừa bởi U (kí hiệu T-). Ngƣời dùng đƣợc chọn hai giá trị ngƣỡng T1 và T2 với 0< T1 ≤ T2 ≤0. Giả sử, có một mệnh đề α trong tập khác biệt, ta có
Λ = diff ≈ ∑1 (O1,U) ∪ diff ≈ ∑2 (O2,U) ∪ mdiff ≈ ∑1,∑2(M,U)
Khi đó, α đƣợc xem là lỗi nếu chỉ số tin cậy conf(α) ≤ T1 (đƣợc ContentMap đánh dấu là T-) và đƣợc xem là hợp lệ nếu chỉ số độ tin cậy conf(α)≥ T2 (đƣợc ContentMap đánh dấu là T+).
ContentMap chỉ ra sự phụ thuộc giữa các kế thừa để tiến hành tổ chức lại chúng. Nếu kế thừa β phụ thuộc vào α trong O , và α bị bỏ đi thì β cũng bị vô hiệu. Điều này ám chỉ rằng nếu α∈ T-, thì β cũng nằm trong T- (và không bao giờ thuộc T+).
Sửa lỗi kế thừa (bƣớc 8-12)
Ontology tích hợp U sẽ chứa lỗi nếu vẫn còn các kế thừa lỗi (nghĩa là T-
≠∅). Ta có thể sửa lỗi bằng cách bỏ đi các mệnh đề sai từ U . Tuy nhiên, bất kì mệnh đề nào bị loại thì cũng phải tuân theo tập T+. Bởi các phép suy dẫn trong
T+ sẽ vẫn đƣợc giữ lại sau khi thực hiện loại bỏ các mệnh đề.
Giả sử, cho O, T +, T-, O- là các tập độc lập chứa mệnh đề thoả mãn: O-
⊆O, O⊨ T-, O⊨ T+ và T+ ∩ T- =∅. Khi đó, một giải pháp sửa lỗi cho O tạo bởi O- , T+, T– là một tập P⊆ O- thoả mãn:
(1) ( O\ P) ⊨α với mọi α ∈ T+
Trong khái niệm trên, ta có một quy trình đơn giản để tính toán toàn bộ các giải pháp sửa lỗi:
Với mỗi P ⊆ O-, ta dùng một bộ suy luận để kiểm tra xem P có phải là một giải pháp sửa lỗi đúng, tức là điều kiện 1, 2 từ định nghĩa trên có thoả mãn. Phƣơng pháp trên dựa theo giả thuyết sau:
(i) Để α ∈ T + đƣợc giữ lại sau khi thực hiện cách giải quyết P, ontology O\ P phải chứa ít nhất một luận chứng cho α trong O. (ii) Để β ∈ T – không đƣợc giữ lại, ta cần chỉ ra rằng không có phép chứng minh β nằm trong O\P (với β nằm trong O ) (dòng 11-13).
Tập các cách giải đơn giản nhất sẽ đƣợc tìm ra chỉ khi tìm thấy toàn bộ các cách giải có thể.
Chú ý rằng, nếu có xung đột giữa T+ với T- thì có thể khiến cho không thể tìm ra bất kì giải pháp sửa lỗi nào. Trong trƣờng hợp đó, giả sử có O, T+, T-, O- và thoả mãn các điều kiện trong định nghĩa trên và O⊨ α, β. Nếu α > β trên O, α ∈T- thì không tồn tại cách sửa lỗi nào.
CHƢƠNG 4. XÂY DỰNG ỨNG DỤNG
4.1. Bài toán ứng dụng
4.1.1. Yêu cầu thực tế
Ngân hàng Chính sách xã hội Việt Nam là một tổ chức tài chính vi mô, hoạt động không vì mục đích lợi nhuận mà vì mục tiêu xóa đói giảm nghèo và an sinh xã hội. Đối tƣợng vay vốn của Ngân hàng Chính sách xã hội là hộ nghèo và các đối tƣợng chính sách khác. Các chƣơng trình cho vay phần lớn do Chính phủ quy định và có nhiều ƣu đãi về lãi suất. Với cơ chế cho vay theo hộ gia đình là chủ yếu, các phòng giao dịch, điểm giao dịch đƣợc thành lập theo địa giới hành chính. Vì thế, khi Chính phủ có những thay đổi về địa giới hành chính thì việc chia tách, sáp nhập hai phòng giao dịch là việc làm tất yếu.
Ngoài ra, cũng có những trƣờng hợp ngoại lệ, không phải do Chính phủ thay đổi địa giới hành chính mà vẫn phải sáp nhập hai phòng giao dịch với nhau, chẳng hạn nhƣ một số phòng giao dịch của các quận của thành phố Hà Nội. Ở các quận nội thành Hà Nội, loại đối tƣợng thuộc diện vay vốn ít, các chƣơng trình cho vay đối với các đối tƣợng này cũng ít, do đó dƣ nợ của các phòng giao dịch này rất thấp. Mặt khác, chi phí cho các phòng giao dịch này rất cao: phần lớn các phòng giao dịch đều phải đi thuê địa điểm để làm việc, nhân sự đông và không thể cắt giảm vì mỗi bƣớc cho vay, mỗi nghiệp vụ ngân hàng đều phải thực hiện đầy đủ theo quy trình. Do đó, việc sáp nhập các phòng giao dịch khi không có thay đổi địa giới hành chính của Chính phủ là thực sự cần thiết. Điều đó dẫn đến yêu cầu tích hợp dữ liệu của các phòng giao dịch với nhau là tất yếu.
Mặc dù vẫn dựa trên một cấu trúc chung và cơ bản, nhƣng do dữ liệu phân tán, không tập trung nên mỗi phòng giao dịch vẫn có thể tự thêm, bớt hay thay đổi tên gọi các trƣờng dữ liệu để tự quản lý dữ liệu tại đơn vị sao cho hiệu quả. Do đó, khi sáp nhập hai phòng giao dịch với nhau gặp phải vấn đề các thông tin không đồng nhất, mặc dù về bản chất thì nội dung của nó có chức năng nhƣ nhau. Một ví dụ đơn giản, cùng là trƣờng thông tin về tên khách hàng, nhƣng phòng giao dịch A lại gọi trƣờng này là Tên Khách hàng, trong khi đó phòng giao dịch B lại gọi là Họ và tên Khách hàng.
Nhƣ vậy, yêu cầu bài toán đặt ra là làm thế nào để hợp nhất các dữ liệu mà không có sự trùng lặp hay nhầm lẫn các trƣờng dữ liệu.
Hiện nay, hệ thống Ngân hàng Chính sách xã hội đang sử dụng các phần mềm đƣợc viết bởi các phần mềm lập trình Foxpro For Dos, Foxpro For Win, thông tin dữ liệu còn phân tán không tập trung, mỗi phòng giao dịch quản lý một cơ sở dữ liệu riêng biệt và có những khái niệm riêng.
Nhƣ đã trình bày ở trên, ý nghĩa lớn nhất của ontology chính là chia sẻ những hiểu biết chung về các khái niệm, cấu trúc thông tin giữa con ngƣời hoặc giữa các hệ thống phần mềm không những trong lĩnh vực Web ngữ nghĩa mà còn trong nhiều ngành và lĩnh vực khác.Trong trƣờng hợp của Ngân hàng chính sách, có thể hình dung nếu có một ontology chứa tất cả các khái niệm của ngân hàng thì đó có thể coi nhƣ một cuốn từ điển chuyên ngành của ngân hàng giúp cho việc thống nhất trong xây dựng cơ sở dữ liệu trở nên đơn giản hơn. Tên các khái niệm trên ontology khi đó là duy nhất giúp cho thông tin là nhất quán và tƣờng minh.
Phƣơng pháp tích hợp ontology hoàn toàn có thể giải đƣợc bài toán về việc sáp nhập các phòng giao dịch tại Ngân hàng chính sách. Đối với hệ thống hiện tại, việc sáp nhập diễn ra khá nhiều, việc tích hợp dữ liệu bằng ontology sẽ giảm bớt thời gian, chi phí cho việc làm sạch và chuẩn hóa dữ liệu cũng nhƣ tăng độ chính xác của tích hợp. Việc tái sử dụng dữ liệu giữa các phòng giao dịch khác nhau nhờ đó cũng sẽ giúp ích rất nhiều cho ngân hàng. Một số dịch vụ gia tăng có thể đƣợc tạo ra khi sử dụng ontology. Ví dụ nhƣ nhờ ontology, ngân hàng có thể thực hiện việc tìm ra các khách hàng uy tín, khách hàng tiềm năng để có chế độ đãi ngộ đặc biệt nhằm tăng sức hấp dẫn của ngân hàng.
4.1.2. Bài toán ứng dụng
Trong phạm vi luận văn này, tôi xin đƣa ra bài toán áp dụng cho tích hợp ontology nhƣ sau:
Ngân hàng Chính sách xã hội có hai phòng giao dịch Ba Đình và Tây Hồ đƣợc lên kế hoạch sáp nhập với nhau. Mỗi phòng giao dịch đều có cơ sở dữ liệu riêng với các khách hàng khác nhau. Trong đó, các khách hàng tại hai phòng giao dịch đều có thông tin riêng biệt và mở tài khoản tiết kiệm và vay vốn riêng tại mỗi phòng giao dịch.
Tuy nhiên, do Ngân hàng Chính sách xã hội còn sử dụng dữ liệu phân tán chƣa đƣợc tập trung nhƣ các ngân hàng thƣơng mại khác, nên vấn đề không đồng nhất dữ liệu giữa các phòng giao dịch vẫn còn diễn ra. Ví dụ, việc gọi tên các trƣờng dữ liệu vẫn còn sự khác biệt do có khác biệt về hành chính và địa lý.
Nhƣ vậy, việc sáp nhập hai phòng giao dịch phải yêu cầu đảm bảo không thay đổi thông tin của tất cả các khách hàng, đặc biệt là thông tin về các tài khoản của khách hàng. Sau khi sáp nhập, cơ sở dữ liệu mới phải có thông tin của tất cả các khách hàng một cách đầy đủ và chính xác.
Để giải bài toán này bằng phƣơng pháp tích hợp ontology, tôi sẽ tiến hành theo các bƣớc sau:
Xây dựng hai ontology tƣơng ứng của hai phòng giao dịch Ba Đình và Tây Hồ bởi hệ soạn thảo Protégé;
So khớp hai ontology bởi chƣơng trình Align. Ở bƣớc này sẽ phát hiện ra những điểm đồng nhất và không đồng nhất trong cách gọi tên trong cơ sở dữ liệu ở hai phòng giao dịch;
Tích hợp hai ontology bởi ContentMap. Sau khi tích hợp, ontology mới có đầy đủ thông tin của tất cả các khách hàng của cả hai phòng giao dịch.
4.2. Thực hiện tích hợp
4.2.1. Xây dựng ontology
Do trên thực tế bài toán sáp nhập hai phòng giao dịch là bài toán lớn, thông tin dữ liệu nhiều nên trong phạm vi luận văn này, tôi chỉ xin trích một số thông tin cơ bản nhất của khách hàng đang đƣợc quản lý ở Ngân hàng Chính sách xã hội đƣa vào ứng dụng. Các thông tin dữ liệu đầy đủ của các phân hệ tín dụng, phân hệ tiết kiệm, phân hệ kế toán sẽ đƣợc đƣa vào ứng dụng để làm hƣớng phát triển cho đề tài sau này.
Sử dụng hệ soạn thảo Protégé 4.0, tôi xây dựng hai ontology tƣơng ứng của hai phòng giao dịch Ba Đình và Tây Hồ.
File OntologyBADINH.owl mô tả ontology của phòng giao dịch Ba Đình:
Các lớp gồm:
HSKH: biểu diễn toàn bộ thông tin của khách hàng.
HS_TIETKIEM: biểu diễn toàn bộ thông tin về sổ tiết kiệm của khách hàng. Lớp này gồm các lớp con:
• HS_TK_COTHOIHAN: biểu diễn toàn bộ thông tin của các sổ tiết kiệm có thời hạn.
• HS_TK_VOTHOIHAN: biểu diễn toàn bộ thông tin của các sổ tiết kiệm không thời hạn.
HS_TINDUNG: biểu diễn toàn bộ thông tin về hồ sơ tín dụng của khách hàng. Lớp này có các lớp con:
• HS_HSSV: biểu diễn toàn bộ thông tin về hồ sơ tín dụng thuộc chƣơng trình cho vay học sinh sinh viên.
• HS_SXKD: biểu diễn toàn bộ thông tin về hồ sơ tín dụng thuộc chƣơng trình cho vay sản xuất kinh doanh.
• HS_HN: biểu diễn toàn bộ thông tin về hồ sơ tín dụng thuộc chƣơng trình cho vay hộ nghèo.