XỬ LÝ CÂU TRUY VẤN BẰNG PHÉP TOÁN ĐẠI SỐ KẾT HỢP THỜI GIAN
lượt xem 19
download
Tìm hiểu các phép toán đại số kết hợp thời gian Thiết kế CSDL đối tượng cho một ứng dụng Xây dựng các luật sinh để xử lý câu truy vấn trên ứng dụng minh họa
Bình luận(0) Đăng nhập để gửi bình luận!
Nội dung Text: XỬ LÝ CÂU TRUY VẤN BẰNG PHÉP TOÁN ĐẠI SỐ KẾT HỢP THỜI GIAN
- LUAÄN VAÊN TOÁT NGHIEÄP PHẦN 2 : MÔ HÌNH ĐỐI TƯỢNG Trang 21
- LUAÄN VAÊN TOÁT NGHIEÄP 1- TỔNG QUAN Mục này định nghĩa mô hình đối tượng hỗ trợ bởi ODMG - Hệ quản trị cơ sở dữ liệu đối tượng nhượng bộ. Mô hình đối tượng là quan trọng bởi vì nó cụ thể những loại ngữ nghĩa mà có thể định nghĩa rõ ràng đối với 1 ODBMS. Về các vấn đề còn lại, ngữ nghĩa của mô hình đối tượng xác định các đặc điểm của đối t ượng, các đối tượng có thể quan hệ với các đối t ượng khác như thế nào, và các đối tượng có thể được định danh và nhận dạng như thế nào. Xây dựng mô hình đối tượng được hỗ trợ bởi ODBMS với các chi tiết sau : - Nguồn gốc của mô hình cơ sở là đối tượng và Literal. Mỗi đối tượng có 1 bộ nhận dạng duy nhất. Literal không có bộ nhận dạng. - Trạng thái của 1 đối tượng được xác định bởi giá trị mà đối tượng đó truyền cho 1 tập tính chất. Những tính chất này có thể là thuộc tính của chính đối tượng đó hoặc mối quan hệ giữa đối tượng này với 1 hoặc nhiều đối tượng còn lại. Điển hình là giá trị của tính chất đối tượng có thể được thay đổi mọi lúc. - Hành vi của 1 đối tượng được xác định bởi tập các thủ tục mà có thể thực thi trên đối tượng của nó. Tất cả các phần tử của 1 kiểu có 1 trạng thái giới hạn chung (như cùng tập tính chất) và hành vi chung (cùng t ập thủ tục xác định). Đôi khi 1 đối tượng được tham khảo như 1 sự thể hiện của kiểu đối tượng. - Một cơ sở dữ liệu lưu trữ các đối tượng cho phép chúng được chia sẽ giữa nhiều người sử dụng và các ứng dụng. Một cơ sở dữ liệu được dựa trên 1 lược đồ mà được định nghĩa trong Ngôn ngữ định nghĩa đối tượng (Object Definition Language (ODL)) và bao hàm thể hiện của những kiểu được xác định bởi lược đồ của nó. Mô hình đối tượng ODMG đề cập đến ý nghĩa của đối t ượng, Literal, kiểu, thủ tục, tính chất, thuộc tính, mối quan hệ ... Một người phát triển ứng dụng dùng cấu trúc của mô hình đối tượng ODMG để xây dựng mô hình đối tượng cho ứng dụng. Mô hình đối tượng ODMG là nền tảng định nghĩa về vai trò của 1 ODBMS. Mô hình đối tượng ODMG bao gồm việc diễn tả ý nghĩa giàu ngữ nghĩa hơn mô hình quan hệ bởi mối quan hệ khai báo và các thủ tục rõ ràng. 2- Kiểu và lớp; Giao tiếp và thực hiện Có 2 hướng để định nghĩa 1 kiểu. Một kiểu có 1 đặc tả giao tiếp cụ thể và 1 hoặc nhiều đặc tả công cụ. Giao tiếp định nghĩa các đặc tính mở rộng của k iểu đối tượng, những đặc tính mở rộng này là diện mạo đối tượng mà có thể thấy được người sử dụng đối tượng. Đây là các thủ tục mà có thể thi hành trên đối tượng và các biến trạng thái mà giá trị có thể được truy cập. Ngược lại, định nghĩa công cụ của 1 kiểu là diện mạo bên trong đối tượng của kiểu. Một công cụ của 1 kiểu bao gồm 1 representation và 1 tập các method : representation là 1 cấu trúc dữ liệu. Method là phần thủ tục chính. Có 1 method cho mỗi thủ tục xác định trong đặc tả giao tiếp kiểu. Một công cụ method có thể nhìn thấy được hành vi bên ngoài của thủ tục kết hợp của nó. Một method có thể đọc hoặc sửa representation của 1 trạng thái đối t ượng hoặc đưa ra thực thi thủ tục định nghĩa trên các đối tượng khác. Cũng có thể có method và các cấu trúc dữ liệu trong 1 công cụ mà không có thủ tục bổ sung trực tiếp hoặc các biến trạng thái của giao tiếp kiểu. Bên trong công cụ là không thể nhìn thấy được đối với người sử dụng đối tượng. Sự khác biệt giữa giao tiếp và công cụ là quan trọng. Sự phân chia giữa 2 việc này là cách mà mô hình đối tượng xem xét tóm tắt. Một kiểu có thể có nhiều hơn 1 đặc tả công cụ, mặc dù chỉ có 1 công cụ có thể được dùng trong những chương trình cụ thể. Ví dụ, 1 kiểu có thể có 1 công cụ C++ và 1 công cụ smalltalk. Hoặc 1 kiểu có thể có 1 công cụ C++ cho 1 cấu trúc máy tính và 1 công cụ C++ khác cho 1 cấu Trang 22
- LUAÄN VAÊN TOÁT NGHIEÄP trúc máy tính khác. Tách biệt giao tiếp từ những công cụ làm cho ngữ nghĩa của kiểu trở nên lộn xộn với các chi tiết representation. Tách biệt giao tiếp với công cụ là 1 bước tiến chắc chắn hướng đến việc truy cập đối tượng bằng nhiều cách của 1 kiểu duy nhất và chia sẽ đối tượng thông qua môi trường tính toán không đồng nhất. Đôi khi, ta tham khảo 1 cách mơ hồ về 1 sự giao tiếp bởi chính nó chẳng hạn như 1 kiểu, và về công cụ của 1 kiểu chẳng hạn như 1 lớp. Một đối tượng là sự thể hiện 1 lớp. Rồi đặc tả lớp được dùng để thực thi tất cả thể hiện các kiểu. Ví dụ, đặc tả lớp C++ được dùng bởi cả 2 tr ình biên dịch C++ và ODBMS để tạo ra sự thể hiện của 1 kiểu. 2.1- Kiểu con và thừa kế (Subtype and Inheritance) Mô hình đối tượng ODMG bao gồm mối quan hệ thừa kế cơ bản kiểu - kiểu con. Những mối quan hệ được biểu diễn chung bằng đồ thị, mỗi nút là 1 kiểu và mỗi đường cung nối kết 1 kiểu, được gọi là siêu kiểu và kiểu còn lại gọi là kiểu con. Đôi khi cũng gọi là mối quan hệ tổng quát - cụ thể. Siêu kiểu là kiểu tổng quát; kiểu con là kiểu cụ thể. interface Employee{...} interface Professor : Employee{...} interface Associate_Professor : Professor{...}; Ví dụ, Associate_Professor là 1 kiểu con của Professor. Professor là 1 kiểu con của Employee. Một sự thể hiện của 1 kiểu con thì cũng hợp lý như sự thể hiện của siêu kiểu. Do đó 1 thể hiện Associate_Professor thì cũng hợp lý như thể hiện Professor. Điều đó làm Associate_Professor là 1 trường hợp đặc biệt của Professor. Kiểu chi tiết đầy đủ của đối t ượng là kiểu mà mô tả tất cả hành vi và tính chất thể hiện. Ví dụ, kiểu chi tiết đầy đủ cho đối t ượng Associate_Professor là giao tiếp Associate_Professor; mà đối tượng cũng mang thông tin từ giao tiếp Professor và Employee. Thể hiện Associate_Professor phù hợp với hành vi được định nghĩa trong giao tiếp Associate_Professor, Professor và những siêu kiểu của giao tiếp Professor (và những siêu kiểu của chúng,...). Nơi mà đối tượng của kiểu Professor có thể được dùng thì đối tượng của kiểu Associate_Professor có thể được thay thế, bởi vì Associate_Professor thừa kế từ Professor. Một sự giao tiếp của kiểu con có thể định nghĩa các đặc tính được thêm vào định nghĩa này trên các siêu kiểu của nó. Những diện mạo mới này của trạng thái hoặc ứng dụng hành vi chỉ thể hiện của kiểu con (và những kiểu con của nó). Ví dụ, kiểu Employee có thể có 1 thủ tục cho calculate_paycheck. Kiểu con Solaried_Employee và Hourly_Employee có thể mỗi trích lược hành vi để phản ánh chuyên môn của họ. Bản tính đa hình của lập trình đối tượng sẽ cho phép hành vi phù hợp được đưa ra thực thi tại thời gian chạy, phụ thuộc vào kiểu hiện tại được thể hiện. interface Teaching_Assistant : Employee, Student {...}; Mô hình đối tượng ODMG hỗ trợ nhiều sự thừa kế. Do đó có thể rằng 1 đặc tính thừa kế kiểu thì có cùng tên, nhưng khác ngữ nghĩa từ 2 siêu kiểu khác nhau. Mô hình hiện tại không cụ thể sự cùng tên được giải quyết như thế nào; đây là vấn đề của định nghĩa công cụ. interface salaried_Employee : Employee{...}; interface Hourly_Employee : Employee{...}; Một số kiểu có thể được thể hiện trực tiếp được gọi là kiểu xác thực. Các kiểu còn lại được gọi là kiểu trừu tượng và không được thể hiện trực tiếp. Ví dụ, nếu phù hợp với trường hợp tất cả công nhân đều được trả lương hoặc tính theo giờ, thì salaried_Employee và Hourly_Employee sẽ là kiểu xác thực và siêu kiểu Employee của chúng là kiểu trừu tượng. Trang 23
- LUAÄN VAÊN TOÁT NGHIEÄP Không có sự thể hiện trực tiếp Employee. ODL không biểu thị rõ ràng 1 kiểu là xác thực hoặc trừu tượng. 2.2- Tầm hoạt động của kiểu (Extents) Phạm vi hoạt động của 1 kiểu là tập của tất cả thể hiện của kiểu trong 1 cơ sở dữ liệu cụ thể. Nếu 1 đối tượng là thể hiện kiểu A thì nó sẽ là 1 thành viên của tầm hoạt động A. Nếu kiểu A là 1 kiểu con của kiểu B, thì tầm hoạt động của A là tập con của tầm hoạt động B. Một DBMS quan hệ duy trì 1 tầm hoạt động cho mỗi bảng định nghĩa. Ngược lại, người thiết kế cơ sở dữ liệu đối tượng có thể quyết định ODBMS nên duy trì tự động tầm hoạt động của mỗi kiểu hay không. Sự duy trì tầm hoạt động bao gồm thêm mới để tạo thể hiện trong tập và loại bỏ thể hiện từ tập khi chúng bị xoá. Có thể cũng có nghĩa tạo và quản lý chỉ mục để tăng tốc độ truy cập đến thể hiện cụ thể trong tầm hoạt động. Duy trì chỉ mục có thể là sự quan trọng mà đã được đưa vào ở phần trên. Vì vậy người định nghĩa mô hình đối tượng cụ thể rằng tầm hoạt động nên được chỉ mục 1 cách riêng biệt từ sự cụ thể rằng tầm hoạt động nên được duy tr ì bởi ODBMS. 2.3- Khoá (Keys) Trong 1 số trường hợp thể hiện riêng lẻ của 1 kiểu có thể được nhận dạng duy nhất bởi giá trị mà chúng mang cho 1 số tính chất hoặc tập tính chất. những tính chất xác định này được gọi là khoá. Trong mô hình quan hệ, những tính chất này (thuộc tính trong cơ sở dữ liệu quan hệ) được gọi là khoá tuyển. Một khoá đơn giản bao gồm 1 tính chất duy nhất. Một khoá kết hợp bao gồm 1 tập tính chất. Một tầm hoạt động duy nhất là tầm hoạt động của 1 kiểu, vì vậy 1 kiểu phải có 1 tầm hoạt động ứng với 1 khoá. 3- Đối tượng Mục này xem xét theo mỗi hướng của đối tượng : - Bộ nhận dạng mà được dùng bởi 1 ODBMS để phân loại 1 đối t ượng từ 1 đối tượng khác và để tìm kiếm đối tượng. - Tên mà được thiết kế bởi người lập trình hoặc người sử dụng theo cách phù hợp để tham khảo đến đối tượng cụ thể. - Thời gian sống xác định bộ nhớ và lưu trữ định vị đối tượng được quản lý như thế nào. - Cấu trúc có thể là nguyên tử hoặc không phải là nguyên tử trong trường hợp mà đối tượng chứa đựng các đối tượng khác. Tất cả đối tượng có giao tiếp ODL theo sau mà được thừa hưởng hoàn toàn bởi định nghĩa của tất cả đối tượng người dùng định nghĩa. interface Object { boolean same_as(in Object anObject); Object copy(); void delete(); }; 3.1- Bộ nhận dạng đối tượng (Object identifiers) Bởi vì tất cả các đối tượng đều có bộ nhận dạng, 1 đối t ượng luôn luôn có thể phân loại từ tất cả đối tượng còn lại trong miền lưu trữ của nó. Ở đây 1 miền lưu trữ là 1 cơ sở dữ liệu. Tất cả bộ nhận dạng của các đối t ượng trong 1 cơ sở dữ liệu là duy nhất, quan hệ với đối tượng khác. Biểu diễn tính đồng nhất của 1 đối t ượng được tham khảo như bộ nhận dạng đối t ượng (hoặc Object_id). Một đối tượng vẫn giữ lại cùng bộ nhận dạng đối t ượng cho toàn bộ thời gian sống của nó. Do đó giá trị của 1 bộ nhận dạng của đố i tượng sẽ không bao giờ thay đổi. Đối t ượng vẫn Trang 24
- LUAÄN VAÊN TOÁT NGHIEÄP còn là đối tượng, ngay cả nếu giá trị thuộc tính hoặc mối quan hệ thay đổi. Một bộ nhận dạng đối tượng được dùng tổng quát như 1 phương tiện để 1 đối tượng tham khảo đến 1 đối t ượng khác. Chú ý rằng khái niệm của bộ nhận dạng đối t ượng là khác với khái niệm khoá chính trong mô hình quan hệ. Một dòng trong 1 bảng quan hệ được định dạng duy nhất bởi giá trị của cột tạo nên khoá chính của bảng. Nếu giá trị trong 1 dòng của các cột này thay đổi, các dòng thay đổ i được đồng nhất hoá và trở thành 1 dòng khác biệt. Ngay cả khả năng lần dò theo giá trị trước đây của khoá chính cũng bị mất. Literal không có bộ nhận dạng và không thể đơn độc như đối tượng. Chúng được gắn vào trong đối tượng và không thể được tham khảo riêng biệt. Giá trị Literal đôi khi được mô tả như hằng số. Giá trị của Literal không thể thay đổi. Ví dụ, giá trị Literal là số 7 và 3.141596, ký t ự A và B và chuổi Fred và April.1. Thay đổi giá trị của thuộc tính của 1 đối t ượng hoặc mối quan hệ mà nó không tham gia, không thay đổi sự đồng nhất đối tượng. Bộ nhận dạng đối t ượng được tạo bởi ODBMS, không phải bằng ứng dụng. Có nhiều cách có thể thực hiện bộ nhận dạng đối t ượng. Cấu trúc của 1 mẫu nhỏ biểu diễn 1 bộ nhận dạng đối tượng thì không được xác định bởi mô hình đối tượng, trong khi điều này được xem xét như là công cụ được tạo ra, không thích hợp cho việc hợp nhất trong mô hình đối tượng. Thay vào đó, thủ tục same_as() được hỗ trợ mà cho phép đồng nhất 2 đối tượng được so sánh. 3.2- Tên đối tượng (Object Names) Một đối tượng có thể có 1 hoặc nhiều t ên mà có ý nghĩa đến người lập trình hoặc người sử dụng. ODBMS cung cấp 1 chức năng mà dùng để ánh xạ từ tên 1 đối tượng đến 1 bộ nhận dạng đối tượng. Ứng dụng có thể tham khảo thuận lợi đến 1 đối t ượng bằng tên, ODBMS áp dụng chức năng ánh xạ để xác định bộ nhận dạng đối t ượng mà định vị đối tượng mong muốn. ODMG mong đợi tên được dùng 1 cách tổng quát bởi ứng dụng để tham khảo đến đối t ượng "gốc" mà cung cấp chỉ mục vào cơ sở dữ liệu. Tên đối tượng giống như tên biến toàn cục trong ngôn ngữ lập tr ình. Chúng cũng không có khoá. Một khoá được bao gồm các tính chất cụ thể trong giao tiếp kiểu đối t ượng. Ngược lại, 1 tên đối tượng không được định nghĩa trong giao tiếp tiếp và không tương ứng với giá trị t ính chất của đối tượng. Phạm vi hoạt động của t ên duy nhất là 1 cơ sở dữ liệu. Mô hình đối tượng không bao gồm khái niệm của vùng tên phân cấp trong 1 cơ sở dữ liệu, hoặc vùng tên liên quan đến nhiều cơ sở dữ liệu. 3.3- Thời gian sống của đối tượng (Object Lifetimes) Thời gian sống của 1 đối t ượng được xác định trong bộ nhớ và lưu trữ định vị đối tượng được quản lý như thế nào. Thời gian sống của đối tượng được xác định vào lúc đối tượng được tạo. Hai thời gian sống được hỗ trợ trong mô hình đối tượng : - ngắn ngủi (transient) - lâu dài (persistent) Một đối tượng mà có thời gian sống là ngắn ngủi được định vị trong bộ nhớ mà được quản lý bởi hệ thống thời gian thực thi của ngôn ngữ lập trình. Đôi khi 1 đối tượng tồn tại ngắn ngủi được khai báo ở trên đầu của 1 thủ tục và được định vị trong bộ nhớ từ stack tạo bởi hệ thống thời gian thực thi ngôn ngữ lập tr ình khi thủ tục được đưa ra thực thi. Bộ nhớ đó được giải phóng khi thủ tục trở về. Đối tượng ngắn ngủi còn lại được quản lý bởi 1 quá trình hơn là 1 hoạt động của thủ tục và được định vị đến cả bộ nhớ tĩnh hoặc heap bởi hệ ngôn ngữ lập tr ình. Khi quá trình kết thúc, bộ nhớ được thu hồi. Một đối tượng mà có thời gian sống là lâu dài được định vị bộ nhớ và lưu trữ quản lý bởi hệ thời gian thực thi ODBMS. Những đối tượng này tiếp tục tồn Trang 25
- LUAÄN VAÊN TOÁT NGHIEÄP tại sau khi thủ tục hoặc quá trình mà tạo ra chúng kết thúc. Đôi khi đối t ượng tồn tại lâu dài được tham khảo như đối tượng cơ sở dữ liệu. Ngôn ngữ lập trình cụ thể có thể cải tiến ý tưởng về dạng thời gian sống ngắn ngủi theo cách sống lâu dài theo khái niệm thời gian sống của đối tượng. Một khiá cạnh quan trọng của thời gian sống đối t ượng là chúng độc lập với kiểu. Một kiểu có thể có nhiều thể hiện thời gian sống lâu dài và ngắn ngủi. Sự độc lập của kiểu và thời gian sống là hoàn toàn khác với mô hình quan hệ. Trong mô hình quan hệ, những kiểu được biết đến trong DBMS được định nghĩa chỉ có 1 thể hiện thời gian sống lâu dài và những kiểu không được biết đến trong DBMS được định nghĩa chỉ có 1 thể hiện thời gian sống ngắn ngủi. Bởi vì mô hình đối tượng ODMG hỗ trợ độc lập về kiểu và thời gian sống, cả 2 đối t ượng tồn tại lâu dài và ngắn ngủi có thể được thao tác dùng cùng thủ tục. Trong mô hình quan hệ, SQL phải dùng để định nghĩa và sử dụng dữ liệu thời gian sống lâu dài, trong khi ngôn ngữ lập trình thì dùng để định nghĩa và sử dụng dữ liệu thời gian sống ngắn ngủi. 3.4- Đối tượng Atomic (Atomic Objects) Kiểu đối tượng Atomic là người sử dụng xác định. Không có kiểu đối t ượng Atomic sẵn có bao gồm trong mô hình đối tượng ODMG. 3.5- Đối tượng Collection (Collection Objects) Trong mô hình đối tượng ODMG, kiểu đối tượng mà không phải là Atomic là Collection. Thể hiện các kiểu này gồm có các phần tử cơ bản riêng biệt, mỗi phần tử cơ bản có thể được thể hiện của 1 kiểu Atomic, kiểu Collection khác hoặc 1 kiểu Literal. Một đặc tính phân loại quan trọng của 1 Collection là tất cả các phần tử cơ bản của Collection phải cùng kiểu. Tất cả chúng phải cùng kiểu Atomic hoặc Collection hoặc kiểu Literal. Kiểu Collection hỗ trợ bởi mô hình đối tượng ODMG bao gồm : - Set - Bag - List - Array Mỗi chúng có 1 bộ tạo kiểu, thông số cho bởi kiểu được trình bày trong dấu ngoặc nhọn. Tất cả các phần tử cơ bản của đối tượng Set thì cùng kiểu t. Tất cả các phần tử cơ bản của đối tượng List thì cùng kiểu t. Trong giao tiếp dưới đây, ta chọn dùng kiểu ODL để biểu diễn thông số kiểu, nhận thấy rằng điều này có thể hàm ý 1 sự không đồng nhất mà không có ý định đưa vào mô hình đối tượng này. Collection có 2 thủ tục sau : interface Collection : Object { unsigned long cardinality(); boolean is_empty(); void insert_element(in any element); void remove_element(in any element); boolean contains_element(in any element); Iterator creat_iterator(); }; interface Iterator : Object { exception Empty(); exception NoMoreElements(); boolean not_done(); Trang 26
- LUAÄN VAÊN TOÁT NGHIEÄP boolean next(out any next_obj); void advance() raises(NoMoreElements); any get_element() raises(Empty); void reset(); }; Một phần tử cơ bản được thêm vào trong 1 Collection hoặc có thể được loại bỏ từ 1 Collection. Một đối tượng Collection có thể được kiểm tra sự tồn tại của 1 phần tử cơ bản xác định. Một Iterator là 1 cơ cấu để truy cập các phần tử cơ bản của đối tượng Collection có thể được tạo. Một bản sao của 1 Collection trả về 1 đối t ượng Collection mới mà các phần tử cơ bản thì cũng giống như các phần tử cơ bản của đối tượng Collection gốc.Đây là 1 thủ tục sao cóp thô. 3.5.1- Đối tượng Set (Set Objects) Một đối tượng Set là 1 collection không sắp thứ tự của các phần tử cơ bản, không được phép sao chép lại. Set cải tiến các thủ tục theo sau thừa hưởng từ siêu kiểu Collection : interface Set : Collection { Set union_with(in Set other); Set intersection_with(in Set other); Set Difference_with(in Set other); boolean is_subset_of(in set other_set); boolean is_proper_subset_of(in Set other_set); boolean is_superset_of(in set other_set); boolean is_proper_superset_of(in Set other_set); }; Thủ tục thừa hưởng insert_element chèn đối tượng qua đối số của nó vào trong 1 tập đối tượng tồn tại. Nếu đối tượng chuyển 1 đối số đã có 1 thành viên của đối tượng Set, thủ tục đưa ra lỗi. Sự cân bằng được xem xét bởi toán tử same_as của phần tử cơ bản. Thêm vào các thủ tục thừa kế từ các siêu kiểu của nó, giao tiếp kiểu Set có thủ tục tập số học phù hợp, cũng như thủ tục kiểm tra tập con và siêu tập kiểu boolean. Thủ tục union_with, intersection_with, difference_with trả về 1 kết quả mới của đối tượng Set. 3.5.2- Đối tượng Bag (Bag Objects) Đối tượng Bag là 1 Collection không sắp xếp của phần tử cơ bản mà có thể chứa bản sao. Sự cân bằng của các phần tử cơ bản được xác định bởi toán tử same_as của các phần tử cơ bản. Bag bao gồm thủ tục theo sau thừa hưởng từ siêu kiểu Collection của nó : insert_element, remove_element. Thủ tục insert_element, chèn vào trong đối tượng Bag phần tử cơ bản thông qua 1 đối số. Nếu phần tử cơ bản đã có 1 thành viên của bag, nó sẽ được chèn vào lúc khác, làm tăng vô số trong Bag. Thêm vào các thủ tục thừa hưởng từ siêu kiểu Collection, kiểu Bag có các thủ tục theo sau xác định trong giao tiếp của nó : interface Bag : Collection { Bag union_with(in Bag other); Bag intersection_with(in Bag other); Bag diference_with(in Bag other); }; Trang 27
- LUAÄN VAÊN TOÁT NGHIEÄP Thủ tục union_with thì tương đương tạo ra 1 đối tượng bag mới mà là 1 bản sao của Bag nhận, rồi lập lại thông qua Bag của đối số và thực hiện 1 phép chèn vào 1 Bag mới cho mỗi phần tử cơ bản trong đối số của Bag đó. 3.5.3- Đối tượng List (List Objects) Đối tượng List là 1 Collection được sắp xếp của phần tử cơ bản. Thêm vào các thủ tục thửa hưởng từ siêu kiểu Collection, kiểu List có các thủ tục cụ thể : interface List : Collection { void replace_element_at(in usigned long index, in any element); any remove_element_at(in unsigned long index); any retrieve_element_at(in unsigned long index); void insert_element_after(in any obj, in unsigned long index); void insert_element_before(in any obj, in unsigned long index); void insert_element_first(in any obj); void insert_element_last(in any obj); any remove_first_element(); any remove_last_element(); any retrieve_first_element(); any retrieve_last_element(); List concat(in List other); void append(in List other); }; Những thủ tục này được đặt tự nhiên, ngay cả tham khảo theo 1 chỉ mục cho trước hoặc điểm bắt đầu hoặc cuối cùng của đối tượng list. Chỉ mục của 1 đối tượng List bắt đầu từ 0. 3.5.4- Đối tượng Array(Array Objects) Đối tượng Array là 1 Collection với 1 số cố định các phần tử cơ bản mà có thể xác định bằng vị trí. Kiểu Array định nghĩa các thủ tục theo sau được thêm vào các thừa hưởng này từ siêu kiểu Collection của nó : interface Array : Collection { void replace_element_at(in usigned long index, in any element); any remove_element_at(in unsigned long index); any retrieve_element_at(in unsigned long index); void resize(in unsigned long new_size); }; Thủ tục remove_element_at thay thế những phần tử cơ bản hiện thời chứa đựng trong ô của đối tượng array xác định bởi vị trí có giá trị null. Nó không loại bỏ ô hoặc thay đổi kích thước của array. Đây là sự đối lập của thủ tục remove_element_at định nghĩa trên kiểu List mà không thay đổi số phần tử cơ bản trong 1 đối t ượng List. Thủ tục định lại kích thước cho phép 1 đối tượng array thay đổi tối đa số phần tử cơ bản nó có thể chứa. 4- Literals Literal không có bộ nhận dạng đối tượng. Mô hình đối tượng hỗ trợ 3 kiểu Literal : - Atomic Literal - Collection Literal - Structured Literal 4.1- Atomic Literal : Trang 28
- LUAÄN VAÊN TOÁT NGHIEÄP Các ký hiệu và đặc tính là những ví dụ kiểu Atomic Literal. Thể hiện của những kiểu này không tạo rõ ràng bởi ứng dụng, nhưng tồn tại khá chắc chắn. Mô hình đối tượng ODMG hỗ trợ các kiểu theo sau của Atomic Literal : - Long - Short - Unsigned long - Unsigned short - Float - Double - Boolean - Octet - Char (character) - String - Enum (enumeration) Những kiểu này tất cả cũng được hỗ trợ bởi IDL (Interface Definition Language) OMG. Mục đích của mô hình đối tượng đó là sự ràng buộc ngôn ngữ lập tr ình nên hỗ trợ ngôn ngữ cụ thể tương tự của những kiểu này cũng như những kiểu Atomic Literal định nghĩa bởi ngôn ngữ lập trình. Nếu ngôn ngữ lập trình không chứa đựng 1 kiểu tương tự trong các kiểu mô hình đối tượng thì 1 thư viện lớp định nghĩa công cụ của kiểu nên được cung cấp như 1 phần của sự ràng buộc ngôn ngữ lập trình. Enum là 1 bộ tạo kiểu. Khai báo Enum định nghĩa 1 kiểu Literal danh định mà có thể chỉ nhận những giá trị được liệt kê khai báo. Ví dụ, 1 giống thuộc tính được định nghĩa bởi : attribute Enum Gender{male,female}; Một thuộc tính State_code được xác định bởi : attribute Enum State_code{AK,AL,AZ,CA,...,WY}; 4.2- Collection Literal : Mô hình đối tượng ODMG hỗ trợ Collection Literal của những kiểu sau: - Set - Bag - List - Array Những bộ tạo kiểu này thì tương tự như những bộ tạo kiểu đó của đối t ượng collection, nhưng những collection này không có bộ nhận dạng đối t ượng. Tuy nhiên, những phần tử cơ bản của chúng có thể là kiểu Literal hoặc kiểu đối t ượng. 4.3- Structured Literal : Structured Literal có 1 số cố định phần tử cơ bản, mỗi phần tử cơ bản có 1 tên biến và có thể chứa giá trị từ hoặc 1 đối tượng. Một phần tử cơ bản của 1 structured được tham khảo bằng tên biến, ví dụ address.zipcode = 12345; address.city = "San Francisco". Kiểu structured hỗ trợ bởi mô hình đối tượng ODMG bao gồm : - Date - Interval - Time - Timestamp Những kiểu này được xác định trong đặc tả SQL chuẩn bởi giao tiếp sau: 4.3.1- Date : Giao tiếp sau định nghĩa các thủ tục trên đối tượng Date : Trang 29
- LUAÄN VAÊN TOÁT NGHIEÄP interface Date : Object { typedefunsigned short ushort; enum Weekday{Sunday, Monday, Tuesday, Wednesday, Thusday, Friday, Saturday}; enum Month{January, February, March, April, May, June, July, August, September, Octorber, November, December}; struct asValue{ushort month, day, year}; ushort year(); ushort month(); ushort day(); ushort day_of_year(); Month month_of_year(); Weekday day_of_week(); boolean is_leap_year(); boolean is_equal(in Date a_date); boolean is-greater(in Date a_date); boolean is_greater_or_equal(in Date a_date); boolean is_less(in Date a_date); boolean is_less_or_equal(in Date a_date); boolean is_between(in Date a_date, in Date b_date); Date next(in Weekday day); Date previous(in weekday day); Date add_days(in ushort days); Date subtract_days(in ushort days); long subtract_date(in Date a_date); }; 4.3.2- Interval Interval biểu diễn 1 khoảng thời gian xác định v à được dùng để thực hiện 1 số thủ tục trên đối tượng Time và Timestamp interface Interval : Object { typedefunsigned short ushort; ushort day(); ushort hour(); ushort minute(); float second(); struct asValue{ushort day, hour, minute, float second}; boolean is_zero(); Interval plus(in Interval an_interval); Interval minus(in Interval an_interval); Interval product(in short val); Interval quotient(in short val); boolean is_equal(in Interval an_interval); boolean is-greater(in Interval an_interval); boolean is_greater_or_equal(in Interval an_interval); Trang 30
- LUAÄN VAÊN TOÁT NGHIEÄP boolean is_less(in Interval an_interval); boolean is_less_or_equal(in Interval an_interval); }; 4.3.3- Time : Time biểu thị cụ thể thời gian thế giới. interface Time : Object { typedef short Time_Zone; const Time_Zone GMT = 0; const Time_Zone GMT1 = 1; const Time_Zone GMT2 = 2; const Time_Zone GMT3 = 3; const Time_Zone GMT4 = 4; const Time_Zone GMT5 = 5; const Time_Zone GMT6 = 6; const Time_Zone GMT7 = 7; const Time_Zone GMT8 = 8; const Time_Zone GMT9 = 9; const Time_Zone GMT10 = 10; const Time_Zone GMT11 = 11; const Time_Zone GMT12 = 12; const Time_Zone GMT_1 = -1; const Time_Zone GMT_2 = -2; const Time_Zone GMT_3 = -3; const Time_Zone GMT_4 = -4; const Time_Zone GMT_5 = -5; const Time_Zone GMT_6 = -6; const Time_Zone GMT_7 = -7; const Time_Zone GMT_8 = -8; const Time_Zone GMT_9 = -9; const Time_Zone GMT_10 = -10; const Time_Zone GMT_11 = -11; const Time_Zone GMT_12 = -12; const Time_Zone USeastern = -5; const Time_Zone UScentral = -6; const Time_Zone USmountain = -7; const Time_Zone USpacific = -8; ushort hour(); ushort minute(); float second(); short tz_hour(); short tz_minute(); boolean is_equal(in Time a_time); boolean is-greater(in Time a_time); boolean is_greater_or_equal(in Time a_time); boolean is_less(in Time a_time); Trang 31
- LUAÄN VAÊN TOÁT NGHIEÄP boolean is_less_or_equal(in Time a_time); boolean is_between(in Time a_time, in Time a_time); Time add_interval(in Interval an_interval); Time subtract_interval(in Interval an_interval); Interval subtract_time(in Time a_time); }; 4.3.4- TimeStamp : TimeStamp gồm Date và Time. interface TimeStamp : Object { typedef unsigned short ushort; Date the_date(); Time the_time(); ushort year(); ushort month(); ushort day(); ushort hour(); ushort minute(); float second(); short tz_hour(); short tz_minute(); TimeStamp plus(in Interval an_interval); TimeStamp minus(in Interval an_interval); boolean is_equal(in TimeStamp a_Stamp); boolean is-greater(in TimeStamp a_Stamp); boolean is_greater_or_equal(in TimeStamp a_Stamp); boolean is_less(in TimeStamp a_Stamp); boolean is_less_or_equal(in TimeStamp a_Stamp); boolean is_between(in TimeStamp a_Stamp, in TimeStamp b_Stamp); }; 4.3.5- Cấu trúc người dùng định nghĩa : (user-defined structures) Bởi vì mô hình đối tượng có thể được mở rộng, người phát triển có thể định nghĩa những kiểu cấu trúc còn lại khi cần thiết. Mô hình đối tượng bao gồm 1 bộ tạo kiểu sẵn có Struct, được dùng để định nghĩa cấu trúc ứng dụng. Ví dụ : attribute struct Address{string dom_name, String roo m_no} dom_address; Thủ tục định nghĩa bởi bộ tạo cho kiểu cấu trúc bao gồm : interface Struct { unsigned long size(); void set_element(in any field, in any value); any get_element(in any field); void clear_element(in any field); Struct copy(); void delete(); }; Trang 32
- LUAÄN VAÊN TOÁT NGHIEÄP Cấu trúc có thể xây dựng 1 cách tự do. Mô hình đối tượng hỗ trợ tập các cấu trúc, cấu trúc của tập, dãy các cấu trúc... Điều này cho phép định nghĩa các kiểu giống như Degrees, như 1 danh sách mà các phần tử cơ bản là các cấu trúc bao gồm 3 trường: struct Degree { String school_name; String degree_type; unsigned short degree_year; }; typedef List Degrees; Mỗi thể hiện Degrees có các phần tử cơ bản của nó được sắp xếp theo giá trị của degree_year. Một công cụ có thể ràng buộc cấu trúc mô hình đối tượng và những collection tạo thành những lớp mà được cung cấp ngôn ngữ lập tr ình. Ví dụ, smalltalk bao gồm các lớp collection, date, time và timestamp. 5- Mô hình trạng thái - tính chất Một kiểu định nghĩa 1 tập các tính chất mà thông qua đó người sử dụng có thể truy cập và trong 1 số trường hợp thao tác trực tiếp, trạng thái của kiểu thể hiện. Hai loại tính chất được định nghĩa trong mô hình đối tượng ODMG là attribute và relationship. Một attribute là thuộc 1 kiểu. Một relationship được xác định giữa 2 kiểu, mà mỗi tính chất phải thể hiện rằng có thể tham khảo bởi bộ nhận dạng đối t ượng. Bởi vì kiểu Literal không có bộ nhận dạng đối t ượng nên không thể tham gia trong relationship. 5.1- Attribute Khai báo attribute trong 1 giao tiếp định nghĩa trạng thái trừu t ượng của 1 kiểu. Ví dụ, kiểu Person có thể chứa đựng khai báo thuộc tính sau : interface Person { attribute short age; attribute string name; attribute enum gender{male,female}; attribute Address home_address; attribute set phones; attribute Department dep; }; Một thể hiện rõ ràng của Person sẽ có 1 giá trị cụ thể cho mỗi thuộc tính được định nghĩa. Giá trị cho mỗi attribute dep ở trên là 1 bộ nhận dạng đối tượng của 1 thể hiện Department. Một giá trị của attribute thì luôn luôn là 1 từ hoặc 1 bộ nhận dạng đối t ượng. Điều đó quan trọng để chú ý rằng 1 attribute thì không giống như 1 cấu trúc dữ liệu. Một attribute thì trừu tượng còn trong khi cấu trúc dữ liệu là 1 sự biểu diễn vật chất. Trong k hi nói chung attribute được thực hiện như 1 cấu trúc dữ liệu, đôi khi nó phù hợp đối với 1 attribute được thực hiện như 1 phương pháp. Ví dụ, attribute age có thể rất tốt để thực hiện như 1 phương pháp để tính toán tuổi theo giá trị gán của ngày sinh và ngày hiện tại của 1 người. Trong mô hình ODMG này, attribute không phải là "lớp thứ nhất". Điều này có nghĩa rằng 1 attribute không phải là 1 đối tượng và do đó không có 1 bộ nhận dạng đối t ượng. Nó không thể định nghĩa thuộc tính của attribute hoặc relatio nship giữa các attribute hoặc các thủ tục kiểu con - cụ thể đối với attribute. Trang 33
- LUAÄN VAÊN TOÁT NGHIEÄP 5.2- Relationship : Relationship được định nghĩa giữa các kiểu. Mô hình đối tượng ODMG chỉ hỗ trợ Relationship nhị phân như Relationship giữa 2 kiểu. Mô hình không hỗ trợ Relat ionship mà có liên quan đến hơn 2 kiểu. Một Relationship nhị phân có thể là 1-1, 1-nhiều, hoặc nhiều - nhiều, phụ thuộc vào có bao nhiêu thể hiện của mỗi kiểu tham gia trong Relationship. ví dụ, marriage là 1 mối quan hệ 1-1 giữa 2 thể hiện của kiểu Person. Một người đàn bà có quan hệ 1 - nhiều, mối quan hệ giữa người mẹ và những đứa con. Thầy giáo và học sinh tham gia trong mối quan hệ nhiều - nhiều. Mối quan hệ trong mô hình đối tượng thì tương tự mối quan hệ trong mô hình dữ liệu thực thể quan hệ. Mối quan hệ của mô hình đối tượng không được đặt tên và không phải là "lớp thứ nhất". Một mối quan hệ thì không phải là 1 đối tượng và không có bộ nhận dạng đối t ượng. Một mối quan hệ được định nghĩa rõ ràng bởi sự khai báo đường thông duyệt mà cho phép các ứng dụng sử dụng sự nối kết hợp lý giữa các đối t ượng tham gia trong mối quan hệ. Đường thông duyệt được khai báo trong từng cặp, 1 cho mỗi hướng duyệt của mối quan hệ nhị phân. Ví dụ, thầy dạy 1 khoá học và 1 khoá học được dạy bởi thầy. Đường thông duyệt teaches được định nghĩa trong khai báo giao tiếp cho kiểu Professor. Đường thông duyệt is_taught_by được định nghĩa trong khai báo giao tiếp cho kiểu Course. Thực tế rằng cả những đường thông duyệt này áp dụng cho cùng mối quan hệ được biểu thị bằng mệnh đề đảo trong cả 2 sự khai báo đường thông duyệt. Ví dụ : interface Professor { ... relationship Set teaches inverse Course::is_taught_by; ... } và interface Course { ... relationship Professor is_taught_by inverse Professor::teaches; ... } Mối quan hệ định nghĩa bởi đ ường thông duyệt teaches và is_taught_by là quan hệ 1 - nhiều giữa Professor và Course. Điểm cốt lõi này được trình bày trong sự khai báo đường thông duyệt. Thể hiện Professor được kết hợp với 1 tập thể hiện Course theo đường thông duyệt teaches. thể hiện Course được kết hợp với 1 thể hiện Professor theo đường thông duyệt is_taught_by. Đường thông duyệt mà gây ra nhiều đối tượng có thể được sắp xếp hoặc không, chẳng hạn biểu thị bởi kiểu của collection cụ thể tro ng khai báo đường thông duyệt. Nếu set được dùng, chẳng hạn Set, những đối t ượng tại cuối đường thông duyệt không được sắp xếp. Nếu List được dùng, như định nghĩa sau, những đối t ượng tại cuối đường thông duyệt được sắp xếp. Mệnh đề order_by chỉ có thể được áp dụng khi List được dùng trong khai báo đường thông duyệt. interface Professor Trang 34
- LUAÄN VAÊN TOÁT NGHIEÄP { ... relationship List teaches inverse Course::is_taught_by {order_by Course::course_no}; ... } ODBMS chịu trách nhiệm duy tr ì sự tham khảo thống nhất của mối quan hệ. Điều này có ý nghĩa rằng nếu 1 đối tượng tham gia trong 1 mối quan hệ bị xoá, thì những đường thông duyệt đến đối tượng đó cũng bị xoá. Ví dụ, nếu thể hiện Course bị xoá thì không chỉ sự tham khảo của đối tượng đến thể hiện Professor theo đường thông dẫn is_taught_by bị xoá mà còn những đường tham khảo trong đối tượng Professor đến thể hiện Course theo đường thông dẫn teaches cũng phải bị xoá. Duy trì sự tham khảo thống nhất chắc rằng ứng dụng không thể tạo tham chiếu lại đường thông duyệt mà dẫn đến đối tượng không tồn tại. attribute Student top_of_class; Một attribute có thể là đối tượng đáng giá. Loại attribute này cho phép 1 đối tượng tham khảo 1 đối tượng khác mà không mong đợi 1 đường thông duyệt đảo hoặc sự tham khảo thống nhất. Điều quan trọng để chú ý rằng 1 đường thông duyệt mối quan hệ không t ương đương với 1 con trỏ. Một con trỏ trong C++ hoặc smalltalk không có cùng ký hiệu của 1 đường thông duyệt đảo tương ứng mà tạo thành 1 mối quan hệ. Các thủ tục định nghĩa các phần quan hệ và các đường thông duyệt của chúng thay đổi theo điểm chốt của đường thông duyệt. Khi đường thông duyệt có điểm chốt "1", các thủ tục được định nghĩa để tạo 1 mối quan hệ, để phá hủy 1 mối quan hệ và để duyệt mối quan hệ. Khi đường thông duyệt có điểm chốt là "nhiều ",Đường thông duyệt hỗ trợ tất cả các hành vi được định nghĩa bên trên lớp Collection được dùng định nghĩa hành vi của quan hệ. Đường thông duyệt bảo đảm sự tham khảo thống nhất trong tất cả trường hợp. 6- Mô hình hành vi - thủ tục Bên cạnh tính chất attribute và relationship, các đặc tính của 1 kiểu là hành vi của nó mà được xác định như 1 tập xác nhận thủ tục. Mỗi sự xác nhận định nghĩa t ên của 1 thủ tục, tên và kiểu của mỗi đối số của nó, kiểu của giá trị trả về và tên của những thủ tục tạo lỗi có thể được đưa ra. Một thủ tục được định nghĩa chỉ trên 1 kiểu duy nhất. Không có khái niệm trong mô hình đối tượng về thủ tục mà có kiểu tồn tại độc lập hoặc của thủ tục định nghĩa trên 2 hoặc nhiều kiểu. Tên thủ tục cần được độc nhất trong 1 định nghĩa kiểu duy nhất. Do đó những kiểu khác nhau có thể có những thủ tục được định nghĩa cùng tên. Tên của những thủ tục nói là bị quá tải. Khi 1 thủ tục được đưa ra thi hành dùng 1 tên bị quá tải, 1 thủ tục cụ thể phải được chọn để thực thi. ODMG có nhiều lý do để chọn theo mô hình truyền 1 chiều hơn là mô hình truyền nhiều chiều. Lý do chính là vì tính vững chắc của ngôn ngữ lập trình C++ và Smalltalk. Tính bền vững này cho phép tích hợp các mặt tích cực của ODBMS vào trong môi trường lập trình đối tượng. Một lý do khác theo mô hình đối tượng cổ điển là ngăn ngừa tính không tương thích với mô hình đối tượng OMG CORBA mà chuẩn mực hơn so với tính phổ biến. Một thủ tục có thể có những mặt ảnh hưởng. Một số thủ tục không có giá trị trả về . Mô hình ODMG không bao gồm đặc tả hình thức về ngữ nghĩa của thủ tục. Tuy nhiên, đó là tập quán tốt để bao gồnm chú thích trong đặc tả giao tiếp, ví dụ nhận xét về mục đích của 1 thủ tục, những mặt ảnh hưởng có thể có của nó, những điều kiện có trước và thường xuyên xảy ra, và những invariants mà có ý định bảo toàn. Trang 35
- LUAÄN VAÊN TOÁT NGHIEÄP Mô hình đối tượng giả sử hỗ trợ thủ tục thực thi tuần tự. Nó không yêu cầu hỗ trợ thủ tục đồng thời hoặc song song, nhưng không ngăn ngừa 1 ODBMS hỗ trợ đa xử lý. 6.1- Mô hình loại trừ Mô hình đối tượng ODMG hỗ trợ điều khiển lỗi lồng vào nhau 1 cách linh động, sử dụng 1 mô hình đầu cuối của điều khiển lỗi những thủ tục có thể đưa ra những lỗi, và những lỗi có thể liên lạc với lỗi đưa ra. Lỗi trong mô hình đối tượng là chính các đối tượng và có 1 giao tiếp mà chúng cho phép được quan hệ với lỗi khác trong 1 phân cấp tổng quát - cụ thể. Một kiểu gốc Exception được cung cấp bởi ODBMS. Kiểu này bao gồm 1 thủ tục để xuất ra 1 thông báo chú ý rằng 1 lỗi không được điều khiển của kiểu Exception_type đã xảy ra để dừng quá trình. Thông tin trong trường hợp này của lỗi hoặc trong ngữ cảnh mà nó xảy ra được chuyển lại cho bộ điều khiển lỗi như tính chất của đối tượng Exception. Kiểm soát theo các bước sau : 2. Người lập trình khai báo 1 bộ điều khiển lỗi trong khả năng phạm vi điều khiển lỗi kiểu t. 3. Thủ tục trong 1 phạm vi chứa đựng Sn có thể "đưa ra" 1 lỗi kiểu t. 4. Lỗi được bắt tức thời bởi hầu hết phạm vi chứa đựng mà có 1 bộ điều khiển lỗi. Chồng gọi lệnh không bị ảnh hưởng bởi hệ thống thời gian chạy mà ngoài mức kiểm soát của bộ điều khiển. Lệnh phá hủy được gọi cho tất cả đối tượng được định vị trong vùng stack quản lý. Những tác vụ này bắt đầu 1 tầm mức lồng nhau mà không bị ảnh hưởng bởi hệ thống thời gian chạy trong quá trình tìm kiếm trên stack cho 1 bộ điều khiển lỗi bị bỏ qua. 5. Khi kiểm soát truyền đến bộ điều khiển, bộ điều khiển có thể quyết định rằng nó có thể điều khiển lỗi hoặc chuyển nó đến 1 bộ điều khiển chứa đựng. Một bộ điều khiển lỗi mà khai báo khả năng của nó về điều khiển lỗi của kiểu t, sẽ cũng điều khiển lỗi những kiểu con của t. Người lập trình mà yêu cầu kiểm soát cụ thể hơn những lỗi của 1 kiểu con cụ thể của t có thể khai báo 1 bộ điều khiển cho kiểu con cụ thể này trong 1 phạm vi kiểm soát. Xác nhận của thủ tục bao gồm sự khai báo của những lỗi mà thủ tục có thể đưa ra. 7- Metadata Metadata mô tả thông tin về đối tượng CSDL. Metadata định nghĩa sơ đồ của CSDL : nó được dùng bởi cấu trúc CSDL của ODBMS và tại thời gian chạy để hướng dẫn truy cập CSDL. Metadata có thể truy cập đến công cụ và ứng dụng sử dụng cùng thủ tục mà áp dụng cho kiểu người dùng định nghĩa. 7.1- Phân cấp đầy đủ kiểu có sẵn Hình 2-1 trình bày đầy đủ tập các kiểu có sẵn của phân cấp kiểu mô hình đối tượng. Kiểu hữu hình được trình bày bằng chữ không in nghiêng và được thể hiện trực tiếp. Kiểu trừu tượng được trình bày in nghiêng. Trong các vấn đề đơn giản hoá được quan tâm, kiểu và bộ tạo kiểu được bao hàm trong cùng 1 phân cấp. Bộ tạo kiểu được biểu thị bởi dấu ngoặc nhọn. 7.2- Luật tương thích kiểu : Mỗi đối tượng hoặc Literal có 1 kiểu và lỗi thủ tục yêu cầu những toán hạng có kiểu. Quy tắc để đồng nhất kiểu và tương thích kiểu được đề cập trong mục này. Hai đối tượng hoặc 2 literal có cùng kiểu nếu và chỉ nếu chúng được khai báo để thể hiện của cùng kiểu danh định. Những đối tượng hoặc literal mà được khai báo để thể hiện của 2 kiểu khác nhau thì không cùng kiểu ngay cả nếu kiểu trong câu hỏi định nghĩa cùng tập tính chất và thủ tục. Tương thích kiểu theo quan hệ kiểu con định nghĩa bởi phân cấp kiểu. Nếu TS là kiểu con của T, thì 1 đối tượng của kiểu TS có thể được gán đến 1 biến của kiểu T, nhưng đảo ngược lại thì Trang 36
- LUAÄN VAÊN TOÁT NGHIEÄP không thể. Không có sự chuyển đổi hoàn toàn giữa những kiểu được cung cấp bởi mô hình đối tượng. Hai Atomic literal có cùng kiểu nếu chúng thuộc cùng tập literal. Phụ thuộc vào sự ràng buộc ngôn ngữ lập trình, 1 sự chuyển đổi có thể được cung cấp giữa những kiểu từ vô hướng. Không có sự chuyển đổi rõ ràng được cung cấp cho literal có cấu trúc. 2.7.3- Giá trị null : Đối với mỗi kiểu literal, có sự tồn tại kiểu literal mà hỗ trợ giá trị null. Kiểu có thể rỗng này thì giống như kiểu literal có giá trị rỗng "nil". 2.7.4- Kiểu Table : Mục đích tạo sự rõ ràng mà mô hình dữ liệu ODMG chứa đựng mô hình dự liệu quan hệ, bộ tạo kiểu Table được định nghĩa trong mô dữ liệu ODMG thì tương tự như bộ tạo kiểu Bag chẳng hạn như Table(a1:t1,a2:t2,…,an:tn) thì tương đương với định nghĩa Bag 8- MÔ HÌNH TÁC VỤ Những chương trình mà sử dụng đối tượng tồn tại lâu dài đã được sắp xếp trong những tác vụ. Quản lý tác vụ là 1 chức năng quan trọng của ODBMS, là nền tảng để tích hợp dữ liệu, chia sẽ và phục hồi dữ liệu. Việc truy cập, tạo, sửa chữa và xoá các đối tượng tồn tại lâu dài phải được thực hiện trong 1 tác vụ. Một tác vụ là 1 bộ phận hợp lý để 1 ODBMS bảo đảm tính nguyên thủy, tính ổn định, sự cô lập và tính lâu dài. Tính nguyên thủy có nghĩa rằng tác vụ kết thúc hoặc không bị ảnh hưởng gì hết. Tính ổn định nghĩa rằng 1 tác vụ chuyển 1 CSDL từ 1 trạng thái nội bộ ổn định đến 1 trạng thái nộ i bộ ổn định khác. Có thể có nhiều lần trong 1 tác vụ khi CSDL không được ổn định. Tuy nhiên, không có người sử dụng CSDL thấy được sự thay đổi bởi 1 tác vụ cho đến khi tác vụ đó được thực hiện. Những người dùng cùng lúc luôn luôn thấy 1 CSDL ổn định bên trong. Sự cô lập có nghĩa rằng sự thực thi của những tác vụ đồng thời phải chuyển giao kết quả mà không thể phân biệt được kết quả mà sẽ đạt được nếu tác vụ được thực hiện 1 cách thứ tự. Tính lâu dài có nghĩaa rằng hiệu quả của những tác vụ đã thực hiện được bảo toàn, ngay cả nếu cò hư hỏng do phương tiên lưu trữ, hư bộ nhớ, hệ thống sụp đổ. Mỗi khi tác vụ được thực hiện, ODBMS bảo đảm rằng sự thay đổi bởi tác vụ thì không bao giờ mất. Khi 1 tác vụ được thực hiện, tất cả những thay đổi bởi tác vụ đó được đặt lâu dài trong CSDL và có thể nhìn thấy những người khác sử dụng CSDL. Khi 1 tác vụ bị ngắt ngang, không có sự thay đổi nào bởi tác vụ được đặt vào trong CSDL, kể cả những thay đổi xảy ra trước lúc bị ngắt. Trong mô hình đối tượng, những đối tượng tồn tại tạm thời thì không phải là chủ đề chính đối với ngữ nghĩa tác vụ. Điều này có thể nghĩ rằng những tác vụ bị ngắt ngang không phục hồi trạng thái bị sửa chữa của những đối tượng tồn tại tạm thời. Mô hình đối tượng giả sử 1 tác vụ tuần tự tuyến tính thực thi trong 1 quá trình duy nhất, được chạy đối ứng với CSDL logic duy nhất. Chú ý rằng CSDL logic duy nhất có thể được thực hiện như 1 hoặc nhiều CSDL vật lý, mà có thể được phân bố trong 1 mạng. Mô hình đối tượng không yêu cầu cũng không ngăn ngừa sự hỗ trợ đối với những tác vụ mà lan rộng đến nhiều quá tr ình hoặc sự lan rộng đó nhiều hơn 1 CSDL logic. 8.1- Kiểm soát khoá và đồng thời : Mô hình đối tượng ODMG sử dụng 1 nền tảng khép kín phù hợp với sự kiểm soát đồng thời khoá có thể hiện thực trên 1 đối tượng cụ thể. Một số công cụ nhượng bộ có thể buộc hoặc cho phép khoá để đưa đến 1 cấp độ nhuyễn hơn. Mô hình đối tượng ODMG hỗ trợ sự kiểm soát đồng thời như cách thức mặc định của nó, nhưng không ngăn DBMS hỗ trợ 1 phuơng thức kiểm soát đồng thời mở rộng hơn. Mô hình mặc định Trang 37
- LUAÄN VAÊN TOÁT NGHIEÄP yêu cầu nắm được chốt chặn đọc trên 1 đối tượng trước khi nó có thể đọc và nắm được chốt chặn ghi trên 1 đối tượng trước khi đối tượng có thể bị sửa. Người đọc trên 1 đối tượng không bị đụng với nguời đọc khác, nhưng người viết đụng cả 2 người đọc và người viết. Nếu có sự đụng độ, DBMS cho phép người giữ chốt chặn được tiếp tục công việc và tác vụ mà được yêu cầu bị chốt chặn xung đột và chỉ đến khi người giữ chốt chặn hoàn tất công việc. Người giữ chốt chặn có thể hoàn tất công việc bằng cách ngắt ngang hoặc cam kết thực hiện tại thời điểm mà tất cả các chốt chặn của nó được giải phóng. 8.2- Thủ tục Transaction ODBMS cung cấp 1 kiểu Transaction với các thủ tục sau : Interface Transaction { void begin(); void commit(); void abort(); vo id checkpoint();}; Thủ tục begin thiết lập 1 Transaction. Những Transaction phải được tạo 1 cách rõ ràng và được thiết lập, chúng không được tạo 1 cách tự động bởi ODBMS khi 1 CSDL được mở hoặc thực hiện tác vụ commit hoặc abort. Thủ tục commit là lý do mà tất cả đối tượng tồn tại lâu dài được tạo hoặc được sửa trong tác vụ này có thể truy cập đến các tác vụ đang chạy khác đối với CSDL trong quá tr ình khác. Thể hiện Transaction bị xoá và giữ tất cả các chốt chặn bởi thể hiện đó được giải phóng. Thủ tục abort là nguyên nhân làm cho đối tượng Transaction bị xoá và CSDL trả về trạng thái mà nó được ưu tiên bắt đầu tác vụ. Tất cả chốt chặn bị giữ bởi tác vụ được giải phóng. Thủ tục checkpoint ghi lại tất cả các đối t ượng bị sửa đổi đến CSDL và giử lại tất cả các chốt chặn bị giữa bởi tác vụ. Nó không xoá đối t ượng Transaction. 9- Thủ tục Database ODBMS có thể quản lý 1 hoặc nhiều CSDL logic mà mỗi chúng có thể lưu trữ 1 hoặc nhiều CSDL vật lý. Mỗi CSDL logic là 1 thể hiện của kiểu Database mà được cung cấp bởi ODBMS. Kiểu Database hỗ trỡ các thủ tục sau : Interface Database { void open(in string database_name); void close(); void bind(in any an_object, in string name); any lookup(in string object_name); }; Thủ tục open phải được đưa raa thực thi với 1 tên CSDl là đối số của nó, trước khi có thể truy cập để tạo ra những đối t ượng tồn tại lâu dài trong CSDL. Mô hình đối tượng chỉ yêu cầu 1 CSDL duy nhất được mở tại 1 thời điểm. Công cụ này có thể mở rộng khả năng của nó, bao gồm những tác vụ mà trải dài đến nhiều CSDL. Thủ tục close phải được đưa ra thực thi khi 1 chương trình đã hoàn tất việc truy cập CSDL. Khi ODBMS đóng 1 CSDL, nó thực hiện thủ tục cleanup. Thủ tục lookup được dùng để t ìm kiếm bộ xác định đối tượng với tên được cung cấp như đối số đối với thủ tục. Thủ tục này được định nghĩa trên kiểu Database, bởi vì phạm vi của tên đối tượng là CSDL. Tên đối tượng trong CSDL, tên các kiểu trong sơ đồ CSDL, và sự mở rộng kiểu được thể hiện trong CSDL là toàn cục đối với CSDL. Chúng không thể truy cập đế n 1 chương Trang 38
- LUAÄN VAÊN TOÁT NGHIEÄP trình khi nó mở CSDL. Đối tượng được đặt tên là chỉ mục phù hợp đối với CSDL. Một tên được gán đến 1 đối tượng sử dụng thủ tục bind. Kiểu Database cũng có thể hỗ trợ những thủ tục được thiết kế để quản trị CSDL như move, copy, reorganize, verify, backup, restore. Những loại thủ tục này không được đề cập ở đây, vì đã xem xét các công cụ bên ngoài phạm vi của mô hình đối tượng. Trang 39
CÓ THỂ BẠN MUỐN DOWNLOAD
-
Giáo trình Tin học B - Trường ĐH Cửu Long
96 p | 965 | 426
-
Ngôn ngữ truy vấn SQL
96 p | 445 | 134
-
Các Cơ Chế Thực Thi Lệnh JOIN Tiếp theo bài Các Loại JOIN Trong SQL Server, bài này
6 p | 351 | 21
-
Bài 2:Truy vấn dữ liệu
27 p | 146 | 19
-
View và Cursor
33 p | 102 | 17
-
MySQL & C
16 p | 112 | 15
-
Google Input Tools - Bàn phím ảo nhập văn bản đa ngữ trong Chrome
3 p | 103 | 9
-
Làm việc với Vấn tin (Query)
45 p | 100 | 9
-
Bài giảng Thực hành cơ sở dữ liệu: Phần 1
70 p | 69 | 9
-
XỬ LÝ CÂU TRUY VẤN BẰNG PHÉP TOÁN ĐẠI SỐ KẾT HỢP VỚI THỜI GIAN
10 p | 112 | 8
-
Tìm Hiểu Về DW 2.0 Chương 7, 8 ,9
0 p | 58 | 6
-
Bài giảng Hệ quản trị cơ sở dữ liệu: Chương 3 - Nguyễn Thị Mỹ Dung
67 p | 33 | 3
-
Bài giảng Thiết kế và quản trị cơ sở dữ liệu - Chương 4: Xử lý truy vấn và hiệu năng hệ CSDL
16 p | 51 | 2
Chịu trách nhiệm nội dung:
Nguyễn Công Hà - Giám đốc Công ty TNHH TÀI LIỆU TRỰC TUYẾN VI NA
LIÊN HỆ
Địa chỉ: P402, 54A Nơ Trang Long, Phường 14, Q.Bình Thạnh, TP.HCM
Hotline: 093 303 0098
Email: support@tailieu.vn