ANSI/X3/SPARC Three Schema Architecture
In 1975, the ANSI/SPARC (American National Standards Institute/Standards Planning And Requirements Committee) Study Group on Data Base Management Systems made its initial interim report on an architecture for database management systems that the committee felt should become an industry standard for the design of commercial database management systems (Bachman et al., 1975).
The ANSI/SPARC architecture was not specifically designed for relational databases, which were not commercially available at the time the interim report was published. Explicitly referring to the hierarchical, network, and relational models, the report notes that “Much of the work [on the architecture] has been driven by the desire to accommodate the various requirements statements and differing viewpoints.”
Perhaps the most interesting aspect of the model for relational databases is its pioneering work highlighting the need for data independence. Data independence is a default property of relational databases that hides both the organization of the data and its access from the requesting user or user application.
The report introduces the concept of data independence in the following, rather long‑winded and strangely worded section, which is the entirety of its Section 1.7: Binding and Mapping of Objects to Each Other:
“Entities and properties of entities can be represented by: objects, the descriptors of which are declared in a source program (e.g., a data division); objects, the descriptors of which are defined in a relational external schema, defined in a Cobol external schema, defined in an accountant’s external schema, and/or defined in a canonical external schema. The descriptors of objects declared in a source program, either directly or from an external schema, are bound to descriptors of objects defined in the conceptual schema. the objects, the descriptors of which are declared in these schemas are all abstract: the internal data is actually stored in objects, the descriptors of which are declared in the internal schema. The objects, the descriptions of which are defined in the conceptual schema, are mapped to objects, the description of which are defined in the internal schema. This does not imply any specific one‑to‑one mapping among these objects.
“An object that is local to an application’s external model, may be not represented by internal data, and may be not under the control of the enterprise administrator. In this case, there is no object defined in the conceptual schema to which the object defined in the external schema can be bound.
“The conceptual schema may contain descriptors of objects that may be not represent4ed by internal data. This may be during the development of augmentations to the conceptual schema, before defining and collecting internal data, or to increase the understanding of the interrelationships between data stored in this data base and data stored in another data base or data that is not machine processable. In this case, it is not envisioned that any object defined in an external schema would be bound to such an object defined in the conceptual schema, except for testing.” (Bachman et al., 1975, pages II-5 - II-6).
This property makes it possible to extract information from a database without specifying, or even knowing, how to access the underlying data in the database. In a relational database management system, the query optimizer plays the role of a surrogate user and specifies all the particulars of accessing the data.
The implementation of data independence also makes it possible to change the storage structure of the database without changing, in any way, the code used to access the data in the database.