Introduction

to Databases

A Brief History

The land when applications ruled the world

An accounting program stores accounting data

A marketing program stores marketing data
An operations program stores marketing data

Databases were part of the application

program that nobody ever noticed (or
changed)

History ctd.

If a customer changes an address, it has to

be updated in each program

Accounting

Marketing

Operations

Problems with the Applications

Approach

Data Storage

Data Updating

Changes or additions must be performed multiple times

Currency of Information

Redundancy and duplicate data

Potential problem of failing to update all affected files

Task-Data Dependency

Files structured, formatted and arranged to suit a specific need.

Each user maintains a separate file for their own use
Individual data files are not related to other files thus integration is difficult
Users inability to obtain additional information as needs change
Difficult to share data
Users own rather than share data

The Database Grows Up

Moores law says:

Every 2 years one of two things will happen

Youll get 2x the computer storage memory for the same price
The price of your current memory will be cut in half

With more disk storage, companies were able to save more

data
All of this data put the focus on the database
Databases were developed as standalone systems
Databases became the engine behind application programs
Why not make one database for the application programs to
feed off of?

Customer address only gets changed once

All application programs see (accounting, marketing, ops)

One Database
Operations

Marketing

Accounting

Standardized Data Format

A data store for the
various applications to pull
from

DBMS Models

Hierarchical
Network
Relational
Industry standard
Column-oriented
Stores data as columns
instead of rows
Extremely fast retrieval
capability in huge data
stores

Past

Future

Information Management
System (IMS)
Hierarchical database
Designed in 1966 for Apollo
rocket program
Now used heavily in banking
industry, especially for ATMs
Used by Federal Reserve
$1B per year business for
IBM
Vern Watts Chief Architect of IMS

The Relational Database

Mathematical mapping of data
No more parent to child relationships
More flexible for business
The defacto standard in databases
Strengthened by the rise of SQL
Relational Databases of note:
Oracle
IBM
mySQL
SAP
More relational database history
http://www.nap.edu/readingroom/books/far/c
h6.html
E.F. Codd

Elements of a Relational
Database
Forms
(User Friendly Way to Enter Data)

Table
(House Data)

Table
(House Data)

Table
(House Data)

Queries
(Join Tables to Get Required Fields)

Reports
(make it pretty)

Table
(House Data)

Components of the Data

Model

Entities

Resources
Events
Agents

Relationships

1:1
1:M, M:1
M:M

Entities

Identify resources, events and agents (found on right

side of Overview Activity Diagram)
Common resources

Common events

Inventory
Cash Accounts
Purchase, Receipt of Inventory, Pay Vendor
Receive Order, Pick Goods, Ship Order, Bill, Receive Cash

Common Agents

Customer, Vendor, Employee

Relationships

Relationships between entities are determined by

analyzing the activity diagram (or narrative if
diagram not given)

If a relationship exists then the tables are linked

Often relationships exist between:

If have an ideal activity diagram, all relationships

known

resources and events

events and agents
events and events

To link tables, need to understand the type of

relationship between the tables - called cardinality

Cardinalities

The cardinality is the degree to which

each entity participates in the relationship
Lets start by looking at some relationships
between entities so that we can see why
they are set up that way

One-to-one relationship

If one instance of Employee, how many Spouses

are possibly related? Put answer by Spouse.
1
Employee

Spouse

If one instance of Spouse, how many Employees

are possibly related? Put answer by Employee.

Many-to-one relationship
If one instance of Employee, how many
Departments are possibly related? Put answer by
Department.
Employee

Department

If one instance of Department, how many

Employees are possibly related? Put answer by
Employee.

One-to-Many relationship
If one instance of Department, how many
Employees are possibly related? Put answer by
Employee.
Department

Employee

If one instance of Employee, how many

Departments are possibly related? Put answer by
Department.

Many-to-Many relationship
If one instance of Sale, how many Shipments are
possibly related? Put answer by Shipments.

Sale

Shipment

If one instance of Shipment, how many Sales are

possibly related? Put answer by Sales.

Practice(Assume most typical/general

case)

Textbook

Class

Payment

Cashier

Vendor

Purchase
Order

Receiving
Report

Receiving
Clerk

Invoice

Inventory
Item

Diving Deeper

Define attributes (fields) for

each entity
Customer

Billing

CustomerID

InvoiceID

Last_Name

Invoice_Date

Address

CustomerID

The Primary Key

Each entity must have a primary key

Think of the primary key as the unique
identifier of each instance of the entity (like a
row on an Excel spreadsheet)
To relate two tables you place the primary
key (PK) of one table into the table you want
to relate it to
The PK used to relate the two tables is called
a foreign key (FK) in the table where it is
placed

Foreign Key Rules

A Foreign key is required for each 1:1 and

1:M relationship
For 1:M, the foreign key is put in the M side
consisting of the primary key from the table
on the 1 side
For 1:1 events, the foreign key is put in the
table representing the second event and
points back to the first event.

M:M relationships

We need to create a table between all M:M

relationships using the PKs of the two tables
as a composite PK of the table in the middle

Tables and Relationships

Inventory Table
Prod no.
Description
Std. Price

Primary key
Foreign key

Inventory-Sale Table
Prod no.
Invoice no.
Qty. ordered
Qty. shipped
Unit Sale Price

Sale Table
Invoice no.
Invoice Date
Total Sale
Account no.
Clerk Emp. no

Customer Table
Account no.
Name
Attention
Street
City
State
Zip

Sales Clerk Table

Clerk Emp. no
Name