Session 01

Bài 1

Thiết Kế CSDL

Mục tiêu bài học:      

Tìm hiểu các khái niệm thiết kế CSDL và mô hình hóa dữ liệu Mô tả mô hình E-R và sơ đồ E-R trong thiết kế CSDL Liệt kê các thành phần của sơ đồ E-R Tìm hiểu quá trình chuẩn hóa Liệt kê các dạng chuẩn Tìm hiểu các quy tắc chuẩn hóa

Giới thiệu CSDL dùng để lưu trữ dữ liệu một cách có tổ chức và hiệu quả. CSDL giúp ta quản lý dữ liệu một cách dễ dàng và nhanh chóng. SQL Server 2000 cung cấp một nền tảng quản lý dữ liệu cấp doanh nghiệp. SQL Server 2000 là phiên bản mới nhất của CSDL SQL Server. Trong kỳ học trước chúng ta đã nghiên cứu các khái niệm cơ bản của CSDL quan hệ cũng như SQL Server 2000. Trong kỳ học này chúng ta sẽ đi tìm hiểu tiếp một số chủ đề nâng cao hơn về SQL Server 2000. Các chủ đề này bao gồm: mô hình hóa CSDL, xử lý theo lô, khóa, truy vấn con/liên kết, chỉ mục, các thủ tục lưu trữ (stored procedure), trigger và các cơ chế bảo mật. 1.1

Thiết kế và mô hình hóa CSDL

CSDL là một tập hợp dữ liệu có tổ chức và có mối quan hệ giúp ta có thể dễ dàng truy xuất, quan lý và cập nhật. Trong bài này chúng ta sẽ tìm hiểu cách thiết kế CSDL. Hãy xem ví dụ về một công ty đã hưởng lợi từ việc thiết kế CSDL để lưu trữ các thông tin của mình. Trong thế giới kinh doanh hiện nay, việc dữ đoán các sự kiện và chuẩn bị cho các sự kiện đó có thể tiết kiệm tiền bạc và thời gian cho doanh nghiệp. Chúng ta cùng tìm hiểu ví dụ sau. Một công ty sản xuất đồ hộp nhựa chất lượng cao đang lên kế hoạch nhập nguyên liệu thô hàng năm. Với dữ liệu bán hàng trong 10 năm qua, ban lãnh đạo công ty có thể tính ra tỷ lệ tăng trưởng của lượng hàng tiêu thụ được. Giá sử họ tính ra tỷ lệ tăng trưởng hàng năm từ 22% đến 27%. Dựa vào tính toán này, họ có thể lên kế hoạch sản xuất với sản lượng tăng khoảng 30%. Lúc này công ty sẽ chỉ đặt số lượng nguyên liệu phù hợp, nhờ đó tiết kiệm được ngoại tệ, nhà xưởng và các tài nguyên liên quan khác. Kết quả là nhờ sự phân tích trên công ty có thể giao hàng đúng hạn cho khách hàng. Ví dụ này đã cho ta thấy một công ty có thể lập kế hoạch và lên lịch mua nguyên liệu dựa trên các thông tin đúc kết từ dữ liệu và khách hàng của họ cũng hưởng lợi. Đây chỉ là một ví dụ nhỏ cho chúng ta thấy việc phân tích dữ liệu một cách thông minh cho ta những thông tin có giá trị.

1.1.1 Mục đích thiết kế CSDL

Thiết kế CSDL

1

Để phấn tích được dữ liệu ta cần có một CSDL tốt, muốn vậy cần phải thiết kế CSDL một cách hiệu quả. Thiết kế CSDL là gì ? Thiết kế CSDL là quá trình lập kế hoạch và cấu trúc các đối tượng dữ liệu cùng với các quan hệ giữa chúng (nếu có) trong CSDL.

Hình 1.1: CSDL thông tin học viên Hình 1.1 là ví dụ về CSDL thông tin và điểm thi của học viên. Sơ đồ trên cũng chỉ ra mối quan hệ giữa các đối tượng dữ liệu Student, Test và Marks. Tại sao lại phải thiết kế CSDL? Các đối tượng dữ liệu được tạo ra trong CSDL và các mối quan hệ phức tạp được xây dựng quanh các đối tượng dữ liệu này đóng vai trò hết sức quan trọng quyết định đến hiệu quả của CSDL. Một CSDL thiết kế tồi có thể dẫn tới: 1. Hiệu quả thấp 2. Sai sót trong cập nhật và truy xuất dữ liệu Ngược lại, một CSDL thiết kế tốt mang lại: 1. Hiệu quả cao 2. Dễ dàng mở rộng CSDL 3. Dễ phát triển ứng dụng Thiết kế CSDL có khó không? Thiết kế bất kỳ một file hay một CSDL không phải là một công việc đơn giản. Có một số vấn đề liên quan đến thiết kế CSDL. Do vậy chúng ta phải nắm vững cách thiết kế CSDL. Một trong những biện pháp tốt và hiệu quả là mô hình hóa CSDL. Chúng ta sẽ nghiên cứu mô hình hóa CSDL ở phần sau của bài. 1.1.2 Quá trình thiết kế CSDL Bước đầu tiên của thiết kế CSDL là lập kế hoạch cho CSDL, kế hoạch này đóng vai trò là bản hướng dẫn khi thực hiện thiết kế đồng thời làm tài liệu kỹ thuật cho CSDL khi đã hoàn thành thiết

2

Thiết kế CSDL và làm việc với CSDL SQL Server

kế. Chi tiết và độ phức tạp của CSDL được quyết định bởi một số yếu tố như sự phức tạp và độ lớn của ứng dụng, số lượng người sử dụng. Độ phức tạp của CSDL và tiến trình lập kế hoạch có thể biến đổi. Một CSDL có thể được thiết kế bởi một người và có thể khá đơn giản hoặc cũng có thể rất lớn và phức tạp, ví dụ, CSDL xử lý hàng trăm nghìn giao dịch ngân hàng. Với trường hợp đầu, việc thiết kế CSDL đơn giản chỉ cần một vài chi chú lên giấy. Trong trường hợp sau ta cần phải có tài liệu chính thức hàng trăm trang chứa tất cả các thông tin chi tiết có thể có trong CSDL. Một số bước cơ bản sau có thể được sử dụng khi thiết kế CSDL bất kể độ lớn và độ phức tạp của CSDL: 1. 2. 3. 4. 5.

Thu thập thông tin Xác định các đối tượng Thiết kế mô hình Xác định loại thông tin cho mỗi đối tượng Xác định quan hệ giữa các đối tượng

Chúng ta đi nghiên cứu chi tiết của từng bước trên. 1. Thu thập thông tin • • • • •

Trước khi thiết kế CSDL ta cần nắm vững những yêu cầu của một CSDL và vai trò của nó. Nếu CSDL được tạo ra để thay thế cho hệ thông dữ liệu giấy hay hệ thống quản lý thông tin thủ công thì các hệ thống cũ sẽ là nguồn thông tin chính cần thu thập. Việc phỏng vấn những người dùng hệ thống để tìm hiểu công việc và yêu cầu của họ cũng rất quan trọng. Cũng cần thiết phải xác định được chức năng của hệ thống mới cũng như xác định các vấn đề, hạn chế và điểm tắc của hệ thống cũ. Cần thu thập các bản sao của các giấy tờ liên quan đến khách hàng, danh sách hàng trong kho và bất kỳ tài liệu nào liên quan đến hệ thống cũ, bởi vì các tài liệu này rất có ích trong thiết kế CSDL và giao diện.

2. Xác định các đối tượng Trong quá trình thu thập thông tin, chúng ta phải xác định các đối tượng hay thực thể chính cần quản lý trong CSDL. Các đối tượng này có thể là những vật hữu hình như người hay sản phẩm hay những vật vô hình như một giao dịch kinh doanh, một phòng ban của côngt y hay một kỳ lương. Thông thường ta sẽ xác định một số đối tượng chính sau đó các đối tượng liên quan sẽ dần định hình. Mỗi đối tượng xác định được sẽ tương ứng với một bảng dữ liệu trong CSDL. 3. Mô hình hóa các đối tượng Khi các đối tượng trong hệ thống được xác định, ta cần đưa chúng vào mô hình sao cho có thể thể hiện một cách trực quan toàn bộ hệ thống. Mô hình CSDL này sau đó có thể được sử dụng để tham khảo trong quá trình thực thi CSDL.

Thiết kế CSDL

3

Chú ý: SQL Server 2000 Enterprise Manager là công cụ thiết kế trực quan giúp thiết kế và tạo các đối tượng trong CSDL. 4. Xác định các loại thông tin cho mỗi đối tượng Sau khi các đối tượng chính của CSDL được xác định, bước tiếp theo là xác định các thông tin được lưu trữ cho mỗi đối tượng. Các thông tin này thường được thể hiện dưới dạng các trường dữ liệu trong bảng đối tượng và có thể được phân loại như sau: Các trường dữ liệu

Mô tả

Các trường dữ liệu Các trường này chứa các thông tin hữu hình như tên, được quyết thô định bởi các nguồn ngoài CSDL. Các trường dữ liệu Các trường này phân loại hay nhóm dữ liệu, chúng chứa những dữ phân loại liệu đơn giản như true/false, married/single, VP/Director/Group Manager, v.v. Các trường xác thực Các trường này giúp xác định mỗi thực thể lưu trong bảng. Chúng (ID) thường có những từ id hay number (ví dụ, employee_id, invoice_number). Trường xác thực là thành phần chính được sử dụng bởi cả người dùng và các cơ chế sử lý bên trong CSDL để truy xuất một bản ghi dữ liệu trong bảng. Các trường quan hệ Các trường này thiết lập kết nối giữa thông tin trong một bảng với tham chiếu thông tin trong bảng khác. Ví dụ, bảng lưu thông tin về các giao dịch bán hàng thường có liên kết với bảng customers giúp truy xuất toàn bộ thông tin của khách hàng trong giao dịch bán hàng. Bảng 1.1: Các trường dữ liệu 5. Xác định mối quan hệ giữa các đối tượng Một trong những thế mạnh của CSDL quan hệ là khả năng gắn kết thông tin giữa nhiều đối tượng trong CSDL. Các loại thông tin được lưu trữ độc lập nhưng CSDL có khả năng truy xuất kết hợp dữ liệu khi cần thiết. Việc xác định mối quan hệ giữa các đối tượng trong quá trình thiết kế đòi hỏi ta phải xem xét các bảng và tìm ra mối quan hệ logic giữa chúng, thêm vào các trường dữ liệu quan hệ và thiết lập kết nối giữa các bảng.

4

Thiết kế CSDL và làm việc với CSDL SQL Server

1.1.3 Mô hình hóa CSDL Sơ đồ mô hình dữ liệu thể hiện mối quan hệ giữa các bảng (thực thể). Sơ đồ này rất có ích với người thiết kế, quản trị hay lập trình với CSDL. Mô hình hóa CSDL có thể được chia thành 3 bước chính sau. Hình 1.2 mô tả quá trình thiết kế CSDL. Các yêu cầu về thông tin nghiệp vụ

Mô hình hóa khái niệm (Conceptual Data Modeling) Thiết kế CSDL Logic (Logical Database Design)

Business view

Systems view

Xây dựng CSDL vật lý (Physical Database Build)

CSDL hoạt động (Operational Database)

Hình 1.2: Quá trình phát triển CSDL Mô hình dữ liệu khái niệm là mô hình trừu tượng hóa dữ liệu mức cao. Mô hình này rất gần với cách nhìn của người dùng về hệ thống. Mô hình này cũng là phương tiện giao tiếp giữa người dùng và lập trình viên. Mô hình hóa khái niệm độc lập với các hệ quản trị CSDL. Trong bài này, chúng ta sẽ tìm hiểu chi tiết về cách thiết kế CSDL logic. Thiết kế CSDL vật lý liên quan đến cách lưu trữ, truyu xuất và ràng buộc dữ liệu để đảm bảo tốc độ phù hợp. 1.2

Thiết kế CSDL logic

Thiết kế CSDL logic bao gồm quá trình xây dựng mô hình thông tin trong doanh nghiệp dựa trên một mô hình dữ liệu cụ thể, nhưng độc lập với CSDL hay các vấn đề vật lý khác. Công cụ mô hình hóa phổ biến nhất được dùng cho việc thiết kế CSDL logic là Sơ đồ quan hệ thực thể (E-R diagram). Mô hình này là nền tảng cho nhiều mô hình khác. Nó mô tả dữ liệu và các mối quan hệ giữa các dữ liệu trong một hệ thống. Trong mô hình E-R dữ liệu được mô tả là các thực thể, thuộc tính và các quan hệ. Sơ đồ The E-R được sử dụng chủ yếu trong quá trình thiết kế CSDL và thể hiện cấu trúc logic chung của CSDL.

Thiết kế CSDL

5

1.2.1 Mô hình Quan hệ - Thực thể Mô hình E-R là công cụ thân thiện và hiệu quả để mô hình hóa dữ liệu. Mô hình này thể hiện thế giới thực dưới dạng các đối tượng cơ bản và các mối quan hệ giữa chúng. Các thành phần của mô hình E-R được liệt kê dưới đây:

 Thực thể - Thực thể là một đối tượng tồn tại và có thể phân biệt với các đối tượng khác. Ví dụ, John có số an sinh xã hội là 890-12-3456 là một thực thể bởi người này có thể được xác định là một người duy nhất trong xã hội. Một thực thể có thể là hữu hình (một quyển sách) hay trừu tượng (như một kỳ nghỉ hay một khái niệm).

 Một tập hợp thực thể - Là một tập các thực thể cùng loại( ví dụ, những người có tài khoản trong ngân hàng).

 Các thuộc tính – Một thực thể được mô tả bằng một tập các thuộc tính. Ví dụ: Name, SSN, Age, Street, City là các thuộc tính của thực thể “Person”.

 Quan hệ và tập quan hệ - Quan hệ là sự gắn kết giữa hai hoặc nhiều thực thể. Một tập quan hệ là một tập hợp các quan hệ cùng kiểu. Chúng ta xem ví dụ về 2 tập thực thể Customers và Accounts. Ta dùng quan hệ CustAcct để mô tả sự gắn kết giữa customers và các accounts của họ..

Customers

C ust

Accounts

Hình 1.3: Quan hệ giữa 2 tập thực thể Một tập quan hệ có thể chứa nhiều hơn 2 tập thực thể như trong hình 1.4. Các tập thực thể như customers, loans và branches có thể được liên kết với nhâu bằng các quan hệ “Borrow”. Quan hệ “Borrow” chỉ ra rằng một khách hàng có thể vay tiền ở một chi nhánh nào đó của ngân hàng.

Customers

Borrow

Loans

Branches Hình 1.4: Quan hệ giữa 3 tập thực thể Tập thực thể trong một quan hệ không cần thiết phải là duy nhất. Vai trò quả một thực thể chính là chức năng của nó trong quan hệ. Ví dụ, quan hệ works-for có thể xuất hiện giứa các cặp thực

6

Thiết kế CSDL và làm việc với CSDL SQL Server

thể employee. Thực thể employee đầu đóng vai trò là người quản lý, và có một người khác đóng vai trò là nhân viên như trong hình sau:

Worker Work s

Employee Manager

Hình 1.5: Self Relationship Các nhãn “Manager” và “Worker” được gọi là các vai trò (roles); chúng chỉ ra tương tác giữa các thực thể employee qua quan hệ “Works for”. Ta có thể định nghĩa một tập các thực thể và quan hệ giữa chúng theo nhiều cách. Sự khác biệt lớn nhất giữa những cách này ở chỗ ta xử lý các thuộc tính như thế nào. Chúng ta xem tập thực thể employee có các thuộc tính Employee_Name, Phone_Number. Chúng ta có thể lập luận rằng thuộc tính phone có thể được coi là một thực thể với các thuộc tính Phone_Number và Location. Vậy ta sẽ có hai thực thể Employee và Phone, và quan hệ EmpPhn thể hiện sự ràng buộc giữa 2 thực thể này. Định nghĩa mới này có thể thể hiện chính xác hơn thế giới thực Tuy nhiên chúng ta không dễ mở rộng lập luận này và việc quyết định đối tượng nào là thuộc tính phụ thuộc chủ yếu vào cấu trúc của hoàn cảnh thế giới thực chúng ta đang mô hình hóa, và ngữ nghĩa của thuộc tính ta đang bàn đến.

 Ràng buộc số lượng – Ràng buộc số lượng thể hiện số thực thể mà một thực thể có quan hệ ràng buộc. Trong mối quan hệ giữa thực thể X và Y, ràng buộc số lượng có thể là một trong những loại sau: 1. Một-một: Một thực thể X có quan hệ với tối đa 1 thực thể Y và ngược lại. 2. Một-nhiều: Một thực thể X có quan hệ với vố số thực thể Y. Một thực thể Y có quan hệ ràng buộc với tối đa 1 thực thể X. 3. Nhiều-một: Một thực thể X có quan hệ với tối đa 1 thực thể Y. Một thực thể Y có quan hệ với vô số thực thể X. 4. Nhiều-nhiều: Các thực thể X và Y có quan hệ với vô số các thực thể của nhau.

Y Y Y Y

X X X X Một – một

Y Y Nhiều – một

Thiết kế CSDL

Một – nhiều Y

X X X X

Y Y Y Y

X X X X

Y Y Y Y

X X X X Nhiều – nhiều

7

Hình 1.6: Ràng buộc số lượng Việc lựa chọn ràng buộc số lượng phù hợp cho một quan hệ phụ thuộc vào các thực thể được mô hình hóa trong đời sống thực. Nếu sự tồn tại của thực thể X phụ thuộc vào sự tồn tại của thực thể Y ta nói Y là thực thể cha và X là thực thể con. Ví dụ, ta xem tập thực thể account và transaction, và quan hệ log giữa 2 thực thể này. Đây là quan hệ một-nhiều với một account có nhiều transaction. Nếu một thực thể account bị xóa các thực thể transaction có quan hệ với thực thể account đó cũng phải được xóa. Do đó account là thực thể cha còn transaction là thực thể con.

 Các trường khóa – Sự khác biệt giữa các thực thể phải được thể hiện bằng các thuộc tính. Khóa chính là một hay nhiều thuộc tính cho phép ta xác định duy nhất một thực thể trong một tập thực thể. Ví dụ, trong tập thực thể customer, các thuộc tính customer_name và S.S.N, kết hợp lại, được coi là khóa chính. Cần chú ý rằng customer_name không được coi là khóa chính vì 2 khách hàng có thể có cùng tên. Một khóa chính không có các tập bản ghi con được coi là khóa ứng viên (candidate key). Trong ví dụ trên S.S.N được coi là khóa ứng viên do thuộc tính này có thể xác định duy nhất một thực thể customer trong tập thực thể. Một tập thực thể không có đủ các thuộc tính để hình thành khóa chính được gọi là tập thực thể yếu (weak entity set). Tập thực thể có khóa chính được gọi là tập thực thể mạnh (strong entity set). Ví dụ, tập thực thể transaction có các thuộc tính transaction_number,date và amount. Các transactions khác nhau được thực hiện bởi những accounts khác nhau có thể chia sẻ chungcùng một mã số transction, điều này cho thấy không có thuộc tính nào có khả năng làm khóa chính (giúp xác định duy nhất một transaction) trong tập thực thể này. Do vậy transaction là một tập thực thể yếu. Để một thực thể yếu tồn tại, nó phải tham gia vào quan hệ một – nhiều. Ý tưởng các thực thể mạnh và yếu liên quan đến sự khác biệt về quan hệ tồn tại bàn ở trên. Các thành viên của một tập thực thể yếu không có khóa chính, nhưng chúng vẫn cần có công cụ để phân biệt với nhau. Yếu tố để phân tách các thực thể trong tập thực thể yếu là một tập các thuộc tính cho phép ta phan biệt được các thực thể. Khóa chính của một thực thể yếu được tạo ra bằng cách lấy khóa chính của thực thể mạnh kết hợp với trường phân biệt trong thực thể yếu. ‘Transaction’ là một thực thể yếu. Nó tồn tại phụ thuộc vào thực thể ‘account’. Khóa chính của thực thể account là account_number. Thuộc tính Transaction_Number phân biệt các thực thể transaction trong cùng một account (account_number,transaction_number). Do vậy, khóa chính của thực thể yếu này được hình thành bằng cách lấy khóa chính của thực thể mạnh mà nó phụ thuộc cùng với thuộc tính phân biệt của tập thực thể yếu. Các thuộc tính của một tập quan hệ là các thuộc tính bao gồm các khóa chính của các tập thực thể trong quan hệ. Ví dụ:: S.S.N là khóa chính của thực thể customer, và account-number là khóa chính của thực thể account. Do đó các thuộc tính của quan hệ CustAcct chính là (Account_Number, S.S.N). Đây là những thông tin đủ giúp chúng ta ràng buộc một account với một person. Nếu quan hệ chứa các thuộc tính mô tả, chúng cũng được đưa vào tập thuộc tính của quan hệ. Ví dụ, chúng ta có thể thêm thuộc tính date vào tập quan hệ trên, thuộc tính này mô tả ngày truy vấn account gần nhất của một customer. Chú ý rằng thuộc tính này không thể đưa vào

8

Thiết kế CSDL và làm việc với CSDL SQL Server

bất kỳ thực thể nào do nó liên quan đến cả customer và account, và mối quan hệ giữa hai thực thể này là nhiều – nhiều. 1.2.2

Sơ đồ quan hệ thực thể

Chúng ta có thể mô tả cấu trúc logic tổng thể của CSDL một cách trực quan bằng sơ đồ quan hệ thực thể (ERD). Các thành phần của ERD bao gồm: 1. Hình chữ nhật thể hiện các tập thực thể. 2. Hình Ellipses thể hiện các thuộc tính. 3. Hình thoi thể hiện các tập quan hệ. 4. Các đường thẳng liên kết các thuộc tính với các tập thực thể và các tập thực thể với các tập quan hệ. Các đường thẳng có thể directed (có mũi tên) để chỉ các ràng buộc số lượng trong các tập quan hệ. Hình 1.7 là một số ví dụ mô tả số lượng các thực thể liên quan mà một thực thể có quan hệ. Vị trí của mũi tên rất đơn giản, đầu mũi tên chỉ đến thực thể mà thực thể “one” trỏ đến. 1:1 – Một customer có tối đa một account và một account được sở hữu tối đa bởi một customer. 1:N – Một customer có thể có vô số accounts nhưng một account chỉ được sở hữu bởi tối đa một customer. M: N – Mỗi customer có thể có vô số accounts và mỗi account có thể được sở hữu bởi vô số customers. Các ký hiệu của sơ đồ E-R:

Ký hiệu

Ý nghĩa THỰC THỂ THỰC THỂ YẾU LOẠI QUAN HỆ THUỘC TÍNH THUỘC TÍNH CHÍNH THUỘC TÍNH NHIỀU GIÁ TRỊ

THUỘC TÍNH TỔNG HỢP

Thiết kế CSDL

9

THUỘC TÍNH PHÁT SINH Bảng 1.2: Các ký hiệu trong sơ đồ E-R Các thuộc tính tập hợp – Các thuộc tính của các tập thực thể có thể được chia thành các tập nhỏ hơn được gọi là các thuộc tính tập hợp (“composite attributes”), chứa những thuộc tính cơ bản với các ý nghĩa khác nhau. Ví dụ, thuộc tính Address của thực thể employee có thể bao gồm Street, City, State and Zip. Một thuộc tính nhiều giá trị (multivalued attribute) là thuộc tính chứa các giá trị cận trên và cận dưới cho giá trị của thực thể. Ví dụ, thuộc tính colors của một thực thể có thể chứa 5 giá trị. Vậy colors có thể chứa các giá trị từ 1 (cận dưới) đến 5 (cận trên). Trong một số trường hợp hai (hay nhiều hơn) các giá trị thuộc tính có liên quan đến nhau – ví dụ, các thuộc tính Age và Birthdate của thực thể person. Với một thực thể person, thuộc tính tuổi có thể được quyết định bởi ngày hiện tại và ngày sinh của thực thể person. Thuộc tính Age do đó được gọi là thuộc tính phái sinh (derived attribute) và được coi là phát sinh từ thuộc tính Birthdate, được gọi là thuộc tính lưu trữ (stored attribute). Chúng ta xem xét một số ví dụ về sơ đồ E-R mô tả các quan hệ 1:1, 1:N và N:N.

Street

Cust_Nam e

Acct_Number

Date City

Acct_Type

CustAcc t Deposito r

Customer

Account

One to One (1:1)

Street

Cust_Nam e

Customer

10

Date

Acct_Number

City

Acct_Type

CustAcc t Deposito r

Account

Thiết kế CSDL và làm việc với CSDL SQL Server

One to Many (1:N)

Thiết kế CSDL

11

Street

Cust_Nam e

Acct_Number

Date

City

Acct_Type

CustAcc t Deposito r

Customer

Account

Many to Many (M:N)

Hình 1.7: Sơ đồ E-R Các tập thực thể yếu trong sơ đồ E-R: Một tập thực thể yếu được xác định bằng một hình hộp có viền đôi. Ví dụ, tập thực thể ‘transaction’ phụ thuộc vào tập thực thể mạnh ‘account’ trên tập quan hệ ‘log’. Hình 1.8 mô tả ví dụ này. Khóa chính của một tập thực thể yếu được tạo bởi khóa chính của tập thực thể mạnh mà nó phụ thuộc kết hợp với trường pgân biệt của tập thực thể yếu. Trans_Number Acct_numbe r

Acct_Type

Account

Amount

Date

Lo

Transaction

Hình 1.8: Sơ đồ E-R có tập thực thể yếu Mô tả tập thực thể mạnh: Ta dùng bảng để trình bày thực thể với mỗi trường của bảng tương ứng với mỗi thuộc tính của tập thực thể. Mỗi bản ghi của bảng tương ứng với một thực thể của tập thực thể. Chúng ta có thể thêm mới, xóa hay sửa đổi các bản ghi của bảng (để thể hiện những thay đổi trong thế giới thực). Trong hình 1.9, các tập quan hệ là nhiều – một, và không chứa các thuộc tính mô tả. Khóa chính của tập thực thể yếu là khóa chính của tập thực thể mạnh. Bảng cho tập quan hệ sẽ có cùng các thuộc tính và do vậy bị dư thừa.

12

Thiết kế CSDL và làm việc với CSDL SQL Server

Street

Cust_Name

Date

Acct_Number

City

Acct_Type

CustAcct Deposito r

Customer

Account

Lo

Amount

Date

Transaction

Trans_Number

Hình 1.9: Sơ đồ E-R có các tập thực thể mạnh và yếu Bước đầu tiên để tạo ra một CSDL quan hệ thành công là phải có thiết kế logic tốt. Điều này bao gồm việc thiết kế các bảng và định nghĩa quan hệ giữa chúng. Thiết kế một CSDL hiệu quả bắt đầu bằng việc thiết kế một CSDL chuẩn hóa. Một CSDL logic được thiết kế tốt là nền tảng để thiết kế CSDL và ứng dụng có hiệu năng tốt. Một thiết kế CSDL logic tồi lại có tác động tiêu cực tới hiệu năng của toàn bộ hệ thống. Chuẩn hóa là một thuật ngữ mỹ miều dùng cho một chủ đề rất bình thường. Chuẩn hóa là quá trình loại bỏ những dư thừa dữ liệu khỏi CSDL. Hãy coi CSDL như là một tủ chứa tất. Phải có chỗ cho mọi thứ và mọi thứ phải được sắp đặt phù hợp. Nếu ta giữ những đôi tất lệch ở nhiều nơi ta sẽ không thể tìm thấy đôi tất vừa để đi trong ngày hôm sau. Nếu ta để lẫn lộn tất với đồ tắm ở cùng một chỗ thì rất có thể ta sẽ mặc nhầm nếu không chú ý. Cũng như vậy, tất cả các dữ liệu cần nằm trong những nhóm phù hợp. Không được xuất hiện những dữ liệu trong bảng giống như những đôi tất lệch. Dữ liệu cần được đặt trong những bảng phù hợp. Chuẩn hóa là một kỹ thuật giúp cho người dùng nhóm dữ liệu và đặt chúng trong những bảng phù hợp. Do vậy mà chuẩn hóa CSDL là bước rất quan trọng trước khi ta làm việc với nó. Có một số quy tắc dạng chuẩn được chấp nhận rộng rãi quy định quá trình tạo CSDL quan hệ. Ba dạng chuẩn đầu được chấp nhận rộng rãi và đóng vai trò quan trọng hơn 2 dạng chuẩn sau. Chúng ta sẽ xem xét các dạng chuẩn này ở các phần sau. 1.3 Chuẩn hóa CSDL Quá trình loại bỏ những dữ liệu dư thừa từ dữ liệu thu thập được để thiết kế các bảng của CSDL quan hệ được gọi là chuẩn hóa. Nếu được dùng một cách đúng đắn, chuẩn hóa là cách tốt nhất và dễ dàng nhất để tổ chức các bảng trong CSDL quan hệ. Khi chúng ta đưa dữ liệu về dạng chuẩn hóa, ta đã: •

Đưa cấu trúc dữ liệu về dạng đơn giản nhất

Thiết kế CSDL

13

• •

Loại bỏ các trường dữ liệu dư thừa từ các bảng Xác định các dữ liệu phụ thuộc nhau

Người ta đã đưa ra 5 dạng chuẩn, nhưng dữ liệu khi ở dạng chuẩn 3 thường được coi là hoàn toàn chuẩn hóa. Tuy nhiên, mức độ chuẩn hóa dữ liệu phụ thuộc vào từng ứng dụng cụ thể. Nếu dữ liệu không được chuẩn hóa phù hợp, sẽ có rất nhiều dữ liệu bị lặp lại trong bảng và ta sẽ phải tìm kiếm trong đống dữ liệu lặp lại này để tìm ra những dữ liệu quan trọng và những bất thường khi cập nhật dữ liệu có thể xảy ra. Nếu dữ liệu được chuẩn hóa quá mức, việc truy xuất dữ liệu sẽ bị chậm hơn do ta phải liên kết nhiều bảng. Thông thường mỗi bản ghi của một bảng sẽ mô tả một dữ liệu. Các dạng chuẩn hóa bao gồm: Dạng chuẩn 1 (1NF), Dạng chuẩn 2 (2NF), Dạng chuẩn 3 (3NF), Dạng chuẩn 4 (4NF) và Dạng chuẩn 5 (5NF). Trong hầu hết những tình huống thực tế, ta thường dừng ở dạng chuẩn 3 (3NF) do dạng chuẩn này đã loại bỏ tất cả những bất thường trong việc cập nhật dữ liệu. Ta cũng cần phải ý thức rằng không có sự bắt buộc phải chuẩn hóa các bảng ở mức cao nhất có thể. Tốc độ truy xuất dữ liệu phải được quan tâm và điều này dẫn đến việc bỏ qua một số bước chuẩn hóa. Mặc dù các mức độ chuẩn hóa đều có thể đạt được nhưng thường dạng chuẩn 3 được coi là mức chuẩn hóa cao nhất cần thực hiện trong hầu hết các ứng dụng. CSDL là một tập hợp các thông tin liên quan với nhau và do vậy không thể tránh khỏi việc một số đối tượng thông tin trong CSDL sẽ phụ thuộc lấn nhau. Các thông tin này có thể chứa 1 giá trị hay nhiều giá trị. Tên của một người (person) và ngày sinh là những giá trị đơn; các bằng cấp (qualifications) của một người hay các môn học (subjects) mà một giảng viên (instructor) dạy là những số liệu nhiều giá trị. Trước hết chúng ta sẽ xem xét các dữ liệu đơn giá trị và bàn về khái niệm sự phụ thuộc chức năng. Khái niệm thông tin phụ thuộc lẫn nhau là rất cơ bản. Ví dụ, tại bất kỳ thời điểm nào một mã tài khoản trong bảng Accounts cũng giúp ta xác định được tên khách hàng và ngày mở tài khoản. Đầu tiên Codd (1972) đã đưa ra 3 dạng chuẩn (1NF, 2NF và 3NF) tất cả đều dựa vào khái niệm sự phụ thuộc chức năng giữa các thuộc tính của một bảng. Các dạng chuẩn 4 và chuẩn 5 dựa vào sự phụ thuộc liên kết và nhiều giá trị và được đưa ra sau này. Quá trình chuẩn hóa dữ liệu hiệu quả bao gồm những công việc sau:  Loại bỏ các trường dữ liệu lặp lại khỏi bảng để đạt được dạng chuẩn 1. Ví dụ, nếu các thông tin về các lần lương được lưu trong bảng EMPLOYEES thì các thông tin này là những dữ liệu lặp lại.  Loại bỏ những dữ liệu không phụ thuộc hoàn toàn vào khóa chính khỏi bảng để đưa về dạng chuẩn 2. Vậy, nếu bảng chứa khóa chính tổng hợp (khóa chính dựa trên nhiều trường) và một số trường dữ liệu lại phụ thuộc vào một phần của trường khóa tổng hợp, ta loại những trường dữ liệu này và phần khóa mà nó phụ thuộc sang một bảng khác.

14

Thiết kế CSDL và làm việc với CSDL SQL Server

 Loại bỏ những dữ liệu không thuộc bảng (những dữ liệu hoàn toàn phụ thuộc vào một trường dữ liệu khác hay phụ thuộc vào khóa phụ) để đưa dữ liệu về dạng chuẩn 3.  Đảm bảo mỗi bản ghi của bảng chỉ chứa dữ liệu về một thực thể.

 Có thể đưa một số dữ liệu dư thừa vào bảng để tăng tốc độ truy xuất dữ liệu bằng cách loại bỏ những liên kết các bảng không cần thiết. Ví dụ, khi ta thêm các trường FIRST_NAME và LAST_NAME của thực thể employee vào bảng SALARY_HISTORY, ta bị dư thừa dữ liệu. Dừ rằng 2 trường dữ liệu này sẽ làm cho dữ liệu trong bảng bị dư thừa nhưng tốc độ truy xuất dữ liệu được cải thiện hơn. Quá trình thêm những dữ liệu dư thừa vào bảng để tăng tôc độ của CSDL được gọi là phi chuẩn hóa (de-normalization). Chúng ta cũng đã thấy các bảng cấu thành CSDL phải thỏa mãn một số thuộc tính. Ví dụ, các bảng không được tồn tại các bản ghi dữ liệu trùng nhau và thứ tự của các bản ghi là không quan trọng, mỗi thành phần trong bảng là thực thể đơn nhất. Các bảng thỏa mãn những yêu cầu cơ bản này vẫn có thể tồn tại những thuộc tính không cần thiết. Chúng ta sẽ xem xét các thuộc tính này và tìm hiểu cách biến đổi và chuẩn hóa các bảng để loại bỏ chúng. Chúng ta xem ví dụ về bảng Accounts. Bảng này chứa thông tin tài khoản và chi tiết các giao dịch của tài khoản khách hàng trong ngân hàng. AccNo Customer name 85001 Smith 85002 James 85003 Ritcha 86005 Jones

Address OpenedOn Type 1, Main 2, Main 3, Main 12, 7th

1/4/03 3/4/03 4/4/03 5/4/03

Transaction No. Savings 1 Savings 2 Savings 3 Current 4

Transaction Amount 1000 200 100 400

Transaction Date 2/4/03 4/4/03 5/4/03 6/4/03

Bảng 1.3: Bảng Account Về mặt khái niệm nếu ta để tất cả thông tin trong một bảng thì việc truy vấn dữ liệu sẽ rất tiện lợi và dễ dàng hơn. Nhưng bảng mô tả ở trên tồn tại những đặc tính không cần thiết: Thông tin lặp lại: Có rất nhiều thông tin bị lặp lại. Trường dữ liệu Type có các thông tin về kiểu tài khoản bị lặp lại. Việc lặp lại thông tin này dẫn đến tốn ổ cứng lưu trữ và các vấn đề khác. Cập nhật bất thường (Update abnomalies): Dư thừa dữ liệu không chỉ dẫn đến phí phạm trong lưu trữ mà còn làm cho việc cập nhật dữ liệu khó khăn hơn. Trong trường hợp ta phải cập nhật tài khoản tiền gửi sang Savings Account thay vì Savings, ta sẽ phải cập nhật tất cả các bản ghi có giá trị này. Nếu vì một lý do nào đó một số bản ghi không được cập nhật, chúng ta sẽ có một CSDL chứa hai loại tài khoản tiền gửi (Một là Savings và Savings Account). Vấn đề này gọi là cập nhật bất thường. Thêm mới bất thường (Insertion Anomalies) (Không thể thể hiện dữ liệu): Giả sử khóa chính của bảng trên là (Accno, TransactionNo). Bất kỳ bản ghi mới nào được thêm vào bảng đều phải có giá trị cho khóa chính do có tồn tại ràng buộc toàn vẹn đòi hỏi cả khóa chính hay một phần của khóa chính không được chứa giá trị NULL. Tuy nhiên ta không thể thêm mới dữ liệu chi tiết của tài khoản trước khi các giao dịch được thực hiên mà phải đến khi một giao dịch của tài khoản đó được thực hiện. Vấn đề này được gọi là thêm mới bất thường.

Thiết kế CSDL

15

Xóa dữ liệu bất thường (Deletion Anomalies) (Mất các thông tin hữu ích): Trong một số trường hợp, các thông tin hữu ích có thể bị mất nếu một bản ghi bị xóa. Ví dụ, nếu ta xóa bản ghi có số tài khoản (AccNo) là 86005, ta có thể mất các thông tin liên quan đến loại tài khoản đó (là tài khoản chi tiêu - current account). Vấn đề này được gọi là xóa dữ liệu bất thường. Vấn đề trên xảy ra chủ yếu do bảng này chứa cả các thông tin về Accounts, Account Types và Transactions. Giải pháp đưa ra là chia nhỏ bảng thành 2 hay nhiều bảng chi tiết. Việc chia nhỏ này có thể mang lại nhiều lợi ích, ví dụ, trong một CSDL phân tán các bảng có thể được lưu trữ ở nhiều nơi khác nhau nếu cần thiết. Tất nhiên, việc chia nhỏ này sẽ dẫn đến truy vấn phải xử lý nhiều hơn do các bảng được chia nhỏ sẽ phải liên kết với nhau và đôi khi là rất thường xuyên. Bảng dữ liệu trên có thể dễ dàng được chia nhỏ thành 3 bảng để loại bỏ hầu hết những thuộc tính không cần thiết: Ta có thể tạo bảng AccountType chứa mã và mô tả của các loại tài khoản. Lúc đó dữ liệu trong bảng chỉ cần được cập nhật ở một nơi (trong bảng AccountType). AccNo Customer name 85001 Smith 85002 James 85003 Ritcha 86005 Jones

Address OpenedOn TypeCode 1, Main 2, Main 3, Main 12, 7th

1/4/03 3/4/03 4/4/03 5/4/03

1 1 1 2

Transaction No 1 2 3 4

Transaction Amount 1000 200 100 400

Transaction Date 2/4/03 4/4/03 5/4/03 6/4/03

Bảng 1.4: Bảng Account Account(Accno, Customername, Address, OpenedOn, TypeCode) AccountType(TypeCode, TypeDesc) Transaction(Accno, TransactionNo, TransactionAmount, TransactionDate) Việc chia nhỏ như vậy được gọi là chuẩn hóa và rất cần thiết nếu ta muốn loại bỏ các bất thường không mong đợi trong thao tác dữ liệu. Như đã đề cập ở trên, chuẩn hóa cũng thường có những tác động ngược ảnh hưởng đến tốc độ. Những dữ liệu mà trước khi chuẩn hóachỉ cần được truy xuất từ một bảng nay phải được truy xuất từ nhiều bảng có liên kết với nhau sau khi chuẩn hóa. Tuy nhiên chuẩn hóa thường giúp cập nhật dữ liệu hiệu quả hơn, việc này trước khi chuẩn hóa cần phải cập nhật nhiều bản ghi, sau khi chuẩn hóa ta chỉ cần cập nhật một bản ghi. Mặc dù trong trường hợp trên ta có thể xem bảng gốc và đưa ra một phương pháp phân chia dữ liệu phù hợp để loại bỏ các bất thường, nhưng nói chung cách tiếp cận như vậy là không thể. Một bảng có thể chứa hàng trăm các thuộc tính và như vậy rất khó có thể khái niệm hóa tất cả các thông tin và đưa ra phương án chia nhỏ phù hợp để xử lý các vấn đề về dữ liệu. Do đó ta cần có một cách tiếp cận số học để tìm ra các vấn đề nảy sinh trong khi thiết kế CSDL và cách loại bỏ chúng. Mục đích chính của chuẩn hóa là tránh một số bất thường về cập nhật dữ liệu mà ta đã bàn ở trên.

16

Thiết kế CSDL và làm việc với CSDL SQL Server

Dạng chuẩn 1 (1NF) Bảng dữ liệu thỏa mãn các đặc tính của một quan hệ (relation) được coi là ở dạng chuẩn 1. Một relation không thể chứa các thuộc tính tập hợp hay có nhiều giá trị. Dưới đây là quy tắc của dạng chuẩn 1. Một quan hệ được coi là ở dạng chuẩn 1 khi và chỉ khi các miền giá trị của quan hệ chứa các giá trị đơn nhất. Dạng chuẩn 1 chỉ quan tâm đến cấu trúc cơ bản của bảng mà không giải quyến vấn đề dư thừa dữ liệu hay các bất thường khi thao tác dữ liệu đã bàn ở trên. Ba bảng Account, AccountType và Transaction đã ở dạng chuẩn 1. Dạng chuẩn 2 (2NF) Điều kiện để đạt được dạng chuẩn 2 là bảng dữ liệu phải ở dạng chuẩn 1. Mục đích của dạng chuẩn 2 là đảm bảo rằng thông tin chứa trong quan hệ chỉ mô tả một thực thể duy nhất. Một quan hệ ở dạng chuẩn 2 khi và chỉ khi nó ở dạng chuẩn 1 và tất cả các trường không phải khóa chính phải phụ thuộc hoàn toàn vào khóa chính của quan hệ Để hiểu rõ hơn định nghĩa dạng chuẩn 2 ở trên ta cần định nghĩa khái niệm key attribute. Mỗi thuộc tính của quan hệ tham gia vào ít nhất một khóa ứng viên (candidate key) được coi là key attribute của quan hệ. Tất cả các thuộc tính khác được gọi là non-key. Dạng chuẩn 2 quy định rằng tất cả các thuộc tính không phải thành phần của khóa ứng viên phải phụ thuộc hoàn toàn vào khóa ứng viên. Chúng ta xem xét ví dụ về các bảng sau: Account(AccountNo, Customername, Address, OpenedOn, TypeCode) Một khách hàng có thể có nhiều tài khoản. Trong trường hợp nàytrường CustomerName không phụ thuộc vào AccountNo. Cũng vậy trường Address của một khách hàng phụ thuộc vào tên của khách hàng chứ không phụ thuộc vào trường khóa chính AccountNo. Tuy nhiên các thuộc tính OpenedOn và TypeCode phụ thuộc vào khóa chính. Do vậy bảng này có thể được chia nhỏ hơn thành Customer và Account. Account(AccountNo, CustomerCode, OpenedOn, TypeCode) Customer (CustomerCode, Customername, Address) Các bảng đó như sau:

AccountType(TypeCode, TypeDesc) Transaction(Accno, TransactionNo, TransactionAmount, TransactionDate) Bảng trên đã ở dạng chuẩn 2 (2NF) do bảng không có các thuộc tính không phải khóa. Các bước chuẩn hóa cao hơn cần thực hiện để giải quyết những vấn đề khác liên quan đến bảng ở dạng chuẩn 2 (2NF) và các dạng chuẩn tiếp theo sẽ dẫn đến việc chia nhỏ các bảng như vậy. Dạng chuẩn 3 (3NF)

Thiết kế CSDL

17

Mặc dù dạng chuẩn 2 đã loại bỏ được các bất thường có thể xuất hiện trong các bảng chưa ở dạng chuẩn 1, nhưng không phải đã loại bỏ được tất cả và cần thiết phải thực hiện dạng chuẩn hóa tiếp theo để đảm bảo loại bỏ hết những bất thường đó. Các tính bất thường này có thể xảy ra do dạng chuẩn 2 có thể chứa những thuộc tính không liên quan trực tiếp đến thực thể được mô tả bởi các khóa ứng viên trong quan hệ. Dạng chuẩn 3 được mô tả dưới đây: Một bảng R ở dạng chuẩn 3 khi và chỉ khi nó ở dạng chuẩn 2 và các thuộc tính không phải khóa không phụ thuộc ngoại suy vào các trường khóa ứng viên của R Để hiểu rõ hơn về dạng chuẩn 3 chúng ta tìm hiểu khái niệm sự phụ thuộc ngoại suy (transitive dependence), khái niệm này dựa vào một trong những tiên đề của Armstrong. Coi A, B và C là ba thuộc tính của quan hệ R, ta có các mối quan hệ sau AB và BC. Từ các mối quan hệ này ta suy ra là AC. Như đã đề cập ở trên, mối quan hệ giữa AC là phụ thuộc ngoại suy (transitive). Dạng chuẩn 3 khác với dạng chuẩn 2 ở chỗ tất cả các thuộc tính không phải khóa chính trong dạng chuẩn 3 phải phụ thuộc trực tiếp vào khóa ứng viên của mỗi quan hệ. Nếu có thuộc tính phụ thuộc vào trường khóa theo quan hệ ngoại suy điều đó có ý nghĩa là các thuộc tính đó mô tả không chỉ trường khóa mà còn mô tả thuộc tính không phải khóa. Do đó thông tin không phụ thuộc trực tiếp vào khóa chính mặc dù rõ ràng thuộc tính này có quan hệ với khóa chính. Chúng ta xem bảng Account. Mỗi thuộc tính trong bảng này phụ thuộc hoàn toàn vào khóa chính và đều mô tả một account. Do vậy bảng này đã ở dạng chuẩn 3 (3NF). Có tồn tại dạng chuẩn 4 và 5 nhưng rất ít được sử dụng khi thiết kế CSDL. Bỏ qua các quy tắc này có thể dẫn đến một CSDL chưa hoàn hảo nhưng không ảnh hưởng đến tính năng của CSDL. Đưa sơ đồ E-R về dạng bảng Một CSDL được mô tả bằng sơ đồ quan hệ thực thể có thể được thể hiện bởi một tập hợp các bảng. Với mỗi htập thực thể và tập quan hệ ta có một bảng duy nhất được gán tên của tập tương ứng. Mỗi bảng có một số trường (thuộc tính) với tên duy nhất.

18

Thiết kế CSDL và làm việc với CSDL SQL Server

Tóm tắt  Để phân tích được dữ liệu ta cần có CSDL tốt. Muốn vậy ta cần thiết kế CSDL một cách hiệu quả.  Thiết kế CSDL là định nghĩa cấu trúc của các đối tượng dữ liệu và các mối quan hệ giữa các đối tượng dữ liệu đó trong CSDL.  Các mô hình là những hình ảnh đơn giản hóa của các sự kiện hay điều kiện thực  Các mô hình có thể được sử dụng để đơn giản hóa việc thiết kế CSDL; các mô hình tốt giúp thiết kế CSDL tốt và do đó giúp phát triển các ứng dụng tôt.  Khi thiết kế một CSDL bất kể độ lớn và độ phức tập, ta nên theo các bước cơ bản sau: • Thu thập thông tin • Xác định các đối tượng • Thiết kế mô hình • Xác định loại thông tin cho từng đối tượng. • Xác định mối quan hệ giữa các đối tượng.  Các giai đoạn thiết kế CSDL • Phân tích yêu cầu • Thiết kế khái niệm (Conceptual Design) • Mô hình hóa dữ liệu • Thiết kế vật lý (Physical design)

 A data model diagram shows the relationships among database tables (entities). They can be classified as • • •

Conceptual Data modeling Logical data modeling Physical database build

 Thiết kế CSDL logic là quá trình xây dựng mô hình các thông tin được sử dụng trong doanh nghiệp dựa trên một mô hình dữ liệu cụ thể, nhưng độc lập với bất kỳ CSDL nào hay với các quan tâm về vật lý.  Sơ đồ E-R là một công cụ thân thiện và hiệu quả trong việc mô hình hóa dữ liệu. Mô hình này thể hiện thế giới thực bằng các đối tượng cơ bản và các quan hệ giữa những đối tượng này.

 Quá trình loại bỏ các dữ liệu dư thừa từ các bảng của CSDL quan hệ được gọi là chuẩn hóa.. Nếu được sử dụng hợp lý, chuẩn hóa sẽ là cách tốt nhất và dễ dàng nhất để tổ chức các bảng dữ liệu trong CSDL quan hệ. Khi chúng ta đưa dữ liệu về dạng chuẩn hóa, ta đã: • Đưa cấu trúc dữ liệu về dạng đơn giản nhất • Loại bỏ các trường dữ liệu dư thừa từ các bảng • Xác định các dữ liệu phụ thuộc nhau

Thiết kế CSDL

19

Bài kiểm tra 1. Mô hình tập trung vào bản chất logic của dữ liệu được gọi là a. Mô hình khái niệm (Conceptual Model) b. Mô hình logic (Logical model) c. Mô hình ảo (Virtual Model) d. Mô hình thực thi (Implementation Model) 2. Mô hình tập trung vào thể hiện dữ liệu được gọi là a. Mô hình khái niệm (Conceptual Model) b. Mô hình logic (Logical model) c. Mô hình ảo (Virtual Model) d. Mô hình thực thi (Implementation Model) 3. Sơ đồ chỉ ra mối quan hệ giữa các thực thể trong CSDL được gọi là ___________. a. Sơ đồ quan hệ thực thể (Entity Relationship diagram) b. Sơ đồ mô hình hóa dữ liệu (Data Model diagram) c. Sơ đồ phân loại thực thể (Entity Classification diagram) d. Không có loại nào 4. Một thực thể là một đối tượng tồn tại và có thể phân biệt được với các thực thể khác. a. Đúng b. Sai 5. Những quan hệ nào sau đây là những quan hệ ràng buộc hợp lệ? a. Một – một (One to One) b. Nhiều – nhiều (May to Many) c. Nhiều – một (Many to One) d. Tất cả các quan hệ trên

20

Thiết kế CSDL và làm việc với CSDL SQL Server

Thử sức 1. Hãy chỉ ra các bước cơ bản trong thiết kế CSDL.

2. Hãy giải thích ràng buộc số lượng trong quan hệ giữa hai tập thực thể X và Y.

Thiết kế CSDL

21