What a Data Model Is
A data model is the set of concepts used to describe data, relationships, semantics and constraints. Models are grouped as high level, representational and low level, and each level serves a different audience.
-
DBMS Fundamentals
- Data, Information and Databases
- What a DBMS Is and Why It Exists
- File System versus DBMS
- Advantages and Limitations of a DBMS
- Database Users and the Role of the DBA
- Three Level Architecture and Data Abstraction
- Logical and Physical Data Independence
- Schema, Instance and Metadata
- Database Applications and the Database System Environment
- Database Architecture
- Data Models
-
ER Model
- Entities, Entity Sets and Entity Types
- Types of Attributes in the ER Model
- Keys in the ER Model
- Relationships, Relationship Sets and Degree
- Cardinality and Participation Constraints
- Strong and Weak Entities
- Drawing and Reading ER Diagrams
- Extended ER: Generalisation, Specialisation and Aggregation
- Converting an ER Diagram into Relational Tables
- ER Design Projects
- Relational Model
- Relational Algebra
- Functional Dependencies
-
Normalisation
- Why Normalisation Exists: Anomalies and Redundancy
- First Normal Form
- Second Normal Form and Partial Dependency
- Third Normal Form and Transitive Dependency
- BCNF and BCNF Decomposition
- 4NF, 5NF, Multivalued and Join Dependencies
- Lossless Decomposition and Dependency Preservation
- Complete Worked Normalisation: Unnormalised to BCNF
- Denormalisation and When to Use It
Concept
A data model is a collection of concepts for describing four things about data:
- Structure — what shapes the data may take.
- Relationships — how one piece of data connects to another.
- Semantics — what the data means.
- Constraints — what values and combinations are legal.
Most notes mention only structure. All four belong in the definition, and the fourth is where marks are usually lost.
Why a data model is needed
Without an agreed model, everyone describes data differently and no design can be discussed, checked or implemented. The model provides a shared vocabulary — entity, attribute, relation, key — that designers, programmers and the DBMS all understand the same way.
The three categories of data model
| Category | Also called | Describes data using | Audience | Examples |
|---|---|---|---|---|
| High level | Conceptual | Entities, attributes, relationships — concepts close to how people think | Users and designers | ER model, extended ER model |
| Representational | Implementation | Structures a DBMS can implement, still understandable to people | Designers and programmers | Relational, hierarchical, network |
| Low level | Physical | Record formats, orderings, access paths | The DBMS and the DBA | Internal storage models, index structures |
HOW A DESIGN TRAVELS DOWN THE CATEGORIES
requirements in English
|
v
HIGH LEVEL ER diagram: STUDENT enrols in COURSE
|
v
REPRESENTATIONAL tables: students, courses, enrolments
| with primary and foreign keys
v
LOW LEVEL heap file for courses, B+ tree on roll_no,
16 KB pages, rows stored unordered
Each step down loses freedom and gains precision.Schema and instance, in model terms
A data model gives you the vocabulary for a schema. Applying the model produces a schema; filling the schema with data produces an instance. The model itself is neither — it is the rulebook both obey.
Important terminology
| Term | Meaning |
|---|---|
| Data model | Concepts for describing structure, relationships, semantics and constraints. |
| Structural part | The shapes the model allows. |
| Manipulation part | The operations the model defines for retrieving and changing data. |
| Integrity part | The rules the model can enforce. |
| Conceptual model | A high level model, independent of any product. |
| Logical model | A representational model, tied to a family of products. |
| Physical model | How it is actually stored. |
A complete data model has three parts: structure, operations and integrity rules. The relational model is famous partly because it defined all three precisely, and the earlier models did not.
Example
The same fact in three models
HIGH LEVEL (ER)
entity STUDENT with attributes roll_no, name
entity COURSE with attributes code, title
relationship ENROLS, many to many, with attribute marks
REPRESENTATIONAL (relational)
students ( roll_no, name )
courses ( code, title )
enrolments ( roll_no, code, marks )
roll_no references students
code references courses
LOW LEVEL (physical)
students heap file, B+ tree on roll_no
enrolments clustered on ( roll_no, code )
marks 2 byte integer, page size 16 KBCommon mistakes
- Defining a data model as only structure. Relationships, semantics and constraints belong in the definition.
- Confusing the model with the schema. The relational model is the rulebook; your college tables are a schema written using it.
- Treating the ER model as a database. It is a high level design notation, later converted to tables. No DBMS stores an ER diagram.
- Skipping the operations part. A model that describes shapes but not operations is incomplete.
Exam and interview questions
- Define a data model and list the four things it describes.
- Name the three categories of data model with two examples each.
- What are the three parts of a complete data model?
- Differentiate conceptual, logical and physical models.
- Where does the ER model sit, and where does the relational model sit?
Practice
- Classify each as high level, representational or low level: ER diagram, table definition, B+ tree index, extended ER diagram, record layout in a page.
- Take a library requirement in English and express it in all three categories, as in the example.
- Explain in two sentences why the constraints part of a model matters as much as the structure part.
Conclusion
A data model supplies the concepts for describing structure, relationships, meaning and rules. High level models are for people, representational models are for implementation, and low level models are for storage — and every real design travels down all three.