BÀI GIẢNG Các khái niệm về cơ sở dữ liệu

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á

Phần I

Các khái niệm về

cơ sở dữ liệu

Căn bản về

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ệ?

Chương này giới thiệu các khái niệm căn bản và những định nghĩa liên quan đến cơ sở dữ

liệu, bao gồm các thuộc tính của cơ sở dữ liệu nói chung, các mô hình cơ sở dữ liệu thông dụng, tóm lược lịch sử cơ sở dữ liệu, nguyên nhân tại sao phải tập trung vào mô hình cơ sở dữ liệu quan hệ

Các thuộc tính của cơ sở dữ liệu

Cơ sở dữ liệu (database) là tập hợp các thành phần dữ liệu có liên quan lẫn nhau, được quản

lý dưới dạng một đơn vị duy nhất Định nghĩa trên tương đối rộng, bởi có sự khác biệt đáng kể giữa các cơ sở dữ liệu của các nhà sản xuất phần mềm cung cấp các hệ thống cơ sở dữ liệu Chẳng hạn, Microsoft Access đặt toàn bộ cơ sở dữ liệu trong một file dữ liệu, do đó, một cơ sở dữ liệu Access có thể được định nghĩa như một file chứa các thành phần dữ liệu Công ty Oracle định nghĩa cơ sở dữ liệu của họ như tập các file vật lý được quản lý bởi một thể hiện của phần mềm cơ

sở dữ liệu của Oracle Thể hiện (instance) là một phiên bản của phần mềm cơ sở dữ liệu đang chạy

trong bộ nhớ Microsoft SQL Server và Sybase Adaptive Server Enterprise (ASE) định nghĩa một

cơ sở dữ liệu là tập hợp các thành phần dữ liệu có cùng chủ sở hữu, và nhiều cơ sở dữ liệu được quản trị bởi một thể hiện của một phần mềm quản trị cơ sở dữ liệu Định nghĩa này có thể gây hiểu lầm đôi chút nếu bạn làm việc với nhiều sản phẩm khác nhau, vì theo định nghĩa của Microsoft

SQL Server và Sybase ASE, một cơ sở dữ liệu lại chính là một schema (lược đồ) như định nghĩa

của công ty Oracle

Đối tượng cơ sở dữ liệu (database object) là một cấu trúc dữ liệu được đặt tên và lưu trữ

trong cơ sở dữ liệu Các kiểu đối tượng cơ sở dữ liệu cụ thể được hỗ trợ trong một cơ sở dữ liệu

thường khác nhau giữa các nhà cung cấp và giữa các mô hình cơ sở dữ liệu Mô hình cơ sở dữ liệu (database model) là cách cơ sở dữ liệu tổ chức dữ liệu của nó để mô phỏng thế giới thực Những

mô hình cơ sở dữ liệu phổ biến nhất được trình bày trong mục “Các mô hình cơ sở dữ liệu thông dụng” ở cuối chương này

File là tập hợp các bản ghi có liên quan được lưu trữ như một đơn vị bởi hệ điều hành Thật không may, định nghĩa của file và cơ sở dữ liệu khá giống nhau, vậy làm sao để phân biệt chúng?

Một số nhà cung cấp hệ điều hành Unix gọi các file mật khẩu của họ là các “cơ sở dữ liệu”, song những chuyên gia về cơ sở dữ liệu đã nhanh chóng chỉ ra rằng, thực tế chúng không thực sự là

các cơ sở dữ liệu Rõ ràng, chúng ta cần xem xét tỉ mỉ những định nghĩa này Để hiểu rõ các định nghĩa, chúng ta cần tìm hiểu về các đặc trưng và thuộc tính riêng có trong cơ sở dữ liệu mà không thể tìm thấy trong những file thông thường Những đặc trưng và thuộc tính này bao gồm:

● Quản lý bởi một hệ quản trị cơ sở dữ liệu (DBMS)

● Các lớp trừu tượng hóa dữ liệu

● Độc lập dữ liệu vật lý

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

Những đặc trưng này sẽ được thảo luận trong các phần dưới đây

Hệ quản trị cơ sở dữ liệu

Hệ quản trị cơ sở dữ liệu (database management system - DBMS) là một phần mềm được cung

ứng bởi nhà cung cấp cơ sở dữ liệu Các sản phẩm phần mềm như Microsoft Access, Oracle, Microsoft SQL Server, Sybase ASE, DB2, Ingres và MySQL đều là các hệ quản trị cơ sở dữ liệu Bạn có thể thấy hơi khó hiểu là tại sao lại dùng chữ cái viết tắt DBMS mà không phải DMS Hãy

nhớ, ban đầu, thuật ngữ cơ sở dữ liệu (database) được viết bằng hai từ và dần dần được quy ước

trở thành một từ đơn

DBMS cung cấp tất cả các dịch vụ cơ bản cần thiết để tổ chức và duy trì cơ sở dữ liệu, bao gồm:

● Di chuyển dữ liệu từ cơ sở dữ liệu ra các file dữ liệu vật lý và từ các file dữ liệu vật lý vào cơ

sở dữ liệu khi cần thiết

● Quản lý việc truy cập dữ liệu đồng thời bởi nhiều người dùng, bao gồm việc ngăn các cập nhật tại cùng một thời điểm xung đột lẫn nhau

● Quản lý các giao dịch (transaction) để những thay đổi tới cơ sở dữ liệu của giao dịch phải

được thực hiện một cách trọn vẹn như một đơn vị công việc duy nhất hoặc không thực hiện gì

cả Nói cách khác, nếu giao dịch thành công, tất cả các thay đổi cơ sở dữ liệu được giao dịch tạo ra sẽ được lưu vào cơ sở dữ liệu; ngược lại, nếu giao dịch thất bại, sẽ không có bất cứ thay đổi nào được lưu vào cơ sở dữ liệu

● Hỗ trợ ngôn ngữ truy vấn (query language) - một hệ thống lệnh do người dùng cơ sở dữ liệu

sử dụng để truy xuất dữ liệu từ cơ sở dữ liệu

● Cho phép sao lưu dự phòng cơ sở dữ liệu và phục hồi sau sự cố

● Cung cấp cơ chế bảo mật để ngăn các truy cập và chỉnh sửa dữ liệu không được cấp phép

Hỏi chuyên gia

Câu hỏi: Tôi nghe nói có thuật ngữ “ngân hàng dữ liệu” Điểm khác nhau giữa ngân

hàng dữ liệu và cơ sở dữ liệu là gì?

Trả lời: Ngân hàng dữ liệu và cơ sở dữ liệu là một Ngân hàng dữ liệu (data bank) là thuật

ngữ cũ, được các nhà khoa học phát triển hệ thống cơ sở dữ liệu ban đầu sử dụng

Thực tế, thuật ngữ ngân hàng dữ liệu vẫn đang được sử dụng trong một số ngôn ngữ của loài người, chẳng hạn trong tiếng Bồ Đào Nha, cụm từ banco de dados

có nghĩa là ngân hàng dữ liệu

Các lớp trừu tượng hóa dữ liệu

Một đặc trưng của cơ sở dữ liệu là khả năng cung cấp cho nhiều người dùng những cách quan sát khác nhau đối với cùng một dữ liệu được lưu trữ trong CSDL, phù hợp với nhu cầu riêng của họ

Những cách quan sát dữ liệu đó được gọi là các view người dùng (user view) Trong trường hợp này, người dùng có thể là một người, hoặc ứng dụng truy cập vào cơ sở dữ liệu với mục đích lưu trữ và/hoặc lấy dữ liệu Ứng dụng (application) là tập các chương trình máy tính được thiết kế để

giải quyết một vấn đề nghiệp vụ cụ thể, chẳng hạn như hệ thống nhập đơn đặt hàng, hệ thống xử

lý sổ lương, hay hệ thống kế toán

Khi sử dụng ứng dụng bảng tính điện tử như Microsoft Excel, tất cả người dùng cần chia sẻ một view dữ liệu chung, và view đó phải khớp với cách dữ liệu được lưu trữ trong file dữ liệu Nếu một người dùng ẩn vài cột trong một trang tính, sắp xếp lại thứ tự các dòng và lưu trang tính lại, thì khi mở trang tính, người dùng tiếp theo sẽ nhìn thấy dữ liệu đúng như những gì mà người dùng trước đã lưu Một giải pháp khác là mỗi người dùng sẽ lưu bản sao của họ trong một file vật

lý riêng, nhưng khi một người dùng tiến hành chỉnh sửa, những người dùng khác sẽ không nhận được các cập nhật mới này Với cùng một dữ liệu cơ sở, các hệ thống cơ sở dữ liệu cung cấp cho người dùng các view để quan sát dữ liệu ở các góc độ khác nhau Các view này có thể được điều chỉnh để phù hợp với nhu cầu của mỗi người dùng, bất kể chúng đều bắt nguồn từ cùng một bản sao của dữ liệu được lưu trữ Vì các view không lưu trữ dữ liệu thực, nên chúng tự động phản ánh bất kỳ thay đổi nào đến các đối tượng cơ sở dữ liệu nằm bên dưới Quá trình này được thực hiện

thông qua các lớp trừu tượng (layer of abstraction), được mô phỏng ở Hình 1-1

Kiến trúc trong Hình 1-1 được ANSI/SPARC (Viện Tiêu chuẩn Quốc gia Hoa Kỳ/Ủy ban Quy hoạch và xét duyệt các tiêu chuẩn) phát triển lần đầu vào những năm 1970 Nó nhanh chóng trở thành nền tảng cho các nỗ lực phát triển và nghiên cứu cơ sở dữ liệu Hầu hết DBMS hiện đại đều tuân theo kiến trúc này, bao gồm ba lớp chính: Lớp vật lý, lớp lôgíc và lớp ngoài Kiến trúc ban đầu còn bao gồm lớp khái niệm đã bị loại bỏ do không có nhà cung cấp cơ sở dữ liệu hiện đại nào sử dụng lớp này

Lớp ngoài View 1 View 2

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

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

schema, thuật ngữ chỉ một tập hợp bao gồm toàn bộ các thành phần dữ liệu được lưu trữ trong một

cơ sở dữ liệu cụ thể, hoặc thuộc về một người dùng cơ sở dữ liệu nào đó Tùy thuộc vào DBMS cụ thể, lớp này có thể chứa tập hợp các bảng hai chiều, một cấu trúc phân cấp tương tự như sơ đồ tổ chức của một công ty hay vài cấu trúc khác Trong mục “Các mô hình cơ sở dữ liệu thông dụng”

ở phần sau của chương sẽ mô tả chi tiết hơn về các cấu trúc này

Lớp bên ngoài

Lớp ngoài (external layer) hay mô hình bên ngoài (external model) là lớp trừu tượng thứ hai trong

cơ sở dữ liệu Lớp này bao gồm các view người dùng được trình bày ở phần trên, được gọi chung

là subschema (schema con) Ở lớp này, người dùng cơ sở dữ liệu (các chương trình ứng dụng cũng

như người dùng thực sự) truy cập vào cơ sở dữ liệu sẽ kết nối và gửi các truy vấn tới chúng Lý tưởng nhất là chỉ có DBA mới có thể làm việc với các lớp vật lý và lôgíc DBMS kiểm soát việc chuyển đổi các thành phần được chọn từ một hoặc nhiều cấu trúc dữ liệu ở lớp lôgíc thành từng view người dùng View người dùng ở lớp này có thể được định nghĩa trước, đồng thời được lưu trữ trong cơ sở dữ liệu để tái sử dụng, hoặc có thể là thành phần tạm thời được DBMS tạo ra, nhằm lưu kết quả của một truy vấn ad-hoc tới cơ sở dữ liệu đến khi người dùng không sử dụng nữa Truy

vấn ad-hoc (hay còn gọi là truy vấn tức thời, truy vấn phi chuẩn tắc), là truy vấn không được lập

kế hoạch cẩn thận và không được tái sử dụng View sẽ được trình bày chi tiết hơn ở Chương 2.Độc lập dữ liệu vật lý

Khả năng thay đổi cấu trúc file vật lý của cơ sở dữ liệu mà không làm gián đoạn người dùng và

các quá trình đang diễn ra được gọi là độc lập dữ liệu vật lý (physical data independence) Như đã

thấy ở Hình 1-1, ranh giới phân cách giữa lớp vật lý với lớp lôgíc tạo ra sự độc lập dữ liệu vật lý trong một DBMS Bạn nên hiểu, độc lập dữ liệu vật lý không phải là thuộc tính “có hay không”,

mà là đặc tính cho thấy DBMS này có thể có ít tính độc lập dữ liệu hơn so với DBMS khác Thước

đo cho tính độc lập dữ liệu vật lý, đôi khi còn được gọi là mức độ độc lập dữ liệu vật lý, là có thể

tạo ra bao nhiêu thay đổi trong hệ thống file mà không gây ảnh hưởng tới lớp lôgíc Khi các hệ thống chưa cung cấp khả năng độc lập dữ liệu, thậm chí một thay đổi nhỏ tới cách lưu trữ dữ liệu cũng yêu cầu bộ phận lập trình phải thay đổi mọi chương trình máy tính sử dụng dữ liệu, một công việc tốn kém và ngốn nhiều thời gian

Tất cả hệ thống máy tính hiện đại đều có một số mức độ độc lập dữ liệu vật lý Chẳng hạn, nếu được sao chép từ ổ cứng tới ổ đĩa mềm hay ổ lưu trữ USB, bảng tính trên máy tính cá nhân vẫn tiếp tục làm việc chính xác Sự khác nhau đáng kể giữa hiệu năng (tốc độ) của các thiết bị này không quan trọng, vấn đề nằm ở chỗ, các thiết bị này có cấu trúc vật lý hoàn toàn khác nhau, hệ điều hành trên máy tính cá nhân sẽ tự động kiểm soát những khác biệt đó, đồng thời chuyển dữ liệu trong file cho ứng dụng (trong ví dụ này là chương trình bảng tính, chẳng hạn như Microsoft Excel), và cuối cùng trình bày với người dùng theo cùng một cách thức Tuy nhiên, đối với hầu hết các hệ thống cá nhân, người dùng phải ghi nhớ vị trí đã lưu file để có thể dễ dàng tìm thấy khi cần.DBMS mở rộng mạnh mẽ về tính độc lập dữ liệu vật lý được hệ thống máy tính cung cấp

DBMS cho phép người dùng cơ sở dữ liệu truy cập tới các đối tượng (object) cơ sở dữ liệu

(chẳng hạn, các bảng trong một DBMS quan hệ) mà không cần tham chiếu tới các file dữ liệu

vật lý Catalog trong DBMS lưu trữ định nghĩa đối tượng và theo dõi nơi lưu trữ vật lý của các đối

tượng Sau đây là một số ví dụ về những thay đổi vật lý thể được thực hiện theo kiểu độc lập dữ liệu:

● Di chuyển một file cơ sở dữ liệu từ thiết bị này sang thiết bị khác hay từ thư mục này sang thư mục khác

● Tách hay gộp các file dữ liệu của cơ sở dữ liệu

● Đổi tên file dữ liệu của cơ sở dữ liệu

● Di chuyển một đối tượng cơ sở dữ liệu từ file dữ liệu này sang file dữ liệu khác

● Thêm một đối tượng hay một file dữ liệu mới vào cơ sở dữ liệu

Lưu ý, chúng ta không đề cập tới việc xóa bất cứ thứ gì ở đây Rõ ràng, nếu bạn xóa một đối tượng

cơ sở dữ liệu sẽ khiến việc sử dụng đối tượng đó thất bại Tuy nhiên, mọi thứ khác sẽ không bị ảnh hưởng, ngoại trừ tính sẵn sàng của cơ sở dữ liệu hay dịch vụ bị ảnh hưởng vì một số DBMS sẽ yêu cầu cơ sở dữ liệu hay dịch vụ DBMS ngừng lại trong lúc thực hiện một thay đổi lớp vật lý nào đó.Độc lập dữ liệu lôgíc

Khả năng tạo ra các thay đổi tới lớp lôgíc mà không làm gián đoạn người dùng hiện tại và các quá

trình đang diễn ra được gọi là độc lập dữ liệu lôgíc (logical data independence) Hình 1-1 cho

thấy ranh giới giữa lớp lôgíc và lớp ngoài tạo ra tính độc lập dữ liệu lôgíc Tương tự như độc lập

dữ liệu vật lý, độc lập dữ liệu lôgíc cũng có các mức độ khác nhau Điều quan trọng bạn nên hiểu

là hầu hết thay đổi lôgíc cũng liên quan đến thay đổi vật lý Chẳng hạn, bạn không thể thêm mới

đối tượng cơ sở dữ liệu (ví dụ, một bảng trong một DBMS quan hệ) mà không lưu trữ vật lý dữ liệu ở vị trí nào đó; do vậy, sẽ có một thay đổi tương ứng được tạo ra ở lớp vật lý Ngoài ra, việc xóa các đối tượng trong lớp lôgíc sẽ khiến mọi thứ đang sử dụng những đối tượng đó thất bại, nhưng không gây ảnh hưởng nào khác

Sau đây là một số ví dụ về thay đổi an toàn ở lớp lôgíc nhờ tính độc lập dữ liệu lôgíc:

● Thêm một đối tượng cơ sở dữ liệu mới

● Thêm các thành phần dữ liệu vào một đối tượng có sẵn

● Khi cần thực hiện một thay đổi ở lớp lôgíc (chẳng hạn như kết hợp hay tách những đối tượng

có sẵn), trong trường hợp này có thể tạo view ở mô hình ngoài để thay thế (các xử lý thông qua view thay thế cũng cho kết quả giống như xử lý trực tiếp với đối tượng ban đầu ở lớp lôgíc)

Các mô hình cơ sở dữ liệu thông dụng

Một mô hình cơ sở dữ liệu cơ bản là kiến trúc DBMS sử dụng để lưu các đối tượng trong cơ sở

dữ liệu và liên kết chúng với nhau Các mô hình cơ sở dữ liệu thông dụng nhất sau đây được trình bày lần lượt theo thứ tự phát triển Phần tiếp theo sẽ trình bày tóm lược lịch sử của cơ sở dữ liệu

để giúp sắp xếp mọi thứ theo trật tự thời gian

File phẳng

File phẳng (flat file) là file hệ điều hành “thông thường”, tại đó, các bản ghi nằm trong file không

chứa thông tin về cấu trúc file hay bất kỳ mối quan hệ nào giữa các bản ghi để cung cấp cho ứng dụng sử dụng file Các ứng dụng sử dụng file hay người xem nội dung file cần nắm rõ thông tin

về cấu trúc hay ý nghĩa của dữ liệu trong file Về cơ bản, file phẳng không phải là các cơ sở dữ liệu vì chúng không đáp ứng được các tiêu chí đã đề ra ở phần trước Tuy nhiên, có hai điều quan trọng bạn cần hiểu rõ ở đây Trước hết, file phẳng thường được dùng để lưu trữ thông tin cơ sở dữ liệu Trong trường hợp này, hệ điều hành vẫn không hiểu được nội dung và cấu trúc của các file,

nhưng DBMS chứa siêu dữ liệu (metadata) cho phép chuyển giữa file phẳng trong lớp vật lý và các cấu trúc cơ sở dữ liệu nằm trong lớp lôgíc Theo nghĩa đen, siêu dữ liệu có nghĩa là “dữ liệu về

dữ liệu”, là thuật ngữ được sử dụng khi đề cập tới những thông tin mà cơ sở dữ liệu lưu trữ trong catalog để mô tả dữ liệu được lưu trong cơ sở dữ liệu và mối quan hệ giữa các dữ liệu Chẳng hạn, siêu dữ liệu về một khách hàng có thể bao gồm tất cả các thành phần dữ liệu được thu thập về khách hàng (như tên, địa chỉ và trạng thái tài khoản) cùng với độ dài, giá trị dữ liệu tối thiểu, tối

đa và mô tả ngắn gọn về từng thành phần dữ liệu Thứ hai, các file phẳng tồn tại trước khi có cơ

sở dữ liệu, và các hệ thống cơ sở dữ liệu sơ khai đã được phát triển từ hệ thống file phẳng.

Trên Hình 1-2 là một hệ thống file phẳng mẫu, một phần nhỏ dữ liệu của công ty giả tưởng tên là Northwind Traders, nhà cung cấp các mặt hàng thực phẩm đa quốc gia (và là một cơ sở dữ liệu mẫu của Microsoft) Nhớ rằng, các tiêu đề cột (Customer ID, Company Name…) được đưa vào chỉ với mục đích minh họa - chỉ có các bản ghi dữ liệu được lưu trữ trong những file thực sự

Dữ liệu khách hàng được lưu trữ trong file Customer, ở đó, mỗi bản ghi đại diện cho một khách hàng của Northwind Mỗi khách hàng của Northwind có một bản ghi trong file Employee, và mỗi sản phẩm được Northwind bán ra có một bản ghi trong file Product Dữ liệu về đơn đặt hàng (đơn đặt hàng của khách hàng với Northwind) được lưu trữ trong hai file phẳng khác File Order chứa một bản ghi của mỗi đơn đặt hàng từ khách hàng, lưu dữ liệu về đơn đặt hàng, như ID của khách hàng và tên của nhân viên đã nhận đơn đặt hàng từ khách File Order Detail chứa các dòng chi tiết

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

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 Detail

Order ID Product ID Unit Price Quantity

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.

đị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)

Product 7 Order Detail:Product 51

Hình 1-4 Nội dung bản ghi trong mô hình phân cấp của Northwind

Như bạn thấy, mỗi lớp trong phân cấp có một chuỗi nhiều con trỏ kết nối các bản ghi theo thứ tự hợp lý Một khác biệt quan trọng nữa giữa hệ thống file phẳng và mô hình phân cấp là: khóa (định danh) của bản ghi cha bị loại khỏi bản ghi con trong mô hình phân cấp, bởi các con trỏ kiểm soát mối quan hệ giữa các bản ghi Do đó, ID của khách hàng và ID của nhân viên bị loại khỏi bản ghi Order, và ID của sản phẩm bị loại khỏi bản ghi Order Detail Giữ lại các thông tin trên không phải

là ý kiến hay, vì việc này có thể khiến các thông tin trái ngược, chẳng hạn như một đơn đặt hàng, được một khách hàng trỏ tới trong khi chứa ID của một khách hàng khác

Mô hình mạng

Mô hình cơ sở dữ liệu mạng (network database model) được phát triển vào cùng thời điểm với mô hình cơ sở dữ liệu phân cấp Một ủy ban gồm các đại diện của những công ty trong ngành đã được thành lập để cùng xây dựng một phải pháp hiệu quả hơn Kẻ hoài nghi cho rằng, con lạc đà mà

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

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ượng

Mô hình hướng đối tượng (object-oriented - OO) bắt đầu từ những năm 1970, nhưng chưa được sử dụng theo mục đích thương mại cho tới những năm 1990 Mô hình hướng đối tượng bất ngờ trở nên phổ biến như vậy xuất phát từ thực tế lúc bấy giờ, hệ quản trị cơ sở dữ liệu quan hệ (RDBMS) không thể xử lý được các loại dữ liệu phức tạp như hình ảnh, bản vẽ, file video, âm thanh Sự bùng nổ của Internet và World Wide Web đã tạo ra nhu cầu cấp thiết phải cung cấp các kiểu dữ liệu phức tạp

Đối tượng (object) là nhóm lôgíc tập hợp những dữ liệu liên quan và lôgíc chương trình biểu

diễn cho các sự vật trong thế giới thực, như khách hàng, nhân viên, đơn hàng hay sản phẩm Các

thành phần dữ liệu đơn lẻ, như ID, tên khách hàng, được gọi là biến (variable) trong mô hình OO và được lưu trữ bên trong mỗi đối tượng Bạn có thể hiểu biến chính là biến thể hiện (instance variable) hay thuộc tính (property), nhưng chúng ta chỉ sử dụng thuật ngữ biến để đảm bảo sự nhất quán Theo thuật ngữ của mô hình hướng đối tượng, phương thức (method) là một bộ phận của lôgíc chương

trình ứng dụng, xử lý trên một đối tượng cụ thể, cung cấp một chức năng xác định, như kiểm tra giới hạn dư nợ của khách hàng hay cập nhật địa chỉ của khách hàng Trong số các điểm khác biệt giữa

mô hình OO với những mô hình đã trình bày, khác biệt quan trọng nhất là các biến chỉ có thể được

truy cập thông qua các phương thức Tính chất này được gọi là đóng gói (encapsulation).

Định nghĩa đối tượng được dùng ở đây chỉ áp dụng cho mô hình OO Thuật ngữ đối tượng cơ

sở dữ liệu (database object) sử dụng trong các phần trước chỉ mọi phần tử được đặt tên, đồng thời

lưu trong cơ sở dữ liệu không hướng đối tượng (ví dụ như bảng, chỉ mục hoặc view) OO cũng có những khái niệm giống cơ sở dữ liệu quan hệ, do đó, các thuật ngữ có thể giống nhau nhưng có thể không chính xác về mặt nghĩa

Hình 1-9 biểu diễn đối tượng Customer như một ví dụ về việc cài đặt các đối trượng trong

OO Vòng tròn phương thức bao quanh vòng tròn chứa các biến ở trung tâm biểu diễn cho tính

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 đổi trạ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ượng

Mặc dù mô hình hướng đối tượng (OO) có nhiều ưu điểm quan trọng trong việc đóng gói dữ liệu nhằm giảm thiểu tối đa ảnh hưởng của việc thay đổi hệ thống, song do không có khả năng truy vấn ad-hoc, nên mô hình này chỉ phù hợp với một phân đoạn thị trường riêng cần xử lý những dữ liệu phức tạp nhưng không cần tới khả năng truy vấn ad-hoc Tuy nhiên, một số nhà cung cấp cơ sở dữ liệu quan hệ đã chỉ ra các ưu điểm quan trọng của mô hình OO, đặc biệt là khả năng ánh xạ những kiểu dữ liệu phức tạp, cũng như thêm khả năng giống-như-đối tượng vào các sản phẩm hệ quản trị cơ sở dữ liệu với hy vọng tận dụng được những ưu điểm tốt nhất của cả hai mô hình Mặc dù những người theo chủ nghĩa hướng đối tượng thuần túy không tán thành, nhưng cách tiếp cận này

đã được áp dụng khá rộng rãi, trong khi đó các cơ sở dữ liệu hướng đối tượng thuần túy chỉ được

sử dụng trong phân đoạn thị trường riêng Tên ban đầu của kiểu cơ sở dữ liệu này là cơ sở dữ liệu vạn năng (universal database), và dù những nhà tiếp thị kinh doanh rất thích dùng thuật ngữ này,

nhưng giới kỹ thuật lại không bao giờ sử dụng tới, do đó, tên thường dùng cho mô hình này trở

thành quan hệ đối tượng (object-relational - OR) Qua lịch sử phát triển, Oracle, DB2, Informix

có thể được coi là những hệ quản trị cơ sở dữ liệu OR với nhiều cấp độ khác nhau

Để hiểu mô hình OR một cách đầy đủ, bạn cần có kiến thức sâu hơn về mô hình quan hệ và

mô hình OO Tuy nhiên, hãy nhớ rằng, hệ quản trị cơ sở dữ liệu OR kết hợp các tính năng được

mong đợi từ mô hình đối tượng, chẳng hạn như khả năng lưu trữ các loại dữ liệu phức tạp, với sự đơn giản và dễ sử dụng của mô hình quan hệ Hầu hết các chuyên gia trong ngành đều tin rằng công nghệ quan hệ đối tượng sẽ tiếp tục giành được thị phần.

Tóm tắt lịch sử cơ sở dữ liệu

Các dự án thăm dò không gian dẫn đến sự phát triển quan trọng của nhiều ngành công nghiệp khoa học công nghệ, trong đó có công nghệ thông tin Để phục vụ dự án thám hiểm mặt trăng của NASA, năm 1964, Hãng Hàng không Bắc Mỹ (North American Aviation - NAA) đã tiến hành xây dựng hệ thống file phân cấp có tên là Generalized Update Access Method (GUAM) IBM đã kết hợp với NAA để phát triển GUAM và cho ra đời cơ sở dữ liệu mô hình phân cấp thương mại đầu tiên, được gọi là Hệ thống Quản lý Thông tin (Information Management System - IMS), phát hành năm 1966

Giữa những năm 1960, dưới sự hướng dẫn của nhà khoa học máy tính nổi tiếng lúc bấy giờ

là Charles W Bachman, công ty General Electric đã tự phát triển cơ sở dữ liệu đầu tiên dựa trên

mô hình mạng và đặt tên là Kho Dữ liệu Tích hợp (Integrated Data Store - IDS) Năm 1967, tại hội nghị bàn về các ngôn ngữ cho các hệ thống dữ liệu (Data Systems Languages - CODASYL), một nhóm công ty đã thành lập Nhóm Đặc nhiệm Cơ sở dữ liệu (Database Task Group - DBTG)

và bắt đầu làm việc để thiết lập tập các tiêu chuẩn cho mô hình mạng Để đáp lại những chỉ trích

về hạn chế “một cha” (“single-parent”) trong mô hình phân cấp, IBM đã giới thiệu một phiên bản của IMS giải quyết được vấn đề đó bằng cách cho phép các bản ghi có một “cha” vật lý và nhiều

“cha” lôgíc

Tháng 6 năm 1970, E.F (Ted) Codd, một nhà nghiên cứu của IBM (sau này là thành viên của IBM Fellow – vị trí được chính Giám đốc Điều hành của IBM bổ nhiệm, mỗi năm chỉ bổ nhiệm từ

4 đến 9 thành viên), đã công bố bài nghiên cứu với tiêu đề “Mô hình quan hệ dữ liệu cho các ngân

hàng dữ liệu chia sẻ lớn” trên tạp chí Communications of the ACM, tạp chí của Hiệp hội Máy tính

Mỹ (Association for Computing Machinery – ACM) (Ấn phẩm này có thể dễ dàng tìm thấy trên Internet) Năm 1971, DBTG CODASYL công bố tiêu chuẩn cho mô hình mạng sau hơn 3 năm làm việc Điều này đã khởi đầu cho cuộc tranh luận sôi nổi kéo dài 5 năm về việc mô hình nào là tốt nhất.Những người ủng hộ DBTG CODASYL lập luận như sau:

● Mô hình quan hệ mang nặng tính chất toán học

● Không thể triển khai được mô hình quan hệ một cách hiệu quả

● Hệ thống ứng dụng cần xử lý dữ liệu làm việc với từng bản ghi ở một thời điểm

Những người ủng hộ mô hình quan hệ lập luận như sau:

● Mô hình mà DBTG đưa ra quá phức tạp để quản lý dữ liệu chính xác

● Các truy vấn hướng tập hợp quá khó trong ngôn ngữ DBTG

● Mô hình mạng không có cơ sở lý thuyết toán học chính thức

Các cuộc tranh luận kéo dài cho tới hội nghị SIGMOD (Special Interest Group on Management

of Data) do Hiệp hội Máy tính Mỹ tổ chức vào năm 1975 Codd cùng hai người khác đã tranh luận

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 tional Standards Institute) và ISO (International Organization for Standardization)

Na-● 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 1

Chọn đáp án đúng cho các câu hỏi lựa chọn và câu hỏi điền vào chỗ trống Chú ý, có thể có nhiều đáp án đúng cho mỗi câu hỏi

1 Lớp lôgíc trong mô hình ANSI/SPARC có đặc điểm nào sau đây?

3 Điều nào sau đây là không đúng khi nói về view người dùng?

A Các chương trình ứng dụng tham chiếu tới các view người dùng

B Được tham chiếu tới bởi những người truy vấn cơ sở dữ liệu

C Các view người dùng có thể được thiết kế theo yêu cầu của người dùng cơ sở dữ liệu

D Dữ liệu cập nhật được hiển thị không tức thời

4 Schema cơ sở dữ liệu nằm trong lớp của mô hình ANSI/SPARC

5 Các view người dùng nằm trong lớp của mô hình ANSI/SPARC

6 Khi nào chương trình ứng dụng sử dụng hệ thống file phẳng? Các định nghĩa file nằm ở đâu?

7 Câu nào sau đây là đúng khi nói đến mô hình cơ sở dữ liệu phân cấp?

A Được phát triển lần đầu bởi Peter Chen

B Dữ liệu và phương thức được lưu trữ trong cơ sở dữ liệu

C Mỗi nút có thể có nhiều nút cha

D Các bản ghi được kết nối bằng cách sử dụng những con trỏ địa chỉ vật lý

8 Câu nào sau đây là đúng khi nói đến mô hình cơ sở dữ liệu mạng?

A Được phát triển lần đầu bởi E.F Codd

B Dữ liệu và phương thức được lưu trữ trong cơ sở dữ liệu

C Mỗi nút có thể có nhiều nút cha

D Các bản ghi được kết nối bằng cách sử dụng những con trỏ địa chỉ vật lý

9 Câu nào sau đây là đúng khi nói đến mô hình cơ sở dữ liệu quan hệ?

A Được phát triển lần đầu bởi Charles Bachman

B Dữ liệu và phương thức được lưu trữ trong cơ sở dữ liệu

C Các bản ghi được kết nối bằng cách sử dụng những con trỏ địa chỉ vật lý

D Các bản ghi được liên kết với nhau bằng cách sử dụng những thành phần dữ liệu chung trong mỗi bản ghi

10 Câu nào sau đây là đúng khi nói đến mô hình hướng đối tượng?

A Được phát triển lần đầu bởi Charles Bachman

B Dữ liệu và phương thức được lưu trữ trong cơ sở dữ liệu

C Dữ liệu được biểu diễn dưới dạng các bảng hai chiều

D Các bản ghi được liên kết với nhau bằng cách sử dụng những thành phần dữ liệu chung trong mỗi bản ghi

11 Câu nào sau đây là đúng khi nói đến mô hình quan hệ đối tượng?

A Mô hình này chỉ phục vụ một phân đoạn thị trường riêng và các chuyên gia đều cho rằng

mô hình này sẽ không phát triển rộng được

B Các bản ghi được kết nối bằng cách sử dụng những con trỏ địa chỉ vật lý

C Mô hình này được tạo ra bằng cách thêm các thuộc tính giống-như-đối tượng vào mô hình quan hệ

D Mô hình này được tạo ra bằng cách thêm các thuộc tính giống-như-quan hệ vào mô hình đối tượng

12 Với những người ủng hộ mô hình quan hệ, những điều nào dưới đây mô tả các vấn đề của mô hình CODASYL?

A Mô hình CODASYL mang nặng tính toán học

B Mô hình CODASYL quá phức tạp

C Các truy vấn hướng tập hợp quá khó

D Mô hình này không có cơ sở lý thuyết toán học chính thức

13 Với những người ủng hộ mô hình CODASYL, những điều nào dưới đây mô tả các vấn đề của

mô hình quan hệ?

A Mô hình quan hệ mang nặng tính toán học

B Các truy vấn hướng tập hợp quá khó

C Các hệ thống ứng dụng cần xử lý bản ghi tại một thời điểm

D Mô hình quan hệ kém hiệu quả hơn mô hình CODASYL

14 Khả năng thêm một đối tượng mới vào cơ sở dữ liệu mà không làm gián đoạn quá trình hiện tại là một ví dụ về

15 Thuộc tính giúp phân biệt một bảng cơ sở dữ liệu quan hệ với một trang tính là khả năng cung cấp cho nhiều người dùng của chính họ

Tì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