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

Откуда: Москва. Россия
Сообщений: 1576
Писал, писал, и вдруг БАЦ! пока писал тему закрыли. Почему?

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

Ну вот. В ответ на мой вопрос Вам опять не понравилась РМД (хотя я м попросил пока не фиксироваться на РМД). Ну да ладно.

Далее моё ИМХО. На самом деле все сказанное отностися не только к Вам
1) Вы как то не так пытаетесь использовать РМД. В вашем представлении это нечто, что служит для описания предметной области. Насколько я понял из Ваших слов, вы считаете, что "предметная область должна быть описана как набор отношений" и боретесь с этим, считая (ИМХО справедливо), что такое описание предметной области выглядит корявым и необходимы более ...мммм.... изящные способы.
Но на самом деле требование того, что данные должны быть описаны как множество отношений - это всего лишь условие, делающее возможным применять к этим данным формальные, простые и мощные операции РМД (типа "что бы сложить два значения эти значения должны быть числами"). Это требование к предметной области никакого отношения не имеет. Я сходил по Вашим ссылкам, посмотрел что там написано. Честно говоря я не заметил ничего, касающегося операций. Есть конечно некие попытки организовывать работу с коллекциями, используя FORALL. Но ИМХО это несерьезно. Если Вы пытаетесь что то предложить взамен Реляционной Модели Данных, Вы должны предложить аналогичные возможность - в том числе и для манипулировании данными.

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

Еще раз повторю - нужно очень четко различать формальные модели и языки программирования. Если этого различия не делать, то, конечно, к РМД будут куча претензий. Например, причиной Вашей претензия в невозможности работать с иерархиями, лежит в том, что для Вас имена (отношений и атрибутов отношений) существующие в РМД неразличимы от имен языка. Поэтому Вы думаете, что ежели в РМД есть имя отношения R и имя атрибута A, то в системе , реализующей РМД, ничего глубже чем Х.Y мы изобразить не сможем (Вы заметили? R и A - это имена в смысле РМД, а X и Y - это имена в смысле системы - то есть это разные имена).

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

Например. Я уже давал Вам эту ссылку. В ней описывается ОО система, которая позволяет описывать сложные объекты (в общем их структуру можно опрелить как ненормализованную), использовать ссылки, строить иерархии (здесь я перечислил только то, что, исходя из предыдущих сообщений, Вам интересно), а далее показано, что определение сложной ссылочной структуры, в которой корректно путевое выражение C.*.*.s можно рассматривать как определение переменной отношения с именем C.* , в котором определен скалярный атрибут с именем *.s . Здесь C - имя класса либо имя ссылочной переменной (возможно это групповая ссылка = именованное множество ссылок), s - имя скаляра, *.* остальные имена образующие иерархиию. Это не просто идея - я показываю почему и как это можно сделать. И если в системе как то определена например иерархия a.b.c.d.e, то такая система например гарантирует, что пользователь сможет написать следующие (я использую SQL-подобный синтаксис)
SELECT b.c.d.e FROM a
SELECT c.d.e FROM a.b
SELECT d.e FROM a.b.c
SELECT e FROM a.b.c.d
Здесь а - имя типа(класса), потому иерархия опреляется когда мы описываем тип а, но вместо него можно спользовать ссылку refa на объект(ы) типа a.

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

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

Именно поэтому я и говорю вам, что Ваши предложения по описанию предметной области никак РМД не противоречат.
27 дек 06, 18:05    [3589798]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
Александр Савинов
Member

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

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

U-gene
Еще раз повторю - нужно очень четко различать формальные модели и языки программирования. Если этого различия не делать, то, конечно, к РМД будут куча претензий. Например, причиной Вашей претензия в невозможности работать с иерархиями, лежит в том, что для Вас имена (отношений и атрибутов отношений) существующие в РМД неразличимы от имен языка. Поэтому Вы думаете, что ежели в РМД есть имя отношения R и имя атрибута A, то в системе , реализующей РМД, ничего глубже чем Х.Y мы изобразить не сможем (Вы заметили? R и A - это имена в смысле РМД, а X и Y - это имена в смысле системы - то есть это разные имена).
По-моему, это игра слов, шаманство. При чем тут система (реализующая РМД)? Модель есть модель. Если мы говорим, что надо все данные распределить по разным отношениям, то значит так и надо делать, и никакой иерархии тут нет. Есть отношения и есть операции. Все. А если другая модель предложит хранить данные в виде многомерного куба со своими операциями, то значит это другая модель, даже если они друг в друга могут быть отображены. Важны изначальные принципы моделирования.



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

U-gene
Мы можем описать данные в системе как угодно (ИМХО почти как угодно),
В системе да. А в модели нет, не можем. В РМД есть только отношения и операции, а понятия система в ней нет. Так что кроме отношений ничего нельзя использовать.

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

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

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

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

U-gene
Именно поэтому я и говорю вам, что Ваши предложения по описанию предметной области никак РМД не противоречат.
Я тоже не вижу противоречий. Это просто разные подходы, основанные на разных принципах с разной степенью удобности в разных применениях. Я уже упомянул, что в КоМ мы должны прежде всего упорядочить элементы данные, иначе система просто ничем не сможет помочь. КО системе не важно, есть ли там отношения, иерархии или еще что-то. Ей важно, что для каждого элемента есть родительские и дочерние элементы. Есть еще другая (двойственная) стороная этой же модели, где моделируются сами ссылки, т.е. средства для реализации связей.
27 дек 06, 20:07    [3590101]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
nerdery here
Guest
Александр Савинов
Ну а с РМД я конечно не борюсь и никогда не боролся, а просто сравниваю работу различных механизмов в разных моделях. А сомнения в том, что что-то в РМД может быть не идеально (т.е. неудобно) приводят некоторых в ярость почему-то.
....
гнаться за РМД нет смысла . это тупиковый путь. Ведь в том-то и дело, что у нее есть ряд внутренних логических дефектов, от которых можно избавиться только, если взглянуть на природу данных по-другому. Кроме того, она перегружена мелкими деталями и ненужными операциями, т.е. это прежде всего низкоуровневая модель. Вопрос же в том, чтобы создать простую и высокоуровневую модель, которая может далее отображаться во что угодно, включая РМД.

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

ИМХО, сравнение вашего КОМ'a и РМД некорректно. Они просто на разных уровнях: КоМ - инфологическое моделирование (наряду с E-R, ObjectRoleModeling etc), РМД - даталогическое моделирование (как и сетевая и иерархическая модели). Ну не будете же вы сравнивать дизайн автомобиля с физикой двигателя внутреннего сгорания?

hint: на данном форуме употребленный без уточнений термин "модель данных" воспринимается как синоним "даталогическая модель" (которая определяется через "structural, integrity and manipulation features" (q) ) :)
28 дек 06, 02:24    [3590699]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
nerdery here
Guest
2 Александр Савинов
По поводу языков: системы на основе РМД предлагают ряд оптимизирующих решений хранения и поиска данных для практических проблем (в скобках записаны методы для СОП языков):

1. использование идентичных структур в различных контекстах (проблема размножения, согласованности, необходимости совместного использования полей данных) -> выделение типов отношений (структуры, классы)
Пример - сравните вариант:
obj1_prop0=z1
obj1_prop1_prop0=y1
obj1_prop1_prop1=y2
obj1_prop1_prop2_a=x1
obj1_prop1_prop2_b=x2
obj1_prop1_prop2_abra_j=v1
obj1_prop1_prop2_abra_k=v2
против:
obj1.prop0=z1
with(obj1.prop1) {
  prop0=y1
  prop1=y2
  with(prop2) {
    a=x1
    b=x2
    with(abra) {
      j=v1
      k=v2
    }
  }
}

2. использование идентичных данных в различных контекстах (проблема дублирования) -> связи через FK (ссылки-"reference")

3. поиск по связанным данным (найти объект o типа A для которого o.x.y.z > o.x.y.t ) -> доступ к данным прямой Отношение.Атрибут, JOIN, связи по FK двунаправлены но задаются только в одном отношении, начинать поиск возможно с любого отношения или подвыражения JOIN (СОП требуют задания явных прямых/обратных ссылок, в случае их отсутствия - возможность и порядок перехода между структурами задается начальным объектом)

4. удаление неиспользуемых данных, которые имеют смысл только в определенном контексте (бесполезность) -> referential integrity - delete cascade (garbage collect - удаление недоступных данных)

5. невозможность обработать отсутствующие данные -> foreign key not null (NullPointerException)

6. необходимость пропускать некоторые поля структур (если данные неизвестны или не важны) без увеличения количества структурных типов на все возм. комбинации пропусков -> NULL, вынесение необязательных атрибутов в доп. отношения (спец. значение указателя/ссылки - null)

примечание: языки СОП - языки структурно-объектного программирования, рассматривающие объекты как структуры данных (структура = список пар имя:тип) + методы (типа ObjectPascal, C++, Java, C#)

Что предлагает для тех же проблем КОМ? :)
28 дек 06, 02:38    [3590713]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
nerdery here
игателя внутреннего сгорания?
hint: на данном форуме употребленный без уточнений термин "модель данных" воспринимается как синоним "даталогическая модель" (которая определяется через "structural, integrity and manipulation features" (q) ) :)

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

Откуда:
Сообщений: 173
nerdery here
Александр, не могли бы Вы кратко изложить разницу между инфологическими, даталогическими и физическими моделями данных?
А разницу между абстрактной и конкретной моделью?
Это можно в учебнике найти. Для меня как раз одной из целью было создание многоуровневой модели, где можно было бы моделировать разные степени детализации. В КОМ в основе физической многоуровневости лежит система ссылок. Это позволяет моделировать многоуровневую систему виртуальных пространств. Виртуализация это главный термин в этом подходе. Это позволяет во многом стереть различия между этими классами, при этом оставаясь с рамках единой модели.

nerdery here
А первые два пункта из ряда внутренних логических дефектов РМД? :)

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

1. Пресловутый механизм PK-FK. Изначально он разрабатывался как часть механизма констрейнтов. Но реальная его суть, что подтверждается использованием, в моделировании связей. Но для связей он весьма неудобен, как раз из-за изначальной цели. Получаем несоответствие (цели PK-FK их реальному применению).

2. Декартово произведение (JOIN) используется как основа для получения нужных данных. Формально никаких претензий нет. Но реально эту операцию есть смысл применять для независимых сущностей (ну как оси координат). Если же две сущности связаны ключем, то они зависимы. Конечно, таких понятий в РМД нет, а потому JOIN применяют как единственное средства для получения данных из связанных отношений. Проще говоря, основное применение JOIN в реализации связей PK-FK. Формальное все работает, но реально это совершенно неестественный подход. Получаем несоответствие (цели JOIN ее реальному применению).

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

nerdery here
ИМХО, сравнение вашего КОМ'a и РМД некорректно. Они просто на разных уровнях: КоМ - инфологическое моделирование (наряду с E-R, ObjectRoleModeling etc), РМД - даталогическое моделирование (как и сетевая и иерархическая модели). Ну не будете же вы сравнивать дизайн автомобиля с физикой двигателя внутреннего сгорания?
С этим в целом я мог бы согласиться. Однако, в КОП есть принципиальные свойства, которые не укладываются в такую классификацию. Например:

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

2. КОП имеет две стороны: логическую (структура связей) и физическую (структура уровней). Вторая сторона это как раз то, что позволяет сделать модель многоуровневой. В частности, на нижнем уровне могут быть блоки диска, а на верхнем концептуальные сущности. Важно, что это единая модель. Как тогда ее позиционировать? Как физическую или как логическую? Именно поэтому я уже отметил, что классическое разделение на физический, логический и концептуальный уровни на данный момент не очень актуально. Более актуально понятие виртуализации и многоуровневости, т.е. как раз то, на что нацелена КОП. Там просто нет этих трех уровней, а есть возможность определить свои собственные виртуальные пространства на основе уже существующих пространств.
28 дек 06, 14:58    [3593347]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
nerdery here
Что предлагает для тех же проблем КОМ? :)
Основная цель КОМ это моделирование, т.е. нам важно представить семантику данных и понимать, что наши данные означают. Языки (запросов, программирования) и расширения (API) это уже другой вопрос. В частности, я не вижу принципиальных проблем в том, чтобы все или некоторые перечисленные механизмы отобразить в КОМ, а не в РМД (п.4 это один из механизмов КОМ, поскольку он основан на семантике данных). Вопросы программирования на самом деле отделены от моделирования и рассматриваются в рамках концептно-ориентированного программирования (КОП). Впрочем, КОМ и КОП это две стороны одного и того же.
28 дек 06, 15:15    [3593474]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Александр Савинов
Вот пару примеров.
1. Пресловутый механизм PK-FK. Изначально он разрабатывался как часть механизма констрейнтов. Но реальная его суть, что подтверждается использованием, в моделировании связей. Но для связей он весьма неудобен, как раз из-за изначальной цели. Получаем несоответствие (цели PK-FK их реальному применению).
Откуда вы знаете, удобен механизм PK-FK или нет, если обсуждение в предыдущей теме показало, что у вас практически нет опыта работы с РСУБД? Получается, это голая декларация. Этого маловато.
Александр Савинов
2. Декартово произведение (JOIN) используется как основа для получения нужных данных. Формально никаких претензий нет. Но реально эту операцию есть смысл применять для независимых сущностей (ну как оси координат). Если же две сущности связаны ключем, то они зависимы. Конечно, таких понятий в РМД нет, а потому JOIN применяют как единственное средства для получения данных из связанных отношений. Проще говоря, основное применение JOIN в реализации связей PK-FK. Формальное все работает, но реально это совершенно неестественный подход. Получаем несоответствие (цели JOIN ее реальному применению).
Первое, JOIN — это не декартово произведение. Это к вопросу о вашей компетентности в обсуждаемом вопросе. Второе. Чем докажете, что реально эту операцию есть смысл применять для независимых сущностей? Утверждение выглядит полным абсурдом, поскольку предлагает соединять принципиально несвязанные факты. Тогда как операция по смыслу как раз призвана делать логический вывод из подмножеств связанных фактов. И «совершенно неестественный подход» просматривается пока как раз у вас.

Александр Савинов
Проблема в том, что этому подходу уже больше 30 лет, а за это время в мире данных уже все поменялось, а потому вполне естественно, что многие идеи и механизмы модели выглядят архаично и неестественно (что не мешает им правильно функционировать).
В разговоре технарей апелляция к «возрасту» выглядит довольно смехотворно, это же не биология. Ведь за 30 лет математика не поменялась, логика не поменялась. Собственно, если вместо аргументов апеллируют в «возрасту», это говорит только об отсутствии более сильных аргументов.
Александр Савинов
1. Наличие формальной семантики (нет в РМД из-за слишком низкого уровня и нет в концептуальных моделях типа E-R из-за слишком высокого уровня). А ведь этот вопрос является одним из самых главных, поскольку при моделировании я хочу видеть данные как глобальную конструкцию.
Если бы вы почитали труды по ИИ, то поняли бы, что формализация семантики есть вековая мечта создателей ИИ, но мечта несбыточная. Семантика (смысл) рождается в мозгу человека, а как он мыслит, никто не знает. Компьютер не умеет работать с информацией, только с данными (кто понимает строгую разницу). И если некто говорит, что он походя поддерживает формальную семантику, то он либо обманывает себя, либо других, либо понимает под семантикой что-то совсем иное.
P.S. Только не надо выдавать за семантику метаданные, умоляю, это даже не интересно.
28 дек 06, 16:34    [3594083]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
Александр Савинов
Боюсь опять ..
и правильно
Александр Савинов
1. Пресловутый механизм PK-FK. Изначально он разрабатывался как часть механизма констрейнтов. Но реальная его суть, что подтверждается использованием, в моделировании связей.
Откуда? Чтобы далеко не ходить, гляньте хоть на соседние форумы по ОРАКЛ и МС Сиквел. Неужели там (в части запросов) одни эквиджойны по ключам народ волнуют? Реальная суть именно в предотвращении разрушения данных при DML операциях.
Александр Савинов
2. Декартово произведение (JOIN) используется как основа для получения нужных данных. Формально никаких претензий нет. Но реально эту операцию есть смысл применять для независимых сущностей (ну как оси координат). Если же две сущности связаны ключем, то они зависимы. Конечно, таких понятий в РМД нет, а потому JOIN применяют как единственное средства для получения данных из связанных отношений. Проще говоря, основное применение JOIN в реализации связей PK-FK. Формальное все работает, но реально это совершенно неестественный подход. Получаем несоответствие (цели JOIN ее реальному применению).
Во первых далеко не единственное, а во вторых работает все как раз не так - там же смотреть планы запросов.
Александр Савинов
Я еще раз хочу отметить, что это вовсе не претензии к РМД, которая внутренне вполне логична. Проблема в том, что этому подходу уже больше 30 лет, а за это время в мире данных уже все поменялось, а потому вполне естественно, что многие идеи и механизмы модели выглядят архаично и неестественно (что не мешает им правильно функционировать).
Вы будете смеятся, но 30-40 лет назад доминировали как раз системы основанные на ссылках. Что было признано архаичным и неестественным.

РМД несомненно имеет границы применимости, а подход на основе модели памяти конечно полезен, как правильно сказано, там где гибкость РМД - слишком большая плата за возможность просто сохранить и достать данные. Где ссылки - это основной и почти единственный способ доступа. Скажем графический объект содержит подъобъекты, которые вне контекста объекта никому не интересны.
Но границы применимости РМД ИМХО оисаны неверно.
28 дек 06, 16:51    [3594185]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
ModelR
Вы будете смеятся, но 30-40 лет назад доминировали как раз системы основанные на ссылках. Что было признано архаичным и неестественным.

Вы будете смеятся, но все хорошо спроектированные системы на РСУБД моделируют ссылки, утраченные в реультате реляционной революции - ну и за что боролись ?
28 дек 06, 17:07    [3594291]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
shuklin
Member

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


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


"Свобода" в РМД ? Ха, какая это свобода? Нет там никакой свободы. И это ее основная проблема. Сеть моделирует РМД без метаперехода, а РМД моделирует сеть с метапереходом. => в сетевой модели и возможностей и свободы больше чем в РМД.
28 дек 06, 17:24    [3594396]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
Александр Савинов
Member

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

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

А вот более высокоуровневая модель это всегда ограничения и дисциплина (либо прописанная на бумаге, либо реализованная в системе).

shuklin
Сеть моделирует РМД без метаперехода, а РМД моделирует сеть с метапереходом.
А что такое метапереход?

shuklin
=> в сетевой модели и возможностей и свободы больше чем в РМД.
Это не свобода. Это простота при описании сложных моделей. Так в ООП свободы меньше, но зато он проще по сравнению с машинными кодами. Как, например, в сетевой модели просуммировать значения всех ссылок на А, а потом найти объект, ссылающийся на Б с помощью ссылки, равной этой сумме? Наверное нельзя. А в РМД можно! Зачем такие задачи нужны никто не знает, но в РМД это все-равно можно сделать. Но главная проблема не в том, что это можно, а то, что такая задача ничем не отличается по виду от вполне осмысленных операций, поскольку это просто операции с данными без всякого смысла. Низкий уровень - ничего не поделаешь.
28 дек 06, 18:06    [3594586]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
Александр Савинов
Например, есть в двух отношениях две целочисленные колонки. Что это?


Это уже очень серьезное ограничение. Оно не позволяет денотативно "искажать" отдельные кортежи.

Александр Савинов
То же самое в ассемблере. Есть 32-битное число. Что это: адрес или счетчик или биты? Это знает только программист, кто и отвечает за правильность кода.


Совмещение данных и кода - гениальная идея фон Неймана, позволяющая Машине Тьюринга быть самоприменимой. Без таких вещей прощай вычислительная полнота.

Александр Савинов
А что такое метапереход?


Смотрите Турчина, это его идея.

Александр Савинов
Как, например, в сетевой модели просуммировать значения всех ссылок на А, а потом найти объект, ссылающийся на Б с помощью ссылки, равной этой сумме? Наверное нельзя.
В Cerebrum можно с некоторыми оговорками, но действительно не поощряется, за отсутствием прагматики.
28 дек 06, 18:58    [3594732]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Александр Савинов

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

Не знаю, что Вы понимаете под под формальной семантикой (семантика как бы традиционно противовоставляется формальному), но просто семантики в E-R достаточно, чтобы увидеть лес из-за даревьев в общем случае.

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

2. КОП имеет две стороны: логическую (структура связей) и физическую (структура уровней). Вторая сторона это как раз то, что позволяет сделать модель многоуровневой. В частности, на нижнем уровне могут быть блоки диска, а на верхнем концептуальные сущности. Важно, что это единая модель. Как тогда ее позиционировать? Как физическую или как логическую? Именно поэтому я уже отметил, что классическое разделение на физический, логический и концептуальный уровни на данный момент не очень актуально. Более актуально понятие виртуализации и многоуровневости, т.е. как раз то, на что нацелена КОП. Там просто нет этих трех уровней, а есть возможность определить свои собственные виртуальные пространства на основе уже существующих пространств.

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

Откуда: Нижний Новгород
Сообщений: 1798
мод
ModelR
Вы будете смеятся, но 30-40 лет назад доминировали как раз системы основанные на ссылках. Что было признано архаичным и неестественным.

Вы будете смеятся, но все хорошо спроектированные системы на РСУБД моделируют ссылки, утраченные в реультате реляционной революции - ну и за что боролись ?
Ну это ведь не единственное, что они (хорошо спроектированные системы) используют из SQL? А боролись именно за свободу.
В принципе вопрос о развитии SQL - должен ли он оставться чисто реляционным или должен охватывать и другие модели. ИМХО практически вендоры для себя вопрос уже решили - все идет к универсальному языку данных.
29 дек 06, 11:05    [3596622]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
ModelR
В принципе вопрос о развитии SQL - должен ли он оставться чисто реляционным или должен охватывать и другие модели. ИМХО практически вендоры для себя вопрос уже решили - все идет к универсальному языку данных.

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

Откуда:
Сообщений: 349
Чтобы этот язык был универсальным, необходимо чтобы он работал, кроме реляционных с объектными, иерархическими и прочими данными. Все, что нужно: система, кроме SQL, должна понимать в частности языковые конструкции из XPath и ОО языков.
Например:
select * from X/Y[Z=’1’].m()
Переводится: Отобразить все атрибуты * объектов полученных в результате выполнения метода m() над объектами Y, принадлежащих X и имеющих Z=’1’

В конструкции FROM мы не обязаны указывать имена отношений. Да и нужны ли они вообще? Для примера, в Zigzag имена отношений отсутствуют, в том виде в каком это понимает РМД (имена таблиц). Эти таблицы генерятся. Фактически БД Зигзаг, это классы связанных между собой объектов. То есть данные уже хранятся, как результат того самого NATURAL JOIN, о котором говорил mir.
P.S.
Александр: на последний респонс от mir ответить действительно нечем. Не спеши. Подумай. Все таки у точечной нотации есть плюсы. Чем то она напоминает конструкции из XPath ///
С НАСТУПАЮЩИМ НОВЫМ ГОДОМ!
29 дек 06, 14:11    [3598055]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
Ага, и еще
select *, *.*, *.*.*
- все включая ссылки 1 и 2 го уровня

Но конечно, лучше 5 звездочек.:)

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

Откуда: Москва. Россия
Сообщений: 1576
okdoky
...имена отношений отсутствуют, в том виде в каком это понимает РМД (имена таблиц)...
....Рыдаю молча испатстала....Объяснять ничего не буду.
29 дек 06, 15:13    [3598333]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
okdoky
То есть данные уже хранятся, как результат того самого NATURAL JOIN, о котором говорил mir.


В оракляном кластере данные именно так и хранятся

Идите действительно что-ли квасить, нафига вам вперлось это бодание с распахнутой дверью ?

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

Откуда: Томск
Сообщений: 1027
okdoky
В конструкции FROM мы не обязаны указывать имена отношений. Да и нужны ли они вообще?
Имена переменных отношений -- нужны. Сам FROM -- не нужен. В том смысле, что
конкретный синтаксис SQL не самый удачный вариант реализации РМД. Лично мне синтаксис Tutoral D представляется существенно более логичным и строгим.
P.S. Только не надо приводить в пример Zigzag, это мы уже обсуждали.
29 дек 06, 16:24    [3598531]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
ModelR
В принципе вопрос о развитии SQL - должен ли он оставться чисто реляционным или должен охватывать и другие модели. ИМХО практически вендоры для себя вопрос уже решили - все идет к универсальному языку данных.
Хотелось бы напомнить, что в оригинале (у Кодда) речь идет о реляционном подязыке данных, то есть изначально подразумевалось, что в реляционной системе может быть любой (какой угодно) язык, но его часть, отвечающая за операции с РБД, должна удовлетворять определенным требованиям (см. 12 правил Кодда). Поэтому в идее расширения и универсализации языка реляционной системы баз данных нет ничего сколько-нибудь нового и противоречащего исходной идее. По которой, напомню, чисто реляционным должен быть именно не обязательно весь язык, а именно подязык данных.
29 дек 06, 16:32    [3598563]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
okdoky
Member

Откуда:
Сообщений: 349
mir
Имена переменных отношений -- нужны.
Ну, это просто ваши привычки. В РМД данные, это отношения между объектами. В ОМД, это объекты связанные между собой отношениями, что в принципе одно и тоже. Во втором случае структура данных может оказаться более гибкой и вместо переменных отношений достаточно использовать переменные объектов.
mir
Лично мне синтаксис Tutoral D представляется существенно более логичным и строгим.
P.S. Только не надо приводить в пример Zigzag, это мы уже обсуждали.
Как будет выглядеть на Tutorial D тот запрос, который я привел?
select * from X/Y[Z=’1’].m()
Обращение к методу можете оставить тем же, так как у Tutorial D это не формализуется. Кстати, выражение X/Y[Z=’1’], это из языка XPath. На Zigzag будет по-другому X.Y(Z:’1’).
29 дек 06, 16:50    [3598631]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
okdoky
Чтобы этот язык был универсальным, необходимо чтобы он работал, кроме реляционных с объектными, иерархическими и прочими данными. Все, что нужно: система, кроме SQL, должна понимать в частности языковые конструкции из XPath и ОО языков.
Например:
select * from X/Y[Z=’1’].m()
Переводится: Отобразить все атрибуты * объектов полученных в результате выполнения метода m() над объектами Y, принадлежащих X и имеющих Z=’1’

Хороший пример. Для демонстрации того, как не надо делать. Он развивает худшие традиции SQL, поскольку в одной строке фактически смешаны четыре важные конструкции запроса:
1. Описание исходного пространства: X
2. Выборка нужных элементов: Y из X
3. Выполнение действий над объектами исходного пространства: метод m()
4. Описание возвращаемых компонент: *

Вот как бы я это записал:
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 ); 
} 

Здесь ясно, что обрабатываются элементы исходного двумерного пространства X x Z. Но выбираются только те, что удовлетворяют двум свойствам. Далее для каждого из них вычисляются целое значение и коллекция. Потом возвращается коллекция целых чисел. Важно, что все шаги отделены и нет никакой криптографии.

Но здесь кроме криптографии видно другое, о чем уже говорилось. В SQL (что идет от РМД) в FROM указываются все таблицы, которые участвуют в запросе без разбора их роли. В описанном выше подходе указываются только исходные независимые таблицы (любые коллекции). А те таблицы, которые привязываются по свойствам совершенно в FROM/FORALL не нужны - они появляются только в теле запроса (например, Table3 и Table10). Это один из тех пресловутых "дефектов" или недостатках, о которых я тут пытаюсь говорить. У каждой таблицы в запросе есть роль, которую надо отобразить в структуре запроса. А в SQL этого нет, поскольку РМД не делает различий между ролью независимых и привязанных таблиц. В результате для сложных запросов FROM может содержать десятки таблиц, которые по смыслу там совершенно лишние. В последнем примере запроса на SQL включал бы все 4 таблицы во FROM, тогда как по смыслу надо только 2, а остальные 2 нужны только для нахождения каких-то свойств. Подход SQL более прямолинеен и более дубовый, а на практике приводит к серьезным трудностям для обычного рядового или даже сержанта на SQL-фронте.

okdoky
В конструкции FROM мы не обязаны указывать имена отношений. Да и нужны ли они вообще? Для примера, в Zigzag имена отношений отсутствуют, в том виде в каком это понимает РМД (имена таблиц). Эти таблицы генерятся. Фактически БД Зигзаг, это классы связанных между собой объектов. То есть данные уже хранятся, как результат того самого NATURAL JOIN, о котором говорил mir.


Во FROM/FORALL должны храниться ссылки на исходные коллекции, будь то статические таблицы, локальные (промежуточные) коллекции или просто коллекция значений, указанная в строке. А имя переменой рядом со ссылкой на коллекцию дает в теле запроса ссылку на очередной элемент в исходном пространстве.

okdoky
P.S.
Александр: на последний респонс от mir ответить действительно нечем. Не спеши. Подумай. Все таки у точечной нотации есть плюсы. Чем то она напоминает конструкции из XPath ///
Я вообще не нашел на что там отвечать. Там нет вопросов, а есть просто очередной набор обвинений. Это человек-НЕ, спорить с ним невозможно, поскольку там нет мнения и нет аргументов, а есть отрицания в стиле "это не так, потому что вы некомпетентны".
29 дек 06, 16:54    [3598649]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
okdoky
Ну, это просто ваши привычки. В РМД данные, это отношения между объектами. В ОМД, это объекты связанные между собой отношениями, что в принципе одно и тоже. Во втором случае структура данных может оказаться более гибкой и вместо переменных отношений достаточно использовать переменные объектов.
Вы сначала разберитесь, говорите вы о РМД или об ОМД (если такая вещь вообще есть). А то у вас каша какая-то. При чем здесь ОМД?
Далее, работа с БД обычно ведется сразу с множествами взаимосвязанных "объектов" (в РМД -- фактов), при этом идти от одного "объекта" к другим "объектам" -- задача столь частная, что не заслуживает особого внимания.
okdoky
Как будет выглядеть на Tutorial D тот запрос, который я привел?
select * from X/Y[Z=’1’].m()
Обращение к методу можете оставить тем же, так как у Tutorial D это не формализуется.
Примерно так:
M( Y SEMIJOIN X ) WHERE Z='1'
Кстати, никаких FROM и SELECT там нет. Прямая запись реляционных выражений.
29 дек 06, 17:32    [3598787]     Ответить | Цитировать Сообщить модератору
 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

Откуда: Новосибирск
Сообщений: 2408
Блог
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]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
U-gene
Member

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

В общем в сухом остатке от Вас остается
1) Непонимание понятия модели данных. В качестве определниий предлагалось несколько формулировок, начиная от "всё, что поможет описать данные" до "воблы на веревочках"
2) Постояннаяя путаница межу инфологическими и даталогическими моделями.
3) Постоянная путаница между даталогическими моделями и системами, реализующими эти модели
4) Постоянная путаница меду записью формальных операций моделей данных и конструкциями используемого языка программирования.
5)Незнание предмета критики (РМД), о чём свидетельствуют
а)навязчивые попытки навязать РМД(модели даталогической) роль инфологической модели
б) незнание базовых операций - попытка обозвать выборку проекцией, попытка смешать соединение и декартово произведение.
в)попытки связать JOINы с ключевыми полями
г)попытка разделить ключи РМД на суррогатные ( это которые "привинченные к РМД сбоку", "нетипизированные", имеющие "сильную поддержку со стороны системы") и несуррогатные("толстые")
д) непонимание роли доменов в РМД
е) и, в конце концов, "РМД - это не отношение!"

При этом Вы постоянно пытаетесь обвинить оппнентов в религиозноcти, ограниченности, придумывании пакостей, пытяетесь представить людей, всего лишь понимающих РМД (и Ваше незнание её), как секту, сслыетесь на фирмы, Ленина, воблу, пользователей, пространства, смысл и т.п. странные вещи.

Из недавних ляпов
Александр Савинов
...семантика определяется собственными свойствами, например, значениями кортежа отношения. При изменении свойства изменяется смысл элемента данных
Верно ли я понимаю, что если "свойство" - это "например значение кортежа", то при изменении значения кортежа его семантика изменится? Мне интересно, что Вы ляпнете теперь. В качестве безпроигрышного варианта предлагаю объявить меня злобным четырежды религиозным фанатиком, получившим секретную шифрограмму Дейта.

Друг мой. я честно попыталя прочесть Ваше"Formal Introduction into the Concept-Oriented Data Model".... но буквально сразу же я наткнулся на фразу

A two-level concept-oriented model consists of one root element R which physically includes a set of concept elements ... where each concept physically includes a set of item elements ... .(я убрал определние множеств). Друг мой объясните мне , что в Formal Introduction ... делает слово physically? Далее это physically(не иначе как веревочками от воблы) преследовало меня везде и далее... Physical inclusion is supposed to be persistent and cannot be changed during life cycle of elements. Друг мой, what is physical inclusion supported with? Системой что ли? Это что у Вас, такое вот Formal Introduction of модели и системы? и где же тут операции то? Что Вы даете взамен РМД?

И еще я посмотрел Frequently Asked Questions on the Concept-Oriented Data Model
Перлы, котрые сразу же бросаются в глаза
1) Any model has a physical structure which is defined by physical inclusions of its elements into collections. Это что у Вас что, мантра для внушабельных индиотов - типа если по аглицки и с умным видом, то значит так оно и есть и это истина? Друг мой, "но я же не индиот" (с) С.Лем
2)Concept is an analog of table or relation in the relational data model and class in the object-oriented paradigm. Друг мой, по вашему "отношение",это нечто, что является эквивалентом "класса"? Вперед!
3) In the relational model it is analogous to cascade delete operation. Друг мой, Вы так много интересных вещей находите в РМД!
4) What happens if the reference count gets too low? В это о чём? Это тоже Data Model?
5) The system looks after the usage of items by counting how many each item is referenced from its subitems. (The bottom concept is not taken into account since it is a formal element of the model.) Что, и это тоже?

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

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

В любом случае Вам и всем - С Новым Годом :) Удачи :)
31 дек 06, 01:22    [3600941]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
okdoky
Member

Откуда:
Сообщений: 349
mir:
Взглянул на свой предыдущий пост и не удержался, решил исправиться. Для понимания точность нужна не только в терминологии.
okdoky
Надеюсь вы знаете 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.
R2(Y, Z, B)
   y, 1, b
   y1,2, b

Это не совсем то, что я просил изобразить для X/Y из языка XPath. Вы действительно оперируете множествами отношений. В иерархических моделях реализованных на 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 равным y y1. Для реляционной модели это значения атрибута Y в таблице R1.

Настоятельно рекомендую изучить за праздники XPath (и XQuery). Собственно, на месте X и Y в выражении X/Y могут находиться переменные, представляющие множества объектов (значений) сразу из нескольких атрибутов, то есть объединения UNION. Получить все атрибуты Y можно используя что то типа
[FIXED]select * from X/Y [/FIXED]
или
[FIXED]for $y in X/Y
return $y/*[/FIXED]
Хоть я и не дождался от вас выражения на Tutorial D, согласитесь, это значительно проще, чем в РМ. Можно обойтись без операций JOIN, а значит и самой РМД. При выдаче полной информации об Y Вам не придется вспоминать все нормализованные таблицы (отношения) в которых находятся объекты y, y1. Ведь они могут находится не только в R1. Не правда ли?
31 дек 06, 09:58    [3601041]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
4321ё
Guest
Пьяный Лох
А может забанить дурака, а?
зачем же.
надо же наконетц пыньять, чито двигало например лысенкой. А тут такой заметчательный экземпляр для изучения.
Чистосердечный и фанатичный.


Не в обиду.
С НГ.
4321 (уже вами бизпащадна расклассифицированный, т.ч. - без обид - встречная классифи-какция, всего лишь)



я вот думаю, шо могу проздреть унутреннюю единздвенно-верноздь учения. А ходь бы и учения АликСавинова. У миня с эттим лихко. Я даже кличу это сематической инвариантостью (теорий ли, моделей ли - не суть важно). Проблема лишь в том, шо я могу прозреть внудреннюю верноздь множества учений. Видимо в отличь от АдекСавинова. А уж исходя из этой точки мне интерездно, что же на самом деле может мне дасть модель, кроме деклакакции своей единтсвенна-верности. А вот с энтим, мне кааца, у АСавинова пока туго. Кликните, как сыщете какой-нито явный бонус
31 дек 06, 21:41    [3601570]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
okdoky
Member

Откуда:
Сообщений: 349
okdoky
Хоть я и не дождался от вас выражения на Tutorial D, согласитесь, это значительно проще, чем в РМ. Можно обойтись без операций JOIN, а значит и самой РМД. При выдаче полной информации об Y Вам не придется вспоминать все нормализованные таблицы (отношения) в которых находятся объекты y, y1. Ведь они могут находится не только в R1.
Это было сказано в прядке легкого предновогоднего флейма, с целью отвлечь нездоровое внимание от Александра Савинова и его концептно-ориентированной модели. Ту задачу, которую я предлагал, можно решить в рамках РМД. Для этого достаточно использовать имена отношений, совпадающие или схожие с именами атрибутов X, Y, то есть X(IDX, Y, A), Y(IDY, Z, B). Запрос соответствующий
select * from X/Y 
на SQL будет выглядеть
select * from Y where IDY in (select Y from X)
Пока все просто. Сложнее с SQL или Tutorial D будет для более сложных запросов, которые в XPath например могут выглядеть так X/Y/Z[M/N/K>='k'] или X//*[Z=1]. В последнем случае осуществляется переход ко всем атрибутам, как-либо косвенно связанным с X (не только непосредственно, как Y). Мы не обязаны помнить не только имена отношений, но и имена атрибутов.

Собственно изначально-то речь шла об утверждении
mir
Имена переменных отношений -- нужны.
, по сути об единственности и неповторимости РМД. Уже существуют модели данных не менее строго формализованные, чем РМД. Думаю будет интересно, особенно mir, U-gene, ModelR посмотреть на следующую альтернативу. Здесь также используются переменные, но не отношений…
4 янв 07, 13:07    [3606653]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
okdoky
Собственно изначально-то речь шла об утверждении mir
mir
Имена переменных отношений -- нужны.

, по сути об единственности и неповторимости РМД.

?????

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

Не понятно? Тогда пример - okdoky только что написал...
okdoky
Для этого достаточно использовать имена отношений
...и, по сути, сказал, что РМД является достаточной.

okdoky
Уже существуют модели данных не менее строго формализованные, чем РМД…
... Почитал. Написано по англицки и с умным видом . :) Во всяком случае люди ни с чем не борются и какашками бросаться не пытаются. Нашел проекцию и итераторы. Позабавил аппендикс XML Query Data Model содержащий единственную ссылку...... на себя. :) Нельзя не согласится с содержащейся в конце его примечанием редактора: This section needs to be completed.
4 янв 07, 15:40    [3607081]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Александр Савинов
Ликующий народ (хлеба и зрелищ): Gluk (Kazan), 7


Народ безмолствует

P.S. Я буду молчаливой галюцинацией (с)
6 янв 07, 08:28    [3610480]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
mir
Для типовых задач БД пока лучше РМД ничего не предложили. Вот и все.

Предложили. Или по вашему оракл это только РМД ?
9 янв 07, 11:19    [3615162]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
okdoky
Member

Откуда:
Сообщений: 349
U-gene
РМД является достаточной.
Достаточность, это слабый аргумент. Кто-то, кажется из дискутирующих, заметил, что Ассемблер тоже достаточен.
U-gene
Позабавил аппендикс XML Query Data Model содержащий единственную ссылку...... на себя. :)
Из моего примера можно понять суть XML-модели данных на основе РМД. Есть такая простенькая ссылка http://www.w3.org/XML/Datamodel.html Здесь интересен пример, как на основе иерархической структуры можно представить сеть, используя атрибут href
<p>
<q id="x7">The first q</q>
<q id="x8">The second q</q>
<q href="#x7">The third q</q>
</p>
9 янв 07, 13:58    [3616277]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
okdoky
Есть такая простенькая ссылка
Точнее будет http://www.w3.org/TR/xpath-datamodel/, но увы, уже не такая простенькая.
9 янв 07, 14:43    [3616646]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Все таки интересно, чем люди читают (или думают?). Берем пару слов из контекста и понимаем их как хотим. Например
U-gene написал
Не понятно? Тогда пример - okdoky только что написал... "Для этого достаточно использовать имена отношений" ...и, по сути, сказал, что РМД является достаточной.
okdoky ответил
U-gene
РМД является достаточной.

Достаточность, это слабый аргумент.
Друг мой это был не аргумент, а всего лишь демонстрация Ваших грандиозных способностей понимать оппонентов и строить причинно-следственные связи. Ваш новый ответ все эти ваши спосообности в очередной раз продемонстрировал. Или вот

okdoky раньше написал
Уже существуют модели данных не менее строго формализованные, чем РМД. Думаю будет интересно, особенно mir, U-gene, ModelR посмотреть на следующую альтернативу

okdoky пишет теперь
Из моего примера можно понять суть XML-модели данных на основе РМД.
Друг мой, а Вы не находите (ну так, на минутку) что между "альтернатива" и "на основе" есть некая разница, заключающаяся в том, что первое подразумевает отказ, а второе - использование. То есть Вы сами сначала определитесь, чего же вы собсно доказывать хотите, а потом планомерно об этом пишит. И на всякий случАй хочу повторить - я не считаю, что РМД является едиственно возможной модлью данных.
9 янв 07, 16:15    [3617257]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
okdoky
Member

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

Не буду спорить (пока) с аргументом, что РМД достаточна. Тем более, что он скорее мой, чем ваш (по вашему же предыдущему посланию). Хочу только добавить. Все, что вы изобразите в реляционном виде легко можно представить в XML. А вот обратное может оказаться значительно сложнее. Думаю вам придется покряхтеть даже над таким простым примером:
<операция>
  <елемент id="1">2</елемент>
  <елемент id="2">2</елемент>
  <елемент id="3">2</елемент>
  <сложить>
    <умножить><елемент href="#1"/><елемент href="#2"></умножить>
    <умножить><елемент href="#2"/><елемент href="#3"></умножить>
  </сложить>
</операция>
9 янв 07, 17:51    [3617943]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
Ага, легко заходит но туго выходит.
Сравните SQL и XQuery.
Чтобы определить XQuery (все еще Proposed Recommendation ), сначала приходится определить вышеупомянутую модель данных для XML, затем XPath, не забыть еще XML Schema...

А в принципе отображение непосредственно диктуется той же спецификацией http://www.w3.org/TR/xpath-datamodel/, описывющей конечное число сущностей, каждая с конечным числом атрибутов, каждый из которых есть либо элементарный тип либо список сущностей. Но в чем смысл этого упражнения?
9 янв 07, 19:03    [3618250]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
U-gene
Member

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

Ну изобразили Вы эту штуку
<операция>
<елемент id="1">2</елемент>
<елемент id="2">2</елемент>
<елемент id="3">2</елемент>
<сложить>
<умножить><елемент href="#1"/><елемент href="#2"></умножить>
<умножить><елемент href="#2"/><елемент href="#3"></умножить>
</сложить>
</операция>
Что Вы с ней дальше то делать будете? Какие Вы к ней операции примените? Зачем Вам так нужно изображать банальное выражение? Смысл этого?

Опять же - примерчик то неудачный:) Есть три переменные и мы делаем id1*id2+id2*id3? Так это скаляры - к РМД это вообще никакого отношения не имеет :). А если Вам нужно как это будет выглядет в системе, реализующей РМД....то скорее всего так, как я написал. Но опять же - эта возможность системы не имеет никакго отношения к (т.е ортгональна) РМД и чем больше таких ортогональных возможностей будет, тем лучше будет нам.

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

Простой пример. Существует арифметическая операция сложения х+у . Я ее записал, как она отображается в математике. Но это же не значит, что в языке, реализующем математику я буду пользоваться только простыми целочисленными переменными и что в языке я смогу использовать опреацию сложения только в виде а+b (где a и b простые целочисленные переменные). Я же могу написать object1.ref.a + object2.method_b() и это никоим образом не нарушит арифметику. Почему? Да потому что все эти ссылки, методы, иерархии и т.п. вещи - все это конструкции языка системы, которые ортогональны арифметике. Ведь когда Страуструп создавал С++ , он же не писал, что де арифметика какая то не такая! Ведь для С++ никто не выдумывал каких то новых операций вместо сложения, умножения и т.п.! Потому что object1.ref.a и object2.method_b() это в конечном итоге всего лишь имена переменных, содержащих значения, а как система с этими именами разбирается, что она вытворяет, что бы доступ к этим значениям получить - это её личное дело, которое к арифметике никакого отношения не имеет.

То же самое и РМД. Если в ней мы манипулируем с отношением R имеющим атрибут a, то это восе не значит, что в системы должны существовать только таблицеподобные переменные с колоночками :). Это примитивный подход - типа как первые языки программирования. Язык системы, реализующей РМД, может описывать сложные струкутры использовать ссылки, изобажать иерархии и сети. Это значит, что если описано например дерево вида

               c-d
/
корень a-b-e-f-g
\
h


то система должна выполнить сдедующий запрос

SELECT c.d, SUM(e.f.g)
FROM a.b
WHERE h...

именно потому, что она реализует РМД и рассматривает ссылочную(с точки зрения пользователя) конструкцию "a.b" как имя отношения, а ссылочные (с той же точки зрения) конcтрукции "с.d", "e.f.g", "h" как имена атрибутов этого отношения. Как она с этими конструкциями будет разбираться, как она будет эти отношения сторить - это ее личное дело, которое к РМД никакого отношения не имеет. Всё это ортогонально РМД.
9 янв 07, 21:33    [3618589]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
U-gene
О том то и речь, что для того, что бы иметь в системе сложные структуры (иерархии, сети), что бы пользовать в системе ссылки никакие модели данных вообще не нужны. Всё это ортгонально РМД. То есть Вы можете изображать модель предметной области используя подходящие языковые конструкции системы, а для доступа к данным Вы можете продлжать пользоваться РМД.

Действительно, с помощью РМД можно смоделировать любые сложные структуры. Но это означает, что обработка этих структур перекладывается на приложение, а цель в том, чтобы этим занималась СУБД, а это в свою очередь означает, что СУБД должна поддерживать сложные структуры и ортогональность не катит.
10 янв 07, 10:14    [3619519]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Для тех, кто в танке - переписал последние предложения

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


c-d
/
корень a-b-e-f-g
\
h

то СУБД должна выполнить (например) сдедующий запрос

SELECT c.d, SUM(e.f.g)
FROM a.b
WHERE h...

именно потому, что она (эта СУБД) реализует РМД и рассматривает ссылочную(с точки зрения пользователя) конструкцию "a.b" как имя отношения, а ссылочные (с той же точки зрения) конcтрукции "с.d", "e.f.g", "h" как имена атрибутов этого отношения. Как она (СУБД) с этими конструкциями будет разбираться, как она будет эти отношения строить - это ее личное дело, которое к РМД никакого отношения не имеет. Всё это ортогонально РМД.
10 янв 07, 11:27    [3620027]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
U-gene
она (эта СУБД) реализует РМД

РМД как и любая другая МД нужна пользователю, а не СУБД. Если пользователь описывает иерархию, то для него существует иерархическая МД и никакая другая и он хочет чтобы СУБД поддерживала именно эту МД.
10 янв 07, 12:59    [3620772]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
мод
....МД нужна пользователю, а не СУБД...
"Вид чудовищного коричневого сейфа, мрачно возвышавшегося в углу позади коменданта, поверг его в первую панику, а когда он поднял глаза и обнаружил на стене необъятный кумачовый лозунг "Народу не нужны нездоровые сенсации. Народу нужны здоровые сенсации", лицо его так переменилось, что я понял: Эдик готов." (с) А. и Б. Стругацкие "Сказка о Тройке"

Вы, очевидно, ездиете на формуле горения и питаетесь циклом Кребса. Я же предпочитаю машины и колбасу В общем, не знаю, что Вам нужно, но мне, как пользователю, нужна именно система постоянного хранения данных, где я могу описывать эти данные как мне удобно и оперировать ими понятным мне образом.
10 янв 07, 13:57    [3621283]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
okdoky
Member

Откуда:
Сообщений: 349
ModelR
Ага, легко заходит но туго выходит.
Сравните SQL и XQuery.
Чтобы определить XQuery (все еще Proposed Recommendation ), сначала приходится определить вышеупомянутую модель данных для XML, затем XPath, не забыть еще XML Schema...

А в принципе отображение непосредственно диктуется той же спецификацией http://www.w3.org/TR/xpath-datamodel/, описывющей конечное число сущностей, каждая с конечным числом атрибутов, каждый из которых есть либо элементарный тип либо список сущностей. Но в чем смысл этого упражнения?
Зачем так загонять себя. Чтобы понять особенности XML-данных достаточно той простой ссылки, которую я привел. Если вдаваться в тонкости XPath. Модель данных, которой он может оперировать, во многом зависит от реализации. Можно подключить даже РМ. Но тогда, как я уже демонстрировал ранее, потребуется совпадение имен отношений атрибутам других (внешних) отношений. Либо предварительно использовать NATURAL JOIN всех отношений включающих атрибуты перечисленные в XPath.
10 янв 07, 14:04    [3621345]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
okdoky
Member

Откуда:
Сообщений: 349
U-gene
...То же самое и РМД. Если в ней мы манипулируем с отношением R имеющим атрибут a, то это вовсе не значит, что в реализующей её СУБД должны существовать только таблицеподобные переменные с колоночками :)…. Как она (СУБД) с этими конструкциями будет разбираться, как она будет эти отношения строить - это ее личное дело, которое к РМД никакого отношения не имеет. Всё это ортогонально РМД.
Вам mod правильно заметил, СУБД (ее физический уровень) должна соответствовать модели данных (логическому уровню) для которой она предназначена. Почему? Подумайте сами. Поэтому и приходится делить СУБД на реляционные, иерархические (XML, MUMPS) и т.п. Или вы говорите о какой-то абстрактной объектно-реляционно-иерархической СУБД? Которая позволяет оперировать ортогональными РМД моделями . Почему-же они обязательно должны быть ортогональными? Вспомните для примера ОРСУБД...
10 янв 07, 14:20    [3621461]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
U-gene
мне, как пользователю, нужна именно система постоянного хранения данных, где я могу описывать эти данные как мне удобно и оперировать ими понятным мне образом.

Ага, это называется DDL и DML. Опишите плиз ваш пример понятным вам образом.
10 янв 07, 15:00    [3621780]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
мод
Опишите плиз ваш пример понятным вам образом.
Уже два года как. Там и пример есть и как оно работает.

okdoky
Или вы говорите о какой-то абстрактной объектно-реляционно-иерархической СУБД? Которая позволяет оперировать ортогональными РМД моделями.

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

И почему абстрактная? Для меня вполне конкретная Обоснование есть, язык по мотивам тоже есть, сейчас транслятор пишется.....в общем это уже вопрос уже не принципиальный, а только времени и денег.

К сообщению приложен файл. Размер - 0Kb
10 янв 07, 15:59    [3622244]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
U-gene
Там и пример есть и как оно работает.

Вы привели схему данных и пример DML к ней, осталось привести DDL для полноты картины, если не трудно.
U-gene
Надо говорить так - "СУБД которая реализует РМД, является объектно-ориентированной и позволяет описывать иерархии".

Если СУБД позволяет описывать иерархии, то она по определению реализует иерархическую МД.
См. IMS, Oracle
U-gene
Иерархии, сети, OO - это конечно очень хорошо и очень нужно, но это все языковые вещи

Ага, это DDL у них такой. А МД какая при этом (уж всяко не РМД)?
11 янв 07, 10:09    [3625024]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
мод
Если СУБД позволяет описывать иерархии, то она по определению реализует иерархическую МД.
См. ... Oracle


Уточните, где именно надо смотреть Oracle ?
тынц, если можно
11 янв 07, 10:37    [3625220]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
мод
Вы привели схему данных и пример DML к ней, осталось привести DDL для полноты картины, если не трудно.


Вы это о чём? О картинке? Так это просто скриншот парсера с небольшим кусочком примера, который полностью рассматривается в статье, где есть и DDL и DML.

мод
Если СУБД позволяет описывать иерархии, то она по определению реализует иерархическую МД. См. IMS, Oracle


И слава Богу.

мод
Ага, это DDL у них такой. А МД какая при этом (уж всяко не РМД)?


Попробуйте понять этот пост. Скажите, если система гаранирует, что она работает именно описанным там образом, и пользователь может быть уверен, что описав приведенную там иерархию, он сразу же сможет работать с данными, представленными в виде приведенного там отношенния - эта система иерархическая или реляционная? Что, в РМД прописано, что данные должны быть представлены в виде отношений явно пользователем, и не могут быть представлены в виде отношения системой на основании какого то другого (иерархического) описания? Существует стереотип: "РМД - это только явнооппределяемые таблицеподобные переменные с колоночками" или "если есть иерарахия, то это всяко не РМД", но ИМХО это только стереотип.
11 янв 07, 11:05    [3625462]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
мод
Если СУБД позволяет описывать иерархии, то она по определению реализует иерархическую МД. См. IMS, Oracle
О, и какой номер у ORA-xxxxx Hierarhy violated ?
11 янв 07, 11:54    [3625959]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
Gluk (Kazan)
Уточните, где именно надо смотреть Oracle ?
тынц, если можно

Nested tables - типичная иерархия
11 янв 07, 11:59    [3626012]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
U-gene
Вы это о чём?

Ну там где вы дерево рисовали
c-d /корень a-b-e-f-g \ h
U-gene

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

Именно так и прописано, а как там система это представляет - никого не интересует (физический уровень понимаешь).
Если пользователь мыслит отношениями- это РМД, если иерархиями - никакой РМД нет.
11 янв 07, 12:12    [3626122]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
мод
Gluk (Kazan)
Уточните, где именно надо смотреть Oracle ?
тынц, если можно

Nested tables - типичная иерархия


Мы уже говорили об этом. Я просил дать ссылку на документ, в котором Oracle относится к иерархическим БД. Ваши собственные измыления на эту тему малоинтересны.
11 янв 07, 12:16    [3626179]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
ModelR
и какой номер у ORA-xxxxx Hierarhy violated ?

Извините, не понял. Соственно я просто имелввиду nested tables.
11 янв 07, 12:17    [3626182]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
Gluk (Kazan)
Я просил дать ссылку на документ, в котором Oracle относится к иерархическим БД. Ваши собственные измыления на эту тему малоинтересны.

Вам шашечки или ехать ? Oracle никуда не относится. Oracle это Oracle.
11 янв 07, 12:19    [3626201]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
мод
Gluk (Kazan)
Я просил дать ссылку на документ, в котором Oracle относится к иерархическим БД. Ваши собственные измыления на эту тему малоинтересны.

Вам шашечки или ехать ? Oracle никуда не относится. Oracle это Oracle.


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

Как работать с иерархиями в Oracle я знаю. И как БЕЗ Oracle тоже.
Способность работать с иерархиями не делает БД иерархической
11 янв 07, 12:36    [3626361]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
Gluk (Kazan)
Вы используете собственную терминологию, способную ввести других в заблуждение.

Почему собственную ?
Есть три МД: иерархическая, сетевая, реляционная и их гибриды.
Конкретная СУБД может реализовывать все или некоторые из них. Как при этом называть эту СУБД - вопрос десятый.
11 янв 07, 13:04    [3626589]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
мод
U-gene
мод
Вы привели схему данных и пример DML к ней, осталось привести DDL для полноты картины, если не трудно.

Вы это о чём?
Ну там где вы дерево рисовали
c-d /корень a-b-e-f-g \ h
Эта :) То есть по-Вашему - это дерево - это я пример DML привел? Всё таки у Вас действительно то ли с терминами что-то не так, то ли с их применением. Где Вы в изображениии дерева DML то нашли?

мод
Если пользователь мыслит отношениями- это РМД, если иерархиями - никакой РМД нет.
И что дальше?. Раньше я задал Вам вопрос
Скажите, если система гаранирует, что она работает именно описанным там образом, и пользователь может быть уверен, что описав приведенную там иерархию, он сразу же сможет работать с данными, представленными в виде приведенного там отношенния - эта система иерархическая или реляционная?
Давайте я его перефразирую, что бы понятней было. Что мешает пользователю, определив некое дерево (мысля при этом конечно иерархиями - например a.b.c.d), рассматирать эти же данные как отношения (мысля конечно отношениями - например отношением "a.b" с атрибутом "c.d") при условии , что система такой ход мысли поддерживает. Такая система - она иерархическая или реляционная?
11 янв 07, 13:24    [3626763]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
U-gene
Эта :) То есть по-Вашему - это дерево - это я пример DML привел?

Ну вот:
Это значит, что если описано например дерево вида
то система должна выполнить сдедующий запрос

SELECT c.d, SUM(e.f.g)
FROM a.b
WHERE h...

U-gene

Раньше я задал Вам вопрос: система иерархическая или реляционная? Давайте я его перефразирую, что бы понятней было. Что мешает пользователю, определив некое дерево (мысля при этом конечно иерархиями - например a.b.c.d), рассматирать эти же данные как отношения (мысля конечно отношениями - например отношением "a.b" с атрибутом "c.d") при условии , что система такой ход мысли поддерживает. Такая система - она иерархическая или реляционная?

1. Если СУБД поддерживает таблицы - она реляционная, если иерархии - она иерархическая, если ссылки - она сетевая. Например IMS поддерживает все три.
2. Если пользователь мыслит иерархиями, зачем ему еще рассматирать эти же данные как отношения ? Это не так просто (метапереход). Например a.b.c.d - и сколько здесь отношений ? отношением "a.b" с атрибутом "c.d" - а почему так а не по другому ? А может это 4 отношения a b c d ? Иди одно abcd ?
И самое главное: в иерархии нет ссылок, она самосвязная, а как связывать отношения ?
11 янв 07, 15:12    [3627741]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
мод
ModelR
и какой номер у ORA-xxxxx Hierarhy violated ?

Извините, не понял. Соственно я просто имелввиду nested tables.

А-а, тогда понял. Тут забавная диалектика. Оракл предоставляет реляционный (как к таблице)доступ к данным nested table - колонки , изображающей из себя иерархически построенную память, но на самом деле хранящуюся в таблице.
11 янв 07, 15:26    [3627861]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
ModelR
Тут забавная диалектика. Оракл предоставляет реляционный (как к таблице)доступ к данным nested table - колонки , изображающей из себя иерархически построенную память, но на самом деле хранящуюся в таблице.

Точно - диалектика. Но самое главное - вложенная таблица связана с родительской строкой внутренними ссылками, которые не задаются юзером, т.е это типичная иерархия (правда - пока одноуровневая - не дотягивает оракл до IMS).
11 янв 07, 16:26    [3628355]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
мод
1. Если СУБД поддерживает таблицы - она реляционная, если иерархии - она иерархическая, если ссылки - она сетевая.
Это не ответ на мой вопрос. Или (если это ответ) то я не понял его - можно расшифровать?

мод
Если пользователь мыслит иерархиями, зачем ему еще рассматирать эти же данные как отношения ?
Не думал об абстрактном пользователе, но мне так удобнее. Например мне кажется более естественным описывая накладные представить их как(например)

НАКЛАДНАЯ
(
номер
кому
когда
СТРОКИ
(
артикулНо ...
артикулНо ...
....
)
)
.....

и затем использовать выражение типа
НАКЛАДНАЯ[когда = вчера].строки.артикулNo

(...которое (по большому счету) будет эквивалентно традиционному

SELECT артикул 
FROM накладнаяHEADER JOIN накладнаяLINES
ON накладнаяHEADER.номер = накладнаяLINES.номернакладной
WHERE накладнаяHEADER.когда = вчера
...)
и, при необходимости, выполнить незапланированный запрос,в котором будет присутствовать

...
FROM НАКЛАДНАЯ JOIN .... ON НАКЛАДНАЯ.строки.артикулNo = ....
...

мод
Это не так просто (метапереход)
Всё таки с терминами у Вас как то не так. Что такое метапереход? Какое отношение он имеет к моделям?

мод
Например a.b.c.d - и сколько здесь отношений ? отношением "a.b" с атрибутом "c.d" - а почему так а не по другому ?
Кто сказал, что нельзя по другому? Я не говорил. Я везде говори "например". Правило простое - эти две половинки (имя отношение и имя атрибута), будучи соединенными вместе, должны образовать корректное (определенное в данной системе) путевое(ссылочное) выражение.

мод
как связывать отношения?
Как обычно.
11 янв 07, 16:54    [3628583]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
okdoky
Member

Откуда:
Сообщений: 349
U-gene
Давайте я его перефразирую, что бы понятней было. Что мешает пользователю, определив некое дерево (мысля при этом конечно иерархиями - например a.b.c.d), рассматирать эти же данные как отношения (мысля конечно отношениями - например отношением "a.b" с атрибутом "c.d") при условии , что система такой ход мысли поддерживает. Такая система - она иерархическая или реляционная?
Вам очень хочется это назвать реляционной? Потому что система поддерживает такой ход мысли (a.b - отношением и c.d - атрибут)? Пожалуй да. Осталось только научить систему поддерживать этот ход мыслей . Не забывайте, что и специалисты по РМ, mir и др., также должны поддерживать (понимать) ваш ход мыслей и вашу нотацию. А если добавить к вашему условию следующее:
Атрибут d строго зависит от c, c от b, b от a. При удалении a удаляются и зависимые от него атрибуты. 
Что тогда? Ведь последнее условие не только поясняет точечную нотацию, но и характеризует другую, уже нереляционную модель данных. Впрочем выход уже найден. Он находится в ДИАЛЕКТИКЕ...
11 янв 07, 17:10    [3628685]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
U-gene

1. Ну вопрос о типе СУБД не так уж и важен - это всего лишь этикетка.
2. В остальном вы полностью повторяете то, что в оракле и называется nested tables. При этом имхо это даже не расширение РМД, а чистая иерархическая модель. При этом SQL продолжает рулить. И при этом нет необходимости связывать в selectе nested table с родительской строкой - СУБД это делает сама.
зы мне кажется вы стучитесь в открытые ворота - ваш пример с накладной в чистом виде так и описывается на оракле и в DDL и в DML.
ззы "метапереход" - преобразование одной модели к другой
11 янв 07, 17:20    [3628764]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
1 проехали
2 Например
-Я тут как то задал вопрос Может вы мне ответите?
-Глубина ссылочных стуктур не ограничена. Вместо артикулНо я мог бы использовать ссылку на объект класса Товар. А в нем бы могли быть еще ссылки... и т.д.
- И вообще зачем нужны таблицы?:) Если мы определили стркутурный тип и подразумеваем, что может существовать множество экземпляпров этого типа, зачем нам это еще в таблицыто впихивать?

PPS
vjl
"метапереход" - преобразование одной модели к другой
Это Вы где прочитали? тынц пожалуйста....
11 янв 07, 18:35    [3629299]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
U-gene
- И вообще зачем нужны таблицы?:) Если мы определили стркутурный тип и подразумеваем, что может существовать множество экземпляпров этого типа, зачем нам это еще в таблицыто впихивать?

Так множество экземпляров этого типа это и есть таблица. На самом деле вы правы: определив тип данных, мы можем строить любые коллекции этого типа, но на ум приходит только две - массив и таблица. Если у таблицы есть номер строки - то это и есть массив, тогда все сходится на таблице. Но даже при опеределении структурного типа его элементы м.б. таблицами и это надо явно указывать при его описании. Кстати, все три модели данных используют таблицы как структурную единицу - различия только в способах связи таблиц.
U-gene

-Я тут как то задал вопрос Может вы мне ответите?

Попробую. Если бы я разрабатывал СУБД, то разрешил бы вычисляемые поля даже в базовых таблицах. В существующих СУБД для этого используются view. view можно переопределять и "наследовать" т.е. создавать view на view. Для юзера view и таблицы не различимы (с оговорками). Т.е. в вашем примере надо написать новое view с выч. полем.
PPS "метапереход" - это Шуклин придумал :). Нужен же какой-то термин для понятия "преобразования моделей".
12 янв 07, 09:54    [3630648]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
мод
вложенная таблица связана с родительской строкой внутренними ссылками, которые не задаются юзером, т.е это типичная иерархия (правда - пока одноуровневая - не дотягивает оракл до IMS).
Ну почему же одноуровневая? прямо из мануала:
CREATE TYPE satellite_t AS OBJECT (
  name        VARCHAR2(20),
  diameter    NUMBER);

CREATE TYPE nt_sat_t AS TABLE OF satellite_t;

CREATE TYPE planet_t AS OBJECT (
  name        VARCHAR2(20),
  mass        NUMBER,
  satellites  nt_sat_t);

CREATE TYPE nt_pl_t AS TABLE OF planet_t;


CREATE TABLE stars (
  name     VARCHAR2(20),
  age      NUMBER,
  planets  nt_pl_t)
NESTED TABLE planets STORE AS planets_tab 
  (NESTED TABLE satellites STORE AS satellites_tab);

Но приципиально да, Оракл блюдет иерархию в том смысле, что никоим образом невозможно
создать satellites иначе чем предварительно создав запись stars, а в ней planets. Прямые операции с STORE AS - таблицами planets_tab и satellites_tab запрещены.
12 янв 07, 11:04    [3631137]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
ModelR
Ну почему же одноуровневая?

Sorry, не туда глянул (кажется в 8i). Все нормально, многоуровневая иерархия.
ModelR

Но приципиально да, Оракл блюдет иерархию в том смысле, что никоим образом невозможно
создать satellites иначе чем предварительно создав запись stars, а в ней planets. Прямые операции с STORE AS - таблицами planets_tab и satellites_tab запрещены.

Ну так и д.б. и в IMS так же - полная аналогия. satellites и planets не рассматриваются как самостоятельные таблицы. (спасибо за пример).
12 янв 07, 12:25    [3631855]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
laafrb
Member

Откуда:
Сообщений: 31
чего замолчали то?
18 янв 07, 12:07    [3659412]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
gru
Guest
laafrb О чем тут говорить? Посмотрите что с погодой. Все становится непонятным и странным. Вчитайтесь только:
ModelR
мод
Извините, не понял. Соственно я просто имелввиду nested tables.

А-а, тогда понял. Тут забавная диалектика. Оракл предоставляет реляционный (как к таблице)доступ к данным nested table - колонки , изображающей из себя иерархически построенную память, но на самом деле хранящуюся в таблице.
Это противоречит даже первой нормальной форме, не допускающей в частности многозначные поля в таблице. Разваливается мир, реляционная модель, ...всё. И никакая диалектика тут не поможет (((
21 янв 07, 18:28    [3672001]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
okdoky
Member

Откуда:
Сообщений: 349
gru
ModelR
А-а, тогда понял. Тут забавная диалектика. Оракл предоставляет реляционный (как к таблице)доступ к данным nested table - колонки , изображающей из себя иерархически построенную память, но на самом деле хранящуюся в таблице.
Это противоречит даже первой нормальной форме, не допускающей в частности многозначные поля в таблице. Разваливается мир, реляционная модель, ...всё. И никакая диалектика тут не поможет (((
Ну почему вы так грустно? Да, теория отстает от практики. Реляционные штаны, придуманные Коддом, постепенно становятся короче и уже. Дейт их слегка прирастил. Сказал, что значение домена может быть не только скалярным. Если хотите, можете говорить о нормализованных и ненормализованных реляционных моделях. Говорить можно что угодно. Вон, U-gene добавил, что иерархические структуры и зависимости тоже можно пришить к реляционной модели. Почему нет? Будем такую модель уточнять как иерархическая-реляционная модель или реляционная модель вложенных отношений. Другое дело как быть с той алгеброй, математическим аппаратом, пока удобным только для нормализованных отношений ИМХО. Тут может помочь точечная нотация, или как в Zigzag или XPath, что-то типа a[z/y]/b[c[...]].
23 янв 07, 17:25    [3682410]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
okdoky
gru
Разваливается мир, реляционная модель, ...всё. И никакая диалектика тут не поможет (((
Ну почему вы так грустно? Да, теория отстает от практики. Реляционные штаны, придуманные Коддом, постепенно становятся короче и уже. Дейт их слегка прирастил. Сказал, что значение домена может быть не только скалярным. Если хотите, можете говорить о нормализованных и ненормализованных реляционных моделях. Говорить можно что угодно. Вон, U-gene добавил, что иерархические структуры и зависимости тоже можно пришить к реляционной модели. Почему нет? Будем такую модель уточнять как иерархическая-реляционная модель или реляционная модель вложенных отношений. Другое дело как быть с той алгеброй, математическим аппаратом, пока удобным только для нормализованных отношений ИМХО. Тут может помочь точечная нотация, или как в Zigzag или XPath, что-то типа a[z/y]/b[c[...]].
Родные, но не с вашим уровнем познаний можно философски рассуждать о судьбах РМД, снисходительно похлопывая покойничка Кодда и старичка Дейта по плечу. И тем более нести чушь про "нормализованные и ненормализованные реляционные модели".
Если вы помните, то исходная и самая знаменитая статья Кодда, давшая начало реляционной эпохе -- это A Relational Model of Data for Large Shared Data Banks, Communications of the ACM, Vol. 13, No. 6, June 1970, pp. 377-387. И что же мы там читаем?
E.F.Codd, A Relational Model of Data for Large Shared Data Banks
So far, we have discussed examples of relations which are defined on simple domains — domains whose elements are atomic (nondecomposable) values. Nonatomic values can be discussed within the relational framework. Thus, some domains may have relations as elements. These relations may, in turn, be defined on nonsimple domains, and so on. For example, one of the domains on which the relation employee is defined might be salary history. An element of the salary history domain is a binary relation defined on the domain date and the domain salary. The salary history domain is the set of all such binary relations. At any instant of time there are as many instances of the salary history relation in the data bank as there are employees. In contrast, there is only one instance of the employee relation.

Таким образом, Кодд изначально предусматривал в РМД nonsimple domains и nonatomic values.
Тогда вопрос, откуда взялась 1 нормальная форма? Очень просто. Далее в статье Кодд предложил механизм, названный им "нормализацией", позволяющий преобразовывать отношения с вложенными отношениями в набор отношений в "нормальной форме" (т.е. определенных только на simple domains). Но он ясно указал, что это стоит делать только из прагматических соображений, цитата:
E.F.Codd, A Relational Model of Data for Large Shared Data Banks
The simplicity of the array representation which becomes feasible when all relations are cast in normal form is not only an advantage for storage purposes but also for communication of bulk data between systems which use widely different representations of the data. The communication form would be a suitably compressed version of the array representation and would have the following advantages:
1. It would be devoid of pointers (address-valued or displacement-valued). It would avoid all dependence on hash addressing schemes.
2. It would contain no indices or ordering lists.
Таким образом, приведение доменов к "простому" виду он предложил исключительно для облегчения внутренней реализации будущих реляционных систем. Второй его аргумент, следующий сразу за процитированным, был таков:
E.Codd, A Relational Model of Data for Large Shared Data Banks
If the user's relational model is set up in normal form, names of items of data in the data bank can take a simpler form than would otherwise be the case.
И опять никаких теоретических ограничений, просто "система именования попроще будет".
Что там за прошедшие годы навыдумывали всякие идиоты про теоретический запрет на nosimple domains, пусть останется на их совести. Дейт и другие ничего не "приращивали".

Про алгебраическую поддержку тоже не беритесь рассуждать, полный набор операций, включающих работу с вложенными отношениями, давным-давно предложен. Нотация, как элемент синтаксиса, вообще не имеет отношения к алгебре, но это трудно понять человеку, не осилившему определение типа данных как множества значений...
24 янв 07, 15:25    [3688168]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
P.S. Про "идиотов", придумавших "теоретический запрет" на nosimple domains, я погорячился. Тот же Дейт еще в 6 издании ВвСБД не приветствовал вложенные отношения (правдя, очень вяло). Так что лучше сказать, что сейчас теория во многом просто очищается от ряда ненужных ограничений, ранее вызванных в т.ч. проблемами реализации.
24 янв 07, 15:39    [3688301]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
43210
Guest
mir
P.S. Про "идиотов", придумавших "теоретический запрет" на nosimple domains, я погорячился.
Возможно вы просто определили место для Дейта?
24 янв 07, 17:00    [3689072]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
gru
Guest
mir
Про алгебраическую поддержку тоже не беритесь рассуждать, полный набор операций, включающих работу с вложенными отношениями, давным-давно предложен.
Можно манипулировать комплексными значениями? Не выдавать их в качестве результата, а использовать как исходные данные? Разве точечная нотация это плохо?
mir
Про алгебраическую поддержку тоже не беритесь рассуждать, полный набор операций, включающих работу с вложенными отношениями, давным-давно предложен. Нотация, как элемент синтаксиса, вообще не имеет отношения к алгебре, но это трудно понять человеку, не осилившему определение типа данных как множества значений...
Ужасть. Нотация и синтаксис не имеет отношение к алгебре? А вот это. Нет нотации, нет семантики, уважаемый mir
24 янв 07, 21:31    [3690237]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
gru
Guest
okdoky
Да, теория отстает от практики.
Сомнителное утверждение. Разве Вы пишите программу без предварительной проектирования и разработки модели данных? Как Кодд, так и Дейт, создавали свои модели на бумаге и опирались скорее на предварительные исследовательские разработки, не имеющие достаточного практического применения.
24 янв 07, 22:30    [3690340]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
mir
Member

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

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

Короче говоря, ни в коем случае нельзя сказать, что Дейт ранее возражал против поддержки в РМД RVA и сложных пользовательских типов в целом.
25 янв 07, 08:06    [3690769]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
gru
Ужасть. Нотация и синтаксис не имеет отношение к алгебре?
Не имеет. И ужасть в том, что вы этого не понимаете.
gru
А вот это.
А что вот это? Вы сами-то пытались читать, что написано в статье по данной ссылке?
gru
Нет нотации, нет семантики, уважаемый mir
Запущено-то как все... Хорошо, вот вам тест на понимание.
Допустим, в языке L1 алгебраическая операция сложения чисел x и y записывается так: x + y
В языке L2 так: (+, x, y)
В языке L3 так: x.ADD.y
В языке L4 так: Add(x, y)
В языке L5 так: x.Add(y)
В языке L6 так: x->y->Add
Имеем 6 нотаций. Вопрос: у нас 6 разных алгебр или одна и та же алгебра?
25 янв 07, 08:37    [3690834]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
okdoky
Member

Откуда:
Сообщений: 349
gru
okdoky
Да, теория отстает от практики.
Сомнителное утверждение. Разве Вы пишите программу без предварительной проектирования и разработки модели данных? Как Кодд, так и Дейт, создавали свои модели на бумаге и опирались скорее на предварительные исследовательские разработки, не имеющие достаточного практического применения.
Теория, это обобщение практики. Конечно теоретизировать можно все. Тут надо чувствовать, что является перспективнее. Тогда в 60-х годах очень популярны были системы обрабатывающие данные, хранящиеся в последовательных файлах (заранее отсортированные). Сейчас имеют большие шансы на успех иерархические XML-СУБД. Да, они скорее исследовательские. Исследование, это тоже практика. Если выживут, основанная на них теория тоже выживет. Вот уже новый шаг был позавчера, от "предлагаемой рекомендации" к "рекомендации" для XQuery.
mir
Запущено-то как все... Хорошо, вот вам тест на понимание.
Допустим, в языке L1 алгебраическая операция сложения чисел x и y записывается так: x + y
В языке L2 так: (+, x, y)
В языке L3 так: x.ADD.y
В языке L4 так: Add(x, y)
В языке L5 так: x.Add(y)
В языке L6 так: x->y->Add
Имеем 6 нотаций. Вопрос: у нас 6 разных алгебр или одна и та же алгебра?
Что вы упираетесь? Если есть разные языки для выражения одного и того же, это не значит, что языки, нотация, синтаксис, вообще не требуются. Тут вопрос какой язык лучше? Например, Tutorial D или SQL2 не очень годятся для оперирования с вложенными отношениями и иерархическими зависимостями. Неужели кроме Дейта, вам некого больше изучать? Срочно читать других учеников-неидеотов.
Модератор: будешь продолжать хамить - забаню.


Сообщение было отредактировано: 25 янв 07, 09:27
25 янв 07, 09:17    [3690952]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
mir
Member

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

Откуда: Томск
Сообщений: 1027
gru
mir
Про алгебраическую поддержку тоже не беритесь рассуждать, полный набор операций, включающих работу с вложенными отношениями, давным-давно предложен.
Можно манипулировать комплексными значениями? Не выдавать их в качестве результата, а использовать как исходные данные?
Теоретические вопросы использования вложенных отношений проработаны еще в период с 1977 по 1988 г. в целом ряде публикаций. Библиографию можно найти у того же Дейта. Про долговременное отсутствие реализации RVA в СУБД -- вопросы только к разработчикам СУБД. Oracle, насколько я знаю, уже давно поддерживает, правда в своей собственной манере.
Вопросы поддержки сложных пользовательских типов теоретически проработаны тоже давно. Тот же Дейт в последних изданиях ВвСБД уделил этому очень много внимания. В новых стандартах SQL расширенная поддержка UDT тоже предусмотрена.
gru
Разве точечная нотация это плохо?
Опять двадцать пять. Кто здесь критиковал точечную нотацию? При чем здесь точечная нотация?
25 янв 07, 10:48    [3691570]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
mir
Теоретические вопросы использования вложенных отношений проработаны. Oracle, насколько я знаю, уже давно поддерживает, правда в своей собственной манере.

Oracle поддерживает вложенные таблицы. В связи с этим и возвращаясь к истокам: почему в РМД отношения, а в СУБД таблицы, в чем разница ?
25 янв 07, 11:17    [3691836]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
ModelR
Member

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

В общем, как заметил U-gene, цикл Карно это одно, а двигатель это другое.
25 янв 07, 12:37    [3692593]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
ModelR
Дык отношения - это абстактное понятие, а таблица - техническое устройство, как никак а связанная с устройством памяти.

Как таблица связана с устройством памяти ? Да никак (их еще на МЛ хранили).
ModelR
В частности таблицы - мультимножества, допускают одинаковые строки.

В любом множестве все элементы разные, следовательно таблица - не множество.
Но тогда получается, что СУБД работают совсем с другой моделью данных (что так и есть на самом деле).
25 янв 07, 12:53    [3692714]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
mir
Member

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

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

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

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

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

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

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

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

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

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

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



Поэтому, когда кто-то говорит «отношение» (relation) — его все всегда понимают. Когда кто-то говорит «таблица», его можно понять только по контексту, а то и ошибиться. А когда Шуклин в своей писанине говорит «таблица» — его понять вообще невозможно.
мод
Но тогда получается, что СУБД работают совсем с другой моделью данных (что так и есть на самом деле).
И поэтому чистые теоретики РМД изобрели даже спец-термин — SQL-СУБД, чтобы подчеркнуть, что это не вполне РМД.
25 янв 07, 14:11    [3693421]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
okdoky
Member

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

И еще. То, как вы узко понимаете тип и не признаете другие определения, также подчеркивает ваши слабые знания ООП, а значит и объектно-реляционной модели. Изучайте, подтягивайтесь. Чтобы не было разговора глухих. Зачем нам тратить зря время?
25 янв 07, 14:15    [3693465]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
vadiminfo
Member

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

Отношения в РМД - математические конструкции. Там есть еще и схема отношения. Таблицы в СУБД их представления вместе со схемой отношения - реляционные таблицы. А вложенные таблы - это как раз не реляционные. Это массивы (разреженные) записей, поддерживаются операции доступа по индексу и т.д., т.е. они упорядоченные, в то время как реляционные не упорядочены с точки зрения манипулирования ими. Это расширения РМД, равно как и включение ЛОБов - не структурированных даннх, объектных типов - ОРМД.
25 янв 07, 14:32    [3693616]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
mir
Вторая группа «смыслов» — таблица как физическое понятие.

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

Это не их изобретение. Фактически таблица, это функция вида
n->(A1,A2,A3...An), т.е. отображение целого числа (номер строки) на отношение (ведь отношение - это множество). Частный случай таблицы - массив в ЯП. Поэтому в СУБД реализовали таблицу-функцию, а не R-таблицу - множество. Отсюда:
mir
И поэтому чистые теоретики РМД изобрели даже спец-термин — SQL-СУБД, чтобы подчеркнуть, что это не вполне РМД.
25 янв 07, 14:45    [3693726]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
mir
Member

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

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

Это первое.

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

По поводу "читайте, изучайте", все еще жду от вас список горячо рекомендуемых вам книг.
25 янв 07, 14:46    [3693740]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
vadiminfo
Отношения в РМД - математические конструкции.

Да, множества кортежей.
vadiminfo

Таблицы в СУБД их представления вместе со схемой отношения - реляционные таблицы.

С чего бы это ? Тоже множества ? Что в них "реляционного" ?
vadiminfo
А вложенные таблы - это как раз не реляционные.

Ничем не отличаются от основных таблиц.
vadiminfo
Это расширения РМД

Как можно расширить то, что не реализовано (а реализовано что-то другое).
25 янв 07, 14:52    [3693792]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
мод
mir
Первая группа «смыслов» — таблица как абстрактное представление (логическое понятие).
SQL-таблица (т.е. TABLE в языке SQL) — изобретение авторов SQL.

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

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

мод
Поэтому в СУБД реализовали таблицу-функцию, а не R-таблицу - множество.
Почему "поэтому"? Вывод не следует из посылки.
25 янв 07, 15:02    [3693873]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
мод

С чего бы это ? Тоже множества ? Что в них "реляционного" ?

Не множеста, а таблицы? Реляционными принято называть разновидность таблиц, отвечающих определенным требованиям.

мод

Ничем не отличаются от основных таблиц.

Из Оракловой справки
Understanding Nested Tables
You can think of them as one-dimensional arrays with no declared number of elements. You can model multi-dimensional arrays by creating nested tables whose elements are also nested tables.
Это все таки отличает их от основных таблиц - как не крути.

мод

Как можно расширить то, что не реализовано (а реализовано что-то другое).

Это что-то другое относят к РМД. Есть какие-то требования, которые считаются достаточными, чтобы СУБД была отнесена к РСУБД. Оракл признают РСУБД, чуть ли не первой коомерческой.
Скуль, Диби2, Сибэйс - не оспариваются реально как РСУБД.
25 янв 07, 15:38    [3694226]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Т.е. не ставятся под сомнение, что они РСУБД. ЧАЛ не в счет.
25 янв 07, 15:40    [3694242]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
mir
в логической таблице нет никаких номеров строк

А как их тогда различать ?
mir
не бывает отображения одного числа на множество

ну, был не точен, ессно мн-ва целых чисел на мн-во кортежей (отношение)
mir
Массив в ЯП -- понятие уровня физической реализации, к логическим таблицам не имеет отношения. Что-то у вас в голове все в кучу.

У кого как - причем здесь физическая реализация ЯП (ее вообще может не быть) ?
mir
Почему "поэтому"? Вывод не следует из посылки.

Потому что функцию реализовать можно, а множество нельзя.
25 янв 07, 16:52    [3694832]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
vadiminfo
Реляционными принято называть разновидность таблиц, отвечающих определенным требованиям.

А если я в своей БД имею таблицы, "не отвечающих определенным требованиям", они уже не реляционные ?
vadiminfo
Это все таки отличает их от основных таблиц - как не крути.

Да нет, все таблицы одинаковы. Сравните сегменты в IMS - то же таблицы, а СУБД иерархическая.
vadiminfo
Есть какие-то требования, которые считаются достаточными, чтобы СУБД была отнесена к РСУБД.

Т.е. "Р" - это просто торговая марка, лейбл для чайников.
25 янв 07, 17:01    [3694890]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
мод
ModelR
Дык отношения - это абстактное понятие, а таблица - техническое устройство, как никак а связанная с устройством памяти.

Как таблица связана с устройством памяти ? Да никак (их еще на МЛ хранили).
А я еще перфоленты помню:).
Имеется ввиду, что SQL таблица обладаем физическими характеристиками хранения, а главное она несет на себе свойства памяти. Например, таблицу можно читать сторка за строкой. Да, оговаривается, что никто не гарантирует тот же порядок при следующем проходе. Т.е СУБД имеет право произвольно перетасовывать строки и пользователю запрещено в это вмешиваться, но всегда они обязательно лежат в каком-то порядке.
Такое устройство характерно для памяти а не для отношения.
25 янв 07, 19:31    [3695830]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
мод

А если я в своей БД имею таблицы, "не отвечающих определенным требованиям", они уже не реляционные ?

Например, если имена столбцов не уникальны, или сложная схема имен столбцов (с иерахиями имен), то думаю,
такие таблы не называю в литре по БД реляционными.

мод

Да нет, все таблицы одинаковы. Сравните сегменты в IMS - то же таблицы, а СУБД иерархическая.

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

мод

Есть какие-то требования, которые считаются достаточными, чтобы СУБД была отнесена к РСУБД.

Есть, например, 12 правил Кодда, направленные на то чтобы отсечь СУБД компромитирующие основные идеи РМД. Например, взяли только таблы , а доступ не связан с реляционной системой запросов, например, навигациооный - хождение по указателям и ссылкам.
Однако, думаю, главным остается соблюдение основных идей РМД, позволяющие использовать рациональное зерно идей РМД и отличить от других МД. Думаю, сам Кодд, покинувший нас в 2002, спроси его счас не стал бы назвать не реляционными Оракла, Скуля, Диби2, Сибэйса. Ить кто тада РСУБД? В целом имеет значение признание РСУБД многими специалистами.
25 янв 07, 22:15    [3696198]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
ModelR
Имеется ввиду, что SQL таблица обладаем физическими характеристиками хранения, а главное она несет на себе свойства памяти.
Например, таблицу можно читать сторка за строкой. Да, оговаривается, что никто не гарантирует тот же порядок при следующем проходе. Т.е СУБД имеет право произвольно перетасовывать строки и пользователю запрещено в это вмешиваться, но всегда они обязательно лежат в каком-то порядке.
Такое устройство характерно для памяти а не для отношения.

Да нет, все проще и память здесь не причем. Возможность последовательного чтения таблицы - это прямое следствие того, что это функция (сравните с массивом). То же самое с сортировкой. С таблицей - отношением это просто невозможно, ведь значение переменной-отношения - это множество и над ним возможны только множественные операции.
26 янв 07, 10:37    [3697443]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
vadiminfo
Записеориентированность ведь связана со стремлением манипулировать. И может быть это ближе к компьютерным структурам.

Совершенно верно - понятие таблицы в СУБД очень близко понятиям списков и массивов в ЯП (а точнее - это одно и то же).
Я так и непонял как отличит "реляционную" таблицу от "нереляционной" (сортировка таблицы - это не ее свойство, а операция над ней).
Рассуждение о типах СУБД считаю схоластическими - оставим это маркетологам.
26 янв 07, 10:48    [3697515]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
мод

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

Я пытался Вам сказать, что без операций таблицы имеют значение разве, что в видет отчетов, для всяких ведомств. В этом смысле реляционные - это самые простейшие из возможных табл. Думаю, что в этом смысле они мало имеют значения. Ну только для девочек, что на ворде или в йекселе отчеты клепают. Потому что БД создают не для того, чтобы занять персонал их набором, а все же инфу извлекать какую ни на есть.
Рассуждения о типах СУБД никаим маркетолагам оставлять не стоит. В этом разделе форума - это один из основных вопросов. Скажите Ваш тип СУБД и я скажу кто Вы. (Шуткэ, поясняю а то некоторые все буквально тут понимают на свой счет).
26 янв 07, 11:30    [3697950]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
мод
mir
в логической таблице нет никаких номеров строк

А как их тогда различать?
Как отличают элементы в множестве? Путем сравнения. Если не равны —значит отличаются.
мод

mir
не бывает отображения одного числа на множество
ну, был не точен, ессно мн-ва целых чисел на мн-во кортежей (отношение)
То есть в итоге по вашему таблица есть отображение мн-ва целых чисел на мн-во кортежей. Но поскольку отображение есть частный случай отношения, то по «вашему определению» таблицы она опять-таки является отношением. И к чему тогда сыр-бор?
мод
mir
Массив в ЯП -- понятие уровня физической реализации, к логическим таблицам не имеет отношения. Что-то у вас в голове все в кучу.
У кого как - причем здесь физическая реализация ЯП (ее вообще может не быть)?
По вашему «массив» — это понятие высокого уровня абстракции? Массивы даже в ассемблере есть, вот уж высокий уровень.
мод
mir
Почему "поэтому"? Вывод не следует из посылки.
Потому что функцию реализовать можно, а множество нельзя.
Нельзя, потому что вы не разрешаете? Вот черт, а когда я в C++ или Delphi определяю множество и работаю с ним, я ваш запрет нарушаю, ничего?
(А если вспомнить, что в математике функция часто определяется через отображение, то есть через отношение, то есть через множество, становиться совсем весело.)
27 янв 07, 08:58    [3702667]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
мод
Я так и непонял как отличит "реляционную" таблицу от "нереляционной"

Вот здесь развернутое пояснение по этому вопросу.
27 янв 07, 09:06    [3702670]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
mir
Как отличают элементы в множестве? Путем сравнения. Если не равны —значит отличаются.

Все элементы любого множества - разные - чего их сравнивать ? Да и операции такой нет. Единственное что вы можете сделать - это определить принадлежность элемента мн-ву.
mir
Но поскольку отображение есть частный случай отношения, то по «вашему определению» таблицы она опять-таки является отношением.

Отображение - это функция, а отношение - множество - это что, одно и то же ?
mir
По вашему «массив» — это понятие высокого уровня абстракции? Массивы даже в ассемблере есть, вот уж высокий уровень.

Я бы не стал выставлять уровни абстракции для разных ЯП. Имхо массив - понятие абстрактное.
По сути это функция с целочисленными аргументами. Таблица - частный случай массива.
mir
а когда я в C++ или Delphi определяю множество и работаю с ним

Не понял что вы имеете ввиду, тип данных ?
29 янв 07, 10:12    [3705650]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
mir
Вот здесь [/url] развернутое пояснение по этому вопросу.

Там вроде как про алгебру, а я спрашивал про таблицы.
29 янв 07, 10:15    [3705664]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
okdoky
Member

Откуда:
Сообщений: 349
mir
Я вообще не имею своего собственного, "оригинального" определения основных терминов, да и никому не советую. Есть общепринятые в математике (в первую очередь) и в программировании (как правило, заимствованные из математики) понятия. Их надо просто знать, а не гордиться своим незнанием, приводящим к изобретению "оригинальных" определений.

Это первое.

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

По поводу "читайте, изучайте", все еще жду от вас список горячо рекомендуемых вам книг.
Судя по вашему диалогу с mod вы правильно понимаете таблицу только как одну из форм представления отношения. Но кроме отношения также очень полезно понимать термин класс. Во многом он схож с тем, что называется типом. В РМ определение типа раньше сводилось к банальному определению его как домена. В последнее время в области РМ наметились сдвиги, прежде всего в сторону ООП. Постепенно ваши учителя (или ученики Кодда) трансформируют определение типа в сторону того, как этот тип понимается в ООП. Для начала рекомендую одну из следующих ссылок
http://www.answers.com/topic/object-oriented-programming
http://en.wikipedia.org/wiki/Class_(computer_science)
29 янв 07, 13:43    [3707260]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
мод
mir
Как отличают элементы в множестве? Путем сравнения. Если не равны —значит отличаются.
Все элементы любого множества - разные - чего их сравнивать ? Да и операции такой нет. Единственное что вы можете сделать - это определить принадлежность элемента мн-ву.
Интересно, а в вашем «определении» таблицы как вы собрались отличать номера строк? А если серьезно, то в аксиоматической теории множеств логическая операция равенства элементов a=b считается заданной как аксиоматическая. Читайте, скажем, здесь и в первой же аксиоме (Axiom of extensionality) вы найдете операцию сравнения элементов x=y.
мод
mir
Но поскольку отображение есть частный случай отношения, то по «вашему определению» таблицы она опять-таки является отношением.
Отображение - это функция, а отношение - множество - это что, одно и то же?
Я подозреваю, что вы в каком-то очень плохом вузе учились. Все эти понятия в путнем вузе на 1 курсе дают, в матанализе. Освежите-ка в памяти формальное определение функции через отношение. Пoчитайте хоть вот эту статью, особенно в части «Очень формальное определение».
мод
mir
По вашему «массив» — это понятие высокого уровня абстракции? Массивы даже в ассемблере есть, вот уж высокий уровень.
Я бы не стал выставлять уровни абстракции для разных ЯП. Имхо массив - понятие абстрактное.
Только почему-то в литературе по алгоритмам и структурам данных никогда не рассматривают способы реализации массивов, считая их примитивными встроенными типами языков программирования. Откроем классическую книгу Ахо, Хопкрофта и Ульмана «Структуры данных и алгоритмы». И увидим помимо прочего кучу тем вроде «Реализация списков посредством массивов», «Реализация стеков посредством массивов», «Реализация отображений посредством массивов», «Представление деревьев с помощью массивов» и т.д. Но ни одной — про реализацию массивов посредством чего-либо более атомарного. А про массивы там говорят: «в качестве простейшего механизма агрегирования ячеек […] можно применять (одномерный) массив, т.е. последовательность ячеек определенного вида.»
О чем я и говорил, массивы в ЯП — это самый низкий уровень, уровень реализации. Ниже только «ячейки». Поэтому рассуждать об абстрактных понятиях «множество», «отображение», «отношение» в терминах массивов — значит путать логический и физический уровни представления данных.
мод
mir
а когда я в C++ или Delphi определяю множество и работаю с ним
Не понял что вы имеете ввиду, тип данных ?
И тип данных, и переменные такого типа. И почему вы, интересно, считаете, что множество реализовать нельзя? В уже упомянутой книге аж две (!) главы посвящены способам реализации множеств и операций над множествами. Но вот мод сказал нельзя, значит нельзя?
29 янв 07, 13:54    [3707372]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
okdoky, ну смешно прямо - неужели Вы думаете что кто-то тут не знает что такое ООП?
29 янв 07, 13:56    [3707389]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
мод
mir
Вот здесь [/url] развернутое пояснение по этому вопросу.

Там вроде как про алгебру, а я спрашивал про таблицы.
Я серьезно начинаю сомневаться в вашей способности читать. Там, по ссылке, ни слова про алгебру и очень много про отличия R-таблиц и SQL-таблиц.
29 янв 07, 13:57    [3707398]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
okdoky
Судя по вашему диалогу с mod вы правильно понимаете таблицу только как одну из форм представления отношения.
Вы тоже невнимательно читаете? Вот здесь я написал все, что понимаю под «таблицей». И как форму представления отношения, и не как форму представления отношения. Кстати, спасибо, о сенсей, что милостиво признали одно из пониманий правильным.
okdoky
Но кроме отношения также очень полезно понимать термин класс.
Прям глаза открылись! А я-то лет 15 программирую на OO-языках, книг десять об ООП прочитал и одну книжку сам написал, и никак не мог допереть, что «полезно понимать термин класс».
okdoky
Во многом он схож с тем, что называется типом.
Помедленней, пожалуйста, я записываю…
okdoky
В РМ определение типа раньше сводилось к банальному определению его как домена.
Да ну! Открытия все множатся!
okdoky
В последнее время в области РМ наметились сдвиги, прежде всего в сторону ООП. Постепенно ваши учителя (или ученики Кодда) трансформируют определение типа в сторону того, как этот тип понимается в ООП. Для начала рекомендую одну из следующих ссылок
http://www.answers.com/topic/object-oriented-programming
http://en.wikipedia.org/wiki/Class_(computer_science)
И где ж по этим ссылкам фигурируют ученики Кодда? Или это было для красного словца?
29 янв 07, 14:25    [3707568]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
mir
мод
mir
Как отличают элементы в множестве? Путем сравнения. Если не равны —значит отличаются.
Все элементы любого множества - разные - чего их сравнивать ? Да и операции такой нет. Единственное что вы можете сделать - это определить принадлежность элемента мн-ву.
Интересно, а в вашем «определении» таблицы как вы собрались отличать номера строк? А если серьезно, то в аксиоматической теории множеств логическая операция равенства элементов a=b считается заданной как аксиоматическая. Читайте, скажем, здесь и в первой же аксиоме (Axiom of extensionality) вы найдете операцию сравнения элементов x=y.
мод
mir
Но поскольку отображение есть частный случай отношения, то по «вашему определению» таблицы она опять-таки является отношением.
Отображение - это функция, а отношение - множество - это что, одно и то же?
Я подозреваю, что вы в каком-то очень плохом вузе учились. Все эти понятия в путнем вузе на 1 курсе дают, в матанализе. Освежите-ка в памяти формальное определение функции через отношение. Пoчитайте хоть вот эту статью, особенно в части «Очень формальное определение».
мод
mir
По вашему «массив» — это понятие высокого уровня абстракции? Массивы даже в ассемблере есть, вот уж высокий уровень.
Я бы не стал выставлять уровни абстракции для разных ЯП. Имхо массив - понятие абстрактное.
Только почему-то в литературе по алгоритмам и структурам данных никогда не рассматривают способы реализации массивов, считая их примитивными встроенными типами языков программирования. Откроем классическую книгу Ахо, Хопкрофта и Ульмана «Структуры данных и алгоритмы». И увидим помимо прочего кучу тем вроде «Реализация списков посредством массивов», «Реализация стеков посредством массивов», «Реализация отображений посредством массивов», «Представление деревьев с помощью массивов» и т.д. Но ни одной — про реализацию массивов посредством чего-либо более атомарного. А про массивы там говорят: «в качестве простейшего механизма агрегирования ячеек […] можно применять (одномерный) массив, т.е. последовательность ячеек определенного вида.»
О чем я и говорил, массивы в ЯП — это самый низкий уровень, уровень реализации. Ниже только «ячейки». Поэтому рассуждать об абстрактных понятиях «множество», «отображение», «отношение» в терминах массивов — значит путать логический и физический уровни представления данных.
мод
mir
а когда я в C++ или Delphi определяю множество и работаю с ним
Не понял что вы имеете ввиду, тип данных ?
И тип данных, и переменные такого типа. И почему вы, интересно, считаете, что множество реализовать нельзя? В уже упомянутой книге аж две (!) главы посвящены способам реализации множеств и операций над множествами. Но вот мод сказал нельзя, значит нельзя?
29 янв 07, 14:28    [3707593]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
mir
Там, по ссылке, ни слова про алгебру и очень много про отличия R-таблиц и SQL-таблиц.

Значит не туда попал, сорри. По вашим же словам R-таблицы, это синоним отношений, т.е. совсем не таблицы. А про SQL-таблицы я и сказал, что это не отношения (иначе бы они были R), а функции. Но вот что такое "реляционные таблицы" - это тайна.
29 янв 07, 14:33    [3707626]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
Что-то сглючило...
mir
вы найдете операцию сравнения элементов x=y.

Это не сравнение элементов (сами то читали ?)
mir
Пoчитайте хоть вот эту статью, особенно в части «Очень формальное определение».
Обычное определение функции как отображения (сами то читали ?)
[quot mir]О чем я и говорил, массивы в ЯП — это самый низкий уровень, уровень реализации. Ниже только «ячейки».

Не те вы книжки читаете. Массив, каждый элемент которого может быть произвольного пользовательского типа - это примитив, «ячейки» ?
mir
И почему вы, интересно, считаете, что множество реализовать нельзя?

Хотя бы из-за бесконечности - сравните с таблицами-функциями.
29 янв 07, 14:44    [3707727]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
мод
mir
Там, по ссылке, ни слова про алгебру и очень много про отличия R-таблиц и SQL-таблиц.

Значит не туда попал, сорри. По вашим же словам R-таблицы, это синоним отношений, т.е. совсем не таблицы. А про SQL-таблицы я и сказал, что это не отношения (иначе бы они были R), а функции. Но вот что такое "реляционные таблицы" - это тайна.
Все просто. "Реляционная таблица" -- это SQL-таблица, которая является отношением.
29 янв 07, 15:17    [3708019]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
4321
Member [заблокирован]

Откуда:
Сообщений: 3573
мод
Обычное определение функции как отображения (сами то читали ?)

гм. с каких пор отображения перестали быть (частным случаем) отношениями?


мне кажется вы спорите о следующем:
"субд"-ные таблицы не явлвются вообще говоря _n-местными_ отношениями (где n - число колонок таблицы), но n+1 местными (где первым элементом кортежа является указатель записи - т.е. вещь весьма, с точки зрения пользователя, непостоянная, а сл-но в SQL-таблице не показываемая, поэтому-то и вводится дополнительное требование наличия ключа - с тем, чтобы иметь возможность абстрагироваться от указателя).
29 янв 07, 15:24    [3708086]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
mir
Все просто. "Реляционная таблица" -- это SQL-таблица, которая является отношением.

По вашим же словам SQL-таблица не отношение, иначе она была-бы R таблицей. И вы приводили отличия SQL-таблиц от отношений (повтор строк, null и т.д.). Или вы называете реляционной таблицу без повторов, null ? А сортировка всегда дает не реляционную таблицу ?
29 янв 07, 15:25    [3708095]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
мод

Но вот что такое "реляционные таблицы" - это тайна.

Да ладно запугивать тайнами.
В РБД есть схемы отношений и соответсвующие им отношеня. Схема - множество имен атрибутов. Пусть к примеру R(A, B, C) - схема. r соотв ему отношение, состоит из кортежей
<a1, b1, c1>, <a2, b2, c2>. Реляционная табла - представление этой пары в табличном виде (т.е. из заголовка таблы с именами столбцов и строк).
стало быть представлением данной пары буит
A | B | C
---------
a1|b1|c1
a2|b2|c2

Из этого происхождния как представления пары схема и отношекние из РБД и вытекают требования
Уникальность имен колонок - схема множество.
Наличие заголовка, т.е. табла

a1|b1|c1
a2|b2|c2
Не является реляционной таблицей и всякие типа

|   A     |
_______
a1|b1|c1
a2|b2|c2


Со сложными заголовкакми не реляционная.
С нумераций внутренней или явной не реляционная.
Т.е.

A | B | C
---------
a1|b1|c1
a2|b2|c2
и
A | B | C
---------
a2|b2|c2
a1|b1|c1
Не различимы. Так отношение не упорядоченно.

Из-за этого они совсем не то же что вложенные таблы
29 янв 07, 15:39    [3708215]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
мод
mir
вы найдете операцию сравнения элементов x=y.

Это не сравнение элементов (сами то читали ?)
Верно, это не сравнение элементов. Это сравнение множества. Но главное, что операция сравнения существует. Не вижу, что вам мешает сделать шаг и сравнить любые два элемента x и y следующим образом:
x = y <-> {x} = {y}
мод
mir
Почитайте хоть вот эту статью, особенно в части «Очень формальное определение».

Обычное определение функции как отображения (сами то читали ?)
Ффу-у. Читаем вместе по складам: Отображение множества X в множество Y есть подмножество F < X x Y (где < есть символ подмножества, а x -- произведения). А что такое у нас подмножество декартова произведения множеств? Правильно, отношение. Таким образом, функция как отображение есть частный случай отношения (с доп. ограничениями). Точка.

А теперь вспомним ваше "Отображение - это функция, а отношение - множество - это что, одно и то же?" Получили ответ: не всякое отношение -- функция, но всякая функция -- отношение. Первый курс матанализа.

мод
mir
О чем я и говорил, массивы в ЯП — это самый низкий уровень, уровень реализации. Ниже только «ячейки».

Не те вы книжки читаете.
Конечно, книжки Вирта, Ульмана — отстой. Мнение мод’а — истина.
мод
mir
И почему вы, интересно, считаете, что множество реализовать нельзя?

Хотя бы из-за бесконечности - сравните с таблицами-функциями.
Как все запущено-то. А вы не думали, что и множества бывают конечные, и функции бесконечные?
Кроме того, если вспомнить, что функции в итоге есть отношения, то ваша фраза вообще теряет всякий смысл.
29 янв 07, 15:39    [3708216]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
мод
mir
Все просто. "Реляционная таблица" -- это SQL-таблица, которая является отношением.
По вашим же словам SQL-таблица не отношение, иначе она была-бы R таблицей. И вы приводили отличия SQL-таблиц от отношений (повтор строк, null и т.д.). Или вы называете реляционной таблицу без повторов, null ? А сортировка всегда дает не реляционную таблицу ?
Нет, у вас определенно проблемы с чтением. Я нигде не писал, что SQL-таблица -- не отношение. Я писал, цитирую, что SQL-таблица может не быть отношением. Слово "может" приметили? Еще раз прочитайте. И вот SQL-таблица, которая является отношением, и может быть названа R-таблицей (реляционной таблицей).
29 янв 07, 15:47    [3708268]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
[quot vadiminfo]Наличие заголовка, т.е. табла
Со сложными заголовкакми не реляционная.
С нумераций внутренней или явной не реляционная.[\quot]
Т.е. таблицы Oracle и всех других СУБД не реляционны, т.к.
1. не содержат заголовков (только в метаданных)
2. могут иметь сложные заголовки
3. всегда имеют внутренний номер строки
Впрочем, я согласен - вопрос схоластический. Не важно какие таблицы, главное, что таблицы, а не отношения.
29 янв 07, 16:05    [3708460]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
mir
И вот SQL-таблица, которая является отношением, и может быть названа R-таблицей (реляционной таблицей).

Разные термины должны называть разные понятия, а вас все в кучу, четкости нет, увы.
29 янв 07, 16:10    [3708502]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
mir
Таким образом, функция как отображение есть частный случай отношения (с доп. ограничениями).

Согласен, только что это меняет. СУБД работают не с любыми отношениями, а только с таблицами-функциями. Именно поэтому допускаются одинаковые строки и nullы.
mir
вы не думали, что и множества бывают конечные, и функции бесконечные?

Бывают конечно, но в БД мы храним функции с конечной областью определения на бесконечных в общем случае множествах.
29 янв 07, 16:36    [3708752]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
okdoky
Member

Откуда:
Сообщений: 349
мод
mir
Таким образом, функция как отображение есть частный случай отношения (с доп. ограничениями).

Согласен, только что это меняет. СУБД работают не с любыми отношениями, а только с таблицами-функциями. Именно поэтому допускаются одинаковые строки и nullы.
mir
вы не думали, что и множества бывают конечные, и функции бесконечные?

Бывают конечно, но в БД мы храним функции с конечной областью определения на бесконечных в общем случае множествах.
Вы же согласились, что функция только частный случай отношения. Функцию можно представить отношением и даже таблицей. Но если в БД мы храним таблицы, это не значит что мы храним там функции... Кстати любую таблицу (с нулями, с повторяющимися строками) можно преобразовать в отношение.
29 янв 07, 18:02    [3709462]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
мод
mir
И вот SQL-таблица, которая является отношением, и может быть названа R-таблицей (реляционной таблицей).

Разные термины должны называть разные понятия, а вас все в кучу, четкости нет, увы.
У кого "у вас"?
мод
mir
Таким образом, функция как отображение есть частный случай отношения (с доп. ограничениями).

Согласен, только что это меняет.
Это не меняет ничего. Как были ваши исходные определения и рассуждения (про таблицы и функции) неверными, так и остались. Хорошо, что вы это поняли.
мод
СУБД работают не с любыми отношениями, а только с таблицами-функциями. Именно поэтому допускаются одинаковые строки и nullы.
Это очередные выдумки? Ссылку на источник такой интересной информации можно?
мод
mir
вы не думали, что и множества бывают конечные, и функции бесконечные?
Бывают конечно, но в БД мы храним функции с конечной областью определения на бесконечных в общем случае множествах.
Еще раз вернемся к вашему увлекательному утверждению: функцию-де реализовать можно, а множество нет. Вы продолжаете настаивать или хватит позориться?
30 янв 07, 07:29    [3710656]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
мод

1. не содержат заголовков (только в метаданных)
2. могут иметь сложные заголовки
3. всегда имеют внутренний номер строки
Впрочем, я согласен - вопрос схоластический. Не важно какие таблицы, главное, что таблицы, а не отношения.

1 заголовки содержат - любой запрос выполните к примеру. Описание данных и может быть только в методанных, а где же еще? Данные это знаки - значения всякие сосбсно.
2 Опять выполните запрос. Сложные заголовки это типа
   | D
---------
A | B | C
---------
a1|b1|c1
a2|b2|c2

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

3 не имеет. По крайней мере сто пудово не всегда. Имеется в виду на логическом уровне. Если вы создадтие поле - не в всчет - это просто данные такие. Важно что опять при манипулировании, в отличии от вложенных таблов, ими пользоваться не получится навигационно, т.е. типа MOVE FIRST и т.д.. Конечно, есть в Оракле, к примеру, аналитические ф-ии, котрые при сортировках, внутри секций (групп) пронумеруют Вам все что хотите. Ну так и сортировка - это поготовка отчетов, которые не обязаны быть реляционными таблами. Р таблы не шедевры для окончательных отчетов, они заточены участвовать в алгеброических операциях.
А так если Вы просто выполните запрос сегодня и завтрва, то строка которая была "первая", к примеру, на экране сегодя, завтра может оказать "десятой". Уж не говоря о разных средах Например, запрос в локальный и удаленный без указания на экране отобразить
И уж сто пудово никак де поддерживается какая запись была введена раньше, какая позже. Если это имеет значение - это забота разработчика. А в иерархических это не так.
30 янв 07, 08:58    [3710809]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
okdoky
Вы же согласились, что функция только частный случай отношения.

На этот счет нет единого мнения (и ведь не спроста !):
okdoky
Некоторые авторы считают функцию основным понятием, то есть в определении не нуждающимся

okdoky
Но если в БД мы храним таблицы, это не значит что мы храним там функции...

Но таблица это и есть функция (или уж определите формально что это такое).
okdoky
Кстати любую таблицу (с нулями, с повторяющимися строками) можно преобразовать в отношение.

В отношении не м.б. повторящихся кортежей, а вот в таблице разные номера строк могут отображаться в один и тот же кортеж - отсюда и повторение (и не надо ничего преобразовывать).
30 янв 07, 09:17    [3710876]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
mir
Еще раз вернемся к вашему увлекательному утверждению: функцию-де реализовать можно, а множество нет. Вы продолжаете настаивать или хватит позориться?

Это не я настаиваю, а позорные разработчики СУБД. Или вы где то видели реализованные множества (не функции) ?.
30 янв 07, 09:22    [3710898]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
vadiminfo
По крайней мере сто пудово не всегда. Имеется в виду на логическом уровне.

Именно всегда и именно на логическом уровне - от dbf до оракла. Иначе просто невозможно работать с таблицей. Например update ... current of. У строки таблицы - неважно базовой или виртуальной всегда есть номер. Вы можете его не использовать, но СУБД будет его использовать.
В сетевых СУБД этот номер используется явно для связи таблиц, в иерархических неявно для тех же целей, в реляционных используется ограниченно (пока).
30 янв 07, 09:35    [3710956]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
okdoky
Member

Откуда:
Сообщений: 349
mod: Похоже Вы думаете о чем-то о своем. Дайте тогда более развернутое описание своего понимания, прежде всего таблицы как функции (или ссылку на него). Пользователь обычно смотрит на БД (на ее содержимое) как на множество отношений. Конечно для него важно как они отображаются, но совершенно не интересует внутренняя организация. Возможно вы пытаетесь смотреть на БД с какой-то другой стороны? Что это дает?
30 янв 07, 10:11    [3711143]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
мод
vadiminfo
По крайней мере сто пудово не всегда. Имеется в виду на логическом уровне.

Именно всегда и именно на логическом уровне - от dbf до оракла. Иначе просто невозможно работать с таблицей. Например update ... current of. У строки таблицы - неважно базовой или виртуальной всегда есть номер. Вы можете его не использовать, но СУБД будет его использовать.
В сетевых СУБД этот номер используется явно для связи таблиц, в иерархических неявно для тех же целей, в реляционных используется ограниченно (пока).


WHERE CURRENT OF cursor_name

Refers to the latest row processed by the FETCH statement associated with the cursor identified by cursor_name. The cursor must be FOR UPDATE and must be open and positioned on a row. If the cursor is not open, the CURRENT OF clause causes an error.

Это "номер" не в таблице, а в курсоре. Т.е. это механизм работы в PL/SQL, облегчающий изменение последней выбранной из курсора строки. В курсорах (указатель на набор записей в памяти), коллекциях тем более есть навигация. А вот сам набор получается из таблиц без использования номеров.
Т.е. номер в таблице пока не нужен. В курсорах есть порядок, есть хождение по порядку от первой к последней. Так что Ваш пример про обработку результатов полученных реляционным путем в не реляционных языках. Т.е. без дальнейших уточнений не может быть принят в качесте необходимомти номеров в таблицах РБД в реляционном языке для доступа к данным. В других языках - да нужен, наверное.
30 янв 07, 10:44    [3711373]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
vadiminfo

WHERE CURRENT OF cursor_name
Это "номер" не в таблице, а в курсоре.

А как по номеру в курсоре найти строку таблицы ? Только по rowid. И forms работает по rowid. И вообще вы не сможете обновлять таблицу с повторениями строк без этого номера.
vadiminfo

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

Для меня все СУБД (всех типов и видов) работают только с таблицами. Таблица это одномерный массив строк, т.е. функция от целочисленного аргумента во множестве кортежей. Это позволяет однозначно идентифицировать строку независимо от ее содержания, тем самым становится возможным использовать явные и неявные ссылки между таблицами, т.е строить разные МД внутри одной БД. Согласен, что это субъективный взгляд, но имхо он адекватен реальному состоянию дел в СУБД.
30 янв 07, 11:22    [3711701]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
мод
vadiminfo

WHERE CURRENT OF cursor_name
Это "номер" не в таблице, а в курсоре.

А как по номеру в курсоре найти строку таблицы ? Только по rowid. И forms работает по rowid. И вообще вы не сможете обновлять таблицу с повторениями строк без этого номера.

В связи с тем, что это проблемы СУБД, я думаю, все еще что проблемы физического уровеня. Вот када проггер с помщью MOVE по номерам переходил - это на логическом. А в данном случае для прогера WHERE и условие. А как там ищет СУБД нужную запись - ее дело.

vadiminfo

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

Для меня все СУБД (всех типов и видов) работают только с таблицами. Таблица это одномерный массив строк, т.е. функция от целочисленного аргумента во множестве кортежей. Это позволяет однозначно идентифицировать строку независимо от ее содержания, тем самым становится возможным использовать явные и неявные ссылки между таблицами, т.е строить разные МД внутри одной БД. Согласен, что это субъективный взгляд, но имхо он адекватен реальному состоянию дел в СУБД.[/quot]
Странный у Вас взгляд. Он не распространен. В иерахических в связи со структурой упоминаются не таблицы, а типы записей. У таблы должны быть строки и заголовки, по крайней мере, у реляционной. И все. Так их должен, по крайней мере проггер, проектировщик БД мыслить. Физическое - к админам.
Массив - индексированное множество. Т.е. там явно или не явно присутсвует индексное множество и отображение, которая ставит в соответствие индексу элемент множества.
Там присутствует как правило перемещение по от элемента к элементу с помощью индексов. MOVE или типа. Я счас как раз с OLAP DML от Оракла парюсь. Вот тут конкретно массивы. - Т.е. измерения предлагается мыслить как массивы. А про таблы никаких таких рекомендаций не поступало.
И какой их смысл таблицами называть? Их и изображают то часто не в виде таблов - т.е. не мыслят как таблы.
Что касается самого СУБД, т.е. как они реализуют на физ уровне. То там конечно навигация.
Блоки она считывает с диска. Ну так пока компы устроены.
30 янв 07, 11:55    [3711959]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
2 мод
По прежднему жду ссылку на источник такой вот вашей фразы:
мод
СУБД работают не с любыми отношениями, а только с таблицами-функциями. Именно поэтому допускаются одинаковые строки и nullы.
Или честно признайте, что это ваша выдумка.
мод
mir
Еще раз вернемся к вашему увлекательному утверждению: функцию-де реализовать можно, а множество нет. Вы продолжаете настаивать или хватит позориться?
Это не я настаиваю, а позорные разработчики СУБД.
В доказательство приведите пожалуйства ссылку на соответствующее мнение хотя бы одного разработчика СУБД ("функцию реализовать можно, а множество нет"). Или честно признайте, что это ваша выдумка.
мод
Или вы где то видели реализованные множества (не функции) ?.
Практически везде.
мод
У строки таблицы - неважно базовой или виртуальной всегда есть номер
Ссылку на источник. Или честно признайте, что это ваша выдумка.
мод
В сетевых СУБД этот номер используется явно для связи таблиц, в иерархических неявно для тех же целей, в реляционных используется ограниченно (пока).
Ссылку на источник. Или честно признайте, что это ваша выдумка.
мод
Для меня все СУБД (всех типов и видов) работают только с таблицами. Таблица это одномерный массив строк, т.е. функция от целочисленного аргумента во множестве кортежей. Это позволяет однозначно идентифицировать строку независимо от ее содержания, тем самым становится возможным использовать явные и неявные ссылки между таблицами, т.е строить разные МД внутри одной БД. Согласен, что это субъективный взгляд, но имхо он адекватен реальному состоянию дел в СУБД.
Отборный бред. Ни единое утверждение не обосновано. И, замечу, ни единое не соответствует истине.

Самое главное, по прежнему вы путаете логический и физический уровни представления. Используете термин "таблица" одновременно в разных смыслах. Пора бы навести порядок в мыслях. Если способны.
30 янв 07, 12:06    [3712055]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Т.е. конечно переменны как массив, а измерения типа индексы этих массивов
30 янв 07, 12:06    [3712061]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
vadiminfo

Вот када проггер с помщью MOVE по номерам переходил - это на логическом. А в данном случае для прогера WHERE и условие.

в чем проблема:
where rowid='abcd'
vadiminfo

В иерахических в связи со структурой упоминаются не таблицы, а типы записей.

А еще есть сегменты, файлы, наборы ...терминология понимаешь. А строки и заголовки всегда и везде были и есть.
vadiminfo
Массив - индексированное множество. Т.е. там явно или не явно присутсвует индексное множество и отображение, которая ставит в соответствие индексу элемент множества.

Вообщем да.
vadiminfo
Там присутствует как правило перемещение по от элемента к элементу с помощью индексов.

Необязательно - М - прямой доступ (вычисление функции)
зы я свою позицию изложил, соглашаться, нет, принять к сведению - ваше право. Успехов.
30 янв 07, 12:48    [3712434]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
mir
Или честно признайте, что это ваша выдумка.

не моя - откройте любой dbf
mir

Отборный бред. Ни единое утверждение не обосновано. И, замечу, ни единое не соответствует истине.

И как вы с СУБД только работаете (не понимая базовых принципов) !
mir

Самое главное, по прежнему вы путаете логический и физический уровни представления. Используете термин "таблица" одновременно в разных смыслах. Пора бы навести порядок в мыслях. Если способны.

Вот только про физический уровень не надо - вы не понимаете что это такое. Определение таблицы я вам давал - оно совпадает с учебниками и практикой.
30 янв 07, 12:55    [3712501]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
мод

чем проблема:
where rowid='abcd'

Вы про так СУБД реализовать WHERE CURRENT OF?
Так это проблема разработчика СУБД. У проггера нет проблемы, есть только таблы и курсор в данном случае. Нашел что-то в курсоре, механизм как найти эту запись в БД берет на себя СУБД.
Про номера в табле проггеру ниче не надо. Ведь Вы про нужность номеров говорили.
Вот када массивы или пусть даже курсоры - там про номера мыслить приходится. А в таблах пока еще не нужно.


мод

А еще есть сегменты, файлы, наборы ...терминология понимаешь. А строки и заголовки всегда и везде были и есть.

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


мод
Там присутствует как правило перемещение по от элемента к элементу с помощью индексов.

Необязательно - М - прямой доступ (вычисление функции)
Детали. Я Move в широком смысле употребил, включая и этот случай - ведь речь шла о номнрах и доступа по ним. Т.е. за Move скрывался доступ по номерам.
30 янв 07, 13:31    [3712819]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
vadiminfo
Про номера в табле проггеру ниче не надо. Ведь Вы про нужность номеров говорили.Вот када массивы или пусть даже курсоры - там про номера мыслить приходится. А в таблах пока еще не нужно.

Из вашего выступления я понял, что эта возможность вам не нужна, а вот другим может понадобиться. Многие возможности СУБД нужны не всем и в этом ничего страшного нет. Успехов.
30 янв 07, 13:58    [3713137]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
мод

Из вашего выступления я понял, что эта возможность вам не нужна

Не выступления, а ответа на Ваши предположения про вложеннные таблы не отличаются от реляционных.
Мне в РМД нужна РМД. В процедурных языках массивы. И т.е. Т.е. мне все на своем месте. И не тока мне. Иначе бы массивы были в РМД.
30 янв 07, 14:22    [3713402]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
мод
mir
Или честно признайте, что это ваша выдумка.

не моя - откройте любой dbf
Диагноз товарища Саахова подтверждается.
мод
mir
Отборный бред. Ни единое утверждение не обосновано. И, замечу, ни единое не соответствует истине.
И как вы с СУБД только работаете (не понимая базовых принципов)!
И как вы только беретесь рассуждать о СУБД, при этом как путаясь в основах математики, так и не имея представления о способах реализации хранения внутри современных СУБД (рассуждения о непременных целочисленных "номерах строк" и внутренней "табличной" организации хранения всех во до единой СУБД). Отсылка к dbf как к главному аргументу особенно впечатлила. Товарищ, похоже, не слыхал ни о B-деревьях, ни о модели TransRelational, ни о хранении "по столбцам" в Sybase IQ... Одни, понимаешь, таблицы у всех унутри, в виде массивов. Как будто с пальмы спустился, чесс-слово...
мод
mir
Самое главное, по прежнему вы путаете логический и физический уровни представления. Используете термин "таблица" одновременно в разных смыслах. Пора бы навести порядок в мыслях. Если способны.
Вот только про физический уровень не надо - вы не понимаете что это такое. Определение таблицы я вам давал - оно совпадает с учебниками и практикой.
Только что-то ни одно ваше определение, которые вы на ходу сочиняете с многочисленными ляпами, вы не подкрепили самой завалящей ссылкой или цитаткой. Многочисленные просьбы привести таковые пока без ответа. Как говорится, слив защитан. Так что слова "совпадает с учебниками" -- просто сотрясение воздуха.
30 янв 07, 14:42    [3713608]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
mir
Как говорится, слив защитан.

Если для вас это главная цель обсуждения - да на здоровье. Вы к сожалению не умеете слушать оппонентов и это уже давно замечено. Успехов.
30 янв 07, 15:59    [3714324]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
-dead rowid-
Guest
мод
Таблица это одномерный массив строк, т.е. функция от целочисленного аргумента во множестве кортежей. Это позволяет однозначно идентифицировать строку независимо от ее содержания, тем самым становится возможным использовать явные и неявные ссылки между таблицами, т.е строить разные МД внутри одной БД. Согласен, что это субъективный взгляд, но имхо он адекватен реальному состоянию дел в СУБД.

проблема в том, что значения типа ROWID, как правило, не выживают (т.е. изменяются) при backup/restore.
30 янв 07, 18:56    [3715729]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
-dead rowid-
проблема в том, что значения типа ROWID, как правило, не выживают (т.е. изменяются) при backup/restore.

Это действительно проблема, но оракле уже добился неизменности ROWID при любых обновлениях строк, осталось только решить ее для backup/restore (правда это не просто).
31 янв 07, 10:18    [3717389]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
мод
оракле уже добился неизменности ROWID при любых обновлениях строк


А можно ссылочку на эту шокирующую новость ?

А то может я чего-то проспал, например ROWID в IOT или в партиционированной таблице очень даже легко меняется при банальном UPDATE.

ROWID в кластерных таблицах это вообще отдельный разговор.....

Я конечно в физическом уровне мало что смыслю, в dbf файлах реляционной теории не ищу, не заглядываю даже, но всё-таки интересно :-)

Если вы специалист по какому-нибудь MUMPS-у, CACHE, Pick-у, а Oracle\MSSQL видели только что бы убедится что "SQL бесполезен для доступа к данным" (с) ЧАЛ, тогда вопрос снят.
31 янв 07, 10:43    [3717615]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
Andreww
А то может я чего-то проспал, например ROWID в IOT или в партиционированной таблице очень даже легко меняется при банальном UPDATE.

Может быть я и не прав, не буду спорить - для меня это пока не принципиально.
31 янв 07, 13:49    [3719227]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
мод
mir
Как говорится, слив защитан.

Если для вас это главная цель обсуждения - да на здоровье. Вы к сожалению не умеете слушать оппонентов и это уже давно замечено. Успехов.
Да на этом форуме полным-полно людей, которых я слушаю и молча пытаюсь учиться. Здесь есть приличные математики. Здесь есть живые разработчики современных СУБД (по крайней мере, Firebird, Линтер, MS SQL Server). Это вы им как мега-эсперт порассказывайте, как в СУБД внутри реализовано хранение данных. Про непременные целочисленные номера строк. Про то, что там все сделано на таблицах в виде массивов. И что dbf -- прям-таки эталон формата хранения БД. Это будет шоу "весь вечер на арене цирка -- веселые клоуны".

Я не умею вас слушать? А что, позвольте вас спросить, вы можете ценного поведать? В основах математики разбираетесь крайне слабо. Знания деталей реалиции СУБД -- на уровне dbf, что есть практически каменный век. И при этом на ходу плодите какие-то диковинные на взгляд специалиста утверждения вроде "множества реализовать нельзя", причем без единого аргумента. Классической литературы по структурам данных и технологиям баз данных, похоже, не читали.

Да я не слушать вас пытался, а немножно знаний поприбавить, как преподаватель.

А по поводу умения слушать оппонентов... Не припомните, кого это я дважды (!) отсылал к своему развернутому сообщению, и кто каждый раз ухитрялся пропустить или перековеркать его смысл?

P.S. Если у кого-то создалось впечатление, что я-де обиделся и в обиде строчу этот ответ, это не так. Пишу я его вполне лениво и даже где-то с улыбкой.
31 янв 07, 14:26    [3719531]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
Andreww


'Changing' rowids
Although a rowid uniquely identifies a row in a table, it might change its value if the underlying table is an index organized table or a partitioned table. Also, rowids change if a table is exported and imported using EXP/IMP. This implies that rowids should not be stored away for later re-use as the corresponding row then might either not exist or contain completely different

Такая вот недоработка :)
31 янв 07, 14:29    [3719562]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
чалик
Guest
SQL действительно бесполезен. Два популярных "инструмента" активно используются людьми, далекими от баз данных: SQL и Excel.
Мы уже обсуждали тему "немодельных вычислений", в свое время. В "Р"СУБД не только "суммирование по колонке" (и др. "агрегирующие функции"), но и соединения являются немодельными вычислениями (если считать, что в БД, как об этом говорили Кодд и Дейт, хранится информация о сущностях и связях между ними). Если Человек-Занимает-Должность, то в результате "запроса" Человек-Занимает-Должность, по-прежнему. То есть "результату запроса", как части БД, должна быть присуща та же семантика (сущности и связи между ними), что и самой БД. Да, "результат запроса" можно представить в виде ОДНОЙ таблицы, при необходимости. Но "запрос" в ОСУБД не искажает информацию, а в "Р"СУБД неизбежно искажает (кроме того, из РБД вообще нельзя извлечь никакой информации без этого самого "запроса", то есть без программиста, который придет, исказит, неизбежно, информацию, а потом для исправления этой глупости еще что-то вынужденно запрограммирует), представляя "результат" в виде отношения с неизбежной необходимостью интерпретации (то есть складывая апельсины с автомобилями).
"Ключи" в "Р"СУБД призваны были снивелировать ущерб от "алгебры", и хоть как-то связать сущности (пусть и лишив БД идентификации, навигации, семантики). Но "алгебра" взяла свое. РМД так и осталась нереализованной, а "Р"СУБД неизбежно приближаются к дореляционным ОСУБД во всех отношениях, но тормоз в виде бесполезного для БД SQL, никогда не даст им превратиться в системы управления базами данных. Они так и останутся электронными таблицами с "развитой системой доступа" (обогнали Excel, молодцы!).
5 фев 07, 21:15    [3742060]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Видимо, в дурдоме травят тараканов и больных временно отпустили.
6 фев 07, 06:15    [3742479]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
чалик
если считать, что в БД хранится информация о сущностях и связях между ними

А не надо так считать. В БД (любой) хранится часть модели предметной области. В связи с этим остальные рассуждения не имеют смысла.
6 фев 07, 09:35    [3742831]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
автор
В БД (любой) хранится часть модели предметной области.


Можно даже уточнить, что хранятся ФАКТЫ модели предметной области, а задача БД предоставить аппарат для манипуляции этими фактами.

Когда начинают "хранить" связи,объекты и т.п. получается фуфел.
6 фев 07, 10:07    [3743000]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
чалик
SQL действительно бесполезен. Два популярных "инструмента" активно используются людьми, далекими от баз данных: SQL и Excel.
Да это просто чудотворцы какие-то. Находясь вдалеке и пользуясь бесполезным - и делают работающие системы. А если им дать реальный отбойный молоток...
6 фев 07, 12:22    [3743993]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
чалик
SQL действительно бесполезен.

Вы думаете?

чалик

Два популярных "инструмента" активно используются людьми, далекими от баз данных: SQL и Excel.

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

чалик

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

Соединения выкинули из алгебры РМД? Когда это произошло?

чалик

Если Человек-Занимает-Должность, то в результате "запроса" Человек-Занимает-Должность, по-прежнему.

А должен был перестать ее занимать в результате запроса?

чалик

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

Искажает? Спасибо Вам, что хоть не теряет.

чалик


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

Когда произошел призыв? Раньше у них было другое назначение. И када вдруг у алгебры был обнаружен ущерб? До сих пор считалось наоборот. У математики в целом ущерб когда планируется снивилировать?

чалик

Но "алгебра" взяла свое. РМД так и осталась нереализованной, а "Р"СУБД неизбежно приближаются к дореляционным ОСУБД во всех отношениях, но тормоз в виде бесполезного для БД SQL, никогда не даст им превратиться в системы управления базами данных. Они так и останутся электронными таблицами с "развитой системой доступа" (обогнали Excel, молодцы!).

Не только Йксель. Дореляционною ОМД вмсте с Мумпсом и проч продукты для БД 60-х тоже.
7 фев 07, 10:31    [3748236]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
laafrb
Member

Откуда:
Сообщений: 31
чалик
...


какую траву куришь?
7 фев 07, 15:03    [3750556]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2 3 4 5 6 7 8      [все]
Все форумы / Сравнение СУБД Ответить