Tabela „impreza” nie wygląda dobrze. Porównaj z kodem źródłowym z to inne pytanie SO .
W tego rodzaju strukturze numer identyfikacyjny partii rozchodzi się, że tak powiem, w dół. Zwykle powinien to być klucz podstawowy lub klucz obcy w tabelach przechowujących dane o osobie.
W Twojej tabeli „raportowanie” wygląda na to, że kluczem podstawowym nie powinno być „partyid”. To pozwoliłoby tylko na jeden wiersz na pracownika, co chyba nie było twoim zamiarem. (Mogę się mylić.) Jeśli mam rację, możesz rozważyć opcję NOT NULL UNIQUE ograniczenie na {partyid, date} i PRIMARY KEY ograniczenie nowej kolumny „reportid”. Tabele „podróże” i „wydajność” prawdopodobnie odwołują się do „raportid”. (Ale czytaj dalej.)
Na diagramie są miejsca, w których encja otrzymuje dodatkowy klucz:np. Twoja firma przypisuje swoim pracownikom unikalny numer identyfikacyjny pracownika. Nie ma żadnego teoretycznego powodu, dla którego od tego momentu nie można używać słowa „employid” zamiast „partyid” w odniesieniu do pracowników. Ale jest jest praktyczny powód, dla którego możesz tego nie chcieć. Zwiększa liczbę złączeń.
Na przykład, jeśli tabele „credential”, „tool”, „certification”, „academic” i „compliance” odwołują się do worker.employid zamiast worker.partyid, nie można po prostu dołączyć „compliance” i „party” do uzyskać imię osoby. Musisz też dołączyć do „pracownika”.
Muszą mieć klucz podstawowy; klucz podstawowy niekoniecznie musi być numerem identyfikacyjnym. Jeśli istnieje klucz naturalny, musisz go zidentyfikować i zadeklarować UNIKATOWY.
Tabela „orders” powinna prawdopodobnie mieć tylko „orderid” jako klucz podstawowy; użyj odniesienia do klucza obcego, aby zidentyfikować klienta. W niektórych przypadkach warto zmienić nazwy kolumn. W przypadku klientów sensowne może być nazwanie jego klucza „customerid” zamiast „parytid”. Sam utworzyłbym domenę.
create domain PARTY_ID as integer not null;
Wtedy wszędzie, gdzie potrzebny jest numer identyfikacyjny partii, zamiast tego używałbym domeny.
create table customers (
customerid PARTY_ID primary key references parties (partyid),
...
Ja też wolałbym zobaczyć tabelę menedżerów. Odniesienie do niego gwarantowałoby, że manager.managerid będzie dotyczył rzeczywistego kierownika, a nie tylko dowolnego pracownika.
