A data model describes how data is structured and related. It defines entities, attributes, and relationships. A customer has an address. An order has line items. A product belongs to a category. The model is a blueprint. It tells developers how to build the database and tells analysts how to query it. A good model reflects the business. A bad one creates confusion that persists for years.

Models come in levels. The conceptual model describes business entities and their relationships at a high level. The logical model adds detail: attributes, keys, and normalization. The physical model specifies tables, columns, indexes, and storage. Each level serves a different audience. Business stakeholders understand the conceptual model. Developers work with the physical one. The process of modeling forces clarity. What exactly is a customer? Is a prospect a customer? What happens when an order is cancelled? These questions get answered during modeling, not during a crisis. Poorly designed models cause problems that are hard to fix. Denormalized tables lead to update anomalies. Missing keys lead to duplicates. Inconsistent naming leads to confusion. Changing a model after data is loaded is expensive. Getting it right upfront is cheaper, though never easy.

Model levels

• Conceptual — business entities and relationships
• Logical — attributes, keys, and normalization
• Physical — tables, columns, indexes, and storage
• Dimensional — star and snowflake schemas for analytics

A data model is a contract. It says what the data means and how it connects. Break the contract and everything built on it breaks.