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

Любые попытки хранить все данные в виде набора файлов обрекают пользователя на проблемы поддержки и регулярного обновления этих самых файлов. Также хранение в файлах увеличивает количество потерь данных и ошибок в них при частичной записи информации в несколько разных файлов. Большинство современных систем стремятся перейти к хранению данных в рамках СУБД.

Исходя из всего вышеперечисленного Delta Design хранит свои данные также в СУБД. При этом мы используем СУБД IPR собственной разработки.

Почему своя система хранения данных:

  • SQL-подобные СУБД предназначены для хранения и работы с большими массивами однотипной информации, а структура данных проекта платы представляет из себя сложный граф
  • При всем обилии объектных СУБД на рынке на момент старта разработки системы отсутствовали решения, которые были бы устойчивы и которым можно было доверять. Поэтому было принято решение использовать "прозрачную" и понятную нам собственную разработку. СУБД IPR уже используется в промышленных решениях, поэтому ее надежность не вызывает сомнения.
  • Использование СУБД собственной разработки позволяет уменьшить цену конечного продукта для пользователя, которому не требуется приобретать, развертывать и поддерживать СУБД третьего производителя.

Что умеет наша СУБД (IPR):

  • СУБД является сетевой и многопользовательской
  • Оперирование данными в СУБД выполняется в рамках транзакций
    Транзакция в СУБД полностью удовлетворяет требования ACID, т.е. может быть выполнена либо целиком и успешно, соблюдая целостность данных и независимо от параллельно идущих других транзакций, либо не выполнена вообще и тогда она не должна произвести никакого эффекта.
  • Система обеспечивает высокоскоростной доступ к информации:
    • при запросе данных для конкретного объекта и связанных с ним - выше, чем у реляционных СУБД
    • при запросе "глобальных" данных и при изменении данных - сравнимую с реляционными СУБД.
  • Объектный язык запросов, похожий на SQL

Как устроена модель данных в нашей СУБД (или почему IPR):

  • Модель ведения данных СУБД основана на принципах ООП. Базовыми элементами для построения модели являются айтемы (объекты) и их свойства. Свойство может быть предопределённого (системного) или пользовательского типа данных. Пользовательские типы данных определяются через дополнительные библиотеки, подключаемые разработчиками.
  • В системе существуют пространства для удобства разделения данных. Эти пространства называются миры. Каждый из миров может содержать внутри себя множество классов. Каждый из классов может содержать в себе статические (с единым значение для всего класса) или нестатические свойства. Разработчик может создать множество айтемов (инстансов) каждого класса. И каждый из этих айтемов будет обладать всеми нестатическими свойствами класса.
  • Класс может быть создан "с нуля", а может стать классом-потомком и наследовать свойства от одного или нескольких других классов-родителей. При этом свойства классов-родителей складываются между собой, а класс-потомок может содержать еще дополнительные свойства. "Глубина" наследования не ограничена. Класс в СУБД может быть объявлен абстрактным и в этом случае создавать айтемы в нем нельзя, а можно только в его реальных потомках. Такой подход позволяет строить сложные модели данных, полностью эквивалентные структуре классов в C#. 
  • Между айтемами могут быть возникать отношения. Например, между полкой и книгой на ней возникает отношение "Лежащая на полке книга". При этом важно, что должна быть возможность получить информацию о полке на которой расположена книга и, в свою очередь, о всех книгах на полке или множестве полок. Наша система позволяет задавать отношения между айтемами класса и управлять количеством возможных отношений для айтема класса и количеством участников в каждом отношений с разных сторон.  
  • В реляционных системах управления базами данных (РСУБД) существует возможность задавать отношения через внешние ключи (FK). Однако, отношения бывают множественные (n-арные) и такое отношение в реляционной СУБД вводится дополнительной вспомогательной таблицей. В нашей СУБД в отношении может участвовать несколько классов.
    Таким образом, на уровне ядра базы данных задается возможность ведения данных в объектной модели. Такое построение модели данных определяет название нашей платформы (IPR): "Item-Property-Relation" - "Айтем-Свойство-Отношение"
02.02.2016