43210 mirP.S. Про "идиотов", придумавших "теоретический запрет" на nosimple domains, я погорячился. Возможно вы просто определили место для Дейта?Что ж вы, такой резкий и смелый, прячетесь за безымянным гостевым ником?

Теперь собственно, уточнение. Вчера писал по памяти, дома посмотрел 6 и 8 издания Дейта. На самом деле в 6-м издании он писал о неатомарных значениях в двух местах. Первый раз в вводной главе, очень вскользь. Именно там он и написал, что "в реляционных БД повторяющиеся группы не допускаются". Но в той же книге, в 19 главе, он написал целый большой подраздел про сложные типы вообще и вложенные отношения в частности, использовав термин RVA (relation-valued attributes). И там он прямо указал на их допустимость и даже прямую желательность. Фактически получилось некое противоречие. В последующих изданиях он извинился перед читателями за тот кусочек из вводной части 6-го издания, еще раз подчеркнув возможность применения RVA (стр. 215).

Короче говоря, ни в коем случае нельзя сказать, что Дейт ранее возражал против поддержки в РМД RVA и сложных пользовательских типов в целом.

gruУжасть. Нотация и синтаксис не имеет отношение к алгебре?Не имеет. И ужасть в том, что вы этого не понимаете.
gruА вот это .А что вот это ? Вы сами-то пытались читать, что написано в статье по данной ссылке?
gruНет нотации, нет семантики, уважаемый mirЗапущено-то как все... Хорошо, вот вам тест на понимание.
Допустим, в языке L1 алгебраическая операция сложения чисел x и y записывается так: x + y
В языке L2 так: (+, x, y)
В языке L3 так: x.ADD.y
В языке L4 так: Add(x, y)
В языке L5 так: x.Add(y)
В языке L6 так: x->y->Add
Имеем 6 нотаций. Вопрос: у нас 6 разных алгебр или одна и та же алгебра?

okdokyТогда в 60-х годах очень популярны были системы обрабатывающие данные, хранящиеся в последовательных файлах (заранее отсортированные). Сейчас имеют большие шансы на успех иерархические XML-СУБД. (Извините, что вмешиваюсь) …которые являются фактически в точности тем же самым, и поэтому имеют столько же шансов на успех. По тем же причинам.
okdoky mirЗапущено-то как все... Хорошо, вот вам тест на понимание.
Допустим, в языке L1 алгебраическая операция сложения чисел x и y записывается так: x + y
В языке L2 так: (+, x, y)
В языке L3 так: x.ADD.y
В языке L4 так: Add(x, y)
В языке L5 так: x.Add(y)
В языке L6 так: x->y->Add
Имеем 6 нотаций. Вопрос: у нас 6 разных алгебр или одна и та же алгебра?Что вы упираетесь? Жалобные фразы типа «что вы упираетесь?» в споре обычно свидетельствуют, что аргументы у спорщика иссякли. Поздравляю.
okdokyЕсли есть разные языки для выражения одного и того же, это не значит, что языки, нотация, синтаксис, вообще не требуются. А кто-нибудь здесь такое говорил? Ссылочку, пожалуйста.
okdokyТут вопрос какой язык лучше? Неправда. Если вы такой забывчивый, я напомню ваши слова:
okdoky, /topic/379205&pg=4#3682410Другое дело как быть с той алгеброй, математическим аппаратом, пока удобным только для нормализованных отношений ИМХО. Тут может помочь точечная нотация, или как в Zigzag или XPath, что-то типа a[z/y]/b[c[...]] Как видим, речь шла вовсе не о языке , а об алгебре, математическом аппарате. И вы предложили решить «проблему неудобства» алгебры с помощью… нотации ! Ясное дело, это результат непонимания взаимосвязи между алгеброй и конкретной нотацией (синтаксисом языка). Каковой диагноз я сразу и поставил.
okdokyНапример, Tutorial D или SQL2 не очень годятся для оперирования с вложенными отношениями и иерархическими зависимостями. Не зная толком ни того, ни другого языка беретесь рассуждать о степени их пригодности. Это было бы смешно, коль не было бы так грустно.
okdokyНеужели кроме Дейта, вам некого больше изучать?Давайте только не будем «мериться» количество и качеством прочитанного, а? Боюсь, результаты будут далеко не в вашу пользу. Поверьте, помимо путанной документации по языку ZigZag вам бы не помешало чтение фундаментальной литературы по математике, логике и базам данных.
okdokyСрочно читать других учеников-неидеотов. ОК, давайте ваш рекомендуемый список, с радостью почитаю что-нибудь ранее упущенное.

gru mirПро алгебраическую поддержку тоже не беритесь рассуждать, полный набор операций, включающих работу с вложенными отношениями, давным-давно предложен.Можно манипулировать комплексными значениями? Не выдавать их в качестве результата, а использовать как исходные данные?Теоретические вопросы использования вложенных отношений проработаны еще в период с 1977 по 1988 г. в целом ряде публикаций. Библиографию можно найти у того же Дейта. Про долговременное отсутствие реализации RVA в СУБД -- вопросы только к разработчикам СУБД. Oracle, насколько я знаю, уже давно поддерживает, правда в своей собственной манере.
Вопросы поддержки сложных пользовательских типов теоретически проработаны тоже давно. Тот же Дейт в последних изданиях ВвСБД уделил этому очень много внимания. В новых стандартах SQL расширенная поддержка UDT тоже предусмотрена.
gruРазве точечная нотация это плохо?Опять двадцать пять. Кто здесь критиковал точечную нотацию? При чем здесь точечная нотация?

модВ связи с этим и возвращаясь к истокам: почему в РМД отношения, а в СУБД таблицы, в чем разница ? О, это интересный вопрос. Термин «таблица» встречается (и понимается) аж в нескольких разных смыслах.

Первая группа «смыслов» — таблица как абстрактное представление (логическое понятие).

В этой группе можно выделить R-таблицы и SQL-таблицы.

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

SQL-таблица (т.е. TABLE в языке SQL) — изобретение авторов SQL. Поскольку SQL изначально создавали не мега-умы языкотворения типа Никлауса Вирта, а умы весьма среднего пошиба типа Чамберлена, они не только создали чисто синтаксически не самый удачный язык, но по ныне неведомым причинам еще и исказили РМД. В результате SQL-таблица может не быть отношением . Например, может содержать дубликаты строк. Может содержать пропуски в значениях (NULLs). Может содержать безымянные столбцы. Может содержать столбцы с одинаковыми именами (в результатах запросов). Столбцы упорядочены (на них можно ссылаться по номерам).

Минимум один из сотрудников комитета ANSI по SQL — Хью Дарвен — впоследствии «раскаялся в содеянном» и ныне является соавтором Дейта по 3-му Манифесту.

Вторая группа «смыслов» — таблица как физическое понятие.

В этой группе можно выделить таблицы-визуальные представления и таблицы-структуры в памяти.

Первая в списке — чисто визуальное представление R-таблицы или SQL-таблицы, например, выведенное на экран или напечатанное на бумаге. Понимаемая в этом смысле таблица действительно может называться «плоской» (двумерной), тогда как само отношение «плоским» (двумерным) не является. Также таблица в этом смысле неизбежно имеет определенный порядок строк и столбцов, даже если представляет правильное отношение.

Есть еще и (визуальные) таблицы, не представляющие собой даже SQL-таблицы. Это вообще все, что угодно, что можно нарисовать на бумаге или натворить в Word или Excel, с произвольной нерегулярной структурой и даже с диагональными линиями.

И, наконец, таблицы как структура в памяти — это тупо двумерный массив.



Поэтому, когда кто-то говорит «отношение» (relation) — его все всегда понимают. Когда кто-то говорит «таблица», его можно понять только по контексту, а то и ошибиться. А когда Шуклин в своей писанине говорит «таблица» — его понять вообще невозможно.
модНо тогда получается, что СУБД работают совсем с другой моделью данных (что так и есть на самом деле).И поэтому чистые теоретики РМД изобрели даже спец-термин — SQL-СУБД, чтобы подчеркнуть, что это не вполне РМД.

okdoky mir Как видим, речь шла вовсе не о языке, а об алгебре, математическом аппарате. И вы предложили решить «проблему неудобства» алгебры с помощью… нотации! Ясное дело, это результат непонимания взаимосвязи между алгеброй и конкретной нотацией (синтаксисом языка). Каковой диагноз я сразу и поставил. Родной мой, ведь речь шла и о математическом аппарате…. Как-то я уже задавал Вам вопрос, как на Tutorial D задать операцию перехода от одного атрибута к другому, X/Y. Тогда вы позорно ретировались.Ну, а врать не стоит. И вопрос был совсем другим, и ответ я на него немедленно дал. Любой может отмотать и убедиться. Так что, okdoky, как говориться, бреши, да знай меру. Кстати, я вижу, что вы до сих пор не понимаете разницу между множествами и атрибутами. И, к слову, операция таинственного "перехода между атрибутами" в РМД вообще неизвестна, поэтому задать ее нельзя ни в Tutorial D, ни в SQL, ни в любом другим языке работы с РБД. По причине ненужности.
okdokyНадеюсь за праздники удалось изучить XPath и используемую там нотацию?Не переживайте, основы XPath я давненько знаю.
okdokyВедь алгебра может включать в себя не только операции, предложенные Коддом.Какая именно алгебра? Реляционная? Давным-давно включает. Только при чем здесь XPath, который к ней отношения не имеет?
okdokyЧтобы выразить операции приходится использовать нотацию, которая должна иметь вполне определенный смысл.К чему эта банальная мысль? Никто и не спорил с этим. Не стоит лишь забывать, что всяких разных нотаций может быть вагон. И если сравнивать нотацию -- то с другой нотацией, а алгебру -- с другой алгеброй. А предложение "улучшить" алгебру с помощью нотации -- это уже диагноз.

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

Это первое.

По поводу моих знаний ООП... Хотел было ответить, но передумал. Почему этого делать не стоит, хорошо сказал. ап. Матфей (Мф. 7:6).

По поводу "читайте, изучайте", все еще жду от вас список горячо рекомендуемых вам книг.

мод mirПервая группа «смыслов» — таблица как абстрактное представление (логическое понятие).
SQL-таблица (т.е. TABLE в языке SQL) — изобретение авторов SQL.
Это не их изобретение. Фактически таблица, это функция вида
n->(A1,A2,A3...An), т.е. отображение целого числа (номер строки) на отношение (ведь отношение - это множество). Это вы придумали? Ссылочку на источник можно? Явно писал полный дилетант, т.к. во-первых, в логической таблице нет никаких номеров строк, во-вторых в математике не бывает отображения одного числа на множество, т.к. отбражение (строгий мат. термин) определяется на множествах, в третьих (A1,A2,A3...An) -- это вектор, а не отношение...

модЧастный случай таблицы - массив в ЯП.Мне померещилось, или кое-кто чуть выше написал про таблицу как физическое понятие -- "не интересует". Массив в ЯП -- понятие уровня физической реализации, к логическим таблицам не имеет отношения. Что-то у вас в голове все в кучу.

модПоэтому в СУБД реализовали таблицу-функцию, а не R-таблицу - множество.Почему "поэтому"? Вывод не следует из посылки.