Какова реальная разница между отношениями один-ко-многим и многие-к-одному? Это только наоборот, вид?
Я не могу найти никакого "простого и понятного" учебника по этой теме, кроме этой: SQL для начинающих: Часть 3. Отношения с базами данных
Да, это наоборот. Это зависит от того, на какой стороне отношений присутствует сущность.
Например, если в одном отделе могут работать несколько сотрудников, то отношение отделов к сотрудникам является отношением один ко многим (в одном отделе занято много сотрудников), а отношение сотрудников к отделам - многие к одному (многие сотрудники работают в одном отделе).
Больше информации о типах отношений:
С этой страницы о терминологии базы данных
Большинство отношений между таблицами один ко многим.
Пример:
- Одна область может быть средой обитания многих читателей.
- Один читатель может иметь много подписок.
- Одна газета может иметь много подписок.
Отношение "многие к одному" такое же, как отношение "один ко многим", но с другой точки зрения.
- Многие читатели живут в одной области.
- Многие подписки могут быть одного и того же читателя.
- Многие подписки на одну и ту же газету.
Какова реальная разница между отношениями один-ко-многим и многие-к-одному?
Между этими терминами существуют концептуальные различия, которые должны помочь вам визуализировать данные, а также возможные различия в сгенерированной схеме, которые должны быть полностью поняты. Главным образом, разница заключается в перспективе.
В отношении " один ко многим" локальная таблица имеет одну строку, которая может быть связана со многими строками в другой таблице. В примере из SQL для начинающих, один Customer может быть связан со многими Order s.
В противоположном отношении " многие к одному" в локальной таблице может быть много строк, связанных с одной строкой в другой таблице. В нашем примере много Order может быть связано с одним Customer. Это концептуальное различие важно для умственного представления.
Кроме того, схема, которая поддерживает отношения, может быть представлена по-разному в таблицах Customer и Order. Например, если у клиента есть столбцы id и name:
id,name
1,Bill Smith
2,Jim Kenshaw
Тогда для Order ассоциироваться с Customer, многие реализации SQL добавить в Order таблицу столбец, который хранит id связанного Customer (в этой схеме customer_id:
id,date,amount,customer_id
10,20160620,12.34,1
11,20160620,7.58,1
12,20160621,158.01,2
В приведенных выше строках данных, если мы посмотрим на столбец идентификатора customer_id, мы увидим, что с Bill Smith (идентификатор клиента № 1) связано 2 заказа: один на 12,34 доллара и один на 7,58 доллара. Jim Kenshaw (идентификатор клиента № 2) только 1 заказ на 158,01 $.
Важно понимать, что обычно отношение "один ко многим" фактически не добавляет никаких столбцов в таблицу, которая является "единым". У Customer нет дополнительных столбцов, которые описывают отношения с Order. Фактически, у Customer также может быть отношение "один ко многим" с таблицами ShippingAddress и SalesCall но при этом в таблицу Customer не добавляются дополнительные столбцы.
Однако для описания отношения "многие к одному" часто в таблицу "многие" добавляется столбец id который является внешним ключом к таблице "один" - в этом случае столбец customer_id добавляется в таблицу "многие". Order Для связанного с Bill Smith заказа № 10 за 12,34 доллара США мы присваиваем столбец customer_id идентификатору Bill Smith 1.
Тем не менее, это также возможно, там будет еще одна таблица, которая описывает Customer и Order отношений, так что никакие дополнительные поля не должны быть добавлены в Order таблице. Вместо добавления поля customer_id в таблицу Order, может существовать таблица Customer_Order которая содержит ключи как для Customer и для Order.
customer_id,order_id
1,10
1,11
2,12
В этом случае "один ко многим" и "многие к одному" являются концептуальными, поскольку между ними нет изменений схемы. Какой механизм зависит от вашей схемы и реализации SQL.
Надеюсь это поможет.
Ответ на ваш первый вопрос: оба схожи,
Ответ на ваш второй вопрос: один-ко-многим → MAN (таблица MAN) может иметь более одной жены (таблица WOMEN) много-к-одному → более одной женщины вышли замуж за одного мужчины.
Теперь, если вы хотите связать это отношение с двумя таблицами MAN и WOMEN, одна строка таблицы MAN может иметь много связей с строками в таблице WOMEN. надеюсь, что это ясно.
Нет никакой разницы. Это просто вопрос языка и предпочтения относительно того, как вы обходите отношения.
"Один-ко-многим" и "Много-к-одному" похожи по множественности, но не по форме (т.е. направленность).
Отображение Ассоциаций между классами сущностей и Отношения между таблицами. Существует две категории отношений:
Две таблицы с одним отношением
В SQL есть только один вид отношений, он называется Ссылка. (Ваш интерфейс может сделать полезные или запутанные вещи [например, в некоторых Ответах], но это другая история.)
В терминах SQL Bar ссылается на Foo
А не наоборот
CREATE TABLE Foo (
Foo CHAR(10) NOT NULL, -- primary key
Name CHAR(30) NOT NULL
CONSTRAINT PK -- constraint name
PRIMARY KEY (Foo) -- pk
)
CREATE TABLE Bar (
Bar CHAR(10) NOT NULL, -- primary key
Foo CHAR(10) NOT NULL, -- foreign key to Foo
Name CHAR(30) NOT NULL
CONSTRAINT PK -- constraint name
PRIMARY KEY (Bar), -- pk
CONSTRAINT Foo_HasMany_Bars -- constraint name
FOREIGN KEY (Foo) -- fk in (this) referencing table
REFERENCES Foo(Foo) -- pk in referenced table
)
Поскольку Foo.Foo является первичным ключом, он уникален, для любого заданного значения Foo существует только одна строка
Bar.Foo является ссылкой, внешним ключом и уникального индекса нет, для любого заданного значения Foo может быть много строкFoo::Bar одно к многимBar::Foo много-к-одному Bar есть только одна строка Foo которую она ссылаетсяКакова реальная разница между отношениями один ко многим и многие к одному?
Есть только одно отношение, поэтому нет никакой разницы. Восприятие (от одного "конца" или другого "конца") или чтение его назад не меняет отношения.
Кардинальность объявляется сначала в модели данных, что означает логическое и физическое (намерение), а затем в реализации (реализованное намерение).
Один к нулю ко многим
В SQL это (выше) это все, что требуется.
Один к одному ко многим
Вам нужна транзакция для принудительного выполнения транзакции в таблице ссылок.
Один к нулю к одному
Вам нужно в Bar:
CONSTRAINT AK -- constraint name
UNIQUE (Foo) -- unique column, which makes it an Alternate Key
Один к одному
Вам нужна транзакция для принудительного выполнения транзакции в таблице ссылок.
Много ко многим
На физическом уровне такого нет (напомним, в SQL существует только один тип отношений).
На ранних логических уровнях во время упражнения по моделированию удобно проводить такую связь. Прежде чем модель приблизится к реализации, ее лучше всего использовать только для того, чтобы существовать. Такое отношение разрешается путем реализации ассоциативной таблицы.
Нет никакой практической разницы. Просто используйте отношения, которые имеют наибольший смысл, учитывая то, как вы видите свою проблему, как показала Devendra.
---Many - one--- Эти 3 ребенка могут иметь одного родителя.
Оба похожи. Это может быть использовано относится к необходимости. Если вы хотите найти детей для определенных родителей, то вы можете пойти с One-To-Many. или же, если вы хотите найти родителей для близнецов, вы можете пойти с Много-к-одному. Точно так же....,
Давайте возьмем первый пример: отношение клиента к еде:
Отношение клиент к еде - один ко многим. Позвольте мне объяснить, почему: во-первых, когда мы говорим об отношении, мы ссылаемся на строки (то есть: на экземпляр сущности, то есть на строку в таблице сущностей, такой как таблица Customer или таблица Meal, и т.д..)
Таким образом, экземпляр Meal, например экземпляр с (Meal_ID = 100), не может быть заказан двумя разными экземплярами Customer (логически говоря, еда не может быть продана и доставлена до Customer_ID = 10, а затем иметь тот же экземпляр с Meal_ID = 100 быть доставлено другому клиенту, т.е. другому экземпляру customer_ID = 11.
Тем не менее, хорошим примером взаимоотношений "многие ко многим" могут быть отношения между студентами и курсами Я объясню ниже:
'Adam', 'Sara' и 'Bob' могут взять один и тот же экземпляр курса у сущности Course (course_ID = 101, course_name = 'Intro to CS'), а также курс 'Intro to CS' и курс 'Algorithms' могут быть взятым тем же клиентским экземпляром 'Адам'.
Суть заключается в следующем: применять здравый смысл в простой логике реальной жизни, прежде чем вы решите задействовать специфику базы данных, если это имеет смысл в реальном мышлении, тогда вы сможете просто реализовать его в коде SQL.
Родительский класс one-to-many содержит n дочерних элементов, поэтому он является отображением коллекции.
многие-к-одному имеет п число детей, содержит одного родителя, поэтому это отображение объекта