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
Unit1 –lecture1
 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 is both
convenient and efficient to use.
 Database Applications:
◦ Banking: all transactions
◦ Airlines: reservations, schedules
◦ Universities: registration, grades
◦ Sales: customers, products, purchases
◦ Manufacturing: production, inventory, orders, supply chain
◦ Human resources: employee records, salaries, tax deductions
 Databases touch all aspects of our lives
Purpose of Database
System
In the early days, database applications
were built on top of file systems
 Drawbacks of using file systems to store

data:
◦ Data redundancy and inconsistency
 Multiple file formats, duplication of information in
different files
◦ Difficulty in accessing data
 Need to write a new program to carry out each new task
◦ Data isolation — multiple files and formats
◦ Integrity problems
 Integrity constraints (e.g. account balance > 0) become
part of program code
 Hard to add new constraints or change existing ones
Purpose of Database Systems (Cont.)

 Drawbacks of using file systems (cont.)

◦ Atomicity of updates
 Failures may leave database in an inconsistent state with
partial updates carried out
 E.g. transfer of funds from one account to another should
either complete or not happen at all
◦ Concurrent access by multiple users
 Concurrent accessed needed for performance
 Uncontrolled concurrent accesses can lead to inconsistencies
 E.g. two people reading a balance and updating it at the
same time
◦ Security problems
 Database systems offer solutions to all the
above problems
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.
Unit1 –lecture2
View of Data
An architecture for a database system
Instances and Schemas
 Similar to types and variables in programming languages
 Schema – the logical structure of the database
◦ e.g., the database consists of information about a set of customers and
accounts and the relationship between them)
◦ Analogous to type information of a variable in a program
◦ Physical schema: database design at the physical level
◦ Logical schema: database design at the logical level
 Instance – the actual content of the database at a particular
point in time
◦ Analogous to the value of a variable
 Physical Data Independence – the ability to modify the
physical schema without changing the logical schema
◦ Applications depend on the logical schema
◦ In general, the interfaces between the various levels and components
should be well defined so that changes in some parts do not seriously
influence others.
Data Definition Language (DDL)
 Specification notation for defining the database
schema
◦ E.g.
create table account (
account-number char(10),
balance integer)
 DDL compiler generates a set of tables stored
in a data dictionary
 Data dictionary contains metadata (i.e., data
about data)
◦ database schema
◦ Data storage and definition language
 language in which the storage structure and access methods used
by the database system are specified
 Usually an extension of the data definition language
Data Manipulation Language
(DML)
 Language for accessing and manipulating
the data organized by the appropriate data
model
◦ DML also known as query language
 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
 SQL is the most widely used query language
SQL
 SQL: widely used non-procedural language
◦ E.g. find the name of the customer with customer-id 192-83-7465
select customer.customer-name
from customer
where customer.customer-id = ‘192-83-7465’
◦ E.g. find the balances of all accounts held by the customer with
customer-id 192-83-7465
select account.balance
from depositor, account
where depositor.customer-id = ‘192-83-7465’ and
depositor.account-number = account.account-
number
 Application programs generally access databases
through one of
◦ Language extensions to allow embedded SQL
◦ Application program interface (e.g. ODBC/JDBC) which allow SQL
queries to be sent to a database
Unit1 –lecture3,4
Data Models
 A collection of tools for describing
◦ data
◦ data relationships
◦ data semantics
◦ data constraints
 Entity-Relationship model
 Relational model
 Other models:
◦ object-oriented model
◦ semi-structured data models
◦ Older models: network model and hierarchical model
Entity-Relationship Model
Example of schema in the entity-relationship model
Entity Relationship Model
(Cont.)
 E-R model of real world
◦ Entities (objects)
 E.g. customers, accounts, bank branch
◦ Relationships between entities
 E.g. Account A-101 is held by customer Johnson
 Relationship set depositor associates customers with accounts
 Widely used for database design
◦ Database design in E-R model usually converted to design in the
relational model (coming up next) which is used for storage and
processing
Relational Model Attributes
 Example of tabular data in the relational model
customer- customer- customer- account-
Customer-id
name street city number

192-83-7465 Johnson
Alma Palo Alto A-101
019-28-3746 Smith
North Rye A-215
192-83-7465 Johnson
Alma Palo Alto A-201
321-12-3123 Jones
Main Harrison A-217
019-28-3746 Smith
North Rye A-201
A Sample Relational
Database
Unit1 –lecture5
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
 Naïve users – invoke one of the permanent
application programs that have been written
previously
◦ E.g. people accessing database over the web, bank tellers, clerical staff
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
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.
Storage Management
 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 to the

following tasks:
◦ interaction with the file manager
◦ efficient storing, retrieving and updating of data
Overall System Structure
 Application Architectures

 Two-tier architecture: E.g. client programs using ODBC/JDBC to

communicate with a database
 Three-tier architecture: E.g. web-based applications, and
applications built using “middleware”
Unit1 –lecture6,7
 How to translate ER
Model to Relational Model
Review - Concepts
Relational Model is made up of
tables

 A row of table = a relational

instance/tuple
 A column of table = an attribute
 A table = a schema/relation
 Cardinality = number of rows
 Degree = number of columns
Review - Example

Attribute

Cardinality = 2
tuple/relational
instance SID Name Major GPA
1234 John CS 2.8
5678 Mary EE 3.6

4 Degree

A Schema / Relation
From ER Model to Relational
Model
So… how do we convert an ER diagram into
a table?? Simple!!
Basic Ideas:
 Build a table for each entity set

 Build a table for each relationship set if necessary

(more on this later)

 Make a column in the table for each attribute in

the entity set

 Indivisibility Rule and Ordering Rule

 Primary Key
 Example – Strong Entity
Set
SID Name SSN Name

Student Advisor Professor

Major Dept
GPA

SID Name Major GPA SSN Name Dept

1234 John CS 2.8 9999 Smith Math
5678 Mary EE 3.6 8888 Lee CS
Representation of Weak Entity
Set
 Weak Entity Set Cannot exists alone
 To build a table/schema for weak entity set

◦ Construct a table with one column for each

attribute in the weak entity set
◦ Remember to include discriminator
◦ Augment one extra column on the right side of
the table, put in there the primary key of the
Strong Entity Set (the entity set that the weak
entity set is depending on)
◦ Primary Key of the weak entity set =
Discriminator + foreign key
Example – Weak Entity Set
Age
SID Name Name

Student owns Children

Major GPA

Age Name Parent_SID

10 Bart 1234
8 Lisa 5678

* Primary key of Children is Parent_SID + Name

Representation of Relationship
Set
--This is a little more complicated--
 Unary/Binary Relationship set
 Depends on the cardinality and participation of the
relationship
 Two possible approaches
 N-ary (multiple) Relationship set
 Primary Key Issue
 Identifying Relationship
 No relational model representation necessary
Representing Relationship Set
Unary/Binary Relationship
 For one-to-one relationship w/out total participation
◦ Build a table with two columns, one column for
each participating entity set’s primary key. Add
successive columns, one for each descriptive
attributes of the relationship set (if any).
 For one-to-one relationship with one entity set
having total participation
◦ Augment one extra column on the right side of the
table of the entity set with total participation, put
in there the primary key of the entity set without
complete participation as per to the relationship.
Example – One-to-One
Relationship Set Degree
SID Name ID Code

Student study Major

Major GPA

SID Maj_ID Co S_Degree

9999 07 1234
8888 05 5678

* Primary key can be either SID or Maj_ID_Co

Example – One-to-One
Relationship Set Condition
SID Name 1:1 Relationship S/N #

Student Have Laptop

Major GPA Brand

SID Name Major GPA LP_S/N Hav_Cond

9999 Bart Economy -4.0 123-456 Own
8888 Lisa Physics 4.0 567-890 Loan

* Primary key can be either SID or LP_S/N

Representing Relationship Set
Unary/Binary Relationship
 For one-to-many relationship w/out total
participation
◦ Same thing as one-to-one
 For one-to-many/many-to-one relationship
with one entity set having total
participation on “many” side
◦ Augment one extra column on the right side of
the table of the entity set on the “many” side, put
in there the primary key of the entity set on the
“one” side as per to the relationship.
Example – Many-to-One
Relationship Set Semester
SID Name N:1 Relationship SSN

Student Advisor Professor

Major GPA Dept Name

SID Name Major GPA Pro_SSN Ad_Sem

9999 Bart Economy -4.0 123-456 Fall 2006
8888 Lisa Physics 4.0 567-890 Fall 2005

* Primary key of this table is SID

Representing Relationship Set
Unary/Binary Relationship
 For many-to-many relationship
◦ Same thing as one-to-one relationship without
total participation.
◦ Primary key of this new schema is the union of
the foreign keys of both entity sets.
◦ No augmentation approach possible…
Representing Relationship Set
N-ary Relationship
 Intuitively Simple
◦ Build a new table with as many columns as
there are attributes for the union of the primary
keys of all participating entity sets.
◦ Augment additional columns for descriptive
attributes of the relationship set (if necessary)
◦ The primary key of this table is the union of all
primary keys of entity sets that are on “many”
side
◦ That is it, we are done.
 Example
P-Key1
– N-ary Relationship Set
D-Attribute A-Key
E-Set 1

P-Key2 A relationship Another Set

E-Set 2

P-Key3

E-Set 3

P-Key1 P-Key2 P-Key3 A-Key D-Attribute

9999 8888 7777 6666 Yes
1234 5678 9012 3456 No

* Primary key of this table is P-Key1 + P-Key2 + P-Key3

Representing Relationship Set
Identifying Relationship
 This is what you have to know
◦ You DON’T have to build a table/schema for the
identifying relationship set once you have built
a table/schema for the corresponding weak
entity set
◦ Reason:
 A special case of one-to-many with total participation
 Reduce Redundancy
Representing Composite
Attribute
 Relational Model Indivisibility Rule Applies
 One column for each component attribute
 NO column for the composite attribute

itself
SSN Name

SSN Name Street City

Professor 9999 Dr. Smith 50 1st St. Fake City
8888 Dr. Lee 1 B St. San Jose
Address

Street City
Representing Multivalue
Attribute
 For each multivalue attribute in an entity
set/relationship set
◦ Build a new relation schema with two columns
◦ One column for the primary keys of the entity
set/relationship set that has the multivalue
attribute
◦ Another column for the multivalue attributes.
Each cell of this column holds only one value.
So each value is represented as an unique tuple
◦ Primary key for this schema is the union of all
attributes
 Example – Multivalue
attribute The primary key for this
SID Name
table is Student_SID +
Children, the union of all
Children attributes
Student

Major GPA

Stud_SID Children
1234 Johnson
1234 Mary
SID Name Major GPA
5678 Bart
1234 John CS 2.8
5678 Lisa
5678 Homer EE 3.6
5678 Maggie
Representing Class
Hierarchy
 Two general approaches depending on
disjointness and completeness
◦ For non-disjoint and/or non-complete class
hierarchy:
 create a table for each super class entity set
according to normal entity set translation method.
 Create a table for each subclass entity set with a
column for each of the attributes of that entity set
plus one for each attributes of the primary key of the
super class entity set
 This primary key from super class entity set is also
used as the primary key for this new table
Example SSN Name

Person

SID Status
Gender
ISA
Student

Major GPA

SSN Name Gender

1234 Homer Male
5678 Marge Female

SSN SID Status Major GPA

1234 9999 Full CS 2.8
5678 8888 Part EE 3.6
Representing Class
Hierarchy
 Two general approaches depending on
disjointness and completeness
◦ For disjoint AND complete mapping class
hierarchy:
◦ DO NOT create a table for the super class entity
set
◦ Create a table for each subclass entity set
include all attributes of that subclass entity set
and attributes of the superclass entity set

◦ Simple and Intuitive enough, need example?

Exampl SSN Name
No table created for superclass

e entity set

SJSU people

ISA
SID
Student Faculty
Disjoint and Complete
mapping
Major GPA Dept

SSN Name SID Major GPA SSN Name Dept

1234 John 9999 CS 2.8 1234 Homer C.S.
5678 Mary 8888 EE 3.6 5678 Marge Math
Representing Aggregation
Name SSN Name

Student Advisor Professor

Dept
SID

Name
member
Primary Key of Advisor
Dept

SID Code Code

1234 04
Primary key of Dept
5678 08
Finally, we are done
Applause??
 Thank you…