Bài giảng Nhập môn Cơ sở dữ liệu

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 Employee Employee ID First Name Last Name Job Title Automobile VIN Make Model Year Color Employee ID (FK) Hình 2-2 Quan hệ Employee-automobile. 33Chương 2: Tìm hiểu các thành phần của cơ sở dữ liệu quan hệ 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ều Quan 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 Reason Account Closure Reason Code Description Customer Customer ID Company Name Address City State / Province Country / Region Business Phone Account Closure Reason Code (FK) Credit Report Credit Report Number Report Date Credit Score Notes Customer ID (FK) 34 Nhập môn Cơ sở dữ liệu 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ều Quan 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. 35Chương 2: Tìm hiểu các thành phần của cơ sở dữ liệu quan hệ 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. Employee Employee ID Last Name First Name Job Title Spouse Employee ID (FK) Employee Employee ID Last Name First Name Job Title Manager 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 36 Nhập môn Cơ sở dữ liệu 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ành 1. 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ị. 37Chương 2: Tìm hiểu các thành phần của cơ sở dữ liệu quan hệ 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 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: 38 Nhập môn Cơ sở dữ liệu ● 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ẫu Bạ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 39Chương 2: Tìm hiểu các thành phần của cơ sở dữ liệu quan hệ 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. 40 Nhập môn Cơ sở dữ liệu (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ệu Như đã đề 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ở 41Chương 2: Tìm hiểu các thành phần của cơ sở dữ liệu quan hệ 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). 42 Nhập môn Cơ sở dữ liệu 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ộc Rà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ả. 43Chương 2: Tìm hiểu các thành phần của cơ sở dữ liệu quan hệ 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ính Khó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 44 Nhập môn Cơ sở dữ liệu 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: 45Chương 2: Tìm hiểu các thành phần của cơ sở dữ liệu quan hệ 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. 46 Nhập môn Cơ sở dữ liệu 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. 47Chương 2: Tìm hiểu các thành phần của cơ sở dữ liệu quan hệ 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 giao Quan 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. 48 Nhập môn Cơ sở dữ liệu 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. 49Chương 2: Tìm hiểu các thành phần của cơ sở dữ liệu quan hệ ● 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ẹn Như đã đề 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 NULL Khi đị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. 50 Nhập môn Cơ sở dữ liệu 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 =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 =0) 51Chương 2: Tìm hiểu các thành phần của cơ sở dữ liệu quan hệ Các ràng buộc thực thi sử dụng trigger Mộ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. View View (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. 52 Nhập môn Cơ sở dữ liệu 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). 53Chương 2: Tìm hiểu các thành phần của cơ sở dữ liệu quan hệ 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 2 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. 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ệ. 54 Nhập môn Cơ sở dữ liệu 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ả. 55Chương 2: Tìm hiểu các thành phần của cơ sở dữ liệu quan hệ 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.