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

Откуда:
Сообщений: 3573
c127
Какие дополнительные характеристики (или ограничения) придают графу раскрашенные ребра? Можно ходить по ребрам одного цвета или как?

попробую "домыслить" за аффтара. (не с целью поумничать, но дабы отвечая он такоже спутно поправил мою непраильную картинку).

я думаю, что цвет - это тип отношения (т.е. видимо цвет - это некий идентификатор объедка, в котором описан тип отношения, - тут правда есть проблемы - получается, что есть выделенные объедкты, которые могут быть цветом, а есть те, которые не могут... и вообще тут куча интересного связонного с "ядреными" (непереопределяемыми) объектами (если такие необходимы) и прочими...) - 2shuklin правильно ли я вижу смысл цветов в вашей сети?
1 июл 05, 10:35    [1666083]     Ответить | Цитировать Сообщить модератору
 Re: Cerebrum : Сетевая объектно-ориентированная система управления базой знаний  [new]
4321
Member [заблокирован]

Откуда:
Сообщений: 3573
PS
сам граф, как лехко заметить, ложится в табличку
oid1, oid2, oidColor
(т.е. тренарное отношение)
с первичным ключом
oid1, oid2, oidColor
(отсутствие цвета, если требуется, можно зашить в служебное значение oidColor).

Вообще вся сеть судя по всему тоже несложно размещается в небольшой группе таблиц вполне реляционной СУБД. В чем преимущества афтарсого решения, если языка запросов как я понял еще нет, процедур быстрого поиска видимо тоже????
1 июл 05, 10:42    [1666119]     Ответить | Цитировать Сообщить модератору
 Re: Cerebrum : Сетевая объектно-ориентированная система управления базой знаний  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 4321

Вообще у графа (а сл-но и у сети) есть масса матричных представлений, навскидку :

Матрица инциденций
Матрица смежности
Матрица циклов
Матрица разрезов
Матрица путей

Есть теоремы и алгоритмы для анализа и операций с графами в матричном представлении, которое буквально на раз ложится в любую существующую РСУБД. Апарат неплохо проработан используется уже много лет, но ведь там скуууучно, работать надо много и усердно, формализовать всё чётко, теоремы доказывать и модных слов (ОО,НЕЙРО,СЕМАНТИЧЕСКОЕ) мало.

Не в фаворе сейчас комбинаторная топология, а было бы интересно взять какую-нибудь РСУБД с открытым кодом (благо их сейчас немало) и расширить её языком для операций с графами (TQL какой-нибудь) и основными алгоритмами (для покрытий парасочетаний etc), может получиться вещь пригодная для всяких ГИС,САПР логистики и т.д, но ведь опять работать надо, доооолго и скууучно.
1 июл 05, 11:28    [1666384]     Ответить | Цитировать Сообщить модератору
 Re: Cerebrum : Сетевая объектно-ориентированная система управления базой знаний  [new]
vadiminfo
Member

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

Потому если в Tables (она типа словарь БД), есть описание самой себя, это значит, что она есть строка самой себя. Так как это описание есть тот же самый экземпляр объекта. И таблица Tables и строка Tables в таблице Tables - это один и тот же экземпляр одного и того же класса TableDescriptor и он расположен по одному и тому же адресу в памяти.

Что-то не клеется, если сопоставлять "быть строкой самой себя" с "быть элементом самого себя", чтобы выйти на рассела. Конечно, можно истолковывать смысл "быть строкой" как то по иному, но если в смысле принадлежность самому себе, то если строка Tables есть Tables -> она в свою очередь содержит строку, котороя есть Tables в силу способности Tables содержать в принципе саму себя. Так можно продолжать до бесконечности.
Т.е. Tables содержит в себе что-то не являющееся конечным. Компы, вроде, пока не могут работать ни с чем подобным.
А так как Вы истолковываете "быть строкой" в смысле, что описание экземпляра объекта и сам этот экземпляр одно и тоже, все еще не привычно.
Интесив и Экстенсив дожны же как-то отличаться?
1 июл 05, 12:04    [1666606]     Ответить | Цитировать Сообщить модератору
 Re: Cerebrum : Сетевая объектно-ориентированная система управления базой знаний  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
c127
Как их раскрасить я и сам знаю. Какие дополнительные характеристики (или ограничения) придают графу раскрашенные ребра? Можно ходить по ребрам одного цвета или как?


Можно исспользовать окраску ребер при реализации ваших собственных алгоритмов с использованием СУБЗ Cerebrum.

Я использую раскраску для
- определения типа связи между нейронами (аксон, дендрит)
- определения аттрибута объекта. аттрибуты объекта - тоже полноценные объекты.
1 июл 05, 12:37    [1666816]     Ответить | Цитировать Сообщить модератору
 Re: Cerebrum : Сетевая объектно-ориентированная система управления базой знаний  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
4321
c127
Какие дополнительные характеристики (или ограничения) придают графу раскрашенные ребра? Можно ходить по ребрам одного цвета или как?

попробую "домыслить" за аффтара. (не с целью поумничать, но дабы отвечая он такоже спутно поправил мою непраильную картинку).

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


Да. Правильно.

Дополнение:
Цвет не является объектом, цвет является OID (Int32). Если нужно чтобы цвет являлся объектом, нужно создать некоторый просто-объект и взять его OID в качестве цвета для расскраски ребер.
1 июл 05, 12:39    [1666828]     Ответить | Цитировать Сообщить модератору
 Re: Cerebrum : Сетевая объектно-ориентированная система управления базой знаний  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
4321
PS
сам граф, как лехко заметить, ложится в табличку
oid1, oid2, oidColor
(т.е. тренарное отношение)
с первичным ключом
oid1, oid2, oidColor
(отсутствие цвета, если требуется, можно зашить в служебное значение oidColor).
Вообще вся сеть судя по всему тоже несложно размещается в небольшой группе таблиц вполне реляционной СУБД.

Да, ложиться. см. http://www.microsoft.ru/offext/details.aspx?id=620

4321
В чем преимущества афтарсого решения, если языка запросов как я понял еще нет, процедур быстрого поиска видимо тоже????

В возможности прямой навигации. Как я уже писал, я исспользую только прямую навигацию. Лично мне поиск не интересен.
1 июл 05, 12:42    [1666840]     Ответить | Цитировать Сообщить модератору
 Re: Cerebrum : Сетевая объектно-ориентированная система управления базой знаний  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
Andreww
может получиться вещь пригодная для всяких ГИС,САПР логистики и т.д


Маловероятно. Если взять граф из миллиарда узлов, то матрица получится ...
И ни в какую РБД без доп извращений не поместится. А если применять спец. алгоритмы для работы с разреженными матрицами, то это уже и не РБД.
1 июл 05, 12:44    [1666858]     Ответить | Цитировать Сообщить модератору
 Re: Cerebrum : Сетевая объектно-ориентированная система управления базой знаний  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
vadiminfo

Что-то не клеется, если сопоставлять "быть строкой самой себя" с "быть элементом самого себя", чтобы выйти на рассела. Конечно, можно истолковывать смысл "быть строкой" как то по иному, но если в смысле принадлежность самому себе, то если строка Tables есть Tables -> она в свою очередь содержит строку, котороя есть Tables в силу способности Tables содержать в принципе саму себя. Так можно продолжать до бесконечности.


Да. Можно продолжать до бесконечности.

vadiminfo
Т.е. Tables содержит в себе что-то не являющееся конечным. Компы, вроде, пока не могут работать ни с чем подобным.


Могут. Пролог может выполнять бесконечную рекурсию без переполнения стека, например.

Суть идеи:

class MyClass
{
    public virtual MyClass * get_NextItem()
    {
        return this;
    }
}

vadiminfo
А так как Вы истолковываете "быть строкой" в смысле, что описание экземпляра объекта и сам этот экземпляр одно и тоже, все еще не привычно.
Интесив и Экстенсив дожны же как-то отличаться?


Ну не знаю на счет кому должны и зачем ;). Я сделал так как удобно мне ;)
Грубо, Таблица - это две коллекции указателей на объекты. На колонки и на строки. Если в коллекцию указателей на строки включить указатель на саму таблицу, то таблица станет собственной строкой. Если включть этот указатель в коллекцию колонок - таблица станет собственной колонкой (но этой возможности я не предоставляю из за необходимости переходить с early binding к late binding, если кому-то реально надо - легко сделать).
1 июл 05, 12:52    [1666891]     Ответить | Цитировать Сообщить модератору
 Re: Cerebrum : Сетевая объектно-ориентированная система управления базой знаний  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2405
Блог
shuklin
Маловероятно. Если взять граф из миллиарда узлов, то матрица получится ...
И ни в какую РБД без доп извращений не поместится. А если применять спец. алгоритмы для работы с разреженными матрицами, то это уже и не РБД.
почему? РБД нужна только для хранения, обработки и поддержания целостности данных. С этим она справится, хоть миллиард там узлов хоть триллион. А какие алгоритмы будут работать при обработке этих данных - по барабану.
1 июл 05, 12:55    [1666910]     Ответить | Цитировать Сообщить модератору
 Re: Cerebrum : Сетевая объектно-ориентированная система управления базой знаний  [new]
shuklin
Member

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


Если отказаться от прямого отображения матрицы на таблицу - согласен. Но тогда затраты на JOIN + на хранения рабочей копии могут съесть все достоинства. Спорный вопрос что будет эффективнее. Это только реализация приложения покажет на сколько такой подход оправдан.
1 июл 05, 16:32    [1668278]     Ответить | Цитировать Сообщить модератору
 Re: Cerebrum : Сетевая объектно-ориентированная система управления базой знаний  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
С одной стороны :

>>Если взять граф из миллиарда узлов, то матрица получится ...
И ни в какую РБД без доп извращений не поместится. А если применять спец. алгоритмы для работы с разреженными матрицами, то это уже и не РБД.

С другой :

>>Таблица - это две коллекции указателей на объекты. На колонки и на строки. Если в коллекцию указателей на строки включить указатель на саму таблицу, то таблица станет собственной строкой. Если включть этот указатель в коллекцию колонок - таблица станет собственной колонкой

Коллекция весьма размытое понятие. Для нормальной производительности нужно эту коллекцию особым образом адресовать (читай хранить на диске), через ИНДЕКСЫ, ХЭШ-СПИСКИ или ещё как. При этом не забывать про то, что ещё может понадобиться её редактировать, ещё и в многозадачной среде и.... понеслась. Из расплывчатой фразы "Таблица - это две коллекции указателей на объекты" не понятно чем эти коллекции лучше чем heap-organized tables. Прямой адресацией ? Совсем не очевидно почему в коллекцию можно положить миллиард вершин графа, а в таблицу нет. Расскажите подробнее.

>>Если отказаться от прямого отображения матрицы на таблицу - согласен. Но тогда затраты на JOIN + на хранения рабочей копии могут съесть все достоинства. Спорный вопрос что будет эффективнее.

Согласен полностью. Хорошая тема для исследования. Можно было бы выяснить, нужны ли специальные БД для хранения и операций с графами или имеющихся СУБД хватает "с головой".
1 июл 05, 17:02    [1668488]     Ответить | Цитировать Сообщить модератору
 Re: Cerebrum : Сетевая объектно-ориентированная система управления базой знаний  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
Andreww
Коллекция весьма размытое понятие. Для нормальной производительности нужно эту коллекцию особым образом адресовать (читай хранить на диске), через ИНДЕКСЫ, ХЭШ-СПИСКИ или ещё как. При этом не забывать про то, что ещё может понадобиться её редактировать, ещё и в многозадачной среде и.... понеслась. Из расплывчатой фразы "Таблица - это две коллекции указателей на объекты" не понятно чем эти коллекции лучше чем heap-organized tables. Прямой адресацией ? Совсем не очевидно почему в коллекцию можно положить миллиард вершин графа, а в таблицу нет. Расскажите подробнее.


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

Теперь про cerebrum.

Я тоже применяю мягкие OID. в одном handle space одному OID всегда соответствует один и тот же объект. На протяжении жизни объекта этот OID не изменяется. Тип данных для OID - Cerebrum.Runtime.NativeHandle. Размер OID - 32 бита. Поиск объекта в индексе по его OID происходит в три этапа. 32 бита разбиваются на 12, 12 и 8 бит. по этим значением построено 3х уровневое дерево.

Коллекции объектов организованы на основании того же механизма. Коллекция представляет собой такой же индекс 12-12-8 который производит MAP одного OID на другой OID. Для доступа к объекту первым этапом производится восстановление OID объекта по его индексу в коллекции (это 3 операции поиска в дереве). Вторым этапом производится восстановление указателя на объект по его OID (такие же 3 операции по аналогичному но другому дереву). В итоге, для доступа к строке таблицы надо выполнить 6 операций. В зависимости от размера cache и текущего его заполнения возможно некоторые листья этих деревьев потребуют загрузки из файлового хранилища.

Эти таблицы ничем не лучше РБД таблиц. Они введены для удобства и в качестве примера исспользования ООСУБД Cerebrum. В некоторых случаях, которые не требуют большой производительности их можно исспользовать совместно с обычными объектами ООСУБД. Так как каждая строка таблицы является экземпляром объекта и имеет свой OID то гораздо эффективнее работать с такими строками методом прямой адресации (3 операции доступа к дереву).
1 июл 05, 19:06    [1668943]     Ответить | Цитировать Сообщить модератору
 Re: Cerebrum : Сетевая объектно-ориентированная система управления базой знаний  [new]
vadiminfo
Member

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

Да. Можно продолжать до бесконечности.

Если учесть, что 20 000 лет еще далеко до бесконечности, то табла Tables так и не была бы построена никогда. Т.е. она бы скорее всего так была и не достроина подобно Вавилонской башне, если бы была свойе строкой в полном смысле.

shuklin

Могут. Пролог может выполнять бесконечную рекурсию без переполнения стека, например.

Комп уже за эти выйдет из строя, а рекурсий все равно будет еще конечное число.

shuklin

Суть идеи:

Мне все еще кажется, что если в этой идее заменить имя метода get_NextItem на get_My_ptr, то будет более точный смысл того. что этот метод может.
Всего лишь возвращать указатель на самого себя. Но указатель на объект и сам этот объект не одно и тоже. Первое всего лишь адрес, а второе, в частности, более сложная конструкция, чем адрес.


Чтобы была элементом самого себя должно быть что-то типа:
{X,{X,{X..................бесконечно...}}}.
Тогда можно было бы ставить вопрос о том, что X является элементом X. Действительно, то что
X принадлежит {X,{X,{X..................бесконечно...}}} видно, а равенство
X = {X,{X,{X..................бесконечно...}}} можно было бы допустить, если бы не известный парадокс рассела.
(Для любого конечного {X,{X,{X...n}}} очевидно не равно {X,{X,{X...n+1}}} - разная мощность.)

Так беспечно обращаться с бесконечными классами нельзя.

Актуальный подход не предполагает рассматривать классы, которые являются элементами самих себя, и не считает их множествами. А если у Вас табла является строкой самой себя, то Вы конструтивист? Хотя не уверен, что и они тут бы согласились с Вами на все 100.

shuklin

Ну не знаю на счет кому должны и зачем ;). Я сделал так как удобно мне ;)

Т.е. Вы в принципе игнрорируете многие догмы и стереотипы, которые присутствуют как минимум в представлениях о БД, и более того, иногда в БЗ.
Там разделение тоже упоминается. Там вообще иногда говорят об интенсиональной базе данных и экстенсиональной. Ну по крайней мере, в отдельных источниках такое есть.
Но некоторые Вы все-таки берете. Например ООБД. Хотя там тоже есть деление - класс относят к первому, а объект ко второму. Впрочем, возможно, они тоже ретрограды.

shuklin

Если в коллекцию указателей на строки включить указатель на саму таблицу, то таблица станет собственной строкой.

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

shuklin

Если включть этот указатель в коллекцию колонок - таблица станет собственной колонкой

А вот я скока не включал, таблица не становилась собственной ни колонкой, ни строкой, а тупила во всю, оставалась все той же большой таблой, которую пришлось в конце концов удалить.
1 июл 05, 20:49    [1669124]     Ответить | Цитировать Сообщить модератору
 Re: Cerebrum : Сетевая объектно-ориентированная система управления базой знаний  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
vadiminfo
Так беспечно обращаться с бесконечными классами нельзя.


Давайте не будем про глубокую теорию. В контексте cerebrum быть строкой некоторой таблицы означает что в аттрибуте этой таблицы SelectedComponents есть указатель (OID) на объект. Согласно этому определению таблица Tables является строкой самой себя. Все. А на революции в теории множеств я не претендую - там аксиоматика другая.


vadiminfo
Т.е. Вы в принципе игнрорируете многие догмы и стереотипы, которые присутствуют как минимум в представлениях о БД, и более того, иногда в БЗ.


Если мне какаято догма мешает написать пару строк кода - разумеется игнорирую. Если помогает - встречаю с радостными объятиями ;)


vadiminfo
А почему же строка не станет всего лишь указателем, точнее не будет всего лишь содержать указатель? При этом не очень даже и важно на что именно, в контексте того о чем мы говорим?


Низя (( У меня не абстрактная модель, а конкретная реализация с конкретными ограничениями by design.

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

Объект вовсе не превратится в таблицу если его добавить строкой в таблицу Tables или в аттрибут, если его добавили в таблицу Attributes. Для того чтобы это имело место этот объект должен реализовать контракт на таблицу или на аттрибут. В данном конкретном случае это означает что объект должен быть экземпляром класса TableDescriptor. Либо, что тоже возможно экземпляром класса, унаследованного от класса TableDescriptor.

Добиться такого поведения возможно, отказавшись от подхода early binding и перейдя к подходу late binding. Я люблю late binding но всегда стараюсь как можно меньше исспользовать его в своих разработках. Без дополнительных оснований превращать Table в Attribute легким движением руки я не стану. Это слишком уж центровые объектв в модуле Cerebrum.Integrator. А вот другие - пажалста, преввращайте сколько пожелаете ; ))



vadiminfo
А вот я скока не включал, таблица не становилась собственной ни колонкой, ни строкой, а тупила во всю, оставалась все той же большой таблой, которую пришлось в конце концов удалить.


Это очень странно. Если у тебя была действительно таблица, то возникает вопрос как ты ее получил? Чтоб создать новый экземпляр класса TableDescriptor необходимо добавить новую строку в таблицу Tables - система сделает за тебя оставшуюся черную работу. Если у тебя была таблица - то ты ее мог получить только добавив стрку в таблицу Tables.

Я могу допустить что ты изменил DefaultTypeId у какой то другой таблицы и добавил сначала TablesDescriptor в таблицу UiServices (к примеру ) тогда опять возвращаемся к исходному тезису, или тот объект который ты мучал не таблица или он строка какой то таблицы.

Что касается возможности рассматривать таблицы как колонки, то в текущей версии cerebrum эта возможность теоретическая (я уже писал об этом). Колонка обязана быть экземпляром класса AttributeDescriptor а в .NET множественное наследование классов не поддерживается. Измениять TableDescriptor & AttributeDescrioptor в интерфейсы я не стану. ;)
1 июл 05, 23:46    [1669340]     Ответить | Цитировать Сообщить модератору
 Re: Cerebrum : Сетевая объектно-ориентированная система управления базой знаний  [new]
vadiminfo
Member

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

Согласно этому определению таблица Tables является строкой самой себя. Все. А на революции в теории множеств я не претендую - там аксиоматика другая.


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

shuklin

Если мне какаято догма мешает написать пару строк кода - разумеется игнорирую. Если помогает - встречаю с радостными объятиями ;)

Вы не боитесь, что в этом много непоследовательного?

shuklin

Низя (( У меня не абстрактная модель, а конкретная реализация с конкретными ограничениями by design.

Это, наверное, Вы какие-то догмы уже отвергаете. Хотя я не понял в каком смысле употреблено "абстракная модель", чего у Вас "конкретная реализация", как они соотносятся, и тем более как это относится к тому, что про ту злосчастною строку нельзя грить истинное ее содержание (OID или указатель или что она там на самом деле содержит)? А надо грить что эта строка есть Табла.

shuklin

Для того чтобы это имело место этот объект должен реализовать контракт на таблицу или на аттрибут.

Что что должен сделать объект? Реализовать контракт?
В какой литре есть про такое? Но смысл этого - прописать этот объект в Tables?
У этой Tables какая-то бОльшая роль в Вашей системе, чем просто данные о данных.


shuklin

Это очень странно. Если у тебя была действительно таблица, то возникает вопрос как ты ее получил?

Как получил? Просто нарисовал на бумаге. Таблица она и есть таблица.



shuklin

Если у тебя была таблица - то ты ее мог получить только добавив стрку в таблицу Tables.



Ну могу в Оракле создать таблицу Tables. И добавлять туда строки. Почему нет? Могу понасоздавать пользовательских типов (классов), объектов. Думаю многое могу повтроить про Tables, что есть в Вашей системе. Но все равно там такими определениями, из которых бы следовало, что табла есть строка самой себя не пользуются.
2 июл 05, 15:59    [1669719]     Ответить | Цитировать Сообщить модератору
 Re: Cerebrum : Сетевая объектно-ориентированная система управления базой знаний  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
Привет, Влад!

vadiminfo
Как получил? Просто нарисовал на бумаге. Таблица она и есть таблица.


Если тебя интересует эта тема, предлагаю, вместо того чтобы тратить на очередное обсуждение со мной абстрактных вопросов теории множеств просто загрузить ООСУБД Cerebrum и полностью пройтись по Streams-01 sample.

Так ты увидишь что есть таблица в Cerebrum. После этого я накидаю Tables-01 sample и ты сможешь разбивать мои идеи не абстрактно а конкретно ;)

Дмитрий.
2 июл 05, 20:49    [1669937]     Ответить | Цитировать Сообщить модератору
 Re: Cerebrum : Сетевая объектно-ориентированная система управления базой знаний  [new]
Андрей Леонидович
Guest
"Строка - это объект". Печально. И мне понятны чувства Мимо пробегал, который уже хорошо знаком с классическим объектным подходом (вплоть до "формул" !)...
Попробуйте представить основные понятия структуры ОМД и РМД с помощью их идентификаторов (имен) в виде иерархии. ОМД:

(ид. объекта) (по shuklin - класса)
:
:
(ид. экземпляра) (по shuklin - объекта)
:
:
(ид. характеристики) (по shuklin - "аттрибута") ->значение характеристики

Как видите, экземпляр - это не "строка". Он может не иметь ни одной характеристики (а не то что не иметь значений характеристик - хотя и этого достаточно). А теперь "аналогия" для РМД:

(имя отношения)
:
:
???
:
:
(имя атрибута)->значение атрибута

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

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

Но не совсем. Andreww: работать придется "доооолго и скууучно."

Так чем Вас MUMPS-то не устроил, уважаемый shuklin ? Решали бы Вы в нем свои задачи быстро и радостно, а не "долго и скучно".

P.S. И у Вас какое-то стойкое заблуждение про ОБД. Навигация в них осуществляется именно "по сети", между экземплярами (по Вашему - объектами), а вовсе не "по дереву внутри класса"...
2 июл 05, 23:14    [1670081]     Ответить | Цитировать Сообщить модератору
 Re: Cerebrum : Сетевая объектно-ориентированная система управления базой знаний  [new]
vadiminfo
Member

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

Если тебя интересует эта тема,

...
ты сможешь разбивать мои идеи не абстрактно а конкретно


Меня интересует безусловно тема, но в первую очередь, в плане СУБЗ, ИИ. Если есть что-то необыкновенное в ООМД тоже конечно интересует или даже МД. Но прежде всего концептуально, т.е. абстагировано по отношению к реализации. Чтобы из-за деревьев был виден лес.
Цели разбить идеи нет, но и сомнения, я считаю, чем-то уместным.



Андрей Леонидович

???

Коллеге ЧАЛу, скорее всего, это стоит отнести и на счет остальных своих знаний про РМД, а, возможно, и ООМД. И не тратить на них силы - их ему лучше потратить на выяснение того, что же все-таки из себя представляет дореляционная ОМД. У нее, судя по всему, много проблем, и отвлекаться от нее значит усугублять ее положение. Попытки же помочь ей свержением преуспевающих МД могут ничего не дать, и она окончательно может деградировать за это время. И так уже ей более 30 лет. А коллега ЧАЛ уже еще один год выбросил без всякой пользы для нее. Или уже где 30 там и 40?
3 июл 05, 01:24    [1670163]     Ответить | Цитировать Сообщить модератору
 Re: Cerebrum : Сетевая объектно-ориентированная система управления базой знаний  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
Андрей Леонидович
"Поэтому" навигация принципиально невозможна.../quot]

И это фатально ; ))

[quot Андрей Леонидович]P.S. И у Вас какое-то стойкое заблуждение про ОБД. Навигация в них осуществляется именно "по сети", между экземплярами (по Вашему - объектами), а вовсе не "по дереву внутри класса"...


Вообщето я про конкретную ООСУБД предполагал. Раз возможно - то и славо богу. В таком случае и ошибиться приятно :) Но что то аппологет той СУБД молчит ... Смутные сомнения меня терзают ;)
3 июл 05, 02:16    [1670168]     Ответить | Цитировать Сообщить модератору
 Re: Cerebrum : Сетевая объектно-ориентированная система управления базой знаний  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
vadiminfo
Меня интересует безусловно тема, но в первую очередь, в плане СУБЗ, ИИ. Если есть что-то необыкновенное в ООМД тоже конечно интересует или даже МД. Но прежде всего концептуально, т.е. абстагировано по отношению к реализации. Чтобы из-за деревьев был виден лес.
Цели разбить идеи нет, но и сомнения, я считаю, чем-то уместным.


Тут мы сталкиваемся с аксиоматикой. Вы считаете что часть может быть только по ByVal а я считаю что объекты могут быть частью друг друга и по ByRef в противном случае придется говорить не о коллекции объектов а об коллекции ссылок на объекты и т.п.

Далее, думаю, что по крайней мере в некоторых РБД таблицы реализованы как коллекции указателей на строки. Что теперь отказать этим РБД в том что таблицы содержат строки?

Предлагаю в контексте Cerebrum считать что включение одного объекта в другой по ByRef означает именно включение, и по умолчанию считать что все объекты включаются друг в друга по ByRef в противном случае требуется особое замечание на предмет ByVal.

У случае с Cerebrum все включения производятся по ByRef. Только сериализацию объектов можно считать ByVal да и то много вопросов.

В плане СУБЗ или ИИ Cerebrum на данный момент не выходит за границы опубликованных статьей на тему СНС. Планы есть, но ведь планы не продемонстрируешь в рабочем коде )) На ИИ позже будем посмотреть )) Тут бы с транзакциями и версионингом управиться ...
3 июл 05, 02:33    [1670174]     Ответить | Цитировать Сообщить модератору
 Re: Cerebrum : Сетевая объектно-ориентированная система управления базой знаний  [new]
vadiminfo
Member

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

Вы считаете что часть может быть только по ByVal а я считаю что объекты могут быть частью друг друга и по ByRef в противном случае придется говорить не о коллекции объектов а об коллекции ссылок на объекты и т.п.

Мне кажется, не тока я. В часности, в обыкновенных ООСУБД, када ByVal, то грят о составных объектах т.е. один чать другого, а када ByRef, то грят о связях по ссылке. Т.е. а ООМД это связь, как правило.

vadiminfo

Далее, думаю, что по крайней мере в некоторых РБД таблицы реализованы как коллекции указателей на строки. Что теперь отказать этим РБД в том что таблицы содержат строки?

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

vadiminfo

Предлагаю в контексте Cerebrum считать что включение одного объекта в другой по ByRef означает именно включение, и по умолчанию считать что все объекты включаются друг в друга по ByRef в противном случае требуется особое замечание на предмет ByVal.

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

vadiminfo

У случае с Cerebrum все включения производятся по ByRef. Только сериализацию объектов можно считать ByVal да и то много вопросов.

Это тогда псевдовключение, мягкое включение, или еще какие-то. Чем они оправданы и чем лучше обычных связей?


vadiminfo

В плане СУБЗ или ИИ Cerebrum на данный момент не выходит за границы опубликованных статьей на тему СНС. Планы есть, но ведь планы не продемонстрируешь в рабочем коде )) На ИИ позже будем посмотреть )) Тут бы с транзакциями и версионингом управиться ...

В опубликованных статьях ничего не понял. Там бы тоже концепцию отделить от деталей реализации. Представьте, что читают те, кто первый раз видит эти мыстли. Не формально, чтобы было видно цели, основные идеи, с каким разделами математики это связано. Потому что понятно, что это не нейронные сети в аппаратном смысле. Эмуляция их? Да еще и не обучаются. Чем отличается от того, к чему мы привыкли. Там было что-то про градиентый метод (или типа того), а тут что? Что означает первое С в контексте НС? Как это работаит, и что может решить? Хотя бы кратко.

Однако, у планов есть смысл какой-то, его то можно как-то продемонстрировать.

А вот на ИИ и СУБЗ чем раньше, тем лучше на концептуальном уровне посмотреть. С транзакциями и версионингом многие так или иначе управились, а вот с ИИ и СУБЗ пока не очень.
3 июл 05, 12:22    [1670290]     Ответить | Цитировать Сообщить модератору
 Re: Cerebrum : Сетевая объектно-ориентированная система управления базой знаний  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
vadiminfo
Мне кажется, не тока я. В часности, в обыкновенных ООСУБД, када ByVal, то грят о составных объектах т.е. один чать другого, а када ByRef, то грят о связях по ссылке. Т.е. а ООМД это связь, как правило.


В моем случае на реализационном уровне - все ByRef.

vadiminfo

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


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

vadiminfo

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

ИМХО аксиоматика в теории множеств не является корректной. Поэтому брать ее в качестве примера мне не интересно ;)
В теории множеств отсутствуют понятия : указатель, ссылка, value-переменная, reference-переменная. (в C# это все является основой языка). Поэтому в теории множеств элементы ведут себя в разных случаях как value а в других как reference. В отдельных случаях это приводит к антимониям (таким как парадокс рассела).

vadiminfo

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


Очередной раз говорю. Таблицы это надстройка над ООСУБД выполненная средсвами ООСУБД. Пользоваться в Cerebrum только таблицами смысла не имеет т.к. это будет не эффективно даже с точки зрения самого Cerebrum не говоря уже о сравнении с табличными СУБД у которых таблицы это native level. В Cerebrum таблицы - это удобное дополнение к другим его возможностям.

vadiminfo

Это тогда псевдовключение, мягкое включение, или еще какие-то. Чем они оправданы и чем лучше обычных связей?


Тем что их возможно использовать совместно с другими возможностями ООСУБД Cerebrum.

vadiminfo

Как это работаит, и что может решить? Хотя бы кратко.

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


vadiminfo

Однако, у планов есть смысл какой-то, его то можно как-то продемонстрировать.


А вдруг Microsoft подслушает ? ;)) Ващето я не обсуждаю идеи которые я не опубликовал в том или ином виде. Это в научных кругах считается неэтичным.
3 июл 05, 12:47    [1670302]     Ответить | Цитировать Сообщить модератору
 Re: Cerebrum : Сетевая объектно-ориентированная система управления базой знаний  [new]
vadiminfo
Member

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

Но ведь тогда пользуясь моей "РБД" вы будете наблюдать таблицу собственной строкой ))

Боюсь, Вы переоцениваете мои способности видеть фантастическое. Я этого никак представить себе не могу, кроме описанного выше примера про {X{X...}}, да и он из-за бесконечного не укладывается у меня в воображении.

shuklin

Таблицы это надстройка над ООСУБД выполненная средсвами ООСУБД

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

shuklin

ИМХО аксиоматика в теории множеств не является корректной. Поэтому брать ее в качестве примера мне не интересно ;)
В теории множеств отсутствуют понятия : указатель, ссылка, value-переменная, reference-переменная. (в C# это все является основой языка). Поэтому в теории множеств элементы ведут себя в разных случаях как value а в других как reference. В отдельных случаях это приводит к антимониям (таким как парадокс рассела).

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

shuklin

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

Ну, не статьи, а книжку напишите, и за нее, может, получите деньги от ее продаж. Тока в первый раздел поместите одни концепции, формулируйте сначало не формально, приводите примеры, и тока потом давайте формальное.
Вопрсы для начала(ответ краткий)
1) Пару примеров в терминах понятных любому неучу какие задачи может решать СНС. Желательно, что была видна какая польза может быть народному хозяйству от решения этих задач.
2) Как соотносится СНС, с НС (с обычными нейронными сетями, которые проходят в Вузах)? Что будет если из СНС выкинуть первую букву?
Чем оно станет хуже или лучше.
3) Как простенько без обучения эта СНС что-то может? Типа на чем он будет работать?
Пока достаточно. Потом можно будет подбираться про то, что Вы думаете про СУБЗ. Чем оно отличается от простой СУБД.

shuklin

А вдруг Microsoft подслушает ? ;)) Ващето я не обсуждаю идеи которые я не опубликовал в том или ином виде. Это в научных кругах считается неэтичным.

Ну я имел в виду в терминах того, что изложено в тех книгах 20 летней давности, что Вы привели. Чтобы понять как соотносится Ваша система с известными. В плане того, что она сможет в идеале, если все получится. И в рамках того, что Вы уже заявили. Про СУБЗ и ИИ. Не надо, конечно, секретов никаких.
3 июл 05, 15:29    [1670374]     Ответить | Цитировать Сообщить модератору
 Re: Cerebrum : Сетевая объектно-ориентированная система управления базой знаний  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
vadiminfo
shuklin

Таблицы это надстройка над ООСУБД выполненная средсвами ООСУБД

Вы уверены, учитывая и предыдущю цитату, что у Вас нет и признаков ОРСУБД?


Я уверен, что есть. Т.к. если расматривать реляции = равенство по значению, то на этом свойстве у меня построены отношения между всеми понятиями по равенству OID. В Cerebrum есть такое понятие, как handle space. В пределах этого контекста не может быть двух разных сущностей с одним и тем же OID. Однако в БД таких handle spaces - по колличеству объектов и больше )) Тоесть наличие 3х, ... N объектов с одним и тем же OID - тривиальность. И сопоставляются они друг с другом так же как и РМД - по значению.

vadiminfo

В теории множеств, как бы, указатели, ссылки все еще не нужны.

А я считаю, что все проблемы растут из за их отсутствия. Их нет. Но это не значит что таких понятий нет фундаментально. Как ни крути а объект маршализируется либо по ByVal либо по ByRef. Если не задумываться о том как именно - можно случайным образом применять либо одно либо другое, а потом удивляться наличию парадоксов ;)

{X{X{X ... Вот X - это что? переменная-value или переменная-reference ?
В случае X-Value уже X={X} вызовет TypeCastExeption ))
Другими словами, при решении уравнения
X={X} "множество" ответов пусто. Тут более правильно говорить о пустом enumerator - е Ибо пустое множество {} так же не является правильным ответом.


Скорее всего математикам давно пора взяться за книжки по программированию и разобраться во многих свойствах которые для программистов давным давно стали тривиальностью. Я не считаю парадокс рассела чем то фундаментальным. С точки зрения программера этот парадокс является или TypeCastException ;) или задачей с пустым енумератором решений.

vadiminfo
1) Пару примеров в терминах понятных любому неучу какие задачи может решать СНС. Желательно, что была видна какая польза может быть народному хозяйству от решения этих задач.


СНС может решать

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

- представлять БЗ для продукционной ЭС.

vadiminfo
2) Как соотносится СНС, с НС (с обычными нейронными сетями, которые проходят в Вузах)? Что будет если из СНС выкинуть первую букву?
Чем оно станет хуже или лучше.

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

СНС представляет собой расширение ИНС Неймана-Маккаллока-Питтса. (да да, того самого фон Неймана который сделал первую ЭВМ и участвовал в выборе Хиросимы в качестве первой цели).

vadiminfo
3) Как простенько без обучения эта СНС что-то может? Типа на чем он будет работать?

СНС проектируется а не обучается. Человек создает структуру СНС исспользуя отдельные фрагменты в качестве строительных блоков. Это очень напоминает VHDL.
3 июл 05, 16:26    [1670414]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7 8 9 10   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить