Business analysist

ER digram
The UNION operator returns only distinct rows that appear in either result, while
the UNION ALL operator returns all rows. The UNION ALL operator does not eliminate
duplicate selected rows:
MINUS statement combines results with the MINUS operator, which returns only unique rows
returned by the first query but not by the second
SELECT product_id FROM inventories
MINUS
SELECT product_id FROM order_items;

INTERSECT operator, which returns only those rows returned by both queries
SELECT product_id FROM inventories
INTERSECT
SELECT product_id FROM order_items;

A software requirements specification (SRS) is a description of a software system to be

developed, laying out functionaland non-functional requirements, and may include a set
of use cases that describe interactions the users will have with the software.
Software requirements specification establishes the basis for an agreement between
customers and contractors or suppliers

Waterfall vs. Agile: Which is the Right Development

Methodology for Your Project?

One of the first decisions we face for each of our project

implementations at Segue is Which development methodology should
we use? This is a topic that gets a lot of discussion (and often heated
debate). If this is not something youve worked with before, a definition
of development methodology is in order; put very simply, its a way of
organizing the work of software development. To clarify further, it
is NOT a style of project management or a specific technical approach,
although you will often hear these terms all thrown together or used
interchangeably.
The two basic, most popular methodologies are :
1.

Waterfall (ugh, terrible name!), which might be more properly

called the traditional approach, and
2.
Agile (newer than Waterfall, but not that new).

Both of these are usable, mature methodologies. Having been involved

in software development projects for a long time, here are my thoughts
on the strengths and weaknesses of each.

The Waterfall Methodology

Waterfall is a linear approach to software development. In this
methodology, the sequence of events is something like:
1.
2.
3.
4.
5.
6.
7.

Gather and document requirements

Design
Code and unit test
Perform system testing
Perform user acceptance testing (UAT)
Fix any issues
Deliver the finished product
In a true Waterfall development project, each of these represents a
distinct stage of software development, and each stage generally
finishes before the next one can begin. There is also typically a stage
gate between each; for example, requirements must be reviewed and
approved by the customer before design can begin.
There are good things and bad about the Waterfall approach. On
the positive side:

Developers and customers agree on what will be delivered early in

the development lifecycle. This makes planning and designing more
straightforward.
Progress is more easily measured, as the full scope of the work is
known in advance.
Throughout the development effort, its possible for various
members of the team to be involved or to continue with other work,

depending on the active phase of the project. For example, business

analysts can learn about and document what needs to be done, while
the developers are working on other projects. Testers can prepare test
scripts from requirements documentation while coding is underway.
Except for reviews, approvals, status meetings, etc., a customer
presence is not strictly required after the requirements phase.
Because design is completed early in the development lifecycle,
this approach lends itself to projects where multiple software
components must be designed (sometimes in parallel) for integration
with external systems.
Finally, the software can be designed completely and more
carefully, based upon a more complete understanding of all software
deliverables. This provides a better software design with less likelihood
of the piecemeal effect, a development phenomenon that can occur as
pieces of code are defined and subsequently added to an application
where they may or may not fit well.
Here are some issues I have encountered using a pure Waterfall
approach:

One area which almost always falls short is the effectiveness

of requirements. Gathering and documenting requirements in a way that
is meaningful to a customer is the most difficult part of software
development, in my opinion. Customers are sometimes intimidated by
details, and specific details, provided early in the project, are required
with this approach. In addition, customers are not always able to
visualize an application from a requirements document. Wireframes and
mockups can help, but theres no question that most end users have
some difficulty putting these elements together with written requirements
to arrive at a good picture of what they will be getting.
Another potential drawback of pure Waterfall development is the
possibility that the customer will be dissatisfied with their delivered
software product. As all deliverables are based upon documented

requirements, a customer may not see what will be delivered until its
almost finished. By that time, changes can be difficult (and costly) to
implement.

The Agile Methodology

Agile is an iterative, team-based approach to development. This
approach emphasizes the rapid delivery of an application in complete
functional components. Rather than creating tasks and schedules, all
time is time-boxed into phases called sprints. Each sprint has a
defined duration (usually in weeks) with a running list of deliverables,
planned one sprint in advance. Deliverables are prioritized by business
value as determined by the customer. If all planned work for the sprint
cannot be completed, work is reprioritized and the information is used
for future sprint planning.
As work is completed during each sprint, it is continuously reviewed and
evaluated by the customer, who may be considered the most critical
member of the Agile team. As a result, Agile relies on a very high level
of customer involvement throughout the project.
Some advantages of the Agile approach are easy to see:

The customer has frequent and early opportunities to see the

work being delivered, and to make decisions and changes throughout
the development project.
The customer gains a strong sense of ownership by working
extensively and directly with the project team throughout the project.
If time to market for a specific application is a concern, Agile can
more quickly produce a basic version of working software.
Development is often more user-focused, likely a result of more
and frequent direction from the customer.

For more Agile Development benefits, please see 8 Benefits of

Agile Software Development
And, of course, there are some disadvantages:

The very high degree of customer involvement, while great for the
project, may present problems for some customers who simply may not
have the time or interest for this type of participation.
Agile works best when members of the development team are
completely dedicated to the project.
Because Agile focuses on time-boxed delivery and frequent
reprioritization, its possible that some items set for delivery will not be
completed within the allotted timeframe. Additional sprints (beyond
those initially planned) may be needed, adding to the project cost. In
addition, customer involvement often leads to additional features
requested throughout the project. Again, this can add to the overall time
and cost of the implementation.
The close working relationships in an Agile project are easiest to
manage when the team members are located in the same physical
space, which is not always possible. However, there are a variety of
ways to handle this issue, such as webcams, collaboration tools, etc.
The iterative nature of Agile development may lead to a reduction
in overall system quality, as there is less emphasis on understanding the
finished system as a whole early in the project. This becomes more
pronounced in larger-scale implementations, or with systems that
include a high level of integration.

Making the Choice Between Agile and

Waterfall
So, how do we choose? First, we change the game a little (which is
what most software development organizations do) by defining our own

process. At Segue, its called our Process Framework, and its a

variation on the traditional Waterfall methodology. Our modifications
include use of prototyping where possible to provide the customer a
better view of their finished product early in the design/development
cycle. This helps to improve the teams understanding of requirements
and communication with the customer. After the primary framework of
the application is completed per high level requirements, we continue to
develop and also to reach out to the customer for refinement of
requirements. In this way, we strive to be as iterative as possible without
compromising our overall system architecture.
We consider the following factors when considering which methodology
to use:

Different Maximum Sizes

The SQL data types listed in Table 3-1 have different maximum sizes in PL/SQL and SQL.
Table 3-1 Data Types with Different Maximum Sizes in PL/SQL and SQL

Data Type

Maximum Size in
PL/SQL

Maximum Size in SQL

CHARFoot 1

32,767 bytes

2,000 bytes

NCHARFootref 1

32,767 bytes

2,000 bytes

RAWFootref 1

32,767 bytes

2,000 bytes

VARCHAR2Footref 1

32,767 bytes

4,000 bytes

NVARCHAR2Footref 1

32,767 bytes

4,000 bytes

LONGFoot 2

32,760 bytes

2 gigabytes (GB) - 1

LONG RAWFootref 2

32,760 bytes

2 GB

BLOB

128 terabytes (TB)

(4 GB - 1)
* database_block_size

CLOB

128 TB

(4 GB - 1)
* database_block_size

NCLOB

128 TB

(4 GB - 1)
* database_block_size

Datatype

Description

Max Size:
Oracle 8

Max Size:
Oracle 9i/10g

4000 bytes
Variable length character string
4000 bytes
VARCHAR2
having maximum length size bytes. minimum is
(size)
minimum is 1
You must specify size
1

4000 bytes
minimum is 1

NVARCHA

4000 bytes

Variable length national character

4000 bytes

4000 bytes

R2(size)

set string having maximum

lengthsize bytes.
You must specify size

minimum is
minimum is 1
1

minimum is 1

VARCHAR

Now deprecated (provided for

backward compatibility only)
VARCHAR is a synonym for
VARCHAR2 but this usage may
change in future versions.

2000 bytes
Fixed length character data of length
Default and
size bytes. This should be used for
CHAR(size)
minimum
fixed length data. Such as codes
size is 1
A100, B102
byte.

2000 bytes
2000 bytes
Default and
minimum size is Default and minim
1 byte.

2000 bytes
Fixed length national character set
Default and
NCHAR(siz data of length size bytes. This
minimum
e)
should be used for fixed length data.
size is 1
Such as codes A100, B102
byte.

2000 bytes
Default and
2000 bytes
minimum size is Default and minim
1 byte.

NUMBER(p Number having precision p and

,s)
scale s.

The
The precision p The precision p c
precision p can range from
can range
1 to 38.
The scale s can r
from 1 to 38.
The scale s can
The scale s range from -84
can range
to 127.
from -84 to
127.

A 32-bit, single-precision floatingpoint number data type. Each

BINARY_FL
BINARY_FLOAT value requires 4
OAT
bytes. Supports the special values
infinity and NaN (not a number).

BINARY_D
OUBLE

BOOLEAN

A 64-bit, double-precision floatingpoint number data type. Each

BINARY_DOUBLE value requires 8 bytes. Supports the special values
infinity and NaN (not a number).

True, False or NULL

n/a
Use either
Number or
CHAR

Magnitude:
Magnitude:
1.17549E-38F
1.17549E-38F

3.40282E+38F
3.40282E+38F
Magnitude:
2.22507485850
720E-308

1.79769313486
231E+308

Magnitude:
2.225074858507

1.797693134862

n/a
Use either
Number or
CHAR

n/a
Use either Numb

signed integers
PLS_INTEG PLS_INTEGER values require less
PL/SQL only PL/SQL only
ER
storage and provide better
performance than NUMBER values.

BINARY_IN signed integers (older slower version

TEGER
of PLS_INTEGER)

PL/SQL only

LONG

DATE

2 Gigabytes but now

Character data of variable length (A
deprecated
bigger version the VARCHAR2
2 Gigabytes (provided for
datatype)
backward
compatibility
only).

Valid date range

2 Gigabytes - but
backward compa

from January from January 1,

1, 4712 BC 4712 BC to
from January 1, 4
to December December
31, 9999 AD.
31, 9999AD. 31, 9999 AD.

TIMESTAM
P
the number of digits in the fractional
(fractional_
part of the SECOND datetime field.
seconds_pr
ecision)

Accepted values
offractional_sec Accepted values
onds_precisiona offractional_seco
(default = 6)
re 0 to 9.
(default = 6)

TIMESTAM
P
(fractional_
seconds_pr As above with time zone
ecision)
displacement value
WITH
{LOCAL}
TIMEZONE

Accepted values
offractional_sec Accepted values
onds_precisiona offractional_seco
re 0 to 9.
(default = 6)
(default = 6)

Time in years and months,

whereyear_precision is the number of digits in the YEAR datetime field.

Accepted values
are 0 to 9.
Accepted values
(default = 2)

INTERVAL
YEAR
(year_preci
sion) TO
MONTH

INTERVAL Time in days, hours, minutes, and

DAY
seconds.
(day_precisi

day_precision m day_precision ma
ay be 0 to 9.
fractional_second
(default = 2)

day_precision is the maximum

on) TO
number of digits in 'DAY'
SECOND
(fractional_
fractional_seconds_precision is the
seconds_pr
max number of fractional digits in the
ecision)
SECOND field.
RAW(size)

fractional_seco
nds_precisionm
(default = 6)
ay be 0 to 9.
(default = 6)

Raw binary data of length size bytes. Maximum

Maximum size
size
You must specify size for a RAW
is 2000 bytes
is2000 bytes
value.
2 Gigabytes but now
deprecated
2 Gigabytes. (provided for
backward
compatibility
only)

LONG RAW

Raw binary data of variable length.

(not intrepreted by PL/SQL)

ROWID

Hexadecimal string representing the

unique address of a row in its table.
10 bytes
(primarily for values returned by the
ROWID pseudocolumn.)

UROWID

Hex string representing the logical

address of a row of an indexorganized table

The
maximum
size and
default is
4000 bytes

10 bytes

Maximum size is

2 Gigabytes - but
backward compa

10 bytes

The maximum
size and default The maximum siz
is 4000 bytes

Binary format of an operating system

MLSLABEL label.This datatype is used with
Trusted Oracle7.
CLOB

NCLOB

BLOB

Character Large Object

National Character Large Object

Binary Large Object

4 Gigabytes

4 Gigabytes

4 Gigabytes

BFILE

pointer to binary file on disk

4 Gigabytes

XMLType

A system-defined type for storing

binary XML data stored internally as
a CLOB (starting with 11gR1 stored
as a BLOB)

8 TB to 128 TB
8 TB

(4 Gigabytes - 1)
8 TB to 128 TB

8 TB

(4 Gigabytes - 1)
8 TB to 128 TB

8 TB

(4 Gigabytes - 1)
8 TB to 128 TB

8 TB

64K

(4 Gigabytes - 1)

In 11gR1 the limi

character set.