Information Technology Services 

Getting Started
with Designing a
Relational Database 
ITS@PennState 
23 Willard Building 
University Park, PA 16802 
itstraining@psu.edu 
http://its.psu.edu/training 

version 091906
 Alternative Format Statement 
This publication is available in alternative media upon request. 

Statement of Non­Discrimination 
The Pennsylvania State University is committed to the policy that all persons shall have 
equal access to programs, facilities, admission, and employment without regard to 
personal characteristics not related to ability, performance, or qualifications as 
determined by University policy or by state or federal authorities. It is the policy of the 
University to maintain an academic and work environment free of discrimination, 
including harassment. The Pennsylvania State University prohibits discrimination and 
harassment against any person because of age, ancestry, color, disability or handicap, 
national origin, race, religious creed, sex, sexual orientation, or veteran status. 
Discrimination or harassment against faculty, staff, or students will not be tolerated at 
The Pennsylvania State University. Direct all inquiries regarding the nondiscrimination 
policy to the Affirmative Action Director, The Pennsylvania State University, 328 
Boucke Building, University Park, PA 16802­5901; Tel 814­865­4700/V, 814­863­ 
1150/TTY.
 Table of Contents 
Objectives ........................................................................................................2 

Database Definition and Terminology ..............................................................3 

Relational Database Definition.........................................................................4 

Database Management Systems .....................................................................5 

Steps for Database Design ..............................................................................5 

1) Formulate a Solution.........................................................................5 

2) Gather Information ............................................................................6 

3) Develop Fields ..................................................................................6 

4) Organize Tables................................................................................7 

5) Define Table Relationships .............................................................10 

6) Test and Improve ............................................................................12 

7) Develop Queries, Forms, and Reports............................................12 

Signs of Good Database Design....................................................................13 

Multi­User Considerations..............................................................................13 

Additional Resources .....................................................................................14
 Objectives
· Define basic database terminology

· Describe a database management system (DBMS)

· Consider possible database use

· Understand the basics of database normalization

· Recognize the types of table relationships

· Practice the steps involved in relational database design

Designing a Relational Database  2 
 Getting Started with Designing 
a Relational Database 
What is a Database? 
A database is a collection of data that is stored for a specific purpose.  This 
collection is arranged in a fixed structure. 
Everyday Examples of Simple (Non­Electronic) Databases
· Address book
· Telephone book
· Encyclopedia 

Basic Database Terminology
· Table: contains data about a specific topic or subject; holds records 
Ex. students, courses, supplies

· Record: contains data about one specific entity within a table; holds fields 
Ex. one student, one course, one supply resource

· Field: contains data about a specific object or thing described in a record 
Ex. id of student, number of course, cost of supply resource

· Data Value: specific instance of data kept in a field 
Ex. 5 4327 2910, ENG101, $6.25 

Overview of Database Structure 
Database 
Tables 
Records 
Fields 
Data Values

Designing a Relational Database  3 
Comparing a Database to a File Cabinet 
A Database is like a file cabinet because it holds the data in an 
organized way. 

Tables are like the drawers of the cabinet because they hold related 
pieces of data or lists of records. 

Records are like the file folders because they hold sets of related data. 

Fields are like the sheets of paper in the file folders because they 
contain specific pieces of categorized data that make up the related sets. 

Data values are like the words on the paper because they are the 
specific pieces of data.

What is a Relational Database? 
A relational database contains tables that are related.  Related tables contain 
fields that match. 
Example: A Course Enrollment table is related to a Student table because 
they both contain a field for Student ID. 

Why use a Relational Database? 
The purpose of a database is to organize data so it can be easily selected, sorted, 
managed, and updated. By using a relational database, each piece of information 
only needs to be stored once. 

The benefit is that if a piece of data is updated it needs to be updated in only one 
place and the update will then be recognized throughout the database. 
Otherwise, several updates would need to be made in several different places, 
which can be cumbersome and lead to a messy situation if not done accurately. 

Example: An update for a student’s address is made in the Student table and 
is now recognized by all related tables. 

Designing a Relational Database  4 
Database Management Systems (DBMS) 
A Database Management System is an extra layer of software, or a collection of 
programs, that enables a user to store, modify, and extract data kept in a 
database.  A DBMS allows users to have different access rights in entering, 
manipulating, and retrieving data from different views.  It allows for multiple user 
access and concurrent usage.  Record locking can be incorporated using a 
DBMS to ensure data integrity when multiple users are entering data.  A DBMS 
can also be used to apply customization and simple security features.  The DBMS 
provides a useful user interface. 

There are many different types of DBMS applications, ranging from small systems 
that run on personal computers to large systems that run on mainframe 
computers.  One DBMS can differ widely from another, based on the way it 
organizes information internally. 

Examples of Database Management Systems 
Small  Large
·  Microsoft Access ·  SQL Server
·  FileMaker Pro ·  Oracle
·  Lotus Approach ·  DB2

The Database Design Process 

1) Formulate an idea for a solution 
§ Identify an existing problem that could be improved with a database. 
§ Have a clear purpose in mind. 
Identify the problem: The Imaginary Department of the Fictional College 
currently has a spreadsheet to store student data.  Every school year a new 
spreadsheet is created. Data has to be copied and pasted for existing students 
that are still enrolled in the new year.  Various reports have to be created each 
semester as well as any time data is requested for analysis. Additional 
spreadsheets exist for course enrollment, faculty teaching schedules, and room 
assignments. 
Describe existing difficulties: _______________________________________ 
_________________________________________________________________ 
_________________________________________________________________ 
_________________________________________________________________ 

Designing a Relational Database  5 
Propose a solution: Describe what can be done to make this data easier to 
utilize. Should anything else be a focus here? 
_________________________________________________________________ 
_________________________________________________________________ 
_________________________________________________________________ 

2) Gather information and clarify needs. 
§ Talk to people currently involved with the data and anyone else who may 
have the potential to be a user of the application. 
*WHY: Users will know what they need/want to be able to do.  Knowing requirements 
ahead of time will help ensure that the database design meets the needs of users. 
§ Ask questions such as: 
ü  What information is available?  Is it adequate to meet needs? 
ü  How is the available information being used? 
ü  Who maintains current data? 
§ Sketch out formatting of possible forms and/or reports (mailing labels, 
rosters, course offerings list, etc.) to make sure they are useful to users 

List some people to speak to and possible points to clarify: ______________ 
_________________________________________________________________ 
_________________________________________________________________ 
_________________________________________________________________ 

3) Develop a list of all useful fields. 
§ List all of the possible attributes that will be available within the database 
§ Break down information into the smallest meaningful units possible 
(Ex. use First Name and Last Name fields instead just one Name field) 
§ Eliminate redundancy (Ex. don’t need both age and birth date) 
*REMINDER: Redundancy may be necessary in certain (yet infrequent) cases.  For 
instance, if a course title changes it does not mean that all records with the previous title 
and the same course number need to be changed to eliminate redundancy. 
§ Determine if all proposed fields will be needed (used to calculate, show up 
on a report later), but also be as thorough as possible in field creation 
*NOTE: It is easier to create a field now and remove it if it is unused later than it is to 
create an additional field in an already existing and utilized table.

Designing a Relational Database  6 
List fields: Create a list of possible fields needed in the database.  No grouping 
is necessary at this point. 

_________________________________________________________________ 
_________________________________________________________________ 
_________________________________________________________________ 
_________________________________________________________________ 
_________________________________________________________________ 
_________________________________________________________________ 
_________________________________________________________________ 
_________________________________________________________________ 
_________________________________________________________________ 
_________________________________________________________________ 
_________________________________________________________________ 
_________________________________________________________________ 

4) Organize the fields into logical tables. 
§ Divide fields into categories or subjects. Each of these categories will 
represent a table. 
*NOTE: Be sure that each table has only one focus.  If fields do not directly belong with 
that focus, consider moving them to a different table. (Ex. The Courses table is not 
necessarily the best place to keep detailed faculty information.) 
§ Assign key fields.  A key field or primary key is a unique identifier for a 
record/entity (Ex. ID numbers, Course codes).  These identifiers help to 
associate tables. They are not necessary, but highly recommended. 
*HINT: A primary key can also be made of multiple fields if needed. 

Example of a table with primary key field:  Students Table 
StudentID 
In this case, StudentID is the primary key  FirstName 
field. This means that each student record  LastName 
in the database has a unique identifier that  Address 
both sets it apart and may help it to relate to  City 
records in other tables. State 
PhoneNumber 

Designing a Relational Database  7 
 § Consider normalization rules. 
Normalization Rules: There are 5+ normalization rules (5 Normal 
Forms and Boyce­Codd), but most day­to­day database creation 
focuses on the first three.  These rules are used to help create 
flexible, adaptable tables that have no redundancy and are easy to 
query.  In other words, they ensure that there is “a place for 
everything and everything in its place.” 

1) First Normal Form: 
­Each field contains the smallest meaningful data value possible (no 
fields with multiple values listed). 
Ex. First Name and Last Name as separate fields 
­There are NO repeating groups of fields. 
Ex. One field called Month instead of 12 fields called Jan, Feb, etc. 

2) Second Normal Form 
­Each non­key field in the table must relate to the entire Primary Key 
value. 
Ex. In this table, StudentID & CourseID make up the Compound 
Primary Key 

This table does not satisfy the Second Normal Form 
because not all fields are related directly to entire the primary key. 

StudentID  CourseID  FirstName  Grade 

12345  310.001  Mary  A 

12345  360.007  Mary  B 

The table now satisfies the Second Normal Form 
because all fields relate directly to entire the primary key. 

StudentID  CourseID  Grade 

12345  310.001  A 
12345  360.007  B

Designing a Relational Database  8 
 3) Third Normal Form 
­Each non­key field in the table must relate directly to the single­field 
Primary Key value. 

Ex. In this table, Course ID is the single­field Primary Key 

This table does not satisfy the Third Normal Form 
because not all fields are related directly to the primary key. 

CourseID  Section  FacultyID  FacultyOffice 

310.001  1  001  356 Smith 
110.003  1  001  356 Smith 

The table now satisfies the Third Normal Form because all 
fields relate directly to the primary key. 

CourseID  Section  FacultyID 

310.001  1  001 
110.003  1  001

Organize fields into tables: Create table names and list fields for each table. 

Designing a Relational Database  9 
 *Reminder: Before moving to step 5, it is a good idea to check back on the information 
previously gathered to ensure that all requirements are included in the tables. 

5) Determine and define table relationships. 
§ Identify fields that match among tables 
§ Decide how data is related based on these matching fields (Ex. Student 
table is a primary table with related records in Course Enrollment table, 
which is called the related table) 
§ Define relationships between the primary key of one table and the related 
or foreign key of another.  These matching fields can have the exact 
same name or slightly different names, yet hold the same data. 

Students Table  Course Enrollment 
primary key field  StudentID  Table 
FirstName  CourseID 
LastName  Student ID  foreign key field
Address  Grade 
City  Semester 
State  Year 
PhoneNumber 

§ Add new fields and/or tables as needed to clarify relationships. 
§ Consider how relationships may be used to make queries and reports 
more efficient. 
§ Focus on the three types of table relationships. 
Three Types of Table Relationships: There are three types of table 
relationships.  Each has its own unique purpose in helping to organize 
the data within the database.  These relationships can be used to 
determine joins in queries as well. 

1) One­to­One Relationships: one record in table is related to one 
record in a related table; creates equally dependent tables 
Ex. one student has only one PSU ID 

*NOTE: This type of relationship is rarely used. 

Designing a Relational Database  10 
 2) One­to­Many Relationships: one record in a primary table is 
related to many records in a related table; however, a record in the 
related table has only one related record in the primary table 
Ex. a student can live in one residence hall at a given time, but 
many students can live in a residence hall at a given time 

*NOTE: This is the most common type of relationship. 

3) Many­to­Many Relationships: several records in the primary table 
are related to several records in a related table 
Ex. one student can be enrolled in many courses and each course 
can have many students enrolled 

Define relationships among tables: Draw lines to connect primary and foreign 
key fields on related tables.  This diagramming is referred to as Entity 
Relationship diagramming because it connects entities based on similarities.

Designing a Relational Database  11 
6) Test, refine and improve. 
§ Analyze the overall database design to check for errors as well as to see 
that needs are being met. 
§ Review table structure to make sure all needed fields are present and 
existing relationships are valid and useful. 
§ Test table design by adding records and observing functionality. 

List points to consider when testing, refining, and improve design: Describe 
possible issues and resolutions. 
_________________________________________________________________ 
_________________________________________________________________ 
_________________________________________________________________ 
_________________________________________________________________ 
_________________________________________________________________ 
_________________________________________________________________ 

7) Develop queries, forms, and reports. 
§ Look back at information gathered to get ideas for what type of queries, 
forms, and reports are needed. 
§ Consider table relationships and how they can be utilized. 
§ Try drafts of queries, forms, and reports to see if they show the expected 
data results. 
§ Modify as needed to meet needs. 
§ Consider this development process as on going throughout the use of the 
database. 

Describe possible queries, forms, and reports that may be needed: 
_________________________________________________________________ 
_________________________________________________________________ 
_________________________________________________________________ 
_________________________________________________________________ 
_________________________________________________________________ 
_________________________________________________________________

Designing a Relational Database  12 
Signs of Good Database Design 
­thoughtfully planned 
­works for the intended situation and purpose 
­streamlines a process 
­shows consistency among data (Fall 05 vs. fall 2005) 
­eliminates redundancy as much as possible (i.e. tables are normalized) 
­provides users with an easy way to enter, store, and retrieve data 
­does NOT promote deleting data, but rather making designations or archiving it 
­provides unique identifiers (primary keys) for records 
­grows, changes, and improves as needed 

Considerations for Implementation in a Multi­User Environment 
­Who will administer the database?  An individual?  A group or committee? 
­Are shared folders being used? 
­Is server space needed?  If so, is it available and where? 
­Are web capabilities required (intranet and/or internet)?  If so, is web space 
available? 
­Is security an issue?  If so, how will that be handled? 
*Caution: Various DBMSs have a variety of features concerning these issues and all of 
them may operate differently depending on the environment.

Designing a Relational Database  13 
Additional Resources 
Training
· https://register4its.psu.edu 

Reference Books
· Relational Database Design Clearly Explained, Second Edition by Jan L. Harrington
· Database Design Using Entity­Relationship Diagrams by Sikha Bagui and Richard 
Earp
· Handbook of Relational Database Design by Candace C. Fleming and Barbara von 
Halle
· Database Design for Mere Mortals: A Hands­On Guide to Relational Database 
Design by Michael J. Hernandez
· Information Modeling and Relational Databases: From Conceptual Analysis to 
Logical Design by Terry Halpin, T. A. Halpin 

Websites
· http://proquest.safaribooksonline.com
· http://db.ittoolbox.com/
· http://databases.about.com/
· http://www.geekgirls.com/menu_databases.htm
· http://www.informit.com/articles 

Phone Numbers
· Help Desks 
o  2 Willard Bldg: (814) 863­1035 
o  215 Computer Bldg: (814) 863­2494

· ITS Training Services: (814) 863­9522

Designing a Relational Database  14