NAME OF INSTITUTION UNDER

Ethiopian TVET-System

INFORMATION TECHNOLOGY
DATABASE ADMINISTRATION
LEVEL III
LEARNING GUIDE # 09
Unit of Competence:Design a Database
Module Title : Designing a Database
LG Code : ICT DBA3 M03 09
TTLM Code :ICT DBA3 TTLM 0817
Learning Outcomes (LO) Page

LO1. Determine database requirements -2-

LO2. Develop logical data model -8-

LO3. Design data structures -26-

LO4. Design queries, screens and reports -53-

LO5. Design access and security systems -75-

Confirm database design

LO6. -80-

Learning guide Date 08-2017

DATABASE ADMINISTRATION August 2017
LEVEL III Author: IT Experts Page 1 of 81
 S
INFORMATION SHEET 1
LO1: DETERMINE DATABASE REQUIREMENTS

Gathering business and System requirements

System requirements refer to the combination of the back-end database and the application interface
to the database. The database is responsible for storing the data. The application is a mechanism
through which the end user can interact with the database. A typical application is comprised of ad
hoc queries, reports, and user input forms.
Determining System Requirements
Although at this point in the design process, the focus is still on gathering the requirements for the
business, the evelopers should look ahead and begin thinking about how these requirements will apply
to the database. How will the business rules, processes, and data affect the forward motion of the
design of the database? Although the processes of gathering requirements and beginning to define
system requirements are distinct from one another, the transition between the two should be smooth.
Once again, we point out the importance of completely gathering business requirements because a lack
thereof will definitely create a bumpy road between gathering business requirements and determining
requirements for the database.
System requirements are derived from the information gathered from the interviews. In other words,
business requirements are converted into system requirements. The conversion of business
requirements into system requirements involves the following steps, which are explained afterward:
 Identifying the data
 Grouping the data that has been defined
 Establishing a list of fields
 Establishing data relationships

Identifying the Data

A significant part of the interview process includes the identification of business data. Data will be
found throughout the notes taken during the interviews. Required data to be stored or captured must
be broken down into basic related groups. It is important to ensure that all data has been defined.
How will you know that all data has been defined? You might not at first. Although this question
must be raised, the answer cannot be determined until the business has been completely modeled,
which will come later. The comparison of data and business processes helps determine the
completeness of data. All data should be affected by at least one business process that has been
defined. What is the use of data if it cannot be accessed? Additionally, most business processes
imply the need for data. What data is required for each process? If a business process does not
require data, the process will not be required to design the database.
Data can exist in a variety of forms. Data can currently exist in a legacy database or on paper in a file
cabinet. You should understand how data is currently stored, and how it will be stored after the
creation of the new database. Presumably, as much data as possible will be stored in the database.
Although the total elimination of paperwork is unlikely, it is reasonable to assume that it’s possible
to greatly minimize the amount of paperwork needed. Some data can be stored in the database and
on paper. For example, if a prospective employee submits a resumé to human resources, information
about the prospective employee’s skills are entered into the database, and the original resumé is
stored in a file cabinet. By law, hard copies of other documents might be required.
Establishing Groups of Data
Defining the main groups of data is similar to composing a bit list because a jot list identifies all the
main points associated with a topic. In this case, the jot list is the notes taken during interviews.
Preliminary groups of data, referred to as entities, are established using the data collected from the
interviews. Establishing entities involves breaking the data down into logical categories, which
should be a no-brainer for the development team in the sense that this information should have
already been defined by the interviewees. Some categories of data will be related to one another and
others will not. Some of these categories of data might be directly related to business processes that
are defined, whereas others might not. Entities that are defined during information gathering are later
transformed into database tables during database design.
Examples of basic groups of data for our sample company, TrainTech, include
 Class information
 Student information
 Instructor information
 Class materials
 Class schedules
 Accounts receivable
 Accounts payable
Examples of basic groups of data for an online bookstore might include:
 Book information
 Author information
 Publisher information
 Distributor information
 Order information
 Product inventory
 Product returns
 Accounts receivable
 Accounts payable
 Establishing a List of Fields
Now that the data has been categorized into different groups, some general and other very specific, it
is time to break the data down into more detailed units of information. Based on the primary entities
that have been defined, a list of fields must be defined for each entity. As noted earlier in this book, a
field is called an attribute from a technical standpoint. A field is an individual unit of specific
information that is associated with an occurrence of information in the entity. Likewise, an entity can
be defined as a collection of fields that specifically define a logical grouping of data.
For example, the human resources department for a company must track employee data. Therefore,
the basic type of information stored is employee information. Within the scope of employee
information, many groups of data must be established. Some of these groups of data include basic
personal information for employees, employee pay information, employee resumé, employee
benefits, and employee tax information. For each group of data established, fields must also be
established. As each entity within the organization is unique, so must be all fields within a given
entity.
For example, fields within the pay category of data might include an identifier that refers to a specific
employee, the employee’s position within the company, the department in which the employee
works, the pay information whether it’s salary, hourly, bonus, or commission, the pay effective date,
and so forth. The employee benefit entity might entail the following information: an identifier that
refers to a specific employee, the type of health insurance elected, dental insurance elected, the
deductible amount, the employer contribution toward benefits, the number of employee dependents,
and so on.
Looking back to the entities established in the previous section, the following list of fields can be derived from
the entity associated with class information:
 Class identifier  Class prerequisites
 Class name  Class materials
 Cost of class  Class instructor
 Description of class

In association with instructor information, the following specific information might be required:
 Instructor identifier  Skills
 Instructor name  Certifications
 Address  Hire date
 Phone  Pay rate
In association with book information, an online book store might require the following information:
 Book ISBN  Author
 Book title  Publication date
 Description  Cost
 Category  Page count
 Publisher  Related titles
After a list of fields has been established, all data within the organization should be accounted for, whether
dealing with data associated with manual processes, or data currently used by a legacy system. The list of
fields established for entities are used to generate detailed ERDs. The detailed ERDs should completely
illustrate all data needed to design a database for an organization.

Establishing Relationships
Before determining data relationships, it is important to identify all data first. Relationships allow one or
more entities to be related. Without the ability to relate data among entities, all data and fields would be
required to reside in a single entity, which means that the amount of redundant information stored will be
maximized. Relationships determine how data from one entity can be associated with another entity.
Relationships also determine how data from one entity can refer to (access) data in another entity. In order
for relationships to exist between entities, entities must have fields that are common to one another.
Although many entities that have been identified will not have direct relationships to other entities, all
entities should be related to at least one other entity, creating an indirect relationship between entities.
For example, consider the following entities and brief lists of fields:
· Class schedule (class, date, location, instructor)
· Registration (class, student)
 · Instructors (instructor, address, pay rate)
· Students (student, address)
Instructors are associated with classes, classes are associated with registration, and students are associated
with registration. Instructors and students are not associated with one another directly, but one can easily
determine the students who are taught by a particular instructor by finding out what classes an instructor
teaches, and then by finding out what students are registered for the classes taught by the instructor.
Relationships such as these are typical in a relational database. This scenario represents two types of
relationships found in a relational database: one-to-many and many-to-many relationships. A one-to-one
relationship does not exist in this scenario.
The following one-to-many relationships exist:
o Class schedules are associated with many registrations.
o A student might have registered for many classes.
The following many-to-many relationships exist:
 Instructors can teach more than one class, and a class can be taught by more than one
instructor.
 An instructor can teach many students, and a student can have many instructors.
Business rules affect the relationships that might exist between data. Consider the following business
rules:
 A class might be scheduled many times throughout the year.
 A class must have a lead instructor.
 An instructor must teach at least one class.
 Many students can register for a class that has been scheduled.
 A class might have an assistant instructor, depending on the student enrollment.
 No more than 15 students can register for a given class.
 A class will be canceled if less than 5 students are enrolled for a given class.
The first five business rules determine data relationships. The fifth business rule also affects the logic in the
user application. The last two business rules do not affect the design of the database or the data
relationships, but affect the design of the user application that accesses the data. Take time to compare the
business rules with the sample relationships discussed.
Determining the Direction of Database Design
At some point toward the end of information gathering and requirements analysis, the direction taken for
the remainder of database design must be taken into consideration. Currently, all business requirements
should be defined.
In review, these business requirements include the data (entities and lists of fields), business rules, and
business processes. Interviews have been conducted with the customer and end user, as well as
management. Diagrams have been drawn to depict the business information gathered. These diagrams are
used to enhance the development team’s understanding of the business so that a database can be accurately
 designed. These diagrams are also used to conduct user feedback sessions, to obtain approval for the work
accomplished from all appropriate parties. Back and forth, this process goes, until everyone is satisfied that
all business requirements are completely gathered for the proposed database. After all information has been
gathered, it is simply a process of putting the pieces together.
Imagine putting a puzzle together, only to find out after hours of work that a piece has been missing all
along.
Following are considerations in determining the direction of any database design effort after information
has been gathered. These considerations can be taken before interviews are conducted; just be aware that
database design cannot proceed until the following issues are resolved.
 Database model to be used
 Implementation to be used
 Establishment of naming conventions and standards
 Establishment of milestones and deliverables
 Assign roles to members of design team
Determining the Type of Database Model
Hopefully at this point, a database model has already been selected. In most cases in today’s world, the
choice will be the relational database model. The model that best suits the needs of the business must be
selected. As previously mentioned, this book is based on the concepts of designing a database to fit the
mold of the relational database.
It is very unlikely that the flat-file database, network model, or hierarchical model will be the best choice
for an organization. As time passes, more companies will be paralleling their strategy for storing data with
object-oriented (OO) and object-relational (OR) technologies. In our opinion, the transition most
companies will take toward OO and OR databases will not happen for several years, during which time
these new technologies will have applied standards, have been tested more thoroughly, and have had more
successful real-world implementations.
Selecting an Implementation
It is easy to select a database model. After a database model has been selected, an implementation must be
selected. If the relational database model is being used, a relational database management system
(RDBMS) must be selected.
If you are not familiar with any particular RDBMS, making a selection can be very difficult at first because
so many relational database vendors exist.
Some common relational database management systems include
 Oracle—Commonly used by medium- to large-sized organizations (mainframe, client/server, Internet)
 Microsoft SQL Server—Commonly used by medium- to large-sized organizations (client/server)
 Microsoft Access—Commonly used by smaller organizations for personal applications (personal)
 DB2—Commonly used by small- to large-sized organizations (mainframe, client/server, Internet)
 Informix—Commonly used by small- to large-sized organizations (mainframe, client/server, internet)
 Sybase—Commonly used by small- to large-sized organizations (mainframe, client/server, internet)
 MySQL—Commonly used by small- to large-sized organizations (mainframe, client/server, internet)
Setting Naming Conventions and Standards to Be Used
Naming conventions and development standards are not so important during information gathering, but
must be established before beginning to model and design the database. Consider the following when
establishing naming conventions and standards.
 How will entities be named?
 How will attributes be named?
 How will tables be named?
 How will columns be named?
 How will other database objects be named?
 What abbreviations will be used?
Common sense should prevail when naming any database related object. All names should be descriptive.
At this point in the design process, avoid using abbreviations that might make a name obscure. If
abbreviations are used, an approved abbreviation list should be created.
Entities and attributes should have long, descriptive names. Remember that the main focal point of
information gathering and requirements analysis is understanding the business.
When business objects are converted into database objects, it may be more important to abbreviate names
to simplify code and meet the storage requirements of the RDBMS. For example, some RDBMSs restrict
the length of a database object name to thirty characters. Also, it is a common rule that database object
names cannot contain any spaces, although an underscore can be used to achieve the same effect. An
example is EMPLOYEE PAY (entity name) becomes EMPLOYEE_PAY (table name).
Following are sample rules we like to use when naming database related objects:
 The name should be in singular form (CUSTOMER).
 The name should contain spaces if more than one word for entities, and should
contain underscores in the
 place of spaces for tables.
 Names should be capitalized.
 Identifiers use the word ID.
 If abbreviations are used, be consistent.
 Don’t prefix column names with the table name, or abbreviation for the table name
(for the department
 name, use NAME, not DNAME).
It is important that naming conventions are established, followed, and enforced for consistency throughout
the design and life of a database. Adherence to naming conventions promote ease in the development of the
database, the application, and the management of an existing database. Defining and enforcing naming
conventions is one of an organization’s first steps towards a successful database implementation.
Summary
After all requirements are gathered, the design team draws various diagrams which depict the data and
processes that belong to the business. The most typical diagrams, which are quite vague at this point,
include entity relationship diagrams (illustrate the data), process model diagrams, function hierarchy
diagrams, and data flow diagrams. Detail is added to diagrams when converting business requirements into
system requirements. For example, after a list of fields are determined for a given entity; attributes are
added to the entity on the ERD. System requirements are defined by identifying the data, breaking the data
into logical groups, creating a list of fields for groups of data, and establishing data relationships. Before
information gathering and requirements analysis are complete, and the next major phase, modeling, is
encountered, precautions must be taken to ensure that the project is moving on the right track. Before
modeling begins, standards and naming conventions must be established so that all work is performed
consistently.