Scribd
Upload
35 views

View of Data

The document discusses different levels of abstraction in databases including the physical, logical, and view levels. It provides examples of how data may be structured at each level, from low-level storage details hidden at the physical level to customized views of data seen by users. The document also summarizes several common data models used in database design, including the relational, entity-relationship, object-oriented, and semistructured models.

Uploaded by

Lakshmi Lakshminarayana
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
35 views

View of Data

The document discusses different levels of abstraction in databases including the physical, logical, and view levels. It provides examples of how data may be structured at each level, from low-level storage details hidden at the physical level to customized views of data seen by users. The document also summarizes several common data models used in database design, including the relational, entity-relationship, object-oriented, and semistructured models.

Uploaded by

Lakshmi Lakshminarayana
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 4

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:1
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.
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.
1.3.2 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.
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, that describe different views of the
database.

1.3.3 Data Models


The structure of a database is the data model: a collection of
conceptual tools for describing data, data relationships, data
semantics, and consistency constraints. A data model provides a
way to describe the design of a database at the physical, logical,
and view levels.
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 fixedformat 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.
Entity-Relationship Model. The entity-relationship (E-R)
data model uses a collection of basic objects, called entities,
andrelationships 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.

Object-Based Data Model.Object-oriented programming


(especially in Java, C++, or C#) has become the dominant
software-development methodology. This led to the
development of an object-oriented data model that can be seen
as extending the E-R model with notions of encapsulation,
methods(functions), and object identity. The object-relational
data model combines features of the object-oriented data model
and relational data model.
Semistructured Data Model. The semistructured 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.
The Extensible Markup Language (XML) is widely used to
represent semistructured data.
Historically, the network data model and the hierarchical
data model preceded the relational data model. These
modelswere tied closely to the underlying implementation, and
complicated the task of modeling data. As a result they are used
little now, except in old database code that is still in service in
some places. They are outlined online in Appendices D and E
for interested readers.

You might also like