Data Independence

 


Data Independence


A major objective for the three-level architecture is to provide data independence, which means that upper levels are unaffected by changes to lower levels. There are two kinds of data independence: logical and physical.


Logical data independence


Logical data independence refers to the immunity of the external schemas to changes in the conceptual schema.

Changes to the conceptual schema, such as the addition or removal of new entities, attributes, or relationships, should be possible without having to change existing external schemas or having to rewrite application programs. 

Clearly, the users for whom the changes have been made need to be aware of them, but what is important is that other users should not be.


Physical data independence

Physical data independence refers to the immunity of the conceptual schema to changes in the internal schema.

Changes to the internal schema, such as using different file organizations or storage structures, using different storage devices, modifying indexes, or hashing algorithms, should be possible without having to change the conceptual or external schemas. 

From the users’ point of view, the only effect that may be noticed is a change in performance. In fact, deterioration in performance is the most common reason for internal schema changes. 


Data independence


                    Figure - Data independence



Figure where each type of data independence occurs in relation to the three level architecture. The two-stage mapping in the ANSI-SPARC architecture may be inefficient, but provides greater data independence. 

However, for more efficient mapping, the ANSI-SPARC model allows the direct mapping of external schemas on to the internal schema, thus bypassing the conceptual schema. 

This, of course, reduces data independence, so that every time the internal schema changes, the external schema, and any dependent application programs may also have to change.


Comments

Post a Comment

Popular posts from this blog

Limitations of the File-Based Approach

  Limitations of the File-Based Approach This brief description of traditional file-based systems should be sufficient to discuss the limitations of this approach .  1 . Separation and isolation of data When data is isolated in separate files, it is more difficult to access data that should be available. With file systems, such processing is difficult. The application developer must synchronize the processing of two files to ensure the correct data is extracted. This difficulty is compounded if we require data from more than two files. 2 . Duplication of data Owing to the decentralized approach taken by each department, the file-based approach encouraged, if not necessitated, the uncontrolled duplication of data . Uncontrolled duplication of data is undesirable for several reasons, including: Duplication is wasteful. It costs time and money to enter the data more than once.  It takes up additional storage space, again with associated costs. Often, the duplication of data...
Read more

The Three-Level ANSI-SPARC Architecture

Image
  The Three-Level ANSI-SPARC Architecture For our purposes, the fundamental point of these and later reports is the identification of three levels of abstraction, that is, three distinct levels at which data items can be described. The levels form a three-level architecture comprising an external, a conceptual, and an internal level . The way users perceive the data is called the external level.  The way the DBMS and the operating system perceive the data is the internal level, where the data is actually stored using the data structures and file organizations . The conceptual level provides both the mapping and the desired independence between the external and internal levels.  The objective of the three-level architecture is to separate each user’s view of the database from the way the database is physically represented. There are several reasons why this separation is desirable: Each user should be able to access the same data, but have a different customized view...
Read more

Roles of DA , DBA , Database Designer , Application Developers and Users

  Roles of Data Administrator(DA) , Database Administrator (DBA) , Database Designer , Application Developers and Users Here i will explain all peoples who are involved in DBMS in two parts  Actors on the scene Workers behind the scene . Actors on the scene Roles of Data Administrator The Data Administrator (DA) is responsible for the management of the data resource including database planning, development and maintenance of standards, policies and procedures, and conceptual/logical database design.  The DA consults with and advises senior managers, ensuring that the direction of database development will ultimately support corporate objectives. "Person in the organization who controls the data of the database refers data administrator." DA determines what data to be stored in database based on requirement of the organization. DA works on such as requirements gathering, analysis, and design phases. DA does not to be a technical person, any kind of knowledge about database...
Read more