View of Data
A database system is a collection of interrelated data and a set of programs
that allow users to access and modify these data. A major purpose of a database
system is to provide users with an abstract
view of the data. That is, the system hides certain details of how the data
are stored and maintained.
Data
Abstraction
For the system to be usable, it must retrieve data efficiently. The need
for efficiency has led designers to use complex data structures to represent
data in the database. Since many database-system users are not computer
trained, developers hide the complexity from users through several levels of
abstraction, to simplify users’ interactions with the system:
Figure 1.2 : Levels of Abstraction in a DBMS
• Physical level (or Internal View / Schema): The lowest level of
abstraction describes how the data
are actually stored. The physical level describes complex low-level data
structures in detail.
• Logical level (or Conceptual View / Schema): The next-higher level of
abstraction describes what data are
stored in the database, and what relationships exist among those data. The
logical level thus describes the entire database in terms of a small number of
relatively simple structures. Although implementation of the simple structures
at the logical level may involve complex physical-level structures, the user of
the logical level does not need to be aware of this complexity. This is
referred to as physical data
independence. Database administrators, who must decide what information to
keep in the database, use the logical level of abstraction.
• View level (or External View / Schema): The highest level of abstraction describes
only part of the entire database. Even though the logical level uses simpler
structures, complexity remains because of the variety of information stored in
a large database. Many users of the database system do not need all this
information; instead, they need to access only a part of the database. The view
level of abstraction exists to simplify their interaction with the system. The
system may provide many views for the same database. Figure 1.2 shows the relationship among the
three levels of abstraction.
An analogy to the concept of data types in programming languages may
clarify the distinction among levels of abstraction. Many high-level
programming languages support the notion of a structured type. For example, we
may describe a record as follows:
type instructor = record ID : char (5); name : char (20); dept name : char (20); salary : numeric (8,2); end;
This code defines a new record type called instructor with four fields. Each field has a name and a type
associated with it. A university organization may have several such record
types, including
• department, with fields dept_name, building, and budget
• course,
with fields course_id, title, dept_name, and credits
• student,
with fields ID, name, dept_name, and tot_cred
At the physical level, an instructor,
department, or student record can be described as a block of consecutive storage
locations. The compiler hides this level of detail from programmers. Similarly,
the database system hides many of the lowest-level storage details from
database programmers. Database administrators, on the other hand, may be aware
of certain details of the physical organization of the data.
At the logical level, each such record is described by a type
definition, as in the previous code segment, and the interrelationship of these
record types is defined as well. Programmers using a programming language work
at this level of abstraction. Similarly, database administrators usually work
at this level of abstraction.
Finally, at the view level, computer users see a set of application
programs that hide details of the data types. At the view level, several views
of the database are defined, and a database user sees some or all of these
views. In addition to hiding details of the logical level of the database, the
views also provide a security mechanism to prevent users from accessing certain
parts of the database. For example, clerks in the university registrar office
can see only that part of the database that has information about students;
they cannot access information about salaries of instructors.
Instances and Schemas
Databases change over time as information is inserted and deleted. The
collection of information stored in the database at a particular moment is
called an instance of the database.
The overall design of the database is called the database schema. Schemas are changed infrequently, if at all. The concept of
database schemas and instances can be understood by analogy to a program
written in a programming language. A database schema corresponds to the
variable declarations (along with associated type definitions) in a
program.
Each variable has a particular value at a given instant. The values of
the variables in a program at a point in time correspond to an instance of a database schema. Database
systems have several schemas, partitioned according to the levels of
abstraction. The physical schema describes
the database design at the physical level, while the logical schema describes the database design at the logical level.
A database may also have several schemas at the view level, sometimes called subschemas, which describe different
views of the database. Of these, the logical schema is by far the most
important, in terms of its effect on application programs, since programmers
construct applications by using the logical schema. The physical schema is
hidden beneath the logical schema, and can usually be changed easily without
affecting application programs. Application programs are said to exhibit physical data independence if they do
not depend on the physical schema, and thus need not be rewritten if the
physical schema changes.
