Define Data Independence in a database system

The data independence can be defined as "the immunity of applications to change in storage structure and access techniques" which clearly implies that applications concerned do not depend on ally one particular storage structure or access technique.

We can also say that data independence is the ability to modify a schema definition in one level without affecting a schema in the next higher level.

Let us consider data type conversion on a particular field on each access. In principle, the difference between what the application sees and what is actually stored might be quite considerable, but that difference should not affect the user accessing the fields, hence this difference should be transparent to the user. To amplify this remark, we need to see the aspects of database storage structure that might be subject to variation.

1. Representation of numeric data: A numeric data field might be stored in internal arithmetic form (e.g., in packed decimal) or as a character string. Either way, the DBA must choose an. appropriate base (e.g., binary or decimal), scale (fixed or floating point), mode (real or complex), and precision (number of digits). Any of these aspects might be changed to improve performance or to conform to a new standard or for many other reasons.
2. Representation of character data: A character string field might be stored s sing any of several distinct coded character sets or "forms-of-use'' (e.g., ASCII, EBCDIC).
3. Units of numeric data: The units of numeric Field might change from inches to centimeters, for example, during a process of metrication.
4. Data encoding: We can be able to represent data in coded value, e.g., we can store "Red" as 1, "Blue" as 2 and "Green" as 3, etc., but the user should be able to access them as Red, Blue and Green only.
5. Structure of stored records: Two existing records might be combined into one, and alternatively, a single stored record type might be split into two.
6. Structure of stored files: A given stared file can be physically implemented in storage in a wide variety of ways. For example, it might be entirely contained within a single storage volume (e.g., a single disk), or it might be spread across several volumes on several different types; it might or might not be sorted based on certain attribute; it might be indexed or it might have one or more embedded pointer chains; it might or might not be accessible via hash addressing.

None of the above considerations should affect applications in any way. The database should be able to grow without affecting existing applications.