Download PowerPoint Presentation handout

Practical Database Design
Today’s discussion
Practical Database Design
In a research environment
•
What is a database?
•
Which application should I use?
•
Steps in designing a relational database
•
Database terminology and concepts
•
Live Demo
Kim Laursen, ITS Education Coordinator, 9-5674
Tom Reardon, ITS Senior Programmer/Analyst, 9-5671
•
Common design problems
•
Redesigning the database
So, what exactly is a database?
Manual/
Non-computerized
Flat/
hierarchal
• Rolodex
• Filing cabinet
• Telephone book
• Word labels
• Excel Worksheet
• Tree-like structure
• Access database
• SQL database
Relational
•
•
•
Research data
Patient information
Student information
Top Down Approach
•
Data model that is
Reasons for creating a
computerized database
•
Rapid access to information
•
Eliminate or minimize duplication information
•
Simplify data entry and reporting
•
Accommodate expansion
•
Maintain integrity of data
•
Prevent access to unauthorized persons
•
Provide statistics for analysis
•
Provide summary data for papers, presentations
Bottom Up Approach
Systems
Planning
•
well organized
•
Details can be
easily overlooked
Helps insure no
Database
Designed
data overlooked
Information
Model
•
Overall
organization may
Relationships
Determined
not be so apparent
Proposed
Database
UNMC ITS Helpdesk 559-7700
Data Entities
Identified
12/1/2010
Practical Database Design
What is the purpose of your database?
Combined Approach
Cross check for
both
completeness
and good
organization
Systems
Planning
Database
Designed
•
•
Write out statement of purpose
How do you collect data?
•
•
•
Information
Model
Relationships
Determined
•
Data Entities
Identified
•
•
•
•
•
Who enters it into the database, what is their
experience level (with data and computers)
What’s the expected lifetime of the
project?
j t?
Can the same form be used for multiple
projects – either now or in the future
What kinds of analysis are you going to
do?
•
Proposed
Database
Who collects it
Who will analyze the data
Who will want reports
Brainstorm questions about database
Sketch out workflow - reports
Gather current forms and reports
Which application should I use?
Spreadsheet Strengths
1. Ease of data entry
2. Calculations and statistical functions available
3. Charting capabilities
4. Pivot table reports
Spreadsheet Weaknesses
1. Hard to customize data entry for complicated
situations
2. Not good at managing large amounts of data
with complex relationships (patient records with
multiple visits)
3. Hard to sort or select for specific subsets of data
4. Complex statistics are usually beyond its reach
Which application should I use?
Good Excel Example
Excel
1. Single table of data, fairly small amount
2. Numbers and financial data
Avoid wrapped
text in headings
3. Sophisticated what if models and cost benefit
analyses
4. Charting and data bars
5. Pivot tables
6. Familiarity/preference
UNMC ITS Helpdesk 559-7700
12/1/2010
Practical Database Design
Which application should I use?
Poor Example
Relational Database Management System Strengths
1.
2.
Manage and track large amounts of data
Powerful structure to develop queries to find specific
information
3.
Relatively easy to create data entry forms and reports in
complex situations
4.
Fairly easy to make relatively good, if not publication quality
charts
5.
Allows multiple user access at the same time
6.
Relatively easy to import/export data from/to other
applications
13
Which application should I use?
Which application should I use?
Relational Database Management System Weaknesses
Access Database
1.
Limited statistical capability largely restricted to basic
descriptive measures
2.
Charting and graphing capability is often limited
3.
Learning curve
Access 2007
UNMC ITS Helpdesk 559-7700
1.
Store and manage lots of data, especially repeated data
2.
Keep track of actions or events?
3
3.
More than one table related to each other
4.
Want to create data entry forms
5.
More complex filters/queries
6.
Generate variety of reports
7.
Multiple users entering data at the same time
Making a relational database
work
•
Tables
•
Forms
•
Queries
•
Reports
•
Macros
•
Modules
12/1/2010
Practical Database Design
Rooms “Tables” where you
store your data
Furniture & Possessions
“Fields”
What you keep in the
rooms – “records”
Entrances, doors “Forms & Reports”
- Ways of getting data into and out
of the house
Common Design Problems
Windows
Queries
“Queries”
- Ways of
looking at
what is in the
house, from
different
perspectives
Structural Design Flaws
Additions, Deletions, and Updates
behave unpredictably
Inability to retrieve information
efficiently
Redundant information
Inconsistent information
Loss of information (zip codes)
Preventable Data Entry Errors
These are data entry errors that the system
could either prevent, or provide a warning,
if th
the right
data
i ht d
t validation
lid ti rules
l are iin place.
l
1. Data out of range
2. Using the wrong type of variable, entering
mixed character and numeric data – ie 98.6F
3. Loss of information due to rounding errors
Doesn’t export easily
Operator Errors
These are data entry errors that could not be
caught by the system. Some examples
would be:
1. Inconsistent spellings or terms for the same
thing
How to avoid errors
Three-pronged approach at table
design and forms design level
1 Formal model constrains what
1.
can be done and insures data
integrity
2. Reversed letters and/or numbers
2. Data validation rules
3. Wrong codes
3. Basic design principles,
4. Inaccurate entry within a variable’s acceptable
psychology
range
UNMC ITS Helpdesk 559-7700
12/1/2010
Practical Database Design
Tables
Steps in Designing a Database
•
Look at individual
 Purpose of your database
facts about the
table
 Table(s) you’ll need
 Fields in each table
•
Base table or
•
Don’t duplicate
lookup table
 Relationships
 Refine your design
information
 Add data and create other database
•
Don’t eliminate or
delete valuable
objects
information
Identify Facts about your Database
TestID#
Fields
Rats
Lab Tests
RatID#
Date
RatID#
Weight
M/F
DOB
Rat
Database
TestIDCode
Related to the subject of the table
Don’t include derived or calculated data
Include
I l d allll the
h information
i f
i that
h you need
d
Store information in its smallest logical
parts
Avoid spaces in field names
Primary key fields
•
•
Description
Application
•
•
•
•
Lab Test
lookup
Foreign field
•
Primary Key
Field
•
Primary key in one table, used to relate
(join) records in another table.
•
Has the same type and properties of the primary
field (doesn’t
(doesn t have to have the same name)
Uniquely defines a row in a table
•
•
•
Minimal size
Stable – should not change
Simple and familiar
UNMC ITS Helpdesk 559-7700
12/1/2010
Practical Database Design
Other Keys
Determine Relationships
One-to-one relationship – inner join
Compound key
Composed of two or more columns, such as
DateDone and TestName (if a specific test is
done only once per day)
Surrogate key
Doesn’t come from the data, such as autonumber
31
One-to-many relationship – outer join
•
•
This is where a row in one table (the parent table) has one or more matching rows in a second (child) table. d ( hild) bl
This is probably the most common relationship, Many-to-many relationship
Row in table 1 has many matching rows in
table 2, and a row in table 2 has many
matching rows in table 1.
Requires a third intermediate table
Sample Relationship Screen
Enter sample
data
Many empty
fields?
fi ld ?
Duplicate
information in
your tables?
UNMC ITS Helpdesk 559-7700
Refine
your
design
Forget any
fields?
fi ld ?
Good primary
key for each
table?
12/1/2010
Practical Database Design
More on Relationships and Referential
Integrity
Add data and other database objects
Small number of
records initially
Continue to
refine
Create forms,
queries, reports
Test to see if
you’re getting the
desired results
Did you inherit someone else’s
database?
Other considerations
•
Updating and
modifying data
•
I d
Indexes
needed?
d d?
•
Security
•
Backup and
Tools > Analyze >
Documenter
recovery
•
Documentation
Sample Database Scenarios
Database terms
Hierarchical database
Relational database
Database objects
1.
2.
3.
4.
5.
6.
Tables - tblName
Fields
Queries - qryName
Forms - frmName
Reports – rptName
Properties
UNMC ITS Helpdesk 559-7700
Relationships
•
Birthday cards
1. Primary keys
•
Home music library
2.
2 Foreign
F i kkeys
•
Home inventory
•
Employee equipment inventory
•
Research data on rat experiments
Referential integrity
Validity
kl1
Normalizing
12/1/2010
Slide 42
kl1
These are probably not appropriate for a research audience. Depending on time, we may not have time
for this. I think more effective to show good and bad examples.
klaursen, 10/19/2010
Practical Database Design
Where to Get More Information
•
Detailed handout and recording of today’s session
at RUG web page – www.unmc.edu/its/292.htm
Training sessions- ITS Web page
•
•
•
•
•
Building a
Database
•
Tom Reardon
43
UNMC ITS Helpdesk 559-7700
•
•
•
http://office.microsoft.com
DVD tutorials – 6th floor circulation desk of the Library
Books, articles, electronic sources
•
Live Demo
www.unmc.edu/its - classes and training link
On-line resources
The Missing Manual for Access 2007– Matthew
McDonald
ITS Customer Support – 559-7700
Academic programming–Tom Reardon – 9-5671
College courses
12/1/2010