Lecture 2

▪ A transaction is an executing program or process that includes one

or more database accesses, such as reading or updating of database
records.
▪ Each transaction is supposed to execute a logically correct database
access if executed in its entirety without interference from other
transactions.
▪ The DBMS must enforce several transaction properties (Atomicity,
Consistency, Isolation, and Durability (ACID) properties)
▪ A transaction is an executing program or process that includes one
or more database accesses, such as reading or updating of database
records.
▪ Each transaction is supposed to execute a logically correct database
access if executed in its entirety without interference from other
transactions.
▪ The DBMS must enforce several transaction properties (Atomicity,
Consistency, Isolation, and Durability (ACID) properties)
▪ Database Administrators
▪ In a database environment, the primary resource is the database
itself, and the secondary resource is the DBMS and related software.
Administering these resources is the responsibility of the database
administrator (DBA).
▪ The DBA is responsible for authorizing access to the database,
coordinating and monitoring its use, and acquiring software and
hardware resources as needed.
▪ The DBA is accountable for problems such as security breaches and
poor system response time.
▪ Database designers
▪ they are responsible for identifying the data to be stored in the
database and for choosing appropriate structures to represent and
store this data.
▪ they communicate with all prospective database users in order to
understand their requirements and to create a design that meets
these requirements.
▪ Design the DB Conceptual Schema.
▪ Database designers typically interact with each potential group of
users and develop views of the database that meet the data and
processing requirements of these groups.
▪ Adjusting data parameters for performance.
▪ End users
▪ End users are the people whose jobs require access to the database
for querying, updating, and generating reports.
▪ End users
▪ Database End users are categorized as:
▪ Casual end users: they may need different information each time.
▪ Naive or parametric end users: Their main job function revolves
around constantly querying and updating the database, using standard
types of queries and updates called canned transactions, that have
been carefully programmed and tested. examples are: Bank customers,
tellers , and Reservation agents or customers for airlines
▪ Sophisticated end users include engineers, scientists, business
analysts, and others who thoroughly familiarize themselves with the
facilities of the DBMS in order to implement their own applications to
meet their complex requirements.
▪ Standalone users maintain personal databases by using ready-made
program packages that provide easy-to-use menu-based or graphics-
based interfaces.
▪ System Analysts and Application Programmers (Software
Engineers)
▪ System analysts determine the requirements of end users, and
develop specifications for standard canned transactions that meet
these requirements.
▪ Application programmers implement these specifications as
programs; then they test, debug, document, and maintain these
canned transactions.
▪ Such System Analysts and Application Programmers commonly
referred to as software developers or software engineers.
▪ The overhead costs of using a DBMS are due to the following:
▪ High initial investment in hardware, software, and training
▪ The generality that a DBMS provides for defining and processing
data
▪ Overhead for providing security, concurrency control, recovery,
and integrity functions.
▪ Therefore, it may be more desirable to develop customized database
applications under the following circumstances:
▪ simple, well-defined database applications that are not expected to
change at all
▪ Stringent, real-time requirements for some application programs
that may not be met because of DBMS overhead
▪ Embedded systems with limited storage capacity, where a general-
purpose DBMS would not fit
▪ No multiple-user access to data
▪ Data abstraction
▪ Suppression of details of data organization and storage.
▪ Highlighting of the essential features for an improved
understanding of data.
▪ Different users can perceive data at their preferred level
of detail.
▪ Data Model
▪ Collection of concepts that can be used to describe the
structure of a database (the data types, relationships, and
constraints that apply to the data)
▪ and also, the set of basic operations for specifying
retrievals and updates on the database.
▪ Data Model
▪ High-level or conceptual data models
▪ concepts that are close to the way many users perceive
data.
▪ use concepts such as entities, attributes, and
relationships.
▪ Entities: represents a real world object or concept.
▪ Attribute: represents some property of interest, further
describes an entity
▪ Relationship: represents an association among the entities.
▪ Data Model
▪ High-level or conceptual data models
▪ the Entity-Relationship (ER) Model is a popular high-
level conceptual data model.
▪ the ER Model creates entity set, relationship set, general
attributes and constraints.
▪ ER Model is based on entities and their attributes and
relationships among entities.
Entity-Relationship (ER) Model
Entity-Relationship (ER) Model
▪ Data Model
▪ Representational or implementation 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.
▪ the most frequently used 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 so-called legacy data
models
▪ Data Model
▪ Representational or implementation data models
▪ Representational data models represent data by using
record structures and hence are sometimes called
record-based data models.
▪ the object data model is an example of a new family of
higher-level implementation data models that are closer
to conceptual data models.
Relational Data Model
▪ Data Model
▪ low-level or physical data models
▪ they provide concepts that describe the details of how data is
stored on the computer storage media, typically magnetic
disks.
▪ generally meant for computer specialists, not for end users.
▪ Such as, access path which is a search structure that makes
the search for particular records efficient, such as indexing or
hashing.
▪ An index is an example of an access path that allows direct
access to data using an index term or a keyword.
▪ Data Model
▪ Another class of data models is known as 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 that were recently created for
managing big data.
▪ Database Schema
▪ the description of a database.
▪ displays only some aspects of a schema, such as the names of
record types and data items, and some types of constraints.
▪ Schema Diagram
▪ displays the structure of each record type but not the actual
instances of records..
▪ the database designers who design the schema to help
programmers understand the database and make it useful.
 Database
schema diagram
▪ Schema Construct
▪ each object in the schema
▪ Database state or database instance or snapshot
▪ is represented as the data in the database at a particular
moment in time.
▪ It is also called the current set of occurrences or instances
in the database.
▪ empty state of database
▪ is occurred at the beginning when we define the database
schema to DBMS and database has not any data.
▪ initial state of database
▪ is represented when the database is first populated or loaded
with the initial data
▪ valid state of database
▪ Is a state that satisfies the structure and constraints specified
in the schema.
▪ The DBMS is partly responsible for ensuring that every state
of the database is a valid state.
▪ schema evolution
▪ When we 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.
▪ Three-Schema Architecture
▪ The goal of the three-schema architecture is to separate the user
applications from the physical database.
▪ internal level
▪ has an internal schema
▪ describes the physical storage structure of the database
▪ 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 schema hides the details of physical storage
structures
▪ concentrates on describing entities, data types, relationships, user
operations, and constraints.
▪ Three-Schema Architecture
▪ external or view level
▪ number of external schemas or user views
▪ describes the part of the database that a particular user group is
interested in
▪ external schemas are specified in the same data model that
describes the conceptual-level information
▪ Mappings
▪ are the processes of transforming requests and results between
levels.
The 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.
▪ Logical data independence
▪ is the capacity to change the conceptual schema without having to
change external schemas or application programs.
▪ Physical data independence
▪ is the capacity to change the internal schema without having to
change the conceptual schema. Hence, the external schemas need
not be changed as well.