Alexey MaslovБредятина...совершенно очевидно, что многие отношения, содержащие более одного внешнего ключа представляют собой сущности (а не связи), имеющие "связи" с другими сущностями (М:1).ИМХО, в данном случае совершенно неочевидно. Ибо обсуждаемое отношение как раз и было создано, чтобы промоделировать связь M:N между сущностями. Т.е. его две связи (1:M) как раз и являются "ненастоящими", и нет никаких причин для их превращения в "настоящие" (M:N). Если Вы другого мнения, обоснуйте его. Можно на каком-то конкретном примере.
Что значит "в данном случае"? Как представляются "связи" в РМД? С помощью внешних ключей? Или с помощью отношений? Как Вы определяете, что "связь" М:1, представленная в виде внешнего ключа, не может стать "настоящей связью", представленной в виде отношения? Вы говорите, что вот эта конкретная "связь" вот в этом конкретном отношении гарантированно не может стать "настоящей", потому что само это отношение было специально создано, чтобы поддерживать "настоящую связь"? Во-первых, а откуда это известно-то? А, во-вторых, это не так! Например:

Люди работают в организациях. М:М. Создаем отдельное отношение.

Человек -(1:М) -> Работа человека в организации <-(М:1) - Организация

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

Человек <- (М:М) -> Работа человека в организации {Должность} <- (М:М) -> Организация

Конечно же, и это еще не все. Создав еще два отношения, Вы не можете опять гарантировать, что это "настоящие связи":)

Нет в РМД структуры для представления связи, вот и прихидится вводить, мягко говоря, странные определения: "не настоящие связи" и "настоящие связи". Это дополнительное отношение, конечно же, новая сущность (а вовсе не связь), "связанная" с двумя другими сущностями стандартным для РМД механизмом - внешний ключ. А в широком смысле, механизмом связывания по "общим" полям (вовсе не обязательно по ключам).

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

Чем хуже? Я без БД не знаю как задачи решать. Это однодневки будут. А Вы про БД ничего не говорите. Нет схемы данных. А она решает все. Программирование ничего не решает. Его нужно сводить к минимуму во всех стандартных случаях. А с другой строны, не боятся программировать наиболее эффективным образом (не полагаясь на "помощь" постоянно меняющихся "оптимизаторов") редкие "не стандартные" задачи, постепенно превращая и их в "стандартные".
Блок А.Н.
В SQL эта задача решается в одно выражение, но каше такой sql не поддерживает и вообще он по скорости будет очень плохим. Либо SQL с процедурным программированием, тоже ничего приятного.

С SQL ничем не могу помочь. Периодически приходится с ним сталкиваться, и убеждаться, что пользы от него меньше, чем вреда. Хотя интересно что означает "такой SQL"?
А программировать приложение на нескольких языках с разными парадигмами, конечно, малоприятное занятие.
Блок А.Н.
Я уже говорил, что ИДЕЙ на самом деле очень мало. И либо вы гений и придумали какую-то оригинальную новую идею, либо вы используете что-то из уже известного.

Я постоянно подчеркиваю, что ничего нового не придумал. А Вы это постоянно игнорируете:)
Блок А.Н.
И еще, вы опытный спорщик, и споре избегаете давать прямые ответы. На мой вопрос вы не ответили - придется додумывать за вас.

Я сейчас разбираюсь с couchdb, и не могу решать какие-то задачи про "состояния объектов". Могу только сказать, что ничего сложного в этой задаче нет.
Блок А.Н.
Мне так показалось, вы будете использовать объектную модель и процедурное программирование? Причем класс будет с поддержкой интерфейса "связи" и методами работы со связями. Так?
И в чем изюм?
Я бы, конечно, использовал КОМД и ее ЯМД. Вы почти правы. И на 100% правы, что никакого изюма нет и в помине. А Вы вот думаете как быть с Cache, в которой не тот SQL, который нужен:)

Siemargl
Неверно получаем. Всего лишь так.
Человек <- (1:М) -> Работа человека в организации <- (М:1) -> Организация
Должность <- (1:M) --/
:) Вы уж, пожалуйста, не путайте людей. Которые хотят разобраться со связями. Я с удовольствием готов обсудить с Вами ту проблему, которую Вы сейчас придумываете на ходу, как и проблемы проектирования БД в целом. А сейчас мы получили именно то, что я написал, объясняя, что связь M:1 может стать связью М:М, о чем и написал Дейт в абзаце, с которого все это началось. А Вы взяли кусочек из контекста, и поставили для себя другую задачу. Видимо, строгую задачу изначально правильного проектирования БД:)

Блок А.Н.С каше все нормально, не о ней речь (не смотря на название темы )

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

А Вы меня опять с кем-то путаете. Я предельно точно ответил.
Блок А.Н.
Свою задачу я привел в ответ на тезис о том, что модель решает все и ничего не надо программировать, сделал мастер-детайл или другие связи - наступило счастье.

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

И я это подтвердил. Черным по белому (только использовал КОМД, а не "объектная модель", поскольку не знаю, что Вы подразумеваете под "объектной моделью").
Блок А.Н.
Вы обвинили SQL в том, что на нем нужно программировать ("обеспечивает работой целую армию программистов")
Хочу знать новый способ.

Не хитрите, пожалуйста:) Я не голословно "обвинил". И вовсе не обвинил. А привел пример, с которыми сталкиваюсь на практике ежедневно. Так как по роду работы анализирую эксплуатацию разнообразных информационных систем:)
Про ДРУГОЙ ПОДХОД (я же нового ничего не придумал, так что это не новый способ:)) мы здесь как раз и рассуждаем.
Блок А.Н.
Кстати, КОМД - это аббревиатура, которой пользуетесь на sql.ru только вы. В какой-то момент я ее начал понимать, а потом забыл :(
И в чем я виноват? Опять?:)

Siemargl
Пойдем с другой стороны. Как эта задача правильно, на ваш взгляд, проектируется в объектах ?
Зачем же идти с другой стороны?. И при чем здесь "правильное проектирование"? Мы же рассматривали пример, который показывает, что отношение, представляющее "настоящую связь", вовсе не представляет никакой связи. Вы хотите бОльшей строгости в примере что ли? Это справедливо, согласен.

Человек - (1:М) -> Работа человека в организации <- (М:1) - Организация

Мы создали отношение для представления связи М:М и думаем, что оно представляет "настоящую связь. Пусть, каждая Работа продолжает относится строго к одной организации. Просто для учета Должностей заменяем ее на Должность и добавляем поля (Оклад, например):

Человек - (1:М) -> Должность <- (М:1) - Организация

Мы уже видим, что то, что мы хотели бы назвать "настоящей связью" оказалось вовсе не связью:). Пошли дальше. Должность занимают разные люди в разное время. Таким образом, первая связь становится М:М. Но! То отношение, которое мы сейчас добавим как бы для реализации этой связи является, конечно же, отдельной сущностью со своими многочисленными характеристиками (Дата назначения и т.п.):

Человек - (1:М) -> Назначение <- (М:1) - Должность <- (М:1) - Организация

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

КОМД и соответсвующая КОСУБД отличаются тем (только в том узком направлении, о котором мы говорим сейчас), что поддерживают связи (в том числе М:М, что принципиально невозможно в РМД) и их семантику (что особенно важно, когда между двумя объектами более одной связи).
В КОМД мы создаем схему:

Человек (A) - Имеет/Относится к -> Назначение (B) <- Относится к/Имеет - Должность (C) <-Относится к/Имеет - Организация (D)

Где A, B, C, D - идентификаторы объектов (технические метаданные).

Человек, а не table People:) То же самое и с характеристиками этих объектов. То есть, приложение семантически готово к использованию стандартными средствами.

Блок А.Н.Блин, рыбину в аквариуме проще поймать, чем от вас добиться точного ответа.
С каше по прежнему все нормально, потому что SQL является в ней вспомогательным, а не основным инструментом.

Спасибо за уточнение. Клещами приходится вытягивать, указывая на очевидные противоречия в высказываниях:) А мои-то ответы предельно точны.
Блок А.Н.
С моделью данных тоже понятно. Это сущности и связи между ними. Причем связи не являются атрибутами объектов, за счет этого могут свободно меня тип от 1-М до М-М и потенциально еще много чего. Это мы тоже выяснили.

Термин сущность не вполне хорош. Нужно использовать термин "объект". Так как он (объект) может быть двух типов: сущность (вот где сущность) и событие (см. сообщение о перспективных идеях).
Блок А.Н.
С такой моделью можно работать через SQL, можно через объекты, но мы выяснили, что вы это не делаете.

А это уже не просто неточность, а серьезное заблуждение. Никак нельзя работать "через SQL" с такой моделью, поскольку в SQL принципиально не поддерживаются связи между объектами.
Блок А.Н.
Осталось выяснить что такое этот таинственный КОМД и как вы посредством ее минуя процедурное/объектное программирование и SQL что-то получить.

КОМД - это классическая объектная модель данных, о которой, как Вы сказали выше, Вам все понятно. Видимо, все-таки, не все:)

Alexey Maslov
Тогда вполне подходит модель Siemargl: бинарная связь M:N превращается в тернарную M:N:P. По-прежнему моделируется _одной_ дополнительной сущностью, правда теперь уже с тремя внешними ключами.
Соглашусь с тем, что "настоящую связь" M:N лучше рассматривать как отдельную сущность (тем более, что и классики к этому призывают :), но пока что не вижу, к каким проблемам это ведет.
Удивительно:) Как это "соглашусь"? "Ваше" ПО просто не будет работать, если этого не сделать. Это вынужденная мера, из-за того, что связи ПРИНЦИПИАЛЬНО НЕ ПОДДЕРЖИВАЮТСЯ. Что значит "рассматривать"? Держать у себя в голове? Ведь на логике это никак не отражается. Нет никакой связи. И наконец, Вы забыли, что классики призывают ВСЕ СВЯЗИ "рассматривать" как отдельные сущности. Но это также бессмысленно, как и НЕКОТОРЫЕ связи "рассматривать" как отдельные сущности. "Связи" в РМД представляются внешними ключами, и никак иначе. Теоретически, есть вариант поддержки всех связей с помощью специального типа отношения. В таком типе отношения нужно запретить создавать атрибуты, которые НЕ ЯВЛЯЮТСЯ ВНЕШНИМИ КЛЮЧАМИ, а также предусмотреть создание ровно двух внешних ключей (так как никаких связей, кроме бинарных не существует). Это было бы неким приближением к реальной поддержке связей между объектами. При этом мощность связи управляется условиями уникальности, накладываемыми на пару внешних ключей. Но это уже не реляционная модель:)

Блок А.Н.А дальше то, дальше что с этой КОМД делать?
То же, что и с любой другой МД. Создать СУБД, которая поддерживает эту модель. И использовать ее для создания приложений. Что и было сделано. А почему Вы задали этот странный вопрос, ответ на который очевиден?

Siemargl
Искуственное размазывание простой звезды для показывания ущербности реализации М:М в РСУБД думаю можно опустить, не суть важно.

Здесь требуются пояснение. При проектировании БД в любой модели данных я не слышал термина "искусственное размазывание". Также ни в РМД, ни в КОМД нет понятия "простая звезда". В РМД есть отношения. А в КОМД объекты и связи. Я не понимаю какие "простые звезды" я "искусственно размазывал".
Siemargl
Отличий не вижу при подходах:
1. Человек - (1:М) -> Назначение <- (М:1) - Должность <- (М:1) - Организация
и
2. Человек (A) - Имеет/Относится к -> Назначение (B) <- Относится к/Имеет - Должность (C) <-Относится к/Имеет - Организация (D)
Может с объектами все же не так прямолинейно?

Да нет, все достаточно прямолинейно. Есть объекты и связи между ними. А в другом случае нет ни объектов, ни связей. А Вы сделали вид будто-бы они есть, и нарисовали два раза одно и то же:)

Siemargl
Просветим легко =)

И где же "искусственное размазывание" и "простая звезда"???
Siemargl
В компьютере все биты и байты. Все остальное всего лишь один из способов сильно наморщить лоб, т.е сила абстракции ))

А-а-а, значит РМД - это биты и байты? А КОМД - это "наморшить лоб"? Я так и знал:)
Siemargl
Напишите на любом метаязыке представление объектов для этой структуры - может станет понятнее, куда медитировать.

Хорошо, напишу на рефале, он мне больше всего нравится:) И буду медитировать.
Siemargl
А сделал и и написал не я, а вы - я лишь процитировал ваши структуры.

Не поняв о чем речь:) Бывает..

Alexey MaslovБредятина, прошу извинить, разместил свою реплику, не увидев Вашей в 19:19). Ушел думать :)... Приятных всем выходных!
И Вам хорошо отдохнуть. То есть, подумать:)

Блок А.Н.Андрей Леонидович, у меня создается ощущение, что вы всегда работали Пророком, а не в практической разработке.

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

Денормализация БД возможна при использовании любой модели данных, конечно же. Как и нормализация. Большой интерес, кстати, представляет вопрос: что такое нормализация для иерархической модели данных. Хотя в mumps и не иерархическая модель данных, ответ на этот вопрос поможет многое прояснить (в том числе, для IMS, раз уж она здесь упоминалась).
А вот аналогию применить сложно: что такое денормализация модели данных мне трудно сказать:)
Блок А.Н.
Ответьте, что за методика, какие методы. Если есть возможность привести кусок кода - покажите как делаются простейшие операции.

Не один раз показывал. Обычные для КОМД функции ЯМД, похожие на команды mumps, типа
$$ge(идентификатор объекта,идентификатор экземпляра,"d") - получить все характеритики экземпляра в локальный массив d. Аналогично для обновлений/удалений и объектов, и экземпляров объектов, и связей, и экземпляров связей, аналогично для навигации.
Декларативный язык не актуален, хотя и возможен. Если Вам это интересно, можете реализовать:)И потом, это же не моя разработка. Существующая 18 лет. Хорошо документированная.
А здесь я говорил только про то, что мне не нравится, так как противоречит формальной теории. Но Вас это мало интересует. Но не могу же я удовлетворить интересы всех и каждого:)
Блок А.Н.
А то создается впечатление, что вы пришли сюда просто всех потроллить. В этом случае мне жаль, что я участвую в этом разговоре.
[quot Блок А.Н.]
После идиота, шизофреника и т.п. мне совсем не сложно побыть троллем:)

Siemargl
Звезда в википедии и мой пример тоже звезда
Человек <- (1:М) -> Работа человека в организации <- (М:1) -> Организация
Должность <- (1:M) --/
Избыточное размазывание в этом случае это -
Человек - (1:М) -> Назначение <- (М:1) - Должность <- (М:1) - Организация

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

А зачем тогда про биты и байты? Значит продолжаем про модели данных.
Siemargl
На рефале нет смысла - он не объектный.
Вопрос простой - как обсуждаемую структуру правильно на ваш взгляд описать в КОМД?
А РМД оставим в покое - ей и так неплохо живется.

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