Різниця між стосунками один до багатьох і багато хто


117

Яка реальна різниця між відносинами «один до багатьох» та «багато хто до одного»? Це лише зворотно, вид?

Я не можу знайти жодного "хорошого і легкого для розуміння" підручника з цієї теми, окрім цієї: SQL для початківців: Частина 3 - Взаємозв'язки з базою даних


1
Це ідеальне пояснення: en.wikipedia.org/wiki/Many-to-many_(data_model)
RobertPitt

@RobertPitt як стаття «багато-до-багатьох» має відношення до питання? Ви, мабуть, мали на увазі en.wikipedia.org/wiki/One-to-many_(data_model)
TMG

Відповіді:


111

Так, це навпаки. Це залежить від того, на якій стороні відносин присутній суб'єкт господарювання.

Наприклад, якщо один відділ може зайняти декількох працівників, тоді відділ до працівника відносини один до багатьох (1 відділ працює багато співробітників), тоді як відносини працівника до відділу - багато до одного (багато співробітників працюють в одному відділі).

Детальніше про типи відносин:

Взаємозв'язки бази даних - документація IBM DB2


2
Я боюся, що це не створює сцен! ( НЕ Впевнена, АЛЕ ) Я думаю, що порядок являє собою залежність! Чи не так ?? EG, Користувач на роль може бути від 1 до багатьох, але не багато до одного, оскільки не можна отримати посилання користувача, який використовує роль! Чи має це сенс?
Амануїл Нега

Можливо, стосунки з базою даних зараз?
fragorl

29

З цієї сторінки про термінологію баз даних

Більшість відносин між таблицями є одним на багато.

Приклад:

  • Один район може бути місцем проживання багатьох читачів.
  • У одного читача може бути багато підписок.
  • В одній газеті може бути багато підписок.

Співвідношення «Багато хто до одного» те саме, що «багато хто», але з іншого погляду.

  • Багато читачів живуть в одній області.
  • Багато підписок можуть бути одного і того ж читача.
  • Багато підписок на одну і ту ж газету.

20

Яка реальна різниця між відносинами «один до багатьох» та «багато хто до одного»?

Між цими термінами існують концептуальні відмінності, які повинні допомогти вам візуалізувати дані, а також можливі відмінності в створеній схемі, які слід повністю зрозуміти. В основному різниця одна з перспектив.

У співвідношенні " один до багатьох " локальна таблиця має один рядок, який може бути пов'язаний з багатьма рядками в іншій таблиці. У прикладі з SQL для початківців , хтось Customerможе бути пов'язаний з багатьма Orders.

У протилежному співвідношенні « багато в один» місцева таблиця може мати багато рядків, пов’язаних з одним рядком в іншій таблиці. У нашому прикладі багато Orders можуть бути пов'язані з одним Customer. Ця концептуальна різниця важлива для розумового уявлення.

Крім того, схема, яка підтримує взаємозв'язок, може бути представлена ​​по-різному в таблицях Customerта Order. Наприклад, якщо у замовника є стовпці idта name:

id,name
1,Bill Smith
2,Jim Kenshaw

Тоді для Orderасоціації з a 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стовпчик id, ми побачимо, що Bill Smith(ID клієнта №1) з ним пов'язано 2 замовлення: одне за 12,34 долара та одне за 7,58 долара. Jim Kenshaw(ідентифікатор клієнта №2) має лише 1 замовлення на $ 158,01

Важливо усвідомити, що, як правило, відносини «один до багатьох» насправді не додають стовпців до таблиці, яка є «єдиною». У Customerстовпці немає додаткових стовпців, які описують відносини з Order. Насправді , Customerможливо , також має відношення один-ко-многим з ShippingAddressі SalesCallтаблицями і ще не мають ніяких додаткових стовпців додані в Customerтаблицю.

Однак, щоб описати відносини "багато в одному", часто до idтаблиці "багато" додається стовпець, який є зовнішнім ключем до таблиці "один" - у цьому випадку customer_idстовпчик додається до Order. Для асоційованого замовлення №10 за 12,34 доларів США до стовпця Bill Smithми призначаємо id 1.customer_idBill Smith

Тим НЕ менше, це також можливо, там буде ще одна таблиця , яка описує Customerі Orderвідносини, так що ніякі додаткові поля не повинні бути додані в Orderтаблицю. Замість додавання customer_idполя до Orderтаблиці може бути Customer_Orderтаблиця, яка містить ключі і для, Customerі Order.

customer_id,order_id
1,10
1,11
2,12

У цьому випадку один-багато - багато-багато-хто поняття « - це концептуальна концепція, оскільки між ними не існує змін схеми. Який механізм залежить від вашої схеми та реалізації SQL.

Сподіваюся, це допомагає.


3
Загальний випадок називається залежністю включення. Обмеження щодо закордонного ключа є найпоширенішим типом залежності від включення, але не всі залежності від включення включають іноземний ключ. Загальний атрибут або атрибути ("посилання") завжди існують в обох таблицях. На стороні "one" ці атрибути називаються ключовими словами. З боку "багатьох" вони можуть бути іноземним ключем. Терміни "один на багато" або "багато на один" можна застосувати до будь-якої залежності включення, яка включає щонайменше один кандидат-ключ, не обов'язково вказуючи, яка сторона може бути необов'язковою.
nvogel

Цікавий @sqlvogel. У Java javax.persistence.OneToManyінакше, ніж у ManyToOne. Ви хочете сказати, що вони є синонімами або просто це залежить від реалізації? Моя відповідь неправильна?
Сірий

2
Питання стосується реляційних баз даних та SQL, а не Java. Можливо, ти маєш рацію щодо Java.
nvogel

Я використовував це як приклад @sqlvogel. Ви кажете, що "один на багато" і "багато на один" є синонімами?
Сірий

2
Я кажу, що це два способи опису абсолютно однакових відносин, але з різних точок зору. Таким же чином, як "A - це підмножина B" означає те саме, що "B є надмножиною A".
nvogel

4

Різниці немає. Це лише питання мови та уподобань щодо того, у який бік ви заявляєте стосунки.


1
Звичайно, є різниця, як в концептуальній, так і в створеній схемі. Дивіться мою відповідь: stackoverflow.com/a/37954280/179850
Сірий

4
@Gray. Ні, немає. Ваша відповідь не тільки неправильна, вона бентежить початківців (тих, хто задає це питання).
PerformanceDBA

4

Відповідь на ваше перше запитання: обидва схожі,

Відповідь на ваше друге запитання полягає в тому, що: "один до багатьох" -> ЧОЛОВІК (стіл чоловіка) може мати більше однієї дружини (стіл ЖІНОК), багато хто до одного -> більше однієї жінки одружилися з однією людиною.

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


3

Приклад

Дві таблиці з одним відношенням

SQL

У 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 це все, що ми маємо. Це все, що потрібно.

Яка реальна різниця між стосунками один до багатьох і багатьма до одного?

Є лише одне відношення, тому різниці немає. Сприйняття (від одного "кінця" чи іншого "кінця") чи читання його назад, не змінює відношення.

Кардинальність

Кардинальність декларується спочатку в моделі даних, що означає логічне та фізичне (наміри), а потім у реалізації (наміри реалізовані).

Кардинальність


У SQL від нуля до багатьох - це все, що потрібно.

"Один до багатьох"
Вам потрібна транзакція, щоб застосувати її в таблиці "Посилання".

Один до нуля до одного
Вам потрібно Bar:

CONSTRAINT AK    -- constraint name
    UNIQUE (Foo) -- unique column, which makes it an Alternate Key

Один до одного
Вам потрібна транзакція, щоб застосувати цю в таблиці довідки.

Багато до багатьох
На фізичному рівні такого не існує (нагадаємо, у SQL існує лише один тип відношення).

На ранніх логічних рівнях під час вправи моделювання зручно проводити таке відношення. Перш ніж модель наблизиться до впровадження, краще було б поставитись до використання лише речей, які можуть існувати. Таке відношення вирішується шляхом впровадження Асоціативної таблиці.

Багато-до-багатьох вирішено


1
@Martijn Peters. Я можу відредагувати його, щоб відповідати кодексу поведінки. Але ви також зняли (а) пояснення та (б) підтвердили факти насправді. Що я з цим робити?
PerformanceDBA

3
Знайдіть інший спосіб виразити ці речі, не вдаючись до оскарження, виклику імен та відкидання роздумів про чийсь інтелект чи професійну поведінку. Зосередьтеся на техніці, а не на людях, які можуть чи не помиляються.
Martijn Pieters

2

Один до багатьох і багато хто до одного схожі за кратністю, але не з точки зору (тобто спрямованості).

Відображення асоціацій між класами сутностей та таблицями зв'язків . Є дві категорії відносин:

  1. Кратність (термін ER: кардинальність)
    • Стосунки один на один : Приклад Чоловік і Дружина
    • Стосунки один на багато : Приклад матері та дітей
    • Відносини багато до багатьох : Приклад Студент та Предмет
  2. Спрямованість : Не впливає на картографування, але різниться в тому, як ми можемо отримати доступ до даних.
    • Односторонні відносини : поле відносин або властивість, яке відноситься до іншої сутності.
    • Двонаправлені відносини : кожне підприємство має поле відносин або властивість, яке відноситься до іншої сутності.

У реляційній базі даних немає «спрямованості». Кожне відношення має два "кінці": Посилання (таблиця, на яку посилається) і Референтування (таблиця, що робить посилання). SQL / DML дозволяє посилатися на будь-яку таблицю, будь-яким способом… одна сторона… друга сторона… обидві сторони… немає сторін.
PerformanceDBA

0

Практичної різниці немає. Просто використовуйте відносини, які мають найбільш сенс, враховуючи те, як ви бачите свою проблему, як показано Девендра.


Звичайно, є різниця, як в концептуальній, так і в створеній схемі. Дивіться мою відповідь: stackoverflow.com/a/37954280/179850
Сірий

3
@Gray. Ні, немає. Ваша відповідь не тільки неправильна, вона бентежить початківців (тих, хто задає це питання).
PerformanceDBA

0
  • --- один до багатьох --- батьки можуть мати двох і більше дітей.
  • --- Багато до одного --- Ці 3 дитини можуть мати одиноких батьків.

    Обидва схожі. Це може бути використане належить потребі. Якщо ви хочете знайти дітей для конкретних батьків, тоді ви можете піти з одним для багатьох. інакше, хочете знайти батьків для близнюків, ви можете поїхати з багатьма до одного. Так само ....,


-6

батьківський клас one-to-many містить n кількість дитячих дітей, тому це зіставлення колекції.

багато-до-одного має n кількість дитячих дітей, містить один з батьків, тому це відображення об'єкта


ця відповідь хороша, і у вас є додаткова інформація, не розумію, чому за неї було проголосовано, в однонаправленому контексті один до багатьох і багато до одного не забезпечать однакову якість коду залежно від UX: Якщо вам потрібно отримати набір даних, пов'язаних тож один до багатьох мудріший, якщо вам не потрібен оператор вибору, де деяка умова нормальна, тому що набір є на карті, однак якщо користувачеві не потрібно отримувати набір даних і цікавить кожен рядок як унікальний бажаний екземпляр, так що багато хто є мудрішим вибором
Мухаммед Гуссейн Талеб

Це може бути хорошою відповіддю, але вони не однакові: у багатьох до одного є батьківський клас, який містить n кількість дітей, один - до багатьох - багато батьків на одну дитину. У SQL це може не змінити, оскільки відносини "багато на одного" можуть бути всенаправленими, але в таких умовах, як Джанго, це головне питання, оскільки немає відносин "багато хто" та зовнішнього ключа, який має стосунки "Багато хто до одного" працює лише природним чином в одному напрямку, це не можна використовувати навпаки таким же чином.
iFunction
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.