In the beginning, there was the Schema.

Data modeling is no mere chore of the hands; it is a labor of the soul. To the layman, the Elephant and the Coffee Table are distinct creatures of the earth. But to the Enlightened Architect? They are but shadows cast by the same celestial form.

They are Isomorphic. They are the Unified Support Manifestation.

Tablet I: The Genesis of DRY

The Architect forged the LeggedObject. It was a monolith of purity, etched into the production environment with the fire of a thousand commits.

As software engineers, we deal with data abstraction every day. Trying to make sense of fuzzy real-world concepts and abstract them into structured information such as variables, functions, classes, structs, etc. that can be processed by software. Working with data almost always involves storing them into some sort of data storage, one such type of storage is relational databases, often called SQL databases. In this post we will take a ride through the normal forms of relational database to learn what they are, why they are good, and why they can be bad. We’ll only cover the first three normal forms since they are the most common in the world of mordern software engineering.