Хорошо, у меня есть 2 стола. Таблица книг с основным ключом book_id и другим полем, называемым названием. И таблица автора с основным ключом author_id и поля first_name, last_name и внешний ключ book_id.Разве это дизайн confrorm 2NF?
Является ли мой дизайн совместимым с 2NF?
Обычно (и с точки зрения непрофессионала), нормализация на уровне одного означает:
Для 2NF у вас есть дополнительное ограничение, что каждый столбец зависит от всего ключа (прямо или косвенно через другой нек-ключ).
Поэтому я бы сказал, что он соответствует 2NF в этом случае, так как он соответствует критериям для 1NF, и книга зависит от автора.
Однако это не обязательно хороший дизайн, тем более, что вы всегда должны начинать с 3NF, как правило. Лучшим решением было бы полномасштабная:
books:
book_id
title
authors:
author_id
name
books_and_authors:
book_id
author_id
Таким образом, у вас есть много-ко-многим (включая ноль) связи между книгами и авторами.
таблица находится в 2НФ, если и только тогда, когда оно находится в 1НФ и нет, не главный атрибут не зависит от любого собственного подмножества любого кандидата ключа таблицы (от wikipedia).
Я должен предположить, что ваш стол находится в 1NF.
Вашими кандидатами (и первичными) являются book_id и author_id.
Ваши, не простые атрибуты название, first_name и last_name. Ни один из этих атрибутов не зависит от любого правильного подмножества ключей-кандидатов (что легко реализовать, поскольку у них нет подмножеств). Единственная проблема с этим дизайном заключается в том, что внешний ключ book_id делает книгу-автора соотношением 1: 1 (т. Е. Одна книга -> один автор. Один автор -> одна книга). Это может быть легко исправлено с новой таблицей проведения book_id и AUTHOR_ID
1nf (также wikipedia):
Как мы привыкли строить реляционные базы данных.
Я знаю, что это не очень хороший дизайн, учитывая, что он не вмещает отношения «многие ко многим». Мой вышеупомянутый вопрос был просто предназначен для выяснения проблемы в моем сознании. Спасибо за помощь. –