Database Systems (CC-2141)

Lecture # 6

Instructor
Amna Zulfiqar
Data Models
● a collection of concepts that can be used to describe
○ the structure of a database (data types, constraints,
relationships)
○ the operations for manipulating this structure
● Most data models also include a set of basic operations for
specifying retrievals and updates on the database.
● Some data models allows a database designer to specify the
dynamic aspect or behavior of a database application
Categories of Data Models
● High-level or conceptual or semantic data models
provide concepts that are close to the way many users
perceive data
○ entities, attributes, and relationships based
○ Object based data model
● Low-level or physical or internal data models provide
concepts that describe the details of how data is stored on
the computer storage media
○ represents information such as record formats, record
orderings, and access paths
Categories of Data Models
● Implementation or Representational data models
provide concepts that may be easily understood by end
users but that are not too far removed from the way data is
organized in computer storage
○ these models are most frequently used in traditional
commercial DBMSs (relational data model, the network and
hierarchical models)
● Self-describing data models combines the description of
the data with the data values themselves.
○ These models include XML as well as many of the key-value
stores and NOSQL systems
A collection in MongoDB (Self describing data model) will look like this:

{
"_id": ObjectId("507f191e810c19729de860ea"),
"name": "Alice Johnson",
"age": 22,
"major": "Computer Science",
"enrollmentDate": "2023-09-01"
}
Schemas
● description of a database
● It is specified during database design and is not expected to
change frequently.
● Schema Diagram: a displayed schema.
○ The diagram displays the structure of each record type
● Each object in the schema—such as STUDENT or COURSE—a
schema construct.
Schema Diagram
Database State
● Data in the database at a particular moment in time is called a
database state or snapshot
○ current set of occurrences or instances in the database.
● In a given database state, each schema construct has its own
current set of instances;
● 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.
Database State
Database schema vs Database state
● When we define a new database, we specify its database schema
only to the DBMS.
○ 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.
● The DBMS is partly responsible for ensuring that every state of the
database is a valid state
● The schema is sometimes called the intension, and a database
state is called an extension of the schema.
Schema Evolution
Changes occasionally need to be applied to the schema as the
application requirements change.

Example, adding the Date_of_birth to the STUDENT schema.

This is known as schema evolution.

Most modern DBMSs include some operations for schema evolution

that can be applied while the database is operational.
Three schema architecture

Characteristics of Database Approach:

● use of a catalog/data dictionary to store the database
description (schema) to make it self-describing,
● insulation of programs and data (program-data and program-
operation independence), and
● support of multiple user views.
Three schema architecture

● was proposed to help achieve and visualize these characteristics

● Goal: To separate the user applications from the physical
database.

Schemas at different levels:

Internal level has an internal schema: describes the physical

storage structure of the database.
● The internal schema uses a physical data model and describes
the complete details of data storage and access paths for the
database.
Three schema architecture

● Conceptual level has a conceptual schema: describes the

structure of the whole database for a community of users.
● The conceptual level hides the details of physical storage
structures and concentrates on describing:
○ entities, data types, relationships, user operations, and
constraints:
● Usually, a representational data model is used to describe the
conceptual schema when a database system is implemented.
● implementation is often based on a conceptual schema
design in a high-level data model.
Three schema architecture

External Level or View Level: includes a number of external

schemas or user views.

Each external schema:

● describes the part of the database that a particular user group is
interested in and hides the rest of the database from that user
group.
● is typically implemented using a representational data model,
● possibly based on an external schema design in a high-level
conceptual data model
Three schema architecture
Data Independence
the capacity to change the schema at one level of a database
system without having to change the schema at the next higher
level.

Types of data independence

● Logical data independence
● Physical data independence
Logical Data Independence

Capacity to change the conceptual schema without having to

change external schemas or application programs.
We may change the conceptual schema
● to expand the database (by adding a record type or data
item),
● to change constraints, or
● to reduce the database (by removing a record type or data
item).
Clearly, the users for whom the changes have been made need
to be aware of them, but what is important is that other users
Logical Data Independence
After the conceptual schema undergoes a logical reorganization,
application programs that reference the external schema constructs
must work as before.

Example:
● add new columns to a certain relation, or split it into several
subrelations,
● as long as the user views still produce the same result as
before, the users and applications that access the data through
these views will not notice the change in the logical data
model.
Physical Data Independence
Capacity to change the internal schema without having to change the
conceptual schema.

Changes to the internal schema may be needed because some

physical files were reorganized

Example, providing an access path to improve retrieval speed of

SECTION records should not require a query/program that accesses all
sections offered in fall 2008 to be changed

although the query would be executed more efficiently by the DBMS

by utilizing the new access path
Data Independence
Database Languages

In many DBMSs where no strict separation of levels of schemas is

maintained,
● Data definition language (DDL), is used by the DBA and by
database designers to define both (conceptual and internal)
schemas.
● DDL compiler processes DDL statements
○ to identify descriptions of the schema constructs and
○ to store the schema description in the DBMS catalog
Database languages

Where a clear separation is maintained between the conceptual

and internal levels:
● the DDL is used to specify the conceptual schema only.
● the Storage Definition Language (SDL), is used to
specify the internal schema.
● View definition language (VDL), to specify user views and
their mappings to the conceptual schema,
● Manipulations include retrieval, insertion, deletion, and
modification of the data are performed using Data
manipulation language (DML).
Database languages

● In current DBMSs, the preceding types of languages are usually

not considered distinct languages; rather, a comprehensive
integrated language is used that includes constructs for
conceptual schema definition, view definition, and data
manipulation.
● A typical example of a comprehensive database language is the
SQL relational database language, which represents a
combination of DDL, VDL, and DML, as well as statements for
constraint specification, schema evolution, and many other
features
Types of DML

Procedural DML Non-Procedural DML

must be embedded in a general- can be used on its own to specify

purpose programming language. complex database operations
concisely.

● retrieves individual records or can specify and retrieve many

objects from the database records in a single DML statement
and processes each
called set-at-a-time or set-
separately
oriented DMLs
● also called record-at-a-time
DMLs

specify what data is needed ● query often specifies which

data to retrieve rather than
and exactly how to retrieve how to retrieve it;
Example of Procedural DML
CREATE OR REPLACE PROCEDURE
Update_Salaries()
LANGUAGE plpgsql
AS $$
DECLARE
rec RECORD;
BEGIN
FOR rec IN
SELECT EmployeeID FROM Employees
WHERE EXTRACT(YEAR FROM AGE(HireDate))
>5
LOOP
UPDATE Employees
SET Salary = Salary * 1.10
WHERE EmployeeID = rec.EmployeeID;
END LOOP;
END;
$$;
 Example of Non- Procedural DML

UPDATE Employees
SET Salary = Salary * 1.10
WHERE EXTRACT(YEAR FROM AGE(HireDate)) > 5;

SELECT * FROM Students WHERE Major = 'Computer

Science';
Database languages

● Whenever DML commands, whether high level or low level, are

embedded in a general-purpose programming language, that
language is called the host language and the DML is called the
data sublanguage.
● a high-level DML used in a standalone interactive manner is
called a query language
● In general, both retrieval and update commands of a high-level
DML may be used interactively and are hence considered part of
the query language.
Classification of Database Management Systems

Based on Data Models: main criterion for classifying DBMSs

● Relational
○ represents a database as a collection of tables, where each table can
be stored as a separate file.
○ main data model used in many current commercial DBMSs
● Object
○ defines a database in terms of objects, their properties, and their
operations
● Object-relational
○ Relational DBMSs have been extending their models to incorporate
object database concepts and other capabilities
Classification of Database Management Systems

Based on Data Models

Classification of Database Management Systems

Based on Data Models

Recently, so-called big data systems, also known as key-value storage

systems and NOSQL systems, use various data models
● Key-value
○ associates a unique key with each value (which can be a record or
object) and provides very fast access to a value given its key.
● Document data model
○ based on JSON (Java Script Object Notation) and stores the data as
documents, which somewhat resemble complex objects
● Graph data model
○ stores objects as graph nodes and relationships among objects as
directed graph edges.
Classification of Database Management Systems

Document data model

Classification of Database Management Systems

Based on number of users supported by the system

● Single-user systems support only one user at a time and are
mostly used with PCs.
● Multiuser systems, which include the majority of DBMSs,
support concurrent multiple users.
Classification of Database Management Systems

Based on number of sites over which the database is

distributed
● centralized if the data is stored at a single computer site.
○ can support multiple users, but the DBMS and the database
reside totally at a single computer site.
● distributed DBMS (DDBMS) can have the actual database and
DBMS software distributed over many sites connected by a
computer network.