на главнуюВсе эхи RU.ALGORITHMS
войти ?

О представлении графа в базе данных

От Kalachihin Vladimir (2:5095/1.39) к Alex Mizrahi

В ответ на Заголовок предыдущего сообщения в треде (Имя Автора)


Приветствую тебя, Alex!

Replying to a message of Alex Mizrahi to Kalachihin Vladimir:

Я знал, я знал!!!

AM> Hу тут неплохо вспомнить определение

Hу я, как бы, помню...

AM> Hа практике неориентированные графы можно считать частным случаем
AM> ориентированных: если граф G неориентированный, то для каждого ребра
AM> A->B существует также и ребро B->A.

А вот это никак нельзя считать. Поскольку в неориентированном графе отсутствует ребро A->B. Там есть только A-B. Или, если хочешь, A<->B.

AM> Как ты правильно заметил, ориентированный граф соответствует некоему
AM> отношению, т.к. отношение как раз и есть множество упорядоченных пар.
AM> Тогда неориентированный граф можно сопоставить симметричному
AM> отношению, т.е. такому отношению, в котором наличие пары <A,B>
AM> означает тажке и наличие <B,A>.

KV>> Более того, представление ненаправленного графа становится вообще
KV>> невозможным,

AM> А если подумать -- возможным.

Гы. Как? В свете через абзац выше процитированного?
Hа всякий случай напомню - в теории реляционных баз данных нет встроенных процедур ;-)

KV>> Поэтому на практике отношение Предок, Потомок вида A,B рассматривают
KV>> либо как "Объект A, имеющий потомка B", либо как "Объект B, имеющий
KV>> предка A".

AM> Hу это ты уже в какую-то не ту степь ушёл. В теории графов нет
AM> объектов, предков и потомков. Есть вершины и рёбра/дуги.

Я тут плавно перешёл от теории графов к их представлению в реляционной форме. А если слово "объект" вызывает у тебя нехорошие аллюзии - замени его словом "сущность".

KV>> Так вопрос - а как правильно?
AM> Честно говоря, не вижу разницы.

Ото-ж. А я - вижу:

KV>> Моя практика показывает, что представлять
KV>> узлы дерева, как объекты, имеющие предка - радикально удобней, чем
KV>> как объекты, имеющие потомка. В одной известной мне предметной
KV>> области, которая точно никогда не заморачивалась такими вопросами,
KV>> все связи строятся именно как указание предка, а не потомка.

AM> Тут неплохо бы привести пример, честно говоря не понимаю о чём ты...

Hу вот если мы рассмативаем представление связи между двумя объектами (пардон, сущностями...) в виде атрибутов - указателей на потомков, то, скажем, визуализация такой связи не может быть независимой для каждого атрибута, а касается всей кучи таких атрибутов сразу. А именно: в случае изображения свёрнутой ветви дерева для первого потомка надо нарисовать плюсик, а для всех остальных - ничего. А в случае изображения развёрнутой - для каждого атрибута рисовать что положено. В некоторых случаях такая зависимость аннойна, а в других - недопустима.
В случае же, если связь представлена указанием на предка - таких трудностей нет, и что рисовать - целиком проблема, локализованная в одном атрибуте.



Калачихин Владимир.

--- FleetStreet 1.22+
* Origin: Stager's station, aka stagerATau.ru (2:5095/1.39)

Ответы на это письмо:

From: Username
Заголовок следующего сообщения в треде может быть длинным и его придется перенести на новую строку

From: Username
Или коротким

FGHI-url этого письма: area://RU.ALGORITHMS?msgid=2:5095/1.39+4c770c8f