Можно ли добавить первичный ключ сломанной таблице

Question

У меня есть эти таблицы:

Emp_Tutor: Tutor table. 
Emp_Tu_De :Tutor details table. 
Emp_Tu_St: Tutor status table. 
Emp_School: School table. 

Как мы знаем, школа имеет много наставников, и каждый учитель может быть, работает в одной школе или другой, может быть, два или три школ ,
Так Репетитор стол я играл как Сломанный стол между школой и репетитора деталей>

таблица состояния Tutor мы создаем его, чтобы вставить статус преподавателя Репетитор как (курсы, занятия, учебные часы, ЕКТС.)

Итак, мой вопрос:
Могу ли я добавить первичный ключ к таблице Tutor, чтобы установить связь между таблицей Tutor и таблицей состояния Tutor?
Не забывайте, что таблица репетитора нарушает отношения.
look at image attachment.

Answer 1

Я считаю, что пытаться хранить вещи, как статус обычно ошибка. Например, статус занятости «текущий», «бывший», «переиздание» обычно лучше реализуется как таблица занятости с датами начала и датами окончания.

Разбитые таблицы и неработающие отношения не являются нормальными английскими терминами в дизайне базы данных. Я не уверен, что вы имеете в виду здесь.

Последующий код PostgreSQL. SQL Server будет использовать тип данных datetime вместо стандартного типа данных timestamp SQL. Есть, вероятно, и другие небольшие отличия.

-- Nothing surprising here. 
create table schools (
    school_id integer primary key, 
    school_name varchar(20) not null unique 
    -- other columns go here 
); 

-- Nothing surprising here. 
create table tutors (
    tutor_id integer primary key, 
    tutor_name varchar(20) not null 
    -- other columns go here 
); 

-- Nothing surprising here. 
create table tutor_details (
    tutor_id integer primary key references tutors (tutor_id), 
    tutor_phone varchar(15) 
    -- other columns go here 
); 

-- Predicate: School <school_id> employed <tutor_id> 
-- starting on <start_date> and ending on <end_date>. 
-- Allows multiple periods of employment. 
create table school_tutors (
    school_id integer not null references schools (school_id), 
    tutor_id integer not null references tutors (tutor_id), 
    start_date date not null default current_date, 
    end_date date not null default '9999-12-31', 
    -- You can make a good, practical argument for including end_date 
    -- in the primary key, but that's a different issue. 
    primary key (school_id, tutor_id, start_date) 
); 


-- Only makes sense in the context of employment, so a composite 
-- foreign key references school_tutors. In production, I'd try 
-- to use more check constraints on the timestamps. 
create table tutor_office_hours (
    school_id integer not null, 
    tutor_id integer not null, 
    start_date date not null, 
    foreign key (school_id, tutor_id, start_date) 
    references school_tutors (school_id, tutor_id, start_date), 
    office_hours_start_time timestamp not null, 
    office_hours_end_time timestamp not null 
    check (office_hours_end_time > office_hours_start_time), 
    primary key (school_id, tutor_id, office_hours_start_time) 
);