Transcript Chapter 1: Introduction

Chapter 1: Introduction
1.1
Chapter 1: Introduction
 Purpose of Database Systems
 View of Data
 Database Languages
 Relational Databases
 Database Design
 Database Users and Administrators
 Overall Structure
 Database Architecture
1.2
Database Management System (DBMS)
 DBMS contains information about a particular enterprise

Collection of interrelated data

Set of programs to access the data

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

Telecommunication: records of calls, generating monthly bills

Manufacturing: production, inventory, orders, supply chain

Finance: customers, sales, stocks, bonds, market data
 Databases touch all aspects of our lives
1.3
Purpose of Database Systems
 In the early days, database applications were built directly on top of
file systems
 Drawbacks of using file systems to store data:

Data redundancy and inconsistency


Difficulty in accessing data


Need to write a new program to carry out each new task
Data isolation


Multiple file formats, duplication of information in different files
Because data are scattered in various files, and files may be
in different formats, writing new application programs to
retrieve appropriate data is difficult
Integrity problems

The data values stored in the database must satisfy certain
types of consistency constraints

Especially, when constraints involve several data items from
different files
1.4
Purpose of Database Systems (Cont.)
 Drawbacks of using file systems (cont.)

Atomicity of updates
 If a failure occurs, the data be restored to the consistent state
existed prior to the failure
 For example: a program to transfer $50 from account A to account
B --- either both the credit and debit occur, or that neither occur
It is difficult to ensure atomicity in a file-processing system
 Concurrent access by multiple users
 Concurrent accessed needed for performance
 Uncontrolled concurrent accesses can lead to inconsistencies
– Example: Two people reading a balance and updating it at the
same time
 Security problems
 Hard to provide user access to some, but not all, data
 Database systems offer solutions to all the above problems

1.5
Levels of Abstraction
 Data Abstraction

For the system to be usable, it must retrieve data efficiently
 The need for efficiency has led designers to use complex data
structures to represent data
 Developers hide the complexity from users through several levels of
abstraction, to simplify users’ interactions with the system
 Physical level:

Describe how the data are actually stored
 Describe complex low-level data structures in detail
 The lowest level of abstraction
 Logical level:

Describe what data are stored in the database, and what
relationships exist among those data
 Database administrators must decide what information to keep in
the database
1.6
Levels of Abstraction
 Logical level (cont.):

Analogy to the concept of data types in programming language
type customer = record
customer_id : string;
customer_name : string;
customer_street : string;
customer_city : integer;
end;
 View level:

The highest level of abstraction describes only part of the entire
database
Simplify users’ interaction with the system
 Views can also hide information (such as an employee’s salary)
for security purposes.
 The system may provide many views for the same database

1.7
View of Data
The three levels of database abstraction
1.8
Instances and Schemas
 Schema – the logical structure of the database

Example: 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

Subschema: describe different views of the database
 Instance – the actual content of the database at a particular point in time

Analogous to the value of a variable
1.9
Data Models
 Data Independence

The ability to modify a schema definition in one level without
affecting a schema definition in the next higher level

Physical data independence: The ability to modify the physical
schema without changing the logical schema

Logical data independence: Modify the logical schema without
affecting application programs
 Data models

A collection of conceptual tools for describing data, data
relationships, data semantics, and consistency constraints
 Entity-Relationship data model
 Relational data model

Object-based data models (Object-oriented and Objectrelational)

Semistructured data model (XML)
1.10
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

Declarative (nonprocedural) – user specifies what data is
required without specifying how to get those data
 SQL is the most widely used query language
1.11
Data Definition Language (DDL)
 Specification notation for defining the database schema
Example:
create table account (
account-number
balance
char(10),
integer)
 DDL compiler generates a set of tables stored in a data dictionary
 Data dictionary contains metadata (i.e., data about data)

Database schema

Integrity constraints

The database systems check these constraints every time the
database is updated

Authorization

A database system consults the data dictionary before reading or
modifying actual data
1.12
Relational Model
Attributes
 Example of tabular data in the relational model
1.13
A Sample Relational Database
1.14
SQL
 SQL: widely used non-procedural language

Example: 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’

Example: 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
1.15
Database Design
The process of designing the general structure of the database:
 Logical Design – Deciding on the database schema. Database design
requires that we find a “good” collection of relation schemas.

Business decision – What attributes should we record in the
database?

Computer Science decision – What relation schemas should we
have and how should the attributes be distributed among the various
relation schemas?
 Physical Design – Deciding on the physical layout of the database
1.16
The Entity-Relationship Model
 Models an enterprise as a collection of entities and relationships
Entity: a “thing” or “object” in the enterprise that is distinguishable
from other objects
 Described by a set of attributes
 Relationship: an association among several entities
 Represented diagrammatically by an entity-relationship diagram:

 Database design in E-R model usually converted to design in the
relational model which is used for storage and processing
1.17
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
 Naïve users – invoke one of the permanent application programs that
have been written previously

Examples, people accessing database over the web
 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.
1.18
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
Periodically backing up the database
Monitoring performance and responding to changes in
requirements
1.19
Overall System Structure
1.20
Application Architectures
 Two-tier architecture
 Three-tier architecture
1.21
End of Chapter 1
Database System Concepts, 5th Ed.