Business Data Models

Conceptual, Logical, and Physical Data Models

Start with the business picture. For customers and orders, identify the entities and how they relate before choosing database-specific types or indexes.

The conceptual model captures that meaning. It should make sense to someone discussing the business without requiring them to know how a table is stored.

The logical model adds attributes, identifiers, and relationships. It states what the data must represent without committing to all the details of one database.

The physical model turns those choices into tables, data types, keys, and storage details for the selected system.

Review the meaning at each transition. A convenient physical implementation should preserve the relationships established in the earlier views.

Normalization

Normalization separates facts that depend on different keys. The aim is to avoid storing the same fact in several places and having those copies disagree.

Work through the dependencies, not just the table count. Each non-key attribute should describe the key of its own table. Third normal form is a common practical target.

First normal form uses single values in fields and a key that identifies each row. A repeated or nested collection needs a clear relational representation.

Second normal form removes partial dependencies: with a composite key, a non-key field must not depend on only one part of that key.

Third normal form also removes transitive dependencies. A non-key field should describe the row’s key, rather than depending on another non-key field.

Analytical systems may deliberately denormalize for easier reads. Make that choice after the underlying relationships are clear.

Relational Model Versus Document Model

A relational model represents data as rows and relationships between tables. A document model keeps related, nested information together in a document.

A user profile with its own nested work history can be convenient to read as one document. The related details travel together without a join for every nested item.

That advantage changes when many profiles share an organization or other independently updated entity. Decide where shared information belongs and how changes will reach its readers.

Look at how the application reads and changes the data. A self-contained document can suit nested records; relationships across many records may still need joins or application logic.

Complete workflow