MX-9Только надо учитывать еще и однополые браки и, на перспективу,
групповые однополые и разнополые - с возможностью выбывания - прибывания участников
в процессе существования этой сущности
Процесс может длится бесконечно..
Разумеется. Все это элементарно учитывается. А Вы, похоже, хотите снова повторить, что МД не нужны, так как все равно все будет неправильно спроектировано))

Блок А.Н.Вы непонятно зачем спорите с Дейтом. Я то причем тут?
Если вы хотите поговорить об этом, можно создать тему "мое несогласие с Дейтом".
Это неправда. Я не спорю с Дейтом. А очень четко поясняю суть заблуждений Кодда и Дейта. Зачем Вы, вместо обсуждения по существу, опять переходите на личности???
БредятинаВедь у связей нет и не может быть свойств.А вот это можете обосновать? Без ссылок на Дейта или кого-либо еще? Вы всегда высказываете это утверждение как аксиому, непонятно почему.
А я заявлю, что связи - это такие же сущности. И буду использовать это как аксиому.[/quot]
Извините, это Дейт заявляет, потому что в рамках РМД иное невозможно .
И Вы (Дейта то этот результат догматического вынужденного подхода не очень интересует) неизбежно будете использовать архитектуру "модель верхнего уровня(в которой есть разница между сущностями и связями)+маппинг+модель нижнего уровня (в которой нет разницы между сущностями и связями)". Причем с маппингом по всем трем аспектам МД.
Этому вопросу была посвящена большая тема, на которую я не раз ссылался.
В М0 (1976) связи не такие же сущности 13577413 . И это было сделано ради семантического развития РМД, против которого, кажется, никто не возражает. Кроме Вас.

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

DirksDRЯ - в некотором роде, сущность (прошу прощения за нескромность).
Мой автомобиль - тоже сущность.
Между нами существует связь.
Она существует с 24.04.2012.
Разве это дата не является характеристикой(свойством) связи?
Нет, не является. Вероятно, нужно повторить сначала, раз лень читать специальную тему по этому вопросу.
1) _мод, в философском плане, прав, когда говорит, что связей не существует в реальности.
2) _мод, во всех планах, не прав, когда моделирует "несуществующие связи" с помощью конкретных элементов структуры БД (или ограничений целостности), например, ссылок. Возникает противоречие связей нет, но они есть.
3) Разработчики "современных" NoSQL-систем более последовательны - в этих системах связи, как правило, не поддерживаются.
4) Возвращаясь к п. 1), связи придуманы человеком для лучшего понимания (семантической окраски) действительности. Обычно, для этого используются глагольные формы.
5) Таким образом, в представлении человека об окружающем мире связи есть . Рискованно говорить существуют . Так как это может интерпретироваться (и, действительно, интерпретируется) не правильно - если существуют, значит это сущности:)
6) Очевидно, что у этой семантической окраски нет никаких свойств, кроме самой себя, кроме самой семантической окраски. Поэтому, связи в МД имеют атрибуты (но не свойства) - мощность и семантику в обоих направлениях.

Если непонятно, можно привести детальный пример, поясняющий перечисленные факты.
Что касается Вашего примера, то Вы говорите, вероятно о праве собственности. Или о покупке автомобиля. Во всех случаях Вы говорите о сущности.

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

Блок А.Н.А я и не буду говорить ничего конкретного, потому что практика тривиальна и в рамках этого обсуждения, я считаю, не интересна. Интересней теория, как это можно сделать.
Теория разве не конкретна? И уж точно тривиальнее практики.
Блок А.Н.Давайте прокомментирую, что я думаю про каждый пункт.
0) Пожалуй, избыточно. Связи в этом случае не разделяются по своим свойствам от сущностей.
Это ER-модель. Именно ее используют для семантического моделирования и последующего маппинга на РМД.
Блок А.Н.1) Имеет право на жизнь (если не выкидывать "лишние" сущности и не создавать тернарных связей или связей многие-ко-многим (которые я так и не придумал, где не являются "грязными". Наверное случаи есть, но в голову не приходят). Такая вполне сбалансированная модель получается.
Модель, в которой связи являются элементом структуры, наравне с сущностями. Сложнее всего маппится на РМД, но проще всего при самостоятельном использовании. Единственная модель, обеспечивающая симметричный доступ, и стирающая границу между концептуальным и логическим уровнями. Минимизирует программирование приложений БД.
Блок А.Н.2) Вариант схемы 1. По сути, отказ от типизации сущностей. Интересен в плане создания ИИ и подобного, когда схема данных не задается кодом программы, но вряд ли интересен для создания обычных БД. Если только не использовать несколько уровней модели.
Полезна для обучения, как минимум. В ОРМ, например (см. мое предложение чем заняться автору темы - в соседней теме этого же автора про SQL), тоже нет свойств.
Блок А.Н.3) Вот этот вариант интересен, но я не смог его даже мысленно представить. По сути, как-то так работает сознание человека, в котором практически нет базовых сущностей, а все создается на основе их. Какие-то сущности оставить все равно нужно, пусть они ничего и не означают, иначе просто непонятно, как с этим жить.
Но результат ничем не отличается (кроме терминологии) от М4 (или М5). Модель Arhat109.
Блок А.Н.4) По сути эта схема ближе всего к реляционной (к их реализации).
Это модель _мод. Нет она далека от реляционной. Она ближе к модели Cache. Нужно читать обсуждение. Там множественные ссылки, например. Несимметричный доступ, что характерно для моделей со ссылками.
Блок А.Н.5) Не понял, чем отличается от 4.
Это модель ViPRos. Отличается. В ней нет множественных ссылок, и она наиболее близка к РМД. Но, с другой стороны, используется, все-таки, концепция связи (в отличие от М4), но так же неубедительно, как и в М0. Так же у VipRos много концепций, которые обсуждались в теме на предмет необходимости включения в модель.
Блок А.Н.В общем, если я правильно понял (а я не совсем в этом уверен), то в практике скорее использую модель 4(или 5?), а как мысленный эксперимент интереснее всего модель 3.
Я тоже думаю, что Вы используете 4 или 5.

doublefintАндрей Леонидович, заинтересовали также ваши рассуждения о неполноценности SQL-запросов (вы упоминали статистику запросов). Можно в таком же формате как про связи или ссылку? Спасибо!
1) Большинство запросов в типичных OLTP-приложениях связаны с поиском экземпляра объекта (сущности определенного типа) и экземпляров объекта, связанных с конкретным экземпляром другого объекта (записи документа, договоры клиента и т.п.). Оптимизировать здесь нечего (сердце "реляционной системы" - оптимизатор - бесполезен), а интегрированный язык БД удобнее двух языков (процедурного и декларативного) пусть и с общим заголовком, типа PL/SQL.
2) Большинство оставшихся запросов относятся к классу так называемых непредусмотренных. Они формулируются пользователями с использованием интерактивного интерфейса, и язык, на котором реализованы вычислительные мощности этого интерфейса не имеет никакого значения. Так же, как и в п. 1) интегрированный язык и структуры, используемые в MUMPS, как минимум, не менее эффективны, чем два языка с разными парадигмами и разными структурами. Но, повторю, не имеет никакого значения на каком именно языке реализованы непредусмотренные запросы и отчеты в рамках интерактивного интерфейса.
3) Наконец, остались "сложные вычисления", например, расчет фактической себестоимости продукции или расчет заработной платы. У меня нет сомнений в преимуществе MUMPS, как технологии, перед PL/SQL или TSQL. Однако, здесь важно услышать мнение специалистов Cache, которые одинаково хорошо владеют MUMPS (COS) и SQL.

Перспективы связаны с направлениями такого плана
14020854

Замечу, что "сложные вычисления" по п. 3) содержат, в основном, не сложные запросы, а множество простых.
Для такого типичного фрагмента, как
"Если значение характеристики ih экземпляра ie объекта io не существует, то выполнить программу PRG и завершить текущую программу"
вот код, написанный любителем в среде СУБД на MUMPS

i $$g(io,ie,ih)="" d ^PRG q

а вот попытка написания аналогичного кода профессионалом на языке реляционной системы хранения и обработки данных (РСХОД)

IF NOT EXISTS (SELECT * FROM x WHERE ...)
THEN
CALL PRG() ;
RETURN;
END IF;

Запрос не дописан, не понятно используются ли в нем переменные или имена, но понятно, что интегрированный язык БД мощнее двух языков.