You never see the actual bytes — three levels stand between you and them
A DBMS hides how data is physically stored behind layers, the same way a function hides its implementation behind a signature. This lesson names those layers, and introduces the data model — the ER model in particular — that describes data at the topmost, most human-readable layer.
After this lesson
You should be able to
- Name the three levels of data abstraction and what each one hides.
- Distinguish a schema (the design) from an instance (the data at one moment).
A function signature hides the loop inside it
When you called a search function in CS205ES, you never needed to know whether it used a for loop or a while loop internally — the signature was a contract, and the implementation was free to change underneath it. A DBMS applies this exact idea to data itself, through three levels of abstraction. The physical level describes how data is actually stored on disk — file blocks, indexes, byte layouts. Most users, and even most application programmers, never see this level at all.
The logical level describes what data is stored and what relationships exist among it — this is where a database administrator works, and where tables, columns, and constraints are defined. The view level is the topmost layer: what a specific application or user actually sees, often a small slice of the logical level, hiding parts they do not need. A fee-office screen and a library screen can be two different views over the same underlying student data.
Schema is the blueprint, instance is one moment in time
A schema is the overall design — "a Student has a roll number, a name, and a branch" — and it rarely changes. An instance is the actual data in the database at one specific moment — today's 3,000 student rows. This is exactly like a struct definition versus a variable of that struct type in C: the struct definition (schema) stays fixed while the code runs, but the values inside a particular variable (instance) change constantly.
The ER model: describing data before there is a single table
A data model is a set of concepts used to describe a database's structure at the logical level. The most common one for design is the Entity-Relationship (ER) model, which describes the world as things (entities, like a Student) and connections between things (relationships, like a Student enrolling in a Course) — pure structure, with no mention of rows or SQL yet. The relational model, which the next unit covers, is where that design finally becomes actual tables with rows and columns. Other models exist (object-based, semi-structured) but the ER model and relational model are this course's focus, matching the industry-standard path from design to implementation.
Try it yourself
For a college library database, write one schema-level fact ("a Book has ...") and one instance-level fact (an actual book's actual details). Then say which of the three abstraction levels each fact belongs to.
Need a hint?
"A Book has an ISBN, a title, and an author" describes structure and belongs at the logical level, regardless of any specific book.
Check the worked solution
"A Book has an ISBN, a title, and an author" is a schema-level fact at the logical level — it describes the structure, true for every book, and stays fixed across time. "The book with ISBN 978-0-13 is titled Database System Concepts by Silberschatz" is an instance-level fact — one row of actual data, true today but potentially edited or removed tomorrow.
Quick check
Why does the physical level of data abstraction stay invisible to most application programmers?
Why this lesson exists
Syllabus mapping
View of Data, Data Abstraction, Instances and Schemas · Data Models, the ER Model, Relational Model, Other Models
Maps to course outcome CO1.