Luận văn Cơ sở dữ liệu đa phương tiện yêu cầu và các vấn đề

cần được quan tâm như ngày, thời gian và địa điểm chụp bức ảnh đó. • λ là một ánh xạ đặc trưng rút gọn cho phép ta biết đặc trưng nào xuất hiện trong những trạng thái nào. λ có thể là một GUI cho phép người sử dụng tương tác nhằm mục đích nhận biết được nội dung của một đối tượng media. • R là một tập các quan hệ trên fei x ATTRj x S các quan hệ này phụ thuộc vào trạng thái. Ví dụ nếu xem xét một bức ảnh như photo1.gif thì ở đây có thể có một quan hệ phụ thuộc vào trạng thái gọi là left.of bao gồm một bộ ba có dạng (đối tượng A, đối tượng B, photo1.gif). tương tự như vậy chúng ta cũng có thể có một quan hệ khác gọi là background bao gồm một cặp có dạng (photo1.gif, White_House). • F có thể chứa các liên kết kết hợp 2 trạng thái chẳng hạn như liên kết có trước, nếu chúng ta có 2 bức ảnh (photo1.gif, photo2.gif) mà giữa chúng tồn tại liên kết có trước thì khi đó có nghĩa là bức ảnh 1 được chụp trước bức ảnh 2 và tiếp tục như vậy[18]. Để nắm rõ hơn, chúng ta xem xét một số ví dụ áp dụng trên một số loại đối tượng media sau 2.4.1 Dữ liệu ảnh như là một tóm tắt media. Giả sử chúng ta xem một CSDL hình ảnh đơn giản gồm có 7 bức ảnh, CSDL này sẽ tương ứng với media trừu tượng sau: 34 • Tập các trạng thái bao gồm (pic1.gif,……….,pic7.gif). • Tập các đặc trưng bao gồm tên của các đối tượng xuất hiện trong các bức ảnh tương ứng là Bob, Jim, Bill, Charlic và Ed. • Ánh xạ thu gọn λ cho chúng ta biết với mỗi trạng thái có những đặc trưng nào xuất hiện trong nó. Bảng sau sẽ mô tả cho vấn đề này Trạng thái Đặc trưng Pic1.gif Bob.Jim Pic2.gif Jim Pic3.gif Bob Pic4.gif Bill Pic5.gif Charlie Pic6.gif Ed, Bill Pic7.gif Ed Bảng 2.1: Liên hệ giữa đặc trưng và trạng thái cho hình ảnh Một điểm cần chú ý ở đây là chúng ta dùng bảng trên để mô tả cho λ nhưng cách thức chỉ số hoá mà chúng ta sử dụng có thể khác đi. • Tập các quan hệ chỉ chứa 2 quan hệ: một quan hệ phụ thuộc vào trạng thái gọi là left_of và một quan hệ không phụ thuộc vào trạng thái gọi là father. • Tập các quan hệ nội tại có thể trống 2.4.2 Dữ liệu video như là một tóm tắt media. • Tập các trạng thái bao gồm 5 frames video từ frame 1 đến frame 5. • Tập các đặc trưng bao gồm Jane Shady, Denis Dopeman, ngôi nhà của Dopeman và chiếc valy. 35 • Ánh xạ rút gọn λ được mô tả ở bảng sau State Feature Frame1 Dopemanhouse,briefcase,JaneShady Frame2 Dopemanhouse,briefcase,JaneShady,DenisDopeman Frame3 Dopemanhouse,briefcase,JaneShady,DenisDopeman Frame4 Dopemanhouse_briefcase,JaneShady,DenisDopeman Frame5 Dopemanhouse,JaneShady Bảng 2.2: Liên hệ giữa đặc trưng và trạng thái cho video Cũng giống như trường hợp áp dụng đối với CSDL hình ảnh, định dạng cụ thể của ánh xạ λ có thể khác đi để tối ưu hoá cho quá trình chỉ số hoá và khai thác. • Chúng ta có thể có một số quan hệ phụ thuộc vào trạng thái sau: o Quan hệ có (have) là một quan hệ phụ thuộc vào trạng thái xác định chiếc valy (đối tượng) xuất hiện cùng với nhân vật nào ở trong trạng thái nào? Quan hệ này có được mô tả như sau: Person Object State JaneShady Briefcase 1 JaneShady briefcase 2 JaneShady briefcase 3 DenisDopeman briefcase 4 Bảng 2.3: Quan hệ Have o Quan hệ vợ chồng (spouse) là một quan hệ phụ thuộc vào trạng thái chỉ ra tên vợ (hoặc chồng) của một đối tượng nào đó. Quan hệ này có thể được mô tả như sau 36 Person Spouse JaneShady PeterShady JaneShady PeterShady DenisDopeman DebraDopewoman Bảng 2.4: Quan hệ vợ- chồng • Ở đây có thể chỉ có một quan hệ nội tại của trạng thái gọi là before (s1,s2) chỉ ra rằng trạng thái s1 có trước trạng thái s2. Cũng tương tự như trên, chúng ta có thể dễ dàng thấy rằng các kiểu media khác nhau chằng hạn như dữ liệu âm thanh hoặc dữ liệu văn bản có thể được mô tả như là một trường hợp của kiểu media tóm tắt tổng quát. Với cấu trúc đơn giản đề cập ở trên, một CSDL Multimedia là một tập bao gồm các media tóm tắt. 2.4.3 Định nghĩa về một CSDL Multimedia đơn giản Một CSDL Multimedia đơn giản là một tập hữu hạn M của các media tóm tắt. Ví dụ, một CSDL Multimedia đơn giản có thể chứa tệp vidoe video1.mpg và một tệp ảnh photo1.gif, trong trường hợp này CSDL có chứa hai trường hợp của media tóm tắt. Tuy nhiên một CSDL Multimedia đơn giản tỏ ra quá đơn giản và kém hiệu quả nếu xét thêm một số khía cạnh. Ví dụ, một media tóm tắt có thể liệt kê “nhà thờ” là một đặc trưng, tuy nhiên khi chúng ta tìm kiếm với đặc trưng là “thánh đường” thì có thể sẽ không tìm thấy nhà thờ đó vì hệ thống không thể hiểu được rằng nhà thờ và thành đường là tương tự nhau. Các hạn chế về mặt từ đồng nghĩa này cũng thường rất hay xẩy ra đối với CSDL văn bản. Một vấn đề nữa mà chúng ta cũng cần phải quan tâm là người dùng thường hay tìm kiếm các đối tượng có chứa một hoặc nhiều các đặc trưng khác nhau và một thực tế là mặc dù sau một số lần chỉnh sửa lại câu hỏi của mình một 37 cách hoàn chỉnh thì các kết quả trả về tương ứng với câu hỏi vẫn chưa chính xác với những gì người dùng thực sự mong muốn, điều này được thể hiện rõ nhất trong trường hợp chúng ta tìm kiến trên web sử dụng các công cụ tìm kiếm như Google hoặc AltaVista. Ngược lại, ở đây cũng tồn tại các trường hợp khi người dùng muốn mở rộng khả năng tìm kiếm (tìm kiếm một cách chính xác hơn bằng cách khai bào câu hỏi rõ ràng hơn) thì có thể sẽ không thu được kết quả nào, trong khi đó nếu đơn giản hoá bớt câu hỏi thì lại tìm được các thông tin mình mong muốn. Cuối cùng, khi người dùng đưa ra câu hỏi có dạng “ hãy tìm tất cả các hình ảnh mà Jane Shady và Denis Dopeman có mặt tại địa điểm A”, nếu kết quả tìm kiếm trả về là trống thì người dùng có thể suy nghĩ là “địa điểm A có thể tương tự như địa điểm B” và sửa lại câu hỏi bằng cách thay thê việc tìm kiếm tại địa điểm A bằng việc tìm kiếm tại địa điểm B, điều này dẫn đến việc chỉnh sửa lại câu hỏi bằng cách thay thế một hằng số cụ thể này bằng một hằng số khác. Các ví dụ trên đưa đến việc thúc đẩy việc tìm ra một cấu trúc khác để xác định CSDL Multimedia hỗ trợ được các vấn dề về ngữ nghĩa cũng như kế thừa được mối quan hệ giữa các đặc trưng. 2.4.4 Định nghĩa về một CSDL Multimedia có cấu trúc Một CSDL Multimedia có cấu trúc là một tập gồm có 5 thuộc tinh ({M1,…..,Mn),≡,≤,inh,subst) trong đó: • là một media tóm tắt. • ≡ là một quan hệ tương đưong trên . • ≤ là một thứ tự bộ phận trên tập của các lớp tương đương trên F. 38 • inh: giả sử cho biết Như vậy inh là một ánh xạ kết hợp với mỗi đặc trưng f một tập các đặc trưng “bên dưới f y theo ≤ thứ tự trên đặc trưng. • Subst là một ánh xạ từ đến Để hiểu rõ hơn, chúng ta xem xét ví dụ sau: Một CSDL Multimedia có chứa 3 loại media trừu tượng là hình ảnh, âm thanh và video được liệt kê dưới đây Media Object Part_frame Feature_s) image Photo1.gif _ Church,durnstein,danube,subrahmanian image Photo2.gif _ Cathedral,melk,subrahmanian image Photo3.gif _ Church,st.paul,rome Video Video1.mpg 1-5 Church,durnstein,stream Video Video1.mpg 6-10 stream Audio Audio1.wav 1-20 St.peters,tiber,rome Bảng 2.5 • Tập các đặc trưng F có chứa: church, durnstein, danube, subrahmanian, cathedral, melk, st. paul. Rome. Stream. Restaurant, st.peters, tiber. • ≡ cho biết : o Church ≡ cathedral. o River ≡ Stream 39 • Quan hệ ≤ cho biết Hình 2.4 Có nghĩa là [tiber] ≤ [river], [danube] ≤ [river]. [st.paul] ≤ [church], [st.peter] ≤ [church]. Cách định nghĩa trên tuy cung cấp đầy đủ hơn các thông tin hữu ích cho việc tìm kiếm và trình bầy cấu trúc đơn giản của một hệ CSDL Multimedia có cấu trúc nhưng nó vẫn chưa cung cấp được một cấu trúc chỉ số hoá mà hệ thống CSDL Multimedia dùng để tổ chức và lưu trữ dữ liệu. Trước khi đưa ra một cấu trúc chỉ số hoá thích hợp, chúng ta sẽ được ra một ngôn ngữ truy vấn đơn giản dùng để truy vấn dữ liệu Multimedia. Ở đây chúng ta trình bầy ngôn ngữ truy vấn trước vì chúng ta chỉ có được một cấu trúc chỉ số hoá có hiệu quả khi mà chúng ta đã tối ưu được các kiểu truy vấn mà người sử dụng mong muốn . 2.4 Ngôn ngữ truy vấn khai thác dư liệu multimedia Trong phần này, chúng ta sẽ trình bầy một ngôn ngữ truy vấn đơn giản được xây dựng dựa trên SQL dùng để khai thác dữ liệu Multimedia. Chúng ta đã chỉ ra được rằng một media tóm tắt có thể được dùng để mô tả các loại dữ liệu media khác nhau sử dụng kiến trúc mô tả đồng nhất. Việc mở rộng ngôn ngữ truy vấn SQL sử dụng cho việc truy vấn dữ liệu được xây dựng bởi kiến trúc mô tả đồng nhất sẽ là tiền đề để chúng ta tiếp tục mở rộng ngôn ngữ truy vấn dùng cho việc khai thác các dữ liệu media được xây dụng theo kiến trúc lai ghép 40 2.4.1 Truy vấn SMDSs (mô tả đồng nhất) Các hàm cơ bản của SMDSs bao gồm: • FindType(Obj): hàm này sử dụng đối tượng media Obj làm đầu vào và sẽ trả về kiểu của đối tượng, ví dụ: o FindType(image1.gif) = gif. o FindType(movie1.mpg) = mpg. • FindObjWithFeature(f): hàm này sử dụng đặc trưng f là giá trị đầu vào và trả về một tập tất cả các loại đối tượng media mà có chứa đặc trưng f, ví dụ o . o • FindObjWithFeatureAttr(f,a,v): hàm này sử dụng đặc trưng f, một thuộc tính tên a kết hợp với đặc trưng này và một giá trị v là đầu vào. Giá trị trả về sẽ là tất cả các đối tượng o có chứa đặc trưng và giá trị của thuộc tính a trong đối tượng o là v. Ví dụ: o : câu hỏi này đòi hỏi tìm tất cả các đối tượng media mà có sự xuất hiện của Jane Shady trong chiếc áo mầu blue. o câu hỏi này đòi hỏi tìm tất cả các đối tượng media mà một con voi có mang một cái nơ mầu đỏ xuất hiện. • FindFeaturesInObj(Obj): câu hỏi này đòi hỏi phải tìm tất cả các đặc trưng có mặt trong một đối tượng media đã cho. Kết quả trả về là một tập bao gồm tất cả các đặc trưng. Ví dụ: o câu hỏi này yêu cầu trả về tất cả các đặc trưng có trong file ảnh im1.gif. 41 o câu hỏi này yêu cầu trả về tất cả các đặc trưng có trong 5 frame đầu tiên của file video video1.mpg. • FindFeatureandAttrinObj(Obj): hàm này cũng có chức năng tương tự như hàm trước ngoại trừ việc nó trả về một quan hệ có schema như sau: (Feature, Attribute,Value) trong đó cặp 3 (f,a,v) xuất hiện trong quan hệ đầu ra nếu thuộc tính a của đặc trưng f được xác định và có giá trị là v. Ví dụ: o có thể trả về kết quả được mô tả ở bảng sau Feature Attribute Value John age 32 John address 32 PicoLane.Mclean.VA 22050. Mary age 46 Mary address 16 ShawRoad.Dumfries.VA 2290s. Mary employer XYZCorp. Mary boss David Bảng 2.6 SMDS-SQL mở rộng của chúng ta sẽ bao gồm tất cả các câu lệnh chuẩn của SQL có bổ sung thêm một số đặc trưng của dữ liệu Multimedia vào SQL (bổ sung thêm vào Select, From, Where) • Tuyên bố Select có thể chứa thực thể media. Một thực thể media được định nghĩa như sau: o Nếu m là một đối tượng media liên tục, i và j là 2 số nguyên khi đó m : [i,j] là một thực thể media thể hiện một tập tất cả các frame của đối tượng media m nằm trong (và chỉ trong) khoảng i và j. o Nếu m không phải là một đối tượng media liên tục thì khi đó m là một thực thể media. 42 o Nếu m là một thực thể media và a là một thuộc tính của m thì khi dó m.a là một thực thể media. • Tuyên bố From có thể có các thực thể theo mẫu sau: (media) (source) (M), có nghĩa là chỉ có các đối tượng media kết hợp với tên của kiểu media và tên của dữ liệu nguồn được xem xét dến khi thực hiện câu hỏi và M là một biến được xếp loại trên các đối tượng media đó. • Tuyên bố Where cho phép có các biểu thức có dạng term In func.call. Trong đó: o Term có thể là một biến (trong trường hợp này được sắp xếp trên kiểu trả về của func.call) hoặc là một đối tượng có kiểu đầu ra giống như func.call. o Func.call kà một trong 5 hàm đã nêu ra ở trên. Chúng ta cũng xem xét một vài ví dụ • Tìm tất cả các đối tượng ảnh hoặc video có chứa cả Jane Shady và Denis Dopeman. SELECT M Select M FROM smds source M WHERE (FindType(M)= Video OR FindType(M)=Image AND M IN FindObjWithFeatureand(Jane Shady) And M IN FindObjWithFeatureand(Denis Dopeman) • Tìm tất cả các ảnh và video mà đối tượng Jane Shady mặc áo vét mầu tím SELECT M FROM smds source M WHERE FindType(M)=Video OR FindType(M)=Image AND M IN FindObjWithFeatureandAttr(Jane Shady,suit,purple) • Tìm tất cả các ảnh có chứa cả Jane Shady và Denis Dopeman và Jane đứng bên trái Denis 43 SELECT M FROM smds source M WHERE FindType(M)=Image AND M IN FindObjWithFeature(Denis Dopeman) AND M IN FindObjWithFeature(Jane Shady) AND Left (jane Shady,Denis Dopeman.M) Ở đây có một chú ý là quan hệ left được sử dụng ở trên là một quan hệ media tóm tắt của CSDL hình ảnh • Tìm tất cả các ảnh có Jane Shady cùng với đối tượng xuất hiện trong đoạn Video cùng với Denis Hopeman. Khác với câu hỏi trước, câu hỏi này đòi hỏi phải có các thao tác kết hợp giữa các loại dữ liệu khác nhau. Để thực hiện được câu hỏi này, chúng ta phải sử dụng các biến mở rộng như là Person, biến này được dùng để tham chiếu đến đối tượng chưa xác định được danh tính trong đoạn băng video. 2.4.2 Truy vấn dữ liệu multimedia mô tả dưới kiến trúc lai tạo. Trong phần trước, chúng ta đã trình bày ngôn ngữ SMDS-SQL như là một mô hình để truy vấn các dối tượng Multimedia lưu trữ trong kiến trúc thổng nhất. Trong kiến trúc 44 đồng nhất, tất cả các dữ liệu nguồn được truy vấn đều là SMDSs, trong khi trong kiến trúc lai tạo các cách thức mô tả khác (non-SMDS) cũng được sử dụng. Cách thức mô tả dữ liệu kiểu lai tạo thường có hai phần chính: • Một tập các đối tượng media được mô tả dưới dạng đồng nhất. • Một tập các kiểu media khác nhau mà có cấu trúc để truy nhập và truy vấn riêng. Để mở rộng ngôn ngữ truy vấn SMDS-SQL thành ngôn ngữ có thể truy vấn được các dữ liệu được mô tả dưới dạng lai tạo (HM-SQL) các yêu cầu sau bắt buộc phải có: • HM-SQL phải có khả năng thực hiện tất cả các câu hỏi sử dụng ngôn ngữ riêng đối với nguồn dữ liệu không đồng nhất này. • HM-SQL phải có cơ chế “joins” hoặc các thao tác đại số nhị phân có trách nhiệm “joins” giữa 2 nguồn dữ liệu SMDS và non-SMDS. Ngôn ngữ HM-SQL cũng tương tự như ngôn ngữ SQL chuẩn ngoại trừ các mệnh đề Select, From. Where được mở rộng như sau: • Mệnh đề SELECT và WHERE được mở rộng giống như với ngôn ngữ SMDS- SQL. • Tuyên bố Where cho phép sự có mặt của biểu thức có dạng Term IN MS : func_call trong đó: o Term:có thể là một biến hoặc là một đối tượng có kiểu đầu ra giống hệt với của func_call đã được định nghĩa trong media gốc và . o Nếu MS=SMDS hoặc họ func_call thuộc 1 trong 5 hàm đã đinh nghĩa ở trên hoặc o MS không phải là một nguồn SDMS và func_call là một câu hỏi trong QL(MS). • Khi đó có 2 sự khác nhau giữa SMDS-SQL và HM-SQL là: o func_call xuất hiện trong mệnh đề where cần được chú thích một cách tường minh với media gốc kèm theo và 45 o Các câu hỏi được xây dựng từ các ngôn ngữ hỏi đáp của từng loại dữ liệu non-SMDS có thể được nhúng vào bên trong câu lệnh truy vấn của HM- SQL. Điều này làm cho HM_SQL trở nên hết sức mạnh mẽ và linh hoạt. Căn cứ vào điều này chúng ta có thể thực thi các câu hỏi đối với các nguồn dữ liệu khác nhau. Xét một số ví dụ sau: • Giả sử chúng ta có 2 nguồn dữ liệu video video1 và video2, nguồn video1 được triển khai qua hình thức SDMS, nguồn video2 được triển khai qua hình thức non-SDMS (gọi là videob). Câu hỏi của chúng ta ở đây là “hãy tìm tất cả các video clip có mặt Denis Hopeman từ cả 2 nguồn dữ liệu video1 và video2. Câu hỏi này có thể được diễn đạt bằng ngôn ngữ HM-SQL như sau: Trong câu hỏi này, chúng ta tìm kiếm tất cả các Ms mà chúng trả về kết quả mong muốn từ cả 2 nguồn dữ liệu (SDMS và non-SDMS). • Cũng với câu hỏi trên nhưng ở đây chúng ta thêm vào một nguồn dữ liệu mới là dữ liệu hình ảnh (idb) được triền khai dưới hình thức non-SDMS và giả sử dữ liệu hình ảnh này có riêng chức năng tìm kiếm getpic(obj) với tham số đầu vào là obj và kết quả trả về là một cặp bao gồm một ảnh (file ảnh) và thứ tự có liên quan. Giả sử chúng ta muốn tìm kiếm trên cả 3 loại dữ liệu này (video1, video2, idb) có mặt của đối tượng Denis Hopeman thì câu hỏi diễn đạt bằng ngôn ngữ HM-SQL có thể như sau: Select M From sdms Video1, vi•eob Video2 46 Where M IN sdms: FindObjWithFeature(Denis Hopeman) OR M IN videodb: FindVideoWithObj(Denis Dopeman) UNION (Select M.file From imagedb idb M Where M In imagedb:getpic(Denis Dopeman) • Giả sử chúng ta muốn tìm tất cả các đối tượng có mặt cùng với Denis Dopeman trong tất cả các nguồn dữ liệu (video1, video2, idb), câu hỏi sẽ như sau 2.4.3 Chỉ số hoá SMDS với chỉ số đảo. Trong các phần trước, chúng ta đã trình bầy các cách thức để truy vấn CSDL multimedia dưới cả 2 hình thức mô tả là đồng nhất và lai tạo. Các nguồn dữ liệu non- SMDS được chỉ số hoá bởi các cơ chế riêng của chúng, ở đây chúng ta đi sâu vào tìm hiểu cách thức chỉ số hoá đối với các nguồn dữ liệu SDMS. Giả sử chúng ta có trước một SMDS có dạng: 47 trong đó Chúng ta phải chỉ ra được một cách thức chỉ số hoá có hiệu quả dữ liệu này, ý tưởng cơ bản ở đây là: • Featuretable: đây là một bảng băm có chứa tất cả các đặc trưng có trong . Mỗi bảng băm ở vị trí I có chứa một đại diện featurenodes được băm đến vị trí i. • Statetable: là một bảng băm chưa tất cả các trạng thái thuộc . Cũng giống như featuretable, statetable cũng chứa một đại diện của statenotes được băm đến vị trí xác định. • Featurenodes: mỗi featurenodes bao gồm các thành phần sau: o Tên của đặc trưng (ví dụ “Denis Dopeman”). o Một danh sách các nút con (nếu f1 và f2 là các đặc trưng trong chúng ta nói rằng f2 là con của f1 nếu f2≤f1 và không có một đặc trưng f3 khác ( ) mà f2<f3<f1. o Một danh sách con trỏ trỏ tới statenodes có chứa các đặc trưng liên quan (ví dụ trong trường hợp CSDL hình ảnh nó có thể là một con trỏ trỏ đến node kết hợp với hình ảnh có chứa đặc trưng được nêu ra trong câu hỏi (VD “Denis Hopeman”). o Một tập các con trỏ trỏ đến featurenodes khác thích hợp để thay thế cho featurenodes trong câu hỏi. • Statenodes: Một statenodes chỉ chứa 2 thành phần bao gồm: o Một con trỏ trỏ đến file có chứa đối tượng media (hình ảnh, video, audio ) mà trạng thái được quy đến trong câu hỏi. 48 o Một danh sách các mối quan hệ mà thành viên của nó trỏ đến featurenodes, bằng trực giác chúng ta có thể thấy được là có một con trỏ trỏ đến featurenodes f nếu đặc trưng có trong câu hỏi ở trạng thái đó. Cấu trúc dữ liệu của SMDS được mô tả như sau: Type featurenode = record of name: String ;/* Tên của đặc trưng */ children: ^ node1; /* trỏ đến danh sách các on trỏ trỏ đến nodes con */ statelist: ^ node2 ;/* trỏ đến danh sách các on trỏ trỏ đến các trạng thái có chứa đặc trưng này */ replacelít: ^ node3; /* trỏ đến một danh sách bao gồm các con cháu kết hợp với các trạng thái có thể cho là có đặc trưng kết hợp với node đó */ end record; type node1 = record of element: ^ featurenode; /* trỏ đến node con của một featurenode */ next: ^ node1; /* trỏ đến nodé con tiếp theo */ end record; type node2 = record of state: ^ statenode; /* trỏ đến danh sách kết hợp với trạng thái */ link: ^ node2; /* node tiếp theo */ end record; type node3 = record of feat: ^ featurenode; /* trỏ đến một node mà có thể cho là có đặc trưng kết hợp với node hiện thời */ link1: ^ node3; end record; 49 type statenode = record of rep: framerep; flist: ^ node4; end record; type node4 = record of f: ^ featurenode; link2: ^ node4; end record; Hình 2.5: Ví dụ về statetable 50 Chúng ta hãy xem xét một ví dụ của SDMS bao gồm 3 media trừu tượng bào gồm : dữ liệu ảnh, video và âm thanh (audio) có nội dung như sau Media trừu tượng Trạng thái Các đặc trưng Img Im1 Im2 Im3 john, mary john, mary, lizt lizt, mary Video Vid1: [1,10] Vid1: [11,20] Vid1: [21,40] Vid2: [1,20] Vid2: [21,30] john, singing john, mary, dancing john, mary, lizt, singing, dancing ed, speaking man, speaking Audio Disk1: [1,20] Disk1: [21,40] John, singing woman, speaking Bảng 2.7 • Hình 2.5 cho chúng ta thấy một ví dụ về statetable (để đơn giản chúng ta không đề cập đến các hàm băm được sử dụng) ví dụ về một featuretable. Một trong 10 trạng thái liệt kê ở trên được lưu trữ trong statetable cùng với 9 đặc trưng. Trong trường hợp này phải chú ý là “singing” và “dancing” được xem như là các đặc trưng. • Thứ tự ≤ trên các đặc trưng được thể hiện ở hình dưới Hình 2.6 • Chúng ta đã chỉ ra được sự kết hợp của featurelist với các trạng thái im1 và disk1: [1,20], các featurelist khác không được thể hiện ra ở đây nhằm mục đích đơn giản hoá. 51 • Tương tự như vậy chúng ta chỉ ra statelist kết hợp với các đặc trưng man và lizt. • Mối liên hệ kết hợp giữa các media trừu tượng này có thể lưu trữ trong một CSDL quan hệ chuẩn. 52 CHƯƠNG 3 HỆ QUẢN TRỊ CƠ SỞ DỮ LIỆU ĐA PHƯONG TIỆN – YÊU CẦU VÀ CÁC VẤN ĐỀ Trung tâm của một hệ thống thông tin multimedia chính là hệ quản trị CSDL MULTIMEDIA (MDBMS). Theo truyền thống, một CSDL bao gồm một bộ các dữ có liên quan về một thực thể cho trước hoặc một hệ quản trị CSDL (DBMS) là một bộ các dữ liệu có liên quan đến nhau với một tập hợp các chương trình được dùng để khai báo, tạo lập, lưu trữ, truy cập và truy vấn CSDL. Tương tự như vậy, chúng ta có thể xem một CSDL MULTIMEDIA là một tập các loại dữ liệu multimedia như văn bản, hình ảnh, video, âm thanh, các đối tượng đồ hoạ….Một hệ quản trị CSDL MULTIMEDIA (MDBMS) cung cấp hỗ trợ cho các loại dữ liệu MULTIMEDIA trong việc tạo lập, lưu trữ, truy cập, truy vấn và kiểm soát. Sự khác nhau của các kiểu dữ liệu trong CSDL MULTIMEDIA có thể đòi hỏi các phương thức đặc biệt để tối ưu hoá việc lưu trữ, truy cập, chỉ số hoá và khai thác. MDBMS cần phải cung cấp các yêu cầu đặc biệt này bằng cách cung cấp các cơ chế tóm tắt bậc cao để quản lý các kiểu dữ liệu khác nhau cũng như các giao diện thích hợp để thể hiện chúng. 3.1 Mục đích của MDBMS Một MDBMS cung cấp một môi trường thích hợp để sử dụng và quản lý các thông tin CSDL MULTIMEDIA. Vì vậy, nó phải hỗ trợ các kiểu dữ liệu MULTIMEDIA khác nhau bên cạnh việc phải cung cấp đầy đủ các chức năng của một DBMS truyền thống như khai báo và tạo lập CSDL, khai thác dữ liệu, truy cập và tổ chức dữ liệu, độc lập dữ liệu, tính riêng, toàn vẹn dữ liệu, kiểm soát phiên bản. Các chức năng của MDBMS cơ bản tương tự như các chức năng của DBMS, tuy nhiên, bản chất của thông tin 53 MULTIMEDIA tạo ra các đòi hỏi mới. Bằng cách sử dụng các chức năng tổng quát của DBMS chúng ta có thể trình bầy mục đích của MDBMS như sau[1]: • Sự thống nhất: bảo đảm rằng một dữ liệu không phải tạo lại khi các chương trình khác nhau đòi hỏi dữ liệu đó. • Độc lập dữ liệu: Đảm bảo sự tách rời giữa CSDL và các chức năng quản trị từ các chương trình ứng dụng. • Điều khiển nhất quán: đảm bảo sự toàn vẹn của CSDL MULTIMEDIA thông qua các quy tắc dược áp dụng trên các giao dịch đồng thời. • Sự tồn tại: bảo đảm các đối tượng dữ liệu tồn tại qua các giao dịch khác nhau cũng như các yêu cầu của chương trình. • Tính riêng: ngăn chặn các truy cập và sửa chữa các dữ liệu được lưu trữ một cách trái phép. • Kiểm soát sự toàn vẹn; bảo đảm sự toàn vẹn của CSDL một giao dịch này sang một giao dịch khác thông qua việc áp đặt các ràng buộc. • Khả năng phục hồi: phải có các phương thức cần thiết để đảm bảo rằng kết quả của các giao dịch thất bại không làm ảnh hưởng đến dữ liệu lưu trữ. • Hỗ trợ truy vấn: bảo đảm các cơ chế truy vấn phù hợp với dữ liệu MULTIMEDIA. • Kiểm soát phiên bản: tổ chức và quản lý các phiên bản khác nhau của các đối tượng lưu trữ có thể được yêu cầu bởi các ứng dụng. 54 Hình3.1: Kiến trúc bậc cao cho một MDBMS đáp ứng các yêu cầu cho dữ liệu MULTIMEDIA Đối với việc điều khiển nhất quán, một giao dịch là một chuỗi các hướng dẫn được thực thi một cách hoàn toàn hoặc không hoàn toàn, đối với trường hợp không hoàn toàn CSDL sẽ được khôi phục lại trạng thái trước đó, việc đưa ra được một cơ chế tương ứng đảm bảo cho việc nhất quán là một vấn đề khó khăn đối với CSDL MULTIMEDIA. Các CSDL quan hệ truyền thống sử dụng một bản ghi hoặc một bảng duy nhất như là một đơn vị nhất quán. CSDL MULTIMEDIA thường sử dụng một đối tượng đơn lẻ (hoặc đối tượng ghép) như là một đơn vị logic của truy cập. Như vậy một đối tượng MULTIMEDIA đơn lẻ có thể tạo thành đơn vị nhất quán[14]. Đối với vấn đề lưu trữ, một phương thức đơn giản là lưu trữ các tệp MULTIMEDIA trong các tệp tương ứng của hệ điều hành. Tuy nhiên với đặc thù là dung lượng lớn, các dữ liệu MULTIMEDIA là cho chi phí triển khai theo cách thức này trở nên tốn kém. Hơn nữa, hệ thống cũng cần phải lưu trữ các metadata MULTIMEDIA và có thể cả các đối tượng MULTIMEDIA tổng hợp. Vì vậy, hầu hết các MDBMS phân loại thành 2 phần là cố đ