Моделиране на множество връзки много към много между едни и същи обекти в релационна база данни

От теб зависи. Можете да дефинирате „приятелство“ като различно от „романтична връзка“ и затова ви трябват две свързващи маси. Или можете да дефинирате „романтична обвързаност“ като специален случай на „приятелство“ и така се нуждаете от една маса. Бих се насочил към последното като по-просто и по-малко объркващо. (Ами ако едни и същи двама души са посочени като приятели, а също и като любовници?)

„Дължи пари на“ обаче е различно. Ако A е приятел с B, тогава B е приятел с A. Но ако A дължи пари на B, е невярно да се каже, че B дължи пари на A. Така че не само дефинирате различен вид връзка, но позиционирането на кое поле съдържа препратката към A и кое съдържа препратката към B става значимо. За това тогава би било най-добре да имате отделна съединителна маса.

Таблиците TL;DR представляват приложение/бизнес отношения/асоциации. Както в модела Entity-Relationship. Т.е. отношения. Както в релационния модел. Всеки път, когато се интересуваме от отделна връзка, разглеждаме нова таблица („свързване“/„асоциация“). Нормализация ни казва кога и как да разложим връзка/таблица на други или да комбинираме някои в една.

Ние идентифицираме връзка чрез някакъв предикат, т.е. шаблон на изявление, който ред превръща в предложение, т.е. изявление, което казва нещо, което ни интересува за нашето приложение. Редовете, които правят вярно изявление от предиката на таблицата, отиват в таблицата.

Employee(e, n, ...) -- employee identified by E is named N and ...
Manages(e, m) -- employee M manages employee E

Не можете да знаете какво казва една таблица за приложението или да я настроите според приложението, без да знаете неговия предикат! Когато заявявате "кардиналността" на "връзка", първо трябва да определите за каква връзка/асоциация/предикат говорите.

(За съжаление „връзката“ се използва от много така наречени ER методи и продукти за означаване на чужд ключ на таблица.)

Можем да комбинираме множество таблици в една или да заменим таблица с други, когато можем да реконструираме оригинала(ите) от новия. Тук можем да комбинираме таблиците по-горе в

-- employee identified by E is named N and ... AND employee M manages employee E
EmployeeM(e, n, ..., m)

Това се случва винаги да бъде JOIN на Employee & Manages, защото предикатът на JOIN е AND на предикатите на неговите аргументи. Но тъй като E е набор от общи колони и е уникален в една от тях, можем да реконструираме оригиналите чрез проекции на новото.

Това би било разумен дизайн, когато един служител може да има само точно един мениджър. Но ако един служител може да има един или повече мениджъри, тогава тази таблица, въпреки че все още ще съдържа редовете, които отговарят на този предикат и позволява реконструиране на оригиналите, ще показва аномалии при актуализиране, така че бихме предпочели оригиналите. И ако един служител може да има нула или един или нула или повече мениджъри, тогава пак можем да използваме тази таблица, но не само тази таблица, защото не може да ни каже за служители без мениджър(и). (Което прави оригиналният дизайн.) Ще ни трябва и таблица като Employee, но с различен предикат employee identified by E is named N and ... AND E has no manager. Или вместо тези две таблици можем да използваме само таблица < em>като EmployeeM, но това позволява нули чрез различен предикат employee identified by E is named N and ... AND ( employee M manages employee E OR M IS NULL AND E has no manager ).

Прочетете за оригиналния модел/метод на Chen ER, където има типове обекти, икони и таблици и типове отношения, икони и таблици. Всеки тип връзка е ясно диаграмиран като диамант. Всеки ред ясно представя участието на тип обект (възможно асоциативен тип обект) в тип връзка, т.е. ясно представя FK между таблиците. Докато много от така наречените ER методи дори не правят разграничение между обекти и взаимоотношения. (Не е необходимо това да е добро или лошо, но техните презентации обикновено не обясняват как да се моделира правилно.)

Релационният модел не се интересува от обекти и връзки сами по себе си. Неговите таблици са просто релации на стойности. ER и така наречените ER методи правят ненужно и ограничаващо произволно разграничение между обекти и връзки. Естествено, таблицата все още може да каже какво прави за приложението, както в ER модел, тъй като подредовете от стойности могат да идентифицират обекти. Вижте този отговор.

Нормализирането ви казва кога и как да разложите предиката/таблицата на връзката на по-малки (които са нейни проекции, които AND/JOIN обратно към нея), и ви казва кога и как да комбинирате множество релации ' предикати/таблици в едно (чрез AND/JOIN, използвайки проекция за реконструиране).

PS Няма нищо лошо в дублираните стойности сами по себе си. Това, което може да бъде проблем, е когато множество редове предполагат едно и също нещо за приложението, като са в или не в таблици според вашия избор на предикати. Не всички подобни излишъци са погрешни; просто неконтролираното излишък е погрешно. Като цяло искаме да имаме дизайни, които са възможно най-много в 5NF. (Т.е. намаляване на аномалиите при актуализиране, сложността на предикатите и ограниченията.)