Должен ли быть внешний ключ «к» ассоциативному объекту или «от» ассоциативного объекта?

Question

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

В настоящее время у меня есть объект Book с ISBN (первичный ключ), заголовок и некоторые другие в качестве атрибутов.

У меня есть объект Author сauthor_id (первичный ключ), name.

Поскольку книга и автор - это отношение многие ко многим.У меня есть ассоциативная сущность Authorted_title с ISBN и author_id в качестве атрибутов.Таким образом, ISBN является внешним ключом для сущности Book, а author_id является внешним ключом для сущности Author.

Мой вопрос заключается в том, возможно ли иметь ISBN из сущности Book в качестве внешнего ключа для объекта author_id и в качестве Authorсоответствующие атрибуты в ассоциативной сущности Authored_title, чем наоборот (в отличие от того, что я упоминал в предыдущем абзаце)?

Я немного растерялся, подумав об этом.Есть ли в таблицах даже что-то вроде "до" и "от", когда дело доходит до ФК?

Answer 1

Идея ограничения внешнего ключа состоит в том, что оно предотвращает создание записи в таблице X, если в таблице Y нет записи, к которой относится X.В вашем случае Author и Book имеют первичные ключи, а таблица Book_Author, которая разбивает отношение M: M до двух, отношения 1: M привязаны к Author и Book;Вы не можете создать запись в Book_Author до тех пор, пока вы сначала не создадите запись в Book, а также запись в Author

Похоже, вы спрашиваете, можете ли вы сделать это наоборот, и набираете таблицу Book иТаблица автора к таблице Book_Author

Ответ - Нет (ну, нет, нет, но это действительно не следует)

Чтобы принять отношения внешнего ключа,Book_Author должен иметь первичный ключ.Что вы выберете для первичного ключа?Вы можете использовать BookID + AuthorID.Вы могли бы иметь отдельный инкремент int или guid, но размещение такого типа PK в таблице, которая разрушает ассоциацию M: M, находится в списке «просто потому, что вы можете, это не значит, что вы должны».Вы не можете установить внешний ключ только для части первичного ключа, поэтому, если Book и Author должны быть привязаны к Book_Author, а Book_Author иметь составной PK, тогда другим таблицам (Book, Author) понадобятся дополнительные столбцы для покрытиядругие элементы ключа;в итоге вы сохраните автора в таблице книг, а книгу - в таблице авторов.Что тогда за книга с двумя авторами?Для этого потребуется две записи в таблице Book, по одной для каждого автора. Предполагается, что мы активно удаляем эту программу дублирования данных, когда нормализуем нашу базу данных.Этот шаг активно нормализуется.Тот же аргумент существует для помещения возрастающего PK в вашу таблицу Book_Author;как вы представляете, что у книги 2 автора?Вам нужно 2 строки в вашей таблице ассоциации, и они не могут иметь одинаковое значение PK, поэтому давайте дадим им разные значения:

BookAuthorId, Book, Author
1, GoodOmens, NeilGaiman
2, GoodOmens, TerryPratchett

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

Book Name, BookAuthorId, Description
Good Omens, 1, A funny story about life as a fallen angel
Good Omens, 2, A funny story about life as a fallen angel

Чем больше времени вы тратите на размышления об этой концепции, что «Book_Author должен быть первичным ключом, а таблицы Book и Author должны иметь внешний ключ к нему», тем больше вы пойметечто он абсолютно неработоспособен и ничего не решает, он просто создает головные боли

Одна книга, одна строка в таблице книг.Один автор, один ряд в авторах.У нас есть эти правила, потому что есть только один Терри Пратчетт, один Нил Гейман, одна история под названием Good Omens.Все эти «единые» вещи должны иметь одну строку, первичный ключ идентифицирует ее… и когда мы хотим связать эти вещи вместе в комбинации, мы используем другую таблицу, которая имеет составной ключ, который гарантирует, что мы не сможем записать Нила Гаймана дважды какнаписав Good Omens и внешний ключ, чтобы гарантировать, что Книга и Автор, которых мы связываем вместе, действительно существуют ... Нет смысла присваивать книги несуществующим авторам и несуществующие книги авторам ..

Итак,вот почему эти вещи "так" круглые;«наоборот» не имеет никакой выгоды

Answer 2

Нет.Ваша первоначальная реализация верна.FK в вашей таблице ссылок ссылаются на PK в ваших таблицах сущностей.

Редактировать

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

A FK -> PK В сущности, отношение many -> one.В вашем случае многие строки в таблице ссылок будут ссылаться на одну строку в таблице сущностей.