Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7 8   вперед  Ctrl      все
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
mir
M( Y SEMIJOIN X ) WHERE Z='1'
Или так, если задача несколько иная:
M( Y SEMIJOIN X WHERE Z='1')
29 дек 06, 17:34    [3598792]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Александр Савинов
Вот как бы я это записал:
Collection result = 
FORALL(x in X) // Аналог FROM 
IF x instanceof Y // Аналог WHERE 
RETURN x.m() // Аналог SELECT 

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

Collection result = 
FORALL(x in X, y in Y) 
IF( x->prop1->prop2 > 10 AND count( y<-prop5<-prop10<-Table3 ) > 5 ) { 
  int localVar = x->p2; 
  Collection localCollection = y->p8->Table10<-p3; 
  RETURN localVar +2 - localVar*5 - sum( localCollection->intProp ); 
} 

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

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

Оценить подобный перл можно по следующей аналогии: в арифметических выражениях алгебра не делает различий между числами, поэтому может содержать числа, которые там совершенно лишние.
Александр Савинов
Подход SQL более прямолинеен и более дубовый, а на практике приводит к серьезным трудностям для обычного рядового или даже сержанта на SQL-фронте.
У SQL есть многочисленные недостатки, но SQL не есть РМД. Можно изобрести и другой реляционный подъязык, более удобный и компактный, но надо отличать дефекты модели данных и дефекты синтаксиса конкретного языка. Вам это давно пытаются втолковать, но вы не видите разницы. Это особый род избирательной слепоты.
Кроме того, повторю, что не вам судить о серьезности практических трудностей SQL, поскольку вы не имеет практического опыта работы с ним. Это как у Жванецкого: «давайте спорить о вкусе устриц с теми, кто их ел, до хрипоты, до драки». Вы спорите о вкусе устриц с теми, кто их ест.
Александр Савинов
Это человек-НЕ, спорить с ним невозможно, поскольку там нет мнения и нет аргументов, а есть отрицания в стиле "это не так, потому что вы некомпетентны".
Но ведь вы действительно некомпетентны. Или вам привести сводный список ваших перлов? Из последних: "JOIN — это декартово произведение".

Когда вам указывают на ваши ошибки, естественно, что «спорить с ним невозможно». Гораздо проще жаловаться и хныкать, что вас-де «зажимают» и «забижают» какие-то недобрые реляционщики. И этот подход вы, почему-то, назвали "конструктивным".
29 дек 06, 18:13    [3598893]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
mir
okdoky
В конструкции FROM мы не обязаны указывать имена отношений. Да и нужны ли они вообще?
Имена переменных отношений -- нужны. Сам FROM -- не нужен.
FROM это то, с чего начинается любой запрос к данным, поскольку именно здесь указываются исходные коллекции вместе с именами переменных. Убрать его никак нельзя (разве только для целей РМД). Соответственно без имен коллекций тоже нельзя обойтись (это могут быть статические таблицы или любые другие ссылки на коллекции данных). Например, конструкция
... FROM Table1 t1, Table2 t2, ..., TableN tN ... 
означает создание n-мерного пространства, над элементами которого можно выполнять действия (обычно выборку). Но лучше это записать в привычном всем виде как самый первый элемент запроса:
FORALL( Table1 t1, Table2 t2, ..., TableN tN ) {
  // Тело запроса. Здесь можно использовать другие таблицы
}
Теперь понятно, почему убрать FROM нельзя без потери естественности восприятия и простоты выражения запросов?
29 дек 06, 18:20    [3598903]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
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. Так что я желаю Вам в новом году расширить этот круг и выйти за границы РМД. Да, это очень тяжело, поскольку Вы думаете, что там, за этой границей просто ничего нет (весь мир это РМД), но Вы попробуйте и не пожалеете.
29 дек 06, 19:00    [3599001]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
U-gene
Member

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

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

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


И опять Вы облажались в своих выводах. Я же говорю - Вы просто не умеете её готовить!

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

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


Итак я спросил, что Вы можете предложить взамен? Вы же ответили, что де даже гнаться не будете. То есть взамен РМД(по крайней мере в том, что касается манипулирования данными) Вы предложить ничего не можете. Так и запишем

Умиляет Эта Ваша пара фраз
у нее есть ряд внутренних логических дефектов
и буквально через пост
внутренне РМД вполне гармонична
Впору задуматься о Ваших персональных внутренних, логических.... :)

Александр Савинов
U-gene
Мы можем описать данные в системе как угодно (ИМХО почти как угодно),

В системе да. А в модели нет, не можем. В РМД есть только отношения и операции, а понятия система в ней нет. Так что кроме отношений ничего нельзя использовать.
Ну так я и собираюсь в своей практической деятельности пользовать систему. Не знаю как Вы :)

Надо ли это понимать как то, что Вы считаете правила нормализации не самым главным механизмом РМД?
Это механизм позволяющий избавиться от избыточности данных в системе. Это не элемент модели.


Александр Савинов
U-gene
использовать ссылки, строить иерархии (здесь я перечислил только то, что, исходя из предыдущих сообщений, Вам интересно),

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

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

Александр Савинов
Декартово произведение (JOIN)
ВАУ!Сильный ход. Боюсь только, что в ответ на это мое замечание, Вы скажете, что я тоже человек-НЕ и использую только аргументы типа "это не так, потому что вы некомпетентны".

Александр Савинов
...в частности, на нижнем уровне могут быть блоки диска, а на верхнем концептуальные сущности...
....избавьте, ради бога. :)

Александр Савинов
FROM это то, с чего начинается любой запрос к данным, поскольку именно здесь указываются исходные коллекции вместе с именами переменных.....
.....Теперь понятно, почему убрать FROM нельзя без потери естественности восприятия и простоты выражения запросов?
Опана!....
..
...
....
.....Вызез испатстала! Ну что mir , признавайтесь - умыл Вас Александр! Можно пойти дальше и несогласится с Александром. Например для меня FROM выглядет всё же не очень естественным - для меня естественне ИЗ. Даешь РМД на русском, поскольку он великий и могучий!

Всё, Александр я умываю руки :). А Вы, пожалуйста, продолжайте - с удовольствием Вас почитаю на досуге, в минуты скуки и печали. :)
29 дек 06, 19:16    [3599033]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Александ Савинов
История учит, что декларативный подход умер, поскольку люди (разработчики) так не мыслят
Друг мой, это уже даже и не смешно. Я например именно так мыслю. Вот у меня ребята сидят - стороннии разаработчики приложений для весьма изветсной ERP системы со своим собственным языком, средствами построеняи отчетов и тп.п. Так вот - они были рады как дети, когда поняли, что вместо того, что бы ползать по записям, они могут сляпать SQL запрос для используемого сервера, а результат вывести в EXCEL. И все это по времени в десятки раз быстрее получается.

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

Александр Савинов
Ну тогда сведите все к операциям на процессоре, и скажите, что это и есть лучшая модель данных. А если кто возразит, что где же там данные, то Вы ответьте, что процессор не должен это знать, а должен просто загружать байты из памяти и оперировать ими, а соответственно претензии не принимаются. Глупость очевидная, но Вы почему-то упорно мыслите именно так.
Не, я так не скажу Множество типов не определено? Нет. Значит операции на процессоре - это не модель данных Не буду я так говорить (и любой человек. который знает значение термина "модель данных", так не скажет) так что этот Ваш аргумент не канает.

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

С Новым Годом! :)
29 дек 06, 20:08    [3599132]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Александр Савинов
Откуда Вы увидели, что это не декларативный язык?

Если это декларативный язык, то PL/SQL декларативный язык - там тоже есть такие ключевые слова для циклов. А парни из Оракла все еще думают, что это типичный процедурный язык. К сожалению, многие разделяют именно их точку зрения. А так счас бы Оракл оторвался ото всех капитально.

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

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


Александр Савинов

А один из этих принципов говорит, что для нахождения связанных записей надо строить декартово произведение, для которого есть другое прямое применение:

Не такого принципа в РМД. Есть алгебраическая операция соединения. А декартоврое произведение - ее частный случай.

Александр Савинов

А один из этих принципов говорит, что для нахождения связанных записей надо строить декартово произведение, для которого есть другое прямое применение:

Не такого принципа в РМД. Есть алгебраическая операция соединения. А декартоврое произведение - всего лишь ее частный случай.

Александр Савинов

Так вот, в РМД эти роли никак не различаются. А конкретный диалект языка никак не меняет эту ситуацию. Это принципиальный недостаток модели как таковой.

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

Александр Савинов

Из-за таких людей РМД и страдает.

Типа позаботились о РМД. Рано.
Пока вроде не страдает, к Вашему разочарованию, совсем. Не смотря на все Ваши усилия.
Пока она на вершине успеха. Другой сравнимой с ней по качеству МД пока формально не зафиксировано. Там где она не адекватна, мы все равно видим почти обычное проггрество (хотя и ООП), а там где она хороша - другие и близко не стоят. Возможно, она уйдет в историю, но наверное, для этого понадобится что-то много большее, чем то что сейчас есть. Какие-то достижения в компьютерных науках, которые пока, скорее всего, если и есть то слишком в зачаточном состоянии, чтобы быть отчетливо видимыми.
29 дек 06, 20:10    [3599142]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
Александр Савинов
Member

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

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

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

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

U-gene
Александр Савинов
U-gene
использовать ссылки, строить иерархии (здесь я перечислил только то, что, исходя из предыдущих сообщений, Вам интересно),

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

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

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

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

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

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

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

U-gene
С Новым Годом! :)
С новым.
29 дек 06, 20:41    [3599205]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
Александр Савинов
Member

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

Этому история учит только проггеров на процедурных языках. Пролог для написания решения задач ИИ много лучше процедурных языков. Точно так же РМД лучше для БД. А для написания окон - они хуже процедурных универсальных языков. Т.е. в ИИ, например, задачи могут решать на Прологе, Липсе, а потом для реализации прог каких-то там отдают обычным проггерам. А для БД - языки БД и в последствии не нуждаются в замене, если МД приличная. Впрочем, при определенных достижениях в ИИ может прийти еще время Пролога и Липса и для конечных прог.
О, золотые слова! Это то, чего я хочу донести, т.е. многополярный мир без блатных или избранных. Любой подход может быть удобным или неудобным, адекватным или неадекватным. Любой подход можно критиковать, в том числе формально безупречный (как Пролог или РМД). За это и выпьем.
29 дек 06, 20:51    [3599215]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
okdoky
Member

Откуда:
Сообщений: 349
mir
Далее, работа с БД обычно ведется сразу с множествами взаимосвязанных "объектов" (в РМД -- фактов), при этом идти от одного "объекта" к другим "объектам" -- задача столь частная, что не заслуживает особого внимания.
Эээ…. Хорошо, поясню. Почему вы в конструкции X.Y или X/Y видите переход от одного объекта к другому? Здесь выражен переход от одного множества X к другому Y. Чтобы вам было понятнее, X и Y по сути атрибуты той глобальной таблицы, которая получается после NATURAL JOIN примененной ко всем нормализованным таблицам БД. Чтобы выразить переход от более конкретных объектов я мог бы написать X[ID=1]/Y. Все эти вещи уже реализованы в XML-СУБД. Судя по Зигзагу, эта реализация может быть весьма эффективной...
mir
okdoky
Как будет выглядеть на Tutorial D тот запрос, который я привел?
select * from X/Y[Z=’1’].m()
Обращение к методу можете оставить тем же, так как у Tutorial D это не формализуется.
Примерно так:
M( Y SEMIJOIN X ) WHERE Z='1'
Кстати, никаких FROM и SELECT там нет. Прямая запись реляционных выражений.
Неуд. Если в терминах РМ, меня интересует переход от значений атрибута X ко всем связанным с ними значениям атрибута Y. Вы же изобразили соединение двух отношений и применили метод M ко всему соединению, а не к значениям из Y. Пока с Tutorial D что-то не получается?
29 дек 06, 21:09    [3599231]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
okdoky
Member

Откуда:
Сообщений: 349
Повторюсь
select * from X/Y[Z=’1’].m()
Переводится: Отобразить все атрибуты * объектов полученных в результате выполнения метода m() над объектами Y, принадлежащих X и имеющих Z=’1’
29 дек 06, 21:14    [3599234]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
U-gene
Member

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

Александр Савинов
Дайте нам, пожалуйста, второй шанс, мы новый истинный коммунизм построим на основе Tutorial
Ну хоть как то манипулировать данными он позволяет. Хоть что-то. А в Ваших, извините, утопиях этого нет. Так что увольте. Мне для какого-нибуть анализа продаж этого будет немножко не хватать.


Александр Савинов
U-gene
Это механизм позволяющий избавиться от избыточности данных в системе. Это не элемент модели.
О, самое интересное вдруг взяли и выкинули.. Мне нравится фраза "бороться с избыточностью", которая собственно и говорит, что проблемы все-таки есть. Действительно, сделали модель, а потом оказалось, что это не модель вовсе, поскольку в ней теперь надо бороться с возникающими проблемами типа избыточности.


Что Вы! Активно пользуюсь!

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


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

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

Тока я не понимаю, почему это я увиливаю и оправдываюсь. Или эта фраза на бестолковую публику рассчитано?

Александр Савинов
Вообще, вот Вам напутствие на 2007 год: Данные не могут существовать вне пространства (контекста), а пространство это прежде всего ссылки.
ВАУ! Ккая блистательная мысль! Значения не могут существовать вне системы, которая должна обеспечить доступ к ним. Где то я про это читал? или даже писал? Но все равно спасибо... правда про ассоциативный способ доступа Вы таки забыли....хотя чему же тут удивляться, когда Вам ссылки даже в предметной области мерещатся.

Но вообще это своего рода искусство - с умным видом говорить о банальностях.

Александр Савинов
Еще раз: ссылки - это часть модели данных, поскольку данные без пространства и без ссылок не имеют смысла. Применение ссылок так же как и смоделированных данных, это уже может вопрос программирования.
Друг мой, видимо Вы втайне надеетесь, что от многократного повторения фразы, она станет истиной. Зря. Слова "Еще раз" и "Я считаю" доказательствами не являются.

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

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

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

Александр Савинов
Да нет же. Все развивается. И что было хорошо 30 или 20 лет назад, может стать просто неудобным из-за низкого уровня. Так что не надо меня сильно ругать, а лучше взгляните на мир данных честно без религиозных предубеждений в идеальности реляционного учения.
Ей богу, надели уже эти Ваши обвинения в религиозности. Я уже про это писал. Тогда вся математика - это религия.
29 дек 06, 21:22    [3599240]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Александр Савинов
Но главное, что я хочу донести здесь без всякого успеха это то, что формальная чистота вовсе не означает удобности, естественности и полезности.

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

Или Вам принципиально РМД подвинуть? Так Вы же не предлагаете ничего взамен - так что она двигаться пока не будет. Предложите - тогда видно будет.

Александр Савинов
не то что книжки какие-то читать. :-)
Заметно.
29 дек 06, 21:40    [3599284]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
Александр Савинов
Member

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

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

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

U-gene
Тогда вся математика - это религия.
Я не хочу Вас расстраивать, но в математике тоже ведутся очень большие споры, причем вовсе не по поводу формальной корректности. А иначе мы бы до сих пор геометрией Эвклида пользовались бы или вообще ничего не было бы. Я как раз Вам и хочу донести мысль, что если обычная геометрия работает и корректна, то это не значит, что нет другой геометрии, более удобной, более адекватной и более общей. Попробуйте вернуться на пару сотен лет назад и объяснить кому-то, что кроме обычных чисел могут быть еще какие-то комплексные. Вас тут же на костре сожгут просто за саму постановку вопроса. Так что (очередная) аппеляция к математике не проходит.
29 дек 06, 22:17    [3599339]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
U-gene
Александр Савинов
Но главное, что я хочу донести здесь без всякого успеха это то, что формальная чистота вовсе не означает удобности, естественности и полезности.

Друг мой, такое осЧусЧение, чтоВы живете в миер населенном враждебными призраками, с которыми постянно боритесь :). Зачем? Все тут в один голос сказали, что язык управления системой хранения должнем быть многополярным и обладать многими возможностями.
Вообще-то, все в один голос говорят, что мы не обсуждаем языки и системы, а обсуждаем модели данных и только модели данных. Либо Вы не понимаете в чем разница либо слушаете только себя, поскольку очередной раз поднимаете один и тот же вопрос.
29 дек 06, 22:24    [3599345]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
Александр Савинов
Member

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

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

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

mir
Но ведь вы действительно некомпетентны. Или вам привести сводный список ваших перлов? Из последних: "JOIN — это декартово произведение".
Может еще список опечаток в качестве компромата приведете? Вообще-то, во всех предметных спорах Вы проиграли. Но в конце всегда убегали со словами "а РМД все равно самая лучшая, поскольку основана на теории множеств, а плохие это языки и системы". А свои ошибки, на которые Вам здесь постоянно указывают, Вы почему-то не хотите исправлять. Вы похожи на человека, который в качестве аргумента говорит, что "я это в газете прочитал". Научитесь думать своей головой и делать свои собственные выводы, вместо того, чтобы чужие мысли повторять, тем более, если Вы не понимаете их суть. Как говорится, РМД это не догма, а руководство к действию. А вот для Вас это догма.
29 дек 06, 22:41    [3599381]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
А может забанить дурака, а?
Ну нельзя же так...

Олегзандра Совиноф, читайде книжке, в кондзе кондзов...

Просдиде, насморг.
29 дек 06, 23:58    [3599558]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
Александр Савинов
Member

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

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

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

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

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

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

Разумно мыслящие наверняка поняли, что это новогодняя шутка. Собственно, перед тем как покинуть это обсуждение, которое явно затянулось (праздник ведь на носу), я хотел бы всех поздравить с этим наступающим событием и пожелать успехов в моделировании данных.
30 дек 06, 01:31    [3599776]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Александр Савинов
Откуда Вы увидели, что это не декларативный язык?
Наличие цикла со внутренними переменными, ветвлениями IF-ELSE внутри итераций и выдачей результата record-by-record — это типичные признаки процедурного подхода. Учите матчасть. У вас вообще с характеристиками языков проблемы (помнится, вы приписали языку ассемблера огромную выразительность).
Александр Савинов
История учит, что декларативный подход умер, поскольку люди (разработчики) так не мыслят, поскольку это неудобно, поскольку противоестественно.
Декларативность в SQL и других реляционных языках жива, поэтому вше утверждение фактологически ложно. А если для вас мыслить — противоестественно, не стоит приписывать то же остальным.
Александр Савинов
А именно, для реализации связей в РМД предлагается строить декартово произведение, что есть попросту глупо. В результате во FROM включаются как независимые таблицы, так и таблицы, которые так или иначе связаны с исходными. Мухи и котлеты все вместе в одном FROM. И Вы говорите, что это хорошо? Подумайте в новом году над этим.
А вы подумайте над тем, что в очередной раз облажались. Никто и никогда (кроме идиотов) не включает во FROM независимые таблицы. Только взаимосвязанные. Как вам не стыдно принародно демонстрировать такое невежество.
Александр Савинов
mir
Предложение FROM (как и весь синтаксис SQL) есть наследие первых авторов SQL, которые очень торопились состряпать язык для РСУБД, но не потрудились хорошенько подумать над его дизайном и теорией (РМД) в целом.
Ну вот опять попытка свалить на кого-то почему все так плохо сейчас. Мы же о ПРИНЦИПАХ модели говорим.
Так о принципах или о синтаксисе? Если о принципах, то в РМД нет никакого FROM. Доказательство — наличие других реляционных языков (скажем, Tutoral D, QBE), безо всякого FROM.
Александр Савинов
А один из этих принципов говорит, что для нахождения связанных записей надо строить декартово произведение
Если в запросе необходимо связать факты из двух отношений, то разумеется надо применить ту или иную операцию, позволяющую эти факты таки связать (что здесь криминального?). Не обязательно декартово произведение (практически никогда), чаще всего — эквисоединение. Но не только, есть и другие бинарные операции — объединение, разность, пересечение, другие виды соединений. Так что вы в очередной раз сморозили глупость.
Александр Савинов
для которого есть другое прямое применение: построение многомерного пространства из исходных таблиц.
Укажите хоть один источник, где сказано, что прямое назначение декартова произведения множеств — «построение многомерного пространства из исходных таблиц». Полагаю, не сможете. Ибо это ваши выдумки.
Александр Савинов
Так вот, в РМД эти роли никак не различаются. А конкретный диалект языка никак не меняет эту ситуацию. Это принципиальный недостаток модели как таковой.
С учетов вышесказанного, никакого принципиального недостатка РМД не наблюдается. Пока наблюдаются ваши ляпы и выдумки.
Александр Савинов
mir
У SQL есть многочисленные недостатки, но SQL не есть РМД. Можно изобрести и другой реляционный подъязык, более удобный и компактный, но надо отличать дефекты модели данных и дефекты синтаксиса конкретного языка. Вам это давно пытаются втолковать, но вы не видите разницы. Это особый род избирательной слепоты.
Я как раз говорю о принципах
Пока вы говорите не о принципах, а о синтаксисе, ибо в РМД никакого FROM (к которому вы прицепились), просто нет. Упомянутый вами якобы имеющийся «принцип обязательности декартова произведения» я рассмотрел выше, он несостоятелен.
Александр Савинов
а вот Вы пытаетесь объективные недостатки модели свалить на SQL, на начальный этап развития, на разработчиков и на кого угодно, только не на саму модель.
Но вы пока ни одного объективного недостатка не продемострировали. Ваши теоретические изыски пока показывали слабость ваших знаний, а ваши отсылки к практике несерьезны, ибо этой практики у вас нет.
Александр Савинов
По Вашему она идеальна что ли?
Я этого нигде не говорил. Идеального нет ничего, но есть более и менее пригодные инструменты для конкретных задач. Для типовых задач БД пока лучше РМД ничего не предложили. Вот и все.
Александр Савинов
Вы похожи на человека, который говорит "я крутой каратист, поскольку я три книги про карате прочитал". Если Вы прочитали пару популярных книг по РМД, то этого недостаточно, чтобы судить о ней.
Оставьте ваши инсинуации. Вы не знаете, сколько и чего я чего прочитал. Пока что ясно только одно — таких книг я прочитал гораздо больше, чем вы. Вы же явно не читали ни 3 Манифест, ни последних изданий Дейта, ни книг по истории технологий БД (типа Когаловского), ни литературы по внутреннему устройству РСУБД (ваши пассажи про роль ПК в индексах это говорят) … О разнице в практическом опыте я вообще молчу.
Тем не менее вы — беретесь судить. А мне вот почему-то судить об РМД запрещаете.
Александр Савинов
Из-за таких людей РМД и страдает.
Пока РМД не страдает, не волнуйтесь.
Александр Савинов
Кроме того, нельзя судить о чем-то только изнутри. А у Вас же очень узкий взгляд на вещи, поскольку круг познаний ограничивается только некоторыми аспектами SQL.
Ой-ой, вы судите о моем круге познаний :) Ну ладно, допустим на минутку, что все это так — но у вас даже и того нет. Вы похожи на человека, начитавшегося журнала «Здоровье», который с этим багажом пришел к хирургам в операционную советовать, как им правильно оперировать. Вы-де, хирурги, судите только изнутри своей профессии. У вас-де узкий взгляд на вещи. Истинно-де вам говорю, и скальпель вы держите неправильно, и разрез тканей не той формы, да и халат не так одели. Со стороны-то виднее, ясное дело.
30 дек 06, 10:34    [3599897]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
okdoky
Здесь выражен переход от одного множества X к другому Y. Чтобы вам было понятнее, X и Y по сути атрибуты той глобальной таблицы, которая получается после NATURAL JOIN примененной ко всем нормализованным таблицам БД.
Сначала определитесь, являются ваши X и Y множествами объектов или атрибутами. Если вы не знаете разницы — вам пока разговаривать о базах данных рано.
okdoky
mir
okdoky
Как будет выглядеть на Tutorial D тот запрос, который я привел?
select * from X/Y[Z=’1’].m()
Обращение к методу можете оставить тем же, так как у Tutorial D это не формализуется.
Примерно так:
M( Y SEMIJOIN X WHERE Z='1') 

Неуд. Если в терминах РМ, меня интересует переход от значений атрибута X ко всем связанным с ними значениям атрибута Y. Вы же изобразили соединение двух отношений и применили метод M ко всему соединению, а не к значениям из Y. Пока с Tutorial D что-то не получается?

Первое. Прекратите на ходу менять условия задачи. Ранее было сказано следующее: Отобразить все атрибуты * объектов полученных в результате выполнения метода m() над объектами Y, принадлежащих X и имеющих Z=’1’
То есть в исходной постановке были множества объектов X и Y. А теперь вы говорите об атрибутах X и Y. (Атрибутах неясно чего, кстати.)

Второе. Задачу в начальной постановке я решил. Метод M применен не ко всему соединению двух отношений, а именно к кортежам отношения Y, связанными с X. Читаем про SEMIJOIN.
Пока вам неуд.
И прекратите на ходу менять условия задачи.
30 дек 06, 10:50    [3599932]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
okdoky
Member

Откуда:
Сообщений: 349
mir
То есть в исходной постановке были множества объектов X и Y. А теперь вы говорите об атрибутах X и Y. (Атрибутах неясно чего, кстати.)

Второе. Задачу в начальной постановке я решил. Метод M применен не ко всему соединению двух отношений, а именно к кортежам отношения Y, связанными с X. Читаем про SEMIJOIN.
Пока вам неуд.
И прекратите на ходу менять условия задачи.
Ну вот, опять мы не понимаем друг друга. Давайте тогда так. Я поясню вам смысл X/Y на языке XPath, а вы проясните для меня операцию Y SEMIJOIN X. Это будет конструктивнее, чем отправлять друг друга в читальный зал. Впрочем, элементарное представление нам обоим не мешало бы иметь заранее в смежных областях. Надеюсь вы знаете XML. Иерархические структуры в нем это отображение JOIN которые реляционщики вынуждены применять при переходе от атрибутов одних таблиц к другим. Да, на месте X и Y могут находится как объектные переменные (обозначающие множество объектов), так и то, что называется атрибутом в РМ.
Пример двух отношений R и R1
R(X, Y, A)
  x, y, a
  x, y1,a
R1(Y, Z, B)
   y, 1, b
   y1,2, b
  y2, 3, b
Если я правильно догадываюсь, результатом R1 SEMIJOIN R будет таблица R2(Y, Z, B) со значениями Y, одинаковыми в обеих таблицах и полученная из NATURAL JOIN для R и R1?
R1(Y, Z, B)
   y, 1, b
   y1,2, b

Это не совсем то, что я просил изобразить для X/Y. Вы действительно оперируете множествами отношений. В иерархических моделях реализованных на Zigzag и XML-СУБД имена отношений отсутствуют вообще и используются переменные множества объектов. Те же данные из R и R1 можно в XML представить так
<X ID="x">
  <A>
    a
  </A>
  <Y ID="y">
    <Z>
      1
    </Z>
    <B>
      b
    </B>
  </Y>
  <Y ID="y1">
    <Z>
      2
    </Z>
    <B>
      b
    </B>
  </Y>
</X>
Возможно, это менее наглядно чем в табличном виде. Судить не берусь. Но это лучше отражает реальные связи. Идентификаторы ID в XML можно не использовать вообще. То есть ограничится некими внутренними ссылками, известными самой системе. Иногда, когда множество взаимосвязанных таблиц со сложной структурой (записи одной таблицы зависят от записей другой или вложены в нее) XML может даже оказаться удобнее. Особенно конечно при транспортировке данных. Операция X/Y для таких данных даст нам узлы с ID равным y1 y2. Для реляционной модели это значения атрибута Y в таблице R1.

На Zigzag те же данные из таблиц R, R1 могут выглядеть так
X:x(
  A:a,
  Y:[
      y(Z:1,B:b),
      y1(Z:2,B:b)
    ]
)
И тот же запрос на Zigzag Y:*(X:*) или {X:*}.Y

Очевидно для вас это открытие, но повторюсь в объектных моделях не нужны переменные отношений в том виде как их понимали Вы.
30 дек 06, 13:15    [3600109]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2402
Блог
okdoky
Это не совсем то, что я просил изобразить для X/Y. Вы действительно оперируете множествами отношений. В иерархических моделях реализованных на Zigzag и XML-СУБД имена отношений отсутствуют вообще и используются переменные множества объектов.
Друг мой... Возможно это для Вас новость, но отношения - это именно переменные множества объектов. Объекты строго специфицированы и сами по себе являются множествами (кортежи). Но сути это не меняет.
30 дек 06, 20:40    [3600556]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
разговоры слепого с глухим. С Новым годом, познаний в моделях (не только своих, но и "чужих"), свободы выбора и успехов всем!
30 дек 06, 21:22    [3600626]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Александр Савинов
От такого широкого спектра мнений у многих простых граждан, привыкших к наличию только одного мнения и одной теории, крыша едет.

Насчет широты спектра Вы явно преувеличили. Слов много, путаницы в понятиях достаточно. Что есть то есть.
Прогерров от ООП, решивших что в каких-то там БД для них будет легкая прогулка, и до Вас было и здесь и в реале полно. Проблема только в том, что еще в начале 90-х в БД пробовали прорваться более реальные спецы от ООП (которые как минмум код процедурного языка не будут считать декларативным).

Александр Савинов
Легализация ссылок. ...Ссылки должны присутствовать в модели данных и для них должны иметься адекватные средства описания

Када построите стоящую МД, тада и раскажите что у Вас там должно присутствовать, и как оно должно там описываться. А другим изобретателям МД зачем прислушиваться к Вашим требованиям? Тем более их понимать можно как угодно. В дореляционных МД ссылки присутствуют так или иначе. В ООМД тоже. А что Вам там не нравится из Вашего текста не ясно.

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

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

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

Какое у Вас там пространство нарисовалось? Евклидово, топологическое, Хана-Банаха или какое?
Ну, да, раскажите здесь что есть в РМД. Про моделирование поучите. Про то что у него там бОльшая часть, что мЕньшая. Здесь ить никто никогда ничего не моделировал. Ждали проггеров от ООП, когда им надоест обработкоу изображений или что-то подобное моделировать и они придут
БД заниматься.

Александр Савинов
Созидатели эволюционисты (есть способ лучше, я знаю как): shuklin, okdoky, я

Созидатели или нет, но к одной группе Вас можно. У всех у вас есть вера, что вы продвините значительно БД. Что здесь благодатная почва, где можно не напрягаясь добиться больших успехов.
Типа легализовал ссылки и готово. Привистовал поняие "пространство" и дело в шляпе.


Александр Савинов
Практики (если это когда-то заработает, то почему бы и нет, но пока в гробу я видал любые новшества): vadiminfo, 4321, !

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

Александр Савинов
Революционеры подпольщики (запрещены по идеологическим причинам): ЧАЛ

Как раз ЧАЛ не революционер, а наоборот ретроград. Впрочем, его следовало отнести к первой группе, по некоторым признакам грамотности при критике РМД.
То что его запретили - это, конечно, вызывает озабоченность в плане свободы слова.
Я не сочувствую его мыстлям и методам пропаганды, но мне важно, чтобы он имел право говорить то что хочет. Иначе нет уверенности что все говорят то что думают, а не подстраиваются под цензуру.
Но за создание клонов, его бы надо было как-то осудить, но все же не запрещать.
31 дек 06, 01:14    [3600925]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7 8   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить