BÀI GIẢNG Các khái niệm về cơ sở dữ liệu
Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (2.03 MB, 56 trang )
Phần
I
Các khái niệm về
cơ sở dữ liệu
Chương
Căn bản về
cơ sở dữ liệu
1
3
4
Nhập môn Cơ sở dữ liệu
Các khái niệm và kỹ năng chính
●● Các thuộc tính của cơ sở dữ liệu
●● Các mô hình cơ sở dữ liệu thông dụng
●● Tóm lược lịch sử cơ sở dữ liệu
●● Tại sao phải tập trung vào mô hình quan hệ?
C
hương này giới thiệu các khái niệm căn bản và những định nghĩa liên quan đến cơ sở dữ
liệu, bao gồm các thuộc tính của cơ sở dữ liệu nói chung, các mô hình cơ sở dữ liệu thông
dụng, tóm lược lịch sử cơ sở dữ liệu, nguyên nhân tại sao phải tập trung vào mô hình cơ sở dữ
liệu quan hệ.
Các thuộc tính của cơ sở dữ liệu
Cơ sở dữ liệu (database) là tập hợp các thành phần dữ liệu có liên quan lẫn nhau, được quản
lý dưới dạng một đơn vị duy nhất. Định nghĩa trên tương đối rộng, bởi có sự khác biệt đáng kể
giữa các cơ sở dữ liệu của các nhà sản xuất phần mềm cung cấp các hệ thống cơ sở dữ liệu. Chẳng
hạn, Microsoft Access đặt toàn bộ cơ sở dữ liệu trong một file dữ liệu, do đó, một cơ sở dữ liệu
Access có thể được định nghĩa như một file chứa các thành phần dữ liệu. Công ty Oracle định
nghĩa cơ sở dữ liệu của họ như tập các file vật lý được quản lý bởi một thể hiện của phần mềm cơ
sở dữ liệu của Oracle. Thể hiện (instance) là một phiên bản của phần mềm cơ sở dữ liệu đang chạy
trong bộ nhớ. Microsoft SQL Server và Sybase Adaptive Server Enterprise (ASE) định nghĩa một
cơ sở dữ liệu là tập hợp các thành phần dữ liệu có cùng chủ sở hữu, và nhiều cơ sở dữ liệu được
quản trị bởi một thể hiện của một phần mềm quản trị cơ sở dữ liệu. Định nghĩa này có thể gây hiểu
lầm đôi chút nếu bạn làm việc với nhiều sản phẩm khác nhau, vì theo định nghĩa của Microsoft
SQL Server và Sybase ASE, một cơ sở dữ liệu lại chính là một schema (lược đồ) như định nghĩa
của công ty Oracle.
Đối tượng cơ sở dữ liệu (database object) là một cấu trúc dữ liệu được đặt tên và lưu trữ
trong cơ sở dữ liệu. Các kiểu đối tượng cơ sở dữ liệu cụ thể được hỗ trợ trong một cơ sở dữ liệu
thường khác nhau giữa các nhà cung cấp và giữa các mô hình cơ sở dữ liệu. Mô hình cơ sở dữ liệu
(database model) là cách cơ sở dữ liệu tổ chức dữ liệu của nó để mô phỏng thế giới thực. Những
mô hình cơ sở dữ liệu phổ biến nhất được trình bày trong mục “Các mô hình cơ sở dữ liệu thông
dụng” ở cuối chương này.
File là tập hợp các bản ghi có liên quan được lưu trữ như một đơn vị bởi hệ điều hành. Thật
không may, định nghĩa của file và cơ sở dữ liệu khá giống nhau, vậy làm sao để phân biệt chúng?
Một số nhà cung cấp hệ điều hành Unix gọi các file mật khẩu của họ là các “cơ sở dữ liệu”, song
những chuyên gia về cơ sở dữ liệu đã nhanh chóng chỉ ra rằng, thực tế chúng không thực sự là
Chương 1: Căn bản về cơ sở dữ liệu
các cơ sở dữ liệu. Rõ ràng, chúng ta cần xem xét tỉ mỉ những định nghĩa này. Để hiểu rõ các định
nghĩa, chúng ta cần tìm hiểu về các đặc trưng và thuộc tính riêng có trong cơ sở dữ liệu mà không
thể tìm thấy trong những file thông thường. Những đặc trưng và thuộc tính này bao gồm:
●● Quản lý bởi một hệ quản trị cơ sở dữ liệu (DBMS).
●● Các lớp trừu tượng hóa dữ liệu.
●● Độc lập dữ liệu vật lý.
●● Độc lập dữ liệu lôgíc.
Những đặc trưng này sẽ được thảo luận trong các phần dưới đây.
Hệ quản trị cơ sở dữ liệu
Hệ quản trị cơ sở dữ liệu (database management system - DBMS) là một phần mềm được cung
ứng bởi nhà cung cấp cơ sở dữ liệu. Các sản phẩm phần mềm như Microsoft Access, Oracle,
Microsoft SQL Server, Sybase ASE, DB2, Ingres và MySQL đều là các hệ quản trị cơ sở dữ liệu.
Bạn có thể thấy hơi khó hiểu là tại sao lại dùng chữ cái viết tắt DBMS mà không phải DMS. Hãy
nhớ, ban đầu, thuật ngữ cơ sở dữ liệu (database) được viết bằng hai từ và dần dần được quy ước
trở thành một từ đơn.
DBMS cung cấp tất cả các dịch vụ cơ bản cần thiết để tổ chức và duy trì cơ sở dữ liệu,
bao gồm:
●● Di chuyển dữ liệu từ cơ sở dữ liệu ra các file dữ liệu vật lý và từ các file dữ liệu vật lý vào cơ
sở dữ liệu khi cần thiết.
●● Quản lý việc truy cập dữ liệu đồng thời bởi nhiều người dùng, bao gồm việc ngăn các cập nhật
tại cùng một thời điểm xung đột lẫn nhau.
●● Quản lý các giao dịch (transaction) để những thay đổi tới cơ sở dữ liệu của giao dịch phải
được thực hiện một cách trọn vẹn như một đơn vị công việc duy nhất hoặc không thực hiện gì
cả. Nói cách khác, nếu giao dịch thành công, tất cả các thay đổi cơ sở dữ liệu được giao dịch
tạo ra sẽ được lưu vào cơ sở dữ liệu; ngược lại, nếu giao dịch thất bại, sẽ không có bất cứ thay
đổi nào được lưu vào cơ sở dữ liệu.
●● Hỗ trợ ngôn ngữ truy vấn (query language) - một hệ thống lệnh do người dùng cơ sở dữ liệu
sử dụng để truy xuất dữ liệu từ cơ sở dữ liệu.
●● Cho phép sao lưu dự phòng cơ sở dữ liệu và phục hồi sau sự cố.
●● Cung cấp cơ chế bảo mật để ngăn các truy cập và chỉnh sửa dữ liệu không được cấp phép.
5
6
Nhập môn Cơ sở dữ liệu
Hỏi chuyên gia
Câu hỏi:
Tôi nghe nói có thuật ngữ “ngân hàng dữ liệu”. Điểm khác nhau giữa ngân
hàng dữ liệu và cơ sở dữ liệu là gì?
Trả lời:
Ngân hàng dữ liệu và cơ sở dữ liệu là một. Ngân hàng dữ liệu (data bank) là thuật
ngữ cũ, được các nhà khoa học phát triển hệ thống cơ sở dữ liệu ban đầu sử dụng.
Thực tế, thuật ngữ ngân hàng dữ liệu vẫn đang được sử dụng trong một số ngôn
ngữ của loài người, chẳng hạn trong tiếng Bồ Đào Nha, cụm từ banco de dados
có nghĩa là ngân hàng dữ liệu.
Các lớp trừu tượng hóa dữ liệu
Một đặc trưng của cơ sở dữ liệu là khả năng cung cấp cho nhiều người dùng những cách quan sát
khác nhau đối với cùng một dữ liệu được lưu trữ trong CSDL, phù hợp với nhu cầu riêng của họ.
Những cách quan sát dữ liệu đó được gọi là các view người dùng (user view). Trong trường hợp
này, người dùng có thể là một người, hoặc ứng dụng truy cập vào cơ sở dữ liệu với mục đích lưu
trữ và/hoặc lấy dữ liệu. Ứng dụng (application) là tập các chương trình máy tính được thiết kế để
giải quyết một vấn đề nghiệp vụ cụ thể, chẳng hạn như hệ thống nhập đơn đặt hàng, hệ thống xử
lý sổ lương, hay hệ thống kế toán.
Khi sử dụng ứng dụng bảng tính điện tử như Microsoft Excel, tất cả người dùng cần chia sẻ
một view dữ liệu chung, và view đó phải khớp với cách dữ liệu được lưu trữ trong file dữ liệu.
Nếu một người dùng ẩn vài cột trong một trang tính, sắp xếp lại thứ tự các dòng và lưu trang tính
lại, thì khi mở trang tính, người dùng tiếp theo sẽ nhìn thấy dữ liệu đúng như những gì mà người
dùng trước đã lưu. Một giải pháp khác là mỗi người dùng sẽ lưu bản sao của họ trong một file vật
lý riêng, nhưng khi một người dùng tiến hành chỉnh sửa, những người dùng khác sẽ không nhận
được các cập nhật mới này. Với cùng một dữ liệu cơ sở, các hệ thống cơ sở dữ liệu cung cấp cho
người dùng các view để quan sát dữ liệu ở các góc độ khác nhau. Các view này có thể được điều
chỉnh để phù hợp với nhu cầu của mỗi người dùng, bất kể chúng đều bắt nguồn từ cùng một bản
sao của dữ liệu được lưu trữ. Vì các view không lưu trữ dữ liệu thực, nên chúng tự động phản ánh
bất kỳ thay đổi nào đến các đối tượng cơ sở dữ liệu nằm bên dưới. Quá trình này được thực hiện
thông qua các lớp trừu tượng (layer of abstraction), được mô phỏng ở Hình 1-1.
Kiến trúc trong Hình 1-1 được ANSI/SPARC (Viện Tiêu chuẩn Quốc gia Hoa Kỳ/Ủy ban
Quy hoạch và xét duyệt các tiêu chuẩn) phát triển lần đầu vào những năm 1970. Nó nhanh chóng
trở thành nền tảng cho các nỗ lực phát triển và nghiên cứu cơ sở dữ liệu. Hầu hết DBMS hiện đại
đều tuân theo kiến trúc này, bao gồm ba lớp chính: Lớp vật lý, lớp lôgíc và lớp ngoài. Kiến trúc
ban đầu còn bao gồm lớp khái niệm đã bị loại bỏ do không có nhà cung cấp cơ sở dữ liệu hiện đại
nào sử dụng lớp này.
Chương 1: Căn bản về cơ sở dữ liệu
Lớp ngoài
View 1
View 2
View 3
Độc lập
dữ liệu lôgíc
Schema nội
(Schema lôgíc)
Lớp lôgíc
File cơ sở
dữ liệu
File cơ sở
dữ liệu
File cơ sở
dữ liệu
File cơ sở
dữ liệu
Lớp vật lý
File cơ sở
dữ liệu
Độc lập
dữ liệu vật lý
Hình 1-1 Các lớp cơ sở dữ liệu trừu tượng.
Lớp vật lý
Lớp vật lý (physical layer) bao gồm các file dữ liệu chứa toàn bộ dữ liệu của cơ sở dữ liệu.
Gần như tất cả hệ quản trị cơ sở dữ liệu hiện đại đều cho phép lưu trữ cơ sở dữ liệu trong nhiều
file dữ liệu và mỗi file dữ liệu có thể trải trên nhiều ổ cứng vật lý. Với cách sắp xếp như vậy, các ổ
cứng có thể làm việc song song để đạt được hiệu suất tối đa. Một ngoại lệ đáng chú ý trong những
hệ quản trị cơ sở dữ liệu được nêu ra ở các ví dụ của cuốn sách là Microsoft Access. Microsoft
Access lưu toàn bộ cơ sở dữ liệu trong một file vật lý duy nhất. Cách sắp xếp này đơn giản hóa
việc sử dụng cơ sở dữ liệu trên hệ thống máy tính cá nhân một người dùng, nhưng lại làm hạn chế
khả năng đáp ứng của DBMS trong việc phục vụ cùng một lúc nhiều người dùng cơ sở dữ liệu. Vì
vậy, đây không phải là giải pháp phù hợp đối với hệ thống của các doanh nghiệp lớn.
Thực tế, Microsoft Access không được thiết kế để trở thành một DBMS mức doanh nghiệp
mạnh mẽ. Chúng ta đề cập tới Microsoft Access trong nội dung của cuốn sách không phải vì sản
phẩm này cạnh tranh với Oracle hay SQL Server, mà bởi Microsoft Access là ví dụ hay về một
DBMS cá nhân với giao diện người dùng cho phép nghiên cứu các khái niệm cơ sở dữ liệu trở
nên dễ dàng, thú vị hơn.
Người dùng cơ sở dữ liệu không nhất thiết phải hiểu rõ cách dữ liệu được lưu trữ thực tế
như thế nào trong file dữ liệu, hay thậm chí các file dữ liệu nào chứa những thành phần dữ liệu
liên quan. Trong hầu hết mọi tổ chức, chuyên gia kỹ thuật được coi là quản trị viên cơ sở dữ liệu
(database administrator - DBA) có trách nhiệm cài đặt, cấu hình phần mềm cơ sở dữ liệu cũng
7
8
Nhập môn Cơ sở dữ liệu
như file dữ liệu, giúp người dùng có thể dễ dàng tiếp cận cơ sở dữ liệu. Cùng với hệ điều hành
của máy tính, DBMS quản lý file dữ liệu một cách tự động, bao gồm các hoạt động mở, đóng,
đọc và ghi file. Khi sử dụng cơ sở dữ liệu, người dùng không nhất thiết phải thao tác trực tiếp với
các file dữ liệu vật lý. Trong khi đó, khi làm việc với các phần mềm bảng tính và xử lý văn bản,
người dùng cần lưu các tài liệu một cách rõ ràng, xác định cụ thể tên file và vị trí lưu trữ. Nhiều
DBMS chạy trên máy tính cá nhân là trường hợp ngoại lệ, vì người dùng được yêu cầu phải tìm
và mở một file vật lý trong quá trình truy cập vào cơ sở dữ liệu. Ngược lại, đối với những DBMS
mức doanh nghiệp (như Oracle, Sybase ASE, Microsoft SQL Server và MySQL), các file vật lý
được quản lý một cách tự động, do đó, khi sử dụng cơ sở dữ liệu, người dùng không bao giờ cần
biết tới chúng.
Lớp lôgíc
Lớp lôgíc (logical layer) hay mô hình lôgíc (logical model) là lớp đầu tiên trong hai lớp trừu
tượng của cơ sở dữ liệu: Lớp vật lý tồn tại thực sự trong các file của hệ điều hành, trong khi lớp
lôgíc chỉ tồn tại như cấu trúc dữ liệu trừu tượng được tạo thành từ lớp vật lý khi cần thiết. DBMS
biến đổi dữ liệu trong các file dữ liệu thành một cấu trúc chung. Đôi khi, lớp này được gọi là
schema, thuật ngữ chỉ một tập hợp bao gồm toàn bộ các thành phần dữ liệu được lưu trữ trong một
cơ sở dữ liệu cụ thể, hoặc thuộc về một người dùng cơ sở dữ liệu nào đó. Tùy thuộc vào DBMS cụ
thể, lớp này có thể chứa tập hợp các bảng hai chiều, một cấu trúc phân cấp tương tự như sơ đồ tổ
chức của một công ty hay vài cấu trúc khác. Trong mục “Các mô hình cơ sở dữ liệu thông dụng”
ở phần sau của chương sẽ mô tả chi tiết hơn về các cấu trúc này.
Lớp bên ngoài
Lớp ngoài (external layer) hay mô hình bên ngoài (external model) là lớp trừu tượng thứ hai trong
cơ sở dữ liệu. Lớp này bao gồm các view người dùng được trình bày ở phần trên, được gọi chung
là subschema (schema con). Ở lớp này, người dùng cơ sở dữ liệu (các chương trình ứng dụng cũng
như người dùng thực sự) truy cập vào cơ sở dữ liệu sẽ kết nối và gửi các truy vấn tới chúng. Lý
tưởng nhất là chỉ có DBA mới có thể làm việc với các lớp vật lý và lôgíc. DBMS kiểm soát việc
chuyển đổi các thành phần được chọn từ một hoặc nhiều cấu trúc dữ liệu ở lớp lôgíc thành từng
view người dùng. View người dùng ở lớp này có thể được định nghĩa trước, đồng thời được lưu
trữ trong cơ sở dữ liệu để tái sử dụng, hoặc có thể là thành phần tạm thời được DBMS tạo ra, nhằm
lưu kết quả của một truy vấn ad-hoc tới cơ sở dữ liệu đến khi người dùng không sử dụng nữa. Truy
vấn ad-hoc (hay còn gọi là truy vấn tức thời, truy vấn phi chuẩn tắc), là truy vấn không được lập
kế hoạch cẩn thận và không được tái sử dụng. View sẽ được trình bày chi tiết hơn ở Chương 2.
Độc lập dữ liệu vật lý
Khả năng thay đổi cấu trúc file vật lý của cơ sở dữ liệu mà không làm gián đoạn người dùng và
các quá trình đang diễn ra được gọi là độc lập dữ liệu vật lý (physical data independence). Như đã
thấy ở Hình 1-1, ranh giới phân cách giữa lớp vật lý với lớp lôgíc tạo ra sự độc lập dữ liệu vật lý
trong một DBMS. Bạn nên hiểu, độc lập dữ liệu vật lý không phải là thuộc tính “có hay không”,
mà là đặc tính cho thấy DBMS này có thể có ít tính độc lập dữ liệu hơn so với DBMS khác. Thước
Chương 1: Căn bản về cơ sở dữ liệu
đo cho tính độc lập dữ liệu vật lý, đôi khi còn được gọi là mức độ độc lập dữ liệu vật lý, là có thể
tạo ra bao nhiêu thay đổi trong hệ thống file mà không gây ảnh hưởng tới lớp lôgíc. Khi các hệ
thống chưa cung cấp khả năng độc lập dữ liệu, thậm chí một thay đổi nhỏ tới cách lưu trữ dữ liệu
cũng yêu cầu bộ phận lập trình phải thay đổi mọi chương trình máy tính sử dụng dữ liệu, một công
việc tốn kém và ngốn nhiều thời gian.
Tất cả hệ thống máy tính hiện đại đều có một số mức độ độc lập dữ liệu vật lý. Chẳng hạn,
nếu được sao chép từ ổ cứng tới ổ đĩa mềm hay ổ lưu trữ USB, bảng tính trên máy tính cá nhân
vẫn tiếp tục làm việc chính xác. Sự khác nhau đáng kể giữa hiệu năng (tốc độ) của các thiết bị này
không quan trọng, vấn đề nằm ở chỗ, các thiết bị này có cấu trúc vật lý hoàn toàn khác nhau, hệ
điều hành trên máy tính cá nhân sẽ tự động kiểm soát những khác biệt đó, đồng thời chuyển dữ
liệu trong file cho ứng dụng (trong ví dụ này là chương trình bảng tính, chẳng hạn như Microsoft
Excel), và cuối cùng trình bày với người dùng theo cùng một cách thức. Tuy nhiên, đối với hầu hết
các hệ thống cá nhân, người dùng phải ghi nhớ vị trí đã lưu file để có thể dễ dàng tìm thấy khi cần.
DBMS mở rộng mạnh mẽ về tính độc lập dữ liệu vật lý được hệ thống máy tính cung cấp.
DBMS cho phép người dùng cơ sở dữ liệu truy cập tới các đối tượng (object) cơ sở dữ liệu
(chẳng hạn, các bảng trong một DBMS quan hệ) mà không cần tham chiếu tới các file dữ liệu
vật lý. Catalog trong DBMS lưu trữ định nghĩa đối tượng và theo dõi nơi lưu trữ vật lý của các đối
tượng. Sau đây là một số ví dụ về những thay đổi vật lý thể được thực hiện theo kiểu độc lập dữ liệu:
●● Di chuyển một file cơ sở dữ liệu từ thiết bị này sang thiết bị khác hay từ thư mục này sang
thư mục khác.
●● Tách hay gộp các file dữ liệu của cơ sở dữ liệu.
●● Đổi tên file dữ liệu của cơ sở dữ liệu.
●● Di chuyển một đối tượng cơ sở dữ liệu từ file dữ liệu này sang file dữ liệu khác.
●● Thêm một đối tượng hay một file dữ liệu mới vào cơ sở dữ liệu.
Lưu ý, chúng ta không đề cập tới việc xóa bất cứ thứ gì ở đây. Rõ ràng, nếu bạn xóa một đối tượng
cơ sở dữ liệu sẽ khiến việc sử dụng đối tượng đó thất bại. Tuy nhiên, mọi thứ khác sẽ không bị ảnh
hưởng, ngoại trừ tính sẵn sàng của cơ sở dữ liệu hay dịch vụ bị ảnh hưởng vì một số DBMS sẽ yêu
cầu cơ sở dữ liệu hay dịch vụ DBMS ngừng lại trong lúc thực hiện một thay đổi lớp vật lý nào đó.
Độc lập dữ liệu lôgíc
Khả năng tạo ra các thay đổi tới lớp lôgíc mà không làm gián đoạn người dùng hiện tại và các quá
trình đang diễn ra được gọi là độc lập dữ liệu lôgíc (logical data independence). Hình 1-1 cho
thấy ranh giới giữa lớp lôgíc và lớp ngoài tạo ra tính độc lập dữ liệu lôgíc. Tương tự như độc lập
dữ liệu vật lý, độc lập dữ liệu lôgíc cũng có các mức độ khác nhau. Điều quan trọng bạn nên hiểu
là hầu hết thay đổi lôgíc cũng liên quan đến thay đổi vật lý. Chẳng hạn, bạn không thể thêm mới
đối tượng cơ sở dữ liệu (ví dụ, một bảng trong một DBMS quan hệ) mà không lưu trữ vật lý dữ
liệu ở vị trí nào đó; do vậy, sẽ có một thay đổi tương ứng được tạo ra ở lớp vật lý. Ngoài ra, việc
xóa các đối tượng trong lớp lôgíc sẽ khiến mọi thứ đang sử dụng những đối tượng đó thất bại,
nhưng không gây ảnh hưởng nào khác.
9
10
Nhập môn Cơ sở dữ liệu
Sau đây là một số ví dụ về thay đổi an toàn ở lớp lôgíc nhờ tính độc lập dữ liệu lôgíc:
●● Thêm một đối tượng cơ sở dữ liệu mới.
●● Thêm các thành phần dữ liệu vào một đối tượng có sẵn.
●● Khi cần thực hiện một thay đổi ở lớp lôgíc (chẳng hạn như kết hợp hay tách những đối tượng
có sẵn), trong trường hợp này có thể tạo view ở mô hình ngoài để thay thế (các xử lý thông qua
view thay thế cũng cho kết quả giống như xử lý trực tiếp với đối tượng ban đầu ở lớp lôgíc).
Các mô hình cơ sở dữ liệu thông dụng
Một mô hình cơ sở dữ liệu cơ bản là kiến trúc DBMS sử dụng để lưu các đối tượng trong cơ sở
dữ liệu và liên kết chúng với nhau. Các mô hình cơ sở dữ liệu thông dụng nhất sau đây được trình
bày lần lượt theo thứ tự phát triển. Phần tiếp theo sẽ trình bày tóm lược lịch sử của cơ sở dữ liệu
để giúp sắp xếp mọi thứ theo trật tự thời gian.
File phẳng
File phẳng (flat file) là file hệ điều hành “thông thường”, tại đó, các bản ghi nằm trong file không
chứa thông tin về cấu trúc file hay bất kỳ mối quan hệ nào giữa các bản ghi để cung cấp cho ứng
dụng sử dụng file. Các ứng dụng sử dụng file hay người xem nội dung file cần nắm rõ thông tin
về cấu trúc hay ý nghĩa của dữ liệu trong file. Về cơ bản, file phẳng không phải là các cơ sở dữ
liệu vì chúng không đáp ứng được các tiêu chí đã đề ra ở phần trước. Tuy nhiên, có hai điều quan
trọng bạn cần hiểu rõ ở đây. Trước hết, file phẳng thường được dùng để lưu trữ thông tin cơ sở dữ
liệu. Trong trường hợp này, hệ điều hành vẫn không hiểu được nội dung và cấu trúc của các file,
nhưng DBMS chứa siêu dữ liệu (metadata) cho phép chuyển giữa file phẳng trong lớp vật lý và
các cấu trúc cơ sở dữ liệu nằm trong lớp lôgíc. Theo nghĩa đen, siêu dữ liệu có nghĩa là “dữ liệu về
dữ liệu”, là thuật ngữ được sử dụng khi đề cập tới những thông tin mà cơ sở dữ liệu lưu trữ trong
catalog để mô tả dữ liệu được lưu trong cơ sở dữ liệu và mối quan hệ giữa các dữ liệu. Chẳng hạn,
siêu dữ liệu về một khách hàng có thể bao gồm tất cả các thành phần dữ liệu được thu thập về
khách hàng (như tên, địa chỉ và trạng thái tài khoản) cùng với độ dài, giá trị dữ liệu tối thiểu, tối
đa và mô tả ngắn gọn về từng thành phần dữ liệu. Thứ hai, các file phẳng tồn tại trước khi có cơ
sở dữ liệu, và các hệ thống cơ sở dữ liệu sơ khai đã được phát triển từ hệ thống file phẳng.
Trên Hình 1-2 là một hệ thống file phẳng mẫu, một phần nhỏ dữ liệu của công ty giả tưởng
tên là Northwind Traders, nhà cung cấp các mặt hàng thực phẩm đa quốc gia (và là một cơ sở dữ
liệu mẫu của Microsoft). Nhớ rằng, các tiêu đề cột (Customer ID, Company Name…) được đưa
vào chỉ với mục đích minh họa - chỉ có các bản ghi dữ liệu được lưu trữ trong những file thực sự.
Dữ liệu khách hàng được lưu trữ trong file Customer, ở đó, mỗi bản ghi đại diện cho một khách
hàng của Northwind. Mỗi khách hàng của Northwind có một bản ghi trong file Employee, và mỗi
sản phẩm được Northwind bán ra có một bản ghi trong file Product. Dữ liệu về đơn đặt hàng (đơn
đặt hàng của khách hàng với Northwind) được lưu trữ trong hai file phẳng khác. File Order chứa
một bản ghi của mỗi đơn đặt hàng từ khách hàng, lưu dữ liệu về đơn đặt hàng, như ID của khách
hàng và tên của nhân viên đã nhận đơn đặt hàng từ khách. File Order Detail chứa các dòng chi tiết
Chương 1: Căn bản về cơ sở dữ liệu
của đơn đặt hàng, mỗi bản ghi cho một dòng chi tiết (một đơn đặt hàng có thể chứa nhiều dòng
chi tiết, mỗi dòng chi tiết là một sản phẩm được đặt hàng). Mỗi dòng chi tiết gồm các dữ liệu như
đơn giá và số lượng.
Chương trình ứng dụng (application program) là một đơn vị lôgíc chương trình máy tính,
thực hiện một chức năng nào đó trong hệ thống ứng dụng. Northwind Traders có một chương trình
ứng dụng in ra danh sách tất cả các đơn đặt hàng. Ứng dụng phải kết nối các dữ liệu giữa năm file
bằng cách đọc một đơn đặt hàng và thực hiện những bước sau:
1. Sử dụng ID của khách hàng (Customer ID) để tìm tên của họ trong file Customer.
2. Sử dụng ID của nhân viên (Employee ID) để tìm tên của nhân viên liên quan trong file Employee.
3. Sử dụng ID của đơn đặt hàng (Order ID) để tìm các dòng chi tiết tương ứng trong file Order Detail.
4. Đối với mỗi dòng chi tiết, sử dụng ID của sản phẩm (Product ID) để tìm tên sản phẩm tương
ứng trong file Product.
Việc này có vẻ khá phức tạp khi chúng ta đang cố gắng in ra một danh sách đơn giản tất cả các đơn
đặt hàng. Dù vậy, đây vẫn là thiết kế dữ liệu tốt nhất có thể cho một hệ thống file phẳng.
Giải pháp thiết kế khác là kết hợp tất cả các thông tin vào một file dữ liệu đơn với toàn bộ
thông tin về khách hàng, nhân viên và đơn đặt hàng vào một bản ghi duy nhất đối với mỗi đơn đặt
hàng. Mặc dù quá trình này giúp đơn giản hóa việc nhận dữ liệu ở mức tối đa, nhưng bạn thấy,
File Customer
Customer ID
Company Name
Contact First Name
Contact Last Name
Job Title
City
State
6
Company F
Francisco
Pérez-Olaeta
Purchasing Manager
Milwaukee
WI
26
Company Z
Run
Liu
Accounting Assistant
Miami
FL
File Employee
Employee ID
First Name
Last Name
Title
2
Andrew
Cencini
Vice President, Sales
5
Steven
Thrope
Sales Manager
9
Anne
Hellung-Larsen
Sales Representative
File Product
Product ID
Product Code
Product Name
Category
Quantity Per Unit
List Price
5
NWTO-5
Northwind Traders Olive Oil
Oil
36 boxes
$21.35
7
NWTDFN-7
Northwind Traders Dried Pears
Dried Fruit & Nuts
12 - 1 lb pkgs
$30.00
40
NWTCM-40
Northwind Traders Crab Meat
Canned Meat
24 - 4 oz tins
$18.40
41
NWTSO-41
Northwind Traders Clam Chowder
Soups
12 - 12 oz cans
48
NWTCA-48
Northwind Traders Chocolate
Candy
10 pkgs
$12.75
51
NWTDFN-51
Northwind Traders Dried Apples
Dried Fruit & Nuts
50 - 300 g pkgs
$53.00
$9.65
11
12
Nhập môn Cơ sở dữ liệu
File Order
Order ID
Customer ID
Employee ID
Order Date
Shipped Date
Shipping Fee
51
26
9
4/5/2006
4/5/2006
$60.00
56
6
2
4/3/2006
4/3/2006
$0.00
79
6
2
6/23/2006
6/23/2006
$0.00
File Order Detail
Order ID
Product ID
Unit Price
Quantity
51
5
$21.35
15
51
41
$9.65
21
51
40
$18.40
2
56
48
$12.75
20
79
7
$30.00
14
79
51
$53.00
8
Hình 1-2 Hệ thống đặt hàng trên file phẳng.
toàn bộ dữ liệu khách hàng lúc này đã bị lặp lại trên mỗi dòng chi tiết của đơn đặt hàng. Có lẽ bạn
sẽ không thể thêm khách hàng mới cho đến khi khách hàng đó có một đơn đặt hàng. Và nếu có ai
đó xóa toàn bộ đơn đặt hàng của khách, bạn sẽ mất toàn bộ thông tin về họ. Tuy nhiên, điều tồi
tệ nhất ở đây là khi thông tin của khách hàng bị thay đổi, bạn sẽ phải tìm kiếm và cập nhật mọi
bản ghi chứa dữ liệu về khách hàng bị lặp lại. Bạn sẽ tìm hiểu vấn đề này kỹ hơn ở Chương 7 khi
chúng ta nghiên cứu về thiết kế cơ sở dữ liệu lôgíc.
Một cách tiếp cận khác thường được sử dụng trong hệ thống file phẳng là kết hợp tất cả các
file liên quan mật thiết với nhau, như file Order và file Order Detail, thành một file mà trong đó,
các dòng chi tiết của đơn đặt hàng sẽ được đặt kế tiếp với bản ghi tiêu đề tương ứng với đơn hàng
và một thành phần dữ liệu Record Type giúp ứng dụng phân biệt giữa hai kiểu bản ghi. Ở cách
tiếp cận này, ID của đơn đặt hàng bị loại bỏ khỏi bản ghi Order Detail, bởi ứng dụng biết bản ghi
Order Detail thuộc về đơn đặt hàng nào nhờ vị trí của nó trong file (nằm sau bản ghi Order). Mặc
dù cách tiếp cận này khiến các dữ liệu đơn đặt hàng được kết nối một cách dễ dàng, song nó cũng
phức tạp khi kết hợp các loại bản ghi khác nhau vào cùng một file, khiến việc phát triển trở nên
mất thời gian và phức tạp hơn.
Tựu trung lại, vấn đề tồi tệ nhất với cách tiếp cận file phẳng là định nghĩa nội dung của mỗi
file, và lôgíc cần thiết để kết nối dữ liệu từ nhiều file phẳng phải nằm trong mỗi chương trình ứng
dụng yêu cầu các file này, vì thế làm gia tăng chi phí và sự phức tạp của chương trình ứng dụng.
Vấn đề trên chính là động lực giúp các nhà khoa học máy tính tìm kiếm một cách thức tổ chức
dữ liệu tốt hơn.
Chương 1: Căn bản về cơ sở dữ liệu
Mô hình phân cấp
Các cơ sở dữ liệu sơ khai đều tuân theo mô hình phân cấp (hierarchical model), được cải tiến từ hệ
thống file thành cơ sở dữ liệu, với các bản ghi được sắp xếp theo một cấu trúc phân cấp gần giống
như sơ đồ tổ chức. Mỗi file trong hệ thống file phẳng trở thành một kiểu bản ghi (record type),
hoặc nút (node) theo thuật ngữ phân cấp. Tuy nhiên, thuật ngữ bản ghi (record) được sử dụng ở
đây nhằm mục đích đơn giản hóa. Những bản ghi được kết nối bằng các con trỏ (pointer) chứa
địa chỉ của bản ghi liên quan. Các con trỏ thông báo cho hệ thống máy tính bản ghi nằm ở đâu về
mặt vật lý, giống như địa chỉ đường phố hướng dẫn bạn cách đi tới một tòa nhà trong một thành
phố, một URL đưa bạn tới một trang web nào đó trên Internet, hay tọa độ GPS thông báo vị trí địa
lý hiện tại của bạn. Mỗi con trỏ tạo ra một mối quan hệ cha - con (parent-child relationship), hay
còn gọi là quan hệ một - nhiều (one-to-many relationship), trong đó, một cha có thể có nhiều con;
tuy nhiên, mỗi con lại chỉ có thể có một cha. Mối quan hệ này tương tự như mối quan hệ trong tổ
chức kinh doanh truyền thống, ở đó, mỗi quản lý có thể có nhiều nhân viên báo cáo trực tiếp; tuy
nhiên, mỗi nhân viên lại chỉ có một quản lý duy nhất. Vấn đề rõ ràng đối với mô hình phân cấp
trên là, một vài dữ liệu không phù hợp với quy tắc của cấu trúc phân cấp này, chẳng hạn một đơn
đặt hàng, có thể có một cha là khách hàng và một cha khác là nhân viên lập đơn đặt hàng. (Các
mối quan hệ dữ liệu được trình bày chi tiết hơn ở Chương 2). Cơ sở dữ liệu phân cấp nổi tiếng
nhất là Information Management System (IMS) của IBM.
Hình 1-3 trình bày cấu trúc phân cấp trong mô hình phân cấp của cơ sở dữ liệu Northwind
Traders. Bạn sẽ nhận ra các kiểu bản ghi Customer, Employee, Product, Order và Order Detail
như được giới thiệu ở phần trước. So sánh cấu trúc phân cấp với hệ thống file phẳng trong Hình
1-2, chú ý, các bản ghi Employee và Product ở cấu trúc phân cấp có nét đứt ở giữa, vì chúng
Hình 1-3 Cấu trúc mô hình phân cấp của Northwind.
không thể được nối với những bản ghi thuộc kiểu còn lại thông qua con trỏ. Hình trên minh họa
hạn chế lớn nhất của mô hình phân cấp, khiến mô hình này bị ngưng sử dụng: Không bản ghi nào
có thể có nhiều hơn một cha. Do đó, ta không thể kết nối bản ghi Employee với bản ghi Order,
vì các bản ghi Order đã có một bản ghi Customer là cha. Tương tự, bản ghi Product cũng không
thể được kết nối với bản ghi Order Detail, vì các bản ghi Order Detail đã có một bản ghi Order là
13
14
Nhập môn Cơ sở dữ liệu
cha. Các kỹ thuật viên cơ sở dữ liệu đã phải giải quyết hạn chế này bằng cách kết nối những bản
ghi cha “bổ sung” từ chương trình ứng dụng, tương tự như trong hệ thống file phẳng, hoặc lặp lại
tất cả các bản ghi dưới mỗi cha, một cách làm rất lãng phí tài nguyên đĩa cứng lẽ ra đáng được
coi trọng, chưa kể còn gây nhiều khó khăn cho việc đồng bộ hóa những dữ liệu không cần thiết.
Không có cách nào trong hai cách trên là giải pháp chấp nhận được, vì thế IBM đã điều chỉnh IMS
để cho phép một bản ghi có thể có nhiều cha. Kết quả, một mô hình dữ liệu mới được tạo ra mang
tên mô hình phân cấp mở rộng (extended hierarchical), có đặc điểm chức năng gần giống với mô
hình cơ sở dữ liệu mạng sẽ được trình bày ở phần tiếp theo.
Hình 1-4 trình bày nội dung một số bản ghi được lựa chọn trong thiết kế mô hình phân cấp
của Northwind. Để đơn giản hóa, chúng ta đã loại bỏ một số thành phần dữ liệu, nhưng nếu muốn
xem lại nội dung của mỗi bản ghi một cách rõ ràng, hãy xem lại Hình 1-2. Bản ghi của khách hàng
6 (Customer: 6) có một con trỏ trỏ tới đơn đặt hàng đầu tiên (ID 56), và đơn đặt hàng này lại có
một con trỏ trỏ tới đơn đặt hàng tiếp theo (ID 79). Bạn có thể nhận ra, đơn đặt hàng 79 là đơn đặt
hàng cuối cùng của khách, vì nó không có con trỏ nào trỏ tới đơn đặt hàng tiếp theo. Quan sát lớp
tiếp theo trong phân cấp, đơn đặt hàng 79 có một con trỏ trỏ tới bản ghi Order Detail (của Product
7), và bản ghi này lại có một con trỏ trỏ tới bản ghi thông tin chi tiết tiếp theo (của Product 51).
Customer: 6
Order: 5 6
Order Detail:
Product 4 8
Order: 7 9
Order Detail:
Product 7
Order Detail:
Product 5 1
Hình 1-4 Nội dung bản ghi trong mô hình phân cấp của Northwind.
Như bạn thấy, mỗi lớp trong phân cấp có một chuỗi nhiều con trỏ kết nối các bản ghi theo thứ tự
hợp lý. Một khác biệt quan trọng nữa giữa hệ thống file phẳng và mô hình phân cấp là: khóa (định
danh) của bản ghi cha bị loại khỏi bản ghi con trong mô hình phân cấp, bởi các con trỏ kiểm soát
mối quan hệ giữa các bản ghi. Do đó, ID của khách hàng và ID của nhân viên bị loại khỏi bản ghi
Order, và ID của sản phẩm bị loại khỏi bản ghi Order Detail. Giữ lại các thông tin trên không phải
là ý kiến hay, vì việc này có thể khiến các thông tin trái ngược, chẳng hạn như một đơn đặt hàng,
được một khách hàng trỏ tới trong khi chứa ID của một khách hàng khác.
Mô hình mạng
Mô hình cơ sở dữ liệu mạng (network database model) được phát triển vào cùng thời điểm với mô
hình cơ sở dữ liệu phân cấp. Một ủy ban gồm các đại diện của những công ty trong ngành đã được
thành lập để cùng xây dựng một phải pháp hiệu quả hơn. Kẻ hoài nghi cho rằng, con lạc đà mà
Chương 1: Căn bản về cơ sở dữ liệu
ủy ban thiết kế ra là một con ngựa, và điều đó có lẽ đúng trong trường hợp này. Cơ sở dữ liệu nổi
tiếng nhất dựa trên mô hình mạng là Integrated Database Management System (IDMS), ban đầu
được phát triển bởi Cullinane (sau đổi tên là Cullinet). Sản phẩm đã được cải tiến để trở thành một
cơ sở dữ liệu quan hệ và được đặt tên là IDMS/R, cuối cùng được bán cho Computer Associates.
Cũng như mô hình phân cấp, kiểu bản ghi (hay đơn giản là bản ghi) đại diện cho các file
riêng trong hệ thống file phẳng, và những bản ghi đó được kết nối với nhau thông qua mối quan
hệ một - nhiều, còn được gọi là quan hệ sở hữu - thành viên (owner-member) hay các tập hợp
(set) trong thuật ngữ mô hình mạng. Chúng ta sử dụng lại thuật ngữ cha (parent) và con (child)
cho dễ hiểu. Ở mô hình phân cấp, các con trỏ địa chỉ vật lý sẽ được sử dụng để kết nối những bản
ghi liên quan, và bất kỳ ID của bản ghi cha nào cũng sẽ bị loại bỏ khỏi bản ghi con để tránh xảy
ra sự thiếu nhất quán. Ngược lại với mô hình phân cấp, các mối quan hệ được đặt tên, từ đó, lập
trình viên có thể hướng dẫn DBMS sử dụng một mối quan hệ nào đó để chuyển từ bản ghi này
sang bản ghi khác trong cơ sở dữ liệu, cho phép một kiểu bản ghi có thể trở thành con trong nhiều
mối quan hệ khác nhau.
Hình 1-5 Cấu trúc mô hình mạng của Northwind.
Mô hình mạng mang lại sự linh hoạt cao hơn, nhưng - thường với các hệ thống máy tính - nó lại
thiếu sự đơn giản.
Cấu trúc mô hình mạng của Northwind, như trong Hình 1-5, đều có toàn bộ bản ghi tương
đương với cấu trúc mô hình phân cấp ở Hình 1-3. Để thuận tiện, quy ước mũi tên sẽ trỏ từ cha sang
con. Chú ý, lúc này, các bản ghi Customer và Employee đã có các đường nét liền trong sơ đồ cấu
trúc, vì chúng có thể được cài đặt một cách trực tiếp ngay trong cơ sở dữ liệu.
Ở ví dụ các nội dung trong mô hình mạng tại Hình 1-6, mỗi mối quan hệ cha - con được mô
tả bằng các loại đường khác nhau, với ý nghĩa mỗi quan hệ có một tên gọi khác nhau. Sự khác biệt
này rất quan trọng, vì nó chỉ ra mặt hạn chế lớn nhất của mô hình mạng - tính phức tạp. Thay vì
chỉ sử dụng một con đường để xử lý các bản ghi, ở đây, ta phải dùng rất nhiều đường. Chẳng hạn,
bắt đầu với bản ghi của Employee 2 (Phó Giám đốc kinh doanh Andrew Cencini) và dùng nó để
tìm đơn đặt hàng đầu tiên (ID 56). Bạn sẽ đi theo chuỗi đơn đặt hàng thuộc về Customer 6 (Công
ty F). Mặc dù thực tế, bạn đang ở vị trí đơn đặt hàng đầu tiên của khách hàng đó, song bạn không
có cách nào để nhận biết được. Để tìm kiếm toàn bộ những đơn đặt hàng khác của khách hàng
này, bạn phải tìm cách đi từ điểm hiện tại tới điểm cuối của chuỗi, sau đó trở lại điểm xuất phát
15
16
Nhập môn Cơ sở dữ liệu
và tiếp tục đi tiếp đến khi bạn quay lại đơn đặt hàng mà bạn bắt đầu. Để quá trình này có thể diễn
ra, toàn bộ chuỗi con trỏ nằm trong cơ sở dữ liệu mô hình mạng phải là vòng tròn. Do đó, bạn có
thể di chuyển con trỏ từ đơn đặt hàng 56 tới đơn hàng tiếp theo (ID 79), sau đó tới bản ghi khách
hàng (ID 6), và cuối cùng quay lại đơn hàng 56. Hãy hình dung, chuỗi các con trỏ vòng quanh này
có thể dễ dàng tạo ra một vòng lặp vô tận (infinite loop - một quá trình không bao giờ kết thúc),
khiến người dùng cơ sở dữ liệu không thể theo dõi được mình đang ở đâu trong cơ sở dữ liệu, và
làm thế nào để tới được đó. Cấu trúc của World Wide Web có thể coi là gần tương đương với một
cơ sở dữ liệu mạng, vì mỗi trang web chứa các liên kết tới những trang web liên quan khác, và các
tham chiếu vòng quanh tồn tại rất phổ biến.
Hình 1-6 Bản ghi trong mô hình mạng của Northwind.
Quá trình di chuyển trong một cơ sở dữ liệu mạng được gọi là “di chuyển trong một tập hợp”
(walking the set), bởi vì nó bao gồm việc chọn những con đường đi qua cấu trúc cơ sở dữ liệu,
giống như chọn đường đi trong rừng, khi có nhiều con đường cùng đi tới đích để chọn. Không
có một bản đồ chứa đầy đủ thông tin sẽ rất dễ bị lạc, hay tồi tệ hơn là tìm đến ngõ cụt, và bạn sẽ
không thể tìm thấy bản ghi đích mong muốn nếu như không quay lại con đường đã đi. Sự phức
tạp của mô hình cùng với chi phí của đội ngũ chuyên gia kỹ thuật cần thiết để duy trì là những
nguyên nhân chính dẫn đến việc ngừng sử dụng mô hình này.
Mô hình quan hệ
Ngoài tính phức tạp, các mô hình cơ sở dữ liệu phân cấp và mạng còn có một điểm chung nữa - đó
là thiếu sự mềm dẻo. Bạn phải đi theo những con đường được định trước để xử lý dữ liệu một cách
hiệu quả. Các lệnh truy vấn ad-hoc, chẳng hạn như tìm kiếm tất cả những đơn đặt hàng có thời gian
Chương 1: Căn bản về cơ sở dữ liệu
đưa hàng trong một tháng nào đó, phải quét toàn bộ cơ sở dữ liệu để phục vụ cho việc tìm kiếm.
Các nhà khoa học máy tính vẫn đang tiếp tục tìm kiếm một cách thức giải quyết vấn đề hiệu quả
hơn. Chỉ có một số sự kiện diễn ra trong lịch sử phát triển máy tính thực sự mang tính cách mạng,
và công trình nghiên cứu của E.F. (Ted) Codd làm tiền đề cho sự phát triển mô hình quan hệ là
một trong số đó.
Mô hình quan hệ (relational model) dựa trên ý tưởng mọi con đường được định trước thông
qua một cấu trúc dữ liệu là giải pháp quá chặt chẽ, đặc biệt khi nhu cầu hỗ trợ các truy vấn ad-hoc
ngày càng tăng lên. Người dùng cơ sở dữ liệu không thể nghĩ đầy đủ về mọi khả năng sử dụng
dữ liệu trước khi tạo ra cơ sở dữ liệu, do đó, các đường đi qua dữ liệu được xác định trước tạo ra
những “nhà tù dữ liệu”. Khi cần, mô hình quan hệ cho phép người dùng liên kết các bản ghi thay
vì định nghĩa rõ từ đầu, khi những bản ghi này được lưu trữ lần đầu trong cơ sở dữ liệu. Ngoài ra,
mô hình quan hệ được xây dựng sao cho các truy vấn làm việc với tập dữ liệu (ví dụ, tìm tất cả
khách hàng có số dư nợ chưa thanh toán), chứ không phải làm việc với một bản ghi riêng lẻ, như
mô hình mạng và mô hình phân cấp vẫn làm.
Mô hình quan hệ biểu diễn dữ liệu dưới dạng các bảng hai chiều, giống như các trang tính.
Tuy nhiên, không giống như trang tính, dữ liệu trong mô hình quan hệ không nhất thiết phải lưu
trữ dưới dạng bảng và mô hình này cho phép kết hợp (kết nối (join) - theo thuật ngữ quan hệ) các
bảng thành những view, cũng được biểu diễn dưới dạng bảng hai chiều. Tóm lại, mô hình quan hệ
tuân theo mô hình ANSI/SPARC, do đó mang tính độc lập dữ liệu vật lý và độc lập dữ liệu lôgíc.
Thay vì liên kết các bản ghi có quan hệ bằng con trỏ địa chỉ vật lý, giống như mô hình mạng hay
mô hình phân cấp thường làm, mô hình quan hệ lưu trữ thành phần dữ liệu chung tại mỗi bảng,
giống như trong các hệ thống file phẳng.
Hình 1-7 biểu diễn thiết kế mô hình quan hệ cho Northwind. Hãy xem lại Hình 1-2, chúng ta
thấy rằng, mỗi file trong hệ thống file phẳng được ánh xạ thành một bảng trong mô hình quan hệ.
Như bạn sẽ được tìm hiểu trong Chương 6, không phải lúc nào phép ánh xạ một - một giữa file
phẳng với bảng quan hệ cũng đúng, tuy nhiên đây là trường hợp phổ biến. Trong Hình 1-7, đường
nối giữa mỗi bảng biểu diễn các quan hệ một - nhiều, đầu mút kết thúc bằng một đường thẳng
biểu thị cho bên “một”, đầu mút kết thúc bằng ba đoạn thẳng (giống hình vương miện) biểu thị
cho bên “nhiều” của quan hệ. Ví dụ, “một” khách hàng (Customer) liên kết tới “nhiều” đơn hàng
(Order) và “một” đơn hàng liên kết với “nhiều” mục chi tiết đơn hàng (Order Detail), bạn có thể
kiểm tra điều này bằng cách xem xét những đường nối các bảng trong hình. Kỹ thuật tạo lược đồ
trong Hình 1-7 được gọi là lược đồ quan hệ thực thể (entity-relationship diagram - ERD), sẽ được
đề cập chi tiết hơn ở Chương 7.
Ở Hình 1-8, ba trong số năm bảng được biểu diễn có cùng dữ liệu mẫu trong các cột được
chọn. Đặc biệt, để ý thấy, cột Customer ID được lưu trong cả bảng Customer và bảng Order. Khi
ID của khách hàng trên một dòng trong bảng Order trùng khớp với ID của khách hàng trong bảng
17
18
Nhập môn Cơ sở dữ liệu
Hình 1-7 Cấu trúc mô hình quan hệ của Northwind.
Bảng Customer
Customer ID
Company Name
Contact First Name
Contact Last Name
Job Title
City
State
6
Company F
Francisco
Pérez-Olaeta
Purchasing Manager
Milwaukee
WI
26
Company Z
Run
Liu
Accounting Assistant
Miami
FL
Order ID
Bảng Order
Customer ID
Employee ID
Order Date
Shipped Date
Shipping Fee
51
26
9
4/5/2006
4/5/2006
$60.00
56
6
2
4/3/2006
4/3/2006
$ 0.00
79
6
2
6/23/2006
6/23/2006
$ 0.00
Bảng Employee
Employee ID
First Name
Last Name
Title
2
Andrew
Cencini
Vice President, Sales
5
Steven
Thrope
Sales Manager
9
Anne
Hellung-Larsen
Sales Representative
Hình 1-8 Các nội dung của bảng quan hệ Northwind.
Customer, đơn hàng đó thuộc về khách hàng tương ứng. Tương tự, cột Employee ID được lưu trữ
trong cả hai bảng Employee và Order biểu thị cho nhân viên tiếp nhận đơn hàng.
Tính đơn giản, dễ hiểu là những yếu tố chính khiến mô hình quan hệ trở nên phổ biến và được
chấp nhận rộng rãi. Mô hình quan hệ là nội dung chính của cuốn sách này vì nó rất phổ biến trong
các hệ thống công nghệ thông tin hiện thời cũng như trong nhiều năm tới.
Chương 1: Căn bản về cơ sở dữ liệu
Mô hình hướng đối tượng
Mô hình hướng đối tượng (object-oriented - OO) bắt đầu từ những năm 1970, nhưng chưa được sử
dụng theo mục đích thương mại cho tới những năm 1990. Mô hình hướng đối tượng bất ngờ trở nên
phổ biến như vậy xuất phát từ thực tế lúc bấy giờ, hệ quản trị cơ sở dữ liệu quan hệ (RDBMS) không
thể xử lý được các loại dữ liệu phức tạp như hình ảnh, bản vẽ, file video, âm thanh. Sự bùng nổ của
Internet và World Wide Web đã tạo ra nhu cầu cấp thiết phải cung cấp các kiểu dữ liệu phức tạp.
Đối tượng (object) là nhóm lôgíc tập hợp những dữ liệu liên quan và lôgíc chương trình biểu
diễn cho các sự vật trong thế giới thực, như khách hàng, nhân viên, đơn hàng hay sản phẩm. Các
thành phần dữ liệu đơn lẻ, như ID, tên khách hàng, được gọi là biến (variable) trong mô hình OO và
được lưu trữ bên trong mỗi đối tượng. Bạn có thể hiểu biến chính là biến thể hiện (instance variable)
hay thuộc tính (property), nhưng chúng ta chỉ sử dụng thuật ngữ biến để đảm bảo sự nhất quán. Theo
thuật ngữ của mô hình hướng đối tượng, phương thức (method) là một bộ phận của lôgíc chương
trình ứng dụng, xử lý trên một đối tượng cụ thể, cung cấp một chức năng xác định, như kiểm tra giới
hạn dư nợ của khách hàng hay cập nhật địa chỉ của khách hàng. Trong số các điểm khác biệt giữa
mô hình OO với những mô hình đã trình bày, khác biệt quan trọng nhất là các biến chỉ có thể được
truy cập thông qua các phương thức. Tính chất này được gọi là đóng gói (encapsulation).
Định nghĩa đối tượng được dùng ở đây chỉ áp dụng cho mô hình OO. Thuật ngữ đối tượng cơ
sở dữ liệu (database object) sử dụng trong các phần trước chỉ mọi phần tử được đặt tên, đồng thời
lưu trong cơ sở dữ liệu không hướng đối tượng (ví dụ như bảng, chỉ mục hoặc view). OO cũng có
những khái niệm giống cơ sở dữ liệu quan hệ, do đó, các thuật ngữ có thể giống nhau nhưng có
thể không chính xác về mặt nghĩa.
Hình 1-9 biểu diễn đối tượng Customer như một ví dụ về việc cài đặt các đối trượng trong
OO. Vòng tròn phương thức bao quanh vòng tròn chứa các biến ở trung tâm biểu diễn cho tính
Đối Customer
tượng Customer
Object
Thêm khách hàng
Phương thức
Liệt kê
khách hàng
Biến
Cập nhật
thông tin liên hệ
Cập nhật địa chỉ
Kiểm tra hạn
mức tín dụng
Thay đổi
trạng thái
Cập nhật
thông tin liên hệ
In nhãn thư
Hình 1-9 Cấu trúc đối tượng.
19
20
Nhập môn Cơ sở dữ liệu
đóng gói. Thực tế, bạn có thể hình dung một đối tượng giống như một nguyên tử, trong đó trường
điện tử là các phương thức và hạt nhân là các biến. Mỗi khách hàng Northwind có bản sao cấu trúc
đối tượng riêng, được gọi là một thể hiện đối tượng (object instance), giống như mỗi khách hàng
có một bản sao của cấu trúc bản ghi khách hàng trong hệ thống file phẳng.
Thoạt nhìn, mô hình OO có vẻ không hiệu quả vì hình như mỗi thể hiện đòi hỏi các phương
thức và định nghĩa các biến phải được lưu trữ dư thừa. Tuy nhiên, không phải lúc nào cũng như
vậy. Các đối tượng được tổ chức theo mô hình phân cấp lớp (class hierarchy) sao cho những
phương thức chung và định nghĩa biến chỉ được định nghĩa một lần duy nhất, sau đó được kế thừa
(inherited) bởi các thành viên trong cùng lớp đó. Biến cũng thuộc về lớp, do đó có thể dễ dàng
tích hợp thêm các kiểu dữ liệu mới bằng cách định nghĩa một lớp mới cho những kiểu dữ liệu đó.
Mô hình OO cũng hỗ trợ các đối tượng phức hợp (complex object), chứa một hoặc nhiều đối
tượng khác. Thông thường, các đối tượng phức hợp được cài đặt bằng cách sử dụng tham chiếu
(reference) đối tượng, hay nói cách khác một đối tượng có thể chứa định danh của một hoặc nhiều
đối tượng khác. Ví dụ, đối tượng Customer có thể chứa danh sách các đối tượng Order mà khách
hàng đó đã đặt hàng, và mỗi đối tượng Order có thể chứa định danh của khách hàng tương ứng.
Định danh duy nhất của một đối tượng được gọi là định danh đối tượng (Object Identifier - OID),
giá trị này tự động được gán khi mỗi đối tượng được tạo ra và là hằng số (tức là, giá trị này không
bao giờ thay đổi). Sự kết hợp của các đối tượng phức hợp và cấu trúc lớp phân cấp giúp cơ sở dữ
liệu hướng đối tượng trở nên phù hợp trong việc quản lý dữ liệu không phải là dữ liệu vô hướng
như các bản vẽ và lược đồ.
Khái niệm hướng đối tượng có rất nhiều ưu điểm, được ứng dụng trong hầu hết các hệ thống
máy tính hiện đại. Ví dụ, Microsoft Windows Registry (thư mục chứa các thiết lập và tùy chọn cho
hệ điều hành Windows) có cấu trúc phân cấp, và hầu hết ứng dụng thiết kế với sự trợ giúp của máy
tính (computer-aided design - CAD) đều sử dụng cơ sở dữ liệu hướng đối tượng để lưu dữ liệu.
Mô hình quan hệ đối tượng
Mặc dù mô hình hướng đối tượng (OO) có nhiều ưu điểm quan trọng trong việc đóng gói dữ liệu
nhằm giảm thiểu tối đa ảnh hưởng của việc thay đổi hệ thống, song do không có khả năng truy vấn
ad-hoc, nên mô hình này chỉ phù hợp với một phân đoạn thị trường riêng cần xử lý những dữ liệu
phức tạp nhưng không cần tới khả năng truy vấn ad-hoc. Tuy nhiên, một số nhà cung cấp cơ sở dữ
liệu quan hệ đã chỉ ra các ưu điểm quan trọng của mô hình OO, đặc biệt là khả năng ánh xạ những
kiểu dữ liệu phức tạp, cũng như thêm khả năng giống-như-đối tượng vào các sản phẩm hệ quản
trị cơ sở dữ liệu với hy vọng tận dụng được những ưu điểm tốt nhất của cả hai mô hình. Mặc dù
những người theo chủ nghĩa hướng đối tượng thuần túy không tán thành, nhưng cách tiếp cận này
đã được áp dụng khá rộng rãi, trong khi đó các cơ sở dữ liệu hướng đối tượng thuần túy chỉ được
sử dụng trong phân đoạn thị trường riêng. Tên ban đầu của kiểu cơ sở dữ liệu này là cơ sở dữ liệu
vạn năng (universal database), và dù những nhà tiếp thị kinh doanh rất thích dùng thuật ngữ này,
nhưng giới kỹ thuật lại không bao giờ sử dụng tới, do đó, tên thường dùng cho mô hình này trở
thành quan hệ đối tượng (object-relational - OR). Qua lịch sử phát triển, Oracle, DB2, Informix
có thể được coi là những hệ quản trị cơ sở dữ liệu OR với nhiều cấp độ khác nhau.
Để hiểu mô hình OR một cách đầy đủ, bạn cần có kiến thức sâu hơn về mô hình quan hệ và
mô hình OO. Tuy nhiên, hãy nhớ rằng, hệ quản trị cơ sở dữ liệu OR kết hợp các tính năng được
Chương 1: Căn bản về cơ sở dữ liệu
mong đợi từ mô hình đối tượng, chẳng hạn như khả năng lưu trữ các loại dữ liệu phức tạp, với sự
đơn giản và dễ sử dụng của mô hình quan hệ. Hầu hết các chuyên gia trong ngành đều tin rằng
công nghệ quan hệ đối tượng sẽ tiếp tục giành được thị phần.
Tóm tắt lịch sử cơ sở dữ liệu
Các dự án thăm dò không gian dẫn đến sự phát triển quan trọng của nhiều ngành công nghiệp
khoa học công nghệ, trong đó có công nghệ thông tin. Để phục vụ dự án thám hiểm mặt trăng của
NASA, năm 1964, Hãng Hàng không Bắc Mỹ (North American Aviation - NAA) đã tiến hành
xây dựng hệ thống file phân cấp có tên là Generalized Update Access Method (GUAM). IBM đã
kết hợp với NAA để phát triển GUAM và cho ra đời cơ sở dữ liệu mô hình phân cấp thương mại
đầu tiên, được gọi là Hệ thống Quản lý Thông tin (Information Management System - IMS), phát
hành năm 1966.
Giữa những năm 1960, dưới sự hướng dẫn của nhà khoa học máy tính nổi tiếng lúc bấy giờ
là Charles W. Bachman, công ty General Electric đã tự phát triển cơ sở dữ liệu đầu tiên dựa trên
mô hình mạng và đặt tên là Kho Dữ liệu Tích hợp (Integrated Data Store - IDS). Năm 1967, tại
hội nghị bàn về các ngôn ngữ cho các hệ thống dữ liệu (Data Systems Languages - CODASYL),
một nhóm công ty đã thành lập Nhóm Đặc nhiệm Cơ sở dữ liệu (Database Task Group - DBTG)
và bắt đầu làm việc để thiết lập tập các tiêu chuẩn cho mô hình mạng. Để đáp lại những chỉ trích
về hạn chế “một cha” (“single-parent”) trong mô hình phân cấp, IBM đã giới thiệu một phiên bản
của IMS giải quyết được vấn đề đó bằng cách cho phép các bản ghi có một “cha” vật lý và nhiều
“cha” lôgíc.
Tháng 6 năm 1970, E.F. (Ted) Codd, một nhà nghiên cứu của IBM (sau này là thành viên của
IBM Fellow – vị trí được chính Giám đốc Điều hành của IBM bổ nhiệm, mỗi năm chỉ bổ nhiệm từ
4 đến 9 thành viên), đã công bố bài nghiên cứu với tiêu đề “Mô hình quan hệ dữ liệu cho các ngân
hàng dữ liệu chia sẻ lớn” trên tạp chí Communications of the ACM, tạp chí của Hiệp hội Máy tính
Mỹ (Association for Computing Machinery – ACM). (Ấn phẩm này có thể dễ dàng tìm thấy trên
Internet). Năm 1971, DBTG CODASYL công bố tiêu chuẩn cho mô hình mạng sau hơn 3 năm làm
việc. Điều này đã khởi đầu cho cuộc tranh luận sôi nổi kéo dài 5 năm về việc mô hình nào là tốt nhất.
Những người ủng hộ DBTG CODASYL lập luận như sau:
●● Mô hình quan hệ mang nặng tính chất toán học.
●● Không thể triển khai được mô hình quan hệ một cách hiệu quả.
●● Hệ thống ứng dụng cần xử lý dữ liệu làm việc với từng bản ghi ở một thời điểm.
Những người ủng hộ mô hình quan hệ lập luận như sau:
●● Mô hình mà DBTG đưa ra quá phức tạp để quản lý dữ liệu chính xác.
●● Các truy vấn hướng tập hợp quá khó trong ngôn ngữ DBTG.
●● Mô hình mạng không có cơ sở lý thuyết toán học chính thức.
Các cuộc tranh luận kéo dài cho tới hội nghị SIGMOD (Special Interest Group on Management
of Data) do Hiệp hội Máy tính Mỹ tổ chức vào năm 1975. Codd cùng hai người khác đã tranh luận
21
22
Nhập môn Cơ sở dữ liệu
với Bachman và hai người khác nữa về ưu điểm của hai mô hình. Cuối cùng, những người theo
dõi cũng không biết nên ủng hộ ai. Vấn đề nằm ở chỗ lập luận của cả hai bên đều hoàn toàn chính
xác! Tuy nhiên, sự quan tâm tới mô hình mạng giảm rõ rệt vào cuối những năm 1970. Đó là do sự
phát triển của cơ sở dữ liệu và công nghệ máy tính sau đó đã chứng minh mô hình quan hệ là sự
lựa chọn tốt hơn, với những phát triển quan trọng sau đây:
●● Các ngôn ngữ truy vấn như SQL (Structured Query Language – Ngôn ngữ truy vấn có cấu
trúc) giúp mô hình quan hệ bớt mang nặng tính chất toán học.
●● Những triển khai thí điểm mô hình quan hệ đã chứng minh rằng có thể đạt được hiệu quả
cao, mặc dù mô hình quan hệ chưa bao giờ hiệu quả bằng mô hình cơ sở dữ liệu mạng tương
đương. Ngoài ra, hệ thống máy tính liên tục giảm giá, và tính linh hoạt được xem là quan
trọng hơn sự hiệu quả.
●● Một số mở rộng cho phép SQL có thể xử lý các tập dữ liệu bằng cách áp dụng phương pháp
một bản ghi tại một thời điểm.
●● Các công cụ nâng cao làm cho mô hình quan hệ trở nên dễ sử dụng hơn.
●● Các nghiên cứu của Codd dẫn đến sự phát triển của một ngành học mới, được gọi là đại số
quan hệ (relational calculus).
Vào giữa những năm 1970, các nghiên cứu và phát triển cơ sở dữ liệu trở nên bão hòa. Dưới
sự chỉ đạo của Frank King, một nhóm gồm 15 nhà nghiên cứu của IBM ở San Jose, California đã
làm việc từ năm 1974 tới năm 1978 để phát triển cơ sở dữ liệu quan hệ nguyên mẫu có tên là System R. System R là sản phẩm thương mại, trở thành nền tảng của HP ALLBASE và IDMS/SQL.
Larry Ellison và một công ty mà sau này chính là Oracle, đã tự thực hiện các đặc tả ngoài của
System R. Thời điểm đó, có một thông tin rất phổ biến nói rằng khách hàng đầu tiên của Oracle
chính là Cục Tình báo Trung ương Mỹ (CIA). Với một số thay đổi, IBM đã phát triển System R
thành SQL/DS và sau đó là DB2, đây vẫn là cơ sở dữ liệu hàng đầu cho đến ngày nay.
Dưới sự chỉ đạo của Michael Stonebraker và Eugene Wong, một nhóm sinh viên của trường
Đại học California tại Berkeley đã làm việc từ năm 1973 tới năm 1977 để phát triển hệ quản trị
cơ sở dữ liệu có tên là Ingres. Ingres cũng trở thành một sản phẩm thương mại khá thành công,
được bán cho Computer Associates, nhưng sau đó xuất hiện lại với tư cách là một công ty độc lập
vào năm 2005.
Năm 1976, Peter Chen giới thiệu mô hình quan hệ thực thể (ER). Những nghiên cứu của ông
đã khắc phục những nhược điểm trong mô hình quan hệ và trở thành nền tảng của các kỹ thuật mô
hình hóa sau này. Nếu Codd được coi là “cha đẻ” của mô hình quan hệ, thì Chen được coi là “cha
đẻ” của ERD. Các mô hình ERD sẽ được tìm hiểu trong Chương 7.
Hãng Sybase, chủ sở hữu của một hệ quản trị cơ sở dữ liệu (RDBMS) triển khai rất thành
công trên các máy chủ Unix, đã ký thỏa thuận liên kết với Microsoft cùng phát triển thế hệ tiếp
theo của Sybase (được gọi là System 10) với một phiên bản có sẵn trên các server Windows. Vì
một lý do không rõ ràng, mối quan hệ giữa hai bên trở nên xấu đi trước khi các sản phẩm hoàn
thành, và vì thế, họ đã thôi không hợp tác và tự phát triển tiếp những công việc còn dang dở. Microsoft đã hoàn thiện phiên bản cho Windows và đưa ra thị trường sản phẩm với tên gọi Microsoft
SQL Server, trong khi đó, Sybase cũng đưa ra thị trường sản phẩm Sybase System 10. Hai sản
phẩm này giống nhau tới mức những giảng viên SQL Server có thể sử dụng các hướng dẫn của
Chương 1: Căn bản về cơ sở dữ liệu
Sybase để giảng dạy thay vì sử dụng tài liệu thế hệ đầu tiên của Microsoft. Hai dòng sản phẩm
này đã có nhiều thay đổi, tách biệt nhau trong những năm qua, nhưng nguồn gốc Sybase trong
Microsoft SQL Server vẫn rất rõ ràng.
Công nghệ quan hệ phát triển nở rộ vào những năm 1980. Thập niên 1980 cũng đánh dấu
những thành công lớn của cơ sở dữ liệu hướng đối tượng vốn đã xuất hiện vào những năm 1970.
Trong thập niên 1990, các hệ thống quan hệ đối tượng xuất hiện, với Informix là sản phẩm đầu
tiên được đưa ra thị trường, theo sau là sự xuất hiện của Oracle và DB2.
Mô hình quan hệ đối tượng không chỉ làm thay đổi công nghệ quan hệ trong thời gian đó mà
còn thu hút sự chú ý của rất nhiều chuyên gia. Michael Stonebraker rời UC Berkeley để thành lập
Illustra, công ty chuyên cung cấp cơ sở dữ liệu quan hệ đối tượng, và ông trở thành giám đốc kỹ
thuật của Informix khi công ty này sát nhập với Illustra. Sau đó, Stonebraker tiếp tục xây dựng
nên Cohera, StreamBase Systems cùng Vertica, và hiện ông đang là giảng viên Học viện Công
nghệ Massachusetts (MIT). Bob Epstein, người đã làm việc trong dự án Ingres cùng Stonebraker,
đã chuyển đến công ty thương mại cùng với sản phẩm Ingres. Từ đây, ông đã tới Britton-Lee (sau
này được mua lại bởi NCR) để nghiên cứu về thế hệ máy cơ sở dữ liệu (database machine) đầu
tiên (các hệ thống máy tính chuyên dụng chạy cơ sở dữ liệu), sau đó gia nhập công ty khởi nghiệp
Sybase, nơi ông giữ chức giám đốc kỹ thuật trong một vài năm và hiện tại, ông đang nghiên cứu
những vấn đề liên quan tới môi trường cũng như máy tính di động (wearable computer). Máy cơ
sở dữ liệu đã thất bại vì chúng quá đắt so với hệ thống máy tính đa năng chạy DBMS. Vùng Vịnh
San Francisco là nơi thu hút rất nhiều chuyên gia cơ sở dữ liệu trong thời gian đó vì tất cả các sản
phẩm cơ sở dữ liệu quan hệ tuyệt vời nhất đều bắt đầu tại đây, song song với sự phát triển bùng nổ
của thung lũng Silicon. Hầu hết các công ty khác đã chuyển tới địa điểm mới, nhưng DB2, Oracle
và Sybase vẫn đặt trụ sở tại vùng Vịnh.
Tại sao phải tập trung vào mô hình quan hệ?
Phần còn lại trong cuốn sách này tập trung vào mô hình quan hệ, cũng như đề cập sơ bộ tới các
mô hình hướng đối tượng và mô hình quan hệ đối tượng. Ngoài thực tế mô hình quan hệ được sử
dụng phổ biến nhất trong số những mô hình cơ sở dữ liệu thuộc hệ thống doanh nghiệp hiện đại,
dưới đây là một số lý do quan trọng khác cho thấy sự cần thiết phải nghiên cứu mô hình quan hệ,
đặc biệt là với những người lần đầu tìm hiểu cơ sở dữ liệu:
●● Việc định nghĩa, bảo trì, và thao tác các cấu trúc lưu trữ dữ liệu rất dễ dàng.
●● Dữ liệu được lấy về thông qua truy vấn ad-hoc đơn giản.
●● Dữ liệu được bảo vệ tốt.
●● Có các tiêu chuẩn được ban hành bởi các tổ chức tiêu chuẩn hóa như ANSI (American National Standards Institute) và ISO (International Organization for Standardization).
●● Có rất nhiều nhà cung cấp với nhiều sản phẩm đa dạng.
●● Việc chuyển đổi triển khai giữa các nhà cung cấp được thực hiện tương đối dễ dàng.
●● Các RDBMS là sản phẩm đã được phát triển lâu dài và ổn định.
23
24
Nhập môn Cơ sở dữ liệu
Bài tự trắc nghiệm kiến thức Chương 1
Chọn đáp án đúng cho các câu hỏi lựa chọn và câu hỏi điền vào chỗ trống. Chú ý, có thể có nhiều
đáp án đúng cho mỗi câu hỏi.
1. Lớp lôgíc trong mô hình ANSI/SPARC có đặc điểm nào sau đây?
A Tính độc lập dữ liệu vật lý.
B Chứa các quan hệ cha - con.
C Tính độc lập dữ liệu lôgíc.
D Tính đóng gói.
2. Lớp ngoài trong mô hình ANSI/SPARC có đặc điểm nào sau đây?
A Tính độc lập dữ liệu vật lý.
B Chứa các quan hệ cha - con.
C Tính độc lập dữ liệu lôgíc.
D Tính đóng gói.
3. Điều nào sau đây là không đúng khi nói về view người dùng?
A Các chương trình ứng dụng tham chiếu tới các view người dùng.
B Được tham chiếu tới bởi những người truy vấn cơ sở dữ liệu.
C Các view người dùng có thể được thiết kế theo yêu cầu của người dùng cơ sở dữ liệu.
D Dữ liệu cập nhật được hiển thị không tức thời.
4. Schema cơ sở dữ liệu nằm trong lớp ____________ của mô hình ANSI/SPARC.
5. Các view người dùng nằm trong lớp ____________ của mô hình ANSI/SPARC.
6. Khi nào chương trình ứng dụng sử dụng hệ thống file phẳng? Các định nghĩa file nằm ở đâu?
7. Câu nào sau đây là đúng khi nói đến mô hình cơ sở dữ liệu phân cấp?
A Được phát triển lần đầu bởi Peter Chen.
B Dữ liệu và phương thức được lưu trữ trong cơ sở dữ liệu.
C Mỗi nút có thể có nhiều nút cha.
D Các bản ghi được kết nối bằng cách sử dụng những con trỏ địa chỉ vật lý.
8. Câu nào sau đây là đúng khi nói đến mô hình cơ sở dữ liệu mạng?
A Được phát triển lần đầu bởi E.F. Codd.
B Dữ liệu và phương thức được lưu trữ trong cơ sở dữ liệu.
C Mỗi nút có thể có nhiều nút cha.
D Các bản ghi được kết nối bằng cách sử dụng những con trỏ địa chỉ vật lý.
Chương 1: Căn bản về cơ sở dữ liệu
9.Câu nào sau đây là đúng khi nói đến mô hình cơ sở dữ liệu quan hệ?
A Được phát triển lần đầu bởi Charles Bachman.
B Dữ liệu và phương thức được lưu trữ trong cơ sở dữ liệu.
C Các bản ghi được kết nối bằng cách sử dụng những con trỏ địa chỉ vật lý.
D Các bản ghi được liên kết với nhau bằng cách sử dụng những thành phần dữ liệu chung
trong mỗi bản ghi.
10.Câu nào sau đây là đúng khi nói đến mô hình hướng đối tượng?
A Được phát triển lần đầu bởi Charles Bachman.
B Dữ liệu và phương thức được lưu trữ trong cơ sở dữ liệu.
C Dữ liệu được biểu diễn dưới dạng các bảng hai chiều.
D Các bản ghi được liên kết với nhau bằng cách sử dụng những thành phần dữ liệu chung
trong mỗi bản ghi.
11.Câu nào sau đây là đúng khi nói đến mô hình quan hệ đối tượng?
A Mô hình này chỉ phục vụ một phân đoạn thị trường riêng và các chuyên gia đều cho rằng
mô hình này sẽ không phát triển rộng được.
B Các bản ghi được kết nối bằng cách sử dụng những con trỏ địa chỉ vật lý.
C Mô hình này được tạo ra bằng cách thêm các thuộc tính giống-như-đối tượng vào mô hình
quan hệ.
D Mô hình này được tạo ra bằng cách thêm các thuộc tính giống-như-quan hệ vào mô hình
đối tượng.
12.Với những người ủng hộ mô hình quan hệ, những điều nào dưới đây mô tả các vấn đề của mô
hình CODASYL?
A Mô hình CODASYL mang nặng tính toán học.
B Mô hình CODASYL quá phức tạp.
C Các truy vấn hướng tập hợp quá khó.
D Mô hình này không có cơ sở lý thuyết toán học chính thức.
13.Với những người ủng hộ mô hình CODASYL, những điều nào dưới đây mô tả các vấn đề của
mô hình quan hệ?
A Mô hình quan hệ mang nặng tính toán học.
B Các truy vấn hướng tập hợp quá khó.
C Các hệ thống ứng dụng cần xử lý bản ghi tại một thời điểm.
D Mô hình quan hệ kém hiệu quả hơn mô hình CODASYL.
14.Khả năng thêm một đối tượng mới vào cơ sở dữ liệu mà không làm gián đoạn quá trình hiện
tại là một ví dụ về ____________ .
15.Thuộc tính giúp phân biệt một bảng cơ sở dữ liệu quan hệ với một trang tính là khả năng cung
cấp cho nhiều người dùng ____________ của chính họ.
25
