1. CS 325 Spring ‘09 Chapter 1 Goals:
* database mindset (why is this important?)
* jump into the terminology
* introduce ideas that come later
Read sections
Problems: 1.1, 1.2, 1.4, 1.5, 1.6, 1.7.

2. Database Management System (DBMS)
Information about a particular enterprise
Two components:
Data
Programs to access the data
Goal: convenient and efficient
Give an example of information that is interesting/useful to you
What is the information?
Is there an organization to it?
What do you want to do with it?
How could you use C++ to do this?
What problems are associated with using this information effectively?

3. Purpose of a DBMS
To handle problems of typical file-processing systems
Data redundancy and inconsistency
Difficulty in accessing data
Data isolation — multiple files and formats
Integrity — e.g. assuring that age ≥ 0
Concurrent access by multiple users
Atomicity of updates — funds transfer from one account to another should be complete or not happen at all
Security

4. Database System Architecture

5. Levels of Abstraction Physical level: how data is stored
Logical level:
What data is stored in database
Relationships among the data (later)
View level:
Different users need different information; e.g. the system might hide salary information from some users
Users do not need to know implementation details
Analogy with C++:
Physical: a list of 10 elements starts in location 1000 and each element takes 2 bytes; a record is stored ....
Logical: int numbers[10]; struct{ }
View: a menu-driven program
How do C++ classes fit here?

6. Instances and Schemas Schema Instance
The structure of the database; e.g.,
logical: customers and accounts and their relationship
physical: how a customer record is stored in the database
Instance
The content of the database at a particular point in time (e.g. the particular customers and their accounts)
Similar to types and variables in C++

7. Data Independence
Ability to modify a schema definition in a level without affecting a schema definition in the next higher level
Two levels of data independence
Physical
ability to modify the physical schema without rewriting logical schema or applications
a database stores information differently on a Mac than on a PC
Logical
ability to modify the logical schema without rewriting applications
one might want to add a field to a customer record
Analogy: C++ classes
Implementation (xx.cpp) can change without altering specification (xx.h)
Both can be used in different applications and on different compilers

8. Data Models A collection of tools for describing
data relationships
data semantics
data constraints
Entity-relationship model
Relational model
Other models:
Object-oriented
Older:
network model
hierarchical model
Emphasis on mathematical models has made the field less ad hoc

9. Entity-Relationship (ER) Model
Example schema:
Entities: customer, account
Relationship: depositor
Attributes: customer-id, customer-name, customer-street, customer-city,
account-number, balance

10. Tabular Data in the Relational Model
Attributes
customer-
name
customer-
street
customer-
city
account-
number
Customer-id
Johnson
Smith
Jones
Alma
North
Main
Palo Alto
Rye
Harrison
A-101
A-215
A-201
A-217
customer entity set

11. Database Languages Database Definition Language (DDL)
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 (data about data)
Data Manipulation Language (DML)
For accessing and manipulating the data
Two types:
procedural – specifies what data is required and how to get it
nonprocedural – describes the data but not how to get it
Most widely used for both: SQL (nonprocedural)
select account-number
from account

12. Beyond the Relational Model
The relational model used to be the gold standard
Emerging models:
Object-based
Semistructured
Extends ER with encapsulation, inheritance, information hiding, structured types...
Allows an object to have different structures (an address structure might differ, based on country)
Data is often packaged in XML

13. Overall System Structure

14. 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”

15. Database Administrator versus User
Database administrator duties:
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
Responding to changes in requirements
Database users
Application programmers – interact through DML calls
Sophisticated users – requests in a query language
Naïve users – invoke an application that someone else wrote

16. Some History
First computers built for calculation. ENIAC at U Penn, 1946.
Late 50's:
Alphanumeric information began to be stored
Business showed interest
COBOL designed to handle large files for business applications
File processing on sequential files (CS 131)
60's, 70's: Commercially available DBMS as opposed to programs written from scratch
70's, 80's:
Relational model: a mathematical foundation, conceptually appealing; originally inefficient.
Commercial DBMSs available on microcomputers
Late 90's: web interfaces
Today: DBMS integrated with most enterprises