Alternatives to the Relational Model

Robust Relationships or High Speed and Performance?

This is the introduction to the chapter on Alternatives to the Relational Model. I’m not settled on calling it “alt-relational,” but it’s the best I could come up with for now. I initially called this “non-relational” modeling, but this received a lot of raised eyebrows and triggered emotions. “What do you mean the data doesn’t relate?!” So, I look at these modeling patterns as alternatives to the relational model, or “alt-relational” for short. Please note that further sections in this chapter will be for paying subscribers only. Consider becoming a paying subscriber to support this project.

This chapter focuses on data modeling for applications. Think NoSQL, streams, and such. The next chapter will take these concepts and apply them (along with relational) to analytics.

As always, comment where you wish. If you find errors, please submit them here.

Thanks,

Joe¹

---

In the last chapter, you learned about relational data modeling. Now, we will go in the other direction and learn about alternatives to relational modeling, or what I call “alt-relational” data modeling. You’re probably wondering what the heck I’m talking about. Isn’t all data related? How dare I commit heresy and deem something other than relational? Let me explain.

The relational model aims to minimize or eliminate redundancy and side effects by implementing strict relationships between entities, which are often tables. Alternate-relational modeling relaxes the strictness of robust data relationships and focuses on the speed and performance of queries and storage.

Also, unlike relational’s emphasis on data independence, where the logical data model is decoupled from the physical application, alt-relational modeling is not as clean-cut. While every data model starts as a conceptual model, translated into a logical model, and then implemented as a physical model, the emphasis on performance might force one to hyper-focus on the shoehorning data into a form that is first optimized for performance. The data is stored according to how it will best perform on queries, whether they require the lowest possible latency, ingestion of lots of data on an ongoing basis, and so on.

Different terminology describes alt-relational modeling. You might hear terms like NoSQL, event-streams, and with tables, denormalized and unnormalized. All of these are variations of alt-relational data. Alt-relational data might start off relational or as something very non-relational, to whatever degree we wish to claim it. As we touched on at the end of the last chapter, in the case of denormalization, we’re starting with normalized data, adding redundancy, and increasing the risk of side effects. Because we’re well aware of the potential challenges, we’re doing a great job of sensibly denormalizing our data to meet our needs. The goal here isn’t to clearly delineate between relational and alt-relational. We need to discuss alt-relational models to cover increasingly common situations where relational modeling must be relaxed to achieve performance optimization from the data model.

Note that some of these concepts can apply to OLAP workloads. For example, denormalized data is commonly used in analytics. Here, we’ll focus on OLTP and application workloads, as these have different query and usage patterns than analytics. OLAP will be covered in upcoming chapters.

The line between logical and purely physical modeling is often blurred. In alt-relational modeling, the goal is usually to optimize directly for physical access performance. Ideally, the physical model translates back to the logical and conceptual model, and I suggest striving for this.

Relational purists might be up in arms about the mere existence of alt-relational approaches. So it goes. Flexibility and knowledge of various approaches - orthodox or not - is the central theme of Mixed Model Arts. For example, in a real fight, you deal with the situation at hand, not some idealized method of combat. Understand the available tools and options, and choose the best for your situation. As long as you’re making an informed decision, that’s the best you can do. But avoid dogma for its own sake. Dogma is almost worse than premature optimization.

Let’s first look at access pattern optimization. After that, we’ll look at alt-relational data modeling concepts using various database systems as examples.

1. Updated Feb 5, 20205