Добрый день. Подскажите пожлуйста, у меня есть поля.
airline_icao_code
airline_name
airline_call_sign
country_ID.
Первые три поля уникальны. По идее они прекрасно подходят для составного первичного ключа, однако этот же весь составной первичный ключ должен мигрировать в другие таблицы, я хочу избежать множество join в select. Могу ли я добавить сурогатный id, а первые три поля сделать уникальными? Не нарушвет ли это нормализацию?

Dimitry Sibiryakov, То есть сурогатный с ограничением уникальности на три поля неплохое решение, как я понял?

И еще вот один вопрос такой. Как сделать ограничение на то, чтобы поле содержала только верхний регистр?

Dimitry Sibiryakov, задача стоит в том, чтобы нормализовать БД. Набор из первых строк представляет собой уникальную идентификацию аэропорта, например
GRO
Grodno airline
GRODNO AIRLINE соответсвуют только одной авиакомпании по ICAO код, поэтому я и подумал, что эти три поля пододйдут для первичного ключа, но PK этой таблицу мигрирует в Полеты, и я не хочу мигрировать такой составной ключ в Полеты, вот и спросил про сурогатный ключ. Мне кажется, что поле страна айти тогда будет зависимть не только от сурогатного, но и от трех остальных полей. Очень надеюясь, что я понятно изложил суть своей проблемы

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

fkthat, вылетелело из головы ФНБК, если рассматривать составной ключ, тогда больше склоняюсь с сурогатному и ограничению по уникальности, чтобы не декомпозировать отношение. Спасибо

MasterZiv, мне сообщением выше написали, что это нарушает 3НФ, хотя я думал, что нет, так как каждое поле зависит от сурагатного. Как вариант, я могу разбить все же на две сущности airline_icao_code => airline_name и airline_icao_code => airline_call_sign, country_ID

Хотя делать связь 1 к 1 тоже не хочется, лишний джойн во время запроса

fkthat, airline_icao_code => airline_name и airline_icao_code => airline_call_sign, country_ID со связью 1 к 1?

fkthat, исходя из данных airline_call_sign тоже уникальный. По идее он тоже может быть альтернативным первичным ключом. Так как как и код и название он уникально идентифицирует афиакомпанию. Если рассматривать такой вариант, то я бы выбрал без сурогатного. Так как пусть имя и airline_call_sign так же уникально идентифицируют авиакомпанию, но по сути оба зависят от кода.

fkthat, по отдельности я не могу сделать эти поля, может быть только такой вариант для идентификации одной компании 'GRO', 'Grodno','Grodno_comp', других вариантов быть никак не может по стандарту. Каждое из этих полей может быть альтернативным первичным ключом

fkthat, получается три альтернативных ключа. Но ограничение уникальности должно быть на 3 поля. От кода точно зависит имя, да и сигн, но они могут быть альтеративными первичными ключами. Что-то я совсем запутался

fkthat, неправильно понял про уникальность на каждое поле, да, такой вариант правильнее, но id_ страны зависит не только от id авиакомпании.

Я думаю над таким варинатом решение

create table ttt (
airline_icao_code nvarchar(50) primary key,
airline_name nvarchar(50) not null unique,
airline_call_sign nvarchar(50) not null unique
);

create table tt (
airline_icao_code nvarchar(50) primary key,
country_ID int not null foreign key reference countries(ID)
);

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

fkthat, путаница в айти страны и зависимости ее как от первичного так и от альтернативного ключа