Data model - History and Advanced Techniques

Historical Development of Data Modeling Data modeling has evolved significantly over the past several decades, with each new approach building upon or reacting to previous techniques. Understanding this history helps you appreciate why certain modeling approaches are used today and what problems they were designed to solve. The Relational Model and Entity-Relationship Model The Relational Model emerged in the late 1960s when Edgar Frank Codd proposed a revolutionary approach to database management. Based on mathematical foundations (first-order predicate logic), the relational model represented data as tables with rows and columns, connected through keys. This was groundbreaking because it provided a formal, structured way to organize and query data. The Entity-Relationship Model (ER Model) came next in the 1970s through Peter Chen's work. While the relational model focused on how to store data physically in databases, the ER model served a different purpose: it provided a way to conceptually design databases during the requirements analysis phase. The key distinction here is important: ER modeling happens before you decide on tables and relationships. An ER diagram shows entities (things in your domain), their attributes (properties), and the relationships between entities. For example, in a university system, you might identify entities like "Student," "Course," and "Instructor," then map out how they relate to each other. Once you have this conceptual design, you can then transform it into relational tables. Object-Role Modeling and Object-Oriented Influence The 1980s brought a fundamental shift in how people thought about data and operations together. The object-oriented paradigm introduced the idea that data and the procedures that operate on that data should be packaged together into objects. This was a departure from earlier approaches, which separated data structures from the functions that manipulated them. This shift meant that data modeling could no longer ignore operations. Instead of just asking "what data do we store?", the question became "what objects do we have, and what can they do?" This led to modeling approaches like Object-Role Modeling (ORM) that extended earlier concepts to account for both structure and behavior. Auxiliary Modeling Techniques Beyond the core approaches above, several other modeling techniques have become important tools for system design. These techniques serve different purposes and often work alongside data models. Data-Flow Diagrams A data-flow diagram (DFD) is a visual tool that shows how data moves through a system. Think of it as a map of information flow, rather than a map of how the system executes operations. Key components of a DFD include: Processes: Activities that transform data (shown as circles or bubbles) Data flows: Movements of data between processes, shown as labeled arrows Data stores: Places where data is held (shown as parallel lines) External entities: Things outside your system that interact with it (shown as squares) The crucial distinction is that DFDs focus on data movement, not program control flow. For example, if you were modeling a library system, a DFD might show "Checkout" as a process that receives data (member ID, book ID) from a Member and updates the "Books Checked Out" data store. This is different from a flowchart, which would show the step-by-step logic of how the checkout works. Information Models An information model is a structured representation of the information requirements for a domain. It formally captures entity types, their properties, relationships, constraints, rules, and operations. The power of an information model is that it exists at a level of abstraction above any particular technology. You can create an information model that works independently of whether you'll eventually implement it as a relational database, an XML schema, or an object-oriented system. This makes information models valuable for communicating requirements across teams and technologies. Think of it this way: an information model says "here's what information we need to represent and how it relates." A data model says "here's how we'll actually structure and store that information in a particular system." Object Models An object model is a collection of objects (or classes in programming terms) that represent aspects of the real world relevant to your system. An object model provides an object-oriented interface to a service or system, allowing the program to examine and manipulate parts of the domain it represents. For example, in an e-commerce system, you might have an object model with classes like Customer, Product, Order, and Payment. Each class encapsulates both data (customer name, email) and methods (place order, process payment). Object models are particularly useful for implementation in object-oriented programming languages and for understanding how systems should behave. Unified Modeling Language The Unified Modeling Language (UML) is a standardized, general-purpose modeling language used throughout software engineering. It provides a visual notation for specifying, constructing, and documenting system artifacts. UML is remarkably flexible—it can represent both high-level abstractions and concrete details: Conceptual level: Business processes, system requirements, and domain concepts Concrete level: Database schemas, programming code structure, and reusable components UML includes many different types of diagrams, each suited for different purposes. Class diagrams show object structures, sequence diagrams show how objects interact over time, use case diagrams show system functionality, and many others exist. Because of its standardization and flexibility, UML has become the lingua franca of software design. The diagram above illustrates an important concept: modeling happens at multiple levels of abstraction. External views show how the system appears to different users, the conceptual level models the logical structure, and the physical level shows actual implementation details.