Все еще запутался в идентификации и неидентификации отношений
Итак, я читал об идентификации и неидентификации отношений в моей структуре базы данных, и некоторые ответы на SO кажутся мне противоречащими. Вот два вопроса, на которые я смотрю:
- В чем разница между идентификацией и неидентификацией отношений
- Проблемы при определении идентифицирующих или неидентифицирующих отношений
Глядя на главные ответы на каждый вопрос, я, кажется, получаю две разные идеи о том, что такое идентифицирующая связь.
В ответе на первый вопрос говорится, что идентифицирующая связь "описывает ситуацию, в которой существование строки в дочерней таблице зависит от строки в родительской таблице". Примером этого является: "Автор может написать много книг (отношение 1 к n), но книга не может существовать без автора". Это имеет смысл для меня.
Однако, когда я читаю ответ на второй вопрос, я смущаюсь, когда он говорит: "Если ребенок идентифицирует своего родителя, это идентифицирующая связь". Затем в ответе приводятся примеры, такие как номер социального страхования (идентифицирующий личность), а адрес - нет (поскольку многие люди могут жить по одному адресу). Для меня это больше похоже на случай выбора между первичным ключом и не первичным ключом.
Мои интуитивные ощущения (и дополнительные исследования на других сайтах) указывают на то, что первый вопрос и его ответ верны. Тем не менее, я хотел проверить, прежде чем продолжить, поскольку я не хочу учиться чему-то неправильному, поскольку я работаю над пониманием дизайна базы данных. Заранее спасибо.
8 ответов
Техническое определение идентифицирующих отношений состоит в том, что внешний ключ ребенка является частью его первичного ключа.
CREATE TABLE AuthoredBook (
author_id INT NOT NULL,
book_id INT NOT NULL,
PRIMARY KEY (author_id, book_id),
FOREIGN KEY (author_id) REFERENCES Authors(author_id),
FOREIGN KEY (book_id) REFERENCES Books(book_id)
);
Увидеть? book_id это внешний ключ, но это также один из столбцов в первичном ключе. Таким образом, эта таблица имеет идентифицирующую связь с ссылочной таблицей Books, Кроме того, он имеет идентифицирующую связь с Authors,
Комментарий к видео на YouTube имеет идентифицирующую связь с соответствующим видео. video_id должен быть частью первичного ключа Comments Таблица.
CREATE TABLE Comments (
video_id INT NOT NULL,
user_id INT NOT NULL,
comment_dt DATETIME NOT NULL,
PRIMARY KEY (video_id, user_id, comment_dt),
FOREIGN KEY (video_id) REFERENCES Videos(video_id),
FOREIGN KEY (user_id) REFERENCES Users(user_id)
);
Это может быть трудно понять, потому что в наши дни так принято использовать только серийный суррогатный ключ вместо составного первичного ключа:
CREATE TABLE Comments (
comment_id SERIAL PRIMARY KEY,
video_id INT NOT NULL,
user_id INT NOT NULL,
comment_dt DATETIME NOT NULL,
FOREIGN KEY (video_id) REFERENCES Videos(video_id),
FOREIGN KEY (user_id) REFERENCES Users(user_id)
);
Это может скрыть случаи, когда таблицы имеют идентифицирующую связь.
Я бы не стал рассматривать SSN для идентификации отношений. Некоторые люди существуют, но не имеют SSN. Другие люди могут подать заявку на получение нового SSN. Таким образом, SSN на самом деле является просто атрибутом, а не частью первичного ключа человека.
Re комментарий от @Niels:
Так что, если мы используем суррогатный ключ вместо составного первичного ключа, нет заметной разницы между использованием идентифицирующих или неидентифицирующих отношений?
Я так полагаю. Я не решаюсь сказать "да", потому что мы не изменили логические отношения между таблицами, используя суррогатный ключ. То есть вы по-прежнему не можете оставлять комментарии, не ссылаясь на существующее видео. Но это просто означает, что video_id должен быть NOT NULL. И логический аспект, для меня, действительно заключается в определении отношений.
Но есть и физический аспект выявления отношений. И это тот факт, что столбец внешнего ключа является частью первичного ключа (первичный ключ не обязательно является составным ключом, это может быть один столбец, который является как первичным ключом комментариев, так и внешним ключом таблицы Videos., но это будет означать, что вы можете хранить только один комментарий на видео).
Кажется, что идентификация отношений важна только для построения диаграмм отношений сущностей, и это появляется в инструментах моделирования данных GUI.
"поскольку я не хочу учить что-то не так".
Welll, если вы действительно это имеете в виду, тогда вы можете перестать беспокоиться о языке ER и терминологии. Это неточно, запутанно, запутанно, совсем не согласовано и по большей части не имеет значения.
ER - это группа прямоугольников и прямых линий, нарисованных на листе бумаги. ER специально предназначен для неформального моделирования. Таким образом, это ценный первый шаг в проектировании базы данных, но это также и первый шаг.
Диаграмма ER никогда не должна приближаться к точности, точности и полноте дизайна базы данных, официально записанного в D.
Идентифицирующие / неидентифицирующие отношения являются концепциями в моделировании ER - отношения, являющиеся идентифицирующими, если они представлены внешним ключом, который является частью первичного ключа ссылочной таблицы. Это обычно очень мало важно в терминах реляционного моделирования, потому что первичные ключи в реляционной модели и в базах данных SQL не имеют какого-либо особого значения или функции, как в модели ER.
Например, предположим, что в вашей таблице используются два ключа-кандидата, A и B. Предположим, что A также является внешним ключом в этой таблице. Представленная таким образом взаимосвязь считается "идентифицирующей", если A обозначена как "первичный" ключ, но она не идентифицирует, если B является первичным ключом. Тем не менее, форма, функция и значение таблицы идентичны в каждом случае! Вот почему, на мой взгляд, я не думаю, что концепция идентификации / неидентификации действительно очень важна.
Я считаю, что единственная разница между идентифицирующими и неидентифицирующими отношениями заключается в обнуляемости внешнего ключа. Если FK не может быть НЕДЕЙСТВИТЕЛЬНЫМ, отношение, которое он представляет, идентифицирует (дочерний элемент не может существовать без родителя), иначе это не идентифицирующий.
Часть проблемы здесь - путаница в терминологии. идентификация отношений полезна для избежания длинных путей соединения.
Лучшее определение, которое я видел, это "идентифицирующая связь включает в себя PK как родителя в дочернем PK. Другими словами, PK ребенка включает в себя FK для родителя, а также" фактический " PK ребенка.
Идентифицирующие отношения - это действительно концепция ERD, поскольку это область концептуального моделирования, моделирующего наше понимание "вселенной дискурса". Это родительско-дочерние отношения, при которых мы моделируем тот факт, что идентичность каждого дочернего объекта (по крайней мере, частично) устанавливается / определяется идентичностью родительского объекта. Поэтому он обязателен и неизменен.
Примером из реальной жизни является постоянная проблема идентификации людей. Уникальная личность человека может быть (частично) определена его отношениями с его родной матерью и отцом. Когда это известно, это незыблемые факты. Таким образом, отношения между рождением родителя и ребенком являются определяющими отношениями в том смысле, что они вносят (неизменно) вклад в определение личности ребенка.
Именно эти качества и использование реляционных конструкций dbms приводят к тому, что PK ребенка является составным ключом, который включает через FK PK родителя. Как PK, личность ребенка является обязательной и неизменной (она не может измениться). "Изменение" в PK фактически создает новый объект. Поэтому PK не должен быть в состоянии изменить. Неизменность PK также должна быть ограничена. Ограничения БД могут быть использованы для реализации этого качества ПК.
Да, иди с первым, но я не думаю, что второе противоречит первому. Это просто сформулировано немного запутанно..
ОБНОВИТЬ:
Только что проверил - ответ на второй вопрос неверен в некоторых предположениях,.. книга-автор не обязательно является отношением 1:n, как это может быть m:n. В реляционных базах данных, которые создают таблицу пересечений для этого отношения m: n, вы получаете идентифицирующие отношения между таблицей пересечений и этими двумя другими таблицами.
Идентификационная связь выдает одно-многим необязательное отношение, когда мы должны определить родительские и дочерние отношения. Кроме того, оно дает одно-единственное отношение от дочернего к родительскому потоку. Поскольку первичный ключ родительского объекта будет частью первичного ключа дочернего объекта, Экземпляр дочерней сущности будет идентифицировать экземпляр родительской сущности. Он представлен сплошной линией на диаграмме er.
где неидентифицирующая связь будет иметь отношение многие ко многим. Для существования экземпляра дочерней сущности должен существовать экземпляр родительской сущности, но каждый экземпляр сущности в дочерней сущности может быть связан со многими экземплярами сущности родительской сущности. Именно поэтому первичный ключ родительская сущность может быть внешним ключом дочерней сущности, но дочерняя сущность не будет принимать первичный ключ родительской сущности, так как ее первичный ключ. у него будет собственный первичный ключ. отношение многих ко многим не существует в реальном мире. так что это должно быть решено