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

U-geneЯ сходил по Вашим ссылкам, посмотрел что там написано. Честно говоря я не заметил ничего, касающегося операций. Есть конечно некие попытки организовывать работу с коллекциями, используя FORALL. Но ИМХО это несерьезно. Если Вы пытаетесь что то предложить взамен Реляционной Модели Данных , Вы должны предложить аналогичные возможность - в том числе и для манипулировании данными. Нет, гнаться за РМД нет смысла . это тупиковый путь. Ведь в том-то и дело, что у нее есть ряд внутренних логических дефектов, от которых можно избавиться только, если взглянуть на природу данных по-другому. Кроме того, она перегружена мелкими деталями и ненужными операциями, т.е. это прежде всего низкоуровневая модель. Вопрос же в том, чтобы создать простую и высокоуровневую модель, которая может далее отображаться во что угодно, включая РМД. А для этого прежде всего надо отказаться от очень большой свободы РМД.

U-geneЕще раз повторю - нужно очень четко различать формальные модели и языки программирования. Если этого различия не делать, то, конечно, к РМД будут куча претензий. Например, причиной Вашей претензия в невозможности работать с иерархиями, лежит в том, что для Вас имена (отношений и атрибутов отношений) существующие в РМД неразличимы от имен языка. Поэтому Вы думаете, что ежели в РМД есть имя отношения R и имя атрибута A, то в системе , реализующей РМД, ничего глубже чем Х.Y мы изобразить не сможем (Вы заметили? R и A - это имена в смысле РМД, а X и Y - это имена в смысле системы - то есть это разные имена). По-моему, это игра слов, шаманство. При чем тут система (реализующая РМД)? Модель есть модель. Если мы говорим, что надо все данные распределить по разным отношениям, то значит так и надо делать, и никакой иерархии тут нет. Есть отношения и есть операции. Все. А если другая модель предложит хранить данные в виде многомерного куба со своими операциями, то значит это другая модель, даже если они друг в друга могут быть отображены. Важны изначальные принципы моделирования.



U-geneПонимаете, требование РМД что бы все данные были представлены как множество отношений вовсе не значит, что они должны быть явно описаны как множество отншений. Если РМД говорит, что надо разместить все имеющиеся данные по отношениям, то значит так и надо делать. Другого способа нет, поскольку ничего другого модель не предлагает. Слова явно или неявно там нет. Это все на бумаге. Мы говорим о принципах моделирования.

U-geneМы можем описать данные в системе как угодно (ИМХО почти как угодно), В системе да. А в модели нет, не можем. В РМД есть только отношения и операции, а понятия система в ней нет. Так что кроме отношений ничего нельзя использовать.

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

U-geneиспользовать ссылки, строить иерархии (здесь я перечислил только то, что, исходя из предыдущих сообщений, Вам интересно), Работать со ссылками и иерархиями это удобно, но знает ли об этом СУБД, вот в чем вопрос? Если не знает, то это действительно расширение, т.е. СУБД за эти структуры ответственности не несет. А если знает, тогда такая СУБД работает по другим принципам, возможно, расширяющими принципы РМД, но все равно это уже другая модель.

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

U-geneЭто можно определить как систему типов. Это можно определить как модель языка. Но это не модель данных в соответствии с определением модели данных. Ничего нового по сравнению с тем, что есть в РМД, здесь нет. Если есть ссылки, то это уже не РМД. Это можно было охарактеризовать как язык описания или язык доступа или как ОО расширение. Но модель это прежде всего ограничивающие принципы.

U-geneИменно поэтому я и говорю вам, что Ваши предложения по описанию предметной области никак РМД не противоречат.Я тоже не вижу противоречий. Это просто разные подходы, основанные на разных принципах с разной степенью удобности в разных применениях. Я уже упомянул, что в КоМ мы должны прежде всего упорядочить элементы данные, иначе система просто ничем не сможет помочь. КО системе не важно, есть ли там отношения, иерархии или еще что-то. Ей важно, что для каждого элемента есть родительские и дочерние элементы. Есть еще другая (двойственная) стороная этой же модели, где моделируются сами ссылки, т.е. средства для реализации связей.

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

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

1. Пресловутый механизм PK-FK. Изначально он разрабатывался как часть механизма констрейнтов. Но реальная его суть, что подтверждается использованием, в моделировании связей. Но для связей он весьма неудобен, как раз из-за изначальной цели. Получаем несоответствие (цели PK-FK их реальному применению).

2. Декартово произведение (JOIN) используется как основа для получения нужных данных. Формально никаких претензий нет. Но реально эту операцию есть смысл применять для независимых сущностей (ну как оси координат). Если же две сущности связаны ключем, то они зависимы. Конечно, таких понятий в РМД нет, а потому JOIN применяют как единственное средства для получения данных из связанных отношений. Проще говоря, основное применение JOIN в реализации связей PK-FK. Формальное все работает, но реально это совершенно неестественный подход. Получаем несоответствие (цели JOIN ее реальному применению).

Я еще раз хочу отметить, что это вовсе не претензии к РМД, которая внутренне вполне логична. Проблема в том, что этому подходу уже больше 30 лет, а за это время в мире данных уже все поменялось, а потому вполне естественно, что многие идеи и механизмы модели выглядят архаично и неестественно (что не мешает им правильно функционировать).

nerdery hereИМХО, сравнение вашего КОМ'a и РМД некорректно. Они просто на разных уровнях: КоМ - инфологическое моделирование (наряду с E-R, ObjectRoleModeling etc), РМД - даталогическое моделирование (как и сетевая и иерархическая модели). Ну не будете же вы сравнивать дизайн автомобиля с физикой двигателя внутреннего сгорания? С этим в целом я мог бы согласиться. Однако, в КОП есть принципиальные свойства, которые не укладываются в такую классификацию. Например:

1. Наличие формальной семантики (нет в РМД из-за слишком низкого уровня и нет в концептуальных моделях типа E-R из-за слишком высокого уровня). А ведь этот вопрос является одним из самых главных, поскольку при моделировании я хочу видеть данные как глобальную конструкцию.

2. КОП имеет две стороны: логическую (структура связей) и физическую (структура уровней). Вторая сторона это как раз то, что позволяет сделать модель многоуровневой. В частности, на нижнем уровне могут быть блоки диска, а на верхнем концептуальные сущности. Важно, что это единая модель. Как тогда ее позиционировать? Как физическую или как логическую? Именно поэтому я уже отметил, что классическое разделение на физический, логический и концептуальный уровни на данный момент не очень актуально. Более актуально понятие виртуализации и многоуровневости, т.е. как раз то, на что нацелена КОП. Там просто нет этих трех уровней, а есть возможность определить свои собственные виртуальные пространства на основе уже существующих пространств.

nerdery hereЧто предлагает для тех же проблем КОМ? :)Основная цель КОМ это моделирование, т.е. нам важно представить семантику данных и понимать, что наши данные означают. Языки (запросов, программирования) и расширения (API) это уже другой вопрос. В частности, я не вижу принципиальных проблем в том, чтобы все или некоторые перечисленные механизмы отобразить в КОМ, а не в РМД (п.4 это один из механизмов КОМ, поскольку он основан на семантике данных). Вопросы программирования на самом деле отделены от моделирования и рассматриваются в рамках концептно-ориентированного программирования (КОП). Впрочем, КОМ и КОП это две стороны одного и того же.

shuklin"Свобода" в РМД ? Ха, какая это свобода? Нет там никакой свободы. Под свободной понимается отсутствие ограничений на выполняемые действия, т.е. делай что хочешь и как хочешь и сам соответственно будешь отвечать за правильность результата. Например, есть в двух отношениях две целочисленные колонки. Что это? Связи, характеристики сущностей, поля битов? Да бог его знает. Для РМД это безразлично. Она об этом ничего не знает. Поэтому любой человек может как хочет соединять эти две таблицы, придавая совершенно любую интерпретацию этим полям. А почему бы и нет - ведь в этом мире смысла и предназначения данных просто нет, а потому можно делать все.

То же самое в ассемблере. Есть 32-битное число. Что это: адрес или счетчик или биты? Это знает только программист, кто и отвечает за правильность кода. Если поместить это число в один регистр, то это будет указатель на код. Если в другой регистр, то указатель на данные. Если в третий регистр, то указатель на стек. В четвертом это же самое число будет уже аргументом операции, т.е. данными. Крутой подход? Да, но только для низкоуровневого программирования. То же самое с РМД. Делай что хочешь и никаких ограничений.

А вот более высокоуровневая модель это всегда ограничения и дисциплина (либо прописанная на бумаге, либо реализованная в системе).

shuklinСеть моделирует РМД без метаперехода, а РМД моделирует сеть с метапереходом. А что такое метапереход?

shuklin=> в сетевой модели и возможностей и свободы больше чем в РМД.Это не свобода. Это простота при описании сложных моделей. Так в ООП свободы меньше, но зато он проще по сравнению с машинными кодами. Как, например, в сетевой модели просуммировать значения всех ссылок на А, а потом найти объект, ссылающийся на Б с помощью ссылки, равной этой сумме? Наверное нельзя. А в РМД можно! Зачем такие задачи нужны никто не знает, но в РМД это все-равно можно сделать. Но главная проблема не в том, что это можно, а то, что такая задача ничем не отличается по виду от вполне осмысленных операций, поскольку это просто операции с данными без всякого смысла. Низкий уровень - ничего не поделаешь.

okdokyЧтобы этот язык был универсальным, необходимо чтобы он работал, кроме реляционных с объектными, иерархическими и прочими данными. Все, что нужно: система, кроме SQL, должна понимать в частности языковые конструкции из XPath и ОО языков.
Например:
Переводится: Отобразить все атрибуты * объектов полученных в результате выполнения метода m() над объектами Y, принадлежащих X и имеющих Z=’1’
Хороший пример. Для демонстрации того, как не надо делать. Он развивает худшие традиции SQL, поскольку в одной строке фактически смешаны четыре важные конструкции запроса:
1. Описание исходного пространства: X
2. Выборка нужных элементов: Y из X
3. Выполнение действий над объектами исходного пространства: метод m()
4. Описание возвращаемых компонент: *

Вот как бы я это записал:

Так намного естественнее и понятнее, поскольку здесь проглядывается аналогия с обычными циклами (только внешняя, поскольку трансляция такого "цикла" зависит от компилятора). Вот более общая форма запроса:


Здесь ясно, что обрабатываются элементы исходного двумерного пространства X x Z. Но выбираются только те, что удовлетворяют двум свойствам. Далее для каждого из них вычисляются целое значение и коллекция. Потом возвращается коллекция целых чисел. Важно, что все шаги отделены и нет никакой криптографии.

Но здесь кроме криптографии видно другое, о чем уже говорилось. В SQL (что идет от РМД) в FROM указываются все таблицы, которые участвуют в запросе без разбора их роли. В описанном выше подходе указываются только исходные независимые таблицы (любые коллекции). А те таблицы, которые привязываются по свойствам совершенно в FROM/FORALL не нужны - они появляются только в теле запроса (например, Table3 и Table10). Это один из тех пресловутых "дефектов" или недостатках, о которых я тут пытаюсь говорить. У каждой таблицы в запросе есть роль, которую надо отобразить в структуре запроса. А в SQL этого нет, поскольку РМД не делает различий между ролью независимых и привязанных таблиц. В результате для сложных запросов FROM может содержать десятки таблиц, которые по смыслу там совершенно лишние. В последнем примере запроса на SQL включал бы все 4 таблицы во FROM, тогда как по смыслу надо только 2, а остальные 2 нужны только для нахождения каких-то свойств. Подход SQL более прямолинеен и более дубовый, а на практике приводит к серьезным трудностям для обычного рядового или даже сержанта на SQL-фронте.

okdokyВ конструкции FROM мы не обязаны указывать имена отношений. Да и нужны ли они вообще? Для примера, в Zigzag имена отношений отсутствуют, в том виде в каком это понимает РМД (имена таблиц). Эти таблицы генерятся. Фактически БД Зигзаг, это классы связанных между собой объектов. То есть данные уже хранятся , как результат того самого NATURAL JOIN, о котором говорил mir.

Во FROM/FORALL должны храниться ссылки на исходные коллекции, будь то статические таблицы, локальные (промежуточные) коллекции или просто коллекция значений, указанная в строке. А имя переменой рядом со ссылкой на коллекцию дает в теле запроса ссылку на очередной элемент в исходном пространстве.

okdokyP.S.
Александр: на последний респонс от mir ответить действительно нечем. Не спеши. Подумай. Все таки у точечной нотации есть плюсы. Чем то она напоминает конструкции из XPath /// Я вообще не нашел на что там отвечать. Там нет вопросов, а есть просто очередной набор обвинений. Это человек-НЕ, спорить с ним невозможно, поскольку там нет мнения и нет аргументов, а есть отрицания в стиле "это не так, потому что вы некомпетентны".

mir okdokyВ конструкции FROM мы не обязаны указывать имена отношений. Да и нужны ли они вообще?Имена переменных отношений -- нужны. Сам FROM -- не нужен. FROM это то, с чего начинается любой запрос к данным, поскольку именно здесь указываются исходные коллекции вместе с именами переменных. Убрать его никак нельзя (разве только для целей РМД). Соответственно без имен коллекций тоже нельзя обойтись (это могут быть статические таблицы или любые другие ссылки на коллекции данных). Например, конструкция
означает создание n-мерного пространства, над элементами которого можно выполнять действия (обычно выборку). Но лучше это записать в привычном всем виде как самый первый элемент запроса:
Теперь понятно, почему убрать FROM нельзя без потери естественности восприятия и простоты выражения запросов?

mirЗамечательный пример! Декларативный язык 4 поколения (SQL) предлагается заменить навигационным языком (т.е. 3 поколения), с необходимостью явно программировать циклы. Регресс в кристалльно чистом виде. Откуда Вы увидели, что это не декларативный язык? Такой запрос можно легко транслировать в SQL или в другую форму. Это от транслятора зависит. Ключевое слово FORALL это всего лишь внешнее сходство (почему-то Вы любите рассматривать все поверхностно). Никто не обязан делать перебор записей (хотя на том или ином уровне он все равно будет сделан). Так что это замечание не относится к делу (как и большинство других).

mirИстория людей ничему не учит... История учит, что декларативный подход умер, поскольку люди (разработчики) так не мыслят, поскольку это неудобно, поскольку противоестественно. Пример: Пролог. Заметьте еще раз, что Пролог формально безупречен как и РМД, но это вовсе не значит, что у него нет недостатков. Если он неудобен для написания программ, значит он плох. То же самое с РМД. Если эта модель неудобна где-то и как-то, то значит так и надо сказать, а не прятаться за формальной корректностью или валить все на нерадивых разработчиков.

mir Александр СавиновВ SQL (что идет от РМД) в FROM указываются все таблицы, которые участвуют в запросе без разбора их роли. В FROM не обязательно «указываются все таблицы, которые участвуют в запросе без разбора их роли». Для вас будет открытием, что таблицы могут появляться в запросе не только во FROM, но и внутри предложений SELECT и WHERE.
Строго говоря, FROM есть операция декартова произведения, а вовсе не «перечисление» таблиц, как кажется дилетантам. Правильно, я это и хотел сказать. А именно, для реализации связей в РМД предлагается строить декартово произведение, что есть попросту глупо. В результате во FROM включаются как независимые таблицы, так и таблицы, которые так или иначе связаны с исходными. Мухи и котлеты все вместе в одном FROM. И Вы говорите, что это хорошо? Подумайте в новом году над этим.

mir Предложение FROM (как и весь синтаксис SQL) есть наследие первых авторов SQL, которые очень торопились состряпать язык для РСУБД, но не потрудились хорошенько подумать над его дизайном и теорией (РМД) в целом. Ну вот опять попытка свалить на кого-то почему все так плохо сейчас. Мы же о ПРИНЦИПАХ модели говорим. А один из этих принципов говорит, что для нахождения связанных записей надо строить декартово произведение, для которого есть другое прямое применение: построение многомерного пространства из исходных таблиц. Так вот, в РМД эти роли никак не различаются. А конкретный диалект языка никак не меняет эту ситуацию. Это принципиальный недостаток модели как таковой.

mir Александр СавиновА в SQL этого нет, поскольку РМД не делает различий между ролью независимых и привязанных таблиц. В результате для сложных запросов FROM может содержать десятки таблиц, которые по смыслу там совершенно лишние.
Оценить подобный перл можно по следующей аналогии: в арифметических выражениях алгебра не делает различий между числами, поэтому может содержать числа, которые там совершенно лишние. Ну тогда сведите все к операциям на процессоре, и скажите, что это и есть лучшая модель данных. А если кто возразит, что где же там данные, то Вы ответьте, что процессор не должен это знать, а должен просто загружать байты из памяти и оперировать ими, а соответственно претензии не принимаются. Глупость очевидная, но Вы почему-то упорно мыслите именно так.

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

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

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

U-geneНу если в ранних версиях SQL-я не было возможности определять свои собственные скалярные типы, то это не есть недостаток РМД - это есть недостаток реализации. Ведь точно так же в любом языке програмирования Вы можете определить целочисленные переменные "адрес" и "счетчик", и что же - неужели Вы потом скажете, что возможность сложить эти два значенияя есть недостаток арифметики, что де она черезчур гибкая? Речь идет о том, что РМД не накладывает никаких ограничений на выполняемые операции с данными. В частности, в ней нет понятия связи. Или это тоже можно устранить с помощью "если". Мне определенно нравится Ваш подход к критике.

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

U-gene Александр Савинов U-gene использовать ссылки, строить иерархии (здесь я перечислил только то, что, исходя из предыдущих сообщений, Вам интересно),
Работать со ссылками и иерархиями это удобно, но знает ли об этом СУБД, вот в чем вопрос? Если не знает, то это действительно расширение, т.е. СУБД за эти структуры ответственности не несет. А если знает, тогда такая СУБД работает по другим принципам, возможно, расширяющими принципы РМД, но все равно это уже другая модель. Всё наоборот. Я (и другие) уже говороли, что ссылки - это механизм, который реализуется системой (то есть система про них точно знает). А модель как раз та же самая, потому как языковое выражение, включающее точки или стрелочки рассматривается всего лишь как имя отношения или атрибута отношения. Не надо увиливать и оправдываться. Мы тут решили, что ссылки это часть данных как минимум, а может и бОльшая часть данных. В любом случае ссылки надо уметь моделировать. Вообще, вот Вам напутствие на 2007 год:

Данные не могут существовать вне пространства (контекста), а пространство это прежде всего ссылки.

Т.е. данные без ссылок попросту не имеют смысла, это нонсенс. Когда Вы это поймете, то у Вас спадут реляционные шоры с глаз и Вы увидите мир данных совершенно в другом свете. Успехов!

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

U-gene Александр СавиновДекартово произведение (JOIN) ВАУ!Сильный ход. Боюсь только, что в ответ на это мое замечание, Вы скажете, что я тоже человек-НЕ и использую только аргументы типа "это не так, потому что вы некомпетентны". Нет, я скажу, что Вы человек-ВАУ :-) Но это существенно лучше, поскольку у Вас есть способность удивляться :-) а вот mir ее уже похоже потерял. Ну действительно, в реляционном мире, где все идеально, где не может быть недостатков, а все новое спускается сверху в виде нового учения чучхе или Tutorial, уже нечему удивляться. Мне кстати жаль, что я высказал некоторые сомнения в правильности учения и нарушил реляционную идиллию. Но ведь проблема не во мне. Оглянитесь вокруг. Вы считаете, что в фирмах идиоты сидят, которые не ведают что творят и имеют целью испортить идеальную РМД? Да нет же. Все развивается. И что было хорошо 30 или 20 лет назад, может стать просто неудобным из-за низкого уровня. Так что не надо меня сильно ругать, а лучше взгляните на мир данных честно без религиозных предубеждений в идеальности реляционного учения.

U-gene Александ СавиновИстория учит, что декларативный подход умер, поскольку люди (разработчики) так не мыслят Друг мой, это уже даже и не смешно. Я например именно так мыслю. Вот у меня ребята сидят - стороннии разаработчики приложений для весьма изветсной ERP системы со своим собственным языком, средствами построеняи отчетов и тп.п. Так вот - они были рады как дети, когда поняли, что вместо того, что бы ползать по записям, они могут сляпать SQL запрос для используемого сервера, а результат вывести в EXCEL. И все это по времени в десятки раз быстрее получается. Ну и что? А я знаю людей, который радуются как дети, когда им на ассемблере дают попрограммить. Мало ли что в мире применяется. Я говорю, что Пролог умер. Это факт. А вместе с ним и великая идея, в которую кстати вбухали огромные деньги и за которую рубились на смерть такие же фанатики. Но главное, что я хочу донести здесь без всякого успеха это то, что формальная чистота вовсе не означает удобности, естественности и полезности. Вот и все.

U-gene... Вы ни одной книги про РМД не прочитали, и что Вы ни одного аспекта SQL не знаете. ... И Вы туда же :-) Ух, заразно это, однако. Ну я Вам помогу. я даже не член партии и в мавзолее не был, не то что книжки какие-то читать. :-)

U-geneС Новым Годом! :) С новым.

vadiminfo Александр Савинов История людей ничему не учит... История учит, что декларативный подход умер, поскольку люди (разработчики) так не мыслят, поскольку это неудобно, поскольку противоестественно. Пример: Пролог. Заметьте еще раз, что Пролог формально безупречен как и РМД, но это вовсе не значит, что у него нет недостатков. Если он неудобен для написания программ, значит он плох. То же самое с РМД. Если эта модель неудобна где-то и как-то, то значит так и надо сказать, а не прятаться за формальной корректностью или валить все на нерадивых разработчиков.

Этому история учит только проггеров на процедурных языках. Пролог для написания решения задач ИИ много лучше процедурных языков. Точно так же РМД лучше для БД. А для написания окон - они хуже процедурных универсальных языков. Т.е. в ИИ, например, задачи могут решать на Прологе, Липсе, а потом для реализации прог каких-то там отдают обычным проггерам. А для БД - языки БД и в последствии не нуждаются в замене, если МД приличная. Впрочем, при определенных достижениях в ИИ может прийти еще время Пролога и Липса и для конечных прог. О, золотые слова! Это то, чего я хочу донести, т.е. многополярный мир без блатных или избранных. Любой подход может быть удобным или неудобным, адекватным или неадекватным. Любой подход можно критиковать, в том числе формально безупречный (как Пролог или РМД). За это и выпьем.

U-gene Александр СавиновНу действительно, в реляционном мире, где все идеально, где не может быть недостатков, а все новое спускается сверху в виде нового учения чучхе или Tutorial, уже нечему удивляться. А там вообще ничего нового нет. Голая теория множеств. Действительно удивлятся нечему. Знать надо. Ну вот опять Вы за старое взялись: РМД это теория множеств. А зачем тогда РМД, если теория множеств уже существовала? Ах ну да, забыл, чтобы критику отмести. Вообще, не стоит теорию множеств в суе упоминать. Если математики услышат, что в РМД понимают под теорией множеств, то они умрут от смеха. Использование пересечения и объединения наборов элементов еще не говорит об использовании теории множеств, ну или по крайней мере тогда все ее используют. Я не знаю, знаете Вы или нет, но проблема, в которой используются конечные или даже счетные множества, математиками даже проблемой не считается. А уж то, что рассматривается в РМД это вообще для математика пшик. Ну или Вы под математикой понимаете вычисление движениея товара в ERP понимаете? :-) Ну тогда ладно.

U-gene Александр СавиновМне кстати жаль, что я высказал некоторые сомнения в правильности учения и нарушил реляционную идиллию. ВАУ! Вы действительно считаете себя таким крутым? ой, боюсь я, что Вы ее не нарушили А чего же Вы тогда так злитесь? Значит нарушил. :-)

U-gene Александр СавиновНо ведь проблема не во мне. Оглянитесь вокруг. Вы считаете, что в фирмах идиоты сидят, которые не ведают что творят и имеют целью испортить идеальную РМД? Мне кажется, основная цель - сделать удобную систему. Основная цель сделать удобным моделирование данных. Пользователи недовольны. Ученые могут на это наплевать, а вот фирма не может, и должна что-то предпринять. Соответственно, они постоянно прикручивают к своей системе новые механизмы для поддержания каких-то новых методов и подходов. При этом курочат РМД, получая некий гибрид методов. Вопрос: зачем? Чтобы сделать хуже для РМД? Из-за глупости? Да нет же. Там сидят очень толковые парни, которые знают что и зачем делают. Просто без новых методов и подходов они не продадут свой товар. Значит есть потребность. Не в языках и системах, а именно в новых методах и подходах.

U-geneТогда вся математика - это религия.Я не хочу Вас расстраивать, но в математике тоже ведутся очень большие споры, причем вовсе не по поводу формальной корректности. А иначе мы бы до сих пор геометрией Эвклида пользовались бы или вообще ничего не было бы. Я как раз Вам и хочу донести мысль, что если обычная геометрия работает и корректна, то это не значит, что нет другой геометрии, более удобной, более адекватной и более общей. Попробуйте вернуться на пару сотен лет назад и объяснить кому-то, что кроме обычных чисел могут быть еще какие-то комплексные. Вас тут же на костре сожгут просто за саму постановку вопроса. Так что (очередная) аппеляция к математике не проходит.

U-gene Александр СавиновНо главное, что я хочу донести здесь без всякого успеха это то, что формальная чистота вовсе не означает удобности, естественности и полезности.
Друг мой, такое осЧусЧение, чтоВы живете в миер населенном враждебными призраками, с которыми постянно боритесь :). Зачем? Все тут в один голос сказали, что язык управления системой хранения должнем быть многополярным и обладать многими возможностями. Вообще-то, все в один голос говорят, что мы не обсуждаем языки и системы, а обсуждаем модели данных и только модели данных. Либо Вы не понимаете в чем разница либо слушаете только себя, поскольку очередной раз поднимаете один и тот же вопрос.

mir Предложение FROM (как и весь синтаксис SQL) есть наследие первых авторов SQL, которые очень торопились состряпать язык для РСУБД, но не потрудились хорошенько подумать над его дизайном и теорией (РМД) в целом. О боже, что я слышу. Так проблемы все-таки могут быть. Я не верю. Вы уже праздновать что ли начали?

mirУ SQL есть многочисленные недостатки, но SQL не есть РМД. Можно изобрести и другой реляционный подъязык, более удобный и компактный, но надо отличать дефекты модели данных и дефекты синтаксиса конкретного языка. Вам это давно пытаются втолковать, но вы не видите разницы. Это особый род избирательной слепоты. Ну опять Вы старую песню затянули, мол все проблемы от SQL, а РМД чиста. Мы же уже договорились, что обсуждаем принципы моделирования. А Вы никак не можете их отличить от языка и систем.

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

mirНо ведь вы действительно некомпетентны. Или вам привести сводный список ваших перлов? Из последних: "JOIN — это декартово произведение". Может еще список опечаток в качестве компромата приведете? Вообще-то, во всех предметных спорах Вы проиграли. Но в конце всегда убегали со словами "а РМД все равно самая лучшая, поскольку основана на теории множеств, а плохие это языки и системы". А свои ошибки, на которые Вам здесь постоянно указывают, Вы почему-то не хотите исправлять. Вы похожи на человека, который в качестве аргумента говорит, что "я это в газете прочитал". Научитесь думать своей головой и делать свои собственные выводы, вместо того, чтобы чужие мысли повторять, тем более, если Вы не понимаете их суть. Как говорится, РМД это не догма, а руководство к действию. А вот для Вас это догма.

Я в самом начале понял: зря заново открыли это обсуждение. От такого широкого спектра мнений у многих простых граждан, привыкших к наличию только одного мнения и одной теории, крыша едет. Но раз так получилось, то надо как-то закругляться. Поэтому я сделал небольшое резюме, исключив частные вопросы.

Легализация ссылок. Ссылки должны выйти из подполья и стать гражданами первого сорта наравне с объектами, которые они представляют. Ссылки должны присутствовать в модели данных и для них должны иметься адекватные средства описания. РМД: ссылки не имеют значения и не должны моделироваться.

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

Структура пространства. Данные не могут существовать вне пространства, а потому нужны адекватные средства для моделирования его структуры. Более того, бОльшая часть моделирования собственно сводится к описанию структуры пространства, где живут данные. Например, важно иметь средства для описания иерархий или многомерных пространств. РМД: модель данных не предполагает никаких особых структур. Есть просто набор операций, которые применяются для любых целей.

Я также ради интереса создал классификацию для всех персонажей в данном обсуждении (если кого-то забыл или не в ту категорию включил, то не серчайте - в этом мире все условно, даже РМД).

Созидатели эволюционисты (есть способ лучше, я знаю как): shuklin, okdoky, я
Разумно мыслящие (проблемы есть и их надо как-то решать): мод, ModelR
Практики (если это когда-то заработает, то почему бы и нет, но пока в гробу я видал любые новшества): vadiminfo, 4321, !
Революционеры подпольщики (запрещены по идеологическим причинам): ЧАЛ
Непримиримые фундаменталисты (п.1 проблем нет, п.2 если они есть, то см. п.1, все уже давно создано до нас, только не трогай святое): mir, U-gene,
Ликующий народ (хлеба и зрелищ): Gluk (Kazan), 7
Местная шпана и засранцы (грозное тявканье из подворотни): Пьяный Лох

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