×

Courses

Chapters

>
<

DBMS

DBMS Abstraction & Independence | CrackEase

DBMS Abstraction & Independence

Data abstraction and independence diagram

Data abstraction and data independence describe different levels of data representation, storage and user view in a DBMS. They help provide security, manage complexity, and hide implementation details from users.

Data Abstraction

Definition: Data abstraction is the hiding of implementation details from users at certain levels, exposing only what is necessary for use or security.

Most DBMS architectures define three primary abstraction levels:

  • Conceptual level
  • Internal level
  • External level

Levels of Data Abstraction

1. Conceptual Level

The conceptual level describes the logical structure of the entire database. It specifies what data is stored, types, and relationships (e.g., primary key, foreign key, constraints).

Example: CREATE TABLE emp(id NUMBER(5) PRIMARY KEY, name VARCHAR2(50));

2. External Level

The external level describes the user's view of the database — different users or applications may see different subsets or formats of the data. It also enforces access restrictions and security for different user roles.

3. Internal Level

The internal level (lowest level) describes how data is physically stored: file structures, indexes, clusters and storage paths on disk. It details the complex data structures used for efficient storage and retrieval.

Data Independence

Levels of abstraction enable data independence — changes in one level should not require changes in others. DBMS provides two main types:

  • Logical Data Independence
  • Physical Data Independence

Logical Data Independence

Refers to the ability to change the conceptual schema (e.g., add or remove entities, attributes) without changing external views or application programs. Example: Adding a new column in the conceptual model should not require changes in user views that don't need that column.

Physical Data Independence

Means changes at the internal (physical) level — such as changing storage structures, indexing methods, or file organization — should not affect the conceptual schema or external views. Example: Changing an index or moving data files should not require changing application logic.

Footer Content | CrackEase
→
←