Data independence is also called Data abstraction. In the 3-level architecture of D.B.M.S, we see the purpose of all three levels of architecture. In data independence, we discuss the use of these levels. Data independence is the concept of making data independent from the users.
The basic aim of the user is to access data, and the demand of the user is:
- Data must be available 24X7 on servers and
- Data can be accessed from anywhere at any time.
Here we have to fulfill the user’s demands but make them independent from the user. It means we hide some information from the user like
- Where all data stored,
- How data are stored in the database,
- What are the indexing module applied during storing of data,
- Uses of different data structures,
- Numbers of tables,
- Types of tables and their names,
- Constraints like primary key, foreign key, and other logic.
Why do we need to hide all this information?
We need to hide all this information from the user because the user accesses the data from the database through some interface like a web application or mobile application.
Here we can disclose all the things to the user because:
1. Most information is irrelevant to the user and makes the information complex.
2. It also protects data from security risks.
Now, the problem with this data independence concept is to change at one level of architecture not affect another level. So it is divided into two categories:
Types of Data Independence
- Logical data independence
- Physical data independence
Difference between Physical and Logical Data Independence
Logical data independence
Changing the logical schema or at a conceptual level without affecting the external schema or at the view level is known as logical data independence.
It gives independence to only external schema and some application programs.
For example: If we want to change the logic like constraints, or the type of table at the conceptual level of D.B.M.S. these changes cannot affect the view level, web application, or mobile application interface. This is because of Logical data independence.
Physical data independence
Physical data independence says that without any change at the conceptual level, it is possible to make changes at the physical level because of physical data independence.
It gives independence to the conceptual schema.
For example: If we want to change data structure or place of storage at the physical level of architecture without affecting the tables and their attributes at the conceptual level. This is only possible because of physical data independence.
Physical Data Independence VS Logical Data Independence
| Feature | Logical Data Independence | Physical Data Independence |
|---|---|---|
| Definition | The capacity to change the schema at the conceptual level without altering the schema at the external level or rewriting application programs. | The ability to change the schema at the internal level without altering the schema at the conceptual level or affecting application programs. |
| Focus | Changes in the conceptual schema (tables, columns, relationships, etc.) | Changes in the physical storage of data (storage devices, compression methods, data paths, etc.) |
| Type of Changes | Changes include adding new entities, attributes, or relationships; modifying data types or constraints; and reorganizing the database structure. | Changes involve altering data storage structures, switching storage devices, changing indexing strategies, or optimizing query performance. |
| Impact on Applications | Applications remain unaffected when changes are made to the database structure, provided the external view remains consistent. | Applications remain unaffected by how data is physically stored or accessed, ensuring consistent performance and data access patterns. |
| Example | Modifying the database to add a new column to a table without changing how the application queries the table. | Moving data to a new storage system or implementing new compression techniques without altering the application’s query or update operations. |
| Aim | To ensure that the evolution of the conceptual schema, driven by changing business requirements, does not disrupt application operations. | To ensure that the physical organization of data can evolve for efficiency and performance optimization without impacting the logical structure of the database. |