0% found this document useful (0 votes)
6 views36 pages

Lecture 1

Uploaded by

rexboyahmad
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
6 views36 pages

Lecture 1

Uploaded by

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

Fundamental

Fundamental Database
Database
Concepts
Concepts
Lecture 1

Introduction to Database Systems

Instructor: Maqsood Ahmad


Department of Information Security
IUB

1
What is a Database?

•A database is any collection of data.

•A DBMS is a software system


designed to maintain a database.

•We use a DBMS when


– there is a large amount of data
– security and integrity of the data are important
– many users access the data concurrently
Example Database Application

•Consider a Phone Company, such as AT&T


•Kinds of information they deal with:

customer records employee records

billing information management records

customer service orders switching and wiring diagrams


Concerns of a Database User

•With all that data,


AT&T must be concerned with questions such as:

– Where is the information kept?


– How is the data structured?
– How is the data kept consistent?
– How is the data described?
– How is the data kept secure?
– How do different pieces of data interrelate?
Why Use a DBMS?

•Without a DBMS, we'd have:

Access by a collection
of ad hoc programs
in C++, Java, PHP, etc.
users of
the data

There is no control or
coordination of what
these programs do
data stored as bits on disks
organized as files with the data
Why Use a DBMS?

•With a DBMS, we have:


applications

DBMS
users of
the data

DBMS provides control


data stored as bits on disks and coordination to
organized as files protect the data.
DBMS Structure

application
application
program(s)
application
program(s)
application
program(s) users of
program(s)
the data
external/application view
internal/implementation view
query processor
security manager
DBMS
software concurrency manager
components index manager

data
data definition data
description processor data
dictionary
DBMS Languages

application
application
DML: data manipulation language application
program(s)
application
program(s) users of
QL: query language program(s)
program(s) the
GPL: general purpose languages data

query processor
security manager
concurrency manager system
index manager configuration
languages
DDL:
data data
definition definition data
language processor data
dictionary
Advantages of Using a DBMS

•Anything you can do with a DBMS,


you can do with a file system, a network
and a heap of C code

•So why spend the money to buy a DBMS?


– there is a well defined collection of capabilities
common to a certain class of applications

– for applications in this class, the DBMS already has


these capabilities and probably does them better
than you could with home-brewed code
DATABASE
FUNCTIONALITY
Advantages of Using a DBMS
application
application
application
program(s)
application
program(s) users of
program(s)
program(s) the
data

query processor
software operating
security manager
between the data and
concurrency manager the applications can
index manager provide many
capabilities
in a generic way
data
definition data
processor data
dictionary
Persistence

•A DBMS provides
persistent objects, types and data structures

– persistent = having a lifetime longer than


the programs that use the data

– any information that fits the data model


of a particular DBMS
can be made persistent with little effort

– data model = concepts that can be used to describe


the data
Concurrency

•A DBMS supports access by concurrent users

– concurrent = happening at the same time

– concurrent access, particularly writes (data changes),


can result in inconsistent states
(even when the individual operations are correct)

– the DBMS can check the actual operations of


concurrent users, to prevent activity that will lead to
inconsistent states
Access Control

•A DBMS can restrict access to authorized users

– security policies often require control that is more


fine-grained than that provided by a file system

– since the DBMS understands the data structure, it


can enforce fairly sophisticated and detailed
security policies
• on subsets of the data
• on subsets of the available operations
Redundancy Control

•A DBMS can assist in controlling redundancy

– redundancy = multiple copies of the same data

– with file storage, it's often convenient to store


multiple copies of the same data, so that it's
"local" to other data and applications

– this can cause many problems:


• wasted disk space
• inconsistencies
• need to enter the data multiple times
Backup and Recovery

•A DBMS can provide backup and recovery

– backup = snapshots of the data particular times


– recovery = restoring the data to a consistent state
after a system crash

– the higher level semantics (relationships and


constraints)
can make it difficult to restore a consistent state

– transaction analysis can allow a DBMS to reconstruct


a consistent state from a number of backups
Views and Interfaces

•A DBMS can support


multiple user interfaces and user views

– since the DBMS provides a well-defined data model


and a persistent data dictionary, many different
interfaces can be developed to access the same data

– data independence ensures that these UIs will not be


made invalid by most changes to the data

– new user views can be supported as new schemas


defined against the conceptual schema
Advantages of Using a DBMS

•persistent objects, types and data structures


•control of concurrent users
•controlling of redundancy
•restricting access (security)
•representation of complex relationships
and integrity constraints
•backup and recovery
•multiple user interfaces and user views
DATABASE USERS
AND ROLES
DBMS Roles

application
application
application
program(s)
application
program(s) users of
application developers program(s)
program(s) the
data

query processor
DBMS security manager
system concurrency manager
developers index manager system
database administrator
(and DB
designer data
designer)
definition data
processor data
dictionary
DBMS Roles

•Actors On the Scene


(people interested in the actual data):

– database administrators
– database designers
– systems analysts and application programmers
– end users
Actors on the Scene

•Database Administrators

– acquiring a DBMS
– managing the system
– acquiring HW and SW to support the DBMS
– authorizing access (security policies)
– managing staff, including DB designers
Actors on the Scene

•Database Designers

– identifying the information of interested


in the Universe of Discourse (the complete range
of objects, events, attributes , relations , ideas,
etc)
– designing the database conceptual schema
– designing views for particular users
– designing the physical data layout and logical
schema
– adjusting data parameters for performance
Actors on the Scene

•Systems Analysts and Application Programmers


(generic database developers)

– provide specialized knowledge to optimize


database usage
– provide generic (canned) application programs
Actors on the Scene

•End Users

– casual users: ad-hoc queries

– naïve or parametric users: canned queries such as


menus for a phone company customer service agent

– sophisticated users: people who understand the


system and the data and use it in many novel ways

– standalone users: people who use personal easy-to-


use databases for personal data
DBMS Roles

•Actors Behind the Scene:


people who maintain the environment
but aren't interested in the actual data

– DBMS designers and implementers


– tools developers
– operators and maintenance personnel
– database researchers
Actors Behind the Scene

•DBMS designers and implementers

– work for the company that supplies the DBMS


(i.e. Microsoft , Oracle, Sybase, MySQL …)

– programmers and engineers

– design and implement the DBMS


Actors Behind the Scene

•Tools Developers

– design and implement DBMS add-ons or plug-ins

– may work for DBMS supplier or be independent

– kinds of tools: database design aids, performance


monitoring tools, user and designer interfaces
Actors Behind the Scene

•Operators and maintenance personnel

– run and maintain the computer environment in


which a DBMS operates

– probably work for the database administrator


(DBA)
Actors Behind the Scene

•Database Researchers

– academic or industrial researchers

– develop new theory, new designs, new data


models and new algorithms to improve future
database management systems
DATA
ORGANIZATION
Schemas and Instances

•A database instance is the collective values of


all database objects at some point in time

– also called the (data) instance or (database) state

•A schema describes the database and


defines the possible instances

– also called the data definition, data dictionary, or


meta-data
Conceptual Data Models

•A data model describes the possible schemas


(essentially the meta-schema)

•A DBMS is designed around a particular data model


– this is what allows all system components (and
humans)
to understand the schema and data
•possible data models
– relational,
object-oriented, object-relational,
entity-relationship,
semantic, network, hierarchical, etc.
Physical Data Models

•A physical data model describes the way


in which data is stored in the computer

– typically only of interest to database designers,


implementers and maintainers …not end users

– must provide a well-defined structure that can be


mapped to the conceptual schema

– allows optimization strategies to be defined


generically
Three-Schema Architecture

user-specific
views

External View External View External View

Conceptual Schema generic view

Internal Schema physical view


Data Independence

•physical data independence


– conceptual and external schema are defined
in terms of the data model,
rather than the actual data layout
– ensures that conceptual and external schemas
are not affected by changes to the physical data layout

•logical data independence


– ensures that changes to the conceptual schema
don't affect the external views
– (this is not always achievable)

You might also like