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