написания сценарий SQL база на концептуальной схеме

Question

У меня есть эти следующие требования

работодатель может войти в систему с именем пользователя и паролем и создать возможность работы. Заявитель МОЖЕТ войти в систему со своим именем пользователя и паролем, чтобы просмотреть возможность работы.

• employer имеет атрибуты employer_id,name,role
• applicant имеет атрибуты applicant_id,DOB,Name
• jobOpportunity имеет атрибуты JobId,Title,Description

Это диаграмма я придумал.

Преобразование диаграммы в SQL скрипт:

http://pastebin.com/wUnU5NMT

Я не совсем уверен, что я пишу сценарий и рисования диаграммы правильно, в соответствии с требованиями.

Answer 1

Прорезка на Вход таблице не выглядит правильно, т.е .:

CREATE TABLE Login(
     (employer_id,applicant_id) INT PRIMARY KEY NOT NULL, 
     -- Username + password OK 
     FOREIGN KEY(applicant_id) REFERENCES Applicant(applicant_id)); 
     FOREIGN KEY(employer_id) REFERENCES Employer(employer_id)); 

Поскольку Логин будет либо работодатель или соискатель, составной ключ на обоих из них не имеет никакого смысла.

Скорее создайте суррогатный ключ для входа (например, только LoginID INT) Похоже, что требование подталкивает вас к модели наследования между логином, работодателем и заявителем. Если вы сделаете это, внешние ключи будут переключены так, чтобы employer и applicant оба FK для входа в систему. LoginID. Вы можете либо создать новые суррогатные первичные ключи для работодателя и логина, либо использовать унаследованный ключ от имени входа в качестве первичного ключа для этих таблиц. (Т.е. столбец может быть как первичный ключ и внешний ключ одновременно.) Вот как бы я это сделать:

CREATE TABLE Login(
    (LoginID INT PRIMARY KEY NOT NULL, 
    username VARCHAR(45) NOT NULL, 
    password VARCHAR(45) NOT NULL); 

CREATE TABLE Employer(
    LoginID INT PRIMARY KEY NOT NULL, 
    name VARCHAR(45) NOT NULL, 
    ROLE VARCHAR(45) NOT NULL, 
    FOREIGN KEY(LoginID) REFERENCES Login(LoginID)); 

CREATE TABLE Applicant(
    LoginID INT PRIMARY KEY NOT NULL, 
    name VARCHAR(45) NOT NULL, 
    DOB VARCHAR(45) NOT NULL, 
    FOREIGN KEY(LoginID) REFERENCES Login(LoginID)); 

CREATE TABLE Job(
    (jobId INT PRIMARY KEY NOT NULL, 
    title VARCHAR(45) NOT NULL, 
    description VARCHAR(45) NOT NULL, 
    ListedByEmployerId INT NOT NULL, 
    FOREIGN KEY(ListedByEmployerId) REFERENCES Employer(LoginID)); 

Эта модель, однако, не ограничивают работу, должны быть перечислены работодателями только - это должно быть принудительно применено в приложении или с правилом базы данных, триггером и т. д.. Внешний ключ к Employer(LoginID), конечно, обращается к этому.

В требовании ничего не говорится о том, чтобы позволить заявителю ПРИМЕНЯТЬСЯ для работы, поэтому это не моделируется.

Но если это так, вам нужно разрешить многим претендентам подать заявку на одно задание - т. Е. Много: много соединительной таблицы.

Answer 2

В приведенном выше проекте схемы нет никакой связи между рабочими местами как для работодателя, так и для заявителя.

Если вы хотите посмотреть, какие рабочие места создали работодатель, или задание, поданное заявителем.

Поэтому я предлагаю вам добавить идентификатор работы как внешний ключ как для таблицы работодателя, так и для заявителя.