Альтернатива иерархической модели данных

Проблемная область

Я работаю над довольно большим приложением, которое использует иерархическую модель данных. Он принимает изображения, извлекает функции изображений и создает объекты анализа поверх них. Таким образом, базовая модель похожа на Object- (1: N) -Image_features- (1:1) -Image. Но один и тот же набор изображений может использоваться для создания нескольких объектов анализа (с различными параметрами).

Тогда объект и изображение могут иметь много других связанных объектов, например, объект анализа может быть уточнен с помощью дополнительных данных или сложных выводов (решений), которые могут быть основаны на объекте анализа и других данных.

Текущее решение

Это эскиз решения. Стеки представляют наборы объектов, стрелки представляют указатели (то есть функции изображения ссылаются на их изображения, но не наоборот). Некоторые части: изображения, функции изображения, дополнительные данные, могут быть включены в несколько объектов анализа (потому что пользователь хочет провести анализ на разных наборах объектов, комбинированных по-разному).

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

Все объекты (изображения, функции изображения, объекты анализа, решения, дополнительные данные) являются экземплярами соответствующих классов (например, IImage,...). Почти все части являются необязательными (то есть, мы можем захотеть сбросить изображения после решения).

Недостатки текущего решения

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

Моя идея

Я хотел бы построить более расширяемую (2) и гибкую (1) модель данных. Первой идеей было использование реляционной модели, разделяющей объекты и их отношения. И почему бы не использовать РСУБД здесь - sqlite кажется мне подходящим движком. Таким образом, сложные отношения будут доступны простым (слева) JOIN в базе данных: псевдокодом "images JOIN images_to_image_features JOIN image_features JOIN image_features_to_objects JOIN objects JOIN solutions JOIN solution_features" ), а затем извлечением фактических объектов С++ для функций решения из глобального хранилища по идентификатору.

Вопрос

Итак, мой основной вопрос:

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

Если RDBMS в порядке, я был бы признателен за любые советы по использованию СУРБД и реляционного подхода для хранения отношений объектов С++.

Ответ 1

Я не рекомендую РСУБД, исходя из вашего требования к расширяемой и гибкой модели.

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

Я настоятельно рекомендую использовать стандартное программирование С++ OO с помощью STL.

Вы можете использовать инкапсуляцию, чтобы обеспечить правильное изменение данных, с обновлениями связанных объектов и индексов.
Вы можете использовать STL для создания высокоэффективных индексов данных
Вы можете создавать фасады, чтобы легко получить информацию, а не переходить на несколько объектов/коллекций. Это будет одноразовая работа.
Вы можете сделать unit test случаи для обеспечения правильности (гораздо менее сложной по сравнению с модульным тестированием с базами данных).
Вы можете использовать полиморфизм для создания различных объектов, различных типов анализа и т.д.

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

Ответ 2

Вы можете захотеть взглянуть на технологии Semantic Web, такие как RDF, RDFS и OWL, которые предоставляют альтернативный, расширяемый способ моделирования мира. Существует несколько открытых магазинов с открытым исходным кодом, и некоторые из основных RDBMS также имеют возможности с тремя магазинами.

В частности, посмотрите на Манчестер Вузы Protege/OWL учебник: http://owl.cs.manchester.ac.uk/tutorials/protegeowltutorial/

И если вы решите это направление стоит смотреть дальше, я могу рекомендовать „Semantic Web для РАБОЧЕГО онтолог“

Ответ 3

Просто основанный на диаграмме, я бы предположил, что решение RDBMS действительно сработает. Прошло много лет с тех пор, как я был разработчиком RDMS (конечно, RDM), но я смог обновить свои знания и получить очень много ценных сведений о структуре данных и макете, очень похожих на то, что вы описываете, прочитав сказочные книга "Искусство SQL" Стефана Фарута. Его книга проделает долгий путь, чтобы ответить на ваши вопросы.

Я включил ссылку на него на Amazon, чтобы обеспечить точность: http://www.amazon.com/The-Art-SQL-Stephane -Faroult/дп/0596008945

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

Использование RDBMS для отслеживания связей между данными может быть эффективным способом хранения и анализа анализа, который вы ищете, а ссылки являются "мягкими", то есть они уходят, когда жесткие объекты, на которые они ссылаются, удален. Это обеспечивает целостность данных; и Mssr Fauroult может ответить, что делать, чтобы убедиться, что это правда.

Ответ 4

http://www.boost.org/doc/libs/1_51_0/libs/multi_index/doc/index.html

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

С помощью Boost.MultiIndex вы можете создавать почти все типы индексов на "таблице". Я думаю, что цитированная проблема не так серьезна, поэтому исходное решение управляемо.