Bài giảng Cơ sở dữ liệu - Đặng Thị Từ Mỹ

Date chỉ phụ thuộc vào Order_Num Thuộc tính Product_Desc chỉ phụ thuộc vào Product_Num  Như vậy, quan hệ ORDER không phải ở dạng 2NF 3.5. Kết luận. Theo thủ tục chuyển thành 2NF, tiến hành như sau: Từ quan hệ ban đầu, với mỗi thuộc tính thuộc khoá chính tạo được các quan hệ tách biệt: (Order_Num, (Product_Num, Kết hợp tiếp theo của các thuộc tính trong khoá chính là hai thuộc tính Order_Num và Product_Num, vì vậy, có thêm quan hệ: (Order_Num, Product_Num, Đặt các thuộc tính còn lại trong quan hệ ban đầu ORDER vào các quan hệ mới tương ứng: ORDER(Order_Num, Order_Date) PRODUCT(Product_Num, Product_Desc) ORDER_LINE(Order_Num, Product_Num, Num_Ordered) Như vậy, thay vì một quan hệ ORDER ban đầu, đã nhận được ba quan hệ ở dạng 2NF 3.5. Kết luận. Bước 3: Tạo các ánh xạ của các quan hệ 2NF này để hạn chế mọi phụ thuộc hàm bắc cầu của các thuộc tính không khoá vào khoá chính. Kết quả sẽ tạo nên một tập các quan hệ 3NF. Từ quan hệ 2NF ban đầu, mang bản copy của thuộc tính quyết định cùng tất cả các thuộc tính không khoá mà phụ thuộc hàm vào thuộc tính quyết định này sang một quan hệ mới với thuộc tính quyết định sẽ được chỉ định làm khoá chính của quan hệ mới 3.5. Kết luận. Ví dụ, xét quan hệ CUSTOMER như sau: CUSTOMER (Customer_Num, Customer_Name, Address, Sales_Rep_Num, Sales_Rep_Name) Quan hệ này chưa ở dạng 3NF vì thuộc tính Sales_Rep_Name phụ thuộc hàm vào một thuộc tính là Sales_Rep_Num Theo thủ tục trên sẽ nhận được 2 quan hệ ở dạng 3NF: CUSTOMER(Customer_Num, Customer_Name, Address, Sales_Rep_Num) SALES_REP (Sales_Rep_Num, Sales_Rep_Name) 3.5. Kết luận. Lưu ý: Trường hợp quan hệ đã ở dạng 3NF nhưng có các khoá ứng cử phủ nhau thì chưa thể khẳng định là đã ở dạng chuẩn BCNF Nếu tồn tại thuộc tính quyết định mà không phải là khoá ứng cử thì phải mang bản copy của thuộc tính quyết định cùng các thuộc tính phụ thuộc hàm đầy đủ vào nó sang một quan hệ mới Mục đích chính của quá trình này là giảm được sự dư thừa thông tin, và do đó tránh được các vấn đề dị thường với các phép toán lưu trữ như đã bàn đến ở trên 3.5. Kết luận. 2. Kết luận Các khái niệm phụ thuộc dữ liệu trong chương này đã được xét cùng với ngữ nghĩa của dữ liệu Trong khi đó các ngôn ngữ con dữ liệu chỉ đụng chạm đến các giá trị dữ liệu tồn tại ở một thời điểm nào đó Đặc biệt, các ngôn ngữ đó không yêu cầu các quan hệ mà trên đó chúng sẽ thao tác phải ở dạng chuẩn nào ngoài dạng 1NF Mô hình CSDL ở dạng chuẩn 3NF/BCNF có thể xem như một quy định - một quy định cho người thiết kế hệ thống dữ liệu (người quản trị CSDL) để có thể xây dựng một mô hình dữ liệu phần nào phản ánh được đôi nét ngữ nghĩa của thế giới hiện thực phong phú 4. Thiết kế CSDL 4.1. Tám bước thiết kế một Cơ sở dữ liệu a. Phân tích toàn bộ các yêu cầu. b. Nhận diện các thực thể. c. Nhận diện các mối tương quan giữa các thực thể d. Xác định khoá chính (Primary Key - PK) e. Nhận diện khoá ngoại lai (Foreign Key - FK) f. Thêm các thuộc tính không phải khoá vào bảng dữ liệu g. Thực hiện chuẩn hoá các bảng dữ liệu h. Khai báo phạm vi của mỗi thuộc tính 4.2. Các quy tắc toàn vẹn dữ liệu trong mô hình quan hệ. a. Qui tắc Toàn vẹn thực thể (Entity Integrity Rule - EI) b. Qui tắc Toàn vẹn quy chiếu (Referential Integrity Rule - RI) 4.3. Ví dụ 4.1. Tám bước thiết kế một Cơ sở dữ liệu Bước 1: Phân tích toàn bộ các yêu cầu Phân tích trọn vẹn những yêu cầu cho việc hình thành một cơ sở dữ liệu của một đơn vị Trong giai đoạn này cần phải gặp gỡ để thảo luận với ban lãnh đạo cơ quan cũng như với người sử dụng cuối cùng để tìm hiểu các dữ kiện cần xử lý và quá trình xử lý các dữ kiện Người sử dụng cuối cùng (end user) là người sẽ sử dụng sản phẩm ta tạo ra Bước 2: Nhận diện các thực thể Sau khi đã thấu hiểu tiến trình xử lý, phải nhận diện những thực thể (entities) mà ta sẽ làm việc Mỗi thực thể được xem như một đối tượng xử lý rõ ràng, riêng biệt nhau Những thực thể này có thể được biểu diễn bởi những bảng dữ liệu trong CSDL Tạm thời phải bảo đảm mọi dữ kiện liên quan đến việc nhận dạng duy nhất một thực thể phải được nhận biết hết trong giai đoạn này 4.1. Tám bước thiết kế một Cơ sở dữ liệu Bước 3: Nhận diện các mối tương quan giữa các thực thể Sau khi nhận diện xong các thực thể, phải nhận diện tiếp những mối tương quan giữa các thực thể này Tóm lại, trong giai đoạn này, phải nhận diện kỹ tất cả các mối tương quan giữa các thực thể, và loại tương quan tương ứng Bước 4: Xác định khoá chính (Primary Key - PK) Lưu ý phải đảm bảo quy tắc toàn vẹn thực thể đối với khóa chính Nếu có hơn một khoá ứng cử, thì để chọn khóa chính: Phải chọn thuộc tính nào mang tính "có nhiều ý nghĩa nhất" đối với ứng dụng làm khóa chính Nên tránh sử dụng những thuộc tính có chuỗi ký tự quá dài làm khoá chính để tránh sai lầm và gây lúng túng. Thông thường nên sử dụng số thay vì chuỗi ký tự làm khoá chính 4.1. Tám bước thiết kế một Cơ sở dữ liệu Bước 5: Nhận diện khoá ngoại lai (Foreign Key - FK) Lưu ý phải đảm bảo quy tắc toàn vẹn quy chiếu đối với khóa ngoại lai Bước 6: Thêm các thuộc tính không phải khoá vào bảng dữ liệu. Sau khi đã khai báo định nghĩa các thực thể, các khoá chính và khoá ngoại lai, phải xác định những thuộc tính còn lại của mỗi bảng dữ liệu thuộc CSDL Trong bước này, phải quyết định việc chọn đặt tên cho các thuộc tính Nên tuân thủ theo một số quy ước đặt tên để giúp ta sau này trong việc viết tài liệu (documentation) và bảo trì hệ thống 4.1. Tám bước thiết kế một Cơ sở dữ liệu Ví dụ cách đặt tên thuộc tính: 4.1. Tám bước thiết kế một Cơ sở dữ liệu Bước 7: Tiếp theo và là bước quan trọng, đó là thực hiện chuẩn hoá các bảng dữ liệu Bước này không thêm thông tin gì ngoài những điều đã xác định ở trên. Sau khi tiến hành chuẩn hóa đến dạng chuẩn mong muốn, tiến hành vẽ sơ đồ thực thể liên kết giữa các quan hệ ở dạng chuẩn cuối cùng. Lưu ý: Bảng dữ liệu (quan hệ) nào mà không kết nối với các bảng dữ liệu khác, nghĩa là nằm tách riêng một mình thì Hoặc coi như không cần thiết đối với việc thiết kế và có thể loại khỏi CSDL mà không bị sợ thiếu sót. Hoặc cũng có thể quay trở lại những bước đi trước để kiểm tra lại xem có sai lầm ở đâu đó không Bước 8: Khai báo phạm vi của mỗi thuộc tính Trong giai đoạn cuối cùng này, đối với mỗi thuộc tính cần xác định một kiểu dữ liệu thích hợp cho nó, nghĩa là kiểu giá trị mà thuộc tính này sẽ chứa như: kiểu số, kiểu ký tự, kiểu ngày tháng, kiểu hình ảnh, kiểu âm thanh... Tiếp theo, cần xác định miền (range) mà các giá trị này dao động để từ đó biết kích thước của mỗi thuộc tính cũng như giá trị tối thiểu và tối đa của các thuộc tính kiểu số Cũng có thể xác định quy tắc kiểm tra hợp lệ ở đây nghĩa là xác định những thủ tục kiểm tra hợp lệ nào sẽ đưa vào trong ứng dụng 4.1. Tám bước thiết kế một Cơ sở dữ liệu Ví dụ: 4.2. Các quy tắc toàn vẹn dữ liệu: C.J. Date: Qui tắc Toàn vẹn thực thể (Entity Integrity Rule - EI): Không một thành phần nào của các thuộc tính dùng làm khoá chính trên một bảng dữ liệu được là null Qui tắc Toàn vẹn quy chiếu (Referential Integrity Rule - RI): Nếu một bảng dữ liệu bao gồm một khoá ngoại lai (FK) khớp với một khoá chính (PK) trên một bảng dữ liệu T nào đó, thì mỗi trị của FK phải hoặc: bằng trị của khoá chính trên một hàng nào đó của bảng dữ liệu T, hoặc hoàn toàn null (Điều này không nên có vì không kết nối vào đâu) Cần tuân thủ các quy tắc toàn vẹn dữ liệu này trong 3 phép toán thao tác CSDL 4.2. Các quy tắc toàn vẹn dữ liệu: Phép toán Chèn (Insert): Nếu người sử dụng cố thử đưa vào một bộ với khoá ngoại lai không khớp với trị của khoá chính của bảng dữ liệu tương ứng thì để đảm bảo các quy tắc toàn vẹn dữ liệu, ta có thể cho áp dụng một trong 3 nguyên tắc sau đây: Gạt bỏ việc thêm hàng này và yêu cầu người sử dụng đưa vào thông tin của khoá chính trên bảng dữ liệu tương ứng Nguyên tắc này được gọi là nguyên tắc phụ thuộc (DEPENDENT) Tự động chuyển người sử dụng qua một chương trình khác để cho phép người sử dụng thêm vào quan hệ tương ứng một hàng mới với khoá chính cần thiết Nguyên tắc này được gọi là nguyên tắc tự động (AUTOMATIC) Chấp nhận bộ mới với khoá ngoại lai là null, nếu đồng ý chấp nhận null đối với khoá ngoại lai Nguyên tắc này được gọi là nguyên tắc làm rỗng (NULLIFY) 4.2. Các quy tắc toàn vẹn dữ liệu: Phép toán Thay đổi (Update): Để xác định sẽ xử lý như thế nào khi người sử dụng cố tình thay đổi khoá chính có liên hệ với một khoá ngoại lai, có thể chọn một trong 3 hướng giải quyết sau đây: Tự động thay đổi giá trị của khoá ngoại lai cho khớp với giá trị mới của khoá chính Nguyên tắc này được gọi là nguyên tắc thác đổ hay dây chuyền (CASCADE) Chỉ cho phép thay đổi giá trị khoá chính ở hàng hiện không có giá trị của khoá chính khớp với giá trị hiện có của khoá ngoại lai tương ứng Nguyên tắc này được gọi là nguyên tắc hạn chế (RESTRICT) Cho khoá ngoại lai về null đối với các hàng có giá trị của khoá ngoại lai hiện khớp với giá trị của khoá chính cần thay đổi, nếu đồng ý chấp nhận null đối với khoá ngoại lai Đây là nguyên tắc làm rỗng (NULLIFY) 4.2. Các quy tắc toàn vẹn dữ liệu: Phép toán Xoá (Delete): Nếu người sử dụng cố tình xoá một hàng chứa giá trị của khoá chính mà ít nhất có một bảng dữ liệu hiện đang sử dụng giá trị này cho khoá ngoại lai thì quy tắc toàn vẹn dữ liệu có thể tăng cường bằng một trong ba nguyên tắc sau đây (cũng tương tự như với phép thay đổi ở trên): Tự động xoá tất cả các hàng trong tất cả các bảng dữ liệu có giá trị của khoá ngoại lai trùng với giá trị của khoá chính cần xoá Nguyên tắc này được gọi là nguyên tắc thác đổ hay dây chuyền (CASCADE) Chỉ cho phép xoá giá trị khoá chính ở hàng hiện không có giá trị của khoá chính khớp với giá trị hiện có của khoá ngoại lai tương ứng Nguyên tắc này được gọi là nguyên tắc hạn chế (RESTRICT) Cho khoá ngoại lai về null đối với các hàng có giá trị của khoá ngoại lai hiện khớp với giá trị của khoá chính cần xoá, nếu đồng ý chấp nhận null đối với khoá ngoại lai Đây là nguyên tắc làm rỗng (NULLIFY) 4.3. Ví dụ Xét bảng dữ liệu Hoá đơn: 4.3. Ví dụ Chuẩn hóa và đưa về dạng 1NF 4.3. Ví dụ Đưa về dạng 2NF 4.3. Ví dụ Đưa về dạng 3NF 1 n 1 n 1 n 4.3. Ví dụ Sơ đồ thực thể liên kết