|
|
|
Связь многие ко многим
|
|||
|---|---|---|---|
|
#18+
Мнение г. Дейта, с которым я согласен :-) "Что можно сказать о первичном ключе этой переменной-отношения? Одним из возможных способов его определения может быть комбинация внешних ключей, индетифицирующих участников соответсвующей связи (в случае базовой переменной-отношения SP ими являются атрибуты S# и P#). Это возможно, если данная комбинация имеет уникальное значение для каждого экземпляра данной переменной-отношения (обычно так и бывает, хотя могут быть и обратные случаи) и если разработчик базы данных не возражает против использования составных первичных ключей (на практике это в равной степени возможно и невозможно). В качестве альтернативного варианта первичного ключа можно использовать новый суррогатный атрибут "номер поставки" (подробности приводятся в [13.10], [13.16])." (К. Дж. Дейт "Введение в системы Баз Данных", седьмое изд., [13.5]) С уважением, bw. P.S. Knowledge is of two kinds. We know a subject ourselves, or we know where we can find information upon it. --Samuel Johnson ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2007, 21:48 |
|
||
|
Связь многие ко многим
|
|||
|---|---|---|---|
|
#18+
BW mcureenabВ реляционной БД нет связей, есть таблицы и ограничения ссылочной целостности. В процессе реижиниринга схемы БД в ER модель в зависимости от наших целей, мы можем обозвать одни таблицы связями, другие сущностями. Например, связь двух сущностей может быть реализована целой цепочкой таблиц, но если эти промежуточные таблицы в данный момент нас не интересуют, в ER модели мы можем изобразить только связь этих сущностей, опустив детали реализации. Фактически связи отношений (таблиц и представлений) реляционной БД возникают только в процессе выполнения SQL запроса. Как напишем условия соединения таблиц в запросе, такая связь и получиться. Она может быть отражена в ER модели, но может и отсутствовать. Более того, она может быть совершенно бессмысленной, с точки зрения бизнес логики, как например соединение поставщика и товара по № телефона и артикулу изделия. Иногда связь может иметь атрибуты, которых нет в БД, например, нужно получить исторические сведения о сотруднике и его зарплате на определённую дату в прошлом. Без этой даты связь будет 1:*, с датой, 1:1. Во-первых, обязательно нужно делать ссыдку, что речь идет о реляционной модели. Во-вторых, не нужно путать физическую и логическую модель данных. Физическая модель может отличаться от одной СУБД к другой на одной логической моделе БД. С уважением, bw. 1. Будем считать, что Вы её уже сделали. 2. Я имел в виду именно логическую модель данных, поскольку на физической модели верёвки между таблицами моделируют ограничения ссылочной целостности, а не логические связи, хотя выглядят почти также и во многих случаях однозначно трассируются на связи в логической модели. Когда смысл ясен из контекста их часто тоже называют связями. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2007, 22:03 |
|
||
|
Связь многие ко многим
|
|||
|---|---|---|---|
|
#18+
BWМнение г. Дейта, с которым я согласен :-) А куда деваться?.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2007, 22:05 |
|
||
|
Связь многие ко многим
|
|||
|---|---|---|---|
|
#18+
softwarer UrsegoКстати, пример того, когда в связывающей таблице НЕОБХОДИМО разрешить дублирование комбинаций внешних ключей, так и не был преведен. Ну это тривиально. Допустим, слева - клиенты, справа - банки, развязка - банковские счета.Неправильно. Этот пример - просто таблица банковских счетов. Именно в силу того, что комбинация "человек+банк" не является ключём-кандидатом (candidate key), таблица не является таблицей связи many-to-many между таблицей людей и таблицей банков, это ключевой момент! Да, в таблице имеются поинтеры (foreign keys) на эти две таблицы, ну и что? Могут иметься поинтеры на десятки каких угодно другх таблиц (например, на таблицу адресов, конкретно - адрес человека, как результат денормализации с целью уменьшить время запроса), так по-Вашему выходит, что мы можем кучу других связей many-to-many насчитать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2007, 00:12 |
|
||
|
Связь многие ко многим
|
|||
|---|---|---|---|
|
#18+
Bely softwarerЧтобы показать это - пример, обратный Вашему. Возьмите любую пару таблиц, как Вы считаете, связанных многие-ко-многим, и добавьте в таблицу связи поля date_from, date_to. По-вашему, таблица теперь перестала быть связью многие-ко-многим?Здесь, пожалуй, соглашусь. Эта связь всеравно останется Много-ко-Многим....но не потому, что поля date_from и date_to не выглядят столь важными, а потому, что комбинация внешних ключей уникальна (UNIQUE или PRIMARY KEY - не важно что из них) и позволяет построить из двух связанных физических таблиц одну виртуальную двухмерную таблицу. Двухмерную - это значит, что пусть она не нормализована по всем полям, но в ней нет ни одной дублирующейся записи. Если же, как тут некоторые утверждают, построить такую таблицу по мнимой связи many-to-many (с разрешённым дублированием комбинаций), то развёртывание двух связанных физических таблиц даёт виртуальную N-мерную таблицу (N равно максимальному числу повторов комбинации внешних ключей). А в реляционной теории отношение (таблица) двумерно (имеет поля в одном измерении и записи во втором) - примем это за аксиому. Утверждение о том, что неуникальная комбинация внешних ключей реализует связь "many-to-many", опровергнуто путём прихода к противоречию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2007, 00:28 |
|
||
|
Связь многие ко многим
|
|||
|---|---|---|---|
|
#18+
BelyЕсли добавлять атрибуты к связи, то это получится уже не связь, а новая сущность.Пардон, мсье, но связь между таблицами - это частный случай сущности (наряду, например, с предметами, которые можно пощупать, и событиями, например, приходом работника на работу). Говоря научным языком: раз какой-то фигне посвящена таблица, то эта фигня - сущность (entity). Даже связь таблиц! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2007, 00:34 |
|
||
|
Связь многие ко многим
|
|||
|---|---|---|---|
|
#18+
UrsegoИменно в силу того, что Вы дошли до тавтологии. Сначала Вы сказали "примера никто не привел", а как получили пример, придумали левое определение, суть которого в том, что "такого вообще никогда не может быть". Ursegoтак по-Вашему выходит, что мы можем кучу других связей many-to-many насчитать? Я уже написал выше: трактовка таблицы как сущности или как связи зависит исключительно от восприятия проектировщика. Скажем, Вы делаете учетку - и для Вас банковские счета являются важнейшим реквизитом, а рядом крутят OLAP, для которого та же самая таблица - всего лишь малоинтересная развязка между двумя измерениями "Банки" и "Клиенты". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2007, 00:48 |
|
||
|
Связь многие ко многим
|
|||
|---|---|---|---|
|
#18+
Ursego...но не потому, что поля date_from и date_to не выглядят столь важными, а потому, что комбинация внешних ключей уникальна Плюньте в лицо тому, кто Вам сказал такую глупость... и не придумывайте дополнительных условий, не фигурирующих в постановке задачи. Поля date_from/date_to чаще всего вводят именно тогда, когда прорезается "неуникальность комбинации внешних ключей" - скажем, нужно отразить тот факт, что сотрудник Путин сначала работал над проектом "Президент России", потом перестал работать, потом снова начал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2007, 00:55 |
|
||
|
Связь многие ко многим
|
|||
|---|---|---|---|
|
#18+
в линковочной таблице не может быть дубликатов. В примере с банками в ней будет дополнительное поле, обеспечивающее уникальность - допустим,номер счета. :) если ключ удалить, то это будет корзина(мусорка). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2007, 01:15 |
|
||
|
Связь многие ко многим
|
|||
|---|---|---|---|
|
#18+
iscrafmв линковочной таблице не может быть дубликатов. В любой таблице не может быть дубликатов. iscrafmВ примере с банками в ней будет дополнительное поле, обеспечивающее уникальность - допустим,номер счета. Правильно. Вот только не понял, к чему этот комментарий; такое впечатление, что Вам стоит перечитать то, на что Вы отвечаете. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2007, 03:24 |
|
||
|
Связь многие ко многим
|
|||
|---|---|---|---|
|
#18+
softwarer iscrafmв линковочной таблице не может быть дубликатов. В любой таблице не может быть дубликатов. поразили softwarer iscrafmВ примере с банками в ней будет дополнительное поле, обеспечивающее уникальность - допустим,номер счета. Правильно. Вот только не понял, к чему этот комментарий; такое впечатление, что Вам стоит перечитать то, на что Вы отвечаете. И Вам того же. Перечитайте, особенно вопрос автора и свои изъяснения на этот счет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2007, 10:37 |
|
||
|
Связь многие ко многим
|
|||
|---|---|---|---|
|
#18+
UrsegoА в реляционной теории отношение (таблица) двумерно (имеет поля в одном измерении и записи во втором) - примем это за аксиому. Утверждение о том, что неуникальная комбинация внешних ключей реализует связь "many-to-many", опровергнуто путём прихода к противоречию.Круто! Придумать аксиому и свести к ней - это что-то новое в мат.логике iscrafmв линковочной таблице не может быть дубликатов. В примере с банками в ней будет дополнительное поле, обеспечивающее уникальность - допустим,номер счета. :) если ключ удалить, то это будет корзина(мусорка).А если ключ оставить, но сделать его суррогатным? Мусорки не будет, а дубликаты останутся. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2007, 11:07 |
|
||
|
Связь многие ко многим
|
|||
|---|---|---|---|
|
#18+
iscrafm softwarer iscrafmв линковочной таблице не может быть дубликатов. В любой таблице не может быть дубликатов. поразили Нет, всего лишь намекнул, что стоило бы следить за своими словами. iscrafmИ Вам того же. Перечитайте, особенно вопрос автора и свои изъяснения на этот счет. Не беспокойтесь, я как правило перечитываю до того, как ссылаться на ранее сказанное. Вы же, судя по всему, не перечитываете вообще (ну или считаете "номер счета" внешним ключом, но это пожалуй слишком уж идиотская версия, чтобы всерьез на нее рассчитывать). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2007, 11:32 |
|
||
|
Связь многие ко многим
|
|||
|---|---|---|---|
|
#18+
softwarer, Вы в голове у себя наведите порядок сначала. Мой ответ, во-первых , был не Вам. Во-вторых прочитайте что спрашивает автор. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2007, 12:06 |
|
||
|
Связь многие ко многим
|
|||
|---|---|---|---|
|
#18+
iscrafmsoftwarer, Вы в голове у себя наведите порядок сначала. Готов и рад выслушать конкретные конструктивные предложения. iscrafmМой ответ, во-первых , был не Вам. Тогда во-вторых будьте добры явно указывать, кому и на что отвечаете. В ситуации, когда Вы пишете некий текст без обращений и цитат - создается впечатление, что он отвечает на пост непосредственно перед собой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2007, 13:35 |
|
||
|
Связь многие ко многим
|
|||
|---|---|---|---|
|
#18+
softwarer BelyЕсли добавлять атрибуты к связи, то это получится уже не связь, а новая сущность. Между этими понятиями нет принципиальной разницы. Как минимум, на уровне словаря данных: Если из множества связей вычесть множество сущностей, останется ли что-нибудь? Правильно, останутся ограничения целостности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.07.2007, 17:11 |
|
||
|
Связь многие ко многим
|
|||
|---|---|---|---|
|
#18+
Мне кажется, понятие связей many-to-many, можно объяснить на следующей модели. Представим, что у нас есть таблица ЛЮДИ, с первичным ключом id. 1. Для хранения информации, кто из них кого знает, создаём таблицу ЗНАКОМСТВА, с полями id1, id2. Это первый пример many-to-many, причём на каждую пару может быть от нуля до двух записей. В этом случае достаточно построить уникальный индекс по (id1, id2) 2. Другая задача. Теперь нас интересует, кто с кем дружит. Создаём таблицу ДРУЗьЯ, с полями id1, id2. Это второй пример many-to-many, причём на каждую пару может быть от нуля до одной записей. В этом случае мы должны построить уникальный индекс по (id1, id2) и проверять при добавлении новой записи (id1, id2) есть ли уже запись (id2, id1). Вторую проверку скорее всего нужно выполнять в триггере. 3. Расширяем задачу номер 2, теперь нас интересует сохранить несколько типов двусторонних связей, например "друзья", "сослуживцы", "любовники" и т.д. Отложим не совсем реляционные варианты типа битовых масок . Если количество типов заранее неизвестно, то мы должны создать домен "тип связи". Это можно обеспечить разными способами, например, с помощью CHECK CONSTRAINT или создания таблицы ТИПЫ_СВЯЗЕЙ. Создаём таблицу СВЯЗИ, с полями id1, id2, type. Это третий пример many-to-many, причём на каждую пару может быть от нуля до одной записей одного типа. В этом случае мы должны построить уникальный индекс по (id1, id2, type) и проверять при добавлении новой записи (id1, id2, type) есть ли уже запись (id2, id1, type). Вторую проверку скорее всего нужно выполнять в триггере. 4. Усложним задачу номер 3. Теперь нас интересует даты начала и конца связи. Добавляем в таблицу СВЯЗИ поля started, ended. Это четвёртый пример many-to-many, причём на каждую пару может быть от нуля до одной записей одного типа с заданным диапазоном дат. Диапазоны для тройки (id1, id2, type) не должны пересекаются. В этой ситуации индекс нам не поможет вообще и все проверки мы вынуждены будем осуществлять в триггере. Можно продолжать дальше, но, на мой взгляд, основные типы many-to-many описаны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2007, 11:36 |
|
||
|
Связь многие ко многим
|
|||
|---|---|---|---|
|
#18+
drev Представим, что у нас есть таблица ЛЮДИ, с первичным ключом id. Можно продолжать дальше, но, на мой взгляд, основные типы many-to-many описаны. А представим, что есть сущности от с1 до с99 и все они связаны между собой сущностью с100. Вывод: связи n:m всегда есть самостоятельные сущности со своим уникальным id. А связи 1:n - это просто ссылки между сущностями. В примере сущность с100 ссылается на все (или не все) сущности с1-с99 по типу n:1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2007, 12:11 |
|
||
|
Связь многие ко многим
|
|||
|---|---|---|---|
|
#18+
модА связи 1:n - это просто ссылки между сущностями. Не обязательно. Связь 1:n - вполне может быть самостоятельной таблицей, хотя ее редко так оформляют, предпочитая включить атрибуты связи в одну из связываемых таблиц. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2007, 13:28 |
|
||
|
Связь многие ко многим
|
|||
|---|---|---|---|
|
#18+
softwarerСвязь 1:n - вполне может быть самостоятельной таблицей, хотя ее редко так оформляют, предпочитая включить атрибуты связи в одну из связываемых таблиц. Я имел ввиду связь между сущностями. Связи между таблицами м.б. более разнообразны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2007, 14:13 |
|
||
|
Связь многие ко многим
|
|||
|---|---|---|---|
|
#18+
мод drev Представим, что у нас есть таблица ЛЮДИ, с первичным ключом id. Можно продолжать дальше, но, на мой взгляд, основные типы many-to-many описаны. А представим, что есть сущности от с1 до с99 и все они связаны между собой сущностью с100. Вывод: связи n:m всегда есть самостоятельные сущности со своим уникальным id. А связи 1:n - это просто ссылки между сущностями. В примере сущность с100 ссылается на все (или не все) сущности с1-с99 по типу n:1. 1. Я не совсем понял как Ваши высказывания связанны с цитатой. 2. Вывод о обязательном наличии уникального id не следует из Вашего утверждения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2007, 18:51 |
|
||
|
Связь многие ко многим
|
|||
|---|---|---|---|
|
#18+
модЯ имел ввиду связь между сущностями. Связи между таблицами м.б. более разнообразны. Я тоже. На концептуальном уровне у нас есть понятия "сущность" и "связь", причем последняя - вовсе не обязательно "просто ссылка". На физическом уровне у нас есть два варианта реализации связи: "простой ссылкой" (поле в таблице + внешний ключ) либо дополнительной таблицей с внешними ключами. Заранее прошу прощения, если применяю неудачную терминологию - давно не открывал "концептуальных" трудов, мог забыть адекватные слова. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2007, 20:02 |
|
||
|
Связь многие ко многим
|
|||
|---|---|---|---|
|
#18+
softwarerПоля date_from/date_to чаще всего вводят именно тогда, когда прорезается "неуникальность комбинации внешних ключей" - скажем, нужно отразить тот факт, что сотрудник Путин сначала работал над проектом "Президент России", потом перестал работать, потом снова начал.ОК, в таком случае не два, как было в условии задачи, а три поля являются составным первичным ключом этой таблицы (или же на них висит юник констрейнт + имеется суррогатный ключ из одного дополнительного поля-нумератора, это не меняет дела). Это прекрасная таблица, не имею ничего против неё, но вот незадача - она НЕ является таблицей связи many-to-many между таблицами "Сотрудники" и "Проекты" ! Как известно, каждая таблица имеет своим назначением хранить сущности, и сущность описанной таблицы - фрагмент времени, когда сотрудник работал над проектом, а вовсе не факт, что сотрудник имеет к проекту отношение (т.е. хоть раз работал над ним - вот тогда выло бы many-to-many в строгом понимании: один сотрудник может работать над многими проектами; над одним проектом может работать много сотрудников). Поле времени добавляет новое измерение, меняя сущность - это ключевой момент! С ним сущность более не является связью many-to-many, а обретает абсолютно другой смысл, а именно - смысл каденции (вместо старого смысла - связи между сотрудниками и проектами). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2007, 01:49 |
|
||
|
Связь многие ко многим
|
|||
|---|---|---|---|
|
#18+
softwarerНа концептуальном уровне у нас есть понятия "сущность" и "связь", причем последняя - вовсе не обязательно "просто ссылка". ПМСМ связь - это всегда "просто ссылка" одной сущности на другую, т.е n:1. Такой подход позволяет всегда однозначно отделить сущности от связей. зы физический уровень пока не очень интересен ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2007, 10:00 |
|
||
|
|
start [/forum/topic.php?fid=32&msg=34653411&tid=1540721]: |
0ms |
get settings: |
10ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
67ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
57ms |
get tp. blocked users: |
1ms |
| others: | 14ms |
| total: | 179ms |
| 0 / 0 |
Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...
