LEARNING GUIDE # 06

Module Title: - Determining

Suitability of Database Functionality
and Scalability

MODULE CODE: ICT DBA4 06 0411

Prepared By: Awraja M (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: Awraja M (2013)

 Sata Technology College

LO
At the end of the module the learner will be able to:
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.

Examples of Functional Requirements

Instructor: Fasil Solomon Page

18
 Sata Technology College
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.

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

Instructor: Fasil Solomon Page

18
 Sata Technology College
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
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.

Instructor: Fasil Solomon Page

18
 Sata Technology College
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.
 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).

Instructor: Fasil Solomon Page

18
 Sata Technology College
 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 been devised subsequently
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

Instructor: Fasil Solomon Page

18
 Sata Technology College
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
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.

Instructor: Fasil Solomon Page

18
 Sata Technology College
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.

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:

Instructor: Fasil Solomon Page

18
 Sata Technology College
 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.
• 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

Instructor: Fasil Solomon Page

18
 Sata Technology College
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.

• 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

Instructor: Fasil Solomon Page

18
 Sata Technology College
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;

• Record descriptions for storage (with stored sizes for data items);
• 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.

Instructor: Fasil Solomon Page

18
 Sata Technology College
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.

A schema is defined as an outline or a plan that describes the records and relationships existing
at the particular level. The External view is described by means of a schema called external
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.

Instructor: Fasil Solomon Page

18
 Sata Technology 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
required in a database system with three different views.

Instructor: Fasil Solomon Page

18
 Sata Technology College
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.

Instructor: Fasil Solomon Page

18
 Sata Technology 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.
2. A manipulative part: - define the type of operation that is allowed on the data.

Instructor: Fasil Solomon Page

18
 Sata Technology College
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
1. 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.
2. New conceptual data model
 Includes all the data requirements for the new system.
Gathering information for Data Modeling
There are two approaches:
1. Top-down approach

Instructor: Fasil Solomon Page

18
 Sata Technology College
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.

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

Instructor: Fasil Solomon Page

18
 Sata Technology College
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
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.

Instructor: Fasil Solomon Page

18
 Sata Technology College
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:

 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.

Instructor: Fasil Solomon Page

18
 Sata Technology College
 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.

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

Instructor: Fasil Solomon Page

18
 Sata Technology College
 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
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

Instructor: Fasil Solomon Page

18
 Sata Technology College
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.

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.

Instructor: Fasil Solomon Page

18
 Sata Technology College
Satisfactory
Questions
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:
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.

Instructor: Fasil Solomon Page

18
 Sata Technology College
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.

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

Instructor: Fasil Solomon Page

18
 Sata Technology College
 Internal Level

Performance Criteria

Satisfactory
Assessment Criteria
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

Instructor: Fasil Solomon Page

18
 Sata Technology College
Trainees’ Performance is:
[ ] Satisfactory [ ] Not Satisfactory

Feedback to Trainee:

Trainee’s Signature: Date:

Instructor’s Signature: Date:

Instructor: Fasil Solomon Page

18