![Fundamental of Database Systems: Data Models and Database System Architecture
Page 10
External View 1
Staff_No FName Salary
External View 2
FName DOB
Conceptual Level
Staff_No FName LName DOB Salary Branch_No
Internal Level
struct STAFF{
int Staff_No;
int Branch_No;
char FName[15];
char LName[15];
struct DOB;
float salary;
}
Fig. Differences between Three Levels of ANSI-SPARC Architecture
The ANSI-SPARC Architecture Defines DBMS schemas at three levels:
Internal schema
o at the internal level to describe physical storage structures and access paths.
Typically uses a physical data model.
Conceptual schema
o at the conceptual level to describe the structure and constraints for the whole
database for a community of users. Uses a conceptual or an implementation data
model.
External schemas
o at the external level to describe the various user views. Usually uses the same data
model as the conceptual level.](https://image.slidesharecdn.com/2-230504131445-f99e473f/85/2-Chapter-Two-pdf-10-320.jpg)
2. Chapter Two.pdf
- 1. Fundamental of Database Systems: Data Models and Database System Architecture Page 1 CHAPTER TWO DATABASE SYSTEM ARCHITECTURE Data Models, Schemas, and Instances One fundamental characteristic of the database approach is that it provides some level of data abstraction by hiding details of data storage that are not needed by most database users. A data model is a collection of concepts that can be used to describe the structure of a database and also it provides the necessary means to achieve this abstraction. By structure of a database, we mean the data types, relationships, and constraints that should hold for the data. Most data models also include a set of basic operations for specifying retrievals and updates on the database. In addition to the basic operations provided by the data model, it is becoming more common to include concepts in the data model to specify the dynamic aspect or behavior of a database application. This allows the database designer to specify a set of valid user defined operations that arc allowed on the database objects. An example of a user-defined operation could be COMPUTE_GPA, which can be applied to a STUDENT object. On the other hand, generic operations to insert, delete, modify, or retrieve any kind of object are often included in the basic data model operations. Categories of Data Models Many data models have been proposed, which we can categorize according to the types of concepts they use to describe the database structure. High-level or conceptual data models provide concepts that are close to the way many users perceive data, whereas low-level or physical data models provide concepts that describe the details of how data is stored in the computer. Concepts provided by low-level data models are generally meant for computer specialists, not for typical end users. Between these two extremes is a class of representational (or implementation) data models, which provide concepts that may be understood by end users but that are not too far removed from the way data is organized within the computer. Representational data models hide some details of data storage but can be implemented on a computer system in a direct way. Conceptual data models use concepts such as entities, attributes, and relationships. An entity represents a real-world object or concept, such as an employee or a project that is described in
- 2. Fundamental of Database Systems: Data Models and Database System Architecture Page 2 the database. An attribute represents some property of interest that further describes an entity, such as the employee's name or salary. A relationship among two or more entities represents an association among two or more entities, for example, a works-on relationship between an employee and a project. Representational or implementation data models are the models used most frequently in traditional commercial DBMSs. These include the widely used relational data model, as well as the so-called legacy data models-the network and hierarchical models-that have been widely used in the past. Representational data models represent data by using record structures and hence are sometimes called record-based data models. We can regard object data models as a new family of higher-level implementation data models that are closer to conceptual data models. FIGURE 1.2 A database that stores student and course information.
- 3. Fundamental of Database Systems: Data Models and Database System Architecture Page 3 Hierarchical Data Model In the hierarchical data model, information is organized as a collection of inverted trees of records. The inverted trees may be of arbitrary depth. The record at the root of a tree has zero or more child records; the child records, in turn, serve as parent records for their immediate descendants. This parent-child relationship recursively continues down the tree. The records consists of fields, where each field may contain simple data values (e.g. integer, real, text)., or a pointer to a record. The pointer graph is not allowed to contain cycles. Some combinations of fields may form the key for a record relative to its parent. Applications can navigate a hierarchical database by starting at a root and successively navigate downward from parent to children until the desired record is found. Applications can interleave parent-child navigation with traversal of pointers. Searching down a hierarchical tree is very fast since the storage layer for hierarchical databases use contiguous storage for hierarchical structures. All other types of queries require sequential search techniques. The hierarchical data model is impoverished for expressing complex information models. Often a natural hierarchy does not exist and it is awkward to impose a parent-child relationship. Pointers partially compensate for this weakness, but it is still difficult to specify suitable hierarchical schemas for large models. Hierarchical Data Model Summary The simplest data model Record type is referred to as node or segment The top node is the root node Nodes are arranged in a hierarchical structure as sort of upside-down tree A parent node can have more than one child node A child node can only have one parent node The relationship between parent and child is one-to-many Relation is established by creating physical link between stored records (each is stored with a predefined access path to other records) Corresponds to a number of natural hierarchically organized domains - e.g., assemblies in manufacturing, personnel organization in companies
- 4. Fundamental of Database Systems: Data Models and Database System Architecture Page 4 Fig. Example of Hierarchical data model Network Data Model In the network data model, information is organized as a collection of graphs of record that are related with pointers. Network data models represent data in a symmetric manner, unlike the hierarchical data model (distinction between a parent and a child). A network data model is more flexible than a hierarchical data model and still permits efficient navigation. The records consists of lists of fields (fixed or variable length with maximum length), where each field contains a simple value (fixed or variable size). The network data model also introduces the notion of indexes of fields and records, sets of pointers, and physical placement of records. Network Data Model Summary Allows record types to have more that one parent unlike hierarchical model A network data models sees records as set members Each set has an owner and one or more members Allow no many to many relationship between entities Like hierarchical model network model is a collection of physically linked records. Allow member records to have more than one owner Database contains a complex array of pointers that thread through a set of records.
- 5. Fundamental of Database Systems: Data Models and Database System Architecture Page 5 Fig. Many-to-many relationship defined using Network data type Relational Data Model In the relational data model, information is organized in relations (two-dimensional tables). Each relation contain a set of tuples (records). Each tuple contain a number of fields. A field may contain a simple value (fixed or variable size) from some domain (e.g. integer, real, text, etc.). The relational data model is based on a mathematical foundation, called relational algebra. This mathematical foundation is the cornerstone to some of the very attractive properties of relational databases, since it first of all offers data independence, and offers a mathematical framework for many of the optimizations possible in relational databases (e.g. query optimization). Relational Data Model Summary Developed by Dr. Edgar Frank Codd in 1970 (famous paper, 'A Relational Model for Large Shared Data Banks') Viewed as a collection of tables called “Relations” equivalent to collection of record types Stores information or data in the form of tables .. rows and columns A row of the table is called tuple.. equivalent to record A column of a table is called attribute.. equivalent to field The tables seem to be independent but are related some how. Conducts searches by using data in specified columns of one table to find additional data in another table In conducting searches, a relational database matches information from a field in one table with information in a corresponding field of another table to produce a third table that combines requested data from both tables Can define more flexible and complex relationship
- 6. Fundamental of Database Systems: Data Models and Database System Architecture Page 6 Schemas, Instances, and Database State In any data model, it is important to distinguish between the descriptions of the database and the database itself. The description of a database is called the database schema, which is specified during database design and is not expected to change frequently. Most data models have certain conventions for displaying schemas as diagrams. A displayed schema is called a schema diagram. Figure 2.1 shows a schema diagram for the database shown in Figure 1.2; the diagram displays the structure of each record type but not the actual instances of records. We call each object in the schema-such as STUDENT or COURSE-a schema construct. A schema diagram displays only some aspects of a schema, such as the names of record types and data items, and some types of constraints. Other aspects are not specified in the schema diagram; for example, Figure 2.1 shows neither the data type of each data item nor the relationships among the various files. Many types of constraints are not represented in schema diagrams. A constraint such as "students majoring in computer science must take CS1310 before the end of their sophomore year" is quite difficult to represent. The actual data in a database may change quite frequently. For example, the database shown in Figure 1.2 changes every time we add a student or enter a new grade for a student. The data in the database at a particular moment in time is called a database state or snapshot. It is also called the current set of occurrences or instances in the database. In a given database state, each schema construct has its own current set of instances; for example, the STUDENT construct will contain the set of individual student entities (records) as its instances. Many database states can be constructed to correspond to a particular database schema. Every time we insert or delete a record or change the value of a data item in a record, we change one state of the database into another state. The distinction between database schema and database state is very important. When we define a new database, we specify its database schema only to the DBMS. At this point, the corresponding database state is the empty state with no data. We get the initial state of the database when the database is first populated or loaded with the initial data. From then on, every time an update operation is applied to the database, we get another database state. At any point in time, the database has a current state. The DBMS is partly responsible for ensuring that every state of the database is a valid state-that is, a state that satisfies the structure and constraints
- 7. Fundamental of Database Systems: Data Models and Database System Architecture Page 7 specified in the schema. Hence, specifying a correct schema to the DBMS is extremely important, and the schema must be designed with the utmost care. The DBMS stores the descriptions of the schema constructs and constraints-also called the meta-data-in the DBMS catalog so that DBMS software can refer to the schema whenever it needs to. The schema is sometimes called the intension, and a database state an extension of the schema. Although, as mentioned earlier, the schema is not supposed to change frequently, it is not uncommon that changes need to be occasionally applied to the schema as the application requirements change. For example, we may decide that another data item needs to be stored for each record in a file, such as adding the DateOfBirth to the STUDENT schema in Figure 2.1. This is known as schema evolution. Most modern DBMSs include some operations for schema evolution that can be applied while the database is operational. STUDENT CourseName CourseNumber CreditHours Department COURSE SectionIdentifier CourseNumber Semester Year Instructor SECTION FIGURE 2.1 Schema diagram for the database in Figure 1.2. Name StudentNumber Class Major
- 8. Fundamental of Database Systems: Data Models and Database System Architecture Page 8 THREE-SCHEMA ARCHITECTURE AND DATA INDEPENDENCE Three of the four important characteristics of the database approach, are (1) insulation of program; and data (program-data and program-operation independence), (2) support of multiple user views, and (3) use of a catalog to store the database description (schema). In this section we specify an architecture for database systems, called the three-schema architecture also known as the ANSI/SPARC architecture, that was proposed to help achieve and visualize these characteristics. We then further discuss the concept of data independence. The Three-Schema Architecture The goal of the three-schema architecture, illustrated in Figure 2.2, is to separate the user applications and the physical database. In this architecture, schemas can be defined at the following three levels: Internal Level The internal level has an internal schema, which describes the physical storage structure of the database. The internal schema uses a physical data model and describes the complete details of data storage and access paths for the database. Conceptual Level The conceptual level has a conceptual schema, which describes the structure of the whole database for a community of users. The conceptual schema hides the details of physical storage structures and concentrates on describing entities, data types, relationships, user operations, and constraints. Usually, a representational data model is used to describe the conceptual schema when a database system is implemented. This implementation conceptual schema is often based on a conceptual schema design in a high-level data model. External Level The external or view level includes a number of external schemas or user views. Each external schema describes the part of the database that a particular user group is interested in and hides the rest of the database from that user group. As in the previous case, each external schema is typically implemented using a representational data model, possibly based on an external schema design in a high level data model.
- 9. Fundamental of Database Systems: Data Models and Database System Architecture Page 9 The three-schema architecture is a convenient tool with which the user can visualize the schema levels in a database system. Most DBMSs do not separate the three levels completely, but support the three-schema architecture to some extent. Some DBMSs may include physical-level details in the conceptual schema. In most DBMSs that support user views, external schemas are specified in the same data model that describes the conceptual-level information. Some DBMSs allow different data models to be used at the conceptual and external levels. Notice that the three schemas are only descriptions of data; the only data that actually exists is at the physical level. In a DBMS based on the three-schema architecture, each user group refers only to its own external schema. Hence, the DBMS must transform a request specified on an external schema into a request against the conceptual schema, and then into a request on the internal schema for processing over the stored database. If the request is a database retrieval, the data extracted from the stored database must be reformatted to match the user's external view. The processes of transforming requests and results between levels are called mappings. These mappings may be time-consuming, so some DBMSs-especially those that are meant to support small databases-do not support external views. Even in such systems, however, a certain amount of mapping is necessary to transform requests between the conceptual and internal levels. ANSI-SPARC Three-level Architecture
- 10. Fundamental of Database Systems: Data Models and Database System Architecture Page 10 External View 1 Staff_No FName Salary External View 2 FName DOB Conceptual Level Staff_No FName LName DOB Salary Branch_No Internal Level struct STAFF{ int Staff_No; int Branch_No; char FName[15]; char LName[15]; struct DOB; float salary; } Fig. Differences between Three Levels of ANSI-SPARC Architecture The ANSI-SPARC Architecture Defines DBMS schemas at three levels: Internal schema o at the internal level to describe physical storage structures and access paths. Typically uses a physical data model. Conceptual schema o at the conceptual level to describe the structure and constraints for the whole database for a community of users. Uses a conceptual or an implementation data model. External schemas o at the external level to describe the various user views. Usually uses the same data model as the conceptual level.
- 11. Fundamental of Database Systems: Data Models and Database System Architecture Page 11 Data Independence The three-schema architecture can be used to further explain the concept of data independence, which can be defined as the capacity to change the schema at one level of a database system without having to change the schema at the next higher level. We can define two types of data independence: Logical Data Independence Logical data independence is the capacity to change the conceptual schema without having to change external schemas or application programs. We may change the conceptual schema to expand the database (by adding a record type or data item), to change constraints, or to reduce the database (by removing a record type or data item). In the last case, external schemas that refer only to the remaining data should not be affected. For example, the external schema of Figure l.4a should not be affected by changing the GRADE_REPORT file shown in Figure 1.2 into the one shown in Figure 1.5a. Only the view definition and the mappings need be changed in a DBMS that supports logical data independence. After the conceptual schema undergoes a logical reorganization, application programs that reference the external schema constructs must work as before. Changes to constraints can be applied to the conceptual schema without affecting the external schemas or application programs. Logical Data Independence Summary Refers to immunity of external schemas to changes in conceptual schema. Conceptual schema changes e.g. addition/removal of entities should not require changes to external schema or rewrites of application programs. The capacity to change the conceptual schema without having to change the external schemas and their application programs. Physical Data Independence Physical data independence is the capacity to change the internal schema without having to change the conceptual schema. Hence, the external schemas need not be changed as well. Changes to the internal schema may be needed because some physical files had to be reorganized-for example, by creating additional access structures-to improve the performance of retrieval or update. If the same data as before remains in the database, we should not have to
- 12. Fundamental of Database Systems: Data Models and Database System Architecture Page 12 change the conceptual schema. For example, providing an access path to improve retrieval speed of SECTION records (Figure 1.2) by Semester and Year should not require a query such as "list all sections offered in fall 1998" to be changed, although the query would be executed more efficiently by the DBMS by utilizing the new access path. Physical Data Independence Summary The ability to modify the physical schema without changing the logical schema Applications depend on the logical schema In general, the interfaces between the various levels and components should be well defined so that changes in some parts do not seriously influence others. The capacity to change the internal schema without having to change the conceptual schema Refers to immunity of conceptual schema to changes in the internal schema Internal schema changes e.g. using different file organizations, storage structures/devices should not require change to conceptual or external schemas. Whenever we have a multiple-level DBMS, its catalog must be expanded to include information on how to map requests and data among the various levels. The DBMS uses additional software to accomplish these mappings by referring to the mapping information in the catalog. Data independence occurs because when the schema is changed at some level, the schema at the next higher level remains unchanged; only the mapping between the two levels is changed. Hence, application programs referring to the higher-level schema need not be changed. The three-schema architecture can make it easier to achieve true data independence, both physical and logical. However, the two levels of mappings create an overhead during compilation or execution of a query or program, leading to inefficiencies in the DBMS. Because of this, few DBMSs have implemented the full three-schema architecture.
- 13. Fundamental of Database Systems: Data Models and Database System Architecture Page 13 Fig. Data Independence and the ANSI-SPARC Three-level Architecture