Я бы предложил два подхода для построения базы знаний любой структуры - ассоциативные сети и построение следующего уровня над реляционной БД.
Должен сказать, что "ассоциативные сети" - подход, разработанный не мной; и по нему, в отличие предлагаемого мной метода, можно найти множество дополнительной информации, достаточно набрать "ассоциативные сети" в поисковике. Еще их, вроде бы, называют "семантическими сетями".---------------------------------------------------------------------------
Ассоциативные сети (терминология не соблюдается, потому как я ее забыл):
Разработано специально для хранения ассоциативной информации, что достаточно просто для человека и, на мой взгляд, достаточно сложно в реализации для программиста.
1. Граф-декларатор.
Представим себе граф, в котором вершинам соответствуют названия классов понятий, а ребрам - их название типов соответствий между ними. Т.е. есть для высказывания "нечто помещено куда-то", "нечто" и "куда-то" - классы, а "перемещено" - тип соответствия между "нечто" и "куда-то". Получившийся граф поясняет этот тип соответствия (можно его даже обозвать как-нибудь в этом роде).
2. Граф-имплементатор.
Такой граф полностью соответствует какому-либо из графов-деклараторов, однако вместо классов в нем представлены реальные объекты. Допустим, для рассмотренного графа-декларатора подходит высказывание "документ N12.34 помещен в архив" - тут "документ N12.34" соответствует классу "нечто", а архив соотетствует "куда-то". Синтаксис не самое главное, главное - сохранение ассоциативной целостности.
3. Хранение данных в ассоциативных сетях.
Видимо, необходимо универсально хранить деклараторы (что достаточно просто в реализации для реляционных БД в силу элементарности конструкции), универсально хранить объекты и классы объектов (тут возникают некие сложности - все-таки строки разной длины), и универсально хранить имплементации (что также вполне реализуемо).
4. Поиск в ассоциативных сетях.
Наверное, стоит реализовать два вида поиска - по ассоциациям (необходимо представлять в графическом виде графы для поиска данных) и по контексту.
При этом надо, видимо, учесть, что при поиске по контексту отношения могут называться по-разному (при реализации учесть возможность нескольких названий отношений для одного и того же декларатора). Поиск осуществляется так - по заданной на человеческом языке строке отыскиваются все подходящие отношения, для которых затем проверяются подходящие классы или (если таковых не находится) отыскиваются все подходящие объекты.
---------------------------------------------------------------------------
Надстройка следующего уровня над БД:
Суть заключается в том, чтобы все возможные виды связей (1:n, n:m, может, еще какие придумаете ;-)) описать и дать им названия раз и навсегда.
Далее нужно построить:
1. таблицы для хранения связей (видимо, две, раз всего два вида);
2. таблицу объектов (с уникальными идентификаторами);
3. таблицу значений полей объектов (тут есть некая сложность - опять-таки, разной длины могут быть названия объектов, но можно построить таблицы по типам данных, однако будет необходима еще и таблица описаний типов данных);
4. таблицу описаний объектов (какие поля есть у объекта).
В итоге получается, что мы имеем универсальную систему для хранения любых объектов и любых видов связей между ними. Я бы еще для навороченности добавил возможность отката/наката базы по дате - для этого у объектов и связей необходимо добавить к идентификатору еще и дату.
Сложности:
Для работы с такой базой необходимо построить язык более высокого, чем SQL, уровня. Причем, понятное дело, необходимы транзакции, хранимые процедуры, триггеры и т.д. и т.п.. Однако в чистом виде это вполне реализуемо, и наверняка для реальной работы не понадобится особо много видов запросов - нужны будут запросы на выборку, на запись и на построение объекта.
В общем, гив ми эбаут ту хандред фаузенд долларс энд ю'л си ит воркинг ин ту еарс.
