Нормализовать две таблицы с одним и тем же первичным ключом для 3NF

Question

У меня есть две таблицы в настоящее время с тем же самым первичным ключом, могу ли я иметь эти две таблицы с одним и тем же основным ключом?

Кроме того, все столы в 3-й нормальной форме

Ticket:     
------------------- 
Ticket_id* PK 
Flight_name* FK 
Names* 
Price 
Tax 
Number_bags 

Travel class: 
------------------- 
Ticket id * PK 
Customer_5star 
Customer_normal 
Customer_2star 
Airmiles 
Lounge_discount 
ticket_economy 
ticket_business 
ticket_first 
food allowance 
drink allowance 

остальной части таблицы в базе данных ниже

Пассажиров:

имен * PK Credit_card_number Credit_card_issue TICKET_ID * Адрес

Рейс:

Flight_name * PK FLIGHT_DATE Source_airport_id * FK Dest_airport_id * FK Источник Destination Plane_id *

Аэропорт:

Source_airport_id * PK Dest_airport_id * PK Source_airport_country Dest_airport_country

Пилот:

Pilot_name * PK Plane идентификатор * FK Pilot_grade месяц часов пролетели Оценить

Plane:

Plane_id * PK Pilot_name * FK

Answer 1

Имея две таблицы с тем же ключом идет против идеи устранения избыточности при нормализации.

Исключая это, являются ли эти таблицы в 1NF и 2NF?

Судя по полям Names, я бы предложил, чтобы таблица1 не была. Если несколько имен могут принадлежать одному биту, вам нужна новая таблица, скорее всего, с составным ключом ticket_id,name.

Answer 2

Это не означает, как ответ, но он стал слишком длинным для комментария ...

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

Рассмотрите, что произойдет, если Пассажир покупает второй билет, например. Таблица Пассажира не должна содержать никаких ссылок на билеты. Может быть, у пассажира может быть более одной кредитной карты? Разве кредитные карты не должны быть за столом? То же самое относится к адресам.

Почему в таблице аэропорта содержится информация, которая действительно касается пунктов назначения (или путей/поездок)? Вы уже записываете информацию о поездке в таблицу «Полеты». Мне кажется, что в таблице аэропорта должна храниться информация, относящаяся к определенному аэропорту (например, имя, местоположение ?, код ИАТА и так далее).

Может ли пилот быть связан только с одним самолетом? Звучит не очень. Пилотная таблица не должна содержать информацию о самолетах.

И таблица Planes не должна содержать информацию о пилотах, так как самолет, безусловно, может быть подключен к нескольким пилотам.

И так далее ... есть, скорее всего, и другие проблемы, но эти указатели должны дать вам о чем подумать.

Единственные столы, которые мне нравятся, - это билет и полет.

Answer 3

Re же первичный ключ:

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

Например: типичным разумным случаем является «подтипирование»/«субтитры», где объекты, идентифицированные ключом кандидата одной таблицы, всегда или иногда также имеют вид, идентичный тем же значениям в другой таблице. (Если всегда, то значения ключа кандидата в одной таблице также находятся в другой таблице. И поэтому мы будем объявлять внешний ключ от одного к другому. Мы бы сказали, что тип одной таблицы является подтипом другого.) On с другой стороны иногда одна таблица используется с атрибутами обоих видов и атрибутов, неприменимых к одному виду, не используются. (Т.е. через NULL или тег, указывающий вид.)

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

Например: все ключи простые и 3NF подразумевают 5NF, поэтому, если ваши две таблицы имеют одинаковый набор значений, только & простой первичный ключ в каждом состоянии, и оба они находятся в 3NF, тогда их соединение содержит точно такую ​​же информацию, как они делать отдельно. Тем не менее, возможно, вы сохранили бы их отдельно для ясности дизайна, для вероятности изменения или для производительности, основанной на использовании. Вы не указали эту информацию.

Re нормальных форм:

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

Для нормализации или определения самой высокой нормальной формы таблицы необходимо знать (в общем) все функциональные зависимости в ней. (Для нормальных форм выше BCNF, также присоединяйтесь к зависимостям.) Вы их не дали. Они определяются тем, что означает значение таблицы (то есть, как определить, какие строки идут в ней в любой заданной ситуации) и возможные ситуации, которые могут возникнуть. Вы их не дали. Ваше ожидание, что мы могли бы рассказать вам о нормальных формах ваших таблиц, не указывая такую ​​информацию, предполагает, что вы не понимаете нормализации и вам нужно воспитывать себя.

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