Question

I’m working with a colleague new to programming and I’m trying to explain some of the concepts of ORM (and SRP) but I’m somehow failing. This is a Rails app.

The class hierarchy of an application I’m working in goes like this:

-CallFlow
— Route (polymorphic)
— RouteOptions

There are attributes specific to the various Routes and each RouteType has it’s own set of options. Ideally, to me, there would be a table for call_flows, a table for each of the route types, and then for the route types that have options, an options table for that route type. A really rough mockup:

Simple_route and outbound_route have no options. Of the routes that do have options, it’s a has_many relationship, giving us an array of options for that route.

Conversely, my colleague would like to put all the fields specific to each route on the call_flows table. This is a mockup of that mode:

So you would have one big call_flows table with fields that don’t apply to every record. In fact, only a handful will. My reasoning behind my modeling decision follows:

• It follows the basic normalization patterns
• It reduces the amount of null values, thus db size
• It’s more flexible to change
• It follows basic SRP principle

Am I missing anything? It would be nice to have any resources that would help a new programmer the importance of DB normalization.

Thanks!

Answer 1

The core concept behind the normalization is Data Dependency vs Functional Dependency. In a normalized schema, only dependencies are functional dependencies, dictated by the business or the semantics of data. For example, RouteOptions depend on Route.

In a non-normalized table, since all data is stored in all places, there will be data dependencies as well as functional dependencies. In such cases, it is very hard to execute a transaction and assert with 100% confidence that your data model is consistent.

Lets take an example. You want to add a new Route Option. This is your transaction. In a normalized table, you create a new record in RouteOption table and fill the Route_ID in in the same record. You are 100% confident that your data model is consistent after the transaction.

Take a Non-Normalized schema, suppose you have the same RoutOption Table and a RouteSummary Table with columns from several tables in it. When you execute the above transaction on this schema, your data model is not consistent. You have to “remember” to update the RouteSummary Table. After a few days, some other table will be created which will also have RouteOption. The preexisting transactions will not know about this new table.

There is a place for non-normalized schema also. It is, when your data store is not transactional. If it is a ReadOnly schema, largely used for Analytical reasons, there will be no transactions, so there will be no risk of inconsistent data. Hence they are okay in that use case.