AlexKBДаже анархисты свои взгляды излагали в трудах!!!
А тут сплошные лозунги...
Уточните, пожалуйста. что конкретно Вы восприняли, как лозунг, и почему.

EvLaUyНу вот видите, Андрей Леонидович, народ поддерживает, просят книгу.
Нет. Народ старательно игнорирует обсуждение по существу. То есть, по существу могут обсуждаться только команды на языке программирования, но не теория или проектирование БД. Это просто так принято на sql.ru. Не обсуждать вопросы, которые как-то конкретно решены разработчиками программного обеспечения, которое, в свою очередь, используют участники форума, и их не интересует почему эти разработчики сделали именно так. Я это понимаю.
EvLaUyДействительно, я вырос и получил образование, когда никаких персональных компьютеров еще не было, и "расти над собой" привык путем чтения книг. Поэтому и не могу всерьез воспринимать разбросанные по разным веткам форума "баталии", ибо любые знания становятся наукой только тогда, когда они систематизированы. А о какой систематизации может идти речь на этом форуме?
Об элементарной. Все здесь тщательно систематизировано и в систематизированном виде постоянно повторяется. Никакая книга ничего не изменит. Классический пример, книга Дейта, с проблематикой которой и пониманием проблем, стоявших перед автором, мало кто (мягко говоря) хочет разбираться. Вы хотите сказать, что "теоретики" должны где-то в своем кругу что-то обсуждать, и выдать Вам готовую версию, например, Cache, которую Вы просто будете использовать согласно документации. Это понятно.
EvLaUyБудет книга - будет и разговор, где всё уже как Вы любите - по-существу.
Ничего подобного. Совершенно не серьезно. Никто не мешает Вам обсуждать вопрос о моделировании связей между типами сущностей (например) по существу.
EvLaUyНу не получается в "твердом" варианте через издательство - сделайте хотя бы электронный вариант с платным скачиванием, я с удовольствием заплачу, чтобы хотя бы распечатать и ознакомиться с Вашими взглядами в структурированном и систематизированном виде. Ну не могу я собирать по всем форумам Ваши высказывания, определять - в каком порядке их следует читать и приводить к литературному виду. Эту работу должны выполнить Вы.
Постоянно выполняется. Ссылки даются локально и по существу. Вам просто не интересна сама проблематика БД. Или нет времени. Вы Дейта часто читаете?

EvLaUyНет, пожалуй, я пас. Больше не могу.
Даже и не начав обсуждение какого-либо, пусть самого простого вопроса, по существу))
EvLaUyКак писал Морис Дрюон в романе "Лилия и лев": "Считается, что сильный человек способен признать свою неправоту. Но, может быть, еще сильнее тот, кто никогда её не признает". Видимо, это про Вас. Читая Ваши ответы, кажется, что говоришь с железобетонной стеной. С имеющимися у меня знаниями и опытом проектирования БД уж как-нибудь доживу до пенсии и заработаю денег и без знания неопубликованных трудов Андрея Леонидовича. Может быть, конечно, мои представления безнадежно устарели, но я всегда привык считать, что рейтинг ученого измеряется в первую очередь опубликованными им трудами и тем, насколько часто другие ученые на них ссылаются. Я, вот, две книги в центральных издательствах опубликовал, причем, когда жил еще не в Москве, а скажем так, в Зажопинске. И ничего, пробился. А Вам, коренному москвичу, что-то мешает.
Несколько необычное представление о процессах нормализации и денормализации. Мне кажется, лучше на более простом примере рассмотреть Ваш вопрос, так как тип сущности "Коренной москвич" может осложнить обсуждение, просто из-за использования прилагательного. Прилагательные допускают различные интерпретации.

MX-9Товарищ Сталин,
Вы - большой ученый,
В языкознании познавший толк.
А я - простой cоветский заключенный
И мой товарищ - серый брянский волк ..
Здесь часто возникает такое предложение - не поддерживать целостность БД. Собственно, все NoSQL нового поколения так и работают. В этом Вы правы.

Шваров ЕвгенийЯ тоже за книгу.
Андрей Леонидович, материала - масса. Более того - есть примеры успешного практического опыта с реализованной объектной СУБД, построенной по вашей теории и несколько промышленных предприятий на ней работающих успешно и много лет по-моему до сих пор и не планирующих на что-то иное переходить.
И новые предприятия появляются. Но дело совсем не в этом. Здесь два совершенно разных направления. Одно дело написание книг. Это физически не возможно. Так как есть масса других проблем и их обсуждений, многие из которых более сложные, чем проблемы БД. Вот только несколько примеров:
http://www.gosbook.ru/node/29875
http://www.gosbook.ru/node/28059
http://www.gosbook.ru/node/28080
http://www.gosbook.ru/node/35384
http://www.gosbook.ru/node/29436
Еще 5 книг? А если все посмотреть, то 25?
И совсем другое дело, когда вместо обсуждения по существу даже самых простых вопросов говорят, вот будет в книге про это написано, тогда будем обсуждать. Совершенно не серьезно))
Шваров ЕвгенийА форумный способ изложения сложных идей, когда Вы за каждой фразой оставляете за скобками пару сотен страниц текста, которые "очевидны" только для вас - уже на протяжении нескольких лет в этом форуме приводят, на мой взгляд, к безрезультатной полемике на высоких тонах.
Не страшно. Уверен, что пусть один-два человека, но лучше стали понимать теорию и практику БД. И этого вполне достаточно.
Шваров ЕвгенийТем более, что все суть уже давно изложена в двух словах.
Цитирую:
1. В БД что-то должно отражать факт существования объекта независимо от его свойств.
2. Модель данных должна быть одна и та же на концептуальном и логическом уровнях.
3. Результатом запроса должна быть часть БД со всей присущей БД семантикой.
4. Содержательные метаданные (в рамках МД, удовлетворяющей пункту 2) должны поддерживаться на уровне БД.

И каждый из этих принципов раскрыт подробно, и при необходимости, раскрывается снова.
Шваров ЕвгенийИ ведь сделана была такая СУБД, с помощью которой можно было быстро разрабатывать, легко поддерживать и развивать сложные информационные системы. С UI были проблемы - но бекэнд был прекрасен. Почему бы не поделиться с сообществом теорией и практикой в формате книги?
Первую причину объяснил выше. Вторая - МД должна быть другая. Так что, конкретный продукт здесь не причем.
Шваров ЕвгенийС пиаром и распространением труда поддержим) А может быть - кикстартер?)
Может быть. Но не сейчас.

Блок А.Н....
Зависит от подходов к моделированию. Кстати, как вы относитесь к тернарным связям? Считаете, что это более общий случай бинарной связи?
Позволю себе повторить кратко факты о связях между типами сущностей.
1) Связи многие ко многим являются, как правило, результатом денормализации, для простого доступа в интерактивном интерфейсе. Например:
для схемы A-->B-->C<--D
в которой мы видим четыре типа сущности и три связи между ними, можно поддерживать связь
A<-->D
Разумеется, возникают затраты на поддержку целостности, как и при любой другой денормализации.
Попутно замечу, что у ViPRos в ВИПРОС реализована так называемая миграция свойств (автоматизирована денормализация, так сказать).
2) Связи другой мощности также часто являются результатом денормализации. Например, связь Имел жену/Являлась женой - многие ко многим, а связь Имеет жену/Является женой (конечно, если не допускается многоженство или многомужество) - один к одному, и может поддерживаться при вводе/удалении событий регистрации браков или разводов.
Это частный пример, по которому заблуждается Дейт (издание 8, раздел "Сравнительный анализ сущностей и связей", стр. 550).
3) Разумеется, если бы у связей были свойства, связи многие ко многим применялись бы на каждом шагу. Но у связей нет свойств.
4) Никаких n-арных связей не существует в принципе. Связи всегда бинарные и двунаправленные. См. о симметрии 13545785

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

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

Дейт пишет: "Здесь Кодд явно предлагает использовать отношения для моделирования и сущностей, и связей."

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