Data models play a key role in bringing together all segments of an enterprise – IT, business analysts, management and others – to cooperatively design information systems (and the databases they rely on).
These systems require properly defined and formatted data, and models shine a clear light on what data is required and how it must be structured to support the desired business processes.
By explicitly determining the structure of your data, these models support a variety of use cases, including database modeling, information system design, and process development in support of a consistent, clean exchange of data.
It’s also important to understand the three different types of data models. Each will serve a different purpose as you work through the data modeling process.
Also known as domain models, conceptual data models explore and detail your high-level, static business structures and concepts. They are most frequently used during the beginning of a new project, when high-level concepts and initial requirements are hashed out. Often, they are created as precursors or alternatives to the next stage: logical data models.
After your problem domain and initial concepts become more clear through conceptual data modeling, it’s time to get more specific with a logical data model. Whether you’re looking through the lens of a single project or your entire enterprise, these models clarify the various logical entities (types or classes of data) you’ll be working with, the data attributes that define those entities, and the relationships between them.
When you get to the physical data modeling stage, it’s truly time to get down to the nitty-gritty. These models are used to design the internal schema of a database. That includes all of the various tables, the columns on those tables and the relationships between them. These models will be directly translated into production database design, which will support further development of information systems. Physical data models generally are used to design three types of databases: relational for traditional operational databases, document for NoSQL and JSON databases, and dimensional for aggregation and business intelligence data stores such as data warehouses and data marts.
Ultimately, all three models can and should work independently of each other. But as your project matures, the best results will come from a natural progression through all three models. Of course, consistency must be maintained across the models on a structural level. Adjusting the table/column format on a physical model, for example, should not change the initial conceptual model in any meaningful way.
By leveraging all three models, organizations can ensure their projects do not lose sight of initial objectives – but still maintain the flexibility to address unexpected changes in requirements or parameters.