Обсуждение:Реляционная модель данных

Необходима полная переработка

Текст статьи ужасен. Термин "реляционная модель" сегодня почти синоним "модель данных", РСУБД почти синоним СУБД, а здесь... Сюда же и дети наши ходят!

"Определение" просто позорно - это скажет даже тот, кто вообще никогда не слышал про РМД - просто по внешнему виду. Следующие пара абзацев - унылый и беспорядочный набор каких-то терминов, то ли имеющих отношение к делу, то ли нет. Затем длиннющие рассуждения на тему, чем "отношение" отличается от "таблицы", убеждающие лишь в том, что и сами авторы не имеют об этом ни малейшего представления... снова бессмысленный набор терминов... несколько фраз примерно такой же ценности про другие модели (для увеличения объема?)... все, статья готова!

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

Господа! Давайте доведем статью до ну хоть сколько-нибудь приличного состояния. Преподаватели! Трудно представить более приличное место приложения ваших талантов.

84.42.6.114 07:55, 28 декабря 2009 (UTC)Владимир Рыбинкин

• Статья и правда очень скудно освещает тему. В ней, например недостаёт конкретных определений всех составляющих, они просто перечислены. Во то же время не поддерживаю Владимир Рыбинкина в его категоричности. Определение "не позорное", просто оно слишком обзорное, но при этом верное. Для сравнения: в "Энциклопедии технологий баз данных" Когаловского определение РМД дано на том же примерно уровне обзорности, причём сущностная часть в определении даже меньше, чем здесь. А я книгу Когалосвкого позорной, в отличие от, видимо, Владимир Рыбинкина, не считаю. Аналогично и по поводу остальной части статьи: это может быть скудно, это может быть несколько бессистемно, да, но то, что написано -- написано верно. То есть фактических ошибок нет. Ваше мнение по поводу рассуждений на тему, чем "отношение" отличается от "таблицы" можете прямо адресовать мне, я его формулировал. Только залихватскими фразами не отделаетесь, нужны аргументы. Со своей стороны укажу, что в этой части просто своими словами пересказал слова К. Дейта на эту тему, с которыми, кстати, совершенно согласен.
  Итак, согласен, что статья нуждается в сильной доработке, у меня времени не было. Не согласен с предложением о полной переработке, т.к. здесь именно надо дополнить и структурировать. Пока закрываю глаза на некорректный стиль общения Владимира Рыбинкин, надеясь на его последующее приведение в норму. Евгений Мирошниченко 10:07, 28 декабря 2009 (UTC)

Согласен про стиль - извиняюсь. Это не ругань, это именно многолетний стиль. Не оправдывает, конечно... Готовлю проект статьи - очень трудно идет. Приветствовал бы предварительное обсуждение ЗДЕСЬ. Когаловского я ОЧЕНЬ уважаю (знаком лично, он мне даже оказывал просто неоценимую помощь).

Требуется доработка

Я слабоват для того, чтобы написать статью самостоятельно (по крайней мере, такую, которая меня бы устроила). Кроме того, я пристрастен: к РМД я отношусь ОЧЕНЬ плохо. Поэтому даю набор тезисов, которые, как мне кажется, должны найти отражение в статье.

0. Статья предназначена для неспециалистов - грубо говоря, для старшеклассников. Поэтому хорошо бы параллельно вести пример простейшей БД, иллюстрирующий положения статьи "на пальцах".

1. РЕАЛЬНАЯ история того, что обычно воспринимается как триумфальное шествие РМД: "В рядах сторонников сетевой архитектуры был сам великий Чарльз Бахман, и только гений Эдгара Кодда позволил реляционной модели одержать победу". Опровержение подобной "подгонки под ответ" есть у Когаловского: "Велись споры... как известно, завершившиеся ничейным исходом в открытой дискуссии Ч.Бахмана и Э.Кодда".

1.1. Принципы реляционной модели данных впервые были изложены Коддом в 1970 году в статье "A Relational Model of Data for Large Shared Data Banks", хотя определение термина "data model" появилось на 10 лет позже.

1.2. Представления самого Кодда о том, что такое RDM, неоднократно менялись в течение всей жизни. Например, Стоунбрейкер писал, что "можно видеть четыре разных версии" модели.

1.3. До сих пор это понятие не имеет однозначного толкования. По-видимому, наиболее "классическим" определением следует считать Третий Манифест, поскольку Дейт писал (немного перефразировано): "Мы с Хью Дарвеном хотели, чтобы Манифест отчасти рассматривался бы как определительная формулировка, что такое реляционная модель".

1.4. Перспективы РМД: от полупрезрительного отношения сторонников ООБД во главе с Аткинсоном до восторженного ("на многие столетия вперед") у Дейта.

2. Цели, которыми руководствовался Кодд (по его собственным словам и словам Дейта - сборная солянка, нумерация моя, т.е. как попалось под руку, источники не всегда известны, требуется уточнение):

2.1. Обеспечить высокий уровень независимости данных.

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

2.1.2. В математике (и в SQL, с которым Дейт энд кампани ведут борьбу не на жизнь, а на смерть) кортежи "упорядочены", разрешаются их дубли. Мало того, сам Кодд первоначально определял кортежи именно так! Отказ от упорядочивания расматривается (кажется, Дейтом) как величайший вклад Кодда в РМД. В ООБД, однако, "почему-то" вновь требуется "поддержка индивидуальности объектов", т.е. "объекты должны иметь уникальный идентификатор, который не зависит от значений их атрибутов".

2.1.3. Лично я думаю, что отказ от упорядоченности есть НЕИЗБЕЖНОЕ СЛЕДСТВИЕ "структурного аспекта реляционной модели" (данные в базе данных представляют собой набор отношений, т.е. первичный элемент есть группа). В любом случае, наличие/отсутствие упорядоченности имеет принципиальное значение - это признается обеими сторонами (Дейт тоже категорически против компромиссов). Следовательно, чрезвычайно важно "не ошибиться с направлением" именно на этом "водоразделе".

2.1.4. Совершенно неизбежным и страшным следствием отсутствия упорядоченности является концепция "ключа". Подмена понятий (замена идентификатора ключом) имеет далеко идущие последствия. Понятие идентификатора, "жульническим" образом изъятое из модели данных, принципиально не может быть убрано также из РСУБД - ведь даже для тривиального чтения значения ключа нужно получить доступ к кортежу каким-то иным способом. Иными словами, полностью избавиться от понятия идентификатора невозможно - можно лишь "сделать вид", что его не существует при групповой обработке данных.

2.2. Обеспечить спартанскую простоту представления данных.

2.2.1. Сделать многие приложения доступными для непрограммистов в тех случаях, когда ранее программисты были бы необходимы. Благороднейшая цель! Слова самого Кодда: "Важно помнить, что базы данных появились, чтобы приносить пользу конечным пользователям, а не для прикладных программистов, которые сегодня выступают в качестве посредников (middle-men)". И... полностью противоположный заявленной цели результат: именно благодаря Кодду в приложения БД буквально ломанулась целая толпа посредников, благо требования к их квалификации резко снизились.

2.2.2. Переместить прикладное программирование на уровень, на котором множества (и, более конкретно, отношения) трактуются как операнды, а не обрабатываются поэлементно. Опять же, замечательная цель: язык, позволяющий работать с множествами, бесспорно, удобен. РМД, однако, предполагает работу ТОЛЬКО с множествами (никаких покортежных операций, единичный кортеж есть просто частный случай множества, категорически запрещается концепция курсора). А в таких "коротких штанишках" становится уже тесно даже SQL - ближайшему родственнику РМД.

2.2.3. Ввести мощные операции, обеспечивающие и программистов и непрограммистов возможностями хранения и выборки данных без потребности "навигации" [в оригинале подчеркнуто]. Маниакальная борьба Кодда с навигацией (да и сложностью) явно обусловлена знанием о существовании концепций БД от CODASYL, стремлением избавиться от ее недостатков (как и появление 3-го Манифеста обусловлено знанием о существовании SQL). Он сам отвергал возможность компромисса, любую попытку объединения двух подходов, поскольку в результате "мы получаем ненужную сложность".

2.2.4. Подобная жесткость подхода к простоте представления данных (которые все это время обнаруживали явную тенденцию к усложнению), дополненная появлением различных нормальных форм, уже привела к ситуации, что реальные "реляционные" СУБД в действительности РМД не поддерживают. В частности, обычным явлением стал отказ от нормализации таблиц.

2.3. Ввести теоретическую основу (хотя бы небольшую) в управление базами данных.

2.3.1. Вроде как реляционная алгебра (как и реляционное исчисление) обладают какой-то там "полнотой". Наверное, для каких-то там теоретических умозаключений это очень важно. На практике же РМД (как, скажем, и машина Тьюринга) на фиг никому не нужна. Типы данных (string, int, date, boolean, etc.) реляционной теории по барабану. Концептуально, реляционная алгебра оперирует понятием Декартова произведения, которое в реальных РСУБД использовать слишком дорого, поэтому используют различные техники "оптимизации запросов". Нормальные формы (иерархичные по природе) приводят к ограничению сложности поддерживаемых структур данных. Между тем, идея самого Кодда состояла в том, что "при выборе логических структур данных должно присутствовать только одно соображение - удобство большинства пользователей".

Кроме примеров, хотелось бы еще преимущества и недостатки РМД (в сравнении с SQL, графовой и ОО-моделями данных). Короче говоря, статья видится мне достаточно "тяжелой" по объему. Напишем?

84.42.23.83 09:21, 15 января 2010 (UTC)Владимир Рыбинкин

Согласен почти со всем. Однако есть ряд пунктов, которые можно назвать сомнительными или прямо ошибочными. Их укажу с комментариями.

2.1.1. Именно что нет понимания. Про независимость (и виды зависимости) Кодд расписал ещё в статье "A Relational Model of Data for Large Shared Data Banks".

2.1.4. Выдаёт непонимание понятия идентификации. Фраза "даже для тривиального чтения значения ключа нужно получить доступ к кортежу каким-то иным способом" выдаёт отсутствие знакомства с понятием ассоциативного доступа. К сведению, есть даже компьютеры с ассоциативной памятью.

2.2.2. Навигационные операции просто не являются частью РМД, но это не значит, что РМД категорически запрещает их иметь и использовать в той или иной системе (реализации).

2.2.4. Проблемы поддержки РМД в СУБД не имеют ничего общего с "отказом от нормализации таблиц", т.к. СУБД не занимается нормализацией таблиц, это дело проектировщиков БД. Поэтому фраза в целом выглядит бессмысленно.

2.3.1. Для человека, который постоянно упоминает про участие в разработке какой-то СУБД, странно подобное непонимание разницы между абстракцией и реализацией, то есть между логическим и физическим уровнем. Отношения, как и реляционные операции (в т.ч. декартово произведение) есть абстракции, а их реализации (хранение и операции) в СУБД могут быть самыми разными, это дело разработчиков. РМД лишь предписывает, чтобы результат, например, соединения отношений логически был эквивалентен произведению с последующим ограничением (выборкой). Но РМД никак не предписывает конкретную реализацию этих операций (в т.ч. не предписывает обязательное создание в памяти промежуточных результатов), каковой занимается оптимизатор запросов. Это же азы. Далее, сказано: "Нормальные формы приводят к ограничению сложности поддерживаемых структур данных". Нормальные формы не имеют отношения к сложности поддерживаемых структур данных, они имеют отношение к уровню избыточности данных и вытекающим из него проблемам. Евгений Мирошниченко 06:39, 16 января 2010 (UTC)

Не согласный я с большинством комментариев.

2.1.1. Вот и славно. У ВАС - есть? Озвучьте, и мы вместе посмеемся. Кодд свои мнения вообще менял, как перчатки.

2.1.4. Какой "ассоциативный доступ", побойтесь Бога! К сведению, есть только один вид доступа к данным, пригодный для реально работоспособной СУБД, и он называется "прямой" (а концепция ключа, между прочим, его явно запрещает - в отличие от SQL). Фраза "даже для тривиального чтения значения ключа нужно получить доступ к кортежу каким-то иным способом" - ВЕРНА (Y/N)? И еще: что там "выдаёт отсутствие знакомства с понятием" - никому не интересно. Можете дать формулировку - дайте. Остальное - болтовня.

2.2.2. Ха-ха-ха! Перечитайте Третий Манифест: "РМ-предписания и запреты не могут быть предметом компромисса". Даже несчастный курсор "категорически запрещается" (а уж более примитивной навигации просто не бывает в природе). РМД именно КАТЕГОРИЧЕСКИ запрещает их иметь, ибо концепция ключа мгновенно превращает навигационные операции в рекурсивный SQL-запрос: раз кортежи идентификатора иметь не могут - будь любезен рыскать по ЗНАЧЕНИЯМ, хоть ключом их обзови. И обязательный первичный ключ на реляцию вынь, да положь. И одинаковых кортежей заводить не моги - худо будет. Кстати, Вы что, видели где-то использование навигационных выражений в запросах? Кодд ненавидел навигацию не меньше, чем Дейт SQL.

2.2.4. Именно это я и сказал: на практике РМД на фиг никому не нужна. Более того, жесткость подхода к простоте представления данных НЕИЗБЕЖНО приводит к ограничениям в сложности самих хранимых данных БД. Иными словами, данные в РБД хронически примитивны: сколько-нибудь сложных конструкций там держать нельзя. И ни сама СУБД, ни проектировщики БД не могут обойти это ограничение. Строго говоря, могут (Когаловский, во всяком случае, об этом говорил), но работать это не будет. Еще точнее - будет, но выполнение сложных запросов растянется на тысячелетия. И никакия "оптимизация" не поможет.

2.3.1. "Для человека, который постоянно упоминает про участие в разработке какой-то СУБД", физический уровень - ЕДИНСТВЕННЫЙ, который осуществляет непосредственный доступ к данным, а логический - его единственный клиент. Остальные уровни (включая user layer) - клиенты уже для логического или более верхних уровней. И мне, как разработчику, ни декартово произведение, ни другие реляционные операции на фиг не нужны - SQL для "реляционного" юзера я как-нить и без них обеспечу: это всего лишь язык, то бишь UI.

Далее: если действительно "РМД лишь предписывает, чтобы результат, например, соединения отношений логически был эквивалентен произведению с последующим ограничением (выборкой)", то какого же черта Дейт страдает, что "Cartesian product and union are both noncommutative"? Чего он с такой ненавистью набрасывается на идентификаторы столбцов и кортежей в SQL? Какое его собачье дело?! РМД не только "никак не предписывает конкретную реализацию этих операций" - она вообще ничего полезного, практически пригодного не предписывает. Это же азы. ;)

Нормальные формы имеют ПРЯМОЕ отношение к сложности поддерживаемых структур данных, а вот "уровень избыточности данных и вытекающие из него проблемы" как раз НЕИЗБЕЖНОЕ СЛЕДСТВИЕ ограничений на сложность поддерживаемых структур. 83.229.208.1 06:21, 20 января 2010 (UTC)Владимир Рыбинкин

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

2.1.1. Есть классическая статья Кодда, в ней есть описание и классификация видов зависимостей. Это факт. Да, любой человек меняет некоторые точки зрения, и Кодд тоже менял какие-то взгляды. Но по поводу изменения его позиции по данному конкретному вопросу потрудитесь привести ссылки. Тут общими фразами "мнения менял как перчатки" не отделаешься.

2.1.4. Получение физического доступа к кортежу есть вопрос реализации, а не вопрос модели данных. Реляционная модель данных предписывает ассоциативный доступ к данным, т.е. доступ на основе значений, а как это реализуется в конкретной системе — для модели совершенно неважно. Вы же пытаетесь рассуждать о модели, постоянно сбиваясь на понятия уровня реализации. Советую по этому вопросу ознакомиться, например, со статьями "On the Logical Difference Between Model and Implementation" в кн. Date on Database: Writings 2000–2006, APress, 2006 и "Model Versus Implementation" в кн. Database in Depth, O'Reilly, 2005.

2.2.2. Предписания Третьего Манифеста относятся к строго реляционному языку. Я в точности об этом и сказал, навигационные операции не есть часть реляционной модели (в строго реляционном языке запрещены). Однако это не значит, что в конкретной системе, частью которой является реализация РМД, всё нереляционное запрещено. Проиллюстрирую это словами Дейта об операции сортировки ORDER BY. Всем известно, что ORDER BY совершенно точно не есть часть РМД (т.к. он формирует упорядоченный список, а не отношение). Значит ли это, по мнению Дейта, что ORDER BY не нужен и не может использоваться в конкретной системе? Нет, он говорит иное: "The fact that the tuples of a relation are unordered doesn't mean queries can't include an ORDER BY specification, but it does mean that such queries produce a result that's not a relation. ORDER BY is useful for the purpose of displaying results, but it isn't a relational operator as such." (Database in Depth, O'Reilly, 2005).

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

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

P.S. Когда в разговоре про операцию соединения цитируете "Cartesian product and union are both noncommutative", полезно перевести с английского, чтобы понять, что цитата к операции соединения отношения никакого не имеет. Равно как не имеют к этому отношения "идентификаторы столбцов и кортежей".

(Оффтоп) Вы мне сильно напомнили одного персонажа по имени Чернышов Андрей Леонидович, который примерно с таким же невысоким уровнем познаний в РМД и с такой же к ней ненавистью начал её типа "критиковать" на форуме www.sql.ru. Опозорился, конечно, по самое не могу. Евгений Мирошниченко 11:28, 22 января 2010 (UTC)

Сударь, не нужно вновь повторять то, что уже говорилось выше (тем более - мной). И про "сам факт наших разногласий по этим вопросам", и про "фаллосометрию", и про все остальное - на память я пока что не жалуюсь. Я рад, что Вы упомянули, на ком именно лежит "бремя доказательства" - надеюсь, Вы также помните свои же слова про "двойные стандарты", и мне не придется более "подпрыгивать" в удивлении от фраз типа "для них действительно нужны особые(?) подходы", "РБД изо всех сил нормализуют, чтобы устранить(!) избыточность", "между ними есть чёткая(!) граница", "никаких проблем(!) в разделении этих понятий нет" (интересно, дождусь я когда-нить критериев?), "знание структуры БД может быть заложены в программу алгоритмически, безо всяких метаданных(!)", "изобретение(!) метаданных позволило создать универсальные СУБД", "внешний ключ - это внешний ключ(?!)" и т.д. Кстати, вот попалось на глаза прямое опровержение Вашей ахинеи насчет внешнего ключа от Дейта: In other words, the information that was represented by a foreign key in the relational design is represented by a link in the network design; links are the network analog of foreign keys (speaking very loosely).

2.1.1. Я и просил Вас дать формулировки, касающиеся независимости данных. Я свое понимание озвучил, и оно четко перекликается с РМ-запретами Третьего Манифеста. Меня совершенно не интересуют пустые фразы про "нет понимания" или "есть классическая статья Кодда, в ней есть описание". Вот и изложите эти "описания", а не занимайтесь болтовней! "По поводу изменения его позиции по данному конкретному вопросу" я УЖЕ "потрудился" привести мнение Стоунбрейкера, а вот Вы - соблаговолите ли Вы привести ту самую "классификацию видов зависимостей"? Тут общими фразами "есть классическая статья Кодда" не отделаешься. ;)

2.1.4. Не нужно пудрить мозги "умными" словечками вроде "ассоциативного доступа" - я русским языком сказал: "Раз кортежи идентификатора иметь не могут - будь любезен рыскать по ЗНАЧЕНИЯМ", а даже для чтения этого самого значения доступ к кортежу ОБЯЗАН быть обеспечен каким-то иным способом. И не надо ля-ля: клевета Кодда на сетевую модель, попавшая чуть ли не во все учебники, НАПРЯМУЮ связана с тем, что "получение физического доступа к кортежу ЕСТЬ вопрос модели данных". Например: "изменение структуры базы по-прежнему требует значительных усилий и времени, поскольку операции модификации и удаления данных ТРЕБУЮТ ПЕРЕСТАНОВКИ УКАЗАТЕЛЕЙ" - очевидный идиотизм. Или еще один: Those "pointers" needn't be physically represented in storage by actual pointers, but the user can always think of them as actual pointers. (That's the network model!) А вот в РМД - да, согласен "как это реализуется в конкретной системе - для модели совершенно неважно" - те самые "двойные стандарты", то самое жульничество. Я потому и говорил: "на практике РМД на фиг никому не нужна". А потому (раз уж Вы сами хотите "рассуждать о модели, не сбиваясь на понятия уровня реализации") давайте отразим в статье, что РМД имеет значение разве что для отвлеченной псевдотеоретической болтовни на тему баз данных. ;) И не надо, пожалуйста, "советовать ознакомиться" путем тыканья в мегатонные доки - на такие "советы" у меня давно есть стандартный ответ: "Ознакомьтесь сами, раз уж Вы ничего внятно оттуда процитировать не можете".

2.2.2. Вот и почитайте приведенную Вами же цитату. Разумеется, Дейт не полный кретин, чтобы "всё нереляционное запрещать". Он и говорит: ВНЕ РМД - делайте, что хотите. А теперь взгляните на название обсуждаемой статьи. Так что Дейт говорит не "иное", он говорит "то самое". ;)

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

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

P.S. Мне АБСОЛЮТНО насрать на "персонажа по имени Чернышов Андрей Леонидович", как и на Ваше отношение к нему (а после разговора в "базе данных" - и ко мне). Никакой "ненависти к РМД" у меня нет, и не было - хотя бы потому, что "ненависть" и "презрение" - понятия несовместимые. И уж если Вы считаете себя вправе говорить о моем "примерно таком же невысоким уровнем познаний в РМД", так не городите ахинею сами чуть не в каждом предложении - давайте формулировки, пригодные для внесения в текст статьи, дабы она не выглядела столь позорно, как сейчас. Напоминаю Вам Ваши же слова: "Вместо споров попробуйте дать чёткую формулировку". Тем более, что я явно Вас просил именно об этом.

94.241.42.164 15:06, 25 января 2010 (UTC)Владимир Рыбинкин

Поскольку ваш агрессивный стиль ad hominem не позволяет вести нормальную дискуссию, её придётся, к сожалению, прервать (как ранее вы вынудили меня прервать дискуссию в статье "база данных"). Уж не знаю почему вы не регистрируетесь в Википедии, но -- вот совпадение -- незарегистрированному участнику гораздо проще до поры избегать проблем с администраторами по поводу нарушения правил. Напоследок покажу "качество" ваших аргументов для стороннего читателя. Итак, вы пишете "что реляционная алгебра может обойтись и без отдельной операции декартова произведения" - это да, это оглушительная новость. По крайней мере для меня, с моим "невысоким уровнем познаний в РМД". :) Третий манифест (перевод: М.Р. Когаловский, новая редакция: С.Д. Кузнецов, 2009 г.) также ни слова об этом не говорит". Читаем раздел Новая реляционная алгебра (С.Д.Кузнецов):

Операция декартова произведения (TIMES) заменена операцией естественного соединения, которую, подчеркивая наличие двойника этой операции в логике предикатов, Д&Д (Дейт и Дарвен) называют просто >AND<. TIMES становится частным случаем >AND<.

То есть недвусмысленно сказано, что отдельной операции декартова произведения в базисе алгебры может и не быть, если она рассматривается как частный случай соединения. Это и понятно, ведь если условием соединения будет константа "истина", то соединение эквивалентно декартовому произведению. Ну а теперь пусть каждый сам оценит, кто "недобросовестно поработал" (во вашему выражению) с 3 Манифестом, вы, или же Кузнецов с Когаловским. Евгений Мирошниченко 03:55, 27 января 2010 (UTC)

Я зарегистрировался сразу - мне просто лень авторизоваться. Вот это другое дело: ссылка не на Третий Манифест, а куда-то в иное место. Спасибо, посмотрим... 83.229.208.1 07:46, 27 января 2010 (UTC)Владимир Рыбинкин

Это ссылка на обзор и частичный перевод С. Д. Кузнецова книги Дейта и Дарвена "Foundation for Object/Relational Databases: The Third Manifesto", то есть, в итоге, ссылка на информацию из Третьего Манифеста. Евгений Мирошниченко 09:12, 27 января 2010 (UTC)

Предложения в текст статьи.

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

Сам Кодд пропагандировал трехзначную логику (истина, ложь и NULL), а в 1990 даже четырехзначную, однако из-за высокой сложности(!) в Третьем Манифесте все это запрещено: "больше никаких неопределенных значений и больше никакой многозначной логики"!

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

83.229.208.1 07:43, 27 января 2010 (UTC)Владимир Рыбинкин

Новая реляционная алгебра

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

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

1. Итак, "новая реляционная алгебра" (по Кузнецову, ее создание относится к высшим достижениям авторов, и у него даже "отсутствуют какие-либо замечания по поводу этого материала") НЕ ЕСТЬ "оригинальная алгебра Кодда", и отличается от нее "четырьмя основными аспектами". Факт, бесспорно, положительный. Я бы даже сказал - знаковый, символизирующий агонию РМД.

2. Бросается в глаза изменение синтаксиса, который теперь более привычен для восприятия - разумно (тем более, что это явно озвученная цель), но пока это ни о чем не говорит. Итак, если я ничего не пропустил, имеем AND, OR, NOT, RENAME, REMOTE (скорее всего, REMOVE?), COMPOSE и TCLOSE. С "заменителями" (placeholder) они, как мне кажется, чего-то перемудрили - обоснование какое-то странное: "логические переменные" вполне могут быть "переменными в смысле языка программирования".

3. Атрибуты по-прежнему используются для идентификации - правда, в "формальных определениях" появилась пара "имя атрибута - тип атрибута", то бишь "голые" имена вроде как могут и дублироваться. Нет, извиняюсь - запрещено... Кстати, термин "кортеж" явно перегружен: "Пусть tr - это кортеж, соответствующий Hr; т.е. tr - это множество(?!) упорядоченных кортежей..." или это издержки перевода? Ах, вот оно что: "Любое подмножество заголовка - это заголовок, любое подмножество тела - это тело, и любое подмножество кортежа - это кортеж". Ну, допустим...

4. Операции:

4.1. NOT. Ну, отношение на входе. А откуда берется дополнение? Из БД? Туманно как-то без второго аргумента...

4.2. REMOVE. Вроде как тривиальное удаление столбца. А как насчет CREATE или COPY? А, ну да, с COPY у них проблемы...

4.3. RENAME. Ну, это понятно - когда-нить допрут, что метаданные - это ТОЖЕ данные... Упс! "Операция RENAME производит отношение"! Ах, да - это ж у них "сфера интересов" такая.

4.4. AND. "Называлась ранее естественным соединением". И кому только эта хрень нужна? Все эти "ловушки соединений"?

4.5. OR. Похожа на AND как однояйцевый близнец. TIMES, кстати, больше похожа на OR, чем на AND (если я что-нибудь в чем-нибудь понимаю). О, даже так? Некий де Морган показал, что это одно и то же (любую из них можно выбросить)? Впрочем, у меня тоже нет никакого желания "сократить алгебру A до всего лишь трех операций".

4.6. COMPOSE. "Макро"-операция: AND с какими-то REMOVE. Стало быть, на фиг не нужна.

4.7. TCLOSE. Вау! Это какая-то песня: в разговоре про реляцию увидеть слова "направленный граф" - приятная неожиданность! Бедняга Кодд - как он там себя чувствует после такого? Я и говорил про агонию РМД в ожидании неизбежной капитуляции перед графовой МД (термин "сетевая" слишком загажен "ребром" на CODASYL по вине Кодда). Ну, это совсем МОЯ зона...

Ха-ха-ха! Это, оказывается, то, что у нас называется "виртуальными ребрами"! У них что, совсем крышу снесло?! Сколько тысяч лет будет выполняться такая операция в сколько-нибудь сложных случаях? И на сколько гига-тера-пета потянет результат (особенно промежуточный)? Тем более, "в виде иерархии с возможно повторяющимися узлами"? А если еще закольцевать - кортежик P3-P1 подкинуть, например - не поплохеет? Я понимаю: "вопросы реализации не интересуют", но надо же и совесть иметь! В третий раз спасибо за ссылку: я просто в восторге - ПОЛНЫЙ нокаут РМД! Для "сторонних читателей": "транзитивное замыкание" есть находение всех путей в графе - от каждого узла к каждому - и запись их в результат (если там его еще нет). Евгений, я не ошибся? :) Алё, Сергей Дмитриевич! У Вас что, в самом деле К ЭТОМУ нет замечаний?!

83.229.208.1 05:39, 28 января 2010 (UTC)Владимир Рыбинкин

Ну так что, писать статью будем, али глазки строить, "обиженный" Вы наш?

Замкнутый круг

В определении (!) присутствует ссылка на «реляционные базы данных», а там — ссылка в обратном направлении. Надо бы исправить. alanubi 16:42, 30 августа 2010 (UTC)

Готово. Евгений Мирошниченко 04:13, 31 августа 2010 (UTC)

Стиль и содержание

На мой взгляд статья слишком специализированая. Кучу сухих терминов, определений. Лучше бы общий простой обзор сделали с примерами, понятный почти каждому. 213.184.224.33 18:23, 10 июля 2008 (UTC)

100% согласен. --Учаснег 01:54, 11 ноября 2008 (UTC)

• Ы! Так сабж где-либо еще (кроме соотв. БД) применяется?? или же нет никаой разницы межны этой статьей и Реляционная БД)...? --Tpyvvikky 22:13, 26 сентября 2012 (UTC)

Список литературы для самообразования по этим вопросам можно найти в разделе «Литература» статьи база данных. ◦ Евгений Мирошниченко ◦ 01:55, 27 сентября 2012 (UTC)

-_о т.е. предлагаете для понимания того что написано в статье (точнее даже в Определении) предварительно ознакомиться ("самообразоваться") со всей имеющейся Литературой? о_О --Tpyvvikky 11:23, 27 сентября 2012 (UTC) ..для нахождения ответа на данный вопрос (см. выше)

• статья действительно выглядит очень сухой. Надо будет подумать, как можно её оживить. Более того, в конце говорится об устаревании других архитектур, что как я полагаю, неверно. РоманСузи 03:45, 27 сентября 2012 (UTC)

  Она не сухая, она просто слишком маленькая. Грубо говоря, одни кости (краткое описание теории, даже не теории, а философии). А аноним 213.184.224.33 хочет даже не мяса, а сала. Тут надо просто писать и писать. Разумеется, не вместо, а в дополнение, т.к. «лучше бы общий простой обзор сделали» — это позиция ленивого дилетанта, который хочет перескочить скучный этап определений и основ и сразу каким-то чудом понять весь смысл. ◦ Евгений Мирошниченко ◦ 05:44, 27 сентября 2012 (UTC)

Менее абстрактно и более удобоваримо

читайте здесь http://citforum.ru/database/dbguide/3-2.shtml

Спасибо автору. 195.66.137.110 18:35, 10 октября 2012 (UTC)

Кому предлагаете читать? И пособие Кириллова проглядывали, да и получше книги читали. Уж больно Кириллов убого и неглубоко пишет, с большим числом ошибок. Впрочем, для начинающих, возможно, и ничего. ◦ Евгений Мирошниченко ◦ 00:14, 11 октября 2012 (UTC)