NoSQL, Graph Database for Enterprises – How to derive Logical Graph Domain Data Model from Logical Domain Data Model?

As announced in my last post, today I will look to possibilities for graph modeling. Here I will briefly address why is necessary to use a defined approach to design a Logical Graph Domain Data Model.
I want to explain a Logical Graph Domain Data Model based on proven Logical Domain Data Model. Starting from this definition, I will derive the graph view. From a logical point of view there is no difference on the business entities but on the relations between entities on meaningful attributes to define allow traversal through the logical graph.

Advantages of Relational Database (RDB)
Advantages of Relational Database (RDB) are building for many years on formal approach they are defined within different models views and design decisions to create a Conceptual, Logical and Physical Domain Data Model by usage of normalisation and denormalisation Forms.

Development of IT Solutions/Systems typically contains a numerous levels of abstraction. These levels are focused on data they have a range from high conceptual over logical to physical level. Domain modeling use normalization Forms as well established approach based on following Models:

  1. Conceptual Model, documents the basic entities and relationships between them
  2. Logical Model, specifies entities, attributes and their relationships without implementation details
  3. Physical Model –defines the database structure for a technology specific format as a RDB

In addition to the Logical Domain Data Model-s is the Relational Algebra (RA) a solid mathematical foundation for the RDB. These use the Relational Algebra as a god theoretical foundation to define the selection, projections, and operations to build queries.
A particularly query languages for such databases, chief among which is SQL. The knowledge of Relational Algebra is helpful by understanding SQL, normalisation, denormalisation Forms and RDB in general.

Normally are Notations used to define different Domain Data Model-s:

  1. Entity-Relationship Model (ERM)
  2. UML Class Diagram as Entity Diagram

Deriving the Graph view from RDB

Logical Graph Domain Data Model can be directly derived from Logical Domain Data Model. Starting from this definition, I derive the graph view and model from Logical Domain Data Model. From logical point of view there is no difference on the business entities the difference are on the relations between entities on meaningful attributes to enable traversal through the logical graph.

NoSQL_Relational_to_Graph_Principle_Map

In considering this topic instantly yield the following Questions. Can an Entity-Relationship Model be implemented by Resource Description Framework (RDF) Model? Yes, but in detail is the question how good can this model be used for needed Graph Capabilities.

The second Question is, is RDF model an entity-relationship model? Yes and no. Because RDF is used for other things as well, RDF is more general. ER-Model Capabilities can be seen as subset of RDF-s Capabilities. RDF and Web Ontology Language (OWL) are primary designed to describe wide Semantic Web as Domain and not only tight Business Domain, but RDF can be used to define this Business Domain. RDF model contain the relationships and they are first class objects and are identified by a URI-s.

The Relational Algebra (RA) is used RDB as a god theoretical mathematical foundation for the RDB and Graph DB use a Graph Theory as also mature and valuable Base.

Normally are Notations used to define different Graph Domain Data Model-s:

  1. Web Ontology Language (OWL). Usage of OWL and if needed Description Logic (henceforth DL) to define logical Graph Domain Model. OWL is not required to create diff. Graph Models, but if you use Graph Abstraction Layer as Jena or Sesame is recommended for physical Graph Domain Data Model.
  2. Resource Description Framework (RDF)

One Example for Logical Graph Domain Data Model derived from Lehigh University Benchmark (LUBM) OWL.

univ-bench.owl

This with extensions of diff. Properties can this Logical Graph Domain Data Model be used as a Physical Model and by consideration Performance and Response Time Requirements are the Relations between Classes over Properties to optimize for Graph Operations.

Conclusion

The Graph Domain Data Model can be derived from Domain Data Model based on exist Notations and Rules.

In many cases, from the Enterprise Point of View, I see the usage of Graph Domain Data Model as very useful, referring to the benefits of the RDB. But based on cost and flexibility reasons is to consider, by very simple business requirements and short life cycle of the solutions, whether this complexity and effort are needful.

My next topic will consider “Pragmatic Graph Modeling” or “When makes sense to use Graph/Object Mapping (GOM)?” for NoSQL, Graph Database for Enterprises.

Reference list

  1. RDF BEST PRACTICES CURRENT STATUS, http://www.w3.org/standards/techs/rdfbp#w3c_all
  2. A Semantic Web Primer for Object-Oriented Software Developers, http://www.w3.org/TR/2006/NOTE-sw-oosd-primer-20060309/
  3. Ontology Development 101: A Guide to Creating Your First Ontology, http://protege.stanford.edu/publications/ontology_development/ontology101-noy-mcguinness.html
  4. Ontology Best Practices, http://techwiki.openstructs.org/index.php/Ontology_Best_Practices
  5. Domain Modeling with OWL, http://css.dzone.com/articles/domain-modeling-owl-part-2
  6. The Lehigh University Benchmark (LUBM), http://swat.cse.lehigh.edu/projects/lubm/