Liên hệ
IBSurgeon
Trang này được dịch bằng máy. Đọc bản gốc tiếng Anh. English

Thư viện IBSurgeon

Cấu trúc vật lý của cơ sở dữ liệu (InterBase và Firebird)

Alexey Kovyazin, Sergey Vostrikov, cập nhật lần cuối 05-Tháng Sáu-2004

Cấu trúc vật lý của cơ sở dữ liệu

Tại sao chúng ta phải nghiên cứu cấu trúc vật lý của cơ sở dữ liệu InterBase?

Thông thường, khi nói về cấu trúc vật lý của cơ sở dữ liệu InterBase, chúng ta muốn nói rằng nó biểu diễn dữ liệu từ quan điểm tổ chức dữ liệu ở mức thấp - ngay đến mức byte. Nhiều lập trình viên phát triển ứng dụng sử dụng ngôn ngữ cấp cao bỏ qua việc nghiên cứu các chi tiết ở mức thấp. Tuy nhiên, biết các nguyên tắc chính của tổ chức dữ liệu bên trong cơ sở dữ liệu là chìa khóa để thiết kế hiệu quả các ứng dụng cơ sở dữ liệu. Vì vậy, chúng ta sẽ có một chuyến khảo sát vào bên trong tổ chức cơ sở dữ liệu InterBase và tìm hiểu xem nó được sắp xếp như thế nào.

Vậy, hệ quản trị cơ sở dữ liệu (DBMS) dùng để làm gì? Rõ ràng là để lưu trữ và kiểm soát dữ liệu. Nghe có vẻ sáo rỗng, nhưng đáng để suy nghĩ. Người dùng đưa dữ liệu vào DBMS, hệ thống này bằng cách nào đó chuyển đổi dữ liệu sang các định dạng nội bộ mà nó hiểu được. Bạn có thể hình dung “0 và 1” nếu cụm từ “định dạng dữ liệu nội bộ” gây khó khăn trong việc liên tưởng. DBMS lưu trữ dữ liệu này, và tại thời điểm có yêu cầu đầu tiên phải trích xuất chúng từ định dạng của mình, chuyển đổi thành dạng phù hợp và đưa cho người dùng.

Chủ đề của chương này là DBMS lưu trữ dữ liệu của mình như thế nào, dưới dạng gì và chúng được tổ chức ra sao ở mức thấp nhất. Chúng tôi sẽ cố gắng giải thích cho bạn cách từ các bit và byte nằm trên ổ cứng, chúng ta có được dữ liệu có giá trị.

Các tệp cơ sở dữ liệu InterBase

Thông thường, khi nói về cơ sở dữ liệu, chúng ta muốn nói đến bản thân DBMS và thông tin người dùng, và thậm chí cả chương trình của khách hàng làm việc với dữ liệu. Trong chương này, chúng ta sẽ xem xét cơ sở dữ liệu như các tệp cơ sở dữ liệu.

Cơ sở dữ liệu InterBase đại diện cho một hoặc nhiều tệp chứa thông tin về mọi thứ liên quan đến cơ sở dữ liệu này. Thông tin về người dùng là một ngoại lệ vì người dùng được xác định ở mức toàn bộ máy chủ và được lưu trữ riêng, trong cơ sở dữ liệu bảo mật admin.ib (trước đây là ISC4.GDB trong các phiên bản trước 7).

Lời khuyên: Hãy xem chương “Bảo mật máy chủ và cơ sở dữ liệu” để nghiên cứu thêm về các nguyên tắc bảo mật InterBase.

Vì vậy, tất cả thông tin về cơ sở dữ liệu được lưu trữ trong các tệp này: dữ liệu, chỉ mục, trigger, thủ tục lưu trữ, v.v.

Cơ sở dữ liệu InterBase cho một dự án trung bình đại diện cho một tệp vì các phiên bản InterBase hiện đại có thể sử dụng 64bitIO để hoạt động với tệp dữ liệu và điều này cho phép bạn có tệp dữ liệu lên đến 64Gb. Các phiên bản InterBase trước đó có giới hạn 4 gigabyte cho mỗi tệp cơ sở dữ liệu (lên đến 64 Tbyte cho toàn bộ cơ sở dữ liệu). Như chúng ta có thể giả định, 64 gigabyte là khá đủ để lưu trữ thông tin của hầu hết mọi ứng dụng cơ sở dữ liệu. Nhưng nếu cần thiết, chúng ta có thể chia cơ sở dữ liệu thành nhiều tệp. Nhân tiện, có những cơ sở dữ liệu InterBase có kích thước hàng trăm gigabyte.

IBSurgeon - một hướng dẫn xuyên suốt cơ sở dữ liệu InterBase

Chúng ta cần biết chi tiết cấu trúc của các tệp cơ sở dữ liệu InterBase. Và do đó, nên có bất kỳ công cụ tiện lợi nào cho phép làm việc trực tiếp với các tệp cơ sở dữ liệu, không phải thông qua nhân máy chủ InterBase. Cách dễ nhất là sử dụng trình xem hex thông thường và cố gắng hiểu cấu trúc của các tệp cơ sở dữ liệu khi xem biểu diễn HEX của chúng. Đó sẽ là công việc khá tẻ nhạt.

Nhưng may mắn thay, có một công cụ để làm việc trực tiếp với cơ sở dữ liệu InterBase. Đó là IBSurgeon Editor - một công cụ để làm việc trực tiếp ở mức thấp với cơ sở dữ liệu InterBase, có thể được sử dụng để nghiên cứu cấu trúc bên trong của cơ sở dữ liệu InterBase và chẩn đoán các cơ sở dữ liệu bị hỏng để khôi phục chúng. Để biết thêm chi tiết, xem phụ lục «Công cụ quản trị và nhà phát triển InterBase».

IBSurgeon sử dụng cơ chế truy cập cơ sở dữ liệu thay thế của riêng mình cho phép mở và xem xét cơ sở dữ liệu ở bất kỳ trạng thái nào, bao gồm cả những cơ sở dữ liệu bị hỏng nặng mà nhân máy chủ InterBase/FireBird/Yaffil không thể mở được.

Chúng tôi sẽ sử dụng IBSurgeon để minh họa cấu trúc bên trong của cơ sở dữ liệu.

Các tệp *.IB/*.FDB từ bên trong

IB là phần mở rộng được khuyến nghị cho các tệp cơ sở dữ liệu InterBase, và FDB cho Firebird (trước đây là GDB). Điều đầu tiên chúng ta phải nói về cấu trúc của tệp IB là nó đại diện cho một tập hợp các trang có kích thước được xác định chặt chẽ. Kích thước của tệp cơ sở dữ liệu chia hết cho kích thước trang, không thay đổi đối với tất cả các tệp của cơ sở dữ liệu này. Các phiên bản InterBase khác nhau hỗ trợ các kích thước trang khác nhau, như được hiển thị trong bảng 1. Kích thước trang được đặt khi tạo cơ sở dữ liệu và không thể thay đổi trong suốt vòng đời của nó. Nói cách khác, chúng ta chỉ có thể thay đổi kích thước trang khi khôi phục cơ sở dữ liệu từ bản sao lưu.

Bảng 1. Kích thước trang được hỗ trợ bởi các phiên bản InterBase khác nhau
Phiên bản InterBase Kích thước trang, byte
1024 2048 4096 8192 16384
InterBase 4.0 * * * *
InterBase 5.x * * * *
InterBase 6.x-7.x * * * *

Việc đọc và ghi dữ liệu trong cơ sở dữ liệu được thực hiện theo từng trang, nhiều đặc tính quan trọng của máy chủ và cơ sở dữ liệu như kích thước bộ nhớ đệm cơ sở dữ liệu phụ thuộc vào kích thước trang và được tính bằng «trang».

Hãy mở bất kỳ cơ sở dữ liệu InterBase nào bằng IBSurgeon. Chỉ cần nhấp đúp vào tệp cơ sở dữ liệu là đủ. Hình 1 thể hiện danh sách các trang xuất hiện sau khi IBSurgeon mở cơ sở dữ liệu:

![](/images/IB DB structure/InterBase database structure_html_m4f802417.png)

Hình 1. Danh sách các trang cơ sở dữ liệu

Các trang có thể thuộc các loại khác nhau, mỗi loại phục vụ một mục đích nhất định. Sự phụ thuộc lẫn nhau của các loại khác nhau được biểu diễn có điều kiện trên hình 2. Hình 2 mô tả sơ đồ sự phân bố các trang trong tệp cơ sở dữ liệu - từ trái sang phải, từ trên xuống dưới, nếu tính từ đầu tệp. Các trang cùng loại không đi liền nhau một cách nghiêm ngặt - chúng có thể dễ dàng được trộn lẫn, được phân bố trong tệp theo thứ tự chúng được tạo bởi máy chủ khi mở rộng hoặc tạo cơ sở dữ liệu.

![](/images/IB DB structure/InterBase database structure_html_4005a6b0.png)

Hình 2. Sự phụ thuộc lẫn nhau giữa các loại trang khác nhau trong cơ sở dữ liệu InterBase

Bạn hẳn đã nhận thấy rằng một số loại trang không có tham chiếu đến các loại trang khác. Tuy nhiên, không có mâu thuẫn nào ở đây, vấn đề là các loại trang này được liên kết và sử dụng ở một mức cấu trúc khác. Chúng có thể được liên kết với bảng RDB$PAGES và các bảng hệ thống khác (bảng này và các đối tượng hệ thống khác chúng ta sẽ xem xét bên dưới - trong chương «Cấu trúc logic của cơ sở dữ liệu»). Trên hình 2, chúng ta chỉ có thể thấy các tham chiếu rõ ràng giữa các trang ở mức vật lý.

Hãy xem xét chi tiết có những loại trang nào trong cơ sở dữ liệu InterBase. Trong tệp ods.h từ bộ mã nguồn chính của InterBase có thông tin về tất cả các loại trang có thể có. Chúng tôi sẽ thường xuyên tham khảo tệp này để nhận dữ liệu không chỉ về ODS mà còn về nhiều điều cơ bản khác của nhân InterBase từ mã nguồn gốc. Tổng cộng có 11 loại trang được khai báo, nhưng chỉ có 9 loại đáng được giải thích (chúng ta có thể thấy rõ từ bảng 2). Các loại trang có định danh 0 và 1 là không xác định hoặc không được sử dụng.

Bảng 3. Các loại trang trong FB
Định nghĩa trong ods.h Định danh loại trang Mô tả trang
pag_undefined 0 Không xác định - Nếu một trang có loại trang này thì có lẽ nó là trang trống
pag_header 1 Trang tiêu đề cơ sở dữ liệu
pag_pages 2 Trang kiểm kê trang (hoặc Trang kiểm kê không gian - SIP)
pag_transactions 3 Trang kiểm kê giao dịch (TIP)
pag_pointer 4 Trang con trỏ
pag_data 5 Trang dữ liệu
pag_root 6 Trang gốc chỉ mục
pag_index 7 Trang chỉ mục (B-tree)
pag_blob 8 Trang dữ liệu Blob
pag_ids 9 Gen-ids
pag_log 10 Thông tin nhật ký ghi trước (Write ahead log)

Mỗi trang có tiêu đề riêng, chứa thông tin về loại trang và số của trang tiếp theo cùng loại. Chúng ta có thể nhận được danh sách đầy đủ các tham số mà mỗi tiêu đề trang chứa, nếu xem xét cấu trúc pag trong tệp định nghĩa ods.h.

/\* Tiêu đề trang cơ bản */

typedef struct pag {

SCHAR pag_type; /*định danh loại trang*/

SCHAR pag_flags; /*cờ trang*/

USHORT pag_checksum; /*tổng kiểm tra trang: bằng 12345 sau phiên bản 5.0 */

ULONG pag_generation; /*thế hệ trang */

ULONG pag_seqno; /* WAL seqno của lần cập nhật cuối - không dùng nữa*/

ULONG pag_offset; /* WAL offset của lần cập nhật cuối - không dùng nữa*/

} *PAG;

Các loại trang và cách sử dụng chúng

Hãy xem xét chi tiết từng loại trang và tìm hiểu về chức năng cũng như thông tin chúng chứa. Chúng ta sẽ bắt đầu từng bước - từ trang đầu tiên.

Bất kỳ thao tác nào với cơ sở dữ liệu đều bắt đầu từ việc đọc trang tiêu đề cơ sở dữ liệu (hoặc trang tiêu đề). Trang tiêu đề cơ sở dữ liệu nằm đầu tiên trong tất cả các tệp cơ sở dữ liệu. Theo đó, nó được biểu diễn đầu tiên trên hình 2 (nếu chúng ta tưởng tượng rằng hình ảnh biểu diễn sự mở rộng của tệp cơ sở dữ liệu từ trái sang phải, từ trên xuống dưới)

Trang tiêu đề chứa thông tin về toàn bộ cơ sở dữ liệu. Trên hình 3, một trang dữ liệu được biểu diễn theo cách IBSurgeon hiển thị cho chúng ta:

![](/images/IB DB structure/InterBase database structure_html_m3c792928.png)

Hình 3. Trang tiêu đề cơ sở dữ liệu.

Bạn có thể có ý tưởng về nội dung của trang tiêu đề bằng cách nhận số liệu thống kê cơ sở dữ liệu. Để làm điều này, bạn có thể sử dụng tiện ích dòng lệnh gstat hoặc một công cụ quản trị InterBase tiện lợi hơn từ danh sách trong phụ lục «Công cụ quản trị và nhà phát triển InterBase». Để biết thêm chi tiết về quá trình nhận số liệu thống kê và mô tả dữ liệu trang tiêu đề, xem chương «Số liệu thống kê».

Cần lưu ý rằng trang tiêu đề chứa thông tin quan trọng như kích thước trang, số phiên bản ODS (thông tin về nó bạn sẽ tìm thấy bên dưới), ngày tạo cơ sở dữ liệu, thông tin về giao dịch và một tập hợp các thông tin khác nhau. Ví dụ, ID triển khai lưu trữ thông tin về hệ điều hành mà cơ sở dữ liệu này được tạo ra.

Khi kết nối cơ sở dữ liệu, máy chủ InterBase đọc 1024 byte thông tin đầu tiên từ đầu tệp và xác định theo các giá trị đã đọc xem tệp được chỉ ra trong dòng kết nối có phải là cơ sở dữ liệu InterBase hay không. Sau đó, máy chủ đọc số phiên bản ODS từ trang tiêu đề và kích thước trang trong cơ sở dữ liệu này và, nếu phiên bản ODS tương thích với triển khai máy chủ, nó đọc lại toàn bộ trang tiêu đề, sử dụng kích thước trang phù hợp, nhận được từ 1024 byte đầu tiên. Sau đó, các tham số quan trọng khác của cơ sở dữ liệu như chế độ đọc-ghi, phương ngữ cơ sở dữ liệu, v.v. được đọc từ trang tiêu đề.

Trên trang tiêu đề có tham chiếu đến trang con trỏ đầu tiên, lưu trữ các tham chiếu đến các trang dữ liệu chứa siêu dữ liệu: bảng RDB$Pages (xem bên dưới trong chương «Cấu trúc logic của cơ sở dữ liệu InterBase»). Trên hình 2, tham chiếu này được minh họa bằng mũi tên có ghi chú «Số của trang con trỏ thứ 1 trong cơ sở dữ liệu». Máy chủ đọc số của trang con trỏ thứ 1 từ trang tiêu đề và chuyển đến nó. Trang con trỏ bao gồm một mảng có thứ tự các số trang dữ liệu tạo thành một bảng nhất định (một bảng được coi là đối tượng SQL, được mô tả bởi cấu trúc logic của cơ sở dữ liệu). Bây giờ bạn có thể thấy IBSurgeon diễn giải trang con trỏ như thế nào (xem hình 4):

![](/images/IB DB structure/InterBase database structure_html_3bb85660.png)

Hình 4. Trang con trỏ cơ sở dữ liệu InterBase

Trang chứa một vectơ trang dữ liệu; dữ liệu này tạo thành một bảng nhất định trong cơ sở dữ liệu. Vectơ này đại diện cho một mảng các con trỏ tương ứng với số của các trang dữ liệu trong tệp. Máy chủ đọc số 4 byte của trang dữ liệu và chuyển đến trang dữ liệu cần thiết. Khi chuyển đến trang dữ liệu thứ 1 của RDB$Pages, máy chủ bắt đầu xây dựng biểu diễn nội bộ của cơ sở dữ liệu được sử dụng sau đó bởi máy chủ cho tất cả các thao tác với cơ sở dữ liệu. RDB$Pages lưu trữ các tham chiếu không chỉ đến các trang dữ liệu chứa thông tin về cơ sở dữ liệu mà còn đến các trang còn lại đóng vai trò trong việc đảm bảo hoạt động của cơ sở dữ liệu.

Chúng ta thường đề cập đến bảng này, nói đúng ra, liên quan đến cấu trúc logic của cơ sở dữ liệu. Tuy nhiên, mọi thứ đều liên kết với nhau, do đó chúng ta không thể mô tả điều gì đó mà không đề cập đến điều khác.

Một trong những loại trang quan trọng là trang kiểm kê giao dịch (TIP). Các trang này giống như tất cả các trang khác, bao gồm một phần tiêu đề và phần chính biểu thị một mảng các chuỗi 2 byte. Các chuỗi này mô tả trạng thái của các giao dịch trong cơ sở dữ liệu (để biết thêm chi tiết về giao dịch, xem chương «Giao dịch»).

Bảng 4. Các trạng thái giao dịch có thể có trong TIP
Giá trị của chuỗi trên PIP Ý nghĩa
0 Giao dịch chưa bắt đầu, đang hoạt động hoặc bị mất mà không có commit hoặc rollback
1 Giao dịch đã thực hiện Commit
2 Giao dịch đã thực hiện Rollback
3 Giao dịch Limbo (cho 2PC)

Mỗi phiên bản bản ghi có định danh giao dịch riêng, điều này cho phép các giao dịch thực hiện đồng thời có thể «biết» về trạng thái của nhau và giải quyết xung đột trong quá trình làm việc đa người dùng (xem chương “Kiến trúc đa thế hệ của InterBase” để biết thêm về phiên bản bản ghi và các vấn đề khác).

Trang tiêu đề cơ sở dữ liệu, trang con trỏ và TIP thuộc về các loại trang «nội bộ», chỉ được sử dụng bởi máy chủ. Người dùng InterBase không bao giờ nhận được thông tin chúng chứa một cách tường minh. Các trang lưu trữ thông tin về việc phân bổ trang (thường được gọi là Trang kiểm kê trang (PIP) hoặc Trang kiểm kê không gian (SIP)) cũng thuộc loại trang nội bộ. Các trang này nằm bắt đầu từ trang thứ hai, tức là PIP đầu tiên nằm ngay sau trang tiêu đề, và xuất hiện trong cơ sở dữ liệu theo các khoảng trang cố định của các loại khác. Kích thước của các khoảng này cho biết PIP xuất hiện sau bao nhiêu trang thuộc loại khác, và phụ thuộc vào kích thước trang được đặt cho cơ sở dữ liệu này. Các Trang kiểm kê trang không được tính trên các trang con trỏ và không được chỉ ra trong RDB$Pages. Tính toàn vẹn của các trang này là rất quan trọng cho hoạt động thành công của toàn bộ cơ sở dữ liệu vì nội dung PIP mô tả trạng thái của tất cả các trang còn lại trong cơ sở dữ liệu. Mỗi trang cơ sở dữ liệu có thể có 3 trạng thái: chưa được phân bổ, được phân bổ có không gian, được phân bổ và đầy. Khi có nhu cầu về không gian bổ sung cho dữ liệu mới, máy chủ kiểm tra PIP để tìm các trang chưa được phân bổ. Nếu có trang như vậy, máy chủ thay đổi trạng thái của nó thành được phân bổ có không gian. Nếu không có trang chưa được phân bổ, cơ sở dữ liệu mở rộng - một trang dữ liệu mới được thêm vào.

Một ví dụ về trang dữ liệu trong IBSurgeon và dữ liệu nó chứa được đưa ra trong hình 5.

![](/images/IB DB structure/InterBase database structure_html_1cb26c4f.png)

Hình 5. Trang kiểm kê trang

Ngay khi trang được phân bổ, InterBase ghi trạng thái của nó lên SIP và sau đó ghi chính trang đó. Sau đó, chúng ta phải thêm trang vừa được tạo lại này vào một số lượng lớn các trang, ví dụ như các trang dữ liệu cho một bảng. Để làm điều đó, chúng ta nên ghi tham chiếu đến trang mới này trên trang cuối cùng của số lượng lớn các trang đó - ví dụ, trên trang dữ liệu cuối cùng của một bảng. Nếu máy chủ bị gián đoạn công việc ngay sau khi ghi lên SIP, nhưng không ghi tham chiếu trên các trang tham chiếu đến trang vừa được phân bổ, thì trang này trở thành trang mồ côi. Một trang mồ côi được tạo về mặt vật lý, được dành riêng trên SIP, nhưng không có tham chiếu nào đến nó từ các trang khác, điều đó có nghĩa là máy chủ sẽ không thể tìm thấy nó và ghi dữ liệu lên đĩa. Trang mồ côi được đánh dấu bằng hình vuông màu đỏ trong hình 2. Các trang mồ côi chủ yếu phát sinh do máy chủ bị mất điện đột ngột và được «chữa trị» bằng công cụ đặc biệt để sửa chữa cơ sở dữ liệu gfix (hoặc bằng FirstAID) (hoặc bằng IBSurFirstAID).

Trước khi xem xét các trang dữ liệu, chúng ta nên đề cập đến các loại trang quan trọng: trang bộ sinh và trang chỉ mục. Các trang bộ sinh biểu thị một mảng các số 4 byte, hiển thị trạng thái của các bộ sinh. Thực tế, bộ sinh là một bộ đếm thông thường.

Trong hình 6, bạn có thể thấy một trang bộ sinh. Lưu ý rằng mặc dù IBSurgeon hiển thị tên bộ sinh, nhưng nó không phải là các tên này được lưu trữ trên các trang bộ sinh. Điều này được thực hiện để thuận tiện cho người dùng khi nghiên cứu cơ sở dữ liệu. Trong thực tế, tên bộ sinh được lưu trữ trong bảng hệ thống RDB$Generators.

![](/images/IB DB structure/InterBase database structure_html_7728f31.png)

Hình 6. Trang bộ sinh (g en-ids )

Như bạn thấy trong ví dụ này, cơ sở dữ liệu chứa các bộ sinh hệ thống, bắt đầu bằng tiền tố RDB$, và các bộ sinh do người dùng định nghĩa. Nếu bạn muốn biết về chức năng và cách sử dụng bộ sinh khi phát triển ứng dụng cơ sở dữ liệu InterBase, xem chương «Bảng. Khóa chính và bộ sinh». Các trang bộ sinh được tính cùng với các trang khác trong bảng RDB$Pages.

Mỗi bảng có ít nhất một trang gốc chỉ mục, bất kể nó có chỉ mục hay không. Trang này chứa các con trỏ đến các trang chỉ mục cho một bảng cụ thể. Chúng ta có thể nói rằng trang gốc chỉ mục có tầm quan trọng tương tự đối với các trang chỉ mục như trang con trỏ đối với các trang dữ liệu. Do đó IBSurgeon biểu thị nó theo cách tương tự. Một ví dụ về trang gốc chỉ mục được đưa ra trong hình 7.

![](/images/IB DB structure/InterBase database structure_html_1c46b1cd.png)

Hình 7. Trang gốc chỉ mục

Trang gốc chỉ mục chứa danh sách các trang nơi lưu trữ các giá trị chỉ mục, cũng như thông tin chỉ mục - độ chọn lọc của chỉ mục và các cờ khác nhau. Để biết thêm chi tiết về chỉ mục, vai trò và cách sử dụng của chúng trong cơ sở dữ liệu InterBase, xem chương «Chỉ mục».

Các trang chỉ mục chứa trực tiếp các giá trị của chỉ mục, hoặc nếu cấp chỉ mục >0, chứa các tham chiếu đến các trang chỉ mục bên dưới. Đây là một ví dụ về trang chỉ mục (hình 8).

![](/images/IB DB structure/InterBase database structure_html_m35b3f5ff.png)

Hình 8. Trang chỉ mục (B-tree)

Trang chỉ mục lưu trữ các giá trị được nén của dữ liệu được lập chỉ mục. Một cơ chế lập chỉ mục khá phức tạp được sử dụng, đặc biệt khi tạo chỉ mục tổng hợp (bao gồm nhiều trường).

Nói chung, các trang dữ liệu và các trang chứa giá trị BLOB lưu trữ thông tin người dùng. Các trang dữ liệu chứa các bản ghi trong các bảng người dùng của cơ sở dữ liệu, các đoạn bản ghi, phiên bản cũ, sự khác biệt giữa các phiên bản, trường BLOB, v.v. Đối với các trường BLOB, chúng được kết nối với các bản ghi trên các trang dữ liệu và chứa dữ liệu có kích thước lớn, không thể nằm trên trang dữ liệu. Kiểu tham chiếu lưu trữ giá trị BLOB cho phép lưu trữ dữ liệu lớn.

Một ví dụ về trình bày trang dữ liệu trong IBSurgeon được đưa ra trong hình 9:

![](/images/IB DB structure/InterBase database structure_html_235e0c51.png)

Hình 9. Trang dữ liệu

Tiêu đề trang dữ liệu chứa loại trang, định danh bảng sở hữu (relationID). Các bản ghi được lưu trữ trên các trang dữ liệu từ cuối trang và chúng được phân bổ gần về phía đầu trang khi chúng được lấp đầy.

Chúng ta có thể chắc chắn về điều này nếu nhìn vào các chỉ mục hàng, chứa 2 giá trị - độ lệch trên trang và độ dài của nó. Như bạn thấy ở đầu hàng có các bản ghi, được phân bổ ở cuối trang - ví dụ, bản ghi đầu tiên có độ lệch 8156 byte và độ dài 34 byte - do đó nó kết thúc ở 8156+34=8192 byte - ngay tại mép của trang (trong trường hợp của chúng ta, kích thước trang là 8192 byte). Khi trang được lấp đầy (với dữ liệu từ trên xuống và chỉ mục bản ghi từ dưới lên), máy chủ bắt đầu ghi các bản ghi mới và phiên bản của các bản ghi cũ vào các trang mới. Từ cơ chế lấp đầy trang được mô tả ở trên, chúng ta có thể dễ dàng hiểu tại sao các chuyên gia InterBase nhấn mạnh khuyến nghị sử dụng các trang dữ liệu có kích thước lớn (tối thiểu 4096 byte, tốt hơn là 8192). Nếu chúng ta tạo một bảng có một bản ghi có kích thước khá lớn (ví dụ 10 trường VARCHAR (255)), chúng sẽ chiếm, được lấp đầy, hơn 2550 byte. Điều đó có nghĩa là bản ghi như vậy sẽ quá lớn đối với một trang có kích thước nhỏ (1024 hoặc 2048). Rõ ràng là việc cần phải tải nhiều trang từ đĩa để đọc một bản ghi duy nhất sẽ không làm tăng tốc độ làm việc với cơ sở dữ liệu của bạn. Do đó, nên xác định lại kích thước trang dữ liệu khi tạo hoặc khôi phục cơ sở dữ liệu vì kích thước 1024 byte được đặt theo mặc định. Chúng ta vừa xem xét ngắn gọn các loại trang chính của tệp dữ liệu InterBase và chức năng của chúng. Bây giờ chúng ta có thể chuyển sang cấp độ cấu trúc cao hơn.

ODS

ODS là chữ viết tắt của On-Disk Structure, tức là cấu trúc dữ liệu của cơ sở dữ liệu InterBase trên đĩa. ODS xác định cách dữ liệu trong các tệp cơ sở dữ liệu được tổ chức. Định nghĩa về các hằng số và cấu trúc dữ liệu chính để triển khai cấu trúc trên đĩa nằm trong tệp ods.h từ bộ mã nguồn InterBase. ODS đã được thay đổi trong quá trình phát triển InterBase, và khi làm việc với một cơ sở dữ liệu cụ thể, máy chủ xác định số phiên bản ODS để biết nó đang xử lý cái gì. Tệp ods.h trình bày cho chúng ta các phiên bản sau của cấu trúc trên đĩa:

  • ODS 5 được sử dụng bởi InterBase 3.3 và không được hỗ trợ bởi các phiên bản cao hơn

  • ODS 6 và ODS 7 chưa bao giờ được phát hành

  • ODS 8 được sử dụng bởi InterBase 4.0

  • ODS 9 được sử dụng bởi InterBase 4.5 trở lên

  • ODS 10 ra đời với InterBase 6

  • ODS 11 ra đời với InterBase 7.0

Ngoài các phiên bản ODS chính, còn có các phiên bản phụ phụ thuộc vào phiên bản cụ thể của máy chủ cơ sở dữ liệu đã tạo ra chúng. Số chính của phiên bản được ghi trong phần nguyên của số, biểu thị phiên bản, số phụ - trong phần phân số. Ví dụ, phiên bản máy chủ 4.0 tạo các cơ sở dữ liệu có ODS 8.0 và InterBase 4.2 - 8.2. Việc chuyển đổi giữa các phiên bản phụ từ dưới lên được thực hiện tự động. Ví dụ, chỉ cần mở một cơ sở dữ liệu có ODS 8.0, được tạo bởi máy chủ 4.0 bằng InterBase 5.6, và ODS của cơ sở dữ liệu này sẽ có phiên bản 8.2. Việc chuyển đổi giữa các phiên bản chính của cơ sở dữ liệu chỉ được thực hiện thông qua sao lưu cơ sở dữ liệu bằng phiên bản cũ và khôi phục bằng phiên bản máy chủ mới. Quá trình chuyển đổi giữa các phiên bản được mô tả chi tiết trong chương 1.4 «Di chuyển».

Điểm quan trọng trong việc triển khai hỗ trợ ODS cho các phiên bản InterBase 4.x và 5.x là khả năng tương thích ngược của các máy chủ InterBase 4.x và 5.x với phiên bản thấp hơn một đơn vị so với phiên bản triển khai của một máy chủ cụ thể. InterBase hỗ trợ nhiều ODS có thể có, và theo phiên bản ODS của nó khi kết nối với cơ sở dữ liệu cụ thể, nó chọn hỗ trợ triển khai ODS cần thiết. Cơ chế đưa ra quyết định về việc chọn triển khai hỗ trợ ODS nào trong một trường hợp cụ thể được gọi là Y-Valve ((c) của Steve Trenton).

Nói một cách dễ hiểu hơn, một cơ sở dữ liệu có ODS 8.x, tương ứng với InterBase 4.0, có thể được mở trong InterBase 5.x.

Bảng tương thích ODS đầy đủ được hiển thị bên dưới:
Phiên bản InterBase ODS chính ODS phụ
4.0/4.1 8.0 …
4.2 8.2 8.2
5.0/5.1 9.0 8.2
5.5 9.1 8.2
5.6 9.1 8.2
6.0 10.0 9.0/9.1
7.0 11.0 10.0
7.1 11.1 10.0

ODS có khả năng tương thích ngược. Nói cách khác, máy chủ có phiên bản cao hơn và tất cả các công cụ của nó sẽ có thể làm việc với cơ sở dữ liệu được tạo bởi các phiên bản máy chủ trước đó, nhưng không phải ngược lại. Nếu bạn cố gắng mở một cơ sở dữ liệu được tạo trong phiên bản InterBase 6 bằng InterBase 5.x, bạn sẽ nhận được thông báo lỗi «Unsupported On-disk structure: Found ODS 10, supported ODS 9».

Mô tả về việc chuyển đổi giữa các phiên bản từ dưới lên và ngược lại xem trong chương «Di chuyển».

ODS rất quan trọng đối với các vấn đề liên quan đến sao lưu và trích xuất cơ sở dữ liệu, cũng như khôi phục các cơ sở dữ liệu bị hỏng. Các công cụ sao lưu gbak và khôi phục gfix theo dõi phiên bản ODS và sẽ không hoạt động nếu phiên bản ODS của cơ sở dữ liệu mà chúng phải phục vụ lớn hơn phiên bản được triển khai trong chúng. Điều đó có nghĩa là gbak từ 4.x sẽ không thể tạo bản sao lưu cơ sở dữ liệu nếu nó được tạo bởi máy chủ 5.x, tuy nhiên điều ngược lại thì dễ dàng.

Cầu nối giữa cấu trúc vật lý và logic của cơ sở dữ liệu

Chúng ta đã xem xét cấu trúc vật lý của các tệp cơ sở dữ liệu một cách tổng quát. Bây giờ chúng ta phải chuyển sang cấu trúc logic của cơ sở dữ liệu. Hãy tạo một cầu nối giữa các cấp độ vật lý và logic của việc biểu diễn thông tin trong cơ sở dữ liệu để không có sự phân chia trong các khái niệm và không có khoảng trống trong tài liệu. Mọi thứ được lưu trữ trong các trang cơ sở dữ liệu khác nhau phải được tổ chức theo một cách nào đó trong bộ nhớ máy tính; dữ liệu từ tệp cơ sở dữ liệu phải được chuyển đổi thành một tập hợp các đối tượng và biến nội bộ của máy chủ. Tập hợp này được gọi là hình ảnh cơ sở dữ liệu nội bộ theo thuật ngữ của Ann Harrison [1.. Vì vậy, chúng ta sẽ cố gắng xem xét quá trình tạo hình ảnh cơ sở dữ liệu nội bộ.

  • Máy chủ đọc 1024 byte từ đầu tệp và nếu đó thực sự là tệp cơ sở dữ liệu InterBase, nó xác định kích thước trang của cơ sở dữ liệu này và đọc lại toàn bộ trang tiêu đề.

  • Từ tiêu đề, máy chủ trang trích xuất số trang con trỏ lưu tham chiếu đến các trang dữ liệu, xác định bảng RDB$Pages.

  • Máy chủ tiếp tục đến trang con trỏ này và bắt đầu đọc thông tin từ các trang dữ liệu được trỏ tới. Nó điền dữ liệu vào bảng RDB$Pages đầu tiên. Bảng này giống như một cầu nối giữa các đối tượng vật lý - các trang của tệp cơ sở dữ liệu và các đối tượng logic - các bảng. Cấu trúc của RDB$Pages giống như các bảng hệ thống khác được cố định chặt chẽ trong InterBase.

  • Sau khi nhận được dữ liệu về việc phân bổ trang theo các quan hệ (quan hệ - thực tế, nó giống như các bảng thông thường, và chúng ta có thể thay thế các khái niệm này một cách tinh thần để đơn giản hóa), InterBase bắt đầu hình thành các cấu trúc dữ liệu: đầu tiên là các bảng hệ thống, ràng buộc và chỉ mục, sau đó là các đối tượng người dùng.

  • Sau khi khởi tạo siêu dữ liệu hệ thống và người dùng (bảng, ràng buộc, chỉ mục và các đối tượng cơ sở dữ liệu khác), InterBase trả về xử lý của cơ sở dữ liệu này cho người dùng, người đã yêu cầu mở cơ sở dữ liệu. Trong xử lý chính là một định danh cho InterBase biết cơ sở dữ liệu nào để làm việc vì một số người dùng có thể làm việc cùng lúc và điều đó có nghĩa là một số cơ sở dữ liệu có thể được mở.

  • Sau các thao tác này, cơ sở dữ liệu được coi là đã mở và máy chủ sẵn sàng thực thi các truy vấn của người dùng đối với nó. Bây giờ khi một cầu nối nhất định được tạo ra, kết nối cấu trúc vật lý và logic của cơ sở dữ liệu, chúng ta có thể bắt đầu nghiên cứu các đặc điểm của cấu trúc logic.

Cấu trúc logic của cơ sở dữ liệu InterBase

Cấu trúc logic là một khái niệm khá mơ hồ, do đó chúng ta sẽ cố gắng nắm vững các ý tưởng chính dần dần, hy vọng rằng sau này chúng sẽ trở nên rõ ràng một cách trực quan. Điều đầu tiên chúng ta sẽ xem xét liên quan đến cấu trúc logic của cơ sở dữ liệu là các bảng hệ thống và nội dung của chúng. Các bảng hệ thống mô tả hệ thống, cũng như siêu dữ liệu người dùng. Nói chung, thuật ngữ «metadata» có nghĩa là «dữ liệu mô tả một tập hợp dữ liệu». Tiền tố «meta» có nghĩa là: «mô tả một tập hợp». Ví dụ, ngôn ngữ meta là một ngôn ngữ mô tả một tập hợp các ngôn ngữ. Siêu dữ liệu mô tả dữ liệu người dùng, đó là các bảng, trình kích hoạt, khung nhìn, thủ tục lưu trữ, v.v. - mọi thứ triển khai các quy tắc lưu trữ và xử lý thông tin, vì đó mà cơ sở dữ liệu cụ thể này được tạo ra.

Thật thú vị khi biết lần đầu tiên rằng tất cả siêu dữ liệu - các bảng người dùng, trình kích hoạt, khung nhìn, cũng như tất cả các đối tượng hệ thống - được lưu trữ trong cùng các bảng, từ đó bạn có thể đọc và ghi dữ liệu bằng các truy vấn SQL thông thường. Các bảng này chỉ khác nhau «trực quan» ở chỗ tên của chúng bắt đầu bằng RDB$. 4 ký hiệu này được dành riêng cho tên của các đối tượng hệ thống. Không một bảng người dùng, cột hoặc đối tượng nào khác có quyền có tên bắt đầu bằng các ký hiệu này. Về mặt hình thức, bạn có thể tạo một bảng có tên bắt đầu bằng các ký hiệu dành riêng, nhưng tài liệu InterBase không khuyến nghị làm điều đó.

Một câu hỏi được đặt ra: nếu dữ liệu về cấu trúc cơ sở dữ liệu được lưu trữ trong cùng các bảng như dữ liệu người dùng, thì thông tin về các bảng mô tả các bảng được lưu trữ ở đâu? Một ví dụ kinh điển về vấn đề «con gà và quả trứng» - làm thế nào một cái có thể xuất hiện trước cái kia, nếu chúng phụ thuộc lẫn nhau? Câu trả lời là các bảng hệ thống ở trạng thái nguyên thủy của chúng được cố định trong các mã InterBase ban đầu và được tự động mở khi tạo cơ sở dữ liệu theo một thứ tự xác định. Chúng ta đã nói về bảng RDB$Pages so sánh các trang vật lý trong các tệp cơ sở dữ liệu với các đối tượng xác định của cơ sở dữ liệu này. Cấu trúc của bảng này được đưa ra dưới đây:

Bảng 5. Bảng hệ thống RDB$Pages
Tên cột Kiểu dữ liệu Mô tả
RDB$PAGE_NUMBER INTEGER Số trang vật lý
RDB$RELATION_ID SMALLINT Định danh của bảng, mà trang được phân bổ cho
RDB$PAGE_SEQUENCE INTEGER Số của trang này
RDB$PAGE_TYPE SMALLINT Loại trang - xem bảng 3

Mỗi trang dữ liệu liên quan đến một bảng nhất định. Mối quan hệ này được hỗ trợ bởi trường RDB$RELATION_ID, nơi lưu trữ tham chiếu đến bảng. Như đã mô tả ở trên, trong quá trình xây dựng hình ảnh cơ sở dữ liệu nội bộ, máy chủ tạo bảng này và điền dữ liệu vào đó theo một thuật toán đã đặt. Để chính xác, tại thời điểm xây dựng hình ảnh cơ sở dữ liệu nội bộ, RDB$Pages không phải là một bảng, nó chỉ là một tệp dữ liệu có định dạng xác định, được InterBase biết đến. Theo một thuật toán cố định, máy chủ đọc dữ liệu từ tệp này và tạo một bảng - RDB$Relations - quan trọng cho toàn bộ cơ sở dữ liệu. Bảng này mô tả tất cả các bảng của cơ sở dữ liệu. Nếu chúng ta thực hiện truy vấn SQL:

SELECT * from RDB$Relations

để tìm hiểu RDB$Relations chứa tham chiếu đến những bảng nào, chúng ta sẽ thấy rằng nó chứa RDB$Pages và chính nó. Rõ ràng là trong trường hợp này máy chủ đang gian lận một chút, thay thế các bảng hệ thống này và các bảng hệ thống khác trong RDB$Relations bằng cách hồi tố, hợp pháp hóa chúng theo cách đó. Máy chủ ghi chúng như các bảng «bình thường», nơi nó có thể thêm hoặc xóa bản ghi. Nói cách khác, cung cấp một giao diện SQL tiêu chuẩn để làm việc với siêu dữ liệu.

Và một câu hỏi khá hợp lý có thể được đặt ra - tại sao các nhà phát triển InterBase lại điều chỉnh dữ liệu hệ thống của họ theo giao diện người dùng? Bạn thấy đấy, các cơ chế nội bộ của các thao tác truy cập và đọc sẽ nhanh hơn. Tất nhiên, có một ý nghĩa lớn trong việc cung cấp một cơ chế phổ quát để làm việc với các bảng, mô tả siêu dữ liệu.

Vấn đề là cấu trúc logic của cơ sở dữ liệu không chỉ bao gồm các bảng mà còn các đối tượng khác. Có các đối tượng sau trong InterBase:

  • Bảng

  • Khung nhìn

  • Trình kích hoạt

  • Trường_tính_toán

  • Xác thực

  • Thủ tục

  • Chỉ_mục_biểu_thức

  • Ngoại lệ

  • Người dùng

  • Trường

  • Chỉ mục

  • Hàm do Người dùng Định nghĩa (UDF)

Tuy nhiên, chúng ta chưa biết chắc chắn chức năng của một số đối tượng, nhưng chúng ta biết chắc chắn rằng tất cả chúng phải được mô tả và lưu trữ ở một dạng xem nào đó, thuận tiện cho người dùng và cho việc truy cập từ nhân InterBase. Tốt nhất là lưu các đối tượng này trong các bảng hệ thống. Việc thêm và sửa đổi chúng được thực hiện bằng các truy vấn SQL. Một giải pháp thông minh, phải không? Việc triển khai máy chủ hoàn toàn tách biệt khỏi một cơ sở dữ liệu cụ thể - tất cả các mối liên kết được mô tả bằng SQL và các phần mở rộng của nó - ngôn ngữ của các thủ tục lưu trữ và trình kích hoạt.

Vì vậy, tất cả các đối tượng máy chủ được lưu trữ trong các bảng. Mỗi loại đối tượng có bảng mô tả tất cả các thể hiện được mô tả trong cơ sở dữ liệu. Ví dụ, đối với trình kích hoạt có bảng RDB$Triggers, cho các thủ tục lưu trữ - RDB$Procedures, các khung nhìn được mô tả trong bảng RDB$Relations.

Chúng ta hãy xem xét chi tiết cấu trúc của bảng cuối cùng, mô tả tất cả các bảng và khung nhìn trong cơ sở dữ liệu. Cấu trúc của bảng RDB$RELATIONS được lấy từ Tài liệu tham khảo ngôn ngữ cho InterBase 6 và được đưa ra dưới đây trong bảng 6.

Bảng 6. Bảng hệ thống RDB$Relations
Tên cột Kiểu dữ liệu Độ dài Mô tả
RDB$VIEW_BLR BLOB 80 BLR: cho các khung nhìn, chứa BLR (Biểu diễn ngôn ngữ nhị phân) của truy vấn, mà InterBase thực hiện mỗi khi áp dụng cho khung nhìn.
RDB$VIEW_SOURCE BLOB 80 Văn bản: cho các khung nhìn, chứa mã của truy vấn SQL triển khai khung nhìn này.
RDB$_DESCRIPTION BLOB 80 Mô tả người dùng về bảng hoặc khung nhìn
RDB$RELATION_ID SMALLINT Chứa định danh nội bộ của bảng/khung nhìn
RDB$SYSTEM_FLAG SMALLINT Xác định loại bảng: dữ liệu người dùng - 0; Thông tin hệ thống > 0.
RDB$DBKEY_LENGTH SMALLINT Độ dài db$key
RDB$FORMAT SMALLINT Dành riêng cho việc sử dụng nội bộ của InterBase. Chứa bộ đếm sửa đổi siêu dữ liệu cho bảng đã cho.
RDB$FIELD_ID SMALLINT Số trường trong bảng.
RDB$RELATION_NAME CHAR 31 Tên bảng duy nhất.

Trong mô tả của bảng hệ thống này, chúng ta thấy một chữ viết tắt BLR. Để hiểu nó là gì, chúng ta sẽ có một chuyến du ngoạn vào SQL. Như đã biết, các khung nhìn, trình kích hoạt và thủ tục lưu trữ là mã, được viết bằng một phần mở rộng của ngôn ngữ SQL (đối với mỗi máy chủ DBMS có các phần mở rộng riêng của chúng). Nó gần với ngôn ngữ con người, điều này cho phép thực hiện các truy vấn trong đó một cách dễ dàng. Nhưng InterBase, rõ ràng, dịch nó thành một thứ gì đó «máy móc» hơn - cụ thể là BLR (Biểu diễn ngôn ngữ nhị phân). Bất kỳ truy vấn, khung nhìn, trình kích hoạt, thủ tục lưu trữ nào luôn được dịch sang BLR và sau đó được truyền đến nhân InterBase để thực thi.

BLR

BLR là một ngôn ngữ đặc biệt, được sử dụng như một liên kết trung gian giữa mã SQL mà lập trình viên viết và mã máy mà máy chủ chấp nhận. Không ai viết trực tiếp bằng BLR - điều đó sẽ khá khó khăn vì để có tốc độ chạy cao nhất có thể trong ngôn ngữ này, cái gọi là ký pháp Ba Lan đảo ngược được sử dụng. Đây là một ví dụ nhỏ:

blr_begin,

     blr\_assignment,

        blr\_field, 0, 7, 'D','A','T','E','I','Z','M',

        blr\_variable, 1,0,

     blr\_assignment,

        blr\_field, 0, 4, 'R','A','T','E',

        blr\_variable, 0,0,

     blr\_block,

BLR cho các truy vấn, thủ tục, trình kích hoạt và các trình kích hoạt khác của bạn được tạo bởi bộ tiền xử lý đặc biệt là một phần của nhân máy chủ. Như được hiển thị trong bảng 7, đối với các khung nhìn, văn bản (ban đầu) của khung nhìn, cũng như khung nhìn đã biên dịch, tức là BLR, được lưu trữ. Khi tham chiếu đến bất kỳ đối tượng nào có BLR, máy chủ thực thi mã nhị phân của đối tượng và nó không diễn giải văn bản ban đầu của các đối tượng này mỗi lần, điều này cho phép tăng tốc độ thực thi các truy vấn phức tạp.

Phân cấp các đối tượng trong InterBase

Để có một ý tưởng rõ ràng về các đối tượng cơ sở dữ liệu đại diện cho điều gì, chúng ta sẽ cố gắng tạo một phân cấp các đối tượng cơ sở dữ liệu theo nguyên tắc «ai chứa cái gì và cái gì». Các trang vật lý của tệp cơ sở dữ liệu là thứ đầu tiên phải được đưa vào phân cấp của chúng ta như mức tổ chức dữ liệu thấp nhất. Sau đó, các bảng đi tiếp như các đối tượng cơ bản, mô tả tất cả các loại đối tượng còn lại. Các bảng mô tả các thủ tục lưu trữ, trình kích hoạt, trường tính toán, xác thực, chỉ mục biểu thức, ngoại lệ, v.v. Hãy chú ý - chỉ mô tả! Các bảng chỉ chứa các khai báo và định nghĩa của các đối tượng này, và các đối tượng được triển khai thông qua BLR. Do đó, chúng ta có thể biểu diễn các bảng dưới dạng một khung, hỗ trợ tất cả các đối tượng cơ sở dữ liệu khác. BLR sẽ ở dưới cùng của khung như lớp triển khai, sau đó là các trình kích hoạt, thủ tục lưu trữ, chỉ mục biểu thức và khung nhìn.

Để trấn an các chuyên gia về cấu trúc nội bộ của InterBase, những người có thể phản đối rằng BLR của nhiều đối tượng (chẳng hạn như khung nhìn) được lưu trữ trong các bảng hệ thống, chúng tôi sẽ nhận xét rằng thái độ này khá khó thể hiện trên một bức tranh, và để đơn giản hóa, chúng tôi sẽ bỏ qua nó. Sơ đồ không có mục đích tái tạo lại các mối phụ thuộc lẫn nhau của các đối tượng cơ sở dữ liệu một cách hoàn toàn chính xác; nó chỉ minh họa mối liên kết chặt chẽ của chúng.

Thực tế là các loại đối tượng này được kết nối trực tiếp với BLR, triển khai chúng mà không có bất kỳ logic trung gian nào, hợp nhất chúng. Các ngoại lệ nên được phân bổ riêng - chúng đại diện cho các loại lỗi đặc biệt, do người dùng xác định. Các ngoại lệ được xử lý ở cấp độ nhân InterBase và do đó không có BLR. Các loại ràng buộc như kiểm tra được phân bổ phía trên các trình kích hoạt vì trong thực tế, các trình kích hoạt triển khai logic của các ràng buộc và kiểm tra.

Một phân cấp các đối tượng của cấu trúc logic và vật lý của cơ sở dữ liệu được vẽ trong hình 2.]

Hình 10. Các đối tượng của cấu trúc logic cơ sở dữ liệu InterBase

Tất nhiên, sơ đồ này mô tả cấu trúc logic và các mối liên kết giữa các đối tượng trong cơ sở dữ liệu một cách gần đúng và đưa ra một ý tưởng chung về nó. Bất kỳ ai muốn nghiên cứu cấu trúc siêu dữ liệu của cơ sở dữ liệu InterBase đều có thể thực hiện tái kỹ thuật các bảng hệ thống của cơ sở dữ liệu và xem xét tất cả các mối liên kết giữa các đối tượng của nó, cũng như áp dụng cho tài liệu và các mã chính của InterBase. Bảng này chỉ hiển thị các đối tượng cơ sở dữ liệu chính. Chúng ta hãy mô tả ngắn gọn các chức năng chính mà các đối tượng này thực hiện trong cơ sở dữ liệu.

Bảng - đối tượng chính, chứa dữ liệu người dùng và dữ liệu hệ thống. Một bảng có tên duy nhất và chứa một tập hợp các trường được đặt tên. Người dùng có thể đưa dữ liệu vào, trích xuất và sửa đổi dữ liệu trong các bảng. Có thể nói rằng bảng tương tự như các bảng giấy thông thường được kẻ tay.

Trigger - các phần mã thực thi, được sử dụng để triển khai các hành động bổ sung tại thời điểm thực hiện các thao tác dữ liệu. Trigger được thực thi trước hoặc sau các thao tác chèn, sửa đổi hoặc xóa, và cho phép thực hiện việc thay thế giá trị vào các bản ghi mới được tạo cũng như nhiều việc khác.

Một thủ tục lưu trữ là một công cụ mạnh mẽ để triển khai logic nghiệp vụ ở cấp độ cơ sở dữ liệu. Được thực thi ở cấp độ máy chủ, nó hoạt động rất nhanh và cho phép thực hiện một tập hợp các thao tác trên các tập dữ liệu. Các thủ tục lưu trữ của InterBase trả về các tập dữ liệu SQL chuẩn, trên đó có thể thực hiện tất cả các thao tác SQL, bao gồm cả việc hợp nhất với các bảng khác.

View là các truy vấn SQL đã được biên dịch, thực thi trên máy chủ. View cho phép tổ chức các tập dữ liệu, chuyển một phần logic nghiệp vụ lên máy chủ.

Ràng buộc (Validation) là các giới hạn được đặt trên các giá trị của trường trong bảng. Ví dụ, chúng ta có thể chỉ ra rằng trường nhất định sẽ chỉ chấp nhận các giá trị dương. Các ràng buộc về giá trị trường được triển khai bằng trigger và cho phép kiểm soát hiệu quả tính toàn vẹn tham chiếu ở cấp độ cơ sở dữ liệu. Thông thường, các ràng buộc được sử dụng để ngăn việc đưa các giá trị sai vào bảng.

Người dùng - InterBase cho phép chúng ta có nhiều người dùng làm việc với cơ sở dữ liệu và phân phối quyền truy cập vào các đối tượng cơ sở dữ liệu khác nhau giữa họ. Do đó, chúng ta có thể kiểm soát quyền thực hiện các thao tác cơ sở dữ liệu này hay thao tác khác.

Hàm do người dùng định nghĩa (UDF) - các hàm do người dùng định nghĩa. Đây là một trong những khả năng mạnh mẽ nhất của InterBase, cho phép chúng ta mở rộng giao diện SQL chuẩn bằng các hàm của riêng mình. Ví dụ, các hàm xử lý chuỗi như UPPER (đặt tất cả các ký tự ở dạng chữ hoa), được triển khai trong thư viện UDF chuẩn, đi kèm với bộ InterBase. Nhờ khả năng tạo UDF riêng, các nhà phát triển có thể mở rộng chức năng của InterBase với hầu như bất kỳ hàm nào. Chúng ta có thể sử dụng bất kỳ môi trường lập trình nào cho phép tạo thư viện động (Visual C++, C++ Builder, Delphi, v.v.) để tạo UDF.

Kết luận

Trong chương này, lần đầu tiên chúng ta đã xem xét các vấn đề về việc triển khai lưu trữ và xử lý dữ liệu trong cơ sở dữ liệu InterBase. Thật không may, chúng ta không thể đưa ra một đánh giá ngắn gọn về chủ đề này mà không đề cập đến một số lượng lớn các thuật ngữ và các phép so sánh không chính xác. Nếu chúng ta mô tả cấu trúc vật lý và logic của cơ sở dữ liệu chi tiết hơn, chúng ta sẽ phải đề cập đến mã nguồn chính của InterBase, nhưng đó sẽ là một cuốn sách khác.

Tuy nhiên, chúng tôi nghĩ rằng sẽ hữu ích cho mọi lập trình viên khi làm quen với nội dung của sản phẩm mà họ sử dụng hàng ngày.

Tài liệu tham khảo

  1. «The On-Disk Structure of InterBase» của Ann.W.Harrison

  2. «Space Management in InterBase» của Ann W.Harrison

  3. «Structure of a Data Page» của Paul Beach (Cảm ơn Dave Schnepper và Deej Bredenberg)