Structural dependence
A file system exhibits structural dependence, which means that access to a file is dependent on its structure. For example, adding a customer date-of-birth field to the CUSTOMER, Given this change, none of the previous programs will work with the new CUSTOMER file structure. Therefore, all of the file system programs must be modified to conform to the new file structure. In short, because the file system application programs are affected by change in the file structure, they exhibit structural dependence. Conversely, structural independence exists when it is possible to make changes in the file structure without affecting the application program’s ability to access the data.
Data dependence:
Even changes in the characteristics of data, such as changing a field from integer to decimal, require changes in all the programs that access the file. Because all data access programs are subject to change when any of the file’s data storage characteristics change (that is, changing the data type), the file system is said to exhibit data dependence.
Conversely, data independence exists when it is possible to make changes in the data storage characteristics without affecting the application program’s ability to access the data.
Data redundancy:
Data redundancy exists when the same data are stored unnecessarily at different places. The file system’s structure makes it difficult to combine data from multiple sources, and its lack of security renders the file system vulnerable to security breaches. The organizational structure promotes the storage of the same basic data in different locations. The different problems with data redundancy are:
Poor data security
Having multiple copies of data increases the chances for a copy of the data to be susceptible to unauthorized access.
Data inconsistency
Data inconsistency exists when different and conflicting versions of the same data appear in different places. For example, suppose you change an agent’s phone number or address in the AGENT file. If you forget to make Corresponding changes in the CUSTOMER file, the files contain different data for the same agent. Reports will yield inconsistent results that depend on which version of the data is used.
Data anomalies
The dictionary defines anomaly as “an abnormality.” Ideally, a field value change should be made in only a single place. Data redundancy, however, fosters an abnormal condition by forcing field value changes in many different locations. A data anomaly develops when not all of the required changes in the redundant data are made successfully.
The data anomalies are commonly defined as follows:
Update anomalies
If agent Leah F. Hahn has a new phone number, that number must be entered in each of the CUSTOMER file records in which Ms. Hahn’s phone number is shown. In this case, only three changes must be made. In a large file system, such a change might occur in hundreds or even thousands of records. Clearly, the potential for data inconsistencies is great.
Insertion anomalies
If only the CUSTOMER file existed, to add a new agent, you would also add a dummy customer data entry to reflect the new agent’s addition. Again, the potential for creating data inconsistencies would be great.
Deletion anomalies
If you delete the customers Amy B. O’Brian, George Williams, and Olette K. Smith, you will also delete John T. Okon’s agent data. Clearly, this is not desirable.
Find More DBMS Question and Answers
