Как определить отношения в СУБД?

Question

Я изучал отношения в RDBMS. Я понял базовую концепцию, лежащую в основе отношения отношения корабля, но я не могу их обнаружить.

три возможности:

1. один ко многим (наиболее часто) требует PK - Таблицы ФК relationsip.Two участвует
2. многие ко многим (реже) требует перехода table.Three таблиц, входящих
3. один к одному (очень редкий). Один стол.

Когда я начинаю проект, я не могу отделить первые два условия, и я не понимаю в голове. Примеры, когда я изучаю помощь на короткое время, но не тогда, когда мне нужно применить эти принципы для практики.

Это место, где большинство начинающих колеблются. Как я могу определить эти отношения. Есть ли более простой способ?

Answer 1

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

Например, предположим, что у нас есть база данных библиотек. Библиотека должна иметь книги.

М: М

Каждого Book может быть написано кратным Authors и каждый Author может быть записан кратным Books. Таким образом, это отношение много ко многим, которое отразится на 3 таблицах в базе данных.

1: M

Каждый Book должен также иметь Publisher, но Book может иметь один Publisher только и Publisher может публиковать много Books. Таким образом, это отношение «один ко многим», и оно отражает с ссылкой PublisherId, ссылающейся на таблицу Books.

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

Answer 2

Скажите, что у вас есть две таблицы A и B. Рассмотрим запись от A и подумайте, сколько записей из B могло быть связано, самое большее: только одно или более? Затем рассмотрим запись из B и подумайте, сколько записей в A можно было бы связать.

Некоторые примеры:

Таблица A: Матери, Таблица B: Дети. У каждого ребенка есть только одна мать, но у матери может быть один или несколько детей. Матери и дети имеют отношение «один ко многим».

Таблица A: Доктора, таблица B: Пациенты. Каждый пациент может посещать одного или нескольких врачей, и каждый врач лечит одного или нескольких пациентов. Таким образом, у них есть отношения «многие-ко-многим».

Answer 3

Пример одного к одному: LicencePlate to Vehicle. Один номерной знак принадлежит одному транспортному средству, а одно транспортное средство имеет один номерной знак.

Answer 4

Я думаю, причина, по которой вы не получаете ответы, которые вам нужны, объясняется тем, как вы формулируете вопрос. Вместо того, чтобы спрашивать: «Как определить правильный тип отношений между сущностями», подумайте о «Как мои функциональные потребности диктуют, какие отношения нужно реализовать». Конструкция базы данных не управляет функцией; это функциональные потребности, которые стимулируют отношения, которые вам нужно реализовать.

При проектировании структуры базы данных необходимо идентифицировать все объекты. Сущности - это все факты, которые вы хотите сохранить: списки вещей, таких как названия книг, счета-фактуры, страны, виды собак и т. Д. Затем, чтобы определить ваши отношения, вы должны рассмотреть типы вопросов, которые вы хотите запросить в своей базе данных. Иногда это требует немного передового мышления ... потому что никто не задает вопрос сейчас не означает, что его никогда не спросят. Поэтому вы не можете спросить Вселенную «какова связь между этими списками фактов?», Потому что нет окончательного ответа. Вы определяете вселенную ... Я только хочу знать ответы на эти типы вопросов; поэтому мне нужно использовать этот тип отношений.

Рассмотрим пример отношения между двумя общими объектами: таблицей клиентов и таблицей мест хранения. Не существует «правильного» способа связать эти объекты без предварительного определения того, что вам нужно знать о них. Предположим, вы работаете в розничном магазине, и вы хотите предоставить клиенту обозначение магазина по умолчанию, чтобы они могли видеть продукты на веб-сайте, которые есть в их местном магазине. Это требует только отношения «один ко многим» между магазином и клиентом. Проектирование отношений таким образом гарантирует, что у одного магазина может быть много клиентов по умолчанию, и каждый клиент может иметь только один магазин по умолчанию. Для реализации этого отношения так же просто, как добавление поля DefaultStore в таблицу Customer в качестве внешнего ключа, который ссылается на первичный ключ таблицы Store.

Те же самые два сущности выше могут иметь альтернативные требования для определения отношений в другом контексте. Предположим, что мне нужно дать клиенту возможность выбрать список любимых магазинов, чтобы они могли запросить в сводной информации обо всех них сразу. Это требует отношения «многие ко многим», потому что вы хотите, чтобы один клиент мог иметь отношение ко многим магазинам, и каждый магазин также может относиться ко многим клиентам. Для реализации отношений «многие ко многим» требуется немного больше накладных расходов, потому что вам нужно будет создать отдельную таблицу для определения связей отношений, но вы получите эту дополнительную функциональность. Вы можете назвать свою таблицу отношений чем-то вроде CustomerStoreFavorites и иметь в качестве ее первичного ключа как комбинированные первичные ключи от каждого из объектов: (CustomerID, StoreID). Вы также можете добавить атрибуты к отношениям, например, возможно, поле LastOrderDate, чтобы указать последнюю дату, которую заказчик заказал у определенного магазина.

Вы можете технически определить оба типа отношений для тех же двух объектов. В качестве примера: возможно, вам нужно предоставить клиенту возможность выбрать хранилище по умолчанию, но вы также должны иметь возможность записать последнюю дату, которую заказчик заказал в определенном магазине. Вы можете реализовать поле DefaultStore в таблице Customer с внешним ключом в таблице Store, а также создать таблицу отношений для отслеживания всех магазинов, заказанных клиентом.

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

Вкратце, как вы определяете, какой тип отношений должен быть реализован, спросить себя, какие вопросы вам нужно задать в базе данных. Способ его создания ограничит реляционные данные, которые вы можете собрать, а также запросы, которые вы можете задать. Если я создаю отношения «один ко многим» от магазина к клиенту, я не буду задавать вопросы обо всех магазинах, которые заказал каждый клиент, если я не могу получить эту информацию, хотя другие отношения. Например, я мог бы создать объект под названием «покупки», который имеет отношение «один ко многим» к клиенту и его хранение. Если каждая покупка определяется как относящаяся к одному клиенту и одному магазину, теперь я могу запросить «какие магазины заказал этот заказ?». Фактически с этой структурой я могу фиксировать и сообщать о гораздо более богатом источнике информации обо всех покупки клиента в любом магазине. Таким образом, вам также необходимо рассмотреть контекст всех других отношений в вашей базе данных, чтобы решить, какое отношение реализовать между двумя конкретными объектами.

Нет волшебной формулы, поэтому она просто требует практики, опыта и небольшого творчества. ER Diagrams - отличный способ вывести свой дизайн из головы и на бумагу, чтобы вы могли проанализировать свой дизайн и убедиться, что вы можете получить ответы на нужные вопросы. Существует также много книг и ресурсов, чтобы узнать о архитектуре базы данных. Одна хорошая книга, которую я многому научился, - это «Концепции системы баз данных» Абрахама Сильбершаца и Генри Корта.