Vous êtes sur la page 1sur 26

c   

A     consists of an organized collection of data for one or more uses, typically in digital form.
One way of classifying databases involves the type of their contents, for example: bibliographic,
document-text, statistical. Digital databases are managed using database management systems, which
store database contents, allowing data creation and maintenance, and search and other access.


Architecture

Database architecture consists of three levels, | |, |  and


|. Clearly separating the
three levels was a major feature of the relational database model that dominates 21st century
databases.

The external level defines how users understand the organization of the data. A single database can
have any number of views at the external level. The internal level defines how the data is physically
stored and processed by the computing system. Internal architecture is concerned with cost,
performance, scalability and other operational matters. The conceptual is a level of indirection
between internal and external. It provides a common view of the database that is uncomplicated by
details of how the data is stored or managed, and that can unify the various external views into a
coherent whole.

Database management systems

A database management system (DBMS) consists of software that operates databases, providing
storage, access, security, backup and other facilities. Database management systems can be
categorized according to the database model that they support, such as relational or XML, the type(s)
of computer they support, such as a server cluster or a mobile phone, the query language(s) that access
the database, such as SQL or XQuery, performance trade-offs, such as maximum scale or maximum
speed or others. Some DBMS cover more than one entry in these categories, e.g., supporting multiple
query languages.Examples of some commonly used DBMS are MySQL, PostgreSQL, Microsoft
Access, SQL Server, FileMaker,Oracle, RDBMS, dBASE, Clipper,FoxPro,etc. Almost every database
software comes with an Open Database Connectivity (ODBC) driver that allows the database to
integrate with other databases.

In Other words,
A Database Management System (DBMS) is a computer program for managing a permanent, self-
descriptive repository of data. This repository of data is called a database and is store in one or more
files. There are many reasons why you could use a DBMS:

`  || The database is protected from hardware crashes, disk media failures, and
some user errors
` Ô 
 ||| |  Multiple users can access the database at the same time
` Ô 
 ||| 

  Multiple application programs can read and write data to the
same database
` Ô| 
 Data can be protected against unauthorized read and write access
` x|
 You can specify rules that data must satisfy. A DBMS can control the quality of its
data over and above facilities that that may be provided by application programs
` u |


 Data may be added to the database without disrupting existing programs. Data
can be reorganized for faster performance.
` c 

 
 The database may be partitioned across various sites, organizations, and
hardware platforms

Several DBMS paradigms are available: hierarchical, network, relational, and object-oriented.

º  
  
 
A Relational Database Management System (RDBMS) provides a comprehensive and integrated
approach to information management.

A relational model provides the basis for a relational database. A relational model has three aspects:

` Structures
` Operations
` Integrity rules

Ô  | consist of a collection of objects or relations that store data. An example of relation is a
table. You can store information in a table and use the table to retrieve and modify data.

|
 are used to manipulate data and structures in a database. When using operations. You
must adhere to a predefined set of integrity rules.

x|
  | are laws that govern the operations allowed on data in a database. This ensures data
accuracy and consistency.

Relational database components include:

` Table
` Row
` Column
` Field
Πi  
£ i
`
`

£          


   

Y

? a i i
t t
t   R BM  
it 
l   tl

  t  tit£  lt Œtlt i  ti  tt   t  t  
 i ti 


? º i
i ti  
l l i tl ii  tii  i  R  l 
   
£  l i t tlŒ
ti i  ti  t 
 t  t



?  i
ll
ti   t  ti tlC l    tt tt i t   j
t


l 
l    
ti l tt  t t i £ 
 l
l i ttlŒ
iit   t  t  ti t  i ti 

? £ i i t 
ti    
l il 
ti   tl t i  ti 
til til ii t 
ti l 


Y

Y
Y

Y Y
YY YY  Y

? Π  is a column or a combination of columns that is used to uniquely identify each row in a
table. For example, the column containing department numbers in the S_DEPT table is created as a
primary key and therefore every department number is different. A primary key must contain a value.
It cannot contain a NULL value.

? £   is a column or set of columns that refers to a primary key in the same table or another
table. You use foreign keys to establish principle connections between, or within, tables. A foreign
key must either match a primary key or else be NULL. Rows are connected logically when required.
The logical connections are based upon conditions that define a relationship between corresponding
values, typically between a primary key and a matching foreign key. This relational method of linking
provides great flexibility as it is independent of physical links between records.

Y
Y
Y

Y Y YY YY

º   




An RDBMS is easily accessible. You execute commands in the Structured Query Language (SQL) to
manipulate data. SQL is the international Standards Organization (ISO) standard language for
interacting with a RDBMS.

An RDBMS provides full data independence. The organization of the data is independent of the
applications that use it. You do not need to specify the access routes to tables or know how data is
physically arranged in a database.

A relational database is a collection of individual, named objects. The basic unit of data storage in a
relational database is called a table. A table consists of rows and columns used to store values. For
access purpose, the order of rows and columns is insignificant. You can control the access order as
required.

Y
Y

Y
Y

Y YYY !Y

When querying the database, you use conditional operations such as joins and restrictions. A join
combines data from separate database rows. A restriction limits the specific rows returned by a query Y

Y
Y

Y" Y  Y# !Y

An RDBMS enables data sharing between users. At the same time, you can ensure consistency of data
across multiple tables by using integrity constraints. An RDBMS uses various types of data integrity
constraints. These types include entity, column, referential and user-defined constraints.

The constraint, entity, ensures uniqueness of rows, and the constraint column ensures consistency of
the type of data within a column. The other type, referential, ensures validity of foreign keys, and
user-defined constraints are used to enforce specific business rules.

An RDBMS minimizes the redundancy of data. This means that similar data is not repeated in
multiple tables.

xndexing

Indexing is a technique for improving database performance. The many types of index share the
common property that they eliminate the need to examine every entry when running a query. In large
databases, this can reduce query time/cost by orders of magnitude. The simplest form of index is a
sorted list of values that can be searched using a binary search with an adjacent reference to the
location of the entry, analogous to the index in the back of a book. The same data can have multiple
indexes (an employee database could be indexed by last name and hire date.

Indexes affect performance, but not results. Database designers can add or remove indexes without
changing application logic, reducing maintenance costs as the database grows and database usage
evolves.

Given a particular query, the DBMS' query optimizer is responsible for devising the most efficient
strategy for finding matching data. The optimizer decides which index or indexes to use, how to
combine data from different parts of the database, how to provide data in the order requested, etc.

Indexes can speed up data access, but they consume space in the database, and must be updated each
time the data is altered. Indexes therefore can speed data access but slow data maintenance. These two
properties determine whether a given index is worth the cost.

c    

A     is a data structure that improves the speed of data retrieval operations on a database
table at the cost of slower writes and decreased storage space. Indexes can be created using one or
more columns of a database table, providing the basis for both rapid random lookups and efficient
access of ordered records. The disk space required to store the index is typically less than that
required by the table (since indexes usually contain only the key-fields according to which the table is
to be arranged, and exclude all the other details in the table), yielding the possibility to store indexes
in memory for a table whose data is too large to store in memory.

In a a
 
   , an index is a copy of one part of a table. Some databases extend the power
of indexing by allowing indexes to be created on functions or expressions. For example, an index
could be created on upper(last_name), which would only store the upper case versions of the
last_name field in the index. Another option sometimes supported is the use of "filtered" indexes,
where index entries are created only for those records that satisfy some conditional expression. A
further aspect of flexibility is to permit indexing on user-defined functions, as well as expressions
formed from an assortment of built-in functions.

Indexes may be defined as unique or non-unique. A unique index acts as a constraint on the table by
preventing duplicate entries in the index and thus the backing table.

Index architectures can be classified as clustered or nonclusteredá

] 

The data is present in random order, but the

 aa is specified by the index. The data rows
may be randomly spread throughout the table. The non-clustered index tree contains the index keys in
sorted order, with the leaf level of the index containing the pointer to the page and the row number in
the data page. In non-clustered index:

  The physical order of the rows is not the same as the index order.
  Typically created on column used in JOIN, WHERE, and ORDER BY clauses.
  Good for tables whose values may be modified frequently.

Microsoft SQL Server creates non-clustered indexes by default when CREATE INDEX command is
given. There can be more than one non-clustered index on a database table. It also creates a clustered
index on a primary key by default.
 
Clustering alters the data block into a certain distinct order to match the index, resulting in the row
data being stored in order. Therefore, only one clustered index can be created on a given database
table. Clustered indexes can greatly increase overall speed of retrieval, but usually only where the data
is accessed sequentially in the same or reverse order of the clustered index, or when a range of items
is selected.

Since the physical records are in this sort order on disk, the next row item in the sequence is
immediately before or after the last one, and so fewer data block reads are required. The primary
feature of a clustered index is therefore the ordering of the physical data rows in accordance with the
index blocks that point to them. Some databases separate the data and index blocks into separate files,
others put two completely different data blocks within the same physical file(s). Create an object
where the physical order of rows is same as the index order of the rows and the bottom(leaf) level of
clustered index contains the actual data rows.

They are known as "index organized tables" under Oracle database.


 umn rder

The order in which columns are listed in the index definition is important. It is possible to retrieve a
set of row identifiers using only the first indexed column. However, it is not possible or efficient (on
most databases) to retrieve the set of row identifiers using only the second or greater indexed column.

For example, imagine a phone book that is organized by city first, then by last name, and then by first
name. If you are given the city, you can easily extract the list of all phone numbers for that city.
However, in this phone book it would be very tedious to find all the phone numbers for a given last
name. You would have to look within each city's section for the entries with that last name. Some
databases can do this, others just won¶t use the index.
Appicati ns and imitati ns

Indexes are useful for many applications but come with some limitations. Consider the
following SQL statement: SELECT first_name FROM people WHERE last_name = 'Smith';. To
process this statement without an index the database software must look at the last_name column on
every row in the table (this is known as a full table scan). With an index the database simply follows
the structure until the Smith entry has been found; this is much less computationally expensive than a
full table scan.

Transacti ns

As every software system, a DBMS operates in a faulty computing environment and prone to failures
of many kinds. A failure can corrupt the respective database unless special measures are taken to
prevent this. A DBMS achieves certain levels of fault tolerance by encapsulating in database
transactions units of work (executed programs) performed upon the respective database.

a c 
Most DBMS provide some form of support for transactions, which allow multiple data items to be
updated in a consistent fashion, such that updates that are part of a transaction succeed or fail in
unison. The so-called ACID rules, summarized here, characterize this behavior:
  Atomicity: Either all the data changes in a transaction must happen, or none of them. The
transaction must be completed, or else it must be undone (rolled back).
  Consistency: Every transaction must preserve the declared consistency rules for the database.
  Isolation: Two concurrent transactions cannot interfere with one another. Intermediate results
within one transaction must remain invisible to other transactions. The most extreme form of
isolation is serializability, meaning that transactions that take place concurrently could instead be
performed in some series, without affecting the ultimate result.
  Durability: Completed transactions cannot be aborted later or their results discarded. They must
persist through (for instance) DBMS restarts.

In practice, many DBMSs allow the selective relaxation of these rules to balance perfect behavior
with optimum performance.

       


Concurrency control is essential for the correctness of transactions executed concurrently in a DBMS,
which is the common execution mode for performance reasons. The main concern and goal of
concurrency control is isolation.

  
x 
 refers to the ability of one transaction to see the results of other transactions. Greater
isolation typically reduces performance and/or concurrency, leading DBMSs to provide administrative
options to reduce isolation. For example, in a database that analyzes trends rather than looking at low-
level detail, increased performance might justify allowing readers to see uncommitted changes ("dirty
reads".)

A common way to achieve isolation is by locking. When a transaction modifies a resource, the DBMS
stops other transactions from also modifying it, typically by locking it. Locks also provide one method
of ensuring that data does not change while a transaction is reading it or even that it doesn't change
until a transaction that once read it has completed.

0 
Locks can be | or | 
|, and can lock out || and/or 
| . Locks can be
created


 by the DBMS when a transaction performs an operation, or | 

 at the
transaction's request.

Shared locks allow multiple transactions to lock the same resource. The lock persists until all such
transactions complete. Exclusive locks are held by a single transaction and prevent other transactions
from locking the same resource.

Read locks are usually shared, and prevent other transactions from modifying the resource. Write
locks are exclusive, and prevent other transactions from modifying the resource. On some systems,
write locks also prevent other transactions from reading the resource.
The DBMS implicitly locks data when it is updated, and may also do so when it is read. Transactions
explicitly lock data to ensure that they can complete without complications. Explicit locks may be
useful for some administrative tasks.

Locking can significantly affect database performance, especially with large and complex transactions
in highly concurrent environments.

0   

Locks can be coarse, covering an entire database, fine-grained, covering a single data item, or
intermediate covering a collection of data such as all the rows in a RDBMS table.

c  
Deadlocks occur when two transactions each require data that the other has already locked
exclusively. Deadlock detection is performed by the DBMS, which then aborts one of the transactions
and allows the other to complete.

Security

Database security denotes the system, processes, and procedures that protect a database from
unauthorized activity.

DBMSs usually enforce security through access control, auditing, and encryption:

  Access control manages who can connect to the database via authentication and what they can do
via authorization.
  Auditing records information about database activity: who, what, when, and possibly where.
  Encryption protects data at the lowest possible level by storing and possibly transmitting data in
an unreadable form. The DBMS encrypts data when it is added to the database and decrypts it
when returning query results. This process can occur on the client side of a network connection to
prevent unauthorized access at the point of use.
  
Law and regulation governs the release of information from some databases, protecting medical
history, driving records, telephone logs, etc.

In the United Kingdom, database privacy regulation falls under the Office of the Information
Commissioner. Organizations based in the United Kingdom and holding personal data in digital
format such as databases must register with the Office.
Ô 0  

Y$%Y&'Y( Y ) !Y*$+Y&',(-./*(/YY$0$./+/.$/Y

Ô 0Ô0a
The Ô 0Ô0a cause seects data fr m ne r m re database tabes and/ r viewsá xn its basic f rm the SQL
SELET syntax  s ie this:

Ô  
 
 
 

Let's have a   at the SELET SQL statement ab veá The first part starts with the SELET cause f  wed by
a ist f c umns separated by c mmasá This ist f c umns defines which c umns we are seecting data fr má
The sec nd part f ur SQL SELET starts with the FROM cause f  wed by name f tabe fr m where we are
extracting dataá

We wi use a tabe caed Weather with 3 c umns ± ity, AverageTemperature and Date, t give a rea w rd
SQL SELET exampe:

 a a a c 

New York 22 C 10/10/2005

Seattle 21 C 10/10/2005

Washington 20 C 10/10/2005

T seect a cities fr m the ab ve tabe, we wi use this SQL SELET statement:

Ô  
  

The resut wi be:



New York

Seattle

Washington

xf we want t seect a the data (a c umns) fr m the Weather tabe we can d it with the f  wing SQL
SELET:

Ô  
  

The * repaced the c umn ist f  wing the SELET SQL cause, thus instructing the SQL interpreter t return a
c umnsá
Ô 0]Ôa]a
The Ô 0]Ôa]a cause faciitates the pr cess f inserting data int a SQL tabeá Here is h w y u can
insert a new r w int the Weather tabe, using SQL xSERT xTO: Y

x
Ô x
     !   "  #
$% Ô&'  '&(& () ()((*&#

The resut f the executi n f the SQL xSERT xTO ab ve wi   ie this:

 a a a c 

New York 22 C 10/10/2005

Seattle 21 C 10/10/2005

Washington 20 C 10/10/2005

Los Angeles 20 C 10/10/2005

Y u can pr duce the same resut, with a sighty m dified SQL xSERT xTO syntax:

x
Ô x
  
$% Ô&'  '&(& () ()((*&#

Y u are a wed t mit the ist f c umn names in the SQL xSERT xTO cause, if y u enter vaues f r each f
the tabe c umnsá

When using SQL xSERT xTO y u might n t want t enter vaues f r a c umns and in this case y u have t
specify the ist f c umns y u are entering vaues f rá xf y u d n t enter vaues f r a c umns, then the
c umns y u have mitted must a w LL vaues r at east have a defaut vaue definedá The f  wing SQL
xSERT exampe enters ny 2 f the 3 c umns in the Weather tabe:

x
Ô x
  "  #
$% Ô&+' && () ()((*&#

The resut f this SQL xSERT wi be as f  ws:

 a a a c 


New York 22 C 10/10/2005

Seattle 21 C 10/10/2005

Washington 20 C 10/10/2005

Los Angeles 20 C 10/10/2005

Boston NULL 10/10/2005

We've inserted a new r w f r B st n, but we haven't received the temperature vaue f r 10/10/2005 that's why
we didn't enter itá

Ô 0

The Ô 0 cause w rs in c njuncti n with ther SQL causes ie SELET, xSERT and DATE t
specify a search c nditi n f r these statementsá We are g ing t give an exampe f the SQL WHERE cause
used a ng with the SQL SELET cause:

Ô     !   
  
,  -&
./0&

The first 2 ines f the SELET SQL statement ab ve are aready famiiar fr m the previ us chapter, but the 3rd
ine is new and specifies the SQL WHERE search c nditi n:

,  -&
./0&

xf we transate the SQL statement t pain Engish, it w ud s und ie this "Seect the average temperature f r
the city f ew Y r"

The resut f the added SQL WHERE c nditi n wi be:

a a a


22 C

We can have m re than ne search c nditi n after the SQL WHERE causeá T iustrate this we wi put a c upe
f m re entries in the weather tabe:

 a a a c 


New York 22 C 10/10/2005

Seattle 21 C 10/10/2005

Washington 20 C 10/10/2005

New York 18 C 10/09/2005

Seattle 20 C 10/09/2005

Washington 17 C 10/09/2005

Ô  
  
,     !   1-(
"21&
./0&

The first 2 ines f the ab ve SQL expressi n instruct the SQL engine t retrieve a the c umns fr m the
Weather tabeá The 3rd ine is the ine that defines what c nditi ns needs t be met f r a r w t be returned in ur
resut setá This time we have 2 search c nditi ns after the SQL WHERE cause ± the first c nditi n imits the
r ws t th se with AverageTemperature greater r equa t 20  and the sec nd c nditi n imits the r ws t ny
th se where the ity c umn is different than 'ew Y r'á As y u may have n ticed the 2 SQL WHERE c nditi ns
are c ncatenated with the AD SQL eyw rd, meaning that b th c nditi ns have t be met f r a r ws returned
in the resut setá

The resut f this SQL WHERE cause c nditi n is be w:


 a a a c 
Seattle 21 C 10/10/2005

Washington 20 C 10/10/2005

Seattle 20 C 10/09/2005

What wi happen if we c ncatenate the 2 SQL WHERE search c nditi n with the OR SQL eyw rd instead f the
AD SQL eyw rd?

Ô  
  
,     !   1-(21&
./0&

 a a a c 

New York 22 C 10/10/2005

Seattle 21 C 10/10/2005

Washington 20 C 10/10/2005

Seattle 20 C 10/09/2005

Washington 17 C 10/09/2005

As y u can see this time we have 2 m re r ws returned (in green) c mpared with the previ us SQL WHERE
cause resutsá Why has this happened? This time we have used the OR SQL eyw rd, which means that every
r w which satisfies at east ne f the 2 SQL WHERE c nditi ns wi be returnedá The first r w d esn¶t satisfy the
c nditi n f r the ity, but satisfy the average temperature c nditi n that¶s why it sh ws up in the fina resut setá
The ast r w satisfy the ity c nditi n, but n t the average temperature c nditi n, and because we need t meet
at east ne f the 2 SQL WHERE c nditi ns this r ws is presented in the resut set t á

Ô 0cÔa]a

The Ô 0cÔa]a cause w rs in c njuncti n with the SQL SELET cause and seects ny distinct (unique)
data fr m a database tabe(s)á Here is an exampe f SQL DxSTxT cause:

Ô  "xÔx
 
 

As y u can see the DxSTxT eyw rd g es immediatey after the SELET cause and is then f  wed by a ist
f ne r m re c umn namesá x' give y u an exampe why y u might need t use the DxSTxT SQL causeá x'
use the Weather tabe fr m the SQL WHERE tut ria t dem nstrate the SQL DxSTxT appicati n:
 a a a c 
New York 22 C 10/10/2005

Seattle 21 C 10/10/2005

Washington 20 C 10/10/2005

New York 18 C 10/09/2005

Seattle 20 C 10/09/2005

Washington 17 C 10/09/2005

 nsider the f  wing SQL statement utiizing SQL DxSTxT:

Ô  "xÔx
 
  

This SQL DxSTxT expressi n wi return a ist with a cities f und in the ity c umn f the Weather tabe, but it
wi rem ve the dupicates and eave ny a singe entry f r each city:


New York

Seattle

Washington

Y u can use the SQL DxSTxT with any tabe c umn f r exampe with the AverageTemperature:

Ô  "xÔx
   !   
  

The resut f this SQL DxSTxT wi be:

a a a


22 C

21 C

20 C

18 C

17 C

Y u can use the SQL DxSTxT with m re than ne c umn and if y u d that, the resut wi have a distinct
c mbinati ns f vaues f r a c umnsá F r exampe if ur Weather tabe has the f  wing entries:
 a a a c 
New York 22 C 10/10/2005

New York 22 C 10/09/2005

New York 20 C 10/08/2005

New York 20 C 10/07/2005

New York 18 C 10/06/2005

And we run the f  wing SQL DxSTxT statement:

Ô  "xÔx
   !   
  

The resut wi be:

 a a a

New York 22 C

New York 20 C

New York 18 C


Ô 0ca
The Ô 0ca cause serves t update data in database tabeá The SQL DATE cause basic syntax  s
ie this:

%3"   
Ô  -$   -$  

The first ine f the ab ve SQL DATE statement defines which tabe we are updatingá The sec nd ine starts
with the SET SQL eyw rd f  wed by ne r m re  umn = Vaue pairs separated by c mmasá The sec nd
ine f the DATE statement defines which tabe c umns t update and with what vaueá

ease c nsider the f  wing SQL DATE syntax:

%3"   
Ô    !   -(

Bef re we run this DATE SQL expressi n, ur Weather tabe  s ie this:

 a a a c 

New York 22 C 10/10/2005

Seattle 21 C 10/10/2005
Washington 20 C 10/10/2005

New York 18 C 10/09/2005

Seattle 20 C 10/09/2005

Washington 17 C 10/09/2005

After the update it  s ie this:

 a a a c 

New York 20 C 10/10/2005

Seattle 20 C 10/10/2005

Washington 20 C 10/10/2005

New York 20 C 10/09/2005

Seattle 20 C 10/09/2005

Washington 20 C 10/09/2005

As y u can see a vaues in the AverageTemperature c umn were set t 20á
But what if we want t update (change) ny the AverageTemperature vaues f r ew Y r? We can d that by
using the DATE and the WHERE SQL causes t gether:

%3"   
Ô    !   -(
,  -&
./0&

The resut wi be:

 a a a c 

New York 20 C 10/10/2005

Seattle 21 C 10/10/2005

Washington 20 C 10/10/2005

New York 20 C 10/09/2005

Seattle 20 C 10/09/2005

Washington 17 C 10/09/2005

xn s me cases y u might want t DATE a c umn in a tabe, and mae the new vaue f the c umn
dependabe n the d neá F r exampe y u might want t increase the AverageTemperature c umn vaues
with 5  f r a entries in the tabeá T d this ind f SQL DATE y u can use the f  wing DATE
statement:

%3"   
Ô    !   -   !   4*
Our SQL DATE statement ab ve simpy instructs says that the new vaue f AverageTemperature wi be
equa t the d ne pus 5á

The SQL DATE cause is very p werfu and y u can easiy ater ne r m re tabe entries by mistae, thus
 sing their rigina vauesá T av id that mae sure y u update ny the r ws that y u want, by utiizing the SQL
WHERE causeá xt's a g d idea t mae a bacup f y ur tabe bef re running DATE statements f r tabes
with imp rtant dataá

Ô 0c0a

The Ô 0c0a cause is used t deete data fr m a database tabeá The simpest SQL DELETE syntax  s
ie this:

"    

The SQL DELETE statement ab ve wi deete a data fr m the Tabe1 tabeá

M st f the time we wi want t deete ny tabe r ws satisfying certain search criteria defined in the SQL
WHERE causeá We wi use the Weather tabe again t iustrate h w t use SQL DELETE t deete a imited
number f r ws fr m a tabe:

 a a a c 

New York 22 C 10/10/2005

Seattle 21 C 10/10/2005

Washington 20 C 10/10/2005

New York 18 C 10/09/2005

Seattle 20 C 10/09/2005

Washington 17 C 10/09/2005

xf we wanted t deete a r ws c ntaining Weather data f r ew Y r, we w ud use the f  wing SQL DELETE
statement:

"     
,  -&
./0&

Be extremey carefu when using SQL DELETE, as y u cann t rest re data nce y u deete it fr m the tabeá Y u
might want t mae a bacup f imp rtant data bef re perf rming deete n itá

Ô 0a]aa0

The Ô 0a]aa0 cause deetes a r ws fr m a database tabeá Here is the SQL TRATE
TABKE syntax:
%
 +   

The SQL TRATE TABLE cause d es the same as a SQL DELETE cause which d esn't have a SQL
WHERE causeá The f  wing tw SQL statements are equivaent:

%
 +   

"     

se SQL TRATE TABLE ny when y u want t deete a r ws in a tabeá

Ô 0    

Ô 0      are used t sum, c unt, get the average, get the minimum and get the maximum
vaues fr m a c umn r fr m a sub-set f c umn vauesá

T c unt the r ws in the Weather tabe we can use the SQL OT aggregate functi n:

Ô  %
#
  

T get the average temperature f r the Weather tabe use the AVG SQL aggregate functi n:

Ô  $5   !   #
  

xf y u want t get the average temperature f r a particuar city y u can d it this way:

Ô  $5   !   #
  
,  -&
./0&

T get the minimum vaue fr m a numeric tabe c umn, use the SQL Mx aggregate functi n:

Ô  x
   !   #
  

T get the maximum vaue fr m a numeric tabe c umn, use the SQL MAX aggregate functi n:

Ô  6   !   #
  

Finay t sum up the vaues in the c umn use the SQL SM aggregate functi n:

Ô  Ô%   !   #
  

Y u can specify search criteria with the SQL WHERE cause f r any f the ab ve SQL aggregate functi nsá

Ô 0

The Ô 0 cause is used a ng with the SQL aggregate functi ns and specifies the gr ups where
seected r ws are pacedá WHE ne r m re aggregate functi ns are presented in the SQL SELET c umn
ist, the SQL GRO BY cause cacuates a summary vaue f r each gr upá T grasp this c ncept we wi
iustrate the SQL GRO BY appicati n with exampeá  nsider the aready famiiar Weather tabe:
 a a a c 
New York 22 C 10/10/2005

Seattle 21 C 10/10/2005

Washington 20 C 10/10/2005

New York 18 C 10/09/2005

Seattle 20 C 10/09/2005

Washington 17 C 10/09/2005

Our tas is t cacuate the average temperature f r each f the cities in the Weather tabeá Here is h w t
acc mpish that using the SQL GRO BY cause:

Ô  $5   !   #
  
5%3+/

The resut f this SQL GRO BY statement is the f  wing:

 a a a

Washington 18.5 C

Seattle 20.5 C

New York 20 C

As y u can see in the resut data set, we have ne r w f r each cityá Each city in ur SQL ORDER BY statement,
represents ne gr up because the ity c umn is specified in the GRO BY causeá
But what is the number in the AverageTemperature c umn? H w c me we have ny ne number f r each city
when we have mutipe temperature entries f r each f the cities in the Weather tabe? Because the
AverageTemperature c umn is an argument f r the SQL AVG aggregate functi n, the singe vaue we see in the
fina resut set is simpy the average temperature vaue f r its respective city:

Washingt n average temperature = (20 + 17)/2 = 18á5


Seatte average temperature = (21 + 20)/2 = 20á5
ew Y r average temperature = (20 + 20)/2 = 20

When GRO BY is used, ne f the f  wing must be true:

1á Each c umn which is n t part f an aggregate expressi n in the seect ist is presented in the SQL GRO
BY causeá
2á The SQL GRO BY expressi n matches exacty the seect ist expressi ná

Here is an exampe f inc rrect GRO BY statement:

Ô  $5   !   #"  


  
5%3+/

This SQL GRO BY statement is wr ng because the Date c umn is presented in the SQL SELET ist, but is
n t in the GRO BY causeá The c rrect SQL GRO BY statement sh ud   ie this:
Ô  $5   !   #"  
  
5%3+/" 
Y

Ô 0]

The Ô 0] eyw rd pr vides a search c nditi n f r a gr up r aggregateá The SQL HAVxG cause
w rs t gether with the SQL SELET causeá The SQL HAVxG cause is s mewhat simiar t the SQL WHERE
cause, because it specifies a search c nditi ná

There is ne imp rtant difference between SQL HAVxG and SQL WHERE causesá The SQL WHERE cause
c nditi n is tested against each and every r w f data, whie the SQL HAVxG cause c nditi n is tested against
the gr ups and/ r aggregates specified in the SQL GRO BY cause and/ r the SQL SELET c umn istá

xt is imp rtant t understand that if a SQL statement c ntains b th SQL WHERE and SQL HAVxG causes the
SQL WHERE cause is appied first, and the SQL HAVxG cause is appied ater t the gr ups and/ r
aggregatesá

We wi dem nstrate h w t use SQL HAVxG using ur Weather tabe:

 a a a c 

New York 22 C 10/10/2005

Seattle 21 C 10/10/2005

Washington 20 C 10/10/2005

New York 18 C 10/09/2005

Seattle 20 C 10/09/2005

Washington 17 C 10/09/2005

Our g a is t seect a cities, with average temperature greater than 19 á T acc mpish that we are g ing t
use the f  wing SQL HAVxG statement:

Ô  $5   !   #
  
5%3+/
,$x
5$5   !   #1 7

The resut f the ab ve SQL HAVxG statement is dispayed be w:

 a a a


Seattle 20.5 C

New York 20 C

xn the SQL GRO BY chapter we used am st the same SQL statement but with ut the HAVxG part:

Ô  $5   !   #
  
5%3+/
The resut f it was the f  wing:

 a a a

Washington 18.5 C

Seattle 20.5 C

New York 20 C

By appying the SQL HAVxG cause t this resut set c nsisting f three gr ups, we rem ve the Washingt n
gr up simpy because its AverageTemperature vaue is ess than 19á

Ô 0]c
The SQL AD & SQL OR eyw rds are used t gether with the SQL WHERE cause t j in tw r m re search
c nditi ns specified in the WHERE causeá Let's use the weather tabe t iustrate h w t use SQL AD & SQL
OR eyw rds:

 a a a c 

New York 22 C 10/10/2005

Seattle 21 C 10/10/2005

Washington 20 C 10/10/2005

New York 18 C 10/09/2005

Seattle 20 C 10/09/2005

Washington 17 C 10/09/2005

Here is h w t seect a r ws where the city is either Washingt n r ew Y r:

Ô  
  
,  -& '  &-&
./0&

The resut f this SQL OR expressi n wi be:

 a a a c 

New York 22 C 10/10/2005

Washington 20 C 10/10/2005

New York 18 C 10/09/2005

Washington 17 C 10/09/2005
The f  wing SQL statement using the SQL AD eyw rd wi seect a dates n which the average temperature
in Washingt n was greater than 18 :

Ô  "  
  
,  -& '  &
"   !   1 8

Here is the resut f this SQL AD expressi n:

c 

10/10/2005
Y

Ô 0]
The Ô 0] cause seects data fr m tw r m re tabes tied t gether by matching tabe c umnsá T iustrate
h w t use the SQL JOx cause we wi use the aready famiiar Weather tabe and we wi intr duce a new ne
caed Stateá

    

 a a a c 


New York 22 C 10/10/2005

Seattle 21 C 10/10/2005

Washington 20 C 10/10/2005

New York 18 C 10/09/2005

Seattle 20 C 10/09/2005

Washington 17 C 10/09/2005

Ô   

Ô  

District of Columbia Washington

Washington Seattle

New York New York

Texas Houston

xf we want t seect a the data fr m the Weather tabe, and t add ne m re additi na c umn caed State t
the resut, we can d it the f  wing way:
Ô    9  9   !     9"  Ô  9Ô  
  Ô  
,    9-Ô  9

xn the SQL SELET ist we see 4 c umn names prefixed with their respective tabe names, s there is n
c nfusi n which c umn fr m which tabe we are referencingá
The SQL FROM cause has c mma separated ist f the tw tabes we are seecting data fr má Finay the SQL
WHERE cause defines that the ity c umn fr m the weather tabe has t match the ity c umn fr m the State
tabeá

We can re-write the ab ve SQL statement using SQL JOx and the resut wi be the same, but the perf rmance
in genera wi be much better:
SELET Weatheráity, WeatheráAverageTemperature, WeatheráDate, StateáState
FROM Weather JOx State
O Weatheráity = Stateáity

The first ine f this SQL JOx statement is identica t the first ine f the previ us SQL expressi ná The sec nd
ine uses the SQL JOx cause instead f c mma, and the third ine uses the O eyw rd t define the c umns
we are j ining ná

The resut f this SQL JOx wi be:

 a a a c  Ô 

New York 22 C 10/10/2005 New York

Seattle 21 C 10/10/2005 Washington

Washington 20 C 10/10/2005 District of Columbia

New York 18 C 10/09/2005 New York

Seattle 20 C 10/09/2005 Washington

Washington 17 C 10/09/2005 District of Columbia


Y

Ô 0]]
The Ô 0]] cause merges the resuts f tw r m re SELET SQL queries int ne resut setá When using
SQL xO, a the SQL expressi ns participating in the xO must have the same structure (they have t
have the same number f c umns and same r c mpatibe data types)á Y u have t eep the c umn rder f a
uni nized SQL SELET expressi ns unif rm, therwise y u¶ get an err rá

Here is an exampe f SQL xO statement:

Ô     !   "  


  

%
x


Ô     !   "  
  :

The resut f the SQL xO statement ab ve wi merge a rec rds fr m the Weather and the WeatherArchive
tabes and the c umn names in the resut wi remain the same as the c umn names in the first SELET
expressi n in the xO statementá This SQL xO expressi n wi as rem ve a dupicates (if any)á
S mething imp rtant t remember when using SQL xO is that the dupicated r ws are rem ved fr m the
resut setá xf y u want a r ws, incuding dupicate nes t be returned, simpy put the ALL eyw rd after the
xO cause:

Ô     !   "  


  

%
x


Ô     !   "  
  :
Y

Vous aimerez peut-être aussi