Designing Databases

Data Storage Design Objectives

The objectives in the design of data storage organization are
o The data must be available when the user wants to use it
o The data must have integrity
ƒ It must be accurate and consistent
o Efficient storage of data as well as efficient updating and retrieval
o The information retrieval be purposeful
o The information obtained from the stored data must be in an
integrated form to be useful for
ƒ Managing
ƒ Planning
ƒ Controlling
ƒ Decision making

Approaches to Data Storage

There are two approaches to the storage of data in a computer system
o Store the data in individual files each unique to a particular
application
o Storage of data in a computer-based system involves building a
database
ƒ A formally defined and centrally controlled store of data
intended for use in many different applications

Files
A file can be designed and built quite rapidly, and the concerns for data
availability and security are minimized
Analysts can choose an appropriate file structure according to the
required processing speed of the particular application system

Objectives of Effective Databases

The effectiveness objectives of the database include
o Ensuring that data can be shared among users for a variety of
applications
o Maintaining data that are both accurate and consistent
o Ensuring all data required for current and future applications will be
readily available
o Allowing the database to evolve and the needs of the users to grow
o Allowing users to construct their personal view of the data without
concern for the way the data are physically stored

1
Efficiency Measures of Database Design
The efficiency measures of database design are
o Time and cost required for the design and development of the
database
o Cost for operation and maintenance
o Cost for the hardware installation
o Cost for user training

Metadata
Metadata is the information that describes data in the file or database
o Used to help users understand the form and structure of the data

Entity-Relationship Concepts
Entities are objects or events for which data is collected and stored
An entity subtype represents data about an entity that may not be found
on every record
Relationships are associations between entities

Entities
A distinct collection of data for one person, place, thing, or event
Entities become files of database tables

Customer

Associative Entity
Associative Entity - links two entities
An associative entity can only exist between two entities
Associative entities become database tables

Order
Item

Attributive Entity
Attributive Entity - describes attributes, especially repeating elements
Attributive entities tables, table files or database code tables

2
 Book
Subject

Associative Entity
The relationship line between a many-to-many relationship becomes an
associative entity, sometimes called a composite entity or gerund

Associative Entity Connections

Each entity end has a “one” connection
The associative entity has a “many” connection on each side

Order Order Item

Item

Associative Entity Keys

The key fields for the associative entity are
o The primary key for each “one” end is a foreign key on the
associative entity
o Both foreign keys concatenated together become the primary key

Relationships
Relationships may be
o One-to-one
o One-to-many
o Many-to-many
A single vertical line represents one
A circle represents zero or none
A crows foot represents many

Many One

Many None

3
Ordinality
The ordinality is the minimum number that can occur in a relationship
If the ordinality is zero, it means that it is possible to have none of the
entity

Item Order

Entity Subtype
A special one-to-one relationship
It is used to represent additional attributes, which may not be present on
every record of the first entity
This eliminates null fields on the primary database
For example, a company that has preferred customers, or student interns

Student
Internship

Attributes, Records, and Keys

Attributes are a characteristic of an entity, sometimes called a field
Records are a collection of data items that have something in common
Keys are data items in a record used to identify the record

Key Types
Key types are
o Primary key, unique for the record
o Secondary key, a key which may not be unique
o Concatenated key, a combination of two or more data items for the
key
o Foreign key, a data item in one record that is the key of another
record

Files
A file contains groups of records used to provide information for
operations, planning, management, and decision making
Files can be used for storing data for an indefinite period of time, or they
can be used to store data temporarily for a specific purpose

4
File Types
Types of files available
o Master file
o Transaction file
o Table file
o Work file
o Report file

Master and Transaction Files

Master files
o Have large records
o Contain all pertinent information about an entity
Transaction records
o Are short records
o Contain information used to update master files

File Organization
There are different organizational structures for file design
o Sequential organization
o Linked lists
o Hashed file organization
o Indexed organization
o Indexed-sequential organization
o VSAM (Virtual Storage Access Method), sequential and indexed-
sequential files

Databases
A database is intended to be shared by many users
There are three structures for storing database files:
o Hierarchical database structures
o Network database structures
o Relational database structures

Normalization
Normalization is the transformation of complex user views and data to a
set of smaller, stable, and easily maintainable data structures
Normalization creates data that are stored only once on a file
The exception is key fields
This eliminates redundant data storage
It provides ideal data storage for database systems

5
Three Steps of Data Normalization
The three steps of data normalization are
o Remove all repeating groups and identify the primary key
o Ensure that all nonkey attributes are fully dependent on the primary
key
o Remove any transitive dependencies, attributes which are
dependent on other nonkey attributes

User View

Unnormalized
Relationship
Remove repeating groups
Normalized
Relations (1NF)
Remove partial dependencies

Second Normal Form

Relations (2NF)
Remove transitive dependencies

Third Normal Form

Relations (3NF)

First Normal Form (1NF)

Remove any repeating groups
All repeating groups are moved into a new table
Foreign keys are used to link the tables
When a relation contains no repeating groups, is in the first normal form
Keys must be included to link the relations, tables

Second Normal Form (2NF)

Remove any partial dependencies
A partial dependency is when the data are only dependent on a part of a
key field

6
 A relation is created for the data that are only dependent on part of the
key and another for data that are dependent on both parts

Third Normal Form (3NF)

Remove any transitive dependencies
A transitive dependency is when a relation contains data that are not part
of the entity
The problem with transitive dependencies is updating the data
A single data item may be present on many records

Normalization Example
Applying normalization means first removing repeating groups. In this
case, CLIENT-ID, CLIENT-NAME, CONTACTS, CLASS, and STAFF-
SIZE would repeat for various EQUIP-TYPE. The resulting tables are:

CLIENT EQUIPMENT
============== ==============
CLIENT-ID CLIENT-ID
(primary key) (primary key)
CLIENT-NAME EQUIP-MODEL-YR
ADDRESS (primary key)
CONTACTS EQUIP-QTY
PHONE-NUMBER EQUIP-TYPE
CLASS
STAFF-SIZE
TRAINING-LEVEL

In addition, CONTACTS and PHONE-NUMBER would still be repeating

groups within CLIENT, yielding:

CLIENT CONTACTS EQUIP

============== ============== ==============
CLIENT-ID CONTACT-NAME CLIENT-ID
(primary key) (primary key) (primary key)
CLIENT-NAME CLIENT-ID EQUIP-MODEL-YR
ADDRESS PHONE-NUMBER (primary key)
CLASS EQUIP-QTY
STAFF-SIZE EQUIP-TYPE
TRAINING-LEVEL

The next step is to remove partial dependencies. In this case the EQUIP-
TYPE depends on EQUIP-MODEL-YR while EQUIP-QTY depends on the
entire compound key. The resulting tables are:

7
CLIENT CONTACTS
============== ==============
CLIENT-ID CONTACT-NAME
(primary key) (primary key)
CLIENT-NAME CLIENT-ID
ADDRESS PHONE-NUMBER
CLASS
STAFF-SIZE
TRAINING-LEVEL

CLIENT-EQUIP EQUIPMENT
============== ==============
CLIENT-ID EQUIP-MODEL-YR
(primary key) (primary key)
EQUIP-MODEL-YR EQUIP-TYPE
(primary key)
EQUIP-QTY

The last step is to remove any transitive dependencies. In this case, the
minimum training level is assigned to various hospital classes. Thus,
TRAINING-LEVEL is dependent on CLASS (and only transitively
dependent on CLIENT-ID). Yielding:

CLIENT TRAINING-REQUIRED
============== ==============
CLIENT-ID CLASS
(primary key) (primary key)
CLIENT-NAME TRAINING-LEVEL
ADDRESS
CLASS
STAFF-SIZE

CONTACTS CLIENT-EQUIP
============== ==============
CONTACT-NAME CLIENT-ID
(primary key) (primary key)
CLIENT-ID EQUIP-MODEL-YR
PHONE-NUMBER (primary key)
EQUIP-QTY

EQUIPMENT
==============
EQUIP-MODEL-YR
(primary key)
EQUIP-TYPE