design database DETERMINE DATABASE REQUIREMENTS

1. LO1: DETERMINE DATABASE REQUIREMENTS
 Determining System Requirements
 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
 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.

2. ESTABLISHING GROUPS OF DATA
 Defining the main groups of data is similar to composing a jot list because a jot list identifies all the
main points associated with a topic.
 . 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
 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

3.  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
 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.

4.  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 name
 Cost of class
 Description of class
 Class prerequisites
 Class materials
 Class instructor
 In association with instructor information, the following specific information might be required:

Instructor identifier
 Instructor name
 Address
 Phone
 Skills
 Certifications
 Hire date
 Pay rate

5.  In association with book information, an online book store might require the following information:

Book ISBN
 Book title
 Description
 Category
 Publisher
 Author
 Publication date
 Cost
 Page count
 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.

6.  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 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.
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)

7.  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.
 The following one-to-many relationships exist:
 Class schedules are associated with many registrations.
 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.

8. 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.
Determining the Type of Database Model
 a database model has already been selected
 The model that best suits the needs of the business must be selected. .
 strategy for storing data with object-oriented (OO) and object-relational (OR)
technologies.

9. 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)

10.  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?
 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).