Database Application

Development Methodology
- an Example
Leo Mark & Rocky Dunlap
College of Computing
Georgia Tech

opyright: Leo Mark and Rocky Dunlap

Assumptions

Business process is well-designed

Documents are known
Tasks are known
System boundary is known
One database schema unifying all views can be
designed
difficult: interests, goals, power, politics
problems with the methodology?
problems with the organization?
or-ga-ni-za-tion: an entity created to pursue a shared
set of goals
2

Un
Da iqu
Me tab e fo
th a s r
od e
ol
og
y

Business process
(re-)design
Analysis
Specification
Design
Implementation
Testing
Operation
Maintenance

Management

The Software Process

Overview of the Methodology

- data first!!
2b

3b
Tasks

Information
Flow
1 Diagram 2a

ER
Diagram
1
2
3
4

3a

Abstract
Code
w/SQL
Relational
Schema

4b

4a

PHP Code
w/SQL
MySQL
Relational
Platform

Analysis
Specification
Design
Implementation
4

Example Project Description

The project description represents
the customer:
Business process
Documents
Tasks
System boundary

GTOnline is a simple social networking application

with a set of basic features similar to those found on
sites like Facebook and LinkedIn. GTOnline users
maintain a basic profile including their name, birth
date, hometown, current city, schools they have
attended, and places of employment. Users can
connect to other users by sending friend requests. If
a request is accepted, then a friendship link is
established between the two users. In addition to
maintaining basic profile information, users can let
their friends know what they are currently doing by
writing status updates. Users can also comment on
their friends status updates as well as their own
6
status updates. The GTOnline application also

GTOnline is a simple social networking application

with a set of basic features similar to those found on
sites like Facebook and LinkedIn. GTOnline users
maintain a basic profile including their name, birth
Reacity, schools they have
date, hometown, current
d th
e fu
d
esemployment.
attended, and places of
crip
ll ex Users can
tion
amp
!
connect to other users
by
sending
friend
requests.
If
le p
Scre
en sa friendship link is roject
a request is accepted,
then
hots
requ
and In addition to
iretwo
established between
menusers.
on the
t s n i s ma l l
the
ppetusers can let
maintaining basic nprofile
ollow
ot su finformation,
s are
i
n
g
ffi
their friends knowapwhat they
are currently doing by
plica cient to slides. T shown
hese on
writing status updates. tUsers
comment
ion i candalso
e
v
e
n
l pt
is exas otheir
heownare
their friends status updates asth
well
a mp
7
e.
status updates. The GTOnline application lalso

10

[Requirem
ent]: .. L
ogging In
login scre
to GTOnlin
en. All use
e via the
rs are uniq
Email Add
uely identifi
ress. Prov
ed by his o
iding a vali
Password
r her
d Email A
combinatio
d
d
r
ess and
n will log th
Providing in
e user into
valid login
the system
credentials
message a
.
should disp
nd return t
lay an erro
he user to
r
the login sc
[Requi
re
e
n
.
re
GTOnlin ment]: .. U
sers wh
e
o are n
provide must register
e
d direc
fi
r
s
t
.
A Regis w to
tly on t
button
ter but
he login
display
ton is
p
s
a
the new
After th
ge. Cli
cking t
e user
his
clicks R user registra
should
tion for
egiste
verify t
m.
r, t
ha
Email
Addres t all fields are he system
s has n
fi
and tha
ot alrea lled in, that t
t the P
he
dy
as
fields a
re equa sword and C been register
ed,
onfirm
l.
Passw
ord
xcept ing
e
(
s
user s contain
e
n
i
nl
le
isters
O
f
g
T
o
e
r
r
G
P
user to the
ser
. . Al l
U
w

e
a
:
n
]
ent
have . After a
iately ude the
m
)
d
e
s
e
r
r
i
e
m
u
m
l
s
en im erties inc , and
[Req strative u about the
k
a
t
ni
wn
ld be
prop
tion
o
u
a
t
e
l
o
admi
e
m
fi
h
r
s
o
info
Hom
c pr
hey
basic Online, t . The basi ent City,
r
n
GT
scree ate, Cur
with
e
l
fi
ro
hd
Edit P Sex, Birt erests.
s
11
Int
These snippets of task requirements are taken from
ofproject
searcomprehensive
r
u
e
b
description and are just part of what is used to design n
the
IFD Diagram.
um

[Require
ment]:
.. Social
about ma
networks
king conn
are all
ections.
allows u
GTOnlin
sers to s
e
[Requ
earch fo
connect
ireme
r friends
to them
nt]:
a
p
.
n
r
T
d
o
involved
h
fi
e
r
l
e
e
.. The
a
a
r
e
l
in making
several s
profes so contains
teps
a connec
friend on
sio
tion with
GTOnline
a new
user w nal informat
:
The use
ill sele
ion. Th
r searche
c
e
t
E
s
h
m
for a frien
is or h
several p
ploye
e
d based o
rofile crit
r
r
from th
then p
eria inclu
n
Address
e list a
r
d
o
in
v
, and Hom
g Name,
ide a J
nd
ob Tit
Email
Then, th
etown.
le.
e user su
bmits a f
another u
riend req
ser with w
uest to
hom they
connect.
wish to
Finally,
the other
mber of
[Req
u
n
a
e
r
u
a
s
e
e
request a
r
r
e
uirem
h
r
T
e
..
c
e
:
iv
t]
e
n
n
eccep
s
da
t
h
a
ent]:
e
:
l
f
n
r
s
e
ie
[Requirem
e
o
r
tw
nd
c
s it
s
c
le
f
o
o
o
r
r
.. T
P
n
r
e
jects it. list of friends
tains
Vie
t
he pr
h
e
i
e
links on the
n
th
s
u
f
w
o
o
h
s
s
ofile
r
s
e
d
m
n
r
ie

r
ation
F
s edu
w
ie
V
a
g
in
k
v
ic
Cl
ailabl
catio
abou
n
t
e
.
S
r.
T
e
e
c
s
T
th
u
h
f
h
o
y
t
e
u
o
p
o
for this
r
e
o
s
s
e
u
e
l
e
s is m
s and
t of
ut signs th
a
G
t
i
h
n
T
.
e
n
t
O
Clicking Log O
e
a
i
r
nline.
ined
s the login scre
w
b
o
h
s
y
A
d
n
n
a
t
u
u
m
he
mber
ser ca
syste
o
n
:
f
n
a
h
c
s
r
h
ave a
chool
is or h

gged in use
lo
s
ny
y
tl
n
e
a
e
r
r
r
s
u
c
s
profil
e
e
o
th
th
,
p
c
n
e
e
io
r
s
i
it
d
o
a
to
d
s
a
v
t
t
e and
In
ed wi
ide a
ding Reques
n
th
e
c
P
G
w
a
n
e
r
ie
e
n
V
e
a
b
a
g
t
e
c
d
a
y
t
Clickin
o
h
l
u
n
s
e
v
a
o
s
a
h
c
tion
hool.
quests that
Date
list of friend re
for
d
te
c
je
re
r
le
o
fi
d
ro
te
P
p
it
acce
shows the Ed
le
f
o
r
P
it
d
E
changes to his
Clicking
e
k
a
m
to
r
e
s
g the u
screen allowin
12
file.
or her own pro

Analysis
D2

Information Flow Diagram

D3

information
flow; not
control flow
never connect
two documents
never connect
two tasks

D4

D1
T1
Database

T2

T3
T4
D6
D5
task
name

document
name

n
tio
a
rm
info ow
fl

tem
sys

ary
d
n
bou

13

IFD

Use document
and task
names from
the project

Friend
request

Friend
Search
and
Results

14

Dont go there
Login

The IFD is a
model of reality
as described in
the project
description
It is not a model
of the computer
system you
implement

Profile

Friends
Schools/
Employers

Login
Database

Generate
Reports

Maintain
Database

Friends
Report
Other
Report

15

D1

D2

T1

D3

T2

What goes into the

database?
What comes out of the
Everything in the database must come from
database?
somewhere
Everything on the input documents must go
somewhere
Everything in the database must be used for
something
Everything on the output documents must
16
come from somewhere

Specification

EER Diagram
Data Formats
Constraints
Task Decomposition

Le
En arn
Re tit ab
ou
M lat y
tt
od io
he
el ns
hi
p
17

[Requirement]: .. All users are

uniquely identified by his or her
Email Address. Providing a valid
Email Address and Password
combination will log the user into
the system ..

Email

User

Password
FirstName
Name
LastName

[Question]: Should Name be a

composite attribute? Well, you
decide, sort of ..
Name

These snippets of task requirements are taken from a

comprehensive project description and are just part of what
is used to design the ER Diagram.

18

Interests
Sex
Birthdate

RegularUser

CurrentCity
HomeTown

Use attribute
names from
the documents
in the EER
Diagram!
19

[Requirements]: .. All
GTOnline users (except
administrative users) have a
profile containing basic
information about them. ..

Email

Password
FirstName

User

Name

Interests

Birthdate

RegularUser

Sex

LastName

AdminUser

LastLogin

CurrentCity
HomeTown

[Requirements]: .. Administrative users have some of the same

information as regular users (Email Address, Password, First
Name, and Last Name) .., but do not have a full profile and
cannot request friends, etc. A user must be either an
administrator or a regular user, but never both. GTOnline also
tracks the last date and time that an admin user logged in to
the system ..

20

[Requirements]: A list of
Schools, from which the user can
select, is maintained in the system.
Assume that all School Names
will be unique. A user can have any
number of schools associated with
him or her and can provide a
Graduation Date for each school.
.. It is possible that the same
school will appear multiple times
with different graduation dates.
RegularUser
N

YearGraduated

School
SchoolName

21

RegularUser
N

[Requirements]: .. Each school

must have a School Type. There
are four possible types:
College/University, High School,
Middle School, and Elementary
School. .. It should be possible
for the database administrator to
add new school types from behind
the scenes.

YearGraduated

School
N

SchoolName

SchoolType

TypeName

22

RegularUser
N
JobTitle

Employer
EmployerName

[Requirements]: .. Administrators are

responsible for managing the list of
Employers. Assume that all Employers have a
unique Name.
[Requirements]: .. The Job Title field is not managed
by the administrator and can be any value provided by
the user. A profile can contain multiple Employers and
the same Employer may even appear multiple times as
long as the Job Title is different in each case.
23

RegularUser

[Requirements]: .. friendship is
not always reciprocal .. just
because Emily is friends with
Sarah, this does not imply that
Sarah is friends with Emily. ..

accept
request
N

.. the DateConnected field

is set when the friend request
is accepted, not when the
request is originally sent.

Relationship
DateConnected

Friendship
24

EER
Diagram

Email

Password
FirstName

User

Name

Interests

LastName

RegularUser

Birthdate

CurrentCity
HomeTown

request

Relationship
DateConnected

AdminUser

LastLogin

accept

Sex

YearGraduated

School
N

Employer
SchoolName
EmployerName

Friendship

JobTitle

SchoolType

TypeName

25

Reading ER-Diagrams - mechanically

(useful when communicating with your customer)

GTOnline stores Users. There are two kinds of Users. Every User
must be either a RegularUser or an AdminUser. All Users have a
unique Email, a Password, and a Name consisting of FirstName
and LastName. An AdminUser also has a LastLogin. A
RegularUser also has a Sex, a Birthdate, a CurrentCity, a
HomeTown, and multiple Interests. GTOnline stores Employers.
Every Employer has a unique Name. A RegularUser may be
related to many Employers, who in turn may be related to many
RegularUsers. In the relationship between a RegularUser and an
Employer, multiple JobTitles may be stored. GTOnline stores
SchoolType. Every SchoolType has a unique TypeName. GTOnline
stores Schools. Every School has a unique Name. All Schools
must have a SchoolType, which in turn may be the SchoolType
for multiple Schools. A RegularUser may be related to many
Schools, which in turn may be related to many RegularUsers. In
the relationship between a RegularUser and a School, multiple
YearGraduated may be stored. A Friendship must be related to
the one RegularUser who requested it, who in turn may have 26

Data
Formats
Interests steal,
- beg,
Sex borrow
Birthdate
CurrentCity
HomeTown

Email

User

Password
FirstName
Name
LastName

RegularUser User:

Email: max 36 chars. Example:

leomark@cc.gt.edu
Password: max 20 chars. Example: qwerty
Name: FirstName: max 25 chars; Last: max 40
chars
Addresses (when needed) are very very
difficult.
E.g., look at the 208 page
guideline at
http://pe.usps.com/cpim/ftp/pubs/pub28/pub28.
pdf

RegularUser:

Birthdate: Date: 'YYYY-MM-DD'

Sex: {M, F}
27
CurrentCity, HomeTown: max 20 chars, each

Constraints
Examples:
DateConnected is NULL until request is accepted.
Cannot be Friend with yourself.
Can only comment on Status of Friends.
Ignore:
Data formatting constraints
Constraints that can be expressed in the EER
Diagram
28

Task Decomposition
Rules of Thumb:
Lookup vs. insert, delete,
and update?
(different database locks)

How many schema

constructs are involved?
(many database locks)

Are enabling conditions

consistent across tasks?
(let run what can run - scheduling)

Are frequencies
consistent across tasks?
(index only what must be
indexed)

Is consistency essential?
(ACID transaction properties)

Is mother task control

needed or not?
29

Traditionalapps

Web-apps

Traditionally, almost
stateless.
Must have some state, e.g.
email of the session user.
May need some click stream
history.

Things are changing. Socalled Web 2.0 and AJAX

technologies provide more

rich user interface in the Web
browser. These technologies
make it easier to keep state

information locally on the

browser or behind the scenes
on the server (but not in the
DB).
In this sense, the web apps
are beginning to act more

In a traditional app, it is
much easier to manage local
state separately from the DB
(e.g., using smart widgets,
etc.).
A whole slew of changes can
be collected before
submitting them all to the
database.
Supports better control of
ACID transactions execution.

30

Task Decomposition
- ViewProfile

View Profle: three lookups of Personal,

Education, and Professional information for a
RegularUser
All three are read-only.
All three are enabled by a users login or a
friends lookup.
All three have the same frequency.
Several different schema constructs are needed.
Consistency is not critical, even if the profile is
being edited by the user while a friend is looking
at it.
Perso
They can be done in any order.
nal
All three must be done, so mother task is
needed.

View
profile

Educa
tion

Profes
sional
31

Abstract Code
View
profil
e
Perso
nal

Educ
ation

- ViewProfile
Profe
ssion
al

View Profle
Find the current User using the User
Email;
Display User Name;
Find the current RegularUser using the
User Email;
Display RegularUser Sex, Birthdate,
CurrentCity, Hometown, and Interests;
Find each School for the RegularUser
{Display School Name and
YearsGraduated;
Find SchoolType;
Display SchoolType Name};

32

Task Decomposition
- Edit Profile
Edit Profle:
lookups of Personal, Education, and
Professional information of a
RegularUser (use: View Profle)
Lookups of School and Employer lists
Edits of Personal, Education, and
Professional information

Read, insert, delete, and update

All three are enabled by a users login
and separate edit request.
Different frequencies
Several different schema constructs
are needed.
Consistency is not critical, even View
if the
profile
profile
is being looked at by a
friend
of the user
Read
Lookup done first followed by any only
number of edits and lookups

Edit
Profile

Update
personal
Updates
RegularUser
only

Add/Del
school

Updates
RegularUser
and school

Add/Del
job
Updates
RegularUser
and 33
Employer

Abstract Code

- Edit Profile

Edit
Profile
View
profile

Update
persona
l

Add/Del
school

Add/Del
job

Edit Profle
View Profle. Populate School and
Employer dropdowns.
While no buttons are pushed, do nothing.
When a button is pushed, then do the
following:
{If SAVE PERSONAL: Update Personal. View
Profle.
If DELETE THIS SCHOOL: Delete School. View
Profle.
If DELETE THIS JOB: Delete Job. View Profle.
If ADD ANOTHER SCHOOL: View Profle;
display the form with room for another School;
If ADD ANOTHER JOB: View Profle; display
the form with room for another Job
If
SAVE SCHOOL:
Add School.
View
BoldUnderline:
Task definition.
Bold: Task
call. Profle
Italics: Button names

34

Task Decomposition
- Friend Requests, etc.

Read User,
RegularUser,
Friendship

View
reques
ts

View,
Cancel,
Accept,
Reject,
Request

Accept,
Reject,
Cancel

Updates
Friendship

Reques
t
Friend
Updates
Friendship

35

Relational Data Model

Learn about
relations
Learn the EER
Relational
mapping

Le
Re arn
Le
M lat EEre arn
ap io R la
pi na tio abo
ng l
ns ut

36

Email

Password
FirstName

User

Name

Interests

LastName

RegularUser

Birthdate

CurrentCity
HomeTown

request

Relationship
DateConnected

AdminUser

LastLogin

accept

Sex

YearGraduated

School
N

Employer
SchoolName
EmployerName

Friendship

JobTitle

SchoolType

TypeName

37

Relational Schema

38

SQL: Create
Table
Statements
CREATE TABLE `User`(
Email varchar(50) NOT
NULL,
FirstName varchar(50)
NOT NULL,
LastName varchar(50)
NOT NULL,
Password varchar(50)
NOT NULL,
PRIMARY KEY (Email));

CREATE TABLE RegularUser(

Email varchar(50) NOT
NULL,
Sex char(1) NULL,
Birthdate datetime NULL,
CurrentCity varchar(50)
NULL,

CREATE TABLE AdminUser(

Email varchar(50) NOT
NULL,
LastLogin datetime
NULL,
PRIMARY KEY (Email),
FOREIGN KEY (Email)
REFERENCES `User`
(Email));

CREATE TABLE UserInterests(

Email varchar(50) NOT
NULL,
Interest varchar(50) NOT
39
NULL,

SQL:

Create Tables

CREATE TABLE SchoolType(

TypeName varchar(50) NOT NULL,
PRIMARY KEY (TypeName));

CREATE TABLE Employer(

EmployerName varchar(50) NOT NULL,
PRIMARY KEY (EmployerName));
CREATE TABLE School(
SchoolName varchar(50) NOT NULL,
Type varchar(50) NULL,
PRIMARY KEY (SchoolName),
FOREIGN KEY (Type)
REFERENCES SchoolType (TypeName));

40

SQL:

CREATE TABLE Attend(

Email varchar(50) NOT NULL,
SchoolName varchar(50) NOT NULL,
YearGraduated int NULL,
PRIMARY KEY (Email, SchoolName,
YearGraduated),
FOREIGN KEY (Email) REFERENCES
RegularUser (Email));

CREATE TABLE Employment(

Email varchar(50) NOT NULL,
EmployerName varchar(50) NOT NULL,
JobTitle varchar(50) NOT NULL,
PRIMARY KEY (Email, EmployerName),
FOREIGN KEY (EmployerName)
REFERENCES Employer
(EmployerName),
FOREIGN KEY (Email)
REFERENCES RegularUser
(Email));

Create Tables

41

SQL:

Create Tables

CREATE TABLE Friendship(

Email varchar(50) NOT NULL,
FriendEmail varchar(50) NOT NULL,
Relationship varchar(50) NOT NULL,
DateConnected datetime NULL,
PRIMARY KEY (Email, FriendEmail),
FOREIGN KEY (Email)
REFERENCES RegularUser (Email),
FOREIGN KEY (FriendEmail)
REFERENCES RegularUser (Email));
42

SQL Query Statements

Le
ar

SQ
L!

43

Design
Relational Schema
SQL statements

44

SQL:

view profilepart1

//assume $Email of current user

is managed by application

SELECT FirstName, LastName,

Birthdate, Sex, CurrentCity,
Hometown
FROM User INNER JOIN
RegularUser ON User.Email =
RegularUser.Email
WHERE Email=$Email;

SELECT Interest
FROM Interests
WHERE Email=$Email;

View
profil
e
Perso
nal

Educ
ation

Profe
ssion
al

45

SQL :

view profilepart2

SELECT School.SchoolName,
School.Type,
Attend.YearGraduated
FROM Attend INNER JOIN School
ON
Attend.SchoolName=School.Scho
olName
WHERE Email=$Email
ORDER BY Attend.YearGraduated
DESC;

SELECT EmployerName, JobTitle

FROM Employment
WHERE Email=$Email;

View
profil
e
Perso
nal

Educ
ation

Profe
ssion
al

46

SQL :

edit profilepart1

Edit
Profile

View
profile

Update
personal

//populate dropdowns
SELECT SchoolName, Type FROM School;
SELECT EmployerName FROM Employer;

//assume $Email of current user is managed by

application
//read $Sex, $Birthdate, $CurrentCity,
$Hometown
UPDATE RegularUser
SET Sex=$Sex, Birthdate=$Birthdate,
CurrentCity=$CurrentCity,
Hometown=$Hometown
WHERE Email=$Email;

for each $Interest

INSERT Add/Delet
INTO Interest (Email, Interest) VALUES
Add/Delet
e
e school($Email, $Interest);
47
employer
end for

SQL :

edit profilepart2

//if user clicks Delete this School

DELETE FROM Attend
WHERE Email=$Email AND SchoolName=$SchoolName
AND YearGraduated=$YearGraduated
Edit

Profile
//add new schools
for each $SchoolName, $YearGraduated
INSERT INTO Attend (Email, SchoolName,
View
Update
Add/Delet
YearGraduated)
profile
personal
e school
VALUES ($Email, $SchoolName, $YearGraduated)
end for

//update existing schools

//assume application manages $OldSchoolName,
$OldYearGraduated
for each $SchoolName, $YearGraduated
UPDATE Attend
SET SchoolName=$SchoolName,
YearGraduated=$YearGraduated
WHERE Email=$Email AND

Add/Delet
e
employer

48

SQL :

edit profilepart3

//if user clicks Delete this Job

DELETE FROM Employment WHERE Email=$Email
AND EmployerName=$EmployerName AND
JobTitle=$JobTitle

//add new jobs

for each $EmployerName, $JobTitle
INSERT INTO Employment (Email, EmployerName,
View
Update
JobTitle)
profile
personal
VALUES ($Email, $EmployerName, $JobTitle)
end for

//update existing jobs

//assume application manages $OldEmployerName,
$OldJobTitle
for each $EmployerName, $JobTitle
UPDATE Employment
SET EmployerName=$EmployerName,
JobTitle=$JobTitle

Edit
Profile

Add/Delet
e school

Add/Delet
e
employer

49

SQL:

- Request Friend

//application provides $FriendEmail (based on user

click)
//read $Relationship from user
INSERT INTO Friendship
(Email, FriendEmail, DateConnected, Relationship)
VALUES ($Email, $FriendEmail, NULL, $Relationship)

View,
Cancel,
Accept,
Reject,
Request

View
reques
ts

Accept,
Reject,
Cancel

Reques
t
Friend

50

SQL:

- View Requests

View,
Cancel,
Accept,
Reject,
Request
View
//application provides $Email of current user
reques
//show pending requests to you
ts
SELECT R.Email, FirstName, LastName, Hometown,
Relationship
FROM Friendship AS F INNER JOIN RegularUser AS R ON
F.Email = R.Email INNER JOIN User AS U ON U.Email =
R.Email
WHERE F.FriendEmail=$Email AND DateConencted IS NULL

//show pending requests from you

SELECT R.Email, FirstName, LastName, Hometown,
Relationship
FROM Friendship AS F INNER JOIN RegularUser AS R

Accept,
Reject,
Cancel

51

SQL:

- Accept, Reject, Cancel Friend Requests

//if user clicks reject

//$FriendEmail is email of requestor
//$Email is email of current user
DELETE FROM Friendship
WHERE Email=$FriendEmail AND FriendEmail=$Email;

//if user clicks accept

View
//application provides $Now
reques
ts
UPDATE Friendship
SET DateConnected=$Now
WHERE Email=$FriendEmail AND FriendEmail=$Email;

View,
Cancel,
Accept,
Reject,
Request

Accept,
Reject,
Cancel

Reques
t
Friend

//if user clicks cancel

DELETE FROM Friendship
WHERE Email=$Email and FriendEmail=$FriendEmail;
52

Implementation
Implement the database using a relational
engine, e.g. MySQL, SQLServer, Oracle,
Implement the interface from the SQL
statements using a programming
language, e.g. PHP, Java, Python,
Convenient packaging of free, open source
software available to build a Webserver
Apache HTTP Server, MySQL, PHP (AMP):
WAMP (Windows)
MAMP (Mac)
SAMP (Solaris)
53

AMP solution stack

Client
Brows
er

Serve
r
HTML
Server

PHP
Server

DB
Server

Static
HTML
Dynam
ic
HTML

DB

54