Как нормализовать таблицу «место в самолёте», чтобы было понятно на какой рейс берётся место?
То есть чтобы не было такого чтобы в посадочном талоне были одинаковые места для разных пассажиров. Знаю только, что надо делать с помощью дополнительных ключей.
Adamos, Вы имеете ввиду такое? Если да, то я уже такое ей показывал, она сказала не так должно быть, кстати забыл важное замечание написать: в посадочном талоне первичным ключом будет что то другое, возможно как раз там нужны дополнительные ключи (но это не точно)
ravil262004, а зачем дублировать информацию? ID рейса + ID места.
И уж если говорить за нормализацию, то и в посадочном стоит прибраться: там достаточно ID билета и ID места в рейсе. Ну, и собственного номера.
Впрочем, угадать, чего хочет ваш препод, я не берусь.
ravil262004, из таблицы мест в самолете. Сами посмотрите на картинку - где в связанных таблицах оказываются одни и те же поля, там нарушена нормализация.
ravil262004, для связи между таблицами обычно используется простой, автоинкрементный первичный ключ на поле ID.
Для обеспечения уникальности записей - составной.
Причин использовать второй вместо первого я не знаю, а вот проблемы от такого использования довольно очевидны: например, обновление данных в одной таблице требует обновления их же и во всех связанных, использующих эти данные как ключ. Если этого не произошло - связь просто сломается.
Ну это видимо преподаватель так считает, но а всё же "место в самолёте на рейс" теоретически верна? Я так смотрю и кажется что более менее нормально, но при попытке сдать мне говорят какие то вещи, которые я не совсем понимаю, но опять же это только гадать. Спасибо, что попытались помочь! Зачёта мне уже в этом семестре видно не видать
ravil262004, у вас во всех таблицах, кроме центра картинки, нормализованы данные и связи - по ID.
Сделайте так же в таблицах рейса, билета, места... - и если у вас тема "нормализация", то препода это должно устроить ;)
Adamos, для связи между таблицами используется наиболее подходящий ключ в данном конкретном случае и это далеко не всегда суррогатный ключ.
Бездумно лепить суррогатные ключи -- болезнь современности.
s5656, наиболее подходящий у него выявится сильно позже, на этапе реализации, по практике использования данных. А соединение по сложным ключам на этапе планирования, только чтобы не создавать лишнее поле - экономия на спичках и создание себе же граблей на будущее.
