2012-04-16 2 views
0

я не могу узнать, что это неправильно, что я получаю сообщение об ошибке:Невозможно создать внешний ключ с использованием отдельных столбцов против нескольких столбцов первичного ключа

Msg 1776, Level 16, State 0, Line 56 В ссылочной таблице «Тип воздушного судна» нет первичных или кандидатов ключей «Тип самолета», которые соответствуют списку столбцов по внешнему ключу 'FK_ Самолет _make__68487DD7'. Msg 1750, уровень 16, состояние 0, строка 56 Не удалось создать ограничение. См. Предыдущие ошибки.

Вот та часть запроса:

CREATE TABLE Airplane_type 
(
make VARCHAR NOT NULL, 
model VARCHAR NOT NULL, 
type VARCHAR NOT NULL, 
business_capacity INT NOT NULL, 
economy_capacity INT NOT NULL, 
range INT NOT NULL, 
weight INT NOT NULL, 
length INT NOT NULL, 
wingspan INT NOT NULL, 
PRIMARY KEY(make, model) 
); 

CREATE TABLE Airplane 
(
airplane_ID VARCHAR(3) NOT NULL PRIMARY KEY, 
make VARCHAR NOT NULL FOREIGN KEY REFERENCES Airplane_type(make), 
model VARCHAR NOT NULL FOREIGN KEY REFERENCES Airplane_type(model) 
); 

Любая помощь очень ценится, благодаря

ответ

3

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

CREATE TABLE Airplane 
(
    airplane_ID VARCHAR(3) NOT NULL PRIMARY KEY, 
    make VARCHAR NOT NULL, 
    model VARCHAR NOT NULL, 
    CONSTRAINT FK_Airplane_type FOREIGN KEY (make, model) 
    REFERENCES Airplane_type(make, model) 
); 

Кроме того, почему вы используете VARCHAR без указания длины? Пожалуйста, прочитайте эту запись в блоге: http://sqlblog.com/blogs/aaron_bertrand/archive/2009/10/09/bad-habits-to-kick-declaring-varchar-without-length.aspx

+0

Несмотря на 15 лет + сервера sql, я не знал, что вы можете это сделать, конечно, они не помогают мне согласиться с тем, почему вы хотите. –

+0

Еще один совет для вас @Troy. Поместите имена в свои ограничения, используйте стандартное соглашение об именах, это всегда помогло мне, когда колеса сошли. –

1

Столбец, на который ссылается внешний ключ, должен быть ограничен первичным ключом или уникальным индексом. Поскольку ваш первичный ключ представляет собой совокупность двух столбцов (make, model), внешний ключ должен также ссылаться на ту же сложную пару.

0
CREATE TABLE Airplane_type 
(
airplane_type_id not null Identity(1,1), 
make VARCHAR NOT NULL, 
model VARCHAR NOT NULL, 
type VARCHAR NOT NULL, 
business_capacity INT NOT NULL, 
economy_capacity INT NOT NULL, 
range INT NOT NULL, 
weight INT NOT NULL, 
length INT NOT NULL, 
wingspan INT NOT NULL, 
CONSTRAINT PK_AIRPLANE_TYPE PRIMARY KEY(airplane_type_id), 
Constraint UK_Spotted_By_AARON Unique Key (make, model) 
); 

CREATE TABLE Airplane 
(
airplane_ID VARCHAR(3) NOT NULL, 
airplane_type_id int not null CONSTRAINT FK_Airplane_AirPlane_Type 
    Foreign Key References(AirPlane.Airplane_type_id), 
Constraint PK_Airplane Primary Key (Airplane_id), 
); 

Использование частей сложного ключа в качестве ограничения не является зрителем, насколько я знаю, и если вы нормализуете его, это не нужно. Действительный способ, которым у вас была ваша схема, - самолет с комбинацией моделей и моделей не в таблице вашего самолета.

+0

Как добавление столбца идентификации и удаление ключа на 'make, model' помогают? Теперь у вас может быть дубликат 'make, model', потому что единственное единственное ограничение - на бессмысленное значение идентификатора. По крайней мере, у вас должно быть уникальное ограничение на make, model или наоборот (ограничение внешнего ключа * может * ссылаться на уникальное ограничение в SQL Server, а не только на первичный ключ, поэтому вы можете иметь оба). –

+0

Я собираюсь взять здесь дикое предположение и предсказать, что вы не сидите на одной стороне суррогатной и естественной дискуссии. Я забыл об уникальном ограничении, дай мне минуту. Бессмысленная идентификационная ценность - это точка ... –

+0

Нет. Я согласен с суррогатами. Я просто думаю, что ИДЕНТИФИКАЦИЯ слишком часто бросается на стол, служащий единственным уникальным аспектом таблицы. Мой ответ на вопрос был основан на объяснении, почему было вызвано сообщение об ошибке, а не о перепроектировании таблицы. В любом дизайне я не вижу цели второй таблицы. –