GotAI.NET - Форум - Искусственный интеллект

Все темы | Новая тема

Стр.3 (6)

<< < Пред. | След. > >>

Поиск:

Автор

Тема: На: Создание искусственного интеллекта на основе сетевой объектно-ориентированной базы знаний

shuklin
Сообщений: 2053

На: Создание искусственного интеллекта на основе сетевой объектно-ориентированной базы знаний

Добавлено: 26 сен 08 11:23

Цитата:

Автор: tac
Мы разобрались что количество узлов нужно для лучшей оптимизации, если бы не это всю информацию вообще можно было бы хранить в одном узле.

В первую очередь не для оптимизации, а для свободы творчества в построении архитектуры. Контейнейрные узлы предоставляют собственную реализацию адресного пространства, такой концепции адресного пространства Вы не найдете в обычном языке программирования. Допустим применение .NET, в этом случае адресное пространство предлагаемое Ц потребуется эмулировать на основе множества HashTable, По одной HashTable на узел. Это потребует затрат на реализацию. Я называю этот механизм Сетевой Моделью Данных (СМД). Оптимизатор, он уже существует за ширмой, так же как и сборщик мусора в .NET , это уже средство поддержки реализации, а не концепции. А еще требуется признать, что оптимизатор в Ц не есть вершина оптимизации. Его можно улучшать и улучшать. Хотя, даже то что уже есть в текущей версии, имхо очень даже вещь ))

Цитата:

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

Похоже, но причинность расставлена неверно. Я не использую таблицы, а реализую таблицы средствами сети. Таблица - это программный табличный интерфейс к участку сети. Концепция интерфейса данных - удобная вещь. У узлов есть аттрибуты (= тоже узлы). Однотипные узлы (=экземпляры классов) обладают идентичными по семантике аттрибутами и образуют множеством аттрибутов интерфейс. Каждый однотипный узел предоставляет интерфейс своего типа. Интерфейс данных - множество однотипных аттрибутов с единой семантикой. Возможна ситуация, когда узел реализует некоторый интерфейс не полностью. Тогда отсутствующие аттрибуты считаются равными null. Эта структура естественно отображается на коллекцию(=таблицу) экземпляров с фиксированным набором полей (=колонок таблицы). Таблица в Ц это уже не элемент физической реализации, а элемент абстрактного уровня представления данных. Можно рассматривать таблицу Ц как аналог реляционного VIEW, но развернутого не поверх других таблиц, а развернутого поверх фрагментов сети. В связи с тем что таблицы==view абстрагируют сети а не другие таблицы, то и свойства их весьма разнятся по сравнению с РБД-шными view. Такой интерфейс к данным значительно экономит колличество строк в программе. За счет наличия метоинформации, описывающей аттрибуты, появляется возможность автоматического управления аттрибутами узлов, входящих в коллекции узлов(таблицы). Рекомендация, держать в таблице узлы одного типа является всего лишь рекомендацией. В одной таблице следует держать узлы с совместимыми интерфейсами, что тоже самое с некоторым общим подмножеством аттрибутов, общим для всей коллекции и объявленных в шапке таблици. Т.к. это рекомендация, то ее можно, а иногда даже нужно нарушать. Таблицы - тоже узлы, их можно прицепить значением аттрибута любого узла, находящегося в какойто другой таблице, получится, что значением поля таблицы будет выступать другая таблица, или даже та же самая таблица. Очень важно обратить внимание, что различные узлы могут ссылаться на один и тот же экземпляр узла в качестве своего аттрибута. Таким образом ячейки в таблице можно мержить способом, похожим на объединение ячеек в экселе. Однако объединять можно произвольные ячейки, не обязательно даже в одной таблице. Это уже работа в обход табличного интерфейса, с сетью узлов. Табличный интерфейс являясь view над фрагментом сети, будет соответственно отображать изменения в сети так, как будто ячейки таблицы объединились в одну.

Цитата:

В реляционных базах все ясно - там храним то, что привели к нормальной форме, а в объектной казалось бы именно этого и не нужно ?

В объектной БД и в сетевой МД нормальные формы столь же важны как и в РБД, но выполняют несколько иную функцию. ИМХО и удобно и правильно нормализовать классы пользуясь нормальными формами. Когда стоит задача разработать некоторую объектную модель для представления некоторой сущности внешнего мира, то для разделения аттрибутов по классам следует пользоваться нормальными формами. Как и в РБД нормализация, всего лишь рекомендация, облегчающая разработчику жизнь и экономящая рессурсы. Ограничением же свободы разработчика является "физический" с точки зрения приложения уровень хранения информации. В РБД физическим уровнем выступают таблицы, а в Cerebrum - сеть узлов. Если нужна сеть в РБД то ее требуется эмулировать с помощью таблиц, если нужны таблицы в Ц, то их нужно эмулировать сетью, что в Ц и сделано. Таблицы в Ц - эмуляция для удобства, а так же для совместимости со стандартами .NET Data Binding

Форум: Проблемы искусственного интеллекта