Widzę kilka powodów, dla których potrzebujesz do tego dwóch tabel:
- prawdziwi pracownicy muszą mieć nazwisko, dział itp., podczas gdy tylko pracownicy prognozujący mogą mieć te atrybuty
- Będą obowiązki, które mogą mieć tylko prawdziwi pracownicy, więc chcesz mieć możliwość oddzielnego odniesienia się do nich
Ale jednocześnie chcesz się upewnić, że nie ma kolizji identyfikatorów w dwóch tabelach, ponieważ (miejmy nadzieję) prognozowani pracownicy staną się rzeczywistymi pracownikami.
Sposobem na to jest zaimplementowanie struktury supertypu/podtypu. Masz więc jedną tabelę PRACOWNICY, która gwarantuje pojedyncze klucze podstawowe i dwie tabele zależne dla rzeczywistych i prognozowanych pracowników. Użycie kolumny typu jest kluczowe, ponieważ zapewnia, że dany pracownik pojawia się tylko w jednej podtabeli.
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 ;
Więc klawisze mogą wyglądać trochę dziwnie. Tabela nadrzędna ma zarówno klucz podstawowy, jak i unikalny klucz złożony. Klucz podstawowy gwarantuje pojedyncze wystąpienie EMP_ID. Unikalny klucz pozwala nam budować klucze obce w tabelach podrzędnych, które odwołują się zarówno do EMP_ID, jak i EMP_TYPE. W połączeniu z ograniczeniami sprawdzającymi w potomnym t Dzieje się tak, ponieważ odwołują się one do unikatowego klucza w tabeli nadrzędnej, a nie do jej klucza podstawowego. w stanie to rozwiązanie zapewnia, że pracownik może być w FORECAST_EMPLOYEES lub ACTUAL_EMPLOYEES, ale nie w obu.
Klucze obce są odroczone, aby umożliwić konwersję pracowników prognozowanych na rzeczywistych pracowników. Wymaga to trzech czynności:
- usunięcie wpisu z FORECAST_EMPLOYEES
- wstawianie wpisu do ACTUAL_EMPLOYEES
- zmiana EMP_TYPE (ale nie EMP_ID) w PRACOWNIKACH.
Synchronizacja działań 2 i 3 jest łatwiejsza dzięki odroczonym ograniczeniom.
Należy również zauważyć, że inne ograniczenia klucza obcego odnoszące się do PRACOWNIKÓW powinny używać klucza podstawowego, a nie klucza unikalnego. Jeśli związek dba o typ pracownika, prawdopodobnie powinien zamiast tego połączyć się z tabelami podrzędnymi.
Witamy w świecie modelowania danych. To jeden wielki ból głowy. Ponieważ próba dopasowania nieporządnej rzeczywistości do czystego modelu danych jest trudna :potrzebujesz jasnych wymagań, aby zrobić to dobrze, i zrozumienia tego, co jest najważniejsze, aby móc iść na rozsądne kompromisy.
Zaproponowałem podejście supertypu/podtypu na podstawie twojego drugiego pytania i ponieważ wydaje się, że jest to najlepszy sposób obsługi dwóch zestawów danych:rzeczywistych pracowników i pracowników hipotetycznych. Myślę, że te dwie grupy należy traktować inaczej. Na przykład nalegałbym, aby menedżerowie byli prawdziwymi pracownikami. Jest to łatwe do osiągnięcia dzięki ograniczeniu integralności wobec ACTUAL_EMPLOYEES i znacznie trudniejsze do osiągnięcia przy jednej tabeli zawierającej oba typy pracowników.
Oczywiście posiadanie dwóch tabel oznacza, że prawdopodobnie generuje więcej pracy w odniesieniu do synchronizacji ich struktur. Więc co? Jest to w dużej mierze trywialne, ponieważ napisanie dwóch instrukcji ALTER TABLE jest niewiele więcej pracy niż jednej. Dodatkowo całkiem możliwe, że nowa kolumna dotyczy tylko rzeczywistych pracowników i nie ma żadnego znaczenia dla prognozowanych pracowników (np. EARNED_COMMISSION, LAST_REVIEW_RATING). W tym świetle posiadanie oddzielnych tabel sprawia, że model danych jest dokładniejszy.
W odniesieniu do konieczności duplikowania tabel zależnych, jak wskazuje Ollie, jest to nieporozumienie. Tabele, które dotyczą wszystkich pracowników bez względu na ich aktualność, powinny odnosić się do tabeli PRACOWNICY, a nie jej elementów podrzędnych.
Wreszcie nie rozumiem, dlaczego utrzymanie danych historycznych jest trudniejsze przy dwóch tabelach niż przy jednej. Większość kodu księgowania powinna być w całości generowana ze słownika danych.
Są trzy stoły:
- PRACOWNICY – główna tabela gwarantująca unikalne identyfikatory EMP_ID
- ACTUAL_EMPLOYEES – stolik podrzędny dla osób pracujących w Twojej firmie
- FORECAST_EMPLOYEES - stolik dziecięcy dla osób, które masz nadzieję zrekrutować do swojej firmy
Proszę pamiętać, że przyjmuję założenia dotyczące Twojej logiki biznesowej na podstawie skąpych danych, które podałeś.
Teraz wydaje mi się, że osoby, które jeszcze nie pracują w Twojej firmie, nie powinny mieć żadnych powiązanych działań. W tym scenariuszu miałbyś jedną tabelę, EMPLOYEE_ACTIVITIES, która jest dzieckiem ACTUAL_EMPLOYEES.
Ale być może naprawdę prowadzisz zajęcia dla ludzi, którzy nie istnieją. Mamy więc wybór:jeden stolik czy dwa? Projekt jednej tabeli ma EMPLOYEE_TASKS jako element podrzędny głównej tabeli EMPLOYEES. Projekt dwóch tabel ma ACTUAL_EMPLOYEE_TASKS i FORECAST_EMPLOYEE_TASKS jako elementy podrzędne odpowiednio tabel ACTUAL_EMPLOYEES i FORECAST_EMPLOYEES.
To, który projekt jest poprawny, zależy od tego, czy musisz wymusić zasady przydziału zadań. Na przykład Twoja firma może mieć regułę, która mówi, że tylko prawdziwi ludzie mogą zatrudniać nowych pracowników. Przydałby się więc model, w którym zadania rekrutacyjne można przypisywać tylko do ACTUAL_EMPLOYEES.
Dobra, dodałem kolumny dat do dwóch tabel. To pozwoli Ci uruchomić żądany raport.
