DATABASE ADMINISTRATION

LEVEL III
LEARNING GUIDE # 5
Unit of Competence : Identify Physical Database Requirements
Module Title : Identifying Physical Database Requirements
LG Code : ICT DBA3 M02 05
TTLM Code : ICT DBA3 TTLM 0817

Learning Outcomes (LO) Page

1. Identify database scope -2-
1. Identify database requirements -24-
1. Identify security requirements -41-
1. Seek client feedback and approval -53-
LO1. Identify database scope
• THE DATABASE ENVIRONMENT AND DEVELOPMENT PROCESS
• After Studying This Information Sheet, You Should Be Able To: · Concisely Define Each of The
Following Key Terms: Data, Database, Database Management System, Data Model, Information,
Metadata, Enterprise Data Model, Entity, Relational Da- Abase, Enterprise Resource Planning (ERP)
System, Database Application, Data Warehouse, Data Independence, Repository, User View, And
Enterprise Data Modeling.
• · Name Several Limitations of Conventional File Processing Systems.
• · Explain At Least Ten Advantages of The Database Approach, Compared to Traditional File Pro-
• Cussing.
• · Identify Several Costs and Risks of The Database Approach.
• · List and Briefly Describe Nine Components of a Typical Database Environment.
• · Identify Four Categories of Applications That Use Databases and Their Key Characteristics
• BASIC CONCEPTS AND Definitions
• A database as an organized collection of logically related data.
• Data
• the term data referred to facts concerning objects and events that could be
recorded and stored on computer media. For example, in a salesperson’s
database, the data would include facts such as customer name, address,
and telephone number.
• This type of data is called structured data.
• The most important structured data types are numeric, character, and
dates. Structured data are stored in tabular form (in tables, relations,
arrays, spreadsheets, etc.) and are most commonly found in traditional
databases and data warehouses.
• An expanded definition of data that includes structured and unstructured
types is “a stored representation of objects and events that have meaning
and importance in the user’s environment.”
 Data Versus Information
• We define information as data that have been processed in such a
way that the knowledge of the person who uses the data is increased.
For example, consider the following list of facts:
•
Baker, Kenneth D.
• Doyle, Joan E.
• Finkle, Clive R.
• Lewis, John C.
• McFerrin, Debra R.
• Meta data
• As we have indicated, data become useful only when placed in
some context. The primary mechanism for providing context for
data is metadata. Metadata are data that describe the properties
or characteristics of end-user data and the context of that data.
Some of the properties that are typically described include data
names, definitions, length (or size), and allowable values
• Traditional File Processing Systems
• When computer-based data processing was first available, there
were no databases. To be useful for business applications,
computers had to store, manipulate, and retrieve large files of
data. Computer file processing systems were developed for this
purpose. These systems have been replaced by database
processing systems in most business applications today.
Disadvantages of File
Processing Systems
•Program-Data Dependence
• Duplication of Data
• Limited Data Sharing
• Lengthy Development Times
• Excessive Program Maintenance

FIGURE 1-2: OLD file PROCESSING SYSTEMS

 The Database Approach
• Data Models
• Designing a database properly is fundamental to
establishing a database that meets the needs of the users.
Data models capture the nature of and relationships
among data and are used at different levels of abstraction
as a database is conceptualized and designed. The
effectiveness and efficiency of a database is directly
associated with the structure of the database.
• data model is made up entities, attributes, and
relationships and the most common data modeling
representation is the entity-relationship model. A brief
description is presented below.
 Basic symbols : E-R notation

Entity Relationship Primary key Attribute Multivalued Gerund

attribute
Relationship degree :

Unary Binary
Ternary
Relationship cardinality:

Mandatory 1 cardinality ISA

Many(M) cardinality Class-subclass relationship

(1,2,.. ,many) Exclusive
Optional 0 or 1 relationship
cardinality
Optional zero-many
cardinality (0,1,2, ..., many)
Entities
• Is an object in the real world that is distinguishable from other objects
• Relationships
• A well-structured database establishes the relationships between
entities that exist in organizational data so that desired
information can be retrieved. Most relationships are one-to-many
(1:M) or many-to-many (M: N). A customer can place (the Places
relationship) more than one order with a company.
STUDENT Completes COURSE

Many to many
• Relational Databases
• Relational databases establish the relationships between
entities by means of common fields included in a file, called a
relation.
 Database Management Systems

• A database management system (DBMS) is a software system that

enables the use of a database approach. The primary purpose of a
DBMS is to provide a systematic method of creating, updating, storing,
and retrieving the data stored in a database. It enables end users and
application programmers to share data, and it enables data to be shared
among multiple applications rather than propagated and stored in new
files for every new application. A DBMS also provides facilities for
controlling data access, enforcing data integrity, managing concurrency
control, and restoring a database.
 ADVANTAGES OF THE DATABASE
APPROACH
• Program-Data Independence
• Planned Data Redundancy
• Improved Data Consistency
• Improved Data Sharing
• Increased Productivity of Application Development
• Enforcement of Standards
• Improved Data Quality
• Improved Data Accessibility and Responsiveness
• Reduced Program Maintenance
• Improved Decision Support
 COSTS AND RISKS OF THE
DATABASE APPROACH
• New, Specialized Personnel
• Installation and Management Cost and Complexity
• Conversion Costs
• Need for Explicit Backup and Recovery
• ORGANIZATIONAL Conflict
 Components of the Database
• Now that you have seen Environment
the advantages and risks of using the database approach
to managing data, let us examine the major components of a typical database
environment and their relationships. Following is a brief description of the nine
components shown in Figure 1-5:
• Computer-aided software engineering (CASE) tools. CASE tools
• Repository
• DBMS.
• Database.
• Application programs
• User interface
• Data and database administrators
• System developers
• End users
• hardware, software, and people
The Range of Database Applications
• Personal Databases
• Personal databases are designed to support one user. Personal
databases have long resided on personal computers (PCs), including
laptops, and increasingly on smart phones and PDAs.
• TWO-TIER CLIENT/SERVER DATABASES
• Often, what starts off as a single-user database evolves into
something that needs to be shared among several users. A
workgroup is a relatively small team of people (typically fewer than
25 persons) who collaborate on the same project or application or on
a group of similar projects or applications. These persons might be
engaged (for example) with a construction project or with developing
a new computer application and need to share data amongst the
group.
• MULTITIER CLIENT/SERVER DATABASES
• One of the drawbacks of the two-tier database architecture is
that the amount of functionality that needs to be programmed
into the application on the users’ computer can be pretty
significant because it needs to contain both the user interface
logic as well as the business logic. This, of course, means that
the client computers need to be powerful enough to handle the
programmed application.
• ENTERPRISE APPLICATIONS
• An enterprise application/database is one whose scope is the
entire organization or enterprise (or, at least, many different
departments). Such databases are intended to support
organization-wide operations and decision making. Note that an
organization may have several enterprise databases, so such a
database is not inclusive of all organizational data.
The evolution of enterprise databases has resulted in two major
developments:
• Enterprise resource planning (ERP) systems
• 2. Data warehousing implementations
 Match the following terms and definitions
• A. data placed in context or summarized
__________ 1. data B. application program(s)
• __________ 2. database application C. facts, text, graphics, images, etc.
• __________ 3. constraint
D. a graphical model that shows the high-level entities for the
• __________ 4. repository organization and the relationships among those entities
• __________ 5. metadata E. organized collection of related data
• __________ 6. data warehouse
F. centralized storehouse for all data definitions
• __________ 7. Information F. includes data definitions and constraints
G. separation of data description from programs system
• __________ 8. user view
H. A business management system that integrates all
• __________ 9. database management
functions of the enterprise logical description of portion of
• __________ 10. data independence database
• __________ 11. Database
I. provide controlled access to user databases
• __________ 12. enterprise resource plan-Ning (ERP)
J. a rule that cannot be violated by database users
• __________ 13. systems development life cycle (SDLC)
K. integrated decision support database
• __________ 14. prototyping
L. consist of the enterprise data model and multiple user
• __________ 15. enterprise data model K. a software application that is used
views
to create, maintain, and
• __________ 16. conceptual schema consists of two data models: a logical M. a rapid approach to systems development
model and a physical N. a comprehensive description of business data
• __________ 17. internal schema O. a structured, step-by-step approach to systems
• __________ 18. external schema model development
 DATABASE DESIGN PLANNING

• What Is Database Design?

• · Importance of Database Design
 · Planning Database Design
 · Trademarks of A Solid Database Design
 · Design Methodologies
 · Logical Versus Physical Modeling
•
What Is a Database Design?
• Webster’s dictionary uses the following phrases to define the term design:
• · “To prepare the preliminary plans or sketch for”
• · “To intend for a definite purpose”
• · “The combination of details or features of something constructed”
• · “To plan and fashion artistically or skillfully”
• · “Adaptation of means to a preconceived end”
• “Many “details and features” are involved during the design of any database.
Three very basic phases of database design exist:
1. Requirements gathering—Is the process of conducting meetings and/or
interviews with customers, end users, and other individuals in the company to
establish the requirements for the proposed database. Requirements involve, but are
not limited to, the following information:
•How the business does business
•Business rules and processes
2. Data modeling—Is the process of visually representing the data for a
business, and then eventually converting the business model into a data
model. The data model generated is used to ultimately create the tables,
views, and other objects that comprise the database.
3 Database design and normalization—Is a phase in which the business model
(logical model) is converted into a physical model (tables). Also, part of design is
normalization, or the reduction or elimination of data redundancy.
•Importance of Database Design
•The main reason good database design is so important is that organization is
promoted. The designers have more control over the design, implementation, and
management of any project if the project is well thought out. Because the database
design’s goal is to completely capture all a business’ data storage needs, its product
should be an accurate and easy-to-use database that performs well.
•Planning Database Design
• The only true chance the design team has to get a handle on the design of a
database takes place before the design process actually begins. Before any
significant action should be taken toward gathering requirements, business
modeling, or database design, a solid plan must be devised.
•The Mission Statement
• The mission statement is a summation of the overall purpose of the proposed database. Typically, management
is the main force involved in determining the mission statement. Management, developers, and end users are all
involved in determining the mission objectives, or the detailed goals set forth for the database.
• The mission statement should be further refined by answering the following questions:
• What is the purpose of the database?
• Who will use the database?
• What type of database will this be?
• What models and methodologies will be used?
• Is this a new database?
• Will this database be molded after a legacy database?
• Will the database need to be modified in the near future?
• Will there be multiple databases?
• How will the customer access the database?
 Mission Statement and Objectives for Our Model Company, TriTech
•Mission statement—An automated business system is needed to manage and track student class
registrations, class schedules, instructors, and instructor availability.
•Mission objectives:
 The manual process of managing the training program will be automated.
 Internal users will be accessing the database.
 The relational model will be used.
 An automated design (AD) tool will be used to design the database.
 Currently no database is in place to meet the present needs (no legacy database).
 The database might need to be modified as the training company grows and more data storage
requirements are established.
•DEVISING A WORK PLAN
•After the mission statement and design objectives have been defined, it is time to devise a work plan that will be used as a
guide for the design of the database. A work plan is an outline that breaks down the steps involved.
•Following are preliminary considerations for planning a work plan:
 Location of the work to be conducted.
 A design team must be established.
 Business rules.
 Hardware to be used.
 Software to be used.
 Tools for development.
 Tools for the end users.
 Backup plan for development work done.
 Database environments used for development.
 Basic standards and naming conventions.
 Database environment for production.
•SETTING MILESTONES AND MAKING DEADLINES
A milestone is a significant point in the database design process.
• Following are common milestones:
• All business requirements are gathered.
• A work plan is devised.
• Entities and attributes are established.
• The logical design of the database is complete.
• The physical design of the database is complete.
• The database is tested.
• The database is implemented into production.
• Project time frames should be determined for each milestone
established. Deadline dates are established and associated with
each milestone.
 Establishing the Design Team and Assigning Tasks
• After a work plan has been established and milestones with deadlines are set, a
design (development) team is established if one does not already exist. The design
team might consist of one or many individuals. The responsibility to design a
database might fall into the hands of only one individual for smaller companies.
 Trademarks of a Solid Database Design

Trademarks of a good database design include

•A functional database is generated.
•The database accurately represents the business’s data.
•The database will be easy to use and maintain.
•Acceptable response time exists for the end users.
•Modifications are easily made to the structure.
•Data can be retrieved and modified easily.
•Down time because of poor design is minimized.
•Very little maintenance is needed.
•Data is kept safe by planning for security.
•Redundant data is minimized or nonexistent.
Data can be easily backed up or recovered.
•The actual structure of the database will be virtually transparent to the end
user.
•Overview of Design Methodologies
•A methodology represents the thought process used by the design team in
order to develop a database model. Some of the questions that should be
raised when selecting a design methodology are
• What tools are available to aid in design?
• How critical is development time?
• What are the skills of the developers?
• Will the project require outsourcing?
• What resources are available for the project?
•Design methodology traditionally involves the following three phases:
• 1. Requirements analysis
• 2. Data modeling
• 3. Design and Normalization
•Two types of data modeling are as follows:
 Logical modeling
 Physical modeling
•Logical Modeling
• Logical modeling deals with gathering business requirements and converting those
requirements into a model.
• The logical model revolves around the needs of the business, not the
database, although the needs of the business are used to establish the
needs of the database.
•Typical deliverables of logical modeling include
 Entity relationship diagrams
 Business process diagrams
 User feedback documentation
• Typical design phases that apply to logical modeling:
 Gathering requirements
 Requirements analysis
• Physical Modeling
• Physical modeling involves the actual design of a database according to the requirements that
were established during logical modeling.
Typical deliverables of physical modeling include the following:
• Server model diagrams
• User feedback documentation
• Database design documentation
• Typical development phases that apply to physical modeling:
• Design
• Implementation
• Maintenance
 LO2: IDENTIFY DATABASE REQUIREMENTS

•Understanding user needs

• designing any custom product, whether it’s a database, beach house, or
case mod, is largely a translation process. you need to translate the
customers’ needs, wants, and desires from the sometimes-fuzzy ideas
floating around in their heads into a product that meets the customers’ needs.
the first step in the translation process is understanding the user’s
requirements
 PHYSICAL DATABASE DESIGN AND PERFORMANCE
•The Physical Database Design Process
• The primary goal of physical database design is data processing
efficiency.
• Designing physical files and databases requires certain
information that should have been collected and produced
during prior systems development phases. The
information needed for physical file and database design
includes these requirements:
• Designing physical files and databases requires certain information that
should have been collected and produced during prior systems
development phases.
 Data Volume and Usage Analysis
•data volume and frequency-of-use statistics are important inputs to the physical
database design process, particularly in the case of very large-scale database
implementations. Thus, you have to maintain a good understanding of the size and
usage patterns of the database throughout its life cycle. In this section, we discuss
data volume and usage analysis as if it were a one-time static activity, but in practice,
you should continuously monitor significant changes in usage and data volumes.
 Designing Fields

• A field is the smallest unit of application data recognized by system software,

such as a programming language or database management system.
• A field corresponds to a simple attribute in the logical data model, and so in
the case of a composite attribute, a field represents a single component.

•CHOOSING DATA TYPES

• A data type is a detailed coding scheme recognized by system software, such as a DBMS, for
representing organizational data.
• Selecting a data type involves four objectives that will have different relative
levels of importance for different applications:
• 1. Represent all possible values.
• 2. Improve data integrity.
• 3. Support all data manipulations.
• 4. Minimize storage space.
 CONTROLLING DATA INTEGRITY
• DBMSs, data integrity controls (i.e., controls on the possible value a field can
assume) can be built into the physical structure of the fields and controls enforced
by the DBMS on those fields.
• Default value. A default value is the value a field will assume
unless a user enters an explicit value for an instance of that field.
• Range control. A range control limits the set of permissible
values a field may assume.
• Null value control. A null value is defined as an empty value.
• Referential integrity. Referential integrity on a field is a form
of range control in which the value of that field must exist as the
value in some field in another row of the same or
• (most commonly) a different table.
•Handling Missing Data
• When a field may be null, simply entering no value may be sufficient. For
example, suppose a customer zip code field is null and a report summarizes total
sales by month and zip code.
 2
L O
of
n d
E
 LO3: IDENTIFY SECURITY REQUIREMENTS
Managing Data Security
• The goal of database security is to protect data from accidental or intentional threats
to their integrity and access.
• The database environment has grown more complex, with
distributed databases located on client/server architectures and
personal computers as well as on mainframes.
• For example, computer listings or computer disks containing
sensitive data should not be left unattended on desktops.
• Data administration is often responsible for developing overall policies and procedures
to protect databases.
• Database administration is typically responsible for administering
database security on a daily basis.
 HOW IS SECURITY IMPORTANT TO DATABASE DESIGN?

• For users to access the system, it must be accessible on the local

(LAN) or wide area network (WAN) and these day’s most often via the
World Wide Web as well. Applications using Web browsers as the
primary user interface are so common as to be the norm for new
development. When we put the database on the Web, it becomes
vulnerable to hackers and other criminals from outside your
organization who will damage your system or steal your data just
because they can. Imagine that everyone’s salary, personnel files, or
your company’s trade secrets are posted for public view on a Web site.
 Threats to Data Security
• Threats to data security may be direct threats to the database. For example,
those who gain unauthorized access to a database may then browse, change,
or even steal the data to which they have gained access.
• All parts of the system must be secure, including the database, the network,
the operating system, the building(s) in which the database resides
physically, and the personnel who have any opportunity to access the system.
• The following threats must be addressed in a comprehensive data
security plan:
•Accidental losses, including human error, software, and hardware-caused breaches.
•Theft and fraud
•Loss of privacy or confidentiality
•Loss of data integrity
•Loss of availability.
 Who Needs Access to The Database?
• Most information required throughout design and for implementation will be gathered from interviews
during analysis. In order to plan for database security during database design and enforce the security after
implementation, all users of the database must first be established. There are potentially different
categories of users for any information system, ranging from end users to administrators of the information
system.
• the most common users, or individuals who might have access to any information
system, include
 End users
 Customers
 Management
 Network administrator
 System administrator
 Database administrator
 Schema owner