_модalexeyvgИнтересно, почему так упорно пытаются хранить списки ИД в тексте через разделители?
Это древняя традиция. На ней построена М-технология. Поиск идет полным перебором.
Серьезное заблуждение...
Если автор темы, действительно, говорит о связи М:М, то напомню, что связь не имеет свойств, и для ее поддержки в СУБД, конечно, не требуется создавать третью "таблицу" (то есть, третий тип сущности). И, конечно, идентификаторы не хранятся "в тексте через разделители" - это просто не возможно, в общем случае, и не профессионально))
Так что эту тему необходимо перенести в раздел "Проектирование реляционных БД". Когда же его создадут?))
А лучше всего - вернуть в раздел MS SQL.

П-ЛВсе остальные, идущие не в ногу (кроме одного Бретятины, идущего в ногу) именно так этот топик и понимают.
Именно, как проектирование реляционной БД, а не проектирование БД))

_модБредятинаСерьезное заблуждение...
Матчасть учите
Глупость, которая легко выявится в случае обсуждения по существу. Именно, поэтому в критические моменты, так сказать, Вы сразу сворачиваете обсуждение по существу до бессмысленных реплик))

vadiminfoП-ЛВсе остальные, идущие не в ногу (кроме одного Бретятины, идущего в ногу) именно так этот топик и понимают.
А идущий в ногу напоминает какую-то ахинеию, что якобы "свзязь не имеет свойств", как-будто так оно и есть, но все просто забыли. Т.е. типа развести хочет.
Типичная глупость и хамство - это все, что Вы можете сказать, просто не понимая что такое связь)) Я же объяснил:
14020991
Связь, действительно, принципиально не может иметь свойств. Это хорошо известный факт в теории БД, а не мое мнение. Обратите еще раз внимание на то, что наличие или отсутствие свойств никак не связано с мощностью связи, если речь идет именно о связи. Связь 1:М (М:1) не имеет свойств (в реляционной интерпретации), а связь М:М почему-то имеет)) Дейт поэтому и вынужден был ввести прилагательное "истинная". Истинная связь и не истинная связь)) Однако, честно порекомендовал создавать отдельное отношение при любой мощности "связи"))
vadiminfoУвязал третью таблицу с типом сущности, тада как она у всех нормальных челов она тип связи.
В реляционной БД. Для связей любой мощности, как справедливо рекомендует Дейт.
vadiminfoПриплел какие-то левые не реляционные СУБД, но в которых таблицы, иначе бы там не надо было создавать не только третью, но и первые две таблицы.
Уже лучше)) Как бы боретесь за чистоту терминологии. Молодец. Обычная ситуация - понимаете, что не правы, и ничего не остается, как хамить))
vadiminfoИ со свойсвенной иму скромностью юзает термин "проектирование БД", хотя вроде никакого авторитета как проектировщик никогда не имел.
Рекомендую убрать "вроде", а то как-то неуверенно получается))
vadiminfoБольше зарекомендовал себя как специалист по мешочкам.
Лабораторную усвоили, значит. Молодец.

_модБредятинаГлупость, которая легко выявится в случае обсуждения по существу.
Кто бы сомневался :)
Надеюсь никто, и традиционная для этого форума хитрость Вам не поможет. Вот мое сообщение, которое Вы элегантно подтвердили:
"Глупость, которая легко выявится в случае обсуждения по существу. Именно, поэтому в критические моменты, так сказать, Вы сразу сворачиваете обсуждение по существу до бессмысленных реплик))"
На него Вы написали "Кто бы сомневался". Молодец.

vadiminfoПриплел какие-то левые не реляционные СУБД, но в которых таблицы, иначе бы там не надо было создавать не только третью, но и первые две таблицы.
Просто прямой подлог. Вот мой текст:
"Если автор темы, действительно, говорит о связи М:М, то напомню, что связь не имеет свойств, и для ее поддержки в СУБД, конечно, не требуется создавать третью "таблицу" (то есть, третий тип сущности)"
Не таблица, а "таблица"))

vadiminfoБредятина Я же объяснил:
14020991

Смешно.
По существу нечего сказать. Остается хамить.
vadiminfoБредятинаСвязь, действительно, принципиально не может иметь свойств.
Нашли дураков отказываться от важной информации.
Подлог. Связь не может иметь свойств. Это факт. И он не заставляет отказываться ни от какой информации, а заставляет называть вещи своими именами. Вы опять нагло выбросили из моего пояснения неудобные слова))
vadiminfoБредятинаЭто хорошо известный факт в теории БД, а не мое мнение.
Ахинея
Именно поэтому у Вас и нет знаний в области БД. Ведь факты для Вас - ахинея)) И опять нечего сказать по существу))
vadiminfoБредятина Связь 1:М (М:1) не имеет свойств (в реляционной интерпретации), ...
Инфа о том что что она связывает, уже свойства.
То, что значение внешнего ключа рассматривается как свойство сущности-владельца - это неизбежный недостаток реляцтонной технологии, противоречащий основам теории БД. И опять банальный подлог. Так как это свойство сущности-владельца, а вовсе не связи))
vadiminfoБредятина Однако, честно порекомендовал создавать отдельное отношение при любой мощности "связи"))
...Намек для Вас, что в "в реляционной интерпретации" что и 1:М много разных свойств у связи в общем случае.
Ложь. Любой может прочитать стр. 539 восьмого издания, чтобы понять аргумент Дейта: "... по крайней мере, из-за того, что достаточно часто существует возможность того, что они будут развиваться и со временем преобразовываться в связи типа "многие ко многим""))
У связей нет и не может быть никаких свойств. Это факт.
vadiminfoБредятинаОбычная ситуация - понимаете, что не правы, ...

Мы добились, на сколько помню, с Вами понимания только в том, что до Вас ниче не доходит.
Нет такого определения "ключа" у Дейта. Он пишет про "клей", но таких слов точно нет.
vadiminfoБредятина Рекомендую убрать "вроде", а то как-то неуверенно получается))...
Зато, скорее всего, правда, потому вынужден не последовать рекомендации.
"Вроде" - правда??? Оригинал))

_модБредятинаНадеюсь никто
Правильно, молодец
Надеюсь никто, и традиционная для этого форума хитрость Вам не поможет. Вот мое сообщение, которое Вы элегантно подтвердили:
"Глупость, которая легко выявится в случае обсуждения по существу. Именно, поэтому в критические моменты, так сказать, Вы сразу сворачиваете обсуждение по существу до бессмысленных реплик))"
На него Вы написали "Кто бы сомневался". Молодец.

vadiminfoБредятина Связь не может иметь свойств.

Дума такого закона пока, вроде, еще не принимала.
Как и реляционную теорию. Зачем Вы пишите глупости?))
То, что у связи между сущностями нет никаких свойств - это одно из фундаментальных положений теории БД))
vadiminfoБредятинаТо, что значение внешнего ключа рассматривается как свойство сущности-владельца - это неизбежный недостаток реляционной технологии, противоречащий основам теории БД.
.
У связи есть свойства даже если ОЦ внешний ключ отсутсвует "сущности-владельца".
Смешно)) Какие свойства есть у связи между сущностями М:1, независимо от того присутствует "ОЦ внешний ключ", моделирующее связь в РМД, или отсутствует (то есть, связь даже не моделируется)))?
vadiminfoА свойство связи как мимум, то что с чем она связывает (какие сущностей). Хотя она может иметь и дополнительные свойства.
Как интересно)) Начались рассуждения о непонятом Вами предмете. Первое предположение: свойствами связи являются связываемые сущности. Итак, Вы согласились с Дейтом, что для моделирования связи между сущностями любой мощности нужно создать отдельное отношение с двумя "внешними ключами". Поскольку внешний ключ при связи М:1 - это свойство сущности-владельца, а вовсе не связи, то и у той сущности (именно сущности, если предполагается наличие собственных свойств), которая моделируется этим третьим отношением, естественно ( чужими - связываемых сущностей) свойствами являются два внешних ключа. Кодд пытался формально поддерживать отношения типа связи (см. ранние отчеты IBM), но из этого ничего не получилось)) С алгеброй не срослось)) Так что, в РБД нет никаких отношений типа связи или отношений типа сущности. Именно поэтому и возникает необходимость в архитектуре подробно нами рассмотренной:
13577413
vadiminfoНапример, Связь "Пониманиет" между Чалом и Дейтом (свойстово кого с кем позволяет отличить от других связей Челов с Дейтом), имеет еще свойство "Качество" со значением "Не удолетворительное" када речь идет о Чале. В то время как для Челов с образованем по БД оно как правлило "Удовлетворительное". А Вы говорите: свойств нет.
У связей, конечно, нет свойств. Это фундаментальное положение теории БД, неизвестное, как Вам, так и Дейту. Но, в этом нет ничего страшного. Было бы желание учиться))
Понимание - это процесс, участниками которого являются сущности (в Вашем примере сущностью является Человек и речь идет о взаимопонимании). Процесс, как и его частный случай - событие (процесс с равными моментами времени - начала и окончания) - это, конечно же объект. Вот почему я использовал именно термин "объект", а не "сущность" - потому что есть сущности, а есть процессы. Другой вопрос нужно ли в будущей модели делить объекты на сущности и процессы (события) и поддерживать это на уровне СУБД. Поэтому для простоты ограничиваемся понятием "сущность". Разумеется, это не связь. Так же, разумеется, в Вашем примере есть и две связи, а не только))

Человек {...}
Понимание {Качество}
Понимание <-- Кто понимает/Который понимает -- Человек
Понимание <-- Кого понимает/Которого понимает -- Человек

И если бы Вы были по-внимательнее, Вы бы поняли, что по Вашей с Дейтом логике для этих связей нужно создать отдельные отношения)) И так до бесконечности, потому что нет в РМД никаких отношений типа связи - они остаются в сознании разработчика))

vadiminfoБредятина
Ложь. Любой может прочитать стр. 539 восьмого издания, чтобы понять аргумент Дейта: "... по крайней мере, из-за того, что достаточно часто существует возможность того, что они будут развиваться и со временем преобразовываться в связи типа "многие ко многим""))
.
Правда. Если до Вас не дошло, что у связи 1:М в РМД нет запретов на много свойств, то цитируемый Вами ни к месту фрагмент, демонстриует как их описать. Вынесли в отельную таблицу и описали много свойств. Т.е. в "в реляционной интерпретации" у 1:М может быть много свойсв у связи. И готово.
Отлично. Главное, что до Вас дошло)) Выяснили, что упустили при моделировании сущность, и смоделировали ее дополнительной таблицей))
vadiminfoБредятина
У связей нет и не может быть никаких свойств. Это факт.
.
Вам не нужны свойства у связей, не пользуйтесь. А нормальным челам от них отказываться ради Вас ни к чему.
Нормальные челы - это те, кто не понимает про сущности и связи. Хорошо))
[quot vadiminfo]Бредятина
Нет такого ... у Дейта. ...
Зато у нас про Вас такое есть.
Нет такого определения "ключа" у Дейта. Он пишет про "клей", но таких слов точно нет.

vadiminfoБредятинаэто одно из фундаментальных положений теории БД))
.
Если тЭоретик типа ЧАЛа. А обычно свойства у связей есть в Реале, а потому и моделируется в БД,
Именно в реале их и нет:
14020991
И не может быть. И я не сомневаюсь, что Вы это понимаете. И даже понимаю, как сложно в этом признаться))
vadiminfoБредятинаСмешно)) Какие свойства есть у связи между сущностями М:1, независимо от того присутствует "ОЦ внешний ключ", моделирующее связь в РМД, или отсутствует (то есть, связь даже не моделируется)))?
. Если до Вас дойдет текст Дейта, то те свойства что добавите в "Третью таблицу" и есть свойства связи. Тугодум Вы наш.
Ложь. Любой может прочитать стр. 539 восьмого издания, чтобы понять аргумент Дейта: "... по крайней мере, из-за того, что достаточно часто существует возможность того, что они будут развиваться и со временем преобразовываться в связи типа "многие ко многим""))
У связей нет и не может быть никаких свойств. Это факт.
Именно поэтому Вы и не состоянии привести ни одного примера. Но, поскольку помимо традиционного хамства и подлога, Вы, все-таки, и по существу что-то говорите, разумеется, я Вам помогу. Итак, 1:М. ТТН - Операция отгрузки. Создаем третью таблицу с двумя внешними ключами. Очевидно, что для поддержки 1:М на второй ключ (операция отгрузки) необходимо наложить ОЦ уникальности. Тогда, в таблице операций:
1
2
3
4
5
6
И в третьей таблице
1 1
1 2
1 3
2 4
2 5
3 6
То есть, те же самые (уникальные) операции. Поскольку только Вам, как разработчику, известно, что это якобы связь (попутно замечу, что следуя такой логике и сама операция - это связь))) - между товаром и накладной), возникает вопрос - зачем же Вы создали эту избыточность? Какая Вам разница где хранить эти (пока не известные) характеристики связи операции с накладной? В таблице, где хранятся характеристики операции или в этой третьей таблице? Вы можете сказать, чтобы семантически верно отразить самому себе факт, что это (пока неизвестно что) именно характеристики связи. Это логично, при условии использования архитектуры "модель верхнего уровня+маппинг+РМД"
13577413
Но, давайте придумаем какие-нибудь характеристики. Может быть Номер страницы (на которой в ТТН находится информация об этой операции?)) Но, страница - это сущность. Если страница - не сущность, значит и ТТН (состоящая из страниц) - не сущность))
Не получилось... С номером записи - аналогично...
Давайте, подключайтесь))
vadiminfoБредятина неизвестное,... так и Дейту
.
С Вашей сообразительностью только Дейта жизни учить.
Никак не могу взять на себя ответственность за то, что кому-либо неизвестны какие-либо положения теории БД.
vadiminfoБредятинаПонимание - это процесс,
.
Для особо одаренных специально написал "Понимает", а не "Понимание". Связь.: Чал Понимает Дейта.
Свойство этой связи: Не удовлетворительно. Ну такая модель.
Я и поясняю, для особо одаренных, что это процесс)) Не помогает использовать для именования таблицы глагол. Так же, как не поможет назвать ТТН "Отгружаем для" (ведь это "связь" операций отгрузки с клиентом), а Операцию отгрузки "Содержит" (ведь это "связь" ТТН с товаром). В частности, и потому, что ТТН "связана" еще и с Грузополучателем (это не обязательно клиент), и с перевозчиком, и с какими-то другими сущностями. Дейт должен был бы назвать ТТН n-арной связью)))...
Глагольные формы нужно использовать именно для представления семантики связи. Я Вам это уже много раз на многих примерах объяснял.
vadiminfoВешних ключей нет в БД одна запись, а связь со свойствами есть.
Меня не запутаете. Теперь Вы, вероятно, говорите об отношении, в котором "понимает" является значением одного из атрибутов. Другие возможные значения "ненавидит", "любит", "уважает" и т.п. Но Вы, вероятно, наложили ограничение на этот атрибут, и он у Вас для всех записей имеет одно и то же значение))) Еще более очевидно, что речь идет о сущности, а не связи, и в таком варианте нет вообще ни одной связи (потому что нет даже типа сущности Человек и нечего связывать):
Взаимоотношения{Фамилия первого, Фамилия второго, Тип, Степень}
или сокращенный Вами вариант до одного типа:
Понимание{Фамилия понимающего, Фамилия понимаемого, Степень понимания}.

vadiminfoБредятинаИменно в реале их и нет:
14020991

Наверняка опять какая-то ахинея. Так или иначе в реале есть. Под реалом понимается в данном контексте, то что мы собираемся отражать в БД. И если это мысль о том кто как понимает Дейта, то это реал. А "Понимает" в нем связь.
Хамство Вам не поможет))
Я и поясняю, что Вы собираетесь использовать в БД. Это процесс. Не помогает использовать для именования таблицы глагол. Так же, как не поможет назвать ТТН "Отгружаем для" (ведь это "связь" операций отгрузки с клиентом), а Операцию отгрузки "Содержит" (ведь это "связь" ТТН с товаром). В частности, и потому, что ТТН "связана" еще и с Грузополучателем (это не обязательно клиент), и с перевозчиком, и с какими-то другими сущностями. Дейт должен был бы назвать ТТН n-арной связью)))...
Глагольные формы нужно использовать именно для представления семантики связи. Я Вам это уже много раз на многих примерах объяснял.
Наиболее последовательным в отстаивании того, что ТТН, Операция отгрузки и Товар - это связи (!) был один из участников этой дискуссии со свое й МД верхнего уровня:
13577413
Но он не объяснял что он понимает под "связью" (связь между чем?). В той же дискуссии я ясно показал, что Чен (ER-модель) тоже не понимает концепцию связи (он просто некоторые сущности по своему усмотрению называет связями)) То же самое делаете и Вы. Причина понятна. Связей принципиально нет в РМД. А моделировать их как-то нужно. Потому, что они есть, как Вы выражаетесь, в реале. Но, должен заметить, что для моделирования нужно понимать предмет моделирования. И я постепенно добиваюсь этого понимания. Тем более, что вопрос достаточно простой:
14020991
vadiminfoБредятинаВам, как разработчику, известно, что это якобы связь
Не знание кем-то про связи не достаточное основание в общем случае упразднить связь.
Банальная ложь и подлог. Вот мой текст:
---
Именно поэтому Вы и не состоянии привести ни одного примера. Но, поскольку помимо традиционного хамства и подлога, Вы, все-таки, и по существу что-то говорите, разумеется, я Вам помогу. Итак, 1:М. ТТН - Операция отгрузки. Создаем третью таблицу с двумя внешними ключами. Очевидно, что для поддержки 1:М на второй ключ (операция отгрузки) необходимо наложить ОЦ уникальности. Тогда, в таблице операций:
1
2
3
4
5
6
И в третьей таблице
1 1
1 2
1 3
2 4
2 5
3 6
То есть, те же самые (уникальные) операции. Поскольку только Вам, как разработчику, известно, что это якобы связь (попутно замечу, что следуя такой логике и сама операция - это связь))) - между товаром и накладной), возникает вопрос - зачем же Вы создали эту избыточность? Какая Вам разница где хранить эти (пока не известные) характеристики связи операции с накладной? В таблице, где хранятся характеристики операции или в этой третьей таблице? Вы можете сказать, чтобы семантически верно отразить самому себе факт, что это (пока неизвестно что) именно характеристики связи. Это логично, при условии использования архитектуры "модель верхнего уровня+маппинг+РМД"
...
Но, давайте придумаем какие-нибудь характеристики. Может быть Номер страницы (на которой в ТТН находится информация об этой операции?)) Но, страница - это сущность. Если страница - не сущность, значит и ТТН (состоящая из страниц) - не сущность))
Не получилось... С номером записи - аналогично...
Давайте, подключайтесь))
---
vadiminfoБредятинаНо, давайте придумаем какие-нибудь характеристики.

Придумывать у Вас лучше про мешочки получается.
Глупость. Придумайте Вы. Что же Вы - были такой принципиальный, а как доходит до существа, так сразу одно хамство остается)))
vadiminfoБредятинаНикак не могу взять на себя ответственность за то, что кому-либо неизвестны какие-либо положения теории БД.

"Чем кумушек считать трудиться, лучше ль на себя оборотиться?" (С) Крылов
Никак не могу взять на себя ответственность за то, что кому-либо неизвестны какие-либо положения теории БД.
vadiminfoБредятинаЯ и поясняю, для особо одаренных, что это процесс))
Процесса то как раз и нет никакого, когда речь заходит о понимании ЧАЛом. Процесс завершился 30 лет назад.
Ложь и подлог. Вот мой текст:
---
Я и поясняю, для особо одаренных, что это процесс)) Не помогает использовать для именования таблицы глагол. Так же, как не поможет назвать ТТН "Отгружаем для" (ведь это "связь" операций отгрузки с клиентом), а Операцию отгрузки "Содержит" (ведь это "связь" ТТН с товаром). В частности, и потому, что ТТН "связана" еще и с Грузополучателем (это не обязательно клиент), и с перевозчиком, и с какими-то другими сущностями. Дейт должен был бы назвать ТТН n-арной связью)))...
Глагольные формы нужно использовать именно для представления семантики связи. Я Вам это уже много раз на многих примерах объяснял.
---
vadiminfoБредятина Не помогает использовать для именования таблицы глагол.

По ходу Вам уже ниче не поможет.
Тогда прекратите вести это обсуждение, так как по существу Вам нечего сказать.
vadiminfoБредятинаВ частности, и потому, что ТТН "связана" еще и с Грузополучателем (это не обязательно клиент), и с перевозчиком, и с какими-то другими сущностями. Дейт должен был бы назвать ТТН n-арной связью)))...

Дошло что-ли наконец, что связи есть да еще и n-арные? А было время, что Вы идиотскую теорему налабали, что связи бывают только бинарные. Мы еще ржали над ней. Мол Вейрштрасс нервно курит.
Глупость очевидная)) Разумеется никаких n-арных связей не существует. Дейт вынужден хвататься за эту соломинку, в придачу к делению связей на "истинные" и "не истинные", чтобы объяснить, что связи - это не связи, а сущности)) Иначе, РМД - это не модель данных, а математическая теория)) Но у него, конечно, ничего не получилось. Но, он хотя бы пытался как-то объяснить, и даже приводил примеры сущностей, которые он очень хотел бы считать n-арными связями. Поскольку хорошо известна не состоятельность этих примеров, Вы и не хотите рассматривать ничего по существу, чтобы не попадать в неудобную ситуацию (абсолютно по любому вопросу БД).
vadiminfoБредятина Еще более очевидно, что речь идет о сущности, а не связи, и в таком варианте нет вообще ни одной связи (потому что нет даже типа сущности Человек и нечего связывать):

Ну если только Вы Чала человеком не считаете, то связывать нечего. Но я в свой модели связал. И думаю что она нагляднее отображает реал, чем Ваша "Сущность":

БредятинаВзаимоотношения{Фамилия первого, Фамилия второго, Тип, Степень}
или сокращенный Вами вариант до одного типа:
Понимание{Фамилия понимающего, Фамилия понимаемого, Степень понимания}.

С заказчиком мой вариант, например, проще обсуждать: он наверняка тоже "не знает", что связей нет. И мыслит мир как взаимосвязанные понятия. И связи могут друг от друга отличаться, т.е. иметь свойства.
Ваш вариант Вы не привели. Прекратите лгать. Я его за Вас привел
Понимание{Фамилия понимающего, Фамилия понимаемого, Степень понимания}
И никакого типа сущности Человек в нем нет. Имейте хотя бы немного совести, когда обсуждаете простые технические вопросы))
Замена "сущностей" "понятиями" ни Вам, ни заказчику не поможет, а заказчика только запутает. Предложите заказчику какую-то свою гипотезу, если считаете необходимым:
13577413
И, главное (в этом контексте) - что же Вы обманываете заказчика - ведь у Вас нет ничего кроме отношений. Или Вы разработали некую модель верхнего уровня и реализовали архитектуру "модель верхнего уровня+маппинг по всем трем аспекта+РМД"?))) И разговариваете с заказчиком на языке этой модели верхнего уровня? Или Вы просто показываете процесс выявления сущностей и связей между ними в предметной области (а не навязываете сущности и связи заказчику)? Но мы-то говорили о результате (модели во втором смысле по Дейту). И там, если уж говорить до конца у Вас не будет даже
Понимание{Фамилия понимающего, Фамилия понимаемого, Степень понимания}
А будет абракадабра латинскими буквами)))
Хорошо известный факт - реляционная технология не позволяет пользователю получить даже фамилию человека из БД - он это может сделать только с помощью программиста. И за этот коммерческий подход к БД я, конечно, вас - коммерсантов уважаю)))

vadiminfoБредятинаЭто процесс.

Ну если бы их связал процесс, то это все равно связь: связаны процессом. Связи нет када вообще никак не ассоциируются. Вас связали с самим Дейтом. Так радуйтесь: нигде больше Вас с ним не проассциируют никак.
Итак, участники процесса связаны процессом (поэтому процесс - это связь между сущностями))). А участники события, например, Операции отгрузки (Товар, Склад, Кладовщик и т.п.) связаны событием (поэтому, событие - это связь между сущностями))). А фамилия и год рождения кладовщика связаны кладовщиком (поэтому, кладовщик - это связь... формально, тоже между сущностями))). Значит Вам понравилась эта, на первый взгляд необычная, гипотеза, что мир состоит из связей, обладающих свойствами и связей между этими связями:
13577413
Что ж - это очень хороший результат моих усилий.
vadiminfoБредятинаНикак не могу взять на себя ответственность за то, что кому-либо неизвестны какие-либо положения теории БД.


Включая Чена:

БредятинаВ той же дискуссии я ясно показал, что Чен (ER-модель) тоже не понимает концепцию связи


Т.е. связь: "Отвечает". Чал отвечает за Чена. У нее есть свойство: Важность. Значение 0,0009.
Никак не могу взять на себя ответственность за то, что кому-либо неизвестны какие-либо положения теории БД.
vadiminfoБредятинаРазумеется никаких n-арных связей не существует. Дейт вынужден хвататься за эту соломинку, ...
Связь Чал "Критикует" Дейта. Свойство связи Важность. Значение: -100.
Ложь и подлог. Вот мой текст:
---
Разумеется никаких n-арных связей не существует. Дейт вынужден хвататься за эту соломинку, в придачу к делению связей на "истинные" и "не истинные", чтобы объяснить, что связи - это не связи, а сущности)) Иначе, РМД - это не модель данных, а математическая теория)) Но у него, конечно, ничего не получилось. Но, он хотя бы пытался как-то объяснить, и даже приводил примеры сущностей, которые он очень хотел бы считать n-арными связями. Поскольку хорошо известна не состоятельность этих примеров, Вы и не хотите рассматривать ничего по существу, чтобы не попадать в неудобную ситуацию (абсолютно по любому вопросу БД).
---
vadiminfoБредятинаИ, главное (в этом контексте) - что же Вы обманываете заказчика - ведь у Вас нет ничего кроме отношений.
Это примерно тоже, что сказать что на картине нет ничего кроме красок.
Везде обман.
Ложь и подлог. Вот мой текст:
---
Ваш вариант Вы не привели. Прекратите лгать. Я его за Вас привел
Понимание{Фамилия понимающего, Фамилия понимаемого, Степень понимания}
И никакого типа сущности Человек в нем нет. Имейте хотя бы немного совести, когда обсуждаете простые технические вопросы))
Замена "сущностей" "понятиями" ни Вам, ни заказчику не поможет, а заказчика только запутает. Предложите заказчику какую-то свою гипотезу, если считаете необходимым:
13577413
И, главное (в этом контексте) - что же Вы обманываете заказчика - ведь у Вас нет ничего кроме отношений. Или Вы разработали некую модель верхнего уровня и реализовали архитектуру "модель верхнего уровня+маппинг по всем трем аспекта+РМД"?))) И разговариваете с заказчиком на языке этой модели верхнего уровня? Или Вы просто показываете процесс выявления сущностей и связей между ними в предметной области (а не навязываете сущности и связи заказчику)? Но мы-то говорили о результате (модели во втором смысле по Дейту). И там, если уж говорить до конца у Вас не будет даже
Понимание{Фамилия понимающего, Фамилия понимаемого, Степень понимания}
А будет абракадабра латинскими буквами)))
Хорошо известный факт - реляционная технология не позволяет пользователю получить даже фамилию человека из БД - он это может сделать только с помощью программиста. И за этот коммерческий подход к БД я, конечно, вас - коммерсантов уважаю)))
---

vadiminfoБредятинаВаш вариант Вы не привели. Прекратите лгать. Я его за Вас привел

Вы вместо моего какой-то там подлог привели. Левый. До Вас ничего не доходит и Вы опять включили повторы детсадовские.
Короче, у нормальных челов есть Связи и свойства связей и РМД и РСУБД и все такое. А Вы там в своем МУМПСе как хотите.

Единственное, что удалось подтвердить, я думаю, так это ранее нами с Вами единодушно установленный факт:

БредятинаДо таких идиотов, как я, конечно, не доходит))

Ложь.
Ваш вариант Вы не привели. Прекратите лгать. Я его за Вас привел
Понимание{Фамилия понимающего, Фамилия понимаемого, Степень понимания}
И никакого типа сущности Человек в нем нет. Имейте хотя бы немного совести, когда обсуждаете простые технические вопросы))
Замена "сущностей" "понятиями" ни Вам, ни заказчику не поможет, а заказчика только запутает. Предложите заказчику какую-то свою гипотезу, если считаете необходимым:
13577413
И, главное (в этом контексте) - что же Вы обманываете заказчика - ведь у Вас нет ничего кроме отношений. Или Вы разработали некую модель верхнего уровня и реализовали архитектуру "модель верхнего уровня+маппинг по всем трем аспекта+РМД"?))) И разговариваете с заказчиком на языке этой модели верхнего уровня? Или Вы просто показываете процесс выявления сущностей и связей между ними в предметной области (а не навязываете сущности и связи заказчику)? Но мы-то говорили о результате (модели во втором смысле по Дейту). И там, если уж говорить до конца у Вас не будет даже
Понимание{Фамилия понимающего, Фамилия понимаемого, Степень понимания}
А будет абракадабра латинскими буквами)))
Хорошо известный факт - реляционная технология не позволяет пользователю получить даже фамилию человека из БД - он это может сделать только с помощью программиста. И за этот коммерческий подход к БД я, конечно, вас - коммерсантов уважаю)))

vadiminfoБредятинаЛожь.
Ваш вариант Вы не привели. Прекратите лгать. Я его за Вас привел

Правда. Просто до Вас не дошло. То что Вы привели оставьте себе.

Тем более Вы же сами сказали:

БредятинаДо таких идиотов, как я, конечно, не доходит))


С этим да, не поспоришь.
Наглая ложь и хамство))
Ваш вариант Вы не привели. Прекратите лгать. Я его за Вас привел
Понимание{Фамилия понимающего, Фамилия понимаемого, Степень понимания}
И никакого типа сущности Человек в нем нет. Имейте хотя бы немного совести, когда обсуждаете простые технические вопросы))
Замена "сущностей" "понятиями" ни Вам, ни заказчику не поможет, а заказчика только запутает. Предложите заказчику какую-то свою гипотезу, если считаете необходимым:
13577413
И, главное (в этом контексте) - что же Вы обманываете заказчика - ведь у Вас нет ничего кроме отношений. Или Вы разработали некую модель верхнего уровня и реализовали архитектуру "модель верхнего уровня+маппинг по всем трем аспекта+РМД"?))) И разговариваете с заказчиком на языке этой модели верхнего уровня? Или Вы просто показываете процесс выявления сущностей и связей между ними в предметной области (а не навязываете сущности и связи заказчику)? Но мы-то говорили о результате (модели во втором смысле по Дейту). И там, если уж говорить до конца у Вас не будет даже
Понимание{Фамилия понимающего, Фамилия понимаемого, Степень понимания}
А будет абракадабра латинскими буквами)))
Хорошо известный факт - реляционная технология не позволяет пользователю получить даже фамилию человека из БД - он это может сделать только с помощью программиста. И за этот коммерческий подход к БД я, конечно, вас - коммерсантов уважаю)))

vadiminfoБредятина Я его ... привел
....
И никакого типа сущности Человек в нем нет.

Ну есно дело, что у Вас нет. Потому и не стоило Вам пытаться приводить ничего кроме

Бредятина
До таких идиотов, как я, конечно, не доходит))


Эту связь между экземпляром Идиот Типа сущности Умственные достоинства и Вами я признаю без всяких не уместных колебаний.
Ага, значит поняли!)) Не зря я старался)) Теперь можно с чистой совестью подтвердить - конечно, я идиот))

vadiminfoБредятинаАга, значит поняли!))

Давно понял мыстль:
БредятинаДо таких идиотов, как я, конечно, не доходит))


еще в 2004 подозрал что-то подобное.

БредятинаНе зря я старался))


Да Ваши старания в плане подтвержнеия
Бредятина Теперь можно с чистой совестью подтвердить - конечно, я идиот))

Можно признать достаточно успешными. Вот так бы и сразу.

А то какая-то дурацкая модель с "Понимание". Откуда оно возьмется у Вас?
А тут у Вас нормальная адекватная связь, со свойством.
))) Поняли о чем речь! И это - главное. Теперь я - идиот)) С чистой совестью)) Это нормально.

vadiminfoБредятина Теперь я - идиот))
Вообще то не только теперь.

Мы с Вами и раньше приходили к согласию в этом вопросе:
Бредятина
До таких идиотов, как я, конечно, не доходит))


Не надо, плиз, выдать это за новость.
Очевидно, что поняли о чем речь))) А эта типичная форма благодарности, в принципе, нормальная)) Я доволен, что идиот))

vadiminfoБредятинаЯ доволен, что идиот))
Восхищаюсь, но не завидую.
Умница!))

vadiminfoБредятинаЯ доволен, что идиот))
В знак одобрения, я готов заменить тип сущности Человек в моей модели, раз он Вам так не нравится, типом Самочука, и добавить атрибут Способности. И поставить значение этого атрибута Идиот экземпляру Чал. А Тип сущности Книга и тип связи Понимает с ранее указанными данными можно оставить без изменений, поскольку никакой другой информации теперь не требуется.
))) Поняли о чем речь! И это - главное. Теперь я - идиот)) С чистой совестью)) Это нормально.

ViPRosвощем нифига вы не понимаете в теории структуризации знаний
А вот Вы, похоже, пока не поняли)) Но, вряд ли Вас это интересует.