Chapter_2

Database system concepts and architecture

 Learning Objectives:
– Discuss the three categories of Data Models.
– Define the concepts of database schema & instances, and Database
State.
– Modeling Data in the Organization:
 Business Rules.
 Entity-Relationship Model (E-R Model)
 (E-R Model) Constructs:
– Entities.
– Attributes (Classifications of attributes).
– Relationships (Degree, Cardinality , & cardinality constraints)
 Entity Relationship Diagram (ERD) Design steps.
 Relational Database Model (RDM) design steps.
 Normalization process.
2.1Data Models, Schemas, and Instances
One fundamental characteristic of the database approach is that it
provides some level of data abstraction.
Data abstraction generally refers to
the suppression of details of data organization and storage, and
the highlighting of the essential features for an improved
understanding of data.
Database approach supports data abstraction so that different users
can perceive data at their preferred level of details.
Each level can be represented by a data model.
A data model—a collection of concepts that can be used to describe
the structure of a database—provides the necessary means to achieve
this abstraction.
The “Structure of a database” means the data types, relationships,
and constraints that apply to the data.
Most data models also include a set of basic operations for specifying
retrievals and updates on the database.
 2.1.1 Categories of Data Models
we can categorize data models according to the types of concepts they use to
describe the database structure.
1. High-level or conceptual data models: provide concepts that are close to
the way many users perceive data, whereas
2. Low-level or physical data models: provide concepts that describe the
details of how data is stored on the computer storage media, typically
magnetic disks.
 Concepts provided by low-level data models are generally meant for
computer specialists, not for end users.
3. Between these two extremes is a class of representational (or
implementation) data models: which hide many details of data storage
on disk but can be implemented on a computer system directly.
1. 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 from the miniworld that is
described in 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
the entities, for example, a works-on
relationship between an employee and a
project.

In the following sections, we will study the Entity-Relationship

model, which is a popular high-level conceptual data model.
2. 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
network and hierarchical models—that have been widely used in the
past.
Our course is devoted to the relational data model, and its constraints,
operations and languages.
Representational data models represent data by using record structures
and hence are sometimes called record-based data models. (Figure 2.1)

3. Physical data models describe how data is stored as files in the

computer by representing information such as record formats,
record orderings, and access paths.
An access path is a structure that makes the search for particular
database records efficient.
An index is an example of an access path that allows direct access to
data using an index term or a keyword.
It is similar to the index at the end of any book, except that it may be
organized in an hierarchical (tree-structured), or some other fashion.
 Figure 2-1
a simple example of a university database
Shows the conceptual and implementation data model
2.1.2 Schemas, Instances, and Database State
It is important to distinguish between the description 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-2 shows a schema diagram for the database shown in
Figure 1-11; the diagram displays the structure of each record type
but not the actual instances of records.
We call each object (record type) 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.
 Figure 2-2
a Schema diagram for the database in Figure 1-11
 Other aspects are not specified in the schema diagram; for
example, Figure 2-2 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 diagrammatically.

A DATABASE STATE:
The actual data in a database may change quite frequently; For
example, the database shown in Figure 1-11 changes every time
we add a new student or enter a new grade.
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.
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 specified in the schema.
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
is called an extension of the schema.

Although the schema is not supposed to change frequently, it is not

uncommon that changes occasionally need to be 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 Date_of_birth to
the STUDENT schema in Figure 2-2 ; This is known as schema
evolution.
Most modern DBMSs include some operations for schema evolution
that can be applied while the database is operational.
 Summary for the main concepts
Database Schema:
The description of a database.
Includes descriptions of the database structure, data types, and
the constraints on the database.
Schema Diagram :
An illustrative display of (most aspects of) a database schema.
Schema Construct:
A component of the schema or an object within the schema, e.g.,
STUDENT, COURSE.
Database State:
The actual data stored in a database at a particular moment in
time. This includes the collection of all the data in the database.
Also called database instance (or occurrence or snapshot).
The term instance is also applied to individual database
components, e.g. record instance, table instance, entity instance
Database State:
Refers to the content of a database at a moment in time.
Initial Database State:
Refers to the database state when it is initially loaded
into the system.
Valid State:
A state that satisfies the structure and constraints of the
database.
Distinction between Database Schema and Database
State:
The database schema changes very infrequently. It is
also called intension.
The database state changes every time the database is
updated. also called extension.
End of Lecture_3