Data Modeling

Short answer: Data modeling produces a data model. This is a diagram and set of definitions that describe the things a business tracks, such as customers, orders and products. It also records the details held about each one and how they connect. A modeler often draws a simple version for business review first, then a detailed version for the people who build the database.

A good model matches how the business actually works, such as whether one order can ship in several parts. Models for day-to-day systems usually avoid storing the same fact twice, which keeps records consistent. Models for reporting put speed and ease of analysis first, so they may repeat some details. A data model is different from a data dictionary. The model defines structure and relationships. The dictionary documents what each field means and where it comes from. The two complement each other.

The modeler interviews business users about their processes and the questions they need answered. From this, the modeler identifies the things the business tracks, the details held for each and how they relate. That includes how many of one relate to another, such as one customer having many orders. The modeler records business rules, such as every order must belong to a customer. Each type of record also gets an identifier, such as a customer number. For reporting models, the modeler decides the level of detail of each table, such as one row per order line. Business users review the model, and the modeler revises it as understanding improves.

A building services company keeps its customers in a spreadsheet with one row per customer and one site address column. One customer has 4 sites, each with its own contact and address, but the sheet holds only the first. Technicians booked for the other 3 sites arrive at the wrong address or call the wrong person. A new model separates Customer, Site and Contact. One customer can have many sites, and each site can have many contacts. If 50 customers each had about 2 missing sites, the old structure was hiding 100 sites. With the new model, the team stops sending technicians to the wrong place.

Modeling decisions determine which questions a system or report can answer later and how easily. Changing a model after the team builds a system and fills it with data is costly. When buying software, the vendor's model of customers, products and contracts shapes how well it fits the business. It is worth checking that model against real cases.

Over-detailed modeling can delay delivery without adding value. Models need updating as the business changes, such as when the company introduces a new pricing structure or service line. Technical diagrams can shut out business reviewers, so the modeler should explain models in plain terms. Packaged software comes with its own model, which may not match how the company works and can be expensive to adapt.