Abstraction, Users & Architecture

Lecture 1 · the three abstraction levels, data independence, who works with a database, and how DBMS systems are structured.

Three levels of data abstraction

PLVBottom → top: Physical → Logical → View.

Level	Also called	Describes	Who works here
Physical	Internal	How data is stored — structures, disk allocation, indexing (B+-tree, hashing)	DBA
Logical	Conceptual	What data exists + relationships & constraints	Designers / programmers
View	External	Per-user slices — forms, charts, reports (security & simplicity)	End users

Data independence: change one level without disturbing the one above. Physical independence = storage changes don't affect the logical schema; logical independence = logical changes don't affect user views.

Database users & roles

User	One-line job	Does
DBA	Runs the machine	Install, configure, security, backup, tuning; technical management
Database Designer	Plans the blueprint	Identify data requirements; design conceptual/logical schema; define constraints & relationships
Application Programmer	Writes the code	Develop apps, write embedded SQL / API calls (“most CS grads start here”)
End Users	Just uses it	Casual (forms) · sophisticated (SQL/reports) · standalone (personal DBs) · naïve/parametric (repetitive forms)

DBMS architectures

Architecture	Key idea	Trade-off	Example use
Centralized	One server; all storage + processing	Simple but single point of failure	Small, single-branch orgs
Client-Server	Clients = UI, server = data (2/3-tier)	Scales clients; server can overload	Banking, university, enterprise
Distributed	Data across sites (fragmentation + replication)	Fault-tolerant but complex	Multinationals, cloud
Parallel	Parallel query execution (shared-memory / -disk / -nothing)	Very fast but costly hardware	Data warehousing, big-data analytics

Ready for the exam view of these ideas? Part 1 — Concepts (solved) →