1. ABC’s of Database Design
Instructor: Vicki Weidler
Assistant: Joaquin Obieta

2. Overview Basics Designing Good Databases Common Mistakes to Avoid
Additional Resources

3. Part 1: Basics What is a database? When do you use a database?
Types of databases
Database structure
Data types
What is a database?
Collection of data
Organized some way
More useful
Examples: Phone Book
Card Catalog
LIAS CAT System
Used to solve problems
Filing system
Subsets of data
Reports-Annual, Quarterly, etc.
When do you use a database?
Large collection of data
Organized in many different ways
To be useful
Easier to work with large datasets
Breaking it up into smaller subsets
Based on multiple criteria
Example: Penn State students from Pgh
3 Types of Databases
Flat Files
Text with data/values separated by commas
Spreadsheet/Excel
Relational
Stores info in tables
Tables joined in different ways
Efficiently access info
Tables consist of rows & columns
Table has a specific name
Columns have specific names
Rows each have unique identifier
Called primary key
Primary keys used to link info together
By creating tables for for each subset of info
Increases efficiency
Reduces redundancy/duplication
Improved performance
Object-Oriented
DBMS (database mgmt systems)
Advantage of Java & C++
Components of system
Created once, then reused, exxtended or modified

4. Part 2: Designing Good Databases
Database planning
Administration and maintenance
Security
Working with constraints
Example: The key database
Planning
Info needed?
Who will use?
Info used for?
Often info needed?
1 person access/edit info?
Multipe access/alter same time?
How accessed? Web?
Timelines for completion?
Available resources?
Administration & Maintenance
What server will run database app?
What OS will run on?
What software available to dev?
Different clients accessing it?
Responsibility for updating info?
Responsible for chging database structure?
Security
Responsible for security w/multiple users?
Authentication needed for web access?
Use CAC access accts/passwords to access?
Working With Constraints
To decide which technologies to use
& how to develop
Must consider resources
Personnel
Infrastructure
Existing database apps
Cost to dev
Time to dev
Unfortunately
Databases developed w/o adequate planning
Result in loss of time
Need altered or re-created
Design of database
Dictates what can be done w/it
Example: Key Database
Problem:
Dept has large # of staff, faculty & students
Large # keys
Rooms, Cabinets, Special Equipment
Overall System Evaluation
Purpose/Scope of database?
Users?
Maintenance?
Report/Query Evaluation
What info will be pulled/queried?
Kinds of reports needed?

5. Part 3: Common Mistakes to Avoid
Database Requirements
Important to be useful in long-term
Do’s & Don’ts
Don’t assume every problem solved w/database
Don’t assume anything
Don’t leave it too long between reviews
Don’t spend too long on prototype
Don’t start developing until fully understand what users want
Don’t start developing until clear where all responsibilities lie
Don’t expect app to be finalized when it is finished
Don’t aim for 100% functionality
80-20 rule (80% functionality in 20% of time)
Do involve users in shaping design
Do find out if anyone else has already solved problem
Do plan on an iterative development process
Do get users feedback
Do find ways to encourage idea generation
Database Standards
Standards agreed upon for the project and documented for future reference
File-Naming Standards
Clearly identifies particular file & purpose
If OS allows long filenames, take advantage
Field Standards
Fields should have unique, meaningful names
Example: Instead of ID, use TableNameID
for primary key
Use consistent naming conventions for fields
Form Standards
All forms unique, meaningful names
Consistent naming convention
Colors & fonts standardized on all forms
Images/company logos all uniform
If copyright or ADA accessibility info required, consistent on all forms
View Standards
All views unique, meaningful names
Follow file naming structure
Colors, fonts & general order of info should be standardized
Function Code
Use standard code for reusable features
Such as Save & Exit or Quit options
Functions & formulas written to be re-used
Other Documentation-Include
Identify audience
Specific procedures/directions
Who is responsible for design/updating info…
Who is tech support
Identify technology used to develop database
Include software version # & date of development
Database requirements
Database standards
Database development life-cycle

6. Database Development Life-Cycle
Developing w/o testing
Asking for problems
First Phase: Database Design
Take time to answer all ? Discussed at beginning of seminar
Get as much info as possible
Outline standards for the project
Second Phase: Database Prototype
Develop quick & dirty prototype
Used only to determine functionality of database
May learn that another software pkg or approach to design
Prototype should be carefully evaluationed
Functionality approved
Before add’l time spent on development
Third Phase: Database Development
Set final specs
Create final database app
Check to insure meets
Design standards
Functions correctly
Performs on all required platforms/clients
Help documents consistent & clear
Testing done internally first
Fourth Phase: Database Testing
Pilot in real production environment
Limited audience of people/testers
Database
Design
Get feedback
Try to set up separate server for testing purposes
Monitor server closely for performance problems
Once tested successfully, move to production server
All documentation should be written/edited
Final Phase: Production
Reviewed, evaluated, tested
Meets all standards & needs of user
Further refinement always possible
Add’l features added in future
Directions readily available to users
Database
Production
Database
Prototype
Database
Testing
Database
Development

7. Summary Basics Designing Good Databases Common Mistakes to Avoid
Additional Resources

8. Conclusion
Questions & Answers
Evaluations
Thank You!!!
Evaluations