Kiểu dữ liệu nhị phân trong PostgreSQL

2.4. Dữ liệu đa phƣơng tiện trong PostgreSQL

2.4.1. Kiểu dữ liệu nhị phân trong PostgreSQL

Hiện nay có hai cách khác nhau để lƣu trữ dữ liệu nhị phân trong PostgreSQL - Kiểu dữ liệ” bytea”: thích hợp cho khối nhị phân kích thƣớc nhỏ.

- Kiểu dữ liệu” đối tƣợng lớn”: Lƣu trữ dữ liệu nhị phân nhƣ một tệp riêng biệt trong một bảng riêng, có khuôn dạng đƣợc định nghĩa sẵn sẽ trình bày dƣới đây.

Phiên bản 7.2 là lần đầu tiên có JDBC driver hỗ trợ kiểu” bytea” .

Trong những phiên bản Postgresql trƣớc 7.1, kích thƣớc của bất kỳ một dòng nào trong cơ sở dữ liệu không thể vƣợt hơn kích thƣớc của một trang dữ liệu (data page). Vì kích thƣớc của một trang dữ liệu là 8192 bytes (theo mặc định, có thể đƣợc nâng lên tới 32768 byte), giới hạn trên về kích thƣớc của một giá trị dữ liệu sẽ hạn chế

một cách đáng kể. Để hỗ trợ lƣu trữ các kiểu đối tƣợng nhị phân lớn, Postgresql đã cung cấp một giao diện cho phép truy nhập tới dữ liệu ngƣời dùng nhƣ một tệp, bằng cách khai báo kiểu đối tƣợng lớn.

Phiên bản Postgre 4.2, tiền thân của Postgresql, hỗ trợ ba phƣơng thức chuẩn xử lí những đối tƣợng lớn: coi nhƣ những tệp ngoài máy phục vụ PostgreSQL, coi nhƣ tệp ngoài nhƣng quản lý bởi máy phục vụ Postgre, và coi nhƣ tệp dữ liệu đƣợc cất giữ bên trong CSDL Postgre. Điều này gây ra sự lẫn lộn đáng kể đối với những ngƣời dùng. Vì thế, Postgresql chỉ giữ lại sự hỗ trợ cho những đối tƣợng lớn nhƣ dữ liệu cất giữ bên trong cơ sở dữ liệu Postgresql. Mặc dù truy nhập chậm hơn, phƣơng thức này đảm bảo sự toàn vẹn dữ liệu chính xác hơn. Vì những lý do lịch sử, sơ đồ lƣu trữ này đƣợc gọi là inversion large object. Ta sẽ thấy thuật ngữ inversion large object thỉnh thoảng cũng có nghĩa cùng nhƣ large object. Kể từ Postgresql 7.1, tất cả các đối tƣợng lớn đƣợc đặt trong một bảng hệ thống gọi là pg_largeobject.

Postgresql 7.1 đƣa vào một cơ chế (gọi vui là” toast - Bánh mì nƣớng” ), cho phép một dòng dữ liệu lớn hơn nhiều so với trang dữ liệu riêng lẻ. Điều này làm cho giao diện đối tƣợng lớn một phần bị lỗi thời. Tuy nhiên, còn lại một lợi thế của giao diện đối tƣợng lớn là nó cho phép cho sự truy nhập ngẫu nhiên tới dữ liệu, tức là khả năng đọc hoặc viết một chunk dữ liệu của một giá trị lớn. Trong tƣơng lai, đã có kế hoạch để trang bị cho tính năng này cho” toast”.

2.4.2. Kiểu mã định danh đối tượng

Các mã định danh đối tƣợng (OID – object identifier) đƣợc sử dụng nội tại trong PostgreSQL nhƣ khoá chính trong các bảng khác nhau của hệ thống. Hơn nữa, các bảng do ngƣời sử dụng tạo ra cũng đƣợc hệ thống cộng thêm một cột OID (nếu không chỉ định WITHOUT OID khi tạo bảng). Kiểu OID để biểu diễn một mã định danh cho đối tƣợng. Cũng có một vài kiểu thay thế khác cho OID, ví dụ regproc, regprocedure, regoper, regoperator, regclass, và regtype.

Kiểu OID đƣợc xem nhƣ là một kiểu số nguyên 4 byte không dấu (unsigned integer). Vì vậy, nó không đủ lớn để đảm bảo tính duy nhất trên diện rộng toàn bộ CSDL trong những CSDL lớn, hoặc thậm chí ngay cả trong một bảng riêng lẻ, nếu rất lớn. Vì vậy, việc sử dụng cột OID thuộc bảng do ngƣời sử dụng định nghĩa nhƣ khoá chính là không thích hợp. OID chỉ sử dụng tốt nhất cho việc tham chiếu tới những bảng hệ thống.

Ngoài các phép so sánh (nhƣ so sánh số nguyên không dấu), kiểu OID không có các phép toán khác. Tuy nhiên, có thể ép kiểu, coi OID là số nguyên không dấu và dùng các phép toán chuẩn đối với số nguyên không dấu. Tuy nhiên, hãy thận trọng nếu thực hiện các phép toán trên, tránh nhầm lẫn.

Các kiểu OID khác không có phép toán nào khác ngoại trừ những thƣờng trình (routine) xuất/nhập chuyên dụng. Những thƣờng trình này có thể nhận và hiển thị các tên tƣợng trƣng của các đối tƣợng hệ thống, thay cho những giá trị số nguyên mà kiểu OID sử dụng. Các kiểu OID thay thế cho phép đơn giản hoá việc tìm kiếm các giá trị OID của các đối tƣợng, ví dụ có thể viết „mytable‟::regclass để nhận giá trị OID của bảng „mytable‟, không cần thực hiện câu lệnh SQL, SELECT oid FROM pg_class WHERE relname = ‟mytable‟. (Trong thực tế, nhiều lệnh SELECT phức tạp hơn cần đƣợc thực hiện để chọn giá trị OID chính xác khi có nhiều bảng có tên mytable trong lƣợc đồ khác nhau)

Bảng: Các kiểu mã định danh đối tượng

Type name References Description Value example Oid Any numeric object identifier 564182

Regproc Pg_proc function name Sum regprocedure Pg_proc function with argument

types

sum(int4)

Regoper Pg_operator operator name + regoperator Pg_operator operator with argument

types

*(integer,integer) or - (NONE,integer)

Regclass Pg_class relation name pg_type Regtype Pg_type type name Integer

Tất cả các kiểu OID thay thế đều chấp nhận các tên đầy đủ (schema-qualified) và sẽ hiển thị tên schema-qualified này khi không tìm thấy các đối tƣợng trong đƣờng dẫn tìm kiếm hiện thời. Các kiểu OID thay thế nhƣ regproc và regoper sẽ chỉ chấp nhận tên nhập duy nhất, không over-loaded, vì vậy sử dụng chúng bi hạn chế; Đối với nhiểu ứng dụng kiêu regprocedure hoặc regoperator sẽ thích hợp hơn. Đối với kiểu regoperator đơn nguyên (một toán hạng), cần viết NONE vào chỗ của toán hạng không sử dụng.

OID là một số 32-bit và đƣợc gán từ bộ đếm trên phạm vi cluster. Trong CSDL lớn hoặc đã tồn tại một thời gian dài, có thể chấp nhận đếm quay vòng tròn. Vì thế, không nên giả định các OID là duy nhất, trừ phi chúng ta thực hiện các bƣớc để đảm bảo rằng chúng là duy nhất. Nếu sử dụng các OID để định danh các dòng, cần chỉ định ràng buộc duy nhất UNIQUE khi tạo cột của bảng. Không bao giờ nên cho rằng các OID là duy nhất trong phạm vi bao trùm nhiều bảng. Phải sử dụng sự kết nối của tableoid và OID dòng nếu chúng ta cần mã định danh duy nhất trên diện rộng toàn bộ CSDL. (Trong tƣơng lai, PostgreSQL có khả năng sử dụng bộ đếm riêng biệt cho mỗi

bảng. Do đó, để có một mã định danh toàn cục duy nhất, bắt buộc phải dùng tableoid kèm với OID).

Một kiểu mã định danh khác đƣợc sử dụng bởi hệ thống là xid, hay kiểu mã định danh giao tác (transaction, viết tắt xact). Đây là kiểu dữ liệu của các cột hệ thống xmin và xmax. Các mã định danh giao tác là những con số 32-bit. Trong một CSDL tồn tại lâu dài, thì nó có thể chấp nhận đếm quay vòng tròn đối với các ID giao tác. Đây sẽ không phải là một vấn đề lớn nếu có các qui trình duy trì thích hợp. Tuy nhiên, sẽ là không thông minh khi lệ thuộc vào sự duy nhất của các ID giao tác trong một thời hạn dài.

Kiểu mã định danh thứ ba đƣợc sử dụng bởi hệ thống là cid, hay kiểu mã định danh lệnh. Đây là kiểu dữ liệu của các cột hệ thống cmin và cmax. Các mã định danh lệnh cũng là các số 32-bit. Điêu này tạo ra một giới hạn cứng là 232 (4 tỷ) câu lệnh SQL trong phạm vi một phiên giao dịch. Trong thực tế giới hạn này không có vấn đề gì. (chú ý: giới hạn này là tổng số các lệnh SQL, không phải tổng các bộ đƣợc xử lý).

Kiểu mã định danh cuối cùng đƣợc sử dụng trong hệ thống là tid hay kiểu mã định danh các bộ. Đây là kiểu dữ liệu của cột hệ thống ctid. Một ID bộ là một cặp (số khối, chỉ số bộ trong phạm vi khối) xác định vị trí vật lý của bộ trong phạm vi bảng của nó.

2.4.3. PostgreSQL quản lí dữ liệu” đối tượng lớn” như thế nào

Hệ quản trị CSDL PostgreSQL quản trị các dữ liệu đa phƣơng tiện nhƣ hình ảnh, video, hoạt hình, âm thanh, v.v… nhƣ là các khối bit, không có cấu trúc - BLOB (Binary Large Objects). Các BLOB đƣợc lƣu trữ trong một bảng riêng, chung cho toàn bộ CSDL. Bảng này là nội tại, đƣợc làm sẵn, không phải do ngƣời dùng định nghĩa. Bảng chỉ có 2 cột. Cột thứ nhất tên là oid, kiểu Oid, tức mã định danh đối tƣợng, là một số nguyên, sinh tự động, đảm bảo duy nhất, không trùng nhau trong CSDL. Cột thứ hai tên là description, kiểu xâu kí tự, mô tả tóm tắt đối tƣợng.

Truy cập BLOB trong PostgreSQL thông qua cơ chế xuất nhập khẩu (import/export). Khi nhập khẩu một BLOB vào CSDL, ngƣời sử dụng sẽ nhận đƣợc một mã định danh đối tƣợng oid. Mã này dùng để truy cập đối tƣợng thông qua lệnh xuất khẩu.

2.4.4. Thiết kế bảng chứa dữ liệu đa phương tiện

Các dữ liệu đa phƣơng tiện đƣợc lƣu trữ trong CSDL dƣới dạng các khối bít hay BLOB. Cơ chế quản lí các BLOB nhƣ trình bày trên chỉ cung cấp giao tiếp tối thiểu cho ngƣời sử dụng. Để quản lí các dữ liệu đa phƣơng tiện trong CSDL cần có thêm một số mục dữ liệu khác nữa, do đó phải có một bảng do ngƣời sử dụng thiết kế phù hợp với yêu cầu ứng dụng.

Dữ liệu đa phƣơng tiện thƣờng gắn với một thực thể. Quan hệ giữa bảng của các thực thể (bảng tham chiếu) với bảng chứa dữ liệu mutltimedia gắn với thực thể (bảng đƣợc tham chiếu) thể hiện qua cặp khoá chính-khoá ngoài. Có thể dùng mã định danh oid của BLOB để thực hiện quan hệ tham chiếu này. Bảng tham chiếu, gọi là

ref_tab sẽ có một cột chứa các mã định danh oid đƣợc định nghĩa là khoá ngoài. Cột này ta sẽ gọi là ref_col. Bảng dữ liệu đa phƣơng tiện có cột mã định danh oid là khoá chính.

Hình 5: Một bảng có thể tham chiếu đến nhiều bảng dữ liệu đa phương tiện khác nhau

Bảng chứa dữ liệu đa phƣơng tiện bắt buộc phải có hai cột chứa tên tệp và mã định danh nhƣ phân tích trên. Do đó, ta ấn định luôn hai tên cột là Ten và id. Ngoài ra, nó có thể có thêm một số cột khác, chứa các trƣờng dữ liệu ví dụ nhƣ ngày tháng tạo ra dữ liệu, ngƣời tạo ra dữ liệu, các mô tả khác,v.v... Các cột này là tuỳ chọn phụ thuộc vào từng ứng dụng.

Trong một CSDL có thể có nhiều bảng dữ liệu đa phƣơng tiện khác nhau. Một bảng tham chiếu ref_tab có thể có nhiều cột tham chiếu tới một hay nhiều bảng dữ liệu đa phƣơng tiện, nhƣ minh hoạ trong hình vẽ.

Ref_tab 1 Blobs * .map Blobs * .jpg Ref_tab2

Chƣơng 3- WEBGIS GIỚI THIỆU DANH LAM THẮNG CẢNH HÀ NỘI

3.1. Mô tả yêu cầu

Để minh họa cho những nghiên cứu lý thuyết đã trình bày ở trên, chƣơng này chúng ta sẽ xây dựng một WebGIS đơn giản giới thiệu danh lam thắng cảnh phục vụ du khách du lịch Hà Nội.

Một hệ thống thông tin hỗ trợ du lịch cần có các thông tin nhƣ vị trí du lịch, các di tích lịch sử, lễ hội và các dịch vụ cần thiết nhƣ khách sạn, nhà hàng tại các điểm du lịch. Những yêu cầu này hoàn toàn có thể thực hiện thông qua một website thông thƣờng. Tuy nhiên việc tích hợp thêm các chức năng GIS cho phép sử dụng giao diện là bản đồ số hóa. Hệ thống có tính trực quan hơn và tiện dùng hơn. Giải pháp hệ thống WebGIS giàu dữ liệu đa phƣơng tiện là phù hợp nhất với mục đích này.

Chúng ta có thể xác định một số yêu cầu mà ứng dụng cần thực hiện nhƣ sau

3.1.1. Yêu cầu đối với người sử dụng

- Trang web sẽ hiển thị bản đồ Hà Nội lên một khung nhìn

- Một thực đơn các lớp thông tin hiển thị, ngƣời sử dụng có thể chọn hiển thị một hoặc nhiều lớp thông tin mà mình cần.

- Cho phép ngƣời sử dụng thực hiện các thao tác đơn giản trên bản đồ nhƣ phóng to, thu nhỏ, di chuyển bản đồ.

- Có chức năng truy vấn bản đồ, khi chọn chức năng này ngƣời sử dụng có thể xem các thông tin về một đối tƣợng trên bản đồ bao gồm các thông tin thuộc tính và trình diễn các dữ liệu đa phƣơng tiện đi kèm.

- Từ các thông tin thuộc tính của đối tƣợng ngƣời dùng có thể xem đƣợc vị trí của đối tƣợng trên bản đồ.

3.1.2. Yêu cầu quản trị

- Chỉ cho phép ngƣời có quyền mới truy cập vào đƣợc. - Hiển thị danh sách các đối tƣợng của lớp đƣợc lựa chọn

- Cho phép sửa thông tin thuộc tính và cập nhật dữ liệu hình ảnh, âm thanh đi kèm mỗi đối tƣợng trong lớp.

3.2. Kiến trúc hệ thống và các công cụ nguồn mở

3.2.1. Hệ thống cơ sở

Để xây dựng ứng dụng minh họa, chúng tôi dựa vào bản mẫu của công ty DM Solution đƣợc tải về từ trang web http://www2.dmsolutions.ca/webtools/.

Đây là một hệ thống WebGIS minh hoạ cho khả năng tạo bản đồ động bằng việc sử dụng ROSA Applet. Nhƣ đã trình bày ở trên, Mapserver không phải là một hệ thông tin địa lý hoàn chỉnh. Nó chỉ có khả năng hiển thị các bản đồ tĩnh, để có thể thực hiện các thao tác duyệt bản đồ động nhƣ phóng to, thu nhỏ hay di chuyển bản đồ, chúng ta cần sử dụng các ngôn ngữ lập trình có hỗ trợ nhƣ PHP, Java,....

ROSA Applet là một trình tiện ích nhỏ đƣợc viết bằng Java, cho phép ngƣời sử dụng thay đổi cách xem bản đồ bằng cách Click chuột trên bản đồ. Có thể minh hoạ cách hoạt động của hệ thống khi sử dụng Rosa applet nhƣ sau:

Hình 6: Các thành phần của hệ thống WebGIS với MapServer

Các tiện ích Rosa Applet đƣợc tải về từ địa chỉ:

http://www2.dmsolutions.ca/webtools/rosa/index.html

WebGIS minh hoạ nêu trên đã thực hiện đƣợc một số chức năng nhƣ sau:

- Trang web hiển thị bản đồ Canada gồm các thông tin về ranh giới các bang và hệ thống giao thông chính.

- Có các thao tác cơ bản nhƣ phóng to, thu nhỏ, di chuyển bản đồ.

- Có chức năng truy vấn bản đồ, khi ngƣời sử dụng chọn chức năng này và bấm chuột trên bản đồ thì trang web sẽ trả lại các thông tin về vị trí truy vấn.

Tuy nhiên, trong ví dụ trên các thông tin thuộc tính chƣa đƣợc đƣa vào cơ sở dữ liệu. Hơn nữa các thông tin trả lại của trang web chỉ là dữ liệu dạng văn bản thông thƣờng, không có khả năng đính kèm và hiển thị dữ liệu đa phƣơng tiện.

3.2.2. Một cách đơn giản kết nối và trình diễn dữ liệu đa phương tiện

Môi trƣờng ứng dụng Web rất thuận tiện cho việc tích hợp và trình diễn dữ liệu đa phƣong tiện. Cách đơn giản nhất là dùng chức năng siêu liên kết của HTML. Ví dụ, mã lệnh HTML với nội dung là siêu liên kết

<a href =“ Đƣờng dẫn đến tệp ảnh đính kèm” > Tên đối tƣợng </a>

cho kết quả là khi tƣơng tác vào vị trí của đối tƣợng có siêu liên kết trên bản đồ sẽ nhận đƣợc hình ảnh hiển thị trên màn hình. Ví dụ có đoạn mã LAYER NAME khachsan METADATA “ DESCRIPTION”“ Khách sạn”

“ RESULT_FIELDS” “TEN DIACHI SOPHONG MIEUTA” END

Dòng” RESULT_FIELDS”“ TEN DIACHI SOPHONG MIEUTA” nói rằng thông tin trả lại khi truy vấn gồm có Tên, các thông tin bổ sung, địa chỉ khách sạn và

số phòng. Nếu ta thêm vào trƣờng” Ten” trong bảng khach_san.dbf nội dung dữ liệu là <a href =“ Đƣờng dẫn đến file ảnh đính kèm” >Tên đối tƣợng </a>

thì kết quả vấn tin trả về sẽ cho đoạn mã nhƣ mong muốn.

Tuy nhiên, đây không phải là cách nên dùng vì gây khó khăn cho việc quản lý các dữ liệu đa phƣơng tiện đƣợc đƣa vào hệ thống. Ảnh đính kèm cần phải đặt trong một thƣ mục sẵn có, trang web sẽ truy cập theo tên ảnh qua đƣờng dẫn trực tiếp, nhƣ thế nếu tên thƣ mục hoặc ảnh bị thay đổi thì trang web không thể tìm thấy ảnh. Thêm nữa việc thêm ảnh mới buộc phải thực hiện thủ công, và ngƣời quản trị phải tự quyết định cho tên ảnh để không trùng lặp, đây là công việc thực sự khó khăn khi hệ thống ngày càng lớn hơn.

Giải pháp hiệu quả hơn là xây dựng hệ thống lƣu trữ dữ liệu đa phƣơng tiện với một hệ quản trị CSDL có hỗ trợ kiểu dữ liệu này. Đây chính là các chức năng xử lý kiểu BLOB cần nghiên cứu.

3.3. Xây dựng dữ liệu

Để tạo dữ liệu thƣờng qua các bƣớc số hoá bản đồ, chuẩn hoá, thu thập thông