'
Chapter 1: Introduction
$
• Purpose of Database Systems
• View of Data
• Data Models
• Data Definition Language
• Data Manipulation Language
• Transaction Management
• Storage Management
&
• Database Administrator
• Database Users
• Overall System Structure
Database Systems Concepts
1.1
c
Silberschatz, Korth and Sudarshan 1997
%
'
Database Management System (DBMS)
$
• Collection of interrelated data
• Set of programs to access the data
• DBMS contains information about a particular enterprise
• DBMS provides an environment that it both convenient and
efficient to use
&
Database Systems Concepts
1.2
c
Silberschatz, Korth and Sudarshan 1997
%
'
Purpose of Database Systems
$
Database management systems were developed to handle the
following difficulties of typical file-processing systems supported by
conventional operating systems.
• Data redundancy and inconsistency
• Difficulty in accessing data
• Data isolation – multiple files and formats
• Integrity problems
&
• Atomicity of updates
• Concurrent access by multiple users
• Security problems
Database Systems Concepts
1.3
c
Silberschatz, Korth and Sudarshan 1997
%
'
$
View of Data
An architecture for a database system
view level
view 1
&
Database Systems Concepts
view 2
…
view n
logical
level
physical
level
1.4
c
Silberschatz, Korth and Sudarshan 1997
%
'
$
Levels of Abstraction
• Physical level: describes how a record (e.g., customer) is
stored.
• Logical level: describes data stored in database, and the
relationships among the data.
&
type customer = record
name : string;
street : string;
city : integer;
end;
• View level: application programs hide details of data types.
Views can also hide information (e.g. salary) for security
purposes.
Database Systems Concepts
1.5
c
Silberschatz, Korth and Sudarshan 1997
%
'
Instances and Schemas
$
• Similar to types and variables in programming languages
• Schema – the logical structure of the database (e.g., set of
customers and accounts and the relationship between them)
• Instance – the actual content of the database at a particular
point in time
&
Database Systems Concepts
1.6
c
Silberschatz, Korth and Sudarshan 1997
%
'
$
Data Independence
• Ability to modify a schema definition in one level without
affecting a schema definition in the next higher level.
• The interfaces between the various levels and components
should be well defined so that changes in some parts do not
seriously influence others.
• Two levels of data independence:
– Physical data independence
&
– Logical data independence
Database Systems Concepts
1.7
c
Silberschatz, Korth and Sudarshan 1997
%
'
$
Data Models
• A collection of tools for describing:
– data
– data relationships
– data semantics
– data constraints
• Object-based logical models
– entity-relationship model
– object-oriented model
– semantic model
– functional model
&
• Record-based logical models
– relational model (e.g., SQL/DS, DB2)
– network model
– hierarchical model (e.g., IMS)
Database Systems Concepts
1.8
c
Silberschatz, Korth and Sudarshan 1997
%
'
$
Entity-Relationship Model
Example of entity-relationship model
social-security
customer-street
account-number
customer
&
Database Systems Concepts
balance
customer-city
customer-name
depositor
1.9
account
c
Silberschatz, Korth and Sudarshan 1997
%
'
$
Relational Model
Example of tabular data in the relational model:
customer-
social-security
name
customer-
customer-
account-
street
city
number
Johnson
192-83-7465
Alma
Palo Alto
A-101
Smith
019-28-3746
North
Rye
A-215
Johnson
192-83-7465
Alma
Palo Alto
A-201
Jones
321-12-3123
Main
Harrison
A-217
Smith
019-28-3746
North
Rye
A-201
&
Database Systems Concepts
account-number
balance
A-101
500
A-201
900
A-215
700
A-217
750
1.10
c
Silberschatz, Korth and Sudarshan 1997
%
'
Data Definition Language (DDL)
$
• Specification notation for defining the database schema
• DDL compiler generates a set of tables stored in a data
dictionary
• Data dictionary contains metadata (i.e., data about data)
• Data storage and definition language – special type of DDL in
which the storage structure and access methods used by the
database system are specified
&
Database Systems Concepts
1.11
c
Silberschatz, Korth and Sudarshan 1997
%
'
Data Manipulation Language (DML)
$
• Language for accessing and manipulating the data organized
by the appropriate data model
• Two classes of languages
– Procedural – user specifies what data is required and how
to get those data
– Nonprocedural – user specifies what data is required
without specifying how to get those data
&
Database Systems Concepts
1.12
c
Silberschatz, Korth and Sudarshan 1997
%
'
Transaction Management
$
• A transaction is a collection of operations that performs a
single logical function in a database application
• Transaction-management component ensures that the
database remains in a consistent (correct) state despite
system failures (e.g. power failures and operating system
crashes) and transaction failures.
• Concurrency-control manager controls the interaction among
the concurrent transactions, to ensure the consistency of the
database.
&
Database Systems Concepts
1.13
c
Silberschatz, Korth and Sudarshan 1997
%
'
$
Storage Management
• A storage manager is a program module that provides the
interface between the low-level data stored in the database and
the application programs and queries submitted to the system.
• The storage manager is responsible for the following tasks:
– interaction with the file manager
– efficient storing, retrieving, and updating of data
&
Database Systems Concepts
1.14
c
Silberschatz, Korth and Sudarshan 1997
%
'
Database Administrator
$
• Coordinates all the activities of the database system; the
database administrator has a good understanding of the
enterprise’s information resources and needs.
• Database administrator’s duties include:
– Schema definition
– Storage structure and access method definition
– Schema and physical organization modification
– Granting user authority to access the database
&
– Specifying integrity constraints
– Acting as liaison with users
– Monitoring performance and responding to changes in
requirements
Database Systems Concepts
1.15
c
Silberschatz, Korth and Sudarshan 1997
%
'
$
Database Users
• Users are differentiated by the way they expect to interact with
the system
• Application programmers – interact with system through DML
calls
• Sophisticated users – form requests in a database query
language
• Specialized users – write specialized database applications
that do not fit into the traditional data processing framework
&
• Naive users – invoke one of the permanent application
programs that have been written previously
Database Systems Concepts
1.16
c
Silberschatz, Korth and Sudarshan 1997
%
'
Overall System Structure
naive users
(tellers, agents, etc.)
application
interfaces
application
programs
object code
application
programmers
sophisticated
users
database
administrator
application
programs
query
database
scheme
embedded
DML
precompiler
DML
compiler
DDL
interpreter
$
users
query
processor
query
evaluation
engine
databasemanagement
system
transaction
manager
buffer
manager
storage
manager
file
manager
&
Database Systems Concepts
indices
statistical data
disk storage
data files
data dictionary
1.17
c
Silberschatz, Korth and Sudarshan 1997
%
'
Chapter 2: Entity-Relationship Model
$
• Entity Sets
• Relationship Sets
• Design Issues
• Mapping Constraints
• Keys
• E–R Diagram
&
• Extended E-R Features
• Design of an E-R Database Schema
• Reduction of an E-R Schema to Tables
Database Systems Concepts
2.1
c
Silberschatz, Korth and Sudarshan 1997
%
'
$
Entity Sets
• A database can be modeled as:
– a collection of entities,
– relationships among entities.
• An entity is an object that exists and is distinguishable from
other objects.
Example: specific person, company, event, plant
• An entity set is a set of entities of the same type that share the
same properties.
&
Example: set of all persons, companies, trees, holidays
Database Systems Concepts
2.2
c
Silberschatz, Korth and Sudarshan 1997
%
'
$
Attributes
• An entity is represented by a set of attributes, that is,
descriptive properties possessed by all members of an entity
set.
Example:
customer = (customer-name, social-security,
customer-street, customer-city)
account = (account-number, balance)
• Domain – the set of permitted values for each attribute
• Attribute types:
&
– Simple and composite attributes.
– Single-valued and multi-valued attributes.
– Null attributes.
– Derived attributes.
Database Systems Concepts
2.3
c
Silberschatz, Korth and Sudarshan 1997
%
'
$
Relationship Sets
• A relationship is an association among several entities
Example:
depositor
A-102
Hayes
customer entity
relationship set
account entity
• A relationship set is a mathematical relation among n ≥ 2
entities, each taken from entity sets
{(e1 , e2 , ..., en ) | e1 ∈ E1 , e2 ∈ E2 , ..., en ∈ En }
&
where (e1 , e2 , ..., en ) is a relationship
– Example:
Database Systems Concepts
(Hayes, A-102) ∈ depositor
2.4
c
Silberschatz, Korth and Sudarshan 1997
%
'
$
Relationship Sets (Cont.)
• An attribute can also be a property of a relationship set.
For instance, the depositor relationship set between entity sets
customer and account may have the attribute access-date
access-date
social-security
customer-name
Database Systems Concepts
balance
customer-city
depositor
customer
&
account-number
customer-street
2.5
account
c
Silberschatz, Korth and Sudarshan 1997
%
'
Degree of a Relationship Set
$
• Refers to number of entity sets that participate in a relationship
set.
• Relationship sets that involve two entity sets are binary (or
degree two). Generally, most relationship sets in a database
system are binary.
• Relationship sets may involve more than two entity sets.
The entity sets customer, loan, and branch may be linked by
the ternary (degree three) relationship set CLB.
&
Database Systems Concepts
2.6
c
Silberschatz, Korth and Sudarshan 1997
%
'
$
Roles
Entity sets of a relationship need not be distinct
employee-name
e-social-security
telephone-number
manager
works-for
employee
worker
• The labels “manager” and “worker” are called roles; they
specify how employee entities interact via the works-for
relationship set.
&
• Roles are indicated in E-R diagrams by labeling the lines that
connect diamonds to rectangles.
• Role labels are optional, and are used to clarify semantics of
the relationship
Database Systems Concepts
2.7
c
Silberschatz, Korth and Sudarshan 1997
%
'
$
Design Issues
• Use of entity sets vs. attributes
Choice mainly depends on the structure of the enterprise being
modeled, and on the semantics associated with the attribute in
question.
• Use of entity sets vs. relationship sets
Possible guideline is to designate a relationship set to describe
an action that occurs between entities
• Binary versus n-ary relationship sets
Although it is possible to replace a nonbinary (n-ary, for n > 2)
relationship set by a number of distinct binary relationship sets,
a n-ary relationship set shows more clearly that several entities
participate in a single relationship.
&
Database Systems Concepts
2.8
c
Silberschatz, Korth and Sudarshan 1997
%
'
Mapping Cardinalities
$
• Express the number of entities to which another entity can be
associated via a relationship set.
• Most useful in describing binary relationship sets.
• For a binary relationship set the mapping cardinality must be
one of the following types:
– One to one
– One to many
– Many to one
&
– Many to many
• We distinguish among these types by drawing either a directed
line (→), signifying “one,” or an undirected line (—), signifying
“many,” between the relationship set and the entity set.
Database Systems Concepts
2.9
c
Silberschatz, Korth and Sudarshan 1997
%
'
social-security
$
One-To-One Relationship
customer-street
customer-name
amount
loan-number
customer-city
borrower
customer
loan
• A customer is associated with at most one loan via the
relationship borrower
&
• A loan is associated with at most one customer via borrower
Database Systems Concepts
2.10
c
Silberschatz, Korth and Sudarshan 1997
%
'
One-To-Many and Many-to-One Relationships
social-security
customer-street
customer-name
$
amount
loan-number
customer-city
borrower
customer
loan
(a)
social-security
&
customer-street
customer-name
Database Systems Concepts
amount
loan-number
customer-city
borrower
customer
loan
(b)
2.11
c
Silberschatz, Korth and Sudarshan 1997
%
'
One-To-Many and Many-to-One (Cont.)
$
• In the one-to-many relationship (a), a loan is associated with at
most one customer via borrower; a customer is associated with
several (including 0) loans via borrower
• In the many-to-one relationship (b), a loan is associated with
several (including 0) customers via borrower; a customer is
associated with at most one loan via borrower
&
Database Systems Concepts
2.12
c
Silberschatz, Korth and Sudarshan 1997
%
'
$
Many-To-Many Relationship
social-security
customer-street
customer-name
amount
loan-number
customer-city
borrower
customer
loan
• A customer is associated with several (possibly 0) loans via
borrower
&
• A loan is associated with several (possibly 0) customers via
borrower
Database Systems Concepts
2.13
c
Silberschatz, Korth and Sudarshan 1997
%
'
$
Existence Dependencies
• If the existence of entity x depends on the existence of entity y,
then x is said to be existence dependent on y.
– y is a dominant entity (in example below, loan)
– x is a subordinate entity (in example below, payment)
loan
&
loan-payment
payment
• If a loan entity is deleted, then all its associated payment
entities must be deleted also.
Database Systems Concepts
2.14
c
Silberschatz, Korth and Sudarshan 1997
%