Tôi có thể thấy một số lý do bạn cần hai bảng cho việc này:
- nhân viên thực sự phải có tên, phòng ban, v.v. trong khi chỉ những nhân viên dự báo mới có thể có những thuộc tính này
- sẽ có những trách nhiệm mà chỉ những nhân viên thực sự mới có thể có, vì vậy bạn muốn có thể đề cập đến họ một cách riêng biệt
Nhưng đồng thời, bạn muốn đảm bảo rằng không có xung đột về ID giữa hai bảng, vì bạn (hy vọng) dự báo nhân viên sẽ trở thành nhân viên thực tế.
Cách để làm điều này là triển khai cấu trúc kiểu siêu / kiểu con. Vì vậy, bạn có một bảng, NHÂN VIÊN đảm bảo các khóa chính duy nhất và hai bảng phụ thuộc cho nhân viên thực tế và dự báo. Việc sử dụng cột loại là rất quan trọng, vì nó đảm bảo rằng một nhân viên nhất định chỉ xuất hiện trong một bảng phụ.
create table employees
( emp_id number not null
, emp_type varchar2(8) not null
, constraint emp_pk primary key (emp_id)
, constraint emp_uk unique (emp_id, emp_type)
, constraint emp_type_ck check (emp_type in ('FORECAST', 'ACTUAL'));
create table actual_employees
( emp_id number not null
, emp_type varchar2(8) not null
, name varchar2(30) not null
, deptno number(2,0) not null
, sal number(7,2) not null
, hiredate date not null
, constraint actemp_pk primary key (emp_id)
, constraint actemp_type_ck check (emp_type = 'ACTUAL')
, constraint actemp_emp_fk foreign key (emp_id, emp_type)
references emp (emp_id, emp_type)
deferrable initially deferred ;
create table forecast_employees
( emp_id number not null
, emp_type varchar2(8) not null
, name varchar2(30)
, deptno number(2,0)
, sal number(7,2)
, predicted_joining_date date
, constraint foremp_pk primary key (emp_id)
, constraint foremp_type_ck check (emp_type = 'FORECAST')
, constraint foremp_emp_fk foreign key (emp_id, emp_type)
references emp (emp_id, emp_type)
deferrable initially deferred ;
Vì vậy, các phím có thể trông hơi kỳ quặc. Bảng cha có cả khóa chính và khóa duy nhất phức hợp. Khóa chính đảm bảo một phiên bản duy nhất của EMP_ID. Khóa duy nhất cho phép chúng tôi tạo khóa ngoại trên các bảng con tham chiếu đến cả EMP_ID và EMP_TYPE. Kết hợp với các đối chiếu kiểm tra trên con t Điều này là do chúng tham chiếu đến khóa duy nhất trên bảng cha chứ không phải khóa chính của nó. Theo thỏa thuận này đảm bảo rằng một nhân viên có thể ở FORECAST_EMPLOYEES hoặc ACTUAL_EMPLOYEES nhưng không phải cả hai.
Các khóa ngoại có thể hoãn lại để cho phép chuyển đổi nhân viên dự báo thành công nhân thực tế. Điều này đòi hỏi ba hoạt động:
- xóa bản ghi khỏi FORECAST_EMPLOYEES
- chèn một bản ghi vào ACTUAL_EMPLOYEES
- thay đổi EMP_TYPE (nhưng không EMP_ID) trong EMPLOYEES.
Đồng bộ hóa các hành động 2 và 3 dễ dàng hơn với các ràng buộc hoãn lại.
Ngoài ra, lưu ý rằng các ràng buộc khóa ngoại khác tham chiếu đến NHÂN VIÊN nên sử dụng khóa chính thay vì khóa duy nhất. Nếu mối quan hệ quan tâm đến loại nhân viên hơn nó có thể nên liên kết với các bảng con.
Chào mừng bạn đến với thế giới mô hình hóa dữ liệu. Đó là một cơn đau đầu lớn. Bởi vì cố gắng đưa thực tế lộn xộn vào một mô hình dữ liệu sạch sẽ là điều khó :bạn cần có các yêu cầu rõ ràng để thực hiện đúng và hiểu rõ điều gì quan trọng nhất để bạn có thể đưa ra các thỏa hiệp hợp lý.
Tôi đã đề xuất một cách tiếp cận siêu kiểu / kiểu phụ dựa trên câu hỏi khác của bạn và bởi vì nó có vẻ là cách tốt nhất để xử lý hai bộ dữ liệu:nhân viên thực sự và nhân viên danh nghĩa. Tôi nghĩ hai nhóm đó cần được đối xử khác nhau. Ví dụ, tôi muốn các nhà quản lý phải là những nhân viên thực thụ. Điều này dễ thực hiện với ràng buộc toàn vẹn đối với ACTUAL_EMPLOYEES và khó đạt được hơn với một bảng duy nhất chứa cả hai loại nhân viên.
Chắc chắn có hai bảng có nghĩa là có thể tạo ra nhiều công việc hơn liên quan đến việc đồng bộ hóa cấu trúc của chúng. Vậy thì sao? Nó phần lớn là nhỏ, vì nó hầu như không nhiều công việc để viết hai câu lệnh ALTER TABLE hơn một câu lệnh. Thêm vào đó, rất có thể cột mới chỉ áp dụng cho nhân viên thực tế và không có ý nghĩa gì đối với nhân viên dự báo (ví dụ:EARNED_COMMISSION, LAST_REVIEW_RATING). Do đó, việc có các bảng riêng biệt làm cho mô hình dữ liệu chính xác hơn.
Liên quan đến việc phải sao chép các bảng phụ thuộc, như Ollie đã chỉ ra, đó là một sự hiểu lầm. Các bảng áp dụng cho tất cả nhân viên bất kể thực tế của họ như thế nào, tham chiếu đến bảng NHÂN VIÊN không phải bảng con của nó.
Cuối cùng, tôi không hiểu tại sao việc duy trì dữ liệu lịch sử khó hơn với hai bảng so với một bảng. Hầu hết mã nhật ký phải được tạo hoàn toàn từ từ điển dữ liệu.
Có ba bảng:
- EMPLOYEES - một bảng chính để đảm bảo các EMP_ID duy nhất
- ACTUAL_EMPLOYEES - bảng con dành cho những người làm việc cho công ty của bạn
- FORECAST_EMPLOYEES - bảng con dành cho những người bạn hy vọng sẽ tuyển dụng vào công ty của mình
Xin lưu ý rằng tôi đang đưa ra các giả định về logic kinh doanh của bạn từ những chi tiết ít ỏi mà bạn đã cung cấp.
Bây giờ đối với tôi, dường như những người chưa làm việc cho công ty của bạn không nên có bất kỳ hoạt động liên quan nào. Trong trường hợp đó, bạn sẽ có một bảng, EMPLOYEE_ACTIVITIES, là bảng con của ACTUAL_EMPLOYEES.
Nhưng có lẽ bạn thực sự có những hoạt động dành cho những người không tồn tại. Vì vậy, đây là một sự lựa chọn:một hoặc hai bàn? Thiết kế một bảng có EMPLOYEE_TASKS là con của bảng EMPLOYEES chính. Hai thiết kế bảng có ACTUAL_EMPLOYEE_TASKS và FORECAST_EMPLOYEE_TASKS tương ứng là con của bảng ACTUAL_EMPLOYEES và FORECAST_EMPLOYEES.
Thiết kế nào là thiết kế chính xác phụ thuộc vào việc bạn có cần thực thi các quy tắc liên quan đến người được giao nhiệm vụ hay không. Ví dụ:công ty của bạn có thể có một quy tắc quy định rằng chỉ những người thực sự mới có thể thuê nhân viên mới. Vì vậy, sẽ rất hữu ích nếu có một mô hình chỉ cho phép các nhiệm vụ tuyển dụng được chỉ định cho ACTUAL_EMPLOYEES.
Được rồi, tôi đã thêm cột ngày vào hai bảng. Điều đó sẽ cho phép bạn chạy báo cáo bạn muốn.
