Блок А.Н.Однако у меня в иногда создатеся впечатление, что рекламируете. Ну да суть не в этом :-)

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

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

Базовая идея объединить концептаульный и логический уровень (в случае РМД - логический уровень, концептуальным, обычно, считается ER-модель).

У КОМД другой уровень абстракции (помимо уже много раз объясненных принципиальных отличий в идентификации и семантике): в РМД только отношения, в КОМД объекты и связи.
Кодд также пытался как-то описывать связи (вводил понятия "отношение типа сущности" и "отношение типа связи"), но из этого ничего не получилось. И не может получиться чисто формально. Я уже приводил мнение Дейта о том, что "связи" (он использует неизбежно этот термин концептуального уровня, хотя в РМД, конечно же, нет никаких связей) нужно представлять одним способом, независимо от их мощности, то есть, всегда отдельным отношением. Но это невозможно в РМД:
1) "Cвязи" "реализуются" с помощью внешних ключей. Формально, связи - это линии от внешнего ключа в отношении A к потенциальномe в отношении B.
2) Создаем для этой "связи" отношение C.
3) В нем два внешних ключа.
4) Но внешние ключи - это связи.
5) Следовательно, для них нужно создать отдельные отношения D и E.
6) И т.д.

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

Важно, что КОМД восприимчива к развитию, тогда как РМД органически не восприимчива.

Пара идей по развитию.
1. Поддерживать два типа объектов: сущности и события (участниками которых являются сущности).
2. Реализовать "классификаторы", как тип характеристики объекта. Это идея имеет простое обоснование. Представим, что у нас есть характеристики (свойства, атрибуты) Фамилия и Дата рождения объекта (класса, отношения) Человек. Когда мы для определенного экземпляра (объекта, кортежа) указываем значение характеристики Фамилия Сидоров, мы относим конкретного человека к КЛАССУ ЛЮДЕЙ, имеющих фамилию Сидоров. Когда мы для определенного экземпляра указываем значение характеристики Дата рождения 12.09.1990, мы относим конкретного человека к КЛАССУ ЛЮДЕЙ, родившихся 12.09.1990. То есть, любая характеристика - в определенном смысле "классификатор". Вот и нужно "классификаторы" (и иерархические и фасетные) сделать типом характеристики, наряду со строками и датами. Тот, кто это первым реализует почувсвует существенное упрощение при решении многих практических задач:)

И т.д.:)

Блок А.Н.В том же Аксессе можно без программирования создать функциональную СУБД. Так почему же он не захватил весь мир?

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

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

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

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

В этой части тоже есть несколько полезных идей, которые несложно реализовать.
Пример.
Конечно, у пользователя уйдет меньше минуты, чтобы создать себе такую схему. Но, все-таки, ее нужно создать, и она пополнит список пользовательстких схем. Однако этого можно избежать, если реализовать ФУНКЦИЮ АВТОМАТИЧЕСКОЙ РОТАЦИИ. Тогда изменение головного объекта в схеме (а точнее полное "вращение", так как в схеме может быть более двух взаимосвязанных объектов) будет делаться одним щелчком:)

Блок А.Н.
Пока с точки определений модель ... очень близка к реляционной. Но дополнительные ограничения дают нам основания ожидать, что мы взамен получим некий механизм, некую новую "алгебру" для работы с этими сущностями-связями. И интуитивно мне кажется, что это возможно...

Не думаю, что "алгебра" актуальна. Я уже объяснял, что от SQL толку мало. Для него нужно искать ниши какие-то. Вот я нашел одну - "статистическая алгебра":) Но производители РСУБД эти ниши не ищут, а, пользуясь "историческим моментом", впаривают всем подряд:)
Еще раз приведу пример.
Предположим у нас есть сложная система, в которой нового пользователя интересует вот такой фрагмент:
Страна - Имеет (1:М) - Университеты
Страна - Имеет (1:М) - Гостиницы
Его интересуют, например, страны с населением менее 20 млн. (это характеристика объекта Страна), университеты в них с числом студентов более 2 тыс. (это характеристика объекта Университет) и гостиницы типа *** (это характеристика объекта гостиница).
Он просто создает указанную выше схему и делает в ней указанный запрос. Поскольку
РЕЗУЛЬТАТОМ ЗАПРОСА К БАЗЕ ДАННЫХ ЯВЛЯЕТСЯ ПОСХЕМА СХЕМЫ БАЗЫ ДАННЫХ СО ВСЕЙ СЕМАНТИКОЙ, ПРИСУЩЕЙ БАЗЕ ДАННЫХ
результатом является точно та же схема, в которой просто поменьше экземпляров этих трех объектов:)
В реляционной технологии, благодаря замечательному свойству реляционной замкнутости результатом запроса будет некоторое новое отношение. Что это за отношение? Вы узнаете обычным путем: заключить договор, написать ТЗ, заплатить деньги:) И так на каждом шагу. Безусловный плюс реляционной технологии - она обеспечивает работой целую армию программистов, которые только и обсуждают между собой аспекты борьбы с "запросами", "хинтами", "оптимизаторами", "EAV" и т.п.:)

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

ser_shuAlexey Maslov,

Потому что "связи" никакого отношения к данным в ИС и их целостности не имеют.
Целостность обеспечивают операции записи/корректировки/удаления данных в ИС.
Если эти операции не обращают внимания на нарисованные "связи", то целостности все равно не будет.
А если операции обеспечивают целостность данных в ИС без явно прописанных "связей", то и "связи" не нужны.
"Связи" это избыточный набор данных, с помощью которого операции записи/корректировки/удаления поддерживают целостность данных в ИС.
Надеюсь, здесь речь идет о реляционных ИС:)
Так как в КОМД связи являются таким же полноправным элементов структуры, как и объекты, и "участвуют" в ограничениях целостности.

Блок А.Н.Такое ощущение, что вы забыли написать большой кусок текста. Ничего не понятно
У какого пользователя уйдет меньше минуты?
Что такое функция ротации и зачем она нужна?
Что такое вращение?

Вы о чем-то своем?
Здасьте, приехали:)
Я исключительно о Вашем.
Есть "стандартная" схема, которая, например, создана разработчиком:
Документ: ТТН - Состоит из -> Операция отгрузки
Пользователь элементарно (меньше минуты) создает себе другую, нужную ему для работы, схему:
Операция отгрузки <- Входит в - Документ: ТТН
и работает с ней.
Именно об этом Вам написал doublefint
А я пояснил, что можно идти дальше и одним щелчком сделать объект Операция отгрузки головным в первой схеме (и вообще не делать вторую схему). Что же здесь непонятного?:)

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

Siemargl
В теме про IBM IMS пробегала именно такая операция на уровне СУБД. Давно придумали )
Пробегала, но не такая:) Здесь БД совсем не затрагивается. В КОМД итак поддерживаютсядвухсторонние связи. Здесь речь идет только о функционале навигатора.

doublefintSiemargl, как бы настолько необязательная и интерфейсная операция... Дополнительный бантик к объектному навигатору, не более. Это скорее уровень реализации, но не идеи.
Но ведь существуют же идеи реализации:)

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

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