Database Concepts

Join (SQL)
SQL JOIN clause combines records from two tables in a relational database, resulting in a new, temporary
table, sometimes called a "joined table". A JOIN may also be thought of as a SQL operation that relates
tables by means of values common between them. SQL specifies four types of JOIN: INNER, OUTER, LEFT,
and RIGHT. In special cases, a table (base table, view, or joined table) can JOIN to itself in a self-join.
A programmer writes a JOIN predicate to identify the records for joining. If the predicate evaluates
positively, the combined record is inserted into the temporary (or "joined") table. Any predicate supported
by SQL can become a JOIN-predicate, for example, WHERE-clauses.

Sample tables
Department Table
DepartmentID DepartmentName
31 Sales
33 Engineering
4 Clerical
35 Marketing

 Inner join
An inner join requires each record in the two joined tables to have a matching record. An inner join
essentially combines the records from two tables (A and B) based on a given join-predicate. The result of
the join can be defined as the outcome of first taking the Cartesian product (or cross-join) of all records in
the tables (combining every record in table A with every record in table B) - then return all records which
satisfy the join predicate. Actual SQL implementations will normally use other approaches where possible,
since computing the Cartesian product is not very efficient. This type of join occurs most commonly in
applications, and represents the default join-type.
SQL:2003 specifies two different syntactical ways to express joins. The first, called "explicit join notation",
uses the keyword JOIN, whereas the second uses the "implicit join notation". The implicit join notation lists
the tables for joining in the FROM clause of a SELECT statement, using commas to separate them. Thus, it
specifies a cross-join, and the WHERE clause may apply additional filter-predicates. Those filter-predicates
function comparably to join-predicates in the explicit notation.
One can further classify inner joins as equi-joins, as natural joins, or as cross-joins (see below).
Programmers should take special care when joining tables on columns that can contain NULL values, since
NULL will never match any other value (or even NULL itself), unless the join condition explicitly uses the IS
NULL or IS NOT NULL predicates.
As an example, the following query takes all the records from the Employee table and finds the matching
record(s) in the Department table, based on the join predicate. The join predicate compares the values in
the DepartmentID column in both tables. If it finds no match (i.e., the department-id of an employee does
not match the current department-id from the Department table), then the joined record remains outside
the joined table, i.e., outside the (intermediate) result of the join.
Example of an explicit inner join:

SELECT * FROM employee INNER JOIN department ON employee.DepartmentID =

department.DepartmentID
Is equivalent to:
1
SELECT * FROM employee, department WHERE employee.DepartmentID =
department.DepartmentID

Explicit Inner join result:

Employee.LastName Employee.DepartmentID Department.DepartmentName Department.DepartmentID
Smith 34 Clerical 34
Jones 33 Engineering 33
Robinson 34 Clerical 34
Steinberg 33 Engineering 33
Rafferty 31 Sales 31
Notice that the employee "Jasper" and the department "Marketing" do not appear. Neither of these has
any matching records in the respective other table: "Jasper" has no associated department and no
employee has the department ID 35. Thus, no information on Jasper or on Marketing appears in the joined
table. Depending on the desired results, this behavior may be a subtle bug. Outer joins may be used to
avoid it.

 Types of inner joins

o Natural join
A natural join offers a further specialization of equi-joins. The join predicate arises implicitly by comparing
all columns in both tables that have the same column-name in the joined tables. The resulting joined table
contains only one column for each pair of equally-named columns.
The above sample query for inner joins can be expressed as a natural join in the following way:

SELECT * FROM employee NATURAL JOIN department;

DepartmentID Employee.LastName Department.DepartmentName

34 Smith Clerical
33 Jones Engineering
34 Robinson Clerical
33 Steinberg Engineering
31 Rafferty Sales

Using the NATURAL JOIN keyword to express joins can suffer from ambiguity at best, and could, in the case
of poor coding or design, leave systems open to problems if schema changes occur in the database. For
example, the removal, addition, or renaming of columns changes the semantics of a natural join. Thus, the
safer approach involves explicitly coding the join-condition using a regular inner join, but such problems
are likely to show in the cases of poor design.
The Oracle database implementation of SQL selects the appropriate column in the naturally-joined table
from which to gather data. An error-message such as "ORA-25155: column used in NATURAL join cannot
have qualifier" is an error to help prevent or reduce the problems that could occur may encourage
checking and precise specification of the columns named in the query, and can also help in providing
compile time checking (instead of errors in query).

o Cross join
A cross join, cartesian join or product provides the foundation upon which all types of inner joins operate.
A cross join returns the cartesian product of the sets of records from the two joined tables. Thus, it equates
to an inner join where the join-condition always evaluates to True or join-condition is absent in statement.
If A and B are two sets, then the cross join is written as A × B.The SQL code for a cross join lists the tables
for joining (FROM), but does not include any filtering join-predicate.
2
Example of an explicit cross join:
SELECT * FROM employee CROSS JOIN department
Example of an implicit cross join:
SELECT * FROM employee, department;

Employee.LastName Employee.DepartmentID Department.DepartmentName Department.DepartmentID

Rafferty 31 Sales 31
Jones 33 Sales 31
Steinberg 33 Sales 31
Smith 34 Sales 31
Robinson 34 Sales 31
Jasper NULL Sales 31
Rafferty 31 Engineering 33
Jones 33 Engineering 33
Steinberg 33 Engineering 33
Smith 34 Engineering 33
Robinson 34 Engineering 33
Jasper NULL Engineering 33
Rafferty 31 Clerical 34
Jones 33 Clerical 34
Steinberg 33 Clerical 34
Smith 34 Clerical 34
Robinson 34 Clerical 34
Jasper NULL Clerical 34
Rafferty 31 Marketing 35
Jones 33 Marketing 35
Steinberg 33 Marketing 35
Smith 34 Marketing 35
Robinson 34 Marketing 35
Jasper NULL Marketing 35
The cross join does not apply any predicate to filter records from the joined table. Programmers can
further filter the results of a cross join by using a WHERE clause.

 Outer joins
An outer join does not require each record in the two joined tables to have a matching record. The joined
table retains each record—even if no other matching record exists. Outer joins subdivide further into left
outer joins, right outer joins, and full outer joins, depending on which table(s) one retains the rows from
(left, right, or both). ** No implicit join-notation for outer joins exists in SQL:2003.

o Left outer join

The result of a left outer join (or simply left join) for tables A and B always contains all records of the "left"
table (A), even if the join-condition does not find any matching record in the "right" table (B). This means
that if the ON clause matches 0 (zero) records in B, the join will still return a row in the result—but with
NULL in each column from B. This means that a left outer join returns all the values from the left table, plus
matched values from the right table (or NULL in case of no matching join predicate).
3
For example, this allows us to find an employee's department, but still to show the employee even when
their department does not exist (contrary to the inner-join example above, where employees in non-
existent departments are excluded from the result).
Example of a left outer join, with the additional result row italicized:

SELECT * FROM employee LEFT OUTER JOIN department ON employee.DepartmentID =

department.DepartmentID

Employee.LastName Employee.DepartmentID Department.DepartmentName Department.DepartmentID

Jones 33 Engineering 33
Rafferty 31 Sales 31
Robinson 34 Clerical 34
Smith 34 Clerical 34
Jasper NULL NULL NULL
Steinberg 33 Engineering 33

o Right outer join

A right outer join (or right join) closely resembles a left outer join, except with the tables reversed. Every
record from the "right" table (B) will appear in the joined table at least once. If no matching row from the
"left" table (A) exists, NULL will appear in columns from A for those records that have no match in A.
A right outer join returns all the values from the right table and matched values from the left table (NULL in
case of no matching join predicate).
For example, this allows us to find each employee and their department, but still show departments that
have no employees.

Example right outer join, with the additional result row italicized:
SELECT * FROM employee RIGHT OUTER JOIN department ON employee.DepartmentID =
department.DepartmentID

Employee.LastName Employee.DepartmentID Department.DepartmentName Department.DepartmentID

Smith 34 Clerical 34
Jones 33 Engineering 33
Robinson 34 Clerical 34
Steinberg 33 Engineering 33
Rafferty 31 Sales 31
NULL NULL Marketing 35

o Full outer join

A full outer join combines the results of both left and right outer joins. The joined table will contain all
records from both tables, and fill in NULLs for missing matches on either side.
For example, this allows us to see each employee who is in a department and each department that has an
employee, but also see each employee who is not part of a department and each department who doesn't
have an employee.
Example full outer join:
SELECT * FROM employee FULL OUTER JOIN department ON employee.DepartmentID =
department.DepartmentID

4
Employee.LastName Employee.DepartmentID Department.DepartmentName Department.DepartmentID
Smith 34 Clerical 34
Jones 33 Engineering 33
Robinson 34 Clerical 34
Jasper NULL NULL NULL
Steinberg 33 Engineering 33
Rafferty 31 Sales 31
NULL NULL Marketing 35

Some database systems like db2 (version 2 and before) do not support this functionality directly, but they
can emulate it through the use of left and right outer joins and unions. The same example can appear as
follows:
SELECT * FROM employee LEFT JOIN department ON employee.DepartmentID =
department.DepartmentID
UNION
SELECT *FROM employee RIGHT JOIN department ON employee.DepartmentID =
department.DepartmentID WHERE employee.DepartmentID IS NULL

or:
SELECT * FROM employee LEFT JOIN department ON employee.DepartmentID =
department.DepartmentID
UNION
SELECT * FROM department LEFT JOIN employee ON employee.DepartmentID =
department.DepartmentID WHERE employee.DepartmentID IS NULL

or :
SELECT * FROM department RIGHT JOIN employee ON employee.DepartmentID =
department.DepartmentID
UNION
SELECT * FROM employee RIGHT JOIN department ON employee.DepartmentID =
department.DepartmentID WHERE employee.DepartmentID IS NULL

Note: UNION=UNION ALL in above examples

 Self-join
A self-join is joining a table to itself.[1] This is best illustrated by the following example.

Example
A query to find all pairings of two employees in the same country is desired. If you had two separate tables
for employees and a query which requested employees in the first table having the same country as
employees in the second table, you could use a normal join operation to find the answer table. However,
all the employee information is contained within a single large table. [2]
Considering a modified Employee table such as the following:

5
Employee Table
EmployeeID LastName Country DepartmentID
123 Rafferty Australia 31
124 Jones Australia 33
145 Steinberg Australia 33
201 Robinson United States 34
305 Smith United Kingdom 34
306 Jasper United Kingdom NULL

An example solution query could be as follows:

SELECT F.EmployeeID, F.LastName, S.EmployeeID, S.LastName, F.Country

FROM Employee F, Employee S
WHERE F.Country = S.Country
AND F.EmployeeID < S.EmployeeID
ORDER BY F.EmployeeID, S.EmployeeID;
Which results in the following table being generated.
Employee Table after Self-join by Country
EmployeeID LastName EmployeeID LastName Country
123 Rafferty 124 Jones Australia
123 Rafferty 145 Steinberg Australia
124 Jones 145 Steinberg Australia
305 Smith 306 Jasper United Kingdom

For this example, note that:

F and S are aliases for the first and second copies of the employee table.
The condition F.Country = S.Country excludes pairings between employees in different countries. The
example question only wanted pairs of employees in the same country.
The condition F.EmployeeID < S.EmployeeID excludes pairings where the EmployeeIDs are the same.
F.EmployeeID < S.EmployeeID also excludes duplicate pairings. Without it only the following less useful
part of the table would be generated (for the United Kingdom only shown):
EmployeeID LastName EmployeeID LastName Country
305 Smith 305 Smith United Kingdom
305 Smith 306 Jasper United Kingdom
306 Jasper 305 Smith United Kingdom
306 Jasper 306 Jasper United Kingdom

Only one of the two middle pairings is needed to satisfy the original question, and the topmost and
bottommost are of no interest at all in this example.

 UNION & UNION ALL

SELECT * FROM sales2005 UNION SELECT * FROM sales2006;

person amount ** Remove all duplicate record which has same row values
Joe 1000 in both the tables .
Alex 2000
Bob 5000
Joe 2000
6
Zach 35000
SELECT * FROM sales2005 UNION ALL SELECT * FROM sales2006;

person amount ** Include all record from both the tables .

Joe 1000
Joe 2000
Alex 2000
Alex 2000
Bob 5000
Zach 35000

 EXCEPT

The following example EXCEPT query returns all rows from the Order table where Quantity is between 1 and
49, and those with a Quantity between 76 and 100.

SELECT * FROM ORDER WHERE Quantity BETWEEN 1 AND 100

EXCEPT

SELECT * FROM ORDER WHERE Quantity BETWEEN 50 AND 75;

 INTERSECT operator
The SQL INTERSECT operator takes the results of two queries and returns only rows that appear in both
result sets. For purposes of duplicate removal the INTERSECT operator does not distinguish between NULLs.
The INTERSECT operator removes duplicate rows from the final result set. The INTERSECT ALL operator
does not remove duplicate rows from the final result set.

Example

The following example INTERSECT query returns all rows from the Order table where Quantity is between
50 and 100.

SELECT * FROM ORDER WHERE Qty BETWEEN 1 AND 100

INTERSECT

SELECT * FROM ORDER WHERE Quantity BETWEEN 50 AND 200;

 Database Trigger
A database trigger is procedural code that is automatically executed in response to certain events on a
particular table in a database. Triggers can restrict access to specific data, perform logging, or audit data
modifications.

7
There are two classes of triggers, they are either "row triggers" or "statement triggers". Row triggers define
an action for every row of a table, while statement triggers occur only once per INSERT, UPDATE, or
DELETE statement. Triggers cannot be used to audit data retrieval via SELECT statements.

Each class can be of several types. There are "BEFORE triggers" and "AFTER triggers" which identifies the
time of execution of the trigger. There is also an "INSTEAD OF trigger" which is a trigger that will execute
instead of the triggering statement.

 After Creation , Before Alter , After Alter, Before Drop, After Drop
 Before Logoff , After Logon ORACLE 9i onwords

 CURSOR

In database packages, a cursor is a control structure for the successive traversal (and potential processing)
of records in a result set.

A cursor is used for processing individual rows returned by the database system for a query. It is necessary
because many programming languages suffer from impedance mismatch. Programming languages are often
procedural and do not offer any mechanism for manipulating whole result sets at once. Therefore, the rows
in a result set must be processed sequentially by the application. In this way, a cursor can be thought of as an
iterator over the collection of rows in the result set.

Several SQL statements do not require the use of cursors. That includes the INSERT statement, for example,
as well as most forms of the DELETE and UPDATE statements. Even a SELECT statement may not
involve a cursor if it is used in the variation of SELECT INTO. A SELECT INTO retrieves at most a single row
directly into the application

1 DECLARE cursor_name CURSOR FOR SELECT ... FROM ...

2 OPEN cursor_name , 3 FETCH cursor_name INTO ...

4 CLOSE cursor_name

 Stored Procedures
 Features
Statements can be stored in the database, together with the procedure. This can remove the compilation
overhead that is typically required in situations where software applications send inline SQL queries to a
database. However, most database systems implement statement caches to avoid repetitive compilation of
dynamic SQL statements.

In addition, pre-compiled SQL statements, while avoiding some overhead, add to the complexity of creating
an optimal execution plan because not all arguments of the SQL statement are supplied at compile time.
Depending on the specific database implementation and configuration, mixed performance results will be
seen from stored procedures versus generic queries or user defined functions.

Execution on a database server

Stored procedures can run directly within the database engine. In a production system, this typically means
that the procedures run entirely on a specialized database server, which has direct access to the data being
accessed. The benefit here is that network communication costs can be avoided completely. This becomes
particularly important for complex series of SQL statements.

8
However, note that unnecessary or excessive procedural statement execution in the database server
(typically a singular shared resource) may impair overall enterprise system performance - i.e., while
application servers can often be dramatically scaled horizontally for increased processing capacity, the same
is not generally or as easily accomplished for database servers.

Therefore, a growing school of thought advocates the database be used for what it's best at - i.e., a very
efficient file cabinet. Thereby restricting any database-local procedural executions to only very specific
cases rather than the old school ubiquity - instead advocating the use of advanced object oriented domain
class ontologies and reusable parameterized SQL generation.

Security

Carefully written stored procedures may allow for fine grained security permissions to be applied to a
database. For example, client programs might be restricted from accessing the database via any means
except those that are provided by the available stored procedures. This allows the client program to access
the database system as a non-privileged, or restricted user, whereby preserving role based access and
achieving more complete abstraction of application code from database code.

 Truncate (SQL)
o Immediately remove all records from table.
o save resources .
o Never recoverable.
Ex
Truncate table xyz where xyz_id=25;

 ACID (Atomicity, Consistency, Isolation, Durability)

Atomicity
Atomicity refers to the ability of the DBMS to guarantee that either all of the tasks of a transaction are
performed or none of them are. For example, the transfer of funds can be completed or it can fail for a
multitude of reasons, but atomicity guarantees that one account won't be debited if the other is not credited.
Atomicity states that database modifications must follow an “all or nothing” rule. Each transaction is said to
be “atomic.” If one part of the transaction fails, the entire transaction fails. It is critical that the database
management system maintain the atomic nature of transactions in spite of any DBMS, operating system or
hardware failure. Atomicity is obtained when an attribute can no longer be broken down any further.

Consistency
The Consistency property ensures that the database remains in a consistent state before the start of the
transaction and after the transaction is over (whether successful or not).

Consistency states that only valid data will be written to the database. If, for some reason, a transaction is
executed that violates the database’s consistency rules, the entire transaction will be rolled back and the
database will be restored to a state consistent with those rules. On the other hand, if a transaction
successfully executes, it will take the database from one state that is consistent with the rules to another state
that is also consistent with the rules.

Isolation
9
Isolation refers to the requirement that other operations cannot access or see the data in an intermediate state
during a transaction. This constraint is required to maintain the performance as well as the consistency
between transactions in a DBMS system.

Durability
Durability refers to the guarantee that once the user has been notified of success, the transaction will persist,
and not be undone. This means it will survive system failure, and that the database system has checked the
integrity constraints and won't need to abort the transaction. Many databases implement durability by
writing all transactions into a log that can be played back to recreate the system state right before a failure. A
transaction can only be deemed committed after it is safely in the log.

Create, read, update and delete(CRUD property)

Operation SQL
Create INSERT
Read (Retrieve) SELECT
Update UPDATE
Delete (Destroy) DELETE

 A superkey is a set of columns within a table whose values can be used to uniquely identify a row.
 A candidate key is a minimal set of columns necessary to identify a row, this is also called a
minimal superkey.

 A surrogate key in a database is a unique identifier for either an entity in the modeled world or an
object in the database. The surrogate key is not derived from application data (generated by db tools) like
AUTO_INCREMENT.

NORMAL FORMS
First Normal Form (1NF) sets the very basic rules for an organized database:

 Eliminate duplicative columns from the same table.

 Create separate tables for each group of related data and identify each row with a unique column (the
primary key).

Over the past month, we've looked at several aspects of normalizing a database table. First, we discussed the
basic principles of database normalization. Last time, we explored the basic requirements laid down by the
first normal form (1NF). Now, let's continue our journey and cover the principles of second normal form
(2NF).

Second normal form (2NF)

Recall the general requirements of 2NF:
 Remove subsets of data that apply to multiple rows of a table and place them in separate tables.
 Create relationships between these new tables and their predecessors through the use of foreign keys.

Third Normal Form (3NF)

10
There are two basic requirements for a database to be in third normal form:

 Already meet the requirements of both 1NF and 2NF

 Remove columns that are not fully dependent upon the primary key.

For Ex : we don’t need column like total to store total student marks.

Testing types
Software Testing Types:

Black box testing - Internal system design is not considered in this type of testing. Tests are based on
requirements and functionality.

White box testing - This testing is based on knowledge of the internal logic of an application’s code. Also
known as Glass box Testing. Internal software and code working should be known for this type of testing.
Tests are based on coverage of code statements, branches, paths, conditions.

Unit testing - Testing of individual software components or modules. Typically done by the programmer
and not by testers, as it requires detailed knowledge of the internal program design and code. may require
developing test driver modules or test harnesses.

Incremental integration testing - Bottom up approach for testing i.e continuous testing of an application as
new functionality is added; Application functionality and modules should be independent enough to test
separately. done by programmers or by testers.

Integration testing - Testing of integrated modules to verify combined functionality after integration.
Modules are typically code modules, individual applications, client and server applications on a network,
etc. This type of testing is especially relevant to client/server and distributed systems.

Functional testing - This type of testing ignores the internal parts and focus on the output is as per
requirement or not. Black-box type testing geared to functional requirements of an application.

System testing - Entire system is tested as per the requirements. Black-box type testing that is based on
overall requirements specifications, covers all combined parts of a system.

End-to-end testing - Similar to system testing, involves testing of a complete application environment in a
situation that mimics real-world use, such as interacting with a database, using network communications, or
interacting with other hardware, applications, or systems if appropriate.

Sanity testing - Testing to determine if a new software version is performing well enough to accept it for a
major testing effort. If application is crashing for initial use then system is not stable enough for further
testing and build or application is assigned to fix.

Regression testing - Testing the application as a whole for the modification in any module or functionality.
Difficult to cover all the system in regression testing so typically automation tools are used for these testing
types.

Acceptance testing -Normally this type of testing is done to verify if system meets the customer specified
requirements. User or customer do this testing to determine whether to accept application.

11
Load testing - Its a performance testing to check system behavior under load. Testing an application under
heavy loads, such as testing of a web site under a range of loads to determine at what point the system’s
response time degrades or fails.

Stress testing - System is stressed beyond its specifications to check how and when it fails. Performed under
heavy load like putting large number beyond storage capacity, complex database queries, continuous input
to system or database load.

Performance testing - Term often used interchangeably with ’stress’ and ‘load’ testing. To check whether
system meets performance requirements. Used different performance and load tools to do this.

Usability testing - User-friendliness check. Application flow is tested, Can new user understand the
application easily, Proper help documented whenever user stuck at any point. Basically system navigation is
checked in this testing.

Install/uninstall testing - Tested for full, partial, or upgrade install/uninstall processes on different
operating systems under different hardware, software environment.

Recovery testing - Testing how well a system recovers from crashes, hardware failures, or other
catastrophic problems.

Security testing - Can system be penetrated by any hacking way. Testing how well the system protects
against unauthorized internal or external access. Checked if system, database is safe from external attacks.

Compatibility testing - Testing how well software performs in a particular hardware/software/operating

system/network environment and different combination s of above.

Comparison testing - Comparison of product strengths and weaknesses with previous versions or other
similar products.

Alpha testing - In house virtual user environment can be created for this type of testing. Testing is done at
the end of development. Still minor design changes may be made as a result of such testing.

Beta testing - Testing typically done by end-users or others. Final testing before releasing application for
commercial purpose.

Grey Box Testing

In recent years the term grey box testing has come into common usage. This involves having access to
internal data structures and algorithms for purposes of designing the test cases, but testing at the user, or
black-box level.

Manipulating input data and formatting output do not qualify as grey-box because the input and output are
clearly outside of the black-box we are calling the software under test. This is particularly important when
conducting integration testing between two modules of code written by two different developers, where only
the interfaces are exposed for test. Grey box testing may also include reverse engineering to determine, for
instance, boundary values or error messages.

Testing process
A common practice of software testing is performed by an independent group of testers after the
functionality is developed before it is shipped to the customer.[20] This practice often results in the testing
phase being used as project buffer to compensate for project delays, thereby compromising the time devoted
12
to testing.[21] Another practice is to start software testing at the same moment the project starts and it is a
continuous process until the project finishes.[22]

In counterpoint, some emerging software disciplines such as extreme programming and the agile software
development movement, adhere to a "test-driven software development" model. In this process unit tests are
written first, by the software engineers (often with pair programming in the extreme programming
methodology). Of course these tests fail initially; as they are expected to. Then as code is written it passes
incrementally larger portions of the test suites. The test suites are continuously updated as new failure
conditions and corner cases are discovered, and they are integrated with any regression tests that are
developed. Unit tests are maintained along with the rest of the software source code and generally integrated
into the build process (with inherently interactive tests being relegated to a partially manual build acceptance
process).

Testing can be done on the following levels:

 Unit testing tests the minimal software component, or module. Each unit (basic component) of the
software is tested to verify that the detailed design for the unit has been correctly implemented. In an
object-oriented environment, this is usually at the class level, and the minimal unit tests include the
constructors and destructors.[23]
 Integration testing exposes defects in the interfaces and interaction between integrated components
(modules). Progressively larger groups of tested software components corresponding to elements of
the architectural design are integrated and tested until the software works as a system. [24]
 System testing tests a completely integrated system to verify that it meets its requirements. [25]
 System integration testing verifies that a system is integrated to any external or third party systems
defined in the system requirements.[citation needed]

Before shipping the final version of software, alpha and beta testing are often done additionally:

 Alpha testing is simulated or actual operational testing by potential users/customers or an

independent test team at the developers' site. Alpha testing is often employed for off-the-shelf
software as a form of internal acceptance testing, before the software goes to beta testing. [citation needed]
 Beta testing comes after alpha testing. Versions of the software, known as beta versions, are released
to a limited audience outside of the programming team. The software is released to groups of people
so that further testing can ensure the product has few faults or bugs. Sometimes, beta versions are
made available to the open public to increase the feedback field to a maximal number of future users.
[citation needed]

Finally, acceptance testing can be conducted by the end-user, customer, or client to validate whether or not
to accept the product. Acceptance testing may be performed as part of the hand-off process between any two
phases of development.[citation needed]

Regression testing

After modifying software, either for a change in functionality or to fix defects, a regression test re-runs
previously passing tests on the modified software to ensure that the modifications haven't unintentionally
caused a regression of previous functionality. Regression testing can be performed at any or all of the above
test levels. These regression tests are often automated.

13
 NEWORKING
LAN - Local Area Network

A LAN connects network devices over a relatively short distance. A networked office building, school, or
home usually contains a single LAN, though sometimes one building will contain a few small LANs
(perhaps one per room), and occasionally a LAN will span a group of nearby buildings. In TCP/IP
networking, a LAN is often but not always implemented as a single IP subnet.

In addition to operating in a limited space, LANs are also typically owned, controlled, and managed by a
single person or organization. They also tend to use certain connectivity technologies, primarily Ethernet
and Token Ring.

WAN - Wide Area Network

As the term implies, a WAN spans a large physical distance. The Internet is the largest WAN, spanning the
Earth.

A WAN is a geographically-dispersed collection of LANs. A network device called a router connects LANs
to a WAN. In IP networking, the router maintains both a LAN address and a WAN address.

A WAN differs from a LAN in several important ways. Most WANs (like the Internet) are not owned by
any one organization but rather exist under collective or distributed ownership and management. WANs
tend to use technology like ATM, Frame Relay and X.25 for connectivity over the longer distances.

LAN, WAN and Home Networking

Residences typically employ one LAN and connect to the Internet WAN via an Internet Service Provider
(ISP) using a broadband modem. The ISP provides a WAN IP address to the modem, and all of the
computers on the home network use LAN (so-called private) IP addresses. All computers on the home LAN
can communicate directly with each other but must go through a central gateway, typically a broadband
router, to reach the ISP.

Other Types of Area Networks

While LAN and WAN are by far the most popular network types mentioned, you may also commonly see
references to these others:
 Wireless Local Area Network - a LAN based on WiFi wireless network technology
 Metropolitan Area Network - a network spanning a physical area larger than a LAN but smaller
than a WAN, such as a city. A MAN is typically owned an operated by a single entity such as a
government body or large corporation.
 Campus Area Network - a network spanning multiple LANs but smaller than a MAN, such as on a
university or local business campus.
 Storage Area Network - connects servers to data storage devices through a technology like Fibre
Channel.
 System Area Network - links high-performance computers with high-speed connections in a cluster
configuration. Also known as Cluster Area Network.

14