okdoky mir P.S. Ознакомился с кратким описанием Zigzag Language . Вердикт: авторы полные невежды как в области реляционной теории, так и в области реальных возможностей современных СУБД. Первое можно проиллюстрировать хотя бы тем, что "отношения" (table relations), которые можно задавать в ZigZag, не определены ни на каких множествах (типах, доменах). Поэтому называть их "отношениями" абсурдно с точки зрения хоть РМД, хоть математики. С таким же успехом невеждами можно назвать разработчиков любой РСУБД (Oracle, DB2) только за то, что они не следовали в полной мере описанию РМ Кодда и допустили повторяемость строк. К слову, именно так и считают такие авторитеты как Крис Дейт и Фабиан Паскаль. Это один из потенциальных недостатков SQL, вызванный плохим пониманием реляционной модели. Однако с помощью SQL можно легко создать и поддерживать полностью правильное отношение без дубликатов (для это просто нужно как положено объявить первичный ключ), а вот как создать в ZigZag отношение, ежели его не на чем определить ? В доке утверждается, что “Zigzag does not assume the type declaration” и “there are not schema control in Zigzag”. Возможно, я что-то упустил, укажите тогда как задать отношение с типизированными атрибутами, это будет другой разговор. okdokyГлавный критерий определяющий соответствие СУБД реляционной модели, это прежде всего соответствие операционального языка СУБД реляционной алгебре.Очередное безапелляционное утверждение, ничем не подкрепленное. Неужели вы такой мега-эксперт в области баз данных, что можете самостоятельно определять критерии реляционности СУБД? Может, это будет для вас открытием, но существуют, во-первых, четкое определение реляционной модели данных, а во-вторых, известные 12 правил Кодда, определяющие реляционность СУБД. Так что не надо собственных фантазий на эту тему, пожалуйста. okdokyМножественные классы, используемые в Zigzag, соответствуют понятию домен. При желании любой класс в Zigzag можно определить заранее, но это не является и не должно быть обязаловкой. Я вроде в курсе терминологии и РМД, и ТМ и ООП, но ей-богу не знаю, что такое «множественные классы». Я знаю, что домен — это просто тип данных, то есть в свою очередь — именованное множество значений. okdoky mir Что такое целостность (integrity) авторы тоже не знают. Под этим термином они понимают что-то совершенно иное, свое. Термин нигде формально не определяется, но иллюстрируется примером, который, естественно, ничего не поясняет. Зато гордо утверждается, что "There is integrity control for a field of many tables and the trigger procedure is not required for Zigzag." Из этой совершенно невнятной фразы ясно только одно -- осилить поддержку триггеров в своей системе товарищи тупо не сумели. Интересно, как бы они в своей системе делали, скажем, аудит, хе-хе? Обязательное связывание столбцов таблиц через триггеры подчеркивает лишь низкий уровень СУБД. А кто здесь вообще говорил про «связывание столбцов таблиц», да еще и «через триггеры»? Речь шла вроде о целостности.
okdokyВ Zigzag контроль целостности автоматизирован только благодаря тому, что внутреннее представление больше соответствует реляционной модели. Какая-то бессмысленная фраза, что ни слово, то вопрос. «Контроль целостности в Zigzag» — что это? Это понятие нигде в доке по ZZ не определяется, но ясно, что это что-то совсем не то, что в РМД. «Контроль целостности автоматизирован» — что значит «автоматизирован»? Он либо есть, либо нет. «Внутреннее представление» — представление чего? Что значит «внутреннее»? Это имеет отношение к модели ANSI/SPARC? Если да, при чем здесь модель данных, которая не присутствует на внутреннем уровне представления? «Больше соответствует реляционной модели» — больше чего ? okdokyТаблица в Zigzag –производная от доменов. При удалении значения домена автоматически очищаются все соответствующие поля таблиц и удаляются все связки (кортежи) для которых это значение является ключевым. Вы о чем? Из домена невозможно удалить значение, так как домен — не переменная, а тип данных. Можно лишь переопределить домен. Далее, при чем здесь принадлежность ключам? Если такого значения в домене больше нет, то все его вхождения в кортежи более невалидны, вне зависимости от того, входят ли они в ключи или нет.
okdoky mir Насчет незнания возможностей SQL-СУБД можно процитировать гордое "attribute name (not only value) may be expressed via request in a description or another request. These (and others) unique possibilities are not provided by SQL." Авторы, похоже, слыхом не слыхали ни о возможностях в SQL-СУБД работы с метаданными, ни о динамическом SQL. Пожалуйста, приведите пример использования и оперирования метаданными на SQL. Я обязательно Вам отвечу тем же и добавлю еще.Тут не понял: вы не верите, что на SQL можно работать с метаданными? Если не верите, то это ваше личное горе. Если верите, то к чему просьба привести пример? Речь, между прочим, о том, что авторы ZZ объявляют возможность работы в нем с метаданными не больше не меньше как «unique possibilities are not provided by SQL». Это просто невежество.

Но извольше, вот вам пример на T-SQL:

P.S. А вопросик про триггеры с удовольствием повторю: как на ZZ реализовать аудит? Триггеры в РСУБД с этим прекрасно справляются.

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

Вот, к примеру, цитата из Википедии про классы (http://ru.wikipedia.org/wiki/Класс):
Класс в объектно-ориентированном программировании — абстрактный тип данных.

Вот, к примеру, цитата из Дейта (Введение в системы баз данных, 8 изд. стр.165):
«Понятие типа данных … является фундаментальным: каждое значение, каждая переменная, каждый параметр, каждый оператор… и особенно каждый реляционный атрибут относится к тому или иному типу. Так что же такое тип? Кроме всего прочего, он представляет собой множество значений . […]Типы можно также называть доменами , особенно когда речь идет о реляционной модели; фактически сам автор использовал последний термин в предыдущих изданиях настоящей книги, но теперь предпочитает термин типы .»

Вот еще цитата из Википедии про реляционную модель данных (http://en.wikipedia.org/wiki/Relational_model):
The basic relational building block is the domain or data type, usually abbreviated nowadays to type .

A domain is simply a set of values, together with its associated operators. It is equivalent to the notion of a type in programming languages.
okdokyЭтот класс (множество значений) в Zigzag отвечает задаче ограничения целостности. Не знаком с таким термином: «задача ограничения целостности». Знаю про обширную задачу обеспечения целостности БД , решаемую, в том числе, с помощью ограничений целостности , которые являются ни чем иным, как правилами , накладывающими ограничения на допустимые состояния БД. В РМД выделяют ОЦ общего вида по уровням (ОЦ домена, ОЦ атрибута, ОЦ отношения, ОЦ базы данных) и два специальных важных ОЦ частного вида: ОЦ потенциального ключа (так наз. целостность сущностей) и ОЦ внешнего ключа (так наз. ссылочная целостность). Важным свойством РМД является возможность декларативного задания различных ОЦ в виде предикатов. После этого краткого курса ответьте мне: что же, черт возьми, в точности означает ваша загадочная фраза «класс отвечает задаче ограничения целостности»?
okdokyОтношения можно определять на основе имеющихся классов.А можно и нет? Но тогда полученное «нечто» будет чем угодно, но не отношением, просто по определению.
okdokyВажным и уникальным является то, что мы можем переопределять класс, то есть менять имена его значений, удалять их и вставлять новые. При этом автоматически меняются все отношения определенные на данном классе. 1. У значений имен не бывает. Значения просто существуют, они сами себя идентифицируют. По-вашему, какое имя имеет значение 137? Поэтому фраза про изменение имен значений для меня не имеет смысла.
2. Операции редактирования типа данных по определению невозможны, так как тип данных — не переменная. Можно лишь пытаться переопределить тип данных. Операция крайне редкая, что уж вы нашли в ней такого важного? Кстати, что тут и такого уникального? Вы полагаете, что в SQL нельзя сменить тип атрибута? okdoky mirНо извольте, вот вам пример на T-SQПрокомментируйте, если не трудно. С таким наворотом SELECT и системных названий, боюсь его не сможет сразу понять, даже хорошо знающий SQL.Читаем ответ vadiminfo.

okdokyНачну с того, что именно возможность работы с метаданными является главной причиной … бла-бла-бла Но есть и другие уникальные вещи … бла-бла-блаДорогой okdoky. Вы слишком легко забываете тему разговора. Я твердой рукой возвращаю нас к истокам, а именно: я утверждал, что авторы ZZ невежды как в области реляционной теории, так и в области реальных возможностей современных СУБД. Про теорию, полагаю, все уже ясно, но это мы еще обсудим. А вот про невежество в области возможностей РСУБД я говорил на примере фразы "attribute name (not only value) may be expressed via request in a description or another request. These (and others) unique possibilities are not provided by SQL ." Невежество состоит в том, что авторы ZZ полагают, что РСУБД не позволяют работать с метаданными. Я это показал (и любой мог это показать). Поэтому признайте, что процитированное утверждение не соответствует действительности, а потом уже можно обсуждать детали. Итак: авторы ZZ берутся критиковать возможности SQL просто не зная этих возможностей . Закономерный диагноз: невежды.
okdokyТип, уважаемый U-gene, это не множество значений, а то, что описывает или определяет это множество. Прочитайте цитату, которую привел mir
mirВот, к примеру, цитата из Дейта (Введение в системы баз данных, 8 изд. стр.165):
«Понятие типа данных … является фундаментальным: каждое значение, каждая переменная, каждый параметр, каждый оператор… и особенно каждый реляционный атрибут относится к тому или иному типу. Так что же такое тип? Кроме всего прочего, он представляет собой множество значений. […]Типы можно также называть доменами, особенно когда речь идет о реляционной модели; фактически сам автор использовал последний термин в предыдущих изданиях настоящей книги, но теперь предпочитает термин типы.»Согласно переводу, тип - не значения, тип представляет собой значения. Но что значит "представляет", как это слово выглядит в оригинале? В любом случае, Дэйт в последнее время предпочитает отделять понятие тип от понятия домен. Пора бы и Вам внимательнее отнестись к данным терминам.Вы либо искусный демагог вроде ЧАЛа, либо … не буду продолжать. Во-первых, вы не обосновали ни одного своего утверждения по данному вопросу. Во-вторых, вы проигнорировали прямые цитаты из энциклопедии (повторю с переводом):

The basic relational building block is the domain or data type, usually abbreviated nowadays to type. Базовый «строительный блок» реляционной теории — домен, или тип данных, в наше время обычно сокращаемый до слова «тип».

A domain is simply a set of values, together with its associated operators. It is equivalent to the notion of a type in programming languages. Домен представляет собой просто множество значений, вместе с ассоциированными операциями. Он является эквивалентом понятию типа в языках программирования.

Здесь все сказано предельно четко.

И в-третьих, вы сделали крайне неуклюжую попытку дать свою интерпретацию цитате Дейта, а точнее — просто переврать ее. Ваша фраза «Согласно переводу, тип - не значения» не имеет никакой связи с цитатой Дейта, там ничего подобного нет. И ни я, ни кто-либо еще никогда не говорили, что тип — это значение. Первая ваша неуклюжая ложь. Ваша фраза «тип представляет собой значения» — вторая ложь, так как в тексте «он (тип) представляет собой множество значений».
Далее, рассуждения «что значит "представляет", как это слово выглядит в оригинале?» просто смехотворны, так как в тексте вовсе не «представляет», а «представляет собой», а «являться/быть» и «представлять собой» в русском языке — синонимы, о чем все прекрасно знают. Это такая нелепая попытка навести тень на плетень.

И, наконец, ваша фраза «Дэйт в последнее время предпочитает отделять понятие тип от понятия домен» — это третья прямая ложь, ничего подобного в тексте нет. Дейт ясно указал, что 1) тип — это множество значений («он [тип] представляет собой множество значений»), что 2) домен и тип суть одно и то же («типы можно также называть доменами, особенно когда речь идет о реляционной модели») и 3) он предпочитать в последних изданиях использовать термин «тип», а не термин «домен» («теперь [автор] предпочитает термин типы»). Предпочесть термин «тип» синонимичному термину «домен», это совсем не то же самое, что «отделять понятие тип от понятия домен».

Короче, если вы хотите, чтобы вас воспринимали хоть капельку серьезно, хватит так глупо перевирать сказанное, тем более, когда первоисточник у всех перед глазами.

P.S. А как там насчет целостности? Что-то вы эту тему совсем подзамяли.

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