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

Kiểu dữ liệu

LƯU Ý: Tài liệu này là một chương trong cuốn sách “The InterBase World” được viết bởi Alexey Kovyazin và Serg Vostrikov.

Mặc dù thực tế là các kiểu dữ liệu được mô tả chi tiết trong tài liệu (xem [1, chương 4.), vẫn cần phải xem xét một loạt các khái niệm sẽ được sử dụng thường xuyên trong các chương tiếp theo của cuốn sách này. Ngoài thông tin chung, một số ví dụ về việc sử dụng các kiểu dữ liệu trong cơ sở dữ liệu InterBase và các khuyến nghị về việc sử dụng và chuyển đổi chúng cũng sẽ được xem xét. Chúng ta sẽ xem xét chi tiết sự khác biệt về kiểu dữ liệu tồn tại trong phương ngữ cơ sở dữ liệu InterBase thứ 1 và thứ 3.

Về dữ liệu

Các kiểu dữ liệu là các thành phần cơ bản của bất kỳ ngôn ngữ lập trình nào hoặc bất kỳ máy chủ DBMS nào. InterBase không phải là ngoại lệ. Khi chúng ta nói rằng cơ sở dữ liệu lưu trữ một số thông tin, chúng ta phải nhận ra rằng thông tin này không thể được lưu trữ ở một nơi. Ngược lại; dữ liệu phải được phân loại và đặt vào “kệ” của nó. Các kiểu dữ liệu xác định những gì có thể được đặt vào một “kệ” nhất định và những gì không. Khi chúng ta nói về “kệ”, trước hết chúng ta có nghĩa đến các trường của bảng cơ sở dữ liệu (xem chương “Bảng. Khóa chính và bộ sinh” (phần 1)), cũng như các biến trong trigger và stored procedure, v.v. Mỗi kiểu dữ liệu có một tập hợp các thao tác có thể được thực hiện trên các giá trị của kiểu này. Do đó, điều quan trọng là phải chọn đúng kiểu dữ liệu khi thiết kế cơ sở dữ liệu. Điều này sẽ giúp tránh được nhiều vấn đề khi phát triển các chương trình của khách hàng. Trong InterBase có 12 kiểu dữ liệu có thể đáp ứng yêu cầu của nhà phát triển trong việc lưu trữ dữ liệu. Các kiểu này được phân chia có điều kiện thành 6 nhóm sau:

  • để lưu trữ số nguyên - INTEGER và SMALLINT;
  • để lưu trữ số thực - FLOAT và DOUBLE PRECISION;
  • để lưu trữ số có độ chính xác cố định - NUMERIC và DECIMAL;
  • để lưu trữ ngày, giờ và dấu thời gian - DATE, TIME và TIMESTAMP;
  • để lưu trữ ký tự - CHARACTER (dạng viết tắt - CHAR) và VARYING CHARACTER (VARCHAR);
  • để lưu trữ dữ liệu mở rộng động - BLOB

Ngoài ra, có thể định nghĩa các mảng giá trị của các kiểu nguyên thủy, tức là tất cả các kiểu được liệt kê ngoại trừ BLOB.

Hầu hết các kiểu dữ liệu InterBase tương ứng với các kiểu được định nghĩa trong chuẩn SQL92, tuy nhiên, ngoài ra còn có các đặc điểm riêng của chúng - mảng của các kiểu dữ liệu nguyên thủy và BLOB. Mảng trong InterBase có thể chứa một tập hợp dữ liệu cùng loại trong một trường. Ví dụ: chúng ta có thể định nghĩa một mảng các giá trị kiểu INTEGER. Mảng có thể có nhiều chiều. Kiểu dữ liệu BLOB là một kiểu dữ liệu mở rộng động, tên của nó thường được giải mã là Binary Large OBject. Cần phải nói rằng BLOB là phát minh của các nhà phát triển InterBase mà sau đó đã lan rộng và ổn định trong tất cả các máy chủ SQL hiện đại.

Cú pháp định nghĩa kiểu dữ liệu

Các kiểu dữ liệu được sử dụng để mô tả các trường trong bảng, các biến trong trigger và stored procedure. Cú pháp chung để định nghĩa tất cả các kiểu dữ liệu có thể có trong InterBase được đưa ra dưới đây.

< datatype> =

{SMALLINT | INTEGER | FLOAT | DOUBLE PRECISION}[ ]

| {DATE | TIME | TIMESTAMP} [ ]

| {DECIMAL | NUMERIC} [( precision [, scale])] [ ]

| {CHAR | CHARACTER | CHARACTER VARYING | VARCHAR} [( int)

[ ] [CHARACTER SET charname]

| {NCHAR | NATIONAL CHARACTER | NATIONAL CHAR}

[VARYING] [( int)] [ ]

| BLOB [SUB_TYPE { int | subtype_name}] [SEGMENT SIZE int]

[CHARACTER SET charname]

| BLOB [(seglen [, subtype])]

Các đặc tính của kiểu dữ liệu như kích thước, độ chính xác và phạm vi các giá trị có thể có được mô tả chi tiết trong bảng 4.1 trong [1., do đó chúng ta sẽ không lặp lại ở đây. Bây giờ chúng ta hãy xem xét ngắn gọn các đặc điểm chính của các kiểu dữ liệu và tập trung vào ứng dụng có thể có của chúng.

Các kiểu số nguyên

SMALLINT và INTEGER thuộc về các kiểu số nguyên. Tôi nên nói rằng SMALLINT đại diện cho một phiên bản hạn chế của INTEGER. Độ dài của nó là 2 byte khác với 4 byte dành cho việc lưu trữ INTEGER. Thông thường bạn không nên tiết kiệm dung lượng đĩa. Trên cơ sở này, tốt hơn là sử dụng kiểu INTEGER để lưu trữ các giá trị số nguyên.

Phạm vi áp dụng của các kiểu số nguyên là rõ ràng: chúng cần thiết cho các trường chỉ chứa số nguyên - để lưu trữ bộ đếm, số, v.v. Thông thường kiểu INTEGER cũng có các trường chứa khóa chính.

Các kiểu dữ liệu thực

Các kiểu FLOAT và DOUBLE PRECISION thuộc về các kiểu thực (chúng còn được gọi là các kiểu số có dấu chấm động). Trước tiên, tôi muốn cảnh báo người đọc về việc sử dụng kiểu FLOAT - độ chính xác của nó không đủ để lưu trữ hầu hết các giá trị phân số. Đặc biệt không nên lưu trữ các giá trị tiền tệ trong đó - trong các biến kiểu FLOAT, lỗi làm tròn xuất hiện rất nhanh và nó có thể gây ngạc nhiên cho kế toán viên khi thực hiện tính toán. Cách tốt nhất để lưu trữ các số có dấu chấm động (ví dụ: trong hệ thống kế toán và hệ thống tính toán khoa học) trong cơ sở dữ liệu là lưu trữ chúng trong kiểu DOUBLE PRECISION.

Bạn nên tính đến rằng trong phương ngữ thứ 3 của InterBase có một cơ chế lưu trữ các kiểu có điểm cố định 64 byte. Cơ chế này được sử dụng để lưu trữ các giá trị tiền tệ. Việc sử dụng các kiểu này cung cấp độ chính xác tốt nhất.

Các kiểu dữ liệu có điểm cố định

NUMERIC và DECIMAL thuộc về các kiểu dữ liệu này. Câu hỏi về sự khác biệt giữa NUMERIC và DECIMAL rất thường được đặt ra. Cả hai kiểu này có dung lượng chữ số giống hệt nhau - từ 1 đến 18 chữ số, độ chính xác giống hệt nhau - từ 0 đến dung lượng chữ số.

Hãy nhớ rằng: dung lượng chữ số là tổng số chữ số, và độ chính xác - là số chữ số sau dấu phẩy.

Điều buồn cười nhất là các kiểu này khác nhau về dung lượng chữ số tối đa theo tài liệu, nhưng thực tế, chúng được triển khai gần như giống nhau và không có sự khác biệt giữa chúng.

Bạn có thể dễ dàng kiểm tra điều này, bằng cách khởi động tiện ích isql và thực hiện chuỗi hành động được đề cập dưới đây. Chúng ta tạo bảng có dạng sau:

SQL> CREATE TABLE test (

CON> Num_field NUMERIC(15,2),

CON> Dec_field DECIMAL(15,2));

Sau đó chúng ta đưa ra lệnh để hiển thị cấu trúc của bảng:

SQL> show tables test;

Và chúng ta thấy như sau

NUM_FIELD NUMERIC(15, 2) Nullable

DEC_FIELD NUMERIC(15, 2) Nullable

Như bạn có thể thấy, InterBase thông báo rằng cả hai cột đã cho đều có kiểu NUMERIC. Lý do của hành vi như vậy nằm trong việc triển khai các kiểu dữ liệu có điểm cố định. Vấn đề là InterBase chỉ có ba cơ chế lưu trữ bất kỳ biểu thức số nguyên nào, và tất cả các kiểu, dù chúng được đặt tên là gì, đều được triển khai theo các biến thể này.

Đây là bảng từ [1., minh họa cách các kiểu số nguyên khác nhau (bảng 1.1) được lưu trữ. Như bạn có thể thấy, việc lưu trữ dữ liệu trong phương ngữ thứ 3 là khác nhau đối với các số có dung lượng chữ số lớn:

Bảng 1.1. Lưu trữ các số có điểm cố định

Dung lượng chữ số Phương ngữ 1 Phương ngữ 3
từ 1 đến 4 SMALLINT cho NUMERIC
INTEGER cho DECIMAL		 SMALLINT
từ 5 đến 9 INTEGER INTEGER
từ 10 đến 18 DOUBLE PRECISION INT64

Bây giờ chúng ta có thể nói chắc chắn sự khác biệt chính giữa các kiểu NUMERIC và DECIMAL là gì: trong trường hợp định nghĩa một trường (hoặc biến) có dung lượng chữ số nhỏ (lên đến bốn), kiểu đầu tiên được lưu trữ dưới dạng số nguyên 2 byte SMALLINT, và kiểu thứ hai - dưới dạng INTEGER 4 byte. Do đó, nếu dung lượng chữ số lớn hơn bốn, các kiểu DECIMAL và NUMERIC sẽ tương đương nhau.

Hãy chú ý đến sự khác biệt trong việc triển khai các kiểu có dung lượng chữ số lớn trong phương ngữ thứ nhất và thứ ba. Trong phương ngữ thứ nhất, số có điểm cố định chuyển từ số nguyên sang số thực, nơi các cơ chế làm tròn được áp dụng. Trong phương ngữ thứ ba, đặc điểm này đã được loại bỏ - các số nguyên lớn thực sự được lưu trữ dưới dạng số nguyên - sử dụng cơ chế INT64 có thể lưu trữ các số 64-bit trong phạm vi +/-2^32. Do đó, tốt hơn là lưu trữ dữ liệu về quỹ tiền tệ trong các cơ sở dữ liệu được tạo bằng phương ngữ thứ 3. Chỉ sử dụng cơ chế INT64 sẽ đảm bảo an toàn cho các khoản tiền nhỏ còn lại.

Các kiểu lưu trữ ngày và giờ

Các kiểu lưu trữ ngày và giờ đã thay đổi trong phiên bản InterBase 6.x và các bản sao của nó so với 4.x và 5.x. Để không bị nhầm lẫn trong mạng lưới lịch sử với các kiểu này, chúng ta sẽ xem xét tình huống trong phiên bản InterBase 6. Sau đó, dựa trên đó, chúng ta sẽ đề cập ngắn gọn những gì đã có trước đó. Điều này được thực hiện cho những người dùng vẫn làm việc với các phiên bản InterBase sớm. Vì vậy, có 3 kiểu trong InterBase 6.x để lưu trữ ngày và giờ - DATE, TIME và TIMESTAMP.

  • Kiểu DATE lưu trữ ngày trong phạm vi một ngày. Phạm vi các giá trị có thể có - từ ngày 1 tháng 1 năm 100 sau Công nguyên đến ngày 29 tháng 2 năm 32768.
  • Kiểu TIME lưu trữ dữ liệu về thời gian trong phạm vi một phần mười nghìn giây. Phạm vi các giá trị có thể có - từ 00:00 sáng đến 23:59.9999 chiều.
  • Kiểu TIMESTAMP đại diện cho sự kết hợp của các kiểu DATE và TIME.

Làm thế nào để làm việc với ngày tháng? Nếu câu hỏi là về công việc ở cấp độ máy chủ trong stored procedure hoặc trigger, mọi thứ khá đơn giản - chúng ta luôn có thể khai báo một biến thuộc loại cần thiết và đặt nó từ các bảng và ngược lại. Tuy nhiên, cần phải truyền dữ liệu từ cơ sở dữ liệu đến ứng dụng và ngược lại. Trong trường hợp này có hai cách tiếp cận: sử dụng các thư viện áp dụng định dạng gốc của ngày InterBase để truy cập các đối tượng của các kiểu này và chuyển đổi định dạng này thành các kiểu ngày/giờ thông thường trong ngôn ngữ (FIBPlus là ví dụ về thư viện như vậy), hoặc sử dụng cơ chế chuyển đổi ngày thành chuỗi, được tích hợp trong InterBase.

Bạn sẽ làm gì nếu cần trích xuất chỉ năm hoặc tháng từ ngày đầy đủ? Bạn sẽ phải sử dụng một nhóm các hàm EXTRACT cho mục đích này (có sẵn trong tất cả các bản sao của InterBase 6.x) cho phép bạn trích xuất chỉ phần cần thiết từ ngày. Các hàm này được sử dụng theo cách sau:

EXTRACT (MONTH FROM DATE_FIELD)

EXTRACT (YEAR FROM DATE_FIELD)

Danh sách đầy đủ các tham số trong hàm EXTRACT như sau: YEAR, MONTH, DAY, HOUR, MINUTE, SECOND, WEEKDAY, YEARDAY. Chức năng của chúng theo tên của chúng, do đó chúng ta sẽ không giải thích chúng ở đây.

Các kiểu dữ liệu lưu trữ văn bản

Có hai kiểu trong InterBase dành cho việc lưu trữ thông tin văn bản - CHAR và VARCHAR. Tên đầy đủ của chúng - CHARACTER và CHARACTER VARYING, tuy nhiên không có lý do gì để sử dụng tên dài - ngay cả lệnh Show tables trong tiện ích isql cũng đưa ra tên viết tắt của các kiểu.

Để định nghĩa một trường hoặc một biến thuộc kiểu ký tự, cần phải chỉ định trong ngoặc sau tên của kiểu một số ký tự sẽ được sử dụng trong đối tượng được định nghĩa, hoặc bỏ qua số ký tự - do đó một trường có độ dài 1 ký tự sẽ được tạo.

CREATE TABLE testCHARLen(

Field1 CHAR(255),

Field2 CHAR);

Khi bảng này được tạo, Field1 sẽ có độ dài 255 ký tự, và Field2 - 1 ký tự.

Các kiểu CHAR và VARCHAR về nhiều mặt tương tự nhau - cả hai có thể chứa tối đa 32768 ký tự, tuy nhiên có một số khác biệt. Mặc dù cả hai kiểu này được lưu trữ trong cơ sở dữ liệu theo cùng một cách, nhưng InterBase làm việc với chúng theo những cách khác nhau. Ví dụ sau đây minh họa điều này:

SQL> create table testCHAR ( c1 char(10), c2 varchar(10));

SQL> insert into testCHAR(c1,c2) values(‘Test’,‘Test’);

SQL> SELECT ‘(’||c1.|’)’, ‘(’||c2.|’)’ from testCHAR;

Kết quả, chúng ta sẽ nhận được như sau:

(Test ) (Test)

Như bạn có thể thấy, sau giá trị ‘Test’, được chọn từ trường c1, có các khoảng trắng. Điều đó có nghĩa là khi chọn dữ liệu từ một trường kiểu CHAR, giá trị trả về được bổ sung các khoảng trắng cho đến độ dài đầy đủ của trường. Thật khó để giả định tại sao hành vi như vậy dẫn đến sự gia tăng đáng kể lưu lượng mạng (tải mạng) lại cần thiết. Trong mọi trường hợp, VARCHAR là một kiểu ký tự được khuyến nghị sử dụng.

Một trong những đặc tính quan trọng nhất của kiểu ký tự là bộ ký tự của nó - CHARACTER SET. Bộ ký tự được định nghĩa cho toàn bộ cơ sở dữ liệu và được sử dụng theo mặc định cho tất cả các trường ký tự nếu nó không được định nghĩa lại một cách rõ ràng khi tạo trường. Để tạo một trường ký tự với chỉ định rõ ràng về bộ ký tự, cần phải thêm mô tả về bộ ký tự trong mô tả của cột (trong các câu lệnh CREATE TABLE hoặc ALTER TABLE). Bộ ký tự WIN1251 thường được sử dụng để hỗ trợ tiếng Nga (nếu bạn muốn biết chi tiết về việc sử dụng tiếng Nga trong InterBase, hãy xem chương “InterBase Russification” (phần 1)). Đây là một ví dụ về bảng chứa một trường ký tự với bộ ký tự WIN1251 được mô tả rõ ràng:

CREATE TABLE TestCHARSET(

Field1 VARCHAR(255),

Field2 VARCHAR(255) CHARACTER SET win1251);

Ở đây Field1 là trường không có chỉ định rõ ràng về bộ ký tự, do đó bộ ký tự được chỉ định khi tạo cơ sở dữ liệu sẽ được sử dụng cho nó. Còn đối với trường Field2 thì rõ ràng là nó sẽ lưu trữ các ký hiệu trong mã hóa WIN1251.

Ngoài việc chỉ định bộ ký tự cho các trường ký tự, bạn cũng có thể chỉ định thứ tự sắp xếp (collation order) để xác định cách các ký hiệu của tập dữ liệu này sẽ được sắp xếp. Đối với tiếng Nga có hai biến thể sắp xếp - WIN1251 và PXW_CYRL. Để biết thêm chi tiết về việc sử dụng COLLATION ORDER, hãy xem chương “InterBase Russification”.

Bạn có thể tìm thấy danh sách đầy đủ các bộ ký tự và COLLATION ORDER áp dụng cho chúng trong tài liệu [1, chương 13..

Chú ý! Theo tài liệu về InterBase 6 có 4 loại ký tự: ngoài các loại dữ liệu đã đề cập ở trên còn có 2 loại nữa - NCHAR và NCHAR VARYING, tuy nhiên cùng tài liệu đó ở phần dưới giải thích rằng hai loại cuối cùng này chính là các loại CHAR và VARCHAR, chỉ khác là bộ ký tự ISO8859.1 được sử dụng theo mặc định. Điều đó có nghĩa là thực tế việc sử dụng kiểu giả NCHAR tương đương với việc áp dụng CHAR DEFAULT CHARACTER SET ISO8859.1. Tương tự cho NCHAR VARYING, chỉ khác là thay vì CHAR thì VARCHAR được sử dụng. Rõ ràng việc áp dụng các kiểu giả này dành cho người dùng ở Tây Âu và Hoa Kỳ, nơi bộ ký tự ISO8859.1 được tạo ra để hỗ trợ các ngôn ngữ.

Kiểu dữ liệu BLOB

Kiểu dữ liệu BLOB được dùng để lưu trữ một lượng lớn dữ liệu có kích thước thay đổi. Kiểu BLOB cho phép lưu trữ dữ liệu không thể đặt trong các trường thuộc kiểu khác - ví dụ như hình ảnh, tệp nhạc, đoạn video, v.v. Các yêu cầu để định nghĩa trường đơn giản nhất thuộc kiểu BLOB trong bảng cũng giống như các yêu cầu để định nghĩa một trường thuộc bất kỳ kiểu cơ bản nào:

CREATE TABLE testBLOB(

myBlobField BLOB);

Kết quả là trường myBlobField, trong đó có thể lưu trữ dữ liệu có kích thước đáng kể, sẽ được tạo ra. Mặc dù thực tế là các trường BLOB không khác gì các trường khác về cách định nghĩa, nhưng cách triển khai của chúng bên trong cơ sở dữ liệu lại rất khác. Các trường không phải BLOB được đặt trên trang dữ liệu (xem chương “InterBase database structure” (phần 4)) gần nhau, còn trong trường hợp chỉ có định danh BLOB được lưu trên trang dữ liệu thì bản thân BLOB được phân bổ trên trang đặc biệt. Cấu trúc dữ liệu như vậy cho phép lưu trữ dữ liệu có kích thước không cố định.

Kiểu BLOB có khả năng định nghĩa một tập hợp nhiều kiểu con (subtypes) và các thủ tục đặc biệt gọi là bộ lọc (BLOB filters) để làm việc với các kiểu con này. Có một số kiểu con BLOB được xác định trước được tích hợp sẵn trong InterBase. Tất cả các kiểu con này có số không âm, ví dụ kiểu con 0 - dữ liệu kiểu không xác định, kiểu con 1 - văn bản, kiểu con 2 - BLR (Binary Language Representation, xem bảng chú giải và chương “InterBase database structure”), v.v. Người dùng cũng có thể định nghĩa các kiểu con BLOB có giá trị âm. Bộ lọc có thể được áp dụng cho mọi kiểu. Nó sẽ chuyển đổi một trường từ kiểu con này sang kiểu con khác.

Cần lưu ý rằng việc sử dụng các trường BLOB thường là một giải pháp thay thế cho việc lưu trữ các tệp bên ngoài so với cơ sở dữ liệu. Còn đối với các bộ lọc BLOB, chúng được sử dụng khá hiếm do hướng tới một loại nhiệm vụ hẹp.

Mảng

DBMS InterBase là một trong những hệ quản trị đầu tiên có mảng. Hỗ trợ mảng trong cơ sở dữ liệu là sự mở rộng của mô hình quan hệ truyền thống. Sự hiện diện của mảng cho phép đơn giản hóa việc làm việc với các tập hợp dữ liệu cùng một kiểu.

Mảng là một tập hợp các giá trị cùng một kiểu, có tên chung và cho phép truy cập đến bất kỳ phần tử nào của mảng theo số của nó. Mảng trong InterBase có thể là một chiều và nhiều chiều.

Để tạo một trường mảng số INTEGER trong bảng, cần viết một cái gì đó như sau:

CREATE TABLE test(

myOneDimArray INTEGER[12.,

myTwoDimArray INTEGER[5,4.,

myThreeDimArray INTEGER[2,10,8.);

Như vậy, ba trường kiểu mảng sẽ được tạo ra: myOneDimArray - trường chứa mảng một chiều có độ dài 12 số, myTwoDimArray - trường chứa mảng hai chiều (ma trận) - 5х4 số Integer, và myThreeDimArray - trường chứa mảng ba chiều 2х10х8. Cần lưu ý rằng với định nghĩa như vậy, các phần tử của mảng được đánh số bắt đầu từ “một”, tức là phần tử đầu tiên có số 1, phần tử thứ hai có số 2, v.v. Nếu ai đó muốn tự đặt ranh giới của mảng, ví dụ từ 0 đến 5, thì cần chỉ định định nghĩa trường theo cách sau:

myArray INTEGER[0:5.

Mảng được triển khai dựa trên các trường kiểu BLOB, do đó bạn không cần lo lắng rằng mảng nhiều chiều sẽ “làm bẩn” bảng của bạn với một lượng lớn dữ liệu: InterBase sẽ phân bổ gọn gàng dữ liệu của mảng trên các trang riêng biệt để tối ưu hóa các thao tác nhập/xuất trên các trường này. Làm thế nào để sử dụng mảng? Chúng cung cấp một cơ chế thuận tiện để lưu trữ các đối tượng cùng loại. Tuy nhiên trong 80% trường hợp, thay vì sử dụng mảng, các nhà phát triển thích lưu trữ dữ liệu nhiều bản ghi trong các bảng chi tiết (detail tables), do đó mảng không được sử dụng thường xuyên trong các ứng dụng khách của DBMS InterBase. Điều này xảy ra vì các thư viện truy cập đi kèm với Delphi và C++ Builder như BDE và IBX không thể làm việc với mảng. Theo tài liệu về InterBase, có thể làm việc với mảng bằng bộ tiền xử lý gpre, tuy nhiên đây không phải là cách thuận tiện nhất cho nhà phát triển Delphi/C++ Builder. May mắn thay, trong thư viện FIBPlus có hỗ trợ các trường-mảng trong InterBase. Bạn có thể đọc chi tiết về điều này trong chương “FIBPlus special abilities”. Thư viện khách IBProvider cho phép tạo các ứng dụng khách cho InterBase bằng các công cụ phát triển của công ty Microsoft cũng hỗ trợ làm việc với mảng (xem chương “Development of client applications of InterBase DBMS using the technology of Microsoft OLE DB” (phần 3)).

Kết luận

Cần lưu ý rằng không thể nói về các kiểu dữ liệu mà không đề cập đến các vấn đề phía trước, vì chúng thâm nhập vào tất cả các lĩnh vực chính liên quan đến việc phát triển các ứng dụng cơ sở dữ liệu. Do đó, khi đọc cuốn sách này, tốt hơn là sử dụng chương này như một tài liệu tham khảo nhanh mà bạn có thể tra cứu mỗi khi cần làm mới kiến thức cơ bản về InterBase.