search

unum-cloud / ustore

Multi-Modal Database replacing MongoDB, Neo4J, and Elastic with 1 faster ACID solution, with NetworkX and Pandas interfaces, and bindings for C 99, C++ 17, Python 3, Java, GoLang 🗄️
https://unum-cloud.github.io/ustore/
Apache License 2.0
533 stars 30 forks source link

Feature: Support data models #246

Open Ramimashkouk opened 1 year ago

Ramimashkouk commented 1 year ago

Describe what you are looking for

We're looking for a database that supports data models (ontologies) along with other features that you already have on the roadmap. A data model puts constraints on nodes and edges so that they could be created only after creating their data model kinds. With code it might look something like this:

net = db.main.graph
ontology = net.ontology

ontology.add_node_kind(101) # creates a kind 101 in the ontology
net.add_node(1, kind=101) # creates a node of kind 101
ontology.add_node_kind(102)
net.add_node(2, kind=102)
net.add_node(3) # error
net.add_node(4, kind=104) # error

ontology.add_edge_kind(node_a_kind=101, edge_kind=1001, node_b_kind=102)
net.add_edge(node_a=1, edge_kind=1001, node_b=2)
net.add_edge(node_a=1, edge_kind=1002, node_b=2) # error

How soon could such a feature come to light? :)

Can you contribute to the implementation?

Is your feature request specific to a certain interface?

Official Python bindings

Contact Details

rami.n.mashkouk@gmail.com

Is there an existing issue for this?

Code of Conduct

ashvardanian commented 1 year ago

Interesting suggestion. We are preparing a few things, but it may not be exactly what you describe.

  1. Document schemas. You can specify what attributes members of a specific collection should have. This will allow you to compose collections of objects with vastly different contents, later combining them into "virtual" graphs. But it won't work with diverse ontologies.

  2. Our Graphs are designed as Multi-Graphs. So edges can have identifiers, and multiple edges can connect the same vertices.

  3. You can store the "kind" of a node as one of its attributes and later filter by them in a higher-level interface.

Please let us know if that can cover your use case.

Ramimashkouk commented 1 year ago

  1. Great! It's like putting constraints on attributes. But, will it be a schema optional (constraining is an optional manual thing), or will these document schemas be already built as constraining schemas? What do you mean by “it won't work with diverse ontologies”?

  2. Great! I didn't know that. It's also an interesting feature to us! :)

  3. Yeah, we can even make a separate node for a kind and connect it with nodes belonging to that kind using edges. However, after working with TerminusDB, which provides a native ontology, and Neo4j, which doesn't, we noticed how working with a built-in ontology gives a better performance, and consequently, makes a stronger solution to different tasks

I believe that adding kinds to document schemas will enrich the schema as a whole and make the use cases even wider (for business data modelling as another example).