Introduction to Database and database users.pptx

DATABASES AND
DATABASE USERS
Database System

Outlines
:
• Types of database & database applications.
• Basic definitions.
• Typical DBMS functionality.
• An example for database.
• Main characteristics of the database
approach.
• Database users.

Introduction
Databases and database systems are an essential
component of life in modern society.
There are two types of database applications:
Traditional database applications:
• Bank system.
• Hotel or airline reservation.
• Library.
• Online shopping.
• Supermarket.
Modern database applications:
• Geographic information systems (GIS).
• Data warehouses and online analytical processing
(OLAP).

What is a database
?
• Database is a collection of related data.
• Data means known facts that can be recorded and
that have implicit meaning. For example, consider
the names, telephone numbers, and addresses of the
people you know.
• A database represents some aspect of the real world,
sometimes called the miniworld. Changes to the
miniworld are reflected in the database.
• A database can be of any size and complexity

What is a DBMS
?
A database management system (DBMS) is a
collection of programs that enables users to create and
maintain a database. The DBMS is a general-purpose
software system that facilitates the processes of defining,
constructing, manipulating, and sharing databases
among various users and applications.
The DBMS typical functionalities are:
1. Defining
2. Constructing
3. Manipulating
4. Sharing
5. Protection
6. Maintain

Types of databases
A DBMS can support many different types of databases.
Databases can be classified according to the:
Number of users:
Single user database / multiuser database
Database location(s):
Centralized database / distributed database
Expected type and extent of use:
Operational database / data warehouse

A Simplified Database System
Environment
Figure 1

An Example
Examples of querying (retrieving):
• Retrieve the transcript—a list of all courses and
grades—of ‘Smith’
• List the names of students who took the section of
the ‘Database’ course offered in fall 2008 and their
grades in that section
• List the prerequisites of the ‘Database’ course.
Examples of updates include the following:
• Change the class of ‘Smith’ to 2
• Create a new section for the ‘Database’ course for
this semester
• Enter a grade of ‘A’ for ‘Smith’ in the ‘Database’
section of last semester

Characteristics of the Database
Approach
 A number of characteristics distinguish the database
approach from the much older approach of
programming with files. In traditional file
processing, each user defines and implements the
files needed for a specific software application as
part of programming the application. In the
database approach, a single repository maintains
data that is defined once and then accessed by
various users.
 In file systems, each application is free to name data
elements independently. In contrast, in a database,
the names or labels of data are defined once, and
used repeatedly by queries, transactions, and

Approach
1. Self-Describing Nature of a Database System
Database system contains not only the database
itself but also a complete definition or description
of the database structure and constraints. This
definition is stored in the DBMS catalog (meta-
data).

Approach
Figure 3

Approach
2. Insulation between Programs and Data, and Data
Abstraction
In traditional file processing, the structure of data
files is embedded in the application programs, so
any changes to the structure of a file may require
changing all programs that access that file. By
contrast, DBMS access programs do not require
such changes in most cases. The structure of data
files is stored in the DBMS catalog separately from
the access programs. We call this property
program-data independence.

Approach
Figure 4

Approach
3. Support of Multiple Views of the Data
A database typically has many users, each of whom
may require a different perspective or view of the
database. For example, one user of the database of
Figure 2 may be interested only in accessing and
printing the transcript of each student; the view for
this user is shown in Figure 5(a). A second user,
who is interested only in checking that students
have taken all the prerequisites of each course for
which they register, may require the view shown in
Figure 5(b).

Approach

Approach
4. Sharing of Data and Multiuser Transaction
Processing
A multiuser DBMS, as its name implies, must allow
multiple users to access the database at the same
time.

Database users
There are two types of people who dealing with
database:
1. People whose jobs involve the day-to-day use of a
large database; we call them the actors on the scene.
2. People who may be called workers behind the scene
those who work to maintain the database system
environment but who are not actively interested in
the database contents as part of their daily job.

Actors on the scene
1. Database Administrators:
Database administrator (DBA). The DBA is responsible
for:
 Authorizing access to the database, coordinating and
monitoring its use.
 Acquiring software and hardware resources as
needed.
 The DBA is accountable for problems such as
security breaches and poor system response time.
In large organizations, the DBA is assisted by a staff that
carries out these functions.

Actors on the scene
2. Database Designers:
Database designers are responsible for:
 Identifying the data to be stored in the database and
for choosing appropriate structures to represent and
store this data.
 Communicate with all prospective database users in
order to understand their requirements and to
create a design that meets these requirements.

Actors on the scene
3. End Users:
End users are the people whose jobs require access to
the database for querying, updating, and generating
reports; the database primarily exists for their use.
There are several categories of end users:
 Casual end users
 Naive or parametric end users
 Sophisticated end users
 Standalone users

Actors on the scene
4. System Analysts and Application Programmers
(Software Engineers)
System analysts determine the requirements of end
users, especially naive and parametric 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.

Workers behind the scene
In addition to those who design, use, and administer a
database, others are associated with the design,
development, and operation of the DBMS software and
system environment. These persons are typically not
interested in the database content itself. We call them the
workers behind the scene, and they include the following
categories:
 DBMS system designers and implementers.
 Tool developers.
 Operators and maintenance personnel (system
administration personnel) are responsible for the actual
running and maintenance of the hardware and software
environment for the database system.

Advantages of Using the DBMS
Approach
1. Controlling Redundancy.
 Data Normalization
 Controlled Redundancy
2. Restricting Unauthorized Access
3. Providing Persistent Storage for Program Objects
 object-oriented database systems
4. Providing Storage Structures and Search
Techniques for Efficient Query Processing
5. Providing Backup and Recovery
6. Providing Multiple User Interfaces

Approach
7. Representing Complex Relationships among Data
8. Enforcing Integrity Constraints
9. Permitting Inferencing and Actions Using Rules

Approach
Figure 6:
Redundancy

Approach
DBA Parametric users Financial team
Database
• Make user accounts
• Assigning privileges
• Access database
• access the database
only through the
predefined canned
transactions
• Accessing
financial data
only

Approach
Figure 7
Relationship
s

Historical development of
database technology
1. Hierarchical Databases
A kind of database management system that links
records together like a family tree such that each record
type has only one owner, e.g. an order is owned by only
one customer. Hierarchical structures were widely used
in the first mainframe database management systems.
However, due to their restrictions, they often cannot be
used to relate structures that exist in the real world.

database technology
ORDER_HEADER
CUSTOMER PRODUCT
Figure 8

database technology
Product_NO Customer_ID
10 113
30 204
Address Name Customer_I
D
Duhok Ahmad 113
Zakho Ali 204
Description Product_NO
TV 10
Phone 30

database technology
2. Relational Databases
Relational databases were originally proposed to
separate the physical storage of data from its
conceptual representation and to provide a
mathematical foundation for data representation and
querying. The relational data model also introduced
high-level query languages that provided an alternative
to programming language interfaces, making it much
faster to write new queries. Relational systems were
initially targeted to the same applications as earlier
systems, and provided flexibility to develop new queries
quickly and to reorganize the database as requirements
changed. Hence, data abstraction and program-data

database technology
3. Object-Oriented Databases
The emergence of object-oriented programming
languages in the 1980s and the need to store and share
complex, structured objects led to the development of
object-oriented databases (OODBs). Initially, OODBs
were considered a competitor to relational databases,
since they provided more general data structures. They
also incorporated many of the useful object-oriented
paradigms, such as abstract data types, encapsulation
of operations, inheritance, and object identity.

When Not to Use a DBMS
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

When Not to Use a DBMS
It may be more desirable to use regular files 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

Introduction to Database and database users.pptx

More Related Content

Similar to Introduction to Database and database users.pptx (20)

More from HajarMeseehYaseen (8)

Recently uploaded (20)

Introduction to Database and database users.pptx

Editor's Notes