[BÀI REVIEW KIẾN THỨC]
Khi yêu cầu nghiệp vụ (business requirement) được mô ta lại bằng Logical design, thì nó đã gần gũi hơn về mặt kỹ thuật (kỹ sư có thể hiểu được). Tuy nhiên bản design này vẫn chưa được xem là final design của một Database. Bởi nhìn vào đó lập trình viên vẫn chưa xác định được một cách rõ ràng các relation hay cấu trúc của chúng. Đó là lý do mà ta cần thêm một bước design nữa để ánh xạ conceptual design về một dạng mô hình chi tiết hơn, gọi là logical design. Đây là bản vẽ cung cấp đầy đủ cấu trúc (schema) của các relation trong một cơ sở dữ liệu. Output này còn được gọi là Relational Database Schema.
Quá trình này gồm 7 bước (nhiều nguồn tài liệu có thể chia số bước khác nhau, tuy nhiên phương pháp là giống nhau). Xem ví dụ bên dưới để nắm được chi tiết
Xem xet ERD trong hình 1:
Hình 1: Conceptual Design cho hệ thống quản lý hoạt động doanh nghiệp
Bước 1: Với mỗi entity type bình thường (bỏ qua các subclasses / weak entities) tạo một relation tương ứng.
EMPLOYEE (FNAME, MINT, LNAME, SSN, BDATE, ADDRESS, SEX, SALARAY)
DEPARTMENT (DNAME, DNUMBER)
PROJECT (PNAME, PNUMBER, PLOCATION)
Bước 2: Với mỗi ID-dependent entity tạo một relation tương ứng. Relation này có khóa chính bao gồm khóa chính của relation cha và một thuộc tính của chính nó.
DEPENDENT (ESSN, DEPENDENT_NAME, SEX, BDATE), trong đó ESSN là Foreign Key tham chiếu tới EMPLOYEE (SSN)
Các bảng khác:
EMPLOYEE (FNAME, MINT, LNAME, SSN, BDATE, ADDRESS, SEX, SALARAY)
DEPARTMENT (DNAME, DNUMBER)
PROJECT (PNAME, PNUMBER, PLOCATION
Bước 3: Bước này xử lý cho các supertype và subtype nên tạm thời các relation sẽ không thay đổi gì (Do ví dụ trên không có supertype và subtype) .
Bước 4: Đối với mỗi quan hệ Unary hoặc Binary có kiểu 1-1. Tạo một Foreign key từ một entity và tham chiếu sang entity còn lại.
DEPARTMENT (DNAME, DNUMBER, MgrSSN). MgrSSN là Foreign key tham chiếu tới EMPLOYEE (SSN)
Các bảng khác:
PROJECT (PNAME, PNUMBER, PLOCATION)
EMPLOYEE (FNAME, MINT, LNAME, SSN, BDATE, ADDRESS, SEX, SALARAY)
DEPENDENT (ESSN, DEPENDENT_NAME, SEX, BDATE)
Một số chú ý với bước này:- Khi đặt khóa ngoại nhớ chú ý tới cardinality constraint: partial và mandatory, thông thường khóa ngoại sẽ được đặt ở phía mandatory.
- Có thể đặt thêm các thuộc tính phát sinh liên quan: ví dụ ngày mà manager nhậm chức: DEPARTMENT (DNAME, DNUMBER, MgrSSN, StartDate) .
- Nếu Business Requirement yêu cầu lưu trữ cả History data (dữ liệu lịch sử) thì có thể tạo ra thêm một relation để giải quyết vấn đề này
DEPARTMENT (DNAME, DNUMBER)
EMPLOYEE (FNAME, MINT, LNAME, SSN, BDATE, ADDRESS, SEX, SALARAY)
DEPARTMENT_MANAGER (DNUMBER, SSN, StartDate, EndDate). Trong đó DNUMBER tham chiếu tới DEPARTMENT(DNUMBER) và SSN tham chiếu tới EMPLOYEE(SSN)
Bước 5: Với mỗi quan hệ 1-n, đặt khóa ngoại vào relation phía n tham chiếu khóa chính của relation phía 1
EMPLOYEE (FNAME, MINT, LNAME, SSN, BDATE,. ADDRESS, SEX, SALARAY, DNO, SUPERSSN). Trong đó, DNO là Khóa ngoại tham chiếu tới Department và SUPERSSN là khóa ngoại nhưng tự tham chiếu tới chính khóa chính (self reference cho quan hệ SUPERVISION, một UNARY Relationship).
DEPARTMENT (DNAME, DNUMBER, MGRSSN)
PROJECT (PNAME, PNUMBER, PLOCATION, DNO) Trong đó, DNO là Khóa ngoại tham chiếu tới Department
DEPENDENT (ESSN, DEPENDENT_NAME, SEX, BDATE), Foreign key ESSN đã được triển khai từ bước 2 nên ở đây không cần phải thực hiện lại nữa.
Bước 6: Với mỗi quan hệ N-M tạo ra một relation mới, khóa chính của relation này bao gồm các khóa ngoại tham chiếu tới các relation tham gia vào quan hệ, nó cũng chứa luôn cả các attribute của quan hệ như là attribute của chính nó.
WORKS_ON (ESSN, PNO, HOURS). Trong đó ESSN là Foreign Key tham chiếu tới Employee và PNO cũng tham chiếu tới Project. Cả 2 attribute này hợp thành một Primary Key. Hours là attribute của WORK_ON relationship trong ERD.
Các bảng khác
EMPLOYEE (FNAME, MINT, LNAME, SSN, BDATE, ADDRESS, SEX,. SALARAY, DNO, SUPERSSN)
DEPARTMENT (DNAME, DNUMBER, MGRSSN, MGRSTARTDATE)
PROJECT (PNAME, PNUMBER, PLOCATION, DNO)
DEPENDENT (ESSN, DEPENDENT_NAME, SEX, BDATE)
Bước 7 : Tương ứng với mỗi multi-valued attribute, ta sẽ tạo một relation mới. Primary Key của relation này bao gồm primary key của bảng gốc và value attribute
Trong ví dụ này thuộc tính location của entity Department là multi-valued. Do đó ta sẽ tạo ra relation Dept_Location như bên dưới
Do ví dụ ở phần trước không bao gồm supertype và subtype nên chúng ta sẽ xem xét chi tiết bước 3 ở phần này.
Có nhiều cách triển khai việc mapping cho các cấu trúc cha con tùy vào từng trường hợp để có thể đưa ra giải pháp tốt.
Ta sẽ có giải pháp như sau: EMPLOYEE (SSN, FNAME, MINT, LNAME, ...) ; MANAGER (SSN, MGMT_START_DATE) Trong đó MANAGER (SSN) là FK tham chiếu tới EMPLOYEE(SSN)
Trường hợp 2: có nhiều sub classes
Dựa vào các Business Rules (các ràng buộc nghiệp vụ) có 4 trường hợp có thể xảy ra.
Disjoint Optional
Disjoint Mandatory
Overlapping Optional
Overlapping Mandatory
Và do đó cũng có một loạt các phương án được xem xét:
* Phương pháp 2.1:
Nếu ta có:
Với mỗi entity type ta sẽ tạo 1 relation tương ứng. Các PK của các sub entity cũng đồng thời là FK tham chiếu tới PK của super class relation
EMPLOYEE (SSN, FNAME, MINT, LNAME, ...)
SECRETARY (SSN, TYPINGSPEED)
TECHNICIAN (SSN, TGRADE)
ENGINEER (SSN, ENGTYPE)
Khi làm theo phương pháp này các ràng buộc [total or partial, disjoint or overlapping] đều có thể được giải quyết.
* Phương pháp 2.2:
Với mỗi sub entity ta sẽ tạo một relation, relation này có Key giống với super entity và bao gồm tất cả các attribute của super type cùng với các attribute riêng của nó
SALARIED_EMPLOYEE (SSN, SALARY,...)
HOURLY_EMPLOYEE (SSN, PAYSCALE,...)
Phương pháp này chỉ áp dụng được cho [total , disjoin]
* Phương pháp 2.3:
Chỉ tạo một relation , nhưng có attribute type tương ứng cho mỗi subtype:
EMPLOYEE (SSN, FNAME, MINT, LNAME, …,. JobType_Participation_Occ,. TYPINGSPEED, TGRADE, ENGTYPE)
Phương pháp này có thể thỏa mãn nhiều Business Rules nhưng như vậy cơ sở dữ liệu sẽ phải lưu trữ rất nhiều giá trị NULL. Thông thường nó không được khuyến khích sử dụng.
* Phương pháp 2.4:
Chỉ tạo một relation biểu diễn cho cả supertype và subtype. Sử dụng các biến cờ (true/false) để biểu diễn cho từng loại subtype.
PART (PartNo, Description, MFlag, DrawingNo, ManufactureDate, BatchNo, PFlag, SupplierName, ListPrice) . Trong đó: MFlag và PFlag là 2 Binary Attribute đại diện cho từng subtype. Nhận giá trị True có nghĩa là tuple biểu diễn cho một sub entity instance tương ứng.
Phương pháp này có thể thỏa mãn nhiều điều kiện.
Bài viết bởi : sonnt5@fpt.edu.vn