Конструктор концепций

Конструктор концепций - представляет собой двухуровневый клиент-серверный, многопользовательский программный комплекс, обеспечивающий управление структурированной базой данных, посредством предопределенного программного интерфейса - API БД. Структурированная БД обеспечивает возможность конструирования древовидных иерархических структур - Концепций, создаваемых архитекторами (проектировщиками), систематизирующими данные произвольной предметной области в соответствии с принципами объектно-ориентированного подхода. Конструктор концепций обеспечивает среду для существования, модификации и взаимодействия с пользователями не ограниченному количеству Концепций на протяжении всего жизненного цикла. Предопределенная архитектура индексированного табличного пространства структурированной БД, совместно с API БД обеспечивает высокий уровень производительности для процессов доступа к данным Концепций.

Область применения

Схемы данных в общем случае условно можно поделить на три типа:

• Простые статические схемы данных с относительно простой архитектурой и не большим количествои связей, ориетированных для работы с огромными массивами однородных данных;
• Сложные статические схемы данных со сложной архитектурой и большим или значительным количеством связей, ориентированных для работы с большими массивами многогранных данных поддающихся первичной классификации на этапе проектирования системы хранения;
• Сложные динамические схемы данных со сложной архитектурой и большим количеством связей, ориентированных для работы с большими массивами многогранных данных, не поддающихся первичной классификации на этапе проектирования системы;

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

Работа с последним типом данных представляет наибольшую сложность. Из моего опыта я могу выделить три основных направления решения проблемы представления данных с динамической архитектурой:

• Использование полей типа JSON - это наиболее популярный на сегодняшний день вариант;

• Использование антипаттерна EAV - это достаточно старый подход обросший массой мифов и суеверий;

• Создание супер схем - это недооценненный подход, мало освещенный среди разработчиков баз данных, однако среди разработчиков СУБД он широко используется. Взять хотябы системные таблицы PostgreSQL, статическая схема данных основанная на наборе системных таблиц позволяет описать произвольную схему данных пользователя для пользовательской базы и является по отношению к ней супер схемой.

  Создание супер схем требует применения API для достпу к данным, что осложняет взаимодействие с данными и делает понимание схемы как таковой более сложной, так как отдаляет структуру хранения данных от общепринятой реляционной модели. По сути реляционная модель данных СУБД уже решает проблему хранения данных для произвольной предметной области, но требует привлечения квалифицированных разработчиков баз данных. Упрощение данной задачи, популярное в настоящее время направление, использование всевозможных ORM, обеспечивающих прозрачный доступ к данным для разработчиков приложений требующих использования систем хранения данных без погружения в суть систем хранения данных. Как правило расплата за это потеря производительности и консистентности данных. Если рассматривать проблему шире, то существует значительная категория пользователей испытывающих потребность в гибкой, настраиваемой, многопользовательской системе хранения данных с простым, дружественным интерфейсом, обеспечивающим хранение и взаимодействие со сложными данными имеющими множественные переферейные свзязи. Для этого и был создан конструктор концепций упрощающий моделирование систем хранения данных, обеспечивающий возможности многопользовательского взаимодействия и импорта-экспорта. Изначально проект был ориентирован на специалистов из инженерной области, и ставил перед собой задачу скрыть сложность разработки и взаимодействия с многопользовательскими серверными СУБД до уровня использования MS Excel при этом сохранив возможности полноценных реляционных СУБД. В целом опыт эксплуатации решения показывает что цель была достигнута, было систематизировано значительное количество сложных технических данных, обеспечен простой и удобный способ их анализа, систематизации и нкопления.

Куб метаданных

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

• Изменение отделных значений свойств экземпяров сущностей;
• Изменени набора и типов свойств классов сущностей;

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

Таким образом сущности с разными наборами свойств и их значений остаются связанными общим классом, что существенно облегчает их систематизацию и формирование аналитических данных:

Библиотека доступа к API