В основе системы лежит "объектная модель" предприятия.  "Описание" этой модели хранится в ядре CODB и загружается в него в момент компиляции из XML - файлов.

Что такое "Объектная модель предприятия" вообще? Это такая модель, которая позволяет вычислить неразрывную цепочку ссылок классов и их атрибутов по любым информационным сущностям занесенным в систему. Собственно создание модели не особо отличается от оптимизации реляционных данных. Нужно лишь четко себе представлять задачи, которые будет решть информационная система. Отличаются лишь принципы работы с СУБД, сервера с клиентом. В момент загрузки ACCORD'а, эта модель в виде XML-описания загружается в память клиента. По этой модели динамически строится универсальный редактор классов. То есть, мы можем выбрать для редактирования,  поиска  и составления  таблиц любой класс и производить на нем любые операции по аналогии с любой СУБД. Любому классу мы можем присвоить первичный документ - текстовое представление экземпляра класса. 

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

В чем ее суть. Ядро поддерживает 6 иерархических уровней аналитики. То есть каждый нижний уровень, входит в один верхний. Например, аналитика по расчетам с поставщиками делится на аналитику по счетам фактурам. Система позволяет получить оборотно - сальдовую ведомость как по поставщикам так и по всем счетам-фактурам, в зависимости от уровня заказанного пользователем. Возникает вопрос, а как быть с договорами. С объектной точки зрения - между поставщиком и счет-фактурой должна стоять аналитика по договорам и тогда получится трехуровневая аналитика. Но в этом нет необходимости. Договор - это атрибут счет фактуры, если исходить из того, что счет-фактура принадлежит одному договору. Поэтому достаточно в объектной модели прописать вывод атрибута "Договор" в запрос по счетам-фактурам оборотно-сальдовой ведомости и, на клиенте легко делается свертка по договорам из первого уровня по счет-фактурам. Неискушенный читатель задаст вопрос - "Но ведь тогда из этого запроса таже можно получить свертку по поставщикам?" Совершенно верно, а еще по городам и регионам, так как это атрибуты поставщика. Таким образом имея только один уровень аналитики - по счетам фактурам, мы можем получить анализ по четырем срезам - "поставщикам-договорам-регионам-городам". Итак, имеем иерархические уровни и паралельные срезы на каждом уровне. Но и это еще не все. Запросив любой объект, который может находиться на любом уровне иерархической аналитики любого счета, мы также можем получить по нему всю оборотно-сальдовую картину. Например, запросив работника - увидим и его зарплату и подотчет и материальную ответственность.

Как работает клиент-сервер. В отличие от классической схемы с SQL гораздо проще. Во-первых, нет необходимости писать сложные SQL-запросы. Обмен построен на технологии асинхронных запросов AJAX. Рассмотрим простейший запрос на поиск по индексу. Клиент формирует HTTP запрос cgi-скрипту с указанием класса, индексного атрибута и искомого значения. В запросе нет необходимости указывать в каком виде выводить ответ. Ответ возвращается со значениями всех атрибутов и ссылок в двух видах RDF или объектах JavaScript.

Предвижу вопрос о скорости. Мол, если заказать вывод не всех атрибутов, запрос будет выполнен быстрее. "Отнюдь" (С) ИТК. Особенности CODB. А вот что делать с этим выводом, решает клиент в виде XSLT шаблона, XUL шаблона (RDF) или динамического дерева (JavaScript) или рисования графики в SVG. Возможно объединение нескольких запросов в один шаблон или сценарий JavaScript и вывод результата в редактируемый документ - HTML (в перспективе ODF ) или преобразование этого запроса в часть клиентского интерфейса (дерева, меню XUL и т.д.). Во-вторых. Какая разница где ждать преобразования - на сервере приложений или на своем клиентском рабочем месте? Всего сервер поддерживает два десятка запросов, которые покрывают всю потребность в обмене между клиентом и сервером. И конечно не вся логика делается на клиенте. На сервере работают триггера. В процессе проектирования очень увлекательно переносить одну и ту же задачу с сервера на клиент и обратно, выбирая - "а где же эффективнее работать будет?".

О том, что по одному аналитическому объекту можно выудить всю его бухгалтерскую жизнь и состояние уже говорилось. Но есть еще один уникальный запрос. По идентификатору объекта или нескольких объектов можно получить циклическую развертку всех ссылок (до пресечения рекурсии). Например, я задаю объект "Накладная N 36" - возвращается не только ее состав, но и всех поставщиков всех товаров этой накладной с их адресами и накладными по которым эти товары поставлялись. Скорость? Самый упругий, который приходилось отслеживать -1.5-3 сек вместе с XSLT преобразованием. Объем XML - 2 МБ. Не трудно себе представить, что на таком материале можно сделать.

Общее резюме. Для работы в комплексе r2d2-ACCORD нет необходимости изучать какой-то новый или специфический язык. Разве что XUL. Имеется объектная СУБД, API которой, ограничен двумя десятками (а реально и того меньше запросами). Все остальное широко распространенная web-технология XML и JavaScript. Имеется универсальное балансовое ядро с сетевой аналитикой. Осталось приложить опыт системного аналитика и получается неплохой симбиоз для создания информационных систем управления широкого круга задач.