Идентифицирующие и неидентифицирующие отношения
Прежде всего, я прочитал несколько похожих вопросов с "техническими" ответами, которые выглядят как C & P. То, что мне нужно, это наглядный пример. Нормализация 3НФ.
В этом проекте в административной панели вы должны создать города и зоны, и каждая зона должна принадлежать городу. Также создайте отели и назначьте их в соответствующей зоне, и, наконец, создайте псевдонимы для каждого конкретного отеля, поскольку люди знают один и тот же отель под разными именами. Таблицы hotels и hotels_alias заполняют данные автозаполнения.
Расчет цены производится в соответствии с услугой (стандартная, частная и VIP) в зависимости от зоны, а также в зависимости от количества пассажиров и сезона. Я до сих пор не создаю логику или таблицы для расчета цены на пассажира и сезон. Вот почему их нет на диаграмме ниже.
Я нашел хорошее объяснение: в чем разница между идентифицирующими и неидентифицирующими отношениями?
Однако у меня есть некоторые сомнения.
hotels_alias не может существовать без таблицы отелей, которые, в свою очередь, не могут существовать без таблицы зон, а это, в свою очередь, не может существовать без городов. Поскольку город разделен на множество зон, отели принадлежат этим зонам, зонам, которые являются частью города, и псевдонимы гостиниц принадлежат гостинице и не могут существовать, если нет гостиницы.
Пока ясно, что города являются сильными или родительскими объектами, а зоны, hotels и hotels_alias являются дочерними объектами.
На диаграмме EER вы можете видеть, что она имеет идентифицирующую связь. Первый вопрос: правильно ли, что, несмотря на то, что дочерние объекты имеют свои собственные идентификаторы? и что это идентификатор PK и NN и AI? В некоторых примерах эти дочерние объекты не имеют своего собственного идентификатора, следовательно, их PK формируется двумя FK из связанных таблиц, как в отношении N: N (zone_has_servicees).
Если на самом деле дочерние таблицы не должны иметь свой собственный идентификатор, потому что они должны иметь возможность идентифицировать себя по родительской таблице, то как вы сможете обновить или удалить область, или отель, или псевдоним отеля?
DELETE FROM zones WHERE name = 'name'
Это правильно? Должен ли я создать индекс для столбца имени? Какие преимущества, если таковые имеются, будут делать с именем Colum вместо его собственного идентификатора? Можно ли для дочерней таблицы иметь собственный идентификатор и создать составной PK с этим идентификатором и идентификатором родительской таблицы? Имеет ли этот тип отношений какую-либо функцию или это только для таких движков, как InnoDB? выполнить действие ON DELETE CASCADE?
Что произойдет, если у меня две зоны с одинаковым именем? например: Hotel Zone, что оба города Канкун и Тулум имеют эту область. Сделать УДАЛЕНИЕ было бы?
DELETE FROM zones WHERE name = 'name' AND cities_id = ID
Понимая, что такое родительский и дочерний объект, почему WordPress создает отношения, подобные приведенным ниже, где вы можете видеть, что он использует слабые отношения с wp_postmeta и wp_posts. Предполагается, что wp_postmeta не может существовать без wp_posts, верно? То же самое касается комментариев и пользователей.
1 ответ
Во-первых, ваш пример 1 не является диаграммой EER (скорее назовите ее диаграммой таблицы). Чтобы называться диаграммой ER или EER, вы должны использовать нотацию (например, нотацию Чена), которая представляет понятия модели сущности-отношения и отличает наборы сущностей от отношений. В модели ER как отношения сущностей, так и отношения взаимосвязей реализуются с использованием таблиц, и ни одна из них не соответствует ограничениям FK, которые являются просто механизмом целостности. Многие люди путают модель ER со старой моделью данных сети.
Во-вторых, идентифицирующие отношения используются в сочетании со слабыми наборами сущностей, в которых первичный ключ регулярного (родительского) набора сущностей образует часть первичного ключа слабого (дочернего) набора сущностей. Когда набор сущностей идентифицируется его собственными атрибутами, это обычный набор сущностей.
Чтобы удалить строку из слабого отношения сущности, вы обычно определяете ее по первичному ключу. Слабые наборы сущностей обычно имеют составной первичный ключ, состоящий из родительского ключа и дополнительного слабого ключа. Слабый ключ должен быть уникальным только в сочетании с родительским ключом. Например, если zones были определены cities_id а также nameВы можете удалить зону, указав эти атрибуты:
DELETE FROM zones WHERE cities_id = 1 AND name = 'name';
Составной первичный ключ должен автоматически индексироваться и однозначно ограничиваться вашей СУБД, если вы объявили его как PK. Преимущество слабых наборов сущностей заключается в том, что в некоторых случаях этот метод идентификации является более естественным, чем введение бессмысленного суррогатного ключа.
Не очень хорошая идея иметь таблицу с составным первичным ключом, состоящим из уникального суррогатного идентификатора вместе с другим атрибутом, таким как идентификатор его родителя. Помимо риска непреднамеренного дублирования значений, если уникальность не соблюдается должным образом, это излишне усложняет то, что иначе было бы простой таблицей с простым суррогатным PK.
Ваша диаграмма WordPress не иллюстрирует слабые наборы сущностей или идентифицирующие отношения (и это не диаграмма EER, как упоминалось ранее). У каждой таблицы, которую вы упомянули, есть свои суррогатные ключи. Обратите внимание, что в модели ER нет слабых отношений.