Luận văn Nghiên cứu, xây dựng cơ sở dữ liệu tích cực

ó sẵn một cách trực tiếp (trong trường hợp chèn) hoặc phải được trích rút từ cơ sở dữ liệu (trong trường hợp loại bỏ hoặc sửa đổi). Thuật toán bắt tuân theo kiểm tra rằng tất cả các ràng buộc thích hợp sẽ thỏa mãn sau khi cập nhật các bộ giá trị này. Điều này thường được thực hiện bằng cách áp dụng với các bộ giá trị này các kiểm tra được suy diễn từ các ràng buộc toàn vẹn. Biết rằng các kiểm tra này được áp dụng trước khi trạng thái cơ sở dữ liệu được thay đổi, chúng thường được gọi là các tiền kiểm tra. Phương pháp ngăn ngừa là hiệu quả hơn phương pháp phát hiện bởi vì các cập nhật không bao giờ cần bị hủy bỏ do vi phạm tính toàn vẹn. Thuật toán sửa đổi truy vấn là một ví dụ của phương pháp ngăn ngừa có hiệu quả đặc biệt ở việc bắt tuân theo các ràng buộc miền. Nó thêm các điều kiện khẳng định về điều kiện truy vấn bằng phép toán AND sao cho truy vấn được sửa đổi có thể bắt tuân theo tính toàn vẹn. Để xử lý các khẳng định tổng quát hơn, tiền kiểm tra có thể được tạo ra tại thời điểm định nghĩa khẳng định và bắt tuân theo tại thời gian chạy khi các update xảy ra. Phương pháp được hạn chế đến các cập nhật chèn hoặc xóa một bộ giá trị đơn của quan hệ đơn. Thuật toán xây dựng một tiền kiểm tra tại thời điểm định nghĩa khẳng định cho mỗi khẳng định và mỗi một kiểu cập nhật (insert, delete). Các tiền kiểm tra này được bắt tuân theo tại thời gian chạy. Phương pháp này chấp nhận nhiều quan hệ, các khẳng định nhiều biến, có thể với các hàm nhóm. Nguyên tắc là sự thay thế các biến bộ trong khẳng định bằng các hằng từ một bộ được cập nhật. Mặc dù sự đóng góp quan trọng của nó cho nghiên cứu, phương pháp là khó sử dụng được trong môi trường thực vì sự hạn chế trên các cập nhật. Trong phần còn lại giới thiệu một phương pháp tổ hợp tính tổng quát của các cập nhật được hỗ trợ với ít nhất tính tổng quát của các khẳng định mà đối với nó các tiền kiểm tra được tạo ra. Phương pháp này dựa trên tích, tại thời 41 điểm định nghĩa khẳng định, của các khẳng định thu thập (compled assertion) được sử dụng muộn hơn để ngăn ngừa tổng quát xử lý tập hợp trọn vẹn các khẳng định được sinh ra trong phần trước. Nó làm giảm đáng kể phần của cơ sở dữ liệu phải được kiểm tra khi các khẳng định bắt tuân theo trong sự có mặt của các cập nhật. Định nghĩa của một khẳng định thu thập dựa trên khái niệm các quan hệ vi phân (differentiale relation). Giả sử u là một cập nhật của quan hệ R. R+ và R- là các quan hệ vi phân của R theo u, trong đó R+ chứa các bộ giá trị đươc chèn vào R bởi u và R- chứa các bộ giá trị của R bị loại bỏ bởi u. Nếu u là một phép chèn, R- là rỗng. Nếu u là một phép xóa, R+ là rỗng. Cuối cùng, nếu u là phép sửa đổi quan hệ R sau khi sửa đổi là bằng với R+ (R – R+). Một khẳng định thu thập là một bộ ba (R, T, C) trong đó R là quan hệ, T là một kiểu cập nhật, C là một khẳng định biến thiên trên các quan hệ vi phân bao hàm trong một cập nhật của kiểu T. Khi một ràng buộc toàn vẹn I được định nghĩa, một tập hợp các khẳng định thu thập có thể được sinh ra cho các quan hệ được sử dụng bởi I. Mỗi khi một quan hệ được bao hàm trong I được cập nhật bởi một chương trình u, các khẳng định thu thập phải được kiểm tra để bắt tuân theo I chỉ là khằng định đã được định nghĩa trên I đối với kiểu cập nhật u. Ưu điểm thao tác của phương pháp này là gấp đôi. Trước tiên, số các khẳng định để bắt tuân theo là được làm tối thiểu bởi vì chỉ các khẳng định thu thập của kiểu u cần được kiểm tra. Thứ hai, chi phí bắt tuân theo một khẳng định thu thập là nhỏ hơn chi phí bắt tuân theo I bởi vì nói chung, các quan hệ vi phân là nhỏ hơn nhiều so với các quan hệ cơ sở. Các khẳng định thu thập có thể nhận được bằng cách áp dụng các quy tắc chuyển đổi thành khẳng định nguyên thủy. Các quy tắc dựa trên một phân tích cú pháp của khẳng định và số lượng các giao hoán. Chúng cho phép thay thế các quan hệ vi phân cho quan hệ cơ sở. Bởi vì các khẳng định thu thập là đơn giản hơn các khẳng định nguyên thủy, quá trình tạo ra chúng được gọi là đơn giản hóa. Ví dụ 1.15 42 Xét biểu thức được sửa đổi của ràng buộc khóa ngoài. Các khẳng định thu thập liên kết với ràng buộc này là: (ASG, INSERT, C1), (PROJ, DELETE, C2) và (PROJ, MODIFY,C3) Trong đó: C1 là NEW ASG+, j PROJ : NEW.PNO = j.PNO C2 là g ASG, OLD PROJ : g.PNO OLD.PNO C3 là g ASG, OLD PROJ-, NEW PROJ- ; g.PNO OLD.PNO OR OLD.PNO = NEW.PNO Ưu điểm do các khẳng định thu thập như vậy cung cấp là hiển nhiên. Ví dụ, một loại bỏ trên quan hệ ASG không nằm trong kiểm tra khẳng định nào. Bây giờ chúng ta tổng kết thuật toán bắt tuân theo. Nhớ lại rằng một chương trình cập nhật cập nhật tất cả các bộ giá trị của một quan hệ R thỏa mãn một điều kiện nào đó. Thuật toán hành động trong hai bước: bước thứ nhất tạo ra các quan hệ vi phân R+ và R- từ R. Bước thứ hai đơn giản bao gồm việc trích rút các bộ giá trị của R+ và R- không thỏa mãn các khẳng định thu thập. Nếu không có bộ giá trị nào được rút ra, khẳng định là hợp lệ. Ví dụ 1.15 Giả sử có một phép xóa trên PROJ. Sự bắt tuân theo (PROJ, DELETE, C2) bao gồm việc tạo ra lệnh sau đây: Kết quả trích rút tất cả các bộ giá trị của PROJ- mà ở đó ¬ (C2) Sau đó, nếu kết quả là rỗng, khẳng định được kiểm tra bởi cập nhật. 43 Chương II CƠ SỞ DỮ LIỆU TÍCH CỰC 2.1. CƠ SỞ DỮ LIỆU TÍCH CỰC 2.1.1. Khái niệm cơ sở dữ liệu tích cực Cơ sở dữ liệu tích cực là một CSDL bao gồm tập quy tắc được tự động kích hoạt bằng các sự kiện đã được thực hiện một hành động. Quy tắc đó được gọi là quy tắc ECA. Tuy nhiên, nhiều nghiên cứu mà trong đó một mô hình tổng quát cho các cơ sở dữ liệu tích cực có thể nhìn thấy đã được làm từ các mô hình trigger trước đó đã được đề nghị. 2.1.2. Quy tắc ECA 2.1.2.1. Sự kiện (Event) Một sự kiện là một điều gì đó xảy ra ở một thời điểm. Bởi vậy, việc xác định một sự kiện bao gồm cả việc mô tả sự việc xảy ra được giám sát. Bản chất của việc mô tả và cách thức mà theo đó sự kiện có thể được phát hiện rộng rãi phụ thuộc vào nguồn (Source) hoặc đối tượng phát sinh sự kiện [5]. Các lựa chọn có thể là: - Các hành động cấu trúc, trong trường hợp sự kiện được sinh ra bằng một hành động ở một phần của cấu trúc (ví dụ như: thêm bản ghi, sửa một thuộc tính, truy cập vào 1 bản ghi). - Lời kêu gọi hành vi, trong trường hợp sự kiện được sinh ra bởi việc thực hiện một vài hành động của người dùng (ví dụ, thông điệp hiển thị được gửi tới một đối tượng kiểu widget). Đối với các ngôn ngữ sự kiện thường cho phép các sự kiện xuất hiện trước hoặc sau một hành động nào đó thực thi. - Sự thực thi (giải quyết), trong trường hợp khi sự kiện được sinh ra bằng các lệnh thực thi (ví dụ, từ chối abort, ủy thác commit, bắt đầu thực thi begin – transaction) - Trừu tượng hoặc người dùng định rõ, trong trường hợp một cơ chế lập trình được sử dụng cho phép một chương trình ứng dụng báo hiệu sự xuất 44 hiện một sự kiện rõ ràng (ví dụ trong phản hồi một vài thông tin mà người dùng nhập vào). - Ngoại lệ (loại trừ ra), trong trường hợp sự kiện được sinh ra như là kết quả của một vài ngoại lệ phát sinh (ví dụ như, sự cố gắng truy cập một vài dữ liệu mà không có sự cho phép thích hợp). - Đồng hồ, trong trường hợp sự kiện được sinh ra ở một điểm thời gian, sự kiện thời gian tương đối và chu kỳ được báo cáo trong tài liệu - Ngoài ra, trong trường hợp sự kiện được sinh ra bởi sự việc xảy ra bên ngoài cơ sở dữ liệu (ví dụ, nhiệt độ dọc lớn hơn 30 độ). Một sự kiện biểu thị một sự kiện được xác định cho tất cả các đối tượng trong một tập hợp hay không (ví dụ, tất cả các đối tượng thuộc một lớp), đối với các tập hợp con đã cho (ví dụ như, tất cả các nhân viên trừ giáo sư) hoặc đối với một số thành viên nhất định của tập hợp (ví dụ, để tránh việc truy cập trái phép tới các đối tượng xác định, hoặc cho phép cập nhật các đối tượng cụ thể hiển thị trên màn hình). Các kiểu sự kiện có thể là: - Gốc (nguyên thủy), trong trường hợp này sự kiện được sinh ra bởi sự việc đơn lẻ ở tầng thấp thuộc một trong những loại được mô tả ở nguồn (Source). Ví dụ, sự kiện “on insert to Owns” theo dõi việc thêm những bản ghi mới vào quan hệ “Owns”. - Hỗn hợp, trong trường hợp này sự kiện được sinh ra bởi sự kết hợp các sự kiện hoặc hỗn hợp bằng cách sử dụng một loạt các toán tử cấu thành lên sự kiện. Các toán tử sự kiện khác nhau tùy vào hệ thống. Phổ biến là: Toán tử tách rời(disjunction) – E1 or E2 xuất hiện khi một trong các thành phần E1 hoặc E2 xuất hiện; Toán tử kết hợp (conjunction) – E1 and E2 xảy ra khi cả hai E1 và E2 đều xảy ra theo thứ tự bất kỳ; Toán tử nối tiếp (sequence)– seq(E1,E2) xuất hiện khi E1 xuất hiện trước E2; toán tử đóng kín – “closure E in Int” xuất hiện chỉ một lần lần 45 đầu tiên E ra tín hiệu, không cần chú ý tới sự xuất hiện sau đó của E trong một khoảng thời gian Int, Toán tử sử học (history) – times(n,E) in Int báo hiệu khi sự kiện E xuất hiện n lần trong khoảng thời gian Int; Phủ định (not) – not E1 in Int phát hiện sự không xuất hiện của sự E1 trong khoảng thời gian Int. Như một ví dụ của của quy tắc với sự kiện hỗn hợp, quy tắc sau thực hiện sự ràng buộc mà thuộc tính qty của stock là như nhau bằng số lượng được ghi vào quan hệ Owns: on update to qty of Holder or update to qty of Stock or insert to Stock or delete to Stock or insert to Holder or delete to Holder If exists (select * from Stock where qty # ( select sum (qty) from Owns where Owns.reg# =Stock-.reg#) ) do abort Như một ví dụ thêm, để xác định giá cổ phiểu bị thay đổi hay không trong ngày làm việc sự kiện có thể được sử dụng: on update to price of Stock in [09:00, 17:00]. 46 Đại số sự kiện phong phú có thể đề xuất cho một loạt các hệ thống, bao gồm HiPAC [Dayal et al. 1988], SAMOS [Gatziu và Dittrich 1994], ODE [Gehani et al.1992] và Sentinel [Chakravarthy et al.1994]. Khi phát hiện những sự kiện hỗn hợp, có vài sự kiện xuất hiện (của cùng một loại sự kiện) có thể được sử dụng để hình thành nên một sự kiện hỗn hợp. Ví dụ như, hãy xem xét một sự kiện hỗn hợp CE mà là sự nối tiếp của hai sự kiện EV1 và EV2. Nếu cả hai sự xuất hiện của sự kiện EV1, đầu tiên là ev1 và sau đó là ev1’, được báo hiệu, và sự xuất hiện của sự kiện EV2 (ví dụ, ev2) bây giờ được tạo ra, có một câu hỏi là trường hợp nào của CE sẽ được tạo ra. Khả năng bao gồm sequence(ev1,ev2) hoặc sequence(ev1’,ev2) hoặc sequence(ev1,ev2)  sequence(ev1’,ev2) . Các sự lựa chọn là phân biệt với nhau bằng cách sử dụng các điều khoản tiêu thụ. Trong Chakravarthy et al.[1994] tồn tại 4 điều khoản tiêu hủy được trình bày là: ngữ cảnh gần đây, xem xét phần lớn tập hợp sự kiện gần đây mà có thể được sử dụng để xây dựng lên sự hỗn hợp ( trong ví dụ trước, sequence(ev1’,ev2) được phát hiện khi ev2 xuất hiện, sau khi ev1’ và ev2 không còn được xét để phát hiện CE nữa); ngữ cảnh liên tục, nó xác định cửa sổ trượt và bắt đầu kết hợp với mỗi sự kiện nguyên thủy diễn ra (2 sự kiện nối tiếp bắt đầu được hình thành khi ev1 và ev1’ xuất hiện, và cả hai sự kiện nối tiếp sẽ được báo hiệu như là ev2 được phát hiện); và ngữ cảnh tích lũy, chất đống tất cả các sự kiện nguyên thủy đến khi sự kiện ghép lại xuất hiện (sự kiện nối tiếp được báo chỉ một lần khi ev2 sinh ra, ở nơi tham số đầu tiên của sự nối tiếp chứa các tham số của tất cả sự xuất hiện của EV1, tức là ev1 và ev1’). Nhân tố cơ bản cho mỗi ngữ cảnh có thể được tìm thấy ở Chakravarthy et al.[1994]. Vai trò của một sự kiện biểu thị các sự kiện phải luôn được định sẵn cho các quy tắc tích cực hay không, hoặc việc đặt tên rõ ràng của một sự kiện có cần thiết hay không. Nếu vai trò là tùy ý, thì khi mà không một sự kiện nào được xác định thì các quy tắc điều kiện - hành động được hỗ trợ, các quy tắc đó có chức năng khác nhau đáng kể và thực thi từ quy tắc sự kiện - điều kiện - hành động (ECA). Nếu như vai trò là none thì các sự kiện có thể không được định rõ, và tất 47 cả các quy tắc là quy tắc điều kiện – hành động. Nếu vai trò là bắt buộc, thì chỉ quy tắc ECA được hỗ trợ. Hình 2.1 Ngữ cảnh mà trong đó một quy tắc được xử lý 2.1.2.2. Điều kiện (Condition) Vai trò của một điều kiện biểu thị đã quy định hay chưa. Trong các quy tắc ECA, điều kiện thông thường là tùy chọn. Khi không điều kiện nào được quy định cho một quy tắc ECA, dẫn đến một quy tắc sự kiện – hành động. Trong các hệ thống mà ở đó cả sự kiện và điều kiện là tùy chọn, thì đó luôn là trường hợp mà ít nhất một cái được quy định [5]. Ngữ cảnh biểu thị sự thiết lập mà trong đó điều kiện được đánh giá. Các thành phần khác nhau của một quy tắc không được đánh giá trong sự độc lập trong cơ sở dữ liệu hoặc từ mỗi thành phần khác, và hơn nữa cũng có thể không được đánh giá lần lượt. Kết quả là, việc xử lý một quy tắc đơn lẻ có thể được liên kết với ít nhất 4 trạng thái cơ sở dữ liệu khác nhau: – cơ sở dữ liệu ở thời điểm bắt đầu của sự thực thi hiện thời; – cơ sở dữ liệu khi sự kiện đã diễn ra, – cơ sở dữ liệu khi điều kiện được đánh giá; và – cơ sở dữ liệu khi hành động được thực hiện. Hệ thống quy tắc tích cực có thể hỗ trợ các công cụ bên trong điều kiện của quy tắc mà cho phép nó có thể không truy cập tới hoặc nhiều hơn các trạng thái và, , và có thể cũng cho phép truy cập tới các ràng buộc liên kết với sự kiện . Các thông tin có sẵn được dùng với các thành phần khác nhau của một quy tắc được minh họa ở Hình 2.1. Nhìn chung, vị trí của các thành phần còn phức tạp hơn trong miêu tả ở Hình 2.1, bởi 48 vì trạng thái trước và sau một sự kiện diễn ra có thể khác nhau, và bởi vì nhiều sự kiện có thể được bắt đầu và có thể thực hiện tới khi hoàn thành trong khi thực hiện một hành động đơn lẻ. Như là một ví dụ tính tiện ích của thông tin đó, quy tắc sau được sử dụng để phản hồi lại tình huống trong đó giá trị của cổ phần nắm giữ bởi cổ đông (Holder) giảm về 0. on update tovalue of Holder If new.value = 0 do (action) Trong quy tắc này, thông tin từ sự kiện ( được sử dụng để xác định khi nào trường value được thiết lập bằng 0, do đó việc phản hồi thích hợp có thể được tạo ra (ví dụ, cổ đông Holder được xóa, thông tin về cổ đông Holder được gửi tới người quản lý quỹ). Một ví dụ khác, các điều kiện hay hành động truy cập tới tham số sự kiện sử dụng old chuyển đến giá trị mà một mục dữ liệu nắm giữ trước một sự kiện cập nhật nó, insert dẫn tới giá trị mới được chèn vào, delete là việc dẫn tới một giá trị hiện tại bị xoá và cập nhật liên quan tới các thuộc tính của một mục dữ liệu mà chúng không bị ảnh hưởng bởi sự kiện cập nhật. 2.1.2.3. Hành động (Active) Phạm vi các công việc mà có thể được thực hiện bởi một hành động được chỉ rõ như là sự lựa chọn của nó. Các hành động có thể cập nhật theo cấu trúc của cơ sở dữ liệu hoặc quy tắc thiết lập, thực hiện hành động lấy thông tin từ cơ sở dữ liệu và thông báo người dùng hoặc quản trị hệ thống trong một vài tình huống, hủy bỏ giao dịch, hoặc lấy một số quy tắc phụ của hành động sử dụng trong do-instead [Stonebraker et al.1990]. Sau đây là một ví dụ của do-instead, nếu muốn cố xóa đi giá trị từ quan hệ Holder mà có giá trị value > 0, sau đó cho phép hành động được thực hiện, người quản lý hệ thống có thể được thông báo hành động đó: on delete to Holder if delete.value > 0 do instead (inform system manager) 49 Khác với nhiều cú pháp chuẩn, trong trường hợp này bản ghi được xóa đi và người quản lý hệ thống được thông báo: on delete to Holder if delete.value > 0 do (inform system manager) Ngữ cảnh của hành động gần giống với ngữ cảnh của điều kiện, và biểu thị thông tin sẵn có về hành động, như trong minh họa ở Hình 2.1. Đôi khi thông tin có thể được chuyển từ điều kiện của quy tắc sang hành động, như ( hoặc ( . Sau đây là một ví dụ về sự tiện ích của thông tin ngữ cảnh, quy tắc sau được sử dụng để sửa lại thông tin lưu trữ trong thuộc tính value của tất cả bản ghi Holder mà bị ảnh hưởng bởi sự thay đổi price của vài Stock. On update to price of Stock If true Do update Holder Set value = value*(new.price/old.price) Where reg# in (select reg# from Owns where stock# = update.stock#) Trong quy tắc này, cả giá trị old và new của price đều được truy cập tới ( , để làm trạng thái của cơ sở dữ liệu tại thời gian của cập nhật ( . 2.2. MÔ HÌNH TỔNG QUÁT VÀ CÁC TRIGGER TRONG ORACLE 2.2.1. Mô hình tổng quát của CSDL tích cực: Mô hình được sử dụng để chỉ rõ các quy tắc của cơ sở dữ liệu tích cực được tham chiếu đến như là mô hình ECA (Event-Condition-Active). Một quy tắc trong mô hình ECA có 3 thành phần: a. Sự kiện (Event) làm kích hoạt quy tắc: các sự kiện này thường là các thao tác cập nhật cơ sở dữ liệu được áp dụng một cách tường minh đối với cơ sở dữ liệu. Tuy nhiên, trong mô hình tổng quát chúng cũng có thể là các sự kiện thời gian hoặc là các dạng sự kiện ngoài khác. b. Điều kiện (Condition) xác định hành động của quy tắc có thể được thực hiện hay không: mỗi khi sự kiện kích hoạt có mặt, một điều kiện được chọn 50 có thể được tính giá trị. Nếu không có điều kiện nào được chỉ rõ, hành động sẽ được thực hiện sự kiện xảy ra. Nếu điều kiện được chỉ rõ, đầu tiên nó được tính giá trị và chỉ khi nó tính giá trị là đúng (true) thì hành động của quy tắc sẽ được thực hiện. c. Hành động (Action) thực hiện: Hành động thường là một dãy lệnh SQL nhưng nó cũng có thể là một giao tác cơ sở dữ liệu hoặc một chương trình bên ngoài sẽ được thực hiện một cách tự động. Hãy xem một vài ví dụ minh họa khái niệm này. Có hai quan hệ NHÂN VIÊN và ĐƠN VỊ. Mỗi nhân viên có một tên (tenNV), mã số (masoNV), lương, mã số đơn vị (masoDV) là khóa ngoài tham chiếu đến DONVI, và mã số người giám sát (MasoNGS) là khóa ngoài đệ quy đến NHANVIEN. Với ví dụ này, chúng ta giả thiết rằng masoNV có thể cho phép có giá trị null, chỉ ra rằng nhân viên có thể tạm thời chưa được đăng ký vào đơn vị nào. Mỗi đơn vị có một tên (TenDV), một mã số (MasoDV), tổng lương của tất cả các nhân viên đăng ký vào đơn vị (Tongluong) và một người quản lý (MasoNQL) là khóa ngoài đến NHANVIEN. Chú ý rằng thuôc tính Tongluong thực chất là một thuộc tính suy diễn được, giá trị của nó là tổng lương của tất cả các nhân viên đăng ký vào một đơn vị cụ thể. Việc duy trì giá trị đúng của một thuộc tính suy diễn được như vậy có thể được thực hiện thông qua một luật tích cực. Trước tiên chúng ta phải xác định các sự kiện có thể gây ra một thay đổi giá trị của Tongluong, đó là các sự kiện sau: [1]. Chèn vào một hoặc nhiều bộ giá trị nhân viên mới [2]. Thay đổi lương của một hoặc nhiều nhân viên có sẵn [3]. Thay đổi việc đăng ký của các nhân viên có sẵn từ đơn vị này sang đơn vị khác. [4]. Loại bỏ một hoặc nhiều bộ giá trị nhân viên. Trong trường hợp sự kiện 1, chúng ta chỉ cần tính lại Tongluong nếu nhân viên mới được ghi tức khắc vào một đơn vị - nghĩa là giá trị của thuộc tính MasoNV đối với bộ nhân viên mới là khác null (giả thiết null là cho phép đối 51 với MasoNV). Như vậy điều đó sẽ là điều kiện để kiểm tra. Một điều kiện tương tự có thể sẽ được kiểm tra cho sự kiện 2 (và 4) để xác định xem có phải là nhân viên mà lương của anh ta bị thay đổi (hoặc bị xóa) hiện tại đã được đăng ký vào một đơn vị hay không. Với sự kiện 3, chúng ta luôn luôn thực hiện một hành động để duy trì giá trị của Tongluong một cách đúng đắn, như vậy là không cần điều kiện nào (hành động luôn luôn được thực hiện). Hành động đối với các sự kiện 1, 2 và 4 là cập nhật một cách tự động giá trị của Tongluong đối với đơn vị của nhân viên để phản ánh việc lương của nhân viên vừa mới được thêm, xóa hoặc cập nhật. Trong trường hợp của sự kiện 3, cần một hành động đúp: một để cập nhật Tongluong của đơn vị cũ của nhân viên và hành động khác để cập nhật Tongluong của đơn vị mới của nhân viên. Bốn active rules R1, R2, R3 và R4 tương ứng với tình trạng ở trên có thể được chỉ ra trong ký hiệu của hệ quản trị cơ sở dữ liệu Oracle. Chúng ta hãy xét quy tắc R1 để minh họa cú pháp của việc tạo ra các luật tích cực trong Oracle. Lệnh CREATE TRIGGER chỉ rõ tên của một trigger (hoặc các luật tích cực) – Tongluong1 cho R1. Mệnh đề AFTER chỉ ra rằng quy tắc sẽ được kích hoạt sau sự kiện kích hoạt quy tắc xảy ra. Các sự kiện kích hoạt – ví dụ như chèn một nhân viên mới ở trong ví dụ này – được chỉ ra sau từ khóa AFTER. Mệnh đề ON chỉ rõ quan hệ mà trên đó quy tắc được chỉ ra – NHÂN VIÊN đối với R1. Các từ khóa tùy chọn FOR EACH ROW chỉ ra rằng quy tắc sẽ được kích hoạt một lần với mỗi một hàng bị ảnh hưởng bởi sự kiện kích hoạt. Mệnh đề tùy chọn WHEN được sử dụng để chỉ ra điều kiện nào cần kiểm tra sau khi quy tắc được kích hoạt nhưng trước khi hành động được thực hiện. Cuối cùng, hành động cần làm được chỉ ra như một khối PL/SQL, khối này thường chứa một hoặc nhiều lệnh SQL hoặc các lời gọi để thực hiện các thủ tục bên ngoài. R1: CREATE TRIGGER Tongluong1 AFTER INSERT ON NHÂNVIÊN FOR EACH ROW WHEN (NEW.MasoDV IS NOT NULL) UPDATE ĐƠNVỊ 52 SET Tongluong = Tongluong + NEW.Luong WHERE MasoDV = NEW.MasoDV; R2: CREATE TRIGGER Tongluong2 AFTER UPDATE OF Luong ON NHÂNVIÊN FOR EACH ROW WHEN (NEW.MasoDV IS NOT NULL) UPDATE ĐƠNVỊ SET Tongluong = Tongluong + NEW.Luong – OLD.Luong WHERE MasoDV = NEW.MasoDV; R3: CREATE TRIGGER Tongluong3 AFTER UPDATE OF DNO ON NHÂNVIÊN FOR EACH ROW BEGIN UPDATE ĐƠNVỊ SET Tongluong = Tongluong + NEW.Luong WHERE MasoDV = NEW.MasoDV; UPDATE ĐƠNVỊ SET Tongluong = Tongluong - OLD.Luong WHERE MasoDV = OLD.MasoDV; END; R4: CREATE TRIGGER Tongluong4 AFTER DELETE ON NHÂNVIÊN FOR EACH ROW WHEN (OLD.MasoDV IS NOT NULL) UPDATE ĐƠNVỊ SET Tongluong = Tongluong - OLD.Luong WHERE MasoDV = OLD.MasoDV; Bốn trigger (các quy tắc tích cực) R1, R2, R3 và R4 minh họa một số tính chất của các quy tắc tích cực. Trước tiên, các sự kiện cơ bản có thể chỉ ra để kích hoạt các quy tắc là các lệnh cập nhật của SQL chuẩn: INSERT, DELETE, 53 UPDATE. Chúng được chỉ ra bằng các từ khóa INSERT, DELETE, UPDATE trong ký hiệu của Oracle. Trong trường hợp của UPDATE người ta có thể chỉ ra các thuộc tính được cập nhật – ví dụ, bằng cách viết UPDATE OF Luong, MasoDV. Thứ hai, người thiết kế quy tắc cần có cách tham chiếu đến các bộ giá trị đã được chèn, xóa, sửa đổi: Các từ khóa NEW và OLD được sử dụng trong Oracle: NEW được sử dụng để tham chiếu đến bộ vừa được chèn vào hoặc vừa được sửa đổi, trong khi đó OLD được sử dụng để tham chiếu đến bộ bị xóa hoặc bộ trước khi được cập nhật. Như vậy, quy tắc R1 được kích hoạt sau một phép toán INSERT được áp dụng cho quan hệ NHÂNVIÊN. Trong R1, điều kiện (NEW.MasoDV IS NOT NULL) được kiểm tra, và nếu nó được tính giá trị là đúng, nghĩa là bộ nhân viên vừa mới được chèn vào là có quan hệ với một đơn vị, thì hành động sẽ được thực hiện. Hành động cập nhật các bộ ĐƠNVỊ có liên quan tới nhân viên vừa mới được chèn vào bằng cách cộng lương của người đó (NEW.Luong) vào thuộc tính Tongluong của đơn vị liên quan của chúng. Quy tắc R2 tương tự với R1 nhưng nó được kích hoạt bằng một phép toán UPDATE, sửa đổi lương của một nhân viên thay vì chèn. Quy tắc R3 được kích hoạt bằng một sửa đổi đối với thuộc tính MasoDV của NHÂNVIÊN, nó có nghĩa thay đổi đăng ký của nhân viên từ một đơn vị sang một đơn vị khác. Không có điều kiện để kiểm tra trong R3, vì vậy hành động được thực hiện mỗi khi sự kiện kích hoạt xuất hiện. Hành động sửa đổi cả đơn vị mới và đơn vị cũ của nhân viên đăng ký lại bằng cách cộng lương của họ vào Tongluong của đơn vị mới và trừ lương của họ ra khỏi Tongluong của đơn vị cũ. Để ý rằng điều này có thể làm việc ngay cả giá trị của MasoDV là NULL bởi vì trong trường hợp này không đơn vị nào được lựa chọn cho hành động của quy tắc. Điều quan trọng là xét ảnh hưởng của mệnh đề tùy chọn FOR EACH ROW, nó có nghĩa là quy tắc được kích hoạt một cách riêng rẽ đối với mỗi bộ giá trị. Điều này được biết đến như một row-level-trigger. Nếu mệnh đề này bị bỏ qua, trigger sẽ được biết như là một statement-level trigger và sẽ được kích hoạt một lần đối với mỗi lệnh kích hoạt. Để thấy sự khác nhau, hãy xem phép 54 toán cập nhật sau đây, nó tăng 10% lương cho tất cả các nhân viên đăng ký vào đơn vị 5. Phép toán này sẽ là một sự kiện kích hoạt quy tắc R2: R2: UPDATE NHÂNVIÊN SET Luong = 1.1* Luong WHERE MasoDV=5; Bởi vì lệnh ở trên có thể cập nhật nhiều bản ghi, một quy tắc sử dụng ngôn ngữ row-level như là R2 sẽ được kích hoạt một lần đối với mỗi hàng, trong khi đó một quy tắc sử dụng ngữ nghĩa statement-level được kích hoạt chỉ một lần. Hệ thống Oracle cho phép người sử dụng chọn lựa một trong hai tùy chọn trên để sử dụng cho mỗi quy tắc. Việc dựa vào mệnh đề tùy chọn FOR EACH ROW tạo ra một row-level trigger và việc bỏ nó tạo ra một statement-level trigger. Để ý rằng các từ khóa NEW và OLD chỉ có thể được sử dụng với các row-level trigger. Cú pháp để chỉ ra các trigger trong hệ thống Oracle được tổng kết như sau: :: = CREATE TRIGGER (AFTER| BEFORE) ON [ FOR EACH ROW] [WHEN ] ; ::= ::= {, }]. Một ví dụ khác, giả sử rằng chúng ta muốn kiểm tra có phải lương của một nhân viên là lớn hơn lương của người giám sát trực tiếp của anh ta hay không? Nhiều sự kiện có thể kích hoạt quy tắc này: việc chèn vào một nhân viên mới, thay đổi lương của một nhân viên hoặc thay đổi người giám sát của nhân viên. Giả sử rằng hành động sẽ thực hiện sẽ là một lời gọi đến một thủ tục bên ngoài INFORM_SUPERVISOR, nó sẽ thông báo về người giám sát. Quy tắc có thể được viết như sau: R5: CREATE TRIGGER INFORM_SUPERVISOR1 55 BEFORE INSERT OF UPDATE OF Luong, MasoNGS ON NHÂNVIÊN FOR EACH ROW WHEN (NEW.Luong > (SELECT Luong FROM NHÂNVIÊN WHERE MasoNV = NEW.MasoNGS)) INFORM_SUPERVISOR (NEW.MasoNGS, NEW.MasoNV); 2.2.2. Vấn đề thiết kế và cài đặt cho các cơ sở dữ liệu tích cực Phần trước đã cho tổng quan về các khái niệm chính để chỉ ra các quy tắc tích cực. Trong phần này đưa các vấn đề bổ sung liên quan đến việc thiết kế và cài đặt các quy tắc như thế nào. Vấn đề thứ nhất liên quan đến việc kích hoạt, thôi kích hoạt và nhóm các quy tắc. Thêm vào việc tạo ra các quy tắc, một hệ thống cơ sở dữ liệu tích cực phải cho phép những người sử dụng kích hoạt, thôi kích hoạt và bỏ các quy tắc bằng cách tham chiếu đến các tên quy tắc của chúng. Một quy tắc thôi kích hoạt sẽ không bị kích hoạt bởi sự kiện kích hoạt. Tính chất này cho phép các người sử dụng lựa chọn các quy tắc thôi kích hoạt đối với một chu kỳ thời gian nào đó khi chúng là không cần thiết. Các lệnh kích hoạt sẽ làm cho các quy tắc tích cực trở lại. Lệnh drop loại bỏ các luật ra khỏi hệ thống. Một tùy chọn khác là nhóm các quy tắc vào một cái gọi là thiết lập quy tắc, như vậy toàn bộ tập hợp các quy tắc có thể được kích hoạt, ngừng kích hoạt hoặc loại bỏ. Việc có một lệnh có thể kích hoạt một quy tắc hoặc một tập quy tắc thông qua một lệnh PROCESS RULES do người sử dụng đưa ra cũng là một điều có lợi. Vấn đề thứ hai liên quan đến liệu hành động được kích hoạt có thể được thực hiện trước, sau, hoặc đồng thời với sự kiện kích hoạt được hay không. Vấn đề liên quan là liệu hành động được kích hoạt có thể được xem như một giao tác tách rời hay không hay nó phải là một phần của cung giao tác kích hoạt quy tắc. Trước tiên chúng ta phải cố gắng phân loại các tùy chọn khác nhau. Điều quan trọng là không phải tất cả các tùy chọn có thể sẵn sang sử dụng đối với một hệ cơ sở dữ liệu tích cực. Thật vậy, hầu hết các hệ thống thương mại được giới hạn đến một hoặc hai tùy chọn. 56 Giả thiết rằng sự kiện kích hoạt xảy ra như là một phần của việc thực hiện giao tác. Trước hết chúng ta xét các tùy chọn khác nhau với việc sự kiện kích hoạt liên kết với việc tính giá trị của các điều kiện của quy tắc như thế nào. Việc tính giá trị của các điều kiện của quy tắc cũng được xem như xem xét quy tắc bởi vì hành động chỉ được thực hiện sau sự xem xét lại điều kiện tính giá trị đến true hoặc fasle. Có ba khả năng chính đối với sự xem xét quy tắc: [1]. Sự xem xét tức khắc (immediate consideration): Điều kiện được tính giá trị như là một phần của cùng giao tác như là sự kiện kích hoạt và được tính toán ngay tức khắc. Trường hợp này có thể được phân loại thành ba tùy chọn: - Tính giá trị điều kiện trước khi thực hiện sự kiện kích hoạt - Tính giá trị điều kiện sau khi thực hiện sự kiện kích hoạt - Tính giá trị điều kiện thay vì thực hiện sự kiện kích hoạt [2]. Sự xem xét chậm: Điều kiện được tính giá trị ở cuối giao tác chứa sự kiện kích hoạt. Trong trường hợp này có thể có nhiều quy tắc được kích hoạt chờ để có các điều kiện của chúng được tính. [3]. Sự xem xét riêng rẽ: Điều kiện được tính giá trị như là một giao tác riêng rẽ, tách rời khỏi giao tác kích hoạt. Tập hợp các tùy chọn tiếp theo liên quan đến mối quan hệ giữa việc tính giá trị điều kiện của quy tắc và việc thực hiện hành động của quy tắc. Ở đây, một lần nữa có ba tùy chọn có thể có: thực hiện tức khắc, thực hiện chậm và thực hiện tách rời. Tuy nhiên, hầu hết các hệ thống tích cực sử dụng tùy chọn thứ nhất. Nghĩa là, khi điều kiện được tính giá trị, nếu nó trả lại giá trị true, hành động được thực hiện ngay tức khắc. Một vấn đề khác liên quan đến các quy tắc của cơ sở dữ liệu tích cực là sự phân biệt các quy tắc mức dòng (row-level rule) và các quy tắc mức lệnh (statement-level rule). Bởi vì các lệnh cập nhật của SQL (được xem như các sự kiện kích hoạt) có thể chỉ ra một tập hợp các bộ, ta phải phân biệt giữa liệu quy tắc có thể xem xét một lần đối với toàn bộ lệnh hay không hay liệu nó có thể được xem xét một cách tách biệt đối với từng hàng bị ảnh hưởng bởi lệnh. Hệ 57 thống Oracle cho phép người sử dụng chọn một trong hai tùy chọn trên sử dụng với từng quy tắc. Một trong các khó khăn có thể hạn chế việc sử dụng rộng rãi các quy tắc tích cực, mặc dù khả năng của chúng lầm đơn giản việc phát triển cơ sở dữ liệu và phần mềm, là ở chỗ không có các kỹ thuật dễ sử dụng để thiết kế, viết và kiểm tra các quy tắc. Ví dụ, rất khó khăn để kiểm tra rằng một tập hợp các quy tắc là tương thích, nghĩa là hai hoặc nhiều quy tắc trong tập hợp không mâu thuẫn với nhau. Cũng rất khó khăn để đảm bảo sự kết thúc của một tập hợp các quy tắc dưới mọi hoàn cảnh. Để minh họa ngắn gọn vấn đề kết thúc, hãy xem xét các quy tắc dưới đây: R1: CREATE TRIGGER T1 AFTER INSERT ON TABLE1 FOR EACH ROW UPDATE TABLE 2 SET ATTRIBUTE 1 = ……..; R2: CREATE TRIGGER T2 AFTER UPDATE OF ATTRIBUTE1 ON TABLE 2 FOR EACH ROW INSERT INTO TABLE 1 VALUE (….); Ở đây quy tắc R1 được kích hoạt bởi một sự kiện INSERT trên bảng 1 và hành động của nó gồm một sự kiện UPDATE trên thuộc tính 1 của bảng 2. Tuy nhiên, sự kiện kích hoạt của quy tắc R2 là một sự kiện UPDATE trên thuộc tính 1 của bảng 2 và hành động của nó bao gồm một sự kiện INSERT trên bảng 1. Dễ dàng nhìn thấy trong ví dụ này hai quy tắc có thể kích hoạt lẫn nhau không ngừng, dẫn đến sự không kết thúc. Vì vậy, nếu hàng chục quy tắc được viết thì sẽ rất khó khăn để xác định sự kết thúc có được đảm bảo hay không. Nếu các quy tắc tích cực đạt đến khả năng của nó thì cần phải phát triển các phương tiện để thiết kế, sửa lỗi và hướng dẫn các quy tắc tích cực nhằm giúp các người sử dụng trong việc thiết kế và sửa lỗi các quy tắc đó. 2.2.3. Các ứng dụng tiềm năng đối với các cơ sở dữ liệu tích cực 58 Một ứng dụng quan trọng là cho phép khai báo một số các điều kiện xuất hiện. Ví dụ, một cơ sở dữ liệu tích cực có thể được sử dụng để theo dõi nhiệt độ của một lò nung công nghiệp. Ứng dụng có thể đưa một cách có chu kỳ các bản ghi đọc nhiệt độ một cách trực tiếp từ các cảm ứng nhiệt độ vào cơ sở dữ liệu và các quy tắc tích cực có thể được viết để được kích hoạt khi một bản ghi nhiệt độ được đưa vào với điều kiện là kiểm tra nếu nhiệt độ vượt quá mức nguy hiểm và hành động là đưa ra báo động. Các quy tắc tích cực cũng có thể được sử dụng để bắt tuân theo các ràng buộc toàn vẹn bằng cách chỉ rõ các kiểu của sự kiện có thể gây ra việc các ràng buộc bị vi phạm và sau đó tính giá trị các điều kiện thích hợp để kiểm tra xem các ràng buộc có bị vi phạm bởi các sự kiện hay không. Vì thế, các ràng buộc ứng dụng phức tạp, thường được biết như các quy tắc nghiệp vụ có thể được bắt buộc theo cách đó. Ví dụ, trong ứng dụng của cơ sở dữ liệu “Trường đại học” một quy tắc có thể theo dõi điểm trung bình của các sinh viên mỗi khi một điểm mới được nhập vào và nó có thể báo cho người giám sát nếu điểm trung bình của sinh viên ở dưới một ngưỡng nào đấy. Một ứng dụng khác bao gồm duy trì tự động dữ liệu suy diễn được giống như các ví dụ về quy tắc R1 đến R4 duy trì thuộc tính suy diễn được Tongluong mỗi khi các bộ giá trị nhân viên riêng rẽ được thay đổi. Một ứng dụng tương tự là sử dụng các quy tắc active để duy trì sự kiên định của các khung nhìn mỗi khi các quan hệ cơ sở được sửa đổi. Một ứng dụng liên quan là duy trì tính kiên định của các bảng được nhân bản bằng cách chỉ rõ các quy tắc sửa đổi các bản sao mỗi khi bảng chính được sửa đổi. 59 Chương III CÀI ĐẶT CÁC QUY TẮC ECA BẰNG NGÔN NGỮ SQL 3.1. GIỚI THIỆU TRIGGER TRONG SQL-SERVER Ta đã biết các ràng buộc được sử dụng để đảm bảo tính toàn vẹn dữ liệu trong cơ sở dữ liệu [2]. Một đối tượng khác cũng thường được sử dụng trong các cơ sở dữ liệu cũng với mục đích này là các trigger. Cũng tương tự như thủ tục lưu trữ, một trigger là một đối tượng chứa một tập các câu lệnh SQL và tập các câu lệnh này sẽ được thực thi khi trigger được gọi. Điểm khác biệt giữa thủ tục lưu trữ và trigger là: các thủ tục lưu trữ được thực thi khi người sử dụng có lời gọi đến chúng còn các trigger lại được "gọi" tự động khi xảy ra những giao tác làm thay đổi dữ liệu trong các bảng. Mỗi một trigger được tạo ra và gắn liền với một bảng nào đó trong cơ sở dữ liệu. Khi dữ liệu trong bảng bị thay đổi (tức là khi bảng chịu tác động của các câu lệnh INSERT, UPDATE hay DELETE) thì trigger sẽ được tự động kích hoạt. Sử dụng trigger một cách hợp lý trong cơ sở dữ liệu sẽ có tác động rất lớn trong việc tăng hiệu năng của cơ sở dữ liệu. Các trigger thực sự hữu dụng với những khả năng sau:  Một trigger có thể nhận biết, ngăn chặn và huỷ bỏ được những thao tác làm thay đổi trái phép dữ liệu trong cơ sở dữ liệu.  Các thao tác trên dữ liệu (xoá, cập nhật và bổ sung) có thể được trigger phát hiện ra và tự động thực hiện một loạt các thao tác khác trên cơ sở dữ liệu nhằm đảm bảo tính hợp lệ của dữ liệu.  Thông qua trigger, ta có thể tạo và kiểm tra được những mối quan hệ phức tạp hơn giữa các bảng trong cơ sở dữ liệu mà bản thân các ràng buộc không thể thực hiện được. 3.2. CSDL TRONG QUẢN LÝ BÁN HÀNG Trong chương này tôi cài đặt các quy tắc ECA trên CSDL Quản lý bán hàng. Gồm một số bảng chính sau: 60 3.2.1. Danh mục Cart: 2.2.2. Danh mục CartStatus: 2.2.3. Danh mục News: STT Tên trường Kiểu dữ liệu Ràng buộc 1 Id Bigint Khoá chính 2 userId Bigint 3 DateOrder Datetime 4 DateSell Datetime 5 Status Id Int Khóa ngoài STT Tên trường Kiểu dữ liệu Ràng buộc 1 Id Int Khoá chính 2 code nvarchar(50) 3 discription nvarchar(250) STT Tên trường Kiểu dữ liệu Ràng buộc 1 Id Bigint Khóa chính 2 code nvarchar(50) 3 discription ntext 4 Parent bigint 5 Parent Id Bigint Khoá ngoài 61 2.2.4. Danh mục Parent Product: 2.2.5. Danh mục Product: 2.2.6. Danh mục ProductCart: STT Tên trường Kiểu dữ liệu Ràng buộc 1 Id Bigint Khoá chính 2 Name nvarchar(250) 3 Code nvarchar(50) 4 Discription nvarchar(500) 5 GroupId bigint 6 FlagDisplay bit 7 Flag 1 bit 8 Flag 2 bit STT Tên trường Kiểu dữ liệu Ràng buộc 1 Id Bigint Khoá chính 2 Name nvarchar(250) 3 Code nvarchar(50) 4 OldCost bigint 5 Amount bigint 6 Discription ntext 7 CurrentCost Bigint 8 Promotion Description nvarchar(512) 9 Parent Id bigint Khoá ngoài STT Tên trường Kiểu dữ liệu Ràng buộc 1 CartId Bigint Khoá chính 2 ProductId bigint 3 amount int 62 2.2.7. Danh mục Role: 2.2.8. Danh mục user: 3.3. QUY TẮC TẠO TRIGGER Cú pháp để tạo một trigger giống như tạo thủ tục thường trú. Tuy nhiên, Trigger được tạo ra cho bảng dữ liệu cụ thể. CREATE Trigger ON [WITH ENCRYPTION] { { FOR | AFTER} | INSTEAD OF } AS STT Tên trường Kiểu dữ liệu Ràng buộc 1 Id Int Khoá chính 2 Discription nvarchar(250) 3 code nvarchar(50) STT Tên trường Kiểu dữ liệu Ràng buộc 1 Id Bigint Khoá chính 2 UserName nvarchar(50) 3 FullName nvarchar(250) 4 Password Ntext 5 discription Ntext 6 Email nvarchar(250) 7 Phone nvarchar(50) 8 typeCustomer nvarchar(50) 63 Trong đó: - ON chỉ ra rằng Trigger được viết cho bảng hoặc tên bảng ảo. Trigger với từ khóa AFTER không hỗ trợ VIEW - WITH ENCRYPTION: giống như trong Thủ tục thường trú hoặc bảng ảo cho phép ngăn ngừa việc sửa đổi nội dung Trigger. Sử dụng ALTER Trigger thì WITH ENCRYPTION không hỗ trợ. - FOR | AFTER: Mệnh đề FOR (AFTER) chỉ ra rằng Trigger sẽ áp dụng cho hành động nào trong ba hành động sau: INSERT, DELETE, UPDATE. Mệnh đề có dạng như sau: + FOR INSERT + FOR DELETE + FOR UPDATE + FOR INSERT, UPDATE, DELETE - INSTEAD OF: Trigger được thực thi thay cho các câu lệnh SQL gây ra Trigger. INSTEAD OF dùng được cho View. - [DELETE] [,] [INSERT] [,] [UPDATE]: xác định câu lệnh mà khi thực thi trên bảng hoặc VIEW sẽ gây ra trigger. 3.4. CÁC TRIGGER TRONG CSDL Trong phạm vi của luận văn tôi xin đưa ra chương trình thử nghiệm trên một CSDL về quản lý hàng hóa. Xây dựng các trigger đảm bảo một số ràng buộc đối với CSDL đó. 3.4.1. Trigger ngăn chặn việc xóa database trên Server. Với trigger này được dụng trong phạm vi Server với tên: tr_01_DontDropDataBase a. Lệnh tạo (create) và kiểm tra (test) trigger: /*1.tr_01_DontDropDataBase*/ --Create IF EXISTS (SELECT * FROM sys.triggers WHERE parent_class = 0 AND name = 'tr_01_DontDropDataBase') DROP TRIGGER tr_01_DontDropDataBase 64 ON ALL SERVER; GO CREATE TRIGGER tr_01_DontDropDataBase ON ALL SERVER FOR DROP_DATABASE AS RAISERROR ('tr_01_DontDropDataBase:Ban khong the xoa DataBase nay.Muon xoa ban phai disable trigger tr_01_DontDropDataBase !',10, 1) ROLLBACK GO --Test DROP Database databaseTest GO c. Hiển thị thông báo sau khi chạy Test 3.4.2. Trigger ngăn chặn insert vào bảng Product. a. Mô tả: Với tên: tr_02_Product. Sử dụng trong phạm vi bảng Table Product - Khi gặp sự kiện Thêm dữ liệu vào bảng Product. 65 - Với điều kiện là Các trường Name, Code, ParentId mới insert vào bị trùng với record đã tồn tại trong bảng Product. - Hành động xảy ra là: Không cho phép insert dữ liệu trùng Name, Code, ParentId (rollback lại table, dữ liệu của table vẫn như cũ) b. Lệnh tạo và kiểm tra: /*2.tr_02_Product*/ --Create IF OBJECT_ID('tr_02_Product','TR') IS NOT NULL DROP TRIGGER tr_02_Product; GO CREATE TRIGGER tr_02_Product ON Product AFTER INSERT AS DECLARE @Name nvarchar(250), @Code nvarchar(50), @ParentId bigint SELECT @Name = inst.Name, @Code =inst.Code, @ParentId = inst.ParentId FROM inserted AS inst IF EXISTS ( SELECT * FROM Product WHERE Name = @Name AND Code = @Code AND ParentId =@ParentId ) BEGIN RAISERROR ('tr_02_Product:San pham nay da co trong bang, ban khong insert vao duoc nua',16,1) ROLLBACK TRANSACTION END GO --Test 66 SELECT * FROM [Product] WHERE ParentId =16 AND Code = 'updatecode' AND Name = 'updateproduct' GO INSERT INTO [ECADataBase].[dbo].[Product] ([Name],[Code],[ParentId],[FlagNew],[FlagDeleted],[Fl agHot]) VALUES ('updateproduct','updatecode',16,1,1,1) c. Hiển thị thông báo sau khi chạy Test. 3.4.3. Trigger ngăn chặn update (cập nhật) bảng Product. Với tên tr_03_Product. Phạm vi sử dụng trong bảng Table Product. a. Mô tả - Event: cập nhật (Update) bảng Product. - Condition: Giá trị update của CurrentCost nằm ngoài khoảng (10000,2000000) - Action: Rollback lại dữ liệu, không update dữ liệu mới b. Lệnh tạo và kiểm tra: /*3.tr_03_Product*/ 67 --Create IF OBJECT_ID('tr_03_Product','TR') IS NOT NULL DROP TRIGGER tr_03_Product; GO CREATE TRIGGER tr_03_Product ON Product AFTER UPDATE AS DECLARE @CurrentCost bigint SELECT @CurrentCost = inst.CurrentCost FROM inserted AS inst IF (@CurrentCost 2000000) BEGIN IF(@CurrentCost < 10000) RAISERROR ('tr_03_Product:Ban Update sai.CurrentCost khong the nho hon 10000',16,1) IF (@CurrentCost > 2000000) RAISERROR ('tr_03_Product:Ban Update sai.CurrentCost khong the lon hon 2000000',16,1) ROLLBACK TRANSACTION END GO --Test SELECT * FROM Product WHERE Id =1195 Update Product Set CurrentCost =2300000 WHERE Id =1195 3.4.4. Trigger ngăn chặn xóa dữ liệu trong bảng Tên tr_04_Product. Sử dụng trong phạm vi bảng Table Product a. Mô tả: - Event: Xóa dữ liệu trong bảng. - Condition: Record (row) của bảng có trường Amount > 0. - Action: Rollback lại dữ liệu, không xóa được record có Amount >0 b. Lệnh tạo và kiểm tra: 68 --Create IF OBJECT_ID('tr_04_Product','TR') IS NOT NULL DROP TRIGGER tr_04_Product; GO CREATE TRIGGER tr_04_Product ON Product AFTER DELETE AS DECLARE @Amount bigint SELECT @Amount = inst.Amount FROM deleted AS inst BEGIN IF(@Amount > 0) RAISERROR ('tr_04_Product:San pham van con trong kho.Ban khong the xoa duoc',16,1) ROLLBACK TRANSACTION END GO --Test SELECT * FROM Product WHERE Id =1195 DELETE FROM Product WHERE Id =1195 3.4.5. Trigger ngăn chặn tạo mới record trong bảng. Tên tr_05_ProductCart. Sử dụng trong phạm vi bảng Table ProductCart a. Mô tả: - Event: tạo mới record trong bảng. - Condition:Trường Amount của record này có giá trị lớn hơn trường Amount của record bảng Product mà có cùng ProducId với nhau. - Action: Rollback lại dữ liệu, không tạo mới được b. Lệnh tạo và kiểm tra: --Create IF OBJECT_ID('tr_05_ProductCart','TR') IS NOT NULL DROP TRIGGER tr_05_ProductCart; 69 GO CREATE TRIGGER tr_05_ProductCart ON ProductCart AFTER INSERT AS DECLARE @AmountInProduct INT, @AmountInProductCart INT, @ProductId BIGINT SELECT @AmountInProductCart = Amount,@ProductId = ProductId FROM inserted SELECT @AmountInProduct = Amount FROM Product WHERE Id = @ProductId IF (@AmountInProduct < @AmountInProductCart) BEGIN RAISERROR ('tr_05_ProductCard:Ban ko the tao moi ProductCart.Vi Amount trong table Product < Amount ma ban muon tao trong table ProductCart',16,1) ROLLBACK TRANSACTION END GO --Test SELECT Id as ProductId,Name,Code,Amount,ParentId FROM Product WHERE Id =1195 INSERT INTO ProductCart (CartId,ProductId,Amount) VALUES (213,1195,1001) 3.4.6. Tạo mới trong bảng ( không vi phạm trigger của trigger 05) Với tên tr_06_ProductCart. Được sử dụng trong phạm vi bảng Table ProductCart, Product a. Mô tả: - Event : tạo mới record trong bảng. 70 - Condition: không vi phạm condition ở trigger tr_05_ProductCart. - Action: Cập nhật lại trường Amount trong bảng Product = Amount - giá trị Amount tạo mới của table ProductCart b. Lệnh tạo và kiểm tra: /*6.tr_06_ProductCart*/ --Create IF OBJECT_ID('tr_06_ProductCart','TR') IS NOT NULL DROP TRIGGER tr_06_ProductCart; GO CREATE TRIGGER tr_06_ProductCart ON ProductCart AFTER INSERT AS DECLARE @AmountInProduct INT, @AmountInProductCart INT, @ProductId BIGINT SELECT @AmountInProductCart = Amount,@ProductId = ProductId FROM inserted SELECT @AmountInProduct = Amount FROM Product WHERE Id = @ProductId IF (@AmountInProduct > @AmountInProductCart) BEGIN UPDATE Product SET Amount = @AmountInProduct - @AmountInProductCart WHERE Id = @ProductId PRINT('tr_06_ProductCart: Da update, giam Amount= ' +CAST(@AmountInProductCart AS nvarchar(10))+ ' trong Product xuong khi tao moi data trong ProductCart') END GO 71 --Test SELECT Id as ProductId,Name,Code,Amount,ParentId FROM Product WHERE Id =1195 INSERT INTO ProductCart (CartId,ProductId,Amount) VALUES (213,1195,100) DELETE FROM ProductCart UPDATE Product SET Amount = 1000 WHERE Id = 1195 3.4.7. Trigger ngăn chặn xóa bảng trong database. Với tên tr_07_DontDropTable. Sử dụng trong phạm vi bảng Database. a. Mô tả: Không cho phép xóa table trong cơ sở dữ liệu ECA Database b. Lệnh tạo và kiểm tra: /*7.tr_07_DontDropTable*/ --Create IF EXISTS (SELECT * FROM sys.triggers WHERE parent_class = 0 AND name = 'tr_07_DontDropTable') DROP TRIGGER tr_07_DontDropTable ON DATABASE; GO CREATE TRIGGER tr_07_DontDropTable ON DATABASE FOR DROP_TABLE AS RAISERROR ('tr_07_DontDropTable:Ban khong the xoa table trong co so du lieu duoc.Muon xoa ban phai disable trigger tr_07_DontDropTable !',10, 1) ROLLBACK GO --Test DROP TABLE TableForTest2 3.4.8. Ngăn chặn xóa trigger trong CSDL Với tên: tr_08_DontDropTrigger. Sử dụng trong phạm vi bảng Database. a. Mô tả: Không cho phép xóa trigger trong CSDL ECA Database. 72 b. Lệnh tạo và kiểm tra: /*8.tr_08_DontDropTrigger*/ --Create IF EXISTS (SELECT * FROM sys.triggers WHERE parent_class = 0 AND name = 'tr_08_DontDropTrigger') DROP TRIGGER tr_08_DontDropTrigger ON DATABASE; GO CREATE TRIGGER tr_08_DontDropTrigger ON DATABASE FOR DROP_TRIGGER AS RAISERROR ('tr_08_DontDropTrigger:Ban khong the xoa Trigger trong co so du lieu duoc.Muon xoa ban phai disable trigger tr_08_DontDropTrigger !',10, 1) ROLLBACK GO --Test DROP TRIGGER tr_07_DontDropTable ON DATABASE 3.4.9. Không cho phép tạo mới bảng trong CSDL. Với tên bảng: tr_09_DontCreateTable. Sử dụng trong phạm vi bảng Database a. Mô tả: Không cho phép tạo mới table trong CSDL ECA DataBase b. Lệnh tạo và kiểm tra: /*09.tr_09_DontCreateTable*/ --Create IF EXISTS (SELECT * FROM sys.triggers WHERE parent_class = 0 AND name = 'tr_09_DontCreateTable') DROP TRIGGER tr_09_DontCreateTable ON DATABASE; GO CREATE TRIGGER tr_09_DontCreateTable ON DATABASE 73 FOR CREATE_TABLE,ALTER_TABLE AS RAISERROR ('tr_09_DontCreateTable:Ban khong co quyen them table hoac sua chua table ! Muon tao moi table ban phai disable trigger tr_09_DontCreateTable !',16, 1) ROLLBACK GO --Test CREATE TABLE TestCreateTable (OrderID int, CustID int) 3.4.10. Không cho phép tạo mới trigger trong CSDL. Với tên bảng: tr_10_DontCreateTrigger. Phạm vi sử dụng trong bảng Database. a. Mô tả: Không cho phép tạo mới trigger trong CSDL b. Lệnh tạo và kiểm tra: /*10.tr_10_DontCreateTrigger*/ --Create IF EXISTS (SELECT * FROM sys.triggers WHERE parent_class = 0 AND name = 'tr_10_DontCreateTrigger') DROP TRIGGER tr_10_DontCreateTrigger ON DATABASE; GO CREATE TRIGGER tr_10_DontCreateTrigger ON DATABASE FOR CREATE_TRIGGER AS RAISERROR ('tr_10_DontCreateTrigger:Ban khong the tao Trigger moi duoc nua. Muon tao them trigger ban phai xoa trigger tr_10_DontCreateTrigger !',10, 1) ROLLBACK GO --Test 74 IF EXISTS (SELECT * FROM sys.triggers WHERE parent_class = 0 AND name = 'triggerForTest') DROP TRIGGER triggerForTest ON DATABASE; GO CREATE TRIGGER triggerForTest ON Product AFTER INSERT AS PRINT('Tao moi triggerForTest') GO 75 KẾT LUẬN Cơ sở dữ liệu là nền tảng của việc lưu trữ dữ liệu, được thể hiện ở chỗ nó là dữ liệu chính và duy nhất tồn tại thực sự cho mọi ứng dụng. Trong số những lĩnh vực nhận được sự chú ý trong những năm gần đây với cái nhìn làm nổi bật sự hoạt động dễ dàng là lập trình cơ sở dữ liệu, các cơ sở dữ liệu tạm thời, các cơ sở dữ liệu không gian, các cơ sở dữ liệu đa phương tiện (truyền thông), các cơ sở dữ liệu suy diễn và các cơ sở dữ liệu tích cực. Vì vậy tính ứng dụng của khai thác cơ sở dữ liệu là một vấn đề đang được quan tâm bởi tính ứng dụng cao trong thực tế. Trên cơ sở đó luận văn đã nghiên cứu và đưa ra một số vấn đề sau: Thứ nhất, đã trình được tổng quan về cơ sở dữ liệu quan hệ, các ràng buộc toàn vẹn trên cơ sở dữ liệu Thứ hai, luận văn đã tìm hiểu về cơ sở dữ liệu tích cực và các quy tắc ECA trong cơ sở dữ liệu tích cực Thứ ba, trên cơ sở tìm hiểu lý thuyết về cơ sở dữ liệu tích cực, luận văn đã đưa ra chương trình thử nghiệm ứng dụng tốt trong việc mở rộng các hệ thống cơ sở dữ liệu, làm dễ dàng cho người sử dụng khai thác cơ sở dữ liệu Với nội dung trình bày của luận văn hy vọng đóng góp phần nào việc tìm hiểu và xây dựng cài đặt các quy tắc ECA trên SQL. Tuy nhiên, do giới hạn phạm vi nghiên cứu, luận văn mới chỉ tập trung tìm hiểu những khái niệm cơ bản và do thời gian và khả năng có hạn vì vậy chương trình thử nghiệm còn nhiều hạn chế và luận văn khó tránh khỏi những thiếu sót. Rất mong những ý kiến tham gia bổ sung của thầy cô để luận văn được hoàn thiện hơn. 76 TÀI LIỆU THAM KHẢO Tiếng Việt 1. TS. Nguyễn Tuệ (2007), Nhập môn cơ sở dữ liệu, Nhà xuất bản Giáo dục. 2. TS. Nguyễn Tuệ (2006), Giáo trình Ngôn ngữ SQL, Nhà xuất bản Đại học Quốc Gia. Tiếng Anh 3. N. H. Gehani-H. V. Jagadish-AT&T Bell Laboratories-Murray Hill, Ode as an Active Database: Constraints and Triggers, New Jersey 07974, pp. 19-22 4. Klaus R. Dittrich, Stella Gatziu-Institut fr Informatik, Universitt Zrich: Time Issues in Active Database Systems, Winterthurerstrasse 190, CH-8057 Zurich, Switzerland 5. NORMANW.PATON, ActiveDatabaseSystems, University of Manchester and OSCARDIAZ, University of the Basque Country, pp. 67-72