Neo4j: Принудительная схема с XSD

Question

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

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

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

Как я понимаю, стандартная практика заключается в том, чтобы контролировать схему из самого приложения, которое для меня не похоже, что это должна быть ЛУЧШАЯ практика. Например, придирчивые разработчики из земли Oracle создают представления для приложений, с которыми можно взаимодействовать, а затем применяют триггеры к представлениям, которые выполняют соответствующие транзакции при попытке приложения или обновления в представлении.

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

Это то, что я хочу написать, если для этого уже нет библиотеки. У меня есть дневная работа. :)

Спасибо!

Answer 1

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

this python application here, который может импортировать XML в neo4j; документы, а не схемы. Но в том, как это делается, есть много вещей, о которых следует помнить:

1. Нет явного отображения элементов XML/атрибутов на узлы/свойства neo4j. Вы думаете, что элементы должны быть узлами, свойствами атрибутов; но лучшая модель графа обычно будет отличаться от этого. Например, пространства имен XML создавали бы большие узлы, потому что они соединяются со многими другими вещами (например, все элементы, определенные в пространстве имен), но, как правило, они являются атрибутами. Может быть, пространства имен должны быть ярлыками? Также, возможно, разумный выбор, за исключением того, что нет стандартного ответа.
2. XML-деревья имеют последовательность и последовательность вопросов; графиков нет. Скажем, у вас есть элемент XML с 2 детьми, A и B. В neo4j у вас может быть узел, подключенный к двум другим узлам, но вам нужен способ выражения (возможно, через свойство отношений), что A приходит перед B. Это, конечно, возможно в neo4j, но нет никакого соглашения, насколько я знаю как это сделать. Итак, вы можете выбрать атрибут sequence и дать ему целочисленное значение. Кажется разумным ... но теперь ваше программное обеспечение проверки схемы имеет зависимость от этого выбора дизайна. XML в neo4j, сохраненный любым другим способом, не будет проверяться.
3. Существует множество параметров обработки XML, которые имеют значение в проверке схемы, которые не были бы на графике, например, независимо от того, хотите ли вы игнорировать узлы пробелов, строгое сравнение с lax schema и т. Д.

Посмотрите, Neo4j велик, но если вам действительно нужно проверить кучу XML-документы, это, вероятно, не лучший выбор из-за некоторые несоответствия между моделью графа и моделями документа XML,.Возможные варианты могут заключаться в проверке документов до того, как они войдут в neo4j, или просто для того, чтобы придумать способ синтеза XML-документов от, что находится в neo4j, а затем проверки этого результата, когда он находится вне базы данных графа, в виде XML файл.