Дизайн базы данных: основной ключ и многие из многих ассоциаций

Question

Это мой первый проект базы данных моей домашней библиотеки. У меня вопрос о том, как реализовать первичные ключи в каждой таблице, мне также интересно узнать, допустимо ли иметь множество таблиц, связанных с одним из иностранных, как у меня есть со многими отношениями с «contributor_id».

Не все мои таблицы имеют первичный ключ. Если первичный ключ НЕ должен быть внешним ключом (как я понял это), что может служить первичным ключом в таблицах copy_info и book_info? Я не уверен, что правильно реализовал таблицы-посредники, где может существовать много-много отношений. Является ли ситуация ситуацией, когда мне потребуется составной первичный ключ ?

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

Answer 1

Я недопонимание, как реализовать многие-ко многие отношения. После того, как я установил соединительные столы, у моих таблиц были первичные ключи. Updated Design

Answer 2

Я просто дать несколько простых советов:

• Я понимаю, 4 таблицы слева является промежуточной между таблицей book_info и 4 других таблицами с переводчиками информацией, информацией авторов и так далее; я прав? Так много отношений для многих (у книги может быть много авторов, а у одного автора много книг), но если вы настраиваете такие таблицы каждый раз, когда вы пытаетесь вставить тому же вкладчику в другую книгу, это вызовет повторяющаяся ошибка ключа! Итак, удалите ключи оттуда.

• правильный путь, чтобы назначить клавишу для этих агрегированных таблиц с будет назначить ключ к обеим значениям (так что вы никогда не сломаетесь «уникальность» ограничения), НО полностью неполезный (и трата пространства и ресурсы Db) для назначения ключей в этих простых таблицах совокупности

• books andinfo_info - это взаимно однозначные отношения? Таким образом, имеет смысл разделить это на две отдельные таблицы ТОЛЬКО для целей аккуратности (например, если у вас много полей, и вы хотите их разделить по некоторым логическим критериям)
  books и book_info - это еще одно отношение «многие ко многим» ? В этом случае поле «id» в качестве ключа является правильным решением, но неправильно сопоставлять книги таблиц и copy_info (лучше соединить copy_info с book_info, чтобы вы разделили его на два отношения «один ко многим» (легче управлять в данном случае)

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