1. DATABASE DESIGN

2.  Database design is the process of producing a
detailed data model of a database.

3.  This logical data model contains all the needed
logical and physical design choices and physical
storage parameters needed to generate a design in
a Data Definition Language, which can then be
used to create a database.

4.  A fully attributed data model contains detailed
attributes for each entity.

5. Usually, the designer must:
 Determine the relationships between the different data
elements.
 Superimpose a logical structure upon the data on the
basis of these relationships.

6. THE DESIGN PROCESS
 Determine the purpose of the
database - This helps prepare for the
remaining steps.

7.  Find and organize the information required -
Gather all of the types of information to record in
the database, such as product name and order
number.

8.  Divide the information into tables - Divide information
items into major entities or subjects, such as Products or
Orders. Each subject then becomes a table.

9.  Turn information items into columns -
Decide what information needs to stored
in each table. Each item becomes a field,
and is displayed as a column in the table.
For example, an Employees table might
include fields such as Last Name and
Hire Date.

10.  Specify primary keys - Choose each
table’s primary key. The primary key is a
column that is used to uniquely identify
each row.

11.  Setup the table relationships - Look at
each table and decide how the data in
one table is related to the data in other
tables. Add fields to tables or create new
tables to clarify the relationships, as
necessary.

12.  Refine the design - Analyze the design for errors.
Create tables and add a few records of sample
data. Check if results come from the tables as
expected. Make adjustments to the design, as
needed.

13.  Apply the normalization rules - Apply
the data normalization rules to see if
tables are structured correctly. Make
adjustments to the tables

14. THE TABLES

15.  The core table of the database is Incident. This
tracks the bulk of information submitting about a
particular incident. For example, under injuries
there might be multiple parts of the body that were
injured. There are several ways to deal with this.

16. Solution Pros Cons
Add one field for Keeps all the data in one Makes the table extremely large. Adding
each item table. a new piece of information to be stored
means adding an entirely new field. If
there are multiple copies of the database
in use synchronization becomes
extremely difficult. Many database fields
will be empty. Poor database design
practice. Less efficient database
storage.
Allow multiple Keeps all the data in one Extremely poor database design
pieces of data to be table. practice. Makes querying the database
entered in each for incidents that meet certain criteria
field. extremely difficult and time consuming.
Create Child Tables Best practice for database Spreads data out over multiple tables
design. Allows for easily which means that greater database
adding new types of expertise is needed to develop and work
information. Does not with the data.
create a "bulky" core table.
More efficient for querying
the database for incidents
that meet certain criteria.

17.  The recommendation is to create an idb_Incidents
Table to handle the information that is discrete (that is
can only have one value such as the date of the
incident) and create a series of Child tables that store
information where there may be multiple pieces of
data.

18.  This makes the database much more extendable. If
new information needs to be collected, either a new
field would be added to the idb_Incidents Table or a
new Child table could be created.