DATABASE ANALYSIS AND DESIGN ST
DATABASE ANALYSIS AND DESIGN ST
DATABASE ANALYSIS AND DESIGN ST
Database Lifecycle
Like everything else, databases have a finite lifespan. They are born in a flush of
optimism and make their way through life achieving fame, fortune, and peaceful
anonymity, or notoriety as the case may be, before fading out once more. Even the most
successful database at some time is replaced by another, more flexible and up-to-date
structure, and so begins life anew. Although exact definitions differ, there are generally
six stages of the database lifecycle.
Analysis
The analysis phase is where the stakeholders are interviewed and any existing system is
examined to identify problems, possibilities and constraints. The objectives and scope of
the new system are determined.
Design
The design phase is where a conceptual design is created from the previously
determined requirements, and a logical and physical design are created that will ready
the database for implementation.
Implementation
Testing
The testing phase is where the database is tested and fine-tuned, usually in conjunction
with the associated applications.
Operation
The operation phase is where the database is working normally, producing information
for its users.
Maintenance
The maintenance phase is where changes are made to the database in response to new
requirements or changed operating conditions (such as heavier load).
Database development is not independent of systems development, often being one
component of the greater systems development process. The stages of systems
development basically mirror the stages of a database lifecycle but are a superset.
Whereas database design deals with designing the system to store the data, systems
design is also concerned with the processes that will impact on the data.
Database design
Databases exist because of the need to change data into information. Data are the raw
and unprocessed facts. Information is obtained by processing the data into something
useful. For example, millions of names and telephone numbers in a phone book are
data. Information is the telephone number of the fire department when your house is
burning down.
Certain principles guide the database design process. The first principle is that
duplicate information (also called redundant data) is bad, because it wastes space and
increases the likelihood of errors and inconsistencies. The second principle is that the
correctness and completeness of information is important. If your database contains
incorrect information, any reports that pull information from the database will also
contain incorrect information. As a result, any decisions you make that are based on
those reports will then be misinformed.
It is a good idea to write down the purpose of the database on paper — its
purpose, how you expect to use it, and who will use it. For a small database for a
home based business, for example, you might write something simple like "The
customer database keeps a list of customer information for the purpose of
producing mailings and reports.
Gather all of the types of information you might want to record in the database,
such as product name and order number.
To find and organize the information required, start with your existing
information. For example, you might record purchase orders in a ledger or keep
customer information on paper forms in a file cabinet. Gather those documents
and list each type of information shown (for example, each box that you fill in on
a form). If you don't have any existing forms, imagine instead that you have to
design a form to record the customer information. What information would you
put on the form? What fill-in boxes would you create? Identify and list each of
these items. For example, suppose you currently keep the customer list on index
cards. Examining these cards might show that each card holds a customers name,
address, city, state, postal code and telephone number. Each of these items
represents a potential column in a table.
Divide your information items into major entities or subjects, such as Products or
Orders. Each subject then becomes a table.
Decide what information you want to store 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.
Choose each table’s primary key. The primary key is a column that is used to
uniquely identify each row. An example might be Product ID or Order ID.
Analyze your design for errors. Create the tables and add a few records of
sample data. See if you can get the results you want from your tables. Make
adjustments to the design, as needed.
Apply the data normalization rules to see if your tables are structured correctly.
Make adjustments to the tables, as needed.