Chapter 1

Databases and
Database Users

Copyright © 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

 Outline
1. Applications of database
2. Concepts of Database
3. Simplified database system environment.
4. An introduction example about Database
5. Phases for designing a database
6. Characteristics of the Database Approach
1. Data Abstraction
2. Support of Multiple Views of the Data
3. Sharing of Data and MTP
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
 Outline
7. Actors on the Scene
8. Workers behind the Scene
9. Advantages of Using the DBMS Approach
10.When Not to Use a DBMS
11.Summary

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Outline
1. Applications of database
2. Concepts of Database
3. Simplified database system environment.
4. An introduction example about Database
5. Phases for designing a database
6. Characteristics of the Database Approach
1. Data Abstraction
2. Support of Multiple Views of the Data
3. Sharing of Data and MTP
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
 Applications of database
 Traditional database applications
 Store textual or numeric information
 Multimedia databases
 Store images, audio clips, and video streams
digitally
 Geographic information systems (GIS)
 Store and analyze maps, weather data, and
satellite images

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Applications of database
 Data warehouses and online analytical
processing (OLAP) systems
 Extract and analyze useful business
information from very large databases
 Support decision making

 Real-time and active database

technology
 Control industrial and manufacturing processes

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Outline
1. Applications of database
2. Concepts of Database
3. Simplified database system environment.
4. An introduction example about Database
5. Phases for designing a database
6. Characteristics of the Database Approach
1. Data Abstraction
2. Support of Multiple Views of the Data
3. Sharing of Data and MTP
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
 Concepts of DB
 Database
 Collection of related data
 Known facts that can be recorded and that
have implicit meaning
 Miniworld or universe of discourse (UoD)
 Represents some aspect of the real world
 Logically coherent collection of data with
inherent meaning
 Built for a specific purpose

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Concepts of DB
 Database management system (DBMS)
 Collection of programs
 Enables users to create and maintain a
database
 Defining a database
 Specify the data types, structures, and
constraints of the data to be stored

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Concepts of DB
 Meta-data
 Database definition or descriptive information
 Stored by the DBMS in the form of a database
catalog or dictionary
 Manipulating a database
 Query and update the database miniworld
 Generate reports

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Concepts of DB
 Sharing a database
 Allow multiple users and programs to access
the database simultaneously
 Application program
 Accesses database by sending queries to
DBMS
 Query
 Causes some data to be retrieved
 As select the employee no with salary > 2000

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Concepts of DB
 Transaction
 May cause some data to be read and some
data to be written into the database.
 Protection includes:
 System protection
 Security protection

 Maintain the database system

 Process to monitoring and maintaining the
system following installation.
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
 As Student, Dean
Teacher …

As the CST’s
System

Oracle
MySql
Access

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Outline
1. Applications of database
2. Concepts of Database
3. Simplified database system environment.
4. An introduction example about Database
5. Phases for designing a database
6. Characteristics of the Database Approach
1. Data Abstraction
2. Support of Multiple Views of the Data
3. Sharing of Data and MTP

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 An introduction example
 UNIVERSITY database
 Information concerning students, courses, and
grades in a university environment
 Data records
 STUDENT
 COURSE
 SECTION
 GRADE_REPORT
 PREREQUISITE
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
 An introduction example
 Specify structure of Entity by specifying
data type for each data element
(attribute) as:
 Student:
 Name is String of alphabetic characters
 ID: Integer
 Etc.

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 An introduction example
 Construct UNIVERSITY database
 Store data to represent each student, course,
section, grade report, and prerequisite as a
record in appropriate file
 Record is a row in table

 Relationships among the records

 Manipulation involves querying and
updating

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 An introduction example
 Examples of queries:
 Retrieve the transcript
 List the names of students who took the
section of the ‘Database’ course offered in fall
2008 and their grades in that section more than
80
 List the prerequisites of the ‘Database’ course

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 An introduction example
 Examples of updates:
 Change the class of ‘Ali’ to number 2
 Create a new section for the ‘Database’ course
for this semester
 Enter a grade ‘A’ for ‘Ahmad’ in the ‘Database’
course of last semester

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

Copyright © 2011 Ramez Elmasri and Shamkant Navathe
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
 Outline
1. Applications of database
2. Concepts of Database
3. Simplified database system environment.
4. An introduction example about Database
5. Phases for designing a database
6. Characteristics of the Database Approach
1. Data Abstraction
2. Support of Multiple Views of the Data
3. Sharing of Data and MTP
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
Phases for designing a database
Conceptual design
Different people
have different
views of the
database…these
are the external
schema

Logical & Physical design

The internal
schema is the
underlying
design and
implementation

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

Phases for designing a database
 Requirements specification and analysis
 Conceptual design:
 To build the conceptual representation of the
database, which includes identification of
important entity and relationship (what?).
 Conceptual representation of data does not
include details of how data is stored or how
operations are implemented.

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

Phases for designing a database
 Logical design :
 To translate the conceptual representation to
the logical structure of the database, which
includes designing the relations.
 Physical design
 To allow the designer to decide how the logical
structure is to be physically implemented on
the target DBMS (How?).

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Outline
1. Applications of database
2. Concepts of Database
3. Simplified database system environment.
4. An introduction example about Database
5. Phases for designing a database
6. Characteristics of the Database Approach
1. Data Abstraction
2. Support of Multiple Views of the Data
3. Sharing of Data and MTP
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
 1. Data Abstraction
 Data abstraction
 Allows program-data independence and
program-operation independence.
 Data abstraction is that we can change the
internal definition of an object without affecting
the users of the object, provided the external
definition remains the same.

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 1. Data Abstraction (continue)

 Data model
 Type of data abstraction used to provide
conceptual representation.
 An integrated collection of concepts for
describing data, relationships between data,
and constrains on the data in an organization.

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 2. Support of Multiple Views of
the Data
 View
 Subset of the database
 Contains virtual data derived from the
database files but is not explicitly stored
 Multiuser DBMS
 Users have a variety of distinct applications
 Must provide facilities for defining multiple
views

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 3. Sharing of Data and Multiuser
Transaction Processing
 Allow multiple users to access the database
at the same time
 Concurrency control software
 Ensure that several users trying to update the
same data do so in a controlled manner
• Result of the updates is correct
 Online transaction processing (OLTP)
application

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 3. Sharing of Data and Multiuser
Transaction Processing (continue)
 Transaction
 Central to many database applications
 Executing program or process that includes
one or more database operations
 Isolation property
• Each transaction appears to execute in isolation
from other transactions
 Atomicity property
• Either all the database operations in a transaction
are executed or none are

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Outline
7. Actors on the Scene
8. Workers behind the Scene
9. Advantages of Using the DBMS Approach
10.When Not to Use a DBMS
11.Summary

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Actors on the Scene
 Database administrators (DBA) are
responsible for:
 Authorizing access to the database
 Coordinating and monitoring its use
 Acquiring software and hardware resources

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Actors on the Scene
 End users
 People whose jobs require access to the
database
 Types
• Casual end users
• Naive or parametric end users
• Sophisticated end users
• Standalone users

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Actors on the Scene
 System analysts
 Determine requirements of end users
 Database designers are responsible for:
 Identifying the data to be stored
 Choosing appropriate structures to represent
and store this data
 Application programmers
 Implement these specifications as programs

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Outline
7. Actors on the Scene
8. Workers behind the Scene
9. Advantages of Using the DBMS Approach
10.When Not to Use a DBMS
11.Summary

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Workers behind the Scene
 DBMS system designers and
implementers
 Design and implement the DBMS modules and
interfaces as a software package
 Operators and maintenance personnel
 Responsible for running and maintenance of
hardware and software environment for
database system.

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Outline
7. Actors on the Scene
8. Workers behind the Scene
9. Advantages of Using the DBMS Approach
10.When Not to Use a DBMS
11.Summary

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Advantages of Using the
DBMS Approach
1. Controlling redundancy
 Data normalization
• Sometimes necessary to use controlled
redundancy to improve the performance of queries
2. Restricting unauthorized access
 Security and authorization subsystem
 Privileged software

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Advantages of Using the
DBMS Approach (continue)
3. Providing storage structures and search
techniques for efficient query processing.
 Indexes
 Buffering and caching
 Query processing and optimization

Case Study: What I is the main difference between Buffering and

caching?

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Advantages of Using the
DBMS Approach (continue)
4. Providing backup and recovery
 Backup and recovery subsystem of the
DBMS is responsible for recovery

5. Providing multiple user interfaces

 Graphical user interfaces (GUIs)

6. Representing complex relationships

among data
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
 Advantages of Using the
DBMS Approach (continue)
7. Permitting inferencing and actions
using rules
 Deductive database systems
• Provide capabilities for defining deduction rules
• Inferencing new information from the stored
database facts
 Trigger
• Rule activated by updates to the table
 Stored procedures
• More involved procedures to enforce rules
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
 Advantages of Using the
DBMS Approach (continue)
8. Data Integrity
Example, before inserting salary information for an employee,
the DBMS can check that the department budget is not
exceeded. Also, it can enforce access that govern what data is
visible to different classes of users.

9. Economies of scale

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Advantages of Using the
DBMS Approach (continue)
10. Data Independence:
Application programs should not, ideally, be exposed to
details of data representation and storage
11. Efficient Data Access:
A DBMS utilizes a variety of sophisticated techniques to
store and retrieve data efficiently.

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Advantages of Using the
DBMS Approach (continue)
12. Data Administration:
When several users share the data, centralizing the
administration of data can offer significant improvements.
13. Concurrent Access and Crash
Recovery:
A DBMS schedules concurrent accesses to the data in such
a manner that users can think of the data as being
accessed by only one user at a time.

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Advantages of Using the
DBMS Approach (continue)
14. Reduced Application Development
Time:
DBMS applications are likely to be more robust than
similar stand-alone applications because many important
tasks are handled by the DBMS (and do not have to be
debugged and tested in the application).

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Outline
7. Actors on the Scene
8. Workers behind the Scene
9. Advantages of Using the DBMS Approach
10.When Not to Use a DBMS
11.Summary

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 When Not to Use a DBMS
 High initial investment in hardware,
software, and training
 More desirable to use regular files for:
 Simple, well-defined database applications not
expected to change at all
 Embedded systems with limited storage capacity
 No multiple-user access to data

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Outline
7. Actors on the Scene
8. Workers behind the Scene
9. Advantages of Using the DBMS Approach
10.When Not to Use a DBMS
11.Summary

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Summary
 Database
 Collection of related data (recorded facts)
 DBMS
 Generalized software package for
implementing and maintaining a computerized
database
 Several categories of database users
 Database applications have evolved

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 File Systems Versus A DBMS
let us consider a motivating scenario:
 A company has a large collection (say, 500
GB) of data on employees, departments,
products, sales, and so on.
 This data is accessed concurrently by several
employees.

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 File Systems Versus A DBMS (2)
 We probably do not have 500 GB of main memory to hold all
the data.
 We must therefore store data in a storage device such as a
disk or tape and bring relevant parts into main memory for
processing as needed.
 Even if we have 500 GB of main memory, on computer
systems with 32-bit addressing, we cannot refer directly to
more than about 4 GB of data.
 Have to program some method of identifying all data items.
 Have to write special programs to answer each question a
user may want to ask about the data (complex program)

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 File Systems Versus A DBMS (3)
 Must protect the data from inconsistent changes made by
different users
 accessing the data concurrently.
 Must ensure that data is restored to a consistent state if
the system
 crashes while changes are being made.
 Operating systems provide only a password mechanism
for security. This is not sufficiently flexible to enforce
security policies in which different users have permission
to access different subsets of the data.

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

Database Terms - and their Meanings

Database
A database is a collection of data that is organized
in a specific way.
The data is stored in a way that makes it easy to
access using queries.

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

Database Terms - and their Meanings

Table
 A database can have multiple tables in it.
 All the data is stored in the tables.
 A table has a set of fields in it.
 These fields makes the design or the structure of
the database.

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

Database Terms - and their Meanings

Field
Each table has a set of fields.
Our example table ‘student' has four fields - id,
name, …...

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Attribute
 Describes the value found in each field in a table.
Every field or column in a database table
represents a single attribute of that table.
 (An attribute is what the data in that
field represents, while the value is the actual data
that a specific field contains.

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

Database Terms - and their Meanings
Data Type
 Each field can have only one kind of data. That is
called the Data Type of that field.
 This can be a string, an integer, a date, etc.
 When creating a table, you have to specify the kind
of data that can be stored in that field.
 One field can be used to store a number, another
for a string since every table has a number of fields,
different types of data can be stored in a table.
The data type in our example table ‘student' are...
•id – integer & name - string

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

Database Terms - and their Meanings

Row
 All the terms till now dealt with the structure - row
refers to the data. It can also called a record.
 The collection of a set of values for all fields in
one table is together called a row.

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

 Database Terms - and their Meanings
Primary Key
 Primary key is a field that will uniquely identify each
row in the table.
 The value of this field will be unique through the
table.
 In our example table, 'id' is the primary key. This will
be 1 for the first row, 2 for the second and so on.

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

Database Terms - and their Meanings

Relationship
There will be many cases when the data in one
table can be related to the data in another table.
This connection between two tables is called a
relationship.

Copyright © 2011 Ramez Elmasri and Shamkant Navathe

Database Terms - and their Meanings
Foreign Key
 When there is a relation between 2 tables, these
tables will be connected by inserting the primary
key of one table into the corresponding row of
the other table.
 The field used in such a way to connect the 2
tables is called the foreign key.
 For example, the ‘student' table has 4 fields id,
name, and …...
 The “name” field will have the key of the student
who reserve a course
Copyright © 2011 Ramez Elmasri and Shamkant Navathe