mir
Все мы понимаем, что XML-СУБД не более чем очередной нежизнеспособный маркетинговый уродец.

Все таки для такого прогноза нужны основания. Официально XML декларируется как полуструктурированная модель данных, и ведущие производители СУБД спешат втюхать ее поддрержку в свои системы. Есть, например, приложения, которые работают с документами, и дела там обстоят не очень. Структурированные модели данных помочь сильно не могут. Вот XML там может что-то налабать кое-что в некоторых случаях.
Другое дело что такое XML-СУБД? Есть ли конкретные примеры таких СУБД? В чистых документных системах не было СУБД раньше (но там и модели данных речь не шла). Там были тока информационно поисковые системы вместо этого.
Кроме того, с производительностью при разборе больших XML документов, и трансформации их в другие форматы, тоже пока есть вроде проблемы.

White Owl
Или в качестве основания принимается толькр статья в толстом журнале?

В толстых книгах. И то там как правило избегают жестких прогнозов.

White Owl
Ну положим не столько "полуструктурированя" сколько "древовидная".

Именно полуструктурированная, которая противопоставляется структурированным: реляционным, объектно-ориентированным и проч. В том числе и иерархическим, которые можно как-то отнести к древовидным, хотя в явном виде такого термина в отношении моделей данных не встречал.
Они противопоставляются в том смысле, что изменеие структуры в структурированной МД , например, изменение типа записи в иерархической, означает, что мы уже фромально, а в общем случае и не формально имеем дело с другой БД.
ХМЛ менее чувствительна к появлению новых тегов. Интерпритация данных и сами данные там менее оторваны друг от друга, чем в структурированных.

White Owl
xml-субд это такие СУБД, в которых обращение к данным идет как к ветвям дерева. То есть не SQL или какой-нибудь другой язык работающий с массивами, а обход дерева в чистом виде. Чтобы например найти записи по накладной надо найти ветвь документов, в ней находим ветвь накладных, в ней ищем ветвь конкретной накладной, а потом выдаем пользователю все ветви находящиеся на этой найденой.


Это Вы всетаки описываете что-то типа навигации в иерархических СУБД. Такие СУБД хорошо известны. А вот про xml пока в толстых хоть книгах, хоть журналах не встречал.

>Судьба иерархических БД и есть такое основание. Как говорил один из присутсвующих без ссылок на первоисточники "общественная практика есть критерий истины". (С)

Во-первых, с судьбой иерархических не все ясно. Они, например, в каком-то виде попали в ООСУБД. Но все еще думаю, что XML не сводится к иерархическим. Подкину Вам еще ссылку на первоисточник :"Третий закон диалектики - Отрицание отрицания" Иерархические могут через отрицание появиться в новом качестве.
Мы не можем это игнорировать.

Джаву тоже сначала всунули в сайбейз АСА как язык сохраненок, потом отказались.
А в Оракле она до сих пор. И, например, если надо из Оракла убить процесс или посмотреть свободное место на дисках, без использования тулсов в ОС, это Джава поможет. Не говоря уже о всяких навороченных интерпрайсных технологиях (EJB), если кому надо.

А что такое полуструктурированные? Вообще ХМЛ элементарно пишется в реляциьнной БД, не как поле типа ХМЛ, а именно в таблицах, так что выигрыш врядли получится.
Писал выше в этом посту. Таблицу поменять - другая БД. Так как она входит в структуру, а структура наиболее статичная часть системы в силу своего пределения. А теги добавить - все таже.

mir
но вы взялись рассуждать о предмете, в котором мало понимаете

Ну, я как раз здесь для того, чтобы понимать больше, чем теперь.
У меня на данный момент есть те сведения, что я высказал.
Если в них есть ошибки, то надеюсь их прояснят.
В Толстых и тонких книгах про технологии XML читал, особенно в плане Оракла. На практике сталкиваюсь с XML. Поэтому тем более мне все мысли про это интересны. А если не рассуждать, то что можно узнать?

mir
Дело в том, что термин "плоские", а хуже того - "двумерные" - таблицы часто применяют вследствие невежества. Просто реляционные таблицы не имеют измерений как таковых. Этот термин к ним неприменим. Строки в них неупорядочены, атрибуты тоже. Кроме того, каждая запись реляционной таблицы с N столбцами является точкой N-мерного пространства (вектор из N компонент).

Как посмотреть. Када речь заходит о пространствах, то нужно указывать о каком именно речь идет. И какая польза от применения того ли иного пространства. Двухмерная таблица в пространстве где одна координата столбцы, другая - записи. И ее можно нарисовать на листе - на плоскости (в двухмерном пространстве). Это существенно с точки зрения представления данных. А что дает N-мерное пространство в данном случае не ясно (и что это за пространство, мы же не собираемся складывать там эти вектора, стал быть не векторное). Тем более такую N-мерность можно связать с отношениями. А таблицы - всего лишь представления отношений, в данном случае плоские (представления).

fanat_FOXa
Просто обратных утверждений в этом топике хватает, хотелось бы объективности ради ознакомиться и примерами упомянутого выигрыша в поиске по XML-базе.

Вообще-то там речь шла о выигрыше иерархической базы, а не XML-базы.
Две большие разницы. Иерархические это те, что господствали в дореляционную эпоху (наряду с сетевыми). Известным примером иерархической СУБД является IMS фирмы IBM. И до 1986 года они действительно в скорости значительно выигрывали. Вплоть до того, что РСУБД не претендовали поддерживать OLTP системы до 1986 года. (В 1986 Сибэйс впервые выпустил OLTP РСУБД). Однако, с тех пор все изменилось. Но и в настоящее время одним из направлений развития РСУБД является совершенствование производительности.
Что касается XML-базы, то это как раз что-то новое, типа постреляционное.
Но пока о ее выигрыше в скорости, вроде, никто не говорил. Мож я пропустил что? Более того, возможно, она несколько для других задач, чем "плоские" БД.

c127
Знать бы что такое ООСУБД. Но это мы уже обсуждали.

К какому типу СУБД Вы отеносите, к примеру, Версантовские продкты?

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

В чем-то проигрыш у всех есть.
Вопрос в том нет ли областей, в которых выигрыш проявляется? Пусть хоть и узкий класс, как Вы говорите. Но дело не в иерархическом.
Иерархическое можно найти и в РМД. Например, унарная связь. Часто употребляют термины предок потомок. В Оракле есть иерархические запросы. Этого не достаточно. Там есть еще кое-что. Я вот Вам намекал - полуструктурированная модель. Нет у такой модели заранее фиксированной схемы. (У иерархических БД - IMS есть). Это бОльшая гибкость.

c127
Не знаком с диалектикой, как и с ООБД, я больше по математике.

А между тем, кое-что в математике сделали именно диалектики - Декарт, Рассел.

c127
Не нужно менять таблицы. Посмотрите ЛДАП в исполнении М$ на МС СКЛ сервере, там 6 или 7 таблиц, реализована фактически иерархическая БД, ничего не меняется. Впихнуть туда ХМЛ ничего не стоит.

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


fanat_FOXa
С того расстояния на котором я "нахожусь" от XML-баз и от иерархических баз они все "сливаются" в одну точку :)


А между тем между ними пропасть с близкого расстояния, которую я пытался Вам описать в пред посте.

fanat_FOXa
Или я неправильно понял (Конечно, если считать XML-базы и иерархические "близкими" понятиями.):

Да, наверное, Вы не обратили внимание, на упоминаемые у Bald слова про физические ссылки. Это именно к иерархическим относится, ну и к ООСУБД.
Но врядли к XML. Он чисто логическая. В ней мало физичекого, я думаю.
А Вы говорите - одна точка. Пропасть там. Помяните мое слово.

c127
Ни к каким, это вообще не СУБД, мы же вроде выяснили, там транзакции (или правила целостности или еще что-то еще очень важное, лень искать) распределены между сервером и клиентом.

Ну, при таком подходе многие СУБД, в том числе и реляционные, окажутся вообще не СУБД. Например, у Аксцесса нет триггеров.

c127
Так в том же и дело, что прикладные задачи как раз очень редко укладываюстя в иерархическую схему. И что еще хуже, те, которые вроде сначала укладываются, при расширении, которое всегда рано или поздно происходит, тоже уходят из этой области.

Это вопрос сложных исследований, времени. А пока, мне кажется, лучше всех их посчитать, до момента их окончательной отмены или снятия с производства. Тем более, что рациональные их зерна пытаются использовать основные производители. ХМЛ, ООП втюхивают и в Оракл и в Скуль, к примеру.

c127
Посмотрите ЛДАП, там это все есть и структура БД не меняется. Но можно не смотреть, принцип по-моему очевиден.

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

c127
Для меня все что можно записать в реляционной схеме - реляционно.

Но не всегда рел модель данных. А именно модель фундамент БД. Без нее понимать что в этой БД ломновато будет.

c127
Это для Вас они диалектики, а для меня они математики. :) Они же это кое-что сделали в МАТЕМАТИКЕ. Хотя они скорее философы, а не диалектитки, но это опять же слова.


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


c127
Метаданные тоже можно записать в реляционной схеме. Весь ХМЛ, без исключения, вместе со всеми "данными о данных", причем при изменении ХМЛ схемы структуру таблиц менять не нужно. Чем не полуструктурированные данные?

Если полуструктурированные, тока благодаря тому что там в такой форме представлен ХМЛ, а РМД. Вы вот пример про ленту приводили, что на нее можно таблу записать. Но от этого лента не станет таблой. Так и здесь.

Кстати одно из достоинств ХМЛ, что существуют стандартизованные методы его отображения во многие форматы в достаточны выразительном виде. Хотя это напрямую к вопросу МД может и не относится, но говорит о том, что на него сделали ставку в инфотехнолгиях. SQL, например, не нравится Дейту, но из-за этого он теперь уже не сойдет в небытие.

fanat_FOXa
Очень далеко ушедшие от реального уровня юзеров.

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

c127
А где я говорил про триггеры? Есть определение СУБД, не бязательно реляционной, данное Коддом по-меому, оно тут многократно цитировалось.Там гаворится что СУБД должна поддерживать целостность данных и еще много чего. Версант на сервере целостность не поддерживает. Следовательно сервер без клиента не СУБД. Можно к серверу прилепить клиент и это все попытаться назвать сервером, как это делал Alexey Rovdo, но тогда нарушается другой пункт этого определения, что доступ к данным осуществляется токлько через сервер. Вы же участвовали в этой дискуссии и по-моему доказывали что версант не СУБД.

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

Я высказывал мысли, что Мумпс не СУБД. Это было. Так он и в литре упоминается как язык программирования, а не СУБД.

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

c127
Какие исследования, уже обожглись один раз, на иерархической модели, зачем еще раз наступать на те же грабли. Бедная модель, почти ничего туда хорошо не ложится. Техника стала лучше с шестидесятых годов, но проблема была не в технике, а в модели, а она не изменилась, т.е. дергаться в этом направлении смысла нет. А для некоторых задач она используется, слышал что как-то там юзеры через ЛДАП логинятся в оракл, говорят получается быстрее, но подробностей не знаю.

Имеет значение именно та иерархическая модель на, которой "обожглись".(Хотя как посмотреть - это важный этап в ИТ технолгиях). Она имеет недостатеки именно на тех же задачах, на которых имеет соотвествующие достоинства РМД. И не имеет явных преимуществ на других задачах. В частности, она тоже сильнотипизированная модель данных. У нее нет преимущества в гибкости, как у ХМЛ. И на некоторых задачах эти преимущества могут проявиться. Поэтому из истории иерархических БД нельзя однозначно вывести неуспех нигде ХМЛ.
Тем более там же не дураки сидят. Стали бы они развивать технологию, если так просто можно было вывести ее неуспех.


c127
Что касается ОО у оракла и прочих, то чего не сделаешь ради денег. Маркетинг называется. Я пробовал применять ОО фишки оракла, ничего хорошего, сплошные проблемы. Реляционными методами все делается гораздо легче.

Но то, что сегодня нельзя получить ничего хорошего, не означает что и завтра не получат. В Орале ОО развивается от версии к версии. Сегодня да - там много ограничений. Например, не приятно, что такие типы не могут участвовать в репликации. Ну какое это имеет отношение к самому ОО? Я считаю, что они просто специально хотят навредить русским.) Кто еще будет применять ОО, или все что Оракл понапихал, не выясняя заранее всех обстоятельств?

Кстати, забыл ответить про иерархические запросы в Оракле. Там именно иерархические. Рекурсивных они, по крайней мере, на 9 еще не втюхали. Конструкцию WITH уже вставили, а до конца дело не довели. (Ну не гады?)

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



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

В реляционной нет. Но она есть в реальном мире и ее моделируем с помощью таблиц (или отношений, если последовательно надо). Модель данных представляет сущности (хотите объекты) реального мира. Отсюда и про соттветсвие.

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

c127
А что такое философия? На западе кандидаты физ-мат, химических, биологических, лингвистических и некоторых других наук называюстя докторами философии. Т.е. по их понятия эти все науки и есть философия, в том числе и математика. А отдельных специалистов-философов у них нет, это у нас бездельники слетелись на сладкое, а теперь шара закончилась и они ноют, что при большевиках жить было лучше.

Тем более. Я же Вам и грил, что ее не стоит игнорировать как минимум математикам. Конечно, я в серьез этого не утверждаю. Так мои предположения. Впрочем, ее же не зря в высшее образование включают.

О том что такое философия, и что там диалектика можно конечно долго грить и ни до чего не договориться. Но все-таки наиболее общие законы развития могут помочь. В частности, отрицание отрицания. Была иерархическая модель. Он господствовала (наряду с сетевой). Ну не менее 10 лет, хотя и не более 20.
Потом появилась Рел модель - отрицание. Что будет дальше? Должно быть отрицание орицания. Стал быть можно допустить появление иерархической в новом качестве. Конечно, может я не правильно применил этот закон. Но на размышления это наводит. В частности, при выяснении подробностей про ООСУБД, мы увидели, что там есть полезные признаки иерархических. Например, физические ссылки.
Правда, если более точно применять закон, то в этом новом должна все равно как-то проявиться Рел модель. Что-то от нее рационального.
Ну хоть можно что-то пытаться предполагать. Поди плохо?

c127
Акцес тоже не СУБД, я об этом говорил. Не верите - читайте

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

c127
В реальном мире тем более нет, там вообще нет определений.

Ну может тогда нет и самого реального мира, раз определений нет? И самих определений тоже нет, так как рано или поздно мы нарвемся на что-то не определяемое в его опрделении? А Вы говорите, что философия не Ваше кредо. Вот она самая.
Хорошо, возьмем пока реальный мир в ковычки "Реальный мир".

c127
А где сказано, что колонки должны соответствовать свойствам сущностей?

Вот тут на форуме полно споров о суррогатных ключах. А ведь главная проблема этих ключей, что они не соответсвуют никакому свойству сущности.
Т.е. появляется термин суррогатное свойство. Искусствено привистованное.
Это ухудшает модель. В пределе, если в модели нет нет ни свойств, ни сущностей, то модель слишком плоха, чтобы называться моделью. Зато термин формат к этому равнодушен.
Если модель данных нужна не для того, чтобы представлять "реальный мир" объектов и событий и связей между ними (а они имеют свойства), то зачем же еще? Все остальное как бы хорошо не было, скорее всего, обошлось бы без термина "модель".


c127
По-моему этот закон в философской интерпретации есть пустой набор слов, как и все остальное в марксистко-ленинской философии.

Это не в Марксистко-Ленинской, а в объективно-идеалистической Гегелевской. А Маркс И Ленин не дураки были, чтобы все это взять в свою в виде составной части.
Вы слишком категоричны - это достижение человеческой мысли уже.

c127
Он мне больше нравится в математической формулировке: (not (not X)).

Это закон формальной логики. Именно он и подвергся в первую очередь критике, когда Рассел с его помощью нашел знаменитый парадокс в Канторовской теории множества.
А я Вам закон диалектики подбрасывал. Другое совсем дело.

c127
Я так и не понял, что такое полуструктурированные данные? Можете объяснить поконкретней? Это по-Вашему единственное существенное отличие ХМЛ-я от иерархических БД?

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

Т.е. они обладают структурой, но эта структура может оказаться непостоянной, недостаточно изученной или неполной.

Были и раньше попытки создания СУБД для слабоструктурированных данных (Lorel)

Модели данных давно делят на сильнотипизированные и слаботипизированные. У одних они преимущеста и недостаки у других другие.
В, частности, манипулировать легче первыми, и в пределе для РМД - есть вообще рел алгебра. (Впрочем, W3C предложила алгебру запросов XML). У полуструктурированных - большая гибкость.

Это концептуалное отличие, но не только от ирархичеких, а от структурированных вообще, в том числе и иерархических.
Реально мало кто сравнивает ХМЛ с иерархическими.
Берите выше.

Насчет единственности отличия от ирерхических моделей данных, можно там и дальше искать. Вот у иерархических есть физические ссылки, а с ХМЛ вообще уже целая технология связана.

2 mir
Я имел ввиду в том вопросе семантический и прагматический аспекты моделей данных.
Конечно и связи и события она может представлять. Ясное дело.
Там речь шла о противопоставлении РМД реляционному формату. А формату, кстати говоря, и формальный (теоретический, синтаксический) и прочие аспект тоже сам по себе безразличны. Хотя есть типы, есть ограничения, есть язык программирования, который может работать с этими форматами данных.
Их главная цель упростить программирование.
У Ворда тоже есть и элементы структуры, операторы ввода, правила целостности в том или ином виде. Но это не модель данных.

Чистые формальные теории обретают пользу, и тем самым оправдывают свое существование, только благодаря интерпретации. Для моделей данных семантика имеет значение, иначе слово "модель" не оправдано. Говорили бы формальная теория данных. И не было бы вопросов.

c127
Дело в том, что есть определение Кодда. Соответствует - СУБД, не соответсвует - не СУБД.

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

Почему Вы ничего не говорите о том, что СУБД вообще появилось раньше 1970 года и предложено группой Кодасил? Их вроде как бы слово первое что есть СУБД вообще. Вряд ли Кодд это оспаривал.
Может тока СУБД второго покаления или будущие.

c127
Так я ж и говорю, был закон логики, его не разобравшись всунули в философию.

Думаю, все-таки, что Гегель это слишком серьезно, чтобы говорить о том, что он не разобравшись что-то сделал.
В формальной логике все рассматривается в одном и том же смысле, и в одно и то же время. А там диалектика - все рассматривается в развитии. Даются общие методы познания.
Впрочем, дело веры.

c127
парадоксы Рассела просто очень красиво и изящно подтвердили что основания имеют проблемы и над этим нужно работать.

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

c127
В любом случае это легко записывается в РСУБД. Правда Вы эту структуру не называте реляционной

В РСУБД записывается, возможно, легко. Структуру назваю реляционной. Формат называю реляционным, даже если затолкали в Йексесль, но реляционную таблу. Не называю произвольную совокупность рел табл реляционной моделью в общем случае.
Т.е. речь шла о том, что простое заталкиваение модели данных ХМЛ в РСУБД
не есть еще отображение на реляционную модель данных. А запихать можно не тока в РСУБД, а в тот же йексель или ворд.

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

c127
Вопрос: речь идет о структуре данных или о том что структура известна, но неизвестны типы?

О том, например, что про одного автора в листе дерева написаны ФИО слитно, а для другого отделно три листа (Ф, И, О) и еще четвертый про гонорар. Полхо формализованная модель.

В реляционной модели данных - есть заранее фиксированная схема. А в полуструктурированной, как правило, нельзя данные описать с помощью какой-то неизменной схемы. Характерной особенностью слабоструктурированных данных опистельная информация присутствует в самих данных, а не отделяется от них как в структурированных.
Затолкать это в 6 рел таблиц, наверное, можно, а отобразить на рел модель сложновато будет, и модель получится корявая. А потом схему постоянно менять придется? А тех 6 табл самих по себе не достаточно, нужно все равно знать про ту модель что внутри у них, чтобы извлекать нужные данные как можно проще. Например, найти все книги автора.