LEARNING GUIDE # 06

Module Title: - Determining

Suitability of Database Functionality
and Scalability
MODULE CODE: ICT DBA4 06
0411
Prepared By: Mezgebe Manaye (2013)
SYMBOLS
These symbols are located at the left margin of the module. These illustrate the actions that should be
taken or resource to be used at a particular stage in the module.

LO Learning
Outcome Self-Check

Answer Key
Resources

Reading Assessment
Activity

Remember/Tips
Use Computer

Practice Task Safety

Prepared By: Mezgebe Manaye (2013)

 New INFORMAT UNIT Database Administration Level IV
Abyssinia ION SHEET MODULE Determining Suitability of Database Functionality and Scalability
College

At the end of the module the learner will be able to:

LO
1.Determine database functionality
2.Identify scalability and functionality requirements
3. Prepare report

Database requirement
Functional Requirements

The Functional Requirement document (also called Functional Specifications or Functional

Requirement Specifications), defines the capabilities and functions that a System must be able to
perform successfully.

Functional Requirements should include:

Descriptions of data to be entered into the system

Descriptions of operations performed by each screen
Descriptions of work-flows performed by the system
Descriptions of system reports or other outputs
Who can enter the data into the system.
How the system meets applicable regulatory requirements

The functional specification is designed to be read by a general audience. Readers should

understand the system, but no particular technical knowledge should be required to understand
the document.

Determining Suitability of Database Functionality and Scalability version 1.0 Year 2012 prepared By: Mezgebe M. Page 1
 New INFORMAT UNIT Database Administration Level IV
Abyssinia ION SHEET MODULE Determining Suitability of Database Functionality and Scalability
College

Examples of Functional Requirements

Functional requirements should include functions performed by specific screens, outlines

of work-flows performed by the system and other business or compliance requirements the
system must meet.

Interface requirements

Field accepts numeric data entry

Field only accepts dates before the current date
Screen can print on-screen data to the printer

Business Requirements

Data must be entered before a request can approved

Clicking the Approve Button moves the request to the Approval Workflow
All personnel using the system will be trained according to internal SOP AA-101

Regulatory/Compliance Requirements

The database will have a functional audit trail

The system will limit access to authorized users
The spreadsheet can secure data with electronic signatures

Security Requirements

Members of the Data Entry group can enter requests but not approve or delete requests
Members of the Managers group can enter or approve a request, but not delete requests
Members of the Administrators group cannot enter or approve requests, but can delete
requests

Depending on the system being described, different categories of requirements are appropriate.
System Owners, Key End Users, Developers, Engineers and Quality Assurance should all
participate in the requirement gathering process, as appropriate to the system.

Determining Suitability of Database Functionality and Scalability version 1.0 Year 2012 prepared By: Mezgebe M. Page 2
 New INFORMAT UNIT Database Administration Level IV
Abyssinia ION SHEET MODULE Determining Suitability of Database Functionality and Scalability
College

Requirements outlined in the functional requirements are usually tested in the Operational
Qualification.

Non-functional requirement

In systems engineering and requirements engineering, a non-functional requirement is

a requirement that specifies criteria that can be used to judge the operation of a system, rather
than specific behaviors. This should be contrasted with functional requirements that define
specific behavior or functions. The plan for implementing functional requirements is
detailed in the system design. The plan for implementing non-functional requirements is
detailed in the system architecture.

Broadly, functional requirements define what a system is supposed to do whereas non-functional

requirements define how a system is supposed to be. Functional requirements are usually in the
form of "system shall do <requirement>", while non-functional requirements are "system shall be
<requirement>".

Non-functional requirements are often called qualities of a system. Other terms for non-
functional requirements are "constraints", "quality attributes", "quality goals", "quality of service
requirements" and "non-behavioral requirements".[1] Informally these are sometimes called the
"ilities", from attributes like stability and portability. Qualities, that are non-
functional requirements, can be divided into two main categories:

1.Execution qualities, such as security and usability, which are observable at run time.
2.Evolution qualities, such as testability, maintainability, extensibility and scalability, which
are embodied in the static structure of the software system.

Identifying business rule, Entities, and relationship

Identifying Business Rules

Typically during a requirements elicitation process, a Business Analyst elicits the

functional requirements, nonfunctional requirements and business rules. It is only common to
confuse some business rules with functional or nonfunctional requirements and vice versa.
For example, the
Determining Suitability of Database Functionality and Scalability version 1.0 Year 2012 prepared By: Mezgebe M. Page 3
 New INFORMAT UNIT Database Administration Level IV
Abyssinia ION SHEET MODULE Determining Suitability of Database Functionality and Scalability
College

mathematical formula to calculate sales percentage in year is a business rule whereas, compare
sales percentage of different regions and identify the best performing region is a
functional requirement. In order to remove redundancy, sometimes the business rule is
incorrectly merged with functional requirements.

An incorrect classification of business rule, can cause design and architectural issues, especially
when it comes to maintaining an external rules engine or an embedded one.

Below are some common properties of business rules:

Constraints: Statements intended to assert business structure or influence the behavior of the
business are business rules. For example, The system will not allow any Sale/ Return
transaction(s) on Weekends and Public Holidays.
Access Control: Defining the security matrix for the system is part of the business rule. For
example, the company internal portal should be accessible by employees only.
Authorization: A statement that defines the level of authorization or the Create, Read, Update
and Delete (C.R.U.D) permissions for each user is also classified as a business rule. For
example, only managers should have permission to approve/ reject the employees’
leave requests.
Business Calculations: Mathematical Calculations or Business specific calculations are all part
of the business rule. For example, No employee can carry forward more than 30 privilege leaves
to the next accounting year.
Organizational Policies: Sometimes organizational policies are laid to handle specific
functionalities in a slightly different behavior. There is a condition described and if the condition
is true, the system takes an alternate flow of execution. For example, Customers, who
have helped generate revenue more than $100,000 should receive a 10% discount on future
purchases.

Below are some points on the approach to document Business Rules (by Ronald Ross):

Be written and made explicit.

Be expressed in plain language.

Determining Suitability of Database Functionality and Scalability version 1.0 Year 2012 prepared By: Mezgebe M. Page 4
 New INFORMAT UNIT Database Administration Level IV
Abyssinia ION SHEET MODULE Determining Suitability of Database Functionality and Scalability
College

 Exist independent of procedures and workflows (e.g. multiple models).

 Build on facts, and facts should build on concepts as represented by terms (e.g.
glossaries).
 Guide or influence behavior in desired ways. Be motivated by identifiable and important
business factors.
 Be accessible to authorized parties (e.g. collective ownership).
 Be single sourced.
 Be specified directly by those people who have relevant knowledge (e.g.
active stakeholder participation).
 Be managed.

Entity

An entity is something that exists by itself, although it need not be of material

existence. In particular, abstractions and legal fictions are usually regarded as entities. In
general, there is also no presumption that an entity is animate.

In business, an entity is a person, department, team, corporation, cooperative,

partnership, or other group with whom it is possible to conduct business.

Sometimes, the word entity is used in a general sense of a being, whether or not the referent
has material existence, e.g., is often referred to as an entity with no corporeal form
(non-physical entity), such as a language. It is also often used to refer to ghosts and other
spirits.

The word entitative is the adjective form of the noun entity. Something that is
entitative is "considered as pure entity; abstracted from all circumstances", that is,
regarded as entity alone, apart from attendant circumstances.

Entity–relationship model

In software engineering, an Entity–relationship model (ER model) is a data model for

describing a database in an abstract way. This article refers to the techniques proposed in
Peter Chen's 1976 paper. However, variants of the idea existed previously, and have
Determining Suitability of Database
been devised Functionality and Scalability version
subsequently 1.0 Year 2012 prepared By: Mezgebe M. Page 5
 New INFORMAT UNIT Database Administration Level IV
Abyssinia ION SHEET MODULE Determining Suitability of Database Functionality and Scalability
College

such as super type and subtype data entities and commonality relationships.

Process models

Process models are processes of the same nature that are classified together into a model. Thus, a
process model is a description of a process at the type level. Since the process model is at the
type level, a process is an instantiation of it. The same process model is used repeatedly for the
development of many applications and thus, has many instantiations. One possible use of
a process model is to prescribe how things must/should/could be done in contrast to the process
itself which is really what happens. A process model is roughly an anticipation of what
the process will look like. What the process shall be will be determined during actual
system development.

The goals of a process model are to be: Descriptive

Track what actually happens during a process.

Take the point of view of an external observer who looks at the way a process has been
performed and determines the improvements that must be made to make it perform more
effectively or efficiently.

Prescriptive

Define the desired processes and how they should/could/might be performed.

Establish rules, guidelines, and behavior patterns which, if followed, would lead to the desired
process performance. They can range from strict enforcement to flexible guidance.

Explanatory

Provide explanations about the rationale of processes.

Explore and evaluate the several possible courses of action based on rational arguments.
Establish an explicit link between processes and the requirements that the model needs to

Determining Suitability of Database Functionality and Scalability version 1.0 Year 2012 prepared By: Mezgebe M. Page 6
 New INFORMAT UNIT Database Administration Level IV
Abyssinia ION SHEET MODULE Determining Suitability of Database Functionality and Scalability
College

fulfill.
Pre-defines points at which data can be extracted for reporting purposes.

Database Scalability

A popular notion about databases is that they don't "scale" well, i.e. that it's too difficult
to keep growing the size a database, or too hard to handle the load of an increasing
number of concurrent users. To put it differently, some believe that database-centric
design is fundamentally incapable of efficiently meeting the demands of high-
performance distributed computing. We disagree.

Twenty years ago, the practical limits of database scalability were legitimately in doubt,
since a single commodity server was relatively puny, and techniques of connecting
multiple servers were slow, costly, and experimental. Today, those doubts are
ancient mythology because of significant advances in both hardware and
multiprocessing DBMS technology. Today, the debate is about optimization, not the
feasibility of scaling to a sufficiently humongous database capacity.

Database Capacity Planning

Disk Estimation for IBM Sterling Distributed Order Management provides a

methodology to estimate your initial disk requirements. By using this worksheet and
then tracking your actual database usage over time, disk growth will be easier to
anticipate.

In recent years, the cost of disks has dramatically decreased and the capacity and speed of
disks has increased. Information system managers who order disk capacity have
shifted from purchasing disk arrays that are dedicated to a particular database server and
project to the use of Storage Area Networks (SANs).

Consider the confidence that you have in your data estimates when making the final
purchase decision and adjust accordingly. After your initial purchase and production
deployment, you can track disk growth for future purchase forecasts.

Determining Suitability of Database Functionality and Scalability version 1.0 Year 2012 prepared By: Mezgebe M. Page 7
 New INFORMAT UNIT Database Administration Level IV
Abyssinia ION SHEET MODULE Determining Suitability of Database Functionality and Scalability
College

Database Architecture

An early proposal for a standard terminology and general architecture for database systems was
produced in 1971 by the DBTG (Data Base Task Group) appointed by the Conference on Data
Systems and Languages (CODASYL, 1971). The DBTG recognized the need for a two
level approach with a system view called the schema and user views called subschema. The
American National Standards Institute (ANSI) Standards Planning and Requirements Committee
(SPARC) produced a similar terminology mid architecture in 1975 (ANSI 1975).
ANSI-SPARC recognized the need for a three level approach with a system catalog.

There are following three levels or layers of DBMS architecture:

External Level
Conceptual Level
Internal Level

Objective of the Three Level Architecture

The objective of the three level architecture is to separate each user's view of the database from
the Way the database is physically represented. There are several reasons why this separation is
desirable:

•Each user should be able to access the same data, but have a different customized view of the
data. Each user should be able to change the way he or she views the data, and this change
should not affect other users.
•Users should not have to deal directly with physical database storage details, such as
indexing or hashing. In other words a user's interaction with the database should be
independent of storage considerations.
•The Database Administrator (DBA) should be able to change the database storage
structures without affecting the user's views.
•The internal structure of the database should be unaffected by changes to the physical
aspects of storage, such as the changeover to a new storage device.

Determining Suitability of Database Functionality and Scalability version 1.0 Year 2012 prepared By: Mezgebe M. Page 8
 New INFORMAT UNIT Database Administration Level IV
Abyssinia ION SHEET MODULE Determining Suitability of Database Functionality and Scalability
College

• The DBA should be able to change the conceptual structure of the database without
affecting all users.

External Level or View level

It is the users' view of the database. This level describes that part of the database that is relevant
to each user. External level is the one which is closest to the end users. This level deals with
the way in which individual users vie\v data. Individual users are given different views
according to the user's requirement.

A view involves only those portions of a database which are of concern to a user. Therefore
same database can have different views for different users. The external view insulates
users from the details of the internal and conceptual levels. External level is also known as
the view level. In addition different views may have different representations of the same
data. For example, one user may view dates in the form (day, month, year), while
another may view dates as (year, month, day).

Conceptual Level or Logical level

It is the community view of the database. This level describes what data is stored in the
database and the relationships among the data. The middle level in the three level
architecture is the conceptual level. This level contains the logical structure of the entire
database as seen by the DBA. It is a complete view of the data requirements of the
organization that is independent of any storage considerations. The conceptual level
represents:

• All entities, their attributes, and their relationships;

An Entity is an object whose information is stored in the database. For example, in

student database the entity is student. An attribute is a characteristic of interest about an
entity.

For example, in case of student database Roll No, Name, Class, Address etc. are attributes
of entity student.

Determining Suitability of Database Functionality and Scalability version 1.0 Year 2012 prepared By: Mezgebe M. Page 9
 New INFORMAT UNIT Database Administration Level IV
Abyssinia ION SHEET MODULE Determining Suitability of Database Functionality and Scalability
College

• The constraints on the data;

• Semantic information about the data;
• Security and integrity information.

The conceptual level supports each external view, in that any data available to a user
must be contained in, or derivable from, the conceptual level. However, this level
must not contain any storage dependent details. For instance, the description
of an entity should contain only data types of attributes (for example, integer,
real, character) and their length (such as the maximum number of digits or
characters), but not any stQrage considerations, such as the number of bytes
occupied. Conceptual level is also known as the, logical level.

Internal level or Storage level

It is the physical representation of the database on the computer. This level describes
how the data is stored in the database. The internal level is the one that concerns
the way the data are physically stored on the hardware. The internal level covers
the physical\ implementation of the database to achieve optimal runtime
performance and storage space utilization. It covers the data structures and file
organizations used to store data on storage devices. It interfaces with the
operating system access methods to place the data on the storage devices,
build the indexes, retrieve the data, and so· on.

The internal level is concerned with such things as:

• Storage space allocation for data and indexes;

• ofRecord
Determining Suitability Databasedescriptions forScalability
Functionality and storage (with
versionstored sizes
1.0 Year for
2012 data items);By: Mezgebe M.
prepared Page
10
 New INFORMAT UNIT Database Administration Level IV
Abyssinia ION SHEET MODULE Determining Suitability of Database Functionality and Scalability
College

• Record placement;
• Data compression and data encryption techniques.

There will be only one conceptual view, consisting of the abstract representation of
the database in it’s entirely. Similarly there will be only one internal or physical
view, representing the total database, as it is physically stored.

Schema

It is important to note that the data in the database changes frequently, while
the plans or schemes remain the same over long periods of time. The
database plans consist of types of entities that a database deals with, the
relationship among these entities and the ways in which the entities and
relationships are expressed from one level of abstraction to the next level for the
users' view. The users' view of the data (also called logical organization of data)
should be in a form that is most convenient for the users and they should not be
concerned about the way data is physically organized. Therefore, a DBMS should
do the translation between the logical (users' view) organization and the physical
organization of the data in the database.

The plan or scheme of the database is known as Schema. Schema gives the names of
the entities and attributes. It specifies the relationship among them. It is a
framework into which the values of the data items (or fields) are fitted. The plans
or the format of schema remains the same. But the values fitted into this format
changes from instance to instance. In other terms, schema means overall plans of
all the data item (field) types and record types stored in a database.
Schema includes the definition of the database name, the record type and the
components that make up those records

Types of Schema

There are three different types of schema in the database corresponding to

each data view of database. In other words, the data views at each of three
levels are described by schema.
Determining Suitability of Database Functionality and Scalability version 1.0 Year 2012 Page
prepared By: Mezgebe M.
A schema is defined as an outline or a plan that describes the records and 11
relationships existing at the particular level. The External view is described
 New INFORMAT UNIT Database Administration Level IV
Abyssinia ION SHEET MODULE Determining Suitability of Database Functionality and Scalability
College

schema that correspond to different views of the data. Similarly the Conceptual view is defined
by conceptual schema, which describes all the entities, attributes, and relationship together with
integrity constraints. Internal View is defined by internal schema, which is a
complete description of the internal model, containing definition of stored records, the
methods of representation, the data fields, and the indexes used.

There is only one conceptual schema and one internal schema per database. The schema
also describes the way in which data elements at one level can be mapped to the corresponding
data elements in the next level.

Thus, we can say that schema establishes correspondence between the records and relationships
in the two levels. In a relational database, the schema defines the tables, the fields in each table,
and the relationships between fields and tables. Schemas are generally stored in a data dictionary.

The data in the database at any particular point in time is called a database instance. Therefore,
many database instances can correspond to the same database schema. The schema is sometimes
called the intension of the database, while an instance is called an extension (or state) of
the database.

Determining Suitability of Database Functionality and Scalability version 1.0 Year 2012 prepared By: Mezgebe M. Page
12
 New INFORMAT UNIT Database Administration Level IV
Abyssinia ION SHEET MODULE Determining Suitability of Database Functionality and Scalability
College

Example: To understand the difference between the three levels, consider again the
database schema that describes College Database system. If User1 is a Library clerk, the
external view would contain only the student and book information. If User2 is an account office
clerk then he/she may be interested in students detail and fee detail. Shows specific information
actually available at each level regarding a particular user.

The external view would depend upon the user who is accessing the database. The conceptual
level contain the logical view of the whole database, it represents the data type of each required
field. The internal view represents the physical location of each element on the disk of
the servers well as how many bytes of storage each element needs.

Mapping between Views

The DBMS is responsible for mapping between these three types of schema. Two mappings are

Determining Suitability of Database Functionality and Scalability version 1.0 Year 2012 prepared By: Mezgebe M. Page
13
 New INFORMAT UNIT Database Administration Level IV
Abyssinia ION SHEET MODULE Determining Suitability of Database Functionality and Scalability
College

required in a database system with three different views.

External/Conceptual Mapping: Each external schema is related to the conceptual schema by

the external/conceptual mapping. A mapping between the external and conceptual views gives
the correspondence among the records and the relationships of the external and conceptual views
the external view is an abstraction of the conceptual view, which in its turn is an abstraction of
the internal view. It describes the contents of the database as perceived by the user or application
program of that view. The user of the external view sees and manipulates a record corresponding
to the external view. There is a mapping from0 a particular logical record in the external view to
one (or more) conceptual record(s) in the conceptual view.

Differences between External/Conceptual views

Following could be differences that exist between the two:

Names of the field’s and. records, for instance, may be different. A number of conceptual fields
can be combined into a single external field, for example, Last_Name and First_Name at
the conceptual level but Name at the external level. A given external record could be derived
from a number of conceptual .records.

Conceptual/Internal Mapping: Conceptual schema is related to the internal schema by

the conceptual/internal mapping. This enables the DBMS to find the actual record or combination
of records in physical storage that constitute a logical record in conceptual schema.
Mapping between the conceptual and the internal levels specifies the method of deriving the
conceptual record from the physical database.

Determining Suitability of Database Functionality and Scalability version 1.0 Year 2012 prepared By: Mezgebe M. Page
14
 New INFORMAT UNIT Database Administration Level IV
Abyssinia ION SHEET MODULE Determining Suitability of Database Functionality and Scalability
College

Data Modeling / Information System Modeling/

Data: - is row fact about people, objects and events in an organization. Every information system
depends on data in order to produce information.
System developers must understand not only what kind of data a system uses but also
the structure and r/ship within the data.
Data Modeling: - is a technique for organizing and documenting a system data, r/ship b/n data
and constraints on the data.
It is sometimes called database model /information model. Its purpose is to represent data and
make the data understandable.
Data modeling compromise three components:
1. A structural part: - consisting of a set of rules according to which databases can be
constructed.

Determining Suitability of Database Functionality and Scalability version 1.0 Year 2012 prepared By: Mezgebe M. Page
15
 New INFORMAT UNIT Database Administration Level IV
Abyssinia ION SHEET MODULE Determining Suitability of Database Functionality and Scalability
College

2. A manipulative part: - define the type of operation that is allowed on the data.
3. A set of integrity rules: - ensures that the data is accurate.
A data model is the most important part of the statement for the following reasons:
 The characteristics of data captured during data modeling are crucial in the design of the
databases, programs, user interface and printed report.
 Data rather than processes are the most complex aspects of many modern
information
systems and hence require a central role in structuring system requirement.
 Characteristics of data (such as length, format, and r/ship with other data) are reasonably
permanent.

Types of data modeling

1. An external data modeling:- to represent each user’s view sometimes called the
universe of discourse
2. A conceptual data modeling
 To represent administrative view
 A model of the information used in enterprise.
 Independent of implementation details, such
as target DBMS, application programming language or any
other physical conditions.
 Also known as logical data modeling
3. An internal data model: - represent the conceptual schema in such away that it can be
understood by the DBMS.
Developing a conceptual data model
2. Conceptual data model for the system being replaced. This is essential for:
 Planning the conversion of the current files or database in to database of the new
system.
 Understanding the data requirements of the new system in depth.
• New conceptual data model
 Includes all the data requirements for the new system.
Gathering information for Data Modeling There are two approaches:

Determining Suitability of Database Functionality and Scalability version 1.0 Year 2012 prepared By: Mezgebe M. Page
16
 New INFORMAT UNIT Database Administration Level IV
Abyssinia ION SHEET MODULE Determining Suitability of Database Functionality and Scalability
College

1. Top-down approach
Drive the business rules for a data model from an intimate understanding of the nature of the
business.
2. Bottom-up approach
Gather information for data modeling by reviewing specific business documents.
Example computer displays, reports, or business forms

There are several notations for data modeling, most organizations do conceptual data
modeling using Entity r/ship diagram (E-R diagram)

Data structure
In computer science, a data structure is a particular way of storing and organizing
data in a computer so that it can be used efficiently.
Different kinds of data structures are suited to different kinds of applications, and
some are
highly specialized to specific tasks. For example, B-trees are particularly well-suited
for implementation of databases, while compiler implementations usually use hash tables
to look up identifiers.
Data structures provide a means to manage large amounts of data efficiently, such as
large
databases and internet indexing services. Usually, efficient data structures are a key to
designing efficient algorithms. Some formal design methods and programming languages
emphasize data structures, rather than algorithms, as the key organizing factor in software
design. Storing and retrieving can be carried out on data stored in both main memory and
in secondary memory.
Generating report

The market research is normally outsourced to third party agencies by organizations and in
turn they create a professional report to the organization. These reports are
preferably provided to senior officials who are the critical decision makers of the
organization. Hence these reports need to be exclusively efficient and well formatted
and the matter should be limpid, analytical and directive.
Determining Suitability of Database Functionality and Scalability version 1.0 Year 2012 prepared By: Mezgebe M. Page
17
 New INFORMAT UNIT Database Administration Level IV
Abyssinia ION SHEET MODULE Determining Suitability of Database Functionality and Scalability
College

The actual facts must be depicted clearly and it is desirable that the data and results are furnished
in graphical or tabular format which could create a substantially good impression and is
unambiguous to understand. The reports must be essentially capable to compare related
information in the report so that conclusions can be derived potentially and easily.

It is necessary for a report to contain following details to be called a good report:

1.Information collected in the report must be relevant and focused to derive desired results.
Pictorial and graphical presentation of data and related information help to understand the details
easily. There is a possibility that the collected data in the report needs to be represented
at many places in different formats to fulfill the report goals. The ultimate goal is to determine
all the issue and make suitable strategies to cope up with these issue or problems.
2.Report should follow the exact predefined goals and objectives. If there is any sort of
divergence of related information which does not match the goals then the results are of no use.
In fact there is a probability of landing up in making negative or out of focus strategies,
which will be very dangerous.
3.The report should always contain the executive summary of the work. This is generally kept
before the actual report starts as it shows the summary of the desired business plan.
4.Apart from the actual analysis the report should also depict the reasons of making this report
and what advantages and profit it can provide after successful implementation of business plans
described inside the report.
5.It should also contain the methodology of the research which shows the overall process adopted
to create the report.
6.It is important that the report contains the possibility of errors in any of the module or
process so that immediate measures could be taken to cope up with these errors.
7.The report should contain the description of the questionnaires used in analysis and the way it
has been prepared.
8.The methodology used in the interviews should also be elaborated and what was achieved
in this should also be described.
9.If the information show that some aspects needs to predict the future trends then the

Determining Suitability of Database Functionality and Scalability version 1.0 Year 2012 prepared By: Mezgebe M. Page
18
 New INFORMAT UNIT Database Administration Level IV
Abyssinia ION SHEET MODULE Determining Suitability of Database Functionality and Scalability
College

reports should depict that prediction. This prediction should have scale of success so that
the accuracy could be judged efficaciously. The report should also define each and every
variable and element used in creating these predictive analyses.
10. The report should be flexible enough to be changed accordingly. The
analytical
information described inside the report should be maintained in such a way that there is
no extra effort labored if any strategy or process it to be changed in future. It
should necessarily mood the changes without changing the structure of the report.

The analytical report creation is very important phase of market research which
acts as a blueprint of the business plan which is to be executed. By following the above
guidelines while report generation process can be efficiently taken care of.

SQL Report Writer

This section will provide a basic understanding of SQL*ReportWriter. This

document will briefly cover each main menu choice available to users of
SQL*ReportWriter. Most of the information contained in this section is
DIRECTLY extracted from ``Introduction to SQL*ReportWriter'', ``Building
Reports with SQL*ReportWriter'', and ``SQL*ReportWriter Reference Manual'' and
all credit should be given to ORACLE. If you require more detailed information
than provided in this section, consult the above stated manuals.

SQL*ReportWriter is a general purpose tool for developing and executing reports,

specially designed for application developers who know the SQL language. Information is
entered into SQL*ReportWriter through its fill-in-the-form interface. This interface allows
you to navigate quickly and easily throughout the report definiton screens.

The best way to learn SQL*ReportWriter is through hands on experience.

Elements of a Report

A SQL*ReportWriter report is made up of the following objects:

Determining Suitability of Database Functionality and Scalability version 1.0 Year 2012 prepared By: Mezgebe M. Page
19
 New INFORMAT UNIT Database Administration Level IV
Abyssinia ION SHEET MODULE Determining Suitability of Database Functionality and Scalability
College

 Queries define the data to be retrieved from the database.

 Fields represent column expressions and report calculations from SELECT
statements and describe how each is to be displayed.
 Groups contain sets of fields. Groups are used to describe each section or subsection in
the report and its relationships, as well as to dictate control breaks for subtotalling
purposes.
 Summaries are similar to fields, except they display subtotals and grandtotals rather than
data directly from a query.
 Texts contain fields, summaries, and parameter references combined with literal strings,
such as titles, and define the final report format.
 The Report object defines the page size, margins, parameter form text, comments,
security, and history of the report.
 Parameters contain literal values that you supply at runtime to control the behavior of
the report. You can vary the data, routing of the output and select national
language settings.

Every report contains at least one query, one group, and one field. Each object in a report has
a set of attributes, or ``settings'', which provides information about the object. For
example, fields have settings for Width and Display Format, among others.

Most objects are initially created by default, and, in many cases, the default settings
are sufficient. Simple forms are provided to edit the defaults and to create new
objects, such as subtotals and grandtotals.

Every SQL*ReportWriter object (except Report) is owned by another object. For

example, a group owns all of the fields within it. An object is not shared with another
object; it has one, and only one, owner.

Determining Suitability of Database Functionality and Scalability version 1.0 Year 2012 prepared By: Mezgebe M. Page
20
 New INFORMAT UNIT Database Administration Level IV
Abyssinia ION SHEET MODULE Determining Suitability of Database Functionality and Scalability
College

Report Building Process

There are a few simple steps involved in building a report:

creating a blank report

specifying the data and calculations to be used in the report
specifying the format of the report

SQL*ReportWriter separates the process of data access from report formatting, providing you
with an additional degree of freedom.

Creating a Blank Report:

In order to build reports successfully with SQL*ReportWriter, you must follow a few
simple steps. First, select the Action choice from the main menu and then select New
from the pull- down menu, and then enter a name for your report.

After you have created a blank report, it is helpful to enter a comment describing the purpose of
the report, and at the same time define your page size and margins. Select the Report choice on
the main menu to access these settings.

Specifying the Data:

The next step is to define one or more queries. Queries enable you to specify the data you plan to
use. You can access data from one or more tables residing in one or more databases. You can use
multiple queries in a report, and you can create relationships between them.

Specifying the Report Format:

Once queries are defined, you can use groups settings to specify where groups of data from your
queries should be placed in your report and/or specify control breaks (or
master/detail relationships). You can think of groups as a tool to perform ``coarse'' or overall
placement of data in your report. ``Fine tuning'' can be done using the field and text objects
described below.

The next step in building reports is to modify the fields. For each column in the database that
Determining Suitability of Database Functionality and Scalability version 1.0 Year 2012 prepared By: Mezgebe M. Page
21
 New INFORMAT UNIT Database Administration Level IV
Abyssinia ION SHEET MODULE Determining Suitability of Database Functionality and Scalability
College

you selected, a field is created. By default, each field is made up of two parts: a label and the data
of the field. You can change the default field label to any name, using any capitalization you
wish; you can change the default data format to any format you desire.

The final step that is used to build a report is to modify the text. Using the text object you can
change the positioning or appearance of the fields. You can even highlight parts of field labels.
You can also move or highlight one, or any number of fields. In the text object, you can add your
own text to appear in a report. The text that you create is called ``boilerplate text''. You
can reposition your boilerplate text, and any part(s) of it.

Determining Suitability of Database Functionality and Scalability version 1.0 Year 2012 prepared By: Mezgebe M. Page
22
 New INFORMAT UNIT Database Administration Level IV
Abyssinia ION SHEET MODULE Determining Suitability of Database Functionality and Scalability
College

Self-Check 1

 Answer the questions on the following questionnaire; provide the answer sheet to your
trainer.
 Check your answers by looking at the feedback sheets; ask for the assistance of the
trainer whenever necessary.
Questions
Satisfactory
Response
 The trainee should answer the following questions YES NO
Give short answer for the following questions
1. Explain the difference between functional and non-
functional requirement?
2.Functional Requirements should include:
3.List the three levels or layers of DBMS architecture:

The trainee’s underpinning knowledge was [ ] Satisfactory [ ] Not satisfactory

 Feedback to Trainee:

Trainee’s Signature: Date:

Instructor’s Signature: Date:

Determining Suitability of Database Functionality and Scalability version 1.0 Year 2012 prepared By: Mezgebe M. Page
23
 New INFORMAT UNIT Database Administration Level IV
Abyssinia ION SHEET MODULE Determining Suitability of Database Functionality and Scalability
College

Answer Key

1.
i.Functional Requirements - a description of the facility or feature required.
Functional requirements deal with what the system should do or provide for users.
They include description of the required functions, outlines of associated reports or
online queries, and details of data to be held in the system.
ii.Non-Functional Requirements - a description and, where possible, target values of
associated non-functional requirements. Non-functional requirements detail
constraints, targets or control mechanisms for the new system. They describe how,
how well or to what standard a function should be provided. For example,
levels of required service such as response times; security and access
requirements; technical constraints; required interfacing with users' and other
systems; and project constraints such as implementation on the organization’s
hardware/software platform. Service level requirements are measures of the quality of
service required, and are crucial to capacity planning and physical design. Identify
realistic, measurable target values for each service level. These include service
hours, service availability, responsiveness, throughput and reliability. Security
includes defining priority and frequency of backup of data, recovery, fallback
and contingency planning and access restrictions. Access restrictions should deal
with what data needs protected; what data should be restricted to a particular user
role; and level of restriction required, eg physical, password, view only. Non-
functional requirements may cover the system as a whole or relate to
specific functional requirements.

Determining Suitability of Database Functionality and Scalability version 1.0 Year 2012 prepared By: Mezgebe M. Page
24
 New INFORMAT UNIT Database Administration Level IV
Abyssinia ION SHEET MODULE Determining Suitability of Database Functionality and Scalability
College

2.
Descriptions of data to be entered into the system
Descriptions of operations performed by each screen
Descriptions of work-flows performed by the system
Descriptions of system reports or other outputs
Who can enter the data into the system.
How the system meets applicable regulatory
requirements 3.
External Level
Conceptual Level
Internal Level

Determining Suitability of Database Functionality and Scalability version 1.0 Year 2012 prepared By: Mezgebe M. Page
25
 New INFORMAT UNIT Database Administration Level IV
Abyssinia ION SHEET MODULE Determining Suitability of Database Functionality and Scalability
College

Performance Criteria

Assessment Criteria
Satisfactory
Response
The trainee will be assessed through the following criteria: YES NO
 Answered all the interview questions clearly
 Performed all activities accordingly
 Followed all instructions in the activities

Trainees’ Performance is:

[ ] Satisfactory [ ] Not Satisfactory
Feedback to Trainee:

Trainee’s Signature: Date:

Instructor’s Signature: Date:

Determining Suitability of Database Functionality and Scalability version 1.0 Year 2012 prepared By: Mezgebe M. Page
26