RavenDB Webinar Thumbnail

Data Modeling - Can You Do it Without a Schema?

How do you model data in a NoSQL setup?

Is it really like reinventing the wheel? That sounds like a lot of work, where do I even begin?

In this webinar, RavenDB CEO Oren Eini shows you how easy it is to transform your data into a 21st century format using the Document model. RavenDB is made to make your life easy and he shows you how to remold your data without having to remold your thinking.

You will learn:

  • RavenDB tools to facilitate Document Data Modeling
  • How to model data in RavenDB
  • Examples of Data Modeling in RavenDB

Chapters

  • 00:00:00 Introduction
  • 00:01:47 What is the Domain Model?
  • 00:04:43 Aggregate Root, Entity, Value Object vs Documents and Entities
  • 00:08:56 Rules of Document Modeling: Independent, Isolated, Coherent
  • 00:14:26 Northwind Example
  • 00:28:44 Many to Many Association in a Document Data Model
  • 00:30:56 Areas of Design Where RavenDB Makes Your Life Significantly Easier
  • 00:51:05 Questions and Answers

Webinar Summary

There are three core concepts in domain driven design, they are aggregate root, entity, and value object. An aggregate root is something that has an identity in the model. This is different than an entity which is just something that has an identity.

What is the difference between an aggregate root and an entity? In this webinar's online shop example, we are going to have an Order and an OrderLines. Both of them are going to be entities. I can say, "Give me OrderLines 6, or give me Order 50." This is, if I am using a relational database, because effectively I must have a primary key on the OrderLines table.

On the other hand, in my model, I am never going to say, "Give me OrderLines 5." It doesn't make sense. In my model, I am always going to approach an OrderLine within the scope of its own parent order.

In the book, Domain Driven Design, by Eric Evans, he talks about only creating references between aggregate roots, even if you have entities that are encompassed by single aggregate root you should only have one of them.

With RavenDB, the situation is different. We don't actually have the concept of an entity. To be more exact, the division that we typically do is that we have a document, and a document is a 1 to 1 mapping to an object graph that is an entity inside your application.

Modeling three rules of thumb

For modeling in RavenDB, here are three rules of thumb for each document:

  • Independent: A document should have its own separate existence from any other documents. You can take a document and do stuff to it, without having to do stuff to anything else. A document is not independent if it can't exist on its own. An OrderLine document is a good example of a document that is not independent. An OrderLine document will always exist within an Order, it's right there in the name.
  • Isolated: A document can change independently from other documents. A document is not isolated if every time that I modify a document, I also have to modify a different document.
  • Coherent: A document should be legible on its own, without referencing other documents. A document is not coherent if, in order to understand it, I have to reference another document. A good example is an association table in a relational database. It's meaningless unless you join to the other tables that it relates to.

You want to get to a point where you can look at the document, you can make sense of it, you can modify it on its own without touching anything else, and it doesn't break any part of the system.

LIVE
DEMO
Request Live Demo

LIVE DEMO

Request a customized
presentation of RavenDB

Request Live Demo

Request a customized presentation of RavenDB