Module Title: - Determining Suitability of Database Functionality and Scalability

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

Introduction to the module

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

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

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

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.

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

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:

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

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.

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.

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.

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