Các khái niệm về cơ sở dữ liệu - poly.edu.vn · có nghĩa là ngân hàng dữ...

Phần ICác khái niệm vềcơ sở dữ liệu

3

Chương 1Căn bản vềcơ sở dữ liệu

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ệuCơ 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à

5Chươ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ệuHệ 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.


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ệuMộ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.


Lớp ngoài View 1 View 2

Schema nội (Schema lôgíc)

View 3

Lớp lôgíc

Độc lập dữ liệu lôgíc

Độc lậpdữ liệu vật lý

Lớp vật lý

File

cơ

sở

dữ li

ệu

File

cơ

sở

dữ li

ệu

File

cơ

sở

dữ li

ệu

File

cơ

sở

dữ li

ệu

File

cơ

sở

dữ li

ệu

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


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ícLớ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àiLớ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


đ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ícKhả 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.


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ụngMộ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ẳngFile 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


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 $9.65

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


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.


Hình 1-3 Cấu trúc mô hình phân cấp của Northwind.

Mô hình phân cấpCá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

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à


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: 7 9

Order Detail:Product 48



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ạngMô 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à


Hình 1-5 Cấu trúc mô hình mạng của Northwind.

ủ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.

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


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


đư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


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

Bảng 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

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.

Hình 1-7 Cấu trúc mô hình quan hệ của Northwind.


Mô hình hướng đối tượngMô 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

Liệt kê khách hàng

Hình 1-9 Cấu trúc đối tượng.

Customer ObjectĐối tượng Customer

Biến

Thêm khách hàng

Cập nhật thông tin liên hệ

Cập nhật địa chỉ

Cập nhật thông tin liên hệ

In nhãn thư

Kiểm tra hạn mức tín dụng

Phương thức

Thay đổitrạng thái


đó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ượngMặ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


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ệuCá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


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à Sys-tem 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ở. Mi-crosoft đã 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


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 Na-tional 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.


Bài tự trắc nghiệm kiến thức Chương 1Chọ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.


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ý.


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.


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.


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ọ.

27

Chương 2Tìm hiểu các thành phần của cơ sở dữ liệu quan hệ


Các khái niệm và kỹ năng chính ● Các thành phần của thiết kế cơ sở dữ liệu mức khái niệm ● Các thành phần của thiết kế cơ sở dữ liệu mức lôgíc/vật lý

Chương này sẽ tìm hiểu về các thành phần mức khái niệm, mức lôgíc và mức vật lý tạo nên mô hình quan hệ. Thiết kế cơ sở dữ liệu mức khái niệm (conceptual database design) bao gồm

việc nghiên cứu và mô hình hóa dữ liệu theo hướng độc lập về công nghệ. Điều này có nghĩa, về lý thuyết, mô hình dữ liệu mức khái niệm có thể triển khai trên một cơ sở dữ liệu bất kỳ, thậm chí trên một hệ thống file phẳng. Người thực hiện việc thiết kế cơ sở dữ liệu mức khái niệm được gọi là nhà mô hình hóa dữ liệu (data modeler). Thiết kế cơ sở dữ liệu mức lôgíc (logical database design) là quá trình chuyển đổi, hay ánh xạ, thiết kế khái niệm thành thiết kế lôgíc phù hợp với mô hình cơ sở dữ liệu được chọn (mô hình quan hệ, mô hình hướng đối tượng, mô hình quan hệ đối tượng...). Chuyên gia thực hiện thiết kế cơ sở dữ liệu mức lôgíc được gọi là nhà thiết kế cơ sở dữ liệu (database designer), nhưng thông thường, người quản trị cơ sở dữ liệu (database admin-istrator - DBA) sẽ thực hiện tất cả các phần việc trong bước thiết kế này. Bước thiết kế cuối cùng là thiết kế cơ sở dữ liệu mức vật lý (physical database design), bao gồm việc ánh xạ thiết kế lôgíc thành một hay nhiều thiết kế vật lý, mỗi thiết kế được gắn với một DBMS cụ thể, DBMS sẽ quản lý cơ sở dữ liệu và hệ thống máy tính mà cơ sở dữ liệu chạy trên đó. Người thực hiện thiết kế cơ sở dữ liệu mức vật lý thường là DBA. Các quy trình thiết kế cơ sở dữ liệu sẽ được đề cập trong Chương 5.

Ở những phần tiếp theo, chúng ta sẽ tìm hiểu các thành phần của một thiết kế cơ sở dữ liệu mức khái niệm, sau đó là các thành phần của thiết kế cơ sở dữ liệu mức lôgíc và mức vật lý.

Các thành phần của thiết kế cơ sở dữ liệu mức khái niệm

Hình 2-1 minh họa thiết kế cơ sở dữ liệu mức khái niệm của Northwind. Lược đồ này tương tự như Hình 1-7 trong Chương 1, tuy nhiên, có một số phần tử được thêm vào để minh họa cho những điểm chính. Những phần tử được gán nhãn (Thực thể - Entity, Thuộc tính - Attribute, Quan hệ - Relationship, Quy tắc nghiệp vụ - Business Rule, và Dữ liệu tương giao - Intersection Data) là các thành phần cơ bản tạo nên thiết kế cơ sở dữ liệu mức khái niệm. Từng phần tử này sẽ được trình bày ở các phần tiếp theo, ngoại trừ phần tử dữ liệu tương giao, sẽ được trình bày trong mục “Quan hệ nhiều - nhiều”.

Thực thểThực thể (entity) hay lớp thực thể (entity class) có thể là một người, địa điểm, sự vật, sự kiện, hay khái niệm chúng ta sẽ thu thập dữ liệu. Nói cách khác, thực thể là những sự vật trong thế giới thực

29Chương 2: Tìm hiểu các thành phần của cơ sở dữ liệu quan hệ

mà chúng ta quan tâm để nắm bắt và lưu trữ dữ liệu về chúng trong cơ sở dữ liệu. Trong lược đồ, thực thể được biểu diễn bởi một hình chữ nhật. Bất kỳ một thứ gì được đặt tên bằng một danh từ cũng có thể là một thực thể. Tuy nhiên, để tránh không thiết kế mọi thứ vào cơ sở dữ liệu, chúng ta giới hạn những thực thể mà người sử dụng cơ sở dữ liệu quan tâm. Mỗi thực thể trong mô hình khái niệm (Hình 2-1) biểu diễn toàn bộ lớp thực thể đó. Ví dụ, thực thể Customer biểu diễn tập các khách hàng của Northwind. Mỗi khách hàng riêng lẻ được gọi là một thể hiện (instance) của thực thể.

Thực thể bên ngoài (external entity) là thực thể mà cơ sở dữ liệu trao đổi dữ liệu (gửi/nhận dữ liệu hoặc cả hai) nhưng không thu thập dữ liệu từ thực thể đó. Ví dụ, hầu hết doanh nghiệp thiết lập tài khoản tín dụng cho khách hàng thường phải mua báo cáo đánh giá điểm tín dụng của khách hàng từ các cơ quan tín dụng. Họ gửi các thông tin của khách hàng tới cơ quan tín dụng và nhận về báo cáo, tuy nhiên, dữ liệu trong báo cáo chứa thông tin về khách hàng chứ không phải thông tin về cơ quan tín dụng. Giả sử, không có lý do thuyết phục nào cho việc lưu trữ dữ liệu về

Thực thể

Thuộc tính

Quan hệ

Quy tắc nghiệp vụ

Dữ liệu tương giao

Unit Price Quantity Discount

ProductProduct IDProduct Name Product Code DescriptionList PriceQuantity Per UnitCategory

Chú ý: Những khách hàng còn nợ đọng không được phép đặt đơn hàng mới.

OrderOrder ID Customer ID (FK)Employee ID (FK) Order Date Shipped Date Ship Address Ship City Shipping Fee

EmployeeEmployee ID Last NameFirst NameJob Title

CustomerCustomer IDConpany NameAddressCityState / Province Country / Region Business Phone

Account ReceivableAccount NumberCredit Score Balance Due Due DateOverdue AmountCustomer ID (FK)

Hình 2-1 Thiết kế cơ sở dữ liệu mức khái niệm của Northwind.


cơ quan tín dụng trong cơ sở dữ liệu, như địa chỉ mail văn phòng của cơ quan, khi đó, cơ quan tín dụng sẽ không xuất hiện với vai trò là một thực thể trong thiết kế cơ sở dữ liệu mức khái niệm. Thực tế, các thực thể bên ngoài hiếm khi được chỉ ra trong thiết kế cơ sở dữ liệu, tuy nhiên, chúng thường xuất hiện trong lược đồ luồng dữ liệu như một nguồn hoặc một đích đến của dữ liệu. Lược đồ luồng dữ liệu sẽ được đề cập ở Chương 7.

Thuộc tínhThuộc tính (attribute) là dữ kiện cơ sở, là đặc trưng cụ thể mô tả một thực thể theo cách xác định. Thuộc tính được biểu diễn bởi các tên nằm bên trong hình chữ nhật biểu diễn thực thể ở lược đồ thiết kế khái niệm trong Hình 2-1. Thuộc tính (hoặc các thuộc tính) nằm trên cùng của hình chữ nhật (phía trên đường nằm ngang), tạo thành định danh duy nhất (unique identifier) cho thực thể tương ứng. Một định danh duy nhất cung cấp giá trị duy nhất cho mỗi thể hiện của thực thể. Ví dụ, thuộc tính Customer ID là định danh duy nhất cho thực thể Customer, vì thế, mỗi khách hàng phải có một giá trị Customer ID duy nhất. Bạn hãy nhớ, định danh duy nhất có thể gồm nhiều thuộc tính, tuy nhiên, trong trường hợp này, các thuộc tính đó vẫn chỉ tạo nên một định danh duy nhất.

Chúng ta nói các thuộc tính là dữ kiện cơ sở vì chúng là nguyên tố, nghĩa là không thể phân chia thành những đơn vị có nghĩa nhỏ hơn. Do đó, một thuộc tính là đơn vị dữ liệu nhỏ nhất được đặt tên, xuất hiện trong một hệ thống cơ sở dữ liệu. Trong trường hợp này, thuộc tính Address có thể được coi là thuộc tính khả nghi vì có thể dễ dàng phân chia thành các thuộc tính Address Line 1, Address Line 2, và thậm chí là Address Line 3, điều này thường được áp dụng trong các hệ thống kinh doanh. Thay đổi này rất có ý nghĩa, vì ví dụ, nó giúp việc in các nhãn địa chỉ trở nên dễ dàng hơn. Mặt khác, việc thiết kế cơ sở dữ liệu không phải là môn khoa học chính xác và bạn hoàn toàn có thể đưa ra những phán xét cá nhân. Dù có thể phân chia thuộc tính Bussiness Phone thành các thuộc tính thành phần như: Country Code, Area Code, Prefix, Suffix, và Extension, song chúng ta phải đặt ra câu hỏi rằng, liệu những thay đổi đó có ý nghĩa hay không. Không có câu trả lời đúng hay sai ở đây, vì thế, chúng ta phải dựa vào ý kiến của người dùng cơ sở dữ liệu, hoặc có thể tham khảo ý kiến của những người tài trợ cho dự án cơ sở dữ liệu để có thể đưa ra quyết định đúng đắn. Luôn nhớ, một thuộc tính phải mô tả được một đặc điểm cụ thể của thực thể (ví dụ như, kích thước, hình dạng, màu sắc, số lượng, vị trí).

Quan hệQuan hệ (relationship) là sự liên kết giữa các thực thể. Vì cơ sở dữ liệu lưu trữ các dữ liệu có liên quan tới nhau, nên quan hệ có thể được coi là chất kết dính để giữ cơ sở dữ liệu gắn với nhau. Những quan hệ trong lược đồ thiết kế mức khái niệm (Hình 2-1) được biểu diễn bởi các đường nối một hoặc nhiều thực thể lại với nhau. Phần kết thúc của đường biểu diễn quan hệ cho biết lực lượng lớn nhất (maximum cardinality) của quan hệ, quy định số thể hiện tối đa của một thực thể có thể liên kết với thực thể đối diện ở cuối đường biểu diễn quan hệ. Lực lượng lớn nhất có thể bằng một (đường quan hệ không có ký tự đặc biệt nào tại vị trí kết thúc) hoặc nhiều (đường quan hệ tại vị trí kết thúc có hình vương miện). Lực lượng nhỏ nhất (minimum cardinality) được biểu diễn bởi một ký tự đặc biệt tại gần vị trí kết thúc của đường quan hệ, quy định số thể hiện nhỏ nhất của một thực thể có thể liên kết với thực thể nằm đối diện ở cuối đường biểu diễn quan hệ. Lực lượng nhỏ nhất có thể bằng 0, được ký hiệu bởi một vòng tròn trên đường quan hệ, hoặc


bằng 1, ký hiệu bởi một đường thẳng đứng vuông góc với đường quan hệ. Đa số chuyên gia mô hình hóa dữ liệu đều sử dụng các đường vuông góc để biểu diễn quan hệ “một và chỉ một”, như trong Hình 2-1.

Để hiểu rõ về quan hệ, bạn cần dành chút thời gian để thực hành; để biết cách định nghĩa và vẽ các quan hệ một cách chính xác, hãy thực hành nhiều hơn nữa. Thủ thuật ở đây là hãy nghĩ về sự kết hợp giữa các thực thể theo một chiều, sau đó đảo ngược góc nhìn, suy nghĩ về sự kết hợp giữa các thực thể theo chiều ngược lại. Ví dụ như, xét quan hệ giữa thực thể Customer và Order, chúng ta phải đặt ra hai câu hỏi: Mỗi khách hàng có thể có bao nhiêu đơn đặt hàng? Và ngược lại, mỗi đơn hàng có thể thuộc về bao nhiêu khách hàng? Các quan hệ có thể được chia thành ba kiểu: một - một, một - nhiều, nhiều - nhiều, sẽ được đề cập ở những phần tiếp theo. Một số người sẽ thắc mắc, nhiều - một cũng là một kiểu quan hệ; tuy nhiên, trong thực tế, quan hệ nhiều - một cũng chính là một - nhiều, nếu xem xét theo chiều ngược lại. Cách tốt nhất để hiểu về những kiểu quan hệ đó là xem xét qua các ví dụ. Xác định đúng quan hệ là điều cốt yếu để có thể thiết kế thành công.

Câu hỏi: Bạn nói, các quan hệ trong thiết kế mức khái niệm là quan hệ giữa một hoặc nhiều thực thể. Tuy nhiên, tôi luôn nghe rằng, những quan hệ trong RDBMS chỉ là quan hệ giữa hai bảng. Vậy điều này là như thế nào?

Trả lời: Thiết kế mức khái niệm thường được tạo ra ở mức trừu tượng hóa cao hơn so với cơ sở dữ liệu vật lý. Như bạn sẽ tìm hiểu trong những phần sau, các ràng buộc tham chiếu trong cơ sở dữ liệu quan hệ chỉ hỗ trợ quan hệ giữa hai bảng, ngoại trừ một trường hợp đặc biệt là quan hệ đệ quy (recursive relationship), chỉ bao gồm một bảng. Tuy nhiên, trong thiết kế mức khái niệm, nhà thiết kế có thể tự do biểu diễn quan hệ giữa nhiều hơn hai thực thể. Ví dụ, quan hệ giữa Order và Product trong Hình 2-1 có thể được biểu diễn trong thiết kế mức khái niệm bằng một quan hệ giữa ba thực thể Order, Product, và Shipping Ware-house (vị trí kho lưu trữ sản phẩm trong dòng chi tiết đơn hàng). Quan hệ đó phải được phân giải trong quá trình thiết kế mức lôgíc, cũng giống như dữ liệu tương giao trong Hình 2-1 (dữ liệu tương giao cuối cùng phải được lưu trong một bảng). Điều này có vẻ hơi khó hiểu; tuy nhiên, vấn đề sẽ trở nên rõ ràng hơn khi bạn tìm hiểu về thiết kế cơ sở dữ liệu trong những chương sau. Thực tế, ít khi tồn tại các quan hệ liên quan tới nhiều hơn hai thực thể. Việc phân tích những quan hệ đó thuộc về chủ đề nâng cao và do đó, những quan hệ như vậy không được sử dụng trong cuốn sách này.

Hỏi chuyên gia

Quan hệ một - mộtQuan hệ một - một (one-to-one relationship) là liên kết mà trong đó thể hiện của một thực thể được liên kết với nhiều nhất một thể hiện của một thực thể khác, và ngược lại. Trong Hình 2-1, quan hệ giữa thực thể Customer và Account Receivable là quan hệ một - một. Điều này có nghĩa là, một khách hàng có nhiều nhất một sổ ghi nợ và ngược lại, một sổ ghi nợ chỉ có thể thuộc về


nhiều nhất một khách hàng. Quan hệ một - một là là bắt buộc (mandatory) theo cả hai chiều, có nghĩa là một khách hàng phải có ít nhất một sổ ghi nợ, và một sổ ghi nợ phải thuộc về ít nhất một khách hàng. Kết hợp những điều trên, chúng ta có thể hiểu quan hệ giữa thực thể Customer và Account Receivable như sau: “Một khách hàng có một và chỉ một sổ ghi nợ, một sổ ghi nợ thuộc về một và chỉ một khách hàng”.

Một khái niệm quan trọng khác là tính khả chuyển (transferability). Một quan hệ được gọi là khả chuyển (transferable) nếu thể hiện của thực thể cha có thể thay đổi - hay nói cách khác, thể hiện của thực thể con có thể được gán cho một thể hiện khác của thực thể cha. Trong trường hợp này, quan hệ giữa thực thể Customer và Account Receivable rõ ràng là không khả chuyển, bởi chúng ta không thể lấy sổ ghi nợ của khách hàng này để gán cho khách hàng khác (thật tệ nếu điều này xảy ra trong kế toán). Thật không may, không có biểu tượng nào biểu diễn tính khả chuyển trong mô hình dữ liệu, song cần lưu ý tính chất này trong một số trường hợp, đặc biệt là trong quan hệ một - một bắt buộc theo cả hai chiều.

Thông thường, quan hệ một - một ít khi xảy ra giữa các thực thể. Trong thực tế, quan hệ một - một bắt buộc theo cả hai chiều và không có tính khả chuyển thể hiện lỗi thiết kế, song lỗi này có thể chỉnh sửa được bằng cách kết hợp hai thực thể với nhau. Như vậy, sổ ghi nợ có phải chỉ là một thông tin thêm của khách hàng? Chúng ta không có ý định thu thập dữ liệu về sổ ghi nợ; thay vào đó, thông tin về thực thể Account Receivable đơn giản chỉ là thông tin về khách hàng được thu thập thêm. Mặt khác, nếu chúng ta mua một phần mềm tài chính từ nhà cung cấp phần mềm độc lập (thực tế, thường là như vậy), gần như chắc chắn phần mềm đó đã kèm theo một cơ sở dữ liệu được định nghĩa trước, do đó, chúng ta không có lựa chọn nào khác. Chúng ta không thể thay đổi các thiết kế cơ sở dữ liệu của nhà cung cấp để thêm những dữ liệu chúng ta muốn có về khách hàng, và cũng không thể làm cho phần mềm của nhà cung cấp đó nhận biết được những dữ liệu lưu trong cơ sở dữ liệu của chúng ta.

Hình 2-2 cho thấy một quan hệ một - một “đặc biệt” khác, trong đó, hai phía của quan hệ là tùy chọn (optional), hay đôi khi gọi là có điều kiện (conditional), theo cả hai chiều. Giả sử, chúng ta đang thiết kế cơ sở dữ liệu cho một đại lý ô tô. Đại lý này phát một số ô tô cho nhân viên, thường là nhân viên bán hàng, để họ lái thử trong thời gian nhất định. Rõ ràng, đại lý đó không muốn phát tất cả ô tô cho nhân viên (nếu làm như vậy, họ sẽ không còn ô tô để bán). Chúng ta có thể hiểu quan hệ giữa thực thể Employee và Automobile như sau: “Tại một thời điểm bất kỳ, mỗi nhân viên có thể được phát cho một ô tô hoặc không được phát ô tô nào cả; và ngược lại, mỗi ô tô có thể được gán cho một nhân viên hoặc không nhân viên nào cả”. Hãy chú ý mệnh đề Tại

EmployeeEmployee IDFirst Name Last Name Job Title

AutomobileVIN MakeModelYearColorEmployee ID (FK)

Hình 2-2 Quan hệ Employee-automobile.


một thời điểm bất kỳ. Nếu một chiếc ô tô được thu hồi lại từ một nhân viên, sau đó được đưa cho một nhân viên khác thì quan hệ vẫn là một - một. Đó là do khi xem xét các quan hệ, chúng ta luôn tư duy vấn đề xảy ra trong một thời điểm cụ thể. Và như đã mô tả trước đó, quan hệ Employee-Automobile là quan hệ khả chuyển.

Quan hệ một - nhiềuQuan hệ một - nhiều (one-to-many relationship) là sự kết hợp giữa hai thực thể, trong đó một thể hiện bất kỳ của thực thể thứ nhất có thể liên kết với một hoặc nhiều thể hiện của thực thể thứ hai, và bất kỳ thể hiện nào của thực thể thứ hai đều có thể liên kết với nhiều nhất một thể hiện của thực thể thứ nhất. Hình 2-1 có hai quan hệ một - nhiều: Quan hệ Customer - Order và quan hệ Employee - Order. Quan hệ giữa thực thể Customer và Order bắt buộc phải theo một chiều, có thể được hiểu như sau: “Tại một thời điểm bất kỳ, mỗi khách hàng có thể không có hoặc có nhiều đơn hàng, và mỗi đơn hàng phải thuộc về một và chỉ một khách hàng”.

Quan hệ một - nhiều rất phổ biến. Trong thực tế, quan hệ một - nhiều là thành phần cơ bản tạo nên mô hình cơ sở dữ liệu quan hệ, vì các quan hệ trong cơ sở dữ liệu quan hệ đều được cài đặt là quan hệ một - nhiều. Trong quan hệ một - nhiều, rất ít khi phía “một” là tùy chọn, và càng hiếm khi phía “nhiều” là bắt buộc, song những tình huống như vậy vẫn xảy ra. Hãy xem xét ví dụ trong Hình 2-3. Khi đóng một tài khoản khách hàng, chúng ta lưu lại lý do tài khoản bị đóng bằng cách

Hình 2-3 Quan hệ một - nhiều.

Account Closure ReasonAccount Closure Reason CodeDescription

Customer Customer ID Company NameAddressCityState / Province Country / Region Business PhoneAccount Closure Reason Code (FK)

Credit ReportCredit Report NumberReport Date Credit Score NotesCustomer ID (FK)


sử dụng một mã lý do đóng tài khoản. Vì một số tài khoản có thể đang mở, nên mã lý do đóng tài khoản là tùy chọn. Chúng ta có thể hiểu quan hệ này như sau: “Tại một thời điểm xác định, mỗi mã lý do đóng tài khoản có thể được gán cho 0, 1, hoặc nhiều khách hàng, và mỗi khách hàng có thể có 0 hoặc 1 mã lý do đóng tài khoản”. Giả sử, một công ty có chính sách là không cho phép mở bất kỳ tài khoản khách hàng nào khi chưa nhận được báo cáo tín dụng về khách hàng đó, và tất cả các báo cáo đều được lưu trong cơ sở dữ liệu. Điều đó có nghĩa là, một khách hàng bất kỳ có thể có nhiều hơn một báo cáo tín dụng trong cơ sở dữ liệu. Điều này làm cho quan hệ giữa thực thể Customer và Credit Report là quan hệ một - nhiều, và bắt buộc theo cả hai chiều. Chúng ta có thể hiểu quan hệ này như sau: “Tại một thời điểm xác định, mỗi khách hàng có thể có một hoặc nhiều báo cáo tín dụng, và mỗi báo cáo tín dụng thuộc về một và chỉ một khách hàng”.

Quan hệ nhiều - nhiềuQuan hệ nhiều - nhiều (many-to-many relationship) là sự kết hợp giữa hai thực thể, trong đó một thể hiện bất kỳ của thực thể thứ nhất có thể liên kết với 0, 1 hoặc nhiều thể hiện của thực thể thứ hai, và ngược lại. Trở lại Hình 2-1, quan hệ giữa thực thể Order và Product là quan hệ nhiều - nhiều. Chúng ta có thể hiểu quan hệ này như sau: “Tại một thời điểm bất kỳ, mỗi đơn hàng có thể không chứa hoặc chứa nhiều sản phẩm, và mỗi sản phẩm có thể xuất hiện trong nhiều đơn hàng hoặc không xuất hiện trong đơn hàng nào cả”.

Quan hệ này có dữ liệu liên kết, được biểu diễn trong hình thoi ở Hình 2-1. Dữ liệu thuộc về quan hệ nhiều - nhiều được gọi là dữ liệu tương giao (intersection data). Dữ liệu tương giao không có ý nghĩa, trừ khi nó được liên kết với cả hai thực thể cùng một lúc. Ví dụ, thuộc tính Quantity (số lượng) không có ý nghĩa, trừ khi bạn biết khách hàng là ai và sản phẩm là gì. Nếu nhìn lại Hình 1-7 trong Chương 1, bạn sẽ nhận thấy dữ liệu tương giao trong bảng Order Detail của mô hình cơ sở dữ liệu Northwind. Vậy tại sao không coi Order Detail là một thực thể? Câu trả lời rất đơn giản: Order Detail không thỏa mãn định nghĩa của một thực thể. Chúng ta không thu thập dữ liệu về các dòng chi tiết trong đơn hàng; thay vào đó, những dòng chi tiết này chỉ đơn giản là thông tin thêm về đơn hàng.

Quan hệ nhiều - nhiều rất phổ biến, và hầu hết đều có dữ liệu tương giao đi kèm. Dù vậy, mô hình quan hệ không trực tiếp hỗ trợ kiểu quan hệ nhiều - nhiều. Trong thiết kế mức khái niệm, quan hệ nhiều - nhiều có thể được biểu diễn dễ dàng, bởi thiết kế mức khái niệm hoàn toàn không phụ thuộc vào bất kỳ công nghệ cụ thể nào. Tuy nhiên, nếu cơ sở dữ liệu được chọn theo mô hình quan hệ, khi ánh xạ mô hình khái niệm sang mô hình lôgíc tương ứng, bạn cần thay đổi một chút. Giải pháp là ánh xạ dữ liệu tương giao thành một bảng riêng, gọi là bảng tương giao (intersection table), đồng thời ánh xạ quan hệ nhiều - nhiều thành hai quan hệ một - nhiều, bảng tương giao sẽ nằm ở giữa và ở phía “nhiều” trong cả hai quan hệ một - nhiều. Hình 1-7 đưa ra kết quả cho giải pháp này, bảng Order Detail chứa dữ liệu tương giao và tham gia vào hai quan hệ một - nhiều, thay thế cho quan hệ nhiều - nhiều ban đầu. Quy trình nhận biết và xử lý các vấn đề liên quan tới quan hệ nhiều - nhiều sẽ được đề cập chi tiết trong Chương 6.


Quan hệ đệ quyĐến đây, bạn đã tìm hiểu về quan hệ giữa những thể hiện của các thực thể khác nhau. Tuy nhiên, quan hệ có thể tồn tại giữa các thể hiện cùng loại. Và những quan hệ như vậy được gọi là quan hệ đệ quy (recursive relationship). Tất cả các quan hệ đã được trình bày (một - một, một - nhiều, nhiều - nhiều) cũng có thể là quan hệ đệ quy. Hình 2-4 và danh sách dưới đây đưa ra một số ví dụ về quan hệ đệ quy:

● Một - một Nếu muốn thống kê các nhân viên kết hôn với nhân viên khác, chúng ta mong muốn mỗi nhân viên có thể kết hôn với một hoặc không nhân viên khác tại một thời điểm.

EmployeeEmployee IDLast Name First Name Job TitleSpouse Employee ID (FK)

EmployeeEmployee IDLast Name First Name Job TitleManager Employee ID (FK)

Part Part ID Description

Một - một: Mỗi nhân viên có thể kết hôn với một nhân viên khác hoặc không kết hôn với ai cả.

Một - nhiều: Một nhân viên có thể quản lý các nhân viên khác.

Nhiều - nhiều: Mỗi bộ phận có thể chứa các bộ phận khác; mỗi bộ phận có thể là một thành phần của các bộ phận khác.

Hình 2-4 Các ví dụ về quan hệ đệ quy.

● Một - nhiều Việc theo dõi và quản lý nhân viên là việc làm rất phổ biến. Trong hầu hết các tổ chức, mọi người thường có một người quản lý cấp trên. Vì vậy, chúng ta thường mong muốn mỗi nhân viên chịu sự quản lý của một nhân viên khác hoặc không ai cả, và những người làm quản lý, giám sát lại trực tiếp quản lý một hoặc nhiều nhân viên.

● Nhiều - nhiều Trong môi trường sản xuất, một quan hệ rất phổ biến là quan hệ giữa các bộ phận tạo thành sản phẩm hoàn thiện. Ví dụ, ổ đĩa CD-ROM trong máy tính cá nhân, bạn có thể hình dung rằng ổ đĩa CD gồm rất nhiều linh kiện khác nhau, tuy nhiên trong toàn bộ dây chuyền lắp ráp máy tính, các linh kiện đó không được nhìn thấy và chỉ có một bộ phận duy nhất là ổ CD. Như vậy, một bộ phận bất kỳ có thể được tạo thành từ nhiều bộ phận khác, đồng thời bộ phận đó có thể là một thành phần của các bộ phận khác.

Quy tắc nghiệp vụQuy tắc nghiệp vụ (business rule) là các chính sách, thủ tục hay những tiêu chuẩn mà một tổ chức tuân thủ và làm theo. Quy tắc nghiệp vụ rất quan trọng trong thiết kế cơ sở dữ liệu vì nó quyết định việc đặt các điều khiển lên dữ liệu. Trong Hình 2-1, bạn có thể thấy một quy tắc nghiệp vụ quy định rằng, các đơn hàng chỉ được chấp nhận khi khách hàng không có dư nợ quá hạn. Hầu hết quy tắc nghiệp vụ có thể được thực thi thông qua những thủ tục sổ sách mà nhân viên là người được chỉ đạo làm theo, hoặc thông qua các quy tắc lôgíc trong chương trình ứng dụng. Dù vậy, quy tắc nghiệp vụ có thể không được tuân thủ - các nhân viên có thể quên hoặc cố tình không làm


theo các thủ tục đã được quy định trong các tài liệu liên quan. Một số người dùng được cấp quyền đặc biệt có thể cập nhật trực tiếp cơ sở dữ liệu, bỏ qua sự kiểm soát của chương trình ứng dụng. Cơ sở dữ liệu có thể đóng vai trò “tuyến phòng thủ cuối cùng” bảo vệ dữ liệu và thực thi các quy tắc nghiệp vụ. Trong cơ sở dữ liệu, quy tắc nghiệp vụ được cài đặt bởi các ràng buộc (constraint), đó là những quy tắc được định nghĩa chính thức, có tác dụng giới hạn giá trị dữ liệu trong cơ sở dữ liệu. Những thông tin bổ sung về ràng buộc có thể được tìm thấy trong mục “Ràng buộc” của chương này. Lưu ý, quy tắc nghiệp vụ thường không xuất hiện trong lược đồ mô hình dữ liệu khái niệm; quy tắc nghiệp vụ trong Hình 2-1 chỉ có tính chất minh họa. Quy tắc nghiệp vụ thường được bao gồm trong các tài liệu văn bản đi kèm lược đồ khái niệm.

Bài tập mẫu 2-1 Tìm hiểu về cơ sở dữ liệu Northwind

Trong phần còn lại của chương này cũng như ở Chương 3, chúng ta sử dụng Microsoft Access 2007 và cơ sở dữ liệu Northwind để giải thích cho các khái niệm được đề cập. Trong bài tập mẫu này, bạn sẽ kết nối tới cơ sở dữ liệu mẫu Northwind theo một trong hai cách: Trên máy tính cá nhân và thông qua Microsoft Office Online, sau đó làm quen với việc điều hướng trong Access để dễ dàng theo dõi các bài tập ví dụ ở chương này và Chương 3. Bạn nên biết, Access 2007 có giao diện và cách sử dụng hoàn toàn khác so với những phiên bản cũ, vì thế, nếu bạn sử dụng phiên bản Access cũ thì việc theo dõi các ví dụ trong cuốn sách này có thể gặp khó khăn. Tuy nhiên, có một giải pháp rất đơn giản là Microsoft Office Online, bạn chỉ cần một trình duyệt web và máy tính có kết nối Internet.

Việc lựa chọn Microsoft Access để giải thích các khái niệm chỉ đơn giản nhằm mục đích thuận tiện hơn, và ở đây không có ý định so sánh Access 2007 với những sản phẩm khác. Thực tế, khi đề cập về SQL trong Chương 4, chúng ta sẽ sử dụng một RDBMS khác là Oracle để minh họa các ví dụ.

Các bước tiến hành1. Nếu bạn đã có sẵn Microsoft Access 2007, hãy tải và cài đặt cơ sở dữ liệu mẫu Northwind

theo các bước sau đây:

a. Khởi động Access 2007 từ menu Start mà không mở cơ sở dữ liệu.

b. Ở bên trái bảng điều khiển Getting Started, nhấn vào Sample nằm dưới tiêu đề From Microsoft Office Online.

c. Nhấn vào biểu tượng Northwind 2007.

d. Ở góc dưới cùng bên phải của bảng điều khiển, nhấn vào nút Download và đáp ứng lại bất kỳ yêu cầu nào xuất hiện.

e. Khi đã kết nối tới cơ sở dữ liệu, một màn hình như trong Hình 2-5 sẽ được hiển thị.


2. Nếu chưa cài đặt Microsoft Access 2007, bạn có thể truy cập thông qua Microsoft Office Online bằng cách sử dụng trình duyệt web và làm theo các bước sau:

a. Nhập địa chỉ URL http://office.microsoft.com/en-us/products/ vào trình duyệt và nhấn ENTER.

b. Tại chính giữa màn hình trình duyệt, tìm và nhấn vào liên kết Try Office 2007 Online.

c. Trong trang tiếp theo, nhấn nút Launch Test Drive và phản hồi lại bất kỳ yêu cầu nào xuất hiện. Quá trình tải phần mềm và thiết lập kết nối tới cơ sở dữ liệu có thể mất vài phút.

Hình 2-5 Màn hình khởi động của cơ sở dữ liệu Northwind.

d. Trong trang Tutorial Menu, nhấn vào Office Access 2007.

e. Ở lề trái bảng điều khiển Getting Started, hãy nhấn Sample nằm dưới tiêu đề From Mi-crosoft Online.

f. Tại góc dưới cùng bên trái của bảng điều khiển (bạn có thể phải mở rộng trình duyệt toàn màn hình mới có thể nhìn thấy được), nhấn nút Download và phản hồi lại bất kỳ yêu cầu nào xuất hiện. Đặc biệt, hãy chú ý một số điều sau đây:


● Có thể có một hoặc nhiều thông báo về việc chạy các add-on từ trang web. Những thông báo này xuất hiện ở gần phía trên cùng màn hình, ngay bên dưới dòng các ngôi sao màu vàng, thường có màu nền vàng nhạt (giống như thông báo Security Warning trong Hình 2-5).

● Bạn sẽ phải phản hồi lại thông báo Security Warning trong Hình 2-5. Hãy nhấn nút Options trên dòng thông báo và lựa chọn cho phép kích hoạt nội dung.

● Khi mở cơ sở dữ liệu lần đầu tiên, một màn hình hiển thị yêu cầu bạn đăng nhập. Nếu điều này xảy ra, hãy nhấn vào tùy chọn Cancel.

g. Khi đã kết nối tới cơ sở dữ liệu, một màn hình như trong Hình 2-5 sẽ hiển thị.

3. Trên dải chức năng (vùng nằm dài theo phía trên cùng của bảng điều khiển, chứa các tùy chọn), nhấn vào Database Tools và chọn Relationships. Bảng điều khiển Relationships xuất hiện, hiển thị 18 bảng cùng quan hệ giữa các bảng đó. Các bảng được bố trí rất sát nhau, song nếu dựa vào những đường nối giữa chúng, bạn có thể dễ dàng quan sát từng quan hệ.

4. Đóng bảng điều khiển Relationships bằng cách nhấn vào nút X ngay bên phải tab Relationships.

5. Mở rộng khung Navigation Pane (nằm dọc lề trái của bảng điều khiển) bằng cách nhấn vào biểu tượng >> trên cùng của khung. Cơ sở dữ liệu Northwind chứa một số màn hình, báo cáo và các đối tượng được sử dụng để minh họa cho những tính năng lập trình trong Microsoft Access 2007. Tuy nhiên, chúng ta sẽ chỉ quan tâm tới những đối tượng liên quan tới cơ sở dữ liệu (việc lập trình ứng dụng không thuộc phạm vi của cuốn sách này). Mở rộng nhóm Supporting Objects để quan sát danh sách tất cả các bảng có trong cơ sở dữ liệu Northwind. Với mỗi bảng, bạn có thể nhấn chuột phải vào tên bảng và chọn Open để xem nội dung của bảng, hoặc Design View để xem định nghĩa của bảng. Bạn không cần hiểu mọi thứ vào thời điểm này - các bảng điều khiển trên sẽ được giới thiệu chi tiết ở những phần tiếp theo.

6. Đóng Microsoft Access 2007 (hoặc Office 2007 Online và cửa sổ trình duyệt).

Tổng kết bài tập mẫuBạn vừa truy cập thành công tới cơ sở dữ liệu mẫu Northwind sẽ được sử dụng để minh họa cho các khái niệm trong phần còn lại của chương này cũng như chương tiếp theo. Bạn cũng đã điều hướng qua bảng điều khiển Relationships và nhóm Supporting Objects trong Navigation Pane.

Các thành phần của thiết kế cơ sở dữ liệu mức lôgíc/mức vật lý

Thiết kế cơ sở dữ liệu mức lôgíc được thực hiện trong lớp lôgíc theo mô hình ANSI/SPARC đã đề cập ở Chương 1. Thiết kế cơ sở dữ liệu mức vật lý được thực hiện trong lớp vật lý của mô hình ANSI/SPARC. Tuy nhiên, lớp vật lý được cài đặt thông qua DBMS, khiến việc phân tách lớp lôgíc và lớp vật lý trở nên khó khăn. Ví dụ, khi tạo bảng, chúng ta thêm một mệnh đề vào trong lệnh create table để thông báo cho DBMS biết vị trí cần đặt bảng. Sau đó, DBMS sẽ tự động cấp phát không gian cho bảng trên các file hệ điều hành đã được chỉ định. Do hầu hết phép cài đặt vật


lý đều diễn ra trong định nghĩa DBMS của cấu trúc lôgíc, nên chúng ta sẽ không tách riêng hai lớp này. Trong quá trình thiết kế cơ sở dữ liệu mức lôgíc, các thuộc tính lưu trữ vật lý (như tên file hoặc tên không gian bảng (tablespace), vị trí lưu trữ, thông tin về kích thước) có thể được gán cho từng đối tượng trong cơ sở dữ liệu khi ánh xạ chúng từ mô hình khái niệm, hoặc chúng ta có thể bỏ qua những thuộc tính đó và thêm vào sau trong quá trình thiết kế vật lý. Để tiết kiệm thời gian, hầu hết các DBA đều thực hiện việc thiết kế lôgíc song song với việc thiết kế vật lý.

BảngĐơn vị lưu trữ cơ bản trong mô hình quan hệ là bảng (table), có cấu trúc hai chiều được tạo thành từ các hàng và cột. Mỗi hàng tương ứng với một thể hiện của thực thể mà bảng đại diện, và mỗi cột tương ứng với một thuộc tính của thực thể đó. Quá trình ánh xạ các thực thể trong thiết kế khái niệm thành các bảng trong thiết kế lôgíc được gọi là chuẩn hóa (normalization), sẽ được đề cập chi tiết ở Chương 6. Thường thì một thực thể trong mô hình khái niệm sẽ ánh xạ chính xác tới một bảng tương ứng trong mô hình lôgíc, tuy nhiên, điều này không phải luôn đúng trong mọi trường hợp. Lý do bạn cần hiểu rõ về quá trình chuẩn hóa là, thông thường, các thực thể được phân chia thành nhiều bảng, nhưng trong một số ít trường hợp, nhiều thực thể lại được kết hợp thành một bảng duy nhất. Hình 2-6 liệt kê một phần nội dung của bảng Orders trong cơ sở dữ liệu Northwind.

Bạn cần nhớ, bảng quan hệ là một cấu trúc lưu trữ lôgíc và thường không tồn tại ở dạng bảng trong lớp vật lý. Khi người quản trị gán một bảng cho một số file hệ điều hành trong lớp vật lý

Hình 2-6 Bảng Orders trong (một phần) cơ sở dữ liệu Northwind.


(trong hầu hết RDBMS, đơn vị lưu trữ lôgíc được tạo từ các file này được gọi là không gian bảng), nhiều bảng có thể được đặt trong cùng một không gian bảng. Tuy nhiên, các bảng lớn có thể được đặt trong không gian bảng riêng, hoặc được phân chia vào nhiều không gian bảng khác nhau, điều này được gọi là phân hoạch (partitioning). Tính năng linh hoạt này thường không được hỗ trợ trong các RDBMS trên máy tính cá nhân như Microsoft Access.

Mỗi bảng phải được gán một tên duy nhất và do DBA quy định. Độ dài tối đa của tên bảng rất khác nhau tùy thuộc vào từng sản phẩm RDBMS, từ ít nhất là 18 ký tự tới nhiều nhất là 255 ký tự. Nên đặt tên bảng mang tính chất mô tả và phản ánh đúng ý nghĩa của thực thể tương ứng trong thế giới thực. Theo quy ước, một số DBA thường sử dụng danh từ số ít để đặt tên cho các thực thể và danh từ số nhiều cho tên của các bảng, bạn sẽ thấy quy ước này trong cơ sở dữ liệu Northwind. (Tôi thích sử dụng danh từ số ít để đặt tên cho cả thực thể và bảng, nhưng rõ ràng, các chuyên gia khác có những ý kiến ngược lại). Bạn nên thiết lập một tiêu chuẩn đặt tên riêng nhằm đảm bảo tính thống nhất, nếu không, rất dễ gây nhầm lẫn sau này. Thực tế, Microsoft Access cho phép sử dụng ký tự khoảng trắng trong tên của bảng và cột, nhưng như vậy được coi là trái với tiêu chuẩn công nghiệp. Ngoài ra, Microsoft Access, Sybase ASE, và Microsoft SQL Server đều cho phép sử dụng kết hợp chữ thường và chữ hoa để đặt tên cho các bảng và cột, ví dụ tên bảng OrderDetails. Trong khi đó, Oracle, DB2, MySQL trên Windows lại tự động chuyển đổi tên các đối tượng thành dạng chữ hoa, trừ khi những tên đó được đặt trong dấu ngoặc kép (“ ”). Những tên chữ hoa như ORDERDETAILS rất khó theo dõi, vì thế, việc sử dụng dấu gạch chân để phân tách các từ là một lựa chọn tốt, phù hợp với tiêu chuẩn công nghiệp. Có thể bạn sẽ muốn một tiêu chuẩn cấm việc sử dụng các tên, trong đó có cả ký tự khoảng trắng, hoặc tên có cả chữ hoa và chữ thường, vì những tên như vậy không tuân theo tiêu chuẩn nào và khiến việc chuyển đổi dữ liệu giữa các sản phẩm RDBMS trở nên khó khăn hơn.

Hỏi chuyên gia Câu hỏi: Bạn đã đề cập tới cả file và không gian bảng. Vậy chúng có giống nhau

không?

Trả lời: Bạn có thể hình dung không gian bảng giống như một file lôgíc tạo thành một lớp trừu tượng nằm giữa lớp vật lý và lớp lôgíc, do đó, không gian bảng giúp tăng tính độc lập dữ liệu lôgíc. Một không gian bảng có thể bao gồm một hoặc nhiều file vật lý. Và thay vì gán bảng vào file vật lý, bạn gán chúng vào không gian bảng. Điều này cho phép xử lý linh hoạt file vật lý tạo nên cơ sở dữ liệu. Ví dụ, khi không gian bảng đầy, người quản trị có một lựa chọn là thêm vào không gian bảng một file từ một thiết bị lưu trữ khác (như ổ đĩa).

Các cột và kiểu dữ liệuNhư đã đề cập, mỗi cột trong bảng quan hệ biểu diễn một thuộc tính trong mô hình khái niệm. Cột (column) là đơn vị dữ liệu nhỏ nhất được đặt tên mà có thể được tham chiếu tới trong cơ sở


dữ liệu quan hệ. Mỗi cột phải được gán một tên duy nhất (trong phạm vi một bảng) và một kiểu dữ liệu xác định. Kiểu dữ liệu (data type) là kiểu định dạng cho một cột cụ thể. Kiểu dữ liệu có những ưu điểm sau:

● Giới hạn dữ liệu trong cột để chỉ chấp nhận những ký tự phù hợp với kiểu dữ liệu (ví dụ, tất cả các chữ số, hoặc chỉ những ký tự ngày tháng hợp lệ).

● Cung cấp một tập các hành vi hữu dụng cho người dùng cơ sở dữ liệu. Ví dụ, nếu trừ một số cho một số khác, bạn sẽ có kết quả là một số; nhưng nếu trừ các giá trị ngày tháng cho nhau, bạn sẽ nhận về một số biểu diễn số ngày nằm giữa hai ngày đó.

● Hỗ trợ RDBMS trong việc lưu trữ hiệu quả dữ liệu trong cột. Ví dụ, số thường được lưu dưới định dạng số để tiết kiệm không gian lưu trữ hơn so với việc lưu số dưới dạng chuỗi ký tự.

Hình 2-7 đưa ra định nghĩa bảng Orders của Northwind được mở trong Microsoft Access 2007 (chính là bảng được liệt kê ở Hình 2-6). Kiểu dữ liệu của các cột được hiển thị ở cột thứ hai. Tên kiểu dữ liệu rất trực quan, nhưng nếu thấy khó hiểu, bạn có thể xem định nghĩa của những kiểu dữ liệu này trên trang trợ giúp của Microsoft Access.

Hình 2-7 Định nghĩa bảng Orders của Northwind (Microsoft Access 2007).


LƯU ÝNếu so sánh Hình 2-6 và Hình 2-7, bạn có thể thấy các cột Employee Name và Customer Name trong Hình 2-6 thay thế cho cột Employee ID và Customer ID trong định nghĩa của bảng Orders ở Hình 2-7. Đây không phải lỗi mà là một tính năng của Microsoft Access, sẽ được đề cập trong mục “Ràng buộc tham chiếu” ở phần sau của chương này.

Điều đáng tiếc nhất là các tiêu chuẩn công nghiệp thường tụt hậu so với sự phát triển của RDBMS. Hầu hết nhà cung cấp đều tự phát triển các tính năng cho sản phẩm của họ trước khi cùng ngồi lại với những nhà cung cấp khác để đưa ra tiêu chuẩn. Điều này giải thích tại sao lại có sự khác biệt lớn về kiểu dữ liệu trong các sản phẩm RDBMS. Ngày nay, tiêu chuẩn ANSI/ISO SQL bao hàm mọi kiểu dữ liệu quan hệ và các nhà cung cấp đều hỗ trợ tất cả hoặc hầu hết kiểu dữ liệu tiêu chuẩn. Tuy nhiên, mỗi nhà cung cấp vẫn có những “mở rộng” riêng ngoài chuẩn, họ không chỉ hỗ trợ những kiểu dữ liệu mới hơn các tiêu chuẩn hiện hành mà còn thêm những tính năng đặc biệt, làm cho sản phẩm của họ trở nên đặc biệt hơn so với đối thủ. Người ta có thể nói đùa rằng, điều tuyệt vời nhất về các tiêu chuẩn cơ sở dữ liệu là có rất nhiều tiêu chuẩn để lựa chọn. Về mặt tiêu chuẩn công nghiệp cho cơ sở dữ liệu quan hệ, Microsoft Access có lẽ là một trong những sản phẩm ít tuân thủ nhất. Do có rất nhiều tiêu chuẩn và mở rộng từ nhà cung cấp, nên DBA phải là người có kiến thức chuyên sâu về những kiểu dữ liệu DBMS hiện đang hỗ trợ để triển khai cơ sở dữ liệu thành công. Và dĩ nhiên, phải rất cẩn thận khi chuyển đổi thiết kế lôgíc giữa các DBMS của những nhà cung cấp khác nhau.

Bảng 2-1 cho thấy các kiểu dữ liệu tương đương từ nhiều nhà cung cấp RDBMS khác nhau. Tuy nhiên, cần nhớ rằng, những kiểu dữ liệu được liệt kê ở đây không giống hệt nhau mà chỉ tương đương.Ví dụ, kiểu VARCHAR trong Oracle có thể có độ dài lên tới 4000 ký tự (ở các phiên bản Oracle8i, độ dài tối đa là 2000 ký tự), tuy nhiên kiểu dữ liệu MEMO tương đương trong Mi-crosoft Access có thể chứa hàng gigabyte ký tự (khoảng 1 tỷ ký tự)!

Ràng buộcRàng buộc (constraint) là quy tắc được đặt vào một đối tượng cơ sở dữ liệu (thường là một bảng hoặc một cột) để giới hạn giá trị dữ liệu cho phép đối với đối tượng cơ sở dữ liệu đó. Bảng và cột là các đối tượng quan trọng nhất trong cơ sở dữ liệu quan hệ mà chúng ta sử dụng các ràng buộc thể cài đặt các quan hệ và quy tắc nghiệp vụ được chỉ ra trong thiết kế lôgíc. Mỗi ràng buộc được gán một tên duy nhất, cho phép tham chiếu tới ràng buộc đó trong các thông báo lỗi và câu lệnh. Một thói quen tốt đối với các DBA là luôn gán tên cho ràng buộc, bởi nếu không làm điều này, RDBMS sẽ tự động sinh ra một tên cho ràng buộc, và tên đó thường không có tính mô tả.


Kiểu dữ liệu Microsoft Access Microsoft SQL Server Oracle

Chuỗi ký tự có độ dài xác định

TEXT CHAR CHAR

Chuỗi ký tự có độ dài biến đổi

MEMO VARCHAR VARCHAR

Văn bản dài MEMO TEXT CLOB hoặc LONG (Đã lỗi thời, khuyến cáo không nên sử dụng)

Số nguyên INTEGER hoặc LONGINTEGER

INTEGER hoặc SMALLINT hoặc TINYINT

NUMBER

Số thập phân NUMBER DECIMAL hoặc NUMERIC NUMBER

Tiền tệ CURRENCY MONEY hoặc SMALLMONEY Không có, sử dụng NUMBER

Ngày/giờ DATE/TIME DATETIME hoặc SMALLDATE-TIME

DATE hoặc TIME-STAMP

Bảng 2-1 Những kiểu dữ liệu tương đương trong các sản phẩm RDBMS chính.

Ràng buộc khóa chínhKhóa chính (primary key) là một cột hoặc tập hợp các cột xác định duy nhất một dòng bản ghi trong bảng. Định danh duy nhất trong thiết kế mức khái niệm được cài đặt bằng một khóa chính trong thiết kế lôgíc. Biểu tượng hình chiếc khóa ngay cạnh trường Order ID trong Hình 2-7 biểu thị rằng, cột này được định nghĩa là khóa chính của bảng Orders. Khi định nghĩa khóa chính, RDBMS sẽ cài đặt một ràng buộc khóa chính để đảm bảo không tồn tại hai dòng trong bảng có cùng giá trị khóa chính. Chú ý, nếu khóa chính được tạo thành từ nhiều cột, mỗi cột có thể có giá trị trùng nhau trong bảng, nhưng khi kết hợp những giá trị trong các cột của khóa chính thì giá trị kết hợp đó phải là duy nhất trong bảng.

Hầu hết các ràng buộc khóa chính được cài đặt trong RDBMS bằng cách sử dụng chỉ mục (index), một kiểu đối tượng đặc biệt trong cơ sở dữ liệu, cho phép tìm kiếm nhanh các giá trị cột. Khi thêm một dòng vào bảng, RDBMS tự động tìm kiếm trên chỉ mục để đảm bảo giá trị khóa chính của dòng mới chưa được sử dụng trong bảng, nếu giá trị khóa đã tồn tại, dòng mới thêm vào sẽ bị từ chối. Chỉ mục được tìm kiếm nhanh hơn so với bảng; vì thế, việc áp dụng chỉ mục cho khóa chính trong bảng là rất cần thiết, giúp việc tìm những khóa trùng nhau khi thêm các dòng mới trở nên nhanh chóng.

Ràng buộc tham chiếuĐể hiểu phương pháp RDBMS sử dụng ràng buộc tham chiếu thực thi các quan hệ, trước tiên, bạn phải nắm được khái niệm khóa ngoại. Khi quan hệ một - nhiều được thực thi trong bảng, cột hoặc tập các cột được lưu trong bảng con (bảng tương ứng với phía “nhiều” trong quan hệ) có chức


năng liên kết bảng đó với một bảng cha (bảng tương ứng với phía “một” trong quan hệ), được gọi là một khóa ngoại (foreign key). Được gọi là khóa ngoại bởi vì cột (các cột) được sao chép từ một bảng khác (bảng ngoài). Trong bảng Orders (Hình 2-6), cột Employee ID là khóa ngoại liên kết tới bảng Employees, và cột Customer ID là khóa ngoại liên kết tới bảng Customers.

Trong hầu hết cơ sở dữ liệu quan hệ, khóa ngoại phải là khóa chính của bảng cha, hoặc là một cột hay tập các cột có định nghĩa một chỉ mục duy nhất. Điều này nhằm mục đích tăng tốc độ xử lý. Phần lớn mọi người đều tán thành việc cột (các cột) khóa ngoại cùng tên với cột (các cột) khóa chính trong bảng cha, tuy nhiên vẫn có những ý kiến trái chiều, và lý do được đưa ra là các tên trùng nhau như vậy sẽ gây khó khăn trong ngôn ngữ truy vấn. Tốt nhất, ngay từ đầu, bạn nên thiết lập một số tiêu chuẩn và tuân thủ theo những tiêu chuẩn đó trong suốt dự án cơ sở dữ liệu.

Mỗi quan hệ giữa các thực thể trong thiết kế mức khái niệm được ánh xạ tương ứng thành một ràng buộc tham chiếu trong thiết kế lôgíc. Ràng buộc tham chiếu (referential constraint), còn được gọi là ràng buộc toàn vẹn tham chiếu (referential integrity constraint) là ràng buộc bắt buộc thực hiện một quan hệ giữa các bảng trong cơ sở dữ liệu quan hệ. Bắt buộc thực hiện có nghĩa là RDBMS tự động kiểm tra để đảm bảo mỗi giá trị khóa ngoại trong bảng con luôn có một giá trị khóa chính tương ứng trong bảng cha.

Microsoft Access cung cấp một tính năng rất thú vị đối với các cột khóa ngoại, tuy nhiên, bạn cần chút ít thời gian để làm quen với tính năng đó. Khi định nghĩa ràng buộc tham chiếu, bạn có thể định nghĩa một phép tìm kiếm tự động trong các dòng của bảng cha. Ở Hình 2-7, cột thứ ba trong bảng Orders được hiển thị Customer ID. Tuy nhiên, ở Hình 2-6, bạn có thể thấy cột thứ ba trong bảng Orders là cột Customer, hiển thị tên khách hàng. Nếu nhấn vào cột Customer ở một dòng bất kỳ, một menu xổ xuống xuất hiện, cho phép bạn chọn những khách hàng hợp lệ (từ bảng Customers) làm cha (chủ) của dòng đang chọn trong bảng Orders. Tương tự, cột Employee ID của bảng Orders hiển thị tên nhân viên. Tính năng này rất dễ sử dụng và tiện lợi cho người dùng, ngăn không cho phép kết hợp một khách hàng hay một nhân viên không tồn tại với một đơn hàng. Tuy nhiên, tính năng này lại ẩn đi khóa ngoại, và vì thế, Hình 2-6 không hữu dụng khi minh họa cho hoạt động của ràng buộc tham chiếu. Hình 2-8 liệt kê các phần tử trong bảng Orders với tính năng tự động tìm kiếm đã được vô hiệu hóa, bạn có thể thấy các giá trị khóa ngoại thực sự ở cột Employee ID và Customer ID.

Khi cập nhật bảng Orders (như ở Hình 2-8), RDBMS sẽ thực thi các ràng buộc tham chiếu mà chúng ta đã định nghĩa trong bảng. Điểm mạnh của ràng buộc cơ sở dữ liệu là chúng được thực thi tự động, vì thế các ràng buộc luôn có hiệu lực trừ khi bị DBA vô hiệu hóa.

Dưới đây là những sự kiện đặc biệt mà RDBMS phải xử lý khi thực thi các ràng buộc tham chiếu:


Hình 2-8 Bảng Orders của Northwind (với các giá trị khóa ngoại).

● Khi bạn chèn một dòng mới vào bảng con, phép chèn sẽ bị từ chối nếu không tồn tại dòng tương ứng trong bảng cha. Ví dụ, nếu bạn chèn một dòng vào bảng Orders với giá trị cột Em-ployee ID bằng 12345, RDBMS sẽ kiểm tra xem trong bảng Employees có nhân viên với mã số (Employee ID) 12345 hay không. Nếu không có, phép chèn sẽ thất bại.

● Khi bạn cập nhật một khóa ngoại trong bảng con, phép cập nhật sẽ bị từ chối nếu giá trị khóa ngoại mới không tồn tại trong bảng cha. Ví dụ, nếu bạn cố thay đổi giá trị cột Employee ID (trong bảng Orders) của đơn hàng 48 từ giá trị 4 thành 12345, RDBMS sẽ kiểm tra trong bảng Employees xem có nhân viên mã số 12345 hay không. Nếu không có, phép cập nhật sẽ thất bại.

● Khi bạn xóa một dòng từ bảng cha, nếu dòng này có liên quan tới một hoặc nhiều dòng khác trong bảng con thì các dòng trong bảng con cũng phải được xóa, nếu không phép xóa sẽ thất bại. Hầu hết RDBMS đều cung cấp tùy chọn cho phép tự động xóa các dòng trong bảng con, gọi là cascading delete. Có thể bạn sẽ băn khoăn vì sao lại phải tự động xóa các dòng trong bảng con. Hãy cùng xem xét các bảng Orders và Order Details. Nếu một đơn hàng bị xóa, tại sao không xóa luôn tất cả các dòng chi tiết đơn hàng đó trong cùng một bước? Tuy nhiên, với bảng Employees, rõ ràng, chúng ta không muốn điều này xảy ra. Nếu xóa nhân viên có mã số 4 khỏi bảng Employees (có thể do người này không còn là nhân viên nữa), RDBMS phải kiểm tra xem có dòng nào được gán Employee ID 4 trong bảng Orders hay không, và nếu có thì phép xóa thất bại. Ở đây, không có bất cứ quy tắc nghiệp vụ nào quy định việc tự động xóa đơn hàng nếu như một nhân viên rời khỏi công ty.


Trong hầu hết các cơ sở dữ liệu quan hệ, một câu lệnh SQL được sử dụng để định nghĩa một ràng buộc tham chiếu. SQL sẽ được giới thiệu trong Chương 4. SQL là ngôn ngữ được sử dụng trong RDBMS để giao tiếp với cơ sở dữ liệu. Nhiều nhà cung cấp cũng hỗ trợ bảng điều khiển giao diện đồ họa (GUI), cho phép định nghĩa đối tượng cơ sở dữ liệu, ví dụ như ràng buộc tham chiếu. Ví dụ, trong SQL Server, bảng điều khiển GUI được đặt trong công cụ SQL Server Management Studio, còn trong Oracle là công cụ SQL Developer. Với Microsoft Access là bảng điều khiển Relationships, như trong Hình 2-9, được sử dụng để định nghĩa các ràng buộc tham chiếu.

Để tiện theo dõi, trong Hình 2-9 chỉ hiển thị bảng Orders và các bảng cha là Employees và Customers. Các ràng buộc tham chiếu được biểu diễn bằng những đường nét đậm cùng với ký tự số 1 nằm gần bảng cha (phía “một”) và ký tự vô cùng (∞) nằm gần bảng con (phía “nhiều”). Những ràng buộc này được định nghĩa rất đơn giản bằng cách kéo tên của khóa chính trong bảng

Hình 2-9 Bảng điều khiển Relationships của Microsoft Access 2007.


Hình 2-10 Bảng điều khiển Edit Relationships của Microsoft Access 2007.

cha vào vị trí tên của khóa ngoại trong bảng con. Sau đó, một cửa sổ pop-up sẽ hiện ra, cho phép xác định các tùy chọn cho ràng buộc tham chiếu, như trong Hình 2-10.

Ở trên cùng bảng điều khiển Edit Relationships, tên của hai bảng xuất hiện với bảng cha nằm bên trái và bảng con nằm bên phải. Nếu bạn không biết bảng nào là bảng cha, bảng nào là bảng con, trường Relationship Type trong bảng này sẽ giúp bạn. Bên dưới tên của mỗi bảng là các dòng để chọn ra những cột tạo thành khóa chính và khóa ngoại. Hình 2-10 hiển thị cột khóa chính ID trong bảng Customers và cột khóa ngoại Customer ID trong bảng Orders. Các hộp kiểm (checkbox) cung cấp một số tùy chọn sau:

● Enforce Referential Integrity Nếu đánh dấu hộp kiểm này, ràng buộc sẽ là bắt buộc; việc bỏ đánh dấu hộp kiểm này sẽ tắt chế độ bắt buộc ràng buộc.

● Cascade Update Related Fields Nếu đánh dấu hộp kiểm này, mọi thay đổi đối với khóa chính trong bảng cha sẽ khiến những khóa ngoại tương ứng trong bảng con cũng tự động cập nhật theo. Tuy nhiên, việc cập nhật khóa chính trong bảng cha ít khi xảy ra.

● Cascade Delete Related Records Nếu đánh dấu hộp kiểm này, khi xóa một dòng trong bảng cha, các dòng liên quan trong bảng con tự động bị xóa. Đến đây, hãy suy nghĩ thật cẩn thận. Có những trường hợp bạn nên sử dụng tùy chọn này, như ràng buộc giữa bảng Orders và bảng Order Details, còn trong một số trường hợp khác, khi sử dụng tùy chọn này sẽ dẫn tới việc xóa mất những dữ liệu không mong muốn, ví dụ như xóa đi một nhân viên, và tất cả các đơn hàng do nhân viên đó phụ trách cũng tự động bị xóa khỏi cơ sở dữ liệu.

Bảng tương giaoQuan hệ nhiều - nhiều đã được đề cập ở các phần trước, chỉ ra rằng kiểu quan hệ này không thể được cài đặt trực tiếp trong cơ sở dữ liệu quan hệ, do đó cần tạo ra một bảng tương giao để có thể thiết lập được quan hệ nhiều - nhiều. Hình 2-11 đưa ra cách cài đặt của bảng tương giao Order Details trong Microsoft Access.


Hình 2-11 Bảng tương giao Order Details (Microsoft Access 2007).

Quan hệ nhiều - nhiều giữa đơn hàng và các sản phẩm trong thiết kế khái niệm trở thành một bảng tương giao (bảng Order Details) trong thiết kế lôgíc. Khi đó, quan hệ nhiều - nhiều được tách thành hai quan hệ một - nhiều, tại đó bảng tương giao nằm ở phía “nhiều” trong mỗi quan hệ. Khóa chính của bảng Order Details có thể được tạo bằng cách kết hợp cột Order ID và Product ID (còn gọi là khóa tự nhiên), trong đó Order ID là khóa ngoại liên kết tới bảng Orders và Product ID là khóa ngoại liên kết tới bảng Products. Tuy nhiên, trong trường hợp này, nhà thiết kế chọn phương án thêm vào bảng một cột mới ID làm khóa chính cho bảng Order Details. Khóa này được gọi là khóa thay thế (surrogate key), bởi nó đã được dùng để thay thế cho khóa tự nhiên (natural key). Hãy dành chút thời gian để kiểm tra nội dung của bảng tương giao và hai ràng buộc tham chiếu. Việc hiểu rõ bảng tương giao và các ràng buộc tham chiếu này rất quan trọng, giúp bạn nắm được cách thức làm việc của cơ sở dữ liệu quan hệ. Sau đây là một số điểm cần xem xét:

● Mỗi dòng trong bảng tương giao Order Details là giao của một sản phẩm và một đơn hàng. Việc bao gồm cả trường Product Name trong bảng này không có ý nghĩa vì tên sản phẩm là hoàn toàn như nhau ở mọi trường hợp xuất hiện sản phẩm đó trong một đơn hàng. Tương tự như vậy, việc thêm cột Customer ID vào bảng Order Details là không cần thiết, vì mỗi dòng chi tiết trong một đơn hàng đều thuộc về cùng một khách hàng.


● Mỗi dòng trong bảng Products có thể có nhiều dòng liên quan trong bảng Order Details (mỗi sản phẩm có thể được đặt hàng nhiều lần trong các đơn hàng khác nhau), tuy nhiên, mỗi dòng trong bảng Order Details thuộc về một và chỉ một dòng trong bảng Products.

● Mỗi dòng trong bảng Orders có thể có nhiều dòng liên quan ở bảng Order Details (mỗi đơn hàng có thể có nhiều dòng chi tiết đơn hàng, mỗi dòng chi tiết cho một sản phẩm), tuy nhiên, mỗi dòng trong bảng Order Details thuộc về một và chỉ một dòng tại bảng Orders.

Ràng buộc toàn vẹnNhư đã đề cập, những quy tắc nghiệp vụ trong thiết kế khái niệm trở thành các ràng buộc trong thiết kế lôgíc. Ràng buộc toàn vẹn (integrity constraint) là ràng buộc làm tăng thêm tính chính xác của dữ liệu trong cơ sở dữ liệu. Ưu điểm chính của ràng buộc toàn vẹn là RDBMS tự động thực thi những ràng buộc này, tức ràng buộc luôn được duy trì, cho dù bạn kết nối tới cơ sở dữ liệu theo cách nào đi chăng nữa (trừ khi bạn là DBA). Một số kiểu ràng buộc toàn vẹn chủ yếu là ràng buộc NOT NULL, ràng buộc CHECK và ràng buộc bắt buộc với các trigger.

Ràng buộc NOT NULLKhi định nghĩa cột trong cơ sở dữ liệu, bạn có thể xác định cột có được cho phép nhận giá trị null hay không. Giá trị null (null value) trong cơ sở dữ liệu quan hệ là một mã đặc biệt, được đặt vào một cột để biểu thị rằng giá trị của cột đó trong hàng là không xác định. Giá trị null không giống giá trị trống, chuỗi rỗng, hay giá trị không - đây là một mã đặc biệt, không biểu thị ý nghĩa nào khác trong cơ sở dữ liệu.

Cách xử lý thống nhất đối với giá trị null được quy định trong tiêu chuẩn ANSI/ISO SQL. Tuy nhiên, đã có nhiều tranh luận về tính hữu ích của giá trị null, vì các cơ sở dữ liệu không thể cho bạn biết tại sao giá trị lại không xác định. Ví dụ, nếu để giá trị cột Job Title trong bảng Employees bằng null, bạn không thể biết liệu giá trị đó là null vì giá trị là không xác định (bạn biết rằng, mỗi nhân viên phải có một chức danh, nhưng lại không biết đó là chức danh gì), chức danh đó không có (có lẽ một số nhân viên không có chức danh), hay vì không được gán (các nhân viên nhất định phải có một chức danh, song có thể người quản lý chưa nghĩ ra chức danh cho họ). Một tình huống khác, do giá trị null là không xác định nên không thể mang ra so sánh với các giá trị khác, kể cả giá trị null khác, điều này dẫn đến khái niệm lôgíc ba giá trị khi tìm kiếm trong cơ sở dữ liệu. Khi sử dụng giá trị null, một phép tìm kiếm có thể trả về điều kiện true (nếu cột thỏa mãn điều kiện tìm kiếm), false (nếu cột không thỏa mãn điều kiện tìm kiếm), hoặc không xác định (nếu cột có giá trị null). Các nhà phát triển viết chương trình ứng dụng phải xử lý giá trị null như một trường hợp đặc biệt. Bạn sẽ hiểu thêm về giá trị null trong Chương 4 khi học về SQL.

Trong Microsoft Access, ràng buộc NOT NULL được điều khiển bởi tùy chọn Required trong cửa sổ thiết kế bảng. Hình 2-12 đưa ra định nghĩa cột Discount trong bảng Order Details. Cột này là bắt buộc (không được phép nhận giá trị null) vì tùy chọn Required được thiết lập là Yes. Trong định nghĩa bảng bằng SQL, bạn chỉ cần đặt từ khóa NULL hoặc NOT NULL vào định nghĩa cột. Hãy chú ý tới các giá trị mặc định! Trong Oracle, nếu bạn bỏ qua ràng buộc NOT NULL thì giá trị mặc định là NULL, có nghĩa rằng cột đó có thể nhận giá trị null.


Hình 2-12 Cửa sổ định nghĩa bảng Order Details, cột Discount.

Nhưng trong một số RDBMS như DB2, Microsoft SQL Server, và Sybase ASE thì ngược lại: Nếu bạn bỏ qua ràng buộc NOT NULL, giá trị mặc định là NOT NULL, có nghĩa rằng cột đó không thể chứa giá trị null.

Ràng buộc CHECK Ràng buộc CHECK sử dụng một câu lệnh lôgíc đơn giản để kiểm tra tính hợp lệ của giá trị cột. Kết quả của câu lệnh lôgíc đó phải là giá trị lôgíc true hoặc false, nếu kết quả bằng true, giá trị cột sẽ được cho phép đặt vào bảng; ngược lại, nếu kết quả bằng false, giá trị cột sẽ bị từ chối và RDBMS sẽ đưa ra thông báo lỗi tương ứng. Trong Hình 2-12, hãy để ý ràng buộc <=1 And >=0 xuất hiện trong tùy chọn Validation Rule của cột Discount. Quy tắc kiểm tra này không cho phép giá trị của cột Discount (tỷ lệ chiết khấu) lớn hơn 100% (giá trị 1,00) hoặc nhỏ hơn 0%. Mặc dù cú pháp của tùy chọn Validation Rule có thể rất khác nhau, song mục đích thì giống nhau. Trong Oracle SQL, ràng buộc trên được viết như sau:

CHECK (DISCOUNT <=1 AND DISCOUNT >=0)


Các ràng buộc thực thi sử dụng triggerMột số ràng buộc phức tạp không thể sử dụng khai báo để thực thi được. Ví dụ, quy tắc nghiệp vụ trong Hình 2-1 (Những khách hàng vẫn còn nợ quá hạn không được phép đặt đơn hàng mới) thuộc nhóm ràng buộc phức tạp vì nó liên quan tới nhiều bảng khác nhau. Nếu kiểm tra thấy dòng trong bảng Account Receivable của khách hàng đó có số dư nợ quá hạn lớn hơn 0, ta cần ngăn không cho phép thêm dòng mới vào bảng Orders. Như đã nói, cách thực thi tốt nhất các quy tắc nghiệp vụ như vậy là thực thi chúng trong lôgíc của ứng dụng. Tuy nhiên, nếu muốn thêm một ràng buộc và yêu cầu ràng buộc này luôn được thực thi, không phụ thuộc vào cách thức cập nhật cơ sở dữ liệu, bạn có thể chọn trigger. Trigger là một mô-đun lôgíc lập trình, được kích hoạt khi xảy ra một sự kiện cụ thể trong cơ sở dữ liệu. Ở ví dụ này, chúng ta muốn trigger kích hoạt khi một dòng mới được thêm vào bảng Orders. Trigger này có nhiệm vụ lấy về số dư nợ quá hạn (overdue amount) của khách hàng từ bảng Account Receivable. Nếu số dư nợ quá hạn lớn hơn 0, trigger sẽ phát ra một lỗi, làm dừng truy vấn thêm dòng, đồng thời trả về thông báo lỗi tương ứng.

Trong Microsoft Access, các trigger được viết dưới dạng macro sử dụng ngôn ngữ Microsoft Visual Basic for Applications (VBA). Một số RDBMS cung cấp một ngôn ngữ đặc biệt để viết các mô-đun chương trình như trigger: PL/SQL của Oracle, Transact SQL trong Microsoft SQL Server và Sybase ASE. Một số RDBMS khác, ví dụ như DB2, có thể sử dụng ngôn ngữ lập trình chung như C.

ViewView (khung nhìn) là một truy vấn cơ sở dữ liệu được lưu trữ, cung cấp cho người dùng tập dữ liệu tổng hợp từ một hoặc nhiều bảng trong cơ sở dữ liệu. Nói cách khác, view là một bảng ảo, vì hình thức và hầu hết thành phần của view đều rất giống bảng, ngoại trừ một điều là view không chứa dữ liệu (view đơn giản chỉ là một truy vấn được lưu trữ trong cơ sở dữ liệu). View người dùng tạo thành lớp ngoài trong mô hình ANSI/SPARC. Trong quá trình thiết kế lôgíc, view được tạo ra bằng cách sử dụng phương pháp tương ứng với một cơ sở dữ liệu cụ thể. Ở hầu hết các RDBMS, view được tạo ra bằng SQL. Trong Microsoft Access, view không được hỗ trợ trực tiếp. Tuy nhiên, Access hỗ trợ một kiểu đối tượng tương đương với view là truy vấn (query), được tạo ra bằng cách sử dụng bảng điều khiển Query. Hình 2-13 cho thấy cách thức Microsoft Access định nghĩa một view đơn giản để liệt kê tất cả các đơn hàng của khách hàng ở bang Washington.


Hình 2-13 Định nghĩa view trong Microsoft Access 2007: Liệt kê tất cả các đơn hàng của khách hàng ở bang Washington.

View trong Hình 2-13 hiển thị hai cột từ bảng Customer cùng ba cột từ bảng Orders. View này còn so khớp (kết nối) bảng Customers và bảng Orders, đồng thời lọc các dòng để chỉ chọn ra những đơn hàng của khách hàng ở bang Washington. Phép lọc này được thực hiện bằng cách thiết lập thuộc tính Criteria trong cột State/Province (= ‘WA’). Chúng ta sẽ tìm hiểu chi tiết về bảng điều khiển Query của Microsoft Access trong Chương 3. Hình 2-14 hiển thị kết quả thực thi của truy vấn trên. Mặc dù có hai khách hàng ở Washington, song chỉ một người trong số họ có đơn hàng, và chỉ có hai đơn hàng xuất hiện trong bảng kết quả.

Các view phục vụ một số chức năng hữu dụng như:

● Ẩn các cột mà người dùng không cần nhìn thấy (hoặc không được phép nhìn thấy).

● Ẩn các dòng mà người dùng không cần nhìn thấy (hoặc không được phép nhìn thấy).

● Ẩn các phép xử lý phức tạp trong cơ sở dữ liệu, ví dụ như phép kết nối.

● Tăng tốc độ xử lý truy vấn (trong một số RDBMS, ví dụ như Microsoft SQL Server).


Hình 2-14 Kết quả thực thi của truy vấn được thể hiện trong Hình 2-13.

Bài tự trắc nghiệm kiến thức Chương 2Chọ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. Ví dụ nào sau đây là thực thể?

A. Một khách hàng.

B. Một đơn hàng của khách hàng.

C. Tiền lương của nhân viên.

D. Tên của khách hàng.

2. Ví dụ nào sau đây là thuộc tính?

A. Một nhân viên.

B. Tên của nhân viên.

C. Tiền lương của nhân viên.

D. Một danh sách tên của các nhân viên được sắp xếp theo thứ tự ABC.

3. Dấu hiệu nào sau đây biểu thị cho lực lượng quan hệ bằng “0, 1, hoặc nhiều” trên đường biểu diễn quan hệ?

A. Một dấu vuông góc và dấu ký hiệu hình vương miện gần vị trí kết thúc của đường quan hệ.

B. Một vòng tròn gần vị trí kết thúc của đường quan hệ và dấu ký hiệu hình vương miện ở vị trí kết thúc của đường quan hệ.

C. Hai dấu vuông góc gần vị trí kết thúc của đường quan hệ.

D. Một vòng tròn và dấu vuông góc gần vị trí kết thúc của đường quan hệ.


4. Đâu là kiểu quan hệ hợp lệ trong cơ sở dữ liệu quan hệ?

A. Một - nhiều.

B. Không - nhiều.

C. Nhiều - nhiều.

D. Một - một.

5. Một sản phẩm có thể được sản xuất tại nhiều nhà máy, và một nhà máy có thể sản xuất nhiều loại sản phẩm, ví dụ này biểu diễn kiểu quan hệ nào?

A. Một - một.

B. Một - nhiều.

C. Nhiều - nhiều.

D. Đệ quy.

6. Trong các ví dụ dưới đây, ví dụ nào là quan hệ đệ quy?

A. Một đơn vị tổ chức của một phòng ban.

B. Một nhân viên quản lý các nhân viên khác.

C. Một nhân viên quản lý một phòng.

D. Một nhân viên có nhiều người cấp dưới.

7. Ví dụ nào sau đây là quy tắc nghiệp vụ?

A. Một ràng buộc tham chiếu phải tham chiếu tới khóa chính của bảng cha.

B. Tuổi của nhân viên phải lớn hơn hoặc bằng 18.

C. Một truy vấn loại bỏ các cột nhân viên không được phép xem.

D. Các nhân viên có bậc lương dưới 6 không được phép thay đổi các đơn hàng.

8. Một bảng quan hệ

A. Được tạo thành từ các cột và các hàng.

B. Phải được gán một kiểu dữ liệu xác định.

C. Phải được gán một tên duy nhất.

D. Là đơn vị lưu trữ cơ bản trong mô hình quan hệ.

9. Một cột trong bảng quan hệ

A. Phải được gán một kiểu dữ liệu xác định.

B. Phải được gán một tên duy nhất trong bảng.

C. Được kế thừa từ một thực thể trong thiết kế khái niệm.

D. Là đơn vị lưu trữ nhỏ nhất được đặt tên trong cơ sở dữ liệu quan hệ.

10. Một kiểu dữ liệu

A. Hỗ trợ DBMS trong việc lưu trữ dữ liệu hiệu quả.


B. Cung cấp tập các hành vi cho một cột hỗ trợ người dùng.

C. Có thể được chọn dựa vào các quy tắc nghiệp vụ đối với một thuộc tính.

D. Giới hạn các ký tự được phép sử dụng trong cột.

11. Một ràng buộc khóa chính

A. Phải tham chiếu tới một hoặc nhiều cột trong một bảng.

B. Phải được định nghĩa cho tất cả các bảng trong cơ sở dữ liệu.

C. Thường được cài đặt bằng cách sử dụng một chỉ mục.

D. Đảm bảo rằng, không có hai dòng nào trong bảng có cùng giá trị khóa chính.

12. Ràng buộc tham chiếu

A. Phải có các cột khóa chính và khóa ngoại cùng tên.

B. Đảm bảo rằng, một giá trị khóa chính không bị trùng nhau trong một bảng.

C. Định nghĩa một quan hệ nhiều - nhiều giữa hai bảng.

D. Đảm bảo rằng, một giá trị khóa ngoại tham chiếu tới một giá trị khóa chính trong bảng cha.

13. Một ràng buộc tham chiếu được định nghĩa

A. Sử dụng bảng điều khiển Relationships trong Microsoft Access.

B. Sử dụng SQL trong hầu hết các cơ sở dữ liệu quan hệ.

C. Sử dụng kiểu dữ liệu tham chiếu cho cột (các cột) khóa ngoại.

D. Sử dụng một trigger.

14. Các kiểu ràng buộc toàn vẹn là

A. Ràng buộc CHECK.

B. Quan hệ một - một.

C. Ràng buộc NOT NULL.

D. Ràng buộc bắt buộc thực thi với các trigger.

15. Bảng ___________ được sử dụng để giải quyết các quan hệ nhiều - nhiều.

16. Một thực thể trong thiết kế mức khái niệm sẽ được ánh xạ thành một ___________ trong thiết kế mức lôgíc.

17. Một thuộc tính trong thiết kế mức khái niệm sẽ được ánh xạ thành một ___________ trong thiết kế mức lôgíc.

18. Các phần tử bên ngoài trong mô hình ANSI/SPARC sẽ trở thành ___________ trong thiết kế mức lôgíc.

19. Một quan hệ trong thiết kế mức khái niệm sẽ được ánh xạ thành một __________ trong thiết kế mức lôgíc.

20. Một ràng buộc khóa chính (primary key) được thực thi bằng cách sử dụng một __________ trong thiết kế mức lôgíc.

Các khái niệm về cơ sở dữ liệu - poly.edu.vn · có nghĩa là ngân hàng dữ...

Documents

Transcript of Các khái niệm về cơ sở dữ liệu - poly.edu.vn · có nghĩa là ngân hàng dữ...