Reality Data Modeling

Reality data modeling in context of enterprise line of business applications development.

As components of technology advance engineers find dealing with legacy versions more and more frustrating. The birth of cloud computing allowed (or forced) developers to look at the architecture of their work in terms of unlimited scalability. Having gone through that transition many years ago, I was frustrated with the data model pattern the development community had been using for so long. And while new persistent storage mediums and methodologies have been growing in popularity, a core problem remains.

Eventually, using the current modeling pattern, your database will need to be extended beyond its original intent. This makes for messy and unmanageable platforms. While big data platforms allow for real-time entity definitions, utilizing this type of data is cumbersome and not ideal for a common data silo. The core of the problem is located in the relationships between entities. Extending a single property on a table is not difficult. Hell, if you have a single application, or even a single API, it could be downright easy. Compare that to changing from a one-to-one single property to a many-to-many relationship. Much more difficult at every level.

This is the problem I addressed with the Reality Modeling data design pattern. The basic idea is that you are only allowed to model reality, not business entities.

THERE IS NO ACCOUNT
In the business world they speak of accounts, clients, leads, and orders. An account might look like this;

“Standard” Table
Accounts
• AccountId
• FirstName
• LastName
• HomePhone
• CellPhone
• CompanyName
• Address1
• Address2
• SubRegion
• Region
• PostalCode

“Normalized” Tables
Accounts
• AccountId
• ContactId
• AddressId

Contacts
• ContactId
• FirstName
• LastName
• CompanyName

Address
• AddressId

God Properties
The issue in both cases is the direct relationships between the entities. Only a many-to-many relationship type will give us the flexibility we need for unlimited adaptation. Does that mean every relationship must be managed through a link table? In a perfect world, yes. Properties of an entity should be only God Properties. These are properties given to entities by nature (or God) and maintain a one-to-one relationship. Here is an example of some reality models.

Reality Tables
People
• PersonId
• FirstName
• LastName
• DisplayName

Organizations
• OrganizationId
• Name

Locations
• LocationId
• Address1
• Address2
• SubRegion
• Region
• PostalCode

Associations
The Reality Model uses an advanced concept of the link table called an Association. Associations define the relationship between two entities and will contain properties that result from the relationship.

Association Tables
Person.Organizations
• AssocationID
• PersonId
• OrganizationId
• IsDefaultOrganization
• AssocationType (Work, Affiliate, Member etc.)

Person.Locations
• AssocationID
• PersonId
• LocationId
• IsDefaultLocation
• AssocationType (Home, Rental, Billing)

Conclusion
My first reaction when this concept went on the white board two years ago was; “Man that is going to be hard to deal with on the back-end.” After having used it for a year and a half, I can’t imagine living without the flexibility of the design. When combined with an agile development method, it makes all the sense in the world. At least to me.

reality

Advertisements