5. B ốc ục của luận văn
2.3.4. Phân loại và định danh
Phân loại (Classification): là sắp xếp các biểu thức sự kiện thành các nhóm.
Các bước tiến hành phân loại và định danh như sau :
- Phân tích cấu trúc của các biểu thức sự kiện sơ cấp trong cùng nhóm thành các mẫu đối tượng hoặc mẫu nhãn theo quy tắc sau: Nếu một phần của
biểu thức sự kiện định ra một đối tượng có nghĩa trong thế giới khách quan thì phân loại nó là một biểu thức mẫu đối tượng, ngược lại đó là một mẫu nhãn. Mẫu đối tượng thì được biểu thị bằng dấu gạch chân đôi, mẫu nhãn thì được biểu thị bằng dấu gạch chân đơn.[3]
Ví dụ:Phân loại và định danh cho bài toán phân bổ giảng viên chủ nhiệm.
Bảng 2.1. Ví dụ về phân loại và định danh cho bài toán
Ghi chú: :Biểu thức nhãn :Biểu thức đối tượng
Giang _Vien :
“Tồn tại giảng viên mang mã là ID04” Mã_giảng_viên
F1: “Tồn tại giảng viên mang mã là <Mã_giảng_viên>”
Ten_Giang_Vien:
“Giảng viên ID04 tên là ĐỗĐức Anh” Giảng_Viên: 01 Họ_tên
‘Giảng viên ID04’ Mã_giảng_viên
F2: “<Giảng Viên: O1> tên là <Họ
tên>”
O1: Giảng_Viên <Mã_giảng_Viên>
Định danh và phân loại
Hình 2.2. Quá trình phân loại và định danh biểu thức sự kiện bằng công cụ Casetalk
2.3.5. Xây dựng sơ đồ ngữ pháp thông tin IGD
Qua quá trình phân loại và định danh chúng ta đã thấy được sự xuất hiện của các mối quan hệ trong các biểu thức sự kiện. Trong thực tế thì các dự án thường là các dự án lớn với khối lượng biểu thức sự kiện khổng lồđiều này sẽ
dẫn tới các nhà phân tích cũng như các nhà hệ thống dễ bị lạc, sai sót. Chính vì vậy mà FCO-IM đã sử dụng một sơ đồđể giải quyết vấn đề đó, đó chính là
Sơ đồ ngữ pháp thông tin IGD (Information Grammar Diagram) để mô
phỏng các biểu thức sự kiện (biểu mẫu, đối tượng, mẫu nhãn) và mối quan hệ
Hình 2.3. Quy ước các biểu tượng đồ họa trong IGD
Giải thích về hình 2.3
- Một mẫu sự kiện được mô tả bởi một số hình chữ nhật được kết nối theo chiều ngang, được gọi là role của các mẫu sự kiện. Mỗi role có mỗi chỗ trống cho mỗi biểu thức mẫu sự kiện tương ứng (hoặc biểu thức mẫu sự kiện tương
ứng). Thứ tự xuất hiện của mỗi role là không quan trọng. Mẫu sự kiện unary chỉ có một role, mẫu sự kiện binary có hai role và mẫu sự kiện ternary có ba role. Mẫu sự kiện với n role được gọi là mẫu sự kiện n-ary.
- Mẫu nhãn được vẽ như một vòng tròn nét đứt.
- Mẫu sự kiện nominalized được như một vòng tròn hay một hình elip bao quanh một mẫu sự kiện trong đó các mẫu đối tượng là một nominalization.
- Đường nối giữa role và với các mẫu nhãn hay một mẫu sự kiện nominalized có nghĩa là role được kết nối với các mẫu đối tượng đối để đưa một biểu thức mẫu đối tượng vào ô trống tương ứng với role, hay role được kết nối với các mẫu nhãn đểđưa các vào ô trống tương ứng với role.
Trong một IGD, chúng ta vẽ tất cả các mẫu sự kiện (nominalized hoặc không) và các mẫu nhãn hoàn chỉnh đã được xác định trong bước phân loại và
đặt tên.
Trình tự dùng để xây dựng một IGD
Lấy một mẫu sự kiện, phân tích biểu thức sự kiện tương ứng cho đến khi không thể tìm thấy biểu thức đối tượng nào nữa. Lần lượt vẽ IGD tương ứng cho mẫu sự kiện này. Thêm các bộ giá trị (tuples) ứng với các mẫu sự kiện vào IGD. Tiếp tục thực hiện tương tự với các biểu thức sự kiện khác. Cuối cùng sơ đồ IGD sẽ được dựng lên và hình thành nên một bức tranh mô tả tổng quát về hệ thống hoàn chỉnh.
Cách xây dựng IGD trong FCO-IM
Dựa vào các quy ước về biểu tượng và trình tự xây dựng sơ đồ ngữ pháp thông tin, chúng ta sử dụng CaseTalk để xuất ra ngay sơ đồ ngữ pháp thông tin.
Những chú ý khi vẽ IGD:
1. Mỗi mẫu sự kiện không được đối tượng hóa phải có ít nhất một biểu thức mẫu sự kiện.
2. Mỗi role phải thuộc một mẫu sự kiện nhất định và có một số role duy nhất.
3. Mỗi role được biểu diễn bởi ít nhất một mẫu nhãn hoặc một mẫu đối tượng.
4. Mỗi mẫu sự kiện phải có ít nhất một bộ giá trị.
5. Mỗi mẫu đối tượng (đối tượng hóa từ biểu thức mẫu sư kiện) có thể cần một biểu thức mẫu sự kiện chỉ sự tồn tại hoặc không.
2.3.6. Các ràng buộc
Có được sơ đồ IGD, chúng ta đã có được một bức tranh toàn diện về hệ
các bộ giá trị.
Ví dụ với mẫu sự kiện Ngay Sinh ta thêm hai bộ giá trị sau:
“Giảng viên ID04 sinh năm 1972” “Giảng viên ID04 sinh năm 1973”
Đây là điều không thể xảy ra vì một giảng viên thì không thể có hai năm sinh. Vì vậy hệ thống cung cấp các ràng buộc vào sơ đồ IGD. Việc xác định các ràng buộc phụ thuộc vào tài liệu mô tả của bài toán. Phương pháp FCO- IM cung cấp các ràng buộc sau: ràng buộc giá trị (value constraints), ràng buộc đơn nhất (unique constraint), ràng buộc toàn diện (totality constraints), ràng buộc con (subset constraints), ràng buộc loại trừ (exclusive constraints), ràng buộc bản số (cardinality constraints).
a. Ràng buộc đơn nhất (Unique Constraints - UC)
Ràng buộc đơn nhất quy định rằng một giá trị (kết hợp của nhiều giá trị) chỉđược xuất hiện một lần trong các bộ giá trị của một mẫu sự kiện. Với mỗi mẫu sự kiện thì có ít nhất một ràng buộc đơn nhất trên một hoặc nhiều role của mẫu sự kiện đó. Ràng buộc đơn nhất được biểu diễn bởi mũi tên hai đầu
đặt trên một hoặc nhiều role.
Lấy 2 sự kiện có cùng giá trị trên role cần xác định UC và giá trị trên các role khác. Hỏi chuyên gia hệ thống liệu hai sự kiện đó có thể xuất hiện cùng nhau không? Nếu câu trả lời là “có” thì không có UC trên role đó, ngược lại thì có UC trên role đó. Thuật toán xác định tất cả các UC có thể có trong mẫu sự kiện:
1. Với mẫu sự kiện chỉ có một role (unary fact type): thêm UC trên một role đó. Thuật toán kết thúc.
2. Với mẫu sự kiện có nhiều hơn một role (n>1): kiểm tra tất cả n UC trên n-1 role.
role. Thêm UC trên n role này vào. Thuật toán kết thúc. b) Nếu có ít nhất 1 UC được tìm thấy trên n-1 role:
- Nếu mẫu sự kiện có 2 role thì thêm UC vừa tìm được vào. Thuật toán kết thúc.
- Nếu mẫu sự kiện đó có 3 hoặc nhiều hơn 3 role thì:
+ Nếu có duy nhất 1 UC trên n - 1 role được tìm thấy thì thêm UC đó vào. Thuật toán kết thúc.
+ Nếu có nhiều hơn 1 UC trên n - 1 role được tìm thấy (gọi là m), giả sử
2<=m<=n thì với mỗi cặp UC trên n -1 role, kiểm tra UC trên n-2 role trùng lặp:
· Nếu không có UC trên n-2 role nào được tìm thấy thì tất cả UC trên n-1
được tìm thấy trước đó đều đúng. Thuật toán kết thúc.
· Nếu có ít nhất 1 UC trên n-2 role được tìm thấy thì mẫu sự kiện này không phải là sơ cấp và nó cần phải được mô tả lại thành hai hay ba mẫu sự
kiện nhỏ.
Tiến hành xác định thuật toán UC cho bài toán đánh giá công chức, viên chức hàng năm (xác định một số mẫu sự kiện các mẫu khác tương tự):
Bảng 2.2. Bảng xét UC cho bài toán M ụ c đ ích Ki ể m t ra U C tr ên c ác Ro le S ố b ộ g iá tr ị Mẫu sự kiện Biểu thức mẫu sự kiện Bộ giá trị C ác b ộ g iá tr ị c ó th ể xu ấ t hi ệ n cùn g n ha u? Câu trả lời (có/ không?) Kết luận 1 Ten_Giang_vien F2:“<2> tên là <3 >” ID04 Võ Văn Anh Kiểm tra UC trên 1 role 2 3 2 3
ID04 Nguyễn Nga ID05 Võ Văn Anh 1+2? 1+3? Không Có UC trên 2 Không có UC 1 Nam_Sinh F3 : “<4> có <5 >” ID04 1972 Kiểm tra UC trên 1 role 4 5 2 3 ID04 1975 ID05 1972 1+2? 1+3? Không Có UC trên 4 Không có UC
b. Ràng buộc toàn diện (Totality Constraints - TC)
Ràng buộc toàn diện là ràng buộc trên các role được biểu diễn bởi cùng một mẫu đối tượng, mỗi bộ giá trị (tuple) của mẫu đối tượng phải xuất hiện ít nhất một lần dưới dạng một hoặc nhiều role liên quan. Nói một cách đơn giản nếu một bộ giá trị xuất hiện ở một mẫu đối tượng thì nó phải xuất hiện ở bộ
giá trịở các role liên quan.
Một ràng buộc toàn diện có thể được xác định trên một hoặc nhiều role và
được biểu diễn bởi một dấu chấm to (˜). Ràng buộc toàn diện trên một role
được gọi là ràng buộc đơn lẻ và ràng buộc toàn diện trên nhiều role gọi là ràng buộc kết hợp.
Ví dụ: Trong mẫu đối tượng Giảng_viên, các mã giảng viên xuất hiện dưới mẫu đối tượng này đều phải xuất hiện dưới mẫu đối tượng Tên_Giảng_viên, mỗi bản ghi giảng viên phải có khai báo tên của giảng viên
đó.
Các bước xác định TC cho một mẫu đối tượng:
- Lập bảng bao gồm tên mẫu đối tượng, các role được biểu diễn bởi đối tượng đó và dòng đầu là một bộ dữ liệu đầy đủ cho tất cả các role tương ứng với các cột.
- Hỏi chuyên gia hệ thống nếu ví dụ của dòng đầu tiên có thể tồn tại trong hệ thống. Nếu câu trả lời là “không”, có nghĩa là có các ràng buộc khác liên quan (như: ràng buộc loại trừ, ràng buộc con....). Nếu câu trả lời là “có” ta tiếp tục thêm các dòng vào và bỏ trống lần lượt các giá trị tương ứng ở các role. Các chuyên gia hệ thống sẽ chỉ ra các giá trị đó có được bỏ trống hay không, nếu không thì tồn tại TC trên role đó, nếu có thì ta tiến hành xét TC kết hợp trên các role (có khả năng bị bỏ trống).
- Trước hết chúng ta nên xét TC trên các role đơn lẻ, sau đó xét trên từng cặp 2 role (không có TC trên từng role) và trên 3 role (nếu không có TC trên cặp 2 role) và cứ tiếp tục đến lúc không thể tìm ra TC kết hợp nào nữa.
- Với các mẫu đối tượng không tồn tại một TC nào trên các role được biểu diễn bởi nó thì nhất thiết phải có một biểu thức mẫu sự kiện chỉ sự tồn tại cho
đối tượng đó.
Bảng 2.3. Bảng ràng buộc toàn diện bài toán Mẫu đối tượng: Giang_vien R ol e 2 c ủ a FT Te n _G ia n g_ vi en R ol e 4 c ủ a FT Nam _s inh R ol e 7 c ủ a FT G ioi _ti nh R ol e 10 c ủ a FT D ia _c hi OK? Kết luận
ID04 Võ Văn Anh 1972 Nam TB - QN Y Áp dụng
ID04 - 1972 Nam TB - QN N TC trên 2
ID04 Võ Văn Anh - Nam TB - QN N TC trên 4 ID04 Võ Văn Anh 1972 - TB - QN N TC trên 7
ID04 Võ Văn Anh 1972 Nam - N TC trên 10
c. Ràng buộc giá trị (Value Constraints - VC)
Ràng buộc giá trị là ràng buộc chỉ ra các giá trị có thể có của một mẫu nhãn.
Ví dụ: mẫu nhãn giới tính của giảng viên chỉ có hai giá trị hợp lệ là “Nam” hoặc “Nữ”.
Ràng buộc giá trị được biểu diễn ngay bên cạnh mẫu nhãn và nằm giữa hai dấu ngoặc đơn {}.
d. Ràng buộc con (Subset Constraints - SC)
Ràng buộc con là ràng buộc được thiết lập trên hai tập các role. Nó chỉ ra rằng “tổng” bộ giá trị của bộ role khác. Các role hoặc kết hợp các role được xét phải được biểu diễn bởi cùng một mẫu nhãn hoặc mẫu đối tượng.
Ràng buộc giá trị được thể hiện bằng mũi tên đi từ tập “con” đến tập “cha”
Hình đầu tiên là ràng buộc con trên một role. Nó chỉ ra rằng tập hợp bộ
giá trị của role 1 là tập con của bộ giá trị 2. Hình tiếp theo là ràng buộc con trên cặp 2 role. Nó chỉ ra rằng mỗi bộ giá trị kết hợp của role 3+4 phải xuất hiện trong bộ giá trị kết hợp 5+6 . Ta cũng có thể biểu diễn ràng buộc con cho 2 hình trên như sau: Fact type 1 (1) à Fact type 2 (2) và Fact type 3(3,4) à
Fact type 4(5,6).
e. Ràng buộc loại trừ (Exclusive Constraints - EC)
Ràng buộc loại trừ là ràng buộc được xác định trên hai hoặc nhiều role. Nó chỉ ra rằng các bộ giá trị của role (tập các role) này không nằm trong tập bộ giá trị của role khác. Các role (tập các role) được xét ràng buộc loại trừ
phải được biểu diễn bởi cùng một mẫu đối tượng/nhãn (tập các mẫu đối tượng/nhãn).
Ví dụ: Giảng viên mà là giảng viên cơ hữu thì không phải là giảng viên thỉnh giảng.
f. Ràng buộc bản số (Cardinality Constraint - CC)
Ràng buộc bản số là ràng buộc được xác định trên 1 role của một mẫu sự
kiện, nó chỉ ra số lần xuất hiện của một giá trị (của role) trong bộ giá trị của role đó.
Ràng buộc bản sốđược biểu diễn bởi một vòng tròn nhỏ chứa số lần xuất hiện của một giá trị. Các toán tử (=, <, >, <= và >=) và ký hiệu viết tắt ‘…..’ cũng được sử dụng.
2.3.7. Thuật toán chuyển đổi GLR
Thuật toán chuyển đổi GLR (Group - Lexicalizing - Reducing) gồm ba bước sau (các bước này có thể thực hiện tựđộng bằng công cụ Casetalk):
- Nhóm (Grouping)
- Định danh hóa (Lexicalizing) - Rút gọn (Reducing)
a. Nhóm (Grouping)
Khi chuyển từ sơ đồ ngữ pháp thông tin sang lược đồ quan hệ, các sự kiện trong các mẫu sự kiện sơ cấp khác nhau có thể cùng nằm trong một bảng. Mục đích của Grouping là nhóm các mẫu sự kiện có thể trong cùng một bảng mà không gây ra sự dư thừa. Do đó, số bảng sinh ra là ít nhất có thể.
Thuật toán Grouping gồm 2 bước sau:
1. Đánh dấu các role thỏa mãn các điều kiện sau (các role sẽ bị xóa trong quá trình grouping):
- Có UC đơn lẻ trên role đó.
- Được biểu diễn bởi một mẫu đối tượng.
2. Với mỗi role được đánh dấu, tiến hành các bước sau:
- Xóa các role được đánh dấu và các UC của nó. Ghép các role còn lại (của cùng một mẫu sự kiện role xóa) vào mẫu đối tượng biểu diễn cho role bị
xóa (giữ nguyên các UC của các role này).
- Tất cả các role được ghép sẽ trở thành tùy chọn (không bắt buộc), trừ khi role bị xóa có TC đơn lẻ.
- Xử lý các biểu thức mẫu sự kiện và biểu thức mẫu đối tượng và bộ giá trị có chứa role bị xóa.
b. Định danh hóa (Lexicalizing)
Về nguyên tắc, lúc chuyển đổi từ IGD sang lược đồ quan hệ, các mẫu sự
thành các cột. Mục đích của bước Lexicalizing là hình thành các mẫu sự kiện có tất cả các role được biểu diễn bởi các mẫu nhãn mà không gây ra sự dư
thừa.
Thuật toán Lexicalizing gồm các bước sau:
1. Đánh dấu các role được biểu diễn bởi một mẫu đối tượng. 2. Với một role được đánh dấu, thực hiện các bước sau:
- Cắt kết nối role đó với mẫu đối tượng, chuyển kết nối này sang mẫu nhãn biểu diễn cho role của mẫu đối tượng đó.
- Xử lý các biểu thức mẫu sự kiện, biểu thức mẫu đối tượng và bộ giá trị. - Thêm các SC từ role được đánh dấu đến role của mẫu đối tượng.
- Nếu role được đánh dấu có chứa TC thì thêm một SC từ role của mẫu
đối tượng đến role được đánh dấu.
- Xóa các mẫu đối tượng không biểu diễn cho role nào và không có biểu thức mẫu đối tượng.
c. Rút gọn (Reducing)
Khi chuyển đổi từ sơ đồ IGD sang lược đồ quan hệ, các mẫu sự kiện sẽ
trở thành các bảng riêng biệt. Tuy nhiên, có những bảng nhỏ và thật sự không cần thiết. Mục đích của bước này là xóa đi các bảng (mẫu sự kiện) không cần