Data modeling produces a set of structures for a relational database management system (RDBMS). First, we build the conceptual data model (CDM) to capture the common business language for the initiative (for example, “What is a customer?”). Next, we create the logical data model (LDM) using the common business language of the CDM to define the business requirements (for example, “I need to see the name and address of the customer in this report.”). In the physical data model (PDM), we design these business requirements specific to a particular technology, such as Oracle, Teradata, or SQL Server. For example, “Customer last name is a variable length not null field with a non-unique index.” Our PDM represents the RDBMS design for an application. We then generate the data definition language (DDL) from the PDM, which we can run within an RDBMS environment to create the set of tables that will store the data of the application. To summarize, we go from common business language to business requirements to design to tables.
Although the conceptual, logical, and physical data models have played a very important role in application development over the last forty years, they will play an even more important role over the next forty years. Regardless of the technology, data complexity, or breadth of requirements, there will always be a need for a diagram that captures the business language (conceptual), the business requirements (logical), and the design (physical). These diagrams continue to prove useful in more and more types of projects.
Read the 27-page whitepaper “MongoDB and JSON Data Modeling” by Steve Hoberman to learn more about NoSQL modeling principles with MongoDB and interchange formats with JavaScript object notation (JSON) using an animal shelter case study.