Data model Study Guide

📖 Core Concepts Data Model – Abstract representation that organizes data elements and defines their relationships to real‑world entities. Data Modeling – Professional activity of creating data models; often synonymous with database design. Three‑Schema Architecture – Conceptual (what the domain means), Logical (how a specific technology expresses the semantics), Physical (how data are actually stored). Entity‑Relationship (ER) Model – Visual diagram using entities (boxes), attributes (inside boxes), and relationships (lines) with cardinality constraints. Semantic Data Model – Captures the meaning of data by linking stored symbols to real‑world concepts. Data Model Theory – Consists of Structure (data structures), Integrity (constraints/rules), and Manipulation (query/update operators). 📌 Must Remember Codd’s Relational Model (1960s) → basis for tables, relational algebra, and first‑order logic constraints. Chen’s ER Model (1970s) → standard for conceptual design during requirements analysis. Three Perspectives Independence – Changing storage (physical) does not require changes to conceptual model if logical schema stays consistent. Data Properties – Relevance, Clarity, Consistency, Timeliness, Accuracy, Completeness, Accessibility, Cost. Modeling Patterns – Reusable structures (e.g., hierarchy, association class, many‑to‑many bridge) that solve common design problems. 🔄 Key Processes Requirements Gathering → Identify business facts, entities, attributes, relationships. Conceptual Modeling → Draft ER diagram; define entity classes, primary keys, cardinalities, integrity rules. Logical Modeling → Translate conceptual model to a technology‑specific schema (tables/columns, classes, XML tags). Physical Modeling – Choose storage details (tablespaces, partitions, indexes, file formats). Validation – Check for consistency, completeness, and integrity across all three schemas. 🔍 Key Comparisons Conceptual vs. Logical vs. Physical Conceptual: “What” the domain means – entity types & relationships. Logical: “How” the meaning is expressed in a specific DBMS – tables, classes, XML. Physical: “Where” and “in what form” data live – disks, tablespaces, indexes. Entity‑Relationship vs. Semantic Data Model ER: Focus on structure (entities, attributes, cardinalities). Semantic: Emphasizes meaning and real‑world interpretation; may include richer constraints and inference rules. Structured vs. Unstructured vs. Semi‑structured Data Structured: Conforms to a strict data model (relational tables). Semi‑structured: Partial schema (e.g., XML, JSON). Unstructured: No predefined schema (e.g., images, free‑text). ⚠️ Common Misunderstandings “Data model = data structure” – A model is an abstract schema; a structure is a concrete implementation (e.g., a linked list). Changing a physical schema always breaks the logical model – Not true if the logical schema remains consistent; physical changes can be transparent. ER diagrams capture business rules – They show relationships and cardinality but often omit complex constraints (e.g., temporal rules) that belong in integrity specifications. 🧠 Mental Models / Intuition Three‑Layer “Map” Analogy: Conceptual = city map (landmarks, streets). Logical = GPS route (how you navigate using the map). Physical = road surface (asphalt, bridges). “Grammar of Data” – Think of a data model as the grammar that tells you how to form valid “sentences” (records) in the data language. 🚩 Exceptions & Edge Cases Many‑to‑many relationships – Must be resolved with an associative (bridge) entity; otherwise physical tables cannot directly store the relationship. Inheritance in Object‑Oriented Models – Not all relational DBMS support true inheritance; need to emulate via tables or views. Temporal Data – Standard ER does not capture time‑varying attributes; requires extensions (e.g., temporal ER or versioning tables). 📍 When to Use Which ER Diagram – Early requirements phase; stakeholder communication. Logical Relational Schema – When implementing in a relational DBMS; need precise column types and keys. Object Model / UML Class Diagram – For object‑oriented applications or when generating code from the model. Data‑Flow Diagram – To illustrate how data move between processes, not to define storage structure. Semantic Model – When domain meaning and inference are critical (e.g., knowledge graphs, ontologies). 👀 Patterns to Recognize Bridge Entity – Look for a linking table when two entities have a many‑to‑many cardinality. Hierarchy / Tree – Entity with a recursive relationship (e.g., Employee → Manager). Subclass / Superclass – Entity that shares attributes with multiple specialized entities. Weak Entity – Entity that depends on another for identification (identified by a partial key plus foreign key). 🗂️ Exam Traps “All ER diagrams are complete models.” – ER diagrams often omit integrity constraints (e.g., check constraints, triggers). Choosing physical storage based on logical design alone. – Ignoring access patterns can lead to poor performance; indexes and partitioning are physical considerations. Confusing “attribute” with “relationship”. – Attributes describe properties of an entity; relationships link distinct entities. Assuming “structured data = relational tables.” – Structured data can also be stored in NoSQL column families or object stores that still obey a schema. Over‑relying on cardinality symbols. – Different notations (crow’s feet vs. numbers) mean the same thing; misreading them can flip a one‑to‑many into many‑to‑one.