1.

3 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.
1.3.1 Data Models
Underlying the structure of a database is the data model: a
collection of conceptual tools for describing data, data
relationships, data semantics, and consistency constraints.
There are a number of different data models that we shall
cover in the text. The data models can be classified into four
different categories:
Relational Model. The relational model uses a
collection of tables to represent both data and the
relationships among those data. Each table has multiple
columns, and each column has a unique name. Tables
are also known as relations. The relational model is an
example of a record-based model. Record-based models
are so named because the database is structured in
f
ixed-format records of several types. Each table
contains records of a particular type. Each record type
defines a fixed number of fields, or attributes. The
columns of the table correspond to the attributes of the
record type. The relational data model is the most
widely used data model, and a vast majority of current
database systems are based on the relational model.
Chapter 2 and
Chapter 7 cover the relational model in
detail.
Entity-Relationship Model. The entity-relationship (E
R) data model uses a collection of basic objects, called
entities, and relationships among these objects. An
entity is a "thing" or "object" in the real world that is
distinguishable from other objects. The entity
relationship model is widely used in database design.
Chapter 6 explores it in detail.
Semi-structured Data Model. The semi-structured
data model permits the specification of data where
individual data items of the same type may have
different sets of attributes. This is in contrast to the data
models mentioned earlier, where every data item of a
particular type must have the same set of attributes.
JSON and Extensible Markup Language (XML) are widely
used semi-structured data representations. Semi
structured data models are explored in detail in
8.
Chapter
Page 9
Object-Based Data Model. Object-oriented
programming (especially in Java, C++, or C#) has
become the dominant software-development
methodology. This led initially to the development of a
distinct object-oriented data model, but today the
concept of objects is well integrated into relational
databases. Standards exist to store objects in relational
tables. Database systems allow procedures to be stored
 in the database system and executed by the database
system. This can be seen as extending the relational
model with notions of encapsulation, methods, and
object identity. Object-based data models are
summarized in
Chapter 8.
A large portion of this text is focused on the relational
model because it serves as the foundation for most
database applications.
1.3.2 Relational Data Model
In the relational model, data are represented in the form of
tables. Each table has multiple columns, and each column
has a unique name. Each row of the table represents one
piece of information.
Figure 1.1 presents a sample relational
database comprising two tables: one shows details of
university instructors and the other shows details of the
various university departments.
Figure 1.1 A sample relational database.
The first table, the instructor table, shows, for example,
that an instructor named Einstein with ID 22222 is a
member of the Physics department and has an annual
salary of $95,000. The second table, department, shows, for
example, that the Biology department is located in the
Watson building and has a budget of $90,000. Of course, a
real-world university would have many more departments
and instructors. We use small tables in the text to illustrate
concepts. A larger example for the same schema is
available online.
1.3.3 Data Abstraction
For the system to be usable, it must retrieve data efficiently.
The need for efficiency has led database system developers
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 data abstraction, to
simplify users' interactions with the system:
Physical level. 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. 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.
Page 10
View level. 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