Scribd
Upload
190 views

Degrees of Data Abstraction

The document discusses four levels of data abstraction: external, conceptual, internal, and physical. The external level defines how end users view subsets of data relevant to their business units. The conceptual level integrates all external views into a global view. The internal level maps the conceptual model to a specific DBMS. The physical level describes how data is stored on physical devices and depends on both the software and hardware used.

Uploaded by

Joshua Blessing
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
190 views

Degrees of Data Abstraction

The document discusses four levels of data abstraction: external, conceptual, internal, and physical. The external level defines how end users view subsets of data relevant to their business units. The conceptual level integrates all external views into a global view. The internal level maps the conceptual model to a specific DBMS. The physical level describes how data is stored on physical devices and depends on both the software and hardware used.

Uploaded by

Joshua Blessing
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 5

Degrees of Data Abstraction

If you ask 10 database designers what a data model is, you will end up with 10 different answers—
depending on the degree of data abstraction.
To illustrate the meaning of data abstraction, consider the example of automotive design. A car
designer begins by drawing the concept of the car to be produced. Next, engineers design the details
that help transfer the basic concept into a structure that can be produced. Finally, the engineering
drawings are translated into production specifications to be used on the factory floor. As you can
see, the process of producing the car begins at a high level of abstraction and proceeds to an ever-
increasing level of detail. The factory floor process cannot proceed unless the engineering details are
properly specified, and the engineering details cannot exist without the basic conceptual framework
created by the designer.

Using levels of abstraction can also be very helpful in integrating multiple (and sometimes
conflicting) views of data at different levels of an organization.
ANSI/SPARC architecture defines three levels of data abstraction: external, conceptual, and internal.

Data abstraction levels

The External Model


The external model is the end users’ view of the data environment. The term end users refer to
people who use the application programs to manipulate the data and generate information. End
users usually operate in an environment in which an application has a specific business unit focus.
Companies are generally divided into several business units, such as sales, finance, and marketing.
Each business unit is subject to specific constraints and requirements, and each one uses a subset of
the overall data in the organization. Therefore, end users within those business units view their data
subsets as separate from or external to other units within the organization.
A specific representation of an external view is known as an external schema.

The figure below presents the external schemas for two Tiny College business units: student
registration and class scheduling. Each external schema includes the appropriate entities,
relationships, processes, and constraints imposed by the business unit. Also note that although the
application views are isolated from each other, each view shares a common entity with the other
view. For example, the registration and scheduling external schemas share the entities CLASS and
COURSE.

External models for Tiny College.

Note the ERs represented in Figure above:


• A PROFESSOR may teach many CLASSes, and each CLASS is taught by only one PROFESSOR; there
is a 1:M relationship between PROFESSOR and CLASS.
• A CLASS may ENROLL many students, and each STUDENT may ENROLL in many CLASSes, thus
creating an M:N relationship between STUDENT and CLASS.
• Each COURSE may generate many CLASSes, but each CLASS references a single COURSE. For
example, there may be several classes (sections) of a database course that have a course code of
CIS-420. One of those classes might be offered on MWF from 8:00 a.m. to 8:50 a.m., another
might be offered on MWF from 1:00 p.m. to 1:50 p.m., while a third might be offered on
Thursdays from 6:00 p.m. to 8:40 p.m. Yet, all three classes have the course code CIS-420.
• Finally, a CLASS requires one ROOM, but a ROOM may be scheduled for many CLASSes. That is,
each classroom may be used for several classes: one at 9:00 a.m., one at 11:00 a.m., and one at
1:00 p.m., for example. In other words, there is a 1:M relationship between ROOM and CLASS.

The use of external views that represent subsets of the database has some important advantages:
• It is easy to identify specific data required to support each business unit’s operations.
• It makes the designer’s job easy by providing feedback about the model’s adequacy. Specifically,
the model can be checked to ensure that it supports all processes as defined by their external
models, as well as all operational requirements and constraints.
• It helps to ensure security constraints in the database design. Damaging an entire database is
more difficult when each business unit works with only a subset of data.
• It makes application program development much simpler.

The Conceptual Model


The conceptual model represents a global view of the entire database by the entire organization.
That is, the conceptual model integrates all external views (entities, relationships, constraints, and
processes) into a single global view of the data in the enterprise, as shown in Figure below. Also
known as a conceptual schema, it is the basis for the identification and high-level description of the
main data objects (avoiding any database model-specific details).

Conceptual model for tiny college

The most widely used conceptual model is the ER model. The conceptual model yields some
important advantages.
• it provides a bird’s eye (macro level) view of the data environment that is relatively easy to
understand.
• the conceptual model is independent of both software and hardware. Software independence
means that the model does not depend on the DBMS software used to implement the model.
Hardware independence means that the model does not depend on the hardware used in the
implementation of the model. Therefore, changes in either the hardware or the DBMS software
will have no effect on the database design at the conceptual level. Generally, the term logical
design refers to the task of creating a conceptual data model that could be implemented in any
DBMS.

The Internal Model


Once a specific DBMS has been selected, the internal model maps the conceptual model to the
DBMS. The internal model is the representation of the database as “seen” by the DBMS. In other
words, the internal model requires the designer to match the conceptual model’s characteristics
and constraints to those of the selected implementation model.
An internal schema depicts a specific representation of an internal model, using the database
constructs supported by the chosen database.
Internal model for Tiny College

Because the internal model depends on specific database software, it is said to be software
dependent. Therefore, a change in the DBMS software requires that the internal model be changed
to fit the characteristics and requirements of the implementation database model. When you can
change the internal model without affecting the conceptual model, you have logical independence.
However, the internal model is still hardware independent because it is unaffected by the type of
computer on which the software is installed. Therefore, a change in storage devices or even a
change in operating systems will not affect the internal model.

The Physical Model


The physical model operates at the lowest level of abstraction, describing the way data is saved on
storage media such as magnetic, solid state, or optical media. The physical model requires the
definition of both the physical storage devices and the (physical) access methods required to reach
the data within those storage devices, making it both software and hardware dependent. The
storage structures used are dependent on the software (the DBMS and the operating system) and on
the type of storage devices the computer can handle. The precision required in the physical model’
s definition demands that database designers have a detailed knowledge of the hardware and
software used to implement the database design.

Early data models forced the database designer to take the details of the physical model’s data
storage requirements into account. However, the now-dominant relational model is aimed largely at
the logical level rather than at the physical level; therefore, it does not require the physical-level
details common to its predecessors.

You might also like