АнатоЛойБредятина1) Связи всегда бинарные.
...
3) У связей нет никаких свойств (иначе они стали бы сущностями).


Бредятина, я правильно понимаю, что как только возникает потребность отразить факт временного наличия/отсутствия связи между сущностями, то связи в вашем примере придётся переделывать?

Ну, например, я правильно понимаю:
Если у ТС возникает потребность отразить факт наличия/отсутствия связи между сущностями в разное время
(Например:
1) Небезысвестный Потрошитель (породы Джек рассел) содержался в 2011 году в Соломенском приюте для бездомных животных.
2) Небезысвестный Потрошитель (породы Джек рассел) содержался в 2012 году у доброго человека Плюшкина.
3) Небезысвестный Потрошитель (породы Джек рассел) содержался в 2013 году в Соломенском приюте для бездомных животных.
то
прийдётся изменить приведённый Вами пример связи
БредятинаПриют --- В котором содержится/Содержится в --> Животное

на сущность "Содержание животного в приюте" с атрибутом "Период содержания (с..по)" с двумя бинарными связями (грубо: "Содержание"-"Животное", "Содержание"-"Приют")?
Нет, не правильно понимаете. Я так резко говорю из-за многочисленных и, на мой взгляд, умышленных неточностей.
1) Это не мой пример. Это факт.
2) В этом примере автора есть только одно событие - Пожертвование. И нет событий передачи животного, гибели животного и др. Это тоже факт.
3) Сущность "Содержание животного" (моделирующая процесс), если уж на то пошло (а не "Содержание животного в приюте"), не "придется добавить", она изначально будет использоваться для другой какой-то задачи, которую никто здесь не формулировал. И, конечно же, независимо от модели данных.
Так что, я не понимаю, пока, суть вопроса. Но, понимаю, что то, что я пояснил ранее, Вы поняли. И решили пойти дальше. Это хорошо) Но не имеет никакого отношения к сравнению моделей. Потому что "переделывать" в случае включения новых типов сущностей предметной области придется в любом случае. Для того, чтобы, как бы, не переделывать, придумывают EAV и другие подходы "свободного моделирования")))

lemurryБредятинаЗначит Вас, на самом деле, базы данных не интересуют, раз начинаете с каких-то тайн)))
Бредятина, у вас откровенная мания величия. Конечно, причина моей регистрации на sql.ru - это тайны, интриги, а может быть и расследования. И их центр - Вы.
Также у вас непреодолимое желание всех учить и поучать. Сублимируйте. Может быть, вам стоит устроиться преподавателем? А если вдруг вы уже преподаете, то возьмите сверхурочные.

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

Обсуждать вашу личность желания больше не имею. По теме: ваше замечание по поводу использования слова "ссылка" восприняла всерьез.
Вы обыкновенная, традиционная для этого сайта, хамка. Это очень современно. Далеко пойдете. А про ссылку - напрасно восприняли всерьез. Это обыкновенная глупость дебила)))

vadiminfolemurry, не запоминайте, плиз, ахинею самозванных "профессионалов".
В частности,
1. связи могут иметь арность больше 2.
Например Связь между тремя сущностями: Актер - Киностудия -Фильм тернарная.
2. У связей вполне могут быть свойства. Кто запретит их различать, если их несколько между двумя объектами к примеру?
3. Если кто-то сомнительный всерьез говорит о заблуждениях Чена (не ссылаясь на авторитетный источник) или что никому кроме него не удалось обнаружить чего-либо, то, скорее всего, следует заподозрить его в некоторой неадекватности. И, по видимому, считать тексты оного достойными гомерического гогота.
Глупость абсолютная. Я это детально показал на всех примерах, которые использовал Дейт. Причем он достаточно подробно описывал примеры, а не просто перечислял три сущности через тире))) В данном случае речь, вероятно, идет о процессе - участии актера в фильме, снятом на киностудии. Разумеется, это сущность, и никакой тернарной связи здесь нет. Потому что ее просто не может быть даже теоретически. Связь - это линия на схеме БД, а не прямоугольник или ромб))) Запомните этот простой факт из теории БД))) Разумеется линий между двумя типами сущностей может быть сколько угодно. С разной семантикой. Вам должно быть стыдно уже, что такие очевидные факты Вы отрицаете просто из-за личной неприязни ко мне. Вам есть что обсудить с lemurry, конечно))

vadiminfolemurry, не запоминайте, плиз, ахинею самозванных "профессионалов".
В частности,
1. связи могут иметь арность больше 2.
Например Связь между тремя сущностями: Актер - Киностудия -Фильм тернарная.
2. У связей вполне могут быть свойства. Кто запретит их различать, если их несколько между двумя объектами к примеру?
3. Если кто-то сомнительный всерьез говорит о заблуждениях Чена (не ссылаясь на авторитетный источник) или что никому кроме него не удалось обнаружить чего-либо, то, скорее всего, следует заподозрить его в некоторой неадекватности. И, по видимому, считать тексты оного достойными гомерического гогота.
Лжете - "не ссылаясь на авторитетный источник". Прекрасно знаете, что не просто ссылался, а тщательно и подробно цитировал, и пояснял в чем суть ошибки Чена.

Кот МатроскинБредятинаУ связей нет никаких свойств (иначе они стали бы сущностями).


Бредятина Разумеется линий между двумя типами сущностей может быть сколько угодно. С разной семантикой.
О, у связей/линий уже "семантика" появилась - хотя, казалось бы, " нет никаких свойств".
Так же как у сущности есть имя. И есть свойства))) Но, хорошо хоть, что начали задумываться, пусть и в целях найти противоречие в теории БД)))

Кот МатроскинБредятинаУ связей нет никаких свойств (иначе они стали бы сущностями).


Бредятина Разумеется линий между двумя типами сущностей может быть сколько угодно. С разной семантикой.
О, у связей/линий уже "семантика" появилась - хотя, казалось бы, " нет никаких свойств".
У связей нет и не может быть никаких свойств. Не путайте атрибуты элементов структуры со свойствами сущностей)) Я же очень подробно все это пояснял не один раз. Вас явно не интересуют базы данных, раз до сих пор даже не попытались понять)))

vadiminfoБредятина Связь - это линия на схеме БД...
В нотации Чена связи обозначаются ромбиками.

БредятинаЛжете - "не ссылаясь на авторитетный источник".

Авторитетный источник выявивший ошибку.

А
Бредятина ... пояснял в чем суть ошибки Чена.

это не авторитетный источник, и даже наоборот: чрезмерно сомнительный
Авторитетнее не бывает. Это Вы, наверное, занимаетесь БД на уровне первого юношеского, а я не понимаю зачем вообще чем-то заниматься, если не стремишься стать лучшим?) У Чена связь ничем не отличается от сущности. Как и у Кодда. У Кодда даже была такая детская мысль, что если в отношении более одного внешнего ключа, то оно представляет связь))) Чен пошел немного дальше - если нарисовать ромбик, то это связь))) Модель Чена ориентирована изначально на маппинг в РМД, так что ничего удивительного в ошибке Чена нет.

Здесь рассматривали связи у Чена в том числе.
http://www.sql.ru/forum/973198-1/db-specific-orm

В этой теме (а не только в этом сообщении) детально обсуждали связи
14020991

vadiminfoБредятинаАвторитетнее не бывает.

Ну разве в какой-то сельской местности "Авторитетнее не бывает".

Бредятина... а я не понимаю зачем вообще чем-то заниматься, если не стремишься стать лучшим?)

Ну Вы как раз пример, того что стремление быть лучшим никак не препятствует тому, чтобы стабильно годами оставаться худшим без всякой надежды на малейшее улучшение.

БредятинаУ Чена связь ничем не отличается от сущности.

Не надо, плиз, говорить за всех.

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

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